Software Engineering

116U01C501

MODULE 1 1
MODULE 1: Introduction to Software Engineering

CO 1:Understand and use basic knowledge in software

engineering.

1. Software Engineering, Software Process,

2. Capability Maturity Model (CMM) Generic Process Model,
3. Prescriptive Process Models: The Waterfall Model, V-model,
Incremental Process Models, Evolutionary Process Models,
Concurrent Models,
4. Agile process, Agility Principles,
5. Extreme Programming (XP), Scrum, Kanban model

MODULE 1 2
Definition of Software Engineering
• IEEE defines software engineering as: (1) The application of a
systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software; that is,
the application of engineering to software. (2) Study of
approaches as in (1).
• Fritz Bauer defined Software engineering as the ―establishment
and use of sound engineering principles in order to obtain
economically software that is reliable and works efficiently on
real machines. ―

MODULE 1 3
 Why Software Engineering is Important
:
Complexity of Software: Modern systems are highly complex (e.g., AI systems,
cloud platforms).
Rapid Changes in Requirements: Market trends and customer needs evolve
quickly.
Reliability and Quality: Faulty software can lead to financial or even life-threatening
consequences.
Examples of Software Failures:
NASA Mars Climate Orbiter (1999): Lost due to a unit conversion error in software.
Ariane 5 Rocket Explosion (1996): Software bug caused rocket self-destruction.
Objectives of Software Engineering:
Deliver software on time and within budget.
Develop software that is efficient, reliable, and maintainable.
Meet customer requirements effectively.

4
5
6
7
8
9
1
1. Abstraction:
Definition: Abstraction is the process of focusing on the essential features of a
problem while ignoring irrelevant details.

2. Decomposition:
Definition: Decomposition involves breaking down a complex problem or system
into smaller, manageable parts or modules

Combined Impact:
Enhanced Understanding: Breaking down and simplifying systems helps humans
grasp functionality more easily.
Parallel Development: Teams can work on separate modules simultaneously,
boosting productivity.
Reusability: Abstraction and decomposition promote reusable components,
reducing redundant work.
Error Reduction: Smaller modules are easier to test and debug, improving system
1
reliability.
THE SOFTWARE PROCESS
Characterized by:
• Common process framework established by defining a small number of framework activities that
are applicable to all software projects, regardless of their size or complexity

MODULE 1 12
 Process Framework activities
The following generic process framework is applicable to the vast majority of S/W projects.
• Communication: By communication, customer requirement gathering is done. Communication with
consumers and stakeholders to determine the system’s objectives and the software’s requirements.
• Planning: Establish engineering work plan, describes technical risk, lists resources requirements, work
produced and defines work schedule.
• Modeling: Architectural models and design to better understand the problem and for work towards the
best solution. The software model is prepared by:
o Analysis of requirements
o Design
• Construction: Creating code, testing the system, fixing bugs, and confirming that all criteria are met.
The software design is mapped into a code by:
o Code generation
o Testing
• Deployment: In this activity, a complete or non-complete product or software is represented to the
customers to evaluate and give feedback. On the basis of their feedback, we modify the product for the
supply of better products.
• Each engineering action defined by a framework activity comprises a list of needed work outputs,
project milestones, and software quality assurance (SQA) points.

MODULE 1 13
 Framework activities
Framework activities are the core building blocks of the software process. These
are:
Tasks:
The specific actions required to achieve objectives within each activity.
Examples: Writing code, testing, gathering requirements.
Milestones & Deliverables:
Milestones: Checkpoints to measure progress (e.g., completion of the design phase).
Deliverables: Tangible outputs of a phase, like requirements documents, test plans, or the final product.
SQA (Software Quality Assurance) Points:
Quality checks performed during the process to ensure that the software meets customer requirements
and quality standards.
Examples: Code reviews, unit testing, and system testing.
Umbrella Activities
These are ongoing activities that span the entire software process. They ensure the overall success of
the project and include:
Project Management: Scheduling, resource allocation, and risk management.
Configuration Management: Managing changes in software components to ensure consistency.
Quality Assurance (QA): Continuous monitoring and testing of software quality.
Documentation: Preparing and maintaining all relevant documents throughout the project. 1
 Process Maturity
