SOFTWARE ENGINEERING AND

PROJECT MANAGEMENT
(BCS501)

Prepared by,
Kavya Jayaprasad
Assistant Professor
AI&ML department
AIEMS, Bidadi
 Course Outcomes

Learning Resources
 Module 5
Software Quality and Project
Estimation
 INTRODUCTION
Quality:
• Quality is generally agreed to be ‘a good thing’.
• In a practice what people really mean by the ‘quality’ of a system can be vague,
undefined attribute.
• We need to define precisely what qualities we require of a system.

Objective assessment:
• We need to judge objectively whether a system meets our quality requirements
and this need measurement.
 INTRODUCTION
• During development, it's important to:
• Assess the likely quality of the final system.
• Ensure development methods will produce the desired
quality.

• Potential customers might focus on:

• Checking if suppliers use the best development
methods.
• Ensuring these methods will lead to the required quality
in the final system.
THE PLACE OF SOFTWARE QUALITY IN PROJECT PLANNING
 THE PLACE OF SOFTWARE QUALITY IN PROJECT PLANNING

Quality will be of concern at all stages of project planning and execution, but will be
particular interest at Stepwise framework.
• Step 1 : Identifying project scope and objectives Some objective could relate to the
quality of the application to be delivered.
• Step 2 : Identifying project infrastructure involves identifying installation
standards and procedures. Some of these will almost certainly be about quality
requirements.
• Step 3: Analyze project characteristics. In this activity the application to be
implemented will be examined to see if it has any special quality requirements.
• Step 4: Identify the product and activities of the project. It is at that point the entry,
exit and process requirement are identified for each activity.
• Step 8: Review and publicize plan. At this stage the overall quality aspects of the
project plan are reviewed.
 THE IMPORTANCE OF SOFTWARE QUALITY
• Now a days, quality is the important aspect of all organization.
• Few reasons which are most important to ensure quality are :
Increasing criticality of software:
• The final customer or user is naturally anxious about the general quality of software
especially about the reliability.
• They are concern about the safety because of their dependency on the software system
such as aircraft control system which are more safety critical systems.
The intangibility of software:
• Difficulty in verifying the satisfactory completion of project tasks.
• Tangibility is achieved by requiring developers to produce "deliverables" that can be
examined for quality.
Accumulating errors during software development:
• Errors in earlier steps can propagate and accumulate in later steps.
• Errors found later in the project are more expensive to fix.
• The unknown number of errors can make the debugging phase difficult to control.
 DEFINING SOFTWARE QUALITY
• Defining quality is not enough.

• If we are to judge whether a system meets our requirements,

we need to be able to measure its qualities.
• A good measure must relate the number of units o the
maximum possible.
• Trying to find measures for a particular quality helps to clarify
and communicate what quality really is.
• The measure may be direct or indirect.
• When project managers identify quality measurements, they
effectively set targets for project team members.
 DEFINING SOFTWARE QUALITY
• Quality is a rather vague term and we need to define carefully what we mean by it.

• For any software system there should be three specifications.

• A functional specification describing what the system is to do.
• A quality specification concerned with how well the function are to operate.
• A resource specification concerned with how much is to be spent on the system.

• Software qualities are grouped into three sets:

• Product operation qualities,
• Product revision qualities and
• Product transition qualities.
 DEFINING SOFTWARE QUALITY
Product operation qualities:
• Correctness: The extent to which a program satisfies its specification and fulfil user objective.
• Reliability: the extent to which a program can be expected to perform its intended function with
required precision.
• Efficiency: The amounts of computer resource required by software.
• Integrity: The extent to which access to software or data by unauthorized persons can be
controlled.
• Usability: The effort required to learn, operate, prepare input and interprets output.
 DEFINING SOFTWARE QUALITY
Product Revision Qualities:
• Maintainability: The effort required to locate and fix an error in an operational program
• Testability: The effort required to test a program to ensure it performs its intended function.
• Flexibility: The effort required to modify an operational program.

