SE (Diploma 4th Computer Engineering)

Unit : 3

Software Project Estimation

and Scheduling

Prepared by:
Mr. Uresh N. Parmar
Lecturer, Computer Engg. Dept.
C U Shah Govt. Polytechnic
Surendranagar
 CO (Course Outcome)
&
UOs (Unit Outcomes)
CO (c)
Prepare software development plan using project scheduling.
UOs
3a. Estimate the size of the software product using the given
method
3b. Evaluate the size of the given software using COCOMO model
3c. Prepare the Flow chart/ Gantt chart/ Sprint burn down chart
to track progress of the given project.

2
 3.1 Responsibilities of software project manager
• Person who is responsible for accomplishing project objectives.
 Responsibilities of project manager
• Overall responsibilities
• Planning to deployment
• Bridging the gap
• Managing the constraints of project management triangle (cost, time,
scope, quality)
• All of the above activities are classified in to: project planning,
monitoring and control.
• Doing the task of risk management.
• Follow project status and ensure project success.
• Decision should be project benefits and quality of the product.
3
 3.1 Responsibilities of software project manager
• Setup milestones.
• Preparing documentation.
• Finally, he is responsible for closing the project, conducting reviews,
successful deployment and conducting maintenance of the project.
 Skills required in project manager
• Theoretical knowledge
• Decision making
• Client representative
• Should have management skills
• Focus on risk management
• Experience in related work
• Monitoring and scheduling the project
4
 3.1 Responsibilities of software project manager
• Performance evaluation
• Leadership skill
• Some skills like tracking and controlling the progress of the project,
customer interaction, managerial presentations, and team building
are acquired through experience.

5
 3.2 Metrics for project size estimation
• Metrics are the tools that help in better monitoring and control of
project.
• Size doesn’t mean the number of bytes occupied by the source code.
But it is an indicator of effort and time to develop software project.
• There are several metrics to measure problem size. Each of them has
its own advantages and disadvantages.
• We will consider two important metrics to estimate size: Lines of
code (LOC) and Function point (FP).
 Lines Of Code (LOC)
• It is popular and very simple.
• LOC is a software metric used to measure the size of a software
program by counting the number of lines in the text of the program's
source code. Comments line and headers lines are ignored at
counting the source code.
6
 3.2 Metrics for project size estimation
• It is calculated by project manager by calculating the size of each
module and sub module (every line of source code is calculated as
one LOC).
• One main advantage if LOC is  its simplicity.
 Some disadvantages of LOC
• Language dependent.
• Gives only numeric value.
• It doesn't issue logical and structural complexities.
• It is very difficult to accurately estimate the LOC in the final product
from the problem specification.
• LOC doesn’t work well with non-procedural languages.
• Example (self explanatory)
7
 3.2 Metrics for project size estimation
 Function Point (FP)
• It was proposed by Albrecht in 1979.
• It overcomes many of the shortcomings of the LOC metric.
• One of the important advantages of using the function point metric is
that it can be used to easily estimate the size of a software product
directly from the problem specification.
• Unlike LOC, FP directly dependent on the number of different
functions or features it supports. As number of features increase, FP
increases.
• Basically FP computes the size based on number of inputs and
output values.
• FP considers five different components of the product to calculate
the size. 8
 3.2 Metrics for project size estimation
• These components are:

9
 3.2 Metrics for project size estimation
 Advantages of FP
• It is not restricted to code.
• It is language and technology independent.
• It is more accurate than estimate LOC.
• We can have the measure from the specification that can’t be done
with LOC.
 Disadvantages of FP
• It ignores quality of output.
• It is fully oriented to traditional data processing system.
• Time consuming process.
• Major shortcoming of FP is  it does not calculate the algorithmic
complexity of software.
• It doesn’t capture real time software functional characteristics.
10
 3.2 Metrics for project size estimation
 Example of FP

11
 3.3 Project Estimation Techniques using COCOMO model
• Project estimation is very important in software project development.

• Estimation is the process of making an educated guess or approximation

about a quantity or value.

• The Project Estimation is prediction or a rough idea to determine how much

effort, time, cost or resources would take to complete a defined project task.

• Goal  to provide an accurate assessment of the project's requirements and

constraints.

• It helps in resource planning and scheduling.

• Main categories of project estimation techniques are:

• Empirical estimation techniques

– Based on educated guess.

– Ex: Expert judgement, Delphi cost estimation. 12

 3.3 Project Estimation Techniques using COCOMO model
