Things have really changed in the software development arena over the last few years. You don’t have to look back too far to remember a time when system development meant asking a programmer to write some code in order to carry out a procedure or resolve an issue.
However, now times have changed. These days systems are highly complex and that means that many large companies employ huge teams of programmers, analysts, testers, architects and more – they have to collaborate and work together in order to produce the custom-written code which ultimately drives companies to success.
As a result the traditional interface can now be managed by a series of system development lifecycle (SDLC) methodologies. We will explore some of these models below.
What is a typical systems development lifecycle?
There are several stages to software/systems development. A usual lifecycle will follow this format:
- Step one | An analysis of the planning stage and requirements
- Step two | A definition of the requirements
- Step three | A design of the product’s architecture.
- Step four | The actual development and building of the product.
- Step five | Product testing.
- Step six | Deploying the system into the market and carrying out any necessary maintenance.
Systems Development Lifecycle Models
There are a host of system development different lifecycle (SDLC) models that have become popular through the industry. Here is a brief explanation of some of the most popular examples:
The waterfall model is generally seen as the most common system development lifecycle methodology albeit it has been surpassed in recent years.
There are several phases to the waterfall model. The first is the requirement gathering stage with analysis. Here all potential requirements will be developed, captured and documented. Then comes the system design stage which will specify the system requirements and hardware necessary. This is followed by implementation which usually sees the system developed with small programs and then tested for functionality. The next stage is testing and integration with the units phased into the system and examined for any failures or faults. From there the system is deployed and the final stage is maintenance should any issues arise when in the client’s hands.
The iterative model is generally used when the system’s requirements are fully understood and there is a time to market constraint. The idea is that major requirements are defined from the outset with additional functionalities and enhancements potentially appearing over time. The technology will be learnt by developers as they work on the project and it is possible that some of the key goals and features may change over time.
There are four phases to the spiral model. The first is identification when the business requirements are gathered – bear in mind that when the product matures, further requirements may be identified. Then comes design, which will begin with the baseline and architecture along with module design and design of physical products. The third stage is the build stage which is the actual software production itself. During this stage a proof of concept should also be developed so it is possible to gain consumer feedback. Finally comes the risk analysis and evaluation which will see risks managed and technical feasibility assessed. When testing is complete the consumer should evaluate the software and provide any feedback.
Next comes the V-Model, where execution is carried out sequentially to effectively form a V-shape. The V is meant to stand for verification or validation. Effectively, the V-Model is simply a waterfall concept extended and sees a testing phase carried out at each development stage. So for every cycle of development there is a corresponding test phase. This model is considered highly disciplined as it is not possible to start another phase until the preceding phase has been completed.
SDLC Big Bang Model
Here there is no specific process. Instead, development starts with the necessary money and efforts and the output is the software which might or might not be suitable to meet consumer requirements. Obviously there is little planning required and even the consumer is not sure about what they actually want from the product.
This thought process has become the best-known in recent years because of its adaptability and flexibility. There are many different Agile methods including the rational unified process created in 1994, Scrum developed in 1995, Crystal Clear and Extreme Programming which was developed in 1996 and the likes of feature driven development, adaptive software development and dynamic system development. Collectively they were united by the Agile manifesto in 2001.
The main concepts of the agile manifesto are that: motivation and self-organisation are vital; working software is the best form of interaction with consumers; interaction with consumers is vital in establishing the product’s requirements; and the ability to respond to change quickly is vital for continuous development.
RAD and Software Prototype
These are more modern concepts that rely on understanding requirements as quickly as possible while providing a model that allows for fast feedback that can be organised suitably to boost the product.
This is just a brief introduction to the various models: look out for more in-depth explanations in later Arrk Thought Leadership articles.