Systems Development Life Cycle is a terminology used in information systems, software engineering, and systems engineering for describing the process of planning, creating, testing, and deploying an information system (Pavalkis & Nemuraite, 2013). It comprises of a series of steps that model the development and lifecycle of managing an application or software. SDLC model was developed to ease the development of complex and large systems. Previously software development was a one-man task since the programs were small and less complex. Today, the systems have grown both in complexity and in size, which necessitated for a structured method to manage the development process. SDLC can be used for software and hardware configurations. Different industries have different processes that they would use in their development. The need to have formal methodologies for managing and developing systems resulted in the creation of SDLC. The traditional SDLC consists of these phases' project planning, systems analysis, systems design, development, testing, deployment, and maintenance (Melville, 2010). Project planning is the first stage, and it comprises of the preliminary analysis, alternative solutions, budget, and recommendations. During this phase, the project is defined and goals established. Alternative solutions are proposed and analyzed to determine if there really is a need for the new system. Systems analysis or requirements definition refines the project goals and converts them into functions and operations. The end-user information needs are also analyzed to establish their specific needs. Requirements analysis is vital to ensure that no user is left out. This analysis will determine how the system is developed, and the reports required for its effective usage. Systems design phase describes the desired features and operations using screen layouts, process diagrams, and business rules. This is meant to provide a detailed simulation of the features and operations, which would make it easy for developers and users to understand. It is also at this stage that information flow is presented to aid in system development. Development phase is where the real code for the system is written. The code is developed using the defined features and processes, which ensures that the system meets the needs of the users.

Integration and testing will normally be conducted together. This is because all the implemented components have to be tested once they have been integrated into the system. This checks if the feature is working as expected. Combining all the components together in one environment offers the developers the opportunity to fine-tune the system. The developers will detect if there are any bugs or errors and check the systems interoperability. Deployment is the final phase of initial development (Cohen et al., 2010). During this phase, the software is placed in its live environment for running a business. The software is installed at the client's business, and the users are given the opportunity to interact with the system for the performance of their work activities. Maintenance is what happens after the software is deployed for the rest of its life. It involves making changes, corrections, additions, and moving to different computing platforms. This phase goes on forever and is quite vital.

SDLC predictive models

There are two approaches used for SDLC namely predictive and adaptive approach. The predictive approach operates on the assumption that all the stages of the project can be planned. This approach allows the developers to determine what they need in advance and plan. Predictive approaches insist on developing a system using the predetermined plan, and no deviations are allowed. There are two models of SDLC using the predictive approach waterfall and parallel.

In the waterfall model, each phase is completed in sequence. The results of the past phase are required or used in the next phase. This is a structured method of developing a system requiring a systematic flow of processes (Balaji & Murugaiyan, 2012). Once a stage has been finalized, there is no chance of returning and making amends to it because it would result in changes in all the other stages. Just like a natural waterfall it is quite difficult to return to a stage once it has been completed. There is no overlap of stages, as one stage should be completed before the next stage begins. The lack of overlap ensures that each stage is fully completed. Each stage deliverables are documented in hundreds of paper.

The advantages of using this approach are identification of requirements before programming begins. This is vital as it allows the programmers to plan early for all they will need during the project. This also offers them an opportunity to think wide and determine...

Planning all the way to the end gives the developers vast information that they can use before they begin the project. Any problems are anticipated in advance, and there are plans in place for mitigation. The other advantage is reduction of requirement changes during the project life cycle. Requirement changes can affect the timelines for any project. Any changes should be analyzed before they can be implemented into the system, which would eat up the project development timeline. Using the waterfall approach the number of changes is limited and quite difficult to implement.
The disadvantages of this approach are design should be specified completely before programming begins. This takes up time and resources that would otherwise be used for programming. There are situations when it is difficult to design the system completely without programming. The time taken between system proposal, and delivery is quite significant. The waterfall approach takes up more time than other SDLC approaches for a system to be delivered. The amount of documentation produced makes it hard to find all the relevant information. There is a possibility of overlooking some requirements in the documentation. Since the implementation is done long after the initial system proposal, the user is rarely prepared for the new system. Taking too long to deliver a system is discouraging to the users because they have been used to working without it, and they have adapted to not having the system. Once a proposal is made, the users expect system delivery to occur within a short period. The difficulty of returning to a past stage makes is quite expensive if the developers missed a vital requirement. The approach is not accommodative to business process or environment changes. Therefore, the amount of work required to implement any changes is immense. A single change taking place after the project has begun would require the developers to return to all the previous phases and implement this single change. This approach is no longer in use because of its disadvantages.

The parallel model was developed to overcome the limitation of having long delays from the analysis phase and system delivery (Mandal & Pal, 2013). The parallel approach does not require for the design and implementation to occur in sequence, but rather it requires for a general design and then division of the project into subprojects. The subprojects are developed in parallel, which reduces the time taken to develop the whole system. Having a general design ensures that the subprojects will have the same look and feel. Integration of project is done when all the subprojects are complete. Integration enables the subprojects to be brought together into one functional system ready for delivery to the users. Parallel development reduces the time taken for developing the system, which allows for quick delivery of the system.

The advantages of the parallel model are reducing the scheduled time for delivering the system. Developing all the parts of the system simultaneously does reduce the time for system delivery, which is beneficial to the users. Using a structured methodology allows for a consistency among the subprojects. Taking a short time to develop the system ensures there will not be any changes in the business environment, which might necessitate for system changes. Having reduced the timeframe for developing the system ensures the system is completed and implemented before any changes are necessary. This is beneficial to both the developers and the users.

Disadvantages include too much paper documentation like the waterfall approach. Like in the waterfall approach, this approach also suffers from having too much paper documentation, which does affect feature development. The likelihood of missing a vital feature is evident and will only be discovered when it is too late or after the system is implemented. The customer is not involved during the system development, which results in misunderstanding after the system is delivered. Involving the customer allows the developers to understand the customer requirements and seek clarifications early. The misunderstandings could result in the overhaul of the whole system, which will be quite costly. Developing a system in parallel means that individual subprojects will require integration later. The integration might fail to work requiring significant changes to accommodate a single integration. Design and development of some subprojects might be dependent on completion of others. If this occurs, the parallel development will not be possible, and the subprojects would have to wait for the completion of the other subproject.

References

Balaji, S., & Murugaiyan, M.S. (2012). Waterfall vs. v-model vs. Agile: A…