Вы находитесь на странице: 1из 41

ESSENCE CONFERENCE

ESSENCE-DRIVEN ADAPTIVE
SOFTWARE ENGINEERING
Dr. June Sung Park, Invited Professor, KAIST / President, SEMAT

http://june-sung-park.flavors.me/

ESSENCE KERNEL

Alpha
Activity Space
Competency

Read [5], [12]

ALPHA

<fulfills

Software
System
<produces

Solution

Stakeholders

Work

Team
<performs and plans

Way of
Working

Support>

Requirements
scopes and
constraints>

Endeavor

<provide

focuses>

deal with in any software


engineering project.

<set up to address

Alpha represents things to

Opportunity

use and
consume>

Customer

ALPHA STATE AND CHECKLIST

ALPHA DECOMPOSITION AND EXTENSION

An alpha may have lower-level, more granule

sub-alphas whose states contribute to and drive


the state of the super-alpha.

Alpha

Sub-Alpha

Alpha

Extended Alpha

Association between super-alphas and sub-alphas


can be many-to-many.

An alpha may be Extended (i.e., have the values

of its attributes be changed) in the context of a


Practice (such as Scrum).

ESSENCE KERNEL EXTENSION

Patterns can arrange language

elements into arbitrary


meaningful structures.
Resources can be attached to any

language element.
Tags add user defined

information to any language


element.
User-Defined Types detail,

explain, and constrain the proper


usage of particular patterns,
resources, or tags.

ESSENCE LANGUAGE

STATE OF SOFTWARE ENGINEERING PROJECT

Oh, I guess
its going
OK?

How is the
project
going?

STATE OF SOFTWARE ENGINEERING PROJECT

Yeah, this
is
the
current
state.

Really?
Youre
sure?

ALPHA STATE CHECKLIST


Essence Alpha Card

I use state
checklists.

Alpha State Card

State Checklist
How
do
you know
where we
are?

GOAL STATE
Well, I will show
you
how
I
determine the
next activities
to achieve the
next goal state.

Current State

Goal State
So whats
next to do?

CHOOSING ACTIVITIES TO FULFILL THE GOAL STATE


Essence Kernel
Before we proceed,
you
need
to
understand
how
software engineering
practices
are
mapped
to
the
Essence kernel.

Software Engineering Practice

Hmm

METHOD DESCRIPTION IN ESSENCE LANGUAGE

13

Methods

There are probably hundred

thousands of methods applied in


SE projects worldwide.
There are about 300 well known

practices reusable across projects.

Custom Method A

are defined
in terms of

Custom Method B

Practices

Those practices can be described

using a common notation-Essence kernel and language.


A project method can be

composed of practices.

Essence Kernel

OMG
Standard
Essence Language

are
composed
of

are
described
using

ESSENCE KERNEL AND METHOD

14

<has

produces /
updates>

Method

targets>

Alpha State

< defines

is qualified to
perform>

Activity
Activity Space

Competency

< is composed of

Work Product

Alpha

Practice

profiles>

Role

Read [18]

PRACTICE DESCRIPTION IN ESSENCE LANGUAGE


Essence Kernel

A software engineering practice can be

described in Essence kernel and


language by mapping:
work products to Alphas

15
Practice

Alpha
Work Product
Alpha State

activities to Activity Spaces

roles to Competencies

Read [19]

Activity Space

Activity

Competency

Role

ACTIVITY SPACE

16

Activity spaces are containers of activities performed in a project.

An activity may be a part of another activity forming a work breakdown structure.

Customer

Explore
Possibilities

Solution

Understand the
Requirements

Endeavor

The association between activity spaces and activities can be many-to-many.

Prepare to do the
Work

Ensure Stakeholder
Satisfaction

Understand
Stakeholder Needs

Shape the
System

Coordinate the
Activity

Implement the
System

Test the
System

Support Team

Deploy the
System

Track Progress

Use the System

Operate the
System

Stop the Work

ACTIVITY SPACE AND ALPHA STATE

17

Pre and post conditions of each activity space are suggested in terms of alpha states in the kernel.

Read [19]

ACTIVITY AND STATE TRANSITION

By tailoring the checkpoints for the

default target states we can generate


an Activity Checklist.

Work Product

Alpha State

produces
/ updates>

<has

more Activity Spaces the activity


inherits default state transitions (i.e.,
starting Alpha States and target
Alpha States) and associated
checkpoints (i.e. criteria of done).

Alpha

targets>

By mapping each activity to one or

18

Activity
Activity Space

Competency

Read [16]

COMPUTING ACTIVITY CHECKLIST

19

Read [16]