• Heuristic estimation techniques
– Based on mathematical and regression model
– Ex: COCOMO model
• Analytical estimation techniques
– Based on scientific estimation basis
– Ex: Halstead’s software science
 Before understanding the concept of COCOMO model, it is necessary to
get the idea of software project categories.
• Boehm classified the software development category as following:
o Organic
o Semidetached
o Embedded
• These three product classes correspond to application, utility and
system programs, respectively.
13
 3.3 Project Estimation Techniques using COCOMO model
Organic
• Small group of team.
• Having experienced developers with similar kind of projects.
• Well understood application.
• Little or no innovation.
• Project size: 2 – 50 KLOC.
• Ex: data processing system, inventory management system.
Semidetached
• Mixture of experienced and inexperienced staff.
• Limited experience of related projects.
• Medium innovation.
• Project size: 50-300 KLOC.
• Ex: compilers, interpreters.
14
 3.3 Project Estimation Techniques using COCOMO model
Embedded
• Strongly coupled with complex hardware.
• Inflexible regulations on operations.
• Great innovation.
• Project size is large and number of team members are also large.
• Project size: above 300 KLOC.
• Ex: real time system applications.

15
 3.3 Project Estimation Techniques using COCOMO model
 COCOMO Model

• Full form.
• Kind of heuristic model.
• It is regression based model.
16
 3.3 Project Estimation Techniques using COCOMO model
• Three stages:
– Basic COCOMO
– Intermediate COCOMO
– Complete COCOMO
1. Basic COCOMO
• It is static single valued model.
• Provides quick and rough estimation.
• It mainly calculates development efforts and time for project.

17
 3.3 Project Estimation Techniques using COCOMO model
 Estimation of development efforts:

 Estimation of development time:

 The above estimations are called nominal effort estimation and nominal
duration estimation. 18
 3.3 Project Estimation Techniques using COCOMO model
 In brief:

19
 3.3 Project Estimation Techniques using COCOMO model
 Example:
Assume that the size of an organic type software product has been
estimated to be 2,000 lines of source code. Assume that the average
salary of software engineers be Rs. 20,000/- per month. Determine
the effort required to develop the software product and the nominal
development time.
Solution:

20
 3.3 Project Estimation Techniques using COCOMO model
2. Intermediate COCOMO
• Disadvantage of basic COCOMO model.
• Some other factors (parameters) also affecting effort and time
calculation. So they should be taken in account for estimation.
• Intermediate COCOMO doing it by using set of 15 cost drivers
(multipliers).
• The cost drivers grouped into following categories:
o Product attributes
o Computer attributes
o Personal attributes
o Project attributes

21
 3.3 Project Estimation Techniques using COCOMO model
3. Complete COCOMO
• It is also known as detailed COCOMO model or advanced COCOMO
model.
• A major shortcoming of both the basic and intermediate COCOMO
models is that they consider a software product as a single
homogeneous entity.
• But most large systems are made up several smaller sub-systems.
• For example, some subsystems may be considered as organic type,
some semidetached, and some embedded.
• And these subsystems may be different requirements, development
complexities and may not have previous experience of similar
developing.
• The complete COCOMO model considers these differences in
characteristics of the subsystems. 22
 3.3 Project Estimation Techniques using COCOMO model
• Detailed COCOMO model - incorporates all characteristics of the
intermediate version with an assessment of the cost driver's impact
on each step (analysis, design, etc.) of the software engineering
process.
• It estimates the effort and development time as the sum of the
estimates for the individual subsystems.
• The cost of each subsystem is estimated separately.
• This approach reduces the margin of error in the final estimate.
• For example, a distributed Management Information System (MIS).
Because it can have following sub components:
– Graphical User Interface (GUI) part (organic)
– Database part (semi-detached)
– Communication part (embedded)
• The costs for these three components can be estimated separately,
and summed up to give the overall cost of the system.
23
 3.3 Project Estimation Techniques using COCOMO model
• There are six phases of complete COCOMO model:
1. Planning and requirements
2. System design
3. Detailed design
4. Module code and test
5. Integration and test
6. Cost Constructive model
 Advantages of COCOMO model
• It is easy to use.
• It is repeatable process.
• It is highly standardize.
• It can be detailed documented.
• It is versatile enough to support different modes and levels.
24
 3.3 Project Estimation Techniques using COCOMO model
 Disadvantages of COCOMO model
• Not accurate and not good for scientific justification.
• It ignores software safety issues.
• Ignores hardware issues.
• It ignores personal turn over.
• Dependent on size estimates.

25
 3.4 Project Scheduling
