The SEMAT Initiative

Modelos de Procesos y Metodologías de Ingeniería de software

Mayo de 2013

Universidad de CaldasFacultad de IngenieríasMaestría en Ingeniería Computacional

¡Welcome!

ContentSEMAT Intro

SEMAT elements

SEMAT as SW process

Sources• Ivar Jacobson et al. The Essence of SoftwareEngineering - Applying the SEMAT Kernel. 2013Pearson Education, Inc. ISBN 978-0-321-88595-1

• Ivar Jacobson, Pan-Wei Ng, Paul McMahon and IanSpence. The Essence of Software Engineering: TheSEMAT Kernel (Paper). Available inhttp://queue.acm.org/detail.cfm?id=2389616

SEMAT

• Acronym of Software Engineering Methodand Theory

• Works from Ivar Jacobson in 2006

• SEMAT was officially founded in September2009 by Ivar Jacobson, Bertrand Meyer, andRichard Soley.

• RFP OMG

• www.semat.org

SEMAT – Motivation (I)

(From Jacobson)

Some areas of software engineering today suffer from immaturepractices. Specific problems include:

• The prevalence of fads more typical of the fashionindustry than an engineering discipline.

• The lack of a sound, widely accepted theoretical basis.

• The huge number of methods and method variants, withdifferences little understood and artificially magnified.

• The lack of credible experimental evaluation andvalidation.

• The split between industry practice and academicresearch.

SEMAT – Motivation (II) (From Jacobson)

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.

SEMAT – Common Ground (II)

Jacobson, 2006

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

Organization of SEMAT

SEMAT defines

• The essential things to progress andevolve—the alphas

• The essential things to do— the activityspaces

• The essential capabilities needed— thecompetencies

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.

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.

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.

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

SEMAT’ Alphas states (II)

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.

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.

SEMAT as a Practical Kernel

In addition

Information about Alpha State features available in http://www.ivarjacobson.com/uploadedFiles/Content/Landing_Pages/SEMAT%20SW%20Eng%20Kernel%20Cards%20A8.pdf

The Kernel Alphas Made Tangible with Cards

Organization of SEMAT (I)

Organization of SEMAT (II)• Customer: The customer perspective must be integrated intothe day-to-day work to ensure that an appropriate solution isdeveloped. The customer area of concern contains everythingto do with the actual use and exploitation of the softwaresystem to be produced.

• Solution: The goal of software development is to develop aworking software system to solve some problem. The solutionarea of concern contains everything related to the specificationand development of the software system.

• Endeavor: Software development is an endeavor ofconsequence that typically takes significant time and effort tocomplete, affects many different people, and involves adevelopment team. The endeavor area of concern containseverything related to the development team and the way theydo their work.

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.

SEMAT Activities spaces (II)

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.

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.

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.

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.

SEMAT Competencies (II)

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.

Aligning the kernel with one governance framework

Glimpse of the kernel language

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.

Planning Iterations (II)

Planning Iterations (III)

Task board at the beginning of the iteration

Planning Iterations (IV)

Task board at the ending of the iteration

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).

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.

Terminology and Notation

Questions?

Thanks