Unit No 4 Slides Full

Software Engineering
Course Outline:
- Introduction to Software Engineering (SE)

- Software Process
- Software Requirements Analysis
√ Planning a Project
Planning a Software Project
Planning a Software Project
• Software development is a highly labor-intensive activity.
• The project turn into chaos if proper management controls are not
imposed.
• Proper management controls and checkpoints are required for
effective project monitoring.
• Controlling the development, ensuring quality, satisfying the

constraints of the selected process model all require careful
management of the project.
Planning a Software Project(contd.)
Basic goal of planning is
To look into the future, identify the activities that need to be done to
complete the project successfully, and plan the scheduling and
resource allocation for these activities.
• For successful project, both good project management and good

engineering are essential. Lack of either once can cause a project to
fail.
Input to the planning activity: SRS
Output of the planning activity: Project Plan
Good Plan is flexible enough to handle the unforeseen events.
The major issues the project plan addresses are:

- Cost Estimation
- Schedule and Milestone Determination
- Personnel Plan
- Software Configuration Management Plans
- Software Quality Assurance Plans
- Project Monitoring Plans
- Risk Management
Planning a Software Project (contd.)
Project Estimation Techniques:
Main techniques of estimating project parameters:
 Empirical Estimation Techniques
 Heuristic Technique
 Analytical Estimation Technique

Three main techniques of estimating project parameters:
 Empirical Estimation Techniques


Based on making educated guess of the project parameters using past experience.
• Expert Judgement
• Delphi Technique

• Expert Judgement
 An expert makes an educated guess at the problem size after analyzing the
problem.
 Subject to human errors and individual bias.
 Expert may overlook some factors inadvertently.
 Expert may not have experience and knowledge of all aspects of a project.
• Delphi Cost Estimation
 Team – comprising of a group of experts and coordinator.
 Coordinator provides each estimator with a copy of SRS and a form for
recording their cost estimate.
 Estimator completes their estimates anonymously.
 Coordinator prepares and distributes a summary of responses of estimators,
and include any unusual rationale notes by any of the estimators.
 No discussion among the estimator is allowed.
 The process repeats.
 Heuristic Technique
Project parameters can be modelled using a mathematical expression.
Three class of models:
• Static Single Variable Model
• Static Multi-Variable Model
• Dynamic Multi-variable Model

 Analytical Estimation Technique

Derive the required results based upon certain basic assumption regarding the
project.
• Halstead’s Software Science

 Analyze the program to give result.
 Not useful for planning.
 Useful for estimating software maintenance efforts.

- Cost Estimation
- Personnel Plan
- Risk Management
- Cost Estimation
- Personnel Plan
- Risk Management
Planning a Software Project (contd.):
Cost Estimation
Heuristic Technique of project parameter estimation.
Project parameters can be modelled using a mathematical expression.
Basic idea of having a model or procedure for cost estimation is that it reduces the
problem of estimation to estimating or determining the value of the “key
parameters” that characterize the project, based on which the cost can be estimated.
The primary factor that controls the cost is the SIZE of the project, i.e., the larger the
project, the greater the cost and resource requirements.
The other factors that affect the cost include programmer ability, experience of the
developers in the area, complexity of the project , and reliability requirements.
Planning a Software Project (contd.): Cost Estimation
Uncertainties in Cost Estimation:
Cost estimation with

Complete Knowledge
The model may be:

 Static - a unique variable is taken as a key element for calculating all
others. Say size.
 Dynamic - all variables are interdependent and there is no basic

variable as in the static model.
• Single Variable Model – A Model makes use of a single basic variable to calculate all
others.
• Multi-Variable Model - A Model makes use of several variable to calculate all

others.
• Top-Down Approach: From Overall Effort Distribution to Phase-wise Effort

Distribution.
• Bottom-Up Approach: From Phase-wise Effort Distribution to Overall Effort Distribution.
Barry Boehm introduces a hierarchy of software estimation models bearing the

name COCOMO.
COnstructive COst MOdel
[COCOMO]
Proposed in 1970 and is based on the study of 63 projects.
COCOMO is a regression model based on LOC, i.e., number of Lines Of Code.

Planning a Software Project (contd.): COnstructive COst MOdel
[COCOMO]
The COCOMOs are defined for three classes of software projects:
• Organic Mode
• Semi-detached Mode
• Embedded Mode
• Organic Mode
 The team size required is adequately small.
 The team members have a nominal experience regarding the problem.
 The problem is well understood and has been solved in the past.
 Example – Application Software
[COCOMO]
• Embedded Mode
 The software project that requiring the highest level of complexity, creativity and
experience requirement fall under this category.
 Requires larger team size.
 Developers need to be sufficiently experienced and creative to develop such a
complex models.
 Example – System Programs
• Semi-detached Mode
 Team size, experience, knowledge of the various programming environment lie in
between above two modes.
 Comparatively less familiar and difficult to develop compared to organic ones.
 Example – Utility Software
[COCOMO]
Modes of Development
Parameters Organic Mode Semi-detached Mode Embedded Mode

Size 2-50 KLOC 50-300 KLOC > 300 KLOC
Team Size Small Medium Large
Developer’s Experience Experienced developer Average Experience Very little previous
needed experience
Environment Familiar Less Familiar New
Innovation Required Little Medium Major
Deadline Flexible Medium Tight
Example Application Software Utility Software System Software
[COCOMO]
Boehm’s hierarchy of models takes the following form:
• Model 1: Basic COCOMO
• Model 2: Intermediate COCOMO
• Model 3: Advanced/Detailed COCOMO

[COCOMO]
• Model 1: Basic COCOMO
Computes software development effort (and cost) as a function of program size
expressed in estimated lines of code.

Computes software development effort (and cost) as a function of program size and
set of “cost drivers” that include subjective assessments of product, hardware,
personnel and project attributes.
This model incorporates all characteristics of the intermediate version with an

assessments of the cost drivers impact on each step (Analysis, Design etc.) of the
software engineering process.
[COCOMO]
Cost Driver Attributes is grouped into four major categories:
Product Attributes Computer Attributes Personnel Attributes Project Attributes

