Next Generation Process - cs.tut.fi · Next Generation Process with Essential Modeling Ivar...

Next Generation Process with

Essential Modeling

Ivar Jacobsonwith

Pan Wei Ng and Ian [email protected]

[email protected]

2Essential Unified Process Primer / 01 - Essential Principles and Practices© 2005 Ivar Jacobson International

Agenda

• A new paradigm with several exciting innovations

• Practice separation – Essential UML

• Practice user experience using the card metaphor– Essential UML

• Developing software by playing games

• Final words


A Next Generation Process is not monolithic

From the successes in modern software

development

Agile Methods Camp

Unified Process Camp

Process Maturity Camp

In the future, an ever present but invisible process

Process becomes second nature

A new paradigm

Practice is a First Class Citizen

the unit of adoption, planning and execution of process

Practice Separation

Practice User

Experience

Practice Smartness

And the innovations of

a new paradigm


A Next Generation Process is not monolithic

From the successes in modern software

development

Agile Methods Camp

Unified Process Camp

Process Maturity Camp

In the future, an ever present but invisible process

Process becomes second nature

A new paradigm

Practice is a First Class Citizen

the unit of adoption, planning and execution of process

Practice Separation

Practice User

Experience

Practice Smartness

And the innovations of

a new paradigm

NEW


New paradigm must appeal to two distinct communities

Process engineers

• Experts who develop process content in the form of practices

• Have a deep understanding of process & practice structure etc

• Key needs: tailoring, extension and composition

“Process descriptions don’t need to be lengthy... Since there are lots of publications available, there is no need write a massive document.”

- Dave Thomas

Process users

• Practitioners who apply the process to a project

• Select practices & add them to their process

• Key needs: simplicity, ease of use, understandability


The Unified Process

Ericsson Approach

Objectory Process

Late ’60s

‘87 –’96

‘97 –’98

IBM Rational Unified Process

Really Good Software

‘99 –’05

Building on our heritage


However, there are challenges with UP based methods

• Unified Process is too heavy

• UP requires substantial investments in tools, training and mentoring

We need to attack these challenges

Find the knowledge

Learn the knowledge

Apply the knowledge

Control the use of

knowledge

Knowledge base is too big, how to find just the right stuff?

Knowledge base is too big, How to learn the stuff I need?

How to apply what I learn in a project?

How to manage project applying this stuff?What tools?


Being Agile goes without saying for a NGP

What characterizes an agile process 1. It includes social engineering patterns

• War-room

• Everything is owned by someone

• Developer sandboxes

• Pair development

2. It is lightweight– Tacit knowledge instead of explicit knowledge

3. It usually has some specific technical practices• User stories

• Test driven design

• Refactoring


Agenda





• Final words


What is a Practice?

Pragmatics• A Practice is a set of activities to give value to a particular stakeholder

of a software organization

• A Practice – explicit knowledge waiting to be put into action– A practice has a clear beginning and an end allowing it to be

independently applied

• Our practices are supplied as a set of cards and

guidelines defining a way of doing something

More precisely• A use-case module in our AOSD book

– It has a beginning and an end

– It may be a peer practice or extend an existing practice


The Practices in the Essential Unified Process

TechnicalPractices

Social Engineering Practices

Process Practices

Organizational Practices

Iteration

Component

Architecture Use Case

ModelingProcess Team

Title

Essential Practices

Product

Whe

re is

test

ing?

It is

Eve

ryw

here

!


Building a process eco-system around 8 Essential Practices

• There will be 100s of practices extending the essentials

PSP / TSP Pair Programming

Social Engineering Practices

Extended CMMI

6 Sigma Prince2

Process Practices

Organizational PracticesPortfolio

Management

ProgramManagement

Enterprise Architecture

Product Line Eng.

SOA

REUSE Model Driven Architecture

Systems Engineering Business Use-Case

Domain Modeling

Robustness Analysis

Aspect Orientation

Technical Practices

Iteration

Component



Title

Essential Practices

Product


Agenda





• Final words


Modeling Essentials Practice

• About using models to facilitate communication and produce useful documentation

