The document introduces the SEMAT Initiative, which aims to establish a common ground and kernel for software engineering. It discusses the motivation for SEMAT, which is to address immature practices, lack of theoretical basis, huge number of methods, and split between industry and academia. SEMAT defines essential elements called "alphas" that represent things needed to monitor progress, as well as activity spaces that represent essential things that must be done. It also defines competencies needed without specifying skills. The kernel provides a framework for teams to understand their progress, assemble practices, and improve communication. The document explains how SEMAT can be used in planning iterations and aligns with other processes without competing with existing methods.

1. The SEMAT
Initiative
Modelos de Procesos y
Metodologías de Ingeniería de
software
Mayo de 2013
Universidad de Caldas
Facultad de Ingenierías
Maestría en Ingeniería Computacional

2. ¡Welcome!

3. Content
SEMAT Intro
SEMAT elements
SEMAT as SW process

4. Sources
• Ivar Jacobson et al. The Essence of Software
Engineering - Applying the SEMAT Kernel. 2013
Pearson Education, Inc. ISBN 978-0-321-88595-1
• Ivar Jacobson, Pan-Wei Ng, Paul McMahon and Ian
Spence. The Essence of Software Engineering: The
SEMAT Kernel (Paper). Available in
http://queue.acm.org/detail.cfm?id=2389616

5. SEMAT
• Acronym of Software Engineering Method
and Theory
• Works from Ivar Jacobson in 2006
• SEMAT was officially founded in September
2009 by Ivar Jacobson, Bertrand Meyer, and
Richard Soley.
• RFP OMG
• www.semat.org

6. SEMAT – Motivation (I)
(From Jacobson)
Some areas of software engineering today suffer from immature
practices. Specific problems include:
• The prevalence of fads more typical of the fashion
industry than an engineering discipline.
• The lack of a sound, widely accepted theoretical basis.
• The huge number of methods and method variants, with
differences little understood and artificially magnified.
• The lack of credible experimental evaluation and
validation.
• The split between industry practice and academic
research.

7. SEMAT – Motivation (II)
(From Jacobson)

8. SEMAT – Common Ground (I)
• SEMAT’s first step was to identify a common
ground for software engineering.
• This common ground is manifested as a
kernel of essential elements that are universal
to all software development efforts, and a
simple language for describing methods and
practices.

9. SEMAT – Common Ground (II)
Jacobson, 2006

10. SEMAT – Common Ground (III)
(From Jacobson)
More than just a conceptual model, the kernel provides:
• A thinking framework for teams to reason about the progress
they are making and the health of their endeavors
• A framework for teams to assemble and continuously improve
their way of working
• A common ground for improved communication, standardized
measurement, and the sharing of best practices
• A foundation for accessible, interoperable method and practice
definitions
• And most importantly, a way to help teams understand where
they are and what they should do next

11. Organization of SEMAT
SEMAT defines
• The essential things to progress and
evolve—the alphas
• The essential things to do— the activity
spaces
• The essential capabilities needed— the
competencies

12. SEMAT’ Alphas
• Alphas represent the things you need to monitor for
progress and health to steer your endeavor to a
successful conclusion, and they have states and
checklists to that effect.
• A good way to remember this is as a mnemonic formed
from the words “Aspiration Led Progress and Health
Attribute”,
• Those words stresses that
(1) alphas are about progress and health,
(2) they are focused on achieving positive results, and
(3) they should be looked at as a set and not
individually.

13. SEMAT’ Alphas (II)
• An alpha is an essential element of the software engineering
endeavor, one that is relevant to an assessment of its
progress and health.
• How the “things to work with” are handled.
• These are captured as alphas rather than work products
(such as documents).
• SEMAT has identified seven alphas: Opportunity,
Stakeholders, Requirements, Software System, Work,
Way of Working, and Team.
• The alphas are characterized by a simple set of states that
represent their progress and health. As an example, the
Software System moves through the states of Architecture
Selected, Demonstrable, Usable, Ready, Operational, and
Retired.

