What is SDLC?  SDLC stands for System Development LifeCycle or, in some industries, Software Development Lifecycle.  Simply put, SDLC is the overall process of developing information systems through a multi-phase process.  We’ll use the term System development here, as the term System development is inclusive of Software development, but not vice versa. 

Types of SDLC Models

• Waterfall model (The original SDLC model)
• Agile model
• Spiral model
• Incremental model
• DSDM model

Although SDLC has different forms and models, it follows certain steps.  Each SDLC methodology will have variations from its counterparts, but the key principles behind systems development include several core steps.  We will detail those below. Please note: the differing methodologies were designed, in large part, to achieve specific aims.  For example, a strength of the Waterfall methodology is that it places emphasis on documentation and source code, whereas the Agile methodology supports rapid development and frequent code inspection.  As an auditor, if you understand the key success drivers for a project you may also be able to assess whether the appropriate SDLC methodology was selected.  This would add value to your audit as you are not only addressing risks, but also IT governance. 

Core steps for any SDLC model

1. Requirements – This phase creates the foundation on which the rest of the project will be built.  In a generic sense, this could be considered a “planning” phase.  The deliverable, or end product, of this phase is a set of Requirements for the project.  Requirements must be actionable, measurable, testable, related to the identified business need or opportunity this project will address, and the requirements must be granular enough to provide a framework for system design.  Fixing issues at this level of the project is much less costly and time-consuming than if the fix needs to be implemented later on in the project.

2. Specification – Simply put, the specification for a project consists of the documentation that describes the requested behavior of the system.  This could be considered the “design” phase of the project.  The specification phase is not so granular as to dictate the exact inner workings of the system under development, but it should provide a framework that will allow for accurate forcasting of resource needs, configurations, and process flows.

3. Design – This is the process of developing a heuristic or algorithm that provides the ‘best way’ to solve the problems and challenges presented by the requirements document in step 1.  Design considerations include, but are not limited to, questions regarding the security, usability, compatibility, extensibility, etc. of the system.  The design is most often carried out in a modeling language, used to represent the logic inherent to the system being designed. 

4. Implementation – This stage represents where the actual programming or coding takes place.  Various languages can be used to implement the design, and design requirements may dictate which language(s) are used.  This section should require the least scrutiny as an Auditor; issues in this phase should be identified during the testing or ultimately the deployment process.  An auditor may wish to examine whether an unreasonably high number of issues are uncovered in the testing and deployment phases to uncover any issues there may be within the implementation phase.

Editor’s note: If you are interested in learning more about the art & science of programming, consider reading Paul Graham’s essay Hackers and Painters.

5. Testing – There are many different ways to implement the testing phase and, depending on the importance of the project and the criticality of the process and its data, multiple testing methodologies may be employed.  Within larger development teams, testing is performed by specialists who would be considered software testers.  They may use a static approach (which would include a review, walkthrough, or manual inspection), a dynamic approach (which consists of executing programmed code using test cases), or a hybrid approach incorporating both methods.  It is also important to make sure that Regression Testing is incorporated into a Software Development Lifecycle methodology.  Regression testing is the process whereby old, previously tested code is re-tested as a part of a system upgrade or release.  This is an important part of the SDLC process in order to ensure that there are no regressions in the quality of the code, thus the name.

Audit tip for Risk-based audits:  A study performed by NIST in 2002 indicates that software errors, or bugs, costs the U.S. economy $59.5 billion annually.  According to the study, more than a third of that cost could have been avoided through the implementation of the appropriate levels of software testing.

6. Acceptance – This phase represents the deployment of the completed system into the hands of the end-user.  For corporate systems, this phase is most often accompanied by testing for compliance to the requirements document (completed in the first phase).  This testing is generally performed by a small number of users from the business unit(s) that commissioned the project and, upon successful completion of the tests, formal signoff for the project is received.  After signoff has been received, the system is then promoted into a ‘production’ state (or is said to have undergone an MPROD, short for a move to production).

Due to the complexity, variation, and constant evolution of information technology systems most companies create a customized deployment plan for each system, rather than defining one corporate process or procedure.  The policies and procedures for when a system is ready for a move to production should be documented at a corporate level.

Audit tip for Risk-based audits:  The corporate Information Security team or a 3rd party contractor should be involved in the signoff process before a system is moved into production.  A risk assessment and possibly also a vulnerability assessment would be very appropriate prior to signoff, especially in the event that the system is a website available to the public via the Internet. 

7. Maintenance – The maintenance phase of the SDLC may be traditionally considered only for fixing the ‘bugs’ that become uncovered during the use of the system, but in reality over three quarters of maintenance effort is to enhance the system (T. Pigosky, Practical Software Maintenance, Wiley Computer Publishing, New York, 1997).  These enhancements, over time, may lead to a more complex system than what was originally intended. 

Audit tip for Risk-based audits:  You may want to confirm whether or not Management has a documented ‘trigger’ to kickoff a code refactoring process, which would reduce the complexity of the algorithm.

8. Disposal – Last but not the least, when a system is being decommissioned, it is not simply a matter of making sure to delete all files associated with the system.  Proper information disposal procedures should already be documented by the organization, so make sure that the parties responsible for decommissioning the system follow them.  If there are no policies or procedures in place to deal with the disposal of data, that should be considered a finding.

In the event that these procedures for disposal of data are not followed, valuable Intellectual Property or even worse – confidential data – may be exposed and put your organization at risk.  Proper levels of data cleansing ultimately depend on how valuable the data is you are trying to protect.  If you are simply cleaning old configuration files and source code, neither of which provides a competitive advantage to your company, then a simple software drive formatting may suffice.  If your data is more critical or the loss of which would subject you to fines and litigation, you may wish to consider degaussing (demagnetizing) the hard drive.  For those items that are most critical, physical destruction of the drive may even be appropriate.  

We have just reviewed the common steps in SDLC processes.  Additional information is available regarding specific SDLC methodologies from various resources on the web, or feel free to post your question on our IT Audit Forum.

If you have any questions or comments regarding this article, please send them to us.