• It is an important project activity.
• Schedule is a timetable showing the forecast start and finish date.
• It outlines the start and end dates of each task.
• Ensuring project time and budget.
• Following steps are involved:
 Identify required tasks.
 Determine the order.
 Estimate the duration.
 Assign resources.
 Create schedule with start and end dates.
 Monitoring the progress.
• After then project manager is ensure about the project completion
and stake holders are informed about this.
26
 3.4 Project Scheduling
 Benefits of project scheduling
• For monitoring and controlling activities.
• Allocate resources.
• Helps in achieving the goal.
• Helps in time assessment.
• Helps in ensure of project completion.
 Project scheduling tools
• Gantt chart
• Critical Path Method (CPM)
• Project management software: Microsoft project, Trello
• Agile project management tool: Jira
• Resource management tool: Resource Guru, Float

27
 3.4 Project Scheduling: GANTT Chart
• It is a popular tool used to visualize a project schedule.
• Proposed by Henry Gantt in 1914.
• Also called Time line chart.
• Mainly used for resource planning. Resources include staff,
hardware, and software etc.
 A Gantt chart is a special type of bar chart where each bar represents
an activity.

• The bars are drawn along a time line. Activities against time are
drawn in bar chart. The length of each bar is proportional to the
duration of time planned for the corresponding activity.
• Start dates, end dates and dependencies are shown graphically.
• Slack time is also shown.
• The chart is prepared by project manager.
28
 3.4 Project Scheduling: GANTT Chart
 How to plan Gantt chart
• Identify all tasks.
• Break down them into smaller tasks.
• Determine total estimated completion time for each task.
• Plot activities on chart.
 Advantages of Gantt chart
• Used in project planning and scheduling.
• It is very simple to understand and easy to use.
• Used in monitoring the progress.
• Mainly used for resource allocation.
• Useful for understanding critical path.

29
 3.4 Project Scheduling: GANTT Chart
 Disadvantages of Gantt chart
• It doesn’t show precedence relationship.
• Not suitable for large projects.
• It can’t calculate short time.
• Updating is time consuming.
• Sometimes compromise quality.
 Applications of Gantt chart
• Used in industry.
• Used to set milestones.
• Used in team coordination.
• Analyze complex projects.

30
 3.4 Project Scheduling: GANTT Chart
 Example

31
 3.4 Project Scheduling: GANTT Chart
 Example

32
 3.4 Project Scheduling: Flow Chart
• It was introduced by Frank Gilbreth in 1921.
• A flowchart is a graphical representation of a process, algorithm, or
system using various symbols. It graphically displays step-by-step
solution of a problem.
• Used to illustrates the sequence of steps required to complete a task.
 Types of flow chart
• List of different important flow charts are:
• Process chart
• Data flow chart
• Business process modeling diagram
• Document flow chart

33
 3.4 Project Scheduling: Flow Chart
 Symbols of flow chart

34
 3.4 Project Scheduling: Flow Chart
 Symbols of flow chart

35
 3.4 Project Scheduling: Flow Chart
 Steps to draw flow chart
• Define scope
• Identify tasks in sequence
• Organize tasks by type and symbol
• Draw chart
 Advantages of flow chart
• Easy to understand.
• It illustrates the work flow.
• Helps in data management.
• Used to document all the steps in pictorial format.
• Used to coordinate team efforts.

• Helps to create clear documentation.

36
 3.4 Project Scheduling: Flow Chart
 Disadvantages of flow chart
• Difficult to rearrange.
• Time consuming.
• Difficult for those who don’t have knowledge about symbols.
• Difficult for complex system.
• Language dependent.
• Does not provide in-depth analysis.

37
 3.4 Project Scheduling: Flow Chart
 Example

38
 3.4 Project Scheduling: Sprint Burn Down Chart
• Mainly used for agile development.
• Help agile team to ship better software in time.
• In Agile product development, a sprint is a set period of time during
which specific work has to be completed and made ready for review.
• During a sprint, the team plans, designs, develops, tests, and delivers
a working software product or a set of product features.
• Execution of sprint work can be shown graphically using Sprint
Burndown chart.
• In Agile methodology, burndown charts today have become more
popular in providing stakeholders as well as the team members the
status whether a sprint goal is accomplished in an easy,
understandable way or not.
• A Sprint Burndown Chart is a graphical representation of the amount
of work has been completed during a sprint and the total amount of
work remaining during an Agile development project.
39
 3.4 Project Scheduling: Sprint Burn Down Chart
• It can be used to track the total work remaining in the sprint, and to
track the progress of a scrum team.
• A simple burndown chart (with explanation, how to read chart)

40
 3.4 Project Scheduling: Sprint Burn Down Chart
 Need of sprint burn down chart
