Unified Software Development Process (3C05/D22) Unit 5: USDP USDP

Similar documents
3C05: Unified Software Development Process

In this Lecture you will Learn: Systems Development Methodologies. Why Methodology? Why Methodology?

The Unified Software Development Process

CHAPTER_3 SOFTWARE ENGINEERING (PROCESS MODELS)

Software Design Models, Tools & Processes *

The most suitable system methodology for the proposed system is drawn out.

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Basic Unified Process: A Process for Small and Agile Projects

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.)

Supporting Workflow Overview. CSC532 Fall06

SOFTWARE PROCESS MODELS

I219 Software Design Methodology

In this Lecture you will Learn: Development Process. Unified Software Development Process. Best Practice

Plan-Driven Methodologies

Software Project Management using an Iterative Lifecycle Model

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Abstract. 1 Introduction

Classical Software Life Cycle Models

Family: Iterative Enhancement Origin: Ivar Jacobson, James Rumbaugh, Grady Booch, 1996 Defines process framework that is adaptable to

The Rap on RUP : An Introduction to the Rational Unified Process

Software Development Methodologies

CS4507 Advanced Software Engineering

10/4/2013. Sharif University of Technology. Session # 3. Contents. Systems Analysis and Design

Chap 1. Introduction to Software Architecture

Agile Unified Process

An Introduction to the UML and the Unified Process

Development Methodologies

Software Lifecycles Models

Inter-operability of DSDM with the Rational Unified Process

Oracle Unified Method (OUM)

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

How To Understand The Software Process

A FRAMEWORK FOR INTEGRATING SARBANES-OXLEY COMPLIANCE INTO THE SOFTWARE DEVELOPMENT PROCESS

Unit 1 Learning Objectives

Iterative Software Development -

Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK

To introduce software process models To describe three generic process models and when they may be used

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

Reaching CMM Levels 2 and 3 with the Rational Unified Process

The Dynamics of Project Management

Masters of Science in Software & Information Systems

RUP for Software Development Projects

Development models. 1 Introduction. 2 Analyzing development models. R. Kuiper and E.J. Luit

A Rational Development Process

Software Process and Models

Leveraging RUP, OpenUP, and the PMBOK. Arthur English, GreenLine Systems

Development Methodologies. Types of Methodologies. Example Methodologies. Dr. James A. Bednar. Dr. David Robertson

What CMMI Cannot Give You: Good Software

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali

Business Modeling with UML

Software Development Process Models and their Impacts on Requirements Engineering Organizational Requirements Engineering

Introduction to OpenUP (Open Unified Process)

A UML Introduction Tutorial

Menouer Boubekeur, Gregory Provan

6. Software Lifecycle Models. A software lifecycle model is a standardised format for planning organising, and running a new development project.

Requirements Management Practice Description

CHAPTER. Software Process Models

What Is the Rational Unified Process?

2. Analysis, Design and Implementation

Web Application Development Process

Software Engineering. Christopher Simpkins Chris Simpkins (Georgia Tech) CS 2340 Objects and Design CS / 16

Zen of VISIO Leona Rubin WebTechNY User Group Date: September, 2008

A Framework for Software Product Line Engineering

Fundamentals of Information Systems, Fifth Edition. Chapter 8 Systems Development

Software Engineering for Software-Intensive Systems: III The Development Life Cycle

What is a life cycle model?

Building an Effective Business Architecture & Metrics Capability

Outline. III The Development Life Cycle. Characteristics of Software Development Methodologies. The Prototyping Process

A Survey of Plan-Driven Development Methodologies

A Software Engineering Approach For GIS Developing

How To Model Software Development Life Cycle Models

Agile Modeling: A Brief Overview

Software Development Life Cycle (SDLC)

ISO 9001:2000 Its Impact on Software

TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW

Title: Topic 3 Software process models (Topic03 Slide 1).

(Refer Slide Time: 01:52)

Quality Assurance Software Development Processes

<Project Name> Configuration Management Plan

Course Computer Science Academic year 2012/2013 Subject Software Engineering II ECTS 6

RUP Design. Purpose of Analysis & Design. Analysis & Design Workflow. Define Candidate Architecture. Create Initial Architecture Sketch

Transitioning from Requirements to Design