• Focuses on establishing the appropriate style and type of models to drive development activities

• Enable software development teams to: – Communicate system requirements, structure and behavior

– Employ the right models to meet their needs

– Be agile in their approach to modeling and documentation

– Focus on the essentials, avoiding modeling paralysis and the production of unnecessary documentation

This is a cross-cutting practice that influences how the other practices are under-taken.


•Involve stakeholders in the decision making process•Ensure the product meets the real needs of the stakeholders

•Establish a firm foundation for the incremental development of the solution•Share the major decisions about the structure and organization of the implemented system

Modeling Essentials supports the other practice goals

ComponentUse CaseProduct Architecture

•Develop and verify the separate parts of the system independently and in parallel•Exploit third party frameworks and component libraries

•Work with customers to capture the essential requirements•Use a systematic approach to ensure the correct design, implementation and verification of requirements

Helps the other practices achieve their goals by establishing the appropriate style and type of models to drive the development activities


What about UML 2.0?

• The UML 2.0 Infrastructure defines the foundational language constructs required for UML 2.0. It is complemented by UML 2.0: Superstructure, which defines the user level constructs required for UML 2.0.• It is 218 pages long!

• The superstructure defines the six structure diagrams, three behavior diagrams, four interaction diagrams, and the elements that comprise them, and so is the part of the language that you'll encounter in UML 2.0 compliant tools.– It is 720 pages long!

Written by tool vendors for tool vendors!


What do practitioners want?

• To be able to easily communicate

• To model with or without tools

• To start with something simple

• A common language to communicate structure, behavior, ownership, packaging, dynamics and abstractions.

Is this something the UML gives us?


What do practitioners want?

• To be able to easily communicate

• To model with or without tools

• To start with something simple

• A common language to communicate structure, behavior, ownership, packaging, dynamics and abstractions.

Is this something the UML gives us?Well it

’s hiding in th

ere somewhere.

It’s th

e 20% that p

rovides 80% of the

value!


Where do practitioners start?

• The Superstructure and Infrastructure Specifications?

• The Meta-Model?

• The Kernel? (part of the superstructure)

• The Core? (part of the infrastructure)

• At the lowest UML Compliance Levels?– Level 0 – Entry Level Modeling Capability (formally defined in the

UML Infrastructure)

– Level 1 – Adds language units for use cases, interactions, structures and activities

– Level 2 – Adds language units for deployment, state machine modeling and profiles

– Level 3 – The complete UML – adds language units for modeling information flows, templates and model packaging


Then, should we use UML for modeling?

• Absolutely, positively, definitely YES …– UML is the standard for visual modeling of software systems

– It is a rare example of a universally popular and pervasive standard

– It has had a long and happy relationship with the Unified Process

• But ….– “UML is language with a very broad scope”

– “Not all of its modeling capabilities are necessarily useful in all domains or applications”

– UML is difficult for practitioners to approach and apply directly

• Essential UML focuses on the essential subset (the 20%) that is useful for any software development project


Where does Essential UML sit?

• It is an Extension to the Modeling Essentials Practice

EssentialUML

Iteration

Component



Title

Essential Practices

Product <<extend>>


Lets extract the essentials from the UML

<< imports >>

UML 2.0

The Essential UML presents the essence of the UML for use by

practitioners.

It depends on the UML 2.0 language definition and benefits from its rigor and completeness

EssentialUML


Extending the Essential UML Practice

Modeling

Modeling For That

<<extend>>

Modeling For This<<extend>>

Practice Area

Modeling

<<extend>>

EssentialUML


Essential UML elements and their applications

Establishing the collaborations required to realize a use caseCollaborations

Establishing a common understanding of what the system must do for its users

Use-Case Diagram

Distributing responsibilities to key abstractions and establishing collaborations between components, interfaces and classes

Interaction Diagrams

Describing lifecycles of key abstractions and dynamic behavior of components and classes

State Machine Diagram

Showing flow of control within interactions and operationsActivity Diagram

Communicating architecturally significant aspects of the deployment

Deployment Diagram

