Management of Software Engineering. Ch. 8 1

Size: px

Start display at page:

Download "Management of Software Engineering. Ch. 8 1"

Meagan Loraine Malone
5 years ago
Views:

1 Management of Software Engineering Ch. 8 1

2 Project control Ch. 8 2

3 Work Breakdown Structure WBS describes a break down of project goal into intermediate goals Each in turn broken down in a hierarchical structure Ch. 8 3

4 Example: a compiler project Compiler project Design Code Integrate and test Write manual Scanner Parser Code generator Ch. 8 4

5 Gantt charts A project control technique Defined by Henry L. Gantt Used for several purposes, including scheduling, budgeting, and resource planning Ch. 8 5

6 Example: a compiler project Ch. 8 6

7 Example: scheduling activities 1/1 4/1 7/1 10/1 Darius training Marta training vacation Leo training vacation Ryan training vacation Silvia training vacation Laura training vacation Ch. 8 7

8 PERT Charts PERT (Program Evaluation and Review Technique) chart network of boxes (or circles) representing activities arrows dependencies among activities activity at the head of an arrow cannot start until the activity at the tail of the arrow is finished Ch. 8 8

9 Example: a compiler project March 7 build scanner Jan 1 Jan 3 March 7 Nov 14 start design build parser integration and testing March 7 build code generator finish Mar 17+ March 7 write manual Ch. 8 9

10 Analysis of PERT charts Critical path for the project (shown in bold) any delay in any activity in the path causes a delay in the entire project activities on the critical path must be monitored more closely than other activities Ch. 8 10

11 Risk management A topic of management theory Identifies project risks, assesses their impact, and monitors and controls them Ch. 8 11

12 Typical SE risks (Boehm 1989) RISK RISK MANAGEMENT TECHNIQUE 1. Personnel shortfalls - Staffing with top talent; job matching; team building; key -personnel agreements; cross - training; pre -scheduling key people 2. Unrealistic schedules and budgets 3. Developing the wrong software functions 4. Developing the wrong user interface - Detailed multisource cost & schedu le estimation; design to cost; incremental development; software reuse; requirements scrubbing - Organization analysis; mission analysis; ops - concept formulation; user surveys; prototyping; early users manuals - Prototyping; scenarios; task analysis; user characterization (functionality, style, workload) Ch. 8 12

13 5. Gold plating - Requirements scrubbing; prototyping; cost benefit analysis; design to cost 6. Continuing stream of requirements 7. Shortfalls in externally furnished components 8. Shortfalls in externally performed tasks 9. Real-time performance shortfalls 10. Straining computer science capabilities - High change threshold; information hiding; incremental development (defer changes to later increments) - Benchmarking; inspections; reference checking; compatibility analysis - Reference checking; pre-award audits; award-fee contracts; competitive design or prototyping; team building - Simulation; benchmarking; modeling; prototyping; instrumentation; tuning - Technical analysis; cost benefit analysis; prototyping; reference checking Ch. 8 13

14 Capability Maturity Model CMM developed by the Software Engineering Institute to help organizations which develop software to improve their software processes organizations which acquire software to assess the quality of their contractors Ch. 8 14

15 Maturity Immature organization processes are improvised during the course of a project to resolve unanticipated crises products often delivered late and their quality is questionable Mature organization organization-wide standard approach to software processes, known and accepted by all engineers focus on continuous improvement both in performance and product quality Ch. 8 15

16 CMM maturity levels Level 5: Optimizing Level 4: Managed Level 3: Defined Level 2: Repeatable Level 1: Initial Ch. 8 16

17 Key process areas Ch. 8 17

18 Software productivity metrics Ch. 8 18

19 Software Measurement Metrics Size-oriented considering the size of the project Function-oriented Ch. 8 19

20 Size-Oriented Metrics Sample size-oriented metrics Project LOC Effort $(000) pp.doc. Errors Defects People Alpha 12, Beta 27, Gamma 20, Normalization value Ch. 8 20

21 Size-Oriented Metrics Normalized metrics Errors per KLOC (000 lines of code) Defects per KLOC $ per LOC Pages of documentation per KLOC Also: Errors/person-month LOC per person-month $/page of documentation Ch. 8 21

22 Size-Oriented Metrics Not universally accepted LOC is programming language dependent Well-designed shorter programs are penalized LOC need to be estimated before design Ch. 8 22

23 Lines of Code Need for a standard (a normalization) For instance we use the count of the ; Once a standard is set they can be computed automatically (Objective metrics) They MUST not be used to evaluate people productivity (easy to alter!!!) When used properly they work!! Ch. 8 23

