Software Engineering

outline
⚫ Software Project Planning
• Cost estimation
• Project Scheduling
• Risk Analysis & Management
• Software Quality Assurance Planning
• Project Monitoring Plans
• Project Management Plan
Objectives
⚫ To introduce the fundamentals of software project
planning
⚫ To explain why different techniques should be used for
software cost estimation
⚫ To describe the COCOMO algorithmic cost estimation
model
Introduction
⚫ Software projects are different from projects of other
engineering discipline. How?
⚫ Software engineering projects may be:
• Evolutionary or maintenance projects
» Most projects are of this type
» Can be several different types
– Corrective projects
– Adaptive projects
– Enhancement projects
– Perfective projects / Reengineering
• Projects that involve building on a framework or a set of existing
components.
• A framework is a software system especially designed to be reused in
different projects, or in the various products of a product line.
Cont‟d
• Green field projects
» The minority of projects
» Developers often enjoy such brand new, or green field projects – they have a
wider freedom to be creative about design decision.
⚫ The goal of any software project is to produce a software system
that meet commitments on cost, schedule, quality.
⚫ Worldwide - many projects fail
• one-third are runaways with cost or schedule overrun of more
than 125%
⚫ Major reasons for project runaways
• unclear objectives, bad planning, no project management
methodology,
new technology, insufficient staff
Cont‟d
⚫ Project planning is crucial to the success of the Project:
• careful planning right from the beginning of the project can help to
avoid costly mistakes.
⚫ Reluctance to Planning
• Takes too much time and cost
» Preventive action
» Long-term payoff is greater than short-term cost
• Too tedious (mental activity)
» “Thinker” and “doer”
• Ego (shoot from the hip)
» Not realistic
“If you fail to plan, you plan to fail.”
Project planning
⚫ Before the project can begin, the manager and the software
team must estimate
• the work to be done,
• the resources that will be required, and
• the time that will elapse from start to finish.
⚫ The objective of project planning is to create a plan to meet
the commitments of the project, i.e. create a path that, if
followed, will lead to a successful project.
⚫ Project Planning helps in
• Facilitating communication
• Monitoring / measuring the project progress
• Provides overall documentation of planning decisions
Cont‟d
⚫ Project Planning is an ongoing effort throughout the
Project Lifecycle.
⚫ The major issues the project plan addresses are:
• Cost estimation
• Schedule and staffing
• Risk Analysis & Management
• Software Quality Assurance Planning
• Project Monitoring Plans
• Configuration Management Plan
Software Cost Estimation
⚫ First step in project planning
⚫ Predicting the resources required for a software
development process.
• i.e. estimate resources, cost and schedule for software development
project
⚫ Highly subjective and depends on experience
⚫ Some of the questions that would be addressed in cost
estimation are:
• How much effort is required to complete an activity?
• How much calendar time is needed to complete an activity?
• What is the total cost of an activity?
⚫ Estimate made at the beginning of s/w project
Software cost components
⚫ Hardware and software costs
⚫ Travel and training costs
⚫ Effort costs (the dominant factor in most
projects)
• salaries of engineers involved in the project
• Social and insurance costs
⚫ Effort costs must take overheads into account
• costs of building, heating, lighting
• costs of networking and communications
• costs of shared facilities (e.g library, staff restaurant, etc.)
Cost Estimation Techniques
⚫ Cost estimations techniques are :
» Expert judgement
» Estimation by analogy
» Parkinson's Law
» Pricing to win
» Algorithmic cost modelling
⚫ Each method has strengths and weaknesses
⚫ Estimation should be based on several methods
⚫ If these do not return approximately the same result, there
is insufficient information available
⚫ Some action should be taken to find out more in order to
make more accurate estimates
Expert Judgment
⚫ One or more experts in both software development and
the application domain use their experience to predict
software costs. Process iterates until some consensus is
reached.
⚫ Advantages: Relatively cheap estimation method.
Can be accurate if experts have direct experience of
similar systems
⚫ Disadvantages: Very inaccurate if there are no experts!
Estimation by Analogy
⚫ The cost of a project is computed by comparing the
project to a similar project in the same application
domain
⚫ Advantages: Accurate if project data available
⚫ Disadvantages:
• Impossible if no comparable project has been
tackled.
• Needs systematically maintained cost database
Parkinson‟s Law
⚫ The project costs whatever resources are available.
⚫ work expands to fill the time available.
• The cost is determined by available resources rather
than by objective assessment.
• If the software has to be delivered in 12 months and 5
people are available, the effort required is estimated
to be 60 person-months.

