key15 iva jacobson(2)

7/31/2019 KEY15 Iva Jacobson(2)

1/51

Software Engineering Method And TheoryA personal perspective

Ivar Jacobson


2/51

The Semat initiative


3/51

As an Industry

Who said that?

Everyone of us knows how todevelop software,

but as an industry we dont know it

We dont have a widely accepted foundation


4/51

A CASE FOR ACTION STATEMENT

Software engineering is gravely hampered today by immaturepractices. Specific problems include:

The prevalence of fads more typical of fashion industry than of anengineering discipline.

The lack of a sound, widely accepted theoretical basis.

The huge number of methods and method variants, with differences littleunderstood and artificially magnified.

The lack of credible experimental evaluation and validation.

The split between industry practice and academic research.

This is unsmart!


5/51

CASE FOR ACTION STATEMENT contd

We support a process to refound software engineering based on asolid theory, proven principles and best practices that:

Include a kernel of widely-agreed elements, extensible for specific uses

Addresses both technology and people issues

Are supported by industry, academia, researchers and users

Support extension in the face of changing requirements and technology

This is the Semat initiativeSOFTWARE ENGINEERING METHOD AND THEORY

This is smart!


6/51

Semat is separated into six tracks:

1. Definitions

2. Theory

3. Language

4. Kernel

5. Assessment

6. Requirements


7/51

This talk focus on the Kernel

It draws on my personal experience.

It suggests a goal we need to find.

It shows it can be found.

Reaching the goal, it will have dramatic impact on the whole softwarecommunity

o

the industry,o the developers,

o the academics,

o the educators,

o the methodologists, etc.

Watts Humphrey on the meeting in Zurich March 17-18:

This meeting in Zurich is likely to be an historic occasion

much like the 1968 NATO session in Garmish.


8/51

Agenda

On what went well and what went wrong

Addressing what went wrong1. Practices

2. A new user experience

3. Practices are not dead, they are enacted

4. Result

There must be a kernel

The Semat kernel: track 3 and 4

If successful what impact can we expect?

Wrap up


9/51

What went well and what went wrong

Good

Many proven practices Use-cases (incl test)

Iterations Components

Architecture

Etc.

Supported UML UML replaced all the hundred

modeling languages at the time

Bad

A soup of practices

Too big

People dont read process books

Hard to extend with agile,CMMI, etc.

Adoption extremely hard Process savvy

Revolutionary

Gap between what peoplesaid they did and what theyreally did The Process Gap

Lets be clear, the rise and fall are all about perception.RUP is still very much alive.

The perceivedrise and fall of RUP


10/51

On Processes (or Methods and Methodologies)

Every process tries to be complete

As a consequence every successful process will grow until it dies underits own weight

Every branded process is just a soup of ideas borrowed from other

processes

With some new idea(s)

Every process usually becomes just shelf-ware Law of Nature: People dont read process books

The process is out of sync with what the team does

and the project process gap get wider and wider

The project has to adopt an entire process

No-one uses an entire process or limits themselves to practices fromone process

Some exaggeration

No wonder people dont like process


11/51

We looked for fundamental changes.

Fixing what was Bad

Make practices first classcitizens, and process acomposition of practices

Focus on the essentialsinstead of trying to be

complete Extensions through practices

A new user experience withfocus on developers, not onprocess engineers.

Enact the process

Bad

A soup of practices Too big

People dont read process books

Hard to extend with agile,CMMI, etc.

Adoption extremely hard Process savvy

Revolutionary, not evolutionary

Gap between what peoplesaid they did and what they

really did The Process Gap

We redesigned RUP as EssUP


12/51

Agenda





4. Result




Wrap up


13/51

Practices

From the successesin modern software

development

AgileMethods

Camp

The SoftwareEngineering

Camp

ProcessMaturityCamp

In the future, an ever present but

invisible process

We need a newparadigm

Process becomes secondnature

The teams way-of-working isjust a composition of

Practices

Practice is a First Class Citizenthe unit of adoption, planning and execution of process

Unified ProcessExamples: CMMI, Spice XP, Scrum


14/51

The Paradigm Shift: From Processes to Practices

We have always had practices in a loose meaning

After the paradigm shift you can do all kinds of operations on practices

o Separate them, compose them, teach them, execute them

Class-like

elements

Before

Process

Practice

Process is FirstClass Citizen

Practices were non-tangible elements

They were therebut not separablefrom one another

Now

Process is just acomposition ofpractices

Practices are FirstClass Citizens


15/51

We needed a shared definition of practice

Pragmatics

A practice provides a way to systematically address a particular aspectof a process. It is a separate concern of the process.

There are three kinds of practices (at the least):

Peer practices

A practice has a clear beginning and an end allowing it to be

separately applied, examples: Iterative development

Use-case driven development

Project management la Scrum

Extension practices

Use cases for SOA Cross-cutting practices

Team practice incl workshops, self-organizing teams, war room,pair programming, etc.

Process improvement for the essentials of CMMI e.g. metrics.


16/51

A Good Practice is good for the team

Gives a result of observable value to the customer of the team

It is a building block for the team not necessarily for the process engineers. Not too big not too small

It includes its own verification

It is that thing that needs to be made lean

It is that thing for which you want to have metrics


17/51

Agenda





4. Result




Wrap up


18/51

Focus on the Essentials

What is Essential?

It is the key things to do and the key things to produce

It is about what is important about these things

It is less than a few percent of what experts know about these things

Law of nature: People dont read process books

It is the placeholders for conversations Law of nature: People figure out the rest themselves

Training helps

It is the base for extensions

Starting with the essentials makes a practiceadoptable.


19/51

How much do you need in your hands?

Reference

books
http://www.amazon.com/gp/product/images/0321321308/ref=dp_image_0/102-2047208-1154549?_encoding=UTF8&n=283155&s=books


20/51

Why Cards?

Cards are tactile

Cards are simple and visual Cards use conversational and

personalized style

Cards are not prescriptive so they getthe learner to think more deeply

Cards getand keepthe readers

attention Cards promote agility

They can be written on to make minoradjustments to the practice on the flyEssential Unified Process 3.1 Ivar Jacobson International, 2005 -2007 Use Case Essentials 2.3 / rev. 40

Find Actors and Use Cases

Opportunity Backlog Find actors and use cases to:

Agree on specified system behavior

Establish the system boundary

Scope the system

Agree on the value the system provides

Identify ways of using & testing system

The activity is completed when:

The Use-Case Model: Value Established orbeyond

Use Case Specifications: Briefly Describedor beyond

Supplementary Requirements: Initiated

The activity contributes to achieving: Specified System : Shared Use-Case Module: Scoped

Recommended approaches:

Use-case modeling workshop

Structure the use-case model

Handle changes (to the use-case model)

SpecifiedSystem

Analyst

CustomerRepresentative

Specified System

Use-Case Module

Supplementary Requirements

Use-Case Specification

Use-Case Model

Specify the System

A practice is a set of cards A team works on a set of instance cards


21/51

Agenda





4. Result

There must be a kernel The Semat kernel: track 3 and 4


Wrap up


22/51

Practices are enacted

Set UpYour Goals

Things to produce

Get HelpTo ReachYour Goals

Things to do


23/51

Agenda





4. Result



Wrap up


24/51

Thus we fixed what didnt work

Great, but now more became evident!

TechnicalPractices

Cross-CuttingPractices

Use Case

Process Modeling

ProductArchitecture

$

ComponentIteration

Team

upupUnified Process

Lifecycle

Essential Unified ProcessFixing what was Bad Make practices firstclass citizens

Focus on theessentials

Extensions through

practices A new user

experience withfocus on developers

Enact the processto close the gap


25/51

Agenda





4. Result



Wrap up


26/51

Hypothesis harvested from the fixing-the-problem work

All methods comprise of a set of things that are always there -documented or not.

We called this set the Kernel.

Every method can then be described as a set of composedpractices using the kernel.

There is a kernel!Many different methods can be built out of

this same kernel.

T if th h th i t t d ll


27/51

To verify the hypothesis we started all over

We called our initiative EssWork (moving beyond EssUP)

The Kernel we harvested is very small, extracted from a large numberof methods

It contains empty slots for things that every process have

Slots for

Competencies, such as analyst, developer, tester

Things to work with, such as backlog, implementation, executablesystem

Things to do, such as implement the system, test the system

The Kernel is practice and of course method agnostic.

Kernel


28/51

The Kernel includes a Meta-Model - an implied language

progresses

>

Alpha

Activity Space

organizes

>

< supports

organizes >

< describes

produces

>

< supports


29/51

The EssWork Kernel

contains empty slots for things that every process have

Kernel

Opportunity

Project

Requirements System

Way ofWorking

Team

$$

Understand theNeed

Ensure StakeholderSatisfaction

Accept theSystem

Specify theSystem

Shape theSystem

ImplementSoftware

Test theSystem

Release theSystem

Establish Project Steer Project Support Team ConcludeProject

Developer

Leadership

CustomerRepresentative

Analyst Tester

Things to Work with Things to Do

Patterns To Apply Competencies


30/51

Practices put the meat (work products) on the bones(alphas)

SpecifiedSystem

Use-CaseModel

User Stories

ProductRequirements

Document

SoftwareRequirements

Document

For example there are many ways to specify the system.

Shared

Correct

Testable

Fulfilled

Stable

Conceived

SpecifiedSystem

SpecifiedSystem

C i Al h d W k P d t


31/51

Comparing Alphas and Work Products

Alphas:

The most important things that allsoftware projects have whether theyexist

Intangible

The things whose progress we want

to understand, monitor, direct andcontrol

Alphas have progress states

State progression meansprogression towards release

Work products:

Used to record informationaboutalphas

Used to understand and assessthe alphas

Can be physical documents,electronic files, models,databases, .xml ....

State progression generallyrepresents more information ordetail


32/51

Things to Work with: Alphas and Work Products

These are the alphas:


33/51

Alpha Relationships

$

Opportunity

Requirements

Team

System

Project

