Software Engineering

Module 1 :
1. Software Engineering—(a) Characteristics (b) Software Matrices & Models
(c) Process & Product Metrices
2. UML --- (a) Class (b) Object (c) Class Relationship----[ Inheritance,
Association, Aggregation, Dependency ]
3. User interface design: (a) Use Case Model (b) Class diagram
(c) Sequence diagram (d) Collaboration diagram (e) Activity Diagram
-----------------------------------------------------------------------------------------------------------
--------------- 1. Software Engineering_:
• Definition:
Software Engineering is the systematic, disciplined, and quantifiable
approach to the development, operation, and maintenance of software.
• Goal:
To create high-quality software that is reliable, efficient, cost-effective,
and easy to maintain.
• Key Focus Areas:
o Applying engineering principles to software development.
o Managing complex projects systematically.
o Ensuring customer satisfaction with delivered software.
o Cost management and time management.
• Origin:
o The term "Software Engineering" was first used in a 1968 conference
by NATO to solve the "software crisis".
• Need for Software Engineering:
o Increase in software complexity.
Page 1 of 18
 o Increase in software size and user expectations.
o Need for systematic, repeatable methods instead of "ad-hoc"
programming.
• Major Activities in Software Engineering:
o Requirements gathering
o System design
o Implementation (coding)
o Testing
o Deployment
o Maintenance and updates
(A) Characteristic of Software engineering :-
S.no Characteristic Explanation
1 Systematic Approach Follows well-defined models and
methods rather than random
coding
2 Quality Focused Aims to build software that is bug-
free, secure, efficient, and user-
friendly.
3 Process-Oriented Uses specific development
processes like Waterfall, Agile,
Spiral, etc.
4 Efficiency Ensures that software
development is done within time
and budget limits.
5 Scalability Software should be able to handle
increasing loads or growing
requirements easily.
6 Reliability Software should function
correctly under all conditions
without failure.

Page 2 of 18
 7 Security Protects software from
unauthorized access, threats, and
vulnerabilities

Bonus Tips :
If you ever want to become a good software engineer, always focus on:
• Writing clean code
• Following software processes
• Always thinking about how others will use and maintain your code later.
(B) Software Metrices :
• Definition:
A Metric is a standard of measurement that helps quantify some attribute
of a software project, process, or product.
• Goal:
To measure, analyze, and improve the quality, productivity, efficiency,
and performance of software development.
• Why Metrics are Important:
o Monitor project progress.
o Identify risks early.
o Help in decision-making.
o Improve quality control.
o Support continuous improvement.
• Where Metrics are Applied:
o During project planning.
o During coding (to monitor size, complexity).
o During testing (to check defect rates, test coverage).
Page 3 of 18
 o After deployment (to monitor performance, user satisfaction).
Type Description Example
1. Product Metrics Measure the software Size, complexity, design
product's characteristics. features, performance
2. Process Metrics Measure the efficiency
of the development Development time, cost,
process. effort, defect detection
rate
3. Project Metrics Measure project Team productivity,
management activities. schedule adherence,
budget variance
4. Maintenance Metrics Measure software Number of defects
maintainability and reported and fixed, time
support work. to fix bugs

Metrics are mainly divided into four major types:

1. Product Metrics
• Definition:
Measure the characteristics of the software product itself (what is being
built).
• Examples:
o Size Metrics: Lines of Code (LOC), Function Points (FP)
o Complexity Metrics: Cyclomatic Complexity
o Quality Metrics: Number of bugs, Defect density
o Performance Metrics: Response time, Throughput
• Purpose:
To ensure the product is efficient, reliable, and high-quality.

2. Process Metrics
Page 4 of 18
 • Definition:
Measure the efficiency and effectiveness of the software development
process (how it is built).
• Examples:
o Defect Removal Efficiency (DRE): % of defects found before release
o Time to Market: How quickly the software is delivered
o Process Cycle Time: Time taken for each phase (e.g., coding, testing)
• Purpose:
To improve development processes for better productivity and quality.

3. Project Metrics
• Definition:
Measure the management aspects of a software project (how the project
is progressing).
• Examples:
o Effort Metrics: Person-hours, Developer hours spent
o Schedule Metrics: Planned vs actual timelines
o Cost Metrics: Budget vs actual cost
o Productivity Metrics: Output per developer
• Purpose:
To monitor, control, and plan the project more effectively.

4. Maintenance Metrics
• Definition:
Measure how well software maintenance is performed after the software
is deployed.

Page 5 of 18
 • Examples:
o Number of defects reported/fixed
o Average time to fix bugs (MTTR - Mean Time to Repair)
o Frequency of updates or patches
• Purpose:
To ensure long-term health, performance, and user satisfaction of the
software after release.
Quick Recap Table :
Type What It Measures Main Goal
Product Metrics Product properties like Build better software
size, complexity, quality
Process Metrics Development process Improve processes
efficiency
Project Metrics Project management Deliver projects on time
parameters and within budget
Maintenance Metrics Post-deployment Maintain and improve
software health deployed software

