Building useful programs to solve complex problems can be challenging. Many people with different skills team up when it is time to get into a new project. An important aspect of this is communication and organisation. For these reasons, people normally adopt a method and try to stick to it. In this post we will be looking into the System Development Life Cycle.
Recall from Chapter 8
We have talked about various kinds of application software to suit different types of users in Chapter 8. The card below should refresh your memory.
Whether we are creating software to, sell as-is to as many users as possible, or, come up with a bespoke product for niche clientele we must use an effective method to increase our chances on obtaining good outcomes.
“Life's too short to build something nobody wants.” - Ash Maurya, Running Lean: Iterate from Plan A to Plan that Works
This topic is very important and you will find a lot of literature if you bother to look.
What is the SDLC?
SDLC stands for System Development Life Cycle which attempts to describe the lifetime of the system from creation to obsoletion and everything in between.
What is a System Development Methodology?
A system development methodology refers to a set of rules that people use to structure and plan so that there is some control over the process of developing a system. Methodologies have evolved over the years. Every methodology has some advantages and disadvantages therefore companies adopt the methodology that fits in with their culture.
We have listed the top 4 methodologies that are used just so you are aware of them, but in reality for your exam you should just know the core steps of the Waterfall Method in some detail.
Waterfall Method | This is a traditional method consisting of sequential phases whereby each phase focuses on a distinct goal. A phase should be 100% complete before moving to the next. There is no way of going back. |
DevOps | Development Operations refers to the practice to support the IT infrastructure of a company. People who work in DevOps are disciplined, specialised, very focused and work fast under pressure! A lot of time and money is invested to automate most processes so that the company can be first in the market and reduce failure rates. |
Agile | Probably the most popular one because it is centred around the idea of constantly reducing risk and continuous improvement. Teams work in short cycles and regularly release a new/improved part of the system for testing. |
Rapid Application Development | This is the methodology your teacher experienced the most because she worked in a lot of start-ups as a junior developer. The focus here is high quality but low cost. Companies that adopt RAD are often new therefore the people working on a project have to be prepared to shift and change direction. |
What is the Waterfall method?
This method is probably easy to understand because it is characterised by a linear progression from beginning to end. The diagram below illustrates the different phases of a project. This methodology heavily relies on careful planning in each phase, detailed documentation in each step and consecutive execution of steps. Therefore despite that it is easy to understand, it is actually very difficult to implement in practice.
Step 1: Requirements Gathering
The goal in this phase is to identify what the problem is broadly for e.g., "many customers like our eco friendly cars but cannot pay the full amount up front and we do not offer alternative payment plans". In fact, in many text books you might find this phase labelled as identification of the problem. To put it simply in this phase people try to find out why things need to change.
Step 2: Analysis
This phase has two goals so in some books you might find this phase split into two but it makes a lot of sense as one. System development projects can be expensive and it is very important to end up with a system which is right for the company. No one would want to reach the end stages and realise that it does not quite work or even worse... it is unethical or too expensive.
After the specialists feel they finally know what the problem is they need to perform analytical activities in order to answer a couple of questions:
Is it feasible to solve the problem, can it be done?
If this problem is already here, how are they dealing with it now in their current system?
Normally a Systems Analyst answers the first question and a Business Analyst answers the second. To dig out answers they perform activities like:
Interviews and questionnaires to gather more specific requirements and identify problems specific to the employees and customers.
Reading documents.
Observing people using the current system.
The outcome of this phase is generally a detailed report of what needs to change or be built as new and at what cost. The company commissioning the system can either say... "yes let us implement a newer and better system" or "no we will stay as we are for now, thank you very much".
Step 3: Design
If a project reaches this stage then it means the company would like to make the changes proposed and agreed to the terms. Hooray! Let's recap a little... the why is covered, the what also so up next is... the how of course. And this phase is personally my favourite ❤️ part.
A small team of specialists leaded by the Systems Analyst come together to plan out how they can help the company achieve their goals. This is a very creative process which involves designing what the system is going to look like, what kind of technologies will be used and what algorithms need to be implemented.
The outcome of this phase is generally a write-up that contains drawings of the user interface, flowcharts, structure diagrams or pseudocode and a detailed timeline with a test plan. This piece of work is passed on to the next stage.
Step 4: Coding + Automated Testing
Presumably this phase needs no explanation. At this stage we know what needs to be done so it is a matter of rolling up those sleeves and tick off all the tasks that are detailed in the design specification with a bit of magic.
Of course you are right, it is not really magic and you know this from your hard work 🙄 during programming sessions. What you experienced in class is similar to what grown-ups do in real life. They use a programming language, they set up their Integrated Development Environment or IDE, the software that we use to create our programs for e.g., Visual Studio Code, we make mistakes in our programs, we cry for help... and so on until finally...
The outcome of this phase is the source code and hardware with the automated tests. Developers must also code tests for each feature they build. A feature is not complete without its test. The beautiful green tick is the proof that it is ready for the next stage.
Developers are not able to test everything... which is why there is a very thorough and dedicated phase right afterwards. However some testing (this is linked to a different topic) can be done at this stage and is usually automated:
Unit Testing Every module would have a corresponding testing module to run all its functions with some test data.
Integration Testing The testing of modules interacting with each other.
White Box Testing End-to-end testing of each possible flow from the interface.
Step 5: Testing
And here we have the arch-enemy of the geeks that work in the basement. The quality assurance people or put simply testers, and their mission is to find the most obscure ways to break the system.
Of course I am joking! I had the pleasure to work with the nicest testers on earth. In this phase it is important to test the system without any knowledge of what is going on inside the code. Users tend to have unpredictable behaviours so in this phase a couple of activities are performed:
Black Box Testing Testing the program without looking at the code.
Alpha Testing Performed by people within the software house.
Beta Testing This is performed by a small range of users outside of the software house before the official release.
The documentation that should be produced at this late stage is perhaps a user manual or a tutorial so that people who are new to the system, or somehow get stuck in the middle of the process can refer to it for guidance.
Step 6: Operations to Launch
There is just some more work to be done to launch 🚀, or more formally implement, the new system. Depending on the nature of the project activities in this phase can vary but we can summarise a few aspects here:
User Training
Data Migration and archiving
Conversion from old to new system (refer to the changeover methods below)
Step 7: Maintenance Plan
This step has been left out in the diagram but nonetheless quite an important element that you should be aware of. After a company invests so many resources into something, they normally want some reassurances from the solution provider. The umbrella term used here is "maintenance" although nowadays, "support plan" is more common. Companies require support for issues that could not be foreseen and perhaps give meaningful feedback after using the new system for a while.
How does the old get replaced with the new?
There are a few ways:
Direct Changeover Like the flick of a switch the old system is turned off and the new system is used immediately.
👍 Quick and no duplication.
👎 Can be a little bit chaotic if there are operational issues or the users are not well trained.
Parallel Changeover
The new system is released to be used but the old system is not switched off in case users need to fall back on it.
👍 Does not cause operational disruptions and users can compare the new way against the old, hopefully to realise the benefits.
👎 Users reluctant to change will keep using the old system even if it is not necessary.
Phased Changeover
If a new system is quite large then the release can happen in bits rather than in one go to minimise certain risks. This is an approach that works alongside direct or parallel changeover.
Pilot Changeover
If something new needs to be released to a very wide user base, like in the case of Netflix, then the new features are released to a portion of the users. The company will keep doing releases until all of their user base is covered. This normally works well with a direct changeover.
Comments