Unit 5: Unified Software Development Process. 3C05: Unified Software Development Process USDP. USDP for your project. Iteration Workflows.

Similar documents
Object-Oriented Design

Software Maintenance Cycles with the RUP

Object-oriented Analysis and Design

About Software Engineering.

UNIT-III LIFE-CYCLE PHASES

Software Life Cycle Models

Model-Based Systems Engineering Methodologies. J. Bermejo Autonomous Systems Laboratory (ASLab)

Requirements Gathering using Object- Oriented Models

IECI Chapter Japan Series Vol. 5 No. 2, 2003 ISSN

IS 525 Chapter 2. Methodology Dr. Nesrine Zemirli

SWEN 256 Software Process & Project Management

UNIT VIII SYSTEM METHODOLOGY 2014

Towards an MDA-based development methodology 1

EGS-CC. System Engineering Team. Commonality of Ground Systems. Executive Summary

CC532 Collaborative System Design

Understanding Requirements. Slides copyright 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman. For non-profit educational use only

Course Outline Department of Computing Science Faculty of Science

Federico Forti, Erdi Izgi, Varalika Rathore, Francesco Forti

Agile Non-Agile. Previously on Software Engineering

Towards Integrated System and Software Modeling for Embedded Systems

Software LEIC/LETI. Lecture 21

Requirements Analysis aka Requirements Engineering. Requirements Elicitation Process

Requirement Definition

AOSE Technical Forum Group

UNIT IV SOFTWARE PROCESSES & TESTING SOFTWARE PROCESS - DEFINITION AND IMPLEMENTATION

The Rational Unified Process: An Introduction (2nd Edition) By Philippe Kruchten

OCEAN OBSERVATORIES INITIATIVE. Release 2 Schedule. OOI CI Release 2 Kickoff M a y 2,

Socio-cognitive Engineering

CHAPTER 1: INTRODUCTION TO SOFTWARE ENGINEERING DESIGN

Arcade Game Maker Product Line Requirements Model

An introduction to software development. Dr. C. Constantinides, P.Eng. Computer Science and Software Engineering Concordia University

A Conceptual Model of Software Development

Chapter 7 Requirements Engineering

IBM Software Group. Mastering Requirements Management with Use Cases Module 2: Introduction to RMUC

3.6 Implementation. Dr. Tarek A. Tutunji Philadelphia University, Jordan. Engineering Skills, Philadelphia University

in the New Zealand Curriculum

TECHNICAL AND OPERATIONAL NOTE ON CHANGE MANAGEMENT OF GAMBLING TECHNICAL SYSTEMS AND APPROVAL OF THE SUBSTANTIAL CHANGES TO CRITICAL COMPONENTS.

Moonzoo Kim. KAIST CS350 Intro. to SE Spring

A Mashup of Techniques to Create Reference Architectures

R3ST for Requirements Recovery of Legacy Runtime Code

Software-Intensive Systems Producibility

ACE3 Working Group Session, March 2, 2005

A FRAMEWORK FOR PERFORMING V&V WITHIN REUSE-BASED SOFTWARE ENGINEERING

Methodology for Agent-Oriented Software

Component Based Mechatronics Modelling Methodology

Score grid for SBO projects with a societal finality version January 2018

UML and Patterns.book Page 52 Thursday, September 16, :48 PM

Pervasive Services Engineering for SOAs

Systems Engineering Process

ENGAGE MSU STUDENTS IN RESEARCH OF MODEL-BASED SYSTEMS ENGINEERING WITH APPLICATION TO NASA SOUNDING ROCKET MISSION

Grundlagen des Software Engineering Fundamentals of Software Engineering

Code Complete 2: A Decade of Advances in Software Construction Construx Software Builders, Inc. All Rights Reserved.

Refinement and Evolution Issues in Bridging Requirements and Architectures

Leading Systems Engineering Narratives

NZQA registered unit standard version 4 Page 1 of 5. Plan, construct, modify, and report on an electronic prototype

Design Science Research Methods. Prof. Dr. Roel Wieringa University of Twente, The Netherlands

COLLABORATIVE PRODUCT DESIGN AND DEVELOPMENT FOR COMMERCIALIZATION OF INVENTION

PROGRAM UNDERSTANDING TASK IN THE CONTEXT OF PSP

CSC2106S Requirements Engineering

CS Division of EECS Dept. KAIST

Understanding the Relations Between Iterative Cycles in Software Engineering

WORKSHOP ON BASIC RESEARCH: POLICY RELEVANT DEFINITIONS AND MEASUREMENT ISSUES PAPER. Holmenkollen Park Hotel, Oslo, Norway October 2001

ARTES Competitiveness & Growth Full Proposal. Requirements for the Content of the Technical Proposal. Part 3B Product Development Plan

Domain Understanding and Requirements Elicitation

oday, This is due in part to been influenced from one product release to the next how the product could be improved We want

Score grid for SBO projects with an economic finality version January 2019

Explicit Domain Knowledge in Software Engineering

learning progression diagrams

Engaging Innate Human Cognitive Capabilities to Coordinate Human Interruption in Human- Computer Interaction: The HAIL System

Agent-Oriented Software Engineering

The NHS England Assurance Framework: national report for consultation Chief Officer, Barnet Clinical Commissioning Group

Is Designing Independent of Domain? Comparing Models of Engineering, Software and Service Design

