Static Structure: Process Description

Slides:



Advertisements
Similar presentations
IBM Software Group ® Traceability From Need To Solution What, Why and How Tammy Lavi Alon Bar-Ner.
Advertisements

Lecture # 2 : Process Models
Objectives Explain the purpose and various phases of the traditional systems development life cycle (SDLC) Explain when to use an adaptive approach to.
RUP/UP Software Development Method Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn.
Ch 3 System Development Environment
1 IBM Software Group ® PRJ270: Essentials of Rational Unified Process Module 3: RUP Structure and Navigation.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Sixth Hour Lecture 10:30 – 11:20 am, September 9 Framework for a Software Management Process – Artifacts of the Process (Part II, Chapter 6 of Royce’ book)
Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 1 Capturing the Requirements as use Cases  Requirements Description  We need to describe –The.
IBM Business Consulting Services © Copyright IBM Corporation 2006 Unified Process March 27, 2006 Chris Armstrong.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
SE 470 Software Development Processes James Nowotarski 21 April 2003.
Requirements Specification
© Copyright Eliyahu Brutman Programming Techniques Course.
SwE 313 Introduction to Rational Unified Process (RUP)
Copyright  Larry Dribin, Ph.D. SE470_EngFlows_v1.ppt SE470 EngFlows - 1 Excellence in Software Engineering Repeatable Level Defined Level Manage.
Iterative development and The Unified process
© 2005 course technology1 1 1 University Of Palestine UML for The IT Business Analyst A practical guide to Object Oriented Requirement Gathering Hoard.
Objectives Explain the purpose and various phases of the traditional systems development life cycle (SDLC) Explain when to use an adaptive approach to.
Rational Unified Process – Part 2
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Object Oriented Analysis and Design Using the UML
Unified Software Practices v 5.0-D Copyright  1998 Rational Software, all rights reserved 1 /26 RUP Architecture.
RUP Requirements RUP Artifacts and Deliverables
UML - Development Process 1 Software Development Process Using UML (2)
Rational Unified Process
RUP Fundamentals - Instructor Notes
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 1: Best Practices of Software Engineering.
2Object-Oriented Analysis and Design with the Unified Process Objectives  Explain the purpose and various phases of the traditional systems development.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Implementation Yaodong Bi. Introduction to Implementation Purposes of Implementation – Plan the system integrations required in each iteration – Distribute.
RUP Implementation and Testing
Rational Unified Process Fundamentals Module 4: Disciplines II.
RUP Fundamentals - Instructor Notes
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
Jyoti Chaturvedi and David Orr Enter RUP. What should I know when I leave? What is the RUP software? What good is it? What can I do with it? How will.
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
Systems Analysis and Design in a Changing World, 3rd Edition
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Information Systems Engineering. Lecture Outline Information Systems Architecture Information System Architecture components Information Engineering Phases.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Object Oriented Analysis and Design using the UML CIS 520 Advanced Object-Oriented Design.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
1 System Analysis and Design Using UML INSTRUCTOR: Jesmin Akhter Lecturer, IIT, JU.
RUP Life Cycle Software Engineering Learning Programme Software Engineering Foundation.
RUP Fundamentals Instructor Notes
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Rational Unified Process Fundamentals Module 3: Disciplines I.
The Rational Unified Process 1 EECS810: Software Engineering.
1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2.
Lecture 9-1 : Intro. to UML (Unified Modeling Language)
The principles of an object oriented software development process Week 04 1.
Software Engineering Lecture # 1.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
CSPC 464 Fall 2014 Son Nguyen. 1. The Process of Software Architecting, Peter Eeles, Peter Cripss 2. Software Architecture for Developers, Simon Brown.
Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts.
Requirement Discipline Spring 2006/1385 Semester 1.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
Enterprise Architectures. Core Concepts Key Learning Points: This chapter will help you to answer the following questions: What are the ADM phase names.
Using Rational Administrator Month Day, Year. Agenda Training Plan Overview Using Rational Administrator Review Next Steps.
TK2023 Object-Oriented Software Engineering
Chapter 1: Introduction to Systems Analysis and Design
Unified Modeling Language
1.Introduction to Rational Unified Process (RUP)
Introduction to Software Engineering
Chapter 1: Introduction to Systems Analysis and Design
Software Development Process Using UML Recap
Presentation transcript:

Static Structure: Process Description Chapter 3 Static Structure: Process Description

Model of Rational Unified Process A process describes who is doing what, how, and when. RUP is represented using five primary elements: Roles: the who Activities: the how Artifacts: the what Workflows: the when Disciplines: the "container" for the preceding four kinds of element

Role, Activities, and Artifact

Roles Behavior is expressed in terms of activities the role performs A role defines the behavior and responsibilities of an individual or of a group of individuals working together as a team Behavior is expressed in terms of activities the role performs Responsibilities of each role are expressed in relation to certain artifacts that the role creates, modifies, or controls. Roles are not individuals Roles describe how individuals should behave in the business and the responsibilities of each individual. Relationship between an individual to roles is one-to-many A person may play the project manager for hours, then play the architect role for the rest of the morning.

Example of Roles System Analyst Designer Test Designer Coordinates requirements elicitation and use-case modeling by outlining system’s functionality and delimiting the system Designer Defines the responsibilities, operations, attributes, and relationships of one or more classes Determines how they should be adjusted to implementation environment Test Designer Responsible for planning, design, implementation, and evaluation of tests Generating test plan and test model Implementing test procedures, Evaluating test coverage, results, and effectiveness

People and Roles

Roles Roles are organized in five main categories: Analyst roles Business-Process Analyst, Business Designer, System Analyst, Requirements Specifier Developer roles Software Architect, Designer, User-Interface Designer, Capsule Designer, Database Designer, Implementer, Integrator Tester roles Test Analyst, Test Designer, Tester Manager roles Project Manager, Change Control Manager, Configuration Manager, Test Manager, Deployment Manager, Process Engineer, Management Reviewer Production and support roles System Administrator, Technical Writer, Graphic Artist, Tool Specialist, Course Developer

Additional Roles Reviewer Review Coordinator Any Role Stakeholder Responsible for providing timely feedback to project team members on the artifacts they have produced. Review Coordinator Responsible for facilitating formal reviews and inspections, and ensuring that they occur when required and are conducted to a satisfactory standard. Any Role This is a generic role used to carry the activities that any project member can perform. Stakeholder Anyone who is materially affected by the outcome of the project. Roles are denoted in the RUP prefixed with the word Role, as in Role: Integration Tester

Activities Every activity is assigned to one specific role. An activity is a unit of work that an individual in that role may be asked to perform and that produces a meaningful result in the context of the project. Every activity is assigned to one specific role. The purpose of activity is to create or update artifacts, such as a model, a class, or a plan An activity may take up a few hours to a few days. Activities may be repeated several times on the same artifact, especially from one iteration to another. Repeated activities are performed by the same role but not necessarily the same individual.

Examples of Activities Plan an iteration: performed by the Role: Project Manager Find use cases and actors: performed by the Role: System Analyst Review the design: performed by the Role: Design Reviewer Execute a performance test: performed by the Role: Performance Tester Activities are prefixed with the word Activity, as in Activity: Find use case and actors.

Activity Steps Steps fall into three main categories: Thinking steps The person playing the role understands the nature of the task, gathers and examines the input artifacts, and formulates the outcome. Performing steps The person playing the role creates or updates some artifacts. Reviewing steps The person playing the role inspects the results against some criteria.

Activity: Find Use Cases and Actors For example, this activity is decomposed into these seven steps: Find actors. Find use cases. Describe how actors and use cases interact. Package use cases and actors. Present the use-case model in use-case diagrams. Develop a survey of the use-case model. Evaluate your results. Thinking Performing Reviewing

Artifacts An artifact is a piece of information that is produced, modified, or used by a process. It is the things the project produces or uses while working toward the final product. Artifacts are used as input by roles to perform an activity Artifacts are the result or output of such activities.

Note: artifact is the term used in the Rational Unified Process. Examples of Artifacts A model, such as the use-case model or the design model A model element—an element within a model—such as a class, a use case, or a subsystem A document, such as a business case or software architecture document Source code Executables Note: artifact is the term used in the Rational Unified Process. Other processes use terms such as work product, work units, deliverables, etc.

Major Artifacts of RUP

More About Artifacts Artifacts can also be composed of other artifacts. For example, the design model contains many classes Artifacts are very likely to be subject to version control and configuration management. The RUP discourages the systematic production of paper documents. Managing project artifacts is to maintain the artifacts within the appropriate tool used to create and manage them Delivering artifacts to the interested parties inside and together with the tool rather than on paper.

More About Artifacts Every piece of information should be the responsibility of a specific person, artifacts are the responsibility of a single role. Even though one person may "own" the artifact, many people may use this artifact, perhaps even updating it if they have been given permission. Artifacts are denoted in the process prefixed with the word artifact, as in Artifact: Use-Case Storyboard.

Reports Models and model elements can have associated reports. A report extracts information about models and model elements from a tool A report presents an artifact or a set of artifacts for a review Unlike regular artifacts, reports are not subject to version control. They can be produced at any time by going back to the artifacts that generated them.

Sets of Artifacts Artifacts of the RUP have been organized into information sets that are aligned with the core disciplines. Management set Planning artifacts, such as the software development plan (SDP), the business case Operational artifacts, such as a release description, status assessments, deployment documents, and defect data Requirements set The vision document Requirements in the form of stakeholders' needs, use-case model, and supplementary specification Design set The design model The architecture description

Sets of Artifacts (cont.) Implementation set The source code and executables The associated data files or the files needed to produce them Deployment set Installation material User documentation Training material

Growing the Information Sets The information sets evolve throughout Iterations of the development cycle.

Core Disciplines Disciplines are "containers" used to organize activities of the process. Core process disciplines

Workflows A workflow is a sequence of activities that produces a result of observable value. In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram However, a form of activity diagrams is used here.

Workflows The Rational Unified Process uses three types of workflow: Core Workflows Associated to each discipline. Workflow details Use workflow details to express a specific group of closely related activities for each core workflows Iteration plans selecting the activities that will be effectively run during the iteration and replicating them as necessary

Example of Workflow

Additional Process Elements Other elements are added to activities or artifacts to make the process easier to understand and use provide more comprehensive guidance to the practitioners. These additional process elements are: Guidelines Templates Tool mentors Concepts

Adding Templates, Tool Mentors, Guidelines These elements enhance the primary elements.

Guidelines Guidelines are rules, recommendations, or heuristics that support activities and steps. Guidelines describe well-formed artifacts, focusing on their specific qualities, Guidelines describe specific techniques to create certain artifacts or the transformations from one artifact to another or the use of UML.

Types of Guidelines Work guidelines Artifact guidelines Give practical advice on how to undertake an activity, especially for group activities; Work guidelines for reviews Work guidelines for a use-case workshop Work guidelines for programming, such as programming in pairs Artifact guidelines Associated with a particular artifact and describe how to develop, evaluate, and use the artifact; Modeling guidelines, Programming guidelines, for languages such as Java, C++, or Ada, User-interface guidelines Guidelines on how to create a specific artifact, such as a risk list or an iteration plan Checkpoints used as part of a review to verify that an activity is complete

Templates Templates are models, or prototypes, of artifacts. One or more templates are associated with the artifact description used to create the corresponding artifacts. Examples of templates are listed below: Microsoft Word templates for documents and some reports SoDA templates for Microsoft Word or FrameMaker that extract information from tools such as Rational Rose, RequisitePro, or TeamTest HTML templates for the various elements of the process Microsoft Project template for the project plan and iteration plan

Tool Mentors Additional means of providing guidance by showing practitioners how to perform the steps using a specific software tool. Tool mentors are provided in RUP, linking its activities with tools such as Rational Rose, Rational XDE, RequisitePro, ClearCase, ClearQuest, and TestStudio. The tool mentors almost completely encapsulate the dependencies of the process on the tool set, keeping the activities free from tool details.

A Process Framework Roles, artifacts, activities, guidelines, concepts, and mentors are the elements that we can add or replace to evolve or adapt the process to the organization's needs. The organization of RUP in this chapter is based on an industry standard called the Software Process Engineering Metamodel (SPEM).

Summary The Rational Unified Process model is built on three fundamental entities: roles, activities, and artifacts. Disciplines are natural groupings of process activities, roles, and artifacts. Workflows relate activities, artifacts, and roles in sequences that produce valuable results. Guidelines, templates, and tool mentors complement the description of the process by providing detailed guidance to the practitioner. The Rational Unified Process is an open process framework based on an industry standard called SPEM.