The Capability Maturity Model (CMM) is a framework that helps organizations
improve the quality, efficiency, and effectiveness of their software development
processes. It was developed by the Software Engineering Institute (SEI) to address
challenges in managing software development and maintenance projects.
Key Concepts of CMM
Purpose: To provide a structured pathway for organizations to improve their software
processes systematically.It helps organizations evaluate their current processes and
develop strategies to enhance productivity, quality, and predictability.
Structure: CMM defines five levels of process maturity, ranging from ad-hoc practices
to optimized processes.
Five levels usually it is termed as Capability Maturity Model (CMM) Levels
CMM is a strategy for improving the software process, to generate quality software.
MODULE 1 15
CMM Levels

MODULE 1 16
 CMM Levels
• Level 1: Initial. The software process is characterized as ad hoc and occasionally even
chaotic. Few processes are defined, and success depends on individual effort.
• Level 2: Repeatable (Managed). Basic project management processes are established to
track cost, schedule, and functionality. The necessary process discipline is in place to repeat
earlier successes on projects with similar applications.(No documentation, no training, no
improvement, no process documentation)
• Level 3: Defined. The software process for both management and engineering activities is
documented, standardized, and integrated into an organization-wide software process. All
projects use a documented and approved version of the organization's process for
developing and supporting software. This level includes all characteristics defined for level 2.
• Level 4: Managed (Quantitively managed). Detailed measures of the software process and
product quality are collected. Both the software process and products are quantitatively
understood and controlled using detailed measures. This level includes all characteristics
defined for level 3.
• Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback
from the process and from testing innovative ideas and technologies. This level includes all
characteristics defined for level 4.
MODULE 1 17
Task Name: "Software in Everyday Life"
Objective: To help students connect the theoretical concepts of software
engineering to real-world applications.
Instructions:
Take real-life examples of software systems that you use daily (e.g., WhatsApp, ATMs, e-commerce
platforms).
The type of software they think it is (e.g., embedded, application, system software).
One key challenge they think developers faced while building it (e.g., scalability, security, user
experience).

1
Activities performed in life cycle of a Software
Development projects
Requirement
Analysis
5. Implementation
1. Requirement Analysis

Implementation Design

4. Testing
2. Design

Testing Development

3. Development
MODULE 1 19
Generic Software Development Process Models

1. Code & Fix Model

2. Waterfall model
3. Rapid Application Development (RAD)
4. Spiral
5. Iterative
6. Evolutionary
7. Agile

MODULE 1 20
Sequential Model: Waterfall Model
Function
Requirements Requirement
Gathering & Analysis SpecificatS
ioonfstware
Requirement
System Design Specifications
Design
Software Document
design Source Code
Coding & Scripts

SW integration Test cases &

& verification test results

System
Verification
Source Code
& Scripts
Operation &
Maintenance
MODULE 1 13
2
Advantages of Waterfall model
1. This model is simple to implement also the number of resources that are required for it is
minimal.
2. The requirements are simple and explicitly declared; they remain unchanged during the entire
project development.
3. The start and end points for each phase is fixed, which makes it easy to cover progress.
4. The release date for the complete product, as well as its final cost, can be determined before
development.
It gives easy to control and clarity for the customer due to a strict reporting system.
Disadvantages of Waterfall model
1. In this model, the risk factor is higher, so this model is not suitable for more significant and
complex projects.
2. This model cannot accept the changes in requirements during development.
3. It becomes tough to go back to the phase. For example, if the application has now shifted to
the coding phase, and there is a change in requirement, It becomes tough to go back and change
it.
4. Since the testing done at a later stage, it does not allow identifying the challenges and risks in
the earlier phase, so the risk reduction strategy is difficult to prepare.

2
23
Step 1: Feasibility Study

24
25
Step 2: Requirement Analysis and Specification

26
Step 3: Design

27
Step 4: Coding and Unit Testing

28
Step 5: Integration and System testing

29
30
Step 6: Maintenance

31
32
33
 Sequential Model: V model
V-Model also referred to as the Verification and Validation Model. In this, each phase of
SDLC must complete before the next phase starts. It follows a sequential design process
same as the waterfall model. Testing of the device is planned in parallel with a corresponding
stage of development.

