6KS03: Software Engineering

Unit 2: Project Management: Process, Metrics, Estimations & Risk Hours:6

Measures, Metrics & Indicators: Metrics in process & project domains
Software measurement: Size oriented, function oriented Metrics, Metrics for software quality,
Defect Removal Efficiency, Metrics for Small Organization.
Software Projects P lanning: S/w Scope, project resources, Importance of SPP
Software Project estimation & decomposition techniques: Software sizing, LOC based
estimation, process-based estimation, and empirical estimation. Automated Tools
Software Risks: Risk Analysis and Management, s/w risk identification, risk components
and drivers. Risk projection, Risk Mitigation, Monitoring and Management & RMMM plan,
Risk refinement.

=======================================================================

Unit 2: Question Bank

Q.1. Define Measure, measurement and metrics. What are process and project metrics?
Q.2. Explain the size oriented metrics. Give an example.
Q.3. Explain the size oriented FP Metrics. Give an example.
OR
Explain function oriented metrics and how function point is calculated? Give example?
Q.4. Explain the function point based estimation technique give an example.
Q.5. Explain how DRE for a software product and project is calculated? Give an example?
Q.6. What are the activities involved in software project planning? Explain each in detailed?
Q.7. State and explain the measures of Software Quality.
Q.8. List the different metrics for software measurement and explain any one of them.
Q.9. What are various software risks? Explain it in brief.
Q.10. Explain Risk information sheet (RIS) with an example.
Q.11. How do you measure software resources?
Q.12. Explain in detail risk refinement.
Q.13. Why RMMM plan is necessary? Explain RMMM plan in details.
====================================================================

1|Page
 Introduction:
Software Measurement and Metrics:
Difference between Measurement and Metric in Software Engineering
Feature Measurement Metric
Definition The process of assigning numbers to A quantitative value derived from one or more
software attributes in a systematic way. measurements to assess software quality/ performance.
Purpose To collect raw data about software To evaluate software processes, products, or projects
attributes. using collected measurements.
Nature Basic data points without interpretation. Derived values from data that provide meaningful
insights.
Example Number of lines of code (LOC), Defect density (defects per KLOC),
Number of defects found. Productivity (LOC per developer per month).

Software Measurement
Software measurement is the process of quantifying different attributes of software to evaluate
its quality, performance, and efficiency. It helps in decision-making, process improvement, and
ensuring software reliability.

1. Measure: A measure is a quantitative indication of the size, dimension, capacity, or quantity of

product or process attributes. In the context of software engineering, measures could include
things like lines of code, development time, defect count, etc.
2. Measurement: Measurement is the process of assigning numbers to the attributes of entities in
real world to represent quantity. Ex. No. of errors occurs before implementation, No. of LOC for
module, No. of personals involved in Analysis Process.
3. Metrics: It is a quantitative measure of the degree to which a system, component, or process
possesses a given attribute.
Metrics are often used to make informed decisions, monitor progress, and improve processes.
Metrics are the specific measures used to evaluate and assess the performance or effectiveness of
a process, system, or project.
Now, let's discuss process and project metrics:

Software Measurement: A measurement is an expression of size, quantity, amount or

dimension of a particular attribute of a product or process. Software measurement is an
attribute indicator of a software product or process. The software measurement process is
defined and governed by ISO Standard.

Need of Software Measurement:

Software is measured to:
1. Enhance quality of a product/ process.
2. Control budget, schedule and overall cost of project

2|Page
Types of Software Measurement

1. Process Measurement – Measures effectiveness of software development process

(e.g., defect density, productivity).
2. Product Measurement – Measures attributes of software itself
(e.g., lines of code, Cyclomatic complexity).
3. Project Measurement – Measures the progress and management aspects of software
project (e.g., schedule variance, cost variance).

Examples of Software Measurement

1. Lines of Code (LOC) – The total number of lines in source code.

2. Cyclomatic Complexity – Measures complexity of a program’s control flow.
3. Defect Density – Number of defects per thousand lines of code (KLOC).
4. Function Points (FP) – Measures the functionality provided to the user based on inputs,
outputs, and interactions.
5. Code Coverage – Percentage of code covered by test cases.
6. Mean Time to Failure (MTTF) – Average time between software failures.
7. Customer Satisfaction Score (CSAT) – Measures user satisfaction with the software.

Software measurement is essential for improving quality, reducing risks, and ensuring successful
project delivery.

Key Differences between Process and Project Metrics

Feature Process Metrics Project Metrics
Focus Software development process efficiency Project planning, cost, schedule, and resource
tracking
Purpose Reduce defects and improve software Ensure timely and cost-effective project completion
quality
Example Defect density, test coverage, cycle time Effort variance, schedule variance, team
productivity

3|Page
Q.1. Define Measure, measurement and metrics. What are process and project metrics?

Certainly! Let's start by defining some key terms:

The goal of software measurement is valuable applications in schedule and budget planning, cost
estimation, quality assurance, testing, software debugging, software performance optimization,
and optimal personnel task assignments.

Software metric is a measure of software characteristics that are countable.

Why Software metrics?

They are important to project manager for many reasons:
1. Track potential risks
2. Determine quality of current product, process and improve
3. Review problem before it become critical
4. Adjust work flow and tasks
5. Evaluate project team’s ability to control quality of work product
6. Project tracking and controlling
7. Measuring work performance and productivity
8. Software metrics are related to four functions of management: Planning, Organization,
Control, and Improvement.

Process and Project Metrics in Software Engineering

1. Process Metrics

Definition:
Process metrics measure effectiveness and efficiency of software development process. These
help organizations improve software quality and streamline development workflows.

Examples of Process Metrics:

1. Defect Density – Number of defects per KLOC (thousand lines of code).

2. Cycle Time – Time taken to complete one development cycle (e.g., from coding to
deployment).
3. Code Review Efficiency – Number of defects found per code review session.
4. Test Coverage – Percentage of code covered by test cases.
5. Rework Percentage – Amount of effort spent on rework due to defects.

✅ Use of process metrics: Process metrics help in improving software quality, reducing
defects, and increasing efficiency.

4|Page
2. Project Metrics

Definition:
Project metrics focus on management and progress of software project. These metrics help track
project performance, schedule, cost, and resource utilization.

Examples of Project Metrics:

1. Effort Variance (EV) – Difference between estimated and actual effort spent.
2. Schedule Variance (SV) – Difference between planned and actual project completion
time.

3. Cost Performance Index (CPI) – Measures cost efficiency using the ratio of earned
value to actual cost.

4. Defect Leakage – Percentage of defects found after software release compared to total
defects found during testing.
5. Team Productivity – Number of features or user stories completed per sprint (for agile
teams). Sprint = teams manage their work in short cycles called sprints, to run a short
distance as fast as you can (SCRUM, XP: framework)

✅ Use: Project metrics help in tracking project health, managing risks, and ensuring timely
delivery within budget.

===============================================================

5|Page
Q.2 Explain the size oriented metrics. Give an example.
Ans:
Size-Oriented Metrics in Software Engineering:
Based on size of software:
Size-oriented metrics are used to measure: Software Quality,
: Software Efficiency -
Software efficiency refers to how well a software system utilizes resources such as CPU time,
memory, disk space, and network bandwidth to perform its tasks. (Time efficiency, space
efficiency, energy/power efficiency, scalability efficiency-workload handling).
(e.g., Quick sort and Bubble sort),
: Software Productivity
(e.g., lines of code per developer per month),
These metrics are typically expressed in terms of physical attributes such as the number of lines
of code (LOC), function points, or modules.
Common Size-Oriented Metrics
1. Lines of Code (LOC) – Measures the total number of lines of source code, including or
excluding comments.
2. Number of Modules – Counts the number of distinct modules in the software.
3. Number of Functions/Procedures – Measures the total functions or procedures
implemented in the software.
4. Function Points (FP) – A higher-level metric that quantifies software functionality
based on inputs, outputs, and user interactions.
5. Number of Classes (for OOP) – Counts the number of classes in an object-oriented
system.
6. Defects per KLOC (thousand lines of code) – Measures the defect density in a software
system.
Example of Size-Oriented Metrics
Suppose a software development team writes an application with the following characteristics:
• Total Lines of Code (LOC): 10,000
• Number of Modules: 20
• Number of Functions: 200
• Defects found: 50
Using size-oriented metrics, we can calculate:

These metrics help evaluate productivity (e.g., lines of code per developer per month),
maintainability, and software quality.

6|Page
Here’s an example to illustrate size-oriented metrics in a software project:

Project: Online Library Management System

Metrics Calculation:

1. Lines of Code (LOC):

o User Interface: 2,500 LOC
o Database Management: 3,000 LOC
o Business Logic: 4,500 LOC
o Total LOC = 10,000 LOC
2. Function Points (FP):
o User Inputs: 30
o User Outputs: 20
o User Inquiries: 15
o Internal Files: 10
o External Interfaces: 5
o Function Point Calculation (approximate) = 250 FP
3. Number of Modules:
o 5 Modules (User Management, Book Catalog, Borrow/Return System, Admin
Panel, Reporting)
4. Number of Classes (for an OOP system):
o 50 Classes (e.g., User, Book, Loan, Admin, ReportGenerator)
5. Number of Files:
o 120 Source Code Files

Conclusion:

Size-oriented metrics help estimate effort, cost, and complexity of software. For instance:

• More LOC → Higher development & maintenance effort.

• Higher FP → More user functionalities.
• More Modules/Classes → Better modular design but possibly higher complexity.

OR

7|Page
Explain the size oriented metrics. Give an example.
Ans: Size-Oriented Metrics are: LOC-based and function point-based metrics
LOC based size oriented metrics-
It is derived by normalising quality and/or productivity measures by considering the size of the
software that has been produced. If a software organisation maintains simple records, a table of
size-oriented measures, such as shown in Table 1 below:

Table 1: Size Oriented Metrics

Project LOC Effort Cost in Pages of Errors Defects People
(Person/m) $ documentation recorded recorded worked
A 12200 24 160000 350 130 25 3
B 27300 62 450000 1200 320 85 5
C 20400 43 340000 400 265 60 6
: : : : : : : :

The table lists, each software development project that has been completed over the past period
and the corresponding measures for that project. Referring to table entry for project A, 12200
LOC were developed with 24 person-months of efforts at the cost of $ 160000. It should be
noted that effort and cost recorded in table represent all software engineering activities (CPMCD,
umbrella activities, analysis, design, code, and testing), not just coding. Further information for
project A indicates that 350 pages of documentation were developed, 130 errors were recorded
before the software was released, and 25 defects were encountered after release to the customer
within the first year of operation. Three people worked on the development of Project A.
In order to develop metrics that can be assimilated with similar metrics from other projects, lines
of code are chosen as a normalisation value. From the primary data contained in Table 1, 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 documentation per KLOC
In addition to, other interesting metrics can be computed:
Errors per person per month
LOC per person per month
$ per page of documentation
Size-oriented metrics are not universally accepted as the best way to measure the process of
software development. Most of the controversy revolves around the use of LOC as a key
measure. Proponents of the LOC measure claim that LOC is a core metric of all software
development projects that can be easily counted. On the other hand, opponents argue that
LOC measures are programming language-dependent. This is a direct type of measure and
does not consider the functionality of process or project. Size-oriented metrics are widely
used, but their validity and applicability are debated.

8|Page
Q.3. Explain the size oriented FP Metrics. Give an example.
OR
Explain the Function Point Metrics. Give an example.
Ans:
Size-oriented FP metrics in software engineering are measures that are based on the size of the
software product. The size of the software can be measured in various ways, such as lines of code,
function points, or object points.
Function-Oriented Metrics are used to measure the functionality of software based on user
requirements rather than its size (e.g., Lines of Code). These metrics measure the functions that
software performs from a user's perspective. One of the most widely used function-oriented
metrics is Function Point Analysis (FPA).
Example of Function Point Metrics:
Function Points (FP) is one of the most widely used size-oriented metrics. It is a standardized
measure of the functionality provided by a software application. Function Points take into
account the functionality provided to user, and they are independent of technology or
implementation details.
The key components considered in calculating Function Points include:
1. External Inputs (EI): These are unique user inputs that the software must process. Each
input type is counted.
2. External Outputs (EO): These are unique sets of processed data that are sent to the user or
another system. Each output type is counted.
3. External Inquiries (EQ): These are unique data inquiries from the user that result in data
retrieval. Each inquiry type is counted.
4. External Interface Files (EIF): These are files used by the software but maintained by other
applications. Each interface file is counted.
5. Internal Logical Files (ILF): These are logical files maintained within the software. Each
logical file is counted.
Table 1
Domain Characteristics No. Multiply WEIGHTING FACTOR COUNT
of domain characteristic Complexity
Simple Average High
No. of User/External I/P (EI) 5 X 3 4 6 20
No. of User/ External O/P (EO) 3 X 4 5 7 12
No. of User/ External Inquires (EQ) 4 X 3 4 6 24
No. of Internal Logical Files (ILF) 2 X 7 10 15 20
No. of External Interfaces (EIF) 1 X 5 7 10 5
Count Total 81

= 81*[0.65+ (0.01* 14* Scale (0 ton5))]. Here Scale is Average =3

= 81*[0.65+(0.01* 14*3)]
= 81*[1.07]
= 86.67

9|Page
The calculation of Function Points involves assigning complexity weights to each of these
components and then summing them up to get the total Function Points. Once the Function
Points are determined, they can be used for various purposes, such as estimating effort, planning
resources, and comparing the productivity of different projects.
The software complexity can be computed by answering the following 14 questions:
1. Does system need reliable backup and recovery?
2. Are data communications required?
3. Are there distribute processing functions?
4. Is performance of system critical?
5. Does system able to run in an existing, heavily, and largely utilized operational environment?
6. Does system require on-line data entry?
7. Does input transaction is required by on-line data entry to be built over multiple screens?
8. Are master files updated on-line?
9. Are inputs, outputs, files, or inquiries complex?
10. Is internal processing complex?
11. Is code reusable?
12. Are conversion and installation included in design?
13. Is system designed for multiple installations?
14. Is application designed to make change and provide effective ease of use?
Each of above questions is answered using a scale that ranges from o to 5 (not important or
applicable to absolutely essential). This scale is shown below:

In summary, Function Point metrics provide a way to quantify the size of a software product
based on its functional aspects, allowing for more accurate estimation and management of
software development projects.
Example 2:
• Step-1: As complexity adjustment factor is average (given in question), hence, Scale = 3.
F = 14 * 3 = 42 (Where Scale from: 0 to 5)
• Step-2: Complexity Adjustment Factor (CAF) of function = 0.65 + (0.01 * 42) = 1.07
• Step-3: As weighting factors of function are also average (given) hence ,
Unadjusted Function Point (Count Total) Refer table 1 above = (5*4) + (3*5) + (4*4) +
(2*10) + (1*7) = 20+15+16+20+7=78
• Step-4:

FP=78*1.07
=83.46

10 | P a g e
 OR

Explain function oriented metrics and how function point is calculated? Give example?
Ans:
Function-Oriented Metrics
Function-Oriented Metrics are used to measure the functionality of software based on user
requirements rather than its size (e.g., Lines of Code). These metrics measure the functions that
software performs from a user's perspective. One of the most widely used function-oriented
metrics is Function Point Analysis (FPA).

Software functionality is divided into five types:

Function Types:
• External Inputs (EI) – User inputs that update internal files (e.g., forms, commands).
• External Outputs (EO) – Processed outputs provided to users (e.g., reports, messages).
• External Inquiries (EQ) – Queries that retrieve data without updating it (e.g., search
function).
• Internal Logical Files (ILF) – Data maintained within the system (e.g., customer
database).
• External Interface Files (EIF) – Data used from other systems (e.g., external API data).

Function Point Calculation

Function Points measure the functionality delivered to the user, independent of technology or
programming language based on logical transactions and data flows rather than lines of code.

Step 1: Identify Function Types and Assign Weights

There are five types of functions classified as either Data Functions or Transactional
Functions:
1. Data Functions
o Internal Logical Files (ILF): Logical groups of data maintained within the
system.
o External Interface Files (EIF): Logical groups of data referenced but not
maintained by the system.
2. Transactional Functions
o External Inputs (EI): User inputs affecting internal data.
o External Outputs (EO): Processed results presented to users (e.g., reports).
o External Inquiries (EQ): User-initiated queries that retrieve data without
updating it.
Each function type is assigned a complexity rating (Low, Average, High) with corresponding
weights.
Function Type Low Average High
External Inputs (EI) 3 4 6
External Outputs (EO) 4 5 7
External Inquiries (EQ) 3 4 6
Internal Logical Files (ILF) 7 10 15
External Interface Files (EIF) 5 7 10

11 | P a g e
Step 2: Count Function Types
For example, assume a system has:
• 5 EI (External Inputs) (Average complexity)
• 3 EO (External Outputs) (High complexity)
• 4 EQ (External Inquiries) (Low complexity)
• 2 ILF (Internal Logical Files) (Average complexity)
• 3 EIF (External Interface Files) (Low complexity)
Step 3: Compute Unadjusted Function Points (UFP)
Multiply each count by its corresponding weight:
UFP=(5×4)+(3×7)+(4×3)+(2×10)+(3×5)
=20+21+12+20+15=88
Step 4: Apply Complexity Adjustment Factor (CAF)
CAF is determined using 14 General System Characteristics (GSC) (e.g., performance,
security, reusability). Each characteristic is rated from 0 to 5, and their sum gives the Degree of
Influence (DI).
CAF=0.65+(0.01×DI) Assume DI = 30,
CAF=0.65+(0.01×30)=0.95
Step 5: Calculate Adjusted Function Points (AFP)
AFP=UFP×CAF
=88×0.95=83.6
≈84 Function Points
Example Application
Suppose a payroll system is being developed. Instead of measuring its size using LOC, function
points can be used to estimate effort, cost, and complexity based on its inputs, outputs, and data
storage.
=====================================================================================

12 | P a g e
Q.4. Explain the function point based estimation technique give an example.
Ans:
Estimation is the judgement of values. It is used to determine how much money, efforts,
resources & time needed to build the software.
Function Point-based Estimation
Function-oriented metrics are used in software engineering to measure and evaluate software
based on its functionality and the services it provides to users. These metrics focus on the
functions and features of the software rather than its internal characteristics or code complexity.
One commonly used function-oriented metric is the Function Point (FP).
Function Point (FP) is a sizing metric that quantifies the functionality provided by a software
application. It is used to measure the size of a software project, which can be useful for
estimating effort, resources, and project duration. The Function Point analysis typically considers
five types of functions in a software application:
Function Point-Based Estimation Technique
The Function Point (FP) estimation technique is a method used to measure the size of a
software project based on its functionality rather than its physical attributes (e.g., lines of code).
It helps estimate effort, cost, and time required for software development.
Steps in Function Point Estimation:
1. Identify Function Types:
The system's functionalities are classified into five types:
o External Inputs (EI):
These are user inputs processed by the software. For example, entering data into a
form. Data input by the user (e.g., forms, login, registration).

o External Outputs (EO):

These are the results provided to the user. For instance, generating a report or
displaying information on the screen. Processed data output to the user (e.g., reports,
dashboards).

o External Inquiries (EQ):

These are interactive inputs and outputs. They involve a combination of input and
output, where the output is based on an inquiry from the user. Queries retrieving data
without modifications (e.g., search feature).

