1. Software Project Management
CS7127
By
K.Sridhar Patnaik
Associate Professor
Department of Computer Science & Engg
Birla Institute of Technology
Mesra,Ranchi(India)
Email:kspatnaik@bitmesra.ac.in
18-04-2015 SPM_KSP_SP2015 1
2. Introduction
• Worldwide, Half million PMs execute about a
million S/w Projects each year producing s/w
worth $600 billion.
• Many of these projects fail.(not fulfilling
customers quality expectations/fail to deliver
within budget and on schedule.
• 1/3 of them have cost and schedule overruns.
• Why s/w projects fail?
18-04-2015 SPM_KSP_SP2015 2
3. Why s/w projects fail?
• Improper management.
Ex:major reasons –unclear objectives,bad
planning, new technology, lack of project
management methodology, insufficient staff.
(New Technology and insufficient staff are risks
whose management is also a part of SPM)
What effective management techniques a PM
can use to improve the chance of success?
18-04-2015 SPM_KSP_SP2015 3
4. Management Techniques
• Proposal writing
• Project planning and scheduling
• Project costing
• Project monitoring and reviews
• Personnel selection and evaluation
• Report writing and presentations
18-04-2015 SPM_KSP_SP2015 4
5. Types of Plan
Plan Description
Quality plan Describes the quality procedures and
standards that will be used in a project.
Validation plan Describes the approach, resources and
schedule used for system validation.
Configuration
management plan
Describes the configuration management
procedures and structures to be used.
Maintenance plan Predicts the maintenance requirements of
the system, maintenance costs and effort
required.
Staff development plan. Describes how the skills and experience of
the project team members will be
developed.
18-04-2015 SPM_KSP_SP2015 5
6. Project and Process
• A project is “a temporary endeavor
undertaken to create a unique product,
service, or result.”
• A project ends when its objectives have been
reached, or the project has been terminated.
• Projects can be large or small and take a short
or long time to complete.
18-04-2015 SPM_KSP_SP2015 6
7. S/w Project
• S/w Project has two main activity dimensions:
18-04-2015 SPM_KSP_SP2015 7
Engineering Project Management
Deals with building the system
and focuses on issues: how to
design,test,code and so on.
(Engg. process specify how
Engg .activities : RA&Spec,
Design,Coding ,Testing etc.
Deals with planning &
controlling the Engg. activities
to meet project goals for cost,
schedule & quality.
(Project Management Process
specify how to set milestones,
organize personnel, manage
risks, monitor progress and so
on.)
8. Process
• Technically, a process for a task comprises a
sequences of steps that should be followed to
execute the task.
• For an Organization,The processes are more
than a sequence of steps.(They encapsulate:
experience gained by Engineers & PMs
(learned about successfully executing
projects).
18-04-2015 SPM_KSP_SP2015 8
9. • This course focuses on PMP (Proj. Mgmt.
Processes)
• Does PMs follow processes? It is heard: PM
don’t follow processes and they resist
changes. Experience says that PMs want to
follow processes but if they are reasonable
and will help PM execute their projects better.
18-04-2015 SPM_KSP_SP2015 9
10. Lightweight Processes
• Those that help PMs plan and control their projects
better & that give them the flexibility to handle various
situations.
• Why should PMs follow processes?
• Processes represents collective knowledge ,using them
increases the chance of success.
• Without processes we cannot predict much about the
outcome of project.
• You and the organization cannot learn effectively
without having defined processes
• Processes lower your anxiety level.
18-04-2015 SPM_KSP_SP2015 10
11. SEI-CMM
• What are desirable characteristics of
processes? Ans:CMM(framework).
• CMM specifies desired characteristics of
processes without prescribing specific
processes.
• The objective of CMM is to distinguish mature
and immature process or adhoc process.
18-04-2015 SPM_KSP_SP2015 11
12. SEI-CMM
Immature Process Mature Process
Imply that projects are
executed without many
guidelines and the outcome
of the project depends
largely on the capability of
the team and PLs.
Project is executed by
following defined
processes. Outcome of the
project is less dependent
on people and more on the
processes.( more mature
the processes , the more
predictable the results and
the more well controlled
the projects..18-04-2015 SPM_KSP_SP2015 12
13. Process Capability and Performance
• The range of results that can be expected in a
project when it is executed using a process is
its process capability.
• The actual result achieved in a project
executed using the process is its process
performance.
• Process performance depends on process
capability(To improve performance enhance
capability)
18-04-2015 SPM_KSP_SP2015 13
14. CMM
• The Capability Maturity Model (CMM) is a way
to develop and refine an organization's
processes.
• The model identifies five levels of process
maturity for an organisation. Within each of
these maturity levels are KPAs (Key Process
Areas) which characterise that level, and for
each KPA there are five definitions identified:
18-04-2015 SPM_KSP_SP2015 14
22. KPAs and GOALS
• Level 2(Repeatable)
18-04-2015 SPM_KSP_SP2015 22
Requirements Management Goals
1)s/w requirements are controlled to
establish a baseline for s/w Engg and
Management activities
2)S/w Plans, products and activities are
kept consistent with requirements.
S/w Project Planning 1)Estimates are documented for use in
planning and tracking the Project.
2)Project activities and commitments
are planned and documented.
3)Affected groups and individuals agree
to their commitments relayed to project
23. Project Management at Infosys
• Infosys executes hundreds of projects every
year.
• Quality Dept of Infy has SEPG (s/e
Engg.process group):responsible for
coordinating all the process activities(process
defn, improvement and deployment)
• SEPG also manages all info and data related to
the use of processes(such as the PDB & PCB)
18-04-2015 SPM_KSP_SP2015 23
24. • SEPG provides SQA(s/w quality advisor) to the
project team to assist in defining, following,
training needed for process.
• Infy has many Business units(BU),within BU,a
team headed by PM.PM reports to (business
mgr (BM).BM to BU head.
• Senior Management Involvement comes when
PM fails to resolves problems.
18-04-2015 SPM_KSP_SP2015 24
25. Project Management Process(PMP)
18-04-2015 SPM_KSP_SP2015 25
Project
Planning
Project
Execution
Project Closure
PM creates plan
involves defining
a life cycle
process to be
followed,
estimating the
effort &
schedule, detail
schedule of
tasks, Quality
and Conf.Mgmt,
Risk Mgmt
Involves
executing the
project plan,
Tracking &
controlling the
implementation
of the project
process(monitori
ng)longest in
PMP
Involves systematic wind-up of the project
after customer acceptance. The main goal
here is to learn from Exp so that the
process can be improved. Post project data
analysis constitutes the main activity;
metrics are analysed, process assets are
collected for future use.Process
assets(templates, guidelines used to aid in
managing the process)
26. Project Planning Infrastructure
• How to build institutional memory and use it
to mould an infrastructure for project
planning?
• What were its elements?
• How should past Exp be recorded and made
available for reuse??
• How could Inf keep the infrastructure current?
18-04-2015 SPM_KSP_SP2015 26
27. Elements of Planning Infrastructure.
• PDB(Process D/b)
• PCB(Process Capability Baseline)
• Process Assets
18-04-2015 SPM_KSP_SP2015 27
28. PDB
• Captures the performance data of completed
projects.
• It can be used for planning, estimation ,
analysis of productivity and Quality.
• General Information in PDB: Languages used,
Database used, tools used, size and effort.
18-04-2015 SPM_KSP_SP2015 28
29. Data Captured in the PDB
• Project Characteristics(Project Name, Names of PM and Module Leaders,
BU, Process deployed, the application domain, the H/w platform,
languages used, DBMS used, brief statement of Project goals, info about
risks, duration of project, team size)
• Project Schedule(Expected start and actual start and end dates)
• Project Effort(Initial estimated effort and actual total effort, distribution of
the actual effort among various stages)
• Size (size in terms of LOC, the number of simple, medium or complex
programs, or a combination of these measures, FPs)
• Defects(includes number of defects found in various defect detection
activities, and the number of defects injected in different stages.
18-04-2015 SPM_KSP_SP2015 29
30. General Data about a Project
General Characteristics
Field Name Value for Synergy
ProcessCategory Development
Lifecycle Full
Business Domain Brokerage/Finance
Process Tailoring notes Added group of high impact documents.
First program of each developer was group
reviewed
PeakTeamSize 12
Tools Used VSS for document CM,VAI for source code
Estimated Start 20Jan 2000
Estimated Finish 5 May 2000
EstimatedEffortHrs 3106
EstimationNotes Use case point approach was one method
used for estimation
ActualStart 20Jan 2000
ActualFinish 5May 2000
First Risk Working through link on customer DB
Second Risk Additional Requirements
Third Risk Attrition
RiskNotes Worked in shifts agreed to take
enhancements after acceptance of this
product teambuilding exercise were done.
18-04-2015 SPM_KSP_SP2015 30
32. Defect Data for the Synergy Project
InjectionStages
Detection stages
Req.
Review
Design.
Review
Code
Review
UT SysTesting AT
Requirements 0 0 0 1 1 0
Design 14 3 1 0 0
Coding 21 48 17 6
18-04-2015 SPM_KSP_SP2015 32
33. • If we can separate the defects detected by
stage according to their injection stages,then
we can compute removal efficiencies of the
defect detection stages.
18-04-2015 SPM_KSP_SP2015 33
34. PCB
• Contains data for each project, it represents
the snapshot of the capability of the process
at some point in time in quantitative terms.
• The capability of the process is essentially the
range of outcomes that can be expected by a
project if the process is followed.
18-04-2015 SPM_KSP_SP2015 34
37. • This info can be used in planning. Ex.a PM can
use productivity and the estimated size to
estimate the effort for the project & can use
the distribution of effort to predict the effort
for various phases & to make staffing plans.
• We can use DIR to predict the total number of
defects & can use the distribution of defects
to predict the defect levels for various defect
detection activities.
18-04-2015 SPM_KSP_SP2015 37
38. • DRE or Quality can be used to forecast the
number of defects that may crop up after the
s/w is delivered & to plan for maintenance.
• PCB also serves as process mgmt in the
organization.
18-04-2015 SPM_KSP_SP2015 38
39. Process Assets
• A process encapsulates an organization’s
experience in form of successful recipes.
• Process description usually contain the
sequence of steps to be executed, identify
who executes them, specify the entry and exit
criteria for major steps, and so on.
• To facilitate the use of processes, guidelines,
checklists, templates provides support.
18-04-2015 SPM_KSP_SP2015 39
41. Guidelines Checklists Templates/Forms
Effort & Schedule
estimation guidelines
Requirements analysis
checklist
Requirements Spec.Doc.
Group Review procedure UT & ST plan checklist UT plan Doc
Process Tailoring
guidelines
Conf.Mgmt checklist AT plan Doc
Defect estimation &
monitoring guidelines
Status report checklist Proj.Mgmt Plan
Guidelines for
measurements & data
analysis
Req.review checklist Confg.Mgmt Plan
Risk Mgmt guidelines Functional Design review
checklist
Metrics analysis report
Guidelines for requirement
traceability
Proj.plan review checklist Milestone status report
Defect prevention
guidelines
Code review checklist for
C++
Defect prevention analysis
report
18-04-2015 SPM_KSP_SP2015 41
42. • Activity Checklist: List of activities that
constitute a process step
• Review Checklist: Is to draw the attention of
reviewers to the defects that are likely to be
found in an output.
• Templates: Provide the structure of the
document in which the output of a process or
step can be captured.
18-04-2015 SPM_KSP_SP2015 42
43. Purpose of Process Assets
• To facilitate the use of processes by saving
effort, thereby improving productivity.
• Ex: Using a template to create a document can
be much easier and less time consuming that
creating it from scratch.
• Helps improving the quality of the project.
18-04-2015 SPM_KSP_SP2015 43
44. BOK(body of Knowledge)
• In addition to PDB,PCB and Process assets, a system called BOK is used to
encapsulate exp.BOK is in the form of articles.It contains posted articles
relating to lessons learned and best practices.
• Key topics of BOK:
• Computer & Comm. Services
• Req.Spec.
• Build
• Tools
• Methodologies & Techniques
• Education & Research
• Design
• Reviews,Inspection & Testing
• SQA & productivity
• Proj.Mgmt
18-04-2015 SPM_KSP_SP2015 44
45. Process Planning
• INFY Development Process
• The standard development process used at
Infy resembles the waterfall model, although
the traditional phases have been broken into
smaller phases to allow parallel execution of
phases.
18-04-2015 SPM_KSP_SP2015 45
46. Process Tailoring
• No defined process-whether an organization’s
standard process or the process used in previous
project-will apply to all situations and all projects.
• A defined process must be tailored to suit the
needs of the current project.
• Tailoring is the process of adjusting a previously
defined process of an organization to obtain a
process i.e suitable for the particular business or
technical needs of a project.
18-04-2015 SPM_KSP_SP2015 46
48. SLT Vs DT
Summary-Level Tailoring(SLT) Detailing Tailoring(DT)
In SLT depending on the project
characteristics, the PM applies overall
guidelines for tailoring the standard
process.
The following characteristics are used for
tailoring:
Exp & skill level of the team & the PM.
Peak team size
Clarity of the requirements
Project duration
Application criticality
Covers execution of activities, their
review, and documentation needs.
When DT is finished, the sequence of
activities to be performed in the process
for the project is defined. These
definitions are then used to plan &
schedule activities and form the basis of
the project execution.
18-04-2015 SPM_KSP_SP2015 48
49. Tailoring for short Duration Projects
• Infy observed that the duration of the of projects has
decreased over the years,and there is increased demand
for projects of short duration.
• Such projects require processes to be tailored to allow
maximum parallelism & very tight project monitoring &
control.
• The process tailoring depends on the clarity of
requirements,the exp.level of team or the PL,size of the
team etc.
18-04-2015 SPM_KSP_SP2015 49
50. Schedule related Guidelines
• Timeboxing:several week duration cycles are
planned,& a working system is delivered after
each cycle.
• Mini-milestone:To keep tight control on the
timeboxes,mini-milestones-milestones within
the cycle-are also set.
• See table 3.1 :Tailoring guidelines for a short
duration project.
18-04-2015 SPM_KSP_SP2015 50
51. Requirements Change Management
• Req.change/change in requirements can come at any
time during the life of a project(or even after that).
• The later in the life cycle the requirements change, the
more severe the impact on the project.
• It is better to prepare to handle change requests as &
when they come.
• Uncontrolled changes to requirements can have an
adverse effect on the cost,schedule & quality of the
project.
• Req changes can account for as much as 40% of the
total cost.
18-04-2015 SPM_KSP_SP2015 51
52. Change Management Process
• During project planning ,a PM decides which process is
to be followed for handling change requests.
• The planned process is discussed with the customer so
that both the customer & the vendor are in agreement
about how to mange changes.
• When a request for a requirements change comes
in,the requirements change mgmt process must be
executed.
• Because change requests have cost implications, it is
necessary to have a clear agreement on payment.
18-04-2015 SPM_KSP_SP2015 52
53. Steps of CM process
• 1)Log the changes
• 2)Perform an impact analysis on the work products
• 3)Estimate the effort needed for the change requests.
• 4)Reestimate the delivery schedule.
• 5)Perform a cumulative cost impact analysis.
• 6)Review the impact with senior mgmt if thresholds
are exceeded.
• 7)Obtain customers sign-off.
• 8)Rework work products.
18-04-2015 SPM_KSP_SP2015 53
54. Effort Estimation and Scheduling
• Effort estimation usually takes place in the
early stages of a project.It may be redone
later when more information becomes
available.
• Highly precise estimates are generally not
needed. Reasonable estimates can do.
Comparison can be done once actual effort is
known.General principle:”work expands to fill
the available time”(Parkinson’s Law)
18-04-2015 SPM_KSP_SP2015 54
55. Effort Estimation Models
Top Down Approach Bottom-up Approach
1)Normally associated with
parametric(Algorithmic )models. Over
estimate is broken down into effort
required for component tasks.
1)Used where project is novel or there is
no historical data available. Component
tasks are identified and sized and
individual estimates are aggregated.
2)COCOMO,FPA 2)This approach is most appropriate at
the later ,more detailed stages of project
planning.If used early in project cycle,the
estimator will have to make some
assumptions about the characteristics of
final system(Ex.No. & size of modules.)
18-04-2015 SPM_KSP_SP2015 55
56. Effort Estimation
• At Infy, estimation generally takes place after analysis. That
is ,when a PM estimates the effort, the requirements are
well understood.
• Ex,the req.phase is sometimes executed as a separate
project from the S/w development project.
• Infy follows multiple estimation approaches:
• The Bottom-up Estimation Approach.
• The Top-Down Estimation Approach
• The Use Case Points Approach
• Because the types of projects undertaken at Infy
vary substantially. The Buttom-up is preferred and
recommended.
18-04-2015 SPM_KSP_SP2015 56
57. Buttom-up Estimation Approach
• Task Unit Approach: The PM divides the s/w under development into
Major programs(units).Each program unit is then classified as
simple,medium and complex based on certain criteria.
• For each unit PM defines a standard effort for coding & self-
testing(together called the build effort)
• The standard build effort can be based on past data from a similar project,
from the internal guidelines available,or some combination of these.
• Once the number of units are known & the estimated build effort for each
program is selected,the total effort for the build phase is known.
• From the build effort ,the effort required for the other phases & activities
is determined as a percentage of the coding effort.
• From the PCB or PDB,the distribution of effort in a project is known.The
PM uses this distribution to determine the effort for other phases and
activites.From these estimates ,the total effort for the project is known.
18-04-2015 SPM_KSP_SP2015 57
58. Summary
1)Identify programs in the system & classify them as S/M/C.As much as possible use
either the provided standard definitions or definitions from past projects.
2)If a project-specific baseline exists, get the average build effort for S/M/C programs
from the baseline.
3)If the project –specific baseline doesn't exists,use project
type,technology,language,and other attributes to look for similar projects in the
PDB.Use data from these projects to define the build effort of S/M/C programs.
4)If no similar project exists in PDB & PCB,use the avg build effort for S/M/C programs
from the general PCB.
5)Use project –specific factors to refine the build effort for S/M/C programs.
6)Get the total build effort using the build effort of S/M/C programs & the counts for
them.
7)Use the effort distribution given in the PCB or for similar projects given in the
PDB,estimate the effort for other tasks & the total effort.
8)Refine the estimates based on the project specific factors.
Note:If many projects of a type are being executed,you can build a project –specific
capability baseline similar to general base line but use only data from specific projects.
18-04-2015 SPM_KSP_SP2015 58
59. Top-Down Estimation Approach
1)Get the estimate of the total size of the s/w in FPs.
2)Using the productivity data from the project-specific
Capabilty Baseline.,from the general PCB,or from similar
projects,fix the productivity level for the project.
3)Obtain the overall-effort estimate from the productivity
and size estimates.
4)Use effort distribution data from the PCB/similar
projects to estimate the effort for the various phases.
5)Refine the estimates,taking project-specific factors into
consideration.
18-04-2015 SPM_KSP_SP2015 59
60. Use Case Points Approach
1)Classify each UC as S/M/C.The basis of this
classification is the No.of trans in UC,including
secondary Scenario.
18-04-2015 SPM_KSP_SP2015 60
UC Type Description Factor
Simple 3 or Fewer Trans. 5
Medium 4-7 Trans. 10
Complex >7 Trans. 15
61. 2)Obtained Unadjusted UCPs as a weighted sum of
factors for the UCs in the application.
3)Adjusted the raw UUCP to reflect the project’s
complexity & the exp.of the people on the project.
TCF=0.6+0.01*TFactor
4)Similarly compute EF(Environment Factor)
EF=1.4+(-0.03*EFactor)
5)UCP(Use Case Points)=UUCP*TCF*EF.
18-04-2015 SPM_KSP_SP2015 61
62. Technical Factors & Weights
Seq No. Factor Weight
1 Distributed System 2
2 Response & Throughput performance
Objectives
1
3 End User Efficiency(Online) 1
4 Complex Int Processing 1
5 Code Reusable 1
6 Easy to Install 0.5
7 Easy to use 0.5
8 Portable 2
9 Easy to change 1
10 Concurrent 1
11 Includes special security features 1
12 Provides direct access to 3rd parties 1
13 Special user training facilities required 1
18-04-2015 SPM_KSP_SP2015 62
63. Environmental Factors for Team &
Weights
Seq No. Factor Weight
1 Familiar with internet
process
1.5
2 Application exp 0.5
3 OO Exp. 1
4 Lead Analyst Capability 0.5
5 Motivation 1
6 Stable Req. 2
7 PartTime Workers -1
8 Difficult Prog.Langs -1
18-04-2015 SPM_KSP_SP2015 63
64. • For effort estimation ,assign,on an avg,20
Person-Hrs/UCP for entire Life cycle.This will
give a rough estimate. Refine this as:
• Count how many factors are <3 & how many
>3.If total no.of factors <3 are few,20 Person-
Hrs/UCP is suitable. If there are many,use 28
Person-Hrs/UCP.Hence the range is 20-28
Person-Hrs/UCP and the PM can decide which
value to use depending on various factors.
18-04-2015 SPM_KSP_SP2015 64
65. Effectiveness of the Overall Approach
1)Compare Estimated with Actual Effort.
2)PDB includes information on the estimated
effort as well as the actual effort.
3)Exp.shows that 50% of the projects are within
25% of the estimated effort.
18-04-2015 SPM_KSP_SP2015 65
66. Scheduling
• Two Sub activities:
• A)Determining the over all schedule(the
project duration)with major milestones.
• B)Developing the detail schedule of the
various tasks.
18-04-2015 SPM_KSP_SP2015 66
67. Overall Scheduling
1)We can gain some flexibility in determining the
schedule by controlling the staffing level, but this
flexibility is limited.
2)Because of flexibility, building strict guidelines for
scheduling may not be desirable.
3)The project schedule is usually determined in the
larger context of business plans, which impose
some schedule requirements.
4)Whenever possible ,exploit schedule flexibility to
satisfy such requirements.
18-04-2015 SPM_KSP_SP2015 67
68. 5)One method is to use scheduling guidelines more for
checking the feasibility of the schedule than for determining
the schedule itself.
6)Scatter plot: Schedule Vs Effort.
Schedule=23.46(effort)0.313
7)From the distribution of points :schedule is not a function
solely of effort.
8)The determined schedule can ,however, be used as a
guideline or check of the schedules' reasonableness ,which
might be decided based on other factors.
9)Similarly ,the schedule & effort data from similar projects
can be used to check the reasonableness of any proposed
schedule.
18-04-2015 SPM_KSP_SP2015 68
69. 10)PMs often use a rule of thumb: square root check ,to check
the schedule of medium-sized projects.
If Effort=50pm,schedule=7 to 8 months(full tine resources)
11)A schedule is accepted only if the head of the business unit
to which the project belongs agrees to provide the necessary
resources. If necessary resources are not available ,the
schedule must be adjusted.
12)If the project execution depends on external
factors(completion of another project /availability of certain
s/w),the schedule must be adjusted to accommodate these
factors.
13)Once the overall duration of the project is fixed, the
schedule for major milestones must be determined.
18-04-2015 SPM_KSP_SP2015 69
70. 14)To determine milestones, first understand the
manpower ramp-up that usually takes place in a project.
15)The number of people in s/w project tends to follow
the Rayleigh curve.
16)For ease of scheduling ,particularly for smaller
projects, all the required people are often assigned
together around the start of the project. This approach
can lead some people being unoccupied at the start &
toward the end. This slack time is often used for training.
17)This training consume fair amount of effort(See PCB)
18)The slack time available at the end can be used for
documentation and other closure tasks.
18-04-2015 SPM_KSP_SP2015 70
72. 19)The schedule distribution differs from the
effort distribution.
Effort Distribution-1:4:1
Schedule Distribution-1:2:1
18-04-2015 SPM_KSP_SP2015 72
73. Detailed Scheduling
1)Once the milestones & the resources are fixed, it
is time to set the detailed scheduling.
2)The PM breaks the task into small schedulable
activities in a hierarchical manner.
3)For each task, the PM estimates the time required
to complete it & assigns a suitable resource so that
overall schedule is met.
4)PM uses Microsoft Project(MSP)/spreadsheet for
detailed scheduling.
5)Detailed project schedule is never static.
18-04-2015 SPM_KSP_SP2015 73
74. The Norden/Rayleigh Curve
𝑚 𝑡 =
𝑑𝑦
𝑑𝑡
= 2𝐾𝑎𝑡𝑒−𝑎𝑡2
(1)
Manpower represents in person /unit time as a
function of time. It is expressed in PY/YR.
Where dy/dt is the manpower utilization
rate/unit time,’t’ is elapsed time,’a’is the
parameter that affects the shape of the curve
&’K’ is the area under the curve in*0, ∞]
Integrating equation (1),on [0,t],we get
18-04-2015 SPM_KSP_SP2015 74
75. 𝑦 𝑡 = 𝐾[1 − 𝑒−𝑎𝑡2
] (2)
Where y(t) is the cumulative manpower used upto
time t.
y(0)=0,y(∞)=K,the cumulative manpower is null at
the start of the project & grows monotonically
towards the total effort K(area under the curve).
𝑑2
𝑦
𝑑𝑡2
= 2𝐾𝑎𝑡𝑒−𝑎𝑡2
1 − 2𝑎𝑡2
= 0
𝑡 𝑑
2
=
1
2𝑎
(3)
18-04-2015 SPM_KSP_SP2015 75
76. ‘𝑡 𝑑 ’=time where max effort rate occurs. i.e,The
point ‘𝑡 𝑑 ’on the time scale should correspond very
closely to the total project development time.
𝐸 = 𝑦 𝑡 = 𝐾 1 − 𝑒−
𝑡 𝑑
2
2𝑡 𝑑
2
= 𝐾 1 − 𝑒−0.5
E=y(t)=0.3935K
Actually if we divide the life cycle of a project into
phases,each phase can be modeled by a curve of
the form(see Fig.)
18-04-2015 SPM_KSP_SP2015 76
77. From equation (3),the peak manning time is
related to ‘a’. Therefore,
𝑎 =
1
2𝑡 𝑑
2
Substitute ‘𝑎′ in equation (1)
𝑚 𝑡 =
𝐾
𝑡 𝑑
2 𝑡𝑒
−
𝑡2
2𝑡 𝑑
2
18-04-2015 SPM_KSP_SP2015 77
78. At time 𝑡 = 𝑡 𝑑,the peak manning, 𝑚(𝑡 𝑑)
denoted by 𝑚0.thus peak manning is
𝑚0 =
𝐾
𝑡 𝑑 𝑒
K=total project cost(or effort) in PY.
𝑡 𝑑=deliver time in years
𝑚0=no. of persons employed at the peak.
The avg rate of s/w team build –up=
𝑚0
𝑡 𝑑
18-04-2015 SPM_KSP_SP2015 78
79. Difficulty metric
𝑚′
𝑡 = 2𝐾𝑎𝑡𝑒−𝑎𝑡2
1 − 2𝑎𝑡2
Then,for t=0,
𝑚′
0 =
𝐾
𝑡 𝑑
2
The ratio is denoted by ‘D’ in P/Y called as
difficulty.
‘D’ in terms of ′𝑚0′ is 𝐷 =
𝑚0 𝑒
𝑡 𝑑
18-04-2015 SPM_KSP_SP2015 79
80. Manpower Build-up
𝐷′
𝑡 𝑑 =
−2𝐾
𝑡 𝑑
3
𝑃𝑒𝑟𝑠𝑜𝑛
𝑦𝑒𝑎𝑟3
𝐷′
𝐾 =
1
𝑡 𝑑
2 𝑦𝑒𝑎𝑟−2
In practice , 𝐷′
𝐾 will always be very much
smaller than absolute value of 𝐷′
𝑡 𝑑 .
This difference in sensitivity can be analysed as:
18-04-2015 SPM_KSP_SP2015 80
81. Project A:cost=20 PY & 𝑡 𝑑=1 year
Project B:cost=120PY & 𝑡 𝑑 = 2.5 𝑦𝑒𝑎𝑟𝑠
The derivative values are
Project A: 𝐷′
𝑡 𝑑 =-40& 𝐷′
𝐾 =1
Project B:𝐷′
𝑡 𝑑 =-15.36 &𝐷′
𝐾 =0.16
Hence s/w development is time sensitive.
Putnam observed that the difficulty derivative
relative to time played an important role in
explaining the behaviour of s/w development.
18-04-2015 SPM_KSP_SP2015 81
82. If the project scale is increased the development time
also increases to such an extent that the quantity
𝐾
𝑡 𝑑
3
remains constant around a value ,which could be 8,15,27.
This quantity is ‘𝐷0 =
𝐾
𝑡 𝑑
3
𝑃𝑒𝑟𝑠𝑜𝑛
𝑦𝑒𝑎𝑟2
If 𝐷0=8 refers to entirely new s/w with many interfaces &
interactions with other systems.
If 𝐷0=15 refers to new stand alone system
If 𝐷0=27 refers to the s/w that is rebuilt from existing s/w.
18-04-2015 SPM_KSP_SP2015 82
83. Putam also observed that 𝐷0 could vary slightly
from organization to organization.
Depending on the avg skill of
analysts,developers and the mgmt involved.
In practice 𝐷0 has strong influence on the shape
of the manpower distribution.The larger 𝐷0
is,the steeper manpower distribution is, and the
faster the necessary manpower build-up will be.
For this reason, 𝐷0 is called manpower build up.
18-04-2015 SPM_KSP_SP2015 83
84. Quality Planning
1)How PMs at Infy set the quality goals for their
projects?
2)How they develop a plan to achieve these
goals using intermediate quality goals to
monitor their progress?
18-04-2015 SPM_KSP_SP2015 84
85. Quality Concepts
1)Ensuring that the final s/w is of high quality is one
of the prime concerns of a PM.
2)But how is s/w quality defined?
3)Not easily definable because s/w has many
possible quality characteristics.
4)In practice quality mgmt often revolves around
defects. Hence we DDD(Delivered Defect Density:
No. of defects/unit size in the delivered s/w as the
definition of quality)
5)This definition is currently the de facto
(concerning fact)industry standard.
18-04-2015 SPM_KSP_SP2015 85
86. • The aim of a s/w project is to deliver the s/w
with as few defects as possible.
• Defect: No precise definition: In general we
can say a defect in s/w is something that
causes the s/w to behave in a manner that is
inconsistent with the requirements or needs
of the customer.
18-04-2015 SPM_KSP_SP2015 86
87. Defect Injection & Removal Cycle
• S/w development is a highly people oriented activity and
hence error-prone.
• Defects can be injected in s/w at any stage during its
evolution.
• The injection stages: RA,high level design, detailed design,
and coding.
• For delivery of high-quality s/w, active removal of defects is
necessary.
• This removal takes place through quality control activities
of reviews & testing.
• Because the cost of defect removal increases as the latency
of defects(time gap between the introduction and its
detection)increases.
18-04-2015 SPM_KSP_SP2015 87
88. • Activities of defect removal include:
Requirements reviews.
Design Reviews.
Code Reviews.
Unit Testing.
Integration Testing.
System Testing.
Acceptance Testing.
Review of plan documents also help in improving
the quality of the s/w.
18-04-2015 SPM_KSP_SP2015 88
90. Procedural Approach to Quality
Management(QM)
1)We detect defects by performing reviews or testing.
2)Reviews are structured and human- oriented process.
3)Testing is a process of executing s/w(or parts of it)in an
attempt to identify defects.
4)In the procedural approach to QM, procedures &
guidelines for review & testing activities are established.
5)The procedural approach is the execution of certain
processes at defined points to detect defects.
18-04-2015 SPM_KSP_SP2015 90
91. 6)This approach does not allow claims to be made about the
percentage of defects removed or the quality of the s/w following the
procedure’s completion.
7)i.e merely executing a set of defect removal procedures does not
provide a basis for judging their effectiveness or assessing the quality
of the final code.
8)Such an approach is highly dependent on the quality of the
procedure & the quality of execution.
9)Ex.If the test planning is done carefully & the plan is thoroughly
reviewed, the quality of the s/w after performance of the testing will
be better than if testing was done but the test plan was not carefully
thought out & the review was done perfunctorily(performed merely as
a routine duty).
10)Lack of quantitative means is the major draw back;the only factor
visible to PMs is whether the quality control tasks are executed.
18-04-2015 SPM_KSP_SP2015 91
92. Quantitative Approach to QM
• QQM has two key aspects:
1)Setting a Quantitative Quality Goal
2)Managing the s/w development process
quantitatively so that this quality goal is met.
Quantitatively control the Quality of the s/w:
a)S/w Reliability Models
b)DRE
c)Defect Prediction(DDD)
c)SPC
18-04-2015 SPM_KSP_SP2015 92
93. QQM Planning
1)Setting the Quality goal
2)Estimating Defects for other Stages
3)Quality Process Planning
18-04-2015 SPM_KSP_SP2015 93
94. Setting the Quality Goal
PMs at Infy set quality goals during the planning
stages. The quality goal for a project generally is
the expected number of defects found during
AT.
Two primary sources can be used for setting the
quality goal:
a)Past data from similar projects
b)Data from the PCB.
18-04-2015 SPM_KSP_SP2015 94
95. • If you used data from similar projects:
𝐷𝐴𝑇(𝑐𝑢𝑟𝑟𝑒𝑛𝑡𝑃) = 𝐷𝐴𝑇(𝑠𝑖𝑚𝑖𝑙𝑎𝑟𝑃) ×
𝐸𝑐𝑢𝑟𝑟𝑒𝑛𝑡𝑃
𝐸 𝑇𝑜𝑡𝑒𝑓𝑓𝑜𝑟𝑡𝑆𝑖𝑚𝑖𝑙𝑎𝑟𝑃)
𝐷𝐴𝑇(𝑐𝑢𝑟𝑟𝑒𝑛𝑡𝑃)
= 𝑁𝑜 𝑜𝑓 𝑑𝑒𝑓𝑒𝑐𝑡𝑠 𝑓𝑜𝑢𝑛𝑑 𝑑𝑢𝑟𝑖𝑛𝑔 𝐴𝑇 𝑜𝑓 𝑐𝑢𝑟𝑟𝑒𝑛𝑡 𝑃𝑟𝑜𝑗𝑒𝑐𝑡.
𝐷𝐴𝑇(𝑠𝑖𝑚𝑖𝑙𝑎𝑟𝑃)
= No of defects found during AT of similar Project
𝐸𝑐𝑢𝑟𝑟𝑒𝑛𝑡𝑃=Estimated effort of current project
𝐸 𝑇𝑜𝑡𝑒𝑓𝑓𝑜𝑟𝑡𝑆𝑖𝑚𝑖𝑙𝑎𝑟𝑃)=Total effort of the similar project.
• If you use data from the PCB:
• The following steps is used:
18-04-2015 SPM_KSP_SP2015 95
96. i)Set the quality goal in terms of defects/FP
ii)Estimate the expected productivity level for the project.
iii)Estimate the size in FP as(expected productivity *estimated effort)
iv)Estimate the number of AT defects as (quality goal*estimated size)
OR
i)Set the quality goal in terms of DRE.
ii)Estimate the total number of defects from the Defect Injection
Rate(DIR) & the estimated size,or by the effort-based DIR and the
effort estimate.
iii)Estimate the number of AT defects from the total number of defects
& the quality goal.
18-04-2015 SPM_KSP_SP2015 96
97. Estimated defects for other stages
The approach for estimating defect levels for other
phases is similar to the approach for estimating defects in
AT.
1)For the estimate of the total number of defects that will
be introduced ,you forecast the defect levels for the
various testing stages by using the percentage
distribution of defects as given in PCB.
Also, you can forecast the defect for the various phases
based on the past data from similar projects.
2) At minimum, you estimate the defects uncovered in
system & integration testing.
18-04-2015 SPM_KSP_SP2015 97
98. Quality Process Planning
1)If the quality goal is based on the data from similar
projects/PCB and the goal is higher than that of the
similar projects, it is unreasonable to expect that
following the same process as used in the earlier projects
will achieve the higher quality goal.
2)If the same process is followed ,the reasonable
expectation is that similar quality levels will be achieved.
Hence, if a higher quality level is desired ,the process
must be suitably upgraded.
3)A new strategy will be needed –a combination of
training, prototyping, testing, reviews,and,in particularly
,defect prevention.
18-04-2015 SPM_KSP_SP2015 98
99. 4)Different levels of testing are deployed in a
project. You can modify the overall testing by
adding or deleting some testing steps.In addition
you can enhance the approach to testing by, Ex.
performing a group review of the test plan & test
results.
5)The choice of work products to be reviewed is
generally made by the PM. The set of documents
reviewed may, in fact, change from project to
project. It can be adjusted according to the quality
goal.
18-04-2015 SPM_KSP_SP2015 99
100. 6)You can use the data in PCB to estimate the
effects of the proposed process changes on the
effort and schedule planned for the project.
Once the process changes are identified, their
effects are predicted based on past
exp.(acceptable because the changes are minor)
18-04-2015 SPM_KSP_SP2015 100
101. Defect Prevention Planning
1)Defect Prevention(DP)activities are intended to
improve quality & improve productivity.
2)It is generally accepted that some defects present
in the system will not be detected by various QC
activities & will inevitably fine their way into the
final system.
3)Hence, the higher the number of defects
introduced in the s/w during development, the
higher the number of residual defects that will
remain in the final delivered system.
18-04-2015 SPM_KSP_SP2015 101
102. The over all DRE of a process is the percentage of total
defects that are removed by the various QC activities
before the s/w is delivered. For a stable process DRE is
also stable.Higher the DIR ,poor the quality is.
DP also has productivity benefits:
The basic defect cycle during the building of s/w is that
developers introduce defects & later identify & remove
them.(i.e DI and DR cycle is a waste of effort).
Hence not to introduce defects in the first place; then the
effort required to identify & remove them will not be
needed.
18-04-2015 SPM_KSP_SP2015 102
103. • If you inject fewer defects,fewer defects must be removed,the
effort required will be less thereby increasing Productivity.
• How is DP done?
DP activities at the project level:
a)Identify a DP team within the project.
b)Have a kick-off meeting & identify existing solutions.
c)Plan for DP
-Set DP goals for the project.
-See that the DP team is trained on DP & causal analysis if needed.
-Define the frequency at which DP activities will be carried out.
18-04-2015 SPM_KSP_SP2015 103
104. d)Do DP
-At defined points ,collate defects data.
-Identify the most common types of defects by doing Pareto
Analysis.
-Perform causal analysis & prioritize the root causes.
-Identify & develop solutions for the root causes.
-Implement the solutions.
-Review the status & benefits of DP at the project milestones.
e)Capture Learning
-In the metrics analysis report & BOK, capture the learning &
benefits you have obtained.
-Submit all outputs of DP as a part of the process assets.
18-04-2015 SPM_KSP_SP2015 104
105. • There are two measures that have a strong
influence on the outcomes of software
projects: 1) Defect potentials; 2) Defect
removal efficiency.
The term “defect potentials” refers to the total
quantity of bugs or defects that will be found in
five software artifacts: requirements, design,
code, documents, and “bad fixes” or secondary
defects
18-04-2015 SPM_KSP_SP2015 105
106. • The term defect removal efficiency refers to
the percentage of total defects found and
removed before software applications are
delivered to customers.
• All software managers and quality assurance
personnel should be familiar with these
measurements, because they have the largest
impact on software quality and also software
costs and schedules of any known measures
18-04-2015 SPM_KSP_SP2015 106
107. • As of 2008 the U.S. average for defect potentials is
about 5 defects per function points. The U.S. average
for defect removal efficiency is only about 85%. The
U.S. average for delivered defects is about 0.75
defects per function point.
• Note that defect potentials should be measured with
function points and not with lines of code. This is
because most of the serious defects are not found in
the code itself, but rather in requirements and design.
18-04-2015 SPM_KSP_SP2015 107
108. • Requirements defects 1.00
• Design defects 1.25
• Coding defects 1.75
• Documentation defects 0.60
• Bad fixes 0.40
• Total 5.0
The measured range of defect potentials ranges from
just below 2.00 defects per function point to about
10.00 defects per function point. Defect potentials
correlate with application size. As application sizes
increase, defect potentials also rise
18-04-2015 SPM_KSP_SP2015 108
109. “defect removal efficiency” refers to the
percentage of the defect potentials that will be
removed before the software application is
delivered to its users or customers. As of 2008
the U.S. average for defect removal efficiency is
about 85%.
18-04-2015 SPM_KSP_SP2015 109
110. DRE
DRE=E/(E+D)
E=No of errors found before the delivery of the s/w
to the end user
D=No of defects found after the delivery.
As ‘D’ increases DRE decreases, ideal value of DRE is
1,which means no defects found after delivery.
DRE encourage s/w team to institute techniques for
finding as many as errors as possible before
delivery.
18-04-2015 SPM_KSP_SP2015 110
111. DRE = (Defect removed during a development
phase/Defects latent(hidden) in the product at
that phase) X100%
Since the latent defects in a s/w product is
unknown at any point in time ,it is approximated
by adding the number of defects removed
during the phase to the number of defects
found later(but that existed during that phase)
18-04-2015 SPM_KSP_SP2015 111
112. Risk Management(RM)
1)A s/w project is a complex undertaking.
Unforeseen events may have an adverse impact on
a project’s cost, schedule,or quality.
2)Risk Management is an attempt to minimize the
chances of failure caused by unplanned events.
3)The aim of RM is an attempt to minimize the
chances of failure caused by unplanned events.
4)The aim is not to avoid getting into projects that
have risks but rather to minimize the impact of risks
in the projects that are undertaken.
5)”Anything worth doing has risks”-N.R.N.Murty
18-04-2015 SPM_KSP_SP2015 112
113. Concepts of Risks and RM
1)Risks are those events or conditions that may occur, and whose
occurrence, if it does take place, has a harmful or negative effect on
project.
2)Risks should not be confused with events & conditions that require
mgmt intervention or action.
3)A PM must deal with and plan for those situations that are likely to
occur but whose exact nature is not known beforehand; such
situations, however, are not risks.
Ex,it is almost certain that defects will be found during s/w testing, so
a reasonable project must plan to fix these defects when they are
found.Similarly,it is almost certain that some change requests will
come,so project mgmt must be prepared for changes & plan
accordingly to handle such normal events.
18-04-2015 SPM_KSP_SP2015 113
114. Example
Consider a computer show for which an important
goal is to provide uninterrupted computer services.
For this goal, one clear risk is electric power failure.
The power may fail or may not fail. If it does fail,
even for a second, the computer services will be
affected substantially(the m/c’s will have to reboot,
data will be lost, and so on).If this case is
unacceptable(i.e, if the cost of power failure is
high),UPS can be deployed to minimize its
consequences.
18-04-2015 SPM_KSP_SP2015 114
115. Example cont.
If it is suspected that the power may go out for a
long period,a back up generator may be set up to
minimize the problem.
With these risk management systems in place, if the
power does not go out ,even for a long period, the
show related goal will not be compromised.
From this example it is clear that RM entails
additional cost. The RM can be considered cost-
effective only if the cost of RM is considerably less
than the loss incurred if the risk materializes.
18-04-2015 SPM_KSP_SP2015 115
116. If the loss due to power failure is low,the cost of UPS is not
justified-A situation that prevails, for ex. in homes.
Its not easy to measure the value of RM, particularly in
hindsight(understanding of a situation or event only after it
has happened or developed.)
If the power fails for one-half hr during the show,the value
provided by UPS & generator might be calculated as the
‘savings’ achieved by having the computers running while the
power was out.
Suppose ,however, if the power supply does not fail even for a
second & therefore UPS & generator are not used.Does it
mean that the expenditure on these components was waste?
No,Because the power could have failed.
18-04-2015 SPM_KSP_SP2015 116
117. 1)A risk, is a probabilistic event-it may or may not
occur.
2)If the risk does not materialize, the value of using
risk management cannot be directly measured in
terms of value or output produced. Because risk
events likely occur infrequently, the chances are
high that risk mgmt systems will not be used during
the project.
3)It is this probabilistic nature of risks & the inability
to always realize the direct value of risk mitigation
efforts that make it difficult to manage risk.
18-04-2015 SPM_KSP_SP2015 117
118. Hence ,the first step in RM is to identify the
possible risks(power failure) & to assess the
consequences(loss).Once you have done risk
assessment ,you can develop a RM plan(UPS).
18-04-2015 SPM_KSP_SP2015 118
120. One way to prioritize risks:
RE(R )=Prob(R)*Loss(R)
RE-Risk Exposure
Prob(R)-Probability of a risk R occurring .
Loss(R)-Total loss incurred if the risk materializes
18-04-2015 SPM_KSP_SP2015 120
121. Risk Management & Project Execution
18-04-2015 SPM_KSP_SP2015 121
Other Factors
Information Control
Project’s Process
Risk Assessment
Risk Monitoring
Managing
Risks
122. Risk Identification(RI)
1)Methods that can aid RI include checklists of possible
risks,surveys,meetings and brainstorming,review of
plans,processes,work products.
2)Checklists of frequently occurring risks are probably the
most common tool for risk identification.
3)At Infy, the commonly occurring risks for projects have
been compiled from survey of previous projects.
4)PM can also use the PDB to get information about risks
and Risk Mgmt on similar projects
18-04-2015 SPM_KSP_SP2015 122
123. Risk Prioritization
1)Proiritization requires analysing possible effects
of the risk event in case it actually occurs.i.e if the
risk materializes, what will be the loss to the
project?
2)The loss could include a direct loss, a loss due to
business opportunity or future business, a loss due
to diminished employee morale etc.
3)Based on the possible consequences and the
probability of the risk event occurring, we can
compute the RE(Risk Exposure),which we can then
use for prioritizing risks.
18-04-2015 SPM_KSP_SP2015 123
124. Risk Categories & Impact Categories
Probability Range
Low 0.0-0.3
Medium 0.3-0.7
High 0.7-1.0
18-04-2015 SPM_KSP_SP2015 124
Level of Consequences Range
Low 0.0-0.3
Medium 3.0-7.0
High 7.0-9.0
Very High 9.0-10.0
Risk Categories
Impact Categories
125. Method for risk prioritization
a)For each risk, rate the probability of its happening as
low, medium, or high. If necessary ,assign probability
values in the ranges given for each rating.
b)For each risk, assess its impact on the project as low,
medium,high,or very high. If necessary, assign a weight
on a scale of 1 to 10.
c)Rank the risks based on the probability & effects on the
projects;for ex, a high-probability, high-impact item will
have higher rank than a risk item with a medium
probability and high impact.In case of conflict ,use your
judgement .
d)Select the top few risk items for mitigation & tracking.
18-04-2015 SPM_KSP_SP2015 125
126. • This approach for prioritizing risks helps focus
attention on high risks,but it does not help
you in making a CB analysis of risk mitigation
options.i.e by stating the consequences in
terms of a scale rather than in terms of money
value, this method does not allow you to
calculate the expected loss in financial
terms,Hence you cannot analyze whether a
certain risk mitigation strategy,costing a
certain amount,is woth employing.
18-04-2015 SPM_KSP_SP2015 126
127. Such an analysis is generally not needed,
however, because the focus of RM is usually on
managing risks at the lowest cost & not on
whether RM itself is beneficial.
On the other hand ,if you must make a decision
about whether a risk should be managed or
whether it is financially smarter to leave it
unmanaged, you must understand the financial
impact of the risk.
18-04-2015 SPM_KSP_SP2015 127
128. Risk Control
1)Once the PM has identified & prioritized the
risks,the question becomes what to do about
them? The basic goal of RM: i)prepare a plan so
that their consequences are minimal.
ii)minimize the effects of risk: Risk Control.
2)RMP: Risk Management Plan
3)Risk Monitoring & Tracking
18-04-2015 SPM_KSP_SP2015 128
129. RMP
1)To mange the risks,proper planning is
essential.The main task is to identify the actions
needed to minimize the risk consequences(Risk
Mitigation Steps)
see table
18-04-2015 SPM_KSP_SP2015 129
130. Risk Monitoring & Tracking
1)Risk prioritization & consequent planning are based on
the risk perception at the time the risk analysis is
performed.
2)The first risk analysis takes place during project
planning,& the initial RMP reflects the view of situation at
that time.
3)Because risks are probabilistic events, frequently
depending on external factors, the threat due to risks
may change with time as factors change.
4) Clearly,then ,the risk perception may also change with
time. So the risk mitigation steps indertaken may affect
the risk perception
18-04-2015 SPM_KSP_SP2015 130
131. 5)Hence risks in a project should not be treated as static
& must be reevaluated periodically .
6)In addition to monitoring the progress of the planned
risk mitigation steps, you must periodically revisit the risk
perception for the entire project.
7)The results of this review are reported in each
milestone analysis report; you report the status of the
risk mitigation steps along with the current risk
perception & strategy.
8)To prepare this report, you make a fresh risk analysis to
determine whether the priorities have changed.
18-04-2015 SPM_KSP_SP2015 131
133. Software Risk
s/w risk is a measure of the probability of its
occurrence and the loss due to its exposure.
s/w risk affects the process of development
,project development and the s/w product itself
.
s/w risk is possible in s/w process, project and
product management.
18-04-2015 SPM_KSP_SP2015 133
134. S/w process risk s/w project risk s/w product risk
Include managerial &
technical procedures
required to be undertaken
for s/w development.
Managerial process –
planning, staffing,
monitoring, QA & control.
Technical procedure-(s/w
engg activities)-RA,D,C,T
and M and S
Arises on account of
operational, organizational
contractual s/w
development factors.
Occur due to conditions &
constraints about resource
relationship with vendors
& contractors. lack of
organizational support.
Funding-project risk occurs
due to initial budgeting
constraints &unreliable
customer payments.
Mainly concerns with the
quality characteristics such
as unstable requirements
specification, not being
able to meet the design
specification affecting s/w
performance & uncertain
test specification.
There is a risk in losing the
business.
18-04-2015 SPM_KSP_SP2015 134
135. They have a close relationship :
If uncertainty in requirement specification
(product risk)affects the resource
estimation(project risk) and uncertainty in
requirement specification leads to uncertainty
about the process of development, affecting
schedule
18-04-2015 SPM_KSP_SP2015 135
137. LMR Risk Framework(Sociotechnical
model )
Actors: refers to all the people involved in the
development of the application in question.A
typical risk in this area is that high staff turnover
leads to expertise of value to the project being lost.
Technology:encompasses both the technology used
to implement the application & that embedded in
the delivered products..Risks here could relate to
the appropriateness of the technologies & to
possible faults within them, especially if they are
novel.
18-04-2015 SPM_KSP_SP2015 137
138. LMR risk framework
Structure: describes the mgmt structures &
systems, including those affecting planning &
control. ex,the implementation might need user
participation in some risks, but the responsibility for
managing the users’ contribution might not be
clearly allocated.
Tasks: relates to the work planned. ex.the
complexity of the work might lead to delays
because of the additional time required integrate
the large number of components.
18-04-2015 SPM_KSP_SP2015 138
139. Case study
Ref Hazard Likelihood Impact RE
R1 Changes to req.spec
during coding
8 8 64
R2 Spec.takes longer than
expected
3 7 21
R3 Siginificant staff
sickness affecting
critical path activities
5 7 35
R4 Significant staff
sickness affecting non
critical activities
10 3 30
R5 Module coding takes
longer than expected
4 5 20
R6 Module testing
demonstrate errors or
deficiences in design
4 8 32
18-04-2015 SPM_KSP_SP2015 139
140. Probability level Range
High >50% chance of happening
Significant 30-50%chance of happening
Moderate 10-29% chance of happening
Low <10% chance of happening
18-04-2015 SPM_KSP_SP2015 140
Impact level Range
High >30%above budgeted expenditure
Significant 20-29% above budgeted expenditure
Moderate 10-19% above budgeted expenditure
Low Within 10% of budgeted expenditure
142. RRL(Risk Reduction Leverage)
Risk Reduction Leverage is another Quantitative means of
assessing how Risks are being managed.
𝑅𝑅𝐿 =
𝑅𝐸 𝑏𝑒𝑓𝑜𝑟𝑒 − 𝑅𝐸 𝑎𝑓𝑡𝑒𝑟
𝑐𝑜𝑠𝑡 𝑜𝑓 𝑟𝑖𝑠𝑘 𝑟𝑒𝑑𝑢𝑐𝑡𝑖𝑜𝑛
𝑅𝐸 𝑏𝑒𝑓𝑜𝑟𝑒=risk exposure before taking the risk reduction
action.
𝑅𝐸 𝑎𝑓𝑡𝑒𝑟= risk exposure after taking the risk reduction action.
An RRL above 1.0 indicates that the reduction in the risk
exposure achieved by a measure is greater than its costs.
Since Risk Exposure is not absolute but relative, we can
compare different exposures to one another.
18-04-2015 SPM_KSP_SP2015 142
143. RRL
It might cost Rs 200000 to replace a h/w
configuration used to develop a s/w application.
There is a 1% chance of fire(because of the
particular location of the installation,say).TheRE
=.01*200000=Rs.2000
Installing the fire alarms at a cost of Rs500 would
reduce the chance of fire by 0.5%.The new
RE=Rs1000.RRL=(2000-1000)/500=2.0
The action would therefore be deemed wothwhile.
18-04-2015 SPM_KSP_SP2015 143
144. The RE is the amount you might pay to an
insurance company to cover a risk. i.e an
insurance company in the above case might be
willing to reduce the premium you pay to have
cover against fire from Rs2000 to Rs1000 if you
installed the fire alarms. As the fire alarms
would cost you only Rs500 &
save Rs1000,the cost would clearly worthwhile.
18-04-2015 SPM_KSP_SP2015 144
145. • Let us consider a Server with some data on it. The probability of
losing the data is 20%. The cost of losing such data is measured in
terms of the cost of rebuilding it. This is estimated at $20,000:
Probability of loss = 0.2 BEFORE Resolution
Loss = $20,000
Exposure to data loss = 0.2 x $20,000 = $4,000
• Now we provide a method of reducing the possibility of data loss
(Say frequent backup or replication on another database, etc). This
reduces the risk to 5%. The impact on losing the data is the same
since we still need to rebuild the data. However, the cost of
introducing the loss reduction is $2000.
18-04-2015 SPM_KSP_SP2015 145
146. Probability of loss = 0.05 AFTER Resolution
Loss= $20,000 (Same loss in this example)
Exposure= 0.05 x $20,000 = $1000
Cost of Risk Reduction= $2000
the Risk Reduction Leverage is:
Leverage = ($4000 - $1000) / $2000 = 1.5
• The higher the Leverage, the better the solution.
18-04-2015 SPM_KSP_SP2015 146
147. • The Risk Reduction Leverage gives us the following
benefits:
• We can now compare different ways of reducing data
loss to each other by comparing the Reduction
Leverage
• We can increase Leverage by Increasing the difference
between Exposure (Before) and Exposure (After), that
is by improving the solution and reducing the
probability.
• We can also increase Leverage by reducing the cost of
risk reduction or by selecting better solutions.
18-04-2015 SPM_KSP_SP2015 147
148. Measurement & Tracking Planning
1)Project Mgmt plan is merely a document that can
be used to guide the execution of a project.
2)Unless the actual performance of the execution is
tracked against the plan, the plan has limited value.
3)And for project tracking ,the value of certain key
parameters must be measured during the project.
4)Tracking is a difficult task,and if you want to
perform it properly you must plan for it.
18-04-2015 SPM_KSP_SP2015 148
149. 5)During planning, you must decide on issues
such as how the tasks, the effort, and the
defects will be tracked, what tools will be used,
what reporting structure & frequency will be
followed and so on.
18-04-2015 SPM_KSP_SP2015 149
150. Concepts in Measurement
1)The basic purpose of measurements in a project is to
effectively control the project.
2)One approach for process control is SPC
3)Metrics & Measurements: S/w metrics can be used to
quantitatively characterize various aspects of the s/w
process or s/w products.
Process metrics: quantify attributes of the s/w process or
the development environment
Product metrics: are measures for the s/w products.
Product metrics remain independent of the process used
to produce the product.
18-04-2015 SPM_KSP_SP2015 150
151. Process metrics: productivity, quality, resource
metrics, DIR, DRE.
Product metrics : size, reliability, quality,
complexity of the code, functionality.
The use of metrics requires that measurements
be made to obtain data. For many metrics
program, you must clearly understand the goals
for collecting data as well as the models that are
used for making judgements based on data.
18-04-2015 SPM_KSP_SP2015 151
152. In general, which metrics to use and which
measurements to take will depend on the
project and organization goals.
Schedule, size,effort,and defects are the basic
measurements for projects and form a stable
metrics set.
18-04-2015 SPM_KSP_SP2015 152
153. Process Monitoring through SPC
SPC has been used with great success in
manufacturing, and its use in s/w is also increasing.
A process is used to produce output, and quality of
the output can be defined in terms of certain
quality characteristics.
A number of factors affect the variability in the
value of these characteristics. These factors can be
classified as Natural(inherent)causes of variability,
and Assignable(or special)causes.
18-04-2015 SPM_KSP_SP2015 153
155. Natural causes: are those that are always present
and each of which contributes to the variability. Its
not practical to control these causes unless the
process itself is changed.
Assignable causes: are those that occur once in a
while, have a larger influence over variability in the
process performance and can be controlled.
Process is said to be statistical control if the
variability in the quality characteristics is due to
natural causes only. The goal of SPC is to keep the
production process in statistical control.
18-04-2015 SPM_KSP_SP2015 155
156. Control Charts(CC): are favourite tool for applying SPC.
To build a CC, the output of a process is considered to be
a stream of numeric values representing the values of the
characteristic of interest. Subgroups of data are taken
from this stream, and the mean values for the subgroups
are plotted, giving X-bar chart.
LCL(Lower control limit) and an UCL(Upper control
limit)are established. If a point falls outside the control
limits, the large variability is considered to be due to
assignable causes.
18-04-2015 SPM_KSP_SP2015 156
157. R-chart: plots the range (the difference between
the min and max values)of the chosen groups.
Control limits are established for R-chart, and a
point falling outside these control limits is also
considered as having assignable causes
By convention,LCL & UCL are frequently set at 3-
sigma around mean,where sigma is the SD for data
with only normal variability(due to natural
causes).With these limits, the probability of a false
alarm-in which a point with natural variability falls
outside the limits-is only 0.27%.
18-04-2015 SPM_KSP_SP2015 157
158. When the production process does not yield the
same item repeatedly, as is the case with s/w
processes,forming sub groups may not make
sense;individual values are considered.For such
processes,XMR charts can be used.
In XMR chart,a moving range of two consecutive
values is considered as the range for the R-chart.For
the X-bar chart,the individual values are plotted;the
CLs are then determined using the average moving
range.
18-04-2015 SPM_KSP_SP2015 158
159. XmR Chart
An individuals and moving range (X-MR) chart is a
pair of control charts for processes with a subgroup
size of one. Used to determine if a process is stable
and predictable, it creates a picture of how the
system changes over time. The individual (X) chart
displays individual measurements. The moving
range (MR) chart shows variability between one
data point and the next. Individuals and moving
range charts are also used to monitor the effects of
process improvement theories.
18-04-2015 SPM_KSP_SP2015 159
161. Measurements
1)Any quantitative control of a project depends
critically on the measurements made during the
project.
2)To perform measurements during project
execution,you must plan carefully regarding
what to measure, when to measure, and how to
measure.
3)Measurement planning is a key element in
Project planning.
18-04-2015 SPM_KSP_SP2015 161
162. Collecting Effort Data
1)To help PM monitor the effort ,each employee
records in a WAR(Weekly Activity Report: online
system)system the effort spent on various tasks.
2)WAR entry consists:
a)Program code
b)Module code
c)Activity code
d)Activity description
e)Hours for Monday through Sunday
18-04-2015 SPM_KSP_SP2015 162
163. Activity codes for effort:
PAC-Acceptance
PACRW-rework after acceptance
PCD-Coding and Self unit Testing
PCDRV-Code walkthrough/review
PST-system testing
18-04-2015 SPM_KSP_SP2015 163
164. • The program code & module code permit separation of effort data
with respect to modules or programs(important for component
level monitoring).
• To facilitate project-level analysis of planned versus actual effort
spent, the WAR system is connected to the Microsoft
Project(MSP)depiction of the project.
• Project staff can begin submitting WARs for a project only after the
MSP for the project has been submitted.
• When entering the WAR for a week ,the user works with a screen
that is divided into two sections-planned and unplanned activities.
18-04-2015 SPM_KSP_SP2015 164
165. Logging & Tracking Defects
In Infy project, defect detection and removal proceed as
follows:
i)A defect is found & recorded by a submitter. The defect is
then in ‘submitted’ state.
ii)The PM assigns the job of fixing the defect to someone
,usually the author of the document or code in which the
defect was found.
iii)This person does the debugging & fixes the reported
defect,& the defect then enters the ‘fixed’ state.
iv)A defect that is fixed is still not closed. Another person,
typically the submitter, verifies that the defect has been fixed.
After this verification, the defect can be marked ‘closed’
18-04-2015 SPM_KSP_SP2015 165
166. Life Cycle of a Defect
Entered by
Submitter Fixed by Checked by
Owner Submitter
Submitted Fixed Closed
18-04-2015 SPM_KSP_SP2015 166
167. • A defect control system(DCS)is used in projects for logging &
Tracking defects.
Recording defect data:
18-04-2015 SPM_KSP_SP2015 167
Data Description Mandatory/Optional
Project code Code of the project for
which defects are
captured
M
Description Description of the defect M
Submitter/Owner Name M
Review Type Type of Review O
Severity Severity of defect M
Type Classification of defect M
168. Defect Types
Defect Type Example
Logic Insufficient/incorrect errors in algos used;
wrong conditions, test cases, or design
documents.
Standards Problems with coding/doc standards such
as layout,modularity,comments etc.
UI Specified function keys not working etc
Performance Poor processing speed,memory problems
etc
Memory mgmt problems Core dump,array overflow,illegal function
call etc.
18-04-2015 SPM_KSP_SP2015 168
169. Defect Severity
Severity Type Explanation
Critical Defect may be critical in terms of affecting
the schedule, or it may be a showstopper
i.e it stops the user from using the system
further.
Major The same of defect has occurred in many
progs or modules.We need to correct
everything. Ex.coding standards are not
followed in any program.
Minor This defect is isolated or does not stop the
user from proceeding, but it causes
inconvenience.
Cosmetic A defect that in no way affects the
performance of the s/w product.Ex
esthetic issues and grammatical errors in
massages.
18-04-2015 SPM_KSP_SP2015 169
170. Measuring Size & Schedule
• Measuring schedule is straight forward
because you use calendar time.The detailed
activities and schedule are captured in MSP
schedule.
• Size measured in terms of LOC/FP.
18-04-2015 SPM_KSP_SP2015 170
171. Project Tracking
The main goal of tracking is for PMs to get
visibility into project execution so that they can
determine whether any action needs to be taken
to ensure that the project goals are met.
Types of Tracking:
Activities Tracking
Defect Tracking
Issues Tracking
18-04-2015 SPM_KSP_SP2015 171
172. Activities Tracking Defect Tracking Issues Tracking
Looks at which planned
activities have been
completed.
Done in connection with
defect logging
Ensures that clarifications
& other problems that
have the potential to delay
the project do not go out
of control.
18-04-2015 SPM_KSP_SP2015 172
173. • To keep track of the projects status along the
effort, schedule & quality dimensions, PMs
also plan for:
i)Activity –level Monitoring(using SPC)
ii)Status reports(prepared weekly)
iii)Milestones Reports(quantitatively check the
actual Vs estimated data along effort, schedule,
& defect dimensions.Also you monitor
risks,training,reviews,customer complaints etc)
18-04-2015 SPM_KSP_SP2015 173
174. Project Management Plan(PMP)
1)PMP document is the culmination of all
planning activities undertaken by PMs.
2)The outputs of the various planning activities
appear in this document, which becomes the
baseline document guiding the overall execution
of the project.(not to confuse with the detailed
project schedule, which represents only the
schedule and assignments of activities.
18-04-2015 SPM_KSP_SP2015 174
175. 3)Documenting the planning outputs enables the project
plan to be reviewed for deficiencies.
4)At Infy, the plans are reviewed by a group(PMs, SEPG
members & Senior Mgmt).
5)The document also serves an important communication
purpose.
6)It gives Senior Mgmt an overall view of the project
goals & commitments & describes how the project will be
managed to meet them.
7)It gives the project team a comprehensive view of the
project & the roles of the individual team members.
18-04-2015 SPM_KSP_SP2015 175
176. Team Management
S/w development is a team effort. High quality
& productivity result when the team members
contribute effectively & remain motivated & the
overall team functions smoothly & efficiently.
a)Team Structure
b)Communication
c)Team Development
18-04-2015 SPM_KSP_SP2015 176
177. Mintzberg’s organizational
configurations
Five ways organizations typically configure and coordinate teams:
• Simple structure – one or few managers, direct supervision
– Typically found in new, relatively small organizations
• Machine bureaucracy – mass-production and assembly lines
– Coordination requires standardization of work processes
• Divisionalized form – each division has autonomy
– Split up work and let each group figure out how to do it
– Coordination achieved through standardization of work outputs and
measuring performance of divisions
• Professional bureaucracy – skilled professionals with autonomy
– Coordination achieved through standardization of worker skills
• Adhocracy – for innovative or exploratory projects
– Coordination achieved through mutual adjustment
• Which configurations apply for software development projects?
18-04-2015 SPM_KSP_SP2015 177
179. Large projects often distinguish levels of management:
– Leaf nodes is where most development gets done; rest of tree is
management
– Different levels do different kinds of work—a good programmer may
not be a good manager
– Status and rewards depend on your level in the organization
– Works well when projects have high degree of certainty, stability and
repetition
– But tends to produce overly positive reports on project progress, e.g.:
• Bottom level: “We are having severe trouble implementing
module X.”
• Level 1: “There are some problems with module X.”
• Level 2: “Progress is steady; I do not foresee any real problems.”
• Top: “Everything is proceeding according to our plan.”
18-04-2015 SPM_KSP_SP2015 179
182. • Organize people in terms of specialties
– Matrix of projects and specialist groups
– People from different departments allocated to software
development, possibly part-time
• Pros and cons?
– Project structure may not match organizational structure
– Individuals have multiple bosses
– Difficult to control a project’s progress
18-04-2015 SPM_KSP_SP2015 182
183. Democratic or
Open structured teams
18-04-2015 SPM_KSP_SP2015 183
Why are democratic teams often favored
in Extreme Programming process?
184. A “grass roots” anti-elitist style of team organization
– Egoless: group owns the documents & code (not
individuals)
– All decisions are based on team consensus
– Depends on total cooperation of its members
– Requires clear structure for the way the team interacts
– Functional roles (e.g. moderator, recorder) rotate among
team members
– A technical leader has external responsibility and resolves
issues when team doesn’t reach consensus
18-04-2015 SPM_KSP_SP2015 184
186. • For large Projects :module leaders(ML) report
to PM and some developers will work under
MLs
• Also a defect prevention team is formed from
the existing team members.
• The SEPG member(SQA) is associated with
each project.SQA interacts extensively with
PM and CC but does not report to PM.
18-04-2015 SPM_KSP_SP2015 186
187. • In determining team structure,the PM must
take into account some people factors:
i)Skills,background,& exp of the team members.
ii)Personal aspirations & career paths of the
members.
iii)Mentoring & people development needs.
18-04-2015 SPM_KSP_SP2015 187
188. Communication
(Communication related to project
&destressing communication)
• Infy PMs use the following methods to enhance team
communication:
i)Project specific bulletin boards for announcements,
notices, status reports & so on.
ii)Project mailing list
iii)Project web site for publishing documents, homepages
of team members, relevant technical articles & notes &
training materials for self learning.
iv) Project meetings for briefings & issue resolution.
v)Best practice sessions & presentation by team members
on their work.
18-04-2015 SPM_KSP_SP2015 188
189. • Because deadlines are usually short &
everyone is under time pressure, stress tend
to build up .Communication aimed at de-
stressing is extremely important to ensure
continued motivation.
Project parties, Birthday parties, Events such as
quizzes & games with prizes.
18-04-2015 SPM_KSP_SP2015 189
190. Team Development
• Project teams often include many junior people.It is
the reponsiblity of the team & the PM to enhance the
personal development of these team members.
i)Job rotation
ii)Mentoring of junior members by exp team members
iii)Reviews, Appraisals & feedback.
iv)Regular recognition of contribution at the project level.
v)Coaching, training,and the like to help people having
trouble.
18-04-2015 SPM_KSP_SP2015 190
191. Customer Communication & Issue
Resolution
1)Team communication is toward keeping the team
informed & motivated.
2)But what about the customer, who is the sponsor
& major stakeholder of the project.
3)Many problems are the result of the
misunderstandings between the customer & the
developers.
4)Regular communication between the
development team & the customer can help avoid
these kinds of problems.
18-04-2015 SPM_KSP_SP2015 191
192. • Status Reports are one such means of
communication, designed to give the
customer a clear idea of the state of the
project on an on-going basis.But these reports
are not enough.
• PMs should plan other means of
communication:weekly teleconferencing or
videoconferencing & regular e-mails.
18-04-2015 SPM_KSP_SP2015 192
193. Despite the use of regular communication channels,
issues crop up that the representative at the two
ends cannot resolve.
Such issues can delay the project & must be
escalated.
To resolve issues,a project plan specifies the
escalation channels at both the customer end and
at the Infy end.
The plan clearly states the policies regarding when
these channels are to be deployed.
18-04-2015 SPM_KSP_SP2015 193
194. Structure of the PMP
PMP has four sections:
1)Project Summary
2)Project Planning
3)Project Tracking
4)Project Team
18-04-2015 SPM_KSP_SP2015 194
195. • Project Summary: High level overall view of the project. Includes start & end
dates, the PL, contacts at customer end, project objectives ,major commitments,
deliverables & assumptions made
• Project Planning:Lists the outputs of executing the various project planning
procedures. Includes the development process being used,tailoring notes,the req
change mgmt process,req traceability plans,effort& schedule
estimates,skills,roles,tools used,quality plan,risk mgmt plan
• Project Tracking:Defines the measurements to be taken & the systems to be used
for recording data,various project tracking activities to be undertaken,The
frequency and nature of the progress reporting,,and escalation procedures.
• Project Team:Defines the project team and its structure,roles and responsibilities
of the various people.
18-04-2015 SPM_KSP_SP2015 195
196. S/W Configuration Management
• Changes those due to the evolution of work products & those
due to requirement changes takes place continuously in a s/w
project.
• All these changes in the files containing source, data,or
documentation.
• When multiple people create & change the huge number of
files in a s/w project,it can lead to complications unless the
changes are properly controlled.
18-04-2015 SPM_KSP_SP2015 196
197. Consider this situations
• A)Two different change requests came from the customer. The PM assigned
one request to X for implementation,& the other to Y. Both had to modify
code for module M. When X finished his modification and saved the file for Y. X
overwritten the changes Y had made a day earlier.
• B)Friday was the deadline for release of a module for which 3 team members
were developing the code. Integration of unit-tested code was planned for the
final two days. On Tuesday night, X, the developer of several function keys, left
to attend an emergency. The next day the module leader & the team members
spent many hours looking through X’s files. They managed to identify some
files containing the various functions X was developing, but they found
umpteen versions of these files. One of the team members had to work on the
problem over the weekend. Starting with some version of X’s programs, he
developed & tested the unit, redoing the work that X had almost finished
before leaving. The module was finally delivered three days late.
18-04-2015 SPM_KSP_SP2015 197
198. c)X’s team was in good spirits. They had finished the development on time, and
the final testing had shown no bugs. The s/w was released to the customer for
implementation. The next day X received angry e-mails from the users & the
customer, reporting problems in the s/w. After frantic effort by the team, the
cause was found: The release version of the s/w contained an older version of a
key component.
Stories like this can be found in most organizations.
SCM is the aspect of project management that focuses
exclusively on systematically controlling the changes so
that such problems do not occur
18-04-2015 SPM_KSP_SP2015 198
199. What is Software Configuration
Management?
• Definition Software Configuration Management:
– A set of management disciplines within a software
engineering process to develop a baseline
– Software Configuration Management encompasses
the disciplines and techniques of initiating, evaluating
and controlling change to software products during
and after a software project
• Standards (approved by ANSI)
– IEEE 828: Software Configuration Management Plans
– IEEE 1042: Guide to Software Configuration
Management.
18-04-2015 SPM_KSP_SP2015 199
200. Concepts in SCM
SCM is essential to satisfy one of the basic objectives of a project:
delivery of high-quality s/w product to the client.
What is this ‘SOFTWARE’ that is delivered? At the least, it contains the
various source or object files that make up the source or object code,
scripts to build the working system from these files, and associated
documentation.
During the project, the files change, leading to the creation of different
versions. In this situation, how does a program manager ensure that
the appropriate versions of source code files are combined without
missing any source, and that the correct versions of the documents,
consistent with the final source, are sent?
All these is ensured through proper CM
18-04-2015 SPM_KSP_SP2015 200
201. • A primary objective of CM is to mange the evolving configuration of the s/w system
• In a project , a program's evolution takes it through many states.At the
beginning, when a programmer develops it, the program is under development(or”
private”).Once the programmer is satisfied with the program, it moves into the” ready for
UT”state.
Only when the program reaches this state can it be unit tested. After it has been Unit
tested, the programmer must fix any defects found.
If the UT succeeds, the program’s state changes to “ready for ST”. Only when all programs
reach this state can ST commence. Again if defects are found during ST,the state of the
program reverts to “private”; otherwise it moves to “ready for AT”.If the AT succeeds,the
state of all programs changes to “ready for release”.
Implying that they can now be released for “production use”.
Once a program is released and is in production use, all the programs(and
documentation)move to the “baselined” state, which represents the state of the production
system.
18-04-2015 SPM_KSP_SP2015 201
202. In addition to the changes that take place during the normal course of s/w
development ,requirement change request may be submitted,& their
implementation may alter programs.
When a project has a large number of items that can be changed, developers
may be called on to take many actions; these actions can be performed only if
proper support is available from the CM process.
18-04-2015 SPM_KSP_SP2015 202
203. SCM Functions
1)Give the state of the programs.(need this info to decide when to start
testing or when to release the s/w)
2)Give the latest version of a program.
3)Handle concurrent update requests.
4)Undo a program change.
5)Prevent unauthorized changes or deletions.
6)Provide traceability between requirement change request and program
change.
7)Undo a requirement change.
8)Show associated changes.
9)Gather all sources ,documents, and other information for the current
system.
18-04-2015 SPM_KSP_SP2015 203
204. • The main purpose of SCM is to provide mechanisms that handle the type
of scenarios in the preceding list. These mechanisms include:
• A)Conventions for naming & organization of files.
• B) Version control
• C)Change request traceability
• D)Access Control
• E)Reconcilition procedures
• F)Modification login programs.
18-04-2015 SPM_KSP_SP2015 204
205. • Conventions for naming & organization of files: Naming program files(&
document files)according to standard convention & keeping the files in specific
directories help in finding a desired file quickly. Proper naming(Ex standard
extensions)also helps developers to readily understand the nature of file contents
without looking at the files. Also segregating programs by their states into separate
directories helps developers to identify the program state easily.
• Version Control: is a key issue for CM and many tools are available to help manage
this task. Version control is a system that records changes to a file or set of files
over time so that you can recall specific versions later. VC helps preserve older
versions of the programs whenever they are changed .Without such mechanism,
the system can not support many of the required CM functions.
18-04-2015 SPM_KSP_SP2015 205
206. • If you are a graphic or web designer and want to keep every version of
an image or layout (which you would most certainly want to), a Version
Control System (VCS) is a very wise thing to use. It allows you to revert
files back to a previous state, revert the entire project back to a
previous state, compare changes over time, see who last modified
something that might be causing a problem, who introduced an issue
and when, and more. Using a VCS also generally means that if you
screw things up or lose files, you can easily recover. In addition, you get
all this for very little overhead.
18-04-2015 SPM_KSP_SP2015 206
207. VCS(Version Control Systems)
• LocalVCS:Many people’s version-control method of choice is to copy files
into another directory. This approach is very common because it is so simple,
but it is also incredibly error prone. It is easy to forget which directory you’re
in and accidentally write to the wrong file or copy over files you don’t mean
to.
• To deal with this issue, programmers long ago developed local VCSs that had a
simple database that kept all the changes to files under revision control.
• One of the more popular VCS tools was a system called RCS, which is still
distributed with many computers today. Even the popular Mac OS X operating
system includes the rcs command when you install the Developer Tools. RCS works
by keeping patch sets (that is, the differences between files) in a special format on
disk; it can then re-create what any file looked like at any point in time by adding
up all the patches.
18-04-2015 SPM_KSP_SP2015 207
210. • The next major issue that people encounter is that they need to collaborate
with developers on other systems. To deal with this problem, Centralized
Version Control Systems (CVCSs) were developed. These systems, such as CVS,
Subversion, and Perforce, have a single server that contains all the versioned
files, and a number of clients that check out files from that central place. For
many years, this has been the standard for version control.
• This setup offers many advantages, especially over local VCSs. For example,
everyone knows to a certain degree what everyone else on the project is
doing. Administrators have fine-grained control over who can do what; and it’s
far easier to administer a CVCS than it is to deal with local databases on every
client.
18-04-2015 SPM_KSP_SP2015 210
211. • However, this setup also has some serious downsides. The most
obvious is the single point of failure that the centralized server
represents. If that server goes down for an hour, then during
that hour nobody can collaborate at all or save versioned
changes to anything they’re working on.
• If the hard disk the central database is on becomes corrupted,
and proper backups haven’t been kept, you lose absolutely
everything – the entire history of the project except whatever
single snapshots people happen to have on their local machines.
• Local VCS systems suffer from this same problem – whenever
you have the entire history of the project in a single place, you
risk losing everything.
18-04-2015 SPM_KSP_SP2015 211
213. • This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such
as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot
of the files: they fully mirror the repository. Thus if any server dies, and these
systems were collaborating via it, any of the client repositories can be copied back
up to the server to restore it. Every clone is really a full backup of all the data.
• Furthermore, many of these systems deal pretty well with having several remote
repositories they can work with, so you can collaborate with different groups of
people in different ways simultaneously within the same project. This allows you
to set up several types of workflows that aren’t possible in centralized systems,
such as hierarchical models.
18-04-2015 SPM_KSP_SP2015 213
214. List of Software configuration
management tools available are:
VSS – Visual source safe(is a centralized version control system from
Microsoft.)
CVS- Concurrent version system(is an open source version controlling system
which lets group of people work simultaneously on group of files. )
Rational Clear Case:(is a configuration management tool developed by IBM. It
provides version control, parallel development, build auditing and workspace
management. It can be easily integrated with other rational products and can
be used for small, large and huge teams which are geographically distributed.)
SVN- Subversion(is the most popular open source Configuration Management
tool used for version controlling. Being open source, it is freely available over
the net. It provides many quality control and cost effective benefits to switch
to mid projects)
18-04-2015 SPM_KSP_SP2015 214
215. Perforce:(is a version controlling software developed by Perforce
Software Inc. here the users connect to shared file repository and files are
transferred between the repositories and individual workstations.)
TortoiseSVN
IBM Rational team concert.
IBM Configuration management version management.
Razor.
Quma version control system.
SourceAnywhere.
18-04-2015 SPM_KSP_SP2015 215
216. • Change request traceability: Provides mapping from a requirement change request
to subsequent changes in the programs, and that helps in managing requirement
changes. To trace a change back to the change request, the modification log is
useful.
• “Traceability is defined as the attributes of the software that provide a thread from
the requirements to the implementation
• The Software Change Control Board (SCCB) is a group of people responsible for
evaluating and classifying a request for change. The SCCB is the control mechanism
on larger projects to ensure that every change is properly considered and co-
ordinated. It may include members from management, development,
documentation, test, assurance, and even the customer. Depending on the size of
the project, several SCCB’s may be required, each having knowledge and authority
over particular project areas. The SCCB is responsible for reviewing each change
request and evaluating it.
• AccuRev, eB CM , IBM Rational ClearCase, McCabe TRUEchange
18-04-2015 SPM_KSP_SP2015 216
217. • Access Control Mechanism: Ensure that only authorized people can
modify certain files & that only one person can modify a file at any given
time.
• Reconciliation procedures: Specify how two changes made independently
to a program can be merged to create a new version that reflects both.
If these mechanisms are provided, the scenarios given can be handled
satisfactorily. Some of these scenarios necessitate the use of more than one
mechanism. Ex. undoing a requirement change involves a mechanism to
show the traceability of a requirement change to subsequent changes in
programs, as well as a version control mechanism to actually undo the
changes.
18-04-2015 SPM_KSP_SP2015 217
218. Some CM mechanisms may be supported by a tool, whereas others may
require that the users perform them explicitly. Ex.Version control may be
carried out by a tool, but capturing the state of a program may require the
programmer to explicitly maintain this information.
The CM process defines all steps needed to implement such mechanism &
explains how these mechanisms are to be used in a project.
The documents that are produced in a project(Reqs Doc,Design Docs,and
plans)also need CM.During the normal course of a project,a document passes
through three states:”under development”,”under review”,and “baselined”.
The CM process must also implement the state diagram for documents.
18-04-2015 SPM_KSP_SP2015 218
219. Configuration Management Process
1)The CM process defines the sequence of activities that must be performed
In support of the CM mechanisms.
2)The first stage in the CM process at Infy is planning(Identifying those items
that need to be under CM(Configuration items),locations to store them,
procedures for change control, and so on.
3)The PM or CC(configuration controller) of the project prepares this plan.
4)The process must be executed, perhaps by deploying a tool.
5)The three activities of the CM process(at Infy):
a)Planning & Setting Up Configuration Management
b)Perform Configuration Control
c)Status Monitoring and Audits
18-04-2015 SPM_KSP_SP2015 219
220. Planning & Setting Up CM
1)Planning for CM involves identifying the Configuration items & specifying
the procedures to be used for controlling & implementing changes to them.
2)Identifying configuration items is a fundamental activity in an type of CM.
3)Typical examples of configuration items include:
requirements specifications
design documents
source code
test plans
test scripts
test procedures
test data
18-04-2015 SPM_KSP_SP2015 220
221. standards used in the project(such as coding standards & design
standards)
the acceptance plan
documents such as CM plan & the project plan
user documentation such as the user manual, and
documents such as the training material
contract documents(including support tools such as compiler or in-
house tools)
Quality records(review records, test records),and
CM records(release records, status tracking records).
Any customer-supplied products or purchased items that will be part
of the delivery(called “included s/w product”)are also configuration
items.
18-04-2015 SPM_KSP_SP2015 221