⚫ Advantages: No overspend
⚫ Disadvantages: System is usually unfinished why?
Pricing to Win
⚫ The project costs whatever the customer has to spend on
it. i.e. the estimated effort depends on the customer‟s
budget and not on the software functionality
⚫ Advantages: You get the contract
⚫ Disadvantages: The probability that the
customer gets the system he or she wants is small. Costs
do not accurately reflect the work required
Top-down and bottom-up estimation
⚫ Any of these approaches may be used top-down or
bottom-up
⚫ Top-down
• Start at the system level and assess the overall system
functionality and how this is delivered through sub-
systems
⚫ Bottom-up
• Start at the component level and estimate the effort
required for each component. Add these efforts to
reach a final estimate
Top-down estimation
⚫ Usable without knowledge of the system architecture and the components
that might be part of the system
⚫ Takes into account costs such as integration, configuration management
and documentation
⚫ Can underestimate the cost of solving difficult low-level technical
problems
⚫ especially at the lower level (e.g., tough algorithms or
performance-critical code).
Bottom-up estimation
⚫ Usable when the architecture of the system is known and components
identified
⚫ Accurate method if the system has been designed in detail
⚫ May underestimate costs of system level activities such as integration
and documentation
Algorithmic cost modeling
⚫ A formulaic approach based on historical cost information
and which is generally based on the size of the software
⚫ Some formula based on empirical studies are derived and
adjusted according to the type of project (Organic,
semidetached, embedded ).
⚫ This estimation is generally based on the size of the software
• Line of Code (LOC)
• Function point (FP)
• Object point effort estimation
• Use case based (object oriented approach)
⚫ COCOMO (constructive cost model) is one of algorithmic cost
models
⚫ Size measurement must reflect effort, cost and productivity.
 Requirement
Design
LOC
Code
Halstead’s
Function point
Software Feature point
size
Use-case
Object point

Cyclomatic complexity Reuse

level Reuse frequency

Reuse density
Size Estimation- Line of Code(LOC)
⚫ “A line of code is any line of program text that is not a
comment or blank line, regardless of the number of
statements or fragments of statements
on the line.
⚫ This specifically includes all lines containing program
header, declaration, and executable and non-executable
⚫ statements”.
⚫ The most commonly used measure of source code
program length is the number of lines of code (LOC).
⚫ In a software development effort, there are three major
development products: specification, design, and code.
Cont‟d

The above program has 17 LOC

Cont‟d

■ NCLOC: non-commented source line of code or

effective lines of code (ELOC).
■ CLOC: commented source line of code.
■ By measuring NCLOC and CLOC separately
we can define:
total length (LOC) = NCLOC + CLOC
■ The ratio: CLOC/LOC measures the density of
comments in a program.
Cont‟d

■ Advantages of LOC
■ Simple and automatically measurable
■ Correlates with programming effort (& cost)

■ Disadvantage of LOC
■ Vague definition
■ Language dependability
■ Not available for early planning
■ Developers’ skill dependability
■ Encouraging “sumo” development!
 Length: Halstead’s Work

■ Maurice Halstead’s Theory (1971~1979):

■ A program P is a collection of tokens, composed
of two basic elements: operands and operators
■ Operands are variables, constants, addresses

■ Operators are defined operations in a

programming language
(language constructs) a, b, x
if ... else + - >
100
= main()
goto
 Length: Halstead’s Work /2
▪ Number of distinct operators in the program
(µ1)
▪ Number of distinct operands in the program
(µ2)
▪ Total number of occurrences of operators in the
program (N1)
▪ Total number of occurrences of operands in the
program (N2)
• Program vocabulary (µ)
µ = µ1 + µ2
What will be the formula of D(program Difficulty)?
▪ Program estimated length

▪ Effort required to generate program P: number

of elementary discriminations
▪ Time required for developing program P is the total
effort divided by the number of elementary
discriminations per second

▪ In cognitive psychology β is usually a number

between 5 and 20
▪ Halstead claims that β =18
 ▪ Remaining bugs: the number of bugs left
in the software at the delivery time

▪ Conclusion: the bigger program needs

more time to be developed and more bugs
remained
Example 1
For the following C program:
#include<stdio.h>
main()
{
int a ;
scanf (“%d”, &a);
if ( a >= 10 )
if ( a < 20 )
printf ("10 < a< 20 %d\n" , a);
else
printf ("a >= 20 %d\n" , a);
else
printf ("a <= 10 %d\n" , a);
}
Example 1 (cont’d)

▪ Determine number of operators (µ1).

▪ Determine number of operands (µ2).

▪ Determine the program length in terms of the total number