3
 Sequential Model: V model
V-Model also referred to as the Verification and Validation Model. In this, each phase of
SDLC must complete before the next phase starts. It follows a sequential design process
same as the waterfall model. Testing of the device is planned in parallel with a corresponding
stage of development.
1. Verification
Definition: Verification is the process of checking whether the software conforms to the
specified requirements and design. It answers the question: "Are we building the product
right?"
Objective: To ensure that the system is being developed according to the requirements and
design specifications, and that no errors have been introduced during development.
2. Validation
Definition: Validation is the process of ensuring that the software meets the user's needs and
requirements, and that it does what it is supposed to do in the real world. It answers the
question: "Are we building the right product?"
Objective: To ensure that the product works as intended and satisfies the business and user
requirements.
3
 Incremental Model
1. The incremental model combines elements of linear and parallel process flows,
incremental model applies linear sequences in a staggered fashion as calendar time
progresses.
2. When an incremental model is used, the first increment is often a core product. That
is, basic requirements are addressed but many supplementary features (some
known, others unknown) remain undelivered.
3. The incremental process model focuses on the delivery of an operational product
with each increment. Early increments are stripped-down versions of the final
product, but they do provide capability that serves the user and also provide a
platform for evaluation by the user.
4. Each linear sequence produces deliverable “increments” of the software.
5. For example, word-processing software developed using the incremental paradigm
might deliver basic file management, editing, and document production functions in
the first increment;
6. more sophisticated editing and document production capabilities in the second
increment;
7. spelling and grammar checking in the third increment;
8. and advanced page layout capability in the fourth increment. 3
3
 Evolutionary Process Models
•Software Evolution:
•Complex systems evolve over time.
•Requirements change during development.
•Linear development paths are often unrealistic.
•Why Use Evolutionary Models?
•Meet tight market deadlines with early versions.
•Accommodate changing requirements.
•Deliver increasingly complete versions iteratively.
•Key Features:
•Iterative Development: Refinement in cycles.
•Incremental Philosophy: Deliver core product first; extend features in increments.
•Aligned with agile methodologies.
•Process Flow:
•Increment #1: Core features delivered.
•Increment #2: Refinements and new features.
•Increment #n: Final, complete product.

3
39
 Difference between Evolutionary and Incremental model
Evolutionary Model:The system evolves over time through iterative refinement. Each
iteration produces a better version of the system by incorporating feedback and
adapting to changing requirements.
.Incremental Model:The system is developed in predefined increments, with each
increment adding a specific, fully functional set of features until the complete system is
delivered.Example: Delivering a banking system in stages, such as account creation,
funds transfer, and loan processing.

4
Evolutionary model: Prototyping model

41
Subcategories of Prototyping Model:
Throwaway Prototyping: The prototype is discarded after requirements are
finalized, and the actual system is built from scratch.
Evolutionary Prototyping: The prototype is gradually improved and eventually
becomes the final system.

4
Advantages of Prototyping Model
1. The customers get to see the partial product early in the life cycle. 2. New requirements can be
easily accommodated as there is scope for refinement.
3. Missing functionalities can be easily figured out.
4. Errors can be detected much earlier thereby saving a lot of effort and cost, besides enhancing
the quality of the software.
5. Early feedback from customers and stakeholders can help guide the development process and
ensure that the final product meets their needs and expectations.
Disadvantages of the Prototyping Model
1. Costly concerning time as well as money.
2. There may be too much variation in requirements each time the prototype is evaluated by the
customer.
3. Poor Documentation due to continuously changing customer requirements.
4. There is uncertainty in determining the number of iterations that would be required before the
prototype is finally accepted by the customer.
5. After seeing an early prototype, the customers sometimes demand the actual product to be
delivered soon.
6. Developers in a hurry to build prototypes may end up with sub-optimal solutions.
4
Evolutionary model:Spiral Model

MODULE 1 32
4
• Why Spiral Model is called Meta Model?

• The Spiral model is called a Meta-Model because it subsumes

