SPM - PART2 (4 Chapters)

8/3/2019 SPM - PART2 (4 Chapters)

1/66


2/66

Outline of presentation

Software Project Mangement by AyazAhmed Shariff K22

Chapter 5: Quality Planning

Chapter 6: Risk Management

Chapter 7: Measurementsand Tracking planning

Chapter 8: ProjectManagement Plan


3/66

By

Ayaz Ahmed Shariff K

Asst. Professor; Dept of CSE;BITIC-RAK-UAE


CH-05: Quality Planning


4/66

5.1 Quality Planning


SE suffered same tragic notion of quality thatmanufacturing companies suffered earlier.

PMs are quality conscious during systemtesting or before delivering a product but failto give importance during developmentprocess.

Like for Effort and Schedule, we can use data

of completed projects and experience foreffective planning.

This chapter focus on how PMs at Infosys setthe quality goals for their projects and how

they develop plan to achieve these goals.


5/66

5.2. Quality Concepts


Delivered Defect Density (DDD):Number of defects per unit size in thedelivered software definition of quality

Defect: Something which causes softwareto behave in inconsistent manner or deviatesfrom the requirements

Defect Injection: Defects can be injected

during any transformational activities likerequirements specification, HLD, Detaileddesign and Coding.

Removal cycle: Active removal of defects

are necessary to deliver a high-quality


6/66


//Japan's quality standard

This speaks a lot about the Japanese quality standardsand also cultural misunderstandings.

They're still laughing about this at IBM. Apparently thecomputer giant decided to have some partsmanufactured in Japan as a trial project. In thespecifications, they set out that they will accept three

defective parts per 10,000 .

When the delivery came in there was an accompanyingletter. "We, Japanese people, had a hard timeunderstanding North American business practices. Butthe three defective parts per 10,000 have beenseparately manufactured and have been included in the

"


7/66

5.3 Defect Injection andRemoval


The defect removal efficiency (DRE) gives ameasure of the development team ability toremove defects prior to release. It iscalculated as a ratio of defects resolved to

total number of defects found. It is typicallymeasured prior and at the moment ofrelease.

DRE = Number of defects resolved by thedevelopment team / total number of defectsat the moment of measurement.

For example, suppose that 100 defects were


8/66

5.4 Procedural Approachto Quality Management


The task of Quality Management is to plansuitable control activities and then executeaccordingly and control them to achieve theprojects quality goals.

Defects can be detected by performing reviewsor testing.

Reviews are human oriented process, testing isthe process of executing a software.

In procedural approach to quality management:Procedures and guidelines for the review areestablished.


9/66

Procedural Approach toQuality

Management(contd..)


Procedural approach is the execution ofcertain processes at defined points to detectdefects.

This approach is dependent on the quality ofprocedure & the quality of execution. For ex:Planning testing and review gives betterperformance after testing.

Drawback of Procedural approach: Lack ofquantitative terms for PM to access thequality of the software produced.


10/66

5.5 Quantitative Approachto Quality management


If controls are applied based on quantitativedata to achieve quantitative goals, then wesay that quantitative quality managementapproach is applied.

It has 2 key aspects

Setting a Quantitative Quality Goal

Managing as Software development process

quantitatively to meet the Quality goal.

A good quality management approach shouldprovide early warning signs early stages (not

only toward end).


11/66

Quantitative Approach toQuality

management(contd..)


1. One approach to quantitatively control thequality of the s/w is to work with SoftwareReliability Models using the failure dataduring final stages of testing to estimate

reliability of the s/w.

2. Defect removal efficiency(DRE):percentage of existing defects that aredetected by Quality Control(QC) activity. It

can define the quality(DDD) of software ifdefect injection rate is known. But thisapproach is not suitable because the DREof a QC can be computed only at the end

of the projects when all defects are


12/66

Quantitative Approach toQuality

management(contd..)


3. Defect Prediction: Here U set thequality goal in terms of DDD, then U setintermediate goals by estimating defectsidentified in each activity; Finally compare

the actual number of defects to theestimated defect levels. (Effectiveness ofthis approach is depends on how well Ucan predict the defect levels at various

stages of project). Defect rate followsRayliegh curve as effort rate. (it is similarto STEER approach of IBM).

4. Statistical Process Control(SPC): U set

the performance expectations of the


13/66

//Sample interview questionsabout Quality


