Requirements Engineering

PROJECT MANAGEMENT Part II

Estimating costs: early calculations

Range of cost estimates after conceptualization phase,based on actual cost of $1

Integration/Test

Design

Implementation

Requirementsanalysis

$1

25c

$4

$1

$1

$1

$1

Conceptual-izationphase

Range of cost estimates after requirements analysis phase

Range of Errors in Estimating Eventual Cost

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Software Cost Estimation

Costs Hardware and software Travel and Training Work effort Overhead loading factor

Other factors Market opportunity

Nose in the door Cost estimate uncertainty Contractual terms e.g. retained rights Volatility Financial Health

Productivity effect Size

LOSC/Month Executable only All loc Level of the language

Function Function point count

Language independent Based on

External input and outputs User interactions External interfaces Files used by the system

Un-adjusted Function point count Sum of like elements times complexity count

Adjusted by other factors Degree of reuse Degree of distribution Productivity Etc ……..

Software Cost Estimation

Costs - productivity

Object Counts When 4gl and higher level language used Count objects (not to be confused with object classes)

Object points Screens produced - 1-3 Number of reports 2/5/8 Number of 3GL modules to be developed to support 4GL 10

points

Function point + Code estimation Code size = AVC x FPC

4GL 2-40 loc/fp Asm 200-300 loc/fp Java 53 loc/fp

Cost estimation techniques

Techniques Expert Judgment

Experience based Algorithmic

Model developed

Expert Judgment

Cost estimation

Cost estimation Techniques continued

Estimation by analogy Parkinson’s law (work expands to fill the time

available) Time avail x people available (12 mo’s X 5 people

= 60 person months) Not good can get in trouble big time

Pricing to win ditto

Typical Cost Estimation Roadmap

1A. Use comparisons with past jobs to estimate cost & duration directly or to estimate lines of code.

and / or

1B. Use function point method to estimate lines of code

1B.1 Compute un-adjusted function points.

1B.2 Apply adjustment process.

2. Use lines of code estimates to compute labor and duration using COCOMO formulas.

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Steps in FP method

Identify functions in the system Compute each functions contribution Apply difficulty factors to each function Compute the general characteristic

contributions (weights) Calculate the adjusted function point total

Step 2 Function Point Computation for a Single Function (IFPUG)

Function

External Inputs (EI)

External Inquiries (EIN)

External Outputs (EO)

file

External Logical Files (ELF)

filefile

Internal Logical Files (ILF)*

* Internal logical grouping of user data into files

Logicalgroup ofuser data

Logicalgroup ofuser data

Logicalgroup ofuser data

Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process)

Ext. inputs EI … 3 or… 4 or ... 6 = ___

Ext. outputs EO … 4 or … 5 or ... 7 = ___

PARAMETER simple complex

countTotal

Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process)

Ext. inputs EI … 3 or… 4 or ... 6 = ___

Ext. outputs EO … 4 or … 5 or ... 7 = ___

Ext. inquiries EIN … 3 or … 4 or ... 6 = ___

Ext. logical files ELF ... 5 or …7 or ... 10 = ___

Int. logical files ILF ... 7 or …10 or ... 15 = ___

PARAMETER simple complex

countTotal

Unadjusted Function Point Computation for First Encounter Functions:“Set up Player Character”

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Unadjusted Function Point Computation for Second Encounter Functions: “Encounter Foreign Character”

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

General Characteristics for FP Adjustment 1-7

1. Requires backup/recovery? 0-2

2. Data communications required? 0-1

3. Distributed processing functions? 0

4. Performance critical? 3-4

5. Run on existing heavily utilized environmt.? 0-1

6. Requires on-line data entry? 5

7. Multiple screens for input? .... Continued 4-5

0

incidental average essential

1 2 3 4 5Casestudy

none moderate significant

8. Master fields updated on-line? 3-4

9. Inputs, outputs, inquiries of files complex? 1-2

10. Internal processing complex? 1-3

11. Code designed for re-use? 2-4

12. Conversion and installation included? 0-2

13. Multiple installation in different orgs.? 1-3

14. Must facilitate change & ease-of-use by user? 4-5

0 1 2 3 4 5

General Characteristics for FP Adjustment 8-14 incidental average essential

Casestudy

none moderate significant

Computation of Adjusted Function Points (IFPUG)

(Adjusted) Function points =

[ Unadjusted function points(41) ]

