Software Engineering (by Shalini)

UNIT-2
Software size estimation
Software size estimation is an essential task in software project management as it helps
project managers to determine the resources required, schedule the project, and
estimate the cost. There are various methods to estimate the size of a software project,
and some of the popular ones are:

1.​ Lines of Code (LOC): This method is based on counting the number of lines of code
required to develop the software. The LOC method is simple and straightforward, but it
does not consider the complexity of the software. The size is estimated by comparing it
with the existing systems of the same kind.
Advantages:
●​ Universally accepted and is used in many models like COCOMO.
●​ Estimation is closer to the developer’s perspective.
●​ Simple to use.
Disadvantages:
●​ Different programming languages contain a different number of lines.
●​ No proper industry standard exists for this technique.
●​ It is difficult to estimate the size using this technique in the early stages of the
project.

2. Number of entities in ER diagram: ER model provides a static view of the project. It

describes the entities and their relationships. The number of entities in ER model can be
used to measure the estimation of the size of the project. The number of entities
depends on the size of the project. This is because more entities needed more
classes/structures thus leading to more coding.
Advantages: ​

●​ Size estimation can be done during the initial stages of planning.

●​ The number of entities is independent of the programming technologies used.
Disadvantages:
●​ No fixed standards exist. Some entities contribute more project size than others.
●​ Just like FPA, it is less used in the cost estimation model. Hence, it must be
converted to LOC.

3. Total number of processes in detailed data flow diagram: Data Flow Diagram
(DFD) represents the functional view of software. The model depicts the main
processes/functions involved in software and the flow of data between them. Utilization
of the number of functions in DFD to predict software size. Already existing processes
of similar type are studied and used to estimate the size of the process. Sum of the
estimated size of each process gives the final estimated size.
Advantages:
 ●​ It is independent of the programming language.
●​ Each major process can be decomposed into smaller processes. This will increase
the accuracy of estimation
Disadvantages:
●​ Studying similar kinds of processes to estimate size takes additional time and effort.
●​ All software projects are not required for the construction of DFD.

4. Function Points (FP): This method is based on the functionality provided by the
software. The FP method considers the complexity of the software and the functions it
performs. It uses a set of metrics to calculate the size of the software project.
Advantages:
●​ It can be easily used in the early stages of project planning.
●​ It is independent of the programming language.
●​ It can be used to compare different projects even if they use different technologies
(database, language, etc.).
Disadvantages:
●​ It is not good for real-time systems and embedded systems.
●​ Many cost estimation models like COCOMO uses LOC and hence FPC must be
converted to LOC.

5. Use Case Points (UCP): This method is based on the number of use cases required
for the software. The UCP method considers the complexity of the software and the
number of interactions it has with the users.

6. Story Points (SP): This method is based on the complexity of the user stories
required to develop the software. The SP method considers the complexity of the
software and the amount of work required to develop it.

Choosing the appropriate method for estimating the size of a software project depends
on various factors, such as the project's complexity, the level of accuracy required, the
available resources, and the project's stage. Project managers must carefully consider
these factors when selecting a size estimation method for their software projects.

Cost estimation
Cost estimation is an essential aspect of software project management, and it involves
predicting the amount of money required to complete a project successfully. There are
various methods for cost estimation, including:

1.​ Expert Judgment: This method involves seeking the opinions of experts in the field
who have experience in managing similar projects. These experts can provide valuable
insights into the cost of the project based on their experience, knowledge, and
expertise.
2.​ Analogous Estimation: This method involves comparing the current project with
similar projects that have been completed in the past. By doing this, the project
manager can estimate the cost based on the previous project's cost.
3.​ Bottom-Up Estimation: This method involves breaking down the project into smaller
tasks and estimating the cost for each task. The individual estimates are then added up
to provide an overall cost estimate for the project.
4.​ Three-Point Estimation: This method involves estimating the cost based on three
scenarios: the best-case scenario, the most likely scenario, and the worst-case
scenario. The weighted average of these scenarios is then used to estimate the
project's cost.
5.​ Parametric Estimation: This method involves using historical data to develop a
statistical model for cost estimation. The model takes into account various factors, such
as project size, complexity, and the team's experience, to provide an accurate cost
estimate.

Ultimately, the method used for cost estimation will depend on the project's size,
complexity, and available data. A combination of different methods may be necessary to
provide an accurate cost estimate for the project.

Constructive Cost Model (COCOMO)

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.
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.
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

