Software Engineering Learning Programme Software Engineering Foundation

40
RUP Life Cycle Software Engineering Learning Programme Software Engineering Foundation

description

Software Engineering Learning Programme Software Engineering Foundation. RUP Life Cycle. Module Objectives. To understand the main concepts - RUP Fundamentals - Terminology / context / deliverables To understand the benefits and best practices Understand the role of the SE within RUP - PowerPoint PPT Presentation

Transcript of Software Engineering Learning Programme Software Engineering Foundation

RUP Life Cycle

Software Engineering Learning ProgrammeSoftware Engineering Foundation

Producer/ddmmyy - Title - author / 2

Module Objectives

To understand the main concepts - RUP Fundamentals - Terminology / context / deliverables

To understand the benefits and best practices

Understand the role of the SE within RUP Understand what input deliverables are needed and where do they

come from Which output deliverables are used as input for roles further in the

process and how they are used

Delivery GuidelinesDelivery Guidelines

Format: Format: Webcast / and intructor-introWebcast / and intructor-intro

Duration: Duration: 3 hours / 60 Minutes3 hours / 60 Minutes

Producer/ddmmyy - Title - author / 3

Module Topics

What about RUP Background and why use it,

RUP Best practices

Model Visually

Requirements management

Importance of traceability

Importance of configuration management

RUP language Terminology and symbols

Deliverables

SE role level 1

Producer/ddmmyy - Title - author / 4

RUP – what about it and why use it?

The "Rational Way" is: Iterative and incremental

Object-oriented

Managed and controlled

Highly automated

It is generic enough to be tailorable to a wide variety of software products and projects, both in size and application domain. It is centered around three poles:

People

Process

Tools and methods

Producer/ddmmyy - Title - author / 5

RUP – history.

1998 Rational Unified Process (RUP) released to the public. Result of from team collaborations and three software developers. “Three

Amigo’s”

RUP successor of Rational Objectory Process (ROP), includes all aspects of the software development life-cycle.

1999 OMG issues a request for proposal (RFP).  Goal to provide an industry standard for tools and technologies for the software

development lifecycle. 

May 2000, Rational Software Corporation, IBM, et al, submit the Unified Process Model (UPM)

And now…

“Object-Oriented Modelling and Design”

(1991)

“Object-Oriented Modelling and Design”

(1991)

“Object-Oriented Software Engineering:

A Use Case Driven Approach” (1992)

“Object-Oriented Software Engineering:

A Use Case Driven Approach” (1992)

GRADYBOOCH

IVARJACOBSON

IVARJACOBSON

JAMESRUMBAUGH

JAMESRUMBAUGH

“Object-Oriented Design with

Applications” (1993)

“Object-Oriented Design with

Applications” (1993)

Producer/ddmmyy - Title - author / 6

Phases, Disciplines and Milestones

TimeC

on

ten

t

Producer/ddmmyy - Title - author / 7

Best practices

Develop Iteratively

Manage Requirements

Model Visually

Use Component Architectures

Continuously Verify Quality

Control Change

Best Practices

Producer/ddmmyy - Title - author / 8

Best Practice 4 Model Visually

Capture the structure and behavior of architectures and components

Show how the elements of the system fit together

Hide or expose details as appropriate for the task

Maintain consistency between a design and its implementation

Promote unambiguous communication Visual modeling improves our ability to manage

software complexity

The Unified Modeling Language (UML) is a language for •specifying, •visualizing, •constructing, and •documenting

•the artifacts of software systems.

Producer/ddmmyy - Title - author / 9

Diagrams are view of a Model

Producer/ddmmyy - Title - author / 10

Best practice 2 Manage Requirements

Producer/ddmmyy - Title - author / 11

Requirement and Requirements Management

A requirement describes a condition or capability to which a system

must conform.. Types:

Functional requirements

Non-functional requirements

packaged Software Requirements Specification (SRS)

Requirements management is a systematic approach to finding, documenting, organizing and tracking the changing requirements of a system

White Paper: Applying Requirements Management with Use Cases

Producer/ddmmyy - Title - author / 12

Business Needs

drive Customer Needs

which driveUser Needs

which demand Product Features

that drive Software Requirements

that we developers Implement and Test

E . Magaziner ‘96

What is Requirements Traceability?

Producer/ddmmyy - Title - author / 13

Why Use Requirements Traceability?

The purpose is to: Verify that all requirements of the system are fulfilled by the implementation.

Verify that the application does only what it was intended to do

Help manage change

A proven technique for assuring quality Practiced by high-reliability system developers

Mandated by standards (e.g.: DOD, FDA)

Recommended by IEEE and CMM

A proven technique for understanding the impact of changes