How To Write An Slcm Project Plan

REVIEW ON THE EFFECTIVENESS OF AGILE UNIFIED PROCESS IN SOFTWARE DEVELOPMENT WITH VAGUE SYSTEM REQUIREMENTS

Course Registration Case Study

Information systems modelling UML and service description languages

COMPARATIVE STUDY ON SOFTWARE PROJECT MANAGEMENT MODELS

6 Contracts and Scenarios in the Software Development Process

AN EVOLUTION PROCESS FOR SERVICE-ORIENTED SYSTEMS

Transitioning Your Software Process To Agile Jeffery Payne Chief Executive Officer Coveros, Inc.

RUP iteration planning

Corso di Laurea Magistrale in Informatica, Università di Padova Tecnologie open-source, Anno accademico 2010/2011. Development Processes 1 / 51

A Rational Software Corporation White Paper

Time Monitoring Tool Software Development Plan. Version <1.1>

JOURNAL OF OBJECT TECHNOLOGY

CMMI and IBM Rational Unified Process

Engineering Process Software Qualities Software Architectural Design

Appendix 2-A. Application and System Development Requirements

Points of Defect Creation

Universiti Teknologi MARA. Requirement Analysis Using UML Approach for Research Management System (RMS)

Transcription:

Unified Software Development Process (3C05/D22) Unit 5: USDP Objectives: Introduce the main concepts of iterative and incremental development Discuss the main USDP phases USDP USDP is an industry standard software development process Free! The generic process for the UML USDP is: Use-case and risk driven Architecture centric Iterative and incremental For reference: Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. Addison Wesley. 1999 1

USDP for your project USDP is a generic software engineering process. It has to be customised (instantiated) for your project: In-house standards Document templates Tools Databases Lifecycle modifications Rational Unified Process is an instantiation of USDP. RUP is a product marketed and owned by IBM Software. RUP also has to be instantiated for your project! Iterations Iterations are the key to the USDP Each iteration is like a mini-project including: Planning Analysis and design Integration and test An internal or external release The result of an iteration is an increment We arrive at a final product release through a sequence of iterations Iterations contain workflows Iterations are organised into phases Iteration Workflows USDP specifies 5 core workflows Requirements Analysis Design Implementation Test Planning Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the lifecycle (see later!) An iteration Specific Activities Assessment 2

Iterations may overlap Iteration 1 Iteration 2 In order to allow parallel development and flexible working in large teams, iterations can, and often do, overlap. In the example above, Iteration 1 overlaps significantly with iteration 2 Iteration 3 This requires careful planning Increments Each iteration generates internal (or external) releases of various artefacts which together constitute a baseline A baseline is a set of reviewed and approved artefacts that: Provides an agreed basis for further review and development Can be changed only through a formal procedure such as configuration and change management An increment is the difference between the release of one iteration and the release of the next The result of an iteration is an increment USDP Lifecycle The USDP lifecycle is divided into a sequence of phases Each phase may include many iterations The exact number of iterations per phase depends on the size of the project! One iteration per phase for small projects Each phase concludes with a major milestone 3

USDP Phases Milestone Life-cycle Objectives Life-cycle Architecture Initial Operational Capability Product Release Phase Iterations Iter 1 Iter 2 Iter 3 Iter 4 Iter 5 Iter 6 5 Core Workflows R A D I T The exact number of iterations per Phase depends on the size of the project! We have assumed a that this particular project lasts 18 months. Phases and Workflows Requirements Analysis Amount of work Design Implementation Test Preliminary Iterations I1 I2 In In+1 In+2 Im Im+1 Time for a typical project 10% 10% If we consider a project of typical difficulty, then this is how the total time for the project is likely to be distributed over the phases 50% 30% Inception Elaboration Construction Transition 4

Time for a difficult project 40% 7% 20% 33% If we consider a project of greater than normal difficulty, then this is how the total time for the project is likely to be distributed over the phases Note that for more difficult projects more time is spent in Inception the early phases Elaboration Construction Transition Resource for a typical project 10% 5% 20% Inception Elaboration Construction Transition If we consider a project of typical difficulty, then this is how the total resource for the project is likely to be utilised over the phases 65% Resource for a difficult project 8% 8% 24% Inception Elaboration Construction Transition If we consider a project of greater than normal difficulty, then this is how the total resource for the project is likely to be distributed over the phases Note that for more difficult projects more resource is used in the early phases 60% 5