RELY TIME ACAP MODP
(required reliability) (execution time constraints) (analyst capability) (modern programming
practices)
DATA STOR AEXP TOOL
(database size) (main storage constraints) (application experience) (use of software tools)
CPLX VITR PCAP SCHED
(product complexity) (virtual machine volatility) (programmer capability) (development schedule)
TURN VEXP
(computer turnaround time) (virtual machine experience)
LEXP
(programming language
experience)
[COCOMO]
Rated on a six-point scale that ranges from “very-low” to “extra-high”:
Very-Low | Low | Nominal | High | Very-High | Extra-High
(1.0)
[COCOMO]
Model 1: Basic COCOMO
𝐸 = 𝑎 (𝐾𝐿𝑂𝐶)𝑏
where, ‘E’ is the initial effort in person-months,

KLOC is thousand of lines of code,
‘a’ and ‘b’ are coefficients to be determined based on different classes of
project.
Class of Project a b
Organic 2.4 1.05
Semi-detached 3.0 1.12
Embedded 3.6 1.20
[COCOMO]
Model 1: Basic COCOMO Example
Assume that the size of an organic type software product has been estimated to be
32,000 lines of source code. Determine the effort required to develop the software
product
Organic 2.4 1.05
Embedded 3.6 1.20
32,000 lines of source code = 32 KLOC
= 2.4 (32)1.05
= 91 PM
[COCOMO]
Person-Month Curve
Effort estimation is expressed in units of person-months (PM).
An effort of 100 PM does not imply that 100 persons should work for 1 month.
An effort of 100 PM does not imply that 1 person should be employed for 100 months.
It denotes the area under the person-month curve.

[COCOMO]
STEP 1: Obtain an initial estimate of the development effort from the estimate
of KLOC.
STEP 2: Determine a set of 15 multiplying factors from different attributes of the
project (Cost Drivers).
𝐸𝐴𝐹 = Product of all Effort Multipliers
STEP 3: Adjust the effort estimate by multiplying the initial estimate with all the
multiplying factors.
𝐸 = 𝑎 (𝐾𝐿𝑂𝐶)𝑏 * EAF
[COCOMO]
Model 2: Intermediate COCOMO Example
Assume that the size of an semi-detached software product has been estimated to
be 32,000 lines of source code. The project is mission critical whose reliability is high.
Determine the effort required to develop the software product
STEP 1: STEP 2: STEP 3:
𝐸=𝑎 (𝐾𝐿𝑂𝐶)𝑏 RELY = High = 1.15 𝐸 = 𝑎 (𝐾𝐿𝑂𝐶)𝑏 * EAF
= 3.0 (32)1.12 All others = Nominal = 1.0 = 145 ∗ 1.15

= 146 PM EAF = 1.0 * 1.15 = 1.15 = 168 PM
[COCOMO]
Major shortcoming of both the Basic and Intermediate COCOMO models is that they
consider a software product as a single homogeneous entity.
Most large system are made up of Several Smaller Sub-systems.
These sub-systems may have widely different characteristics:

 Some sub-systems may be organic.
 Some sub-systems may be semi-detached, and
 Some sub-system may be embedded.
 Cost driver value may vary for different sub-systems.
[COCOMO]
Incorporates all characteristics of the intermediate model with an assessment of the
cost driver’s impact on each step of the software engineering process.
It Uses different phase-sensitive effort multipliers for each cost driver attributes.
STEP 1: Divide whole software into different modules.
STEP 2: Apply COCOMO in different modules to estimate effort using

intermediate model.
STEP 3: Sum the effort of all modules.
Model 3: Advanced/Detailed COCOMO Example
Suppose a system for office automation must be designed. From the requirements it was clear that there will be
four major modules in the system: Data Entry, Data Update, Query and Report generation. It is also clear from
the requirement that this project will fall in the organic category. The size of the different modules and the
overall system were estimated to be:
Data Entry – 0.6 KLOC
Data Update – 0.6 KLOC
Query – 0.8 KLOC
Reports – 1.0 KLOC
TOTAL: 3.0 KLOC
The rating of the different cost driver attributes were assessed as:
Complexity : High (1.15) - Data Update, Query
Storage : High (1.06) - Data Update
Experience : Low (1.13) - Data Entry, Data Update, Query, Reports
Programmer Capability : Low (1.17) - Data Entry, Data Update, Query, Reports
Others : Nominal (1.0)
Model 3: Advanced/Detailed COCOMO Example
STEP 1:
Data Entry Module Data Update Module
EAF = 1.13*1.17*1 = 1.3221 EAF = 1.15*1.06*1.13*1.17 = 2.4 (3)1.05 =7.60656 PM
= 1.6116
𝐸 = 2.4 (0.6)1.05 * 1.3221
= 1.8558 PM 𝐸 = 2.4 (0.6)1.05 * 1.6116 STEP 2:
= 2.2622 PM EAF = 1.15*1.06*1.13*1.17
= 1.6116
Query Module Report Generation Module
STEP 3:
EAF = 1.15*1.13*1.17 = 1.52 EAF = 1.13 * 1.17 = 1.3221
𝐸 = 𝑎 (𝐾𝐿𝑂𝐶)𝑏 * EAF
𝐸 = 2.4 (0.8)1.05 * 1.52 𝐸 = 2.4 (1.0)1.05 * 1.3221 = 7.60656 ∗ 1.6116
= 2.886 PM = 3.173 PM = 12 PM
Total Effort Distribution: 1.8558 + 2.2622 + 2.886 + 3.173 = 10 PM

Top-Down Approach: From Overall Effort Distribution to Phase-wise Effort Distribution.
Suppose a system for office automation must be designed. From the requirements it was clear that there will be
four major modules in the system: Data Entry, Data Update, Query and Report generation. It is also clear from
the requirement that this project will fall in the organic category. The size of the different modules and the
overall system were estimated to be:
Data Entry – 0.6 KLOC
Data Update – 0.6 KLOC
Query – 0.8 KLOC
Reports – 1.0 KLOC
TOTAL: 3.0 KLOC
The rating of the different cost driver attributes were assessed as:
Complexity : High (1.15)
Storage : High (1.06)
Experience : Low (1.13)
Programmer Capability : Low (1.17)
Others : Nominal (1.0)
Top-Down Approach:
EAF = 1.15*1.06*1.13*1.17 = 1.61
𝐼𝑛𝑖𝑡𝑖𝑎𝑙 𝐸𝑓𝑓𝑜𝑟𝑡 (𝐸) = 𝑎 (𝐾𝐿𝑂𝐶)𝑏 = 2.4 (3)1.05 =7.61 PM
𝐴𝑑𝑗𝑢𝑠𝑡𝑒𝑑 𝐸𝑓𝑓𝑜𝑟𝑡 (𝐸) = 𝑎 (𝐾𝐿𝑂𝐶)𝑏 * EAF = 7.61*1.61 = 12.25 PM
Percentage of effort distribution:

