Next Generation Process Essential Modeling: Ivar Jacobson
Next Generation Process Essential Modeling: Ivar Jacobson
with
Essential Modeling
Ivar Jacobson
with Pan Wei Ng and Ian Spence [email protected] [email protected]
A new paradigm
From the successes in modern software development
2005 Ivar Jacobson International
A new paradigm
From the successes in modern software development
2005 Ivar Jacobson International
NEW
Process users Practitioners who apply the process to a project Select practices & add them to their process Key needs: simplicity, ease of use, understandability
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 dont need to be lengthy... Since there are lots of publications available, there is no need write a massive document. - Dave Thomas
Ericsson Approach
Objectory Process
87 96
97 98
99 05
However, there are challenges with UP based methods Unified Process is too heavy UP requires substantial investments in tools, training and mentoring
Find the knowledge
Knowledge base is too big, how to find just the right stuff?
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
Our practices are supplied as a set of cards and guidelines defining a way of doing something 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
More precisely
10
Technical Practices
Architecture
Component
Ti tl e
It is
Process
i Ev s te s er yw ting ? he re !
Iteration Product Team
Use Case
he
re
Modeling
11
Building a process eco-system around 8 Essential Practices There will be 100s of practices extending the essentials
Essential Practices
Systems Engineering Business UseCase Iteration Enterprise Product Architecture Line Eng. SOA
Domain Modeling
Component
Product
T i t l e
Process
Team
PSP / TSP
Pair Programming
Extended CMMI
Portfolio Management
Program Management
12
13
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.
2005 Ivar Jacobson International
14
Product
Use Case
Architecture
Component
Involve stakeholders in the decision making process Ensure the product meets the real needs of the stakeholders
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
Establish a firm foundation for the incremental development of the solution Share the major decisions about the structure and organization of the implemented system
Develop and verify the separate parts of the system independently and in parallel Exploit third party frameworks and component libraries
15
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!
16
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.
17
What do practitioners want? To be able to easily communicate re. To model with or without tools e wh f the To start with something simple me o behavior, A common language to communicate structure, s o 0% 8 ownership, packaging, dynamics ands abstractions. ere
h e n t ovid g i pr din at lue! i s h % t h va l i t 20 el e W th s ItIs this something the UML gives us?
18
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
19
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
20
Where does Essential UML sit? It is an Extension to the Modeling Essentials Practice
Essential Practices
Architecture Iteration
Use Case
Component
Product
Title
Process
2005 Ivar Jacobson International
Team
Modeling
21
The Essential UML presents the essence of the UML for use by practitioners.
Essential UML
<< imports >> It depends on the UML 2.0 language definition and benefits from its rigor and completeness
UML 2.0
22
<<extend>>
<<extend>>
Modeling
<<extend>>
Essential UML
Modeling For That
23
Structuring use-case, architecture, component and other models Communicating architecturally significant aspects of the deployment Establishing a common understanding of what the system must do for its users Showing flow of control within interactions and operations Describing lifecycles of key abstractions and dynamic behavior of components and classes Establishing the collaborations required to realize a use case Distributing responsibilities to key abstractions and establishing collaborations between components, interfaces and classes
Essential Unified Process Primer / 01 - Essential Principles and Practices 24
Use-Case Diagram
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
25
26
Nobody reads.
UC
DD
st Te
se Ca
yT ecif Sp
est
Exe cute
m to us
Tes t
R er
r ep
ta en es
e tiv
er att k a ip M Va ntia in ic a unic st ct ert art se m u bje xp Es Do mm s tr of p ct Su E je or Co ild ble s Bu pa ion 6 Pro dvis or Ca ess 200 ad A l, s ss r na es ba se atio ag rn te Am U an In M pe n bso e ely co co th s tiv S Ja ar Ac cts es Iv ire in D us B
ng ati ic : un h e to m ug th m ro ich am co tho wh te d e th an s a in a y lp ng . H ain d. nit of he eri s om e rtu ds th eed d loy ves e ep po ee ts ti ga n ta op d n en at er f th d n s m d old e o be sen rs es s a ire e in ille eh dg ill re es qu Sk tak wle n w rep riti hold us lem re m s no tio er e rio ke e b rob th ste p m e p sta th k olu y e s sto fin fy ate s nd th rs Cu De nti rsta nd lde alu red ng e v e 24 eli Id de rsta eho d e liv on od si de Un de tak an vi m e : n s re ge ills re d k U e th in th ptu ate kills wle n s ng Ca lid l S no tio ati
en Ess
tia
lU
nifi
ed
d an ts pu in f o. st e o ari f te os tem en d t o rp ys sc an se pu s ic g DD a e t a cif UC nin es r th r no spe ig fin fo o a es de s er rd m e ult th nts te fo as res he me n ys c d w le re fo tio fs st g p te cte n be em da ts n o A pe ati y im d st un tes tio are ex valu ectl es: fo ifiele sy a ting ple sts ecab e rr as e m : put s e te lts co t c vid en test to exec ed co n e e s tart of tth resu e DD s m a s ifi o Te Pro ecify the at th to b ecs omes te test ftwarUC ple r ati w th ts sp n tc fo e im Sp orify ic ssas tio ou: ine th the so s 24 ll st Ve if te n the ts a A pec rm ewta tentermn t of eet d Te on rfo g io em s e an pe owe ho tonde dit pmen lts tm m o st visi nin plan to: g fin Sy egrat re mus su klo All ple ted C on lo ve Int efi ed Bac De im ua tial e de sts it Re ifi -c (d : h the e Specif ec eval en th re e te abl ied ssswit s P Sp System cut d ut ted grewhen ) as w d Exe tem c ss ..n th tif Sys m Focu rds Inp eual pro edlo ste are ocity ie E wa n act to: ete F ble 1 o Iden fied xp mpl pro te d vel to ject eci Sp temPro 1.. are E contify s be an s ari n es Comp ..n ly ide -Ca gress Case ion Sys Steer en se ick n de to 1 ity is c ed pro Testmplet ts Qu activ fere an s rio n: e co Sc Int o derstifiU tio s emen ec Chegrat ble le klog leston 6 achiev : Sp na The Un e 1..nifica Bac eTesterutab stR dict mi an 200 a d Te d ec ce tone : en: em Te Pre ndmiles, st Sp s ariExecnest Syst per nal fi elo d V ed cheswh nd d Dev cifie yo s Spe em Te Asses atio coproa mplet test UCDD De ject Leada ne or be d Syst ta fi ch as A use- rn y is ap em ate te Pro a ivit d Evalu e d (su en In case anact de lts: st dresse 24 t actor su spec ad tD D on The mmen usessy ification have be on bs Bries ults and st Re en test e fly Des Lead co a syst ts)describe revisi d Spe em s how RecoTe whand items defec to sse cifi T t the s ect crib Ja Indepe og on d Sys ed achieve dre ad tem Backl si system does ar achieve esrios an st ed Re Exe Proj lyst ed Iv n te gr that goal rifi flo the for wseda goal cut Re na atio Ve Ana sce as . Module Sys able d rifi actor tem Use-castegr as Ve s been to n er marke e-Case Bullete elop ow In e spec 06 rked Dev ha d OutlineBac Cap The Us ificama s: ement ity is kn 20 tion en klo tureve al, st be oc er iev Teg ation Test ss ha requirements Defi ernation one ach team vel ce Exec Int scen ecific ne d in cont est Sp Pro ut es: ext bson e Mil arios an ed Essenti Ena a d coVe ble proach cking te ord fie tem rec al rify effective r Ja ni e Sys traUC d thProv th st to scop ap Test Outline abl Tes cut DD lU Iva e ev ide the : ende e managem ularly gress ter n 24 Exe ia Id devealu at the mmil deta reg s pro revisio to driv ent Re atioco ults ent en lopment ex nuou Dev elo ss nti activities res they to en tifydeliv n cr ecutab tee the other per defeer Co ite nstraand Fully Des E ocess su ct valu ria le sy ensure mo cribed d Pr that Esse re that s De e of th st ifie The klogntial Con th and pl 2006e em m Un Bac t test tents:tional, e eets Tes ac ey ntial ac1 ults Te Bactivity e rnaare Nam in klog Esse Res addr the le on Inte -Case st:1Ev is co utab Use ule esse back Briefobs m Exec em An Jac log Mod Syst Ivar alu Des plet d y1 Bas ated cription Defe d ed Back Essential cifie Spe em ic wh cts: Flow Unified Test en: s Te log Syst Process 0..n Alte Iden Proces st Re tified rnative fied Te sults Flows Exe ial Uni Ivar Jaco and cut Re st Esse bson Reco Intern : An abl Essent adde e Sys sults ntial ation aly tem d to Unifie Au mmen al, 2006 zed the ded d Pr Defec Pr tomat oces appr ed t s revision oach test Bac Ma ogram 24 klo es: g nual matic ing Iva te test r Ja ing sting co
ce Pro
ss
bson
Intern ation
al,
2006
rev
isio
n 24
published in 1989
27
A card contains concise description of things to produce and things to do, etc.
28
29
Reference books
Intelligent Agents
2005 Ivar Jacobson International
30
Intelligent Agents Learn about Intelligent Agents and how they support software development at www.jaczone.com
JACZONE
WayPointer
31
32
Component Diagram
component
Essentials
port component
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 Essential Contents: Components a unit of software that implements a set of interfaces Ports interaction points with welldefined 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
revision 11
provided interface
component
required interface
Essential UML
33
Essentials Essentials
A component diagram is used to show: A component diagram is and to Components in a system usedthe show: interfaces that they implement the Components in a system and interfaces that they a component The dependencies thatimplement has on dependencies thatinterfaces The other component a component has on other component interfaces Essential Contents: Essential Contents: of software that Components a unit implements a set a interfaces Components of unit of software that implements a set of interfaces Ports interaction points with welldefined interaction points with well Portsinterfaces defined interfaces Provided Interfaces sets of services made available by the sets of services Provided Interfacescomponent made Interfaces sets of services Requiredavailable by the component required by Interfaces sets Required the component of services required by the component Dependency Relationships use of a component or interface by a component Dependency Relationships use of a component or interface Recommended Stereotypes: by a component Recommended Stereotypes: <<subsystem>> A course-grained system component <<subsystem>> A course-grained system component
revision 11 revision 11
provided required interface interface provided required on port on port interfacedependency interface on port on port relationship dependency relationship provided interface provided interface
component component
Reference books
I do Component Modeling
Intelligent Agents
2005 Ivar Jacobson International
34
35
Good Software
36
Good Software
37
Good Software
38
Good Software
39
Good Software
Three collaborating games. All made simpler by the practices and the cards.
2005 Ivar Jacobson International
40
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
C om pe te nc ie s
uc
od
Pr
Th in gs
Opportunity
Specified System
Implemented System
Executable System
Team
Backlog
Project
Th in gs
Way of Working
to
to
o
42
43
Time
Inception
Life Cycle Objectives Project Viability Agreed
Do you understand scope and risk, and do you have a candidate architecture and a credible plan?
Elaboration
Life-Cycle Architecture Selected Approach Proven
Do you have a solution that is proven to work?
Construction
Initial Operating Capability Useable Solution Available
Is the product working and useable, are the users ready to receive it?
Transition
Product Release Development Completed
Is the product acceptable and is the development project over?
44
Implemented System
Approach Selected Approach Confirmed Interfaces Stable Integrated Production Quality Release Available Released
Executable System
Assembled Approach Validated Functionality Validated Ready to Deploy
Lifecycle Patterns
Opportunity Identified Problem Understood Value Established Viability Established Problem Addressed Benefit Accrued
Shared
Stable
Correct
Testable
Accepted
Fulfilled
Operational
Team
Backlog
Project
Way of Working
Set Up Mission Defined Driving Work Formed Change Under Control Focused Quality Goals Met Collaborating Sufficient Work Completed Outstanding Items Handed Over
Underway Gaps Analyzed Milestones Agreed Options Explored Risks Under Control Development Complete Responsibilities Handed Over Closed Essentials In Place Embedded
Key
Essential
Recommended
Disbanded
Handed Over
45
Implemented System
Approach Selected Approach Confirmed Interfaces Stable Integrated Production Quality Release Available Released
Executable System
Assembled Approach Validated Functionality Validated Ready to Deploy
Lifecycle Patterns
Opportunity Identified Problem Understood Value Established Viability Established Problem Addressed Benefit Accrued
Shared
Stable
Correct
Testable
Accepted
Fulfilled
Operational
Team
Backlog
Project
Way of Working
Set Up Mission Defined Driving Work Formed Change Under Control Focused Quality Goals Met Collaborating Sufficient Work Completed Outstanding Items Handed Over
Underway Gaps Analyzed Milestones Agreed Options Explored Risks Under Control Development Complete Responsibilities Handed Over Closed Essentials In Place Embedded
Key
Essential
Recommended
Disbanded
Handed Over
46
Implemented System
Approach Selected Approach Confirmed Interfaces Stable Integrated Production Quality Release Available Released
Executable System
Assembled Approach Validated Functionality Validated Ready to Deploy
Lifecycle Patterns
Opportunity Identified Problem Understood Value Established Viability Established Problem Addressed Benefit Accrued
Shared
Stable
Correct
Testable
Accepted
Fulfilled
Operational
Team
Backlog
Project
Way of Working
Set Up Mission Defined Driving Work Formed Change Under Control Focused Quality Goals Met Collaborating Sufficient Work Completed Outstanding Items Handed Over
Underway Gaps Analyzed Milestones Agreed Options Explored Risks Under Control Development Complete Responsibilities Handed Over Closed Essentials In Place Embedded
Key
Essential
Recommended
Disbanded
Handed Over
47
Implemented System
Approach Selected Approach Confirmed Interfaces Stable Integrated Production Quality Release Available Released
Executable System
Assembled Approach Validated Functionality Validated Ready to Deploy
Lifecycle Patterns
Opportunity Identified Problem Understood Value Established Viability Established Problem Addressed Benefit Accrued
Shared
Stable
Correct
Testable
Accepted
Fulfilled
Operational
Team
Backlog
Project
Way of Working
Set Up Mission Defined Driving Work Formed Change Under Control Focused Quality Goals Met Collaborating Sufficient Work Completed Outstanding Items Handed Over
Underway Gaps Analyzed Milestones Agreed Options Explored Risks Under Control Development Complete Responsibilities Handed Over Closed Essentials In Place Embedded
Key
Essential
Recommended
Disbanded
Handed Over
48
Actual State
Planned State
Opportunity
Specified System
Implemented System
Executable System
Team
Backlog
Project
Way of Working
49
Good Software
50
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?
Add
Finish here
51
Game Board
In more detail ... The Game Board is initially a process independent Kernel
C om pe te nc ie s
uc
Start here
Game Board
od
Pr
Th in gs
Th in gs
to
to
Align
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
2005 Ivar Jacobson International
Establish Project
Steer Project
Support Team
Conclude Project
Implement Software
Finish here
53 54
Start here
Establish Project
Steer Project
Support Team
Conclude Project
Implement Software
55
Good Software
56
Use cards and gameboard to introduce a practice (eg. use case essentials)
Specified System
Conceived Shared Stable Correct Implemented Fulfilled
Start
Scoped
Use-Case Modules
Specification Agreed
Specified System
Use-Case Module
Realized
Scoped
Use-case modules may be split into parts to allows groups of flows to be progressed at different rates
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
Implemented
Verified
Implemented
Described by: 1 Use-Case Specification 0..n Supplementary Requirements 1 Use-Case Realization 1..n Test Cases
revision 35
Verified
57
3. Plan a move
58
Start
Scoped
Use-Case Modules
Specification Agreed
Realized
Implemented
Verified
59
2. Examine Backlog
Backlog
In Play
60
2. Examine Backlog
Backlog
In Play
61
Start
Use-Case Modules
Which activities do we need to perform to get Scoped the specified system from conceived to shared?
Project Lead
Realized
Developer
Implement Software
Implemented
Verified
D
62
Start
Scoped
Use-Case Modules
Specification Agreed
Realized
Implemented
Verified
63
UC Team A
64
Specified System
Conceived Shared Stable Correct Implemented Fulfilled
Use-Case Modules
e lw sfu scope es Start ucc and t em as s ases ed Sys w op usec ecifi h p e rk s Wo d som Thus S ARED H un ed. S Scoped fo s to gre is a resse g pr o
Specification Agreed
2 1 3
Realized
Implemented
Verified
65
Start
2 1 3
Scoped
Use-Case Modules
Realized
Implement Software
Execute Test
Tester
66
Start
2 1 3
Scoped
Use-Case Modules
Specification Agreed
Realized
Implement Software
Implemented
Execute Test
Tester
67
68
Finish here
Start here
References
Practices
Cards
Guidelines
Knowledge Base
Smart Practices
2005 Ivar Jacobson International
69
In a Nutshell...today:
You can have a platform independent process You can get Eight Essential practicesmore 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
JACZONE
WayPointer
70
EssUP Product Release Sign up for updates on EssUP and free product releases at
www.ivarjacobson.com
71