1 / 30

Rational Unified Process Fundamentals Module 4: Disciplines II

Rational Unified Process Fundamentals Module 4: Disciplines II. Objectives. Understand discipline concepts for: Analysis & Design Test Implementation Deployment Configuration & Change Management. Disciplines. Discipline: Analysis & Design. Purpose:

branxton
Download Presentation

Rational Unified Process Fundamentals Module 4: Disciplines II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rational Unified Process FundamentalsModule 4: Disciplines II

  2. Objectives • Understand discipline concepts for: • Analysis & Design • Test • Implementation • Deployment • Configuration & Change Management

  3. Disciplines

  4. Discipline: Analysis & Design • Purpose: • To transform the requirements into a design of the system-to-be • To evolve a robust architecture for the system • To adapt the design to match the non-functional requirements and the implementation environment • Design is a refinement of analysis • Primary artifact is Design Model

  5. The Design Model Artifact: • Consists of a collection of models that collaborate to describe the structure and behavior of the system. • Is an object model describing the realization of use cases. • Serves as an abstraction of the implementation model and its source code. • Is used as essential input to activities in implementation and test.

  6. Use-Case Model Analysis and Design Architecture Document Data Model Use Cases Drive Analysis & Design Analysis Model (optional) Design Model Supplementary Specifications

  7. Analysis & Design Considerations • Transform requirements into classes and subsystems • Adhere to constraints of • Nonfunctional requirements • Implementation environment • Design the database • Mapping the design model to a data model • Identify components • Subsystems and interfaces

  8. Use Case (Use-Case Model) Use-Case Realization (Design Model) Use-Case Realization in Analysis & Design <<realizes>> Sequence Diagrams Use Case Collaboration Diagrams Class Diagrams

  9. Use-Case Analysis & Design • The complete behavior of a use case is allocated to collaborating classes

  10. <<boundary>> CourseCatalogSystem // get course offerings() Sample UML Class Diagram A University Course Registration System <<boundary>> <<boundary>> MaintainScheduleForm MainForm 0..1 1 1 // select maintain schedule() + // open() + // select 4 primary and 2 alternate offerings() 1 1 <<control>> 1 0..* RegistrationController // add courses to schedule() // get course offerings () 0..1 1 <<entity>> Schedule // create with offerings()

  11. Purposes of Architecture • Intellectual control • Basis for reuse • Basis for project management

  12. Architecture: Intellectual Control • Architecture is used for different things by various stakeholders • Customer: visualize what they are buying • Project manager: scheduling and resource allocation • System analyst: organize requirements • Developer: understand boundaries of their chunk of the project • Software architect: reason about evolution or reuse • Multidimensional reality (i.e. multiple views) • Multiple views: functional, implementation, dynamic, structural, spatial (physical distribution), etc.

  13. End-user Functionality LogicalView Implementation View Analysts/Designers Structure Programmers Software management Use-Case View Process View Deployment View System engineering System integrators System topology Delivery, installation communication Performance Scalability Throughput Conceptual Physical Intellectual Control: Architecture Views

  14. Architecture: Basis for Reuse • The structural elements and interfaces which compose the system • The behavior seen in the collaboration of these elements • The composition of these elements into progressively larger subsystems

  15. Architecturally Significant Elements • Not all design is architecture • Main business classes • Important mechanisms • Processors and processes • Layers and subsystems • Architectural views = slices through models

  16. Architecture: Basis for Project Management • Architecture Milestone in Elaboration phase is the Lifecyle Architecture milestone • Architecture primarily results from Analysis & Design • Architecture in phases and iterations: • It drives the risk mitigation of iterations • Architecture baseline is an exit criterion for Elaboration

  17. Discipline: Test • Purpose: Testing focuses primarily on the evaluation or assessment of quality realized through a number of core practices: • Finding and documenting defects in software quality. • Generally advising about perceived software quality. • Proving the validity of the assumptions made in design and requirement specifications through concrete demonstration. • Validating the software product functions as designed. • Validating that the requirements have been implemented appropriately. • Test discipline acts in many respects as a service provider to the other disciplines.

  18. Artifacts of Test Discipline

  19. Define Evaluation Mission Workflow Detail: Define Evaluation Mission • Roles responsible for related activities: • Test Manager (mainly) • Test Analyst • Test Designer For each Iteration: • Identify the objectives for and deliverables of the testing effort • Identify a good utilization strategy for test resources • Define the scope and boundaries for the test effort • Outline the approach that will be used • Define how progress will be monitored and assessed

  20. Concept: Test Automation and Tools • Data acquisition tools • Static measurement tools • Dynamic measurement tools • Simulators or Drivers • Test management tools

  21. Discipline: Implementation • The purposes of Implementation are: • To implement classes and objects in terms of components • To define the organization of the components in terms of implementation subsystems • To test the developed components as units • To create an executable system • Implementation results in an Implementation Model. ImplementationModel

  22. An Implementation Model consists of: Components Implementation Subsystems Components include: Deliverable components, such as executables Components from which the deliverables are produced, such as source code files Telephone Banking A <<import>> <<compilation>> Trading Services B What Is an Implementation Model? Components and implementation subsystems in a Telephone Banking System.

  23. Concept: Build • Operational version of a system or part of a system • Demonstrates a subset of the capabilities provided in the final product • Integral part of the iterative lifecycle • Provides review points • Helps uncover integration problems as soon as they are introduced

  24. Discipline: Deployment • Purpose: Manage the activities associated with ensuring that the software product is available for its end users, such as: • Product deployment • Testing at the installation and target sites • Beta testing • Creating end-user support material • Creating user training material • Releasing to customer (in the form of shrink- wrapped package, download site, etc.)

  25. Use-Case Model Use Cases and End-User Documentation Deployment • End-User Support Material • User’s Guide • Online Help • Demos • Tutorials • Training Material Supplementary Specification

  26. Discipline: Configuration & Change Management • Purpose: Track and maintain integrity of project artifacts • Change control • Configuration identification and management • Configuration status accounting • Change tracking • Version selection • Software manufacture • Workspace management

  27. The Configuration and Change Management (CCM) Cube

  28. Describes the product structure (logically correct configurations) Identifies which artifacts are to be tracked Identifies dependencies among artifacts Maintaining traceability between artifacts Isolate individual and team workspaces Configuration Management (CM)

  29. Addresses: The capture and management of requested changes to one or more artifacts by various stakeholders. A change request has a lifecycle: new, logged, approved, assigned and complete. Not all change requests are acted on. The potential impact of a proposed change determines if it will be acted on. Change Request Management (CRM)

  30. This type of accounting describes the state of the product based on the type, number, rate, and severity of defects found and fixed during the course of product development. Metrics derived under this aspect, either through audits or raw data, are useful in determining the overall completeness status of the project. Problem areas that require attention Configuration Status Accounting

More Related