Lecture 2 Project Management Cost Estimation Project Planning

Lecture 2 Project Management Cost Estimation Project Planning These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 1

Software Project These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 2

The 4 P’s People — the most important element of a successful project Product — the software to be built Process — the set of framework activities and software engineering tasks to get the job done Project — all work required to make the product a reality These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 3

Software Projects Factors that influence the end result. . . • size • delivery deadline • budgets and costs • application domain • technology to be implemented • system constraints • user requirements • available resources These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 4

Project Management Concerns These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 5

Why Projects Fail? • an unrealistic deadline is established • changing customer requirements • an honest underestimate of effort • predictable and/or unpredictable risks • technical difficulties • miscommunication among project staff • failure in project management These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 6

Defining the Product establish scope—a narrative that bounds the problem decomposition—establishes functional partitioning These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 7

Example The CAD software will accept two- and threedimensional geometric data from an engineer. The engineer will interact and control the CAD system through a user interface that will exhibit characteristics of good human/machine interface design. All geometric data and other supporting information will be maintained in a CAD database. Design analysis modules will be developed to produce the required output, which will be displayed on a variety of graphics devices. The software will be designed to control and interact with peripheral devices that include a mouse, digitizer, laser printer, and plotter. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 8

. Co an nstr d r uc ele tio as n e Cu ev stom alu ati er on rin g ee en gin sis ris an k aly COMMON PROCESS FRAMEWORK ACTIVITIES cu s co tom mm er un ica tio n pla nn ing Melding Product and Process Software Engineering Tasks Product Functions Text input Editing and formatting Automatic copy edit Page layout capability Automatic indexing and TOC File management Document production These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 9

To Get to the Essence of a Project “W 5 HH Principle” Why is the system being developed? What will be done? By when? Who is responsible for a function? Where are they organizationally located? How will the job be done technically and managerially? How much of each resource (e. g. , people, software, tools, database) will be needed? Barry Boehm These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 10

Project Metrics These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 12

Measurement & Metrics. . . collecting metrics is too hard. . . it's too time-consuming. . . it's too political. . . it won't prove anything. . . Anything that you need to quantify can be measured in some way that is superior to not measuring it at all. . Tom Gilb These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 13

Why do we Measure? To characterize To evaluate To predict To improve These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 14

A Good Manager Measures process metrics project metrics measurement product metrics product What do we use as a basis? • size? • function? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 15

Process Metrics majority focus on quality achieved as a consequence of a repeatable or managed process statistical SQA data error categorization & analysis defect removal efficiency propagation from phase to phase reuse data These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 16

Project Metrics Effort/time per SE task Errors uncovered per review hour Scheduled vs. actual milestone dates Changes (number) and their characteristics Distribution of effort on SE tasks These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 17

Product Metrics focus on the quality of deliverables measures of analysis model complexity of the design internal algorithmic complexity architectural complexity data flow complexity code measures of process effectiveness e. g. , defect removal efficiency These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 18

Metrics Guidelines Use common sense and organizational sensitivity when interpreting metrics data. Establish a baseline by collecting historical data Provide regular feedback to the individuals and teams who have worked to collect measures and metrics. Work with practitioners and teams to set clear goals and metrics that will be used to achieve them. Never use metrics to threaten individuals or teams. Don’t use metrics to appraise individuals. Metrics data that indicate a problem area should not be considered “negative. ” These data are merely an indicator for process improvement. Don’t obsess on a single metric to the exclusion of other important metrics. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 19

Normalization for Metrics Normalized data are used to evaluate the process and the product (but never individual people) size-oriented normalization—the line of code approach function-oriented normalization—the function point approach These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 20

Typical Size-Oriented Metrics errors per KLOC (thousand lines of code) defects per KLOC $ per LOC page of documentation per KLOC errors / person-month LOC person-month $ / page of documentation These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 21

Typical Function-Oriented Metrics errors per FP (thousand lines of code) defects per FP $ per FP pages of documentation per FP FP person-month These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 22

Why Opt for FP Measures? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 23

Computing Function Points Analyze information domain of the application and develop counts Establish count for input domain and system interfaces Weight each count by assessing complexity Assign level of complexity or weight to each count Assess influence of global factors that affect the application Grade significance of external factors, Fi Such as reuse, concurrency, OS, … Compute function points = (count x weight) x C where: complexity multiplier: C = (0. 65 + 0. 01 x N) degree of influence: N = Fi These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 24

Analyzing the Information Domain These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 25

Taking Complexity Into Account Factors are rated on a scale of 0 (not important) to 5 (very important): Backup and recovery Data communications Distributed processing Performance critical Existing operating environment Online data entry Input transaction over multiple screens Master files updated online Information domain values complex Internal processing complex Code designed for reuse Conversion/installation in design Multiple installations Application designed for change These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 26

Marrying LOC and FP Programming Language LOC/FP (average) Assembly language 320 C 128 COBOL 106 FORTRAN 106 Pascal 90 C++ 64 Ada 95 53 Visual Basic 32 Smalltalk 22 Powerbuilder 16 SQL 12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 27

Measuring Quality Correctness — the degree to which a program operates according to specification e. g. defects per KLOC Maintainability—the degree to which a program is amenable to change e. g Mean-time-to-change, spoilage Integrity—the degree to which a program is impervious to outside attack e. g. integrity = [(1 -threat)x(1 -security)] Usability—the degree to which a program is easy to use e. g. skill required, time required, productivity increase, user assessment These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 28

