This document introduces the SEMAT (Software Engineering Method and Theory) framework for software engineering. It describes the goals of SEMAT as improving quality, using a common framework, and building best practices. SEMAT's kernel captures the essence of software engineering and forms a map of the context. It evaluates projects across three dimensions: customer, system, and endeavor. Each dimension contains "alphas" or essential elements that are assessed for progress. The document defines the alphas across the three dimensions and their possible states to provide a standardized way to evaluate projects.

1. THE ESSENCE OF SOFTWARE ENGINEERING
DRIVE PROJECTS WITH
ESSENCE

2. SUMMARY
Goals
SEMAT Kernel
Dimensions
Alphas
In Action

3. GOALS
Improve software engineering quality
Use a common & actionable framework
Build best practices on a standard core
Drive projects on all aspects

4. SEMAT KERNEL
Captures the essence of software engineering
Forms a map of the software engineering context
Constitutes a basis for evaluating on-going work

5. 3 DIMENSIONS
‣ Customer
‣ System
‣ Endeavor

6. ALPHA
“An essential element of the software engineering endeavor
that is relevant to an assessment of the progress and health of
the endeavor”
‣ Each dimension is assessed on its alphas
‣ An Alpha has multiple states

7. CUSTOMER
‣ OPPORTUNITY
“The set of circumstances that makes it appropriate
to develop or change a software system”
‣ STAKEHOLDER
“The people, groups or organizations who affect or
are affected by a software system”

8. CUSTOMER
Value Established
Viable
Addressed
Benefits Accrued
Identified Stakeholders identified the opportunity
Solution Needed Problem, root causes, needs
Value and Impact understood
Feasibility, Risks, Constraints
Produced, Usable, Worth deploying
Operational, Beneficial, ROI >= expected
OPPORTUNITY

9. CUSTOMER
STAKEHOLDERS
Represented
Involved
In Agreement
Satisfied for
Deployment
Satisfied In Use
Recognized Group and Responsibilities
Collaboration approach, Way of working
Feedback, Decisions, Communication
Inputs, Priorities and Expectations
Stakeholder give feedback and GO Live
System meets or exceed expectations

10. SOLUTION
‣ REQUIREMENTS
“What the software system must do to address the
opportunity and satisfy the stakeholders”
‣ SOFTWARE SYSTEM
“A system made up of software, hardware and data that
provides its primary value by the execution of the software.”

11. SYSTEM
REQUIREMENTS
Conceived
Bounded
Coherent
Acceptable
Addressed
Fullfilled
Need, Users, Sponsors
Purpose, Success, Scope, Mechanisms
Main scenarios, Priorities, Conflict
Resolution
Description acceptable, Change low
Implemented enough, Worth operating
Satisfied by the software system

12. SYSTEM
SOFTWARE SYSTEM
Arch. Selected
Demonstrable
Usable
Ready
Operational
Retired
Architecture, platforms, technologies
Architecture demonstrated and testable
Desired quality, tested, acceptable
Documented, accepted by stakeholders
In use and available
No longer supported, discontinued

13. ENDEAVOR
‣ TEAM
“People engaged in the development, maintenance,
delivery, support of a specific software”
‣ WORK
“Activity done in order to achieve result”
‣ WAY OF WORKING
“Tailored set of practices and tools used by a team”

14. ENDEAVOR
TEAM
Seeded
Formed
Collaborating
Performing
Adjourned
Mission and skills identified
Resources and responsibilities defined
Working as one unit, open
communication
Efficient, adapt to change, high quality
Responsibilities handed over

15. ENDEAVOR
WORK
Initiated
Prepared
Started
Under Control
Concluded
Closed
Mission and skills identified
Resources and responsibilities defined
Working as one unit, open
communication
Efficient, adapt to change, high quality
Enough is implemented, system
operational
Satisfied by the software system

16. ENDEAVOR
WAY OF WORKING
Principles
Established
Foundation
Established
In Use
In Place
Working Well
Retired
Mission and skills identified
Resources and responsibilities defined
Working as one unit, open
communication
Efficient, adapts to change, high quality
Enough is implemented, system
operational
Satisfied by the software system

17. IN ACTION
‣ Experimentation in JIRA
‣ Define new issue types for each alpha
‣ Define state and workflow for each alpha
‣ Create “boards” to act on and monitor workflow

18. REFERENCES
‣ http://semat.org/

19. SEBASTIEN.PLISSON@GMAIL.COM
@SPLISSON