SDLC – Software Development Lifecycle … closer look at basics (part 2 of many)

Continued from our recent discussion, SDLC – Software Development Lifecycle … what’s the point? (part 1 of many).

The basic flow of events

If we take the common activities diagram from the previous post and flatten it, we get the following flow of basic events:

Thoughts in a nutshell

Event	Point	Thoughts
Communicate	Collaboration	To understand the true requirements, it all starts with communication and collaborating with all stakeholders. It is important to collaborate and communicate, not to debate!
	Visualization	At all times visualize the requirements, the discussions, the ideas … in fact anything that can be represented in a picture. A picture speaks a million words!
	Documentation	While it is important to be a good listener, it is also crucial to document discussions, issues, decisions and ideas for future reference.
Planning	Vision & Scope	Before we commence with any planning or design, we need to define the vision and the scope of the solution. What are we trying to solve and how … are we building a house, a plane, a spaceship, a robot, an espresso machine … important to define and agree on the context.
	Collaboration	Collaboration continues throughout the project, but it is especially important to collaborate with all stakeholders, especially the customer, during this event.
	Quality	Create a minimum quality bar and agree on a quality framework at early on in the lifecycle of the project, so that the vision, the design and the construction of the solution can be based on solid quality control from day 1.
	Evolution	Whatever we end up with at the end of this planning event is not the final blueprint. The plan and the future design are evolutionary artefacts, which go through iterative cycles of refinements.
Design | Model	Macro –> Micro	Like zooming into the ecosystem where I am currently typing up this blog post, we should start at a high altitude (the system | problem | business domain) and zoom into the details. Good visualization allows you to zoom in and out as needed:>> >>
	Simplicity	Keep the design as simple as possible and cater for what is needed, not what could one day be applicable, or what the technocrats believe is cool.
	Clear boundaries	Remember that the interfaces, both internal and external, are the windows to your solution. keep them simple, keep them secure, keep them organised and keep them extensible, else other solution windows will suddenly be the preferred choice of the stakeholders.
Construction	Maintainabilityructur	When we construct we have to agree on basics such as coding guidelines and standards. Without deviating into a potential hornets nest, we merely state that the developer should keep the maintenance developer close at heart. Is the code we develop simple, is it layered out neatly and is it self documenting? If not, go back and fix the code, for the benefit of the maintenance team.
Deployment	Preparation	Ensure that you are ready for the deployment, which does not begin and end by handing over installation media to facilities. Is the infrastructure ready? Is support ready and available? Is the customer base aware of the imminent deployment? In fact, we should ask whether all stakeholders are aware of and in support of the imminent deployment?
	Zero bug	While the objective is for a “zero bug” tolerance for any solution that is deployed, we will probably never invent the ‘perfect’ and ‘bug free’ software solution. Look at the minimum quality bar defined during the planning phase … if the solution does not meet the quality bar, do NOT ship!
	First impression	The end-user’s first impression of a system determine their enthusiasm and willingness to embrace the first and subsequent deployments. If the first impression is good, then half your battle is won, If, however, the first impression is bad, you may as well back up and go home.
Maintenance	Same principles	Maintenance should adhere to the same minimum quality bar, the same quality assurance guidelines  and the same coding standards. Just because we are maintaining a deployed solution, often working under severe business pressures, does not give us the liberty to reduce quality, to stop testing or worse, to rush deployments because ‘business demands’ it.

… these are just some basic thoughts. There are numerous books, whitepapers and products that address all of the above and more.

Looking at Team Foundation Server (TFS) and Visual Studio Team System (VSTS), let’s plot some possible value add:

Event	TFS | VSTS artefacts
Communicate	Team Foundation Server (TFS)Team System Widgets … rock on MVPs!!!
Planning	Visual Studio Team System Architecture EditionTeam System Widgets … rock on MVPs!!!
Design | Model	Visual Studio Team System Architecture Edition
Construction	Visual Studio Team System Development EditionVisual Studio Team System Database EditionVisual Studio Team System Test Edition
Deployment	Visual Studio Team System Development EditionVisual Studio Team System Database Edition
Maintenance	All of the above …

Next … in this series …

A look at common models, including a diversion into the agile world …

Comments

• Anonymous
  January 31, 2009
  PingBack from http://blog.a-foton.ru/index.php/2009/02/01/sdlc-%e2%80%93-software-development-lifecycle-%e2%80%a6-closer-look-at-basics-part-2-of-many/

• Anonymous
  February 03, 2009
  The comment has been removed

• Anonymous
  February 03, 2009
  Continued from our recent discussion, SDLC – Software Development Lifecycle … closer look at basics (part

• Anonymous
  February 05, 2009
  This post is simply a collection of the various posts that made up the “ SDLC – Software Development

• Anonymous
  February 05, 2009
  This post is simply a collection of the various posts that made up the “ SDLC – Software Development