The Software Development Life Cycle (SDLC)

SDLC – Introduction

The Software Development Life Cycle, or SDLC, can be defined as a process that aims to create quality software applications while incurring the lowest costs and in the shortest possible amount of time. The SDLC includes principles and a detailed plan to be followed for developing software systems.

The typical SDLC has 7 key stages. They are:

  1. Planning
  2. Requirements Analysis
  3. System Design
  4. System Development
  5. Testing
  6. Deployment
  7. Maintenance
The Software Development Life Cycle

Each stage of the software development life cycle will now be discussed in detail. Additionally, the deliverables of each stage will be outlined too.

1. Planning – SDLC

The planning phase is the initial stage of the software development life cycle. During this phase, the development team need to formulate a plan of what is needed from the software / system / application. The planning stage will identify the client’s current problem/s by getting input from all of the project stakeholders and conducting a requirements analysis. By doing this, the strengths and weaknesses of any existing systems will be noted and the needs of the new system/s will be discovered. The planning section should be carried out simultaneously with the requirements analysis.

Some additional aims of the planning stage are;

  • To outline the existing problem and define the scope of the existing system.
  • To produce a brief summary of the expected system and its’ goals.
  • The feasibility of the system / project should be assessed during the panning phase, and a project schedule should be created.

The deliverables of the planning phase are typically:

  • A Feasibility Study – The aim of a feasibility study / analysis is to exhibit the reasons for developing the system that would be acceptable to users, scalable to future business expansion and compliant to any relevant standards. In summary, the primary aims of a feasibility study are:
2. Requirements Analysis – SDLC

To carry out a requirements analysis is to define the requirements and expectations of the client and the eventual end users of a system that is to be developed. It can usually involve a variety of tasks that will figure out those user and system requirements. These requirements needs to be tailored to optimise the client’s business processes i.e. to make life easier for the workers. A well-executed requirements analysis stage will focus on gathering, validating and analysing relevant information about a business, the business’ processes, the system and the eventual end users.

  • Gathering – Requirements gathering is the process of obtaining all of the information needed to form an understanding of the business, its’ processes, the system and the eventual end users. Practices for gathering requirements include:
    • Brainstorming.
    • Meetings & Interviews.
    • Questionnaires & Surveys.
    • General observation of the client’s work.
  • Validating – To validate requirements is to ensure that they are relevant and will meets the operational needs of the client.Verification of the gathered information will confirm that:
    • The set of requirements is accurate, complete, and consistent.
    • A model can be created that will satisfy those gathered requirements.
    • A realistic prototype can be produced and tested to demonstrate that the requirements will be met.
  • Analysing – The analysis of the gathered requirements is the step that will determine the standards. The analysis involves double checking that the requirements are complete, clear and unambiguous. Any issues that are flagged during the analysis need to be resolved before proceeding to the next stage of the life cycle.

The expected deliverables of a requirements analysis might be:

  • A System / Software Requirements Specification – A system requirements specification is a detailed document that describes the system that is to be built. The document outlines both the functional and non-functional aspects of the systems and outlines what a system is to do and how it is to be used.
  • A Technical Requirements Specification – A technical specification outlines a set of requirements for the system in order for it to function as it is planned to be, such as, the technical user requirements, the technical system requirements and the system security requirements. It is a more in depth specification than the general system requirement specification. These lists of requirements have to be fulfilled before the development of the system can be carried out.
3. System Design – SDLC

The software design phase of the SDLC comes following the planning/requirements analysis stages. During the planning phase, the team should have devised a detailed plan of what is needed from the software. The plans should have outlined the requirements of the system/software along with the cost and resources needed. Specification documents would have been produced that will now be used to design the system.

The primary aim of the software design phase is to deduce how to achieve that which is outlined in the specification documents. This stage will begin by converting those specifications into a design plan called the Design Specification. All stakeholders will be asked to review this plan and to offer feedback and other suggestions. It is important to have a plan for collecting stakeholder input for this document. Failure at the software design phase will most certainly result in cost overruns at best, and the total failure of the project at worst. There are a variety of tools that can and should be utilised during the design stage of the SDLC. The produce of these tools will mostly form the data model deliverables of this stage.

The deliverables of the design stage consist mostly of system data and process models that translate the requirements into a conceivable system. They can come in the form of any of the following:

  • Data Flow Diagrams – Data Flow Diagrams (DFD) graphically represent the flow of data between the different modules of a business system. They also show information about the inputs and outputs of each process, giving a decent representation of the system architecture. See task 2 of this assignment for an example of a DFD.
  • Structure Charts – A Structure Chart is a chart that would be derived from a DFD. It should show the system in much more detail than a DFD would. A Structure Chart will dissemble the whole system down into its lowest functional modules. It will also usually describe the functions and sub-functions of every individual module of the system to a greater extent than a data flow diagram.
  • Structured English – In terms of systems design, structured English is the application of the English language merged together with the syntax of structured programming to express the design of a computer program. Structured English breaks down a system into logical steps using straightforward words. It is a useful design tool as it can give non-technical persons a deeper insight into the inner workings of the system.
  • Pseudo-Code – Pseudocode is a neat way of writing programming code in English. Pseudocode is not a programming language and although it’s similar to using structured English, it is written at a higher level than simple step-by-step English, and probably won’t be understood by most non-technical persons. Designers use short phrases to write code for systems before any real programming is carried out. The pseudocode then acts as a blueprint for the developers – once they know how the program will function, they can use the pseudocode as a basis to writing the actual program code.