In simple Words
"Product Metrics" measure what you build,
"Process Metrics" measure how you build it,
"Project Metrics" measure how the project is managed,
and "Maintenance Metrics" measure how you take care of it afterward.
Common Software Metrices :
Metric What it Measures
LOC (Lines of Code) Size of the program
Cyclomatic Complexity Complexity of the code
Defect Density Number of defects per 1000 lines of
code
Code Coverage % of code tested by automated tests
Mean Time to Repair (MTTR) Average time to fix a bug
Page 6 of 18
 Customer Satisfaction Score (CSAT) End-user satisfaction

Characteristics of Software Metrics

• Quantitative: Metrics must be quantitative in order to be helpful. It means that
metrics can be stated numerically.
• Understandable: Metric computation should be simple to grasp, and the
method for computing them should be well explained.
• Applicability: Metrics should be applied during the early stages of software
development.
• Repeatable: When measured regularly and consistently in nature, the metric
values should be the same.
• Economical: Metric computation should be cost-effective.
• Language Agnostic: Metrics should be language-independent, meaning their
computation should not depend on any programming language.
In Simple Words :
1.Metrics = Measurement tools.
2.Good metrics must be simple, useful, trustworthy, and help you make better
decisions about your software.
Advantages of Software Metrics
• The software system design technique can be analysed in comparison to other
designs.
• Using software metrics, the properties of various programming languages can
be explored for study and comparison.
• Software metrics in software engineering can be used to create software
quality requirements.

Page 7 of 18
• Software system compliance with requirements and standards can be verified.
• It is possible to infer the effort required to design and develop software
systems.
• The code's complexity can be calculated.
• It is possible to decide whether or not to divide a complex module into smaller
ones.
• It is possible to direct the best use of resource managers.
• It is possible to make design trade-offs and compare maintenance and
software development expenses.
Disadvantages of Software Metrics
• It isn't easy to apply measurements in all situations. In some circumstances, it
is difficult and costly.
• It is challenging to validate historical or empirical evidence used for verification
and argumentation.
• Although software products can be managed, technical staff performance
cannot be measured using software metrics.
• The available tools and working environment are utilized to define and derive
software metrics, and there is no standard for doing so.
• Certain variables are estimated using predictive models and are not always
known.
UML-Unified Modeling Language.
• Definition:
UML stands for Unified Modeling Language — it is a standard way to
visualize, design, and document the structure and behavior of a software
system.
• Purpose:

Page 8 of 18
 o To help developers, designers, and stakeholders understand a system
better.
o To plan before coding begins.
o To communicate ideas clearly across teams.
o To document the design for future maintenance.
• Who Uses UML?
o Software engineers
o System architects
o Business analysts
o Project managers
• Origin:
Created by combining methods from Grady Booch, James Rumbaugh, and
Ivar Jacobson in the 1990s under the supervision of OMG (Object
Management Group).

Why Use UML?

• Better communication among teams.
• Catch design problems early.
• Save time and cost in development.
• Provide a blueprint for the system before coding.
• Make future maintenance and upgrades easier.
Types Of UML diagram :
There are two broad classification of UML diagrams.
• Structural Diagrams
o Depict a static view or structure of a system.

Page 9 of 18
 o Presents an outline for the system.
o Widely used in the documentation of software architecture.
o Stresses the elements to be present that are to be modeled.
• Behavioural Diagrams
o Portray a dynamic view or the behaviour of a system.
o Describes the functioning of the system.
o Defines the interaction within the system.

1. Structural Diagrams (Show how the system is structured)

Diagram Purpose Example

Ex: Student, Teacher, and

Class Diagram Shows classes and relationships
Course classes

Ex: Student1 enrolled in

Object Diagram Snapshot of objects at a moment
CourseA

Component Organization of software Ex: Login Service, Payment

Diagram components Module

Page 10 of 18
Diagram Purpose Example

Deployment Physical arrangement of Ex: Web server, database

Diagram hardware and software server

2. Behavioral Diagrams (Show how the system behaves)

Diagram Purpose Example

Use Case
Shows user interactions Ex: "Login to system" use case
Diagram

Sequence Order of messages over Ex: User sends login request →

Diagram time server responds

Activity
Flow of actions Ex: Steps to register on a website
Diagram

States and transitions of an Ex: Order: Created → Packed →

State Diagram
object Shipped

Structural Diagram :
• Definition:
Structural diagrams in UML represent the static (fixed) structure of a
system — showing classes, objects, components, relationships, and
hardware.
• Purpose:
o To show how parts of a system are organized.
o To represent the building blocks of software.
o To define types of objects and their relationships.
o To visualize the architecture of a system.

