1. SFWR ENG 3KO4 Slide 1 Management of Software Engineering Chapter 8: Fundamentals of Software Engineering C. Ghezzi, M. Jazayeri, D. Mandrioli

2. SFWR ENG 3KO4 Slide 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. SFWR ENG 3KO4 Slide 3 Management  Software engineering projects involve many software engineers  Management is needed to coordinate the activities and resources involved in projects "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)

4. SFWR ENG 3KO4 Slide 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. SFWR ENG 3KO4 Slide 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. SFWR ENG 3KO4 Slide 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. SFWR ENG 3KO4 Slide 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. SFWR ENG 3KO4 Slide 8 Function points  A productivity measure, empirically justified value  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. SFWR ENG 3KO4 Slide 9 Function point definition  A weighted sum of 5 characteristic factors

10. SFWR ENG 3KO4 Slide 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. SFWR ENG 3KO4 Slide 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. SFWR ENG 3KO4 Slide 12 Factors affecting productivity  Professionals' capabilities  Product complexity  Schedule constraints  Previous experience (Overly aggressive scheduling may have negative effect)

13. SFWR ENG 3KO4 Slide 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. SFWR ENG 3KO4 Slide 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. SFWR ENG 3KO4 Slide 15 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"

16. SFWR ENG 3KO4 Slide 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. SFWR ENG 3KO4 Slide 17 Cost estimation procedure  Estimate software size, and use it in the model’s formula to get initial effort estimate (Person Month)  Revise effort 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. SFWR ENG 3KO4 Slide 18 COCOMO models Constructive Cost Model proposed by B. Boehm evolved from COCOMO to COCOMO II

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

23. SFWR ENG 3KO4 Slide 23 COCOMO nominal effort and schedule equations

24. SFWR ENG 3KO4 Slide 24 COCOMO scaling factors The nominal effort estimation is multiplied by these ratings to produce the estimated effort for a specific project

25. SFWR ENG 3KO4 Slide 25 COCOMO Tool http://arthurdejong.org/cocomo/