SOFTWARE ENGINEERING

CSE
V SEMESTER ​
​ By
Presented
Ms. Y. Sujana
Assistant Professor,
Department of CSE(DS),
Institute of Aeronautical Engineering, Hyderabad.
 UNIT -
V

PROJECT MANAGEMENT
 contents

Estimation: FP based, LOC based, make/buy decision

COCOMO II: Planning, project plan, planning process,
RFP risk management,
identification, projection;
RMMM: Scheduling and tracking, relationship between
people and effort, task set
and network,
scheduling
EVA: Process and project metrics.
 Project management

• Organising, planning and scheduling software projects

• Objectives

– To introduce software project management and to describe its

distinctive characteristics
– To discuss project planning and the planning process
– To show how graphical schedule representations are
used by
project management
– To discuss the notion of risks and the risk management process
 Software project

• Concerned with activities involved in ensuring that software is

delivered
– on time
– within the budget
– in accordance with the requirements

• Project management is needed because software

development is always subject to budget and schedule
constraints
– Set by the development organisation or the customer
 Software management
• The product is intangible ds
• The product is uniquely flexible

• The product is uniquely complex

• Software engineering is not recognized as an engineering discipline with

the same status as mechanical, electrical engineering, etc.

• The software development process is not Standardised

• Many software projects are o͞ ne-off͟ projects

 Management activities

• Proposal writing
• Project planning and scheduling
• Project costing
• Project monitoring and reviews
• Personnel selection and evaluation
• Report writing and presentations
 Project staffing
• May not be possible to appoint the ideal people to work on a
project
– Project budget may not allow for the use of highly-paid staff
– Staff with the appropriate experience may not be available
–
– An organisation may wish to develop Employee skills on a software
project
• Here’s Bob. He’s a sophomore. He’ll be a member of your HazMat
Rover team. He doesn’t know much yet, but he can brew a mean
cup of coffee and has a great personality.

• Managers have to work within these constraints

– especially when (as is currently case there is
international shortage
the of skilled ITstaff ) an
 Project planning
• Probably the most time-consuming project management activity
• Continuous activity from initial concept through
system delivery to
• Plans must be regularly revised as new
– Beware of grumbling developers information becomes available
• Various different types of plan may be developed to support the
main
software project plan that is concerned with schedule and budget
 Types of project plan