[ 0.65 + 0.01 ( total general characteristics ) ]

41 x [0.65 + 0.01 x (24 to 41))] = 36 to 43

Loc = (36 to 43) x 53 =1.9 to 2.3 loc (java)

Estimating effort and duration from lines of code

Basic COCOMO Formulae (Boehm)

Effort in Person-months = aKLOC b

Duration = cEffort d

Software Project a b c d

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Due to Boehm [Bo]

Organic – stand aloneEmbedded – hardware software systemsSemi detached - mix

Computing COCOMO Case Study ModelsVERY EARLY ESTIMATES

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Later revisions to estimate

Need to account for Product reliability and complexity (RCPX) Reuse required (RUSE) Platform difficulty (PDIF) Personnel Capability (PERS) Personnel Experience (PREX) Schedule (SCED) Facilities (FCIL)

Effort =a x Kb x M M=(RCPX)(RUSE)(PDIF)(PERS)(PREX)(SCHED)(FCIL)

Estimate Cost and Duration Very Early in Project

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1. Use the function point method to estimate lines

of code

2. Use Boehm’s formulas to estimate labor required

3. Use the labor estimate and Boehm’s formula to

estimate duration

The Team Software Process

TSP Launch Issues to Settle(Humphrey)

Graphics reproduced with permission from Corel.

Process to be used Quality goals Manner of tracking quality goals How team will make decisions What to do if quality goals not attained

fallback positions What to do if plan not approved

fallback positions Define team roles Assign team roles

To Be Produced at Launches (Humphrey)1. Written team goals

2. Defined team roles3. Process development plan4. Quality plan5. Project’s support plan

computers, software, personnel etc.

6. Overall development plan and schedule 7. Detailed plans for each engineer8. Project risk assessment 9. Project status report

TSPi Cycle Structure (Humphrey)

1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

1. strategy2. plan3. requirements4. design5. implementation6. test7. postmortem

MilestonesDelivery

1. strat.

Iteration 1

Iteration 2

1. strategy….

Cycle 1 launch

Week1

Cycle 2 launchCycle 3 launch

1 1 1 1 1

Iteration 3

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

The Software Project Management Plan

IEEE 1058.1-1987 SPMP Table of Contents

1. Introduction 1.1 Project overview 1.2 Project deliverables 1.3 Evolution of the SPMP 1.4 Reference materials 1.5 Definitions and acronyms 2. Project organization 2.1 Process model 2.2 Organizational structure 2.3 Organizational boundaries and interfaces 2.4 Project responsibilities 3. Managerial process 3.1 Managerial objectives & priorities. . . .

IEEE 1058.1-1987 SPMP Table of Contents

1. Introduction 1.1 Project overview 1.2 Project deliverables 1.3 Evolution of the SPMP 1.4 Reference materials 1.5 Definitions and acronyms 2. Project organization 2.1 Process model 2.2 Organizational structure 2.3 Organizational boundaries and interfaces 2.4 Project responsibilities 3. Managerial process 3.1 Managerial objectives & priorities

3.2 Assumptions, dependencies & constraints 3.3 Risk management 3.4 Monitoring & controlling mechanisms 3.5 Staffing plan4. Technical process 4.1 Methods, tools & techniques 4.2 Software documentation 4.3 Project support functions 5. Work packages, schedule & budget 5.1 Work packages 5.2 Dependencies 5.3 Resource requirements 5.4 Budget & resource allocation 5.5 Schedule

Quality in project management

Defects detected per ... ... 100 requirements, or ... design diagram, or ... KLOCThis project / norm

Phase in which defects detected

Detailed require-ments

Design Implemen- tation

Phase containing defects

Detailed requirements

2 / 5 0.5 / 1.5 0.1 / 0.3

Design   3 / 1 1 / 3

Implementa-tion

    2 / 2

Table 2.5 Defects by Phase

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Five Process Metric Examples

1.Number of defects per KLOC detected within x weeks of delivery

2.Variance in schedule on each phase actual duration - projected

duration projected duration3.Variance in cost actual cost - projected cost

projected cost4.Total design time / total programming time

should be at least 50% (Humphry)5.Defect injection and detection rates per phase

e.g. “1 defect per class in detailed design phase”

Compare each of the following with company norms averaged over similar processes.

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

IEEE 739-1989 Software Quality Assurance Plans Table of Contents Part 2 of 2

