I’ve been reading the SEMAT Kernel book, The Essence of Software Engineering: Applying the SEMAT Kernel, and it provides a new way of managing software development projects. It’s supposed to make it easy to check the health of a project by classifying the major components, known as Alpha states in SEMAT, and the progress level that they’re at.
Alpha States in SEMAT
There are three layers that the Alphas belong to and each one has a different set of progress levels.
- Software System
- Way of Working
Please be aware that I’m still learning how this works and that I’m around halfway through the book. I wanted to try using the appropriate layers to check the health of a small task I’m working on and after I was complete, to see how the health/status had changed.
You Don’t Need to Use Everything in the SEMAT Kernel
Not all Alphas applied. The small task was a new feature for exporting an Excel spreadsheet that I would work on by myself and I had already discussed the specification with the client. Working on it by myself meant I didn’t need the Way of Working or Team Alphas. Since this was only one feature, I wouldn’t need the Software System or Stakeholder Alphas either.
Therefore, the only Alphas/components I needed to check the health of the task were:
First Health Check of the New Feature
When I first checked, I got the following progress levels:
- Opportunity: viable 4/6
- Requirements: acceptable 4/6
- Work: started 3/6
To be at a certain progress level, I had to go through the short checklist on each card and find one that matched the current status of the project.
The checklist for Opportunity: viable is
- A solution has been outlined
- Indications are solution can be developed and deployed within constraints
- Risks are manageable
The checklist for Requirements: acceptable is:
- Requirements describe a solution acceptable to the stakeholders
- The rate of change to agreed requirements is low
- Value is clear
The checklist for Work: started is:
- Development work has started
- Work progress is monitored
- Work broken down into actionable items with clear definition of done
- Team members are accepting and progressing work items
The client brought up the idea of a new feature and we talked about what was required. I asked some questions to clarify what the client wanted. Those conversations were dealing with the opportunity & requirement Alphas. The client was satisfied with the spec for the new feature, which is why the opportunity was “viable” and the requirements were “acceptable”.
I had already begun to work on the feature, writing unit tests for related functions/classes and installing an additional library for creating Excel spreadsheets. There was a ticket in the ticket system for the feature which included the definition of done for the task. Therefore, I had “started” work.
Second Health Check of the New Feature
After some coding, I finished the feature and it’s ready to be deployed to the staging server so that the client can take a look and offer feedback. I took out the Alpha states cards and did another health check of the feature:
- Opportunity: viable 4/6
- Requirements: addressed 5/6
- Work: concluded 5/6
The checklist for Opportunity: viable is the same as before.
The checklist for Requirements: addressed is:
- Enough requirements are implemented for the system to be acceptable
- Stakeholders agree the system is worth making operational
The checklist for Work: concluded is:
- Work to produce results have been finished
- Work results are being achieved
- The client has accepted the resulting software system
I implemented the feature according to the specs and now I need the client to test it. This is why the requirements have only been “addressed” and haven’t been fulfilled; there may be bugs or the feature may need more functionality.
The work has “concluded”, since I implemented and tested the feature locally, fixed a few bugs and it worked. I’m done working on the feature for now. However, I’m waiting for the client to test the feature. That means the work is not yet at the final stage, “closed”.
After the client inspects the result, I expect the health of the feature to be at the final stage for Opportunity, Requirements and Work.
The Advantage of SEMAT
The advantage of SEMAT from this example is that it was flexible. I only kept track of progress on the Alpha states that I needed, I wasn’t obliged to use all of the Alpha states.
It’s flexible enough that it was easy to see map the current status of tickets in the ticket system, as you can see in the second health check, the work was concluded; the ticket was marked as “needs testing”.
The flexibility lets you use it with Agile, SCRUM, and other methodologies.
Overall this was a good experience. I’m going to try and use SEMAT to check the health of the project and of the milestones that are coming up.