Phase Small (2KLOC) Intermediate (8KLOC) Medium (32 KLOC) Large (120 KLOC)
Product Design 16 16 16 16
Detailed Design 26 25 24 23
Code & Unit Test 42 40 38 36
Integration & Test 16 19 22 25
To obtain the percentage of total effort consumed in different phase, we will have to use
interpolation to get the appropriate percentage as the office automation system’s size is
3KLOC (i.e., more than 2 and less than 8KLOC).
Top-Down Approach:
The percentage of total effort consumed in different phases are:
Phase Small (2KLOC) Office Automation Intermediate (8KLOC)
System (3KLOC)
Product Design 16 16.00 16
Detailed Design 26 25.83 25
Code & Unit Test 42 41.66 40
Integration & Test 16 16.50 19
The percentage of total effort consumed in different phases are:

Phase
Product Design = 0.16 * 12.25 = 1.96 PM
Detailed Design = 0.2583 * 12.25 = 3.16 PM
Code & Unit Test = 0.4166 * 12.25 = 5.10 PM
Integration & Test = 0.165 * 12.25 = 2.02 PM
Effort vs Product Size
The effort is somewhat super linear in the size of the software product. Thus, the effort
required to develop a product increases very rapidly with project size.
COnstructive COst Model - 2

COnstructive COst Model - 2
The present day software projects are much larger in size and reuse of existing
software to develop new products has become pervasive.
This has given rise to Component-based Development.
Most of the present day software is highly interactive and has elaborate graphical
user interface (GUI).
Boehm proposed COCOMO-2 to handle this changes.

Planning a Software Project (contd.): COnstructive COst Model - 2
COCOMO-2 provides three increasingly detailed cost estimation models. These can be
used to estimated project costs at different phases of the software:
• Application Composition Estimation Model
Can be used to estimate cost for prototyping e.g., to resolve user interface issues.
Creating early estimates during prototype stage.
• Early Design
This supports estimation of cost at the architectural design stage.
Making estimates after the requirements are captured, during the early design stage.
• Post-Architectural Stage
This provides cost estimation during detailed design and coding stage.
Making estimates after the design is complete and coding has started.
Application Composition Estimation Model
• Based on counting the number of screens, reports and 3GL modules.
• They are considered to be an OBJECT used to compute the OBJECT POINTS of the
application.
Effort is estimated as:
STEP 1: Estimate the number of screens, reports and 3GL components from an
analysis of the SRS.
STEP 2: Determine the complexity level of each screen and report, and rate
these as either SIMPLE, MEDIUM or DIFFICULT.
The complexity of a screen and report is determine by the number of

tables and views it contains.
SCREEN Complexity Assignments:

No. of Views Tables < 4 Tables < 8 Tables >= 8
<3 Simple Simple Medium
3–7 Simple Medium Difficult
>8 Medium Difficult Difficult
REPORT Complexity Assignments:

No. of Sections Tables < 4 Tables < 8 Tables >= 8
0 or 1 Simple Simple Medium
2 or 3 Simple Medium Difficult
4 or more Medium Difficult Difficult
Table of Complexity Weights:

Object Type Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
3 GL Component - - 10
The weights are supposed to corresponds to the amount of effort required to

implement an instance of an object at the assigned complexity class.
STEP 3: Determine the number of object points.
Add all the assigned complexity values for the object instances together – the Object Count.
STEP 4: Estimate percentage of reuse expected in the system. Then, evaluate New
Object Point Count (NOP).
𝑂𝑏𝑗𝑒𝑐𝑡 𝑃𝑜𝑖𝑛𝑡𝑠 100 − 𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑎𝑔𝑒 𝑜𝑓 𝑟𝑒𝑢𝑠𝑒
𝑁𝑂𝑃 =
100
STEP 5: Determine a Productivity Rate.

𝑁𝑂𝑃
𝑃𝑅𝑂𝐷 =
𝐸
The productivity depends on the experience of the developers as well as maturity of the CASE
environment used.
Developer’s Experience & Capability Very Low Low Nominal High Very High
CASE Maturity Very Low Low Nominal High Very High
PROD 4 7 13 25 50
STEP 6: The Effort is computed as

𝑁𝑂𝑃
𝐸=
𝑃𝑅𝑂𝐷
• Early Design
𝐸𝑓𝑓𝑜𝑟𝑡 = 𝑎 ∗ 𝐾𝐿𝑂𝐶 𝑏 ∗ 𝑐𝑜𝑠𝑡𝑑𝑟𝑖𝑣𝑒𝑟𝑖
𝑖
Where, Seven Cost drivers are there in 7 point scale.
• Post-Architectural Stage
𝐸𝑓𝑓𝑜𝑟𝑡 = 𝑎 ∗ 𝐾𝐿𝑂𝐶 𝑏 ∗ 𝑐𝑜𝑠𝑡𝑑𝑟𝑖𝑣𝑒𝑟𝑖

𝑖
Where, Seventeen Cost drivers are there in 7 point scale.

Application Composition Estimation Model - Example
Estimate the effort required to build software for a simple ATM that produces 12 screens, 10 reports
and will require approx. 80% of new software components. Assume simple complexity and average
developer/environment maturity.
Given: STEP 1: STEP 2: STEP 3:

Object Count Complexity Weight Factor Total Objects
Screen 12 Simple 1 12
Report 10 Simple 2 20
3GL Component 0 NA NA 0
TOTAL OBJECT POINTS 32
STEP 4:
32 100 − 20
𝑁𝑂𝑃 = = 25.6 object points
100
Application Composition Estimation Model - Example
STEP 5: Productivity Rate
𝑃𝑅𝑂𝐷 = Average (Nominal) = 13
STEP 6:
𝑁𝑂𝑃 25.6
𝐸= = = 1.96 PM
𝑃𝑅𝑂𝐷 13
- Cost Estimation
- Personnel Plan
- Risk Management
Project Schedule
The goal of schedule estimation is to determine the total duration of the project and
the duration of the different phases.
Various schedules are possible, depending on the number of resources (people) put
on the project.
The communication time increases with the square of the number of staff. That is
by increasing the staff for a project we may actually increase the time spent in
communication.
Once we have the estimates of the effort and time requirement for the different
phases, a schedule for the project can be prepared.
Planning a Software Project (contd.): Development Time
For the three classes of software products, the formulas for estimating the
development time based on the effort are give below:
𝐷 = 𝑎 (𝐸)𝑏
where, ‘D’ is the estimated development Time to develop the software, expressed in months,
‘E’ is initial effort in person-months,
‘a’ and ‘b’ are coefficients to be determined based on different classes of project.
Organic 2.5 0.38
Embedded 2.5 0.32
Project Schedule vs Product Size
The development time is a sub-linear function of the size of the software product. Thus,
when the size of product increases by two times, the time to develop the product does
not double but rises moderately.
Example – 1:
Assume that the size of an organic type software product has been estimated to be
32,000 lines of source code. Assume that the average salary of software engineers be
Rs. 15,000/- per month. Determine the effort and cost required to develop the
software product and the nominal development time.
𝐸 = 𝑎 (𝐾𝐿𝑂𝐶)𝑏 = 2.4 (32)1.05 = 91 PM
𝐷 = 𝑎 (𝐸)𝑏 = 2.5 (91)0.38 = 14 𝑚𝑜𝑛𝑡ℎ𝑠
Cost required to develop the product = 14 * 15000 = Rs. 2,10,000/-

Example – 2:
A project size of 200 KLOC is to be developed. Software development team has
average experience on similar types of projects. The project schedule is not very tight.
Calculate the effort, development time, average staff size, and productivity of the
project.
The semi-detached mode is the most appropriate mode, keeping in view the size,
schedule and experience of development time.
𝐸 = 𝑎 (𝐾𝐿𝑂𝐶)𝑏 = 3.0 (200)1.12 = 1133.12 PM
𝐷 = 𝑎 (𝐸)𝑏 = 2.5 (1133.12)0.38 = 29.3 𝑚𝑜𝑛𝑡ℎ𝑠

𝐸 1133.12
𝐴𝑣𝑒𝑟𝑎𝑔𝑒 𝑆𝑡𝑎𝑓𝑓 𝑆𝑖𝑧𝑒 𝑆𝑆 = 𝑃𝑒𝑟𝑠𝑜𝑛𝑠 = = 38.67 𝑃𝑒𝑟𝑠𝑜𝑛𝑠
𝐷 29.3
𝐾𝐿𝑂𝐶 200
𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑣𝑖𝑡𝑦 𝑃 = = = 0.1765 𝐾𝐿𝑂𝐶/𝑃𝑀 = 176 LOC/PM
𝐸 1133.12
Planning a Software Project (contd.): Project Schedule
A project is a collection of tasks that must be completed in minimum time or at

minimal cost.
Objectives of Project Scheduling

• Completing the project as early as possible by determining the earliest start and
finish of each activity.
• Calculating the likelihood a project will be completed within a certain time period.
• Finding the minimum cost schedule needed to complete the project by a certain
date.
• Investigating the results of possible delays in activity’s completion time.
• Progress control.
• Smoothing out resource allocation over the duration of the project.
Identifying the Activities of a Project
• To determine optimal schedules we need to
• Identify all the project’s activities.
• Determine the precedence relations among activities.
• Based on this information we can develop managerial tools for project
control.
Example:
• ABC Computers manufactures personal computers.
• It is about to design, manufacture, and market the ABC2019 and
ABC2020 computer.
Example:
• ABC Computers manufactures personal computers.
• It is about to design, manufacture, and market the ABC2019 and
ABC2020 computer.
There are three major tasks to perform:

• Manufacture the new computer.
• Train staff and vendor representatives.
• Advertise the new computer.
ABC needs to develop a precedence relations chart.

The chart gives a concise set of tasks and their immediate predecessors.
Activity Description
A Prototype model design
B Purchase of materials
Manufacturing C Manufacture of prototype model
Activities D Revision of design
E Initial production run
F Staff training
Training Activities G Staff input on prototype models
H Sales training
Advertising Activities I Pre-production advertising campaign
J Post-redesign advertising campaign
Precedence Relationships Chart
Immediate Estimated
Activity Predecessor Completion Time
A None 90
B A 15
C B 5
D G 20
E D 21
F A 25
G C,F 14
H D 28
I A 30
J D,I 45
Activity A is an immediate predecessor of activity B,

B
because it must be competed just prior to the commencement of B.
PERT/CPM approach to project scheduling
PERT: Program Evaluation and Review Technique

CPM: Critical Path Method
• The PERT/CPM approach to project scheduling uses network presentation of the

project to
• Reflect Activity Precedence Relations
• Activity Completion Time
• PERT/CPM is used for scheduling activities such that the project’s completion
time is minimized.
• Management at ABC would like to schedule the activities so that the project is
completed in minimal time.
• Management wishes to know:

• The earliest and latest start times for each activity which will not alter the earliest
completion time of the project.
• The earliest finish times for each activity which will not alter this date.
• Activities with rigid schedule and activities that have slack in their schedules.
Earliest Start Time / Earliest Finish Time
• Make a forward pass through the network as follows:

• Evaluate all the activities which have no immediate predecessors.
• The earliest start for such an activity is zero ES = 0.
• The earliest finish is the activity duration EF = Activity duration.
• Evaluate the ES of all the nodes for which EF of all the immediate
predecessor has been determined.
• ES = Max EF of all its immediate predecessors.
• EF = ES + Activity duration.
• Repeat this process until all nodes have been evaluated
• EF of the finish node is the earliest finish time of the project.
Immediate Estimated
Earliest Start Time / Earliest Finish Time A None 90
B A 15
C B 5
D G 20
E D 21
F A 25
90,105 105,110 170
149,170 G C,F 14
H D 28
BB C
C EE I
J
A
D,I
30
45
15 5 21
110,124
0,90 90,115 115,129 129,149 177
149,177
A
A FF G
G D
D HH 194
90 25 14 20 28
EARLIEST FINISH
90,120 194
149,194
120,165
II JJ
30 45
Latest start time / Latest finish time
• Make a backward pass through the network as follows:
• Evaluate all the activities that immediately precede the finish node.
• The latest finish for such an activity is LF = Minimal Project Completion Time.
• The latest start for such an activity is LS = LF - Activity Duration.
• Evaluate the LF of all the nodes for which LS of all the immediate
successors has been determined.
• LF = Min LS of all its immediate successors.
• LS = LF - Activity duration.
• Repeat this process backward until all nodes have been evaluated.
Immediate Estimated
A None 90
Latest start time / Latest finish time B

C
D
A
B
G
15
5
20
E D 21
F A 25
149,170 G C,F 14
H D 28
105,110 173,194 I A 30
90,105 J D,I 45
B C 110,115 E
95,110 B C E
15 5 21
90,115 115,129 129,149 149,177

5,95 90, 115 129,149
115,129 129,149
153,173 166,194
0,90 129,149 146,166 H
A 0,90 F G 129,149 D
A F G 129,149 20 D H 194
90 25 14 129,149 28
129,149
129,149
129,149
29,119
149,194
90,120
149,194
119,149
I J
I J
45
30
Slack Times
• Activity start time and completion time may be delayed by planned reasons as well as by
unforeseen reasons.
• Some of these delays may affect the overall completion date.
• To learn about the effects of these delays, we calculate the SLACK TIME, and form the
CRITICAL PATH.
• Slack time is the amount of time an activity can be delayed without delaying the project
completion date, assuming no other delays are taking place in the project.
Slack Time = LS - ES = LF - EF
Immediate Estimated
A None 90
Latest start time / Latest finish time B

C
D
A
B
G
15
5
20
E D 21
F A 25
149,170 G C,F 14
H D 28
105,110 173,194 I A 30
90,105 J D,I 45
B C 110,115 E
95,110 B C E
15 5 21
90,115 115,129 129,149 149,177

90,115 115,129 129,149 166,194
0,90
A 0,90 F G D H
A F G D H 194
90 25 14 20 28
149,194
90,120
149,194
119,149
I J
I J
45
30
Slack Times
Activity LS - ES Slack
A 0 -0 0
B 95 - 90 5
C 110 - 105 5
D 119 - 119 0 Critical activities
E 173 - 149 24
must be rigidly
F 90 - 90 0
G 115 - 115 0 scheduled
H 166 - 149 17
I 119 - 90 29
J 149 - 149 0
Critical Path
• The critical path is a set of activities that have no slack, connecting the START
node with the FINISH node.
• The critical activities (activities with 0 slack) form at least one critical path in
the network.
• A critical path is the longest path in the network.
• The sum of the completion times for the activities on the critical path is the
minimal completion time of the project.
Critical Path
90,105 105,110 149,170
95,110 B C 110,115 173,194 E
B C E
15 5 21
0,90 90,115 115,129 129,149 149,177

0,90 90, 115 115,129 129,149 166,194
A F G D H
A F G D H
90 25 14 20 28
149,194
90,120
149,194
119,149
I J
I J
45
30
Possible Delays
• We observe two different types of delays:
• Single Delay
• Multiple Delays
• Under certain conditions the overall project completion time will be delayed.
Single Delay
CASE 1: A delay of a certain amount in a CRITICAL ACTIVITY, causes the entire project to be
delayed by the same amount.
CASE 2: A delay of a certain amount in a NON-CRITICAL ACTIVITY will delay the project by the
amount the delay exceeds the slack time. When the delay is less than the slack, the entire
project is not delayed.
Case 1 (Single Delay): Delay on Critical Activities
Activity D delayed by 10 days.
B C E
15 5 21
ES=129
DELAYED START=129+10 = 139
LS=129
A F G D H
90 25 14 20 28
THE PROJECT COMPLETION TIME IS DELAYED BY 10 DAYS

I J 149,194
30 45
159,204
Case 2 (Single Delay): Delay on Non-Critical Activities
105,110 SLACK TIME = 110 - 105 = 05

110,115
B C E
15 5 21
A F G D H
90 25 14 20 28
I J
30 45
Case 2 (Single Delay): Delay on Non-Critical Activities
Activity C delayed by 02 days. SLACK TIME = 110 - 105 = 05
105,110 107,112
110,115 110,115
B C E
15 5 21
0, 90 90,115 115,129
0, 90 90,115 115,129
A F G D H
90 25 14 20 28
THE PROJECT COMPLETION TIME IS NOT DELAYED

I J
30 45
Possible Delays
• We observe two different types of delays:
• Single Delay
• Multiple Delays
CASE 1: A delay of a certain amount in activities on the DIFFERENT PATHS, the entire project is
not delayed.
CASE 2: A delay of a certain amount in activities on the SAME PATH and SEPARATED BY CRITICAL
ACTIVITIES, the entire project is not delayed.
CASE 3: A delay of a certain amount in activities on the SAME PATH and not SEPARATED BY
CRITICAL ACTIVITIES, the entire project will be delayed.
Case 1 (Multiple Delays): Activities on Different Paths
ES=149
DELAYED START=149+15=164
B C LS=173 E 149,170
173,194
15 5 21
A F G D H
90 25 14 20 28
Activity E and I are each delayed 15 days.
90,120
I 119,149 J
149,194
ES=90 30 45 149,194
DELAYED START=90+15 =105
LS =119
Case 2 (Multiple Delays): Activities are on the Same Path, separated by Critical Activities
ES=90 ES=149
DELAYED START =94 DELAYED START=149+15 =164
LS =95 LS =173
105,110
90,105 B C 149,170 E
110,115
95,110 173,194
15 5 21
90,115
90,115 115,129
F G 115,129 D H
A
90 25 14 20 28
Activity B is delayed 4 days, activity E is delayed 15 days
I J
30 45
Case 3 (Multiple Delays): Activities are on the Same Path, not separated by Critical Activities
ES= 90 3 DAYS DELAY

