+ All Categories

Spm ksp

Date post: 07-Aug-2015
Category:
Upload: ktosri
View: 208 times
Download: 0 times
Share this document with a friend
Popular Tags:
304
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
Transcript
Page 1: Spm ksp

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

Page 2: Spm ksp

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

Page 3: Spm ksp

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

Page 4: Spm ksp

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

Page 5: Spm ksp

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

Page 6: Spm ksp

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

Page 7: Spm ksp

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.)

Page 8: Spm ksp

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

Page 9: Spm ksp

• 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

Page 10: Spm ksp

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

Page 11: Spm ksp

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

Page 12: Spm ksp

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

Page 13: Spm ksp

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

Page 14: Spm ksp

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

Page 15: Spm ksp

Cont.

• GOALS

• COMMITMENT

• ABILITY

• MEASUREMENT

• VERIFICATION

18-04-2015 SPM_KSP_SP2015 15

Page 16: Spm ksp

CMM(developed in mid 1980)

18-04-2015 SPM_KSP_SP2015 16

Page 17: Spm ksp

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

Page 18: Spm ksp

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

Page 19: Spm ksp

KPAs(Key Process Areas)

• LEVEL-4(Managed)

S/w Quality Management

Quantitative Process Management

18-04-2015 SPM_KSP_SP2015 19

Page 20: Spm ksp

KPAs(Key Process Areas)

• LEVEL-5(Optimizing)

Process Change Management

Technology Change Management

Defect Prevention

18-04-2015 SPM_KSP_SP2015 20

Page 21: Spm ksp

18-04-2015 SPM_KSP_SP2015 21

Page 22: Spm ksp

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

Page 23: Spm ksp

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

Page 24: Spm ksp

• 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

Page 25: Spm ksp

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)

Page 26: Spm ksp

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

Page 27: Spm ksp

Elements of Planning Infrastructure.

• PDB(Process D/b)

• PCB(Process Capability Baseline)

• Process Assets

18-04-2015 SPM_KSP_SP2015 27

Page 28: Spm ksp

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

Page 29: Spm ksp

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

Page 30: Spm ksp

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

Page 31: Spm ksp

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

Page 32: Spm ksp

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

Page 33: Spm ksp

• 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

Page 34: Spm ksp

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

Page 35: Spm ksp

• PCB table

18-04-2015 SPM_KSP_SP2015 35

Page 36: Spm ksp

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

Page 37: Spm ksp

• 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

Page 38: Spm ksp

• 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

Page 39: Spm ksp

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

Page 40: Spm ksp

18-04-2015 SPM_KSP_SP2015 40

Process

Checklists Guidelines Templates

Activity Review

Page 41: Spm ksp

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

Page 42: Spm ksp

• 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

Page 43: Spm ksp

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

Page 44: Spm ksp

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

Page 45: Spm ksp

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

Page 46: Spm ksp

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

Page 47: Spm ksp

Process

Tailoring

Characteristics of the

Project

Standard Process Process for the

project

Tailoring Guidelines

18-04-2015 SPM_KSP_SP2015 47

Page 48: Spm ksp

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

Page 49: Spm ksp

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

Page 50: Spm ksp

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

Page 51: Spm ksp

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

Page 52: Spm ksp

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

Page 53: Spm ksp

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

Page 54: Spm ksp

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

Page 55: Spm ksp

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

Page 56: Spm ksp

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

Page 57: Spm ksp

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

Page 58: Spm ksp

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

Page 59: Spm ksp

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

Page 60: Spm ksp

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

Page 61: Spm ksp

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

Page 62: Spm ksp

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

Page 63: Spm ksp

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

Page 64: Spm ksp

• 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

Page 65: Spm ksp

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

Page 66: Spm ksp

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

Page 67: Spm ksp

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

Page 68: Spm ksp

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

Page 69: Spm ksp

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

Page 70: Spm ksp

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

Page 71: Spm ksp

Manpower Ramp-up

Peak Team size

Design Build Test

18-04-2015 SPM_KSP_SP2015 71

Page 72: Spm ksp

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

Page 73: Spm ksp

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

Page 74: Spm ksp

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

Page 75: Spm ksp

𝑦 𝑡 = 𝐾[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

Page 76: Spm ksp

‘𝑡𝑑 ’=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

Page 77: Spm ksp

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

Page 78: Spm ksp

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

Page 79: Spm ksp

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

Page 80: Spm ksp

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

Page 81: Spm ksp

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

Page 82: Spm ksp

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

Page 83: Spm ksp

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

Page 84: Spm ksp

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

Page 85: Spm ksp

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

Page 86: Spm ksp

• 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

Page 87: Spm ksp

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

Page 88: Spm ksp

• 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

Page 89: Spm ksp

Development

Process Defect Injection

Defect Removal

Req Analysis R Design R Coding R UT IT/ST AT

18-04-2015 SPM_KSP_SP2015 89

Page 90: Spm ksp

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

Page 91: Spm ksp

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

Page 92: Spm ksp

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

Page 93: Spm ksp

QQM Planning

1)Setting the Quality goal

