CSC 205: Software Engineering I

1. CSC 205: Software Engineering I Dr. Franz J. Kurfess Computer Science Department Cal Poly

2. Introduction Requirements Engineering Requirements Elicitation Requirements Management Project Management System Design Methods and Notations Design Models and Object-Oriented Design Design Analysis and Formal Specification Design Analysis and Verification Conclusions Course Overview

3. Motivation Objectives Management activities Project planning Project scheduling Risk management Important Concepts and Terms Chapter Summary Chapter OverviewProject Management

4. Objectives • to introduce software project management and to describe its distinctive characteristics • to discuss project planning and the planning process • to show how graphical schedule representations are used by project management • to discuss the notion of risks and the risk management process

5. Project Management • organizing, planning and scheduling software projects • management activities • project planning • project scheduling • risk management [Sommerville 01]

6. Software Project Management • concerned with activities involved in ensuring that software is delivered • on time and on schedule • in accordance with the requirements of the organisations developing and procuring the software • needed because software development is always subject to budget and schedule constraints • set by the organisation developing the software • influenced by the customer • possibly additional sources of constraints • external (standards, governing bodies) • internal (resource limitations, internal processes) [Sommerville 01]

7. Software Management Distinctions • the product is intangible • the product is uniquely flexible • software engineering is not (yet) recognized as an engineering discipline with the same status as mechanical, electrical engineering, etc. • the software development process is not (yet) standardized • many software projects are “one-of-a-kind” projects [Sommerville 01]

8. Management Activities • proposal writing • project planning and scheduling • project costing • project monitoring and reviews • personnel selection and evaluation • report writing and presentations [Sommerville 01]

9. Management Commonalties • these activities are not peculiar to software management • many techniques of engineering project management are equally applicable to software project management • technically complex engineering systems tend to suffer from the same problems as software systems [Sommerville 01]

10. Project Staffing • it may not be possible to appoint the ideal people to work on a project • project budget may not allow for the use of highly-paid staff • staff with the appropriate experience may not be available • an organisation may wish to develop employee skills on a software project • managers have to work within these constraints • especially when there is an wide shortage of skilled IT staff [Sommerville 01]

11. Project Planning • 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 • different types of plans may be developed • to support the main software project plan that is concerned with schedule and budget [Sommerville 01]

12. Types of Project Plan [Sommerville 01]

13. Project Planning Process [Sommerville 01]

14. Project Plan Structure • introduction • project organisation • risk analysis • hardware and software resource requirements • work breakdown • project schedule • monitoring and reporting mechanisms [Sommerville 01]

15. 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 [Sommerville 01]

16. Milestones in the RE Process [Sommerville 01]

17. 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 [Sommerville 01]

18. The Project Scheduling Process [Sommerville 01]

19. Scheduling Problems • estimating the difficulty of problems and hence the cost of developing a solution is hard • productivity is not proportional to the number of people working on a task • adding people to a late project makes it later because of communication overheads • the unexpected can always happen • allow contingency in planning [Sommerville 01]

20. Bar Charts and Activity Networks • 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 • project scheduling software is available • not always easy to use • often expensive [Sommerville 01]

21. Task Durations and Dependencies M1, …, T8 Milestones T1, …, T12 Tasks [Sommerville 01]

22. Activity Network [Sommerville 01]

23. Activity Timeline [Sommerville 01]

24. Staff Allocation [Sommerville 01]

25. Risk Management • risk management is concerned with identifying risks and drawing up plans to minimise their impact on a project • 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 [Sommerville 01]

26. Risk Management • manage risks so they don’t manage you • what is a risk? something that can adversely affect project success • cost • schedule • technical: functional, non-functional • once a risk happens -- it’s an issue • goals • prevent risks from escalating to issues • if it happens minimize or control the impact [Kearns 00]

27. Approaches to Risk Management • some approaches • crisis management • fix on failure • risk mitigation • prevention • elimination of root causes • “wait and see” • maybe the most popular risk management approach [Kearns 00]

