Most people would think this is YASDP (Yet Another Software Development Methodology), but the promise of the SEMAT initiative is NOT to provide another attempt at defining another unified or agile methodology (Kanban, Scrum, Lean, RUP, etc), but to provide a minimal set of rules or language (a guide if you will) which you can use to compose and create your own practice; a practice that makes sense for your team and for your project. This initiative was based on real world experiences learned in the software development community and it is aimed at addressing all of those software development fads that companies have used yet have no theoretical backing.
SEMAT is a brand new proposal backed by Ivar Jacobson and a few others. As most of you know, Ivar is the main contributor to UML and Use Case Design, Aspect Oriented Software Development, to name a few. The idea behind SEMAT is to create a "kernel," - an ontology or a language over which many software lifecycle practices can be be built.
Their proposal submission to the OMG is documented here
I won't go over the entire proposal, you can read the theory on your own, but I will be writing about the aspect that caught my attention the most and where I see the most practical value. And that is how to compose your own software development practice.
First, we must understand what the kernel is, according to the proposal, the kernel
... is a stripped-down, light-weight set of definitions that captures the essence of effective, scalable software engineering in a practice independent way ... The practices can be mixed and matched to create specific software engineering methods tailored to the specific needs...
With this in mind, the kernel is structured in terms of Alphas which we can use to control and measure the health of different aspects of your software lifecycle:
- Software System
- Way of Working
The Alphas have several states and through these states you can monitor the health of the software system as you evaluate what needs to be done to the move to the next state. For instance, in the "Requirements" alpha if your system is in the Scoped state, you can use the kernel to guide you in taking your team to the Analyzed state and finally into the Fulfilled state. In the "Work" alpha, your team can go from the work being Initiated to Under Control and finally to Concluded. You will determine and give meaning to each of these states within an alpha in your organization. You can also use the recommended meanings of each of these states and follow the SEMAT approach. Refer to the documentation for the list of all the states.
The beauty of composing a practice is that we as developers and process engineers do this on a day to day basis. We just don't realize it. And there are many practices: TDD, Architecture Design, Requirements Use Case, Deployment, Spikes, etc.
When presented with a requirement we immediately think: has this requirement been scoped? Is there a Use Case diagram for it? Should we create some unit tests and integrations tests to validate this requirement, whatever the case may be. Let's give this more structure:
A requirement item has the following states:
Let's say I were building a piece of software for the NASA Curiosity rover, then I would have probably included a lot more states. Any piece of software in that project must be reviewed and scrutinized by many engineers and domain experts. But for the typical software project, this is enough.
On top of this, I can compose a Test Driven Development and an Deployment Practice as such:
This is just one way of doing this for a Continuous Deployment method. Basically, any requirement that gets implemented and tested gets deployed. This exercise is actually very simple. In our minds, we probably already do all of this. And for different industries, these practices change: web development has common practices, game development has others. It's just taking the time to actually document it, put on index cards, move things around and identify room for improvement.
I thin the approach taken by SEMAT is the right one. In my experience, it's hard to follow one practice textbook style. It's always a compromise and a hybrid combination of different methodologies. So, the idea of giving you a kernel, a language, makes a lot of sense.
Finally, the end goal is to create a method that fits your development style. If you are a process engineer, own this method and documented it. Once in a while, review it and adapt, be agile. The creation of a method is very similar to the creation of software: do it iteratively. Adapt and fail quickly.
Stay Tuned! visit http://reflectivethought.net