Software Engineering

1. Software Engineering Risk Management

2. Steps in Project Planning • Scope—understand the problem and the work that must be done. • Estimation—how much effort? how much time? • Risk—what can go wrong? how can we avoid it? what can we do about it? • Schedule—how do we allocate resources along the timeline? what are the milestones? • Control strategy—how do we control quality? how do we control change? Project Scope Estimates Risks Schedule Control strategy Software Project Plan

3. Risk Analysis and Management • Definition of Software Risk: • Concerns future happenings. What risks might cause the project to go astray? • Involves change. How will changes in customer requirements, development technologies, target computers, and other entities affect timeliness and success? • Requires choice. What methods and tools should be used, how many people should be involved to reduce risk? • Questions: • What can go wrong? • What is the likelihood? • What will the damage be? • What can we do about it?

4. Reactive Risk Management • “Indiana Jones School of Risk Management” — project team reacts to risks when they occur. • Mitigation—plan for additional resources in anticipation of fire fighting. • Fix on failure—resources are found and applied when the risk strikes. • Crisis management—if failure does not respond to applied resources then the project is in jeopardy. • “If you don’t actively attack the risks, they will actively attack you.”

5. Proactive Risk Management • Formal risk analysis is performed: • Potential risks are identified • Their probability and impact are assessed • They are ranked by importance • Project team established a plan for managing these risks • Organization corrects the root causes of risk: • Examine risk sources that lie beyond the bounds of the software • Develop the skill to manage change

6. Risk Management Paradigm control track RISK identify plan analyze

7. Software Risks • Project Risks: • Threaten the project plan. Should identify potential budgetary, schedule, personnel, resource, customer and requirement problems. • Project complexity, size and degree of uncertainty are factors that increase risk. • Technical Risks: • Threaten the quality. Should identify specification ambiguity, technical uncertainty, technical obsolescence, and “bleeding edge” technology. • Occur because the problem is harder to solve than anticipated. • Business Risks: • Threaten the viability of the software. (1) Building an excellent system that no one wants, (2) building a product that no longer fits into the business strategy, (3) a product the sales force don’t understand, (4) losing the support of management, (5) losing budgetary or personnel commitment.

8. Risk Identification • Risk identification is a systematic attempt to specify threats to the project plan. • Although generic risks are important to consider, usually the product specific risks cause the most headaches. • Ask a set of questions which will allow an estimate of the impact of risk: • Product Size • Business Impact • Customer • Process Maturity • Technology Risks • Staff/People Risks

9. Risk Due to Product Size • Attributes that affect risk: • Estimated size of product in LOC or FP? • Estimated size of product in number of programs, files, transactions? • Percentage deviation in size of product from average for previous products? • Size of database created or used by the product? • Number of users of this product? • Number of projected changes to the product? Before delivery? After delivery? • Amount of reused software?

10. Risk Due to Business Impact • Attributes that affect risk: • Affect of this product on company revenue? • Visibility of this product to senior management? • How reasonable is the delivery deadline? • Number of customers who will use this product? • Interoperability constraints? • Sophistication of end-users? • Amount and quality of product documentation that must be produced and delivered to the customer? • Governmental constraints. • Costs associated with late delivery? • Costs associated with a defective product?

11. Risks Due to the Customer • Questions that must be answered: • Have you worked with the customer before? • Does the customer have a solid idea of requirements? • Has the customer agreed to spend time with you? • Is the customer willing to participate in reviews? • Is the customer technically sophisticated? • Is the customer willing to let your people do their job – that is, will the customer resist looking over your shoulder during technically detailed work? • Does the customer understand the software engineering process?

12. Risks Due to Process Maturity • Questions that must be answered: • Have you established a common process framework? • Is it followed by project teams? • Do you have management support for software engineering? • Do you conduct formal technical reviews? • Are CASE tools used for analysis, design and testing? • Are the tools integrated with one another? • Have document formats been established?

13. Technology Risks • Questions that must be answered: • Is the technology new to your organization? • Are new algorithms, I/O technology required? • Does the application interface with new software? • Is new or unproven hardware required? • Is a specialized user interface required? • Is the application radically different? • Are you using new software engineering methods? • Are you using unconventional software development methods, such as formal methods, AI-based approaches, artificial neural networks? • Are there significant performance constraints? • Is there doubt that the functionality requested is “do-able”?

14. Staff/People Risks • Questions that must be answered: • Are the best people available? • Do staff have the right skills? • Are enough people available? • Are staff committed for entire duration? • Will some people work part time? • Do staff have the right expectations? • Have staff received necessary training? • Will turnover among staff be low?

15. Risk Analysis • Developing a Risk Table (implemented as a spreadsheet): • Identify risks. • Estimate the probability of occurrence. Each member of the project team assigns a probability. Continue in round-robin fashion until agreement is reached. • Estimate the impact on the project on a scale of 1 to 5: • 1 = catastrophic (the failure caused by this risk would result in project failure, or the increase in costs and schedule delays would exceed R500k) • 2 = critical (failure leads to questionable project success, or increased costs and delays in the range R100-500k) • 3 = marginal (the failure would result in degradation of secondary objectives, or increased costs and delays in the range R1-100k) • 4 = negligible (failure to meet requirements would result in inconvenience, or increased costs and delays of less than R1k) • sort the table by probability and impact. • Calculate risk exposure:

16. A Risk Table Risk Probability Impact RMMM Risk Mitigation Monitoring & Management

17. Risk Mitigation, Monitoring,and Management • For the risks with exposure higher than a certain cutoff: • mitigation—how can we avoid the risk? • monitoring—what factors can we track that will enable us to determine if the risk is becoming more or less likely? • management—what contingency plans do we have if the risk becomes a reality? • Example: • Assume high staff turnover is noted as a project risk with probability = 0.7 and impact = 2. • To mitigate meet with staff about grievances, develop techniques to ensure continuity, conduct peer review so all are up to speed, assign a backup staff member to each critical technologist. • To monitor measure the degree of team “jell”, potential problems with compensation and benefits, general attitude of team members. • To mitigate ensure that critical documents are prepared in a timely and consistent manner.

18. Recording Risk Information Project: Embedded software for XYZ system Risk type: schedule risk Priority (1 low ... 5 critical): 4 Risk factor: Project completion will depend on tests which require hardware component under development. Hardware component delivery may be delayed Probability: 60 % Impact: Project completion will be delayed for each day that hardware is unavailable for use in software testing Monitoring approach: Scheduled milestone reviews with hardware group Contingency plan: Modification of testing strategy to accommodate delay using software simulation Estimated resources: 6 additional person months beginning 7-1-96