2. 1 Continuing Best Practices ► Slide information taken in large part from former Rational Corporation slides and the RUP textbook - considerably modified and supplemented for classroom use. ► Additional information taken from other sources.

3. 2 Practice 2: Manage Requirements Control Changes Develop Iteratively Use Component Architectures ManageRequirements Verify Quality A report by Standish Group cites forty percent of software projects fail. According to them, the mail causes of failure are: (note: there are others…) Poor Requirements Management; (eliciting, capturing, documenting, modeling, verification; prototyping…) Incorrect Definition of Requirements from the start of the project; and (feedback, verification…) Poor Requirements Management throughout the development lifecycle. (handling Change!!! Addressing Risk) (Source: Chaos Report, http://www.standishgroup.com).

4. 3 Requirements are dynamic -- Expect them to change during software development Change cannot be stopped, but it can be managed!! Practice 2: Manage Requirements ► Elicit, organize, and document required functionality and constraints ► Evaluate changes and determine impacts ► Track and document tradeoffs and decisions ►  Getting comprehensive system requirements is a continuous process requirements is a continuous process ►  Obtaining a complete, exhaustive set of requirements prior to development is impossible! (except for trivial applications)

5. 4 Definitions: Requirements and Their Management ► A requirement is a condition or capability to which the system must conform ► Requirements management is a systematic approach to  Eliciting, organizing, and documenting the requirements of the system, &  Establishing and maintaining agreement between the customer/user and the project team on the changing requirements of the system ► Requirements specify ‘what’ the system must do - not how! ► Requirements Management will be successful only if it allows for uncertainty early in development ► Requirements Management must ensure requirements coverage over time. (What does this mean to you?)

6. 5 Requirements Trace To Many Project Elements Capturing/Modeling requirements is essential to all other development activities Tells designers what capabilities the software must have Tells testers what tests to construct and test. Provides baselines and version control as change ripples through ALL

7. 6 How To Catch Requirements Errors Early ► Effectively analyze the problem and elicit user needs ► Gain agreement with customer/user on the requirements ► Model interaction between the user and the system ► Establish a baseline and change control process ► Maintain forward and backward traceability of requirements ► Use an iterative development process ► Create a ‘sharable’ model with customers ► All requirements need not be known up front; however, before developing a specific iteration, those requirements must be fully known.

8. 7 Problems Addressed by Requirements Management Root Causes Solutions A disciplined approach is built into requirements management Communications are based on defined requirements Requirements can be prioritized, filtered, and traced Objective assessment of functionality and performance Inconsistencies are more easily detected RM tool provides a repository for requirements, attributes and tracing, with automatic links to documents  Insufficient requirements  Ambiguous communications  Brittle architectures  Overwhelming complexity  Subjective assessment  Undetected inconsistencies  Poor testing  Waterfall development  Uncontrolled change  Insufficient automation

9. 8 UseComponentArchitectures Practice 3: Use Component-Based Architectures Control Changes Develop Iteratively Manage Requirements Verify Quality Software architecture is a much misunderstood discipline by the industry Some say that software architecture is the development product that yields the greatest ROI with respect to quality, schedule, and cost… I wholeheartedly AGREE!

10. 9 Software Architecture Defined ► Software architecture addresses major decisions about the organization of a software system.  Deals with identification of the structural elements and their interfaces by which a system is composed (packages, subsystems, …) ► Addresses how the application will be built…. ► Behavior as specified in collaborations among those elements ► Composition of these structural and behavioral elements into progressively larger subsystems  Architectural style guides this organization, these elements and their interfaces, their collaborations, and their composition  Architecture is part of design – addresses questions on HOW the system will be built. (really, ‘first’ part of design…)

11. 10 Architectural Concerns ► Software architecture is concerned with structure and behavior and context: ► Concerned with “Operational Fit’ for end users, and development – the ‘organization’ used to build the system. ► Must address technical issues but is strongly affected by organizational forces.

12. 11 Resilient, Component-Based Architectures ► Good architectures meet their requirements, are resilient, and are component-based  such as your interface; database access; middleware… ► A resilient architecture enables  Improved maintainability and extensibility  Economically-significant reuse  Clean division of work among teams of developers  Encapsulation of hardware and system dependencies ► A component-based architecture permits  Reuse or customization of existing components  Choice of thousands of commercially-available components  Incremental evolution of existing software

13. 12 Example: Component-Based Architecture Key: - Purchased - Built - New User Interface Mechanisms OracleVantive CustomerProduct Lead Tracking User Interface License Licensing User Interface

14. 13 Problems Addressed by Component Architectures Components facilitate resilient architectures Reuse of commercially available components and frameworks is facilitated Modularity enables separation of concerns Components provide a natural basis for configuration management Visual modeling tools provide automation for component-based design Root Causes Solutions  Insufficient requirements  Ambiguous communications  Brittle architectures  Overwhelming complexity  Subjective assessment  Undetected inconsistencies  Poor testing  Waterfall development  Uncontrolled change  Insufficient automation

15. 14 Practice 4: Visually Model Software Control Changes Develop Iteratively Use Component Architectures Manage Requirements Verify Quality ModelVisually A Model is a simplification of reality that produces a complete description of something from a specific perspective. We build models when we cannot fully comprehend the complexity of some things. Modeling helps the development team visualize, specify, construct, and document the structure and behavior of a system’s architecture. We will use a standard modeling language, UML (Unified Modeling Language).

16. 15 Visual modeling improves our ability to manage software complexity Practice 4: Visually Model Software ► Use to:  Capture (model) both the structure (static) and behavior (dynamic) of architectures and components  Show how the elements of system fit together and collaborate to provide functionality (dependencies, etc.)  Hide / expose details as appropriate for the task - Implies a hierarchy (helps greatly when dealing with complexity…)  Maintain consistency between a design and its implementation  Promote unambiguous communication via standard modeling language, UML

17. 16 What Is the UML? ► The Unified Modeling Language (UML) is a language for ► Specifying ► Visualizing ► Constructing ► Documenting the artifacts of a software-intensive system UML is an industry standard and is platform independent! It defines a graphical modeling language for presenting models and defines the semantics for each graphical element from different perspectives

18. 17 Diagrams Are Views of a Model A model is a complete description of a system from a particular perspective Deployment Diagrams Deployment Diagrams Use-Case Diagrams Use-Case Diagrams Scenario Diagrams Scenario Diagrams Scenario Diagrams Scenario Diagrams Sequence Diagrams Sequence Diagrams State Diagrams State Diagrams State Diagrams State Diagrams State Diagrams State Diagrams Component Diagrams Component Diagrams Component Diagrams Component Diagrams Component Diagrams Component Diagrams Models State Diagrams State Diagrams State Diagrams State Diagrams Object Diagrams Object Diagrams Scenario Diagrams Scenario Diagrams Scenario Diagrams Scenario Diagrams Collaboration Diagrams Collaboration Diagrams Activity Diagrams Activity Diagrams State Diagrams State Diagrams State Diagrams State Diagrams Class Diagrams Class Diagrams Know these!!!!! We use UML to provide nine different diagrams and five (4+1) major views: Use Case View, Logical View, Process View, Implementation View, and Deployment View Explain:

19. 18 Visual Modeling Using UML Diagrams Actor A use-case 1 use-case 2 Actor B user : »ç¿ëÀÚ mainWnd : MainWnd fileMgr : FileMgr repository : Repository document : Document gFile : GrpFile 9: sortByName ( ) L 1: Doc view request ( ) 2: fetchDoc( ) 5: readDoc ( ) 7: readFile ( ) 3: create ( ) 6: fillDocument ( ) 4: create ( ) 8: fillFile ( ) UI MFC RogueWave global DocumentApp Persistence Window95 ¹®¼­°ü¸® Ŭ¶óÀ̾ðÆ®.EXE Windows NT ¹®¼­°ü¸® ¿£Áø.EXE Windows NT Windows95 Solaris ÀÀ¿ë¼­¹ö.EXE Alpha UNIX IBM Mainframe µ¥ÀÌŸº£À̽º¼­¹ö Windows95 ¹®¼­°ü¸® ¾ÖÇø´ ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ - À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼­¹ö - À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼­¹ö ¹× µ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö Document FileManager GraphicFile File Repository DocumentList FileList user mainWndfileMgr : FileMgr repositorydocument : Document gFile 1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( ) 6: fillDocument ( ) 7: readFile ( ) 8: fillFile ( ) 9: sortByName ( ) ƯÁ¤¹®¼­¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù. È­ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼­ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼­ °´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù. È­¸é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡ º¸¿©ÁØ´Ù. Customer name addr withdraw() fetch() send() receive() > Forward Engineering (Code Generation) and Reverse Engineering Executable System User Interface Definition Domain Expert use-case 3 Source Code edit, compile, debug, link Use-Case DiagramClass Diagram Collaboration Diagram Sequence Diagram Component Diagram State Diagram Package Diagram Deployment Diagram Class Single, common modeling language used throughout Maps the artifacts between business engineering, requirements capture, and analysis, design, and testing.

20. 19 Problems Addressed by Visual Modeling use-cases and scenarios unambiguously specify behavior Models capture software designs unambiguously Non-modular or inflexible architectures are exposed Unnecessary detail hidden when appropriate Unambiguous designs reveal inconsistencies more readily Application quality starts with good design Visual modeling tools provide support for UML modeling Root Causes Solutions  Insufficient requirements  Ambiguous communications  Brittle architectures  Overwhelming complexity  Subjective assessment  Undetected inconsistencies  Poor testing  Waterfall development  Uncontrolled change  Insufficient automation