Software Development Life Cycle (SDLC)

Written 2010 by Will Johnson for Fast Forward Technologies Email Fast Forward Technologies at fft2001@aol.com or post your comments for public view far below. Creative Commons Attribution 3.0 License

Follow Fast Forward Technologies on Twitter! or subscribe using my Knol Public activity feed or see Wjhonson's Fifty Most Recent Knols

"Software Development Life Cycle (SDLC)" on Knol, by Will Johnson
for Fast Forward Technologies fft2001@aol.com
URL: http://knol.google.com/k/fft2001/software-development-life-cycle-sdlc/mbasj7lzroyk/28#
Creative Commons Attribution 3.0 License

1) Edit this article;
2) Add a comment at the bottom; or
3) Email me at fft2001@aol.com

Directory Project English Knol Project Computers Portal Computer Programming Portal Software Development Life Cycle (SDLC)

The Software Development Life Cycle refers to the birth, growth, maintenance and death of software.  Birth occurs when it is developed and installed, a growth period in which perhaps many rapid changes are made will typically follow, the stability period occurs when the user community is satisfied with the software as it is or when the software continues to exist but is no longer used, death occurs when the software is uninstalled.

In this article I will discuss the actual usage of SDLC in various companies large and small.  Theory is fine, for what it's worth, but companies in general do not follow what is termed "best" practices.  The bottom-line profit goal streamlines many practices to create a more lean approach.

Software Birth Cycle

[Edit]

Requirements

The birth starts with the desire for some function to be performed in software.  Next follows the analysis and documentation of the details of how the function should work and sometimes why and how it should fail, i.e. how it should reject any attempt to use it in a non-standard fashion.  The document which may be produced at this step is sometimes called a Requirements Specification.  Sometimes this document is "signed off" by the user or department requesting the software.  Signing off on this document, ensures that at a later stage, if things don't "pan out" as the requester had hoped, the document can be referred to, to determine whether there was some error in it's language. In other words, did the programmer not code to the specification? Or was the specification faulty?

At this point, a brief of the request should be drawn up and circulated (with receipt) to any affected person or department on what the proposed change is, who requested it, and who to contact about it.  This circumvents, in large companies, any later claim of lack of notification.

Sometimes process or data modeling occurs next, but not always.  Not all software sites are set-up to allow process or data modeling.  Sometimes program code specification occurs next, and is written up in a Coding Specification document.  Obviously a document of this sort, must be written by another programmer.  Then coding can begin.


[Edit]

Development

Some software development methodologies would see all the steps in the birth of software as occurring discretely.  That is, each step is finished before the next begins.  In other methodologies, sometimes called Rapid Application Development, Extreme Programming or Agile development, phases of next steps can commence, prior to the end of the prior step.  In some methodologies, each step is in a feedback loop to all prior steps.  Thus changes to the desired properties of the function, or changes to any other step, can occur even at the final steps of the software birth.  Which would then necessitate rolling those changes forward through all subsequent steps as well.  It is most typical that the vast majority of such feedback only actually occurs between the Coding Specification, Coding, and Testing phases.  Note that it is atypical, even under some Rapid development schemes to allow the programmer direct access to the original requester.  The purpose behind this, is to prevent any verbal agreements from escaping the Requirements Specification.  The Requirements Specification, with written changes and addendum, signed off by the requester must be the bible from which all further work proceeds, during this Software Birth Cycle.

One interesting methodology that has been used in this step is a "two-programmer" approach.  That is, instead of one programmer writing each code change, two programmers work collaboratively on the exact same code change.  That is, they both agree on the change, they both write the change, working literally side-by-side.  The perceived advantage of this approach is that fewer bugs make it through to the testers.  The disadvantages are that programmers are more expensive than testers, and that it seems likely to slow the rate of code changes.

[Edit]

Testing

Unit testing refers to that testing typically done by the programmer which is simply testing that the function appears to work in the manner specified by the documentation (if any), without any obvious errors.  Programmers (especially contract programmers) may not know the full business purpose for which the function is designed, nor even the various normal or unusual interactions that the business processes or data may undertake.  And thus, after a programmer has done unit testing, another testing phase typically follows.

This next testing phase, is generally referred to as process testing, or quality assurance, which is where the function is tested under normal and perhaps unusual business conditions.  Sometimes the person who is the tester in this phase, is the original person, or department who requested the software.  Sometimes there are special expert users set aside who only do quality assurance testing.

In this step, various business rules must be understood in order to test the function in the fashion that it will actually be used when it is finally made live to the business.  This tester will generally either refer back through the original documentation (if any), or have a detailed Test Plan already written either by them, or for them by an expert user in that business.  When the tester is the original requester or an expert-user, there is sometimes no Test Plan created at all.  When a Test Plan is created, sometimes any user or even another programmer is given the task of following the Test Plan.  In this last case, the tester themselves does not necessarily need to understand the business rules.

