Software Development Life Cycle (SDLC)

 

Introduction into the SDLC

Developing IT application systems is generally done by a team of developers and is made up of various modules / objects. In most cases a comprehensive Application System can take a fairly lengthy period of time to develop. Let us take for example the Zandstra Systems website’s application that facilitates recruitment in South Africa and abroad. It took six developers approximately three years (36 months) to develop the application – from start to finish.

With something so large, with so many interrelating parts, it is difficult to keep track of, the entire system. The way in which such projects are generally managed is through a specially qualified people called Project Managers / Leaders. It is their job to ensure the smooth running of such projects.

Projects always start somewhere and in most cases they will start when a problem or a change in policy is undertaken within a company or organisation. For training purposes we are going to refer to the company / organisation as the client. The client will then brief the Software Development team with the problem and then they will go about formulating a solution to the situation. In addition to the solution (application) they will also have to provide two sets of documentation: The first one is a user’s manual and the second is technical documentation. The reason for the second document is to facilitate further development if necessary and solving any technical issues that may arise.

The process of developing an application solution for a client is called a System Development Life Cycle (SDLC). It breaks up the development of a system into separate stages that are dependent upon one another.

Stages of the Software Development Life Cycle:

The development of a relatively straight forward Application System will normally follow the following stages:

  1. Definition of the desired outcome
  2. Specifications – expected input, processing and output.
  3. Design – a project plan
  4. Coding
  5. Testing
  6. Implementation
  7. Maintenance

Each stage produces an outcome in the form of a document or program. This is used as the input to the next stage and so a circular route emerges. If a new system is developed the cycle starts with the definition of the problem. If an existing system is present, all the technical documentation and source code of that system is required.

As you can see documentation is a very important aspect of the development cycle and there are various ways of simplifying that process. To facilitate the creation of the Technical Documentation it is very worthwhile for the developer to keep all the notes and diagrams created during the planning / design phase. In addition to that the developer must never be shy to include comments in their source code. This will help them to keep track of the different blocks of code that make up their application but also help with the creation of the Technical Documentation.

The user documentation must be created to help the client become familiar with the application you are providing. There are also various ways of implementing it. Firstly there is the hard copy version. This version must have an introduction explaining what the purpose of the program is. The body of the document will have explanations of how each aspect of the application works and how to use it. This can include screen shots as well as a ‘how to’ section.

Another approach to user documentation is creating an online ‘help’ feature. This can be done in various ways and an HTML web page is a good example. Yet another way of helping users is to offer example data in all the fields that require data to be typed in. This sample data is generally selected when the user accesses the field and then when they start typing it disappears. This helps to make the software foolproof.

We are now going to go through all the steps of the SDLC in more detail explaining each step:

Definition of the desired outcome:

At this stage the client will have a good idea of what the problem is without really having an idea as to how to solve it. All they do know is that you, the application developer, will be able to come up with a computer based solution. It will therefore be necessary to have meeting with the client to first of all find out exactly want the problems are and how they have dealt with them up until now.

You may find that there is an existing simple computer based procedure that they have been using till date which has become insufficient to run the business successfully.

It is very important that during the course of the interviews that you keep notes detailing what the proposed inputs are and what the desired outcomes are. You will be using these at a later stage during the design phase.

Specifications:

You will now look at a more formal set of inputs, processing and desired outcomes. This involves composing a list of everything that you propose your solution will do.

Whatever current system they are currently using, now needs to be further analysed and this can be done in the following ways:

Once you have done the research mentioned above you should have a clear understanding of what the new system needs to achieve. You are now ready to write the specifications. The specification lists all the details of what the new system is going to do. It does NOT, however, state how this is going to be achieved in any way.

You are now in the position to write a proposal to the client based on the list of specifications you have put together. It is important to note that this is not a technical proposal and so it must be written in a friendly way. Once you have gone over the specifications with the client and agreed to the solution you proposed the client would usually sign an agreement or contract.

Once the development is completed, tested and covers all the agreed upon specifications, the application can be delivered to the customer with all supporting documentation. If the client now decides they want further features implemented in their software package you would go through the same procedure of getting the desired specifications, produce a proposal and charge the client for further development.

Design:

Now that you have a good idea of what is required by the client as well as a detailed list of specifications it has become time to plan the actual software development stage of the project. There are various stages involved in the design process which we will cover in this section.

Before we can start with flow diagrams, mind maps and pseudo code there are some fundamental decisions that need to be made. They include what the storage policy is going to be and what kind of user interface (UI) is going to be implemented. Since this course is focussed on Web Application development we will skip this part for now as it will be covered in a latter chapter in detail. For now we are going to save data straight to the hard disk drive (HDD) and not worry too much about UI. We will start with command prompt driven programs and then move on to graphic UIs (GUIs).

fig05

Flow diagrams: Flow diagrams allow you to plan your objects and functions in such a way that you can determine a flow of data and how the various objects / function interrelate. The objects can be shown as big blocks containing smaller blocks that represent the functions /data structures within the objects. Then, by using arrows you can show which functions / objects are going to send / receive data from which other objects / functions and what operations are going to be applied to the data.

System flow charts/diagrams are based on an internationally agreed set of symbols (even though they don’t need to be strictly adhered to). Figure 5 shows a collection of system flow diagram symbols in common use. Notice that there is one set of symbols that relate to stored data and yet another set that refers to various types of processing.

It now becomes possible to start splitting the project up into sub-sections which allows you to have various members of the development team work on separately. It is the project leader’s job to make sure that all the separate sections of the Application eventually do work together in harmony.

Pseudo code: Pseudo code relates more to the planning of the actual algorithm/s implemented in the application. Pseudo code is not real computer programming language code but rather an explanation using regular English, algebra and Boolean logic to explain what should happen in certain parts of the program. The purpose of pseudo code is to determine behind the algorithm. Once the pseudo code is in place it becomes relatively easy to translate into program code.

As you become more familiar with the particular development language you use your pseudo code may start using keywords that form part of the programming language anyway.

Writing the Software:

Once the specification of the desired application system has been defined and accepted, the detailed work of the development of the system can begin. System development is deals with the specifying, writing, testing and documenting the programs for the new system, or configuring an existing software application package for the tasks required. Theses activities are done by a team of developers guided by a project leader.

Now, using all the information that has been gathered the project leader can start deciding how the whole project will be developed and start assigning modules / objects to the actual programmers. Each programmer will therefore be assigned a section of the overall application and a later date all these section will be combined to form the form the final product. It is the project leader’s responsibility to keep all his/her developers focussed on the same outcomes and make sure that the modules are going to be able to integrate regarding parameter passing etc.

In addition to that it is also very likely that specific common libraries / dictionaries need to be developed. They would then be accessed by most of the other modules that for, the overall application.

Again I want to mention that it is the responsibility of the developers to keep track of all the coding (programming) they do. This is achieved by adding comments to the actual code as well as keeping a set of hard copy notes. These will eventually be used to facilitate the creation of the Technical documentation as well as the user documentation.

pl

« Previous || Next »