! Role of RE in software and systems engineering! Current techniques, notations, methods, processes and tools used in RE

Course Overview; Development Process

30 April 2 May 2018 ICC Sydney Unlocking the Future through Systems Engineering. sete2018.com.au. Ksenia Ivanova

By the end of this chapter, you should: Understand what is meant by engineering design. Understand the phases of the engineering design process.

Towards a Methodology for Designing Artificial Conscious Robotic Systems

GENERIC MODELLING USING UML EXTENSIONS FOR QUEENS CHALLENGE PUZZLE GAME FROM 1 TO 25 LEVELS SYSTEM

12/5/12. What is HCD?

A FORMAL METHOD FOR MAPPING SOFTWARE ENGINEERING PRACTICES TO ESSENCE

Lean Enablers for Managing Engineering Programs

Making It Your Own A PUBLIC ART POLICY AND PLANNING TEMPLATE. Arts North West Creative Opportunities 2012

Concurrent Increment Sequencing and Synchronization with Design Structure Matrices in Software- Intensive System Development

Final Project Report. Abstract. Document information

Are Rapid Fielding and Good Systems Engineering Mutually Exclusive?

INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 03 STOCKHOLM, AUGUST 19-21, 2003

Pre-commercial procurement in robotics HORIZON ICT 27(d)

Spiral Development: Experience, Principles, and Refinements

Interaction Design -ID. Unit 6

CSE - Annual Research Review. From Informal WinWin Agreements to Formalized Requirements

The Semantics of Innovation Exploring the deep nature of innovation IC3K, Rome, October 2014

The SONNETS Innovation Identification Framework

Computer Science: Who Cares? Computer Science: It Matters. Computer Science: Disciplines

Boxed Economy Simulation Platform and Foundation Model

Automated Software Engineering Writing Code to Help You Write Code. Gregory Gay CSCE Computing in the Modern World October 27, 2015

Benefits of Formal Specification Techniques in Software Development

Agent Oriented Software Engineering

Cognitive Systems Engineering

Enhancing Software Engineering Processes towards Sustainable Software Product Design

WNR Approach: An Extension to Requirements Engineering Lifecycle

Transcription:

Unit 5: Unified Software Development Process 3C05: Unified Software Development Process Objectives: Introduce the main concepts of iterative and incremental development Discuss the main USDP phases 1 2 USDP USDP for your project 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 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 Rational Corporation RUP also has to be instantiated for your project! 3 4 Iteration Workflows are the key to the USDP Each iteration is like a mini-project including: Planning 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 contain workflows are organised into phases 5 Planning Each iteration may contain all of the core workflows but with different emphasis depending on where the iteration is in the USDP specifies 5 core workflows lifecycle (see later!) An iteration Specific Activities Assessment 6 1

may overlap Increments 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 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 7 8 USDP Lifecycle USDP Phases 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 Milestone Phase Life-cycle Objectives Life-cycle Architecture Initial Operational Capability Product Release 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. 9 10 Phases and Workflows 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 30% Inception Elaboration Construction 50% 11 12 2

Time for a difficult project Resource for a typical project 40% 7% 20% 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 Inception Note that for more difficult Elaboration projects more time is spent Construction in the early phases 10% 5% 20% Inception Elaboration Construction 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 33% 65% 13 14 Resource for a difficult project Phases 8% 8% 24% Inception Note that for more difficult Elaboration projects more resource is Construction used in the early phases 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 For each phase we will consider: The goal for the phase The focus in terms of the core workflows 60% The milestone at the end of the phase 15 16 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 17 18 3

Phases and Workflows Inception - Focus establish business case, scope and core requirements establish feasibility design proof of concept or technical prototypes build the proof of concept prototype not generally applicable 19 N.B. The blue bars indicate approximately the relative amount of resource needed 20 Life Cycle Objectives Elaboration 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 21 22 Elaboration - Goals Phases and Workflows 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 23 24 4

How many use-cases? Elaboration - Focus 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 refine system scope and requirements establish what to build create a stable architecture build the architectural baseline test the architectural baseline Model just enough use-cases to capture the information you need! 25 26 Life Cycle Architecture Construction 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 27 28 Construction - Goals Phases and Workflows Completing use-case identification, description and realisation Finish analysis, design, implementation and test Maintain the integrity of the system architecture Revise the Risk Assessment 29 30 5

Construction - Focus Plan for two lines uncover any requirements that had been missed finish the analysis model About 10 to 20% of the resources will not contribute directly to the next release! finish the design model Primary Tasks Next Release 80% build the Initial Operational Capability test the Initial Operational Capability Plan for this! Secondary Tasks Next Release 10-20% 31 32 Primary and secondary tasks Initial Operational Capability 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 The product is ready for beta testing in the user environment Bug tracking and reporting 33 34 - 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 35 36 6

Phases and Workflows - Focus not applicable not applicable modify the design if problems emerge in beta testing tailor the software for the users site and correct problems uncovered in beta testing beta testing and acceptance testing at the users site 37 38 Product Release Key Points Beta testing, acceptance testing and defect repair are finished The product is released into the user community USDP is the iterative and incremental software engineering process for the UML USDP has four phases: Inception Elaboration Construction Each phase may have one or more iterations Each iteration has five iteration workflows,,,, 39 40 7