o Internal Logical Files (ILF):

These are data maintained by the software. For example a database that the software
uses. The Files are maintained and used within the system (e.g., database tables).

o External Interface Files (EIF):

These are files used by the software but maintained by external applications. For
instance, reading data from a file generated by another system. Files used for
reference from external systems (e.g., APIs, shared databases).

13 | P a g e
 2. Assign Weights to Each Function Type:
Each function type is assigned a weight based on complexity (Low, Medium, High):
Function Type Low Medium High
External Inputs (EI) 3 4 6
External Outputs (EO) 4 5 7
External Inquiries (EQ) 3 4 6
Internal Logical Files (ILF) 7 10 15
External Interface Files (EIF) 5 7 10
3. Calculate the Unadjusted Function Points (UFP)

4. Adjust for Complexity Factor: Value Adjustment Factor

Complexity is assessed based on 14 factors (e.g., performance, security, reusability),
each rated from 0 (No Impact) to 5 (Strong Influence).
• VAF formula:

5. Calculate the Final Function Points (FP):

6. Estimate Effort & Cost:

Using industry standards, effort estimation is done using:
Effort (Person-Months) = FP × Productivity Factor
Cost = Effort × Cost per Person-Month

Example: Function Point Estimation for an Online Banking System.

Step 1: Identify Functional Components

Function Type Count Complexity Weight Total
External Inputs (EI) 10 Medium 4 40
External Outputs (EO) 8 High 7 56
External Inquiries (EQ) 6 Low 3 18
Internal Logical Files (ILF) 5 Medium 10 50
External Interface Files (EIF) 4 Low 5 20
Total UFP 184

Step 2: Calculate Value Adjustment Factor (VAF)

Assume the total complexity score is 30, then:

Complexity is assessed based on 14 factors (e.g., performance, security, reusability),

each rated from 0 (No Impact) to 5 (Strong Influence).

14 | P a g e
Step 3: Compute Final Function Points
FP=UFP×VAF=184×0.95
=174.8
≈175

Step 4: Effort and Cost Estimation

• Assume productivity factor = 10 FP per Person-Month
Effort Required = 175 / 10 = 17.5 Person-Months
• Cost per Person-Month = $5,000
Total Cost = 17.5 × $5,000 = $87,500

Once function point has been calculated, they are used to normalize measure for software
productivity as:
Errors per FP
Defects per FP
$ per FP
Pages of documentation per FP
FP per person per month

After calculating the function point, various other measures can be calculated as shown below:
Productivity = FP / person-month
Quality = Number of faults / FP
Cost = $ / FP
Documentation = Pages of documentation / FP

The Function Point technique helps in effort estimation, cost prediction, and project
planning. It is useful for early-stage estimation and comparing projects without depending on
programming language or LOC.

=====================================================================

15 | P a g e
Q.5. Explain how DRE for a software product and project is calculated? Give an example?

Defect Removal Efficiency (DRE) is a metric used to measure the effectiveness of defect
detection and removal processes in software development. It indicates how well defects are
identified and fixed before the software is released.

Where:
• Defects Removed before Release = Bugs found during development, testing, and
internal quality assurance (QA).
• Total Defects = All defects, including those found before and after release.
• Post-release Defects = Bugs found by users after deployment.

Example: Calculating DRE for a Software Project

Scenario:
A company develops an e-commerce website and tracks defects across different stages.
1. Defects found and fixed before release = 450
2. Defects reported by customers after release = 50
3. Total defects = 450 (pre-release) + 50 (post-release) = 500

DRE Calculation:

Interpretation of DRE Values:

• Higher DRE (close to 100%) → Effective defect detection and removal before release.
• Lower DRE (below 85%) → Indicates gaps in testing, requiring process improvements.
• Ideal DRE Goal: Most high-quality projects aim for DRE > 95% to minimize post-
release defects.

How to Improve DRE?

• Enhanced Testing Strategies: Implement automated and exploratory testing.
• Code Reviews & Inspections: Detect issues early in development.
• Static Code Analysis: Use tools to identify defects before testing.
• Better QA Processes: Increase test coverage and conduct rigorous testing.
• Beta Testing: Gather early feedback from real users.

Conclusion

DRE is a critical metric to assess software quality and testing effectiveness. A higher DRE
reduces post-release defects, improving customer satisfaction and reducing maintenance costs.

16 | P a g e
 OR
Defect Removal Efficiency (DRE) is a metric used to measure the effectiveness of the testing
process in identifying and removing defects before the software is released. It provides insight
into how well the testing activities are performing in terms of finding and fixing issues during the
development life cycle. The formula for calculating DRE is:

Here's a breakdown of the components of the formula:

Let's go through an example:

Suppose a software project undergoes testing, and during this phase, 50 defects are identified.
After the software is released and in use, 10 additional defects are reported by users. The
calculation of DRE would be as follows:

In this example, the Defect Removal Efficiency is 80%, indicating that 80% of the defects were
identified and fixed during the testing phase, preventing them from reaching the post-release
stage. A higher DRE percentage suggests a more effective testing process in terms of identifying
and addressing defects before the software is deployed to users

Extra Example:
Suppose a software project undergoes testing, and during this phase, 40 defects are identified.
After the software is released and use, 15 additional defects are reported by users, Calculate DRE
and give your comments.

17 | P a g e
Q.6. What are the activities involved in software project planning? Explain each in detailed?
Answer:
Software project planning is a critical phase in the software development life cycle, where
project scope, objectives, resources, timelines, and risks are defined. It is the process of defining
objectives, scope, goals, milestones (short deliverables),
The activities involved in software project planning are: determination of software scope and
estimation of, how much money, how much effort, how many resources and how much time it
will take to build specific software system.

Major Activities in software project planning:

1. Estimation
2. Scheduling
3. Risk Analysis
4. Quality Management &
5. Change Management
The main activities involved in software project planning include:
1. Project Scope Definition
Clearly define the scope of the project, including the features and functionalities to be
delivered. It involves understanding user requirements, project objectives, and constraints. It
describes data and control to be processed, function, performance, constraints, interfaces, and
reliability.
Develop a detailed scope statement, outlining what is included and excluded from the project.
Identify project boundaries to set clear expectations.
• Define project objectives, deliverables, and boundaries.
• Identify stakeholders and their requirements.
• Establish functional and non-functional requirements.
✅ Example: In an e-commerce project, scope includes features like user authentication, product
search, payment gateway, and order management.

2. Feasibility Study:
Evaluate the technical, economic, legal, and operational feasibility of the project. Assess
whether the project is viable and if it aligns with organizational goals. Conduct a thorough
analysis, considering technical challenges, cost estimates, legal constraints, and the impact on
existing operations.

3. Resource Estimation and Allocation:

Estimate the resources required for the project, including personnel, equipment, software
tools, and facilities. Break down resource requirements by project phase. Consider the skills
and expertise needed for each task.
• Identify required team members, skills, and tools.
• Assign roles and responsibilities (Developers, Testers, Designers, Project Managers).
✅ Example:
Role Team Member Responsibility
Project Manager Alice Oversees project execution
Developer Bob Implements code
Tester Charlie Conducts testing

18 | P a g e
4. Time Estimation ( Scheduling):
• Develop a timeline for the project, specifying the start and end dates for each phase and
milestone. Use historical data, expert judgment, and estimation techniques (e.g., PERT,
Cocomo) to create realistic time estimates for tasks. Create a Work Breakdown Structure
to divide tasks.
• Use Gantt Charts and PERT/CPM techniques to define milestones and dependencies.
• Allocate start and end dates for each phase.
✅ Example:
Task Start Date End Date Duration
Requirement Gathering March 1 March 10 10 days
Design March 11 March 25 15 days
Development March 26 May 15 50 days

5. Effort Estimation
• Estimate the time, resources, and cost required for the project.
• Use estimation techniques like:
o Function Point Analysis (FPA)
o COCOMO Model
o Expert Judgment
o Use Case Points
✅ Example: If a system has 200 function points and the productivity is 10 FP per person-
month, then effort required = 200/10 = 20 person-months.

6. Risk Management:
• Identify potential risks (technical, financial, operational) that could impact the project's
success. Develop strategies to mitigate or manage these risks. Create a risk register,
categorize risks, assess their impact and likelihood, and outline risk response plans.
• Identify potential risks
• Develop mitigation strategies.
• Use a Risk Matrix to categorize risks by probability and impact.
✅ Example:
Risk Probability Impact Mitigation Strategy
Scope Creep High High Regular requirement reviews
Security Issues Medium High Conduct security testing
7. Quality Assurance Planning
• Define testing strategies (Unit Testing, Integration Testing, UAT).
• Plan for Code Reviews, Static Analysis, and Automation Testing.
✅ Example: A software project may require 100% unit test coverage and performance testing
for 10,000 concurrent users.
7. Communication & Collaboration Plan
• Establish meetings, reporting structures, and feedback mechanisms.
• Use collaboration tools like Slack, Jira, Trello.
✅ Example:
• Daily Stand-ups: 15-minute meetings for progress updates.
• Weekly Status Reports: Email updates on project status.

19 | P a g e
8. Cost Estimation & Budgeting
• Estimate total development, testing, deployment, and maintenance costs.
• Plan resource and tool investments.
✅ Example:
Category Estimated Cost
Developer Salaries $50,000
Testing Tools $5,000
Hosting & Infrastructure $10,000
Total Budget $65,000
9. Change Management Planning
• Define a process for handling scope changes.
• Use version control (Git), change request forms, and approval workflows.
✅ Example: If a client requests a new payment method, a change request is submitted,
reviewed, approved, and implemented.

10. Deployment & Maintenance Planning