2)Estimating Defects for other Stages

3)Quality Process Planning

18-04-2015 SPM_KSP_SP2015 93

Page 94: Spm ksp

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

Page 95: Spm ksp

• 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

Page 96: Spm ksp

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

Page 97: Spm ksp

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

Page 98: Spm ksp

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

Page 99: Spm ksp

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

Page 100: Spm ksp

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

Page 101: Spm ksp

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

Page 102: Spm ksp

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

Page 103: Spm ksp

• 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

Page 104: Spm ksp

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

Page 105: Spm ksp

• 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

Page 106: Spm ksp

• 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

Page 107: Spm ksp

• 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

Page 108: Spm ksp

• 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

Page 109: Spm ksp

“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

Page 110: Spm ksp

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

Page 111: Spm ksp

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

Page 112: Spm ksp

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

Page 113: Spm ksp

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

Page 114: Spm ksp

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

Page 115: Spm ksp

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

Page 116: Spm ksp

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

Page 117: Spm ksp

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

Page 118: Spm ksp

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

Page 119: Spm ksp

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

Page 120: Spm ksp

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

Page 121: Spm ksp

Risk Management & Project Execution

18-04-2015 SPM_KSP_SP2015 121

Other Factors

Information Control

Project ’ s Process

Risk Assessment

Risk Monitoring

Managing

Risks

Page 122: Spm ksp

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

Page 123: Spm ksp

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

Page 124: Spm ksp

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

Page 125: Spm ksp

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

Page 126: Spm ksp

• 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

Page 127: Spm ksp

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

Page 128: Spm ksp

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

Page 129: Spm ksp

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

Page 130: Spm ksp

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

Page 131: Spm ksp

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

Page 132: Spm ksp

Risk Categories

Risk

Management Technical

Process Project Product

18-04-2015 SPM_KSP_SP2015 132

Page 133: Spm ksp

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

Page 134: Spm ksp

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

Page 135: Spm ksp

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

Page 136: Spm ksp

Lyytinen-Mathiassen-Ropponen (LMR) Risk Framework

18-04-2015 SPM_KSP_SP2015 136

ACTORS

TECHNOLOGY STRUCTURE

TASKS

Page 137: Spm ksp

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

Page 138: Spm ksp

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

Page 139: Spm ksp

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

Page 140: Spm ksp

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

Page 141: Spm ksp

Probability impact matrix

Tolerance line

High

Significant

Moderate

Low

R6 R1

R2,R3,R5

R4

18-04-2015 SPM_KSP_SP2015 141

Page 142: Spm ksp

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

Page 143: Spm ksp

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

Page 144: Spm ksp

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

Page 145: Spm ksp

• 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

Page 146: Spm ksp

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

Page 147: Spm ksp

• 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

Page 148: Spm ksp

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

Page 149: Spm ksp

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

Page 150: Spm ksp

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

Page 151: Spm ksp

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

Page 152: Spm ksp

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

Page 153: Spm ksp

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

Page 154: Spm ksp

NATURAL

CHARACTERISTIC

ASSIGNABLE

PROCESS

18-04-2015 SPM_KSP_SP2015 154

Page 155: Spm ksp

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

Page 156: Spm ksp

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

Page 157: Spm ksp

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

Page 158: Spm ksp

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

Page 159: Spm ksp

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

Page 160: Spm ksp

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

Page 161: Spm ksp

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

Page 162: Spm ksp

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

Page 163: Spm ksp

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

Page 164: Spm ksp

• 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

Page 165: Spm ksp

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

Page 166: Spm ksp

Life Cycle of a Defect

Entered by

Submitter Fixed by Checked by

Owner Submitter

Submitted Fixed Closed

18-04-2015 SPM_KSP_SP2015 166

Page 167: Spm ksp

• 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

Page 168: Spm ksp

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

Page 169: Spm ksp

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

Page 170: Spm ksp

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

Page 171: Spm ksp

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

Page 172: Spm ksp

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

Page 173: Spm ksp

• 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

Page 174: Spm ksp

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

Page 175: Spm ksp

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

Page 176: Spm ksp

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

Page 177: Spm ksp

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

Page 178: Spm ksp

Hierarchical team organization

18-04-2015 SPM_KSP_SP2015 178

Page 179: Spm ksp

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

Page 180: Spm ksp

Chief Programmer Team

18-04-2015 SPM_KSP_SP2015 180

Page 181: Spm ksp

Matrix organization

18-04-2015 SPM_KSP_SP2015 181

Page 182: Spm ksp

• 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

Page 183: Spm ksp

Democratic or Open structured teams

18-04-2015 SPM_KSP_SP2015 183

Why are democratic teams often favored in Extreme Programming process?

Page 184: Spm ksp

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

Page 185: Spm ksp

At Infosys

Project

Manager

Business Manager/

A/c Manager

Database