What is the difference between QA andtesting?

Describe to me the difference betweenvalidation and verification?

What are the three measures in commonuse in Quality?

What are the benefits of Quality

Management System?


14/66

5.6 Quantitative QualityManagement Planning


To know how PMs at Infosys use defectprediction approach for managing Quality inquantitative terms.

Two issues we face for Quantitative Qualitymanagement planning;

1. Setting the Quality Goal

2. Predicting defect levels at intermediatestages which monitor the progress towardsgoal.


15/66

5.6.1 Setting the QualityGoal


The Quality of Goal is the expected numberof defects found during acceptance testing.

Primary sources used for setting the Qualitygoal are:

Past data from similar projects

Data from PCB

Note: It is expressed that U will useStandard Process and hence StandardQuality results will be expected.


16/66

Setting the Quality Goal(contd..)


If U use data from similar projects, U canestimate the number of defects found during theAcceptance Testing(AT) of the current project asthe product of number of defects found during

AT of the similar projects & the ratio of estimatedeffort for this project & the total effort of similarprojects

If U use data from PCB, you can use any of the

several methods to compute this valueFor ex: if we set quality target as the no. of

defects/FP, then

1. Set the quality goal in terms of defects per

FP


17/66

5.6.2 Quality ProcessPlanning


q Set the quality goal that is higher or lowerthan the quality level of similar project

q Determine the number of defects for thehigher goal by using quality goal set forthe project

1. If the quality goal is based on past dataand Quality goal is higher than that of

similar projects, dont use the sameprocess as used in similar projects(upgrade the process)

2. If the quality goal is higher than the

Quality levels of PCB, dont follow the


18/66

5.7 DEFECT PREVENTIONPLANNING


Defect Prevention (DP) intended to improvequality and improve productivity byunderstanding the cause behind thedefection injection and efforts to eliminate

them.q Like any task, the DP activities must be

planned; the following are the DP activitiesemployed at Infosys.

1. Identify a defect prevention team withinthe project

2. Have a kick-off meeting to identify

existing solutions


19/66

Estimates of Defects to BeDetected


Click to edit Master text stylesSecond level Third level Fourth level Fifth level


20/66


Click to edit Master text stylesSecond level Third level Fourth level Fifth level


21/66

Software Project Mangement by AyazAhmed Shariff K

2121

Quality means doing it right whe
http://thinkexist.com/quotation/quality_means_doing_it_right_when_no_one_is/146322.htmlhttp://thinkexist.com/quotation/quality_means_doing_it_right_when_no_one_is/146322.html


22/66

CH-06 Risk Management

Ayaz Ahmed Shariff K

Asst. Professor; Dept. Of CSE

BITIC-RAK-UAE


2222


23/66

Topics to be covered

q Concepts of Riskq Risk Management Activities

q Risk management execution

q Risk Assessment

q Risk Control

q Top 10 common risks

q Risks of ACIC project at Infosys



24/66

6.1 Concepts of RiskManagementRisks are the those events which may occur,and whose occurrence , if does takes place,has a harmful or negative effect on aproject.

Risks should not be confused with events orconditions.

PM should plan and deal with those

situations whose exact nature is unknown,may or may not be risks.

For ex: Its most likely to get change requestsor defects to be found during testing, so plan

it accordingly to handle these events.Software Project Mangement by AyazAhmed Shariff K2424


25/66

Concepts of RiskManagementRisk Management is required to identify risksand then take actions to minimize their effecton the project.

The effects of Risk Management includes

Additional Cost

Additional Effort & schedule

Its not easy to measure the value of RiskManagement so chances that RM systemsused or may not be used.

Therefore Risk assessment is needed and

well the control process to handle risks.Software Project Mangement by AyazAhmed Shariff K2525


26/66

6.2 Risk ManagementActivities Risk Management

Risk Assessment RiskControl

Risk Identification Risk management &Planning

Risk Analysis Risk Resolution

Risk Prioritization Risk monitoringSoftware Project Mangement by Ayaz

Ahmed Shariff K2626


27/66

6.3 Risk Management &Execution

Other Factors

RiskAssessment

Monitoring

Managing Risks

Proje

ctproc

ess



28/66

Risk Management &Execution(contd..)One way to prioritize the risks, is to estimatethe probability of its occurrence & itsconsequences when it does occur. If Prob(R)is probability of risk R occurring, & Loss(R) is