all the other SDLC models.
• For example, a single loop spiral actually represents the
Iterative Waterfall Model. The spiral model incorporates the
stepwise approach of the Classical Waterfall Model.
• The spiral model uses the approach of the Prototyping Model
by building a prototype at the start of each phase as a risk-
handling technique.
• Also, the spiral model can be considered as supporting the
Evolutionary model – the iterations along the spiral can be
considered as evolutionary levels through which the complete
system is built.
45
• Advantages of Spiral Model:
• Below are some advantages of the Spiral Model.
• Risk Handling: The projects with many unknown risks that occur as the development proceeds,
in that case, Spiral Model is the best development model to follow due to the risk analysis and
risk handling at every phase.
• Good for large projects: It is recommended to use the Spiral Model in large and complex
projects.
• Flexibility in Requirements: Change requests in the Requirements at later phase can be
incorporated accurately by using this model.
• Customer Satisfaction: Customer can see the development of the product at the early phase of
the software development and thus, they habituated with the system by using it before completion
of the total product.
• Iterative and Incremental Approach: The Spiral Model provides an iterative and incremental
approach to software development, allowing for flexibility and adaptability in response to changing
requirements or unexpected events.
• Emphasis on Risk Management: The Spiral Model places a strong emphasis on risk
management, which helps to minimize the impact of uncertainty and risk on the software
development process.
• Improved Communication: The Spiral Model provides for regular evaluations and reviews,
which can improve communication between the customer and the development team.
• Improved Quality: The Spiral Model allows for multiple iterations of the software development
process, which can result in improved software quality and reliability

46
 Concurrent Models
1. The Concurrent Development Model, often referred to as Concurrent Engineering, is
a software development model where multiple activities (phases of development)
occur simultaneously, instead of following a strictly sequential flow like the Waterfall
Model.
What Is the Concurrent Model?
1. Unlike traditional models, where one phase is completed before moving to the next,
the Concurrent Model allows different phases of the software development process to
happen concurrently.
2. Activities such as requirements gathering, design, coding, and testing are not strictly
linear; instead, they can overlap or interact with each other.
3. It provides a more flexible framework where the team can revisit or refine earlier
stages without waiting for others to finish.

4
Key Features of the Concurrent Model
Concurrent Activities:
All phases (e.g., communication, modeling, construction, deployment) can exist in different states at the same
time.
For example:
Requirements gathering might be "in progress."
Design could be "under review."
Coding could already be "in progress."
Iterative Nature:
Activities can be revisited iteratively if needed.
For instance, if new requirements are identified during testing, the requirements phase can be reactivated.
State-Based Approach:
Each activity can exist in one of several states such as:
Inactive: The activity hasn’t started yet.
Active: The activity is currently being worked on.
Under Review: The activity is being evaluated.
Completed: The activity is finalized.
Risk Management:
Like the Spiral Model, it focuses on identifying and resolving risks as early as possible by running multiple
processes concurrently.

4
Advantages of the Concurrent Model
Flexibility:
Activities can overlap, making it easier to adapt to changing requirements.
Parallel Development:
Different teams can work on various parts of the project simultaneously.
Improved Feedback:
Earlier testing and feedback ensure quicker identification of issues.
Time-Saving:
Since multiple activities happen concurrently, development time is reduced.

Disadvantages of the Concurrent Model

Complexity:
Managing overlapping activities can be complicated and requires clear communication.
Higher Resource Needs:
Requires a team skilled in multitasking and handling dependencies.
Difficult to Track Progress:
Because activities are happening simultaneously, monitoring and tracking the state of each activity can be
challenging.

4
50
51
52
 Agile
• Effective (rapid and adaptive) response to change (team members, new technology, requirements)
• Effective communication in structure and attitudes among all team members, technological and
business people, software engineers and managers
• Involving the customer into the team, Business people and developers must work together daily
throughout the project.
• Working as a team, Regularly reflect on team performance and adjust behavior to become more
effective.
• Planning in an uncertain world has its limits and plan must be flexible
• Organizing a team so that it is in control of the work performed
• Eliminate all but the most essential work products and keep them lean
• Emphasize an incremental delivery strategy as opposed to intermediate products that gets
working software to the customer as rapidly as feasible.
• Rapid, incremental delivery of software

MODULE 1 38
5
Agile : Extreme Programming model

39
5
 Extreme Programming (XP)
