Bertrand Meyer Richard Soley What Are We Going to Do About It?

What we should teach you about software at school

The Essence

• The State of the Industry • Specific Problems • A Case for Action – Standing on a Solid Theory – Including a Kernel of Widely-Agreed Elements • Using the Kernel • Extending the Kernel • What’s in it For You? Final Words

2 Are we seen as a trustworthy industry?

• How a Software Company would design a Treeswing Are we seen as a trustworthy industry?

Source: Top 10 Software Failures Of 2011 By Phil Codd

Are we seen as a trustworthy industry?

engineering today

Software . hamperedpractices gravely by immature Agenda

• The State of the Industry • Specific Problems • A Call for Action – Standing on a Solid Theory – Including a Kernel of Widely-Agreed Elements • Using the Kernel • Extending the Kernel • What’s in it For You? Final Words

6 The prevalence of fads typical of fashion industry

Software Development seems to be driven by fashions and fads – Twenty years ago it was all about OO – Twelve years ago it was about components, UML, Unified Process (RUP) – Ten years ago it was about CMMI and Spice – Four years ago it was about XP – Yesterday it was about Scrum – Now it is about Lean and Kanban

All good, but none has all you need! The lack of a sound, widely accepted theoretical basis.

Everyone of us knows how to develop our software, but as a community we have no widely accepted common ground

The huge number of methods…

• The problem is not the huge number but – We cannot compare them so we cannot learn from them – We cannot select the best practices from them – Not even within a large company do we know which methods we have. – For the individual practitioner she has no solid knowledge which she can take from work to work.

9 The lack of credible experimental evaluation and validation.

We throw out our old method and replace it with a new popular one without fully understanding the consequences ---$$$$

The split between industry practice and academic research. Academic Research Industry Practice Industry We need to do something about it!

CALL FOR ACTION – part 1 • Software engineering is gravely hampered today by immature practices. Specific problems include: – The prevalence of fads more typical of fashion industry than of an engineering discipline. – The lack of a sound, widely accepted theoretical basis. – The huge number of methods and method variants, with differences little understood and artificially magnified. – The lack of credible experimental evaluation and validation. – The split between industry practice and academic research. Agenda

13 The Semat initiative

SOFTWARE ENGINEERING METHOD AND THEORY

www.semat.org Founded by the Troika in Sep 2009: Ivar Jacobson Bertrand Meyer Richard Soley What are we going to do about it?

CALL FOR ACTION – part 2 • 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

This is the Grand Vision What are we going to do about it?

CASE FOR ACTION – part 2 • We support a process to refound software engineering based on a solid theory, proven principles and best practicesIncluding that: a – StandingInclude a kernel ofon widely-agreed a elements, extensibleKernel for specificof uses – Addresses both technology and people issues – AreSolid supported Theory by industry , academia, researchersWidely-Agreed and users – Support extension in the face of changing requirements Elements and technology

This is the Grand Vision What Semat is not

A New Competing Unified With Existing Method Methods Signatories

For current list, please see www.semat.org • Pekka Abrahamsson, • David Harel • Scott Ambler, • Brian Henderson-Sellers, • Victor Basili, • Martin Griss, • Jean Bézivin, • Capers Jones, • Robert V. Binder • Ivar Jacobson, • Dines Bjorner, • Philippe Kruchten, • Barry Boehm, • Harold Lawson, • Alan W. Brown, • Robert Martin, • Larry Constantine, • Bertrand Meyer, • Steve Cook, • James Odell, • Bill Curtis, • Meilir Page-Jones, • Donald Firesmith, • Dieter Rombach, • Erich Gamma, • Ken Schwaber, • Carlo Ghezzi, • Alec Sharp, • Tom Gilb, • Richard Soley. • Ellen Gottesdiener, • Andrey Terekhov • Sam Guckenheimer, • Fuqing Yang • Robert Glass, • Ed Yourdon Corporate and Academic Signatories

• ABB, Switzerland • SAAB, Sweden • Chalmers, Sweden • Samsung SDS, Korea • Ericsson, Sweden • Swedish Institute of Computer • Fujitsu, UK Science, Sweden • Huawei, China • SINTEF, Norway • IBM, USA • Software Engineering Center, Korea • Microsoft, Spain • SEI, USA • KAIST, Korea • Telecom Italia, Italy • Peking University, China • City of Toronto, Ontario, Canada • Royal Institute of Technology, • Wellpoint, USA Sweden

For current list, please see www.semat.org Agenda

20 Standing on a Solid Theory

Examples: – Darwin’s theory of natural selection, – Maxwell’s equations, – Einstein’s theory of relativity.

There is nothing so practical as a good theory! -- Kurt Lewin Maxwell’s Equations – Now, an established theory

This is the kind of result we desire for Semat – but most likely of very different nature

22 Software Engineering doesn’t lack theories

There are an abundant number of theories in software engineering: • Boehm’s The Constructive Cost Model – COCOMO, • Parnas’ principle of information hiding, • Constantine’s Cohesion and Coupling, • Conway’s Law, • Dijkstra’s theory of cognitive limits (“Go to statement considered harmful”), • Wirth’s stepwise refinement, • Meyer’s Design by Contract, • Etc., etc., etc..

But none of these theories is foundational Software Engineering doesn’t lack theories

There are an abundant number of theories in software engineering: a • Boehm’s The Constructive Cost Model – COCOMO, find • Parnas’ principle of information hiding, to • Constantine’s Cohesion and Coupling, of • Conway’s Law, hoping top • Dijkstra’s theory are of cognitive limits (“Go on to statement considered We harmful”), theory • Wirth’s stepwise refinement, specialized • Meyer’score Design by Contract, • Etc., etc., etc.. more stand which can But nonetheories of these theories is foundational Agenda

25 Include a kernel of widely-agreed elements

• The Kernel should be harvested from a large number of methods • The Kernel is practice and method agnostic. • The Kernel includes elements which are universal for all software development efforts.

Kernel

The Kernel includes the essence of software engineering

Michelangelo (attributed) “I am freeing the statue from the block”. Paraphrasing him: “We are freeing the kernel from the methods”. Inside the Kernel

Customer

Solution

Endeavor

27 An Example of a Kernel Element

Software System: A system made up of software, hardware, and data that provides its primary value by the execution of the software. A software system can be part of a larger software, hardware, business or social solution.

Architecture An architecture has been selected that addresses the Selected key technical risks and any applicable organizational constraints. An executable version of the system is available that Demonstrable demonstrates the architecture is fit for purpose and supports functional and non-functional testing.

Usable The system is usable and demonstrates all of the quality characteristics required of an operational system.

Ready The system (as a whole) has been accepted for deployment in an operational environment.

Software System SoftwareSystem Operational The system is in use in an operational environment.

Retired The system is no longer supported.

28 Inside the Kernel

Customer get a likely Solution will most within We kernel through Endeavorstandard months six OMG

29 Agenda

30 A few words on how to use the kernel

• Each kernel element represents one universally known concept in software engineering – Requirements, Software System, Work , Team, etc. • Each kernel element has a series of states. • Compactly described as a deck of cards – Can fit into your pocket. An example: an extract from the kernel

Customer

Solution

Endeavor

32 An example: an extract from the kernel

Requirements Software < fulfils System constrains > constrains and Scopes < produces < produces

< performs and plans Work Team Plan: Determine Current State

Requirements

Software System

Work

Team Plan: Determine Current State

Completed Pending Plan: Determine Next State Plan: Determine How to Achieve Next State Agenda

38 Extending the Kernel with Practices

• The Kernel is Universal. • By adding Practices on top of the Kernel you create a specific Method. • Practices such as Use Cases, Test-Driven Development, Etc The Kernel provides a shared frame of reference

Declarative Req’ts Team A Waterfall Architecture

The Kernel

Use Case Architecture Architecture

Team B Component Iterative User Story Scrum Team C

Many methods all built on the same kernel. Summing up

Method Practices

Analysts Developers Architecture Iteration Use Case Component

Software Testers Leaders Development Kernel Practitioners are the target group Theory Summary - What is new?

• Focus are the practitioners, not the process engineers • Focus is Method Use and Adaption, not Method Description • Semat is inclusive and not exclusive – it includes all relevant methods and practices (“good or bad”) • There is a small Kernel of essential • For small teams and large organizations • Practices from the bottom, and not process from the top • Separation of concerns is a fundamental principle • Light and agile in working with methods • The old metaphor: ‘Process is program – Team is computer’ is gone • The process is what the team does. Adaption happens dynamically as a retrospective of what the team did through a feedback loop.

Watts Humphrey (CMMI): “This (SEMAT) meeting in Zurich (2010) is likely to be an historic occasion much like the 1968 NATO session in Garmish.” Agenda

43 What is in it for you as a Software Professioanl

The kernel helps by providing a firm foundation The kernel helps to for your experiences and incrementally improve your team’s way-of your way-of-working. Develop working. Great Software The kernel improves communication allowing for quick learning.

Your objective is to develop great software quickly. The kernel helps you to learn, evolve and grow What’s in it for you

Industry Software Academics Big companies have Asked to educate and many processes. Professional research. Challenges: Challenges: Want to become - The Gap between - Reuse practices experts. Challenges: research and industry - Reuse training - Their skills are not - No widely accepted - “Reuse” of people easily reusable for a theory - Evolutionary new product. - Teaching instances of improvement is hard - Their career path methods don’t create follows a zig-zag track generalists from hype to hype.

