The document discusses Essence, a common ground for flexible software engineering methods. It provides a kernel of essential concepts and a language for defining methods and practices close to how practitioners work. The kernel includes things like activities, competencies, and states. The language allows graphically and textually defining elements like alphas (abstract progress attributes), activity spaces, and competencies. Practices can then be composed from these elements to provide guidance tailored to different contexts. An example shows defining the Scrum practice by extending elements from the kernel. The goal is a flexible yet common foundation to help practitioners across a variety of methods and experience levels.

1. Copyright © 2014 Ivar Jacobson International SA. All rights reserved
Essence:
A Common Ground for Flexible Methods
Ed Seidewitz

2. • Embody essential concepts in a kernel.
• Work with methods in an agile way that are as close to
practitioners’ practice as possible.
• Focus on the things that matter the most.
• Focus on helping the least experienced developers over helping
more experienced developers.
• Understand that the majority of practitioners are interested in…
– the use of methods, not their definition.
– practice, not process or method engineering.
– intuitive and concrete graphical syntax, not formal semantics.
Principles of Essence
2

3. • “Foundation for Agile Creation and Enactment of Software
Engineering Methods” (FACESEM) RFP issued June, 2011
• Essence – Kernel and Language for Software Engineering
Methods submitted February 2013
• Essence 1.0 Finalization Task Force chartered March 2013
• Essence 1.0 (beta) adopted May 2014
The Essence Specification
3

4. Method Architecture
4
The Kernel is the
common ground thus it
includes essential
elements of software
engineering.The Language is used to define
methods, practices and the
essential elements of the Kernel.
A practice is a repeatable
approach to doing
something with a specific
purpose in mind.
A method is an enactable
composition of practices.

5. The Kernel
5
A stripped-down,
lightweight set of
definitions that captures
the essence of effective,
scalable software
engineering in a practice
independent way.
The Kernel is described
using a small subset of the
Language.

6. Alphas: The things to work with
Activity Spaces: The things to do
Competencies: The abilities needed
Content of the Kernel
6

7. What is an alpha?
7
• Alpha is an acronym for an Abstract-Level Progress
Health Attribute.
• An essential element of the software engineering
endeavor that is relevant to an assessment of the
progress and health of the endeavor.

8. Software Engineering Kernel Alphas
8

9. Alphas: Example
9
Requirements
Description
What the software system must do to address the opportunity and satisfy the stakeholders.
It is important to discover what is needed from the software system, share this understanding among the stakeholders and the
team members, and use it to drive the development and testing of the new system.
Associations
scopes and constrains : Work

10. Software Engineering Kernel Activity Spaces
10

11. Activity Spaces: Examples
Scrum Essentials Practice
Activity Space
Activity
Activity Predecessor
Relationship
11

12. Software Engineering Kernel Competencies
12

13. The Language
13
The language provides three
graphical views:
1. Alphas and Their States
2. Sub-Alphas and Work
Products
3. Activity Spaces and
Activities
The language is defined in five
packages:
1. Foundation
2. Alpha and Work Product
3. Activity Space and Activity
4. Competency
5. User Defined Types

14. The Language: Small, Simple and Flexible
Competency
Alpha State
Activity Space<involvestargets>
Alpha
<has Activity
Work Product
produces
/updates>
organizes >
< evidences
PatternResource
Can be added to anything
14

15. Language: Graphical Notation Examples
15

16. Language – Textual Notation Example
16
alpha Requirements {
"What the software system must do to address the opportunity and satisfy the stakeholders."
has {
state Conceived {
"The need for a new system has been agreed.”
checks {
item cli1 {"The initial set of stakeholders agrees that a system is to be produced."}
item cli2 {"The stakeholders that will use and fund the new system are identified."}
item cli3 {"The stakeholders agree on the purpose of the new system.”}
item cli4 {"The expected value of the new system has been agreed."}
}
}
state Bounded {
"The theme and extent of the new system is clear."
checks {
item cli1 {"Stakeholders involved in developing the new system are identified."}
item cli2 {"It is clear what success is for the new system."}
item cli3 {"The stakeholders have a shared understanding of the extent of the proposed solution."}
item cli4 {"The way the requirements will be described is agreed upon.”}
item cli5 {"The mechanisms for managing the requirements are in place."}
}
}
…

17. Language: Semantic Framework
17

18. Semantics:
Determination of State using Check Points
18

19. Practices
19
Practices and
methods are built
on the language
using the kernel.

20. Documenting Practices
20
Tacit
Practices
With
Coaching
Explicit
Practices
With
Coaching
Background
Capability
Common Different
Explicit
Practices
Needed
Tacit
Practices
Sufficient
High
Low

21. A Practice Architecture
Mobile
Application
Development
Method
Kernel
Core Banking
Development
Method
Enterprise
Integration
Method
Defect/Issue Tracking
Configuration Management
Defect/Issue Tracking
Configuration Management
Defect/Issue Tracking
Configuration Management
Common
Practices
Waterfall Lifecycle Modern Lifecycle Modern Lifecycle
Architecture Centric Emerging
Architecture
Emerging Architecture
Traditional Requirements User storiesUse Cases
Endeavor Type
Specific
Practices
Acceptance Test Driven
Development
Acceptance Test Driven
Development
Acceptance Test Driven
Development
Improvement

22. Practice Composition: Base Practices
22
Iterative Planning Practice
Iterative Assessment Practice
Agree on
Iteration
Guide
Team
Iteration
Plan
Evaluate
Result
Iteration
Assessment

23. Practice Composition: Composite Practice
23
Iterative Development
Agree on
Iteration
Guide
Team
Iteration
Plan
Evaluate
Result
Iteration
Assessment

24. Practice Explorer
24
The Practice Explorer shows Practice
Workbench projects
The Essence Kernel project contains the
elements defined in the OMG Essence
specification
Alphas that represent the essential
things to work with
Activity Spaces that represent the
essential things to do

25. ETextile, Guideline and Card views
25
When selecting an
element in the
Practice Explorer
you can switch
between different
views
The ETextile Source view provides the
main editor for authoring the practice
using plain text and annotations
The Guideline Preview
renders how the guideline will
be presented in HTML
The Overview Card
Preview renders the
card presentation

26. Scrum Essentials
26
The Scrum practice is created as a
separate practice project in the Practice
Workbench
The Scrum practice extends the
Essence Kernel by providing more
detailed guidance.
Drag and drop the relevant Alphas to
extend from the Essence Kernel into the
Scrum practice project
Drag and drop the relevant Activity
Spaces to extend from the Essence
Kernel into the Scrum practice project

27. Scrum Roles
27
Scrum roles are
represented as
Patterns
Product Owner
(Guideline Preview)
Product Owner (Card
Preview)

28. Scrum Sprint
28
Sprint is represented as
a sub-alpha of Work
The Sprint has
States with
Checkpoints
The Sprint has associated the Work Product
Sprint Backlog that contains the set of Product
Backlog items selected for the Sprint, and the
plan for delivering the product Increment
Sprint (Card Preview)
Sprint in Under
Control State
(Card Preview)
Under Control
(State Card Preview)