Product Transition Qualities:

• Portability: The efforts require to transfer a program from one hardware configuration and or
software system environment to another.
• Reusability: The extent to which a program can be used in other applications.
• Interoperability: The efforts required to couple one system to another.
 DEFINING SOFTWARE QUALITY
When there is concern about the need for a specific quality characteristic in a software
product then a quality specification with the following minimum details should be
drafted.
• Definition/Description: Clear definition of the quality characteristic.
• Scale : The unit used to measure the quality characteristic.
• Test: The practical test of the extent to which the quality attribute exists.
• Minimally Acceptable: The worst value which might be acceptable, below which the product
would be rejected.
• Target Range: The range of values within which it is planned that the quality measurement value
should lie.
• Now: The value that applies currently to the quality characteristic.
 DEFINING SOFTWARE QUALITY
Measurements Applicable to Quality Characteristic- Reliability in Software are :

• Availability: Percentage of a particular time interval that a system is usable.

• Mean Time Between Failures (MTBF): Total service time divided by the number of failures.
• Failure on Demand: Probability that a system will not be available when required, or
probability that a transaction will fail.
• Support Activity: Number of fault reports generated and processed.
 Defining Software Quality

Related Quality measurements in

case of reliability:
• Maintainability: How quickly a fault can be corrected once
detected.
• Changeability: Ease with which software can be modified.
• Analyzability: Ease with which causes of failure can be identified,
contributing to maintainability.

These measurements help quantify and assess the reliability and

maintainability of software systems, ensuring they meet desired quality
standards.
 SOFTWARE QUALITY MODELS

• The need to be able to quantitatively measure the quality of a software is often felt, to verify whether a software meets the
quality requirements set for it.

• Unfortunately, it is hard to directly measure the quality of a software, However, it can be expressed in terms of several
attributes of a software that can be directly measured.

• The quality models give a characterization (often hierarchical) of software quality in terms of a set of characteristics of the
software.

• The bottom level of the hierarchical can be directly measured, thereby enabling a quantitative assessment of the quality of
the software.

• There are several well-established quality models.

• McCall’s model.
• Dromey’s Model.
• Boehm’s Model.
• ISO 9126 Model.
 SOFTWARE QUALITY MODELS
Garvin’s Quality Dimensions
David A Garvin , a professor of Harvard Business school, defined the quality of any product in terms of
eight general attributes of the product:

• Performance: How well it performs the jobs.

• Features: How well it supports the required features.

• Reliability: Probability of a product working satisfactorily within a specified period of time.

• Conformance: Degree to which the product meets the requirements.

• Durability: Measure of the product life.

• Serviceability: Speed and effectiveness maintenance.

• Aesthetics: The look and feel of the product.

• Perceived quality: User’s opinion about the product quality.

 SOFTWARE QUALITY MODELS
McCall’ Model
McCall defined the quality of a software in terms of three broad parameters:
• its operational characteristics,
• how easy it is to fix defects and
• how easy it is to part it into different platforms.
 SOFTWARE QUALITY MODELS
McCall’ Model
The three high-level quality attributes are defined based on the following eleven attributes of the software:
• Correctness: The extent to which a software product satisfies its specifications.

• Reliability: The probability of the software product working satisfactorily over a given duration.

• Efficiency: The amount of computing resources required to perform the required functions.

• Integrity: The extent to which the data of the software product remain valid.

• Usability: The effort required to operate the software product.

• Maintainability: The ease with which it is possible to locate and fix bugs in the software product.

• Flexibility: The effort required to adapt the software product to changing requirements.

• Testability: The effort required to test a software product to ensure that it performs its intended function.

• Portability: The effort required to transfer the software product from one hardware or software system environment to another.

• Reusability: The extent to which a software can be reused in other applications.

