Development Processes

11/4/09

1

JÖNKÖPING INTERNATIONALBUSINESS SCHOOLJ Ö N K Ö P I N G U N I V E R S I T Y


Wolfram Webers [email protected]



  Analysis in the context of development processes (UP, RUP, XP)

  OOA (part 2)

October, 2008 2 Wolfram Webers

11/4/09

2



October, 2008 Wolfram Webers 3



  Problems can be divided into two categories ◦  Those concerned with the management of the project ◦  Those concerned with the poor quality of the delivered

product   It is useful to divide this “problem solving”

process into smaller steps ◦  Problem definition ◦  Data gathering ◦  Problem redefinition ◦  Finding ideas ◦  Finding solutions ◦  Implementation


Understand the problem

identify ideas towards possible solutions

provide solutions

realize solutions

11/4/09

3



  Lifecycle models are subdivision of processes   The waterfall model is one traditional

approach   It was developed late 1960s   Problem: Once a phase is finished you cannot

go back ◦  Eg. Unresponsive to changing requirements

  Feedback loops do not solve the main problem ◦  They are by no mean iterative, but incremental ◦  Can lead to “ad-hoc” coding





Systems engineering

Requirements analysis

Design

Construction

Testing

Installation

Maintenance

11/4/09

4



  Prototyping involves iterations during the system development

  Prototypes are partial solutions of the final system ◦  Just the user interface (Lo-fi prototype) ◦  Limited data processing (Hi-fi prototype) ◦  Limited operational functions (Hi-fi prototype)

  Danger: ◦  prototypes can be assumed as the final product ◦  after the prototype is discarded, the development

efforts so far is wasted time




  The main stages of prototyping are: ◦  Perform an initial analysis ◦  Define prototype objectives ◦  Specify prototype ◦  Construct prototype ◦  Evaluate prototype and recommend changes

  The last three stages involve iterations


11/4/09

5




Introduced by Barry Boehm in 1981 Similar activities as in waterfall model, but evolutionary approach and risk management added



  The UP reflects the current emphasis on iterative and incremental lifecycles

  Is built upon spiral model


TransitionConstructionElaborationInception

Idea Architecture Prototype Product

11/4/09

6



  Four main phases in the lifecycle ◦  Inception   Approximate vision, business case, scope, vague

estimates ◦  Elaboration   Refined vision, iterative implementation of the core

architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates

◦  Construction   Iterative implementation of the remaining lower risk

and easier elements, preparation for deployment ◦  Transition   Beta test, deployment




  Schedule oriented process ◦  Milestone: Iteration endpoint. Significant decision or evaluations ◦  Release: Stable executable subset of the final product ◦  Increment: Difference between releases of two subsequent

iterations ◦  Final Product Release: system is released for production use


Ince

ptio

n

Transition Construction Elaboration

Development Cycle

Phase Iteration

11/4/09

7



  Built upon disciplines   A discipline is: a set of activities (and related

artifacts) in one subject area   Some literatures replaces the term discipline

with workflow ◦  Business modeling ◦  Requirements ◦  Analysis and design ◦  Implementation ◦  Test ◦  Deployment




  Business modelling ◦  Understand the structure and the dynamics of the organisation ◦  Ensure that customers, end users, and developers have a common

understanding of the organisation ◦  Derived the system requirements needed to support the

organisation   Requirements ◦  Come to an agreement with customer what the system should

do ◦  Give developers a better understanding of the system

requirements ◦  Define the functionality of the system ◦  Provide a basis for planning of the technical contents of the

iterations ◦  Provide a basis for estimating cost and time to develop the

system ◦  Define a user interface for the system


11/4/09

8



  Analysis and Design ◦  Translate requirements into specification describing

how to implement the system ◦  Select the best implementation strategy ◦  Adjust the design to match performance, scalability,

robustness, etc.   Implementation ◦  Define organisation of the code (implementation

modules) ◦  Implement classes and objects in terms of

components ◦  Test components as units ◦  Integrate into an executable system




  Test ◦  Verify interaction between objects and

components ◦  Verify proper integration of all components ◦  Verify that all requirements have been correctly

implemented ◦  Identify defects; ensure defect removal before

deployment


11/4/09

9




Project Management

Requirements

Analysis & Design

Implementation

Test

Deployment

Environment

Business Modelling

Iteration

Relative effort in an iteration




Discipline Artifact Incep. Elab. Const. Trans.

Business Modelling Domain Model s

Requirements Use Case Model s r

Vision s r

Supplementary Specification

s r

Glossary s r Analysis & Design Design Model (opt. Analysis

Model) s r

SW Architecture Document s

Data Model s r

Implementation Implementation Model s r r

Project Management

SW Development Plan s r r r

Testing Test Model s r

s=Start, r=Revise

11/4/09

10



  Derivates: ◦  Rational Unified Process (RUP)   Critics towards RUP:

  It’s heavy and big   It’s expensive and produces a lot of artifacts   It’s hard to tailor it down to smaller projects

  These critics come mostly from people not understanding UP as a framework

◦  OpenUP (Eclipse Process Framework) ◦  EssUP (Essential UP, Ivar Jacobsson) ◦  AUP (Agile UP) ◦  OUP (Oracle UP)




  Introduced by Kent Beck in 2000   Extreme Programming (XP) takes an ‘extreme’

approach to iterative development: ◦  New versions may be built several times per day ◦  Increments are delivered to customers every 2

weeks ◦  All tests must be run for every build and the build is

only accepted if tests run successfully


11/4/09

11



  The Agile Manifesto ◦  Individuals and interactions over processes and

tools ◦  Working software over comprehensive

documentation ◦  Customer collaboration over contract negotiation ◦  Responding to change over following a plan