Test Driven Development
Recommends the construction of test cases before coding commences. So implementer can focus on what must be
implemented to pass the test
Pair Programming
Encourages “pair programming”. Two people work together at one workstation. Real time problem solving, real time review
for quality assurance. Take slightly different roles
Incremental Development
Come up with increments every few days to avoid drawbacks of waterfall model
Simplicity is good
Create simplest design that will support only the current required functionality(less bugs, easy to maintain and test)
Refactoring
Refactoring is an activity to improve a code or component’s internal structure or operation without changing its external
behavior. The goal of software development is the continuous delivery of business value to users and stakeholders.
Constantly changing technology and evolving business objectives, Example: Changing variable names to more
descriptive ones, breaking down a long function into smaller functions, or removing duplicate code.
Metaphor
It provides a simple, concrete idea or image used to help understand complex or abstract concepts and guide the
development process, you might refer to a "shopping cart" metaphor for an e-commerce application.
Continuous Integration
5
Don’t integrate after fully development
 4 values of XP
• Communication: Enhance communication among team members and with
the customers
• Simplicity: build something that will work today, may not work tomorrow
• Feedback: Take continuous feedback of customers. Make customer part
of the team
• Courage: If code structure has become bad don’t hesitate to discard it
and rewrite new code

MODULE 1 41
5
57
Agile : Scrum model

58
59
Ceremonies/Meetings in Scrum:
Sprint Planning:
A meeting at the start of the sprint to decide what tasks the team will work on during the sprint.
Daily Scrum/Stand-up:
A short (15-minute) meeting where team members discuss:
What they did yesterday.
What they plan to do today.
Any obstacles they’re facing.
Sprint Review:
Held at the end of the sprint to demonstrate the completed work to stakeholders and gather feedback.

6
Scrum

MODULE 1 44
6
62
63
64
65
66
Agile:Adaptive Software Development (ASD)
Focusing on human collaboration and team self-organization as a
technique to build complex software and system
Distinguishing features
• Mission-driven planning
• Component-based focus
• Uses “time-boxing” focus of Project Management Concepts
• Explicit consideration of risks
• Emphasizes collaboration for requirements gathering
• Emphasizes “learning” throughout the process

MODULE 1 67
 Three Phases of ASD
1. Speculation: project is initiated and adaptive cycle planning is
conducted
•Adaptive cycle planning uses project initiation information- the
customer’s mission statement, project constraints (e.g. delivery
date), and basic requirements to define the set of release cycles
(increments) that will be required for the project.
•Based on the information obtained at the completion of the first
cycle, the plan is reviewed and adjusted so that planned work
better fits the reality.

MODULE 1 68
 Three Phases of ASD
2. Collaborations are used to multiply their talent and creative output
beyond absolute number (1+1>2).
It encompasses communication and teamwork, but it also emphasizes
individualism, because individual creativity plays an important role in
collaborative thinking
Activities:Continuous interaction between team members and
stakeholders.
Use cross-functional teams to integrate diverse skills.
Encourage open communication and shared ownership of the product.

MODULE 1 69
 Three Phases of ASD
3. Learning: As members of ASD team begin to develop the components, the
emphasis is on “learning”.
• Activities:Regularly reflect on progress and outcomes.
•Conduct reviews and retrospectives after each iteration or release.
•Incorporate feedback from customers, stakeholders, and team members.
•Update the plan and strategies based on what has been learned.
•Three ways to improve learning: focus groups, technical reviews and
project post-mortems

MODULE 1 70
Three Phases of ASD

MODULE 1 71
 Agile:Dynamic Systems Development Method (DSDM)
Provides a framework for building and maintaining systems which meet tight time constraints
through the use of incremental prototyping in a controlled project environment
Supports Rapid application development and Iterative Principal
Works on Pareto Principal 80 % of An application is often delivered in twenty percent of the time
• Similar in most respects to XP and/or ASD
• Guiding principles
1. Active user involvement is imperative.
2. DSDM teams must be empowered to make decisions
3. The focus is on frequent delivery of products
4. Deliverables must meet the business's needs and help achieve its goals to be considered
acceptable
5. Iterative and incremental development is necessary to converge on an accurate business solution
6. All changes during development are reversible
MODULE 1 72
7. Testing is integrated throughout the life-cycle
57
7
 Agile:Kanban model