of occurrences of operators (N1) and operands (N2):
N = N1 + N2
▪ Estimate program length
 Example 1 (cont’d)

Operators Number of Operators Number of

occurrences occurrences
# 1 <= 1
include 1 \n 3
stdio.h 1 printf 3
< ... > 1 < 3
main 1 >= 2
( ... ) 7 if ... else 2
{ ... } 1 & 1
int'i ^ . \ 1 , 4
; 5 %d 4
scanf 1 “….” 4

μ1 = 20 N1 = 47
Example 1 (cont’d)
Operands Number of occurrences
a 10
10 3
20 3

μ2 = 3 N2 = 16

μ1 = 20 N1 = 47

Program length: N = N1 + N2 = 63
Program Estimated length:
Metric Value
Vocabulary ------
Length -------
Estimated Length --------
Volume ---------
Difficulty --------
Level -------
Effort -------
Time (seconds) ----
Estimated Bugs ----
Measuring Software Size:
➢ Function Point (FP),
➢ Feature Point,
➢ Object Point and
➢ Use-case Point

Reading assignment
FP Estimation
⚫ Function points can be estimated from requirement
specification or design specification, thus making it
possible to estimate development efforts in early phases of
development.
⚫ Function points are directly linked to the statement of
requirements; any change of requirements can easily be
followed by a re-estimate.
⚫ Function points are based on the system user‟s external
view of the system, non-technical users of the software
system have a better understanding of what function points
are measuring.
⚫ The principle of Albrecht‟s function point analysis(FPA) is
that a system is decomposed into functional units.
• Inputs : information entering the system
• Outputs : information leaving the system
• Enquiries : requests for instant access to information
• Internal logical files : information held within the system
• External interface files : information held by other system that is
used by the system being analyzed.
The Constructive Cost Model (COCOMO)
⚫ Constructive Cost Model (COCOMO), which is created by
Boehm in 1981, is an empirical model based on project
experience.
⚫ Well-documented, „independent‟ model which is not tied to a
specific software vendor.
⚫ COCOMO predicts the effort and schedule for a software
product development based on inputs relating to the size of
the software and a number of cost drivers that affect
productivity
⚫ COCOMO has three different models that reflect the
complexity:
• the Basic Model
• the Intermediate Model
• and the Detailed Model
Cont‟d

◼ Basic model that is applied early in the project

◼ Intermediate model that is applied after requirements
acquisition
◼ Advanced model that is applied after design is complete
Project Scheduling
⚫ Software project scheduling is creating a network of
software engineering tasks enabling you to get the job done
on time.
⚫ It reflects the start date and end dates for each activity in the
project.
⚫ Responsibility is assigned for each task, progress is tracked,
and the network is updated to changes in the process as they
occur.
⚫ A project Schedule is at two levels - overall schedule and
detailed schedule
⚫ Overall schedule comprises of major milestones and final
date
⚫ Detailed schedule is the assignment of lowest level tasks to
resources
Need for software scheduling
• Software project has a tendency to get out of control because of
the multiple activities that need to be monitored, tracked and
controlled

Milestone vs deliverables
• Milestone is end-point of software process activity or is a point
at which progress on the project may be assessed
• Deliverable is a project result that is delivered to the customer
usually at the end of some major project phase such as
specification, design, etc. (i.e. output (report), code )
• Deliverables are usually milestones but milestones need not be
deliverables.
Project scheduling techniques

⚫ Project scheduling involves identification of:

• The tasks
• dependencies among the tasks
• Duration of each task
• Start and finish date for each task
⚫ Techniques:
a) Gantt Chart
b) Network based scheduling (Precedence Networks ) -> helps to
calculate project duration
» Program Evaluation and Review Technique (PERT): Event-
based
» Critical Path Method (CPM): Activity-based
Gantt chart

⚫ GANTT chart is a type of bar chart that illustrates a

project schedule. used more frequently than others
⚫ Suitable for projects with less than 25 activities
⚫ Graphical display of start/end times
⚫ Shows overlapping activities easily
• CPM or PERT are translated to Gantt sometimes
⚫ For estimation of resource and budget vs. time
⚫ Developed in 1917 by Henry L. Gantt
Example: Gantt chart – Project Development