1. 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:
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.
2. Intermediate Model – The basic Cocomo model assumes that the effort is only a
function of the number of lines of code and some constants evaluated according to the
different software systems. However, in reality, no system’s effort and schedule can be
solely calculated on the basis of Lines of Code. For that, various other factors such as
reliability, experience, Capability. These factors are known as Cost Drivers and the
Intermediate Model utilizes 15 such drivers for cost estimation. Classification of Cost
Drivers and their attributes:
Product attributes –
1.​ Required software reliability extent
2.​ Size of the application database
3.​ The complexity of the product
4.​ Run-time performance constraints
5.​ Memory constraints
6.​ The volatility of the virtual machine environment
7.​ Required turnabout time
8.​ Analyst capability
9.​ Software engineering capability
10.​Applications experience
11.​Virtual machine experience
12.​Programming language experience
13.​Use of software tools
 14.​Application of software engineering methods
15.​Required development schedule
3. Detailed Model – Detailed COCOMO incorporates all characteristics of the
intermediate version with an assessment of the cost driver’s impact on each step of the
software engineering process. The detailed model uses different effort multipliers for
each cost driver attribute. In detailed cocomo, the whole software is divided into
different modules and then we apply COCOMO in different modules to estimate effort
and then sum the effort. The Six phases of detailed COCOMO are:
0.​ Planning and requirements
1.​ System design
2.​ Detailed design
3.​ Module code and test
4.​ Integration and test
5.​ Cost Constructive model

Advantages of the COCOMO model:

1.​ Provides a systematic way to estimate the cost and effort of a software project.
2.​ Can be used to estimate the cost and effort of a software project at different stages
of the development process.
3.​ Helps in identifying the factors that have the greatest impact on the cost and effort of
a software project.
4.​ Can be used to evaluate the feasibility of a software project by estimating the cost
and effort required to complete it.

Disadvantages of the COCOMO model:

1.​ Assumes that the size of the software is the main factor that determines the cost and
effort of a software project, which may not always be the case.
2.​ Does not take into account the specific characteristics of the development team,
which can have a significant impact on the cost and effort of a software project.
3.​ Does not provide a precise estimate of the cost and effort of a software project, as it
is based on assumptions and averages.

Putnam Resource Allocation Model

The Putnam Resource Allocation Model, also known as the Putnam Model, is a
mathematical model used to predict the effort required to complete a software project. It
was developed in the 1960s by Lawrence Putnam and was initially used to estimate the
effort required for large, complex defense projects. The model is based on the principle
that the effort required to complete a project is directly proportional to the number of
delivered lines of code and the number of people working on the project. The Putnam
Model has been widely used in software engineering to estimate project cost and
duration, and it has been used in a variety of domains, including aerospace, finance,
and government. Putnam estimates project effort, schedule, and defect rate by using a
tool known as The Norden/ Rayleigh Curve.
The software equation was derived by Putnam after he observed that the productivity
levels of software staffing profiles followed the Rayleigh distribution.

The Putnam model involves the following terms:

●​ K, which represents the total effort expended (in PM) in product development
●​ L, the product estimate in KLOC.
●​ td, which correlates to the time of system and integration testing and can be
relatively considered as the time required for developing the product.
●​ Ck, the state of technology constant that reflects requirements that impede the
development of the program.
●​ Ck has typical values of 2 for a poor development environment
●​ 8 for a good software development environment
●​ 11 for an excellent environment where software engineering principles,
automated tools, and techniques are used.
The exact value of Ck for a specific task can be calculated from the historical data of the
organization developing it.

Putnam’s model proposes that an ideal number of staff required to develop a project
should follow the Rayleigh distribution. Initially, only a few engineers are needed to
perform planning and specification tasks. As the project progresses and more detailed
work is required, the number of engineers needed reaches a peak. After implementation
and unit testing, the number of project staff reduces.

Risk Management
 Software risk management involves identifying, assessing, and mitigating potential risks
that may arise during the development, testing, deployment, and maintenance of
software.

Software risks can be broadly classified into the following categories:

1.​ Technical risks: Technical risks are related to the software development process, such
as coding errors, design flaws, integration issues, and compatibility problems. These
risks can lead to delays, defects, and failures in the software.
2.​ Business risks: Business risks are related to the impact of software on the
organization's goals and objectives, such as financial risks, market risks, and reputation
risks. These risks can affect the profitability, market share, and brand image of the
organization.
3.​ Project management risks: Project management risks are related to the planning,
execution, and control of the software development project, such as schedule delays,
resource constraints, and scope creep. These risks can lead to project failure, cost
overruns, and missed deadlines.
4.​ Security risks: Security risks are related to the protection of the software and its data
from unauthorized access, theft, or damage. These risks can lead to data breaches,
identity theft, and loss of confidential information.
5.​ Legal and regulatory risks: Legal and regulatory risks are related to compliance with
laws and regulations governing the software industry, such as copyright, patent, and
privacy laws. These risks can lead to lawsuits, fines, and legal liabilities.

Effective software risk management involves identifying and prioritizing risks,

developing strategies to mitigate them, and monitoring and controlling risks throughout
the software development lifecycle. This ensures that software projects are completed
on time, within budget, and meet the organization's goals and objectives.

Identifying Risks

Risk Identification: The project organizer needs to anticipate the risk in the project as
early as possible so that the impact of risk can be reduced by making effective risk
management planning.

A project can be of use by a large variety of risk. To identify the significant risk, this
might affect a project. It is necessary to categories into the different risk of classes.

There are different types of risks which can affect a software project:

1.​ Technology risks: Risks that assume from the software or hardware
technologies that are used to develop the system.
2.​ People risks: Risks that are connected with the person in the development
team.
 3.​ Organizational risks: Risks that assume from the organizational environment
where the software is being developed.
4.​ Tools risks: Risks that assume from the software tools and other support
software used to create the system.
5.​ Requirement risks: Risks that assume from the changes to the customer
requirement and the process of managing the requirements change.
6.​ Estimation risks: Risks that assume from the management estimates of the
resources required to build the system

Risk projection
Risk projection in software engineering involves estimating the likelihood and potential
impact of identified risks. It helps the software engineering team to prioritize risks and
allocate resources accordingly to manage them. Here are some common techniques
used for risk projection in software engineering:

1.​ Probability and Impact Matrix: This technique involves assigning a probability and
impact rating to each identified risk. The probability rating estimates the likelihood of the
risk occurring, while the impact rating estimates the severity of the risk's consequences.
The two ratings are then plotted on a matrix to determine the risk's priority level.
2.​ Monte Carlo Simulation: This technique uses statistical methods to simulate different
scenarios based on input variables such as project duration, resource availability, and
risk events. The simulation generates a probability distribution of outcomes and helps
the team to estimate the likelihood of achieving the project objectives under different
conditions.
3.​ Expert Judgment: This technique involves seeking input from subject matter experts or
experienced practitioners to assess the potential impact of identified risks. The experts
provide their informed opinion on the likelihood and impact of the risk and help the team
to prioritize risks.
4.​ Historical Data Analysis: This technique involves analyzing historical data from similar
projects to identify common risks and their potential impact. The analysis helps the team
to estimate the likelihood and impact of similar risks in the current project and develop
appropriate risk management strategies.

By using these techniques, the software engineering team can project the potential risks
and prioritize them accordingly to manage them effectively.

Risk Refinement
Risk refinement in software engineering involves further analysis and assessment of
identified risks to gain a deeper understanding of their potential impact and develop
more specific strategies for managing them. Here are some common techniques used
for risk refinement in software engineering:
1.​ Risk Breakdown Structure (RBS): This technique involves breaking down high-level
risks into smaller, more manageable components to facilitate analysis and
management. The RBS helps the team to identify the root causes of the risk and
develop specific strategies for addressing them.
2.​ Failure Mode and Effects Analysis (FMEA): This technique involves analyzing each
risk to identify the potential failure modes, their effects, and the likelihood of occurrence.
FMEA helps the team to develop strategies for preventing or mitigating the effects of
each failure mode.
3.​ SWOT Analysis: This technique involves identifying the project's strengths,
weaknesses, opportunities, and threats. The team can use this analysis to identify risks
that may arise from weaknesses and threats and develop strategies to mitigate them.
4.​ Risk Simulation: This technique involves using computer simulations to test different
scenarios and assess the potential impact of identified risks. Risk simulation can help
the team to identify potential problems and develop strategies for managing them before
they occur.

By using these techniques, the software engineering team can gain a more detailed
understanding of each risk's potential impact and develop more specific strategies for
managing them. This process helps to reduce the overall project risk and increase the
likelihood of project success.

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.
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.​

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, in fact, risks may also come up after
the project is delivered.