Structuring use-case, architecture, component and other modelsPackage Diagram

Defining component interfaces and establishing dependenciesComponent Diagram

Establishing key abstractions and designing componentsClass Diagram

Used toDiagram


Essential UML: Summary

• Gets to the heart of the UML

• Presented in the context of its application within essential software development practices

• A simple way to get started

• Just enough UML for most projects

• Built on top of the UML 2.0 specification

• A new way to promote and publicize the UML

A complement to UML 2.0 –Complements the Modeling Essentials Practice


Agenda





• Final words


Today, process descriptions are designed for process engineers

• Usually presented in books, web pages.– Nobody reads.

• Not handy, not easy to work with them, etc.– Can be divorced from reality

Law of Nature:Most People don’t read Manuals, etc.


Apply card game metaphor for practice descriptions

• A card contains concise description of things to produce and things to do, etc.

• A practice is a set of cards

• A team/individual works on a set of instance cards

Essen

tial U

nifie

d Pro

cess

©Iv

ar J

acob

son

Inte

rnat

iona

l, 20

06

revis

ion

24

A test

cas

e def

ines

a s

et o

f tes

t inpu

ts a

nd

expe

cted

resu

lts fo

r the

purp

ose o

f

eval

uatin

g w

hethe

r or n

ot a

sys

tem

corr

ectly

imple

men

ts a

spe

cific

sce

nario

.

Test

Cas

e

UCDD

Test

cas

es:

•Pro

vide

a fo

undat

ion

for d

esig

ning

and

impl

emen

ting

test

s

•Allo

w th

e co

mpl

etio

n of s

yste

m

spec

ifica

tion

•Allo

w te

sts

to b

e sp

ecifi

ed b

efor

e

impl

emen

tatio

n st

arts

Essen

tial C

onte

nts:

•1.

.n P

re-c

ondi

tions

for t

est

•1.

.n In

put

•1.

.n E

xpec

ted

Resul

ts

Refer

ence

s to

:

•1.

.n U

se-C

ase

Flow

s (d

efin

ing a

scen

ario

to b

e te

sted

)

Scena

rio

Chose

n

Test D

ata

and

Resul

ts D

efin

edVar

iabl

es

Defin

ed

Speci

fied

Syste

m

Ess

entia

l Uni

fied

Pro

cess

©Iv

ar J

acob

son

Inte

rnat

iona

l, 20

06

revi

sion

24

Spe

cify

Tes

t

Spe

cify

a t

est t

o:

•V

erif

y th

at t

he e

xecu

tab

le s

yste

m

per

form

s as

sp

ecif

ied

•D

efin

e h

ow th

e ou

tco

mes

of t

he

test

s ar

e

eval

uate

d t

o d

eter

min

e th

e te

st r

esu

lts

•F

ocus

the

dev

elo

pmen

t o

f the

so

ftw

are

tow

ards

th

e te

sts

it m

ust

mee

t

The

acti

vity

is c

omp

lete

d w

hen

:

•Te

st:

Sp

ecifi

ed

•Te

st S

pec

ific

atio

n: T

est C

ases

Iden

tifie

d

or

bey

ond

Rec

om

men

ded

ap

pro

ach

es:

•In

dep

end

ent s

yste

m te

st

•R

egre

ssio

n te

st

•In

tegr

atio

n t

est

UC

DD

Test

er

Exe

cuta

ble

Sys

tem

Spe

cifie

d

Sys

tem

Bac

klog

Dev

elop

er

Pro

ject

Lea

d

Tes

t

Sp

ecif

icat

ion

Tes

t

Inte

gra

te a

nd

Tes

t

Exe

cuta

ble

Sys

tem

Ess

entia

l Uni

fied

Pro

cess

©Iv

ar J

acob

son

Inte

rnat

iona

l, 20

06

revi

sion

24

Sp

ecif

ied

Sys

tem

Tra

ck P

rog

ress

Co

mp

are

actu

al p

rog

ress

wit

h t

he

pla

n t

o:

•Q

uic

kly

iden

tify

pro

ble

m a

reas

•U

nd

