philippekruchten...9/30/11 28 other&references& •...

9/30/11

1

The Frog and the Octopus

A Conceptual Model of So=ware Development

Sauder School of Business September 30 2011 Sept. 2011 1 Copyright © 2005-‐11 by Philippe Kruchten

Philippe Kruchten, Ph.D., P.Eng., CSDP Professor of So)ware Engineering NSERC Chair in Design Engineering Department of Electrical and Computer Engineering

University of BriPsh Columbia Vancouver, BC Canada [email protected]

Founder and president Kruchten Engineering Services Ltd Vancouver, BC Canada [email protected]

2

9/30/11

2

fable |ˈfābəl| (noun) a short story, typically with animals as characters, conveying a moral. – a story, typically a supernatural one incorporaPng elements of myth and legend.

– myth and legend : the unnatural monsters of fable.

– a false statement or belief.

Sept. 2011 Copyright © 2005-‐11 by Philippe Kruchten 3

Once upon a Cme, a frog and an octopus, Met on a so)ware project, that was deep in the bush. The frog said, “you know, all these projects are the same; Over Cme we fill with our work the gap that we find Between the burgeoning product, and our dreamed intent.”

“Oh, no” objected the octopus, “they cannot be the same; They come in all forms or shapes and sizes and colours, And we cannot use the same tools and techniques Like in the cobbler shop, on size does not fit all.”


9/30/11

3

Outline

•  A fable •  MoPvaPon •  The model •  The frog part •  The octopus part •  Using the model •  Further ideas to explore

Copyright © 2005-‐11 by Philippe Kruchten 5 Sept. 2011

“The purpose of science is not to analyze or describe but to make useful models of the world. A model is useful if it allows us to get use out of it.”

Edward de Bono


9/30/11

4

Models of so=ware development

•  Waterfall, iteraPve, agile •  So=ware process as so=ware •  Object-‐oriented models: Objectory, RUP, OMG SPEM, ISO’s

•  Catalog: SWEBOK •  Input-‐process-‐output paradigm •  PMBOK and “thermostat” model


So=ware development processes (cont.)

•  PolarizaPon – Agile vs. rest of the world – Heavyweight vs. lightweight – Formal vs. informal – Old vs. new – Bad vs. good

•  Lihle focus on people •  “One size fits all”, decontextualizaPon


9/30/11

5

Criteria for a new model

•  Encompassing •  Unifying •  Context-‐sensiPve •  Coherent •  Complete



Frog: “All projects are the same”

Value Value

Cost Cost

9/30/11

6

Octopus: “All projects are different!”

Copyright © 2005-‐11 by Philippe Kruchten 11

Context

Size CriPcality

Business model

Stable architecture Team

distribuPon

Governance

Rate of change

Age of the

system

Sept. 2011

Domain, Industry

Corporate & Na9onal Culture

Organiza9onal Maturity

Degree of Innova9on

•  A project is all the work that people have to accomplish over 9me to realize in a product some specific intent, at some level of quality, delivering value to the business at a given cost, while resolving many uncertain9es and risk.

•  All aspects of so=ware projects are affected by context: size, criPcality, team distribuPon, pre-‐existence of an architecture, governance, business model, which will guide with pracPces will actually perform best, within a certain domain and culture.

Sept. 2011 12 Copyright © 2005-‐11 by Philippe Kruchten

9/30/11

7

Outline



A Conceptual Model of So=ware Development

4 key concepts, 3 key ahributes

 Intent  Product  Work  People

 Time  Quality  Risk

14 Copyright © 2005-‐11 by Philippe Kruchten Sept. 2011

9/30/11

8

Intent, Work, People, Product


Adding Time, Quality & Risk


9/30/11

9


SW Dev. Project: Tension between Intent and Product

Intent

Product

Work δV

δT 18 Sept. 2011 Copyright © 2005-‐11 by Philippe Kruchten

9/30/11

10

IteraPons

19 Sept. 2011 Copyright © 2005-‐11 by Philippe Kruchten

Value

Cost 20 Sept. 2011 Copyright © 2005-‐11 by Philippe Kruchten

9/30/11

11


Adding Value and Cost

Value Value

Cost Cost

Outline



9/30/11

12


Context

Size CriPcality

Business model


distribuPon

Governance

Rate of change

Age of the

system

Sept. 2011

Domain, Industry



Degree of Innova9on

Type of So=ware Projects

•  Commercial, speculaPve vs. contract work •  Many instances vs. single few instances •  Internal vs. external (acquisiPon) •  Greenfield vs. evoluPon or legacy transformaPon

•  Single project vs. program or porqolio •  Size

•  Process: one size does not fit all…!

Sept. 2011 Copyright © 2005-‐11 by Philippe Kruchten

24

9/30/11

13

Project Context

Copyright © 2005-‐11 by Philippe Kruchten

•  Environmental CondiPons (organizaPon)

Drive/constrain

•  Context Ahributes (so=ware project)

SelecPon and adaptaPon

•  Good PracPces (actual process)

25 Sept. 2011

Environmental condiPons

•  Business domain –  E-‐commerce –  Manufacturing –  AutomoPve –  Aerospace

•  Number of instances –  One, A dozen, Millions,

SaaS,… •  Maturity of organizaPon

–  Small start up –  Mid size so=ware Dev. Co. –  Large system integrator +… collecPve experience


9/30/11

14

Environmental condiPons (cont.)

•  Level of innovaPon –  New product, never been done… or

–  Old classic, just beher, faster, larger, …

•  Culture –  CommunicaPon –  Trust –  Shared mental models –  EducaPon (?)


In general, environmental condiCons are proper to the organizaCon, and common to several projects

Context ahributes

1.  Size 2.  CriPcality 3.  Age of system 4.  Rate of change 5.  Business model 6.  Stable architecture 7.  Team distribuPon 8.  Governance

Age of System

Rate of change

Governance

Team Distribu9on

Stable Architecture

Business model

Cri9cality

Size

Context


9/30/11

15

Environmental drivers Context ahributes


Business domain

Number of instances

Maturity of organizaPon Level of innovaPon

Culture

Size of system

CriPcality Age of system Rate of change

Business model Stable architecture Team distribuPon

Governance

29 Sept. 2011

Context ahributes PracPces/process


Size

CriPcality Age Rate of change

Business model Architecture Team distribuPon

Governance

Select

Good Prac9ces: •  Planning •  Rate of iteraPon •  Release early, o=en •  Backlog •  ConPnuous integraPon •  DocumentaPon •  Quality •  Risk management •  Daily stand-‐up meePng •  TDD •  Pair programming •  “Customer on site” •  AdaptaPon … etc.

Adapt

30 Sept. 2011

9/30/11

16

1. Size of system


•  SLOC, FP •  Impacts team size, duraPon…

•  Driven by: Business domain •  Related to: Legacy, geographic distribuPon, governance

•  Affects: IteraPon rate, planning, communicaPon modaliPes, documentaPon, risk management, “customer on site”, etc.

31 Sept. 2011

2. CriPcality

•  “So=ware that kills” + Massive losses, damage to environment

•  Demonstrably correct •  Formal methods •  Extensive tesPng •  Audited by external agencies

•  Driven by: Business domain •  Related to: Rate of change •  Affects: DocumentaPon, tesPng, inspecPon

Belleville-‐sur-‐Loire, France


9/30/11

17

3. Age of system


Legacy evoluPon Brownfield vs. green field development, maintenance

•  Related to: size •  Affects: TesPng, (lack of ) documentaPon, architecture

33 Sept. 2011

4. Rate of Change


•  AdaptaPon versus anPcipaPon

•  External & internal changes –  Customer, compePtor, technology, legislators, inside organizaPon, turnover, team evoluPon, maturaPon, …

•  Driven by: business domain •  Related to: size •  Affects: IteraPon length, planning, adaptaPon,…

34 Sept. 2011

9/30/11

18

5. Business Model


•  Commercial market •  Bespoke so=ware •  In-‐house development •  Open source development •  … etc.

•  Driven by: Business domain •  Related to: Governance •  Affects: DocumentaPon, number of instances, “customer on site”, communicaPon, risk management, geographic distribuPon, rate of iteraCon

35 Sept. 2011

6. Architecture stability


•  How much of a stable system and so=ware architecture is in place when the project starts?

•  Driven by: Level of innovaPon •  Related to: Size of system, age of system •  Affects: Rate of iteraPon, risk management, tesPng

Logical View Implementa9on View

Process View

Deployment View

Use Case View

36 Sept. 2011

9/30/11

19

7. Geographic DistribuPon of the Team


•  Seems to make everything a bit harder and more suscepPble to fail

•  Driven by: Maturity of organi-‐ zaPon, culture

•  Related to: Size, business model

•  Affects: CommunicaPon modaliPes, documentaPon, DSM, governance, …

37 Sept. 2011

8. Governance


•  Structural: chains of authority, responsibility and communi-‐ caPon to empower the various actors

•  Dynamic: measures, control, mechanisms, policies to enable all actors to carry out their respecPve responsibiliPes

Is this “big process” coming by the back door?

Clay Williams, IBM, 2008

38 Sept. 2011

9/30/11

20

The agile “sweet spot”


System Size CriPcality

System Age

Rate of change Business model

Stable architecture Team distribuPon

Governance

•  0 ..12 … 300 •  Simple, $ losses, … deaths •  Exploratory, greenfield, legacy maintenance

•  Low, medium, high •  In house, Open Source, …. •  Stable, changed, new •  Collocated, …, …, offshore outsource

•  Simple rules, …, SOX, … 39 Sept. 2011

Outline



9/30/11

21

“… a model is useful if it allows us to get use out of it.”

Edward de Bono


Using the model

•  Analysis of extant process, pracPces, techniques tools

•  Curriculum development (So=ware project management)

•  Basis for empirical research on so=ware engineering

•  Assessing the state of a so=ware development project (review, audit)


9/30/11

22

PracPce: Daily Stand-‐up MeePng



What would Frog say?

Value Value

Cost Cost

9/30/11

23


What would Octopus say?


Context

Size CriPcality

Business model


distribuPon

Governance

Rate of change

Age of the

system

Sept. 2011

Domain, Industry



Degree of Innova9on

9/30/11

24

EECE443/543 Course Outline 1. IntroducPon 2. Conceptual model: the frog

3. Context: the octopus

4. Process & management 5. Managing risk and uncertainty

6. Managing 9me: macro-‐level -‐ lifecycle, esPmaPon

7. Managing 9me: micro-‐level -‐ scheduling

8. Managing quality -‐ metrics

9. Managing objecPves and scope -‐ intent

10. Managing complexity

11. Managing changes 12. Managing so=ware assets 13. Managing so=ware products 14. Managing people: individual

level 15. Managing people: team level 16. Managing external

stakeholders 17. Managing the so=ware

process -‐ work 18. So=ware development

governance 19. Large projects, programs, and

project porqolios 20. Conclusion

June 2011 Copyright © 2011 by Philippe Kruchten 47

Outline



9/30/11

25

Future work…

•  Refining the core classes •  Formalizing the model •  Looking at the more dynamic aspects

•  Mapping various known processes to the model

•  Defining an ontology?



9/30/11

26

Reconciling PerspecPves

Converging ValidaPng

Reaching out

NegoPaPng Consensus

Bunkering AccepPng

Precedes

Accepted Workproduct

Ar9fact Process

• Cycle Cme • Formality • Scale • CommunicaCon

•  Property Transfer

Mismatched Perspec9ves

Workproduct Consensus

Legend:

With Steve Adolph

Summary •  A model in two parts:

1.  Commonality (frog) 2.  Variability (octopus)

•  Reasoning about the management of so=ware development projects

•  SelecPon of appropriate process: –  Lifecycle (Pmeline) – AcPviPes (work) –  Roles (people) – ArPfacts, workproducts (product, intent, quality)

•  Based on the specific context of that project Sept. 2011 Copyright © 2005-‐11 by Philippe Kruchten 52

9/30/11

27

•  A project is all the work that people have to accomplish over 9me to realize in a product some specific intent, at some level of quality, delivering value to the business at a given cost, while resolving many uncertain9es and risk.

•  All aspects of so=ware projects are affected by context: size, criPcality, team distribuPon, pre-‐existence of an architecture, governance, business model, which will guide with pracPces will actually perform best, within a certain domain and culture.

Sept. 2011 53 Copyright © 2005-‐11 by Philippe Kruchten

Once upon a Cme, a frog and an octopus, Met on a so)ware project, that was deep in the bush. The frog said, “you know, all these projects are the same; Over Cme we fill with our work the gap that we find Between the burgeoning product, and our dreamed intent.”

“Oh, no” objected the octopus, “they cannot be the same; They come in all forms or shapes and sizes and colours, And we cannot use the same tools and techniques Like in the cobbler shop, on size does not fit all.”


9/30/11

28

Other references •  Kruchten, P. 2007. Voyage in the Agile Memeplex: Agility, Agilese, AgiliPs, Agilology,

ACM Queue 5 (5), 38-‐44. DOI: 10.1145/1281881.1281893 •  Kruchten, P. 2010. Contextualizing Agile So=ware Development. Presented at

EuroSPI 2010. Grenoble, France. PDF at files.me.com/philippe.kruchten/1q00nw •  Kruchten, P. 2011a. Experience teaching so=ware project management in

academia and industry. Proceedings of the 24th IEEE-‐CS conference on So=ware Engineering EducaPon & Training (CSEE&T). Honolulu, HI, USA. IEEE CS. DOI: 10.1109/CSEET.2011.5876087

•  Kruchten, P. 2011b. The frog and the octopus-‐Experience teaching so=ware project management to undergraduate engineering students. 2nd annual conference of the Canadian Engineering EducaPon AssociaPon. St. John's, NF, Canada.

•  Kruchten, P. 2011. The frog and the octopus-‐-‐A model of so=ware development, CSI CommunicaCons 4 (35), 12-‐15.URL:hhp://www.csi-‐india.org/web/csi/ecommunicaPons-‐july2011

•  Kruchten, P. 2011d. Contextualizing Agile So=ware Development, Journal of So)ware Maintenance and EvoluCon: Research and PracCce. DOI: DOI: 10.1002/smr.572

•  Kruchten, P. (submihed to JSS) The frog and the octopus-‐-‐A conceptual model of so=ware development (That is the paper that was handed at the seminar)


philippekruchten...9/30/11 28 other&references& •...

Documents