CHAPTER 6 UNIQUE CONTRIBUTIONS OF THE UNIFIED PROCESS

1. CHAPTER 6UNIQUE CONTRIBUTIONS OF THE UNIFIED PROCESS Materials taken from SDLC 3.0 by Mark Kennaley

2. Introduction • We know that the UP arose from dissatisfaction over risk-laden large, complex projects sometimes measured in millions of dollars. • The UP arose to address risk up front. • Many huge development projects are always underway, and risk mitigation is essential. • Interesting to note that Agile is somewhat quiet on risk; • Lean (next lecture) embraces risk.

3. More Background / Motivation • Many critical examples of not mitigating risk fill the literature. • Not mitigating risk can result in huge software failures resulting in catastrophe and/or death. • Needs to be a concentrated effort to address risk. • Don’t simply let solutions simply evolve. • There are huge fiduciary duties and social, political, business, and legal ramifications of unmitigated risk. • All this points to the arising of ‘risk-value prioritization’ within the UP.

4. Waterfall Delays Risks Walker Royce, 1995 Requirements R I S K Design Code Waterfall risk Integration System Test T I M E 30 4

5. Accelerate Risk Reduction Walker Royce, 1995 R I S K Risk reduction Waterfall risk Iterative Iteration Iteration Iteration Iteration Iteration T I M E 30 5

6. Waterfall – UP on Risks • Waterfall: risk addressed (if at all) very late in the process. • Waterfall integrates and tests (beyond unit testing) late and breakage / recovery is difficult to recover from and large slippages occur. • Remember the ‘big rocks first’ story. • Tough things first. • In the UP, we mitigate risks up front (recognizing that this is a project-long effort…) • Proofof mitigation is to be illustrated via working, tested software – although perhaps incomplete. (may have drivers and stubs for non-essential functionality) • This is what we mean by an ‘executable architecture.,’ • It represents essential or high-stakes software in executable form

7. More on Risk Mitigation • Essential to undertake risk mitigation up front • Do this in iteration 0 –Inception if at all possible, but much too in Elaboration Phase. • For non-complex systems and/or CRUD, time spent on risk can be significantly shortened. • Much of the architecture, normally built during Elaboration Phase, can be relegated to fine-grained architecture rather than coarse-gained architecture for well-understood and well-known functionalities.

8. More on Risk Mitigation, Architecture, and Comparison with Agile - UP Here is where Agile takes the hit. Hit is due to perception Agile is not amenable to large scale efforts or mission-critical projects due to its ‘lack of rigor’ and explicit risk mitigation and knowledge capture for well-known development components. Methods such as Scrum do not have the rigor in their emerging designs. As typical of Agile, the ‘trust me’ often does not suffice for mission-critical applications. Many want to see more rigor and explicit architecture.

9. More on Risk Mitigation, Architecture, and Comparison with Agile - UP Agile talks about technical debt that arises from doing the easy things first. How so? Often arises due to emphasis on early delivery of value at the expense of technical exploratory iterations! So, this makes it difficult to cancel projects later In the UP, with early attention to risk mitigation through addressing key issues, it is easier to cancel a project. In truth there is no visibility into late project failure due to unmitigated risk without early risk-confrontive testing of architecture.

10. Decision-Centric Software Architecture • UP is a use-case driven, architecture centric, iterative development process. But architecture?? • We now feel that architecture is more about mitigating the risks surrounding significant IT investment decisions than with communicating and capturing the knowledge within a solution. • The software architect can be viewed more like an investment manager in that a system’s software architecture is synonymous to a set of significant design decisions that address stakeholder concerns about the quality of service of a solution. • These decisions significantly affect the success of the technology investment.

11. Decision-Centric Software Architecture Many concerns here. We have evolved from visual modeling effort to describe design decisions Architecting is now much more about techniques used to reduce complexity and communicate properly. Architecture is about balancing competing interests from multiple communities of stakeholders and Architecture is about being able to support those decisions on the basis of cost, benefit, and risk. This can become quite theoretical…

12. Decision-Centric Software Architecture Visual Modeling supports decision reasoning because it reduces complexity. Realize that a model consists of views from the perspective of different stakeholders. Visual Modeling is simply one tool used by the architect to understand solutions and to communicate this understanding in a clear way.

13. More on the Decision ApproachesLook at Concrete Assets. We can use our existing assets (structured elements) brought about through ‘realization’ activities. (class diagrams; interaction diagrams) The UP calls these analysis mechanisms. This refers to using some of our design classes (software classes) as building blocks. May put them into packages, subsystems, etc. But use them! If we can leverage existing assets rather than embarking on building or customizing new development certainly lowers the risk. Idea is simply to ‘build less stuff’ if we can. The associated challenge of this development strategy is getting into the degree of fitness-for-purpose of these building blocks.

