11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Wolfram Webers wewo@ihh.hj.se

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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

Wolfram Webers

October, 2008

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Wolfram Webers

October, 2008

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Problems can be divided into two categories

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

Those concerned with the management of the project Those concerned with the poor quality of the delivered product

identify ideas towards possible solutions provide solutions realize solutions

Wolfram Webers

October, 2008

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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

Feedback loops do not solve the main problem

Eg. Unresponsive to changing requirements

They are by no mean iterative, but incremental Can lead to ad-hoc coding

Wolfram Webers

October, 2008

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Systems engineering Requirements analysis Design Construction Testing Installation Maintenance

Wolfram Webers October, 2008 6

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Prototyping involves iterations during the system development Prototypes are partial solutions of the final system

Danger:

Just the user interface (Lo-fi prototype) Limited data processing (Hi-fi prototype) Limited operational functions (Hi-fi prototype)

prototypes can be assumed as the final product after the prototype is discarded, the development efforts so far is wasted time

Wolfram Webers

October, 2008

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

The main stages of prototyping are:

The last three stages involve iterations

Perform an initial analysis Define prototype objectives Specify prototype Construct prototype Evaluate prototype and recommend changes

Wolfram Webers

October, 2008

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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

Wolfram Webers

October, 2008

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

The UP reflects the current emphasis on iterative and incremental lifecycles Is built upon spiral model

Inception Elaboration Construction Transition

Idea

Architecture

Prototype
Wolfram Webers

Product
October, 2008 10

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Four main phases in the lifecycle

Inception Elaboration
Approximate vision, business case, scope, vague estimates

Construction Transition

Refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates Iterative implementation of the remaining lower risk and easier elements, preparation for deployment Beta test, deployment

Wolfram Webers

October, 2008

11

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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
Development Cycle Iteration Phase

Inception

Elaboration

Construction

Transition

Wolfram Webers

October, 2008

12

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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

Wolfram Webers

October, 2008

13

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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

Requirements

Derived the system requirements needed to support the organisation

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

Wolfram Webers

October, 2008

14

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Analysis and Design

Implementation

Translate requirements into specification describing how to implement the system Select the best implementation strategy Adjust the design to match performance, scalability, robustness, etc. Define organisation of the code (implementation modules) Implement classes and objects in terms of components Test components as units Integrate into an executable system
Wolfram Webers October, 2008 15

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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

Wolfram Webers

October, 2008

16

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Business Modelling Requirements Analysis & Design Implementation Test Deployment

Relative effort in an iteration

Project Management Environment Iteration

Wolfram Webers

October, 2008

17

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Discipline

Artifact

Incep.

Elab. s

Const.

Trans.

Business Modelling Domain Model Requirements Use Case Model Vision Supplementary Specification Glossary Analysis & Design Design Model (opt. Analysis Model) SW Architecture Document Data Model Implementation Project Management Testing Implementation Model SW Development Plan Test Model s s s s s

r r r r s s s s r s r r r r r r r

s=Start, r=Revise
Wolfram Webers October, 2008 18

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Derivates:

Rational Unified Process (RUP)

Critics towards RUP:
Its heavy and big Its expensive and produces a lot of artifacts Its hard to tailor it down to smaller projects

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

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

Wolfram Webers

October, 2008

19

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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

Wolfram Webers

October, 2008

20

10

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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.

Wolfram Webers

October, 2008

21

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

User Stories:

Architecture Spikes: Release Planning:

customer defines use cases; basis for release planning and acceptance testing spike solutions are created to figure out answers to tough technical or design problems based on user stories; sequence of realisation of the stories, small releases

Wolfram Webers

October, 2008

22

11

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Iteration Planning:

Iterative Development: Development:

based on the release planning, each iteration is planned a dozen iterations of 1 to 3 weeks length Daily stand-up meetings, collective code ownership, pair programming, daily integration tests, merciless refactoring

Customer is always available during development and planning

Wolfram Webers

October, 2008