DELAYED START =94 IN THE ENTIRE
DELAYED START= PROJECT
DELAYED FINISH =
109 + 4 =113;
94+15=109
B C LS =110 E
15 5 21
90,105 105,110
95,110 110,115
90,115
90,115 115,129
F G 115,129 D H
A
90 25 14 20 28
Activity B is delayed 4 days; Activity C is delayed 4 days.
THE PROJECT COMPLETION TIME IS DELAYED 3 DAYS

I J
30 45
Determination of Time to Complete each Activity
There is always a great deal of uncertainty associated with the activity durations of any project.
The estimated time is better described by a probability distribution than by a single estimate.
Three time estimates are made as follows:

1) Optimistic Time Estimate (to): Shortest possible time in which an activity can be completed in ideal conditions.
No provisions are made for delays or setbacks while estimating this time.
2) Most Likely Time (tm): It assumes that things go in normal way with few setbacks.
3) Pessimistic Time (tp): The maximum possible time if everything go wrong & abnormal situations prevailed.
However, major catastrophes such as earthquakes, labor troubles, etc. are not taken into account.
Expected time (mean time) for each activity can be approximated using the weighted average i.e.
Expected Time (te) = (to + 4tm + tp)/6

Gantt Charts
• Gantt charts are used as a tool to Monitor and Control the project progress.
• A Gantt Chart is a Graphical Presentation that displays activities as follows:
• Time is measured on the horizontal axis.
• A horizontal bar is drawn proportionately to an activity’ s expected completion time.
• Each activity is listed on the vertical axis.

90
105
90
A 115
15
129
B 5 194
149
C 20
D Immediate
Immediate Estimated
Estimated
21 194
Activity
Activity Predecessor
Predecessor Completion
CompletionTime
Time
E
A None 90 25
F B A 15
C B 5 14
G D G 20 28
E D 21
H
F A 25 30
I G C,F 14 45
H D 28
J I A 30
J D,I 45
Immediate Estimated
90 A
B
None
A
90
15
105 C
D
B
G
5
20
90 E D 21
A 115 F A 25
G C,F 14
15
129 H
I
D
A
28
30
B 5 194 J D,I 45
149
C 20
D 194
21
Gantt chart demonstration of
E
the (no) effects on the project 25 Activity E
F completion time when delaying 14
G
activity “I” and “E” by 15 days.
28
H
30
I Activity I 45
J
Gantt Charts - Monitoring Project Progress
• Gantt chart can be used as a visual aid for tracking the progress of project
activities.
• Appropriate percentage of a bar is shaded to document the completed work.
• The manager can easily see if the project is progressing on schedule (with
respect to the earliest possible completion times).
90 Immediate Estimated
A 15 A None 90
B A 15
B C B 5
5 D G 20
194 E D 21
C 20 F A 25
D
The shaded bars represent G
H
C,F
D
14
28
E
completed work BY DAY 135. 21 194 I
J
A
D,I
30
45
25
F Activity LS - ES Slack
14 A 0 -0 0
G B 95 - 90 5
28 C 110 - 105 5
H Do not conclude that the D 119 - 119 0
30
project is behind schedule. E
F
173 - 149
90 - 90
24
0
I 45 G 115 - 115 0
H 166 - 149 17
J Activity “I” has a slack and I 119 - 90 29
therefore can be delayed!!! J 149 - 149 0
135
- Cost Estimation
- Personnel Plan
- Risk Management
Personnel Plan
Once the project schedule is determined and the effort and schedule of different
phases and tasks are known, staff requirement can be obtained.
E = a (KLOC)b PM
Overall Size
Nominal Productivity P =
Initial Effort
Module Size
Initial Effort Required for Module =
Nominal Productivity
Planning a Software Project (contd.) Personnel Plan
Final Effort Estimate of Module = Initial Estimate of Module ∗ EAF
Final Effort Estimate of System = Final Effort Estimate of Modulei

i=1
How many people will be needed for the different activities at different times for the
duration of the project?
D = a (E)b months
E
Average Staff Size SS = Person
D
Planning a Software Project (contd.): Personnel Plan
The staff requirement for a project is small during the requirement and design, the
maximum during implementation and testing, and drop again during the final phase
of integration and testing.
A method of producing the PERSONNEL PLAN is:
• Make it a calendar-based representation, containing all the months in the duration

of the project.
• For each of the different tasks identified and for which cost and schedule estimates
are prepared, list the number of people needed in each month.
• The total effort for each month and the total effort for each activity can easily be
computed from this plan.
Resource Histogram
Team Structure
The structure of the team has a direct impact on the product quality and project
productivity.
Three basic philosophies have evolved for organizing a team:
 Egoless Teams
 Chief Programmer Team
Controlled Decentralized Team

Team Structure: Egoless Teams
Consist of ten or fewer programmers.
The goals/objectives of the group are set by consensus, and input from every
member is taken for major decisions.
A group leadership rotates among the group members. Due to its nature, egoless
teams are sometimes called DEMOCRATIC TEAM.
The structure results in many communication paths between people.
The structure is well-suited for long-term research-type projects that do not have
time constraints.
Not suitable for regular tasks that are not too complex and that have time
constraints.
Team Structure: Chief Programmer Team
A chief-programmer team has a hierarchy.
It consists of a Chief Programmer, who has a Backup Programmer, a Program

Librarian, and some Programmers.
The chief programmer is essential for all major technical decisions of the project. He
does most of the designs, and he assigns coding of the different part of the design to
the programmers.
The backup programmer uses the chief programmer makes technical decisions, and
takes over the chief programmer if the chief programmer drops sick or leaves.
The program librarian is vital for maintaining the documentation and other
communication-related work.
This structure considerably reduces interpersonal communication.
The structure is well-suited for smaller projects with simple solutions that strict
deadlines.
Team Structure: Controlled Decentralized Team
Combines the strength of the democratic and chief programmer teams.
Consists of project leaders who have a class of senior programmers under him, while
under every senior programmer is a group of a junior programmer.
The group of a senior programmer and his junior programmers behave like an ego-less
team, but communication among different groups occurs only through the senior
programmers of the group.
The senior programmer also communicates with the project leader.
Such a team has fewer communication paths than a democratic team but more paths
compared to a chief programmer team.
This structure works best for large projects that are reasonably straightforward. It is
not well suited for simple projects or research-type projects.
- Cost Estimation
- Personnel Plan
- Risk Management
Software Configuration Management Plans
SCM Plan should:
• Identify all the activities that must be performed.
• Give guidelines for performing the activities.
• Allocate resources for all identified activities.
• Specify the type of SCIs that will be selected and the stages during the project
where baselines should be established.
• Maintain library and versions.
• Identify the different members of the CCB.
• The forms (CR, FR) to be used, policies, procedures and tools for controlling the
changes.
• The plan for configuration accounting and auditing.
- Cost Estimation
- Personnel Plan
- Risk Management
Software Quality Assurance Plans (SQAP)
To ensure that the final product produced is of high quality.