• Plan for deployment strategies (phased rollout, big bang deployment).
• Define post-launch support and bug-fixing processes.
✅ Example: A SaaS product launches in beta mode before full deployment.

Conclusion
Effective software project planning ensures on-time delivery, within budget, and with high
quality. It covers scope, cost, scheduling, risk, and team collaboration, leading to successful
project execution.

=====================================================================

20 | P a g e
 Q.7. State and explain the measures of Software Quality.
Ans: Software quality is a multidimensional concept that encompasses various attributes and
characteristics. The measures of software quality are used to assess and quantify different aspects
of a software product. Here are some key measures of software quality:
1. Correctness: It is a degree to which the software meets its specified requirements without errors.
It measures: Number of defects, accuracy of calculations, adherence to specifications.
2. Reliability: Reliability is ability software to perform consistently and predictably under various
conditions.
It Measures: Mean Time between Failures (MTBF), failure rates, system stability.
3. Efficiency: It is an ability of software to perform its functions with minimum resource utilization
(Time, memory, processing power).
It Measures: Execution time, response time, resource consumption.
4. Integrity: It is accuracy and consistency of data and information within the software.
5. It Measures: Data integrity checks, error handling, and consistency in processing.
6. Usability: It means how easy to use the software to achieve their goals. It Measures: How easy
it is through User satisfaction surveys, task success rates
7. Maintainability: It is the ease with which software can be modified, enhanced, or fixed.
Measures: Mean Time to Repair (MTTR), code readability, modular design.
8. Portability: It is an ability of the software to be adapted for use in different environments and
platforms.
Measures: Platform compatibility, ease of migration, adaptability.
9. Scalability: An ability of software to handle an increasing amount of work or user load.
Measures: Response time under varying loads, resource utilization at different scales.
10. Testability: It is ease with which the software can be tested to ensure its correctness and
reliability.
Measures: Test coverage, ease of creating test cases, fault isolation.
11. Security: Security is the protection of the software and its data from unauthorized access,
attacks, and vulnerabilities.
Measures: Number of security vulnerabilities, penetration testing results, access control.
12. Adaptability: It is ability of software to evolve and adapt to changing requirements and
technologies.
Measures: Frequency of updates, ease of integrating new features, flexibility.
13. Interoperability:
It is ability of the software to interact and operate with other software, hardware, or systems.
Measures: Compatibility with standards, successful integration tests, seamless data exchange.
14. Conformance: It is the degree to which the software adheres to relevant industry standards and
regulations.
Measures: Compliance checks, adherence to coding standards, regulatory audits.
15. Robustness: It is an ability of software to handle unexpected inputs, errors, and adverse
conditions gracefully.
Measures: Response to unexpected inputs, error recovery, fault tolerance.
Measuring software quality involves a combination of quantitative metrics, qualitative
assessments, and adherence to industry best practices. The specific measures chosen may vary
based on the nature of the software, the development process, and the goals of the project. A
comprehensive evaluation of software quality considers multiple dimensions to ensure that the
software meets or exceeds user expectations and requirements.

21 | P a g e
 Q.8. List the different metrics for software measurement and explain any one of them.
Ans:
Software metrics are quantitative measures used to evaluate and assess various aspects of the
software development process and the resulting software product. There are different categories
of software metrics, each focusing on specific aspects. Here are some common categories and
examples of software metrics:
1. Size Metrics:
Examples: Lines of Code (LOC), Function Points (FP), Cyclomatic Complexity.
2. Effort Metrics:
Examples: Person-months, person-hours, cost per line of code.
3. Time Metrics:
Examples: Project duration, time to market, development cycle time.
4. Quality Metrics:
Examples: Defect density, failure rate, code churn.
5. Productivity Metrics:
Examples: Lines of code produced per hour, function points per person-month.
6. Complexity Metrics:
Examples: Cyclomatic Complexity, Halstead's Software Science metrics.
7. Maintainability Metrics:
Examples: Mean Time to Repair (MTTR), code readability, changeability index.
8. Reliability Metrics:
Examples: Mean Time between Failures (MTBF), failure rate, availability.
9. Testing Metrics: Examples, Test coverage, defect detection rate, test effectiveness.
10. Risk Metrics:
Examples: Risk exposure, risk severity, risk mitigation effectiveness.
Let's take one specific metric as an example, Cyclomatic Complexity:
• Definition: Cyclomatic Complexity is a measure of the structural complexity of a program. It is
calculated based on the number of linearly independent paths through a program's source code.
• Purpose: It provides insights into the program's complexity, helping identify areas that may be
more error-prone or difficult to understand.
• Calculation: The formula for Cyclomatic Complexity (V) is given by:
V=E−N+2P Where:
• E is the number of edges in the control flow graph.
• N is the number of nodes in the control flow graph.
• P is the number of connected components (usually 1 for a single program).
• Interpretation: A higher Cyclomatic Complexity value suggests a more complex program. It is
often used in conjunction with other metrics to assess maintainability and identify potential areas
for code refactoring.
For example, consider a program with 50 nodes, 60 edges, and a single connected component.
The Cyclomatic Complexity would be calculated as: V=60−50+2×1=12
A Cyclomatic Complexity of 12 indicates that there are 12 linearly independent paths through
the program. This information can be used by developers and project managers to assess and
manage the program's complexity, potentially leading to improvements in maintainability and
understandability.

22 | P a g e
 Q.9. What are various software risks? Explain it in brief.

Ans:
Software development projects are subject to various risks that can impact their success.
Identifying and managing these risks is crucial for delivering a high-quality product on time and
within budget. Here are various types of software risks:
1. Requirements Risks:
• Incomplete or unclear requirements: Ambiguous or incomplete specifications can lead to
misunderstandings and result in the delivery of a product that does not meet user
expectations.
2. Schedule Risks:
• Time constraints: Unrealistic project schedules or unexpected delays can lead to missed
deadlines and project overruns.
3. Technical Risks:
• Technology obsolescence: Using outdated or unsupported technologies can lead to
difficulties in maintenance and limit the scalability of the system.
• Integration issues: Difficulty in integrating different components or third-party systems
can result in functionality and performance problems.
4. Personnel Risks:
• Team skill gaps: Lack of expertise or skill gaps among team members can affect the
quality and efficiency of the development process.
• Turnover: Loss of key team members during the project can disrupt workflow and impact
project continuity.
5. Quality Risks:
• Defects and bugs: Poor code quality or insufficient testing can lead to the presence of
defects and bugs in the software.
• Insufficient testing: Inadequate testing coverage may result in undetected issues and
reduce the overall quality of the software.
6. Cost Risks:
• Budget overruns: Unexpected costs, scope changes, or inaccurate initial estimates can
lead to budget overruns.
7. External Risks:
• Market changes: Shifts in market conditions or user preferences can impact the relevance
and success of the software product.
• Regulatory changes: Changes in regulations or compliance requirements may necessitate
modifications to the software.
8. Security Risks:
• Vulnerabilities: Failure to address security vulnerabilities can lead to unauthorized
access, data breaches, and compromise the integrity of the software.
9. Legal Risks:
• Intellectual property issues: Violating intellectual property rights or licensing agreements
can result in legal consequences.
• Non-compliance: Failure to adhere to legal and regulatory requirements can lead to legal
actions and project delays.

10. Communication Risks:

23 | P a g e
 • Poor communication: Ineffective communication within the team or with stakeholders
can lead to misunderstandings, delays, and misalignment of expectations.
11. Scope Risks:
• Scope creep: Uncontrolled expansion of project scope without proper evaluation and
management can lead to increased costs and project delays.
12. Change Management Risks:
• Resistance to change: Stakeholders or team members may resist changes, affecting the
successful implementation of new features or processes.
Identifying, assessing, and mitigating these risks throughout the software development life cycle
is essential for successful project management and delivery. A comprehensive risk management
plan helps in anticipating and addressing potential issues, ensuring that the project can adapt to
changing conditions and deliver a successful software product.

=====================================================================

24 | P a g e
 Q.10. Explain Risk information sheet (RIS) with an example.

Ans:
A Risk Information Sheet (RIS) is a document used in risk management to provide detailed
information about a specific risk identified in a project. It helps in documenting, tracking, and
managing individual risks throughout the project lifecycle. The information captured in a Risk
Information Sheet includes details about the nature of the risk, its potential impact, likelihood,
mitigation strategies, and responsible parties. Here's an example of what a Risk Information
Sheet might look like:

Risk Information Sheet (RIS) Example:

1. Risk ID: R001

2. Risk Title: Incomplete Requirements
3. Description:
• The project requirements are not well-defined, and there is a possibility of missing
• critical details that may impact the development process.
4. Source:
• Unclear communication with stakeholders during the requirement gathering phase.

25 | P a g e
5. Potential Impact:
• High
• Delays in development due to frequent changes, increased rework, and potential for
delivering a product that does not meet user expectations.
6. Likelihood:
• Moderate
• Previous projects with similar stakeholders experienced some challenges in the
requirements phase.
7. Risk Owner:
• [Project Manager] - Jane Doe
8. Mitigation Strategies:
• Conduct regular and thorough meetings with stakeholders to clarify and document
requirements.
• Use prototyping or mock-ups to visualize requirements and gather early feedback.
9. Contingency Plans:
• Allocate extra time in the schedule to account for potential changes.
• Establish a change control process to manage requirement modifications.
10. Status:
• Open
• (The status may be updated to "Closed" when the risk is successfully mitigated or no
longer applicable.)
11. Monitoring and Review:
• Regularly review the status of requirements.
• Hold periodic meetings with stakeholders to ensure ongoing clarity and alignment.
12. Date Identified:
• [Date]
13. Date of Last Update:
• [Date]

This is a simplified example, and in a real-world scenario, the RIS might contain additional
fields such as risk triggers, risk response strategies, risk likelihood and impact assessment scales,
and more detailed information about the risk mitigation and contingency plans.