Producer/ddmmyy - Title - author / 14

Sample Queries Using Requirement Links

Show me user needs which are not linked to product features

Show me the status of tests on all use cases in iteration #3?

Show me all supplementary requirements linked to tests whose status is untested

Show me the results of all tests which failed, in order of criticality

Show me the features scheduled for this release, which user needs they satisfy, and their status

Producer/ddmmyy - Title - author / 15

Determine Your Requirement Traceability Strategy

StakeholderRequests

Vision

Design Model

SupplementarySpecification

End-User Documentation Materials and

Training Materials

Use-Case

Model

Test Model

Features

SoftwareRequirements

Needs

Producer/ddmmyy - Title - author / 16

1.1. Trace top level Trace top level requirements into detailed requirements into detailed requirementsrequirements

2.2. Trace requirements into Trace requirements into designdesign

3.3. Trace requirements into test Trace requirements into test proceduresprocedures

4.4. Trace requirements into Trace requirements into user documentation planuser documentation plan

Design

Software Design Descriptions

Object Models

Test Suites

Test

2 3

Req A

1

Product Requirements

(Features)

Detailed Requirements

(Use Cases) Req B

Documentation Plan

User Docs

4

Establish Traceability Paths

Producer/ddmmyy - Title - author / 17

Viewing Links - Traceability Matrix

Producer/ddmmyy - Title - author / 18

Viewing Links - Tree Report

Tree reports provide the ability to trace linkages through the document hierarchy.

Producer/ddmmyy - Title - author / 19

What is Configuration Management?

Configuration Management is a discipline which enables you to identify the components of a system, so that you can:

Control all changes to the components

Maintain integrity and traceability through the whole application life cycle

Producer/ddmmyy - Title - author / 20

Why Configuration Management?

To follow the progress of developments

To follow the evolution of one particular component

To ensure the use of the right component

To allow sharing of one component between several developers without conflicts and loss of data

To ensure the safety of components

To allow regeneration of complete and up-to-date application versions

To provide visibility on the development / maintenance cycle

Producer/ddmmyy - Title - author / 21

Configuration Management Software

CM Software Provides the Ability to: Maintain a single copy of system elements Control access to data Maintain an exhaustive inventory of software components Maintain a history of changes Follow and control a defined process Manage the security of different environments (development,

QA, production)

Producer/ddmmyy - Title - author / 22

RUP – terminology

RUP uses roles, disciplines, phases and artifacts

Some terms are new for developers; Know the RUP language!

Producer/ddmmyy - Title - author / 23

Schedule oriented terms in the RUP

Inception Construction

phase

Elaboration Transition

proces iteration

development cycle

milestonerelease

Final production

release

product increment=

delta

release

InitialOperationalCapability

LifeCycle Architecture Milestone

LifeCycle ObjectivesMilestone

Producer/ddmmyy - Title - author / 24

RUP Terminology: Discipline

All activities you may go through to produce a particular set of artifacts.

The contents of each discipline in RUP are organized as shown in the Environment discipline example.

Producer/ddmmyy - Title - author / 25

Disciplines Produce Models

Use-CaseModel

ImplementationModel

implemented by

TestModel

verified by

realized by

(Analysis) Design (Model) Model

automated by

Analysis & Analysis & DesignDesign

RequirementsRequirements

ImplementationImplementation

TestTest

BusinessBusinessModelingModeling

Business Use-Case Model

BusinessObject Model

Producer/ddmmyy - Title - author / 26

RUP Terminology : Workflow

Disciplines > Test > Workflow

Workflows: Each Discipline contains one Workflow which shows a typical sequence of events when conducting the flow of work.

Workflows are expressed in terms of Workflow Details which are ordered conditionally.

Workflow Details

Producer/ddmmyy - Title - author / 27

RUP Terminology : Workflow Details

Example: Disciplines > Test > Workflow > Improve Test Assets

Workflow Details are groupings of activities that are done "together," presented with input and resulting artifacts.

Disciplines are explained using Workflow Details.

Producer/ddmmyy - Title - author / 28

RUP Terminology : Activity

A piece of work a role may be asked to perform

Granular: usually takes a few hours to a few days

Repeated, as necessary, in each iteration

Example

Thinking

Performing

Evaluating

Activity: Find use cases and actorsStep: Find Actors

Step: Find Use Cases

Step: Describe How Actors & Use Cases Interact

Step: Package Use Cases and Actors

Step: Present Use-Case Model in U-C Diagrams

Step: Develop a Survey of the Use-Case Model

Step: Evaluate Your Results

Producer/ddmmyy - Title - author / 29

RUP Terminology : Artifact

A piece of information that is produced, modified, or just used by a process

Defines an area of responsibility