“[…] While there is value in the items on the right, we value the items on the left more. “




  User Stories: ◦  customer defines use cases; basis for release

planning and acceptance testing   Architecture Spikes: ◦  spike solutions are created to figure out answers to

tough technical or design problems   Release Planning: ◦  based on user stories; sequence of realisation of

the stories, small releases


11/4/09

12



  Iteration Planning: ◦  based on the release planning, each iteration is

planned   Iterative Development: ◦  a dozen iterations of 1 to 3 weeks length

  Development: ◦  Daily stand-up meetings, collective code

ownership, pair programming, daily integration tests, merciless refactoring

  Customer is always available during development and planning




  Requirements Scenarios ◦  In XP, user requirements are expressed as scenarios

or user stories ◦  These are written on cards and the development

team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates ◦  The customer chooses the stories for inclusion in

the next release based on their priorities and the schedule estimates


11/4/09

13



  XP release cycle




  Story card for downloading a document


11/4/09

14



  Task card for downloading a document




  Strengths: ◦  Customer intensively integrated in development

process ◦  Allows customer and developer to determine and to

react to risks at each evolutionary level ◦  Improved code quality (pair programming and unit

testing)   Weaknesses: ◦  Customer has to fulfil both user and client roles

  Under discussion (strength or weakness): ◦  Increased productivity (pair programming) ◦  Continuous integration of customer


11/4/09

15



  Structured methods ◦  SSADM (Structured System Analysis and Design Method)

  Waterfall model with the following stages   Analysis of the current system   Outline business specification   Detailed business specification   Logical data design   Logical process design   Physical design

  OO methods ◦  OOA: Object-Oriented Analysis

  Describe problem domain conceptually   Abstract from implementation constraints   Source can be written requirements specifications, interviews with

stakeholders, etc.   Result in what the system is functionally required to do

  Use cases, Class diagrams, Activity diagrams, Interaction diagrams, UI-mock-up (lo-fi-prototypes)





11/4/09

16



Requirements Analyst

Project Initiation Document

Requirements List

Glossary

Use Case Model

Candidate Requirements

Elicit Requirements

Select Requirements

Develop Use Cases

Prototype Designer

Interface Prototype

Develop Prototypes

Evaluate Prototypes

System Architect

Initial System Architecture

Develop Architecture



Requirements

Model

Use Case Model

Requirements List

Interface Prototype

Initial System Architecture

Glossary

Requirements Team

Identify use case collaboration

Prepare communication

diagrams

Prepare use case class diagrams

Prepare analysis class diagrams

Use Case Collaborations

Communication Diagams

Use Case Class Diagrams

Analysis Class Diagrams

11/4/09

17



  For enhancing the analysis modes by classes, we need to ◦  determine classes ◦  assign operations to classes

  Useful stereotypes for analysis classes ◦  Boundary classes: <<boundary>>   are used to present an interface to the users/actors ◦  Entity classes: <<entity>>   are used to represent arbitrary entities used by the system ◦  Control classes: <<control>>   are used to represent control-mechanisms inside the system



Category Examples People Mr. Harmsworth Organizations Jones & Co, DfS AB Structures Team, project, assembly Physical things truck, drill, t-shirt Abstractions of people Employee, supervisor, customer,

client Abstractions of physical things Wheeled vehicle, hand tool Conceptual things Campaign, employee, rule, team,

project Enduring relationships between members of other categogies

Sale, purchase, contract, campaign, agreement, assembly

11/4/09

18



  CRC cards can be used to determine classes   They are used by in role-playing session   During those session, the determined use-

cases are analyzed Class Name:

Responsibilities: Collaborations:

Responsibilities of the class are listed up here

Collaborations with other classes are listed up here, together with a brief description of the purpose of the collaboration



  A responsibility is a high level description of something a class can do

  They can also be seen as services they offer to other classes

  Responsibilities are later decomposed in operations during the design

  Thus, the definition of operations result in some kind of “contract” between classesDesign by contract

  The detailed interaction between classes can further be defined by communication diagrams

11/4/09

19



  As the name hints: We can model activities ◦  Procedural logics ◦  Workflows ◦  Business processes

  Activity diagrams are similar to data flow diagrams (DFD)

  The essential elements are: ◦  Start node, end node, actions, decisions, join/forks

and edges




  An activity is made of actions   Actions can be decomposed

into subdiagrams   Actions can be implemented

as methods(class::method)

  It‘s also possible toannotate actions with code


ReceiveOrder

FillOrder

SendInvoice

OvernightDelivery

RegularDelivery

ReceivePayment

[priority order] [else]

CloseOrder

Source: Fowler (2004)

11/4/09

20



Delivery Order

Order Order

OvernightDelivery

RegularDelivery

[priority order]

[else]


Receive

Order

Fill

Order

Send

Invoice

Fill

Order

Close

Order

Deliver

Order




  With partitioning, wecan assignresponsibilities: ◦  General concepts ◦  Classes


FinanceCustomer ServiceFullfillment

ReceiveOrder

FillOrder

SendInvoice

ReceivePayment

CloseOrder

DeliverOrder


11/4/09

21




  Actions can accept and/or send signals/events

  Accepting eventsmeans always listening for them

TaxiArrives

Pack bags

Two hours

before flight

Leave for airport

Reserve itinerary

Send itinerary

Book itinerary

Cancel itinerary

Wait 48 hours

Itineraryconfirmed


Triggering input signal

Output signal

Timer signal



  Chapter 6, 7, examples in A3 ◦  Read those chapters. You will recognize many

things you already did during the exercise.   Until the Design-Lecture: A4 ◦  Read the examples given in A4 to be prepared until

the design lecture. ◦  Consult the parts in the chapters before to learn

how to enhance your analysis model


Development Processes

Documents

Transcript of Development Processes