the total loss if risk materializes, then RE(R)is the Risk Exposure given by

RE(R) = Prob(R) * Loss(R)

Risk Management can be integrated in thedevelopment process itself, as its done in thespiral model of software development.

If we treat RM as separate process, we need

to understand its relationship with projectSoftware Project Mangement by Ayaz

Ahmed Shariff K2828


29/66

//Some words

Knowing our risks provides opportunities tomanage and improve our chances ofsuccess Roger VanScoy



30/66

6.3.1 Risk Assessment

Risk Assessment contains 3 traditionalcomponents. The purpose of RiskAssessment is to identify risks, analyze them,organize them and prioritize them.

1. Risk Identification

2. Risk Analysis

3. Risk Prioritization



31/66

6.3.2 Risk Identification

v For a project, any event, condition orsituation that occurs which jeopardize itssuccess, constitutes a Risk.

v Methods to identify risk includechecklists of possible risks, meeting,surveys, brainstorming, reviews of plans,process.

v

At Infosys, the commonly occurringrisks are compiled from survey checklists,PDB of similar projects, and PMsexperience & Judgment



32/66

6.3.3 Risk Prioritization

Prioritization requires analysis the possibleeffects of the risk event if it occurs. If riskmaterializes, what will be the loss to project.

The loss could be direct loss, future businessloss, due to lost business, financial loss, dueto the diminished employee morale, etc.Based on these possible consequences & theprobability of the risk, compute the risk

exposure (RE). Hence RE can be used toprioritize the identified risks.

PROBABILITY

RANGE

Low 0.0 0.3

Medium 0.3 0.7

Level ofConsequence

Range

Low 0.0 to 3.0

Medium 3.0 to 7.0Software Project Mangement by Ayaz

Ahmed Shariff K3232


33/66

Risk Prioritization (contd..)

At Infosys, to rank the effect of a risk on aproject, you must select a unit of impact fromtable below on scale of 1 to 10.

The following is a simple method of riskprioritization:

1. For each risk, rate the probability of its happeningas low, medium or high and assign the probabilityvalues.

2. For each risk, assess its impact on the project aslow, medium or high and assign a weight on a scaleof 1 to 10.

3. Rank the risks based on the probability & effects onthe project.

4. Select few top risk items for mitigation & tracking.



34/66

6.4. Risk Control

Once PM identifies & prioritizes risk, minimize the effect of risk assecond step of risk management. This step is Risk Control.

Risk control involves planning the Risk Mitigation & then executing theplan, finally monitoring them.

1. Risk Management Planning: From prioritized risks, PM is clear withwhich risks to control and manage. The main task is to identify the

actions need to minimize the risk consequence, called Risk Mitigationplan. Commonly used risk mitigation steps are shown in next slide.

2. Risk monitoring & Tracking: Monitor & track the progress of riskmitigation steps and seek fresh risk analysis to check priorities again,if required.



35/66

6.5 Top Ten Risks

SequenceNumber

Risk Category Risk Mitigation Steps

1 Shortage of technicallytrained manpower

Conduct training

2 Too many requirement

changes

Negotiate payment on actual

effort; Convince the clientabout changes;

3 Manpower Attrition Ensure multiple resources;Rotate jobs; Maintaindocumentation

4 Insufficient businessknowledge Increase interaction withclients and ensure KT

5 WORKING ON NEWTECHNOLOGY

Provide training in newtechnology; consider a phaseddelivery

6 UNREALISTIC SCHEDULES Negotiate for a better

schedule; negotiate payment;Software Project Mangement by Ayaz

Ahmed Shariff K3535


36/66

6.6 RMM for ACIC Project

Seq.No

Risks Probability Impact RiskExposure

Mitigation Plan

1 Need supportfrom DB architect

& customersDBA

0.5 8 4 Plan time of thesegroups; Have an

onsite coordinatorwork closely onthese groups

2 Personnelattrition; team

members mightleave on shortnotice

0.9 7 2.1 Assign tasks sothat more than 1

person is aware ofuse cases inproject



37/66

Ex: FIRMA Project RMM plan

//sent through mail



38/66

The person who risksnothing does nothing, has

nothing, is nothing



39/66

CH_07: Measuring & TrackPlanning

AYAZ AHMED SHARIFF K