4. System Development – SDLC

The development phase of the waterfall SDLC should only ever come following completion of the planning and design stages. Failure to sequentially follow the preceding steps will almost certainly result in difficulty, if not total failure. When employing the waterfall model, the development step is entirely dependent on the plans, documents, blueprints and models that were produced throughout the earlier phases.

Although it can typically be the longest phase of the lifecycle, if the correct steps were taken before the build begins, it can actually be the most straightforward stage of all.

In the build stage, work is to be divided into manageable modules or components and allocated to each of the developers. A suitable programming language or tech stack would’ve been decided upon during the design step. The developers will follow the coding guideline associated with the language/languages. A selection of tools will be utilised by the programmers to generate and manage code and to carry out the build, such as; an integrated development environment (IDE), a compiler, an interpreter, some version control software and an emulator.

The purpose of the development stage is to convert the models produced during the design phase into an actual system. The primary deliverable of the development phase is a somewhat functional, testable application that meets the set out requirements from the earlier phases. Other deliverables might include:

  • Application code base.
  • System documentation.
  • Database schema.
5. Testing – SDLC

Following the build phase of the waterfall model, the process of testing the newly developed system should take place.

Software testing is a process that examines the functionality and accuracy of the system against the specifications that would’ve been outlined in stages 1 and 2. Checks will be made to ensure that all user and system requirements have been met, and that the general functionality is up to standard. Negative test results will allow the development team to refine the build, in order to improve the reliability and quality of the software. Testing tends to be an expensive and prolonged process. That being said, it is also imperative part of the development lifecycle.

The aim of the testing stage is to cause the system to fail. A successful testing process is one that identifies bugs and irons them out. It involves a quality assurance team running through the program with the explicit goal of finding errors.

The testing stage should follow a bit of a lifecycle within itself. The flow of the below deliverables identifies this:

  • A Test Strategy – A test strategy is a vague declaration that gives information about the techniques and tools that will be used for the system testing.
  • A Test Plan – A test plan will provide a scheme for testing the newly developed system and should cater for confirming that the system when tested meets the design specifications/the user and system requirements. The plan should detail;
    • The objective of the testing.
    • An overview of the tools and methods that will be used.
    • How much time is to be applied to each test.
    • The availability of resources.
    • An understanding of the standards required for carrying out the tests.
    • Criteria to be met in order for successful completion of the tests.
  • Specific Test Cases – Test cases are applied to identify as many bugs as possible. A variety of test cases should be designed for each section of the system. The test cases will state how the functionality of a requirement is to be checked and the standards for the success of the test. The test plan together with the test cases should be documented in the system spec document.
  • Test Result Documentation A results document should be produced, which contains short pieces of information such as the number of errors encountered and the nature of those errors, as well as the total number of test cases applied. The details of this document will be assessed against the details of the test specification to calculate the overall outcome of the testing.
6. Deployment – SDLC

The deployment phase is the second last stage of the software development lifecycle. The primary objective of the deployment process is to make the completed system operational. Therefore the deployment stage involves the roll-out of the product / system. Following the success of the testing step, the system should be ready to go live, meaning that the application is prepared to be used by real users in the real environment. The system developers need to be conscious that some training of the end users might be necessary.

The deliverables of the deployment stage would most commonly be:

  • Contingency Plan – Producing an effective contingency plan is a critical deliverable of the deployment phase of the SDLC. A contingency plan is a document that prepares the business for predictable issues that could negatively affect them.
  • Business Process Documentation – Another deliverable of the deployment stage are documents that set out the newly devised business processes that match the functionality and optimisation that the new system will bring.
  • Training and User Manuals – During the deployment stage the client’s employees / all of the system end users need to be adequately trained to understand how new systems function and what they can be used for. A training manual is a document that needs to be delivered that will guide the users through a training process step by step. A user manual also needs to be delivered. A user manual is a document that can be referred back to by the users if the ever need future guidance / reminders on how to use the system.
7. Maintenance – SDLC

Finally comes the maintenance stage. This stage is where the IT team of the development company offer support to the users of the system. The goal of maintenance is to make sure that the requirements of the users and the systems are continuously met and that the system consistently behaves accordingly as per the requirements specification. Furthermore, projects rarely turn out perfectly as planned. The maintenance phase also allows for constant and further debugging of any problems that could have been missed in the testing stage, as well as updates to match any advancement in systems reality.

The deliverables of this final stage might be:

  • Maintenance Plan – A maintenance plan is a document outline the steps to support a system throughout it’s’ life cycle. The plan will also contain technical information related to the integration of the system should any problems arise.
  • Procedures for reporting issues – During the maintenance stage, documents need to be produced that clearly outline how future issues with the system are to be reported.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: