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]
2
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
3
ALPHA STATE AND CHECKLIST
4
ALPHA DECOMPOSITION AND EXTENSION
5
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.
6
ESSENCE LANGUAGE
7
STATE OF SOFTWARE ENGINEERING PROJECT
Oh, I guess
it’s going
OK?
How is the
project
going?
8
STATE OF SOFTWARE ENGINEERING PROJECT
Yeah, this
is
the
current
state.
9
Really?
You’re
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 what’s
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 Plan, Total Work Remaining
Increment, Product Backlog Refinement
Sprint Backlog, Development Work, Increment
Sprint Backlog, Development Work Plan, Work Unit,
Increment
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]
We’d better
learn
and
use Essence.
I think so, too. It
really
makes
38
defining and using
methods easy.
REFERENCES
39
1.
D. Cunningham, “Enabling Fujitsu’s 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. Elvesæter, 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 SEMAT—Why 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,
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 Systems—How 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. Péraire 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.