erst

and

pro

gre

ss a

nd

vel

oci

ty

•P

red

ict

mile

sto

ne

com

ple

tio

n

•A

sses

s m

ilest

on

e ac

hie

vem

ents

Th

e ac

tivi

ty is

co

mp

lete

d w

hen

:

•T

est

Res

ult

s: E

valu

ated

•B

ackl

og

item

s ad

dre

ssed

(su

ch a

s

scen

ario

s an

d d

efec

ts)

hav

e b

een

mar

ked

as

Ver

ifie

d

•T

he

Use

-Cas

e M

od

ule

flo

ws

add

ress

ed

hav

e b

een

mar

ked

as

Ver

ifie

d

•M

ilest

on

e ac

hie

vem

ent

has

bee

n

reco

rded

an

d t

eam

vel

oci

ty i

s kn

ow

n

Rec

om

men

ded

ap

pro

ach

es:

•C

on

tin

uo

us

pro

gre

ss t

rack

ing

•D

emo

nst

rate

res

ult

s re

gu

larl

y

UC

DD

Bac

klo

g

Dev

elop

er

An

alys

t

Pro

ject

Lea

d

Tes

ter

Use

-Cas

e

Mo

du

le

Bac

klog

Exe

cuta

ble

Sys

tem

Tes

t

Res

ult

s

Sp

ecif

ied

Sys

tem

Bac

klo

g

Exe

cuta

ble

Sys

tem

Ste

er P

roje

ct

Ess

entia

l Un

ified

Pro

cess

©Iv

ar J

aco

bso

n In

tern

atio

nal,

200

6

revi

sio

n 2

4

A u

se-c

ase

spec

ific

atio

n d

esc

rib

es h

ow

an a

cto

r u

ses

a s

yste

m t

o a

chie

ve

a g

oal

and

wh

at t

he

sys

tem

do

es

for

the

acto

r to

ach

iev

e th

at g

oal

.U

se-c

ase

spec

ific

atio

ns:

•C

aptu

re r

eq

uir

emen

ts i

n c

on

text

•D

efin

e sc

en

ario

s•

En

able

eff

ect

ive

sco

pe

man

agem

ent

•P

rovi

de

the

det

ail t

o d

rive

th

e o

ther

dev

elo

pm

ent

acti

viti

es a

nd

en

sure

th

at

the

y d

eliv

er

valu

e

Brie

fly D

escr

ibed

Ess

entia

l Out

line

Ful

ly D

escr

ibed

Bul

lete

d O

utlin

eUse

-Cas

e S

pec

ific

atio

nU

CD

D

Individual Flows may have different degrees of elaboration

Ess

enti

al C

on

ten

ts:

•1

Nam

e•

1 B

rie

f D

escr

ipti

on

•1

Bas

ic F

low

•0.

.n A

lter

nat

ive

Flo

ws

Sp

eci

fied

Sys

tem

Ess

entia

l Uni

fied

Pro

cess

©Iv

ar J

acob

son

Inte

rnat

iona

l, 20

06

revi

sion

24

Exe

cute

Tes

t

Tes

ter

Exe

cute

a te

st to

:

•V

erif

y th

at th

e ex

ecu

tabl

e sy

stem

mee

ts

the

eval

uati

on c

rite

ria

of t

he te

st

•Id

enti

fy d

efec

ts a

nd p

lace

in th

e ba

cklo

g

to e

nsu

re t

hat

they

are

add

ress

ed

The

activ

ity

is c

ompl

eted

whe

n:

•Te

st:

Eva

luat

ed

•A

ny

Def

ects

: Id

entif

ied

and

adde

d to

the

Bac

klog

•Te

st R

esu

lts:

An

alyz

ed

Rec

omm

end

ed a

ppro

ache

s:

•A

uto

mat

ed te

stin

g

•P

rogr

amm

atic

tes

ting

•M

anua

l tes

ting

UC

DD

Exe

cuta

ble

Sys

tem

Sp

ecif

ied

S

yste

m

Bac

klo

g

Tes

t R

esu

lts

Tes

t