• Interoperability: The effort required to integrate the software with other software.
 Software Quality Models
Dromey’s model
• Dromey proposed that software product quality depends on four major high-level properties of the software:
• Correctness, internal characteristics, contextual characteristics and certain descriptive properties.
• Each of these high-level properties of a software product, in turn depends on several lower-level quality attributes.
• Dromey’s hierarchical quality model is shown in the Fig below:
 SOFTWARE QUALITY MODELS
Boehm’s Model
Boehm’s suggested that the quality of a software can be defined based on the following high-level
characteristics that are important for the users of the software:
• As-is -utility: How well (easily, reliably and efficiently) can it be used?
• Maintainability: How easy is to understand, modify and then retest the software?
• Portability: How difficult would it be to make the software in a changed environment?

• Boehm’s expressed these high-level product quality attributes in terms of several measurable product
attributes.
• Boehm’s hierarchical quality model is shown in the Fig (Next slide).
Software Quality Models
Boehm’s Model
 Software Quality Models
ISO 9126
• ISO 9126 standards was first introduced in 1991 to tackle the question of the
definition of software quality.
• The original 13-page document was designed as a foundation upon which further
more detailed standard could be built.
• ISO9126 documents are now very lengthy.
• People with differing motivation might be interested in software quality,
namely:
• Acquirers who are obtaining software from external suppliers
• Developers who are building a software product
• Independent evaluators who are accessing the quality of a software product, not for
themselves but for a community of users.
• ISO 9126 also introduces another type of quality - quality in use - for which the
following elements have been identified:
• Effectiveness : the ability to achieve user goals with accuracy and completeness;
• Productivity : avoiding the excessive use of resources, such as staff effort, in achieving
user goals;
• Safety: within reasonable levels of risk of harm to people and other entities such as
business, software, property and the environment
• Satisfaction: smiling users.
 Software Quality Models
ISO 9126
• ISO 9126 is a significant standard in defining software quality attributes
and providing a framework for assessing them.

ISO 9126 identifies six major external software quality characteristics:

1. Functionality : The functions that a software product provides to satisfy user needs.
2. Reliability: The capability of the software to maintain its level of performance under
stated conditions.
3. Usability: The effort needed to use the software.
4. Efficiency: The ability to use resources in relation to the amount of work done.
5. Maintainability: The effort needed to make changes to the software.
6. Portability: The ability of the software to be transferred from one environment to
another.
 Software Quality Models
ISO 9126
• ISO 9126 is a significant standard in defining software quality attributes and providing a framework for assessing
them.
ISO 9126 identifies six major external software quality characteristics:
1. Functionality:
• Definition: The functions that a software product provides to satisfy user needs.
• Sub-characteristics: Suitability, accuracy, interoperability, security, compliance.

• Functionality Compliance’ refers to the degree to which the software adheres to application-related standard or legal requirements.
• ‘Interoperability’ refers to the ability of software to interact with others.
 Software Quality Models
ISO 9126
2. Reliability:
• Definition: The capability of the software to maintain its level of performance under stated conditions.
• Sub-characteristics: Maturity, fault tolerance, recoverability.

Maturity refers to frequency of failures due to fault in software, more identification of fault, more changes to remove them.
Recoverability describes the control of access to a system.
 Software Quality Models
ISO 9126
[Link]:
• Definition: The effort needed to use the software.
• Sub-characteristics: Understandability, learnability, operability, attractiveness, usability compliance.

• Understand ability is a clear quality to grasp.

 Software Quality Models
ISO 9126
[Link] and [Link]:

Characteristic Sub-Characteristics

Efficiency Time behaviour

Resource Utilization

Efficiency compliance

Maintainability Analyzability

Changeability

Stability

Testability

Maintainability compliance
 Software Quality Models
ISO 9126

[Link]:
• Definition: The ability to use resources in relation to the amount of work done.
• Sub-characteristics: Time behavior, resource utilization.

