Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.

Slides:



Advertisements
Similar presentations
Objectives Explain the purpose and various phases of the traditional systems development life cycle (SDLC) Explain when to use an adaptive approach to.
Advertisements

RUP/UP Software Development Method Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn.
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.
Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services
Gerhard Dueck -- CS3013Capturing Requirements as Use Cases 1 Capturing the Requirements as use Cases  Requirements Description  We need to describe –The.
Static Structure: Process Description
Mastering Object-Oriented Analysis and Design with UML Module 4: Analysis and Design Overview.
IBM Business Consulting Services © Copyright IBM Corporation 2006 Unified Process March 27, 2006 Chris Armstrong.
1 Software Requirement Analysis Deployment Package for the Basic Profile Version 0.1, January 11th 2008.
Use-case Modeling.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
SE 470 Software Development Processes James Nowotarski 21 April 2003.
Requirements Specification
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.
Copyright 2006 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Rational Unified Process – Part 2
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.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter 1 The Systems.
Lesson 1 Week01.
RUP Requirements RUP Artifacts and Deliverables
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
UML - Development Process 1 Software Development Process Using UML (2)
Rational Unified Process
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.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
RUP Fundamentals - Instructor Notes
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
Systems Analysis and Design in a Changing World, 3rd Edition
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Requirements Capture. Four Steps of requirements capture List candidate requirements Understand system context Capture functional requirements Capture.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Object Oriented Analysis and Design using the UML CIS 520 Advanced Object-Oriented Design.
Actors and Use Case Diagrams Month Day, Year. Agenda Training Plan Overview Review Detailing Requirements with Requisite Pro Concepts Setting Up XDE Integration.
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
Use Cases, Part I Understanding the Business Dynamics  Understand the business workflow  Identify system support points the system 'use cases'
RUP Fundamentals Instructor Notes
Rational Unified Process Fundamentals Module 3: Disciplines I.
Rational Unified Process Fundamentals Module 7: Process for e-Business Development Rational Unified Process Fundamentals Module 7: Process for e-Business.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
UML - Development Process 1 Software Development Process Using UML.
UML Course Instructor: Rizwana Noor. Overview  Modeling  What is UML?  Why UML?  UML Diagrams  Use Case  Components  Relationships  Notations.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Requirement Discipline Spring 2006/1385 Semester 1.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 4: Analysis and Design Overview.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
RATIONAL UNIFIED PROCESS PROCESS FRAMEWORK OVERVIEW.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
1.Introduction to Rational Unified Process (RUP)
The Rational Unified Process (RUP) An Architecture-Centric Process
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Software Development Process Using UML Recap
Presentation transcript:

Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational Unified Process (RUP) Static Structure: Process Description

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 2

Process 3

Example workflow of Requirements 4

Process Elements: Roles The central concept in the process is that of a role. A role defines: the behavior and responsibilities of an individual or of a group of individuals working together as a team. 5

behavior is: activities the role performs each role is associated with a set of cohesive activities. "Cohesive" in this sense means: activities that are best performed by one person. 6 Process Elements: Roles

responsibilities of each role are usually expressed in relation to certain artifacts that the role creates, modifies, or controls. 7 Process Elements: Roles

Roles are not individuals, nor job titles. You can play the Project Manager role for an hour, then play the architect role for the rest of the morning, and switch from coder role to tester role during the afternoon. Your colleagues Joe, Stefan, and Mary might all play simultaneously the Design Reviewer role in your review later in the afternoon. 8 Process Elements: Roles

Examples of roles: System Analyst  leads and coordinates  requirements elicitation and  use-case modeling by outlining the system's functionality and  Defining boundaries of the system. 9 Process Elements: Roles

Designer  defines the  responsibilities,  operations,  attributes, and  relationships of one or more classes and  determines how they should be adjusted to the implementation environment. 10 Process Elements: Roles

Test Designer  is responsible for  planning,  design,  implementation, and  evaluation of tests, including:  generating the test plan and procedures and  implementing the test procedures, and  evaluating  test coverage,  results, and  effectiveness. 11 Process Elements: Roles

12 Process Elements: Roles

Roles have activities, which … define the work they perform. 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. 13 Process Elements: Activities