Exe

cuta

ble

Sys

tem

Bac

klo

g

Def

ect

Inte

gra

te a

nd

Tes

t

Dev

elop

er

Essen

tial U

nified

Pro

cess

©Iva

r Jac

obso

n Int

erna

tiona

l, 200

6

revis

ion 2

4

Skille

d at g

ather

ing a

nd com

munic

atin

g

stak

ehold

er n

eeds.

Has

a th

orough

knowle

dge of t

he dom

ain in

whic

h the

solu

tion w

ill b

e dep

loye

d.

Custom

er R

epre

senta

tive

Custom

er re

prese

ntativ

es h

elp th

e te

am to

:

•Def

ine

priorit

ies

•Id

entif

y sta

kehold

ers

•Under

stan

d the

busines

s opportu

nity

•Under

stan

d the

proble

ms

and n

eeds

of

the

stak

ehold

ers

•Cap

ture

and e

valu

ate

the

require

men

ts

•Val

idat

e th

e del

iver

ed s

yste

m

Essen

tial S

kills

:

•Dom

ain k

nowledge

•Com

munic

atio

n ski

lls

•Build

s tru

st

•Cap

able

of p

artic

ipat

ing in

model

ing

sess

ions

Subje

ct M

atte

r

Exper

t

Amba

ssad

or

User

Projec

t

Adviso

r

Active

ly M

anag

es

Scope

Directs

the

Busine

ss

UCDD

* Ward Cunningham invented CRC cards,

published in 1989


The Essentials are in the cards


More are in the guidelines

I dotest cases

Reference books

Intelligent Agents

RUP Knowledge Base


Intelligent Agents

• Learn about Intelligent Agents and how they support software development at www.jaczone.com

I am an intelligent agent.I have knowledge.I am autonomous.I am goal-oriented.

JACZONEWayPointer


Agenda





• Final words


The Essential UML are also in the cards

Essential UML © Ivar Jacobson International, 2006 revision 11

Implemented System

A component diagram is used to show:• Components in a system and the

interfaces that they implement• The dependencies that a component

has on other component interfaces

Component Diagram

Essential Contents:• Components – a unit of software that

implements a set of interfaces• Ports – interaction points with well-

defined interfaces• Provided Interfaces – sets of services

made available by the component• Required Interfaces – sets of services

required by the component• Dependency Relationships – use of a

component or interface by a component

Recommended Stereotypes:

• <<subsystem>> – A course-grained system component

Essentials

component

component

port

provided interfaceon port

required interfaceon port

component

required interface

provided interface

dependencyrelationship


More is in the guidelines

I doComponent Modeling

Reference books

Intelligent Agents

Essential Unified Process © Ivar Jacobson International, 2006 revision 11

Implemented System

A component diagram is used to show:

• Components in a system and the interfaces that they implement

• The dependencies that a component has on other component interfaces

Component Diagram

Essential Contents:

• Components – a unit of software that implements a set of interfaces

• Ports – interaction points with well-defined interfaces

• Provided Interfaces – sets of services made available by the component

• Required Interfaces – sets of services required by the component

• Dependency Relationships – use of a component or interface by a component



Essentials

component

component

port



component

required interface

provided interface



Implemented System

A component diagram is used to show:

• Components in a system and the interfaces that they implement

• The dependencies that a component has on other component interfaces

Component Diagram

Essential Contents:

• Components – a unit of software that implements a set of interfaces

• Ports – interaction points with well-defined interfaces

• Provided Interfaces – sets of services made available by the component

• Required Interfaces – sets of services required by the component

• Dependency Relationships – use of a component or interface by a component



Essentials

component

component

port



component

required interface

provided interface



Agenda





• Final words


What is the game?

GoodSoftware

Current Situation

andOpportunity

How do we produce good software, quickly?


Surely process is the answer…..

GoodSoftware

Current Situation

andOpportunity

… a list of things to address



GoodSoftware

Current Situation

andOpportunity

… and a map would be useful



GoodSoftware

Current Situation

andOpportunity

… and an understanding of the skills needed


And the rules of the games we are playing