[Link]:
• Definition: The effort needed to make changes to the software.
• Sub-characteristics: Analyzability, changeability, stability, testability.

• Analyzability is the quality that McCall called diagnose ability, the ease with
which the cause of failure can be determined.
• Changeability is the quality that others call flexibility: the latter name implies
suppliers of the software are always changing it.
• Stability means that there is a low risk of a modification to software having
unexpected effects.
 Software Quality Models
ISO 9126
6. Portability:
• Definition: The ability of the software to be transferred from one environment to
another.
• Sub-characteristics: Adaptability, install ability, co-existence.

• Portability compliance relates to those standards that have a bearing on portability.

• Replaceability refers to the factors that give upward compatibility between old software
components and the new ones.
• 'Coexistence' refers to the ability of the software to share resources with other software
components; unlike' interoperability', no direct data passing is necessarily involved
 Software Quality Models
ISO 9126
• ISO 9126 provides structured guidelines for assessing and managing software quality
characteristics based on the specific needs and requirements of the software product.
Steps Suggested by ISO 9126 After Establishing Requirements:
1. Judge the importance of each quality Characteristic for the application:
• Identify key quality characteristics (e.g., Usability, Efficiency, and Maintainability).
• Reliability will be of particular concern with safety-critical systems where failure
can have severe consequences.
• Efficiency is important for real-time systems where timely responses are crucial.

2. Select the external quality measurements within the ISO 9126 framework relevant
to the qualities prioritized:
• Determine appropriate external quality measurements that correspond to each
quality characteristic.
• Reliability: Measure with MTBF or similar metrics.
• Efficiency: Measure with response time or time behavior metrics.
 Software Quality Models
ISO 9126
3. Map measurements onto ratings that reflect user satisfaction:
Develop a comprehensive plan for quality assurance activities, including
testing, verification, and validation processes to ensure adherence to quality
standards.
• For response time, user satisfaction could be mapped as follows :

Response time (seconds) Rating

<2 Exceeds expectation

2-5 Within the target range

6-10 Minimally acceptable

>10 unacceptable
 Software Quality Models
ISO 9126
4. Identify the relevant internal measurements and the intermediate products
in which they appear:
• Identify and track internal measurements such as cyclomatic complexity, code
coverage, defect density, etc.
• Relate these measurements to intermediate products like source code, test cases, and
documentation.
5. Overall assessment of product quality:
• Use weighted quality scores to assess overall product quality.
• Focus on key quality requirements and address potential weaknesses early to avoid
the need for an overall quality rating later.
Response time (seconds) Quality Score
<2 5
2-3 4
4-5 3
6-7 2
8-9 1
>9 0
 Software Quality Models
ISO 9126

• This table provides a comparison of two products (A and B) based on weighted quality
scores.
• Each product quality (Usability, Efficiency, and Maintainability) is given an importance
rating.
• Product A and B are scored for each quality, and these scores are multiplied by the
importance rating to obtain weighted scores.
• The total weighted scores are summed for each product to determine their overall ranking.
 Product Versus Process Quality Management
• In software development, managing quality can be approached from two main
perspectives:
• product quality management and
• process quality management.

Product Quality Management

• Product quality management focuses on evaluating and ensuring the quality of
the software product itself.
• This approach is typically more straightforward to implement and measure
after the software has been developed.

Process Quality Management

• Process quality management focuses on assessing and improving the quality of
the development processes used to create the software.
• This approach aims to reduce errors and improve efficiency throughout the
development lifecycle.
 Product Versus Process Quality Management

The system development process comprises a number of activities linked so that the
output from one activity is input to the next.
 Product Versus Process Quality Management
• Errors can enter the process in any stage.
• Errors not removed at early stage become more expensive to correct at later
stage.
• Errors should therefore be eradicated by careful examination of deliverables
of each step before they are passed on.
• One way of doing this is by having the following requirements for each step:
 Observation on Estimation
