Giving Software Practitioners What They Need: The SEMAT Pattern Construct

It has been a while since last I blogged.  I have been busy with speaking engagements, client engagements, writing, and coordinating the SEMAT community submission of the Essence proposal in response to the OMG Foundation for the Agile Creation and Enactment of Software Engineering Methods (FACESEM)  RFP.

In December we came within a single vote of achieving one of our goals.  Since then we have been working to address the OMG Evaluation team comments.  It is actually good that we fell a little short at the OMG December meeting because it has motivated our SEMAT volunteers to strengthen the Essence submission which is certain to help the software industry in the long run.

One of the great things that comes with being a volunteer for a community initiative such as SEMAT is having the opportunity to work with so many forward thinking people from around the world opening one’s eyes to new ideas and possibilities.  One of those ideas I want to discuss in this blog– the SEMAT Pattern construct.

But first let me mention that in the last few months we have published our first book on SEMAT– The Essence of Software Engineering: Applying the SEMAT Kernel (http://www.amazon.com/s/ref=nb_sb_noss_1?url=search-alias=stripbooks&field-keywords=The+Essence+of+Software+Engineering ).

And we have published an article in ACMQueue that can give you a quick overview of the SEMAT kernel.  But we suggest if you are going to read this article plan to take some time to digest the material, especially if this is your first exposure to the SEMAT kernel.  (http://queue.acm.org/detail.cfm?id=2389616).

Now let me get to what I want to discuss today.  Throughout my 40 years working in the software industry (I started as a programmer in 1973) I have always been sensitive to providing practical help to practitioners.  In my early years I wasn’t a strong supporter of process initiatives because I didn’t see how written processes helped me get my code to run and achieve what the customer wanted.  Even in later years when I  began to see the value I still felt there was a significant gap between the way processes were being defined and deployed  and what practitioners really needed.

I just couldn’t see the value in telling practitioners the ideal sequence of steps to follow when the world most of us were working in rarely match those ideal conditions.  Years later when I started my own consulting business it was this same message I often found myself hearing from my clients.

What my clients wanted most was help in how to handle the difficult situations they often faced such as dealing with stakeholders who weren’t available when you needed them, ambiguous requirements and/or unrealistic schedules and budgets.

In response as a consultant I have found the greatest value I have been able to give the vast majority of my clients is coaching practitioners in  how to handle the common difficult situations they frequently face.

This is where I find the SEMAT pattern construct might hold great promise.  That is, in filling the traditional gap between process definitions and the help practitioners really need.

Patterns in the SEMAT Thinking Framework

The SEMAT kernel can be viewed as a “thinking framework.”  A pattern in the SEMAT framework is an arrangement of language elements (e.g. alphas, alpha states, competencies…) into meaningful structures.   (Refer to the earlier referenced book or article for more information about the SEMAT language elements).

Let me now give you an example how practitioners could use the SEMAT thinking framework and the pattern construct to reason through a requirements dilemma to help them make a better decision when faced with a commonly occurring real software engineering situation.

Reasoning Through a Requirements Dilemma Using the  SEMAT Thinking Framework and the Pattern construct

Some believe software developers just need good tools, a workstation and to be left alone to write their code.  While this may in fact be true in many cases there is a scenario I often run into when talking to software developers that occurs far more often than many of us would like to believe.

I work with a number of organizations that develop software for the U.S. Department of Defense (DoD).  Some of these companies develop simulation software to help train our service personnel.  One of the developers I worked with recently was frustrated trying to understand one of his customer’s requirements.  He explained the problem by stating that when he asked the customer for more details about what he needed, the customer just said:

“We need simulated missiles that fly high and go fast.”

Developers know they can’t implement “fly high, and go fast.”  But what happens when they ask how high and how fast, and the customer responds:

“I don’t know. Just build something and then we’ll tell you if its good enough.”

Often, in the real world, this is the scenario that plays out, and so the developers build something, show it to the customer and the customer says:

“That’s not what I had in mind.  Try again.”

So, is this a problem or not?

Inadequate requirements may be the most common and costly problem software developers face, but what options do they have when faced with this common non-ideal real world scenario?

When using the SEMAT kernel the Alphas are the essential things we work with that need to be monitored and progressed.  Software professionals can quickly refresh what they need to know about requirements essentials through  the Requirements Alpha and its states.  Refer to Figure 1.

In this diagram you will see an example of what we refer to as an Alpha definition card.  Cards are a simple and proven way to keep essential information about the kernel visible to team members.

Figure 1 The Requirements Alpha

The Requirements Alpha is defined as:  What the software system must do to address the opportunity and satisfy the stakeholders.

What every software professional should understand is the intent of the states of this Alpha and  how they can help anyone facing similar challenges reason through their options and consequences to arrive at the best decision.

As an example, lets look at two specific states of the Requirements Alpha and discuss how a software developer might use this information to help  reasons through this common scenario.

The Acceptable state is defined as: The requirements describe a system that is acceptable to the stakeholders. 

 

The Addressed state is defined as: Enough of the requirements have been addressed to satisfy the need for a new system in a way that is acceptable to the stakeholders.

 

Refer to Figure 2 for examples of Alpha state cards.  Alpha state cards are a proven and easy way to help practitioners recall the essentials of each Alpha state.

Figure 2 Requirements Alpha Acceptable, and Addressed States

Stakeholder and development team collaboration is essential to ensure we are converging on an agreed to set of requirements that are Acceptable.  But if we get ahead of ourselves working hard on getting to the Addressed state before we have achieved the Acceptable state there is significant risk of rework as we saw in this scenario.  On the other hand, addressing some requirements early so we can demonstrate parts of the system to a stakeholder can help us move forward toward an Acceptable set of requirements.  The team must understand that there are tradeoffs to consider when making a decision including potential risks of proceeding too far in addressing the requirements without an acceptable set of requirements.

The SEMAT Thinking Framework is Agnostic to Your Method

Some people when they first look at the SEMAT approach think the framework requires a sequential waterfall approach.  This is incorrect.  As can be seen in this example, different parts of your requirements can be in different states at the same time, and you can cycle back through the same state multiple times.  How a team works through the Alpha states depends on a team’s chosen life cycle and practices.  The SEMAT approach is agnostic to your team’s chosen method.

The checklist items identified in Figure 2 provide an abbreviated version of the full checklist items within the SEMAT kernel.  Some of the questions the Requirements Alpha checklist items will lead a practitioner  to ask include:

• Is it clear what success is for the new system?
• Do the stakeholders have a shared understanding of the extent of the new system?
• Do we know the essential characteristics of the new system?
• Does the team understand what has to be delivered?
• Do we have a mechanism in place to manage changes to the requirements?

By asking these questions it can help team members decide whether the state of their requirements (or the state of a specific part of their requirements) is a problem or not that requires them to take some immediate action.   The answer often depends on how your team and the customer are working together.   For example, if you are using an agile approach, and your customer is collaborative and understands the impact of changing requirements, then you may be fine.

However, if you have a fixed cost and schedule and a non-collaborative customer, then not getting to the Acceptable state could present a high risk.  This is an example of using the SEMAT framework as a thinking framework. It helps you keep your options and consequences fresh in your mind when you need them most, and it helps you ask the right questions leading to the best decision given your current situation.

Note in the scenario discussed we have more than one goal state occurring at the same time.  This is not unusual, especially on projects using iterative and agile approaches.  Keep in mind the kernel is practice and method agnostic.  It can help practitioners assess their situation and make sound decisions regardless of their chosen life cycle, practices and method.  Refer to Figure 3 to see how the Cards can be used as a visual aid to help a team assess their current state and their next goal state(s).

Figure 3  Requirements Alpha Target States

To ask critical questions and reach sound solutions with respect to the state of your requirements requires an individual with the  Analysis competency.  This competency is defined in the SEMAT framework as:  A competency that encapsulates the ability to understand opportunities and their related stakeholder needs, and transform them into an agreed and consistent set of requirements.

Refer to Figure 4 for a diagram of the Fly High, Go Fast Pattern using the SEMAT Pattern construct and graphical notation.

                   Figure 4  Case 2: Fly High, Go Fast Pattern

Note how this pattern construct provides a succinct graphical way to represent a common pattern that requires practitioner forethought to make the best possible decision in a common non-ideal real world endeavor.  It is also worth noting how this construct helps us raise awareness of required competencies.  Historically many organizations have focused their efforts on the people side on roles and responsibility definitions, but defining a role and assigning a list of responsibilities to an individual does not assure us that the individual has the needed competency to carry our the assigned role.

The SEMAT pattern construct can help us raise the visibility within our organizations of required competencies, and possible shortfalls, as well as remind practitioners of common situations they should be alert to, and possible options and consequences of related decisions.

Capturing patterns specific to your context is a great way to keep improving, sustaining your performance, and sharing what you learn with your teammates.  The SEMAT pattern construct holds great promise to help us give our practitioners what they need — specific help related to the challenges they most often face each day on the job.

In closing I would like to point out my focus in this blog on the pattern construct is not in any way intended to downplay the significance of the common ground kernel and its support for practices.  The kernel is essential to give us all that common reference from which we can compare and assess so that we can discriminate between what is truly new and innovative and what is fad and reinvention of old ideas.

My intention in this blog is simply to point out that as powerful as the kernel idea is to help us in the Universities and with less experienced practitioners to learn the fundamentals, it is only a starting point for what the SEMAT approach can mean to the future of software engineering.

Love it, or hate it, we want to hear from you.   What do you think of the SEMAT pattern construct and its potential to help  practitioners make better on the job decisions?

Please share your thoughts through your feedback on this blog, or the SEMAT web site (www.semat.org).