Volere and the SDLC

Fri, Jan 19, 2018

Software is a problem solving tool. Yes it’s great to wallow in the latest frameworks, the most obfuscated lines of code, sitting back, hands behind head, proudly surveying the terse and elegant code but these are moments of working out at the code gym. What you’re really doing is honing your problem solving skills, evaluating different ways of approaching a problem. What really counts is the solution you create and how maintainable it is by someone in the future. The original problem may morph as new technology is introduced to the business processes behind the project, requiring someone to update the solution and that someone may not be you.

I’ve worked on a multitude of projects over the years. Small, medium, huge. Projects with just me, projects with a landscape pitted with committees, projects with a few distributed developers and even projects with no users, The ones that have worked have been the ones with well defined boundaries and requirements. The ones with well managed stakeholder expectations. Projects will grow arms and legs, that’s for sure and you need a way to manage those extra limbs. Where to put them, how to suggest changes to them, how to make sure they add value to the project and if they don’t, how to throw them out.

Where do these boundaries come from? In the early days of my professional software development career (ahem!) years ago, the boundaries were defined by the operating system. Developing printer drivers was largely a case of reading the Microsoft GDI documentation and implementing everything a driver needed to do. Add in some non functional requirements (“faster than the competition”) and throw in internationalisation, testing and bug fixing and that’s about it. The added spice was the heavy responsibility of being the PCLXL developer for the whole of the EMEA region for the company. Experience that taught me a lot and the resultant mindset of project success as a first principle has not left me.

However, when you start to interact with users, who have problems, who want you to solve their problems using the images in their heads, images you can’t see but can only translate into images in your head, you have to adopt a different attitude. Your mindset has to become extensible, to borrow from OOP.


class Coder {
  boolean humble;
  boolean hasOpenMind;
  boolean isCodeOwnedBy;
  boolean isAlwaysLearning;
    
  public Neophyte() {
    this.humble = true;
    this.hasOpenMind = true;
    this.isCodeOwnedBy = false;
    this.isAlwaysLearning = true;
  }
}

abstract class Success {
  ArrayList coders;
}

class Project extends Success {
  Scope scope;
  ArrayList bucs;
  ArrayList pucs;
  ArrayList funcReqs;
  ArrayList nonFuncReqs;
  ArrayList userStories;
}

You must build on the initial responsibilty of working on a project on your own, the discipline you create for yourself, the rigorous adherence to schedules and releases. The detached gathering of bugs. These are not personal slights against your coding and design skills, these are just a fact of life, deal with them. Understand the pain they bring to your users, triage them, deal with them, make a new release and build trust with your users. All these attributes and work practices are the base you build on for working on larger, distributed, demanding but ultimately greatly satisfying projects.

I’ve been using the Volere technique for a few years now and my @goto book is Mastering the Requirements Process: Getting Requirements Right by the authors of the Volere process. I’ve also been teaching a modified version to my students on the Open University postgraduate Software development course. Quite simply, I love it.

My Software Development Life Cycle (SDLC) is now composed of the following steps:

  • Stakeholders. Who are the users who need to use the product?
  • Scope. What are the external systems that influence what the product will do?
  • Business Event (BE). What things happen in the organisation that are relevant to the product? How are those BE initiated by the organisation and what effect do they have on the product?
  • Business Use Case (BUC). The are the business processes that are important to the project. A BUC is a unit of work the product must do in order to respond to a BE. I like to model these with Activity Diagrams on a whiteboard in a room full of stakeholders.
  • Product Use Case (PUC). A PUC is how the product will interact with a stakeholder, in order to fulfil a BUC. It’s a textual representation of the steps a stakeholder will perform on the product, in language a stakeholder can understand. A single BUC will usually have multiple PUCs.
  • Functional Requirements. These are derived from the PUCs. A single PUC will have multiple functional requirements. Each requirement has an owner and a testable fit criterion.
  • Non functional requirements. These are subjective stakeholder goals. Words like “fast”, “quick”, “reasonable” define these aspects of the product.
  • User Stories. Created as part of the requirements gathering process, for consumption by developers.
  • SCRUM/Kanban. Which technique gets used depends on the nature of the project.
  • Managing the development process. Jira for stories and releases, Bitbucket Server for git version control and integrating the two in order to see which commits implement each story and which stories are included in each release, either via a scheduled sprint or reactive kanban.
  • Success. The initial release, to great fanfare, much flowing of champaigne (yes this did happen once!) and perhaps promoting on the conference circuit.

To start the journey I prefer to work out the scope, create the BUCs and PUCs and manage stakeholder expectations in user facing workshops, preferably with a very large whiteboard on the wall. After deriving the initial set of functional requirements, with ownership and fit criteria, I can distribute for comment/modification and once they are agreed on, the development work can start. The boundaries are set by the scope. Each requirement, whether functional or non functional are owned by the stakeholder who proposed them, are traceable back to their PUCs which are traceable back to their BUCs which are traceable back to their BE, which are defined by the scope.

Being a polyglot programmer, for me, is only part of being a professional software engineer. I strongly believe having the full package is an asset that allows you to grow into a mobile problem solving machine. You have the full stack skills, the multiple language mindset, the ability to identify the right tool for the job regardless of hype and fads and you have the user facing skills of tact, negotiation, mediation and non technical communication. Add the ability to motivate and manage developers to implement Success and grow and mentor them on their own journeys and it’s a hugely satisfying world in which to work. Above all, it engenders a sense of trust in an organisation that employs people with these skills and who can turn stakeholder ideas into reality in a managed and repeatable way.

Over the next few posts I’ll delve into each of the above aspects of the SDLC, from workshops, to requirements, to development, to testing, release, maintenance and hopefully cracking open that bottle of Bollinger, again.

comments powered by Disqus