Asst. Professor (senior grade)BITIC RAK UAE


39

39


40/66

7.1 Metrics

Software Metrics: Software metrics can beused to quantitatively characterize variousaspects of software process or softwareproducts.

Process Metrics: Quantify attributes of thesoftware process or development.

Ex: Defect injection rate, quality,productivity, DRE

Product metrics: It remain independent ofSoftware Project Mangement by Ayaz

Ahmed Shariff K4040


41/66

7.1.1 Metrics &MeasurementsUse of metrics necessarily requires thatmeasurement be made to obtain data.

Basic measurements:

1.

Schedule: Easiest & important metrics, usescalendar time.

2. Effort: Main resource consumed in project. To makestatements such as cost of project is 30% more

3. Defects: Because defects have direct relationship to

s/w quality

4. Size: Fundamental metric because many data arenormalized with respect to size



42/66

7.1.2 Factors affectingvariability of MetricsFactors affecting the variability in the valueof characteristics in metrics are classifiedinto 2 groups.

Natural (inherent) causes of variability

Assignable (Special) causes of variability

natural...

Assignable


process

4242


43/66

Factors affecting variability ofMetrics (contd..)Natural Causes: always present and each willcontribute to the variability. Its not practicalto control these causes.

Assignable Causes: those which occur once

in a while, will have larger influence overvariability in performance, but can becontrolled.



44/66

7.1.3 Statistical ControlProcess (SPC)A process is said to be in statistical control ifthe variability in the quality characteristics isdue to natural causes only.

Goal of SPC: To keep the production process

in statistical control

Control charts are the tools for applying SPC.



45/66

SPC.

A control chart monitors process performanceand identifies process shifts. Control charts canbe used in many ways to monitor:

X- Charts(average charts), R-charts, xmr

chartsAny product specification over time

Number or percent of defects

Financial performance


4545


46/66

SPC.

Steps to build control charts to apply SPC:

1. Consider output of a process to be stream

of numbers representing characteristics2. Make subgroups of data from this stream

3. Find the mean values for subgroups

4. Plot them on X- Bar5. A lower control Limit(LCL) and Upper

control limit(UCL) are established.

6. If a point falls outside the control limits,Software Project Mangement by Ayaz

Ahmed Shariff K4646


47/66

SPC - Actions, if output fallsoutside control limitsThe following are the actions to be performedif the output falls outside the control limits inX-bars or R-chart:

Rework the output so that it has acceptable

characteristics (take corrective action).

Conduct further analysis to identify theassignable causes and eliminate them from

process(preventive actions).


4747


48/66

7.2 Measurements

To perform measurements during projectexecution, you must plan.

What to Measure?When to Measure?

How to Measure?

Note: Measurement is key element in projectplanning. Lets discuss the standardmeasures used at Infosys.Software Project Mangement by Ayaz

Ahmed Shariff K4848


49/66

7.2.1 Collecting Effort Data

Each employee records in a weekly activityreport(WAR) system the effort spent onvarious tasks.

WAR entry consists of records. Each record

contains list of items and each item hasfollowing fields.

Program Code

Module Code

Activity Code

Activity description

