Software Engineering: Analysis and Design - CSE3308

1. CSE3308/DMS/2005/20 Monash University - School of Computer Science and Software Engineering Software Engineering: Analysis and Design - CSE3308 Risk

2. Lecture Outline • What is Risk? • Risk Areas in Software Development • Risk Analysis • Portfolio Risk Management • Techniques for Managing Risk

3. What is Risk? • Foreseeable events whose occurrence could cause system degradation or failure • Risks concern future happenings • Risk involves change • Risk involves choice • Futile to try to eliminate risk • Questionable to minimise risk • Essential that we take risks • But we must try to take the “right” risks

4. The Laws of Misrule • Murphy’s Law • Whatever can go wrong, will go wrong • O’Halloran’s Corollary to Murphy’s Law • And will go wrong at the worst possible time • McGuire’s Lemma • Everything takes longer than expected • Software Developers are optimists • Humans are inherently bad at estimating

5. What do we want from Software Development Projects ON TIME ON SPECIFICATION ON BUDGET CHOOSE ANY TWO

6. Why Do Systems Fail? • Resource failures • Requirements failures • Goal failures • Technique failures • User contact failures • Organisational failures • Technology failures • Size failures • Methodology failures • Planning and control failures • Personality failures

7. Types of Failure (1) • Resource Failures • Conflicts of people, time and scope • Allotted resources are not sufficient to build the required system • Systems are often late and frequently over budget • Time pressure “Get it done” leads to unreliable systems and unhappy users

8. Types of Failure (2) • Requirements Failures • Incorrect, incomplete or unclear specifications of system requirements • Leads to building the wrong system • Need for changes leads to budget and schedule difficulties

9. Types of Failure (3) • Goal failures • Inadequate or incorrect statements of the system goals by management • Misunderstanding of the goals by the system builders • Leads to Requirement failures • Technique Failures • The system builders fail to use, or use incorrectly, effective software development techniques • Often caused by an obstinate adherence to what has succeeded in the past • Conversely, also often caused by a lemming-like rush towards the “latest and greatest” technology

10. Types of Failure (4) • User Contact Failures • Inability to communicate with the user community • Internal users - leads to poor acceptance and use of the system • External users - leads to contractual problems • User is the marketplace - leads to a poorly received product in the marketplace

11. Types of Failure (5) • Organisational failures • Inability of the organisation to support the software development process • Lack of leadership, large span of control, poor coordination between sub-groups, lack of clearly designated responsibility • Technology failures • Failure of acquired hardware or software utilised by the system being developed • Generally from new and untested software • Sometimes from discontinuation/failure of a product

12. Types of Failure (6) • Size failures • The system is just too big for the software development group to build • People management failures • Lack of motivation for workers • Poor morale • Methodology failures • Failures to perform the activities needed to build the system or performing unnecessary activities • May be due to a lack of a formal methodology • May be due to rigid adherence to a methodology • May be due to management directive

13. Types of Failure (7) • Planning and Control failures • Failure to track progress, depict plans and schedules and vaguely defining assignments • If there are many sub-groups, it often leads to dead time • Personality failures • Clashes between people within the system development group or external to the system development group • In extreme cases, we get acts of revenge and sabotage • More usually, passive cooperation and covert resistance

14. The fate of a software development project?

15. External versus Internal Risk • Problems within the control of the group leader are internal problems • Problems requiring approval, action or decision by persons outside the software development group are external problems • Risks are posed to the system by both external and internal problems

16. Resources Requirements Goals Techniques User Contact Organisational Technology Size People Management Methodology Planning and Control Personalities _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ _______ Exercise: Internal versus External Problems Rating 1 (solely Internal) to 10 (solely External) Failure Category

17. Risk and Politics • The main threats to system failure are external • The external nature of the threats indicates that we will have to deal with people • The art of dealing with people is called politics • Good project managers are good politicians

18. A Process of Risk Analysis • Key part of Requirements Analysis • Is an on-going activity throughout the whole lifecycle • Several steps involved: • Risk Identification • Risk Projection (Estimation) • Risk Assessment • Risk Management and Monitoring

19. Risk identification • Using the categories of risk identified earlier, users and the project team attempt to identify all the specific risks • Risk item check lists are often useful • Example: Staffing Risks • Are the best people available? • Do the people have the right combination of skills? • Are enough people available? • Is the staff committed for the duration of the project? • Will some people be only working part-time? • Does the staff have the right expectations about the job? • Have staff members received necessary training? • Will turnover amongst staff be low enough to allow continuity?

20. Risk Projection • Rating of the impact of the risk on the project • Rating is based upon two factors • The likelihood that the risk will occur • The consequences to the organisation and project if the risk occurs • Method is • Establish a scale that reflects the perceived likelihood of a risk (Boolean, Qualitative, Quantitative) • Describe the consequences of the risk • Estimate the impact of the risk on the project and product (nature, scope and timing) • Note the overall accuracy of the risk projection