Some quality control activities must be performed throughout the development.
Purpose of SQAP:
• Specify all the work products that need to be produced during the project.
• Specify the activities that need to be performed for checking quality of each of the
work products i.e., for identifying and removing defects.
• The tools and methods that may be used for SQA activities.
Planning a Software Project (contd.): Software Quality Assurance
Plans (SQAP)
Proper REVIEW and AUDITS are required.
The documents that should be produced during software development to enhance
software quality should also be specified by the SQAP.
Methods to be followed for SQA:
Verification and Validation (V&V)

Includes:
• The methods to be used for performing the V&V activities.
• The responsibilities and milestones for each activities.
• Inputs and Outputs for each V&V task.
• Criteria for evaluating the outputs are also specified.
Inspections and Reviews
Plans (SQAP)
Inspections and Reviews
IEEE defines inspection as:
“A formal evaluation techniques in which software requirements, design, or
code are examined in detail by a person or a group other than the author to
detect faults, violations of development standards, and other problems.”
Walkthrough: The author describes the work product in an informal meeting to his
peers or superiors to get feedback or inform or explain to them the work product.
Inspection: Is done by a group of peers, who first inspect the product privately and
then get together in a formal meeting to discuss potential defects found by
individuals and to detect more defects.
Plans (SQAP)
There are three reasons for having reviews or inspections:
• Defect Removal.
• Productivity Increase.
• Provide information for project monitoring.
Inspection Process:
The process should have entry criteria that determine if the inspection process is
ready to begin.
This prevents unfinished work products from entering the inspection process.
The entry criteria might be a checklist including items such as "The document has
been spell-checked".
Plans (SQAP)
Inspection Process:
The stages in the inspections process are: Planning: The inspection is planned by the
moderator.
Overview meeting: The author describes the
background of the work product.
Preparation: Each inspector examines the work
product to identify possible defects.
Inspection meeting: During this meeting the
reader reads through the work product, part by
part and the inspectors point out the defects for
every part.
Rework: The author makes changes to the work
product according to the action plans from the
inspection meeting.
Follow-up: The changes by the author are
checked to make sure everything is correct.
The process is ended by the moderator when it satisfies some predefined exit criteria.
Plans (SQAP)
Inspection Process:
Various roles in the inspections process are:
• Author: Prepare the module which is being inspected.

• Moderator: Plans the inspection and coordinates it.
• Reader: The person reading through the documents, one item at a time.
• Inspector: The person that examines the work product to identify possible defects.
• Recorder/Scribe: The person that documents the defects that are found during
the inspection.
- Cost Estimation
- Personnel Plan
- Risk Management
Project Monitoring Plans
Plan is nothing BUT execution of plan is everything.

To ensure that the plan is properly executed, and when needed, modify plan
appropriately.
On large projects, deviations from the original plan and changes to requirements
are both to be expected.
Methods to monitor a project:

Time Sheets Earned Value Method
Reviews Unit Development Folder
Cost-Schedule-Milestone Graph
Planning a Software Project (contd.): Project Monitoring Plans
Time Sheets
Used to track the progress of the project and the expenditure incurred on the project.
Records how much time different project members are spending on the different identified activities in
the project.
Can be filled daily or weekly.

Reviews
Provide a definite and clearly defined milestone.
The review schedule can be used to determine how the project is progressing compared to its planned
schedule.
The review reports indicate

• in which parts of the project the programmers/analysts are having difficulty.
• provide insight into the quality of the software being produced and the types of errors being
detected.
Cost-Schedule-Milestone Graph
Represents the planned cost of different milestones.
Also shows the actual cost of achieving the milestones gained so far.
Earned Value Method
Uses Summary Task Planning Sheet (STPS), which is a Gantt Chart with each task having an entry in the
chart.
Each task has the milestones: Design, Coding, Testing, Integration

Earned Value:
The total value earned can be determined by adding the earned value of all the completed
milestones of that task.
Each milestones of a task is assigned an earned value, which is the value (in Rs. or
PM), that will be “earned” on completion of this milestone.
The sum of the assigned values for all the milestones for a task is equal to the total
cost assigned to this task.
At any given time, the total effort (or cost) spent on a particular task can be
determined from the time sheets.
By comparing the earned value with the total cost spent, the project manager can
determine how far the project is deviating from the initial estimates and then take
the necessary actions.
Unit Development Folder
The project plan produced after the requirements are a macro-level plan.
Even if this plan is prepared meticulously and accurately, if proper control is not exercised at the
micro level (at the level of each programmer and each module), it will be impossible to implement
the project plan.
A UDF is typically established after the system design phase when tasks are distributed among
programmers.
A UDF is given to the programmer responsible for the development of the unit.
An important element of the UDF is the schedule and progress report of the unit.
The overall schedule for the unit is determined from the project plan and is given to the
programmer responsible for the unit.
Unit Development Folder
The programmer then breaks up the allotted time and produces a detailed schedule
for the development of the unit, with intermediate milestones for detailed design,
coding, test plan, unit testing and the test report.
As each of these milestones is achieved, the programmer gets it certified from the
manager and writes the milestone completion date.
The basic idea here is to force the programmer to identify intermediate milestones in the
task.
- Cost Estimation
- Personnel Plan
- Risk Management
Risk Management
Risk in a project is the possibility that the defined goals are not met.
Risk is defined as an exposure to the chance of injury or loss. That is, risk implies that
there is a possibility that something negative may happen.
Negative implies that there is an adverse effect on cost, quality or schedule.
Risk management is the area that tries to ensure that the impact of risks on cost,
quality and schedule is minimal.
Risk management has to deal with

