1. Software engineering Olli Alm Lecture 5: project management & workload estimation

2.  Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software.  Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Software project management

3. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Management activities  Proposal writing.  Project planning and scheduling.  Project costing.  Project monitoring and reviews.  Personnel selection and evaluation.  Report writing and presentations.

4.  Probably the most time-consuming project management activity.  Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available.  Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Project planning

5. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Types of project plan

6. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Activity organization  Activities in a project should be organised to produce tangible outputs for management to judge progress.  Milestones are the end-point of a process activity.  Deliverables are project results delivered to customers.  The waterfall process allows for the straightforward definition of progress milestones.

7. Activity organization  Milestones  example  Deliverables  example

8. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Milestones in requirements engineering

9. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Project scheduling  Split project into tasks and estimate time and resources required to complete each task.  Organize tasks concurrently to make optimal use of workforce.  Minimize task dependencies to avoid delays caused by one task waiting for another to complete.  Dependent on project managers intuition and experience.

10. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Project scheduling process

11. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Bar charts and activity network  Graphical notations used to illustrate the project schedule.  Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two.  Activity charts show task dependencies and the the critical path.  Bar charts show schedule against calendar time.

12. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Bar charts and activity network  Graphical notations used to illustrate the project schedule.  Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two.  Activity charts show task dependencies and the the critical path.  Bar charts show schedule against calendar time. Critical path: (a chain of) tasks that may block the starting of following tasks Critical path (Pressman): ”Tasks that must be completed on schedule if the project as a whole is to be completed on schedule”

13. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Task durations and dependencies

14. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Activity network

15. © Ian Sommerville 2004, Software Engineering 7, ch 5 slides Activity timeline (Gantt chart)

16. Workload estimation  A set of techniques to estimate cost and effort required for software production How much effort (hours?) is required to complete each activity? How much calendar time is needed (when a task should be finished?) What is the total cost of each activity?

17. Workload estimation: productivity  Productivity: How many ”units” are there to be produced? How many ”units” can be produced by a man in an hour? Complete cost: /  total time taken

18. Workload estimation: productivity  Productivity: How many ”units” are there to be produced? How many ”units” can be produced by a man in an hour? Complete cost: /  total time taken BUT: software is always ”unique product”, cost estimation is hard and difficult (and often fails)

19. Workload estimation: productivity  Productivity: Complete cost: /  total time taken / total cost  Productivity example, size-oriented metrics: Unit measure: lines of code No of units: Software size will be 10’000 lines Unit per hour: Developer codes 50 lines in hour Total cost: 10’000 / 50: 200 hours To code the software in a week (~40 hours), we need 200 / 40: 5 persons

20. Workload estimation: cost metrics  Metrics: a measurable / quantifiable factor of the (software) product to be developed  Cost estimation: Size-related metrics  Lines-of-code (LOC)  Size of documentation (no of pages) Function-related metrics  Based on overall functionality of the software  Function points  Object points

21. Workload estimation: size-related example Lines-of-code (LOC)  Pros: simple, explicit measurement unit One measure to whole project: LOC includes all other activities: requirements, design… (in other words, other activities are simplified / reduced to LOC)  Cons: Quantity vs. Quality? Good code  less lines Language dependent measurement (e.g. in Java, it usually takes lots of lines to code anything) Difficult to estimate

22. Workload estimation: function-related metrics  Measuring the functionality of the code More independent from implementation language than size-oriented metrics  Function-Point count (FP) No of function points implemented per person-month  Function-Points: External inputs and outputs User interactions External interfaces Files used by the system  Each function point has a complexity-weight E.g. external input: simple: weight 3 complex: weight 15

23. Workload estimation: function-point (continued)  Unadjusted Function-point Count (UFC) Overall measure (one value) for the productivity UFC = ∑(no of elements of given type)*(weight)  Function-Point count Result value depends (heavily) on the estimator Suitable for data-processing system, not so good for event-driven (=where no of inputs and outputs are hard to calculate)

24. Workload estimation: object-points  Another function-related metrics  Not related to object-oriented programming  Object points is weighted estimation of Number of separate screens displayed Number of reports produced Number of modules that supplement / use database  Object points Easier to estimate high-level software specification More related to user interaction than data processing Utilized in (the famous) COCOMO II estimation model with the name application points

25. Workload estimation  Combinations of function and size related metrics is possible  To estimate workload correctly: You should know your team You should know the problem You should understand what is the best (combination of) estimation techniques in the specific situation  Previous, similar projects are the best source of information! (=experience matters)

26. Factors affecting SE productivity © Ian Sommerville, Software Engineering 7

27. Cost-estimation techiniques © Ian Sommerville, Software Engineering 7

28. Workload estimation – real world example Software company, located in Finland 1.Project group + senior expert in the meeting room 2.Go through the project goals 3.Project activities on the wall, every one on its own paper, size A0 4.Write down those activities + people who do them + their experience 5.Divide the group into three sub groups  independent workload estimations 6.Walk through those estimations and try to think reasons for the differences 7.Final target: List of works that need to done List of workload

29. Workload estimation – real world example Software company, located in Finland 7. Final target: List of works that need to done List of workload Most commonly used figures: pessimistic approximation ( p ) probable approximation ( a ) optimistic approximation ( o ) Maximum likelihood = p + 4a +o 6

30. Project economics  A person who has no experience with project / software work can’t understand where all those huge costs are coming from.  Most of the costs are coming from labor costs = 50.. 70 % of all costs = monthly salary, overtime salary, bonus, necessary indirect employee costs ( 50... 60 % of salary ) and optional indirect employee costs ( car, food, health care, refreshments)  Others: overhead cost (work premises rents, phone, post... ), hardware+software costs, education, literature, traveling costs, project group support ( no active project work ), capital costs and contribution margin ( need to make some money ).  If a new person is hired  means about 6 - 10 months salary. Adapted from Haikala-Märijärvi: Ohjelmistotuotanto

31. Project economics (continued) Rough estimate for software work:  Calculate basic hour rate price = sum ( cost items ) / sum ( hours billing from customer)  Billing hours = (all working hours) – (working hours that are “not“ directly customer work) Example:  normal number of working days = 225 days = 1700 hours / person  management and secretaries can normally use only 25 % their work directly in project.  Working cost = project hours * basic hour rate  Project price = sum ( working cost + other costs ( external services+ equipments..... )) Adapted from Haikala-Märijärvi: Ohjelmistotuotanto

32. Project economics (continued) Rough estimate for software work: Example:  A small company, manager + 9 programmers. Programmers do effective work in projects, 75 % of their working time, last part is for education + old project maintenance work  One person per year leaves the company and new one will come in.  Salaries and indirect employee costs are = 10 * ( 1.6 * 2200 eur *12 moths) = 422 400 eur  Overheads, etc multiply by 1.5  633 600 eur.. Adapted from Haikala-Märijärvi: Ohjelmistotuotanto

33. Project economics (continued) Rough estimate for software work:  9 programmers, but only 8 work effectively in projects  8 * 1700 * 0.75 = about 10000 hours that customer will pay.  Hour rate = about 63 euros ( 633600 / 10000 ) --> day rate = 506 euros  If programmer does 10... 30 lines of program code / day  one line of code = 15... 50 eur  Our Java program that has 15000 code lines costs a couple of millions.  COCOMO / intermediate model= 47 mm * 22 days/mm * 8 hours/day) * 63 euros /h = about 521 000 euros