Professional Documents
Culture Documents
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
ALPHA
<fulfills
Software
System
<produces
Solution
Stakeholders
Work
Team
<performs and plans
Way of
Working
Support>
Requirements
scopes and
constraints>
Endeavor
<provide
focuses>
<set up to address
Opportunity
use and
consume>
Customer
Alpha
Sub-Alpha
Alpha
Extended Alpha
language element.
Tags add user defined
ESSENCE LANGUAGE
Oh, I guess
its going
OK?
How is the
project
going?
Yeah, this
is
the
current
state.
Really?
Youre
sure?
I use state
checklists.
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?
Hmm
13
Methods
Custom Method A
are defined
in terms of
Custom Method B
Practices
composed of practices.
Essence Kernel
OMG
Standard
Essence Language
are
composed
of
are
described
using
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]
15
Practice
Alpha
Work Product
Alpha State
roles to Competencies
Read [19]
Activity Space
Activity
Competency
Role
ACTIVITY SPACE
16
Customer
Explore
Possibilities
Solution
Understand the
Requirements
Endeavor
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
Operate the
System
17
Pre and post conditions of each activity space are suggested in terms of alpha states in the kernel.
Read [19]
Work Product
Alpha State
produces
/ updates>
<has
Alpha
targets>
18
Activity
Activity Space
Competency
Read [16]
19
Read [16]
Read [16]
OK, I see
the value
of Essence
now.
22
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.
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.
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
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
Development Work
Plan
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
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
SCRUM ONTOLOGY
25
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
Development Work
Sprint Planning
Total Work
Remaining
Track Progress
Daily Scrum
Team
Scrum Team
Ensure Stakeholder
Satisfaction
Sprint Review
Way of Working
Improvement
Plan
Sprint Retrospective
Work Unit
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
Product
Backlog
Creation
Explore Possibilities
Product
Backlog
Refinement
Understand Reqts
Understand Reqts
Understand St. Needs
Sprint
Planning
Understand Reqts
Coordinate Activity
Development
Work
Daily Scrum
Track Progress
Sprint
Review
Sprint Retro.
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
29
Scrum Practice
Sprint Review
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
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.
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
Work
Initiated
Prepared
Software System
Architecture Selected
Ready
Work
Prepared
Concluded
Work
Started
Under Control
Scrum Team
Team
Seeded
Performing
Improvement Plan
Way of Working
Foundation Established
Working Well
Product Backlog
Increment
Increment
Product Backlog
Sprint
Goal
Sprint
Backlog
Definition
of Done
Dev Work
Plan
Increment
TWR
31
Scrum Team
Improve
Plan
Scrum Practice
Sprint Backlog
Product
Backlog Item
Understand Stakeholder
Needs
Development
Work Plan
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
Requirements
Coherent
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
Software Requirement
Model
Increment
Spike
Development
Work
Model Storming
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
Sprint Retrospective
Work
Read [18]
Development
Work Plan
Work Unit
METHOD COMPOSITION
35
Add XP
Add
SPM
Add
Dev
Ops
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
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]
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
Wed better
learn
and
use Essence.
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,
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
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",
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,