• Estimation of resources, cost, and schedule for a software engineering effort
requires experience, access to good historical information, and the courage
to commit to quantitative predictions when qualitative information is all that
exists.
• Estimation carries inherent risk and this risk leads to uncertainty.
• Project complexity has a strong effect on the uncertainty inherent in planning.
• Complexity, is a relative measure that is affected by familiarity with past
effort.
• The first-time developer of a sophisticated e-commerce application might
consider it to be exceedingly complex.
• Project size is another important factor that can affect the accuracy and
efficacy of estimates.
• As size increases, the interdependency among various elements of the
software grows rapidly.
 Observation on Estimation
• The availability of historical information has a strong influence on estimation risk.
• By looking back, you can emulate things that worked and improve areas where
problems arose.
• When comprehensive software metrics are available for past projects, estimates can
be made with greater assurance, schedules can be established to avoid past
difficulties, and overall risk is reduced.
• Estimation risk is measured by the degree of uncertainty in the quantitative
estimates established for resources, cost, and schedule.
• If project scope is poorly understood or project requirements are subject to
change, uncertainty and estimation risk become dangerously high.
• As a planner, you and the customer should recognize that variability in software
requirements means instability in cost and schedule.
• Modern software engineering approaches take an iterative view of development.
• In such approaches, it is possible—although not always politically acceptable—to
revisit the estimate and revise it when the customer makes changes to
requirements.
 Software Project Estimation
• Software cost and effort estimation will never be an exact science.
• Too many variables—human, technical, environmental, political—can affect
the ultimate cost of software and effort applied to develop it.

To achieve reliable cost and effort estimates, a number of options arise:

1. Delay estimation until late in the project.
2. Base estimates on similar projects that have already been completed.
3. Use relatively simple decomposition techniques to generate project cost
and effort estimates.
4. Use one or more empirical models for software cost and effort estimation.

• Unfortunately, the first option, however attractive, is not practical.

• The second option can work reasonably well, if the current project is quite
similar to past efforts and other project influences are roughly equivalent.
• Unfortunately, past experience has not always been a good indicator of future results.
• The remaining options are viable approaches to software project estimation.
 Software Project Estimation
• Decomposition techniques take a divide-and-conquer approach to software
project estimation.
• By decomposing a project into major functions and related software
engineering activities, cost and effort estimation can be performed in a
stepwise fashion.
• Empirical estimation models can be used to complement decomposition
techniques and offer a potentially valuable estimation approach in their own
right.
• A model is based on experience (historical data) and takes the form
d = f (𝑽𝒊 )
• where d is one of a number of estimated values (e.g., effort, cost, project
duration) and
• 𝑉𝑖 are selected independent parameters (e.g., estimated LOC or FP).
• Automated estimation tools implement one or more decomposition
techniques or empirical models and provide an attractive option for
estimating.
 Decomposition Techniques
• Software project estimation is a form of problem solving, and in most
cases, the problem to be is too complex to be considered in one piece.

• For this reason, we should decompose the problem into set of smaller
problems.

• Decomposition has 2 points of view:

• Decomposition of the problem and
• Decomposition of the process.

• Estimation uses one or both forms of partitioning.

• But before an estimate can be made, we must understand the scope of the
software to be built and generate an estimate of its “size.”
 Decomposition Techniques
Software Sizing

The accuracy of a software project estimate is predicated on a number of things:

1. the degree to which we have properly estimated the size of the product to be built.
2. the ability to translate the size estimate into human effort, calendar time, and
dollars.
3. the degree to which the project plan reflects the abilities of the software team.
4. the stability of product requirements and the environment that supports the soft-
ware engineering effort.

Sizing represents the first major challenge as a planner.

• If a direct approach is taken, size can be measured in lines of code (LOC).
• If an indirect approach is chosen, size is represented as function points (FP).
 Decomposition Techniques