The activity has a clear purpose, It expressed in terms of creating or updating artifacts, Every activity is assigned to one specific role. The granularity of an activity is generally a few hours to a few days. It usually involves one person in the associated role and affects one or only a small number of artifacts. 14 Process Elements: Activities

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. 15 Process Elements: Activities

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 16 Process Elements: Activities

Activity Steps:  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. 17 Process Elements: Activities

For example, the Activity: Find Use Cases and Actors 1) Find actors 2) Find use cases. 3) Describe how actors and use cases interact. 4) Package use cases and actors. 5) Present the use-case model in use-case diagrams. 6) Develop a survey of the use-case model. 7) Evaluate your results. 18 Process Elements: Activities

Activities have input and output artifacts. An artifact is a piece of information that is produced, modified, or used by a process. Artifacts are the tangible products of the project: the things the project produces or uses while working toward the final product. Artifacts are used as input by roles to perform an activity and are the result or output of such activities. 19 Process Elements: Artifacts

Artifacts take various shapes or forms: 1) A model  such as the use-case model or  the design model 2) A model element  an element within a model such as  a class,  a use case, or  a subsystem 20 Process Elements: Artifacts

3) A document  such as a business case or  software architecture document 4) Source code 5) Executables 21 Process Elements: Artifacts

Artifact is the term used in RUP. Other processes use terms such as  work product,  work units,  deliverables,  and so on Deliverables in RUP: are only the subset of all artifacts that end up in the hands of the customers and end users. 22 Process Elements: Artifacts

Artifacts Major artifacts of RUP: 23

Examples of artifacts:  A design model in UML stored in Rational Rose  A project plan stored in Microsoft Project  A defect stored in Rational ClearQuest  A project requirements database in Rational RequisitePro 24 Process Elements: Artifacts

Disciplines are "containers" used to organize activities of the process. There are nine main disciplines in RUP 25 Process Elements: Disciplines

The nine core disciplines are divided into  six technical disciplines and  three supporting disciplines. 26 Process Elements: Disciplines

27 Process Elements: Disciplines

A workflow is  a sequence of activities that  produces a result of observable value. 28 Process Elements: Workflows

RUP uses three types of workflow: 1) Core workflows,  associated to each discipline 2) Workflow details,  to refine the core workflow 3) Iteration plans 29 Process Elements: Workflows

These additional process elements are:  Guidelines  Templates  Tool mentors  Concepts 30 Additional Process Elements

31 Additional Process Elements

Guidelines are:  rules,  recommendations, or  heuristics that support activities and steps. Guidelines are used also to assess the quality of artifacts. 32 Process Elements: Guidelines

Types of guidelines: 1) Work guidelines  give practical advice on how to undertake an activity, for example:  Work guidelines for reviews  Work guidelines for a use-case workshop  Work guidelines for programming, such as programming in pairs 33 Process Elements: Guidelines

2) Artifact guidelines  describe how to develop,  evaluate, and  use the artifact;  for example:  How to create a specific artifact  User-interface guidelines 34 Process Elements: Guidelines

Some guidelines need to be  refined or  for a given organization or project to  accommodate project specifics 35 Process Elements: Guidelines

examples:  User-interface guidelines,  such as a description of the windowing style specific to a project:  color palette,  fonts,  gallery of icons, and so on  Programming guidelines,  such as a description of naming conventions specific to the project 36 Process Elements: Guidelines

Templates are linked to the tool that is to be used. For example:  Microsoft Word templates for documents and some reports  Microsoft Project template for the  project plan and  iteration plan 37 Process Elements: Templates

Organizations may want to customize the templates before using them by adding the  company logo,  some project identification, or  information specific to the type of project. 38 Process Elements: Templates

Tool mentors  provide guidance  by showing you how to perform the steps using a specific software tool.  Tool mentors in RUP are for  Rational Rose,  RequisitePro,  ClearCase,  ClearQuest, and  TestStudio 39 Process Elements: Tool Mentors

A development organization can  extend the concept of tool mentor to  provide guidance for other tools. 40 Process Elements: Tool Mentors

Some of the key concepts, such as:  iteration,  phase,  artifact,  risk,  performance testing, and so on, are introduced in separate sections of the process, 41 Process Elements: Concepts

With this structure, … RUP constitutes a process framework. Roles, artifacts, activities, guidelines, concepts, and mentors are the elements that:  you can add or  replace  to evolve or adapt the process to the organization's needs. 42 A Process Framework