The purpose of the Risk Information Sheet is to provide a centralized and organized repository
for information related to identified risks. This facilitates effective communication, decision-
making, and monitoring of risks throughout the project, helping the project team and
stakeholders to stay informed and take proactive measures to address potential challenges.
----------------------------------------------------------------------------------------------------------------

26 | P a g e
 Q. 11. How do you measure software resources?
Measuring software resources involves quantifying the various elements that contribute to the
development, maintenance, and deployment of software. Here are some common ways to
measure software resources:
1. Lines of Code (LOC):
• Definition: LOC is a straightforward metric that counts the number of lines in a
program's source code.
• Purpose: It provides a basic measure of the size of the software, which can be used for
estimating effort, productivity, and maintenance requirements.
• Considerations: LOC can vary in terms of complexity, so it's not a perfect measure of
effort or functionality.
2. Function Points (FP):
• Definition: Function Points measure the functionality provided by a software application,
independent of the technology used or the implementation details.
• Purpose: FP offers a size-oriented metric that helps in estimating effort, cost, and
productivity. It focuses on user-visible functionality.
• Considerations: It considers both inputs and outputs of a software system, providing a
more comprehensive measure compared to LOC.
3. Use Case Points (UCP):
• Definition: Similar to Function Points, UCP quantifies the functionality of a system
based on use cases.
• Purpose: UCP provides a way to measure the functionality from the user's perspective,
aiding in effort estimation and project planning.
• Considerations: It considers the complexity of use cases and actors.
4. Object Points:
• Definition: Object Points measure the functionality based on the number and complexity
of user interface objects, processes, and data management.
• Purpose: It provides a size metric focusing on user interactions and data manipulation.
• Considerations: Object Points consider the complexity of different types of objects.
5. Hours per Function Point (HPFP):
• Definition: HPFP measures the average number of hours required to develop one
function point.
• Purpose: It helps in estimating the effort required for a project based on the size of the
software.
• Considerations: The actual HPFP can vary based on the development team's experience,
technology, and project complexity.
6. Effort-to-Size Ratio:
• Definition: Effort-to-Size Ratio is the ratio of effort (person-hours) to a size metric like
LOC or Function Points.
• Purpose: It provides a measure of productivity and can be used for benchmarking and
assessing the efficiency of development teams.
• Considerations: The interpretation of the ratio depends on the specific size metric used.
7. Defect Density:
• Definition: Defect Density measures the number of defects per unit of size (e.g., per
KLOC or per Function Point).

27 | P a g e
 • Purpose: It helps in assessing the quality of the software by identifying the density of
defects relative to its size.
• Considerations: A lower defect density is generally indicative of higher software
quality.
8. Test Coverage:
• Definition: Test Coverage measures the percentage of the software code or functionality
exercised by test cases.
• Purpose: It provides insights into the thoroughness of testing efforts and identifies areas
of the code that are not adequately covered.
• Considerations: Higher test coverage does not guarantee absence of defects, but it helps
in identifying areas for additional testing.
These metrics provide quantitative measures that can be used for project planning, monitoring,
and improvement efforts in the software development process. The choice of metrics depends on
the goals and context of the measurement activities

===================================================================

28 | P a g e
 Q.12. Explain in detail risk refinement.
Ans:
Risk refinement, also known as risk elaboration or risk analysis, is a process in risk management
that involves a detailed examination and further development of initially identified risks. It is an
iterative and ongoing activity that takes place throughout the project life cycle. The goal of risk
refinement is to enhance the understanding of each identified risk, assess its potential impact on
the project, and devise effective strategies for risk mitigation and management.
Here is a detailed explanation of the steps involved in risk refinement:
1. Identify Initial Risks:
• The risk refinement process begins with the identification of initial risks. This can be
done through various techniques such as brainstorming sessions, interviews, historical
data analysis, and expert judgment.
2. Document the Identified Risks:
• Each identified risk is documented in a risk register or a similar document. The
documentation includes details such as the risk description, its potential impact,
likelihood, risk owner, and any initial mitigation strategies.
3. Assess Impact and Likelihood:
• The next step is to assess the potential impact of each identified risk on the project
objectives and its likelihood of occurrence. This assessment helps in prioritizing risks
based on their severity.
4. Risk Categorization:
• Risks can be categorized based on various criteria such as their nature (technical,
schedule, budget, etc.) or their source (internal or external factors). Categorization helps
in organizing and managing risks more effectively.
5. Risk Modeling:
• Use techniques like risk modeling or simulation to analyze the complex
interdependencies between different risks. This step involves creating models that
simulate the potential outcomes of different risk scenarios.
6. Refinement of Risk Descriptions:
• Refine and elaborate on the descriptions of identified risks. Ensure that the descriptions
are clear, specific, and accurately reflect the nature of the risks.
7. Quantitative Analysis:
• If feasible, conduct quantitative risk analysis to assign numerical values to impact and
likelihood. This can involve using tools like Monte Carlo simulations to quantify the
potential effects of risks on project objectives.
8. Develop Risk Mitigation Strategies:
• Work on developing detailed and effective risk mitigation strategies for each identified
risk. These strategies should outline specific actions to reduce the probability of the risk
occurring or to minimize its impact.
9. Identify Secondary Risks:
• During the refinement process, new risks or secondary risks may be identified as a result
of the initial risk mitigation strategies. Document and assess these secondary risks to
ensure a comprehensive risk management approach.
10. Review and Update the Risk Register:
• Regularly review and update the risk register as new information becomes available or as
the project progresses. Ensure that the risk information is current and reflective of the
project's evolving context.

29 | P a g e
11. Communication and Documentation:
• Communicate the refined risk information to relevant stakeholders. Ensure that the risk
register and associated documentation are accessible and understood by the project team,
management, and other key stakeholders.
12. Monitor and Control:
• Continuously monitor and control identified risks throughout the project life cycle.
Implement risk response plans and track the effectiveness of mitigation strategies. Adjust
the risk management plan as needed.
Risk refinement is a dynamic and continuous process that contributes to the overall success of
the project by proactively addressing potential challenges and uncertainties. It involves a
thorough analysis of risks, their impacts, and the development of strategies to manage them
effectively.

====================================================================

30 | P a g e
 Q.13. Why RMMM plan is necessary? Explain RMMM plan in details.
Ans:

Several types of risks can impact a software product; a few of them are defined below:
1. Technology Risks: Risks arising from the software or hardware technologies utilised to
construct the system.
2. People Risks: Risks associated with an individual of the development team.
3. Organizational Risks: Risks arise due to the organization in which the software is being
produced.
4. Tools Risks: Risks arising from the software tools and other support software used to build
the system.
5. Requirement Risks: Risks associated with changes in client requirements and the process
of managing those changes.
6. Estimation Risks: Risks arising from management estimates of the resources necessary to
create the system.

The Risk Mitigation, Monitoring, and Management (RMMM) plan is a crucial component of the
overall risk management process in a project. It provides a structured approach for identifying,
assessing, and addressing risks throughout the project life cycle. The RMMM plan is necessary
for several reasons:
1. Proactive Risk Management:
• The RMMM plan enables a proactive approach to risk management. By identifying
potential risks and developing mitigation strategies in advance, the project team can
reduce the likelihood and impact of risks, contributing to overall project success.
2. Minimizing Negative Impacts:
• Risks, if not managed effectively, can have negative impacts on project objectives, such
as delays, cost overruns, and quality issues. The RMMM plan helps minimize these
negative impacts by outlining strategies to address and mitigate risks before they escalate.
3. Enhancing Project Control:
• A well-defined RMMM plan enhances project control by providing a framework for
monitoring and managing risks throughout the project life cycle. It allows project
managers to stay informed about the status of identified risks and take timely corrective
actions.
4. Improving Decision-Making:
• The RMMM plan provides project managers and stakeholders with valuable information
for decision-making. It helps prioritize risks, allocate resources effectively, and make
informed decisions on risk responses and contingency plans.
5. Communication and Stakeholder Confidence:
• Having a documented RMMM plan facilitates communication among team members,
stakeholders, and management. It instills confidence in stakeholders by demonstrating
that potential risks have been considered, and proactive measures are in place to address
them.
Now, let's delve into the key components of an RMMM plan:

31 | P a g e
 RMMM Plan Components:
1. Risk Identification:
• Clearly document the identified risks, including their descriptions, sources, and potential
impacts. Categorize risks based on their nature (technical, schedule, budget, etc.) for
better organization.
2. Risk Assessment:
• Assess the severity and likelihood of each identified risk. Use qualitative and, if possible,
quantitative methods to assign values to impact and probability.
3. Risk Mitigation Strategies:
• Define specific strategies and actions to mitigate or reduce the probability and impact of
identified risks. These strategies may include process changes, technology alternatives,
resource reallocation, or other proactive measures.
4. Contingency Plans:
• Develop contingency plans for high-priority risks that cannot be fully mitigated.
Contingency plans outline actions to be taken if a risk materializes, helping to minimize
the impact on project objectives.
5. Monitoring and Control Mechanisms:
• Specify how risks will be monitored throughout the project. Define key indicators,
thresholds, and triggers that will prompt a review and update of risk responses.
Implement regular risk reviews and reporting mechanisms.
6. Responsibilities and Roles:
• Clearly define the roles and responsibilities of team members involved in risk
management. Designate a risk owner for each identified risk to ensure accountability.
7. Communication Plan:
• Outline a communication plan for sharing risk-related information with team members,
stakeholders, and management. Define reporting frequencies, formats, and channels.
8. Documentation Updates:
• Specify when and how the RMMM plan and associated documentation will be updated.
Regularly review and revise the plan to reflect changes in the project environment.
9. Training and Awareness:
• Ensure that team members are trained and aware of the RMMM plan. Conduct training
sessions to enhance the team's understanding of risk management concepts and their role
in the process.
10. Budget and Resource Allocation:
• Allocate resources and budget for risk management activities. Consider the costs
associated with risk mitigation, monitoring, and contingency planning.
11. Evaluation and Feedback:
• Establish mechanisms for evaluating the effectiveness of risk mitigation strategies and
the overall RMMM plan. Collect feedback from team members and stakeholders for
continuous improvement.
In summary, the RMMM plan is a critical tool for ensuring that a project is equipped to identify,
assess, and address risks throughout its life cycle. It supports proactive risk management,
enhances project control, and contributes to successful project outcomes by minimizing the
impact of potential uncertainties.