Administrator

Configuration

Controller

Developers

18-04-2015 SPM_KSP_SP2015 185

Page 186: Spm ksp

• 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

Page 187: Spm ksp

• 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

Page 188: Spm ksp

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

Page 189: Spm ksp

• 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

Page 190: Spm ksp

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

Page 191: Spm ksp

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

Page 192: Spm ksp

• 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

Page 193: Spm ksp

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

Page 194: Spm ksp

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

Page 195: Spm ksp

• 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

Page 196: Spm ksp

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

Page 197: Spm ksp

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

Page 198: Spm ksp

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

Page 199: Spm ksp

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

Page 200: Spm ksp

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

Page 201: Spm ksp

• 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

Page 202: Spm ksp

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

Page 203: Spm ksp

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

Page 204: Spm ksp

• 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

Page 205: Spm ksp

• 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

Page 206: Spm ksp

• 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

Page 207: Spm ksp

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

Page 208: Spm ksp

LocalVCS

18-04-2015 SPM_KSP_SP2015 208

Page 209: Spm ksp

CentralizedVCS

18-04-2015 SPM_KSP_SP2015 209

Page 210: Spm ksp

• 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

Page 211: Spm ksp

• 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

Page 212: Spm ksp

DVCS

Distributed VCS

18-04-2015 SPM_KSP_SP2015 212

Page 213: Spm ksp

• 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

Page 214: Spm ksp

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

Page 215: Spm ksp

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

Page 216: Spm ksp

• 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

Page 217: Spm ksp

• 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

Page 218: Spm ksp

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

Page 219: Spm ksp

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

Page 220: Spm ksp

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

Page 221: Spm ksp

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

Page 222: Spm ksp

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

Page 223: Spm ksp

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

Page 224: Spm ksp

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

Page 225: Spm ksp

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

Page 226: Spm ksp

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

Page 227: Spm ksp

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

Page 228: Spm ksp

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

Page 229: Spm ksp

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

Page 230: Spm ksp

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

Page 231: Spm ksp

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

Page 232: Spm ksp

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

Page 233: Spm ksp

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

Page 234: Spm ksp

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

Page 235: Spm ksp

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

Page 236: Spm ksp

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

Page 237: Spm ksp

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

Page 238: Spm ksp

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

Page 239: Spm ksp

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

Page 240: Spm ksp

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

Page 241: Spm ksp

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

Page 242: Spm ksp

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

Page 243: Spm ksp

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

Page 244: Spm ksp

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

Page 245: Spm ksp

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

Page 246: Spm ksp

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

Page 247: Spm ksp

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

Page 248: Spm ksp

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

Page 249: Spm ksp

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

Page 250: Spm ksp

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

Page 251: Spm ksp

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

Page 252: Spm ksp

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

Page 253: Spm ksp

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

Page 254: Spm ksp

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

Page 255: Spm ksp

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

Page 256: Spm ksp

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

Page 257: Spm ksp

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

Page 258: Spm ksp

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

Page 259: Spm ksp

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

Page 260: Spm ksp

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

Page 261: Spm ksp

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

Page 262: Spm ksp

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

Page 263: Spm ksp

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

Page 264: Spm ksp

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

Page 265: Spm ksp

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

Page 266: Spm ksp

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

Page 267: Spm ksp

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

Page 268: Spm ksp

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

Page 269: Spm ksp

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

Page 270: Spm ksp

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

Page 271: Spm ksp

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

Page 272: Spm ksp

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

Page 273: Spm ksp

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

Page 274: Spm ksp

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

Page 275: Spm ksp

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

Page 276: Spm ksp

Project Monitoring & Control Cycle

18-04-2015 SPM_KSP_SP2015 276

Analyze & predict

Apply

management

control

Gather

measurements

Execute Project

Page 277: Spm ksp

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

Page 278: Spm ksp

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

Page 279: Spm ksp

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

Page 280: Spm ksp

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

Page 281: Spm ksp

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

Page 282: Spm ksp

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

Page 283: Spm ksp

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

Page 284: Spm ksp

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

Page 285: Spm ksp

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

Page 286: Spm ksp

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

Page 287: Spm ksp

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

Page 288: Spm ksp

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

Page 289: Spm ksp

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)

Page 290: Spm ksp

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

Page 291: Spm ksp

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

Page 292: Spm ksp

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

Page 293: Spm ksp

18-04-2015 SPM_KSP_SP2015 293

Page 294: Spm ksp

18-04-2015 SPM_KSP_SP2015 294

Page 295: Spm ksp

18-04-2015 SPM_KSP_SP2015 295

Page 296: Spm ksp

18-04-2015 SPM_KSP_SP2015 296

Page 297: Spm ksp

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

Page 298: Spm ksp

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

Page 299: Spm ksp

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

Page 300: Spm ksp

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

Page 301: Spm ksp

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

Page 302: Spm ksp

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

Page 303: Spm ksp

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

Page 304: Spm ksp

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


Recommended