1. CS 564 – Lecture 11 Requirements Risk Management and WinWin

2. Risk Risk is the possibiloity of economic loss or injury Risk Exposure = (Probability of unsatisfactory outcome) X (Loss if unsatisfactory outcome)

3. Types of Risks Risks affect the project plan (project risks), the quality (technical risks), or the viability of the product (business risks).

4. Risk Classification

5. Risk Watchwords Identify the Risks and compute Risk Exposure. When the risk exposure to do something, is unknown DON’T do it. When it’s risky not to do something, DO IT.

6. Risk Exposure For event E, P(E) = m/n P = Probability m = favorable events n = total events The Risk = 1-P(E) The Risk Exposure = Risk * Cost given that the event actually happens

7. Requirements Risk Management Win-Win Spiral Anchor Points Life Cycle Objectives (LCO) Life Cycle Architecture (LCA) Initial Operational Capability (IOC)

8. Functions of Risk Management FctDescription IdentifySearch for and locate risks before they become problems. Analyze Transform risk data into decision-making information. Evaluate impact, probability, and timeframe, classify risks, and prioritize risks. Plan Translate risk information into decisions and mitigating actions (both present and future) and implement those actions. TrackMonitor risk indicators and mitigation actions. ControlCorrect for deviations from the risk mitigation plans. Comm. Provide information and feedback internal and external to the project on the risk activities, current risks, and emerging risks. Note: Communication happens throughout all the functions of risk management.

9. Risk Do’s and Don’t Don’t overestimate the risks : too much contingency planning Don’t underestimate the risks : leads to panic management later Don’t look for scapegoats Do deal with the top 10 risk exposures first

10. 1989 1. Personnel shortfalls 2. Schedules and budgets 3. Wrong software functions 4. Wrong user interface 5. Gold plating 6. Requirements changes 7. Externally-furnished components 8. Externally-performed tasks 9. Real-time performance 10. Straining computer science 1995 1. Personnel shortfalls 2. Schedules, budgets, process 3. COTS, external components 4. Requirements mismatch 5. User interface mismatch 6. Architecture, performance, quality 7. Requirements changes 8. Legacy software 9. Externally-performed tasks 10. Straining computer science Top 10 Risk Items: 1989 and 1995

11. Primary Risk Items People commitment; compatibility; ease of communication; skills Schedule project scope; critical-path items Mismatched user Interfaces and Objectives Performance and overhead External Dependencies Client/User/Administrator Commitment to transition

12. Risk Analysis Template Str ucture Tech- nology SizeRiskScaleQALocal Tests Formal Planning Config Control HighLowLargeLow3no yes HighLowSmallLowest1no yes High LargeMedium7yesmaybeyes High SmallLow- med 5mayb e noyes Low LargeHigh8yes Low SmallMedium7no yes LowHighLargeHighest10Yes yes LowHighSmallHigh8yes

13. COTS and External Component Risks COTS Trustworthiness Compatibility Performance Controllability Non-commercial off-the shelf components Open Source Reuse libraries

14. Technical Background Waterfall focuses on formal Project Control Spiral focuses on Risk management WinWin Spiral focuses on requirements risk management WinWin Risk Driven Spiral with Anchor Points (LCO, LCA, IOC) Agile focuses on Schedule Lambda focuses on Trustworthiness

15. Risk Management Importance Contains Complexity Quantitative Techniques used to manage risks and set priorities Reduces Rework Typically 40-50% of software costs

16. Rework Costs are Concentrated

17. If Risk Management is so important, why don’t people do it? ‘Can Do’ culture Unwillingness to admit risks exist Leaves impression that you don’t know exactly what you’re doing Leaves impression that your bosses, customers don’t know exactly what they’re doing “Success-orientation” Tendency to postpone the hard parts Maybe they’ll go away Maybe they’ll get easier, once we do the easy parts Up front effort, time and investments It is hard to say ‘no.’

18. Motivation for Risk Management Death March Experience Project Failure Fear of Failure Unrealistic Expectations Risk Management Skills

19. Unrealistic or Unknown Expectations

20. WinWin A process that lets stakeholders work out and agree to a known set of mutually shared commitments. The win-win process is composed of a set of principles, practices, and tools.

21. Outsourcing Risks Medium Unique Dev Loose coupling High Unique Dev Tightly coupled Low Existing pattern Stand Alone Medium Unique Dev Loose coupling High Low Level of Integration Level of Customization

22. Key Stakeholders Purchasing Agents, End Users, IT staff, Customers, Developers, Testers and Maintainers Sometimes other project managers, Subcontractors, Supplier’s, Venture Capitalists General Public For each stakeholder identify Home organization Know how Authority

