SDLC – Software Development Lifecycle … Visual Process & Estimating (Guessing) Software Deliverables

Visual SDLC

Those who know me and especially those that have worked with me on projects will know that I visualise everything and that unless Willy has a picture, he is confused, grumpy and constantly scribbling in his notebook. Back in the late 90’s when I was running Objectronics South-Africa, we visualised the Software Development Lifecycle as shown in the illustration below, whereby we standardised our Application Lifecycle Management (ALM) Model on MSF 1.0 at the time as is evident from the model. What was unique, is that the image below could also be opened in a browser and you could click on any of the boxes. The click would wakeup some crude script behind the page and fire up the relevant guidance document or template, to assist you in creating the right artefact at the right time. The templates were customisable, to allow companies to change logos and company information that was pulled into documentation automatically. We thought, at the time, that the idea was “cool”, but none of our partners saw any value in the idea at the time … after which the prototype was used for internal use and slowly fizzled out.

The reason I mentioned the above, was because I remembered it while pondering over software solution estimations, which is covered hereafter, and something a colleague mentioned at the recent MVP Global Summit. Chris, is the above what you were referring to in terms of visualisation and linking diagrams to other content?

Estimating Software Solution Deliverables

When I started my information technology career back in the very early 1980’s, my mentor was this serious looking, bearded and overly cautious systems analyst. He thumped a rule into my head, which to this day I am still using when anyone asks me for a ‘quick’ estimate: Duration = (personal estimate * 3 / 2) . Not very scientific, but to date it has served me well :)

If I look at more formal project management and planning techniques, we get the following possible options … and many, many more:

• Strategic planning
• Feasibility studies and prototypes
• Historical planning data analysis
• Source lines of code (SLOC) estimation
• Function point analysis
• Common Software Measurement Consortium Full Function Point(COSMIC-FFP)
• Guessing …

Then again there are so many law’s, such as the Parkinson’s Law (See his book Parkinson’s Law, John Murray, 1957), which states: “Work expands to fill the time available” … which is so, so true. Looking at the age of the book, the problem we are battling with today, has been known for a very, very long time. What makes software engineering so different from other engineering principles, i.e. civil engineering, is that every project is different, code/component re-use is still in its infancy and until we can introduce repeatability, reusability and predictability, the software projects will continue to be the great adventures. Then again it is exactly the constant change and challenges that have kept me motivated, interested in and passionate about information technology (IT). In what other job can you say that you are constantly learning, constantly evolving and what you know today is redundant legacy tomorrow … I think that I will stick to my simple rule for the time being.

In terms of Team Foundation Server (TFS) and Visual Studio Team System (VSTS) the story is great, but not yet perfect. Looking at my review of Formal Planning and Agile Planning we can see that the management, the planning and estimation, as well as risk management and mitigation is getting easier. The numerous templates, documents and especially spreadsheets are adding immense value.

See you next time for another SDLC adventure …

Comments

• Anonymous
  March 12, 2009
  PingBack from http://www.clickandsolve.com/?p=22392

• Anonymous
  March 19, 2009
  Steve Lange on I told you it was coming!  "Team System Big event" The Public Sector DPE