SOFTWARE DEVELOPMENT LIFE CYCLE
What is the Software Development Life Cycle
The software development life-cycle (SDLC) is the entire process of developing software/systems. This stretches from the initial idea right through to implementation. Although implementation is not the last stage of the life-cycle, as you will soon discover the last true stage of the SDLC is evaluation of the software, at which point you review the software and make suggestions for possible upgrades to the system, then more often than not the system is then added to.
“Just a little note, I will use the words software, system and project interchangeably throughout this 5 part blog post.”
There are certain stages to the SDLC these are:-
Now let’s look at all of these stages in more detail.
This is the stage we you evaluate your situation and gather as much information about everything that could impact your system/software. The easiest one to identify is people, understanding the market is not a new concept for when developing software. It has been used to identify gaps in the market for new products and gauging the success of new products before going into the market. This can be critical to the success of your system/software. If your developing software that help older people to use computers then it would be useful to understand how that target market behaves. One idea would be to rate what they would use the system to do, whether it was going online to buy goods online or just surfing the internet.
Gathering requirements about your software is crucial to this stage. This is creating a checklist to which you can work to when in the design stage. When creating a requirements specification it is always a good idea to keep it open to changes. But good practice would be to create newer version of the requirement specification. So you would have version 1 and version 1.2 then version 2, and so on. There is a model that can help you define these, it is called USE CASE model, it is part of the Unified Modelling Language (UML) framework.
Storyboards are a good technique when discovering and expressing ideas about you software. This tool is just like creating a story using pictures like a comic. Separating each process of the system/software out, it can help to gain a understanding of issues that could affect your software/system.
There are many techniques that can be used to gather all this data about the user of the system. Running workshops with a variety of practical activities and brainstorming sessions are always a good idea to gain the more popular requirements. Spending time with the client is also crucial, people skills can be very important when dealing with all the stakeholders of the project.
Prototyping is also another good technique to gain and understanding. This type of requirements analysis is relatively cheap compared to designing a whole solution. It allows you to make big changes to a solution even changes the entire solution without losing too much ground and budget. Paper prototyping is when rather than creating a mock solution using ICT, you creating pages which are drawn and then run through the prototype in situ.
This list of ideas that has been drawn up is aimed at a functional list of requirements which are the action carried out by the user and the system. But there are more requirements these are called non-functional requirements. Requirements like these are invisible to the users at most levels but are crucial to the system/software. A non-functional requirement could be; the system runs at a fast speed, the data is secured through hash tables. Requirements that are not functional to the system but are required in the background of the system are just as important and in some cases harder to implement, it can mean programming your code to certain standards or running your system on secure and fast hardware.
Understanding any system that is already ready in place is also another analysis technique. Being able to dissect any system that is currently being used in a vital technique in providing you with more information about the problem space you encounter. Even if your system does not use computers it is still doing to be a system of some sort. A system by can be defined by three things:
These three things make an up a system. So that if you’re tackling a business problem for a client and they currently do not use any computer system within their work it will be the processes that they carry out that will define the system they use. Modelling the current system can be valuable, using tools such as diagrams; the Unified Modelling Language (UML) has lots of models that you can use to model the behavior that the current system carries out. Some of the models are the Sequence Diagram and the Class diagram.
Modelling the data that they currently use can be a great advantage to the success to your project. The data will be any information that the system already in place uses. This can be data about customers or information that they use to calculate prices, such as; tax, expenditure and so on. A data context diagram can be used for this. But any data model is a really good technique for understanding the data already in use within the system.
Check out Part Two where we discuss the Design Stage