• Identifying the undesirable events that can occur.
• The probability of their occurring.
• Loss if an undesirable event does occur.
Planning a Software Project (contd.): Risk Management
Risk management revolves around: Risk Assessment and Risk Control
Risk Assessment:
An activity that must be undertaken during project planning.
Involves:
• Identifying the risk.
• Analyzing the risk.
• Prioritizing the risk on the basis of analysis.
Risk Control:
An active measures that are taken by project management to minimize the impact of risks.
Plans are developed for each identified risk that needs to be controlled – Risk Avoidance and Risk
Reduction.
Risk Management Process
Risk Identification
Possible project, product and business risks are identified.
Risk Analysis
The likelihood and consequences of these risks are assessed.
Risk Planning
Plans to address the risk either by avoiding it or minimizing its effects on the
project are drawn up.
Risk Monitoring
The risk is constantly assessed and plans for risk mitigation are revised as more
information about the risk becomes available.
Risk Management Process
Risk Identification Process
Different types of risk are:
Technology Risks – Derive from the software or hardware technologies that re used to develop the
system.
People Risks – Associated with the people in the development team.
Organizational Risks – Derive from the organizational environment where the software is being
developed.
Tools Risks – Derive from the CASE tools and other support software used to develop the system.
Requirements Risks – Derive from changes to the customer requirements and the process of
managing the requirements change.
Requirements Risks – Derive from changes to the customer requirements and the process of
managing the requirements change.
Planning a Software Project (contd.): Risk Management Process
Risk Analysis Process
Consider each identified risk and make a judgement about the probability and the
seriousness of it.
Need to rely on the judgement and experience of the project manager.
Likelihood (Probability) of the risk might be The effects of the risk might be assessed as:
assessed as: • Catastrophe
• Almost Certain (Very High) • Major
• Likely (High) • Moderate
• Possible (Moderate) • Minor
• Unlikely (Low) • Negligible
• Rare (Very Low)
Risk Probability Effects
Organizational financial problems force reductions in Low Catastrophic
the project budget.
It is impossible to recruit staff with the skills required High Catastrophic
for the project.
Key staff are ill at critical times in the project Moderate Major
CASE tools cannot be integrated High Minor
. . .
. . .
. . .
. . .
. . .
. . .
Process
Risk Planning
Considers each of the key risks that have been identified and identifies strategies to
manage the risk.
It relies on the judgement and experience of the project manager.
Strategies fall in to three categories:
• Avoidance Strategies
The probability that the risk arise will be reduced.
The strategy for dealing with defective components – Replace immediately.

Process
• Minimization Strategies
The impact of the risk will be reduced.
The strategy for dealing with staff illness – Reorganize team on regular basis.
• Contingency Plans
You are prepared for the worst and have a strategy in place to deal with it.
The strategy for dealing with organizational financial problems – Convey the
importance of your project to senior management and highlight its
contribution to the goals of the business.
Process
Risk Monitoring
Involves regularly accessing each of the identified risks
- to decide whether or not that risk is becoming more or less probable, and
- whether the effects of the risk have changed.
Risk monitoring should be a continuous process.
At every management progress review, one should consider and discuss each of the
key risks separately.

Unit No 4 Slides Full

Uploaded by

Copyright:

Available Formats

Unit No 4 Slides Full

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit No 4 Slides Full

Uploaded by

Copyright:

Available Formats

Software Engineering

- Introduction to Software Engineering (SE)

• Controlling the development, ensuring quality, satisfying the

• For successful project, both good project management and good

The major issues the project plan addresses are:

Project Estimation Techniques:

Main techniques of estimating project parameters:

 Empirical Estimation Techniques

 Analytical Estimation Technique

Project Estimation Techniques:

Three main techniques of estimating project parameters:

 Empirical Estimation Techniques

 Analytical Estimation Technique

 Empirical Estimation Techniques

 Empirical Estimation Techniques

 Expert may overlook some factors inadvertently.

Project Estimation Techniques:

Three main techniques of estimating project parameters:

 Empirical Estimation Techniques

Three class of models:

• Static Single Variable Model

• Static Multi-Variable Model

• Dynamic Multi-variable Model

Project Estimation Techniques:

Three main techniques of estimating project parameters:

 Empirical Estimation Techniques

 Analytical Estimation Technique

• Halstead’s Software Science

 Not useful for planning.

 Useful for estimating software maintenance efforts.

The major issues the project plan addresses are:

Project parameters can be modelled using a mathematical expression.

Cost estimation with

The model may be:

 Dynamic - all variables are interdependent and there is no basic

• Multi-Variable Model - A Model makes use of several variable to calculate all

• Top-Down Approach: From Overall Effort Distribution to Phase-wise Effort

Barry Boehm introduces a hierarchy of software estimation models bearing the

COCOMO is a regression model based on LOC, i.e., number of Lines Of Code.

Parameters Organic Mode Semi-detached Mode Embedded Mode

Boehm’s hierarchy of models takes the following form:

• Model 1: Basic COCOMO

• Model 2: Intermediate COCOMO

• Model 3: Advanced/Detailed COCOMO

• Model 2: Intermediate COCOMO

• Model 3: Advanced/Detailed COCOMO

This model incorporates all characteristics of the intermediate version with an

Product Attributes Computer Attributes Personnel Attributes Project Attributes

where, ‘E’ is the initial effort in person-months,

32,000 lines of source code = 32 KLOC

It denotes the area under the person-month curve.

32,000 lines of source code = 32 KLOC

STEP 1: STEP 2: STEP 3:

𝐸=𝑎 (𝐾𝐿𝑂𝐶)𝑏 RELY = High = 1.15 𝐸 = 𝑎 (𝐾𝐿𝑂𝐶)𝑏 * EAF

= 3.0 (32)1.12 All others = Nominal = 1.0 = 145 ∗ 1.15

Most large system are made up of Several Smaller Sub-systems.

These sub-systems may have widely different characteristics:

STEP 1: Divide whole software into different modules.

STEP 2: Apply COCOMO in different modules to estimate effort using

Total Effort Distribution: 1.8558 + 2.2622 + 2.886 + 3.173 = 10 PM

EAF = 1.151.061.13*1.17 = 1.61