Phases For each phase we will consider: The goal for the phase The focus in terms of the core workflows The milestone at the end of the phase Inception Inception - Goals Establish feasibility of the project Create a business case Capture key requirements Scope the system Identify critical risks Create proof of concept prototype 6

Phases and Workflows Requirements Analysis Amount of work Design Implementation Test Preliminary Iterations I1 I2 In In+1 In+2 Im Im+1 Inception - Focus Requirements establish business case, scope and core requirements Analysis establish feasibility Design design proof of concept or technical prototypes Implementation build the proof of concept prototype Test not generally applicable N.B. The blue bars indicate approximately the relative amount of resource needed Life Cycle Objectives Conditions of satisfaction: System scope has been defined Key requirements for the system have been captured. These have been defined and agreed with the stakeholders An architectural vision exists. This is just a sketch at this stage A Risk Assessment A Business Case Project feasibility is confirmed The stakeholders agree on the objectives of the project 7

Elaboration Elaboration - Goals Create an executable architectural baseline Refine Risk Assessment Define quality attributes (defect rates etc.) Capture use-cases to 80% of the functional requirements Create a detailed plan for the construction phase Formulate a bid which includes resources, time, equipment, staff and cost Phases and Workflows Requirements Analysis Amount of work Design Implementation Test Preliminary Iterations I1 I2 In In+1 In+2 Im Im+1 8

How many use-cases? Our goal is to find sufficient use-cases to allow us to build a system Aim to identify about 80% of the use-cases based on a consideration of functional requirements The other 20% will come out in later phases if important Aim to model in detail only about 40% to 80% of the set of identified use-cases For each use-case modelled in detail, only a small fraction of the possible scenarios may need to be modelled Model just enough use-cases to capture the information you need! Elaboration - Focus Requirements refine system scope and requirements Analysis establish what to build Design create a stable architecture Implementation build the architectural baseline Test test the architectural baseline Life Cycle Architecture Conditions of satisfaction: A resilient, robust executable architectural baseline has been created The Risk Assessment has been updated A project plan has been created to enable a realistic bid to be formulated The business case has been verified against the plan The stakeholders agree to continue 9

Construction Inception Elaboration Construction Transition Construction - Goals Completing use-case identification, description and realisation Finish analysis, design, implementation and test Maintain the integrity of the system architecture Revise the Risk Assessment Phases and Workflows Requirements Analysis Amount of work Design Implementation Test Preliminary Iterations I1 I2 In In+1 In+2 Im Im+1 10

Construction - Focus Requirements uncover any requirements that had been missed Analysis finish the analysis model Design finish the design model Implementation build the Initial Operational Capability Test test the Initial Operational Capability Plan for two lines of work About 10 to 20% of the resources will not contribute directly to the next release! Primary Tasks Next Release 80% Next Release Plan for this! Secondary Tasks 10-20% Primary and secondary tasks Primary tasks: Everything that contributes directly to the next increment Secondary tasks: Everything else! Attack risks with behavioural prototypes Solve critical problems with taskforces (tiger teams) Research into problem and solution domains Bug tracking and reporting 11

Initial Operational Capability Conditions of satisfaction: The product is ready for beta testing in the user environment Transition Transition - Goals Correct defects Prepare the users site for the new software Tailor the software to operate at the users site Modify software if unforeseen problems arise Create user manuals and other documentation Provide customer consultancy Conduct post project review 12

Phases and Workflows Requirements Analysis Amount of work Design Implementation Test Preliminary Iterations I1 I2 In In+1 In+2 Im Im+1 Transition - Focus Requirements not applicable Analysis not applicable Design modify the design if problems emerge in beta testing Implementation tailor the software for the users site and correct problems uncovered in beta testing Test beta testing and acceptance testing at the users site Product Release Conditions of satisfaction: Beta testing, acceptance testing and defect repair are finished The product is released into the user community 13

Key Points USDP is the iterative and incremental software engineering process for the UML USDP has four phases: Inception Elaboration Construction Transition Each phase may have one or more iterations Each iteration has five iteration workflows Requirements, Analysis, Design, Implementation,Test 14