28. CSC 205/206 Risk Management • think about the risks that your project will face over the course of the next two quarters • develop an approach to identify, address, and eliminate sources of risk • before they prevent the successful completion of your software project • monitor the risks and adapt your risk management approach if necessary

29. Elements of Risk Management • risk assessment • risk identification • risk analysis • risk prioritization • risk avoidance • risk control • plan to deal with each significant risk • execute the plan • monitor risk activities with specific milestones [Kearns 00]

30. General Risks • classic risks • people-related mistakes • process-related mistakes • product-related mistakes • technology-related mistakes • ignoring development fundamentals • management, technical quality • failing to actively manage risks • plan to deal with each significant risk • execute the plan • monitor risk activities with specific milestones [Kearns 00]

31. Schedule Risks • feature creep • gold-plating • shortchanged quality • optimistic schedules • inadequate design • silver-bullet syndrome • friction between developers and customers [Kearns 00]

32. Software Risks [Sommerville 01]

33. Requirements-related Risks: Elicitation • scope creep • not enough time spent on requirements development • requirements not complete, correct • e.g. new products • neglect of non-functional requirements • low customer involvement/approval of requirements • unstated requirements • solutions presented as needs [Kearns 00]

34. Requirements-related Risks: Analysis • no prioritization, can’t make tradeoffs • technically difficult features • success is always “right around the corner” • underestimating the overhead involved in learning and using new methods, tools, technologies [Kearns 00]

35. Requirements-related Risks: Specification • expectation gaps between customer and developers • even after requirements are written • time pressure to proceed despite gaps in requirements • need target dates for all uncertainties to be resolved • ambiguous terminology • unnecessary design constraints included in the system requirements specification, SRS [Kearns 00]

36. Requirements-related Risks: Verification • unverified requirements • inadequate requirements inspection training [Kearns 00]

37. Requirements Related Risks: Management • changing requirements • lack of an effective, well-defined change process • overlooked or duplicated requirements • expanding project scope [Kearns 00]

38. The Risk Management Process • risk identification • identify project, product and business risks • risk analysis • assess the likelihood and consequences of these risks • risk planning • draw up plans to avoid or minimize the effects of the risk • risk monitoring • monitor the risks throughout the project [Sommerville 01]

39. The Risk Management Process [Sommerville 01]

40. Risk Identification • technology risks • people risks • organisational risks • requirements risks • estimation risks [Sommerville 01]

41. Risks and Risk Types [Sommerville 01]

42. Risk Analysis • assess probability and seriousness of each risk • probability may be very low, low, moderate, high or very high • risk effects might be catastrophic, serious, tolerable or insignificant [Sommerville 01]

43. Risk Analysis [Sommerville 01]

44. Risk Planning • consider each risk and develop a strategy to manage that risk • avoidance strategies • the probability that the risk will arise is reduced • minimisation strategies • the impact of the risk on the project or product will be reduced • contingency plans • if the risk arises, contingency plans are plans to deal with that risk [Sommerville 01]

45. Risk Management Strategies [Sommerville 01]

46. Risk Monitoring • assess each identified risks regularly to decide whether or not it is becoming less or more probable • also assess whether the effects of the risk have changed • each key risk should be discussed at management progress meetings [Sommerville 01]

47. Risk Documentation: Risk Item Tracking Template • ID (name) • initial date, date closed • description of risk: condition, consequence • probability: likelihood of risk • impact: consequences • exposure = probability * impact • warning flags (risk becomes an issue) • mitigation plan (ways to control or minimize) • owner [Kearns 00]

48. Documenting Risks goal is to identify the most significant risks • don’t try to be too precise too soon • important to follow through. need owner and checkpoints for each risk • keep top 10 list and focus on the ones that are critical at any given time without losing sight of the others [Kearns 00]

49. Risk Factors [Sommerville 01]

50. What Are the Priorities of 205/206 Risks risk probability size risk of loss of loss exposure [Kearns 00]