[Edit]
If during this quality assurance phase, some flaw is found, there are two methods usually employed.  Under a Rapid Application development framework, the tester and the programmer are typically together in a "bull pen", where they can simply talk back and forth and work out the kinks in the system.  Or the programmer has direct access to the original requester to simply telephone them and ask.  This is not always possible, so the tester may create a Bug Sheet entry item, specifying what data they used to test with, and what error occurred.  It is quite important to note the data, as the programmer will need to repeat the steps taken, in order to see why the error occurred.

Once all bugs have been worked out, the quality assurance person would normally sign off on the testing document or plan.  At this point, or sooner, instructions for the users, on how to utilize the new function should be created.  These will need to be updated, if any changes, to the very latest version approved by quality assurance.


[Edit]

Implementation

The next phase, is the implementation of the software, which may be accompanied by some kind of translation, or modification to the data as well.  A plan should be discussed for how to address any unforeseen problems during this phase.  For example, is there a plan to roll-back the changes in the software system, if the new software fails?  Is there a plan to roll-back the changes to the data? At a minimum, the data and software that is being replaced of modified should be backed up, so it can if needed, be restored later.

The implementation step, must take into account what persons or departments will be affected, and notify them of the impending change, with instructions on how to utilize the new function.  Infrequently a separate Implementation document may be created at this stage.  Sometimes implementation can be handled almost completely by a custom software tool.


[Edit]

Follow-Up

There may follow a training step, where users are trained on how the new function operates.  Functions that are self-explanatory or trivial may not need any user training.  In addition, functions which will only be used by the original requester will probably need no training phase.

Another step which may occur is a "live program" documentation update step.  This is where any user instructions, system documentation, indexes, permissions, settings, menus and so on, are update to reflect the new function.


[Edit]

Software Growth Cycle

Requirements

Many companies while utilizing or even requiring a complex approach during the Software Birth Cycle, will utilize or some might say revert to a simpler approach for the Software Growth Cycle.

First I will discuss what rapid software development is not.  It is not cowboy programming.  Cowboy programming is a derogatory term that refers to a programmer coding directly against a user's vocal requirement specification.  While cowboy programming generally works sufficiently in a company using only a single programmer, for systems designed and implemented by that programmer, and for simple requests, it does not work well in other environments.

[Edit]
Rapid Application Development (RAD), is a favored approach for the Software Growth Cycle.  In Rapid Application Development, the Requirements "document" may simply be one or two sentences from the requester to make a certain minor change to an existing software program.  Add a field here, change a calculation there, change a display here, add a report that does this and that.  Major changes are not part of the Software Growth Cycle, but rather should be addressed as a new Software Birth Cycle.

The "sign off" during the Software Growth Cycle is typically merely the requester being the person who enters the request initially into a Change Request system, which may as well simply be a memo.  If they created the request, we can assume that they are agreeing to it.  Requiring the user themselves to create the request also forces them to try to be clear, concise and complete about their request.  At this point, a brief of the request should be drawn up and circulated (with receipt) to any affected person or department on what the proposed change is, who requested it, and who to contact about it.  This circumvents, in large companies, any later claim of lack of notification.


[Edit]

Development

It would be atypical, even in those companies set up to use process or data modeling, to do any modeling at this stage.  It would as well, be atypical to create a Program Code Specification document.  Analysis and coding simply begin.  The programmer should, under the Rapid Application Development outlined here, have direct access to the requester, either face-to-face, or by telephone to directly address any issues that arise, immediately.  Note that this is not typically the situation under the Software Birth Cycle where there may be two or more layers of individuals between the programmer and the original requester.



[Edit]

Testing

Perhaps fifty percent of businesses actually create an actual Test Plan for the small changes that occur during the Software Growth Cycle.  Of course, when something goes wrong the programmer faces the chance of the charge of cowboy programming.  But at least you will know you're in good shoes, since even some large companies frequently implement changes during this cycle with no Test Plan at all.  In many of those companies who do have a formal Test process, it often simply consists of the original requester testing the change in a test environment, and giving a verbal OK.  In the remaining companies, the most typical scenario is for a quality assurance person (or the original requester) to write a test plan and either the original programmer or the original requester runs that test plan.  It would be atypical for an extra party to be involved in this step under the Software Growth Cycle.

[Edit]

Implementation

Implementation in this cycle generally consists only of the original programmer copying the changes into the live environment.  Often the old version of the code is archived.

[Edit]

Follow-up

There is generally no need for follow-up training, since the changes should be small or obvious.  And there is often no need for a system documentation update step since many or most system documentation manuals are over-broad in their scope.