Likely to be subject to configuration control

Kinds of artifacts: Models Model elements Documents

Artifacts may contain other artifacts

Producer/ddmmyy - Title - author / 30

Example: Artifact Overview Diagram

SystemAnalyst

StakeholderRequests

Vision Use-Case Model

SupplementarySpecification

GlossaryRequirements

Specifier

Use CaseUse-Case Package

User-InterfaceDesigner

Actor(hum an)

Use-Case Storyboard

User-InterfacePrototype

BoundaryClass

SoftwareRequirementsSpecification

RequirementsAttributes

RequirementsManagement

Plan

Example: Disciplines-> Requirements-> Artifact Overview

Producer/ddmmyy - Title - author / 31

RUP Terminology : Role

A role defines the behavior and responsibilities of an individual, or a set of individuals, working together as a team Behavior: a set of cohesive activities

Responsibilities: usually defined relative to certain artifacts

A role is a “hat” wornby an individual

RUP role set•Analysts •Developers •Testers •Managers •Other roles

Producer/ddmmyy - Title - author / 32

Example: Role Responsibility Diagram

Example: Systems Analyst

Example: Implementor

Producer/ddmmyy - Title - author / 33

Guidelines

Rules, recommendations, heuristics that support artifacts and activities

Add the benefit of experience to activities

Describe well-formed artifacts, focus on qualities

Describe specific techniques Transformations from one artifact to another

Use of UML

Used also to assess the quality of artifacts

Can be tailored by the organization

Work guidelines: Provide work and documentation techniques, often complements to the

formal artifacts defined in the RUP Can be used as an aid in more than one of the activities Focus on techniques that help team communication

Producer/ddmmyy - Title - author / 34

Tool Mentors

Similar to guidelines

Explain how to use a specific tool to perform an activity or steps in an activity

Linked by default to Rational tools: Rational RequisitePro: requirements management

Rational Rose: visual modeling, using UML

Rational SoDA: documentation generation

Rational ClearQuest: change management, defect tracking

…. and more

Producer/ddmmyy - Title - author / 35

4 + 1 View Model

Process View

Deployment View

Logical View

Implementation View

Programmers Software management

System IntegratorsPerformanceScalabilityThroughput

System EngineeringSystem topology

Delivery, installationcommunication

Use-Case View

End-userFunctionality

Analysts/TestersBehavior

Producer/ddmmyy - Title - author / 36

Summary

What about RUP Background and why use it,

RUP Best practices Model Visually Requirements management Importance of traceability Importance of configuration management

RUP language Terminology and symbols Deliverables SE role level 1

Producer/ddmmyy - Title - author / 37

More to know…. Sources used when developing the RUP product

Explore the RUP knowledge base. RUP Glossary RUP Resource Center online

Visit www.therationaledge.com and Rational developers network

Books:• The Rational Unified Process an Introduction Philippe Kruchten• Building J2ee Applications with the Rational Unified Process Peter Eeles• Building Web Applications with UML Jim Conallen

Examples white papers Reaching CMM Levels 2 and 3 Applying Requirements Management with Use Cases Developing Large-Scale Systems with the Rational Unified Process The Ten Essentials of RUP — The Essence of an Effective Development

Process Using the Rational Unified Process for Small Projects: Expanding Upon

eXtreme Programming

Producer/ddmmyy - Title - author / 38

Exercise 1/11. What’s the relationship between a Role, Artifact and Activity?

2. What are the roles the CGEY Software Engineer can realize?

3. How do Workflows, Workflow Details and Activities fit together?

4. What is the importance of the iteration plan for a SE?

5. Right or Wrong? (explain your vote !)

1. In the discipline Analyse And Design the analyst performs use case analysis.

2. The System Architect is responsible for the analysis model

3. The Designer is responsible for the activity Find Business actors and use cases

4. The Use case template should always completely been used.

5. The Designer is not responsible for the design Model.

6. The Test Designer performs Unit Tests

7. The Implementer plans and integrates subsystems

8. The Integrator is responsible for the integration build plan

9. The deployment unit is an artifact for which the deployment manager is responsible.

10. Use case realizations are realized in requirements.

Producer/ddmmyy - Title - author / 39

Exercise 1/21. What artifact the SE is responsible for contains other artifacts?

2. Are there any changes for the developer in the new version of RUP (2003)

3. Take 5 artifacts a SE will be responsible for. Describe for each artifact the RUP role responsible and in which view (of the 4 in 1 model view) this artifact is described.

4. What Tools will be used by a CGEY SE in the different roles?

5. Are all tools necessary for a development cycle? What is the minimum set?

6. How do Tool Mentors work in RUP?

Producer/ddmmyy - Title - author / 40

Questions