Defect Removal Efficiency DRE = (errors) / (errors + defects) where errors = problems found before release defects = problems found after release These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 29

Metrics Development Software engineering process Software project Software product Measures Data collection Metrics computation Metrics evaluation Indicators These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 30

Software Project Planning These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 32

The Steps Scoping—understand the problem and the work that must be done Estimation—how much effort? how much time? Risk—what can go wrong? how can we avoid it? what can we do about it? Schedule—how do we allocate resources along the timeline? what are the milestones? Control strategy—how do we control quality? how do we control change? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 34

Software Sizing “fuzzy logic” sizing Function point sizing Standard component sizing Change sizing S = (Sopt + 4 Sm + 5 pess) / 6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 39

Functional Decomposition Statement of Scope perform a "grammatical parse" functional decomposition These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 40

Creating a Task Matrix Obtained from “process framework” framework activities application functions Effort required to accomplish each framework activity for each application function These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 41

Conventional Methods: LOC/FP Approach compute LOC/FP using estimates of information domain values use historical effort for the project These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 42

Example The CAD software will accept two- and threedimensional geometric data from an engineer. The engineer will interact and control the CAD system through a user interface that will exhibit characteristics of good human/machine interface design. All geometric data and other supporting information will be maintained in a CAD database. Design analysis modules will be developed to produce the required output, which will be displayed on a variety of graphics devices. The software will be designed to control and interact with peripheral devices that include a mouse, digitizer, laser printer, and plotter. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 43

Example: LOC Approach These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 44

Example: FP Approach Information domain value Opt. Likely Pess. Number of Inputs 20 24 30 24 4 97 Number of outputs 12 15 22 16 5 78 Number of inquiries 16 22 28 22 5 88 Number of files 4 4 5 4 10 42 Number of external interfaces 2 2 3 2 7 15 Count total Est. count Weight FP count 320 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 45

Example: FP Approach Backup and recovery 4 Data communications 2 Distributed processing 0 Performance critical 4 Existing operating environment 3 Online data entry 4 Input transaction over multiple screens 5 Master files updated online 3 Information domain values complex 5 Internal processing complex 5 Code designed for reuse 4 Conversion/installation in design 3 Multiple installations 5 Application designed for change 5 Total 52 Complexity adjustment factor (0. 65+0. 01 X 52) 1. 17 Estimated FP 375 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 46

Process-Based Estimation Activity CC Planning Risk Analysis Engineering Construction release CE Total analysis Design Code Test UICF 0. 50 2. 50 0. 40 5. 00 n/a 8. 40 2 DGA 0. 75 4. 00 0. 60 2. 00 n/a 7. 35 3 DGA 0. 50 4. 00 1. 00 3. 00 n/a 8. 50 CGDF 0. 50 3. 00 1. 50 n/a 6. 00 DBM 0. 50 3. 00 0. 75 1. 50 n/a 5. 75 PCF 0. 25 2. 00 0. 50 1. 50 n/a 4. 25 DAM 0. 50 2. 00 n/a 5. 00 Task Functio n Total 0. 25 3. 50 20. 5 4. 50 16. 5 0 % effort 1% 1% 1% 8& 45% 10% 36% 46. 00 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 47

Tool-Based Estimation project characteristics calibration factors LOC/FP data These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 48

Empirical Estimation Models General form: effort = tuning coefficient * size exponent usually derived as person-months of effort required either a constant or a number derived based on complexity of project empirically derived usually LOC but may also be function point These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 49

The Make-Buy Decision simple (0. 30) build difficult (0. 70) minor changes (0. 40) system X reuse $380, 000 $450, 000 $275, 000 $310, 000 simple (0. 20) buy contract major changes (0. 60) complex (0. 80) minor changes (0. 70) major changes (0. 30) without changes (0. 60) $490, 000 $210, 000 $400, 000 $350, 000 $500, 000 with changes (0. 40) These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 51

Computing Expected Cost expected cost = (path probability) x (estimated path cost) i i For example, the expected cost to build is: expected cost build = 0. 30($380 K)+0. 70($450 K) = $429 K similarly, expected cost reuse = $382 K expected cost buy = $267 K expected cost contr = $410 K These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 52

Project Team Senior managers – define business issues Project (technical) managers – plan and manage the project and project team Practitioners – engineer a product or application Customers – specify the requirements for the software End-users – use the product on a day-to-day basis These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 53

Software Teams The following factors must be considered when selecting a software project team structure. . . the difficulty of the problem to be solved the size of the resultant program(s) in lines of code or function points the time that the team will stay together (team lifetime) the degree to which the problem can be modularized the required quality and reliability of the system to be built the rigidity of the delivery date the degree of sociability (communication) required for the project These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 54

Organizational Paradigms closed paradigm—structures a team along a traditional hierarchy of authority (similar to a CC team) random paradigm—structures a team loosely and depends on individual initiative of the team members open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm synchronous paradigm—relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves suggested by Constantine [CON 93] These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 55

Team Management Democratic decentralized (DD) Controlled decentralized (CD) Controlled centralized (CC) difficulty; size; duration modularity These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 56