Hours for (5days or 6days.. Depends onSoftware Project Mangement by Ayaz

Ahmed Shariff K4949

i ki


50/66

7.2.2 Logging & trackingDefectsAt Infosys, defect detection and removal ispracticed as follows:

The defect is found and recorded by asubmitter. The defect then in state

submitted.

Next, PM assigns the job of fixing defect tosomeone. That person debugs and fixes the

defect and then enters fixed state.A fixed defect is still not closed unless thesubmitter verifies it.

Life cycle of Defect is shown in figure below.Software Project Mangement by AyazAhmed Shariff KSubmitt

edFixed Closed

5050

2 3 f


51/66

7.2.3 Defect Types

Logic: Algorithmic errors, wrong conditions,test cases, design docs errors

Standards: Problems with coding standardslike aligning, misspelling

Redundant code: same piece of code usedagain

UI: Improper menu navigation

Performance: Poor processing speed, systemcrashes, memory issues

Reusability: Inability to reuse the code

Document defects: Defects in project plans,Software Project Mangement by Ayaz

Ahmed Shariff K5151

7 2 4 D f S i


52/66

7.2.4 Defect Severity

Critical: Defect may be very critical in termsof affecting schedule or it may be ashowstopper that it may stop user fromusing system further.

Major: Same type of defect occurs manytimes in a program

Minor: The defect isolated but causes

inconvenience.Cosmetic: A defect may that does not affectthe performance of s/w product (ex:grammatical errors in a message)

Software Project Mangement by Ayaz

Ahmed Shariff K5252

7 3 P j t T ki


53/66

7.3. Project Tracking

The main goal of tracking is for PM to get thevisibility into the project execution todetermine whether any action needs to betaken or not.

Tracking plan followed at Infosys is asfollows:

1. Activities tracking

2. Defect tracking

3. Issues tracking

//Study about tracking in detail fromChapter 11


Ahmed Shariff K5353


54/66


Ahmed Shariff K

The real problem is what to do with

problem solvers after the problem is solved-Gay Talese

5454


55/66

CH_8 : THE PROJECTMANAGEMENT PLAN

AYAZ AHMED SHARIFF K

Asst. Professor (senior grade)BITIC RAK UAE


Ahmed Shariff K

55

55

8 1 I t d ti


56/66

8.1 Introduction

The project management plan (PMP)document is the culmination of allplanning activities undertaken by projectmanagers.

Outputs of various planning activitiesappear in this document, which becomesthe baseline document guiding the overall

execution of the project.It should not be confused with thedetailed project schedule, whichrepresents only the schedule and

assignment activities.Software Project Mangement by Ayaz

Ahmed Shariff K5656

8 1 T M t


57/66

8.1 Team Management

Software development is a team effort. Highquality and productivity result when theteam members contribute effectively andremain motivated, functions efficiently.

Team management includes

Engineering issues

Project management issues

People issues as well


Ahmed Shariff K5757

8 1 1 T St t


58/66

8.1.1 Team Structure

At Infosys, hierarchical team structure isemployed.

Typical team consists of Developers(DVs), theconfiguration controller(CC), DBA, PM,

Business manager or Account manager,testers.

Some projects will have module leaders,defect prevention team from existingmembers, S/w Quality advisor(SQA).

Following are the factors that a PM takes intoaccount in determining the team structure

and personnel growth.Software Project Mangement by Ayaz

Ahmed Shariff K5858

8 1 2 C i ti


59/66

8.1.2 Communication

A team that will work together for a fewmonths toward a common goal must jell welland must have good intrateamcommunication.

Team communication divided into 2categories

Project related communication

Destressing communication

Following are the methods to enhance team

communication.Software Project Mangement by Ayaz

Ahmed Shariff K5959


60/66

8 1 3 T D l t


61/66

8.1.3 Team Development

Project teams often include many juniorpeople. It is the responsibility of the PM toenhance personnel development of thesemembers.

As the skills and abilities of the teammembers improvement they become moreproductive later in the project.

Following methods make team members tohandlle tasks in better way.

Job rotation

Mentoring of junior membersSoftware Project Mangement by AyazAhmed Shariff K

6161

8 2 Structure of Project


62/66

8.2 Structure of ProjectManagement PlanPMP Plan template provided at Infosys has 4major sections:

1. Project Summary

2. Project Planning3. Project Tracking

4. Project team


Ahmed Shariff K6262

8 2 Structure of PMP plan


63/66

8.2 Structure of PMP plan(contd..)Project summary: Gives high-level overviewof the project(start date, project leader,contacts..)

Project Planning: Outputs of executing the

various project planning procedures(RCM, RA,tailoring)

Project Tracking: defines measurements to betaken and systems to record data.

Project team: Team structure, roles &responsibilities.


Ahmed Shariff K6363

8 3 ACIC Project Plan


64/66

8.3 ACIC Project Plan

// Refer book//Assignment


Ahmed Shariff K6464

//Relax


65/66

//Relax

Project Manageris a Person who thinksnine Women can deliver a babyin One month

Developeris a Person who thinks it will take

18 months to deliver a Baby.

Onsite Coordinatoris one who thinkssingle Woman can deliver ninebabies in one month

Clientis the one who doesn`t know why hewants a baby

Marketing Manageris a person who thinks

he can deliver a baby evenSoftware Project Mangement by Ayaz

Ahmed Shariff K6565


66/66

Mail your queries to:[email protected]

S ft P j t M t b A

Thank You

Documents

SPM - PART2 (4 Chapters)