14. SEMAT’ Alphas (III)
• Opportunity: The set of circumstances that makes it appropriate to
develop or change a software system.
• Stakeholders: The people, groups, or organizations that affect or
are affected by a software system.
• 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.
• Team: The group of people actively engaged in the development,
maintenance, delivery, and support of a specific software system.
• Work: Activity involving mental or physical effort done in order to
achieve a result.
• Way of Working: The tailored set of practices and tools used by a
team to guide and support their work.

15. SEMAT’ Alphas states
• The kernel alphas can be used to explore the
root causes of a challenge.
• The kernel can also help to overcome the
challenge because each alpha has a series of
states to guide a team to achieve progress
and health.
• See:
http://www.ivarjacobson.com/uploadedFiles/Content/Landing_Pages/SEM
AT%20SW%20Eng%20Kernel%20Cards%20A7.pdf

16. SEMAT’ Alphas states (II)

17. SEMAT as a Practical Kernel (I)
(From Jacobson)
• Perhaps the most important feature of the kernel is
the way it is used in practice.
• Traditional approaches to software development
methods tend to focus on supporting process
engineers or quality engineers.
• The kernel, in contrast, is a hands-on, tangible
thinking framework focused on supporting software
professionals as they carry out their work.

18. Why Kernel ?
(From Jacobson)
• A software engineering kernel is a lightweight set of
concepts and definitions that captures the essence
of effective, scalable software engineering in a
practice-independent way.
• The kernel forms a common ground for describing
and conducting software development.

19. SEMAT as a Practical Kernel

20. In addition
Information about Alpha State features available in
http://www.ivarjacobson.com/uploadedFiles/Content/Landing_P
ages/SEMAT%20SW%20Eng%20Kernel%20Cards%20A8.pdf
The Kernel Alphas Made Tangible with Cards

21. Organization of SEMAT (I)

22. Organization of SEMAT (II)
• Customer: The customer perspective must be integrated into
the day-to-day work to ensure that an appropriate solution is
developed. The customer area of concern contains everything
to do with the actual use and exploitation of the software
system to be produced.
• Solution: The goal of software development is to develop a
working software system to solve some problem. The solution
area of concern contains everything related to the specification
and development of the software system.
• Endeavor: Software development is an endeavor of
consequence that typically takes significant time and effort to
complete, affects many different people, and involves a
development team. The endeavor area of concern contains
everything related to the development team and the way they
do their work.

23. SEMAT Activities spaces (I)
• The kernel as such does not define any activities, but it does
define a number of activity spaces.
• The activity spaces represent the essential things that have to
be done to develop good software.
• You can think of activity spaces as method-independent
placeholders for specific activities that will be added later on
top of the kernel.
• They provide general descriptions of the challenges a team
faces when developing, maintaining, and supporting software
systems, and the kinds of things the team will do to meet
them.
• Each activity space then can be extended with concrete
activities that progress one or more of the kernel alphas.

24. SEMAT Activities spaces (II)

25. Customer’ Activities spaces
• Explore Possibilities: Explore the possibilities presented by a
new or improved software system. This includes the analysis
of the opportunity and the identification of the stakeholders.
• Understand Stakeholder Needs: Engage with the
stakeholders to understand their needs and ensure that the
right results are produced. This includes identifying and
working with the stakeholder representatives to progress the
opportunity.
• Ensure Stakeholder Satisfaction: Share the results of the
development work with the stakeholders to gain their
acceptance of the system produced and to verify that the
opportunity has been addressed.
• Use the System: Use the system in a live environment to
benefit the stakeholders.

26. Solution’ Activities spaces
• Understand the Requirements: Establish a shared
understanding of what the system must do.
• Shape the System: Shape the system to make it easy to
develop, change, and maintain. This includes the overall
design and architecture of the system.
• Implement the System: Build a system by implementing,
testing, and integrating one or more system elements.
• Test the System: Verify that the system meets the
stakeholders’ requirements.
• Deploy the System: Take the tested system and make it
available for use outside the development team.
• Operate the System: Support the use of the software system
in the live environment.