14. Leveraging Concrete Assets forDecision-centric approaches to Architecture Visual models from prior development efforts can be used to bridge gaps analysis. This is because visual models help us to understand, and we need to fully understand the elements for reuse under consideration. Use case scenario realizations let us efficiently and clearly approach gap analysis. (remember, use case realizations are the static models (class diagrams and associations) and the dynamic models (interaction diagrams) Scenarios represent stimuli through which quality attributes can be exercised. (user stories w/data and acceptance criteria)

15. Leveraging Investment Analysis for decision-centric architural approaches A second approach to Decisions comes from investment analysis. This boils everything down to dollars and how the decisions affect benefits, costs, risks etc, This allows ‘what if’ reasoning. Thinking about architecture as a decision set is like looking at an investmentportfolio. We identify an optimum decision set such that the latest incremental candidatedecisions can be recommended to the stakeholders. Ultimately, tradeoff points exist between concerns and their associated qualityattributes. Then, we have negotiations and facilitation by the architect to mitigate the tendency of stakeholders to locally optimize individual concerns and ensure a focus on the overall mission of the system.

16. Last Comments on Architecture Each decision taken on how to address each ranked stakeholder concern allows us to converge to optimal solutions available. To do this, concerns are weighed in the beginning of architectural reasoning and allowing concerns to be elaborated upon and negotiated in a weighted order, thus allowing for a higher probability of converging to an efficient and stable architecture. Finally, we have an entire solution decision set (architectural stack) or portion of the solution (individual decisions) that are value-added.

17. Nicely, these results can be used as candidates for other project context in the future in the enterprise repositories. Architectural asset management is enhanced and may facilitate visibility into future projects. This then constitutes a broader knowledge management effort relating to IT delivery. At the End…

18. Model Driven Development We must recognize that the Unified Process grew up in the midst of CASE tools: UML, Visual Modeling tools, Rational Rose, etc. Thus very understandable that the UP uses Model Driven Development – and this is not all bad. Idea was to enable a high level of abstraction via modeling – (think 5th generation language) where models evolve into executable code. Not a new idea. Certainly, we’d like to ‘enable’ visual programming’ so that we can contemplate and solve more complex problems easier. Using this approach allows us to put together reusable components and also to easily identify such opportunities.

19. The 4+1 Architectural View End-user Functionality System Integrators Performance Scalability, Concurrency, Throughput, Parallelism… Logical View Functional Reqmts Deals with design, packages, sub- systems, and classes, layers, … Implementation View – deals mostly with programming and organization of the software modules & unit test (More detailed Design and Implements the Design) Logical View Implementation View Functional requirements Analysts/Designers Programmers Software management Structure Use-Case View Process View Deployment View System Engineering System topology Delivery, installation Communication A View is a complete description (an abstraction) of a system from a particular view- point or perspective – covering particular concerns and omitting others not relevant to this perspective. Different ‘views’ from different ‘stakeholders; different concerns. A Model is a complete representation. Models consist of Views.

20. Slide from Kennaley – See book. Notice Analysis to Design Notice stakeholders on various sides of the rendering Notice Use Case Analysis --- Use Case Design Notice Analysis Modeling – small model; analysis class; abstractions… Notice Design Modeling – Use Case Realizations – analysis classes morph (some) to design classes (software classes. Notice logical …. Physical realizations.

21. One more slide from Kennaley This last slide shows relationships among stakeholders. Also shows correlation among the views and the UML diagram types typically leveraged. Can see a model driven development starts with the identification and communication of system value propositions. Given a use case diagram, the viewpoint is on breadth. Here, they use Use Case Surveys – similar to Scrum’s Product Backlog but with no queueing.

22. Model-Driven Development Iterations are planned by selecting instances of use cases to realize or build – not an entire use case. Instances are scenarios and are equivalent to user stories with fully elaborated acceptance tests. Scenarios are dynamic; use case diagrams are static. Through first identifying analysis or what abstractionsvia analysis classes for a scenario (the logical nature of the system), which are technology neutral abstractions. From this:

23. Model-Driven Development From this: We move to deeper realizations of the scenarios where we morph analysis models in the scenario visualization (sequence diagrams) into design patterns such that design or ‘how’ classes (software classes) emerge. The design classes are then ‘realized’ within components behind interfaces based on analysis of coupling, cohesion, and likelihood of change in the physical view.

24. Concluding Remarks on MDD and Controversy MDD arose out of Object-Oriented Analysis and Design from the 1990s A number of techniques were inputted into developing systems that could generate code in C++, Java, and more. Because of this, ‘reverse engineering’ arose, which leveraged the same parser engines of the development of the development environments that enabled what was known as ‘round-trip engineering.’ It was this ability to commit design into code that led to ‘drift’ in filling in the blanks. This was the main reason by MDD received a bad name and why CASE tools were the target in the first agile manifesto via their value: Individuals and Interactions over Processes and Tools.

25. Concluding Remarks on MDD But, the systematic problem solving has received broader acceptance, even within the agile community. Some day we may get there so that these higher level abstraction of classes and patterns can be leveraged to completely manifest (realize) a system. But today, this practice of MDD may be seen as a useful problem solving technique where it may make sense, as in safety critical systems engineering applications.,