This preview shows page 1. Sign up to view the full content.
Unformatted text preview: Put Into Perspective Why Study Best Practices Where are they used? Because these are what industry practitioners recommend Best Practices are used to develop the tools and methodologies practitioners use. 16 1 Practice 2: Manage Requirements
Develop Iteratively Use Component Architectures Manage Requirements Model Visually Verify Quality Control Changes 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...) 19 2 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 Obtaining a complete, exhaustive set of requirements prior to development is impossible! (except for trivial applications) Requirements are dynamic -Expect them to change during software development Change cannot be stopped, but it can be managed!!
3 Definitions: Requirements and Their Management A requirement is a condition or capability to which the system must conform (functional / nonfunctional) Requirements management is a systematic, disciplined approach to Eliciting, organizing, and documenting requirements of a 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
19 Requirements Management ensure requirements converge 4 over time. (What does this mean to you?) 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 Insufficient automation 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
5 19 Practice 3: Use ComponentBased Architectures
Develop Iteratively Manage Use Requirements Component Architectures Model Visually Verify Quality Control Changes Software architecture is 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! Discuss!
6 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.... What is accommodated where. 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, their interfaces, their collaborations, and their composition Architecture is the first part of design addresses questions on HOW the system will be built. Architectural design accommodated early in the process! 7 19 Discuss. Architectural Concerns Software architecture is concerned with structure and behavior and context: Means?? Concerned with "Operational Fit' for end users, and development the `organization' (typically of components) used to build the system. Must address technical issues (what?? ) but is strongly affected by organizational forces. (what??) 19 8 Lead Tracking User Interface Example: ComponentBased Architecture
User Interface Mechanisms Customer Product Licensing User Interface License 19 Key: - Purchased - Built (green) - New Oracle Vantive 9 Problems Addressed by Component Architectures Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Subjective assessment Undetected inconsistencies Poor testing Waterfall development Uncontrolled change Insufficient automation
19 Root Causes 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 componentbased design
10 Solutions 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. We19 use a standard modeling language, UML (Unified Modeling Language). will
11 Practice 4: Visually Model Software Use models 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 (don't put the architecture in a drawer!!) Promote unambiguous communication via standard modeling language, UML Visual modeling improves our ability to manage software complexity
12 UML components; connections dependencies; collaborations... 19 What Is the UML? The Unified Modeling Language (UML) is a language for
Specifying Visualizing Constructing the artifacts of a softwareintensive 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 13 19 Documenting 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
State State State State Diagrams Class Diagrams Class Diagrams Diagrams Diagrams Diagrams Explain:
Activity Activity Diagrams Diagrams Scenario Scenario Scenario Scenario Diagrams Sequence Diagrams Sequence Diagrams Diagrams Diagrams Diagrams Scenario Scenario Scenario Scenario Diagrams Collaboration Diagrams Collaboration Diagrams Diagrams Diagrams Diagrams
19 Use-Case Use-Case Diagrams Diagrams State State State State Diagrams Object Diagrams Object Diagrams Diagrams Diagrams Diagrams State State State State Diagrams State Diagrams State Diagrams Diagrams Diagrams Diagrams Models Deployment Deployment Diagrams Diagrams Component Component Component Diagrams Component Component Diagrams Diagrams Component Diagrams Diagrams Diagrams Models are more inclusive than Views. Know these!!!!! 14 Visual Modeling Using UML Diagrams
FileMgr add( ) delete( ) fetchDoc( ) sortByName( ) Single, common modeling language used throughout Maps the artifacts between business engineering, requirements capture, and analysis, design, and testing. Class Diagram
DocumentList Document name : int doci...
View Full Document
This note was uploaded on 10/04/2011 for the course CEN 6016 taught by Professor Bobroggio during the Fall '11 term at University of South Florida.
- Fall '11