U08784 Software Project Management

1. U08784 Software Project Management lecturer: Timothy Au email: timothykfau@yahoo.com url: www.geocities.com/timothykfau/2008/u08784

2. What have we learnt last week • Project Scheduling & Tracking • Project Scheduling & Tracking: WBS, CPM, Gantt Charts4a • Project Planning & Project Planning Techniques: Network Diagram4b • Assignment Briefing • Week 1 Exercise • Exercise on Network Diagrams (Page 105) will be covered on this week lecture and the fourth lecture

3. Lecture 4 • In this lecture, you will learn : • Project Estimation: An Introduction to COCOMO 5a • An Introduction to COCOMO (Word document)5b • An Introduction to Estimating 5c • The COnstructive COst MOdel (COCOMO) 5d • In the second-half lecture, • Week 2 Exercise Ex. COCOMO (Page 153-158) • Measure Software Quality (Page 163-175) 6a • Estimating Function Point Analysis (Page 186-192) 6e

4. Lecture Outcomes • You should be able to understand the following upon this lecture: • Sizing, Effort Estimation and Cost justification • Review: Project Planning Steps Project Management Phases • Project Milestones • Have your ballpark effort estimation • Define your Cost Estimation Report Contents • Draft detailed project plan (individual) • Identify your project risks (risk analysis report) • Draft Quality Plan

5. Software Measurement • Measurement in the physical world can be classified into two ways: • Direct measures (e.g. the length) • Indirect measures (e.g. the quality, the functionality) • In software engineering, • Direct measures mean cost and effort including line of code (LOC), memory size and defects reported. • Indirect measures mean functionality, quality, complexity, efficiency, reliability, maintainability, …

6. Software Measurement • Size oriented metrics • derived by normalizing quality and/or productivity measures by considering the size of the software. • The usual practice is to express the work content using SLOC for effort estimation • lines of code (LOC) or thousand lines of code (KLOC) are chosen as a value • Function-oriented metrics • Indirect measures mean functionality, quality, complexity, efficiency, reliability, maintainability, …

7. Software Project Sizing • Commonly, two metrics are used in project sizing estimation: • lines of code (LOC) and • function point (FP)

8. Line of Code • Line of Code (LOC): • Software size is estimated by counting the number of source code in the software programs to be developed. • Sizing should consider the complexity of the overall project and also the effort in design and testing – not just coding. • More commonly, we refer to KLOC (Kilo Line of Code) instead of LOC.

9. Function Point • Function Point (FP): • The concept of function point is to quantify the functionality to be delivered of the software to be developed; • by counting the number of inputs, outputs, enquiries, internal interfaces and external interfaces.

10. Albrecht function point analysis • Albrecht FP • This is a top-down method that was devised by Allan Albrecht when he worked for IBM. • External input types (EI) • External output types (EO) • Logical Internal file types (ILF) • External interface file types (EIF) • External inquiry types (EQ)

11. Computing function points • Calculation of Adjusted function point total: • Adjusted FP = count total x (0.65 + 0.01 x Influence Factor) • Therefore, the formula can be expressed as: • FP = UFC * TCF UFC TCF

12. Albrecht function point analysis • Complexity • The counts of each external user type in each complexity is multiplied by specified weights (low, average, high) to get the individual FP scores which are summed to obtain an overall FP count which indicates the whole software project size.

13. Albrecht function point analysis • Complexity • One problem with the Albrecht FP is that the question of whether the external user type of low, average, high complexity is rather subjective. • The International Function Point User Group (IFPUG) suggests rules on how this to be judged for estimating software project size.

14. Albrecht function point analysis

15. Albrecht function point analysis • Complexity • The general functionality of the systems will be affected by the following 14 complexity characteristics are identified to rate the general functionality of the system (1) Data Communication (8) On-line Update (2) Distributed Processing (9) Complex Processing (3) Performance (10) Reusability (4) Heavily Used Configuration (11) Installation Ease (5) Transaction Rate (12) Operational Ease (6) On-line Data Entry (13) Multiple Sites (7) End-User Efficiency (14) Ease of Change

16. Albrecht function point analysis • Complexity • The weight of the 14 complexity adjustment factors are: • 0 no influence • 1 incidental • 2 moderate • 3 average • 4 significant • 5 essential

17. Function Points Mark II • For each transaction the Unjustified Function points (UFP’s) are calculated from the following factors: • Input data element types (I) • Entity types referenced (E) • Output data element types (O) • The Function Point Mk II is • FP = 0.58I + 1.66E + 0.26O

18. COCOMO • The COnstructive COst MOdel (COCOMO) • It is an algorithmic Software Cost Estimation Model developed by Barry Boehm. • It is an line of code based cost estimation model. • It is a static, single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code.

19. COCOMO Projects are categorized into three types: • Organic projects • are relatively small, simple software projects in which small teams with good application experience work to a set of less than rigid requirements. • Semi-detached projects • are intermediate (in size and complexity) software projects in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements. • Embedded projects • are software projects that must be developed within a set of tight hardware, software, and operational constraints

20. COCOMO • The Basic COCOMO model equations take the form • E=ab(KLOC) Effort (in Person-Month) • D=cb (E)db Development Time in month (TDEV) • P=E/D Productivity bb • Organic: E=2.4(KLOC)1.05 • Semi-detached: E=3.0(KLOC)1.12 • Embedded: E=3.6(KLOC)1.20 Effort

21. COCOMO • The Basic COCOMO Model equations take the form • E=ab(KLOC) Effort (in Person-Month) • D=cb (E)db Development Time in month (TDEV) • P=E/D Productivity bb • Organic: T=2.5(E) 0.38 • Semi-detached: E=2.5(E) 0.35 • Embedded: E=2.5(E) 0.32 Time

22. COCOMO • The Intermediate COCOMO Model refines • the estimate with a complexity factor by computing the project effort as a function of program size; • by the adjustment of 4 cost drivers that includes a subjective assessment of a set of 15 attributes. • The product of all effort multipliers results is an Effort Adjustment Factor (EAF) i.e.E=ab(KLOC) x EAF Effort (in Person-Month)

23. COCOMO • The Detailed COCOMO Model includes • all characteristics of the intermediate version with an assessment of the cost driver's impact on each step of the software engineering process.[By Shamsul Arif Nowshehra]

24. COCOMO II • The COCOMO II Model • is a more comprehensive cost model to compute the effort, cost and time from the program size. • It is evolved from COCOMO (COCOMO 81). • It is also a phase-based model but the project size may be measured in LOC and FP or even object points such as srceens, reports. • The concept of code reusability is included.

25. Staffing • Staffing Plan and Resources Planning • Staffing changes over the project timeline; • What kind of staff is required at what time at what price? • Adding staff at the right time; • Team size, team building, motivation, …