COMPUTING NEXT ACTIVITIES TO REACH THE GOAL STATE 20

Read [16]

AUTOMATION TOOL: ESSENCIA


Well, I have shown you how I
determined the next activities to
perform to achieve the next goal
state.

This can be automated if we use a


tool that supports the description
of practices using the Essence
kernel, and build a database of
checklists for alpha states.

OK, I see
the value
of Essence
now.

PRACTICE DESCRIPTION APPROACH

22

1. Build an Ontology of the Terms used in the Practice

Parse the text description of the Practice to build a Glossary.

Classify the Terms in the Glossary into Work Products, Activities, Roles, etc.

Add missing Terms such as activities for producing or updating work products and
vice versa.

2. Map the Terms to Essence Language Elements.

Determine alphas, alpha states and checkpoints corresponding to each work product.

Determine activity spaces, beginning and target alpha states, target checkpoints
corresponding to each activity.

Determine competencies required of different roles.

3. Decompose and Extend Essence Kernel Elements to represent detailed

concepts, composite constructs and complex relationships.

Define sub-alphas, sub-activity spaces, patterns, resources and tags to represent


concepts in the practice.

Build Practice Ontology

Map Terms to Essence


Language Elements

Decompose and Extend


Essence Kernel Elements
if necessary

SCRUM PRACTICE

23

Development Team
Task Breakdown

Product Increment

