2. 19 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. 19 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, throughout life cycle) (handling Change!! Addressing Risk) Incorrect Definition of Requirements from the start of the project; and (feedback, verification…) (Source: Chaos Report, http://www.standishgroup.com).

4. 19 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. 19 4 Definitions: Requirements and Their Management ►  A requirement is a condition or capability to which the system must conform (functional / non-functional) ►  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. 19 5 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 starting a specific iteration, those requirements must be fully known.

7. 19 6 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

8. 19 7 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!

9. 19 8 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, …) ► For applications: maybe layered architectures or pipe-filter or client-server ► For programs: w/OOP: UML diagrams; procedural: structure charts.  Architectural style guides this organization, these elements and their interfaces, their collaborations, and omposition  Architecture is the key part of design – addresses questions on HOW the system will be built.  (Really, ‘first’ part of design…)

10. 19 9 Architectural Concerns ► Software architecture is concerned with structure and behavior and context:  Structure? relationships between parts  Behaviors? Services / facilities provided. ► Concerned with “Operational Fit’ for end users, and development – the ‘organization’ (typically of components) used to build the system. ► Certainly architectural concerns address technical issues ► But architecture is strongly affected by organizational forces.

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

12. 19 11 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

13. 19 12 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).

14. 19 13 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  Maintain consistency between a design and implementation  Promote unambiguous communication via standard modeling language, UML

15. 19 14 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 a ‘notation.’ 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

16. 19 15 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!!!!! In the Unified Process, 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: Models are more inclusive than Views.

17. 19 16 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.

18. 19 17 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