Software Engineering
BAIEAI3111 / BDSEDS3111 / BCYECY3111
UNIT II : Software Project Planning
Prof. Pratibha Peshwa Swami
Head of Department
Department of Technology
Jodhpur Institute of Engineering & Technology
Formerly
Programme Manager, JCKIF, IIT Jodhpur
Senior Research Officer, RRSCW, ISRO
Course Content:
Unit 1 : Software Engineering Fundamentals- Introduction of Software Engineering, Layered Technology in Software
Engineering, Importance of software, Software myths, software engineering paradigms, Software Process Models: Linear
Sequential Model, Prototyping Model, RAD Model, Evolutionary Software Process Models: Incremental Model, Spiral Model
Component Assembly Model, Formal, Methods, Fourth-Generation Techniques
Unit 2 : Software Project Planning- Introduction of Software Project Planning, Project Size Estimation, Cost Estimation Models-
Static, Single variable models, Static, Multivariable Models, COCOMO, Putnam Resource Allocation Model, Risk Identification and
Projection: RMMM, Project scheduling and Tracking, Software Design Process, Design Principles, and Design Concepts: Effective
Modular Design, Design Heuristics, Design Documentation, Design Methods: Data Design, Architectural Design, Interface Design,
Human Computer Interface Design, Procedural Design. Case Study for Design of any Application Project.
Unit 3 : Software Design and UML- Introduction of Software Design and UML, Unified Modeling Language, Basic structures and
modeling classes, common modeling techniques, relationships, common mechanism, class diagrams, Advanced structured
modeling, advanced classes and relationships, interfaces, types and roles, instances and object diagram. Basic behavioural
Modeling: Use cases, use case diagrams, Interaction diagram, Activity diagrams, state chart diagrams, component diagrams,
deployment diagrams, patterns and frame works.
Unit 4 : Software Testing- Introduction of Software Testing, S/W Testing Fundamentals, Unit testing, Integration testing, System
testing, Black box and White box testing and Incremental testing, Formal proof of correctness, Software matrix, Automated
Testing, Software testing with automated tool
Unit 5 : AGILE Project Management- Introduction of AGILE Project Management, Agile Programming, types of Agile
Development, Agile Manifesto, Refactoring Techniques, Limitations of the Agile Process. Agile Modeling: Principles, Comparing
Waterfall and Agile Modeling , Scrum Methodology- The roles of Scrum, Project Artifacts, Meetings and advantages of Scrum.
Topic Covered in last Unit
• Introduction • Software Process Models
• Evolving Role of Software • Waterfall Model
• Hardware vs. Software • Prototyping Model
• Software characteristics • RAD Model
• Changing nature of software • Evolutionary Software Process Models
• Software Myths • Incremental Model
• Layered Technology • Spiral Model
• Software Process Framework • 4GT Model
• Generic Process Framework Activities • Component Assembly Model
• Umbrella Activities • Revision
• CMMI Level
• Software Evolution
• Software Paradigms
Software Project Planning
◼ The overall goal of project planning is to establish a pragmatic strategy
for controlling, tracking, and monitoring a project. Once a project is
found to be feasible, project managers undertake project planning.
• Estimation is a foundation for all other project planning activities and project
planning provides the road map for successful software engineering
• For estimation of resources, cost, and schedule for a software engineering
effort requires experience, access to good historical information, and the
courage to commit to quantitative predictions when qualitative information is
all that exists.
• Project complexity, project size, and the degree of structural uncertainty all
affect the reliability of estimates.
Project Planning Activities
◼ Estimation:
❑ Effort, cost, resource, and project duration
◼ Project scheduling:
◼ Staff organization:
❑ staffing plans
◼ Risk handling:
❑ identification, analysis, and abatement procedures
◼ Miscellaneous plans:
❑ quality assurance plan, configuration management
plan, etc.
Project Planning Activities
Project planning
◼ Requires utmost care and attention ---
commitments to unrealistic time and resource
estimates result in:
❑ irritating delays.
❑ customer dissatisfaction
❑ adverse affect on team morale
◼ poor quality work
❑ project failure.
Sliding Window Planning
◼ Involves project planning over
several stages:
❑ protects managers from making big
commitments too early.
❑ More information becomes available
as project progresses.
◼ Facilitates accurate planning
SPMP Document
◼ After planning is complete:
❑ Document the plans:
❑ in a Software Project Management
Plan(SPMP) document.
Organization of SPMP Document
❑ Introduction (Objectives,Major Functions,Performance Issues,Management and
Technical Constraints)
❑ Project Estimates (Historical Data,Estimation Techniques,Effort, Cost, and Project
Duration Estimates)
❑ Project Resources Plan (People,Hardware and Software,Special Resources)
❑ Schedules (Work Breakdown Structure,Task Network, Gantt Chart
Representation,PERT Chart Representation)
❑ Risk Management Plan (Risk Analysis,Risk Identification,Risk Estimation,
Abatement Procedures)
❑ Project Tracking and Control Plan
❑ Miscellaneous Plans(Process Tailoring,Quality Assurance)
Software/Project Size Estimation Metrics
• Count the lines
• LOC (Lines of Code)
• Function Point
• Feature Point
11
Software Size Metrics
• LOC (Lines of Code):
• Simplest and most widely used metric.
• Comments and blank lines should not be counted.
Disadvantages:
• Size can vary with coding style.
• Focuses on coding activity alone.
• Correlates poorly with quality and efficiency of code.
• Penalizes higher level programming languages, code reuse, etc.
12
Function Point Metric
13
Function Point Metric
14
15
16
17
18
Calculate FP
19
20
Function Point Metric (CONT.)
• Suffers from a major drawback: the size of a function is considered to be
independent of its complexity.
• Extend function point metric:
• Feature Point metric:
• considers an extra parameter: Algorithm Complexity.
21
FP Short comings
Subjective Evaluation
Conversion Need
Less Research Data
Late Performance
Low Accuracy
Long Learning Curve
Time consuming
22
Feature Point
23
Software Cost Estimation
• Three main approaches to estimation:
• Empirical techniques:
• an educated guess based on past experience.
• Heuristic techniques:
• assume that the characteristics to be estimated can be
expressed in terms of
some mathematical expression.
• Analytical techniques:
• derive the required results starting from certain simple
assumptions.
24
Empirical Size Estimation Techniques
• Expert Judgement:
• An euphemism for guess made by an expert.
• Suffers from individual bias.
• Delphi Estimation:
• overcomes some of the problems of expert judgement.
Expert judgement
• Experts divide a software product into component units:
• e.g. GUI, database module, data communication module, billing
module, etc.
• Add up the guesses for each of the components.
25
Delphi Estimation:
• Team of Experts and a coordinator.
• Experts carry out estimation independently:
• mention the rationale behind their estimation.
• coordinator notes down any extraordinary rationale:
• circulates among experts.
• Experts re-estimate.
• Experts never meet each other to discuss their viewpoints.
26
Heuristic Estimation Techniques
• Single Variable Model:
• Parameter to be Estimated=C1(Estimated
Characteristic)d1
• Multivariable Model:
• Assumes that the parameter to be estimated depends on
more than one characteristic.
• Parameter to be Estimated=C1(Estimated
Characteristic)d1+ C2(Estimated Characteristic)d2+…
• Usually more accurate than single variable models.
27
COCOMO Model
28
Elaboration of Product classes
• Organic:
• Relatively small groups
• working to develop well-understood applications.
• Semidetached:
• Project team consists of a mixture of experienced and
inexperienced staff.
• Embedded:
• The software is strongly coupled to complex
hardware, or real-time systems.
29
30
31
Development Effort Estimation
32
COCOMO Model (CONT.)
• For each of the three product categories:
• From size estimation (in KLOC), Boehm provides equations to
predict:
• project duration in months
• effort in programmer-months
• Boehm obtained these equations:
• examined historical data collected from a large number of actual
projects.
33
COCOMO Model (CONT.)
• Software cost estimation is done through
three stages:
• Basic COCOMO,
• Intermediate COCOMO,
• Complete COCOMO.
34
35
Example
• The size of an organic software product has been
estimated to be 32,000 lines of source code.
• Effort = 2.4*(32)1.05 = 91 PM
• Nominal development time = 2.5*(91)0.38 = 14 months
36
37
38
Intermediate COCOMO
• Cost driver classes:
• Product: Inherent complexity of the product, reliability
requirements of the product, etc.
• Computer: Execution time, storage requirements, etc.
• Personnel: Experience of personnel, etc.
• Development Environment: Sophistication of the tools used for
software development.
39
40
41
42
43
Software Risks
• Risk always involves two characteristics:
• Uncertainty —the risk may or may not happen; that is, there are no
100% probable risks.
• Loss—if the risk becomes a reality, unwanted consequences or
losses will occur
• When risks are analyzed, it is important to quantify the level of
uncertainty and the degree of loss associated with each risk.
• To accomplish this, different categories or types of risks are considered.
• Project Risks
• Technical Risks
• Business Risks
• Known Risks.
• Predictable Risks
• Unpredictable Risks
Risk Identification
• Risk identification is a systematic attempt to specify threats to the project
plan (estimates, schedule, resource loading, etc.).
• By identifying known and predictable risks, the project manager takes a
first step toward avoiding them when possible and controlling them when
necessary.
• Two distinct types of risks
• Generic risks are a potential threat to every software project
• Product-specific risks can be identified only by those with a clear
understanding of the technology, the people, and the environment
that is specific to the project at hand.
Contd.
• To identify product-specific risks, the project Plan and the
software statement of scope are examined.
• One method for identifying risks is to create a risk item
checklist.
• The checklist can be used for risk identification and focuses on
some subset of known and predictable risks in the following
generic subcategories:
• Product size, Business impact, Customer characteristics,
Process definition, Development environment ,Technology
to be built ,Staff size and experience
Risk Components
PM identify the risk drivers that affect software risk components:
• Performance risk—the degree of uncertainty that the product will
meet its requirements and be fit for its intended use.
• Cost risk—the degree of uncertainty that the project budget will
be maintained.
• Support risk—the degree of uncertainty that the resultant
software will be easy to correct, adapt, and enhance.
• Schedule risk—the degree of uncertainty that the project
schedule will be maintained and that the product will be delivered
on time.
The impact of each risk driver on the risk component
Risk Projection
• Risk projection, also called risk estimation, attempts to rate each risk in two
ways:
• The likelihood or probability that the risk is real.
• the consequences (i.e. effect or result) of the problems associated with
the risk, should it occur.
• The project planner, along with other managers and technical staff,
performs four risk projection activities:
• Establish a scale that reflects the supposed likelihood of a risk
• Describe the consequences of the risk,
• Estimate the impact of the risk on the project and the product,
• Note the overall accuracy of the risk projection so that there will be no
misunderstanding
• The intent of these steps is to consider risks in a manner that leads to
prioritization. By prioritizing risks, the team can allocate resources where
they will have the most impact.
Developing Risk Table
Procedure to build risk table
• Listing all risks in first column. This can be accomplished with the
help of the risk item checklists
• Each risk is categorized in the second column
• The probability of occurrence of each risk is entered in the next
column of the table. Which can be estimated by team members.
• Impact of each risk is assessed. Each risk component is assessed
using the characterization and an impact categories like
catastrophic, critical, marginal and negligible are determined.
• Once table is completed, manger will give order of prioritization to
the risk. Therefore, the table is sorted by probability and by impact.
Contd.
• High-probability, high-impact risks get into the top of the table,
and low-probability risks drop to the bottom. (First order
prioritization).
• The project manager studies the resultant sorted table and defines
a cutoff line.
• The cutoff line implies that only risks that lie above the line will be
given further attention.
• Risks that fall below the line are considered as second-order
prioritization.
Contd.
• Risk impact and probability have a distinct influence on
management concern.
• Risk factor that has a high impact but a very low probability of
occurrence then management will give little attention or some time
no attention.
• But if risk factor that has high impact and high probability of
occurrence then management will give high attention.
• All risks that lie above the cutoff line must be managed and specify
in last column of the table under RMMM column.
Contd.
Assessing Risk Impact
• Three factors affect the consequences that are likely if a risk does occur:
• Nature,
• Scope, and
• Timing.
• The nature of the risk indicates the problems that are likely if it occurs.
For example, a technical risk, development environment change
• The scope of a risk combines the strictness with its overall distribution.
• For ex. how much of the project will be affected
or how many customers are harmed?
• The timing of a risk considers when and for how long the impact will be felt.
To determine the overall consequences of a risk:
• Determine the average probability of occurrence value for each risk
component.
• Determine the impact for each component based on the criteria.
• Complete the risk table and analyze the results as described
Now measure, Risk exposure (RE).
RE = P x C
P is the probability of occurrence for a risk and C is the cost to the
project.
Example- the software team defines a project risk in the following manner
• Risk Identification - Only 70 percent of the software components
scheduled for reuse and remaining functionality will have to be
custom developed.
• Risk probability. 80% (likely).
• Risk Impact – Assume total no. of component is 60. If only 70
percent can be used, 18 components would have to be developed
from scratch.
• Since the average component is 100 LOC and local data indicate
that the software engineering cost for each LOC is $14.00,
• the overall cost (impact) to develop the components would be
18 x 100 x 14 = $25,200.
• Risk exposure. RE = 0.80 x 25,200 ~ $20,200.
Risk Mitigation, Monitoring and Management (RMMM)
• Risk analysis goal - to assist the project team in developing a
strategy for dealing with risk. An effective strategy must consider
three issues:
• Risk avoidance or mitigation.
• Risk monitoring
• Risk management and contingency planning
• Proactive approach to risk, avoidance is always the best strategy.
This is achieved by developing a plan for risk mitigation.
• For example, assume that high staff turnover (i.e. revenue) is
noted as a project risk.
Risk Mitigation, Monitoring and Management (RMMM)
• To mitigate this risk, project management must develop a
strategy for reducing turnover.
• Steps are:
• Meet with current staff to determine causes for turnover (e.g., low
pay, competitive job market).
• Mitigate those causes that are under our control before the project
starts.
• Organize project teams so that information about each development
activity is widely dispersed.
• Define documentation standards and establish mechanisms to be
sure that documents are developed in a timely manner.
• Conduct peer reviews of all work
• Assign a backup staff member for every critical technologist.
Risk Mitigation, Monitoring and Management (RMMM)
• As the project proceeds, risk monitoring activities commence.
• The project manager monitors factors that may provide an indication of
whether the risk is becoming more or less likely.
• In the case of high staff turnover, the following factors can be
monitored:
• General attitude of team members based on project pressures.
• Potential problems with compensation and benefits.
• The availability of jobs within the company and outside it.
• Risk management and contingency planning assumes that mitigation
efforts have failed and that the risk has become a reality.
Risk Mitigation, Monitoring and Management (RMMM)
• The project is well underway and a number of people announce that they
will be leaving. If the mitigation strategy has been followed, backup is
available, information is documented, and knowledge has been dispersed
across the team.
• In addition, the project manager may temporarily refocus resources (and
readjust the project schedule) to those functions that are fully staffed,
enabling newcomers who must be added to the team to “get up to speed.”
• Those individuals who are leaving are asked to stop all work and spend
their last weeks in “knowledge transfer mode.”
• This might include video-based knowledge capture, the development of
“commentary documents,” and/or meeting with other team members who
will remain on the project.
RMMM steps incur additional project cost. For example, spending the time
to "backup" every critical technologist costs money.
THE RMMM PLAN
• The RMMM plan documents all work performed as part of risk analysis
and is used by the project manager as part of the overall project plan.
• Some software teams do not develop a formal RMMM document. Rather,
each risk is documented individually using a risk information sheet (RIS).
• RIS is maintained using a database system, so that creation and
information entry, priority ordering, searches, and other analysis may be
accomplished easily.
• Once RMMM has been documented and the project has begun, risk
mitigation and monitoring steps commence.
Project scheduling and Tracking
What is scheduling?
• An activity that distributes estimated effort across the planned
project duration by allocating the effort to specific software
engineering task
• Creating a network of software engineering tasks to complete the
project and assign responsibilities of tasks and timing of tasks
What is Tracking?
• Tracking is the process to make sure that all tasks are completed
according to assigned responsibility and schedule.
Project scheduling
• One of the most difficult jobs for a project manager.
• Begins with process decomposition. It involves separating total work involved in
a project into separate activities and judging the time required to complete these
activities.
• Managers estimate time and resources required to complete activities and
organize them into a coherent sequence.
• When estimating schedules, you should NOT assume that every
stage of the project will be problem-free.
• People may fall ill or may leave
• Hardware may break down
• Essential software/hardware may be delivered late
• If the project is new & technically advanced, then certain parts of it
may turn out to be difficult and take longer than originally anticipated.
Project scheduling : Why is it important?
• Today’s software systems are large, sophisticated and complex
• Many software engineering tasks occur in parallel
• Result of work performed during one task may have a profound effect on work conducted
in another task.
• Task interdependencies are very difficult to understand without a schedule
• It is virtually impossible to assess progress on a large software project without a detailed
schedule
Why Are Software Projects Late?
▪ Technical difficulties that could not have been foreseen in advance
▪ Human difficulties that could not have been foreseen in advance
▪ Project Management fails to track progress –
• Unaware the project is in behind the schedule & in trouble
• No corrective actions taken
Project Scheduling: The Basic Principles
1) Compartmentalization—Compartmentalize the project into a number of
manageable activities, actions & tasks
2) Interdependency—Indicate task interrelationship
3) Time allocation- Each task must be allocated some no. of work units with
start date & completion date
4) Effort validation—be sure resources are available
5) Defined responsibilities—Every task should be assigned to a specific
team member
6) Defined outcomes—Each task must have an output (e.g. work product)
7) Defined milestones—Task(s) should be associated with a project
milestone (A milestone is accomplished when one or more work
products has be reviewed for quality and approved)
The relationship between People and Effort
▪ “If we fall behind schedule, we can
always add more programmers and
catch up later in the project!”
Effort
Why does this not work? Cost
Ea = m ( t d 4 / t a 4 )
• Added/new people must learn the Impossible Ea = effort in person-months
system & learning takes time region t d = nominal delivery time for schedule
• Teaching takes time away from t o = optimal development time (in terms of cost)
productive work Ed
t a = actual delivery time desired
• # of communication paths &
Complexity of communication Eo
increase
td to development time
• The Putnam-Norden-Rayleigh (PNR) Tmin = 0.75T d
Curve provides an indication of the
relationship between effort applied and
delivery time for a software project.
Scheduling Methods
• Two project scheduling methods can be applied to
software development-
1) PERT-Program Evaluation and Review Technique
2) CPM- Critical Path Method
• Both techniques are driven by information already developed in
earlier project planning activities –
• Estimates of effort
• A decomposition of product function
• Selection of appropriate process and task set
• Decomposition of task
72
Scheduling Methods
• Both PERT & CPM provide quantitative tools that allows
software planner to –
• Determine critical path –the chain of tasks that determines
project-duration
• Establish “most likely” time schedules for individual tasks
(using statistical model)
• Calculate “boundary times”
73
Timeline Charts
Tasks Week 1 Week 2 Week 3 Week 4 Week n
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
74
Tracking the schedule
▪ Project schedule provides a road map for a software project manager. Project
schedule defines the tasks & milestones that must be tracked & controlled as the
project proceeds.
▪ Schedule Tracking techniques used by Experienced Project Managers:
• Conducting periodic project status meeting in which each team member
reports progress & problems
• Evaluating the results of all reviews
• Determining whether formal milestones have been accomplished by the
scheduled date
• Compare actual start-date with scheduled start-date
• Informal meeting with practitioners
• Using earned value analysis to assess progress quantitatively.
75
Tracking the schedule
• Control is employed by a project manager to administer project
resources, cope with problems, and direct project staff
• If things are going on well, control is light.
• If problems occur, project manager must exercise control to
reconcile them as quickly as possible.
• Diagnose the problem
• Additional resources may be focused on the problem area
• Staff may be redeployed
• Project schedule can be redefined
• Earned Value Analysis (EVA) is a quantitative technique for assessing
progress. The total hours to complete the entire project are estimated and
each task is given an earned value based on its estimated percentage
contribution to the total. 76
Thank you
“Strive for continuous improvement, instead of perfection.”— Kim Collins