Software Sizing
Putnam and Myers [Put92] suggest four different approaches to the sizing problem:
• “Fuzzy logic” sizing. This approach uses the approximate reasoning techniques that are
the cornerstone of fuzzy logic.
• To apply this approach, the planner must identify the type of application, establish its
magnitude on a qualitative scale, and then refine the magnitude within the original range.
• Function point sizing. The planner develops estimates of the information domain
characteristics.
• Standard component sizing. Software is composed of a number of different “standard
components” that are generic to a particular application area.
• The project planner estimates the number of occurrences of each standard component and
then uses historical project data to estimate the delivered size per standard component.
• Change sizing. This approach is used when a project encompasses the use of existing
software that must be modified in some way as part of a project.
• The planner estimates the number and type (e.g., reuse, adding code, changing code, deleting
code) of modifications that must be accomplished.
 Decomposition Techniques
Problem Based Estimation:
• Lines of code (LOC) and function points (FP) data are used in two ways during
software project estimation:
1. as estimation variables to “size” each element of the software and
2. as baseline metrics collected from past projects and used in conjunction with
estimation variables to develop cost and effort projections.
• LOC and FP estimation are distinct estimation techniques. Yet both have a number of
characteristics in common.
• You begin with a bounded statement of Software scope and from this statement attempt
to decompose the statement of scope into problem functions that can each be
estimated individually.
• LOC or FP (the estimation variable) is then estimated for each function.
 Decomposition Techniques
Problem Based Estimation
• The LOC and FP estimation techniques differ in the level of detail required for
decomposition and the target of the partitioning.
• When LOC is used as the estimation variable, decomposition is absolutely
essential and is often taken to considerable levels of detail.
• The greater the degree of partitioning, the more likely reasonably accurate
estimates of LOC can be developed.
• Regardless of the estimation variable that is used, you should begin by
estimating a range of values for each function or information domain value.
• A three-point or expected value can then be computed.
• The expected value for the estimation variable (size) S can be computed as a
weighted average of the optimistic(sopt), most likely (sm), and pessimistic
(spess) estimates. For example,
 Decomposition Techniques
An Example of LOC-Based Estimation
• As an example of LOC and FP problem-based estimation techniques, let us consider a software package
to be developed for a computer-aided design application for mechanical components.

• The software is to execute on an engineering workstation and must interface with various computer
graphics peripherals including a mouse, digitizer, high-resolution color display, and laser printer.

A preliminary statement of software scope can be developed:

• The mechanical CAD software will accept two- and three-dimensional geometric data from an engineer.

• The engineer will interact and control the CAD system through a user interface that will exhibit
characteristics of good human/machine interface design.

• All geometric data and other supporting information will be maintained in a CAD database.

• Design analysis modules will be developed to produce the required output, which will be displayed on a
variety of graphics devices.

• The software will be designed to control and interact with peripheral devices that include a mouse,
digitizer, laser printer, and plotter.
Decomposition Techniques
An Example of LOC-Based Estimation
 Decomposition Techniques
An Example of FP-Based Estimation
• Decomposition for FP-based estimation focuses on information domain values
rather than software functions.
• we would estimate inputs, outputs, inquiries, files, and external interfaces for the
CAD software.
• For the purposes of this estimate, the complexity weighting factor is assumed to
be average. Table below presents the results of this estimate.
 Decomposition Techniques
An Example of FP-Based Estimation

• The organizational average productivity for systems of this type is 6.5 FP/pm.
• Based on a burdened labor rate of $8000 per month, the cost per FP is approximately $1230.
• Based on the FP estimate and the historical productivity data, the total estimated project cost
is $461,000 and the estimated effort is 58 person-months.
 Decomposition Techniques
Process-Based Estimation
• The most common technique for estimating a project is to base the
estimate on the process that will be used.
• That is, the process is decomposed into a relatively small set of tasks and
the effort required to accomplish each task is estimated.
 Decomposition Techniques