SEMAT targets the whole software community. Agenda

• The State of the Industry • Specific Problems • A Case for Action – Based on a solid theory – Include a kernel of widely-agreed elements • How to Use the Kernel • What’s in it For You? • Wrap Up / Final Words

46 What you can do now

Become a supporter. Go to www.semat.org Join the China Chapter of Semat What you can do now

Become a supporter. Go to www.semat.org Join the China Chapter of Semat Read the OMG submission What you can do now

Become a supporter. Go to www.semat.org Join the China Chapter of Semat

ReadRead the my OMG new book submissionwith Pan Wei and three other top guys What you can do now

Become a supporter. Go to www.semat.org Join the China Chapter of Semat

ReadRead the my OMG new book submission with Pan Wei and Us!!! three other top guys Join References

1. Ivar Jacobson and Bertrand Meyer: “Methods need theory” Dr. Dobb's Journal, August 06, 2009. Online at http://www.drdobbs.com/architecture-and-design/219100242 2. Ivar Jacobson and Ian Spence: “Why we need a theory for software engineering” Dr. Dobb's Journal, October 02, 2009. Online at http://www.drdobbs.com/architecture-and-design/220300840 3. Ivar Jacobson, Bertrand Meyer, and Richard Soley: “Call for Action: The Semat Initiative” Dr. Dobb's Journal December 10, 2009. Online at http://www.drdobbs.com/architecture-and-design/222001342 4. Ivar Jacobson, Bertrand Meyer, and Richard Soley: “The Semat Vision Statement” online at http:// blog.paluno.uni-due.de/semat.org/wp-content/uploads/2012/03/SEMAT-vision.pdf 5. Ivar Jacobson, Shihong Huang, Mira Kajko-Mattsson, Paul McMahon, Ed Seymour. “Semat - Three Year Vision” Programming and Computer Software 38(1): 1-12 (2012), Springer 2012. DOI: 10.1134/ S0361768812010021. 6. “ Essence – Kernel and Language for Software Engineering”(OMG Document number: ad/ 2011-02-04) A proposal submitted to OMG RFP (OMG Document ad/2011-06-26) References

1. Ivar Jacobson and Bertrand Meyer: “Methods need theory” Dr. Dobb's Journal, August 06, 2009. Online at http://www.drdobbs.com/architecture-and-design/219100242 2. Ivar Jacobson and Ian Spence: “Why we need a theory for software engineering” Dr. Dobb's Journal, October 02, 2009. Online at http://www.drdobbs.com/architecture-and-design/220300840 3. Ivar Jacobson, Bertrand Meyer, and Richard Soley: “Call for Action: The Semat Initiative” Dr. Dobb's Journal December 10, 2009. Online at http://www.drdobbs.com/architecture-and-design/222001342 and 4. Ivar Jacobson, Bertrand Meyer, and Richard Soley: “The Semat Vision Statement” online at http:// blog.paluno.uni-due.de/semat.org/wp-content/uploads/2012/03/SEMAT- thesevision.pdf 5. Ivar Jacobson, Shihong Huang, Mira Kajko-Mattsson, Paul McMahon, Ed Seymour. “Semat - Three Year Vision” Programming and Computer find Software 38(1): 1-12 (2012), Springer 2012. DOI: 10.1134/ S0361768812010021. can 6. “ Essence – Kernel and Language for Software Engineering”(OMG Document number: ad/ 2011-02-04)You A proposal submitted to OMG RFP (OMG Document ad/2011-06-26) on www.semat.org more Questions

• Email: – [email protected]

• OMG website: – www.omg.org

• SEMAT website: – http://www.semat.org There will be hundreds of practices

• Most will be contributed by the community

Consultancy Firms Tool Vendors Experts Methodologists Organization Process Engineers

Practice Ecosystem

Project Leaders Developers

54 • I would be very glad to discuss with you what knowledge base (theory) could help us explain and predict the pertinent phenomena of software engineering. I propose that we are looking for a way to answer the main questions of the field, including the following:

• • Is method A better than method B for my organization? Why? • • Is it true that adding manpower to a late software project makes it later (Brook's Law)? Why? • • Is it true that a small sharp team, with as few minds as possible, is best? Why? • • Is it true that the GOTO statement is harmful (as posited by Dijkstra)? Why? • • Is it true that pair programming leads to better code quality? Why? • • Is it true that iterative programming leads to better requirements fulfillment? Why? • • Is it true that XP practices flattens the cost of change curve (as proposed by Kent Beck)? Why? • • Is it true that organizations which design systems are constrained to produce systems which are copies of the communication structures of the organization (Conway's Law)? Why • • Is it true that object-orientation leads to better code than the previous paradigms? Why? • • etc.