The Essential Software Engineering Approach to...

“From Sight to Insyte”Revision 1.0 - 5 September 2012Tel: 011-782-0463 / Fax: 086-505-2686 / Mobile: 082-551-5585 / e-mail: [email protected]

The Essential Software

Engineering Approach to

Requirements Engineering

Presented at the BASSA 2012 Conference

4 & 5th September 2012

Protea Hotel Balalaika, Sandton

Introduction

� Setting the scene:

�BABOK on

Requirements

Engineering

� Situational

Responses

� SEMAT

Revision 1.0 - 5 September 2012Tel: 011-782-0463 / Fax: 086-505-2686 / Mobile: 082-551-5585 / e-mail: [email protected]

BABOK on Requirements Engineering

� Elicitation, analysis & communication of

requirements,

� With objective of ensuring Visibility &

Understanding by stakeholders,

� Is central to discipline of Business Analysis


Based on statement in BABOK 2.0

Requirements Analysis

� One of the BABOK Knowledge Areas

� Involving execution of tasks

� And use of techniques

� A key task:

�Plan the Business Analysis Approach

�Requiring a situational response

� Sometimes Waterfall

� Sometimes Agile


Situational Tension(Explained in the (slighted adapted) Manifesto for Agile Software Development)

(http://agilemanifesto.org/)

� We are uncovering better ways of satisfying requirements when developing software by doing it and helping others do it.

� Through this work we have come to value: � Individuals and interactions over processes and tools

�Working software over comprehensive documentation

� Customer collaboration over contract negotiation

� Responding to change over following a plan

� That is, while there is value in the items on the right, we value the items on the left more.



Calls for a Chaordic Response

� Chaordic

� The behaviour of any self-governing organism,

organization or system which harmoniously blends

characteristics of order and chaos.

� Patterned in a way dominated by neither chaos nor

order.

� Characteristic of the fundamental organising principles

of evolution and nature

(Dee Hock - “Birth of the Chaordic Age” – Berrett-Koehler, 1999)


A Chaordic Response

APPROACH TO MANAGEMENT AND CONTROL

Low Ceremony High Ceremony

(Empirical) (Defined)

APPROACH TO PRODUCING THE RESULTS

Organic C

onventional

(Empirical) (D

efined)

Organic C

onventional

(Empirical) (D

efined)





DOING THE

WORK

PROVIDING

OVERSIGHT


Defined and Empirical Processes

� If a process can be

� fully defined,

� with all things known about it

� so that it can be designed and

run repeatably

� with predictable results,

� It is known as a defined

process.

� Such as the conventional,

Waterfall approach

� If all things about a process

� are not fully known

� only what generally happens

when you mix the inputs, and

� what to measure and control

to get the desired output

� They are called empirical

processes.

� Such as the organic,

Iterative approach


SELF

DIRECTED

RUP Type I

MANAGED

COSTS

(WetAgileTM)

RUP Type IV

Adapted from “Towards

Understanding The Relationship

Between Process Capability

And Enterprise Flexibility”

Myburgh 2005

Insyte’s Complex-Adaptive Situational Model (CASM)

DECREASING VISIBILITY IN

CREASING PARALLE

LISM

INCREASING PROCESS CLARITY

INCREASING FORMALITY





Organic C

onventional

(Empirical) (D

efined)

Organic C

onventional

(Empirical) (D

efined)

APPROACH TO PRODUCING THE RESULTSLo

w Ceremony High Ceremony



WetAgile is a trademark of

Steve Pieczko

CRAFTED

QUALITY

(Agile)

RUP Type III

CONTROLLED

QUALITY

(Waterfall)

RUP Type II

CHAORDICBAND OF

FEASIBILITY

RUP (Rational Unified Process)

is a trademark of IBM


Characteristics:Crafted Quality (Agile) and Controlled Quality (Waterfall)

� Management Characteristics

� Customer Relations

� Planning & control

� Project Communications

� Technical Characteristics

� Requirements Definition

� Development

� Test

� Application Characteristics

� Project goals

� Project size

� Application environment

� Personnel Characteristics

� Customer Characteristics

� Developer Characteristics

� Organizational Culture

� Process Characteristics

� Type

� Repeatability

� Multi-tasking

(Adapted from “Balancing Agility and Discipline” – Boehm and Turner 2004)


Technical CharacteristicsCRAFTED QUALITY

(AGILE – RUP TYPE III)

CONTROLLED QUALITY

(WATERFALL – RUP TYPE II)

REQUIREMENTS �Prioritised informal stories and

test cases

�Undergoing unforeseeable

change

�Evolving architecture

�Formalised project, capability,

interface, quality, architecture

�Foreseeable evolution

requirements

�Guided by full-scope

architecture

DEVELOPMENT �Simple design

�Short increments

�Re-work assumed inexpensive

�Extensive design

�Longer increments

�Re-work assumed expensive

TESTING �Executable test cases define

requirements

�Documented test plans and

procedures

(Adapted from “Balancing Agility and Discipline” – Boehm and Turner 2004)

REQUIRES A SITUATIONAL APPROACH

TO

REQUIREMENTS ENGINEERING

Essential SEMAT Approach to

Requirements Engineering� Software Engineering Method and Theory (http://semat.org/)

� Launched in September 2009 by Ivar Jacobson, Bertrand

Meyer and Richard Soley

� To re-found software engineering based on

� Solid theory,

� Proven principles and

� Best practices.

� Includes a kernel of widely-agreed elements, extensible for

specific uses


Fundamental problem

� Every one of us knows how

to engineer our

requirements,

� But as a community we

have

� No widely accepted

common ground

� Use Case Descriptions

� User Stories

� Declarative Requirements

� Etc.


Start from a common ground

The Kernel:� Should be harvested from a

large number of methods

� Is practice and method

agnostic.

� Includes elements which are

universal for all software

engineering efforts.

� The essence of software

engineering (including

Requirements Engineering)


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


The Kernel Enables Situational Software Engineering


Organizing the Kernel


AREAS OF

CONCERN

Alphas:

What we work with

and aspire to

What is an Alpha?

� An essential element of the

software engineering endeavor

that is:

� Relevant to an assessment of the

progress and health of the endeavor.

� Progress and health of things we

ASPIRE to

� Alpha is an acronym for:

� Aspiration-Led Progress Health

Attribute, or an

� Abstract-Level Progress Health

Attribute


The Seven Kernel Alphas


The Alpha Structure


Requirements: One of the Alphas


Checklist for Requirements


� The initial set of stakeholders agrees that

a system is to be produced.

� The stakeholders that will use the new

system are identified.

� The stakeholders that will fund the initial

work on the new system are identified.

� There is a clear opportunity for the new

system to address.

Using the Kernel

in Practice


Using the Kernel in Practice


What’s New About Semat?


� Focus is 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 practices

� 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 process is what the team does. Adaption happens dynamically as a

retrospective of what the team did through a feedback loop

What You Can Do Now


BECOME A

SUPPORTER

READ THE

BOOK

References

1. Barry Myburgh: “Towards understanding the relationship between Process Capability and Enterprise

Flexibility”, Proceedings of the ImproveIT Conference, 2005. (Updated – September 2010)

2. 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

3. 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

4. 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

5. 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

6. 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.

7. “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)


The Essential Software Engineering Approach to...

Documents

Transcript of The Essential Software Engineering Approach to...