Practice 2 Manage Requirements Develop Iteratively Manage Requirements

Practice 2: Manage Requirements Develop Iteratively Manage Requirements Use Component Architectures Model Visually Verify Quality Control Changes A report by Standish Group cites forty percent of software projects fail. This failure is attributed to: poor requirements management; ((eliciting) capturing, (documenting) modeling, verification; prototyping; agreeing w/customer on how changes will be handled, . . . ) incorrect definition of requirements from the start of the project; and (feedback, verification…) poor requirements management throughout the development lifecycle. (handling Change!!!) (Source: Chaos Report, http: //www. standishgroup. com). Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 1

Practice 2: Manage Requirements w Elicit, organize, and document required functionality and constraints w Evaluate changes and determine their impact w Track and document tradeoffs and decisions w Getting comprehensive system requirements is a continuous process! Obtaining a complete, exhaustive set Requirements are dynamic -of requirements prior to development is impossible! Expect them to change during software development Change cannot be stopped, but it can be managed!! Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 2

Definitions: Requirements and Their Management w A requirement is a condition or capability to which the system must conform w Requirements management is a systematic approach to § Eliciting, organizing, and documenting the requirements of the system, and § Establishing and maintaining agreement between the customer/user and the project team on the changing requirements of the system w Requirements specify ‘what’ the system must do not how! w Requirements Management will be successful only if it allows for uncertainty early in development w Requirements Management must ensure Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 3

How To Catch Requirements Errors Early w Effectively analyze the problem and elicit user needs w Gain agreement with the customer/user on the requirements w Model interaction between the user and the system w Establish a baseline and change control process w Maintain forward and backward traceability of requirements w Use an iterative process w Create a ‘sharable’ model with customers w For a given iteration, all requirements need not be known; however, before developing that Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 6

Problems Addressed by Requirements Management Root Causes þ Insufficient requirements þ Ambiguous communications ¨ Brittle architectures þ Overwhelming complexity þ Subjective assessment þ Undetected inconsistencies þ Poor testing ¨ Waterfall development ¨ Uncontrolled change Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 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 7 RM tool provides a repository for requirements,

Practice 3: Use Component-Based Architectures Develop Iteratively Model Visually Manage Use Requirements Component Architectures Verify Quality Control Changes SOFTWARE ARCHITECTURE IS A MUCH MISUNDERSTOOD DISCIPLINE BY THE SOFTWARE INDUSTRY. SOME SAY THAT SOFTWARE ARCHITETCTURE IS THE DEVELOPMENT PRODUCT THAT YIELDS THE GREATEST ROI WITH RESPECT TO QUALITY, SCHEDULE, AND COST… Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 8

Software Architecture Defined w Software architecture encompasses significant decisions about the organization of a software system. § Selection of the structural elements and their interfaces by which a system is composed (packages, subsystems, …) • • Addresses how the application will be built…. For the most part, it is part of ‘Design. ’ Behavior as specified in collaborations among those elements Composition of these structural and behavioral elements into progressively larger subsystems § Architectural style that 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. § Example of architectural concern: integration. • How will database B work with platform A, etc. w Very important artifact in an incremental development approach! Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 9

Resilient, Component-Based Architectures w Good architectures meet their requirements, are resilient, and are component-based w 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 w A component-based architecture permits § Reuse or customization of existing components § Choice of thousands of commercially available components § Incremental evolution of existing software Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 11

Problems Addressed by Component Architectures Root Causes ¨ Insufficient requirements ¨ Ambiguous communications þ Brittle architectures þ Overwhelming complexity ¨ Subjective assessment ¨ Undetected inconsistencies ¨ Poor testing ¨ Waterfall development þ Uncontrolled change Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved Solutions 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 13

Practice 4: Visually Model Software Develop Iteratively Manage Requirements Use Component Architectures Model Visually Verify Quality Control Changes 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). Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 14

Practice 4: Visually Model Software w Capture the structure (static) and behavior (dynamic) of architectures and components w Show the elements of the system fit together and collaborate to provide functionality w Hide or expose details as appropriate for the task § Implies a hierarchy w Maintain consistency between a design and its implementation w Promote unambiguous communication Visual modeling improves our ability to manage software complexity Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 15

What Is the UML? w 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 Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 16

Diagrams Are Views of a Model A model is a complete description of a system from a particular perspective 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: Activity Diagrams Scenario Diagrams Sequence Diagrams Scenario Diagrams Collaboration Diagrams Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved State Diagrams Class Diagrams use-case Diagrams State Diagrams Object Diagrams State Diagrams Models Deployment Diagrams 17 Component Diagrams Know these!!!!!

Visual Modeling Using UML Diagrams Single, common modeling language used throughout Maps the artifacts between business engineering, requirements capture, and analysis, design, and testing. Use-Case Diagram Class Diagram State Diagram use case 1 Actor A Actor B use case 2 Domain Expert <<entity>> Customer name addr receive() withdraw() fetch() send() use case 3 UI Deployment Diagram Class MFC Document. App ºÐ» ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® À©µµ¿ì NT: ÀÀ¿ë¼ ¹ö À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼ ¹ö ¹× µ¥ÀÌŸ ¼ ¹ö, Åë½Å ¼ ¹ö IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼ ¹ö, Åë½Å ¼ ¹ö Rogue. Wave Repository Persistence 9: sort. By. Name ( ) Document. List Windows 95 global User Interface Definition File. Manager main. Wnd : Main. Wnd 1: Doc view request ( ) ¹®¼ °ü¸® Ŭ¶óÀ̾ðÆ®. EXE L 2: fetch. Doc( ) g. File : Grp. File 4: create ( ) 8: fill. File ( ) user : » ç¿ëÀÚ file. Mgr : File. Mgr Package Diagram ¹®¼ °ü¸® ¾ÖÇø´ Windows NT Document Solaris ¹®¼ °ü¸® ¿£Áø. EXE Alpha UNIX ÀÀ¿ë¼ ¹ö. EXE Windows NT Graphic. File 3: create ( ) File IBM Mainframe File. List 6: fill. Document ( ) µ¥ÀÌŸº£À̽º¼ ¹ö 7: read. File ( ) 5: read. Doc ( ) document : Document repository : Repository Collaboration Diagram main. Wnd file. Mgr : File. Mgr user ƯÁ¤¹®¼ ¿¡ ´ëÇÑ º¸±â¸¦ » ç¿ëÀÚ°¡ ¿äû ÇÑ´Ù. document : Document g. File Component Diagram Forward Engineering (Code Generation) and Reverse Engineering repository Source Code edit, compile, debug, link 1: Doc view request ( ) 2: fetch. Doc( ) 3: create ( ) 4: create ( ) 5: read. Doc ( ) È ÀÏ°ü¸®ÀÚ´ ÀÐ¾î¿ ¹®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼ °´Ã¼¿¡ ¼³Á¤À» ¿äû ÇÑ´Ù. 6: fill. Document ( ) 7: read. File ( ) 8: fill. File ( ) È ¸é °´Ã¼´ ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È ¸é¿¡ º¸¿©ÁØ´Ù. 9: sort. By. Name ( ) Sequence Diagram Executable System Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 18

Visual Modeling and Iterative Development initial requirements risk targeting requirements analysis & design assessment implementation & testing deployment Changes to Design? Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 19

Visual Modeling and Iterative Development initial requirements risk targeting requirements analysis & design assessment implementation & testing deployment What Changed? Are These Changes Acceptable? Reassessment per Iteration? Kill or Press on! Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 20

Problems Addressed by Visual Modeling Will use Rational Rose for creation / maintenance of these UML diagrams and use cases Solutions Root Causes þ Insufficient requirements þ Ambiguous communications þ Brittle architectures þ Overwhelming complexity ¨ Subjective assessment þ Undetected inconsistencies þ Poor testing ¨ Waterfall development ¨ Uncontrolled change Unified Software Practices v 5. 0 D Copyright Ó 1998 Rational Software, all rights reserved 21 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