$done){ count++; if(count > 10){ fixed_count = fixed_count + count; done = 1; } else if(count >5){ fixed_count --;$

24 Example (with our definition) void f() { while (!done){ count++; if(count > 10){ fixed_count = fixed_count + count; done = 1; } else if(count >5){ fixed_count --; } else { fixed_count = count * 4; } } } // while LOC = 5! Ch. 8 24

25 Size of code Size of code produced per unit of time as productivity measure must define exactly what "size of code" means delivered source line of code (SLOC) delivered source instructions (DSI) noncommented source statements (NCSS).. but how good is this metric? Ch. 8 25

26 Source lines of Code (SLOC) Only Source lines that are DELIVERED as part of the product are included -- test drivers and other support software is excluded SOURCE lines are created by the project staff -- code created by applications generators is excluded One SLOC is one logical line of code Declarations are counted as SLOC Comments are not counted as SLOC The original COCOMO 81 defined in terms of Delivered Source Instructions, which are very similar to SLOC. For example, an "if-then-else" statement = one SLOC, but might be counted as several DSI. Ch. 8 26

27 Cyclomatic Complexity Ch. 8 27

28 Flow Graph if (a) { X(); } else { Y(); } Predicate Nodes a X Y 6/16/06 from Pressman pg

$done){ count++; if(count > 10){ fixed_count = fixed_count + count; done = 1; } else if(count >5){ fixed_count --; } } else {$

29 Introducing Cyclomatic Complexity void f() { while (!done){ count++; if(count > 10){ fixed_count = fixed_count + count; done = 1; } else if(count >5){ fixed_count --; } } else { fixed_count = count * 4; } } // while Flow Chart Ch. 8 29

Cyclomatic Complexity Flow Graph Notation Edges 1 Nodes 1 2 2,3 3 6 R2 4,5 R3 6 4 7 R1

30 Cyclomatic Complexity Flow Graph Notation Edges 1 Nodes 1 2 2,3 3 6 R2 4,5 R R1 8 R Regions Flow Chart Flow Graph 6/16/06 from Pressman pg

31 Cyclomatic Complexity (Def) V(G) = #Regions in the Graph V(G) = #Independent Paths in the Graph V(G) = E - N + 2 where E = number of edges and N = number of nodes V(G) = P + 1 P = number of predicated nodes (i.e., if, case, while, for, do) 6/16/06 based on Pressman pg

32 Computing CC (definitions) 1 1 2,3 2,3 6 R R ,5 R3 Regions R ,5 4 regions!!! 4 independent paths!!! Ch. 8 32

33 Computing CC (formula) Edges 1 Nodes 1 2, , Edges, 9 Nodes = 4!!! = 4!! Ch. 8 33

34 Fan In and Fan Out The Fan In of a module is the amount of information that enters the module The Fan Out of a module is the amount of information that exits a module We assume all the pieces of information with the same size Fan In and Fan Out can be computed for functions, modules, objects, and also non-code components Ch. 8 34

35 Computing Fan In and Fan Out Usually: Parameters passed by values count toward Fan In External variables used before being modifies count toward Fan In External variables modified in the block count toward Fan Out Return values count toward Fan Out Parameters passed by reference depend on their use... Ch. 8 35

Simple(float x, float y){ 2 int a; float z; z = sqrt( x + y +

36 Simple Example of Fan In / Fan #define<stdio.h> #define<math.h> fan-in fan-out int globalinvar = 9; int globaloutvar; Out float Simple(float x, float y){ 2 int a; float z; z = sqrt( x + y + globalinvar); 1 globaloutvar = int(z+2); 1 return z; 1 } Ch. 8 36

37 More involved Example #define<stdio.h> #define<math.h> fan-in fan-out int globalvara = 0; int globalvarb = 3; float global VarC = 7.0; float chechvalue( float x, float y){ 2 int a; float z; z = sqrt( x + y + globalvarc ); 1 globalvara ++; 1 a = globalvarb; 1 globalvarc = z + (float)globalvara; 1 1 return z; 1 } Ch. 8 37

38 Function Oriented Metrics Ch. 8 38

39 Function-Oriented Metrics Use functionality of the application as a normalization value How do you measure functionality? Function points [Albrecht] Based on countable (direct) measures of software s information domain and assessments of software complexity Ch. 8 39

40 Function-Oriented Metrics Normalized metrics based on FP Errors per FP Defects per FP $ per FP Page of documentation per FP FP per person-month Ch. 8 40

41 Function Points Function Points are a measure of how big is the program, independently from the actual physical size of it It is a weighted count of several features of the program Dislikers claim FP make no sense wrt the representational theory of measurement There are firms and institutions taking them very seriously Ch. 8 41

42 Function-Oriented Metrics Weighting Factor Measurement parameter Count simple average complex Number of user inputs x = Number of users outputs x = Number of user inquires x = Number of files x = Number of external interfaces x = Count = Total Unadjusted function points UFP Ch. 8 42

43 Function-Oriented Metrics Computing Complexity adjustement factor: 1. Does the system require reliable backup and recovery? 2. Are data communications required? 3. Are there distributed processing functions? 4. Is performance critical? 5. Will the system run in an existing, heavily utilized environment? 6. Does the system require on-line data entry? Ch. 8 43

44 Function-Oriented Metrics 7. Does the on-line data entry require the input transaction to be built over multiple screens or operations? 8. Are the master files updated on-line? 9. Are the inputs, outputs, files, or inquiries complex? 10. Is the internal processing complex? 11. Is the code designed to be reusable? Ch. 8 44

45 Function-Oriented Metrics 12. Are conversion and installation included in the design? 13. Is the system designed for multiple installations in different organizations? 14. Is the application designed to facilitate change and ease of use by the user? Ch. 8 45

46 Function-Oriented Metrics For each point, set complexity adjustment value F i as: F i = [0-5] where 0: N/A 1: Incidental 2: Moderate 3: Average 4: Significant 5: Essential FP = UFP x ( x ΣF i ) (1 i 14) Ch. 8 46

47 Safe Home Example User Input password zone inquiry sensor inquiry panic button activate/deactivate Inquiry SafeHome User Interaction Function Interfaces test sensor Sensors zone setting Output messages sensor status User activate/deactivate File password, sensors... alarm alert Monitoring & Response Subsystem System configuration data 6/16/06 from Pressman pg D:\my document\safehome.ppt

48 Safe Home Example Weighting Factor measurement parameter count simple average complex number of user inputs 3 x = 9 number of user outputs 2 x = 8 number of user inquiries 2 x = 6 number of files 1 x = 7 number of external interfaces 4 x = 20 count-total 50 Using FP = count total x [ x! F i ] where! F i = 46, we get FP = 50 x [ x 46] FP = 56 6/16/06 based on Pressman pg D:\my document\safehome.ppt

49 Cost estimation We need predictive methods to estimate the complexity of software before it has been developed predict size of the software use it as input for deriving the required effort Ch. 8 49

50 COCOMO models Constructive Cost Model proposed by B. Boehm evolved from COCOMO to COCOMO II Ch. 8 50

51 COCOMO Basic/intermediate/advanced Size estimate based on delivered source instructions, KDSI Categorizes the software as: organic semidetached embedded each has an associated formula for nominal development effort based on estimated code size Ch. 8 51

52 Mode Feature Organic Semidetached Embedded Organizational understanding of product objectives Experience in working with related software systems Need for software conformance with pre -es tablished requirements Need for software conformance with external interface specifications Concurrent development of associated new hardware and operational procedures Need for inn ovative data processing architectures, algorithms Premium on early completion Product size range Thorough Considerable General Extensive Considerable Moderate Basic Considerable Full Basic Considerable Full Some Moderate Extensive Minimal Some Considerable Low <50 KDSI Medium <300 KDSI High All sizes Ch. 8 52

53 Generic formula for effort PM = c KLOC k Legend PM: person month KLOC: K lines of code c, k depend on the model k>1 (non-linear growth) Initial estimate then calibrated using a number of "cost drivers" Ch. 8 53

54 COCOMO nominal effort and schedule equations Development Mode Nominal effort Schedule Organic (PM) NOM =3.2(KDSI) 1.05 TDEV=2.5(PM DEV )) 0.38 Semidetached (PM) NOM =3.0(KDSI) 1.12 TDEV=2.5(PM DEV )) 0.35 Embedded (PM) NOM =2.8(KDSI) 1.20 TDEV=2.5(PM DEV )) 0.32 Ch. 8 54

55 Ratings Cost Drivers Very low Low Nominal High Very High Extra High Product attributes Required software reliability Data base size Product complexity Comput er attributes Execution time constraints Main storage constraints Virtual machine volatility* Computer turnaround time Personnel attributes Anal yst capability Applications experience Programmer capability Virtual machine experience* Programming language experience COCOMO scaling factors Project attributes Use of modern programming practices Use of software tools Required development schedule Ch. 8 55

56 Towards COCOMO II COCOMO's deficiencies strictly geared toward traditional development life cycle models custom software built from precisely stated specifications relies on lines of code Now uses KSLOC COCOMO II is a collection of 3 models Adapts to new software production models Uses object points (evolution of FP) Ch. 8 56

Contents. Today Project Management. What is Project Management? Project Management Activities. Project Resources

Contents. Today Project Management. What is Project Management? Project Management Activities. Project Resources Contents Last Time - Software Development Processes Introduction Software Development Processes Project Management Requirements Engineering Software Construction Group processes Quality Assurance Software