Management of Software Engineering

1. Management of Software Engineering Chapter 8: Fundamentals of Software Engineering C. Ghezzi, M. Jazayeri, D. Mandrioli

2. Outline • Why is management needed? • What are the main tasks of managers? • What is special in the case of software? • How can productivity be measured? • Which tools may be used for planning and monitoring? • How can teams be organized? • How can organizations' capabilities be defined and measured?

3. Management "The creation and maintenance of an internal environment in an enterprise where individuals, working together in groups, can perform efficiently and effectively toward the attainment of group goals" (Koontz et al, 1980) • Software engineering projects involve many software engineers • Management is needed to coordinate the activities and resources involved in projects

4. Making decision is difficult! • Invest on modern tools? • Invest on formal techniques? • Short time-to-market? • Adding new features? • Develop or purchase? • Re-engineering or development? State-of-practice in project management is to make judgments, check them against expert opinions, try to achieve consensus, and if possible, calibrate it against the data on previous similar projects within the same organization

5. Management tasks • Planning: What resources are required to achieve the objectives • Organizing: defining the responsibilities and authorities for group activities to achieve the goals • Staffing: hiring personnel for the positions that are identified by the organizational structure • Directing: guiding the groups to understand the goals of the enterprise • Controlling: measuring and correcting activities to make sure the goals are achieved. … and dealing with deviations from the plan “Plan the work and work the plan”

6. Management challenges • Balance conflicting goals • Deliver a high-quality product with limited resources • Organize an activity that is fundamentally intellectual • this complicates the traditional techniques for productivity measurement, project planning, cost and schedule estimation

7. Software productivity • How to define/measure it? • TV production VS. Software production • In terms of lines of code produced • few tens per day • Student project VS. professional program • .. but what do engineers do? • up to half of their time spent in meetings, administrative matters, communication with team members

8. Function points • A productivity measure, empirically justified • Motivation: define and measure the amount of value (or functionality) produced per time unit • Principle: determine complexity of an application as its function point

9. Function point definition • A weighted sum of 5 characteristic factors

10. A byproduct • Function points used to measure the relative power of different languages • compute number of source lines required to code a function point • numbers range from 320 (assembler languages), 128 (C), 91 (Pascal), 71 (Ada83), 53 (C++, Java), 6 (“spreadsheet languages”)

11. Size of code • Size of code produced per unit of time as productivity measure • must define exactly what "size of code" means • Delivered Source Instructions (DSI) • Non-commented source statements (NCSS) • .. but how good is this metric?

12. Factors affecting productivity • Professionals' capabilities • Product complexity • Schedule constraints • Previous experience (Overly aggressive scheduling may have negative effect)

13. People and productivity • Because software engineering is an intellectual activity, the most important ingredient for producing high-quality software efficiently is people • Large variability in productivity between engineers

14. Cost estimation • We need predictive methods to estimate the complexity of software before it has been developed, then: • Predict size of the software • Use it as input for deriving the required effort

15. Generic formula for effort PM = c KLOCk • 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"

16. Typical cost driver categories • Product • e.g., reliability requirements or inherent complexity • Computer • e.g., are there execution time or storage constraints? • Personnel • e.g., are the personnel experienced in the application area or the programming language being used? • Project • e.g., are sophisticated software tools being used?

17. Cost estimation procedure • Estimatesoftware size, and use it in the model’s formula to get initial effort estimate (Person Month) • Reviseeffort estimate by using the cost driver or other scaling factors given by the model • Apply the model’s tools to the estimate effort derived in step 2 above to determine the total effort, activity distribution, etc.

18. COCOMO models Constructive Cost Model proposed by B. Boehm evolved from COCOMO to COCOMO II

19. COCOMO • Size estimate based on delivered source instructions, KDSI • Categorizes the software as different modes: • organic • semidetached • embedded • each has an associated formula for nominal development effort based on estimated code size

20. Examples of software modes • Organic: • In the organic mode, relatively small software teams develop software in a highly familiar, in-house environment. Most people connected with the project have extensive experience in working with related systems within the organization, and have a thorough understanding of how the system under development will contribute to the organizations objectives. Very few organic-mode projects have developed products with more than 50 thousand delivered source instructions (KDSI) • Scientific models, business models, Familiar OS or compilers • Semidetached: • The semidetached mode of software development represents an intermediate stage between the organic and embedded modes. "Intermediate" may mean either of two things: An intermediate level of project characteristic. A mixture of the organic and embedded mode characteristics. The size range of a semidetached mode product generally extends up to 300 KDSI • Most transaction processing systems, New OS, DBMS, ambitious inventory production control, simple command control

21. ... Examples of software modes • Embedded • The major distinguishing factor of an embedded-mode software project is a need to operate within tight constraints. The product must operate within (is embedded in) a strongly coupled complex of hardware, software, regulations, and operational procedures. • Large complex transaction processing systems, ambitious very large OS, avionics, ambitious Command and Control systems.

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

23. COCOMO nominal effort and schedule equations

24. Ratings Very low Low Nominal High Very Extra Cost Drivers High High Product attributes .75 .88 1.00 1.15 1.40 Required software reliability .94 1.00 1.08 1.16 Data base size .70 .85 1.00 1.15 1.30 1.65 Product complexity Comput er attributes 1.00 1.11 1.30 1.66 Execution time constraints 1.00 1.06 1.21 1.56 Main storage constraints .87 1.00 1.15 1.30 Virtual machine volatility* .87 1.00 1.07 1.15 Computer turnaround time Personnel attributes 1.46 1.19 1.00 .86 .71 Anal yst capability 1.29 1.13 1.00 .91 .82 Applications experience 1.42 1.17 1.00 .86 .70 Programmer capability 1.21 1.10 1.00 .90 Virtual machine experience* 1.14 1.07 1.00 .95 Programming language experience Project attributes 1.24 1.10 1.00 .91 .82 Use of modern programming practices 1.24 1.10 1.00 .91 .83 Use of software tools 1.23 1.08 1.00 1.04 1.10 Required development schedule COCOMO scaling factors The nominal effort estimation is multiplied by these ratings to produce the estimated effort for a specific project

25. COCOMO Tool http://arthurdejong.org/cocomo/