Select Practices and Assemble a Process[Process Improvement Game]

Use the Process to Plan the Project[Planning Game]

Use a Practice in a Project[Development Game]

GoodSoftware

Current Situation

andOpportunity

Three collaborating games.All made simpler by the practices and the cards.


The Process Kernel – Controlling the Games

• A practice independent micro-process

• Where we are going – alphas

• What we are doing – activity spaces

• What skills do we need - competencies

Things

to P

roduce

@ Key Generic Artifacts

Things

to D

o

@ Key Generic Activities

Compet

enci

es


Opportunity

Backlog Project

SpecifiedSystem

Implemented System

ExecutableSystem

Way of Working

Team

The Process Kernel…. Eight Top Alphas


Their states tell you where you are


Lifecycle Patterns – Adding control and milestones

Inception Elaboration Construction TransitionInception Elaboration Construction Transition

Architecture Life-Cycle - Initial Operating

Capability Life Cycle Objectives

Product Release

TimeTime

Do you understand scope and risk, and do you have a candidate architecture and a credible plan?

Do you understand scope and risk,

Project Viability Agreed Selected Approach Proven

Do you have a solution that is proven to work?

Is the product working and useable, are the users ready to receive it?

Useable Solution Available

Is the product acceptable and is the development project over?

Development Completed

• The Unified Process lifecycle adding control structures to a release cycle

LifecyclePatterns


Inception Target States

Specified System

Opportunity

Problem Understood

ViabilityEstablished

Problem Addressed

Benefit Accrued

ValueEstablished

Opportunity Identified

Executable System

Assembled

FunctionalityValidated

Ready to Deploy

Accepted

ApproachValidated

Operational

Key

Essential

Recommended

Project

Underway

Risks UnderControl

DevelopmentComplete

ResponsibilitiesHanded Over

MilestonesAgreed

Closed

Conceived

Stable

Correct

Testable

Shared

Fulfilled

Implemented System

Approach Selected

InterfacesStable

Integrated

Production QualityRelease Available

ApproachConfirmed

Released

Backlog

Set Up

Change UnderControl

Quality GoalsMet

Sufficient WorkCompleted

Driving Work

Outstanding ItemsHanded Over

Way of WorkingTeam

Mission Defined

Focused

Collaborating

Formed

Disbanded

Gaps Analyzed

EssentialsIn Place

Embedded

Options Explored

Handed Over

LifecyclePatterns


Elaboration Target States

Specified System

Opportunity

Problem Understood


Problem Addressed

Benefit Accrued

ValueEstablished


Executable System

Assembled


Ready to Deploy

Accepted

ApproachValidated

Operational

Key

Essential

Recommended

Project

Underway

Risks UnderControl

DevelopmentComplete


MilestonesAgreed

Closed

Conceived

Stable

Correct

Testable

Shared

Fulfilled

Implemented System

Approach Selected

InterfacesStable

Integrated


ApproachConfirmed

Released

Backlog

Set Up

Change UnderControl

Quality GoalsMet


Driving Work


Way of WorkingTeam

Mission Defined

Focused

Collaborating

Formed

Disbanded

Gaps Analyzed

EssentialsIn Place

Embedded

Options Explored

Handed Over

LifecyclePatterns


Construction Target States

Specified System

Opportunity

Problem Understood


Problem Addressed

Benefit Accrued

ValueEstablished


Executable System

Assembled


Ready to Deploy

Accepted

ApproachValidated

Operational

Key

Essential

Recommended

Project

Underway

Risks UnderControl

DevelopmentComplete


MilestonesAgreed

Closed

Conceived

Stable

Correct

Testable

Shared

Fulfilled

Implemented System

Approach Selected

InterfacesStable

Integrated


ApproachConfirmed

Released

Backlog

Set Up

Change UnderControl

Quality GoalsMet


Driving Work


Way of WorkingTeam

Mission Defined

Focused

Collaborating

Formed

Disbanded

Gaps Analyzed

EssentialsIn Place

Embedded

Options Explored

Handed Over

LifecyclePatterns


Transition Target States

Specified System

Opportunity

Problem Understood


Problem Addressed

Benefit Accrued

ValueEstablished


Executable System

Assembled


Ready to Deploy

Accepted

ApproachValidated

Operational

Key

Essential

Recommended

Project

Underway

Risks UnderControl

DevelopmentComplete


MilestonesAgreed

Closed

Conceived

Stable

Correct

Testable

Shared

Fulfilled

Implemented System

Approach Selected

InterfacesStable

Integrated


ApproachConfirmed

Released

Backlog

Set Up

Change UnderControl

Quality GoalsMet


Driving Work


Way of WorkingTeam

Mission Defined

Focused

Collaborating

Formed

Disbanded

Gaps Analyzed

EssentialsIn Place

Embedded

Options Explored

Handed Over

LifecyclePatterns


Using alpha states to monitor progress and health

Opportunity

Backlog Project

SpecifiedSystem

Implemented System

ExecutableSystem

Way of Working

Team

LifecyclePatterns

Actual State

Planned State


Let us start where we always started…


Use the Process Cards to Plan the Project[Planning Game]


GoodSoftware

Current Situation

andOpportunity

Assemble a lightweight process


Play your cards to assemble your process

• What are you going to produce (artifacts)

• What skills do you need?

• What are you going to do (activities)?

• What do you do already?

PracticePracticePracticePractice

Add

Sta

rt h

ere

Fin

ish

her

e

Game Board

You need a Game Board


The Game Board is a Start

In more detail ... The Game Board is initially a process independent Kernel

Sta

rt h

ere

Fin

ish

her

e

Game Board

Compet

enci

es

Things

to P

roduce

@ Key Generic Artifacts

Things

to D

o

@ Key Generic Activities


Populate it with your existing process….

People,Processes,

Current Practices

Your Process

Align

Sta

rt h

ere

Fin

ish

her

e

Game Board

• Describe your own practices using the game board ...

• ...and write your own cards, add them to the game board

• Then select which Essential Practices to use and add to the game board


Understand the Need

Ensure Stakeholder Satisfaction

Accept the System

Establish Project Support Team Conclude ProjectSteer Project

Specifythe System

Shape theSystem

Implement Software

Test theSystem

Releasethe System


Understand the Need

Ensure Stakeholder Satisfaction

Accept the System

Establish Project Support Team Conclude ProjectSteer Project

Specifythe System

Shape theSystem

Implement Software

Test theSystem

Releasethe System


Let us now do something we didn’t do before?


Use the Process to Plan the Project[Planning Game]


GoodSoftware

Current Situation

andOpportunity

Apply a practice to help your team.


Use cards and gameboard to introduce a practice (eg. use case essentials)

Specified SystemU

se-C

ase

Mo

du

les

Scoped

SpecificationAgreed

Realized

Implemented

Verified

Start

Conceived Shared Stable Correct Implemented Fulfilled


Specified System

A use-case module is a cross-cutting view of a use case across the specified, implemented and executable systems.

Use-case modules:

• Integrate the different system views provided by use-case driven development

• Enable consolidated status tracking of the use-case specification, realization and test cases included in the module

Use-Case Module

Scoped

Realized

Implemented

Verified

SpecificationAgreed

Described by:

• 1 Use-Case Specification

• 0..n Supplementary Requirements

• 1 Use-Case Realization

• 1..n Test Cases

Use

-cas

e m

od

ule

s m

ay

be

spli

t in

to

par

ts t

o a

llo

ws

gro

up

s o

f fl

ow

s to

be

pro

gre

ssed

at

dif

fere

nt

rate

s

Evolution of top alphas control the game

Evolution of sub-alphas control the moves of the game


Development Game Dynamics

1. Define the goal of the game (or round)• Plan evolution of top alphas (major control elements) in terms of state

progression.

2. Examine the Backlog (consider current project situation)• Select high-priority work items from Backlog (tasks, defects, changes),

include these in the planning of the next move

3. Plan a move• Define desired end states of sub-alphas (sub-ordinate control elements)

• Decide which activities to perform as part of the move

4. Perform the tasks• Deal the relevant cards to team members

• Execute the activities in the appropriate environment

5. Assess the results of the move• Annotate cards and update the game board based on the outcome

• How did we score?


1. Define the goal of the game / round

Specified SystemU

se-C

ase

Mo

du

les

Scoped

SpecificationAgreed

Realized

Implemented

Verified

Start

Conceived Shared Stable Correct Implemented FulfilledWhere are we?

Explained in the guideline

We need to get the specified system from conceived to shared.


2. Examine Backlog

Backlog

In Play


2. Examine Backlog

Backlog

In Play


3. Plan the move – find the activities

Understand the need

Specify the System

Find actors & use cases

Analyst

Specify the System

Select and prioritize use cases

Project Lead

Specify the System

Specify use-case module

Analyst

Shape the System

Realize use case

Developer

Implement Software

Test the System

Build Test

Tester

Test the System

Execute Test

Tester

Release the System

Shape the System

Identify Tests

Tester

Specified System

Use

-Cas

e M

od

ule

s

Scoped

SpecificationAgreed

Realized

Implemented

Verified

Start


Sp

ecif

iy t

he

Sys

tem

- F

ind

Act

ors

and

Use

-Cas

es

- S

elec

t and

Prio

ritiz

e U

se C

ases

Specified System - Conceived - Shared D D

Which activities do we need to perform to getthe specified system from conceived to shared?

Consult the state-activity table, or the practice workflow


3. Plan the move – define the work items

Specified SystemU

se-C

ase

Mo

du

les

Scoped

SpecificationAgreed

Realized

Implemented

Verified

Start


Select an approach, create tasks and allocate resources


4. Perform the tasks

1 Collect the cards that provide the guidance needed to perform the task

3 Team performs the work in the most appropriate environment

4 Artifacts are produced and instance cards describe the findings

Distribute work to the team by building hands of cards

UC Team A

2


5. Assess the results

Specified System

Use

-Cas

e M

od

ule

s

Scoped

SpecificationAgreed

Realized

Implemented

Verified

Start


Instance cards represent the outcome of the work. The gameboard is updated accordingly.

12

34

Workshop was successful – we

found some usecases and scope

is agreed. Thus Specified System

progresses to SHARED


What’s the next move?

Understand the need

Specify the System


Analyst

Specify the System


Project Lead

Specify the System


Analyst

Shape the System

Realize use case

Developer

Implement Software

Test the System

Build Test

Tester

Test the System

Execute Test

Tester

Release the System

Shape the System

Identify Tests

Tester

Specified System

Use

-Cas

e M

od

ule

s

Scoped

SpecificationAgreed

Realized

Implemented

Verified

Start


12

34

Scope all the use-case modules?


What’s the next move?

Specified SystemU

se-C

ase

Mo

du

les

Scoped

SpecificationAgreed

Realized

Implemented

Verified

Start


12

34

Understand the need

Specify the System


Analyst

Specify the System


Project Lead

Specify the System


Analyst

Shape the System

Realize use case

Developer

Implement Software

Test the System

Build Test

Tester

Test the System

Execute Test

Tester

Release the System

Shape the System

Identify Tests

Tester

Or spike one use-case?


Agenda





• Final words


Knowledge Base

Gam

e B

oar

d

Agents and tools

Cards Guidelines

References

Practices

How it all fits together

Sta

rt h

ere

Fin

ish

her

e

SmartPractices


In a Nutshell...today:

You can have a platform independent process

You can get Eight Essential practices…more to come

You can use Smart practices

Capture and publish your own best practices

Use the new paradigm• Cards and games bring the process to life

• Play all three process games

Re-focus process on to developer, not the process engineer

...the Next Generation Process is here today

JACZONEWayPointer


EssUP Product Release

Sign up for updates on EssUP and free product releases atwww.ivarjacobson.com

Next Generation Process - cs.tut.fi · Next Generation Process with Essential Modeling Ivar...

Documents

Transcript of Next Generation Process - cs.tut.fi · Next Generation Process with Essential Modeling Ivar...