Page 11 of 18
 • Key Point:
Structural diagrams do not show behavior or changes over time; they only
show what exists and how things are connected.

Important Structural Diagrams in UML

Here are the main types of Structural Diagrams:

1. Class Diagram
• What it shows:
o Classes in the system, their attributes, operations (methods), and
relationships (association, inheritance).
• Example:
A Student class with attributes like Name, RollNo, and methods like
enrollCourse().

2. Object Diagram
• What it shows:
o Specific instances (objects) of classes at a particular moment.
• Example:
Object: Student1:Student with Name = "Abhishek", RollNo = "45".

3. Component Diagram
• What it shows:
o Organization and dependencies among software components
(modules, libraries).

Page 12 of 18
 • Example:
Components like LoginService, PaymentService, and how they interact.

4. Deployment Diagram
• What it shows:
o Physical deployment of artifacts (software) on hardware (servers,
devices).
• Example:
Web Application deployed on Web Server, Database deployed on Database
Server.

5. Package Diagram
• What it shows:
o Grouping of classes or components into packages (folders or groups).
• Example:
A UserModule package containing User, Profile, Account classes.

Summary Table

Structural Diagram Purpose

Class Diagram Shows classes and their relationships

Object Diagram Shows objects and their state at a point in time

Component Diagram Shows software component organization

Deployment Diagram Shows hardware/software deployment

Package Diagram Groups related elements

Page 13 of 18
Structural Diagram Purpose

Profile Diagram Customizes UML for specific needs

In Simple Words:
Structural diagrams show what exists in the system:
Who are the players (classes/objects),
Where they live (components/packages),
and how they are installed (deployment).

Bonus Tip:
• The Class Diagram is the most important structural diagram and is used in
almost every software project.
• If you master Class, Component, and Deployment Diagrams, you will be
able to design most real-world systems easily!

Behavioral Diagram
• Definition:
Behavioral diagrams in UML describe the dynamic behavior of a system —
how the system acts, responds, or interacts over time.
• Purpose:
• To visualize the flow of activities, interaction between objects, and state
changes in the system.
• To model how the system behaves under different scenarios.
• To understand how the system reacts to inputs, users, or events.
• Key Point:
Behavioral diagrams focus on actions and interactions, NOT static
structure.

Page 14 of 18
 •

• Important Behavioral Diagrams in UML

• Here are the main types of Behavioral Diagrams:

• 1. Use Case Diagram

• What it shows:
• The interactions between actors (users or other systems) and the system
through different use cases (functions).
• Example:
A student logs into a library system and borrows books.

• 2. Sequence Diagram
• What it shows:
• The sequence of messages exchanged between objects over time.
• Example:
User → sends login request → server verifies → server responds.

• 3. Activity Diagram
• What it shows:
• The workflow or step-by-step flow of an activity or operation.
• Example:
Steps in online shopping: Browse → Add to Cart → Checkout → Payment.

• 4. State Diagram (State Machine Diagram)

• What it shows:

Page 15 of 18
 • The different states of an object and how it transitions between states
based on events.
• Example:
Order object: New → Processing → Shipped → Delivered.

• 5. Communication Diagram (Also called Collaboration Diagram)

• What it shows:
• The interactions between objects with a focus on relationships instead of
time sequence.
• Example:
How a customer object interacts with the payment gateway and product
inventory.

• 6. Interaction Overview Diagram

• What it shows:
• A high-level overview combining sequence and activity diagrams.
• Example:
Summarizing an e-commerce flow: Login Interaction → Browse Products →
Place Order.

• 7. Timing Diagram
• What it shows:
• How objects change their state or behavior over time with respect to a
timeline.
• Example:
Response times between sensor signals in a robot.

•
Page 16 of 18
 • Summary Table

• Behavioral Diagram • Purpose

• Use Case Diagram • Shows user interactions with the system

• Sequence Diagram • Shows message flow over time

• Activity Diagram • Shows the workflow or operations flow

• State Diagram • Shows object states and transitions

• Shows object interactions (relationship-

• Communication Diagram
focused)

• Interaction Overview
• Summarizes interaction flows
Diagram

• Timing Diagram • Shows state changes over time

• In Simple Words:
• Behavioral diagrams tell the story of what happens in the system:
Who does what, in what order, what flows happen, and how things
change with time and events.

• Bonus Tip:
• Use Case Diagram is most used in the early stages (requirement
gathering).
• Sequence and Activity Diagrams are often used during design and
development.
• State Diagram is important when designing objects with many states (like
orders, tickets, accounts).

Page 17 of 18
For Class diagram and use case diagram refer S.E college pdf for better
understanding……

Page 18 of 18