1. PRJ566 Project Planning & Management Software Architecture

2. Systems Development Lifecycle (SDLC)  Projects are developed according to a definite methodology called the SDLC  Three major activities Analysis: understanding business needs Design: conceptualizing computer-system solution Implementation: construction, testing, and installation

3. Systems Development Lifecycle (SDLC) Two additional phases: Project planning Support

4. Aids to Assist in Analysis and Design  Methodologies Comprehensive guidelines to follow for completing every SDLC activity Collection of techniques Examples: Structured, OO  Models Representation of an important aspect of the real world Diagrams and charts Project planning aids

5. Software Architecture

6. Architectural Design  Focuses on the overall structure of the system, the relationships among its major components and their interactions  Is divided into sections or views

7. Models and Views  Models are complete representations of the system: use case models, class diagrams  Architectural views focus only on what is architecturally significant

8. The Architect  The person responsible for the overall structure and design of the system In a small system the architect may serve the role of the analyst and the software designer, Programmer/Analyst Should be the most senior and responsible person on the technical team

9. The Architect  Becomes the owner of the technical vision and his/her understanding of the overall system, coupled with his/her ability to to design a model of the system, is critical to the success of the project

10. The Architecture Document  Designed to establish the overall structure of the entire project by describing various architectural views

11. Architectural Views  A view is a specific perspective or focus. Typically an architectural view is a subset of the entire architecture.

12. Architectural Views  The 4 + 1 View Model developed by Philippe Krutchen The 4 + 1 View Model  The 4 + 1 View Model developed by Philippe Krutchen The 4 + 1 View Model

13. Use Case View  Has precedence over the other views, because the use case view--the collected use cases from the requirements analysis--drives and motivates the rest of the design.

14. Use Case View  It is the job of the architecture and ultimately the implementation to realize the use case requirements  Focus is on the interaction of the classes and how these interactions serve to implement the use cases we analyzed previously

15. Logical View  Represents the organization of the most significant classes and how they relate to one another  The class design is integrated into the logical view, creating an integrated perspective of the entire system

16. Logical View  Most comprehensive architectural view  Incorporates the most significant aspects of all other views  Provides an overview of the entire architecture, and in conjunction with the code itself, provides a guide to the software

17. Process View  Focuses on how, in a system with multithreading or multiple processes, the concurrent tasks interact

18. Copyright © 1997 by Rational Software Corporation The Physical World  Component diagrams illustrate the organizations and dependencies among software components  A component may be A source code component A run time components or An executable component

19. Copyright © 1997 by Rational Software Corporation Course Offering Student Professor Component Diagram Course.dll People.dll Course User Register.exe Billing.exe Billing System

20. Copyright © 1997 by Rational Software Corporation Deploying the System  The deployment diagram shows the configuration of run-time processing elements and the software processes living on them  The deployment diagram visualizes the distribution of components across the enterprise.

21. Deployment View  Focuses on the physical allocation of resources and the allocation of tasks among those resources in a distributed system

22. Copyright © 1997 by Rational Software Corporation Deployment Diagram Registration DatabaseLibraryDormMain Building

23. Implementation View  Embodied in the code with its supporting documentation

24. How are architectural goals to be achieved?  Model software objects after problem domain objects  Build software systems like hardware systems, i.e. more pluggable  View programming as assembling parts

25. How are architectural goals to be achieved?  Build new software parts by extension  “Grow” software systems through iterative development  Achieve large-grain interoperability across heterogeneous systems and networks

26. Iteration Across Life Cycle Phases

27. The Spiral Life Cycle Model Phases can be broken into smaller pieces, each with a different type of risk

28. Copyright © 1997 by Rational Software Corporation InceptionElaborationConstructionTransition Iteration 1Iteration 2Iteration 3 Iteration Planning Rqmts Capture Analysis & Design Implementation Test Prepare Release “Mini-Waterfall” Process Use Cases Drive the Iteration Process

29. Copyright © 1997 by Rational Software Corporation Work Allocation Within an Iteration  Work to be accomplished within an iteration is determined by The (new) use cases to be implemented The rework to be done  Packages make convenient work packages for developers High-level packages can be assigned to teams Lower-level packages can be assigned to individual developers  Use Cases make convenient work packages for test and assessment teams

30. Copyright © 1997 by Rational Software Corporation The Iteration Life Cycle: A Mini-Waterfall Results of previous iterations Up-to-date risk assessment Controlled libraries of models, code, and tests Release description Updated risk assessment Controlled libraries Iteration Planning Requirements Capture Analysis & Design Implementation Test Prepare Release Selected scenarios

31. Copyright © 1997 by Rational Software Corporation Detailed Iteration Life Cycle Activities  Analysis & Design Determine the classes to be developed or updated in this iteration Update the object model to reflect additional design classes and associations discovered Update the architecture document if needed Begin development of test procedures  Implementation Automatically generate code from the design model Manually generate code for operations Complete test procedures Conduct unit and integration tests

32. Copyright © 1997 by Rational Software Corporation Detailed Iteration Life Cycle Activities  Test Integrate and test the developed code with the rest of the system (previous releases) Capture and review test results Evaluate test results relative to the evaluation criteria Conduct an iteration assessment  Prepare the release description Synchronize code and design models Place products of the iteration in controlled libraries

33. Copyright © 1997 by Rational Software Corporation Iteration Assessment  Assess iteration results relative to the evaluation criteria established during iteration planning: Functionality Performance Capacity Quality measures  Consider external changes that have occurred during this iteration For example, changes to requirements, user needs, competitor’s plans  Determine what rework, if any, is required and assign it to the remaining iterations

34. Copyright © 1997 by Rational Software Corporation Initial Project Risks Initial Project Scope Revise Overall Project Plan Cost Schedule Scope/Content Plan Iteration N Cost Schedule Assess Iteration N Risks Eliminated Revise Project Risks Reprioritize Develop Iteration N Collect cost and quality metrics Define scenarios to address highest risks Iteration N Risk Reduction Drives Iterations

35. Copyright © 1997 by Rational Software Corporation Three Important Features of the Iterative Approach  Continuous integration Not done in one lump near the delivery date  Frequent, executable releases Some internal; some delivered  Attack risks through demonstrable progress Progress measured in products, not documentation or engineering estimates

36. Copyright © 1997 by Rational Software Corporation Resulting Benefits  Releases are a forcing function that drives the development team to closure at regular intervals Cannot have the “90% done with 90% remaining” phenomenon  Can incorporate problems/issues/changes into future iterations rather than disrupting ongoing production  The project’s supporting elements (testers, writers, toolsmiths, CM, QA, etc.) can better schedule their work