Way ofWorking

can be pursued bydeveloping a solutionthat fulfills the

addressed byproducing a

helps to pursuethe

undertakes the

follows theapplies the

produced and testedby the

delivers working

focuses onpursuing the

real

scope andconstrain the


34/51

Alpha States


35/51

Competency Levels

U i h k l


36/51

Using the kernel

Practice

Each practice contains practice-specifics to add to the kernel.

The kernel definesan empty process

Kernel

Practices slot into the

common kernel.

Way of

Working

Ch b h i b i f h d


37/51

Change starts by harvesting your best practices from your own method

KernelYour Own

Best Practices

+

I h d b ddi h i


38/51

Improve your method by adding other, proven practices

Your Own

Best Practices

Kernel + + Other PracticesFrom Many Sources

Iterative

Component

Architecture

Use Case

Team +++PLA

OK, there is a kernel!Maybe there are many?

But none is widely-accepted!That needs to be changed!


39/51

Agenda





4. Result



Wrap up


40/51

CASE FOR ACTION 2nd part

We support a process to refound software engineering based on a

solid theory, proven principles and best practices that: Include a kernel of widely-agreed elements, extensible for specific uses

Addresses both technology and people issues

Are supported by industry, academia, researchers and users

Support extension in the face of changing requirements and technology

The Kernel The Kernel Language + The Universals


41/51

The Envisioned Kernel

Methods

Practices Patterns

Universals

Composed of

Defined interms of

The kernel1

2

3

Level

Kernel language


42/51

Agenda





4. Result



Wrap up


43/51

A recipe for success

Our work needs to be

driven from the demands of the industry/developer community, and enabled and formulated by the research community, and

popularized by the methodologists.

Industry/Developers

Methodologists

Academics

We need a theoretical basis that is widely shared and supported,one that crosses the boundaries between the different softwaredevelopment camps.

This is smart!


44/51

Some challenges addressed by SEMAT

IndustryBig companies havemany processes.Challenges:

-Reuse practices-Reuse training-Reuse of people-Evolutionaryimprovement is hard

DevelopersWant to becomeexperts. Challenges:-Their skills are not

easily transferable to anew product.-Their career pathfollows a zig-zag trackfrom hype to hype.

MethodologistsEvery method is a soup ofpractices. Challenges:-Have to reinvent the

wheel

AcademicsAsked to educate andresearch. Challenges:-The Gap between

research and industry-No widely acceptedtheory-Teaching instances ofmethods doesnt create

generalists

SEMAT can have significant impact on thesoftware community.

Signatories as of March 24, 2010


45/51

g ,

Pekka Abrahamsson,

Scott Ambler, Victor Basili,

Jean Bzivin,

Dines Bjorner,

Barry Boehm,

Alan W. Brown, Larry Constantine,

Bill Curtis,

Donald Firesmith,

Erich Gamma,

Carlo Ghezzi, Tom Gilb,

Ellen Gottesdiener,

Sam Guckenheimer,

David Harel

Brian Henderson-Sellers,

Watts Humphrey, Martin Griss,

Capers Jones,

Ivar Jacobson,

Philippe Kruchten,

Robert Martin, Stephen Mellor,

Bertrand Meyer,

James Odell,

Meilir Page-Jones,

Dieter Rombach, Ken Schwaber,

Alec Sharp,

Richard Soley.

Ed Yourdan

For current list, please see www.semat.org

Signatories as of March 24, 2010


46/51

g


Agile,Iterative,

RUP,

Computerscience,Metrics,CMMI,

Etc.

Pekka Abrahamsson,

Scott Ambler, Victor Basili,

Jean Bzivin,

Dines Bjorner,

Barry Boehm,

Alan W. Brown, Larry Constantine,

Bill Curtis,

Donald Firesmith,

Erich Gamma,

Carlo Ghezzi, Tom Gilb,

Ellen Gottesdiener,

Sam Guckenheimer,

David Harel

Brian Henderson-Sellers,

Watts Humphrey, Martin Griss,

Capers Jones,

Ivar Jacobson,

Philippe Kruchten,

Robert Martin, Stephen Mellor,

Bertrand Meyer,

James Odell,

Meilir Page-Jones,

Dieter Rombach, Ken Schwaber,

Alec Sharp,

Richard Soley.

Ed Yourdan


47/51

Corporate Signatories as of March 24, 2010

ABB

Ericsson

Fujitsu UK

Microsoft, Spain

SAAB

Samsung SDS

Software Engineering Center -Korea

Telecom Italia

City of Toronto, Ontario

Wellpoint



48/51

Agenda





4. Result



Wrap up


49/51

Final Words

This is smart!

Semat is a fundamentally new way to address the needs of

o

the industry, which needs enough governance but not moreo the developers, who need to select the practices they want

o the academics, who need to understand what the industry really needs

o the educators, who need to train software engineering in general and notjust specific methods

o

the methodologists, who want to create new practices without reinventingthe wheel.

Semat will refound software engineering asa mature discipline


50/51


51/51

[email protected]

key15 iva jacobson(2)

Documents