• It makes team work visible.
• Helps in completing project work.
• To map the current status.
• To make the work progress in transparent manner.
 Persons involved
• Developers (Team)
• Product owner
• Scrum master
 Advantages of sprint burn down chart
• Used to analyse day-to-day work.
• Improve project planning
• Used to reduce risks
41
 3.4 Project Scheduling: Sprint Burn Down Chart
• Serves as early warning system
• Improve team motivation
 Disadvantages of sprint burn down chart
• No changes can be displayed in scope of work
• Limited perspective
• Cannot be used to measure absolute team progress

42
 3.4 Project Scheduling: Sprint Burn Down Chart
 Example

43
 3.4 Project Scheduling: Sprint Burn Down Chart
 Example
Sprint burn down chart for the given data:

Burndown Chart
12

10

0
Jan-01 Jan-02 Jan-03 Jan-04 Jan-05 Jan-08 Jan-09 Jan-10 Jan-11 Jan-12 Jan-13
Mon Tue Wed Thur Fri Mon Tue Wed Thur Fri Sat

Planned Actual

44
 3.5 Risk Management
• In simple term, ‘Tomorrow’s problem is today’s risk’.
• Software risk is a problem that can cause some loss or threaten the
success of software project, but which hasn’t happened yet.
• This risk may affect negatively to the cost, schedule, technical
success or quality of the project.
• Risk can be arise from various sources.
• Risk must be managed for better quality of software product.
• Risk management is the process of identifying, assessing and
eliminating the problems of risks before they can damage the
project.
 Objectives of risk management
• Identify problems before they become critical.
• Continuously care for project quality.

45
 3.5 Risk Management
• Early identification of risks.
• Increase chance of project success.
• Provide monitoring and controlling.

Risk management activities 46

 3.5 Risk Management
 Risk Assessment
• Risk assessment is the process of evaluating and analysing potential
risks that have been identified.
• Primary goal  to determine the likelihood and potential impact of
each risk, so that appropriate mitigation strategies can be developed
and implemented.
• Identify and analyze risks in a systematic way.
• It includes following activities:
– Risk identification

– Risk analysis

– Risk prioritization

47
 3.5 Risk Management
 Risk Identification
• It specifies threats of project plan.
• Risk identification is to identify as many potential risks as possible,
so that the impact of risk can be reduced by making effective risk
management planning.
• Checklist is prepared.
• Risks are categorised mainly into three classes.
• Project risks
– Project risks threaten the project. They concerned with budget,
schedule, resources, customer related problem etc.
– Important project risk is schedule slippage.
• Technical risks
– Related to technical aspects of the project, like architecture, design,
coding, testing, implementation.
– Generally occurs due to insufficient knowledge of technical team.
48
 3.5 Risk Management
• Business risks
– That risks threaten the development (or client) organization.
– This type of risks includes risks of building an excellent product
that no one thinks, losing budgetary, market changes, competition
or personnel commitments, etc.
• Output of this activity  List of risks.
 Risk analysis
• Identified risks are analysed here.
• Purpose  to examine how project outcomes might change with
modification of risk input variables.
• Output is the ranking of the risks.
• Main activities of this process:
- Group similar risks - Determine risk drivers
- Determine source of risk - Estimate risk exposer
- Evaluate against criteria 49
 3.5 Risk Management
 Risk prioritization
• Ranking and ordering of risks based on their potential impact.
• Purpose  Focus on critical risks.
• Given probability (0.1 – 1.0) or scale ( 1 – 10) to risks.
• The higher the exposure, the more the risk should be tackled.

50
 3.5 Risk Management
 Risk Control
• It is the process of managing risks to achieve the desired outcomes.
• Reduce the adverse effects of risks.
• Risk control (OR Mitigation) includes the following activities:
– Risk management planning

– Risk monitoring

– Risk resolution
 Risk management and planning
• It produces a plan for dealing with risks.
• Different strategies:

- Risk avoidance - Risk minimization

- Risk transfer - Risk contingency plan 51
 3.5 Risk Management
 Risk monitoring
• It is continuous process.
• Projects can be evaluated periodically.
• Each risk is discussed at management level.
 Risk resolution
• Execution of plan dealing with each risk.
• Defined by project manager.
• Input is: risk activity and outputs are:
 Risk status
 Acceptable risks
 Reduced rework
 Reduced rework
 Problem prevention

52
Assignment

53
Assignment

54
Assignment

55
 nk Y
Prepared by:
Uresh N. Parmar
Lecturer, Computer Dept.
C U Shah Govt. Polytechnic
Surendranagar