32 | P a g e
 Additional Notes:

What Are the Goals of Planning a Software Project?

The main goal of planning is organizing the process to make sure client and user
requirements are met, and preventing issues and miscommunication. How it’s done will
greatly influence the success or the failure of the project.
If we’re to dive a bit deeper into the purposes of planning a software development project, it
would be about having a clear overview over:
• The functional purpose of the software project
• The tasks and subtasks to complete each functional requirement
• The list of priorities regarding the features development
• The people involved and their clear roles and responsibilities
• Resources and realistic estimates
• The performance and process metrics that will measure efficiency and quality of work.
Among the most important goals and requirements needed for effective planning are:
• Having a clear and concise understanding of the goals and specs
• Finding time and cost efficient solutions to completing the project
• Having a complete documentation of the project roadmap
• Adherence to quality development standards,
• Delivering reliable, high-quality products to end users
• Ensuring the flexibility needed to accommodate changes and iterations without affecting the
process.
As you can see, there are both project goals and business goals to achieve.
Having a well-thought-out development plan also helps when there’s a problem or a roadblock.
By following the process, it’s easier to spot and clear them without affecting the timeline.
Check out how Waydev works: our development analytics platform analyzes your codebase,
PRs, tickets, and CI/CD activities, to help you bring out the best in your engineering teams’
work.
What is Included in a Software Development Plan?
Because software development is a complex technical process that requires a lot of steps, having
a project plan is extremely helpful to visualize and follow each step of its
development, according to a timeline for the team’s work.
Fortunately, there are many tools – such as development and project analytics, as well as project
management apps – to choose from. This choice usually depends on the size of the engineering
team and the complexity of the software project.
What is generally included in a software development plan are the following stages:
• Planning: when you define the project and its objectives;
• Scoping: when you analyze and set:
o tasks and subtasks as specific as possible
o Realistic time and cost estimates together with the developers – but account for unexpected
delays: holidays, sick days, meetings
o Milestones and their indicative dates (to know how the project is going)
• Implementing: when you develop and deploy the software.
Since data is your best friend in software development, it’s always a great idea to use historical
data and check your past processes – with Waydev’s Project Timeline, it’s possible. See whether

33 | P a g e
 you were inclined to overscore or underscore when planning a software project (although it’s
usually the latter).
Now, let’s dive into what matters most – learn how to plan effective software development
projects, by making sure you have these important steps (or phases) on your checklist.
1. Project Analysis
This is the first step of the scoping stage of a software project requested by a customer. It has a
lot to do with the feasibility of the project.
This analysis part is to make sure you’re starting on the right foot, and it means looking into:
• A deeper understanding of the purpose of the project (concept and goals)
• Also, a deeper understanding the needs of the project
• The project specifications.
Most of the time, it takes place at the same time as the requirements and the main planning
phase, since they’re all connected.
2. Requirements
As you move on to the third step in planning and continue to complete the scope of the project,
your development team and you start to document the technical requirements needed to
successfully deliver the software product.
In this stage, your tasks are to:
• Decide on the team responsible for the development
• Decide on the requirements
• Decide on the milestones that would work as checkpoints for testing and feedback rounds (they
answer to: “how’s the project going?”)
Together with your team, you’ll answer specific questions about the technical aspects of the
project, such as: what issue does the project solve? Who’s the end user? What sort of data is
needed? Does it need certain integrations? How is security tackled?
By answering these questions, you will be able to describe and document the technical
specifications and requirements, methods of testing, technology stacks, software and hardware,
as well as the type of methodology (you might start sprint planning, if you’re using Agile).
Part of this planning stage is also the risk assessment, making sure that you’re also understanding
the constraints or risks the project might have.

3. Planning
Planning is the most meticulous and critical part of the project. It’s also part of the project scope
that allows everyone a clear understanding of the timeline from ideation to deployment.
• A clear overview over the timeline ensures a better organization and synchronization of everyone
involved.
• By breaking down work into tasks, subtasks and steps you will take and looking at the resources
needed, you can provide a clearer estimate of the time and budget.
• You can use a Gantt chart, a list or, better yet, a software tool to visualize this timeline plan and
track it smoothly.
If there’s an issue, you can pinpoint and solve it more easily than having no planning at all.
At the same time, this step determines the quality of your management – which, in turn, will
determine the success of the project. The more detailed and well-thought the planning is, the
easier it becomes to follow the schedule and prevent too many issues along the process.
As a result, the planning phase is all about researching, deciding and documenting all the
aspects: goals, deliverables, tasks, costs, deadlines.

34 | P a g e
 But don’t forget to set meaningful engineering KPIs and metrics in place to quantify your
projects’ success for the concrete targets you set.
To give you a more specific structure, now’s the time when you’d have to work on:
• An approximate timeline and main stages of the development
• Tasks and subtasks for each individual who works on the project
• Ways of communicating with the team, the client, stakeholders
• Time and cost estimates (more accurate when the requirements are set and analyzed)
• Release dates and types of releases
• Documentation of everything (even though you’ll make iterations, keep this intact).
An ideal scenario is to have the software development team working together with the marketing
and the testing team to align business and development goals – but that’s not a rule. If they’re
part of an external team, testers, for example, can cover their part at a later stage.
The planning stage also describes the specific stages of the project development, work needed in
each stage, and cost estimation.
The timeline should be frequently revisited. Nothing is set in stone when it comes to software
development, since it’s always a complex process to handle, so adaptability is key.
Waydev is trusted by over 1,000 engineering leaders worldwide. Discover how our complete Git
Analytics tool features can also help you to increase velocity and reduce cycle time.

4. Design & Prototyping

The next part of an effective software project plan is conceptual designing. This has nothing to
do with the aesthetics, but with the project architecture and functionality.
As a result, it’s done by software architects and engineers to make sure the flow, structure and
the functionality meet the project requirements. It can include:
• The whole structure and its capabilities
• The functionality of the software solution
• Hardware and software components, if needed
• Software tools for future development
• Processes that meet the business needs and goals.
In this stage of the software development life cycle, it’s expected to create either simple, easy to
understand wireframes that show the functions and interactions of the product – or prototyping,
if you need feedback from users on the proposed features.

5. Measuring and Tracking Progress

Before moving on, we have to take a look at this step of the planning process checklist.
You need to set software metrics to track and measure performance and code
quality. Setting these metrics should take place at the beginning of the project development, to
secure a clear and steady workflow with as few roadblocks as possible
Without these measurements to collect and provide valuable data, you cannot manage the project
effectively.
Project analytics, or development analytics, are essential tools that help you accurately spot
and then clear out potential or existing obstacles during the software development life cycle.
As you track and measure these software metrics, it becomes easier to see work trends, as well as
the level of code quality and deployment readiness, to name a few. Learn what metrics to track
here: Software Metrics Leaders Can Measure to Track the Development Process.
Our tool provides you with all the relevant developer metrics you need to track and measure
work from start to finish – in real-time.

35 | P a g e
 You have, for example, the Project Timeline report that shows you the most actionable metrics in
code-based activity. It helps you see what your team is working on over a sprint or a custom time
frame.

Depending on the project requirements, evaluating them will lead you to build better software
faster, to ask for additional resources, or adjust the delivery dates based on objective data.
You get a crystal-clear overview of the Code Review Workflow metrics to learn what’s going on
in the review process to optimize engineer collaboration.
And you also get incredible insights with automated executive reports on Resource
Planning and Project Costs to understand how resources are spent and to help teams ship on
schedule.
Working remotely? Request a demo and get the Agile data-driven approach to software
development no matter where your teams are.

6. Development & Coding

Once the design step is complete, it’s time to move to implementing them through coding. So
this next one in planning effective software development projects is one of the hardest, most
complex and time-consuming one: the software development stage.
The software development team is now starting to build the solution according to the scope of
the project, requirements and proposed functionalities previously agreed on. Depending on the
size of the project, it can be a simple and quick process, or a more complex one that requires
various integrations and functionalities.
Either way, the role of the planning work is to make sure you keep potential risks at a minimum
and build a stable, clean and effective software product.

7. Testing & Quality Control

Still, the delivery of reliable software is not done without quality testing. You’ll have to check:
• Compliance with project requirements
• Meeting the budget and time estimates
• Code quality and other relevant software metrics.
That is why this step of the planning process requires you to have these aspects set in place
before starting the actual work.
Oftentimes, development and testing are conducted simultaneously to make sure each software
feature your team is developing is bug-free and ready to go. However, once the software solution
is completely developed, it still needs a full round of testing to make sure the final product is
working as it should and it’s bug-free and useful to end-users.
This is why we have this step separate – it’s also a stage that takes more time to finish.
The testing and quality assurance phase can also be covered by an external team. If that’s the
case, they can provide a separate plan for this stage.

8. Deployment to Production
This is the (almost) final stage of every software project development process: deploying the
code into production. It’s the moment when all the hard work your developers put in is finally
launched live to end-users.
Deploying is not necessarily taking place at the same time as the production stage. Software
projects are, again, pretty complex. So you might perform several deployments during the
development and testing stages, before having the final deployment to production.

