planning a software project
DESCRIPTION
Planning a Software Project. Agenda. Background Effort estimation Schedule and resource estimation Quality Planning Risk management Project monitoring plans. Software Project. Goal: Build a software system to meet commitments on cost, schedule, scope, quality - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/1.jpg)
Planning a Software Project
![Page 2: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/2.jpg)
Project Planning 2
Agenda
BackgroundEffort estimation Schedule and resource estimationQuality PlanningRisk managementProject monitoring plans
![Page 3: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/3.jpg)
Project Planning 3
Software Project
Goal: Build a software system to meet commitments on cost, schedule, scope, quality
Worldwide - many projects fail one-third are runaways with cost or
schedule overrun of more than 125%
![Page 4: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/4.jpg)
Project Planning 4
Project FailuresMajor reasons for project runaways
unclear objectives bad planning no project management methodology new technology insufficient staff
All of these relate to project managementEffective project management is key to
successfully executing a project
![Page 5: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/5.jpg)
Project Planning 5
Why improve PM?
Better predictability leading to commitments that can be met
Lower cost through reduced rework, better resource mgmt, better planning,..
Improved quality through proper quality planning and control
Better control through change control, change management (CM), monitoring etc.
![Page 6: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/6.jpg)
Project Planning 6
Why improve PM ….
Better visibility into project health and
state leading to timely intervention
Better handling of risks reducing the
chances of failure
All this leads to higher customer
satisfaction
And organization improvement
![Page 7: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/7.jpg)
Project Planning 7
The Project Mgmt Process
Has three phases - planning, monitoring and control, and closure
Planning is done before the much of the engineering process (life cycle, LC) and closure after the process
Monitoring phase is in parallel with LCWe focus on planning; monitoring covered
through its planning
![Page 8: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/8.jpg)
Project Planning 8
Project PlanningBasic objective: 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
Planning involves defining the life cycle (LC) process to be followed, estimates, detailed schedule, plan for quality, etc.
Main output - a project management plan and the project schedule
![Page 9: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/9.jpg)
Project Planning 9
Key Planning Tasks
Estimate effort
Define project milestones and create a schedule
Define quality objectives and a quality plan
Identify risks and make plans to mitigate them
Define measurement plan, project-tracking
procedures, training plan, team organization, etc.
![Page 10: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/10.jpg)
Effort Estimation
• For a software development project, overall effort and schedule estimates are essential prerequisites for planning the project.• The accuracy with which effort can be estimated clearly depends on the level of information available about the project. • The more detailed the information, the more accurate the estimation can be.
![Page 11: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/11.jpg)
Project Planning 11
Effort Estimation
For a project total cost and duration has to be committed in start
Requires effort estimation, often in terms of person-months
Effort estimate is key to planning - schedule, cost, resources depend on it
Many problems in project execution stem from improper estimation
![Page 12: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/12.jpg)
Project Planning 12
Estimation..
No easy way, no silver bullet
Estimation accuracy can improve with more information about the project
Early estimates are more likely to be inaccurate than later More uncertainties in the start
With more info, estimation becomes easier
![Page 13: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/13.jpg)
Project Planning 13
Effort Estimation Models..
A model tries to determine the effort estimate from some parameter values
A model also requires input about the project, and cannot work in vacuum
So to apply a model, we should be able to extract properties about the system
Two types of models - top-down and bottom-up
![Page 14: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/14.jpg)
Project Planning 14
Effort Estimation Models
Extract Estimation Model
Values of somecharacteristics
Effort Estimate
Knowledge aboutSW project
![Page 15: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/15.jpg)
Project Planning 15
Top down estimation
The effort for a project is a function of many parameters, it is generally agreed that the primary factor that controls the effort is the size of the project.
The larger the project, the greater is the effort requirement. The top down approach utilizes this and considers effort as a function of project size.
First determine the nature of the function, and then to apply the function, then to estimate the size of the project for which effort is to be estimated.
![Page 16: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/16.jpg)
Project Planning 16
Top down estimation
First determines the total effort, then effort for components
Simple approach – estimate effort from size and productivity Get the estimate of the total size of the software Estimate project productivity using past data and project
characteristics Obtain the overall effort estimate from productivity and
size estimates
Effort distribution data from similar project are used to estimate effort for different phases
![Page 17: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/17.jpg)
Project Planning 17
Top-down Estimation
A better method is to have effort estimate as a function of size using:
Effort (E) = a * size b
E is in person-months, size in KLOC or function points
Incorporates the observation that productivity can dip with increased size
Constants a and b determined through regression analysis of past project data
![Page 18: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/18.jpg)
Project Planning 18
Constructive Cost Model (COCOMO)
Uses size, but adjusts using some factors
Basic procedure Obtain initial estimate using size
Determine a set of 15 multiplying factors from different project attributes
Adjust the effort estimate by scaling it with the final multiplying factor
![Page 19: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/19.jpg)
Project Planning 19
COCOMO..
Initial estimate: a * size b ; some standard values for a, b given for diff project types
There are 15 cost driver attributes like reliability, complexity, application experience, capability, …
Each factor is rated, and for the rating a multiplication factor is given
Final effort adjustment factor is the product of the factors for all 15 attributes
![Page 20: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/20.jpg)
Project Planning 20
COCOMO – Some cost drivers
Cost Driver Very low
Low Nominal
High Very High
Required reliabilityDatabase sizeProduct complexityExecution time constraintMemory constraintAnalyst capabilityApplication experienceProgrammer capabilityUse of software toolsDevelopment schedule
.75
.7
1.461.291.421.241.23
.88
.94
.85
1.191.131.171.101.08
1.01.01.01.01.01.01.01.01.01.0
1.151.081.151.111.06.86.91.86.911.04
1.41.161.31.31.21.71.82.70.831.1
COCOMO uses a set of 15 different attributes of a project called cost driver attributes
![Page 21: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/21.jpg)
Project Planning 21
COCOMO – Example
For example, Watson and Felix [81] analyzed the data of more than 60 projects done at IBM Federal Systems Division, ranging from 4000 to 467,000 lines of delivered source code, and found that if the SIZE estimate is in thousands of delivered lines of code (KLOC), the total effort, E, in person-months (PM) can be given by the equation.
E = 5.2(SIZE) .91
In the Constructive Cost Model (COCOMO) [12, 13], for the initial estimate (also called nominal estimate) the equation for an organic project is
E = 3.9(SIZE) .91
![Page 22: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/22.jpg)
Project Planning 22
COCOMO – Example The multiplying factors for all 15 cost drivers are
multiplied to get the effort adjustment factor (EAF). The final effort estimate, E, is obtained by multiplying the initial estimate by the EAF. In other words, adjustment is made to the size-based estimate using the rating for these 15 different factors.
As an example, consider a system being built for supporting auctions in a university, it is decided that the system will comprise a few different modules. The modules and their expected sizes are:
![Page 23: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/23.jpg)
Project Planning 23
COCOMO – Example Login 200 LOC Payment 200 LOC Administrator interface 600 LOC Seller functions 200 LOC Buyer functions 500 LOC View and bookkeeping 300 LOC TOTAL 2000 LOC The total size of this software is estimated to be 2 KLOC. If we want to use COCOMO for estimation, we should
estimate the value of the different cost drivers. Suppose we expect that the complexity of the system is high, the programmer capability is low, and the application experience of the team is low. All other factors have a nominal rating.
![Page 24: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/24.jpg)
Project Planning 24
COCOMO – Example
Effort adjustment factor (EAF) is EAF = 1.15 * 1.17 * 1.13 = 1.52.
The initial effort estimate for the project is obtained from the relevant equations.
Ei = 3.9 2.91 = 7.3 PM.
Using the EAF, the adjusted effort estimate is E = 1.52 7.3 = 11.1 PM.
![Page 25: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/25.jpg)
Project Planning 25
COCOMO – effort distribution
Effort distribution among different phases is given as a percent of effort
Eg.
![Page 26: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/26.jpg)
The procedure for estimation can be summarized as the following sequence of steps:
1. Identify modules in the system and classify them as simple, medium, or complex.
2. Determine the average coding effort for simple/medium/complex modules.
3. Get the total coding effort using the coding effort of different types of modules and the counts for them.
4. Using the effort distribution for similar projects, estimate the effort for other tasks and the total effort.
5. Refine the estimates based on project-specific factors.
![Page 27: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/27.jpg)
Project Planning 27
Bottom-up Estimation
An alternate approach to top-down Effort for components and phases first estimated,
then the total Project is first divided into tasks and then
estimates for the different tasks of the project are obtained. From the estimates of the different tasks, the overall estimate is determined.
Can use activity based costing - all activities enumerated and then each activity estimated separately
Can group activities into classes - their effort estimate from past data
![Page 28: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/28.jpg)
Project Planning 28
An Estimation Procedure
Identify programs in the system and classify them as simple, medium, or complex (S/M/C)
Define the average coding effort for S/M/C Get the total coding effort.Use the effort distribution in similar projects
to estimate effort for other tasks and totalRefine the estimates based on project
specific factors
![Page 29: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/29.jpg)
Scheduling and Staffing
![Page 30: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/30.jpg)
Project Planning 30
Project Schedule
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
![Page 31: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/31.jpg)
Project Planning 31
Overall Schedule
Depends heavily on the effort estimateFor an effort estimate, some flexibility
exists depending on resources assignedEg a 56 person-months project can be
done in 8 months with 7 people, or 7 months with 8 people
Stretching a schedule is easy; compressing is hard and expensive
![Page 32: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/32.jpg)
Project Planning 32
Overall Scheduling...
One method is to estimate schedule S (in months) as a function of effort in PMs
Can determine the function through analysis of past data; the function is non linear
COCOMO: S = 2.5 E .38 IBM Federal Systems Division: S = 4.1 E .36.Often this schedule is checked and
corrected for the specific project
![Page 33: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/33.jpg)
Project Planning 33
Determining Overall Schedule from past data
Effort in person-days
0
50
100
150
200
250
300
350
400
0 200 400 600 800 1000 1200 1400 1600 1800
Sch
ed
ule
(D
ays
)
![Page 34: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/34.jpg)
Project Planning 34
Overall Scheduling...
Another method for checking a schedule for medium-sized projects is the rule of thumb called the square root check .
This check suggests that the proposed schedule can be around the square root of the total effort in person-months.
This schedule can be met if suitable resources are assigned to the project.
As schedule is not a function solely of effort, the schedule determined in this manner is essentially a guideline
For example, if the effort estimate is 50 person-months, a schedule of about 7 to 8 months will be suitable.
![Page 35: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/35.jpg)
Project Planning 35
Determining Milestones
With effort and overall schedule decided, avg project resources are fixed
Manpower ramp-up in a project decides the milestones
Manpower ramp-up in a project follows a Rayleigh curve - like a normal curve
In reality manpower build-up is a step function
![Page 36: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/36.jpg)
Project Planning 36
Manpower Ramp-up
Design Build Test
PTS
In the beginning and the end, few people are needed on the project; the peak team size (PTS) is needed somewhere near the middle of the project; and again fewer people are needed after that.
TeamSize
![Page 37: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/37.jpg)
Project Planning 37
Manpower Ramp-up
• Given the effort estimate for a phase, we can determine the duration of the phase if we know the manpower ramp-up.
• For these three major phases, the percentage of the schedule consumed in the build phase is smaller than the percentage of the effort consumed because this phase involves more people..
![Page 38: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/38.jpg)
Project Planning 38
Manpower Ramp-up
For ease of scheduling, particularly for smaller projects, often the required people are assigned together around the start of the project.
This approach can lead to some people being unoccupied at the start and toward the end.
This slack time is often used for supporting project activities like training and documentation.
![Page 39: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/39.jpg)
Project Planning 39
Milestones ...
With manpower ramp-up and effort distribution, milestones can be decided
Effort distribution and schedule distribution in phases are different
Generally, the build has larger effort but not correspondingly large schedule
COCOMO specifies distribution of overall schedule: - Design – 19%, programming – 62%, integration – 18%
![Page 40: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/40.jpg)
Project Planning 40
Detailed Scheduling
Detailed schedule not done completely in the start - it evolves
Can use Microsoft Project for keeping it
Detailed Schedule is the most live document for managing the project
Any activity to be done must get reflected in the detailed schedule
![Page 41: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/41.jpg)
Quality Planning
![Page 42: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/42.jpg)
Project Planning 42
Quality Planning
Delivering high quality is a basic goalQuality can be defined in many waysCurrent industry standard - delivered
defect density (e.g. #defects/KLOC)Defect - something that causes software
to behave in an inconsistent mannerAim of a project - deliver software with low
delivered defect density
![Page 43: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/43.jpg)
Project Planning 43
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
![Page 44: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/44.jpg)
Project Planning 44
Defect Injection and Removal
Req.Analysis
Design R Coding R UT IT/ST AT
DevelopmentProcess
Defect Injection
R
Defect Removal
The QC activities for defect removal include requirements reviews, design reviews, code reviews, unit testing, integration testing, system testing, acceptance testing, etc
The QC activities for defect removal include requirements reviews, design reviews, code reviews, unit testing, integration testing, system testing, acceptance testing, etc
![Page 45: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/45.jpg)
Project Planning 45
Approaches to Quality Management
Ad hoc - some testing, some reviews done
as and when needed
Procedural - defined procedures are
followed in a project
Quantitative - defect data analysis done to
manage the quality process
![Page 46: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/46.jpg)
Project Planning 46
Procedural Approach
A quality plan defines what QC tasks will be undertaken and when
Main QC tasks - reviews and testing
Guidelines and procedures for reviews and testing are provided
During project execution, adherence to the plan and procedures are ensured
![Page 47: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/47.jpg)
Project Planning 47
Quantitative Approach
Goes beyond asking “has the procedure been executed”
Analyzes defect data to make judgements about quality
Past data is very importantKey parameters - defect injection and
removal rates, defect removal efficiency (DRE)
![Page 48: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/48.jpg)
Project Planning 48
Quality Plan
The quality plan drives the quality
activities in the project
Must define QC tasks that have to be
performed in the project
Can specify defect levels for each QC
tasks
![Page 49: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/49.jpg)
Risk Management
![Page 50: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/50.jpg)
Project Planning 50
Risk Management
Any project can fail - reasons can be technical, managerial, etc.
Project management aims to tackle the project management aspect
Engineering life cycles aim to tackle the engineering issues
A project may fail due to unforeseen events - risk management aims to tackle this
![Page 51: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/51.jpg)
Project Planning 51
Risk Management
Risk: any condition or event whose occurrence is not certain but which can cause the project to fail
Aim of risk management: minimize the effect of risks on a project
Risk management has two basic aspects Risk assessment Risk control
![Page 52: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/52.jpg)
Project Planning 52
Risk Assessment
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
Can have a list of “top 10” risks that projects have seen in past
![Page 53: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/53.jpg)
Project Planning 53
Top Risk Examples
Shortage of technically trained manpowerToo many requirement changesUnclear requirementsNot meeting performance requirementsUnrealistic schedulesInsufficient business knowledgeWorking on new technology
![Page 54: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/54.jpg)
Project Planning 54
Risk Prioritization
The number of risks might be largeMust prioritize them to focus attention on
the “high risk” areasFor prioritization, impact of each risk must
be understoodIn addition, probability of the risk
occurring should also be understood
![Page 55: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/55.jpg)
Project Planning 55
Risk Prioritization ...
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
![Page 56: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/56.jpg)
Project Planning 56
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
![Page 57: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/57.jpg)
Project Planning 57
Risk Control
Can the risk be avoided? E.g. if new hardware is a risk, it can be
avoided by working with proven hardwareFor 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
![Page 58: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/58.jpg)
Project Planning 58
Risk Mitigation Examples
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.
![Page 59: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/59.jpg)
Project Planning 59
Examples ...
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
![Page 60: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/60.jpg)
Project Planning 60
Examples ...
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
![Page 61: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/61.jpg)
Project Planning 61
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
![Page 62: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/62.jpg)
Project Planning 62
A Practical Risk Mgmt Approach
Based on methods of some orgs1. List risks; for each risk rate probability
as Low, Medium, High2. For each risk assess impact on the
project as Low, medium, High3. Rank the risks based on probability
and impact – HH is the highest4. Select top few items for mitigation
![Page 63: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/63.jpg)
Project Planning 63
A risk mgmt plan
![Page 64: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/64.jpg)
Project Planning 64
A risk mgmt plan
![Page 65: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/65.jpg)
Project Planning 65
A risk mgmt plan
Risk Prob. Impact Exposure
1. Failure to meet performance requirements
High High High
2. Lack of people with right skills
Med Med Med
3. Complexity of the application
Med Med Med
4. Unclear requirements
Med Med Med
![Page 66: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/66.jpg)
Project Planning 66
Risk Mgmt plan…
Risk Mitigation plan
1. Failure to meet performance requirements
Train team in perf. enggHave perf testing scriptsUse suitable tools
2. Lack of people with right skills
Train resourcesDevelop suitable standards
3. Complexity of the application
Ensure ongoing knowledge transferUse people with domain exp.
4. Unclear requirements Have multiple reviewsBuild prototype
![Page 67: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/67.jpg)
Project Monitoring Plans
![Page 68: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/68.jpg)
Project Planning 68
Background
A plan is a mere document that can guide
It must be executedTo ensure execution goes as per plan, it
must be monitored and controlledMonitoring requires measurementsAnd methods for interpreting themMonitoring plan has to plan for all the
tasks related to monitoring
![Page 69: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/69.jpg)
Project Planning 69
MeasurementsMust plan for measurements in a projectWithout planning, measurements will not
be doneMain 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 usedDuring planning – what will be measured,
how, tool support, and data management
![Page 70: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/70.jpg)
Project Planning 70
Project Tracking
Goal: To get visibility in project execution so corrective actions can be taken when needed to ensure project succeeds
Diff types of monitoring is done at projects; measurements provide data for it
![Page 71: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/71.jpg)
Project Planning 71
Tracking…
Activity-level monitoring Each activity in detailed schd is getting done Often done daily by managers A task done marked 100%; tools can
determine status of higher level tasks
Status reports Generally done weekly to take stock Summary of activities completed, pending Issues to be resolved
![Page 72: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/72.jpg)
Project Planning 72
Tracking…
Milestone analysis A bigger review at milestones Actual vs estimated for effort and sched
is done Risks are revisited Changes to product and their impact
may be analyzedCost-schedule milestone graph is
another way of doing this
![Page 73: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/73.jpg)
Project Planning 73
Project Management PlanThe project management plan (PMP)
contains outcome of all planning activities - focuses on overall project management
Besides PMP, a project schedule is needed Reflects what activities get done in the project Microsoft project (MSP) can be used for this Based on project planning; is essential for day-
to-day management Does not replace PMP !
![Page 74: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/74.jpg)
Project Planning 74
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, ..
![Page 75: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/75.jpg)
Project Planning 75
PMP Example ...
Project tracking - data collection, analysis frequency, escalation procedures, status reporting, customer complaints, …
Project team, its organization, roles and responsibility, …
![Page 76: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/76.jpg)
Project Planning 76
Project Planning - Summary
Project planning forms the foundation of project management
Key aspects: effort and schedule estimation, quality planning, risk mgmt., …
Outputs of all can be documented in a PMP, which carries all relevant info about project
Besides PMP, a detailed project schedule maintains tasks to be done in the project
![Page 77: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/77.jpg)
Project Planning 77
Homework
Go through the chapter 4 Quiz from this chapter after Eid
![Page 78: Planning a Software Project](https://reader036.vdocument.in/reader036/viewer/2022081512/568130fa550346895d9724ec/html5/thumbnails/78.jpg)
Project Planning 78
Homework Suppose that you are required to build a School Management System.
As per initial estimate, its size is expected to be around 32 KLOC. You have judged by your experience that the Complexity of the system is Very High (1.30), the Programmer Capability is High (0.86), and the Application Experience of the team is Very Low (1.29). All other factors have a nominal rating. Use COCOMO guidelines to find out the following: -
Effort Adjustment Factor (EAF) Initial effort estimate (Ei). Adjusted Effort Estimate Phase wise distribution of Effort among: Product Design, Detailed
Design, Code &Unit Testing and Integration & Testing. Total duration in Months using COCOMO