23. Win-lose becomes Lose-lose

24. WinWin Key Concepts Win Condition: an objective that makes a stakeholder a winner Issue: conflict or constraint on a win condition Option: A way of overcoming an issue Agreement: mutual commitment to an option or win condition WinWin Equilibrium State: 1.All Win Conditions covered by Agreements 2.There are no outstanding Issues

25. Win Condition Agreement Option Issue blocks addresses adopts covers WinWin Negotiation Model

26. Why WinWin? Alternatives don’t work and leads to lose-lose. Avoids costly rework 60:1 cost increase to fix requirements error after delivery Builds trust and manages expectations Makes Teamwork likely Helps stakeholders adapt to change

27. Anchor Points Life Cycle Objectives (LCO): Stakeholders agreed to system’s requirements and engineers have demonstrated one feasible architecture. Life Cycle Architecture (LCA): Developers have detailed an implementation architecture and stakeholders agree to proceed to implementation. Initial Operating Capability (IOC): Working system has been implemented, tested, and transitioned to customer site, and stakeholders have agreed to put it into operation.

28. SPIRAL MODEL

29. Workflow Balance over the Life Cycle InceptionElaborationConstructionTransition Management Environment Requirements Design Implementation Testing Deployment

30. Do notices look exactly like they always have? Teachers are conservative and will resist changing their routine in any way Possible Model Clashes: Teachers makes the following assumption: success model assumption: no changes should be made to procedure or forms Developer makes one or both of following assumptions: product model assumption: fancier graphics make product more appealing process model assumption: stakeholder interaction is not necessary for requirements gathering © NJCSE Library Overdue Book Notices: Stakeholders fear automation

31. Is output sorted by class, and then by student name? Librarian gives notices to teachers to give to students. If s/he has to sort by hand, s/he won’t use the system. Possible Model Clashes: Librarian makes the following assumption: success model assumption: system should result in less work rather than more work Developer makes one or both of following assumptions: product model assumption: output order is unimportant process model assumption: stakeholder interaction is not necessary for requirements gathering © NJCSE Library Overdue Book Notices: Importance of order of notices

32. Is input by books NOT returned, rather than by books returned? Far more books are returned on time than not. Far more work to enter books returned. Possible Model Clashes: Librarian makes following assumption success model assumption: system should result in less work rather than more work Developer makes one of the following assumptions: product model assumption: any input model is okprocess model assumption: stakeholder interaction is not necessary for requirements gathering © NJCSE Library Overdue Book Notices: Update by Exception

33. Does the manual make it clear that data must be saved to floppy after each time the system is used? If not, computer-shy librarian may forget. Possible Model Clashes: Librarian makes the following assumption” success model assumption: all required actions must be stated explicitly in manual Developer makes one, two, or three of the following assumptions: success model assumption: users are as sophisticated as I am process model assumption: stakeholder interaction is not necessary for requirements gathering success model assumption: expend least possible effort Library Overdue Book Notices Administrator Woes

34. Is saving done via a menu command? Teaching librarian to copy files is much harder than teaching him/her to use a menu command. Possible Model Clashes: Librarian makes one or both of following assumptions: success model assumption: the simpler the better product model assumption: “save” function is part of GUI Developer makes one or both of the following assumptions property (environment) model assumption: users are sophisticated process model assumption: stakeholder interaction is not necessary for requirements gathering © NJCSE Library Overdue Book Notices: Matching User Skills

35. Does system prompt for save upon exiting? If not, librarian may very well forget. Possible Model Clashes Librarian makes one or both of the following assumptions: success model assumption: I can’t afford to ever lose data product model assumption: “save” function should be prompted Developers make one or both of the following assumptions property (environment) model assumption: users are sophisticated process model assumption: stakeholder interaction is not necessary for requirements gathering © NJCSE Library Overdue Book Notices Fail Safe Design

36. Did you add features/functionality to impress the customer? What makes you think they will impress? Have you asked the customer if s/he’s willing to pay the extra cost? Possible Model clash: Librarian makes following assumption: success model assumption: I should be able to learn entire system in an afternoon AND EITHER Customer makes following assumption: success model assumption: I don’t want to be charged for things I didn’t ask for OR Developer makes the following three success model assumptions: I want to maximize profits the more features the more customers the more customers the more profits © NJCSE Library Overdue Book Notices Gold Plating