• A Gantt chart or project schedule includes a list of tasks on the left and
horizontal bars on the right showing when the tasks begin and end.
• We can draw charts with one hour, day, week, or month being the
smallest incremental value.
PERT
⚫ Based on graph theory (nodes and links)-acyclic directed
graph
⚫ Shows dependencies among tasks
⚫ PERT shows critical path ( a path which indicates the
minimum time required to finish the project or the longest
path).
⚫ All activities which don‟t lay on the critical path can be
delayed for some time (slack time) with out having any
effect on overall project schedule.
Activities example
Critical path
⚫ PERT is a network approach that helps to calculate project
duration
• A “path” is a sequence of activities that begins at the start of the project and goes
to the end of the project
» 1,2,3,5,6,7,8
» 1,2,4,6,7,8
• The “critical path” is the path that takes the longest to complete
» and thus determines the minimum duration of the project

3 5
1 2 6 7 8
4
Cont‟d

⚫ Critical Path
• The path that
takes the
longest to
complete
Exercise: Develop PERT and Identify the critical path for the
following activities( after corrected)
Activity duration Intermediate/predecessor
A 8 -
B 7 A
C 6 A
D 10 B,C
E 12 A
F 11 D
G 9 D,E
H 5 F,G
Draw PERT diagram
• How may path do you have
• The time the taken by each path
• CP?
• Can me have more than one CP?
Team Structure
Three ways of organizing a
development team
• Team organization has an effect 1. Egoless team structure (Democratic
on product quality and decomposition):
productivity. ✓ Equal responsibility of team
• Main points to consider for members
organizing development teams ✓ Decision is by consensus (equal
✓ Type of the project (difficulty contribution)
of the problem) ✓ Has many communication paths
✓ The degree to which the ✓ Good for projects which have
problem can be modularized long duration and for complex
✓ The rigidity of delivery of data projects
✓ Team size Analyst

Tester
Programmer

librarian

Designer
Cont‟d

2. Chief Programmer (controlled

centralized): 3. Controlled decentralized
✓ Hierarchical structure for effective • Combines the benefits of DD and
management CC team structure
✓ Contribution of the members only for ✓ Input from different members
the task of the group ✓ Relatively small
✓ Less (vertical) communication path
communication path
✓ Among programmers there exists
horizontal communication
Project Manager
✓ Suitable for small non-difficult projects
and projects with tight schedule
Team Leader

Programmers
Risk Analysis and Management
⚫ Any project can fail - reasons
• Managerial (e.g. schedule and budget overrun)
• Technical (doesn‟t deliver what is expected)
⚫ A project may fail due to unforeseen events - risk management
aims to tackle this.
⚫ Risk: any condition or event whose occurrence is not certain
but which can cause the project to fail
• Cost risk
• Performance risk
• Schedule risk
Cont‟d
Risk Management Tasks

RISK IDENTIFICATION

RISK ASSESSMENT RISK ANALY SIS

RISK PRIORITIZATION
RISK
MANAGEMENT RISK MANAGEMENT
PLANNING

RISK CONTROL RISK RESOLUTION

RISK MONITORING
 …Risk Identification

⚫ To identify possible risks to a project, i.e. to those events that

might occur and which might cause the project to fail
⚫ No “algorithm” possible, done by “what ifs”, checklists, past
experience, etc
⚫ Top Risk Examples
» Shortage of technically trained manpower
» Too many requirement changes
» Unclear requirements
» Not meeting performance requirements
» Unrealistic schedules
» Insufficient business knowledge
» Working on new technology
Risk Prioritization

⚫ The number of risks might be large

⚫ Must prioritize them to focus attention on the “high risk”
areas
⚫ For prioritization, impact of each risk must be understood
⚫ In addition, probability of the risk occurring should also be
understood
⚫ Risk exposure (RE) = probability of risk occurring *
risk impact
⚫ RE is the expected value of loss for a risk
⚫ Prioritization can be done based on risk exposure value
⚫ Plans can be made to handle high RE risks
Cont‟d

⚫ A Simple approach to Risk Prioritization

• Classify risk occurrence probabilities as: Low, Medium,
High
• Classify risk impact as: Low, Medium, High
• Identify those that are HH, or HM/MH
• Focus on these for risk mitigation
• Will work for most small and medium sized projects
Risk Control

⚫ Can the risk be avoided?

• E.g. if new hardware is a risk, it can be avoided by working
with proven hardware
⚫ For others, risk mitigation steps need to be planned and
executed
• Actions taken in the project such that if the risk materializes, its
impact is minimal
• Involves extra cost
Risk Mitigation Example
⚫ Too many requirement changes
• Convince client that changes in requirements will have an impact on
the schedule
• Define a procedure for requirement changes
• Maintain cumulative impact of changes and make it visible to client
• Negotiate payment on actual effort.
⚫ Unrealistic schedules
• Negotiate for better schedule
• Identify parallel tasks
• Have resources ready early
• Identify areas that can be automated
• If the critical path is not within the schedule, negotiate with the client
• Negotiate payment on actual effort
Cont‟d