23

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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

Wolfram Webers

October, 2008

24

12

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

XP release cycle

Wolfram Webers

October, 2008

25

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Story card for downloading a document

Wolfram Webers

October, 2008

26

13

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Task card for downloading a document

Wolfram Webers

October, 2008

27

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Strengths:

Weaknesses:

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) Customer has to fulfil both user and client roles Increased productivity (pair programming) Continuous integration of customer
Wolfram Webers

Under discussion (strength or weakness):

October, 2008

28

14

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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, UImock-up (lo-fi-prototypes)

Wolfram Webers

October, 2008

29

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Wolfram Webers

October, 2008

30

15

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Requirements Analyst

Prototype Designer

Project Initiation Document

Elicit Requirements

Develop Prototypes Glossary

Interface Prototype

Candidate Requirements Select Requirements

Requirements List

Evaluate Prototypes

Develop Use Cases Use Case Model

System Architect

Develop Architecture

Initial System Architecture

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Requirements Model
Use Case Model

Requirements Team

Identify use case collaboration

Use Case Collaborations Requirements List Prepare communication diagrams Communication Diagams Prepare use case class diagrams Use Case Class Diagrams

Interface Prototype

Initial System Architecture Prepare analysis class diagrams Glossary

Analysis Class Diagrams

16

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

For enhancing the analysis modes by classes, we need to Useful stereotypes for analysis classes
Boundary classes: <<boundary>> Entity classes: <<entity>>
are used to present an interface to the users/actors are used to represent arbitrary entities used by the system are used to represent control-mechanisms inside the system

determine classes assign operations to classes

Control classes: <<control>>

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Category People Organizations Structures Physical things Abstractions of people Abstractions of physical things Conceptual things Enduring relationships between members of other categogies

Examples Mr. Harmsworth Jones & Co, DfS AB Team, project, assembly truck, drill, t-shirt Employee, supervisor, customer, client Wheeled vehicle, hand tool Campaign, employee, rule, team, project Sale, purchase, contract, campaign, agreement, assembly

17

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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

Class Name: Responsibilities: Responsibilities of the class are listed up here Collaborations: Collaborations with other classes are listed up here, together with a brief description of the purpose of the collaboration

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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 classes Design by contract The detailed interaction between classes can further be defined by communication diagrams

18

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

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

Wolfram Webers

October, 2008

37

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

An activity is made of actions Actions can be decomposed into subdiagrams Actions can be implemented as methods (class::method) Its also possible to annotate actions with code

Receive Order

Fill Order

Send Invoice

[priority order]

[else]

Overnight Delivery

Regular Delivery

Receive Payment

Close Order

Source: Fowler (2004)

Wolfram Webers

October, 2008

38

19

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Receive Order

Fill Order
Delivery Order

Send Invoice

[else]

Regular Delivery

Order
Overnight Delivery

Order
[priority order]

Deliver Order

Fill Order

Close Order

Source: Fowler (2004)

Wolfram Webers

October, 2008

39

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY
Fullfillment Customer Service Finance

With partitioning, we can assign responsibilities:

General concepts Classes
Fill Order

Receive Order

Send Invoice

Deliver Order

Receive Payment

Close Order

Source: Fowler (2004)

Wolfram Webers

October, 2008

40

20

11/4/09

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Actions can accept and/or send signals/events Accepting events means always listening for them

Two hours before ight

Reserve itinerary

Triggering input signal

Timer signal

Output signal

Pack bags Leave for airport

Taxi Arrives

Itinerary confirmed Send itinerary

Book itinerary

Cancel itinerary

Source: Fowler (2004)

Wait 48 hours
Wolfram Webers October, 2008 41

JNKPING INTERNATIONAL BUSINESS SCHOOL

JNKPING UNIVERSITY

Chapter 6, 7, examples in A3 Until the Design-Lecture: A4

Read those chapters. You will recognize many things you already did during the exercise. 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

Wolfram Webers

October, 2008

42

21