1. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 1 Chapter 4

2. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 2 Topics covered l Management Activities Management Activities l Project Planning Project Planning l Risk Management Risk Management l Project Scheduling Project Scheduling

3. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 3 MANAGEMENT ACTIVITIES

4. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 4 l Proposal writing (to fund new projects) l Project planning and scheduling l Project costing and preparing bids l Project monitoring and reviews l Personnel selection and evaluation l Report writing and presentations l Attending lots and lots of meetings! Management Activities

5. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 5 l These activities are not peculiar to software management. l Many techniques of engineering project management are equally applicable to software project management. l Technically complex engineering systems tend to suffer from most of the same problems as software systems. Management commonalities

6. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 6 Project Staffing l May not be possible to appoint the ideal people to work on a project… Project budget may not allow for use of highly-paid staff. Those with appropriate skills / experience may not be available. An organization may wish to develop employee skills by assigning inexperienced staff. l Managers have to work within these constraints especially when (as is currently the case) there is an international shortage of skilled IT staff.

7. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 7 PROJECT PLANNING

8. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 8 Project Planning l Probably the most time-consuming project management activity (or at least it should be). l Continuous activity from initial concept to system delivery. Plans must be regularly revised as new information becomes available. l Different types of sub-plans may be developed to support a main software project plan concerned with overall schedule and budget.

9. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 9 Types of Project Sub-plans (QA) ?

10. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 10 Project Planning “The plan is nothing – the planning is everything.” – Dwight Eisenhower, on the D-Day invasion plan (a bit of dramatic overstatement to make a point…)

11. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 11 Project planning process - not idle time…

12. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 12 Project Plan document Structure l Introduction (goals, constraints, etc.) l Project organisation l Risk analysis l Hardware and software resource requirements l Work breakdown l Project schedule l Monitoring and reporting mechanisms

13. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 13 Activity Organization l Activities in a project should be associated with tangible outputs for management to judge progress (i.e., to provide process visibility) l Milestones are the unequivocal end-points of process activities. e.g., “DR1 complete” versus “90% of design complete”

14. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 14 Activity organization l Deliverables are project results delivered to customers. (There are also internal “deliverables”.) l The waterfall model allows for the straightforward definition of milestones (“a deliverable oriented model”). l Deliverables are always milestones, but milestones are not necessarily deliverables.

15. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 15 Milestones in the RE process

16. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 16 Project Planning Methods Critical Path Method, Gantt charts, Activity bar charts, etc. Build a work-plan from activity data. Display work-plan in graphical form. Project planning software (e.g., Microsoft Project) Maintain a database of activity data with input tools Calculate and display schedules Provide progress reports

17. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 17 Project Planning Methods All project planning methods are best when: 1. Plan is updated regularly (e.g., weekly or monthly) 2. The structure of the project is well understood 3. The time estimates are reliable 4. Activities do not share resources Unfortunately, #2, #3, #4 rarely apply to software development

18. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 18 A Simple Gantt Chart Source: Microsoft using Excel

19. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 19 A More Complex Gantt Chart Source: SmartDraw

20. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 20 Gantt Charts Dates run along the top (days, weeks or months). Each row represents an activity. Activities may be scheduled sequentially, in parallel or overlapping. The scheduled for an activity is a horizontal bar. The left end marks the planned beginning of the task. The right end marks the expected end date. The chart may be updated by filling in each activity to a length proportional to the work accomplished. Progress to date can be compared with the plan by drawing a vertical line through the chart at the current date.

21. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 21 Project Plan Activity Code Task Duration (in months) Persons Responsible Research Preparation and PresentationA.0  Preliminary Investigation Phase A.12PM  Preparation of Thesis Proposal A.23PM, TA, TS  Thesis Preparation for Proposal Hearing A.32 PM, TA, TS, TP  Conduct of Instrument Validation and Reliability A.43 PM, TA, QV, TS  Survey Administration A.51PM, TS  Data Presentation and Analysis A.61PM, TA, TS  Formulation of Conclusion and Recommendation A.71PM System DevelopmentB.0  System Analysis of I/O Specifications B.13PM

22. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 22 Project Plan Activity Code Task Duration (in months) Persons Responsible  System Design o Preparation of I/O Specification o Content Development o Screenplay o Storyboard B.24PM, WP, GD  Software Development o P rogram Coding B.34 PM, AP, WP, GD  Software Testing and Evaluation o Program Testing and Debugging o System Evaluation B.42PM, SE  Preparation for Final Defense B.52PM, TP, TA, TS  System Implementation o Software Installation o Dry-run for Feedback by end- users B.64PM Final Revision and Submission of the Final Copy of Thesis Paper C.0 1PM, TP, TA

23. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 23 GANTT CHART ActivityPredecessor Schedule of Activities (in months) Starting from November 2007 to July 2008 111212345678 A.1None A.2A.1 A.3A.2 A.4A.3, B.1 A.5A.4 A.6A.5, B.2 A.7A.6 B.1A.1 B.2A.3 B.3A.4, B2 B.4A.7 B.5B.4 B.6B.5 C.0

24. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 24 ActivityPredecessor Schedule of Activities (in months) Starting from August 2008 to April 2009 910111212345 A.1None A.2A.1 A.3A.2 A.4A.3, B.1 A.5A.4 A.6A.5, B.2 A.7A.6 B.1A.1 B.2A.3 B.3A.4, B2 B.4A.7 B.5B.4 B.6B.5 C.0 TOTAL ESTIMATED TIME DURATION IS 19 MONTHS

25. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 25 Activity Graph An activity A dummy activity An event A milestone A scheduling technique that emphasizes dependencies

26. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 26 RISK MANAGEMENT

27. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 27 Risk management l Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project.

28. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 28 Risk Management l Identify risks l Analyze risks l Set up plans to minimize the following effects. Affect schedule or resources Affect the quality or performance Affect organization or procurement l Monitor risks

29. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 29 Risk management l A risk is a probability that some adverse circumstance will occur. Project risks affect schedule or resources. Product risks affect the quality or performance of the software being developed. Business risks affect the organisation developing or procuring the software. (Taxonomy based on Effect)

30. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 30 Software Risks

31. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 31 The risk management process l Risk identification Identify project, product and business risks; l Risk analysis Assess the likelihood and consequences of these risks ; l Risk planning Draw up plans to avoid or minimise the effects of the risk; l Risk monitoring Monitor the risks throughout the project ;

32. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 32 The risk management process

33. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 33 Risk Identification l Technology risks. l People risks. l Organisational risks. l Requirements risks. l Estimation risks.

34. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 34 Risks and risk types

35. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 35 Risk analysis l Assess probability and seriousness of each risk. l Probability may be very low, low, moderate, high or very high. l Risk effects might be catastrophic, serious, tolerable or insignificant.

36. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 36 Risk analysis (i)

37. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 37 Risk analysis (ii)

38. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 38 Risk planning l Consider each risk and develop a strategy to manage that risk. l Avoidance strategies – the probability that the risk will arise is reduced. l Minimisation strategies – the impact of the risk on the project or product is reduced. l Contingency plans – if the risk arises, contingency plans are plans to deal with that risk. (to effect the minimisation strategy)

39. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 39 Risk management strategies (i)

40. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 40 Risk management strategies (ii)

41. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 41 Risk indicators

42. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 42 Risk monitoring l Assess each identified risk regularly to decide whether or not it is becoming less or more probable. l Also assess whether the effects of the risk have changed. l Each key risk should be discussed at management progress meetings.

43. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 43 PROJECT SCHEDULING

44. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 44 Project Scheduling l Split project into tasks and estimate time and resources required to complete each. l Tasks should not be too small or too large – they should last on the order of weeks for projects lasting months. (“Models should be as simple as possible, but no simpler.”)

45. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 45 Project Scheduling l Organize tasks as concurrent activities to make optimal use of workforce. l Minimize task dependencies to avoid potential delays. l Dependent on project managers’ intuition and experience. (Good management is not a science.)

46. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 46 The Project Scheduling Process Review Progress

47. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 47 Scheduling Problems l Estimating the difficulty of problems, and hence the cost of developing solutions, is hard. l Progress is generally not proportional to the number of people working on a task. l Adding people to a late project can make it later (due to coordination overhead). (- F. Brooks, The Mythical Man-Month) l The unexpected always happens. Always allow for different contingencies in planning. (a.k.a. “Murphy’s Law”)

48. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 48 TIMETIME PEOPLE fewmany less more

49. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 49 TIMETIME PEOPLE fewmany less more Stuffing Envelopes

50. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 50 TIMETIME PEOPLE fewmany less more K = time X people

51. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 51 TIMETIME PEOPLE fewmany less more Having a baby Stuffing Envelopes

52. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 52 TIMETIME PEOPLE fewmany less more Software Development

53. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 53 Bar charts and activity networks l Graphical notations are often used to illustrate project schedules. l Activity charts (a.k.a. PERT* charts) show task dependencies, durations, and the critical path. l Bar charts (a.k.a. GANTT charts) generally show resource (e.g., people) assignments and calendar time. * Program Evaluation and Review Technique

54. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 54 Task durations and dependencies

55. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 55 Activity network

56. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 56 Activity timeline duration potential slack time

57. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 57 Staff allocation (Gantt Chart)

58. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 58 Key points l Good project management is essential for project success. l The intangible nature of software causes problems for management. l Managers have diverse roles but their most significant activities are planning, estimating and scheduling. l Planning and estimating are iterative processes which continue throughout the course of a project.

59. ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 59 l A project milestone is a predictable state where a formal report of progress is presented to management. l Project scheduling involves preparing various graphical representations showing project activities, their durations and staffing. l Risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats. Key points