Jeff Sutherland and Ken Schwaber, The Scrum Guide, 2013. (http://www.scrumguides.org/)

SCRUM GLOSSARY
Key Terms

Classification

Daily Scrum
Definition of Done
Developer
Development Team

Activity
Work Product
Role
Role

Development Work

Activity

Improvement Plan
Increment

Work Product
Work Product

Product Backlog

Work Product

Product Backlog Item


Product Backlog Refinement

Work Product
Activity

Product Owner

Role

Scrum Event
Scrum Master
Scrum Team
Sprint
Sprint Backlog
Sprint Goal
Sprint Plan
Sprint Planning
Sprint Retrospective

Composite Activity
Role
Work Product
Milestone
Work Product
Work Product
Composite Work Product
Activity
Activity

Sprint Review

Activity

Stakeholders
Total Work Remaining
Work Unit

Role
Work Product
Work Product

24
Relationship
Role

Activity

Development Team
Sprint Retrospective
Daily Scrum

Product Owner

Sprint Retrospective
Sprint Review
Product Backlog Refinement,
Sprint Review

Work Product

Added Terms

Sprint Plan, Total Work Remaining


Increment, Product Backlog Refinement
Sprint Backlog, Development Work, Increment
Sprint Backlog, Development Work Plan, Work Unit,
Increment

Development Work
Plan

Sprint Plan, Sprint Goal, Sprint Backlog, Definition of Done


Product Backlog Item

Product Backlog
Creation

Product Backlog
Product Backlog
Product Backlog Creation,
Product Backlog Refinement,
Sprint Review

Product Backlog

Product Backlog
Creation

Sprint Retrospective
PO, DT, SM
Development Team

Product Backlog, Sprint Goal, Development Work


Sprint Planning

Sprint Planning

Sprint Plan
Sprint Plan, Definition of Done,
Increment, Product Backlog, Total Work Remaining, Sprint
Plan

Scrum Master
Stakeholders,
Sprint Review
Sprint Review, Daily Scrum

Sprint Backlog, Development Work

SCRUM ONTOLOGY

25

SCRUM TO ESSENCE KERNEL MAPPING


Scrum

26

Explore Possibilities
Opportunity

Product Backlog

Product
Backlog Item

Understand the
Requirements

Sprint Goal
Requirements

Understand Stakeholder
Needs

Product Backlog
Creation
Product Backlog
Refinement

Sprint Backlog
Shape the System
Definition of
Done

Software System

Increment

Work

Development
Work Plan

Implement the System

Development Work

Test the System

Coordinate the Activity

Sprint Planning

Total Work
Remaining

Track Progress

Daily Scrum

Team

Scrum Team

Ensure Stakeholder
Satisfaction

Sprint Review

Way of Working

Improvement
Plan

Support the Team

Sprint Retrospective

Work Unit

COMPOSITE CONSTRUCTS IN SCRUM


Sprint Planning

Development Work

Daily Scrum

produces

may change

27
Sprint
Plan

Sprint
Goal
Product Backlog
Item

Sprint
Backlog
Development
Work Plan

Conducts

Scrum Event

Sprint
Produces

Increment

Sprint Review
Sprint
Retrospective

Manages

Product Backlog

Product Owner
Performs

Scrum Team
Development Team

Creates

Ensures
enactment of

Scrum Master

Scrum

provides input to

Work Unit

ACTIVITY TO ALPHA STATE MAPPING

Product
Backlog
Creation

Explore Possibilities

Product
Backlog
Refinement

Understand St. Needs

Understand Reqts

Understand Reqts
Understand St. Needs

Sprint
Planning

Understand Reqts
Coordinate Activity

Development
Work

Shape the System

Daily Scrum

Track Progress

Sprint
Review

Ensure St. Satisfaction

Sprint Retro.

Support the Team

Implement / Test

Track Progress

In Place
Working
Well
Retired

Way of Working

Closed
Principles
Established
Foundation
Established
In Use

Started
Under
Control
Concluded

Prepared

Initiated

Work

Adjourned

Formed
Collaborating
Performing

Seeded

Team

Retired

Operational

Ready

Software System

Fulfilled
Architecture Se
lected
Demonstrable
Usable

Addressed

Acceptable

Coherent

Activity Spaces

Requirement

Bounded

Activity

Addressed
Benefit
Accrued
Conceived

Alpha States

Identified
Solution
Needed
Value
Established
Viable

Opportunity

28

ACTIVITY DEFINITION CARD

29
Scrum Practice

Sprint Review

The project method

assembled from Essencepowered practices becomes a


small deck of cards in their
pockets, which team
members can easily pull out
to discuss the current project
state, the goal state to
achieve, and the next
activities to perform to reach
the goal state.

Teams can also discuss areas

of improvement by referring
to the cards and their
associated checklists.

Ensure Stakeholder
Satisfaction
Track Progress

Product Owner

Sprint Goal

Development Team

Sprint
Backlog

Scrum Master

Stakeholder

Increment

Product
Backlog

Opportunity

Viable

A usable system that demonstrably addresses the opportunity is available.


The stakeholders agree that the available solution is worth deploying.
The stakeholders are satisfied that the solution produced addresses the opportunity.

Addressed

Work

Under Control

Concluded

All outstanding tasks are administrative housekeeping or related to preparing the next piece of work.
Work results have been achieved.
The stakeholders have accepted the resulting software system.

WORK PRODUCT TO ALPHA STATE MAPPING


Work Product

30

Alpha State

Alpha

Begin In

Target

Requirements

Bounded

Acceptable

Opportunity

Solution Needed

Viable

Sprint Goal

Requirements

Bounded

Coherent

Sprint Backlog

Requirements

Coherent

Acceptable

Definition of Done

Requirements

Acceptable

Fulfilled

Development Work Plan

Work

Initiated

Prepared

Software System

Architecture Selected

Ready

Work

Prepared

Concluded

Total Work Remaining

Work

Started

Under Control

Scrum Team

Team

Seeded

Performing

Improvement Plan

Way of Working

Foundation Established

Working Well

Product Backlog

Increment

WORK PRODUCT TO ALPHA STATE MAPPING

Increment
Product Backlog

Sprint
Goal
Sprint
Backlog
Definition
of Done

Dev Work
Plan
Increment

TWR

31

Scrum Team
Improve
Plan

WORK PRODUCT DEFINITION CARD


The Activity Definition Cards and

Work Product Definition Cards


provide concise reminders and
cues for team members as they
go about their daily tasks.

Scrum Practice

Sprint Backlog

Product
Backlog Item

This is a fundamental difference

from traditional approaches,


which tend to overemphasize
method description as opposed
to method use, and tend to be
consulted only by people new to
the team.

Understand Stakeholder
Needs

Development
Work Plan

By providing practical checklists,

as opposed to conceptual
discussions, the Essencepowered practice becomes
something the team uses on a
daily basis.

32

Understand the
Requirements

Work Unit

Sprint Planning

Coordinate the Activity

Requirements

Coherent

The stakeholders accept that the requirements describe an acceptable solution.


The rate of change to the agreed requirements is relatively low and under control.
The value provided by implementing the requirements is clear.
The parts of the opportunity satisfied by the requirements are clear.
The requirements are testable.

Commitment is made.
Cost and effort of the work are estimated.
Resource availability is understood.
Governance policies and procedures are clear.
Risk exposure is understood.
Acceptance criteria are defined and agreed with client.
The work is broken down sufficiently for productive work to start.
Tasks have been identified and prioritized by the team and stakeholders.
A credible plan is in place.
Funding to start the work is in place.
The team or at least some of the team members are ready to start the work.
Integration and delivery points are defined.

Acceptable

Work

Initiated
Prepared

SCRUM WORKFLOW

33

METHOD COMPOSITION
Scrum
Agile
Modeling

34
Explore Possibilities

Stakeholder
Opportunity

Opportunity

Product
Backlog

Business
Product
Requirements
Backlog Item

Understand the
Requirements

Sprint Goal
Requirements

Understand
Stakeholder Needs

Product Backlog
Refinement

Sprint Backlog
Shape the System
Definition of
Done

Software
System

Business Analysis
Product Backlog
Creation

Implement the System

Software Requirement
Model
Increment

Spike
Development
Work
Model Storming

Test the System

Software Architecture
Coordinate the
Activity

Sprint Planning

Total Work
Remaining

Track Progress

Daily Scrum

Team

Scrum Team

Ensure Stakeholder
Satisfaction

Sprint Review

Way of Working

Improvement
Plan

Support the Team

Sprint Retrospective

Work

Read [18]

Development
Work Plan

Work Unit

METHOD COMPOSITION

35

Kernel elements covered by Scrum


Kernel elements additionally covered by Agile Modeling

Add XP

Add
SPM

Add
Dev
Ops

CASE STUDY: RED HAT

36

Red Hat Architect Team have been using Essence to help standardize its approach to engagements.
They are using alpha state cards in project planning, which provide consistent language and measurable objectives

with which to access the current state, or articulate next steps and goals.
They created a dashboard website to record and report the current alpha states of engagement projects, which

facilitated high-level project governance.


Essence was also used to build the Red Hat Architectural Framework which provides a framework to collate and

index established approaches: techniques, activities, practices and methods. This enables consultants to find
suitable approaches when seeking to achieve goals expressed in terms of Essence.
Red Hat also applies Essence to analysing existing methods and developing more rounded practices. This type

of analysis has proven useful in finding the holes in existing processes and reworking a process to support a
progressive state-based model that is easier to track and apply.

Read [23]

CASE STUDY: FUJITSU UK

37

Fujitsu UK has been using Essence, in particular alpha state checklists, in iteration planning with customers
They also used Essence to analyse, compare, standardize and integrate various Design and Build Methodologies

(such as Architecture DBM, Applications DBM, Infrastructure DBM, Service DBM, etc.)
With all the disruptive changes occurring in IT today including cloud, mobile, big data and IoT, Fujitsu felt they

needed a common framework to standardize their methodologies and applied the Essence kernel successfully to
that end.
The methodologies were further improved so that quality assurance involved checking alpha states rather than

activity completions.
Fujitsu has 165 thousand employees across most geographies in the world. Fujitsu is now working on

developing a common set of global standard methodologies and processes using the Essence as the common
framework.

Read [11]

CONCLUSION
You can use Essence kernel to:
Describe practices
Merge them into a project method
Build an enterprise method architecture
Monitor health and progress of the project
Set up an enterprise-wide dashboard for monitoring all

ongoing projects
Adaptively determine project goals and activities based

on the current state assessment.


Read [7], [10], [18], [20]

Wed better
learn
and
use Essence.

I think so, too. It


really
makes
38
defining and using
methods easy.

REFERENCES

39

1.

D. Cunningham, Enabling Fujitsus Industrialized Delivery of Application Services, OMG Essence Information Day, Berlin, 2013.
(http://www.omg.org/news/meetings/tc/berlin-13/special-events/essence-pdfs/S7-Cunningham.pdf)

2.

B. Elvester, G. Benguria and S. Ilieva, A Comparison of the Essence 1.0 and SPEM 2.0 Specifications for Software Engineering Methods,
Workshop on Process-Based Approaches to Model-Driven Engineering, Montpellier, France, 2013. (http://dl.acm.org/citation.cfm?id=2489835)

3.

Ivar Jacobson International, Asian Telecommunications Equipment Vendor Successfully Achieves Rapid and Sustainable Agile Transformation,
2014. (http://www.ivarjacobson.com/uploadedFiles/Pages/Knowledge_Centre/Resources/Case_Studies/Resources/AsianTelecomm1.pdf)

4.

I. Jacobson, P.-W. Ng, P. E. McMahon, I. Spence and S. Lidman, The Essence of Software Engineering: The SEMAT Kernel, Communications
of the ACM, Vol. 55, pp. 42-29, Dec. 2012.

5.

I. Jacobson, P.-W. Ng, P. E. McMahon, I. Spence and S. Lidman, The Essence of Software Engineering: Applying the SEMAT Kernel, AddisonWesley, 2013.

6.

I. Jacobson, I. Spence and P.-W. Ng, Agile and SEMAT-Perfect Partners, Communications of the ACM, Vol. 56, pp. 53-59, Nov. 2013.

7.

I. Jacobson, P.-W. Ng, I. Spence and P. E. McMahon, Major-League SEMATWhy Should an Executive Care? Communications of the ACM,
Vol. 57, pp. 44-50, April 2014.

8.

I. Jacobson and E. Seidewitz, A New Software Engineering, Communications of the ACM, Vol. 57, pp. 36-41, Dec. 2014.

REFERENCES
9.

40

A. McDonough, Munich Re and Essence Kernel and Language for Software Engineering Methods: A Case Study, OMG, 2014.
(http://www.omg.org/news/whitepapers/Munich_Re_Essence_Case_Study-2014-12-01_JP.pdf)

10. P. E. McMahon, 15 Fundamentals for Higher Performance in Software Development, Leanpub, 2014.
11. S. Nadin, Using Essence to Deliver Together: Practical Experience at Fujitsu, Essence-in-Practice Conference in OMG Technical Meeting,

Berlin, 2015. (http://www.omg.org/news/meetings/tc/berlin-15/special-events/essence-presentations/nadin.pdf)

12. Object Management Group, EssenceKernel and Language for Software Engineering Methods 1.0, November 2014.

(http://www.omg.org/spec/Essence/)

13. J. S. Park, Essence Kernel-Based Enterprise Method Architecture, OMG Essence Information Day, Berlin, 2013.

(http://www.omg.org/news/meetings/tc/berlin-13/special-events/essence-pdfs/S5-Park.pdf)

14. J. S. Park, I. Jacobson, B. Myburgh, P. Johnson and P. E. McMahon, SEMAT Yesterday, Today and Tomorrow, SEMAT, 2014.

(http://semat.org/wp-content/uploads/2014/12/SEMAT-Yesterday-Today-and-Tomorrow-v1.0.pdf).

15. J. S. Park, Essence-Based Adaptive Software Engineering, Pre-Conference Tutorial in the Fourth International Conference on Emerging

Applications of Information Technology (EAIT), Indian Statistical Institute, Kolkata, India, Dec. 19, 2014.
(http://www.scribd.com/doc/251364248/Essence-Tutorial-JP)

16. J. S. Park, Essence-Based Goal-Driven Adaptive Software Engineering, General Theory of Software Engineering (GTSE) Workshop in the

International Conference on Software Engineering, Florence, Italy, May 18, 2015.


(http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7169393&filter%3DAND(p_IS_Number%3A7169380)

REFERENCES

41

17. J. S. Park, Essence-Powered Scrum: A Generic Approach to Describing Practices Using Essence Kernel and Language, Essence-in-Practice

Conference in OMG Technical Meeting, Berlin, Germany, June 18, 2015. (http://www.omg.org/news/meetings/tc/berlin-15/specialevents/essence-presentations/park.pdf)

18. J. S. Park, Software Engineering in the Context of Business SystemsHow Essence can Help, in Ivar Jacobson and Harold Lawson (ed.)

Software Engineering in the Systems Context, College Publications: London, 2015. (ISBN 978-1-84890-176-6)

19. J. S. Park, P.E. McMahon and B. Myburgh, Scrum Powered by Essence, ACM SIGSOFT Software Engineering Note, Nov. 2015 (forthcoming).
20. C. Praire and T. Sedano, "State-Based Monitoring and Goal-Driven Project Steering: Field Study of the SEMAT Essence Framework",

International Conference on Software Engineering, Hyderabad, India, 2014.


(http://repository.cmu.edu/cgi/viewcontent.cgi?article=1147&context=silicon_valley)

21. B. Perkens-Golomb, Applying SEMAT concepts at Munich Re: Personal Reflections, OMG Essence Information Day, Berlin, 2013.

(http://www.omg.org/news/meetings/tc/berlin-13/special-events/essence-pdfs/S6_Burkhard.pdf)

22. B. Perkens-Golomb, Successful Utilization of ESSENCE at Munich Re, Essence-in-Practice Conference in OMG Technical Meeting, Berlin, 2015.

(http://www.omg.org/news/meetings/tc/berlin-15/special-events/essence-presentations/perkens-golomb.pdf)

23. E. Seymour, We All Have Different Ways To Do Things. And Thats OK. Essence-in-Practice Conference in OMG Technical Meeting, Berlin,

2015. (http://www.omg.org/news/meetings/tc/berlin-15/special-events/essence-presentations/seymour.pdf)

24. C. Zapata and I. Jacobson, A First Course in Software Engineering Method and Theory, DYNA, National University of Columbia, Vol. 81,

Jan./Feb. 2014. (http://www.scielo.org.co/scielo.php?pid=S0012-73532014000100026&script=sci_arttext)