21. Risk and Management Concern

22. Risk Assessment • Risk projection provides us with a set of triplets of the form [ri, li, xi] ri is the ith risk, li is its likelihood, and xi is its impact • Prioritize the risks • Think about means to control/avert the risks • Establish risk referent levels • cost, schedule and performance are common • What level of degradation in these areas will cause the project to be cancelled?

23. Risk Referent Levels Referent point (cost value, time value) Area where Project termination will occur is above the line Projected Schedule Overrun Projected Cost Overrun

24. Risk Assessment (2) • Define the risk referent levels for the project • Attempt to develop a relationship between each [ri, li, xi] and each of the referent levels • Predict the set of referent points that define a region of termination bounded by a curve or areas of uncertainty • Try to predict how compound combinations of risks will affect a referent level • Many statistical methods available to use on this • Unfortunately, these things are very difficult to attach to a smooth line and often change in development

25. Risk Management and Monitoring • Develop steps to manage or avert the risks that we have identified and assessed as important • Example - we estimate staff turnover to be 70% over the lifetime of the project ( high but not unreasonable) • Steps which could be taken by management • Determine causes of turnover with staff and mitigate those causes management can control • Assume turnover will occur and develop techniques to assist in continuity • Organize teams so that information is widely dispersed • Appoint a backup staff member for each critical technologist • Define documentation standards and ensure documentation is done in a timely manner • Conduct peer reviews of all work (e.g. walkthroughs)

26. Risk Management and Monitoring • Develop a risk management plan (see handout) • Remember the 80/20 rule - 80%of the impact will come from 20% of the risks • Monitor the risks as the project progresses

27. McFarlan’s Risk Assessment Method • A simpler method of assessing the risk of a project • Relies upon examining three factors of a project • The measurement of these three factors is conducted via a questionnaire • These questionnaires are most useful when based upon the past experience of the organisation (see handout for example)

28. The Three Factors • Project Size • the larger the project, the greater the risk • project size is relative to the experience of the software development group • Experience with the Technology • the less experience the software development group has had with the technology used, the greater the risk • Project Structure • How well-defined are the requirements of the project and how liable are they to change • High structure where requirements are well-defined and stable indicates lower risk

29. Estimating Project Risk LOW STRUCTURE HIGH STRUCTURE Low risk (very susceptible to mismanagement) Large Project Low risk LOW COMPANY-RELATIVE TECHNOLOGY Low risk (very susceptible to mismanagement) Small Project Very low risk Large Project Very high risk Medium risk HIGH COMPANY-RELATIVE TECHNOLOGY Small Project High risk Medium- low risk

30. Estimate Assignment 2 • Applying the three factors to your group’s work on Assignment 2, what risk factor would you give it?

31. Portfolio Risk Profile • Organisations should not build only low risk projects • Organisations should have a portfolio of risks in their system development • Organisations should develop a risk profile appropriate for their situation • Example : where IT is strategic (e.g. banking), managers should be concerned if there are no high-risk projects • Otherwise competitors will almost certainly get ahead

32. Techniques for Managing Risk • Four main categories of techniques • External Integration tools • organisational and communicational tools that link the project team’s work with users • Internal Integration tools • ensure that the team operates as an integrated unit • Formal planning tools • help to structure the sequence of tasks in advance and to estimate the time, money and technical resources the team will need to execute them • Formal results-control mechanisms • help managers to evaluate progress and to spot potential discrepancies

33. Selection of user as project manager Creation of user steering committee Frequent in-depth meetings of user steering committee User-managed change control process Frequent and detailed distribution of project team minutes to key users Selection of users as team members Formal user specification approval process Progress reports prepared for corporate steering committee User responsibility for education and installation of system User management decision on key action dates External Integration Tools

34. Selection of experienced IT professional to lead the team Frequent team meetings Regular preparation and distribution of minutes within team on key design evolution decisions Regular technical status reviews Managed low turnover of team members Selection of high percentage of team members with significant previous work relationships Participation of team members in goal setting and deadline establishment Outside technical assistance Internal Integration Tools

35. Formal Planning Tools • PERT (Program Evaluation and Review Technique) and CPA (Critical Path Analysis) • Milestone phases selection • System specification standards • Feasibility study specifications • Project approval processes • Project post-audit procedures

36. Formal Control Tools • Periodic formal status reports versus plan • Change control disciplines • Regular milestone presentation meetings • Deviations from plan reports

37. Contribution of tools to ensure project success

38. References • Pressman, Roger S., Software Engineering: A Practitioner’s Approach, McGraw-Hill, 2000 (Ch. 6). • McFarlan, F. W., Portfolio Approach to Information Systems, Harvard Business Review, No. 81510, Sep. 1981.