An example of Process-Based Estimation
• To illustrate the use of process-based estimation, consider the CAD software shown in table above
(previous slide).
• The system configuration and all software functions remain unchanged and are indicated by project
scope.
• The engineering and construction release activities are subdivided into the major software engineering
tasks.
• Gross estimates of effort are provided for customer communication, planning, and risk analysis. These
are noted in the total row at the bottom of the table.
• Horizontal and vertical totals provide an indication of estimated effort required for analysis, design,
code, and test.
• It should be noted that 53 percent of all effort is expended on front-end engineering task (requirements
analysis and design), indicating the relative importance of this work.
• Based on an average burdened labor rate of $8000 per month, the total estimated project cost is
$368,000 and the estimated effort is 46 person-months.
• If desired, labor rates could be associated with each framework activity or software engineering task
and computed separately.
 Decomposition Techniques
Estimation with Use Cases
• Use cases provide a software team with insight into software scope and
requirements.
• However, developing an estimation approach with use cases is problematic for
the following reasons:
• Use cases are described using many different formats and styles—there is no
standard form.
• Use cases represent an external view (the user’s view) of the software and can
therefore be written at many different levels of abstraction.
• Use cases do not address the complexity of the functions and features that are
described.
• Use cases can describe complex behavior (e.g., interactions) that involve many
functions and features.
• Unlike an LOC or a function point, one person’s “use case” may require months
of effort while another person’s use case may be implemented in a day or two.
 Decomposition Techniques
Estimation with Use Cases
• Before use cases can be used for estimation, the level within the structural
hierarchy is established, the average length (in pages) of each use case is
determined, the type of software (e.g., real-time, business,
engineering/scientific, WebApp, embedded) is defined, and a rough
architecture for the system is considered.
• Once these characteristics are established, empirical data may be used to
establish the estimated number of LOC or FP per use case (for each level of the
hierarchy).
• Historical data are then used to compute the effort required to develop the
system.
Decomposition Techniques
Estimation with Use Cases
 Decomposition Techniques
An Example of Use-Case–Based Estimation
• The CAD software introduced in LOC based estimation is composed of
three subsystem groups:
• user interface subsystem (includes UICF),
• engineering subsystem group (includes the 2DGA, 3DGA, and DAM
subsystems),
• infrastructure subsystem group (includes CGDF and PCF subsystems).
• Six use cases describe the user interface subsystem.
• Each use case is described by no more than 10 scenarios and has an average
length of six pages.
• The engineering subsystem group is described by 10 use cases (these are
considered to be at a higher level of the structural hierarchy).
• Each of these use cases has no more than 20 scenarios associated with it and
has an average length of eight pages.
• Finally, the infrastructure subsystem group is described by five use cases
with an average of only six scenarios and an average length of five pages.
 Decomposition Techniques
An Example of Use-Case–Based Estimation
 Decomposition Techniques
Reconciling Estimate
• The estimation techniques discussed in the preceding sections result in multiple estimates that must be reconciled
to produce a single estimate of effort, project duration, or cost.

• To illustrate this reconciliation procedure, let us consider the CAD software introduced in LOC example.

• The total estimated effort for the CAD software ranges from a low of 46 person months (derived using a process-
based estimation approach) to a high of 68 person months (derived with use-case estimation).

• The average estimate (using all four approaches) is 56 person-months.

• The variation from the average estimate is approximately 18 percent on the low side and 21 percent on the high
side.

• What happens when agreement between estimates is poor?

• The answer to this question requires a reevaluation of information used to make the estimates.
• Widely divergent estimates can often be traced to one of two causes:

1. the scope of the project is not adequately understood or has been misinterpreted by the planner, or