36 | P a g e
 Sometimes, the process looks like this during the development, testing and production
stages:
• Your team builds, deploys and tests code until it is ready for release;
• That code becomes a release candidate;
• Your team deploys the release candidate for pre-release testing;
• Work on release candidates until one is stable enough as the final one;
• Name that stable release candidate as the release version
• Deploy the release version to production.
9. Support & Maintenance
Even though the planned development work is done, that doesn’t mean the work on the software
is also done. After launching it live, the software usually goes through other stages of its
development.
The post-production stage refers to the support and maintenance of the live software. Almost all
digital projects need some sort of basic maintenance or maybe more advanced updates – at some
point or on a regular basis, hence the name of software development life cycle.
Just like customer needs are always evolving, so do the products and services they use.
The goal of this stage is to ensure the scalability and improvement of the initial software to
better serve its users through:
• Basic maintenance of the existing software
• Bug fixing – there will always be bugs to fix, once the people use the live software;
• New (or improved) features and functionalities to be added, depending on the user feedback
One important thing to remember is that the client should have everything about the project
available to them. In your planning process, make sure that:
• The client can have technical assistance post-deployment (usually agreed initially);
• You have complete documentation of the software project from ideation to production;
• There is a documented plan on maintenance, support and documentation practices;
• There’s a clear procedure when it comes to technical debt and code quality control (keeping
developers accountable). Find out more here about measuring developer productivity with the
right performance metrics.
Make sure you have all this data written in the project timeline and list of activities (tasks and
subtasks) so that you’ll know how to prioritize them accordingly.

Wrapping up: How Can You Improve the Success of a Software Development Project?
Use the full potential of effective project planning to avoid (or minimize) these risks:
• Incomplete or inadequate specs
• Incomplete documentation
• Communication gaps between the client, the team, and stakeholders
• Scope creep (because of lack of an Agile data-driven methodology)
• Delivery delays

37 | P a g e
 What are Steps to Reduce Software Risks
• Track risks before they escalate, becoming issues that derail a development project
• Address the riskiest parts of the development process first
• Tackle risks immediately by using an Agile development approach
• Create plans for potential risks at the beginning of the project, and share all risks with clients to
be transparent
• Track development and client team temperature metrics along with project timeline, budget, and
scope
• Encourage open communication and feedback throughout the development process to maintain
team morale

Why is risk management important?

Risk management has perhaps never been more important than it is now. The risks modern
organizations face has grown more complex, fueled by the rapid pace of globalization. New risks
are constantly emerging, often related to and generated by the now-pervasive use of digital
technology. Climate change has been dubbed a "threat multiplier" by risk experts.
A recent external risk that manifested itself as a supply chain issue at many companies -- the
coronavirus pandemic -- quickly evolved into an existential threat, affecting the health and safety
of their employees, the means of doing business, the ability to interact with customers and
corporate reputations.
Businesses made rapid adjustments to the threats posed by the pandemic. But, going forward
they are grappling with novel risks, including how or whether to bring employees back to the
office and what should be done to make their supply chains less vulnerable to crises.
As the world continues to reckon with COVID-19, companies and their boards of directors are
taking a fresh look at their risk management programs. They are reassessing their risk
exposure and examining risk processes. They are reconsidering who should be involved in risk
management. Companies that currently take a reactive approach to risk management -- guarding
against past risks and changing practices after a new risk causes harm -- are considering the
competitive advantages of a more proactive approach. There is heightened interest in supporting
sustainability, resiliency and enterprise agility. Companies are also exploring how artificial
intelligence technologies and sophisticated governance, risk and compliance (GRC) platforms
can improve risk management.
Financial vs. nonfinancial industries. In discussions of risk management, many experts note
that at companies that are heavily regulated and whose business is risk, managing risk is a formal
function.
Banks and insurance companies, for example, have long had large risk departments typically
headed by a chief risk officer (CRO), a title still relatively uncommon outside of the financial
industry. Moreover, the risks that financial services companies face tend to be rooted in numbers
and therefore can be quantified and effectively analyzed using known technology and mature
methods. Risk scenarios in finance companies can be modeled with some precision.
For other industries, risk tends to be more qualitative and therefore harder to manage, increasing
the need for a deliberate, thorough and consistent approach to risk management, said Gartner
analyst Matt Shinkman, who leads the firm's enterprise risk management and audit practices.
"Enterprise risk management programs aim to help these companies be as smart as they can be
about managing risk."

38 | P a g e
Risk Mitigation, Monitoring, and Management (RMMM) plan
RMMM Plan :
A risk management technique is usually seen in the software Project plan. This can be divided
into Risk Mitigation, Monitoring, and Management Plan (RMMM). In this plan, all works are
done as part of risk analysis. As part of the overall project plan project manager generally uses
this RMMM plan.
In some software teams, risk is documented with the help of a Risk Information Sheet (RIS).
This RIS is controlled by using a database system for easier management of information i.e
creation, priority ordering, searching, and other analysis. After documentation of RMMM and
start of a project, risk mitigation and monitoring steps will start.
Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.

Risk Monitoring:
It is an activity used for project tracking.
It has the following primary objectives as follows.
1. To check if predicted risks occur or not.
2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the project.
Risk Management and planning:
It assumes that the mitigation activity failed and the risk is a reality. This task is done by
Project manager when risk becomes reality and causes severe problems. If the project manager
effectively uses project mitigation to remove risks successfully then it is easier to manage the
risks. This shows that the response that will be taken for each risk by a manager. The main
objective of the risk management plan is the risk register. This risk register describes and
focuses on the predicted threats to a software project.
Example:
Let us understand RMMM with the help of an example of high staff turnover.
Risk Mitigation:
To mitigate this risk, project management must develop a strategy for reducing turnover. The
possible steps to be taken are:
• Meet the current staff to determine causes for turnover (e.g., poor working conditions, low
pay, competitive job market).
• Mitigate those causes that are under our control before the project starts.
• Once the project commences, assume turnover will occur and develop techniques to ensure
continuity when people leave.
• Organize project teams so that information about each development activity is widely
dispersed.
• Define documentation standards and establish mechanisms to ensure that documents are
developed in a timely manner.
• Assign a backup staff member for every critical technologist.

39 | P a g e
Risk Monitoring:
As the project proceeds, risk monitoring activities commence. The project manager monitors
factors that may provide an indication of whether the risk is becoming more or less likely. In
the case of high staff turnover, the following factors can be monitored:
• General attitude of team members based on project pressures.
• Interpersonal relationships among team members.
• Potential problems with compensation and benefits.
• The availability of jobs within the company and outside it.
Risk Management:
Risk management and contingency planning assumes that mitigation efforts have failed and
that the risk has become a reality. Continuing the example, the project is well underway, and a
number of people announce that they will be leaving. If the mitigation strategy has been
followed, backup is available, information is documented, and knowledge has been dispersed
across the team. In addition, the project manager may temporarily refocus resources (and
readjust the project schedule) to those functions that are fully staffed, enabling newcomers who
must be added to the team to “get up to the speed“.
Risk management process
The risk management discipline has published many bodies of knowledge that document what
organizations must do to manage risk. One of the best-known sources is the ISO 31000
standard, Risk Management -- Guidelines, developed by the International Organization for
Standardization, a standards body commonly known as ISO.
ISO's five-step risk management process comprises the following and can be used by any type of
entity:
1. Identify the risks.
2. Analyze the likelihood and impact of each one.
3. Prioritize risks based on business objectives.
4. Treat (or respond to) the risk conditions.
5. Monitor results and adjust as necessary.
The steps are straightforward, but risk management committees should not underestimate the
work required to complete the process. For starters, it requires a solid understanding of what
makes the organization tick. The end goal is to develop the set of processes for identifying the
risks the organization faces, the likelihood and impact of these various risks, how each relates to
the maximum risk the organization is willing to accept, and what actions should be taken to
preserve and enhance organizational value.
"To consider what could go wrong, one needs to begin with what must go right," said risk expert
Greg Witte, a senior security engineer for Huntington Ingalls Industries and an architect of the
National Institute of Standards and Technology (NIST) frameworks on cybersecurity, privacy
and workforce risks, among others.
When identifying risks, it is important to understand that, by definition, something is only a risk
if it has impact, Witte said. For example, the following four factors must be present for a
negative risk scenario, according to guidance from the NIST Interagency Report on identifying
cybersecurity risk in ERM:
1. a valuable asset or resources that could be impacted;
2. a source of threatening action that would act against that asset;
3. a preexisting condition or vulnerability that enables that threat source to act; and
4. some harmful impact that occurs from the threat source exploiting that vulnerability.

40 | P a g e
While the NIST criteria pertains to negative risks, similar processes can be applied to managing
positive risks.

Drawbacks of RMMM:
• It incurs additional project costs.
• It takes additional time.
• For larger projects, implementing an RMMM may itself turn out to be another tedious
project.
• RMMM does not guarantee a risk-free project, infact, risks may also come up after the
project is delivered.

Methods for Identifying Risks

Identifying risk is one of most important or essential and initial steps in risk management
process. By chance, if failure occurs in identifying any specific or particular risk, then all other
steps that are involved in risk management will not be implemented for that particular risk. For
identifying risk, project team should review scope of program, estimate cost, schedule,
technical maturity, parameters of key performance, etc. To manage risk, project team or
organization are needed to know about what risks it faces, and then to evaluate them.
Generally, identification of risk is an iterative process. It basically includes generating or
creating comprehensive list of threats and opportunities that are based on events that can
enhance, prevent, degrade, accelerate, or might delay successful achievement of objectives. In
simple words, if you don’t find or identify risk, you won’t be able to manage it.
Methods for Identifying Risks:
Earlier, there were no easy methods available that will surely identify all risks. But nowadays,
there are some additional approaches available for identifying risks. Some of approaches for
risk identification are given below:
1. Checklist Analysis –
Checklist Analysis is type of technique generally used to identify or find risks and manage it.
The checklist is basically developed by listing items, steps, or even tasks and is then further
analyzed against criteria to just identify and determine if procedure is completed correctly or
not. It is list of risk that is just found to occur regularly in development of software project.
Below is the list of software development risk by Barry Boehm- modified version.
Risk Risk Reduction Technique

