SDLC – Software Development Lifecycle … exploring common models (part 3 of many)

  • Article

Continued from our recent discussion, SDLC – Software Development Lifecycle … closer look at basics (part 2 of many).

Looking at some of the numerous processes … in a picture

image

So … what else can we think of at this stage?image

The listed processes are by no means the only ones, the right ones or the best ones. Each suits a specific environment and team dynamics and it is imperative that you investigate and chose the correct process as the base … not de-facto. If you are allowed to and able to, you should spend the time and effort to customize a base process to a process that matches your environment and your dynamics, not visa versa.

Some of the processes we will look at next time include the agile  world, scrum and feature driven processes … there is definitely more.

The most scary, sorry comprehensive, process is the CMMI process, which uses continuous capability maturity evaluation and improvement techniques, assessment approaches such as:

  • “Standard CMMI Assessment Method for Process Improvement (SCAMPI) ”
  • “CMM-Based Appraisal for internal process improvement (CBA IPI) ”
  • “SPICE (ISO/IEC 5504) standard”
  • “ISO 9001:2000 for Software standard”

… as well as many, many other checklists. Before embarking on CMMI, understand the associated complexity, effort and cost to implement the process. Rather consider to adopt the objectives of CMMI to take software engineering seriously and to strive for quality.

Blue Baker Chef Cook in Uniform and Chef's Hat, Stirring Ingredients in a Bowl Clipart IllustrationIt is important to understand that software projects are not like any other projects, because we deal with intangible and invisible stuff for large durations of the project  (instead of seeing a beautiful bridge appearing, which we can touch and walk on), the complexity per investment (i.e. value per monetary unit) is much higher than in most other projects, we deal with chaos and changing scope and finally instead of having nicely ordered ingredients as in hardware engineering or a bakery, software ingredients are varied based on stakeholders, developers, technologies and even country codes. Project processes attempt to bring order in this chaos and it is imperative that we use the right process, consider customisation and remain flexible within our own unique environment.
Pick your magic sprinkle of process artefacts, i.e. requirements and feasibility elicitation, planning, analysis, design, construction, testing, integration, quality control, implementation, acceptance, maintenance, etc. carefully …. the process must add value to the project and typically the process must fit your environment, not your environment an off-the-shelve process.

Next … in this series …

We will explore the world of agility and perhaps stumble over one or two of the TFS Process templates.