⚫ Manpower attrition
• Ensure that multiple resources are assigned on key project areas
• Have team building sessions
• Rotate jobs among team members
• Keep backup resources in the project
• Maintain documentation of individual‟s work
• Follow the CM process and guidelines strictly
Risk Mitigation Plan

⚫ Risk mitigation involves steps that are to be performed

(hence has extra cost)
⚫ It is not a paper plan - these steps should be scheduled and
executed
⚫ These are different from the steps one would take if the risk
materializes - they are performed only if needed
⚫ Risks must be revisited periodically
Software Quality Assurance Plan
⚫ Software Quality is conformance to
• Explicitly stated functional and performance requirements
• Explicitly stated development standards
• Implicit characteristics of all professional developed software
⚫ Quality can be defined in many ways
⚫ Current industry standard - delivered defect density (e.g.
#defects/KLOC)
⚫ Defect - something that causes software to behave in an
inconsistent manner
Cont‟d

Defect Injection and Removal

⚫ Software development is labor intensive
⚫ Defects are injected at any stage
⚫ As quality goal is low delivered defect density, these
defects have to be removed
⚫ Done primarily by quality control (QC) activities of
reviews and testing
Cont‟d
Quality Plan

⚫ The quality plan drives the quality activities in the project

⚫ Level of plan depends on models available
⚫ Must define QC tasks that have to be performed in the
project
⚫ Can specify defect levels for each QC tasks (if models and
data available)
Project Monitoring Plans
⚫ Project monitoring includes Progress/status, Cost / effort,
Personnel, resources
⚫ A plan is a mere document that can guide - It must be
executed
⚫ To ensure execution goes as per plan, it must be monitored
and controlled
⚫ Monitoring requires measurements
⚫ And methods for interpreting them
⚫ Monitoring plan has to plan for all the tasks related to
monitoring
Cont‟d

Measurements

⚫ Must plan for measurements in a project

⚫ Without planning, measurements will not be done
⚫ Main measurements – effort, size, schedule, and defects
• Effort – as this is the main resource; often tracked through effort
reporting tools
• Defects – as they determine quality; often defect logging and
tracking systems used
⚫ During planning – what will be measured, how, tool
support, and data management
Cont‟d
Project Tracking
⚫ Goal: To get visibility in project execution so corrective
actions can be taken when needed to ensure project
succeeds
⚫ Different types of monitoring done at projects;
measurements provide data for it
⚫ Activity-level monitoring
• Each activity in detailed schedule is getting done
• Often done daily by managers
• A task done marked 100%; tools can determine status of higher
level tasks
Cont‟d

…Tracking
⚫ Status reports
• Generally done weekly to take stock
• Summary of activities completed, pending
• Issues to be resolved
⚫ Milestone analysis
• A bigger review at milestones
• Actual vs estimated for effort and schedule is done
• Risks are revisited
• Changes to product and their impact may be analyzed
⚫ Cost-schedule milestone graph is another way of doing
this
Cont‟d
Cost-schedule milestone graph
Project Management Plan
⚫ The project management plan (PMP) document is the
culmination of all planning activities undertaken by project
managers.
⚫ It should not be confused with the detailed project schedule.
⚫ Detailed project schedule represents only the schedule and
assignment of activities.
⚫ PMP shows what activities get done in the project
Cont‟d
PMP Structure - Example

⚫ Project overview - customer, start and end date, overall

effort, overall value, main contact persons, project
milestones, development environment..
⚫ Project planning - process and tailoring, requirements
change mgmt, effort estimation, quality goals and plan, risk
management plan, ..
⚫ Project tracking - data collection, analysis frequency,
escalation procedures, status reporting, customer
complaints, …
⚫ Project team, its organization, roles and responsibility, …
Format for Format for Project Plan

• Title page 1- Overview

• Signature page * Summary
• Change history ✓ Purpose, scope,
• Preface ✓ Objectives
✓ Assumptions and constraints
• Table of contents
✓ Deliverables
• List of figures ✓ Schedule and budget summary
• List of tables
*Evolution of plan
2 References
3 Definitions
Cont‟d

4 Project organization 6 Technical process plans

• External interface • Process model
• Internal structure • Methods, tools
• Roles and responsibilities • Acceptance plan
5 Managerial process plans 7 Supporting process plans
• Configuration management
▪ Estimation (cost, schedule)
• Verification/validation
▪ Work (activities, resource and • Quality assurance (reviews,
budget allocation) audits, …)
▪ Control (quality, metrics, …) • Subcontract
▪ Risk management • Process improvement plan
Annexes
Index