• Kanban is a framework that falls under the Agile methodology.
• Agile Kanban Framework focuses on visualizing the entire project on boards in
order to increase project transparency and collaboration between team
members.
How does Kanban work?
Kanban method revolves around the kanban board. It is a tool that visualizes the
entire project to track the flow of their project. Through this graphical approach of
Kanban boards, a new member or an external entity can understand what’s
happening right now, tasks completed and future tasks.
Kanban board indicates
the current tasks that are being performed
the tasks to do in the future
the tasks that are completed

MODULE 1 74
• Kanban is a pull system
• Kanban is about work states unlike Scrum or Agile which focus on sprints and iterations.
• Kanban focuses on breaking down work into small tasks, visualizing them, and getting few
items in any given work state.
• In the Kanban board, work always moves from left to right. And, you pick work from the
column to your left when you have completed all your existing work items or when an urgent
task surfaces.
• The work-in-progress limits(Each column (workflow stage) has a limit on the number of
tasks that can be worked on simultaneously) help you enforce this.

7
Process and Project Metrics
• Enables software people to gain insights into efficiency of the
software process and project.
• Basic data are collected and analyzed compared against past
assessed data to determine whether quality and productivity
improvement has occurred.
• Metrics are also used to pinpoint problem areas, so remedies
can be developed and software process can be improved.
• Who does it?
• Software metrics are analyzed and assessed by Software
Managers
• Measures are collected by Software Engineers

72
7
Measure, Measurement, Metrics & Indicators
When a single data point has been collected (e.g., the number of errors
uncovered in the review of a single module), a measure has been established.
Measurement occurs as the result of the collection of one or more data points
(e.g., a number of module reviews are investigated to collect measures of the
number of errors for each).
A software metric relates the individual measures in some way (e.g., the
average number of errors found per review).
A software engineer collects measures and develops metrics so that indicators
will be obtained.
An indicator is a metric or combination of metrics that provide insight into the
software process, a software project, or the product itself . An indicator
provides insight that enables the project manager or software engineers to
adjust the process, the project, or the process to make things better.

MODULE 1 73
7
METRICS IN THE PROCESS AND
PROJECT DOMAINS
• Process indicators enable a software engineering organization to gain
insight into the efficiency of an existing process (i.e., the
paradigm, software engineering tasks, work products, and
milestones).
• They enable managers and practitioners to assess what works and what
doesn’t. Process metrics are collected across all projects and over long
periods of time.
• Their intent is to provide indicators that lead to long-term software
process improvement.
• Project indicators enable a software project manager to (1) assess the
status of an ongoing project, (2) track potential risks, (3) uncover
problem areas before they go―critical, (4) adjust work flow or tasks, and
(5) evaluate the project team’s ability to control quality of software work
products.

74
7
 Software Process Metrics
• Software process metrics can provide significant benefit as an organization works to improve
its overall level of process maturity.
• The process sits at the center of the triangle connecting three factors that have a profound
influence on software quality and organizational performance
• The skill and motivation of people is the most influence factor for software quality
• The complexity of the product can have impact on quality and team performance
• The technology that process uses also has an impact, the process triangle exists within a
environmental circle and customer charactristics that can have impact.

MODULE 1 75
7
• We measure the efficiency of a software process indirectly.
That is, we derive a set of metrics based on the outcomes that
can be derived from the process.
• Outcomes include measures of errors uncovered before
release of the software, defects delivered to and reported by
end-users, work products delivered (productivity), human
effort expended, calendar time expended, schedule
conformance, and other measures.
• We also derive process metrics by measuring the
characteristics of specific software engineering tasks.
• For example, we might measure the effort and time spent
performing the umbrella activities and the generic software
engineering activities described
80
 SSPI
Statistical software process improvement (SSPI):
• the collection and use of process metrics, the derivation of simple indicators gives way to a
more rigorous approach.
• SSPI uses software failure analysis to collect information about all errors and defects
encountered as an application, system, or product is developed and used.

Failure analysis works in the following manner:

1. All errors and defects are categorized by origin (e.g., flaw in specification, flaw in logic,
non-conformance to standards).
2. The cost to correct each error and defect is recorded.
3. The number of errors and defects in each category is counted and ranked in descending
order.
4. The overall cost of errors and defects in each category is computed.
5. Resultant data are analyzed to uncover the categories that result in highest cost to the
organization.
6. Plans are developed to modify the process with the intent of eliminating (or reducing the
frequency of) the class of errors and defects that is most costly.
MODULE 1 81
Failure Analysis

MODULE 1 82
• Following steps 1 and 2, a simple defect distribution can be
developed. eight causes of defects and their origin are shown.

83
 Software Project metrics
• Software project measures are tactical; project metrics and the indicators derived from
them are used by a project manager and a software team to adapt project workflow and
technical activities.
• The first application of project metrics on most software projects occurs during
estimation.
• Metrics collected from past projects are used as a basis from which effort and time
estimates are made for current software work.
• As a project proceeds, measures of effort and calendar time expended are compared to
original estimates (and the project schedule). The project manager uses these data to
monitor and control progress.
As the software evolves from specification into design, technical metrics are collected to
assess Specification defects design quality and to provide indicators that will influence the
approach taken to code generation and testing.
Used to :
1. minimize the development schedule by making the adjustments necessary to avoid
delays and mitigate potential problems and risks.
2. assess product quality on an ongoing basis and, when necessary, modify the technical
approach to improve quality. MODULE 1 81
8
 Software Measurement
• Direct measures of the software engineering process include cost
and effort applied.
• Direct measures of the product include lines of code (LOC)
produced, execution speed, memory size, and defects reported over
some set period of time.

• Indirect measures of the product include functionality, quality,

complexity, efficiency, reliability, maintainability

MODULE 1 85
 Types of Software product Metrics
1. Size-Oriented Metrics
• metrics derived by normalizing quality and/or productivity measures by
considering the size of the software that has been produced
• a set of simple size-oriented metrics can be developed for each project:
• Errors per KLOC (thousand lines of code).
• Defects per KLOC.
• $ per LOC.
• Page of documentation per KLOC.
In addition, other interesting metrics can be computed:
• Errors per person-month.
• LOC per person-month.
• $ per page of documentation.

MODULE 1 86
 Product Metrics
2. Function-oriented Metrics
• software metrics use a measure of the functionality delivered by the
application
• Function points derived from direct measures of the information domain.
1. Number of user inputs. Each user input that provides distinct application oriented data to the
software
2. Number of user outputs. Each user output that provides application oriented information to the user
is counted. In this context output refers to reports, screens, error messages, etc.
3. Number of user inquiries. An inquiry is defined as an on-line input that results in the generation
of some immediate software response in the form of an on-line output.
4. Number of files. Each logical master file (i.e., a logical grouping of data that may be one part of a
large database or a separate file) is counted.
5. Number of external interfaces. All machine readable interfaces (e.g., data files on storage media)
that are used to transmit information to another system are counted.

MODULE 1 87
 Product Metrics
FP calculation

FP = Count total * ( 0.65 + 0.01 * ∑ Fi)

MODULE 1 88
 Software Measurement
The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the following questions
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
• Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5
(absolutely essential)

MODULE 1 89
 Software Measurement
Given the following values, compute function point when all complexity
adjustment factor (CAF) are average and weighting factors are
• User Input = 40 Simple
• User Output = 35 Complex
• User Inquiries = 30 Simple
• User Files = 8 Average
• External Interface = 6 Average

Count Total = 40* 3 + 35 * 7 + 30 * 3 + 8 *10 + 6 *7 = 577

Σ(Fi) = 14* 3 = 42 (total 14 Fi Each is average on scale of 1-5 hence
3)
FP = count total [0.65 + 0.01 Σ(Fi)]
FP = 577 * (0.65+ 0.42)
= 617.39
MODULE 1 90
1. Consider a software project with the following information domain characteristic
for the calculation of function point metric.

It is given that the complexity weighting factors for I, O, E, F, and N are 4, 5, 4, 10,
and 7, respectively. It is also given that, out of fourteen value adjustment factors
that influence the development effort, four factors are not applicable, each of the
other four factors has value 3, and each of the remaining factors has value 4. The
computed value of the function point metric is [GATE CS 2015]

9
 COCOMO