2. productivity data used for problem-based estimation techniques is inappropriate for the application, obsolete
(in that it no longer accurately reflects the software engineering organization), or has been misapplied. You
should determine the cause of divergence and then reconcile the estimates.
 Empirical Estimation Model
• An estimation model for computer software uses empirically derived
formulas to predict effort as a function of LOC or FP.

• The empirical data that support most estimation models are derived from a
limited sample of projects.

• For this reason, no estimation model is appropriate for all classes of software
and in all development environments.

• An estimation model should be calibrated to reflect local conditions.

• The model should be tested by applying data collected from completed

projects, plugging the data into the model, and then comparing actual to
predicted results.

• If agreement is poor, the model must be tuned and retested before it can be
used.
 Empirical Estimation Model
The Structure of Estimation Models

• A typical estimation model is derived using regression analysis on data

collected from past software projects.
• The overall structure of such models takes the form
E = A+B 𝑒𝑣 𝑐
• where A, B, and C are empirically derived constants, E is effort in person-
months, and 𝑒𝑣 is the estimation variable (either LOC or FP).

• The majority of estimation models have some form of project adjustment

component that enables E to be adjusted by other project characteristics.
 Empirical Estimation Model
The Structure of Estimation Models

Among the many LOC-oriented estimation models proposed in the literature are
 Empirical Estimation Model
The COCOMO II Model
• Barry Boehm introduced a hierarchy of software estimation models bearing the name
COCOMO, for COnstructive COst MOdel.
• The original COCOMO model became one of the most widely used and discussed
software cost estimation models in the industry.

• It has evolved into a more comprehensive estimation model, called COCOMO II .

• Like its predecessor, COCOMO II is actually a hierarchy of estimation models that
address the following areas:
➢ Application composition model. Used during the early stages of software engineering,
when prototyping of user interfaces, consideration of software and system interaction,
assessment of performance, and evaluation of technology maturity are paramount.

➢ Early design stage model. Used once requirements have been stabilized and basic
software architecture has been established.
➢ Post-architecture-stage model. Used during the construction of the software.
 Empirical Estimation Model
The COCOMO II Model
• Like all estimation models for software, the COCOMO II models require
sizing information.
• Three different sizing options are available as part of the model
hierarchy: object points, function points, and lines of source code.
• Like function points, the object point is an indirect software measure
that is computed using counts of the number of (1) screens, (2) reports,
and (3) components likely to be required to build the application.
• Each object instance is classified into one of three complexity levels
(i.e., simple, medium, or difficult) using criteria suggested by Boehm.
• In essence, complexity is a function of the number and source of the
client and server data tables that are required to generate the screen or
report and the number of views or sections presented as part of the screen
or report.
 Empirical Estimation Model
The COCOMO II Model

Once complexity is determined, the number of screens, reports, and components are
weighted according to the table illustrated in Figure below:
 Empirical Estimation Model
The COCOMO II Model
When component-based development or general software reuse is to be applied, the
percent of reuse (%reuse) is estimated and the object point count is adjusted:
Empirical Estimation Model
The COCOMO II Model
 Empirical Estimation Model
The COCOMO II Model
The software equation is a dynamic multivariable model that assumes a specific distribution
of effort over the life of a software development project.
The model has been derived from productivity data collected for over 4000 contemporary
software projects.
Based on these data, we derive an estimation model of the form:
 Empirical Estimation Model
The COCOMO II Model
• Typical values might be P=2000 for development of real-time embedded
software, P=10,000 for telecommunication and systems software, and P =28,000
for business systems applications.
• The productivity parameter can be derived for local conditions using historical
data collected from past development efforts.
• The software equation has two independent parameters:
1. an estimate of size (in LOC) and
2. an indication of project duration in calendar months or years.
• To simplify the estimation process and use a more common form for their
estimation model, Putnam and Myers suggest a set of equations derived from
the software equation.
 Empirical Estimation Model
The COCOMO II Model

Minimum development time is defined as

THANK YOU