27. Endeavor’ Activities spaces
• Prepare to Do the Work: Set up the team and its working
environment. Understand and sign up for the work.
• Coordinate Activity: Coordinate and direct the team’s
work. This includes all ongoing planning and replanning
of the work.
• Support the Team: Help the team members to help
themselves, collaborate, and improve their way of
working.
• Track Progress: Measure and assess the progress made
by the team.
• Stop the Work: Shut down the work and hand over the
team’s responsibilities.

28. SEMAT Competencies (I)
• You need competency relevant to the specific tasks you are
working on, but you also need other competencies to understand
what your teammates are working on.
• Competencies are defined in the kernel and can be thought of
as generic containers for specific skills.
• Specific skills—for example, Java programming—are not part of the
kernel because such skills are not essential on all software
engineering endeavors.
• But competency is always required, and it will be up to the
individual teams to identify the specific skills needed for their
particular software endeavors.
• A common problem of software endeavors is not being aware of the
gap between the competency that is needed and the competency
that is available. The kernel approach will raise the visibility of this
gap.

29. SEMAT Competencies (II)

30. SEMAT Competencies (III)
• Stakeholder Representation: This competency encapsulates the ability to
gather, communicate, and balance the needs of other stakeholders, and
accurately represent their views.
• Analysis: This competency encapsulates the ability to understand
opportunities and their related stakeholder needs, and to transform them
into an agreed upon and consistent set of requirements.
• Development: This competency encapsulates the ability to design and
program effective software systems following the standards and norms
agreed upon by the team.
• Testing: This competency encapsulates the ability to test a system,
verifying that it is usable and that it meets the requirements.
• Leadership: This competency enables a person to inspire and motivate a
group of people to achieve a successful conclusion to their work and to
meet their objectives.
• Management: This competency encapsulates the ability to coordinate,
plan, and track the work done by a team.

31. Aligning the kernel with one governance framework

32. Glimpse of the kernel language

33. Planning Iterations (I)
• The art of planning an iteration is in deciding which of the many things
the team has to do should be done in this iteration—the next two to
four weeks.
• Every iteration will produce working software, but there are other things
the team needs to think about.
• They need to make sure they develop the right software in the best way
they can. The kernel helps the team reason about the current
development context, and what to emphasize next, to make sure a good
balance is achieved across the different dimensions of software
development.
• You can think of planning an iteration as follows.
1. Determine where you are. Work out the current state of the endeavor.
2. Determine where to go. Decide what to emphasize next, and what the
objectives of the next iteration will be.
3. Determine how to get there. Agree on the tasks the team needs to do
to achieve the objectives.

34. Planning Iterations (II)

35. Planning Iterations (III)
Task board at the beginning of the iteration

36. Planning Iterations (IV)
Task board at the ending of the iteration

37. SEMAT & other processes
• The kernel doesn’t in any way compete with existing
methods, be they agile or anything else. On the contrary, the
kernel is agnostic to a team’s chosen method. Even if you
have already chosen, or are using, a particular method the
kernel can still help you. Regardless of the method used,
projects—even agile ones—can get out of kilter, and when
they do teams need to know more. This is where the real
value of the kernel can be found.
• It can guide a team in the actions to take to get back on
course, to extend their method, or to address a critical gap in
their way of working. At all times it focuses on the needs of
the software professional and values the “use of methods”
over the “description of method definitions” (as has been
normal in the past).

38. SEMAT & other processes
• The kernel doesn’t just support modern best practices. It also
recognizes that a vast amount of software is already
developed and needs to be maintained; it will live for decades
and it will have to be maintained in an efficient way. This
means the way you work with this software will have to evolve
alongside the software itself.
• New practices will need to be introduced in a way that
complements the ones already in use. The kernel provides
the mechanisms to migrate legacy methods from monolithic
waterfall approaches to more modern agile ones and beyond,
in an evolutionary way. It allows you to change your legacy
methods practice by practice while maintaining and improving
the team’s ability to deliver.

39. Terminology and Notation

40. Questions?
Thanks