Various techniques include training and career

Personnel Shortfalls development, job-matching, teambuilding, etc.

Various techniques include incremental development,

Unrealistic time and standardization of methods, recording, and analysis of
cost estimates the past project, etc.

41 | P a g e
 Development of wrong Various techniques include formal specification
software functions methods, user surveys, etc.

Development of the Various techniques include user involvement,

wrong user interface prototyping, etc.

1. Brainstorming –
This technique provides and gives free and open approach that usually encourages each and
everyone on project team to participate. It also results in greater sense of ownership of
project risk, and team generally committed to managing risk for given time period of
project. It is creative and unique technique to gather risks spontaneously by team members.
The team members identify and determine risks in ‘no wrong answer’ environment. This
technique also provides opportunity for team members to always develop on each other’s
ideas. This technique is also used to determine best possible solution to problems and issue
that arises and emerge.

2. Casual Mapping –
Causal mapping is method that builds or develops on reflection and review of failure
factors in cause and effect of the diagrams. It is very useful for facilitating learning with an
organization or system simply as method of project-post evaluation. It is also key tool for
risk assessment.

3. SWOT Analysis –
Strengths-Weaknesses-Opportunities-Threat (SWOT) is very technique and helpful for
identifying risks within greater organization context. It is generally used as planning tool
for analyzing business, its resources, and also its environment simply by looking at internal
strengths and weaknesses and opportunities and threats in external environment. It is
technique often used in formulation of strategy. The appropriate time and effort should be
spent on thinking seriously about weaknesses and threats of organization for SWOT
analysis to more effective and successful in risk identification.

4. Flowchart Method –
This method allows for dynamic process to be diagrammatically represented in paper. This
method is generally used to represent activities of process graphically and sequentially to
simply identify the risk.

What is included in a risk management plan?

A risk management plan defines how your project's risk management process will be executed.
That includes the funds, tools and approaches that will be used to perform risk
identification, assessment, mitigation and monitoring activities.

=========================================================

42 | P a g e
Estimation
What is it?
“It is the judgement of values”
It is used to determine how much money, efforts, resources & time needed to build the
software.
Why Estimation?
To avoid risk of money loss.
It supports to predict and control project risk.
Help to identify cost, schedule, resources & time requirements during a project.
As to build house, it is not feasible to start building without estimation of cost, similarly before
start of creating new s/w it is necessary to develop estimates.
How S/w Project Estimations done?
S/w cost and effort are never exact science.
How to achieve reliable cost & effort?
1. Estimate based on similar existing project
2. Use simple decomposition technique
i. Decompose problem
ii. Decompose Process

1. LOC-based estimation
Example-
Function Estimated LOC

User interface & control facilities 2300

2D geometric Analysis 5300
3D geometric Analysis 6800
Database Design & management 3350
CG Display facilities 4950
Peripheral Control function 2100
Design Analysis module 8400

Estimated LOC 33200

Historical data indicates average productivity for system is 620 LOC/pm

Based on labor rate $8,000pm & cost per line of code Approx $13. So total estimated
cost=$431000 & estimated effort 54 p/m

Function Point-based Estimation

Explain function oriented metrics and how function point is calculated.
Function-oriented metrics are used in software engineering to measure and evaluate software
based on its functionality and the services it provides to users. These metrics focus on the
functions and features of the software rather than its internal characteristics or code complexity.
One commonly used function-oriented metric is the Function Point (FP).

43 | P a g e
 Function Point (FP) is a sizing metric that quantifies the functionality provided by a software
application. It is used to measure the size of a software project, which can be useful for
estimating effort, resources, and project duration. The Function Point analysis typically considers
five types of functions in a software application:

1. External Inputs (EI): These are user inputs processed by the software. For example, entering
data into a form.
2. External Outputs (EO): These are the results provided to the user. For instance, generating a
report or displaying information on the screen.
3. External Inquiries (EQ): These are interactive inputs and outputs. They involve a combination
of input and output, where the output is based on an inquiry from the user.
4. Internal Logical Files (ILF): These are data maintained by the software. For example, a
database that the software uses.
5. External Interface Files (EIF): These are files used by the software but maintained by external
applications. For instance, reading data from a file generated by another system.
The calculation of Function Points involves assigning complexity levels (low, average, or high)
to each function type based on specific criteria, such as data processing, user interactions, and
file complexity. Each function type is then assigned a weight, and the total Function Points are
calculated using the following formula:
FP= (∑(Number of each function type) \times(Weight for each function type))×Adjustment Factor
The Adjustment Factor is based on 14 General System Characteristics (GSC), which include
factors such as data communications, distributed data processing, performance, and reusability.
The adjustment factor adjusts the calculated Function Points based on the specific characteristics
of the software project.
In summary, function-oriented metrics, particularly Function Points provide a standardized way
to measure the functionality of a software application. This measurement can be valuable for
project estimation, productivity evaluation, and comparing software projects of different sizes
and complexities.

a. Process based Estimation

2. Process decomposed into small set of task & effort estimated

44 | P a g e
 3. It begins with s/w functions obtained from SCOPE
4. Series of framework Activities performed for Each Function
5. Process based estimation Table shown below

Activity Engineering Construction CE Total

Task Ana Design Code Test
Function -- -- --

User interface & control 0.50 2.5 0.40 5.0 na 8.4

facilities 0.75 4.0 0.60 2.0 na 7.3
2D geometric Analysis 0.50 4.0 1.00 3.0 na 8.5
3D geometric Analysis 0.50 3.0 1.00 1.5 na 6.0
Database Design & 0.50 3.00 0.75 1.5 na 5.7
management 0.25 2.0 0.5 1.5 na 4.2
CG Display facilities 3.50 20.50 4.50 16.50 46.0
Peripheral Control function 8% 45% 10% 36
Design Analysis module
Total
% Efforts

Once functions and process defined, estimate efforts and Average labor rate i.e. cost/unit effort
1. USE –CASE BASED ESTIMATION
2. COCOMO Model:

COCOMO (Constructive Cost Model) is a regression model based on LOC, i.e. number of
Lines of Code. It is a procedural cost estimate model for software projects and is often used as a
process of reliably predicting the various parameters associated with making a project such as
size, effort, cost, time, and quality. It was proposed by Barry Boehm in 1981 and is based on the
study of 63 projects, which makes it one of the best-documented models. The key parameters
which define the quality of any software products, which are also an outcome of the Cocomo are
primarily Effort & Schedule:
• Effort: Amount of labor that will be required to complete a task. It is measured in person-
months units.
• Schedule: Simply means the amount of time required for the completion of the job, which is,
of course, proportional to the effort put in. It is measured in the units of time such as weeks,
and months.
Different models of Cocomo have been proposed to predict the cost estimation at different
levels, based on the amount of accuracy and correctness required. All of these models can be
applied to a variety of projects, whose characteristics determine the value of the constant to be
used in subsequent calculations. These characteristics pertaining to different system types are
mentioned below. Boehm’s definition of organic, semidetached, and embedded systems:
1. Organic – A software project is said to be an organic type 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.

45 | P a g e
2. Semi-detached – A software project is said to be a Semi-detached type if the vital
characteristics such as team size, experience, and 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 Semi-Detached types.
3. Embedded – A software project 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.
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model
4. Basic Model –

The above formula is used for the cost estimation of for the basic COCOMO model, and also is
used in the subsequent models. The constant values a,b,c, and d for the Basic Model for the
different categories of the system:

1. The effort is measured in Person-Months and as evident from the formula is dependent on
Kilo-Lines of code. The development time is measured in months. These formulas are used
as such in the Basic Model calculations, as not much consideration of different factors such
as reliability, and expertise is taken into account, henceforth the estimate is rough. Below is
the C++ program for Basic COCOMO.

// C++ program to implement basic COCOMO

#include <bits/stdc++.h>
using namespace std;
// Function for rounding off float to int
int fround(float x)
{
int a;
x = x + 0.5;
a = x;
return (a);
}

46 | P a g e
 // Function to calculate parameters of Basic COCOMO
void calculate(float table[][4], int n, char mode[][15],
int size)
{
float effort, time, staff;
int model;
// Check the mode according to size

if (size >= 2 && size <= 50)

model = 0; // organic

else if (size > 50 && size <= 300)

model = 1; // semi-detached
else if (size > 300)
model = 2; // embedded

cout << "The mode is " << mode[model];

// Calculate Effort
effort = table[model][0] * pow(size, table[model][1]);
// Calculate Time
time = table[model][2] * pow(effort, table[model][3]);
// Calculate Persons Required
staff = effort / time;
// Output the values calculated
cout << "\nEffort = " << effort << " Person-Month";
cout << "\nDevelopment Time = " << time << " Months";
cout << "\nAverage Staff Required = " << fround(staff)
<< " Persons";
}
int main()
{
float table[3][4] = { 2.4, 1.05, 2.5, 0.38, 3.0, 1.12,
2.5, 0.35, 3.6, 1.20, 2.5, 0.32 };
char mode[][15]
= { "Organic", "Semi-Detached", "Embedded" };
int size = 4;
calculate(table, 3, mode, size);
return 0;
}

Output:
The mode is Organic
Effort = 10.289 Person-Month
Development Time = 6.06237 Months
Average Staff Required = 2 Persons
-------------------------------------------------------

47 | P a g e