• Software are categorized into :
1.Organic:if the team size required is adequately small, the problem is well understood
and has been solved in the past and also the team members have a nominal experience
regarding the problem.
2.Embedded Projects: A software project with requiring the highest level of complexity,
creativity, and experience requirement fall under this category. Such software requires a
larger team size than the other two models and also the developers need to be sufficiently
experienced and creative to develop such complex models.
3. Semi-detached projects: if the vital characteristics such as team-size, experience,
knowledge of the various programming environment lie in between that of organic and
Embedded.
The projects classified as Semi-Detached are comparatively less familiar and difficult to
develop compared to the organic ones and require more experience and better
guidance and creativity. Eg: Compilers or different Embedded Systems can be
considered of Semi-Detached type.

MODULE 1 92
 COCOMO
Coefficients Related to Basic Model
Estimation at the early design stage where ONLY User Requirements are
defined
Effort= a* (KLOC)b
Project Duration = c* (Effort)d (represented in Months)
Person Required = Effort /Project Duration

Development Model a b c d
Organic 2.4 1.05 2.5 0.38
Embedded 3.6 1.20 2.5 0.32
Semi detached 3.0 1.12 2.5 0.35
MODULE 1 93
• Suppose a project manager has used FP analysis to estimate
lines of source code required to develop a project and finds
that the code size is 10,000. Estimate duration of the project
and number of persons required.
• Assume the project is classified as Embedded Project.
• b) Assume the project is classified as Organic Project.

94
Cocomo II
 COCOMO II
• COCOMO II is actually a hierarchy of estimation
models that address the following areas:
• Application composition model: Used during the
early stages of software engineering, when
prototyping of user interfaces, consideration of
software and system interaction, assessment of
performance, and evaluation of technology
maturity are paramount.
• Early design stage model: Used once
requirements have been stabilized and basic
software architecture has been established.
• Post-architecture-stage model: Used during the
construction of the software.
• Like all estimation models for software, the
COCOMO II models require sizing
information.
• Three different sizing options are available as
part of the model hierarchy: object points,
function points, and lines of source code.
• The COCOMO II application composition
model uses object points.
• the object point is an indirect software measure
• that is computed using counts of the number of
• (1) screens (at the user interface),
• (2)reports, and
• (3) components likely to be required to build the application.
• Each object instance (e.g., a screen or report) is classified into one
of three complexity levels (i.e., simple, medium, or difficult) using
criteria suggested by Boehm [BOE96].
• In essence, complexity is a function of the number and source of
the client and server data tables that are required to generate the
screen or report and the number of views or sections presented
as part of the screen or report.
• Once complexity is determined, the number of screens, reports,
and components are weighted according to Table.
• The object point count is then determined by multiplying the
original number of object instances by the weighting factor in
Table and summing to obtain a total object point count.
Object Point Analysis - Screens
Object Point Analysis - Reports
Object Point Analysis – Complexity
Weighting
Object Point Analysis – Productivity
Rate
• Object Points = object instances 1 x weighting
factor 1 + object instances 2 x weighting
factor 2 + object instances 3 x weighting
factor 3
• NOP = (object points) x [(100 - %reuse)/100]
• Where, NOP is defined as new object points.
• To derive an estimate of effort based on the
computed NOP value, a “productivity rate”
must be derived.
• estimated effort = NOP/PROD
Questions
Solution:
107
 Intermediate COCOMO
Intermediate COCOMO (Constructive Cost Model) is a
software cost estimation model developed by Barry Boehm
that provides a more accurate effort, time, and cost estimate
compared to the Basic COCOMO model.
It considers not only the size of the software (measured in
KLOC - Kilo Lines of Code) but also various cost drivers
such as product complexity, team experience, and software
reliability.
Effort= a*EAF* (KLOC)b
Project Duration = c* (Effort)d

MODULE 1 10
 Intermediate COCOMO
EAF = Early Adjustment Cost Factors:

MODULE 1 10
A Software company of semi-detached has recently received an order from a
manufacturing company to develop a code using C programming language. The
size of the code is estimated to be 3100 LOC. The reliability of the product is very
high and complexity of the product is nominal. The company has a set of
developers who have high application experience and low experience in c
programming language and low application experience and very high experience in
C programming language . The project manager has a choice of hiring from 2 set of
developers