1. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 43 Introduction to Software Engineering Lecture 5 Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

2. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 2 Reminder: From programming to software engineering People – who else would do the work? – range from novice to very experienced Processes – to organize and manage the efforts of individuals – range from informal to very formal Tools – to support the people and the processes – range from simple to very advanced

3. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 3 Reminder: Processes Essential to achieve a quality product Scarce resource – quality – suitability – cost Many different kinds of processes – bug tracking – change approval – quality assurance Instructor Reminder: Play first “process” video: http://www.pomodorotechnique.com

4. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 4 High Cost

5. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 5 Cost of Change Progressively Higher

6. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 6 More Reminders Essential qualities – Complexity – Conformity – Changeability – Intangibility Potentially drastic or disastrous consequences

7. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 7 Processes as a Remedy software is engineered via a defined process – Cover all steps from initial idea and requirements to delivery, maintenance, and final retirement – Make sure we do the right things/we do things right – Make sure we do not forget to do anything – Different processes for different kinds of software Not a silver bullet [Brooks “No Silver Bullet”] – Software is still intrinsically difficult to deal with – Processes help, but cannot guarantee anything Remember: People + Processes + Tools  Product

8. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 8 Processes Elements – Activities (“Phases”) – Artifacts Can include process specifications – Resources People (their time and their cost) Tools (their time and their cost) Relationships between the elements – Precedence, requires, provides, refines to, … Constraints – Time – Cost – Qualities (repeatable process?)

9. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 9 Software Life Cycle Models Build-and-fix Waterfall Rapid prototyping Incremental Synchronize-and-stabilize Spiral Rational Unified Process (RUP) Open Source Software (OSS) Extreme Programming (XP) Agile A software life cycle model is a high-level process

10. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 10 Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

11. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 11 Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

12. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 12 Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

13. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 13 Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

14. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 14 Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

15. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 15 Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

16. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 16 Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

17. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 17 Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

18. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 18 Build-and-Fix Build first version Modify until client is satisfied Operations mode Retirement Development Maintenance

19. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 19 So… What is it good for? (strengths) What is it bad for? (weaknesses) What’s the (big) deal?

20. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 20 Waterfall First documented by Royce in 1970 (!) Has withstood the test of time – Still being used worldwide… – But not without problems…

21. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 21 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

22. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 22 Waterfall Has clear benefits/strengths – “Forced” discipline Stepwise progression through well-defined phases Documentation-driven at each phase Each phase ends with Testing/Quality Assurance – Validation, verification, and the ability to correct – Feedback loops During product development Post-delivery maintenance So… – What seems to be the problem(s)?

23. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 23 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

24. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 24 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

25. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 25 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

26. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 26 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

27. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 27 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

28. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 28 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

29. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 29 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

30. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 30 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

31. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 31 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

32. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 32 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

33. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 33 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

34. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 34 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

35. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 35 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

36. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 36 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

37. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 37 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

38. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 38 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

39. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 39 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

40. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 40 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

41. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 41 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

42. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 42 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

43. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 43 Waterfall Operations mode Retirement Requirements phase Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

44. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 44 So… What is it good for? (strengths) What is it bad for? (weaknesses) What’s the (big) deal? Instructor Reminder: Play second Process video: Nordstrom Innovation Lab “sunglasses”

45. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 45 Rapid Prototyping Operations mode Retirement Build and discard simple prototype Verify Specification phase Verify Design phase Verify Implementation phase Test Integration phase Test Changed requirements Verify Development Maintenance

46. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 46 FOR EACH BUILD Perform detailed design, implementation, and integration. Test. Deliver to client. Incremental Operations mode Retirement Requirements phase Verify Specification phase Verify Architectural design Verify Development Maintenance

47. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 47 Synchronize-and-Stabilize System developed by multiple teams – Teams work in parallel – On individual application modules – Frequently sync code with other teams – Frequently test/debug/stabilize code throughout development Easier to accommodate change at any point in the process

48. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 48 Synchronize-and-Stabilize Specifications Implementation, Integration Deliver to client (version 1) SpecificationsDesign Implementation, Integration Deliver to client (version 2) SpecificationsDesign Implementation, Integration Deliver to client (version 3) SpecificationsDesign Implementation, Integration Deliver to client (version n).................. Specification teamDesign teamImplementation/integration team Design

49. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 49 Synchronize-and-Stabilize Specifications Implementation, Integration Deliver to client (version 1) SpecificationsDesign Implementation, Integration Deliver to client (version 2) SpecificationsDesign Implementation, Integration Deliver to client (version 3) SpecificationsDesign Implementation, Integration Deliver to client (version n).................. Specification teamDesign teamImplementation/integration team Design

50. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 50 Synchronize-and-Stabilize Specifications Implementation, Integration Deliver to client (version 1) SpecificationsDesign Implementation, Integration Deliver to client (version 2) SpecificationsDesign Implementation, Integration Deliver to client (version 3) SpecificationsDesign Implementation, Integration Deliver to client (version n).................. Specification teamDesign teamImplementation/integration team Design

51. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 51 Synchronize-and-Stabilize Specifications Implementation, Integration Deliver to client version 1 SpecificationsDesign Implementation, Integration Deliver to client version 2 SpecificationsDesign Implementation, Integration Deliver to client version 3 SpecificationsDesign Implementation, Integration Deliver to client version n.................. Specification teamDesign teamImplementation/integration team Design

52. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 52 Synchronize-and-Stabilize Specifications Implementation, Integration Deliver to client version 1 SpecificationsDesign Implementation, Integration Deliver to client version 2 SpecificationsDesign Implementation, Integration Deliver to client version 3 SpecificationsDesign Implementation, Integration Deliver to client version n.................. Specification teamDesign teamImplementation/integration team Design

53. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 53 Synchronize-and-Stabilize Specifications Implementation, Integration Deliver to client version 1 SpecificationsDesign Implementation, Integration Deliver to client version 2 SpecificationsDesign Implementation, Integration Deliver to client version 3 SpecificationsDesign Implementation, Integration Deliver to client version n.................. Specification teamDesign teamImplementation/integration team Design

54. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 54 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

55. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 55 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

56. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 56 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

57. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 57 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

58. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 58 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

59. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 59 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

60. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 60 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

61. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 61 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

62. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 62 Spiral Risk analysis Risk analysis Risk analysis Risk analysis Rapid prototype Specification Design Implementation Verify

63. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 63 Full Spiral

64. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 64 So… What is it good for? (strengths) What is it bad for? (weaknesses) What’s the (big) deal? What is meant by risk-driven? What are examples of risk? Why is it so important?

65. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 65 Rational Unified Process Rational Unified Process (RUP) – Influential, best practices of its time (1990s, Object-Oriented SE) – More realistic depiction of the Non-discrete nature of SE The need to have flexibility/adaptability in the process itself The interplay of – Processes – Time – Various SE activities over time Much more… – Workflows, Activities, Artifacts, Workers… – Makes more sense if you are an experiences developer, project manager…

66. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 66 The RUP Model Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Phases Process Workflows Iterations Supporting Workflows Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements ElaborationTransitionInceptionConstruction Workflows group activities logically In an iteration, you walk through all workflows

67. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 67 RUP Workflow: Architectural Analysis

68. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 68 RUP Activity: Use Case Analysis

69. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 69 The steps of use-case-analysis

70. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 70 So… What is it good for? (strengths) What is it bad for? (weaknesses) What’s the (big) deal?

71. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 71 Open-Source Software (OSS) Only two, informal, phases First, develop the initial version – Usually one or a small number of developers Second, maintain (evolve!) – Users become co-developers (co-maintainers!) – Report and correct defects Corrective maintenance – Enhance and add new functionality Perfective maintenance – Port to a different environment Adaptive maintenance

72. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 72 OSS Success Stories Operating system – Linux, others? Web browser – Firefox, others? Compiler – Such as gcc, others? Web server – Apache, others? Database – MySQL, others? Healthcare – Mirth, others?

73. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 73 So… What is it good for? (strengths) What is it bad for? (weaknesses) What’s the (big) deal?

74. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 74 Extreme Programming (XP) More “extreme” reaction to Waterfall, other heavyweights… Kent Beck – Listening, Testing, Coding, Designing Ron Jeffries – Based on Values of Simplicity, Communication, Feedback, Courage – Works by Simple practices, such as bringing/keeping the team together Just enough feedback to know where you are Just enough (and just in time) “heavier” activities More “programmer welfare” than other process models…

75. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 75 XP Practices Whole team Planning game Small releases Customer tests Simple design Pair programming Test-driven development Design improvement Continuous integration Collective code ownership Coding standards Metaphor Sustainable pace

76. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 76

77. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 77 XP Process Steps Determine the desired features (stories) – Estimate time/cost (effort) per feature – Client can help determine order of development Story prioritization Stories further refined into development tasks Implement/deliver each task – Typically using… Test-driven development Pair programming Follow values and principles – Lots of open space, especially for pair programming – A client rep onsite, working with the XP team – All team members work on all development activities

78. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 78 From XP to Agile Agile includes and evolved from – Extreme Programming – SCRUM, Crystal, others The Agile Manifesto (2001) – “We have come to value…” – Individuals and interactions Over processes and tools – Working software Over comprehensive documentation – Customer collaboration Over contract negotiation – Responding to change Over following a plan

79. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 79 Some Agile Principles Satisfy the customer – Through early and continuous delivery of valuable software Welcome change in requirements – Even late in development – Harness change for competitive advantage Deliver working software frequently – In weeks or a couple of months Timeboxing Sprints

80. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 80 More Agile Principles Business people and developers work together daily throughout the project – Stand-up meetings Build projects around motivated individuals – Give them the environment and support they need Best method of conveying information during development is face-to-face conversation – Stand-up meetings

81. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 81 So… What is it good for? (strengths) What is it bad for? (weaknesses) What’s the (big) deal? Instructor Reminder: Play the third Process video: A day in the life (of a SCRUM team)

82. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 82 A Comparison of Life Cycle Models ModelStrengthsWeaknesses Build-and-FixFine for small programs that do not require much maintenance Totally unsatisfactorily for nontrivial programs WaterfallDisciplined approach Document driven Delivered product may not meet client’s needs Rapid Prototyping Ensures that delivered product meets client’s needs A need to build twice Cannot always be used IncrementalMaximizes early return on investment Promotes maintainability Requires open architecture May degenerate into build-and-fix Synchronize- and-stabilize Future user’s needs are met Ensures components can be successfully integrated Has not been widely used other than in Microsoft SpiralIncorporates features of all the above models Can be used only for large-scale products Developers have to be competent at risk- analysis