7. Test-- can reference Software Test Documentation 8. Problem reporting & corrective action9. Tools, techniques and methodologies-- can reference SPMP 10. Code control-- reference SCMP 11. Media control12. Supplier control13. Records collection, maintenance & retention14. Training15. Risk Management-- can reference SPMP

Gather Process Metrics

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1. Identify & define metrics team will use by phase; include ... time spent on 1. research, 2. execution, 3. review

… size (e.g. lines of code) … # defects detected per unit (e.g., lines of code)

include source

… quality self-assessment of each on scale of 1-10maintain bell-shaped distribution

2. Document these in the SQAP 3. Accumulate historical data by phase4. Decide where the metric data will be placed

as the project progresses SQAP? SPMP? Appendix?

5. Designate engineers to manage collection by phase QA leader or phase leaders (e.g., design leader)

6. Schedule reviews of data for lessons learned Specify when and how to feed back improvement

Requirements Document: 200 detailed requirements

Meeting Research ExecutionPersonal Review

Inspection

Hours spent 0.5 x 4 4 5 3 6

% of total time 10% 20% 25% 15% 30%

% of total time: norm for the organization

15% 15% 30% 15% 25%

Self-assessed quality 1-10 2 8 5 4 6

Defects per 100 N/A N/A N/A 5 6

Defects per 100: organization norm

N/A N/A N/A 3 4

Hours spent per detailed requirement

0.01 0.02 0.025 0.015 0.03

Hours spent per detailed requirement: organization

norm0.02 0.02 0.04 0.01 0.03

Process improvementImprove strawman brought to meeting

  Spend 10% more time executing

   

Summary Productivity: 200/22 = 9.9 detailed requirements per hourProbable remaining defect rate: 6/4[organizational norm of 0.8 per hundred] = 1.2 per 100

Table 2.6 Project Metric Collection for phases

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Process improvement and the Capability Maturity Model

Motor control applicationsProcess

Waterfall Spiral, 2-4 iterations

Spiral, 5-10 iterations

Company average -- Defects per thousand source lines of code at delivery time injected at ...

     

... requirements time 4.2 3.2 2.4

... architecture time 3.1 2.5 3.7

... detailed design time 1.1 1.1 2.2

... implementation time 1.0 2.1 3.5

TOTAL 9.4 8.9 11.8

Table 2.7 Example of Process Comparison

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Feed Back Process/Project Improvement

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1. Decompose the process or sub-process being measured into Preparation, Execution and Review include Research if learning about the procedure

2. Note time taken, assess degree of quality for each part on a 1-10 scale, count defects try to enforce a curve

3. Compute quality / (percent time taken) 4. Compare team’s performance against existing

data, if available5. Use data to improve next sub-process

note poorest values first e.g., low quality/(percent time)

  For each part ...

Preparation Execution Review

% time 45 30 25

Quality (0 to 10)*

If low, investigate

62

investigate6

Quality/(% time)If low,

investigate

0.13 investigate

0.07 investigate

0.24

Typical?No

Joe lost specsYes Yes

Action 

Schedule 20% more time for execution, taken equally from other phases

 

Table 2.8 Measuring Team Phase Performance

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Miscellaneous tools and techniques for project management Model

Remote Team Options Same office area

+ ideal for group communication- labor rates sub-optimal

Same city, different officescommunication fair

Same country, different cities- communication difficult+ common culture

Multi-country- communication most difficult- culture issues problematical+ labor rates optimal

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

Non-Extreme vs Extreme Programming

Limited customer contact Central up-front design

Build for the future too Complex implementation

Tasks assigned Developers in isolation

Infrequent integration Limited communication

Customer on team Open evolving design

Evolve; just in time Radical simplicity

Tasks self-chosen Pair programming

Continuous integration Continual communication

Adapted from Andserson, A., et al, "At Chrysler, Objects Pay", Distributed Computing, October 1998

Triage in Project ManagementAmong top items in importance?

if so, place it in do at once categoryotherwise Could we ignore without

substantially affecting project? if so, place it in last to do category

otherwise (do not spend decision time on this)place in middle category

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Summary of the project management process

Summary

Project management: “silver bullet”? “People” aspects co-equal technical Specify SPMP Define and retire risks Estimate costs with several methods

expect to revisit and refine use ranges at this stage

Schedule project with appropriate detail Maintain a balance among cost, schedule, quality

and functionality

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.