Plan Description
Quality plan Describes the quality procedures and
standards that will be used in a project
Validation plan Describes the approach, resources and
schedule used for system validation.
Configuration management Describes the configuration
plan management procedures and structures to
be used.
Maintenance plan Predicts the maintenance requirements of
the system, maintenance costs and effort
required.
Staff development plan Describes how the skill and
experience of the project
team members will be developed.
 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 (obviously, we can achieve
100 percent accurate estimates after the project is complete!).
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. Cost estimates
must be provided up-front. However, recognize that the longer you wait, the
more you know, and the more you know, the less likely you are to make serious
errors in your estimates.
The second option can work reasonably well, if the current project is quite
similar to past efforts and other project influences (e.g., the customer, business
 Function Point based Estimation
Function Point based Estimation :
•A Function Point (FP) is a unit of measurement to express the amount of business
functionality, an information system (as a product) provides to a user. FPs measure software
size. They are widely accepted as an industry standard for functional sizing
•Function point analysis is a method of quantifying the size and complexity of a software
system in terms of the functions that the system delivers to the user
• It is Independent of the computer language,development methodology,
technology or capability of the project team used to develop the application
• Function point analysis is designed to measure business applications (not scientific
applications)
•Scientific applications generally deal with complex algorithms that the function
point method is not designed to handle
•Function points are independent of the language, tools, or methodologies used for
implementation (ex. Do not take into consideration programming languages, DBMS, or
processing hardware)
•Function points can be estimated early in analysis and design
 Function Point based Estimation
Uses of Function Point:
•Measure productivity (ex. Number of function points achieved per work hour
expended)
• Estimate development and support (cost benefit analysis, staffing estimation)
• Monitor outsourcing agreements (Ensure that the outsourcing entity
delivers the level of support and productivity gains that they promise)
• Drive is related business decisions(Allow decisions regarding the retaining,
retiring and redesign of applications to be made)
• Normalize other measures (Other measures, such as defects,
frequently
require the size in function points)
 LOC based Estimation
LOC based estimation
•Source lines of code (SLOC), also known as lines of code (LOC), is a software metric
used to measure the size of a computer program by counting the number of lines in the
text of the program's source code.
•SLOC is typically used to predict the amount of effort that will be required to develop a
program, as well as to estimate programming productivity or maintainability once the
software is produced.
•Lines used for commenting the code and header file are ignored.
Two major types of LOC:
1. Physical LOC
• Physical LOC is the count of lines in the text of the program's source code including
comment lines.
• Blank lines are also included unless the lines of code in a section consists of more
than 25% blank lines.
2. Logical LOC
• Logical LOC attempts to measure the number of executable statements, but their
specific definitions are tied to specific computer languages.
• Ex: Logical LOC measure for C-like programming languages is the number of
statement-terminating semicolons(;)
 LOCbased Estimation
The problems of lines of code (LOC)
– Different languages lead to different lengths of code
– It is not clear how to count lines of code
– A report, screen, or GUI generator can generate thousands of lines of code
in minutes
– Depending on the application, the complexity of code is different.
 make/buy decision
• In many software application areas, it is often more cost effective to acquire rather
than develop computer software.
• Software engineering managers are faced with a make/ buy decision that can be
further complicated by a number of acquisition options.
(1) Software may be purchased (or licensed) off-the-shelf
(2) ͞full-experience͟ or p͞ artial-experience͟ software
components
may be acquired and then modified and integrated to meet
specific needs.
(3) Software may be custom built by an outside contractor to meet the
purchaser’s
specifications.
• In the final analysis the make/buy decision is made based on the following
conditions:
(1) Will the delivery date of the software product be sooner than that for internally
developed software?
(2)Will the cost of acquisition plus the cost of customization be less than the cost of
developing the software internally?
(3) Will the cost of outside support (e.g., a maintenance contract) be less than the
cost of internal support?
 make/buy decision
Creating a Decision Tree :
•The steps just described can be augmented using statistical techniques such
as decision tree analysis.
•For example, considered the figure below it depicts a decision tree for a software
based system X. In this case, the software engineering organization can
(1) build system X from scratch
(2) reuse existing partial-experience components to construct the system
(3) buy an available software product and modify it to meet local needs, or
(4) contract the software development to an outside vendor.
If the system is to be built from scratch, there is a 70 percent probability that the
job will be difficult.
The expected value for cost, computed along any branch of the decision tree, is:
where i is the decision tree path. For the build path.
 make/buy decision
• It is important to note, however, that many criteria —not just cost—mustbe
considered during the decision-making process. Availability, experience of the
developer/ vendor/contractor, conformance to requirements, local politics ͞, and the
likelihood of change are but a few of the criteria that may affect the ultimate
decision to build, reuse, buy, or contract.
 make/buy decision
Outsourcing
•Sooner or later, every company that develops computer software asks a fundamental
question: I͞ s there a way that we can get the software and systems we need at a lower price?
•The answer to this question is not a simple one, and the emotional discussions that occur
in response to the question always lead to a single word: outsourcing. Regardless of the
breadth of focus, the outsourcing decision is often a financial one.
•Outsourcing is extremely simple. Software engineering activities are contracted to a
third party who does the work at lower cost and, hopefully, higher quality.
•The decision to outsource can be either strategic or tactical.
•At the strategic level, business managers consider whether a significant portion of all
software work can be contracted to others.
•At the tactical level, a project manager determines whether part or all of a project can
be best accomplished by subcontracting the software work.
•On the positive side, cost savings can usually be achieved by reducing the number
of
software people and the facilities (e.g., computers, infrastructure) that support them.
•On the negative side, a company loses some control over the software that it needs.
 COCOMO II Model
Barry Boehm [Boe81] 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 COCOMOII.

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

 COCOMO II Model

The COCOMO II models require sizing information.

• Three different sizing options are available as part of the model hierarchy: object
points, function points, and lines of source code.

The COCOMO II application composition model uses object points:

• The object point is an indirect software measure that is computed using counts of
the number of
(1) screens (at the user interface),
(2) reports
(3) components likely to be required to build the application.

Complexity Weighting for object types

 COCOMO II Model

• Each object instance (e.g., a screen or report) is classified into one of three
complexity levels (i.e., simple, medium, or difficult).
• Once complexity is determined, the number of screens, reports, and components are
weighted according to the table given below
• 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:

NOP = (object points) * [(100 - %reuse)/100]

where NOP is defined as new object points

• To derive an estimate of effort based on the computed NOP value, a “productivity

rate” must be derived.
PROD=NOP/person-month

• Once the productivity rate has been determined, an estimate of project effort is
computed using,
Estimated effort = NOP/PROD
 COCOMO II Model

Productivity rate for object points

COCOMO II Model
 RMMM

Risk Mitigation, Monitoring, and Management:

• An effective strategy for dealing with risk must consider three issues (Note: these
are not mutually exclusive)
– Risk mitigation
– Risk monitoring
– Risk management and contingency planning
• Risk mitigation - is the primary strategy and is achieved through a plan –
Example: Risk of high staff turnover
• Meet with 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
 RMMM

• Conduct peer reviews of all work (so that more than one person is ”up to speed”)

• Assign a backup staff member for every critical technologist.

• During risk monitoring, the project manager monitors factors that may provide an
indication of whether a risk is becoming more or less likely

• Risk management and contingency planning assume that mitigation efforts have
failed and that the risk has become a reality

• RMMM steps incur additional project cost – Large projects may have identified 30
– 40 risks

• Risk is not limited to the software project itself – Risks can occur after the
software has been delivered to the user
 RMMM

• Software safety and hazard analysis

– These are software quality assurance activities that focus on the identification
and assessment of potential hazards that may affect software negatively and
cause an entire system to fail

– If hazards can be identified early in the software process, software design

features can be specified that will either eliminate or control potential hazards.

– It is important to note that risk mitigation, monitoring, and management

(RMMM) steps incur additional project cost
 RMMM

• The RMMM plan may be a part of the software development plan or may be a
separate document.

• Once RMMM has been documented and the project has begun, the risk
mitigation, and monitoring steps begin
– Risk mitigation is a problem avoidance activity
– Risk monitoring is a project tracking activity

• Risk monitoring has three objectives

– To assess whether predicted risks do, in fact, occur
– To ensure that risk aversion steps defined for the risk are being properly
applied
– To collect information that can be used for future risk analysis

• The findings from risk monitoring may allow the project manager to ascertain
what risks caused which problems throughout the project
 Process and Project Metrics

What are Metrics?

• Software process and project metrics are quantitative measures
• They are a management tool
•They offer insight into the effectiveness of the software process and the
projects that are conducted using the process as a framework
• Basic quality and productivity data are collected
• These data are analyzed, compared against past averages, and assessed
• The goal is to determine whether quality and productivity improvements have
occurred
• Thedata can also be used to pin point problem areas
• Remedies can then be developed and the software process can be improved
 Process and Project Metrics

Reasons to Measure
To characterize in order to
Gain an understanding of processes, products, resources, and environments
Establish baselines for comparisons with future
assessments
Toevaluate in orderto
Determine status
with respect to
plans
To predict in order to
Gain
understanding
of relationships
amongprocesses

and products
Build models of these
relationships
Metrics In The Process and Project
Domains
• Process metrics are collected overlong periods of time.

• Their intent is to provide a set of process indicators that lead to long-

term
software processimprovement.

• Project metrics enable a software project manager to

• assess the status of an ongoing project,
• track potential risks,
• uncover problem areas before they go
• adjust work flow or tasks,
• evaluate the project team’s ability to control quality of software work
products
Metrcs In The Process and Project Domains
Determinants for software quality and
organizational
effectiveness.
 Metrics In The Process and Project
• Measure the effectiveness of a process and Project
Errors uncovered before release of thesoftware
• Defects delivered to and reported by the end users
• Work products delivered
• Human effortexpended
• Calendar timeexpended
• Conformance to theschedule
• Time and effort to complete each generic activity.

• Etiquette(good manners) of Process Metrics:

• Use common sense and organizationalsensitivity when interpreting metrics data
• Provide regular feedback to the individuals and teams who collect measures andmetrics
• DoŶ’t use metrics to evaluate individuals
• Work with practitioners and teams to set clear goals and metrics that will be used to
achieve them.
• Never use metrics to pressure individuals or teams.
• Metrics data that indicate a problem should not be considered Ŷ͞ egative
Metrics In The Process and Project
Project Metrics:-
Many of the same metrics are used in both the process and project
domain Project metrics are used for making tactical decisions
They are used to adapt project workflow and technical activities .
Thefirst application of project metrics occurs during estimation
Metrics from past projects are used as a basis for estimating time
and effort
Asa project proceeds, the amount of time and effort expended are compared to
original estimates.
Astechnical work commences, other project metrics become important

Production rates are measured (represented in terms of modelscreated,

review hours,function points, and delivered source lines ofcode)

Error uncovered during each generic framework activity (i.e,

communication, planning, modeling, construction, deployment) aremeasured
 Software Measurement

Measurements in the physical world can be categorized in two ways: direct

measures and indirect measures.
Direct measures of the software process include cost and effort applied.
Direct measures of the product include lines of code (LOC) produced,
execution speed, memory size, and defects reported over some set period of
time.
Indirect measures of the product include functionality, quality,
complexity, efficiency, reliability, maintainability.

Project metrics can be consolidated to create process metrics for

an
organization.
 Software Measurement

Size-Oriented Metrics
Size-oriented metrics are not universallyaccepted as the best way to
measure
the software process.
Opponents argue that KLOCmeasurements
Are dependent on the
programminglanguage Penalize well-
designed but shortprograms
Cannot easily accommodatenonprocedural
Function-Oriented Metrics:-
languages
Function-oriented metrics use a measure of the functionality delivered
Require a level of detail that may be difficult
by the application as a normalization value
to achieve.
Mostwidely used metric of this type is the function point
Computation the function point based on
of characteristics of is the
software’s information domain and complexity.
 Software Measurement
Reconciling LOC and FP Metrics:-
Relationship between LOC and FP dependsupon
The programming language that is usedto
implement thesoftware
The quality of thedesign

FPand LOC have been found to be relatively accurate predictors of software development
effort and cost
However, a historical baseline of informationmust first beestablished.

LOC and FP can be used to estimate object-oriented softwareprojects

However, they do not provide enough granularity for the schedule and effort
adjustments required in the iterations of an evolutionary or incremental process
The table on the next slide provides a rough estimate of the average LOC to one FP
in
various programming languages.
 Software Measurement
LOC Per Function Point
Language Average Median Low High
Ada 154 -- 104 205
Assembler 337 315 91 694
C 162 109 33 704
C++ 66 53 29 178
COBOL 77 77 14 400
Java 55 53 9 214
PL/1 78 67 22 263
Visual Basic 47 42 16 158
 Software Measurement
Object-oriented Metrics:-
Following set of metrics for OOprojects:
Number of scenario scripts:- A scenario script is a detailed sequence of
steps that describe the interaction between the user and the application.
Each script is organized into triplets of the form
{initiator, action, participant}
where initiator is the object that requests some service, action is the result
of the request, and participant is the server object that satisfies the request.

Number of key classes.:- Key classes are the ͞highly independent components
that are defined early in object-oriented analysis
Because key classes are central to the problem domain, the number of such
classes is an indication of the amount of effort required to develop the
software.
Also an indication of the potential amount of reuse to be applied during system
development.
 Software Measurement
Numberof support classes:- Support classes are required to implement the
system but are not immediately related to the problemdomain.
• The number of support classes is an indication of the amount of effort required
to develop the software and also an indication of the potential amount of reuse
to be applied during systemdevelopment.

• Number of subsystems
• A subsystem is an aggregation of classes that support a function that is
visible to the end user of a system.

Average number of support classes per key class

Key classes are identified early in a project (e.g., at requirements
analysis) Estimation of the number of support classes can be made from the
number of keyclasses
GUI applications have between two and three times more support classes as
key classes
Non-GUI applications have between oneand two times more support classes
as
key classes
 Software Measurement

Use-Case–Oriented
Metrics:- basi
Use cases describe user-visible functions and features that
requirements for a system. c
The number of use cases is directly proportional to the size of the application in
are
LOC and to the number of test cases that will have to be designed to fully
exercise the application.

WebApp Project Metrics:-

The objective of all WebApp projects is to deliver a combination of content
and functionality to the end user.
The measures that can be collected are:
• Number of static Webpages.
• Number of dynamic Webpages.
• Number of internal page links.:-Internal page linksare pointers that
provide a hyperlink to some other Web page within theWebApp
 Software Measurement
Number of persistent dataobjects.

Number of external systems interfaced:- WebApps must often interface

with ď͞ aĐkrooŵ͟ business applications.
Number of static content objects:-Static content objects encompass static text-
based, graphical, video, animation, and audio information that are incorporated
within the WebApp.
Number of dynamic contentobjects.
Number of executablefunctions
 Software Measurement

Measurements in the physical world can catrorize in two ways.direct

measures andindirect measures.
Direct measures of the software process include cost and effortapplied.
Direct measures of the product include lines of code (LOC) produced,
execution speed, memory size, and defects reported over some set period of
time.
Indirect measures of the product include functionality, quality, efficiency,
reliability, maintainability.
Project metrics can be consolidated to create process metrics foran
organization.
 Software Measurement
• Size-Oriented Metrics
Size-oriented metrics are not universallyaccepted as the best
wayto measure the softwareprocess.
Opponents argue that KLOCmeasurements
Are dependent on the
programminglanguage Penalize well-
designed but shortprograms
Cannot easily accommodatenonprocedural
languages
Requirea level of detail that may be difficult to
achieve.

• Function-Oriented Metrics:-
Function-oriented metrics use a measure of
the functionality delivered
• by the application as a normalizationvalue
 Metrics For Software Quality
The overriding goal of software engineering is to produce a high-quality system,
application, or product within a time frame that satisfies a marketneed.
The quality of a system, application, or product is only as good as the requirements
that describe the problem, the design that models the solution, the code that leads
to an executable program, and the tests that exercise the software to uncover errors.
Measuring Quality
• There are many measures of software quality,8 correctness, maintainability,
integrity, and usability provide useful indicators for the projectteam
Correctness:
• Correctness is the degree to which the software performs its required function.
• The most common measure for correctness is defects per KLOC, where a
defect is defined as a verified lack of conformance to requirements.
• Defects are those problems reported by a user of the program after
the
program has been released for generaluse.
 Metrics For Software Quality
Maintainability:
• Maintainability is the ease with which a program can be corrected if an error is
encountered, adapted if its environment changes, or enhanced if the customer desires a
change inrequirements.
• Mean -time-to-change (MTTC), the time it takes to analyze the change request, design
an appropriate modification, implement the change, test it, and distribute the change
to allusers.

• Integrity:
• Software integrity has become increasingly important in the age of
cyberterrorists and hackers.
• Attacks can be made on all three components of software: programs, data, and
documentation.
• To measure integrity, two attributes must bedefined:
• threat andsecurity.

• Usability:
• If a program is not easy to use, it is often doomed to failure, even if the
functions that
it performs arevaluable
 Metrics For Software Quality
Defect Removal Efficiency:
Defect removal efficiency provides benefits at both the project and
processlevel

It is a measure of the filtering ability of

quality activities as there are assurances
applied throughout all process framework
activities
It indicates the percentage of software errors
found before software release
It is defined as DRE = E / (E +D)
 Integrating Metrics Within The SoftwareProcess
Establishing a Baseline:-
• By establishing a metrics baseline, benefits can be obtained at thesoftware process,
product, and project levels
• The same metrics can serve many masters
• The baselineconsists of data collected from past software development
projects.
Baselinedata must have the following attributes
Data must be reasonably accurate (guesses should be avoided)
Data should be collected foras many
projectsas possible
Measures must be consistent (e.g., a line of
code must beinterpretedconsistently
across allprojects)
Pastapplicationsshould be similar to the work
that is to beestimated.

Metrics Collection, Computation, and Evaluation

• Data collection requires an historical
investigation of past projects to reconstruct
required data
• After data is collected and metrics are computed, the metrics should be evaluated and
 Integrating Metrics Within The SoftwareProcess
Software Metrics Baseline Process
Software
Engineeri
ng
Process
Measur
Data es
Softwa
Collection
re
Projec
Metric
t
Metrics s
Computation
Softwar
e
Produ Indicato
ct Metrics rs
Evaluation
 Metrics For Small Organizations
• Most software organizations have fewer than 20 software engineers.
• It is reasonable to suggest that software organizations of all sizes measure
and then use the resultant metrics to help improve their local software
process and the quality and timeliness of the products they produce.
• A commonsense approach to the implementation of any software process-
related activity is: keep it simple, customize to meet local needs, and be
sure it adds value.
Asmall organization might select the following set of easily collected
measures:
• Time (hours or days) elapsed from the time a request is made until
evaluation is
complete, tqueue.
• Effort (person-hours) to perform theevaluation,Weval.
• Time (hours or days) elapsed from completion of evaluation to assignment
of
change order to personnel, teval.
 Metrics For Small Organizations
Effort (person-hours) required to make thechange, Wchange.

Time required (hoursor days) to make the change, tchange.

Errorsuncovered during work to make change,Echange.

Defects uncovered after change is released to the customer base,

Dchange.

The defect removal efficiency can becomputed as

DRE can be compared to elapsed time and total effort to determine the impact
of
quality assurance activities on the time and effort required to make a change.
 Establishing a software metrics
The Software Engineering Institute has developed a comprehensive guidebook
for establishing a ―goal-drivenǁsoftware metrics program.
The guidebook suggests the following steps:
• Identify businessgoal
• Identify what you wantto know
• Identifysubgoals
• Identify subgoal entities andattributes
• Formalize measurement goals
• Identify quantifiablequestions and indicators related to subgoals
• Identifydata elements needed to be collected to construct the
indicators definitions
• Define measures to be used and create operational for
them.
• Identify actions needed to implement themeasures
• Preparea plan to implement the measures