37. Operations Model` Object Model Capability Requirements System Definition Class Model Project Requirements Statement of Purpose Project Goals Organization Goals System Capabilities Component Model Organization Entities Behavior Model Enterprise model Domain DescriptionSystem AnalysisSystem Design Operational Concept Description (OCD) System and Software Requirements Definition (SSRD) System and Software Architecture Description (SSAD) Organization Background Organization Activities Interaction Model Levels of Service Goals LOS Requirements * Does not include all MBASE models Release Description Reqs. Satisfaction Capability Tests Data Structures Methods/functions LOS Tests Implementation Construction,Transition,Support (CTS) External to MBASE Coverage/Traceability of MBASE Product Models*

38. Org. goals Shared Vision Initial System/ Project Goals Attractive COTS Revised System/ Project Goals -capabilities -Levels of Service Component Model -COTS components -Build Components Effect of COTS on Mapping Process

39. Expectations Shortfalls Condition for successful LCO a. Feasible architecture b. Meets requirements within cost/schedule/resource constraints c. Viable business case d. Equilibrium At USC Projects That Failed LCO Condition 1996: 4 out of 16 fail(25%) 1997: 4 out of 15 (27%)

40. Easy/hard things for software people “If you can do queries with all those ‘ands’, ‘ors’, ‘synonyms’, ‘data ranges, etc.’, it should be easy to do natural language queries.” “If you can scan the document and digitize the text, it should be easy to digitize the figures too.” Easy/hard things for librarians “It was nice that you could add this access feature, but it overly (centralizes, decentralizes) control of our intellectual property rights.” “It was nice that you could extend the system to serve the medical people, but they haven’t agreed to live with our usage guidelines.” Requirements and Expectations: Domain Model Clashes

41. Identify application simplifiers and complicators –For each digital library sub-domain –For both developers and clients Simplifier/Complicator Experiment

42. Example S&C’s 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 20, 31, 32, 35, 36, 37, 39 Type of Application Simple Block DiagramExamplesSimplifiersComplicators Multimedia Archive  Use standard query languages  Use standard or COTS search engine  Uniform media formats  Natural language processing  Automated cataloging or indexing  Digitizing large archives  Digitizing complex or fragile artifacts  Automated annotation/descrip tion/ or meanings to digital assets  Integration of legacy systems MM asset info Catalog MM Archive query MM asset update query update notification  Rapid access to large Archives  Access to heterogeneous media collections

43. Specialized Material

44. SimplifiersRisks and Trade-offs Generic Uniform Media Formats Specific All video clips are stored using an open file format for video/audio (e.g., MPEG). All film stills are stored using an open image file format (e.g., JPEG). The inverse complicator is to store film clips using streaming video technologies This means that we may have to convert existing digital assets or digitize the original media, which may be costly. A unique file format limits the user base to those who have viewers for that particular file format The chosen file format may not be the most efficient for the various types of media (in terms of compression rates, quality, etc...) Generic Use Standard Query Languages Specific Organize catalog and archive relationally so that queries will be limited to standard search formats,: match exactly by value on any of the fields with or without using boolean combinations (AND, OR, NOT, etc...), or using pattern matching (SQL LIKE keyword) May not be as effective for "discovering" assets in the archive: users must know what they're looking for, in order to search for it Generic Use Standard COTS Specific Use a standard Relational Database Management System (RDBMS) that supports storing multi-media assets A Relational Database Management System may not be most suited for archival of multi-media assets. A Relational Database Management System may have a high initial cost, high implementation, and high administration cost (requires specialized knowledge skills)

45. ComplicatorsRisks and Trade-offs Generic Natural Language Processing Specific Store the information only in one language (e.g., English) and provide dynamic translation into Chinese, Japanese and Korean The inverse simplifier is to store the same information in 4 different languages (English, Chinese, Japanese and Korean). The first approach is a complex, error-prone, expensive natural language processing issue The second approach will require more storage space, in addition to acquiring the translations Generic Digitizing Large Archives Specific Digitizing film clips from the entire collection of films (which grows at a very fast rate of 800 films per year for Indian films alone) If each film clip requires around 10 MB, then the rate of growth of the database will be of 8GB a year (exclusive of catalog information) Generic Integration of "Legacy" Systems Specific Do not require Real-Video plug-in for Web browsers to allow users to view streamed film clips We cannot use more effective multi-media formats, which are becoming standard technologies

46. The USC Results Projects That Failed LCO Criteria 1996: 4 out of 16 (25%) 1997: 4 out of 15 (27%) 1998: 1 out of 20 (5%) 1999: 1 out of 22 (4%) Simplifier and Complicator analysis helps -To focus on achievable requirements with tight schedules - To understanding risks and tradeoffs