Software Project Management CS7127
By
K.Sridhar Patnaik
Associate Professor
Department of Computer Science & Engg
Birla Institute of Technology Mesra,Ranchi(India)
Email:[email protected]
18-04-2015 SPM_KSP_SP2015 1
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
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
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
Types of Plan
Plan Description
Quality plan Describes the quality procedures andstandards that will be used in a project.
Validation plan Describes the approach, resources andschedule used for system validation.
Configurationmanagement plan
Describes the configuration managementprocedures and structures to be used.
Maintenance plan Predicts the maintenance requirements ofthe system, maintenance costs and effortrequired.
Staff development plan. Describes how the skills and experience ofthe project team members will bedeveloped.
18-04-2015 SPM_KSP_SP2015 5
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
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.)
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
• 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
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
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
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
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
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
Cont.
• GOALS
• COMMITMENT
• ABILITY
• MEASUREMENT
• VERIFICATION
18-04-2015 SPM_KSP_SP2015 15
CMM(developed in mid 1980)
18-04-2015 SPM_KSP_SP2015 16
KPAs(Key Process Areas)
• LEVEL-2(Repeatable)
Requirements Management
S/w Project Planning
S/w Project Tracking & Oversight
S/w Subcontract Management
SQA
SCM
18-04-2015 SPM_KSP_SP2015 17
KPAs(Key Process Areas)
• LEVEL-3(Defined)
Organization Process Focus
Organization Process Definition
Training Program
Integrated S/w Management
S/w Product Engg.
Intergroup Coordination
Peer Reviews
18-04-2015 SPM_KSP_SP2015 18
KPAs(Key Process Areas)
• LEVEL-4(Managed)
S/w Quality Management
Quantitative Process Management
18-04-2015 SPM_KSP_SP2015 19
KPAs(Key Process Areas)
• LEVEL-5(Optimizing)
Process Change Management
Technology Change Management
Defect Prevention
18-04-2015 SPM_KSP_SP2015 20
18-04-2015 SPM_KSP_SP2015 21
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
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
• 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
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(monitoring)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)
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
Elements of Planning Infrastructure.
• PDB(Process D/b)
• PCB(Process Capability Baseline)
• Process Assets
18-04-2015 SPM_KSP_SP2015 27
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
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
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
Effort Data Effort By Stage
Stage TaskEffort ReviewEffort Estimated
Req.Analysis 0 0 0
Design 414 32 367
Coding 1147 76 1182
Independent UT 156 74 269
Integration Testing 251 30 180
AT & Installation 183 0 175
Proj.Mgmt 237 8 357
Conf.Mgmt 30 3 38
Proj.Specific Training 200 0 218
Others 332 0 226
18-04-2015 SPM_KSP_SP2015 31
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
• 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
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
• PCB table
18-04-2015 SPM_KSP_SP2015 35
PCB
• Delivered Quality
• Productivity
• Schedule
• Effort Estimation
• Defect Injection Rate(DIR)
• InProcess defect removal efficiency
• Cost of quality
• Defect distribution
18-04-2015 SPM_KSP_SP2015 36
• 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
• 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
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
18-04-2015 SPM_KSP_SP2015 40
Process
Checklists Guidelines Templates
Activity Review
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
• 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
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
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
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
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
Process
Tailoring
Characteristics of the
Project
Standard Process Process for the
project
Tailoring Guidelines
18-04-2015 SPM_KSP_SP2015 47
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
• 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
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
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
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
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
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
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
Manpower Ramp-up
Peak Team size
Design Build Test
18-04-2015 SPM_KSP_SP2015 71
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
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
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
𝑦 𝑡 = 𝐾[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
‘𝑡𝑑 ’=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
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
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
Difficulty metric
𝑚′ 𝑡 = 2𝐾𝑎𝑡𝑒−𝑎𝑡21 − 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
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
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
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
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
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
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
• 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
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
• 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
Development
Process Defect Injection
Defect Removal
Req Analysis R Design R Coding R UT IT/ST AT
18-04-2015 SPM_KSP_SP2015 89
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
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
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
QQM Planning
1)Setting the Quality goal
2)Estimating Defects for other Stages
3)Quality Process Planning
18-04-2015 SPM_KSP_SP2015 93
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
• 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
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
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
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
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
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
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
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
• 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
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
• 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
• 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
• 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
• 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
“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
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
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
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
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
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
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
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
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
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
Risk Management Activities
Risk Identification
Risk Assessment Risk Analysis
Risk prioritization
Risk Management Risk Management Plan
Risk Control Risk Resolution
Risk Monitoring
18-04-2015 SPM_KSP_SP2015 119
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
Risk Management & Project Execution
18-04-2015 SPM_KSP_SP2015 121
Other Factors
Information Control
Project ’ s Process
Risk Assessment
Risk Monitoring
Managing
Risks
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
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
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
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
• 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
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
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
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
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
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
Risk Categories
Risk
Management Technical
Process Project Product
18-04-2015 SPM_KSP_SP2015 132
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
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
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
Lyytinen-Mathiassen-Ropponen (LMR) Risk Framework
18-04-2015 SPM_KSP_SP2015 136
ACTORS
TECHNOLOGY STRUCTURE
TASKS
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
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
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
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
Probability impact matrix
Tolerance line
High
Significant
Moderate
Low
R6 R1
R2,R3,R5
R4
18-04-2015 SPM_KSP_SP2015 141
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
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
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
• 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
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
• 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
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
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
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
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
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
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
NATURAL
CHARACTERISTIC
ASSIGNABLE
PROCESS
18-04-2015 SPM_KSP_SP2015 154
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
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
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
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
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
Tabular values for X and range charts
Subgroup Size
E2
D4
1 2.660 3.268
2 2.660 3.268
3 1.772 2.574
4 1.457 2.282
5 1.290 2.114
6 1.184 2.004
7 1.109 1.924
8 1.054 1.864
9 1.010 1.816
10 0.975 1.777
18-04-2015 SPM_KSP_SP2015 160
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
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
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
• 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
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
Life Cycle of a Defect
Entered by
Submitter Fixed by Checked by
Owner Submitter
Submitted Fixed Closed
18-04-2015 SPM_KSP_SP2015 166
• 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
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
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
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
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
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
• 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
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
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
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
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
Hierarchical team organization
18-04-2015 SPM_KSP_SP2015 178
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
Chief Programmer Team
18-04-2015 SPM_KSP_SP2015 180
Matrix organization
18-04-2015 SPM_KSP_SP2015 181
• 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
Democratic or Open structured teams
18-04-2015 SPM_KSP_SP2015 183
Why are democratic teams often favored in Extreme Programming process?
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
At Infosys
Project
Manager
Business Manager/
A/c Manager
Database
Administrator
Configuration
Controller
Developers
18-04-2015 SPM_KSP_SP2015 185
• 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
• 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
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
• 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
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
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
• 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
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
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
• 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
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
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
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
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
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
• 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
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
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
• 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
• 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
• 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
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
LocalVCS
18-04-2015 SPM_KSP_SP2015 208
CentralizedVCS
18-04-2015 SPM_KSP_SP2015 209
• 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
• 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
DVCS
Distributed VCS
18-04-2015 SPM_KSP_SP2015 212
• 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
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
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
• 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
• 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
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
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
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
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
4)During planning the types of items that come under the aegis of CM are identified, but a detailed list of items is not prepared(some items may not be known during CM planning which occurs at the beginning of the project).
5)Naming conventions for CM items are established during the CM planning stages.
6)PM must plan for version numbering. When a configuration item is changed, the old item is not replaced with new copy; instead the old copy is maintained & a new one is created. This approach results in multiple versions of an item, so policies for version number assignment is needed.(If a CM tool is being used, sometimes the tool handles the version numbering otherwise it is handled explicitly.
18-04-2015 SPM_KSP_SP2015 222
7)During planning ,the PM must decide how to maintain the state of a program. One way of collecting items in different states is to create separate directories for them. All items in a certain state reside in the directory for that state. When the state of the program changes, that program is moved from the directory to new directory for new state.(does not require any tool ).
8)During the planning phase, PMs must set the directory structure employed for managing the states, keeping in mind the requirements of the CM tool,if any.
Activities in this CM plan stage:
a)Identify configuration items, including customer-supplied & purchased items.
b)Define a naming & numbering scheme for the configuration item.
18-04-2015 SPM_KSP_SP2015 223
c)Define the directory structure needed for CM.
d)Define access restrictions.
e)Define change control procedures.
f)Identify & define the responsibility & authority of CC or CCB.
g)Define a method for tracking the status of configuration items.
h)Define a backdrop procedure.
i)Define a reconciliation procedure, if needed.
j)Define a release procedure.
k)Define an archival procedure.
l)Identify the points at which the configuration items will be moved to the baseline.
18-04-2015 SPM_KSP_SP2015 224
9)In certain cases: when there are large teams or when two or more teams or groups are involved in the development of the same or different portions of the s/w or interfacing systems-it may be necessary to have a CCB. This board includes representative from each of the teams. CCB/CC is essential for CM.
10)CM requires that access to some items in some states remain restricted. Ex, the programmer’s access and right to modify a program in the baseline must be limited. Planning activities must therefore specify the access rights of the CC, the PM, and the developers.
11)Policies and procedures for change control are also established during planning. This includes controlling normal changes that takes place during the life cycle as well as changes that are driven by requirement changes.
18-04-2015 SPM_KSP_SP2015 225
12)Normal changes are generally managed through a library mechanism and directory structure.
13)Changes due to requirement change requests, which may necessitate that many programs be changed, are frequently tracked through a spreadsheet that lists all items that must be changed as well as the directory for each item(there by giving its state).
14)If PMs allow concurrent updates to programs, they must specify reconciliation procedures. Concurrent updates are sometime necessary. Ex suppose a high priority change request comes in at the same time that another change request is being implemented.Clearly the new change request can not be put on hold until the first one is finished.
18-04-2015 SPM_KSP_SP2015 226
15)Similarly ,if problems occur in the working system while a change request is being implemented, then changes must be made immediately to ensure that the system can continue to function. For such situation ,reconciliation procedures are needed.
16)One possible procedure is to state that the differences between the original version and the new versions will be examined, and the changes in the version having fewer changes will be merged in the other version.
17)If the changes affect different parts of the program ,merging is straightforward; some CM tools readily support this capability.
18-04-2015 SPM_KSP_SP2015 227
Perform Configuration Control
1)Configuration control activities are undertaken during the execution phase of the project. Two main configuration control activities are performed ;
a)Deals with managing the transitions of programs(and documents)
b)Deals with managing the change requests that must be implemented.
State transition management involves moving the items from one directory to another when the state changes and then creating versions when changes are made. Tools are used to manage the states and versions of items and access to them.
The basic idea is that a program is considered to be in controlled environment(CE) when it is in any state in which others can use it.Once a program is in CE,it can not be modified,even by the original author, without proper authorization,because others may be using it.
18-04-2015 SPM_KSP_SP2015 228
To make an approved change ,the developer must check the program out of CE. Checking out essentially implies making a copy of the item without destroying the earlier version, and making a note that the item has been checked out.
An item is modified after it has been checked out. The modifications must then be reflected in the CE so that others have the benefit of the new version and so that the change request(which may forced the changes)can be truly implemented.
Because other team members may be using the items, some checks are done to ensure that the changed item is suitable before it is checked back in. When in item is checked back into the CE, the older copy is not destroyed; instead a new version is created. Often, only the CC or PL can check items in. This limitation makes it possible to roll back the changes if the need arises.
18-04-2015 SPM_KSP_SP2015 229
To provide information about changes that have been made,PMs can opt to keep a modification log in the program source itself.This log essentially identifies the start and end of a change & includes a reference to the change request that prompted it.
All these tasks-checking in, checking out, version maintenance, and creation of a modification log-can be handled through the use of CM tools.
To implement requirement changes, which in turn trigger changes to configuration items,a change request is first analyzed by performing an impact analysis(refer Requirement Change Management-chap-3).This analysis determines the programs and documents that need to be changed & the cost and schedule implications of making the change.
Once the change is approved by the PL and the CC, all programs & documents identified in the impact analysis must be changed appropriately.
18-04-2015 SPM_KSP_SP2015 230
Following activities are part of implementing a change request:
a)Accept the change request(with impact analysis).
b)Set up tracking mechanism.
c)Check out configuration items that need to be changed.
d)Perform the changes
e)Check in the configuration items.
f)Take the item through its life cycle.
Spreadsheet-based mechanism is frequently used for tracking the status of change requests.
18-04-2015 SPM_KSP_SP2015 231
Status Monitoring and Audits
A configuration item can exist in one of several states. The set of possible states varies according to whether the item is a program or a document and the type of CM tools being used.
It is important to accurately represent the state of each item because state related mistakes can lead to problems. For example,If a program has not been unit tested but is moved to the state ”ready to release”,it can cause problems.
If the system fails to reflect the fact that a program has been checked out from the baseline to implement a change, the s/w might be delivered without the change. Thus when a requirement change request is implemented it is also important that the mechanisms used to capture the state accurately represent the state.
18-04-2015 SPM_KSP_SP2015 232
If projects use a mechanism based on a directory structure to represent the state of a program, mistakes are possible. This type of mechanism requires that the programs be moved properly from one directory to another when their state changes and that change of state be reflected in the master table that maintains the state of the various items. To minimize mistakes and catch any errors early, projects must perform regular status checking of the configuration items. A report can be produced about the discrepancies, and all such discrepancies must be resolved. Also projects must check the status of change requests. To accomplish this goal, change requests that have been received since the last CM status monitoring operation are examined. For each change request, the state of the item as mentioned in the change request records is compared to the actual state. Checks can also be done to ensure that all modified items go through their full life cycle before they are incorporated in the baseline.
18-04-2015 SPM_KSP_SP2015 233
Finally, projects can perform a configuration audit. The main focus here is to ensure that the CM process of the project is indeed being followed. The baseline for the system can also be audited to ensure that its integrity is not being violated and that items are moved to and from the baseline in a manner consistent with the CM plans.
The projects CC generally conducts the CM audits .After a CM audit ,a report is usually issued that lists what needs to be done to keep the CM activities consistent with the CM plan.
18-04-2015 SPM_KSP_SP2015 234
Project Execution (Reviews)
1)You can check a program for quality by testing. But how do you check that the test plan being used for testing has the right test cases? And how do you check the design for design errors or check the requirement specifications for defects?
2)Reviews are the most effective and commonly used method for identifying defects, not only in nonexecutable documents such as the test plan & design document but also in code.
3)Reviews also give PMs visibility into the progress of the project, something that can help them to take timely corrective actions. 18-04-2015 SPM_KSP_SP2015 235
Advantages that the Reviews Offer to PMs
1)Through reviews ,the best talent in the organization can be utilized in a project even if they are not assigned to it.
2)Reviews help preserve team motivation by giving people a sense of achievement, participation, and recognition.
3)Through reviews, team members can develop their skills & senior people can mentor less-exp colleagues.
4)Reviews help prevent defects by creating more awareness about them.
18-04-2015 SPM_KSP_SP2015 236
Review Process at Infosys
1)A formal group review also called an inspection, is perhaps the best for identifying defects. S/w inspection were first proposed by Fagan. Earlier inspection focused on code, but over the years this technique has spread to other work products. 2)Today ,s/w inspections are a recognized industry best practice ,with considerable data to prove that they improve quality & productivity. 3)Infosys follow group review, similar to an inspection. 4) A group review is an analysis of a s/w work product by a group of peers following a clearly defined process.The goals of such reviews are to improve quality by finding defects and to improve productivity by finding defects in a cost effective manner.
18-04-2015 SPM_KSP_SP2015 237
Group Review Process
18-04-2015 SPM_KSP_SP2015 238
Work Product
For review Schedule,
review team, invitation
Self-preparation
logs
Reviewed work product Defects log,
Recommendation
Summary report
Planning Preparation & Overview
Group review
meeting Rework & follow up
Planning
1)The objective of planning is to prepare for the group review(GR) by selecting the group review team & scheduling the review.
2)The author of the work product ensures that the work product is ready for GR & that all pertinent standards have been met.
3)The PM with author agreement ,first selects the moderator; with moderator’s agreement, the PM selects other reviewers(inspectors).
4)The moderator has the over all responsibility of ensuring that the review is done properly & that all steps in the review process are followed.
18-04-2015 SPM_KSP_SP2015 239
4)The reviewers have the responsibility of identifying defects in the work product. The author and moderator are also the reviewers.
5)Once the review team is selected ,the author prepares a package that is distribute for GR. This package includes the work product to be reviewed, its specifications, and relevant checklists & standards
18-04-2015 SPM_KSP_SP2015 240
Preparation & Overview
1)The purpose of the overview & preparation phase is to deliver the package for review to the reviewers & to explain the work product,if necessary. The material can be distributed & explained in an initial meeting.
2)The moderator opens this meeting with a brief statement on the work product,the GR objectives,& if needed, an overview of the GR process.
3)The author may provide a brief tutorial on the work product, including a summary of any special considerations or areas that might be particularly difficult to understand .
18-04-2015 SPM_KSP_SP2015 241
4)To prepare for the GR meeting ,the reviewers than individually review(self-review) the work product(WP).Wherever the WP appears to have a defect, reviewers make notes with explanations in a self preparation log. They also record the time spent in individual review. During this review, they use any relevant checklists, guidelines, and standards.
18-04-2015 SPM_KSP_SP2015 242
GR meeting
1)The basic purpose of GR meeting is to come up with the final defect list. This list is based on the initial list of defects & issues reported by the reviewers & any new ones found during the meeting discussion.
2)Before the meeting is scheduled ,the moderator first checks whether all reviewers are prepared. This verification involves a brief examination of the effort & defect data in the self preparation logs to confirm that sufficient time & attention have gone into the preparation.
3)If preparation is not adequate ,GR is differed until all participants are fully prepared.
18-04-2015 SPM_KSP_SP2015 243
4)When everything is ready,the GR meeting is held.One reviewer is designated as the SCRIBE & another the READER.
The meeting is conducted as follows:
a)The READER goes over the WP line by line(or any other convenient small unit).Paraphrasing each line to the team.
(Some meetings do not include paraphrasing ,in which the role of the READER is not present)
b)There may be discussion on the issues raised.(some may agree or disagree).
c)The SCRIBE records the issues & defects identified.
18-04-2015 SPM_KSP_SP2015 244
c)At the end of the meeting, the SCRIBE presents the list of open issues & defects identified during the meeting,& it undergoes a final review by the team members. d)The defects and issues are merely identified during the review process.It is not the purpose of the group to identified solutions; that action is taken later by author. e)If few modifications are required, the group review status is “accepted”. If many modifications are required ,a follow-up meeting or re-review might be necessary to verify whether the changes have been incorporated correctly. f)The moderator recommends what is to be done.In general a GR team size is three(Author,moderator,reader,all three are also reviewers and one of them can act as scribe) 18-04-2015 SPM_KSP_SP2015 245
Rework & Follow-up
1)The author performs rework to correct all defects raised during the GR meeting. The author may also have to redo the WP if the moderator recommends it.
2)The scribe ensures that the GR report & minutes of the meetings are communicated to the GR team.
3)After all the issues and defects are closed ,the moderator ensures that the GR results & data are recorded & that the GR summary form is submitted to the SEPG & the PL.
18-04-2015 SPM_KSP_SP2015 246
One-Person Review
1)GR is a highly effective way of identifying defects. Unfortunately ,its cost is also high:many people spend time in preparation as well as in the review meeting.
2)In addition ,arranging GR meetings is a complex logistical problem, with associated overhead.
3)If the WP has many defects or is critical one,this cost is justified .Indeed GRs may turn out to be cost –effective way of uncovering defects
4)What if WP is relatively straightforward, is not likely to have many defects ,and is not very critical? In this case GR effort is not justified.
5)One-Person Review.
18-04-2015 SPM_KSP_SP2015 247
Guidelines for Review in Projects
1)Not all WPs in a project undergo group review because it may be prohibitively expensive and may not give commensurate returns.
2)Guidelines for selection of WPs for reviews:
a)The decision is left to the PM and the team reviewing the WPs of the early phases. The team can make better decisions regarding what to review in the rest of the project & which method to use.
Because the WPs of the early part of the life cycle are critical & because defects in them have a multiplier effect in the later stages.
b)It is recommended that the following WPs be group reviewed:
18-04-2015 SPM_KSP_SP2015 248
WPs to be GR
The Project Management Plan.
The SRS
The System Test Plan
The High-Level Design
The Integration Test Plan
18-04-2015 SPM_KSP_SP2015 249
Guidelines for Review of WPs
WP Focus Entry Criteria Participants
SRS Reqs meet customer needs
The doc conforms to the standards
Customer, Designer,Tester(ST), Installation team member , User Doc author
High Level Design HLD implements the Reqs. The design is implementable. Omissions & other defects in the design
The doc conforms to the standards. The Reqs have been reviewed & finalized.
Requirements author ,Detailed designer,Developer
18-04-2015 SPM_KSP_SP2015 250
Data Collection(DC)
1)Data collection during reviews is crucial. Data is collected & recorded at various stages in the process. Because reviews are largely human processes, if data are not properly recorded,the information can easily lost.
2)Detailed defect data(also effort data) are needed for tracking defects in the project and also for analysing the effectiveness of the review & for constructing the review capability baseline.
3)Key forms used for DC during reviews at Infy.
a)Self-Preparation Log
b)GR meeting Log
c)GR summary report.
18-04-2015 SPM_KSP_SP2015 251
Self-Preparation Log
1)Reviewers use SP log to record all defects or issues found during their independent reviews. The effort spent during the reviews is also recorded. Each reviewer prepares this log.
18-04-2015 SPM_KSP_SP2015 252
Project Code: WP Id: Reviewer name: Effort spent for preparation(hrs): Issue list:
Sl# Location Description Criticality/Seriousness
GR meeting Log
1)The Scribe prepares a log of the GR meeting that lists the defects & issues that were identified during the meeting. It includes all defects found by individual reviewers in their self-reviews that were validated as defects or issues during the meeting.
2)Unlike the SP log ,which lists defects as perceived by a reviewer, The GR meeting log lists only those defects that have been agreed to by the author.
3)It lists actual defects found,& it is the official defects list of the review.
18-04-2015 SPM_KSP_SP2015 253
GR Summary Report
1) The defects log is used to track all defects to closure. To analyse the effectiveness of a review, however ,only summary-level information is needed.
2) This information is also needed for updating the review baseline.For process improvement and understanding of the review process, the GR summary report is the most important element.
3) The summary report describes the WP;the total effort spent & the amount spent in each of the review process activities;the total number of defects found for each category;& the size of the WP being reviewed.
18-04-2015 SPM_KSP_SP2015 254
Monitoring & Control
1)The effectiveness of the review process depends on how well the process has been deployed. For Ex, if only two defects were found during the review of a 500 line program or a 20 page design document ,clearly the review was not effective.
2)The most common reason for poor review is that it was not done with proper focus & seriousness.
3)How does a PM or a moderator evaluate whether a review has been effective so that she can decide the future course of action?
4)One effective way of monitoring & controlling reviews is to use SPC concepts implementing through control charts.
18-04-2015 SPM_KSP_SP2015 255
Monitoring & Control Reviews Through SPC Techniques
The Review Capability Baseline: How can SPC be applied to monitoring reviews ? To apply SPC,PMs must identify critical performance parameters, determine control limits for them, and then monitor the actual performance.
The control charts can be build by plotting the performance parameters of reviews & then use the plots to evaluate the effectiveness of a review.
Another approach is to set the control limits for the various parameters & then use that range to determine the effectiveness. (Infy follows)
18-04-2015 SPM_KSP_SP2015 256
1)At Infy, the control limits have been determined for the following performance parameters: the coverage rate during preparation, the coverage rate during GR meeting, the defect density for minor or cosmetic defects, & the defect density for serious or major defects(overall defect density is simply the sum of the two).
2)These limits are determined from past data & from the review capability baseline.
18-04-2015 SPM_KSP_SP2015 257
Review Capability Baseline Review team Preparation
Coverage Rate
Group Review
Coverage Rate
Defect Density
Cosmetic/Minor
Serious/Major
Defect Density
Requirements 5-7 pages/Hr 0.5-1.5
defects/page
0.1-0.3
defects/page
High-level
design
4-5 pages/Hr 0.5-1.5
defects/page
0.1-0.3
defects/page
Detailed design 3-4 pages/Hr 0.5-1.5
Defects/page
0.2-0.6
Defects/page
Code 160-200
LOC/Hr
110-150 LOC/Hr 0.01-0.06
Defects/LOC
0.01-0.06
defects/LOC
Integration Test
Plan
5-7 pages/Hr 0.5-1.5
defects/page
0.1-0.3
Defects/page
Integration test
cases
3-4 pages/Hr
System test plan 5-7 pages/Hr 0.5-1.5
defects/page
0.1-0.3
Defects/page
System test
cases
3-4 pages/Hr
Project
Management &
CM Plan
4-6 pages/Hr 2-4 pages/Hr 0.6-1.8
Defects/page
0.1-0.3
defects/page 18-04-2015 SPM_KSP_SP2015 258
3)The rates for One–Person reviews differ. Detailed design documents, test plans,& code undergo this form of review regularly. Hence One-Person review baseline has been developed for these WPs.
4)In the baseline for one person review of documents, the coverage rate/Hr is about twice the corresponding coverage rate of GRs;
The defect detection rate/page is about half of that found with GRs.
For code,the coverage rate /hr is about the same,but the defect detection rate/LOC is about 30% less.
18-04-2015 SPM_KSP_SP2015 259
Analysis & Control Guidelines:
The ranges given in the baseline are used to determine whether the performance of the review falls within acceptable limits. This check is specified as an exit criterion for the review process.
Instead of using review capability baseline,a PM can monitor reviews using an SPC tool developed in-house(spreadsheet).
This tool has the capability baseline data built into it & it also has data about DIR, DRE, quality capability, and so on. From this data, the tool determines the performance specifications for a review-i.e ,the range in which its outcome is expected to fall if the quality goal is to be met.
18-04-2015 SPM_KSP_SP2015 260
The SPC tool gives warnings when a piece of review data falls outside either the control limits or the expected limits. If the defect density found in a review is not within a range given in the baseline,it does not automatically mean failure of the review. The PM or the moderator critically evaluates the situation & decides on the next steps(The preparation rate(PR) & the review rate(RR) become very useful here.).If the RR is “too fast” compared with given in baseline, the reason for the ineffectiveness of the review is relatively clear. The PM and moderator can use any technique to determine the cause of performance deviation & the corrective & preventive actions can be taken(guidelines)
18-04-2015 SPM_KSP_SP2015 261
Possible Reason Action to Consider
WP was very simple Convert GR of similar WPs to one-person
review.
Combine reviews
Reviews may not be thorough Check Coverage rate; if too low,
reschedule a review, perhaps with a
different team.
Reviews do not have sufficient training on
group reviews or exp. With the review
material.
Schedule or conduct GR training.
Re-review with a different team.
WP is of very good quality Confirm this fact by coverage rate,exp of
the author,reviews and so on;see if the
quality can be duplicated in other parts of
the project.
Revise defect prediction in downstream
activities ;see if there are general process
improvement lessons.
18-04-2015 SPM_KSP_SP2015 262
If defects found are less than Norms
If defects found are more than Norms
WP is of low quality Examine training needs for author.
Have the WP redone.
Consider reassigning future
tasks(e.g.assign easier tasks only to
author)
WP is very complex Ensure good review or testing
downstream.
Increase estimates for ST.
Break the WP into smaller components.
There are too many minor defects (& too few
major defects)
Identify causes of minor defects; correct
in the future by suitably enhancing
checklists & making authors aware of
common causes.
Reviews may have insufficient
understanding of the WP.If so,hold an
overview meeting or have another review
with different reviewers.
18-04-2015 SPM_KSP_SP2015 263
Static control limits work well when the process is operating in a steady state. If changes are consciously made to the process, control charts must be used with care because the process performance is expected to change. If changes in the process are likely to be regular ,it is best to have dynamic control limits. If the review process is changed & if it is expected that the reviews will detect 10% more defects, then when a point falls outside the control limits,this fact should be taken into account during analysis(Used at Infy when DP is employed during reviews.
18-04-2015 SPM_KSP_SP2015 264
With DP, the DIR is expected to decline, the defect density detected in reviews is also likely to fall. If a project is using DP, then during project planning the expected impact of DP is also recorded.
Using DIR,the expected reduction from using DP,and the defect detection rate,the expected limits for performance are established.If a review performance falls outside these limits,it is carefully examined for causes.
18-04-2015 SPM_KSP_SP2015 265
NAH Syndrome
1)A programmer cannot understand how a review by a group of people can be more effective than testing .When human effort is the most critical resource in a project, it is not easy to accept the position that the highly manpower-intensive review process can make the overall process more productive & improve quality.
2)As a result convincing people to use reviews is one of the most difficult process deployment tasks.
3)SEI report indicates that only 22% of s/w organization employs some form of inspections.
18-04-2015 SPM_KSP_SP2015 266
4)A fair amount of published data supports the claim that reviews can be cost effective & can improve quality substantially. Nevertheless, such published data from organizations around the world often fail to convince engineers that reviews can be good for their organization.
5)One reason for this skepticism is Not Applicable Here(NAH)Syndrome.
6)People believe that reviews are good for other organizations but that the situation in their company is different & thus the reviews are not applicable.
18-04-2015 SPM_KSP_SP2015 267
7)If inspections are to be deployed in a project ,the NAH syndrome must be overcome. Managers as well as developers must be shown that inspections can provide benefits. By definition ,data from other organizations cannot be used to overcome NAH syndrome. Instead data from within the Organization itself must be used to build a case for inspections.
8)An experimental setup is needed that can quickly deployed in real life scenarios to evaluate the suitability of inspections in the organization.
18-04-2015 SPM_KSP_SP2015 268
The Infy Experiment
18-04-2015 SPM_KSP_SP2015 269
Program units
Defect, effort data
Defect, effort data Historical data for
System Testing
Effectiveness Analysis
Code Inspection
Compare & Analyze
Unit Testing
1)For Infy Experiment, six System Enhancement Requests (SERs) on a banking product were selected. Six developers were assigned one SER. These developers were first trained in the inspection process; for practice they were asked to inspect the implementation of an earlier SER that had been seeded with defects.
2)The personnel were divided into two groups of three developers each. Each group formed an inspection team. Before submitting the SER ,each developer was asked to implement the SER, compile his code,& do self testing. Once submitted the SER went through two independent paths: Inspection and UT.
18-04-2015 SPM_KSP_SP2015 270
3) During the experiment ,an inspection team inspected the code of the three SERs developed by the members of the group.In each inspection,the author,rather than the moderator or the reader,acted as an inspector.In parallel,the SERs were UT independently by the module leader for the domain to which the SER belonged.
4)For each of the two paths,the effort spent & defects found were recorded. These data were then used to evaluate the cost-effectiveness & quality of the reviews.
18-04-2015 SPM_KSP_SP2015 271
Effort & Defect Data
Size SER Total Effort
LOC Hrs
Total No.of
Defects
Total Effort
Hrs
Total no.of
defects
1 968 8.0 8 2.0 4
2 432 5.0 8 1.5 3
3 85 4.0 4 1.5 1
4 667 6.5 26 1.5 7
5 50 12.5 3 1.5 0
6 408 2.5 5 2.5 5
Total 2610 27.5 54 10.5 20
18-04-2015 SPM_KSP_SP2015 272
Inspections Unit Testing
Defect Distribution
Defect Type Inspections Unit Testing Common
Defects
Data 3 1 0
Function 4 2 0
Interface 14 11 7
Logic 12 5 4
Maintainability 11 0 0
Portability 5 0 0
Other 5 1 1
Total 54 20 12
18-04-2015 SPM_KSP_SP2015 273
Project Monitoring & Control Project Tracking
A project plan, no matter how carefully prepared ,is still only a piece of paper .During project execution PM must carefully monitor that the project must go according to the plan .if any deviations found ,take action/steps to bring project on track.
Case A:X is a PM I/c of developing a secure transaction system for a large mutual fund company. His team ,consisting of many dedicated but junior people, had little experience in computer security. The UT for the first few modules found a large number of defects-much more than expected. Upon analysis . X concluded that because of the difficulty of the programs & the experience of the programmers, the code being produced had more defects. Consequently ,he felt ,more defects would reach IT & ST stage,& unless something was done,more defects would be delivered.
18-04-2015 SPM_KSP_SP2015 274
The corrective & preventive action X took was to create a separate test team for testing. Through discussion with the customer ,he was able to expand the ST phase by 15 days. Finally ,even though there was a delay of 15 days, the delivered system exceeded its quality goal by showing fewer than expected defects during AT.
Case B:After the detailed design phase,the milestone analysis in ACIC project showed that even though there was no schedule slippage, there was an effort over run of 40%. Because the schedule had not slipped,no action was taken.At the next milestone a month later,however,the project showed a delay of one week,which ACIC explained as the result of special circumstances.Eventually ,the development was finished one month late.The number of defects found in AT was many.The project failed on all the three dimensions:effort,schedule and quality. Later analysis showed that he had misunderstood the scope of the system & consequently had grossly underestimated the effort.
If the scope or the schedule had been renegotiated when problems first appeared after the design milestone,the final outcome would have been entirely different.
18-04-2015 SPM_KSP_SP2015 275
Project Monitoring & Control Cycle
18-04-2015 SPM_KSP_SP2015 276
Analyze & predict
Apply
management
control
Gather
measurements
Execute Project
Project Tracking
Activities Tracking: is to ensure that planned activities are done on time, at Infosys activities are usually scheduled using Microsoft Project(MSP).Hence it is also used for activities tracking.
The PM checks the status of the scheduled tasks & updates the status in MSP.
Defects Tracking: Infy uses DCS(Defect Control System) for tracking defects.Once information about a defect is entered in this system ,it remains open until it has been fixed. The defect is marked as “closed” when its removal has been verified. In this way each defect is logged & tracked to closure.
18-04-2015 SPM_KSP_SP2015 277
Issues Tracking: Many small jobs or clarifications come up during a project, these problems are called issues. Managing issues is an important task for any PM because they can be numerous & can potentially delay a project.
Ex. Clarification sought regarding a requirement from the customer (an issue)can delay many activities unless it is resolved.Many such issues have the potential to stop some activities,hence it is important for PM to track & manage issues properly.
Use of issues log.(MSP can be used).
18-04-2015 SPM_KSP_SP2015 278
Status Reports: Status reports are the main mechanism for regularly communicating the state of the project to senior management & the customer. The status reports are generated weekly & contain :
i)Customer Complaints
ii)Milestones achieved this week
iii)Milestones missed this week & the reasons for them.
iv)Milestones planned for the next week.
v) Issues requiring clarification or attention.
vi)Escalation, if any
vii)Estimated work versus available time by milestone.
18-04-2015 SPM_KSP_SP2015 279
Milestone Analysis
A status report provides the mechanism for regular monitoring of the project. It focuses on whether the schedule is being met.
A key advantage of status reports is that they do not require very much metrics data or analysis.
How metrics are used at Infy to evaluate the state of a project at milestones?
If the project has been carefully derived and evaluated ,the project will succeed if the plan is followed.Therefore,a MILESTOE ANALYSIS should use the project plan & schedule as its baseline & compare the plan to the actual progress.
18-04-2015 SPM_KSP_SP2015 280
This strategy is employed in the two common approaches for metrics based tracking:
Cost-Schedule –Milestone Chart
Earned Value Method.
Analyzing planned Vs Actual progress is considered a best practice for project management.
Actual Vs Estimated Analysis of Effort & Schedule.
To differnetiate between the normal from significant deviation. Acceptable deviation limits are set in the project plan .
Many projects at Infy have a limit of about 20% for effort deviation & 10% for schedule deviation.The actual limits for a project are specified in its management plan.
18-04-2015 SPM_KSP_SP2015 281
Guidelines for Effort/Schedule Performance
Possible Reasons Actions to Consider
If Actual is less than Estimate by
More than the Allowable limit
Estimates for programs were too
high or project team has more
domain knowledge or esperience
than expected.
Reestimate for future modules.
Release resources.
The Tasks so far have not been
thoroughly performed
Review tasks done so far &
schedule reviews for WPs not
reviewed.
If Actual is More than Estimate
by More than the Allowable limit
Less domain knowledge Schedule training
Low S/w/coding exp of author Reassign to leverage existing exp.
New Technology area Reestimate or request resources
Negotiate delivery dates. 18-04-2015 SPM_KSP_SP2015 282
Monitoring Quality
To monitor the third dimension-Quality-the main metric is the number of defects found. In addition
The number & status of reviews done & the status & effect of DP activities are also monitored.
Because the number of defects was also estimated during planning, defects are accessed in the same way as schedule & effort.
Using defect levels predicted in the project plan for various stages & the actual number of defects found ,the PM prepares an actual Vs estimated analysis.
18-04-2015 SPM_KSP_SP2015 283
Guidelines If the number of Defects Found Differs from the Estimate
Possible Reasons Actions to Consider
If Fewer than Estimate
WP is of high quality. Identify reason & see whether there
are possible lessons for the project
or for the process.
Inadequate testing Check the effort spent on
testing;review the test plan &
enhance it.
Schedule further testing.
Defect estimates are too high Identify cause & correct estimates.
If More than Estimate
Inadequate execution of quality
control activities so far
Examine all testing & review records.
Schedule reviews of critical modules
before continuing with testing
Defect estimate are too low Identify cause & correct estimates.
18-04-2015 SPM_KSP_SP2015 284
Risk-Related Monitoring
Risks & related activities are also monitored at milestones.
Risks for project are not static ;Risk perceptions change over time & as risk mitigation steps are executed.
Thus ,it is important to take stock of risks & note the effects of risks mitigation steps taken so far.
For this reason ,the current risk perception ,along with the status of current risk mitigation steps,is reported in the milestone analysis report
18-04-2015 SPM_KSP_SP2015 285
Activity-level Analysis(ALA)
Milestone analysis uses metrics to monitor the state of the project at defined milestones & to suggest corrective actions if needed.
However, with milestone-based analysis, it is hard to determine which of the many activities performed since the last milestone may be the cause of performance degradation.
This situation is similar to ST; debugging is much harder when the system comprises many units.It is far easier to debug during UT.
To provide finer control, activity level analysis is also done at Infy.
18-04-2015 SPM_KSP_SP2015 286
In AL analysis, some metrics are analysed immediately after a task is performed .The analysis is used to evaluate the effectiveness of the task performance .If the task has not been performed satisfactorily ,immediate action can be taken to correct it & to prevent a repetition.
Al analysis is usually done using SPC.
At Infy ,reviews & UT have been identified as the two tasks for which SPC is applied.
Using Control charts,the PM immediately evaluates the effectiveness of a review or UT. If the performance is not satisfactory ,necessary action can be taken.
18-04-2015 SPM_KSP_SP2015 287
Broad activities of design, detailed design, ST etc are already evaluated individually through milestone analysis because they typically start & finish at milestones.
Hence the focus of AL analysis is on the coding related activities of reviews & UT.
18-04-2015 SPM_KSP_SP2015 288
UT Defect Rates for Some Language:
18-04-2015 SPM_KSP_SP2015 289
Language Defect Rate Range(Avg)
PB(PowerBuilder) 0.0003-0.0266 defects/LOC(avg:0.008)
C 0.0004-0.0206
defects/LOC(avg:0.0052)
C++ 0.00009-0.0067
defects/LOC(avg:0.0017)
RPG(Report Program Generator) 0.0006-0.0075
defects/LOC(avg:0.0025)
Defect Analysis & Prevention
DP aims to learn from defects found so far on the project & to prevent defects in the rest of the project. DP activities are done twice in a project :once when about 20% of the modules have been coded & UT, and again when 50 % of the modules have been coded and UT.
The main task of DP are to perform Pareto Analysis to identify the main defect types, perform causal analysis to identify the causes of defects,& identify solutions to attack the causes.
18-04-2015 SPM_KSP_SP2015 290
Pareto Analysis
It is one of the primary technique used for analysing causes. Also imp tool for quality management.
Also called as 80-20 rule(80% of the problems come from 20% of the possible sources.)In s/w it can mean that 80% of the defects stem from 20% of the root causes or that 80% of the defects are found in 20 % of the code.
1)The first step in DP is to draw a Pareto chart from the defect data.
2)The number of defects found of different types is computed from defect data & is plotted as bar chart in decreasing order.
3)Along with the bar chart another,another chart is plotted on the same graph showing the cumulative number of defects as we move from types of defects on the left of the X axis to the right of the x-axis.
18-04-2015 SPM_KSP_SP2015 291
4)The Pareto chart makes it immediately clear in visual as well as quantitative terms which are the main types of defects,& also which types of defects together form 80%-85% of the total defects.
Procedure:
a)List all the defects identified so far.
b)Calculate the total number of defects by type.
c)Sort defects by type in descending order of number of defects.
d)Calculate the percentage of each defect type with respect to the total number of defects detected.
e)Identify the defect type that is the cause for the 80% of the total defects.
18-04-2015 SPM_KSP_SP2015 292
18-04-2015 SPM_KSP_SP2015 293
18-04-2015 SPM_KSP_SP2015 294
18-04-2015 SPM_KSP_SP2015 295
18-04-2015 SPM_KSP_SP2015 296
Performing Causal Analysis
1)The Pareto chart helps to identify the main types of defects that have found in the project so far & are likely to be found in the rest of the project unless action is taken.
2)Theses defects can be treated as “effects” that you want to minimize in the future.To reduce these defects,you must find their main causes & then try to eliminate them.
3)A cause–effect(CE) diagram can be used to determine the causes of the observed effects.Ex,The CE diagram can be used to determine the main causes for the high number of GUI defects(or logic defects) in the ACE project.
4)The main purpose of CE diagram is to graphically represent the relationship between an effect & its various possible causes.
Understanding the causes helps to identify solutions to eliminate them.
18-04-2015 SPM_KSP_SP2015 297
Identify the effect to be analyzed .In the ACE example,the effect could be :too many GUI errors”.To identify the causes,you first establish some major categories of causes.
For manufacturing, these major causes often are :manpower, machines, methods, materials, measurement, & environment.
For causal analysis at Infy:The standard set of major causes of defects is:process,people,technology,& training.
18-04-2015 SPM_KSP_SP2015 298
18-04-2015 SPM_KSP_SP2015 299
Standards/checklists Unclear/incorrect Specs.
Not documented well Technical Problems
Lack of Technical Skills Oversight
Lack of Training Standards not followed
Process Technology
Logic/UI/
standard
defects
Training People
To analyze the causes, the key is to ask,” Why does this cause produce this effect?” for each of the major causes. The answers to these questions become subcauses & are represented as short horizontal lines joining the line representing the major cause.
This “Why-Why-Why” process is repeated until all the root causes have been identified i.e, the causes for which asking “Why” no longer makes sense. When all the causes are marked in the diagram,the final picture looks like a fish-bone structure.(Fish-Bone Diagram, Ishikawa Diagram).
18-04-2015 SPM_KSP_SP2015 300
Developing & Implementing Solutions
We have identified the types of frequently occurring defects & their root causes. The next phase is to take action to reduce the occurrence of defects.
The basic paradigm is the adage”An ounce of prevention is worth a pound of cure”. With DP, you are not trying to “cure” the S/w of defects; instead ,you are taking preventive actions so that s/w does not “fall sick” from defects.
Common prevention actions are creating or improving checklists, holding training programs & reviews,& using a specific tool.
18-04-2015 SPM_KSP_SP2015 301
Process Monitoring & Audit
Conducting the Audit Audit checklists
NCR(Noncompliance Report)
Follow-up Actions NCR with Corrective Action
18-04-2015 SPM_KSP_SP2015 302
Project Closure
Project Closure Analysis:
a)The Role of Closure Analysis
b)Performing Closure Analysis
c) Closure Analysis Report:
i)General & Process Related Information
ii)Risk Management
iii)Size
iv)Effort
v)Defects
vi)Causal analysis
vii)Process Assets
18-04-2015 SPM_KSP_SP2015 303
References
1)Pankaj Jalote:Software Project Management in Practice,Pearson Education, NewDelhi
2)Bob Hughes, Mike Cotterell, Rajib Mall, :Software Project Management ,Tata McGraw Hill, NewDelhi,Special Indian Edition,2011.
18-04-2015 SPM_KSP_SP2015 304
