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:

image

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:image>> image >> image
  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.

CLIPART_OF_10868_SM_2DA52622 … 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 …

CLIPART_OF_16337_SM_thumb_6D1FD521

Next … in this series …

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