SDLC methods

The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. SDLC can apply to technical and non-technical systems. In most use cases, a system is an IT technology such as hardware and software. Project and program managers typically take part in SDLC, along with system and software engineers, development teams, and end-users.

Every hardware or software system will go through a development process which can be thought of as an iterative process with multiple steps. SDLC is used to give a rigid structure and framework to define the phases and steps involved in the development of a system.

SDLC is also an abbreviation for Synchronous Data Link Control and software development life cycle. Software development life cycle is a very similar process to the systems development life cycle, but it focuses exclusively on the development life cycle of software.

The SDLC methodology focuses on the following phases of software development:

• Planning
• Software design such as architectural design
• Software development
• Testing
• Deployment

1. plan

Planning usually happens after there is an innovation or initiation that comes up from a group of business end-user or a sponsor who identify a need or an opportunity. within the planning stage, the scope or boundary of concepts is defined. product feasibility study in financial, operational, and technical areas will be conducted by the senior members of the team with input from the business users. Quality Assurance and Risk management plans are also prepared at the planning stage to minimize any unpredictable risks. Business Case Documentation (BSD) should be ready at this stage to summarize all the ideas and have a holistic view of the full plan.

2. Design

Product design is started with a clear definition of requirements. Software Requirement Specification (SRS) document which consists of all the details of the product requirements should be approved by the clients or the customers before product design begins. With SRS in hands, more than one design of the product architecture will be proposed based on their requirements in SRS. They will be documented in a Design Document Specification (DDS) by the junior members of the team and passed to the senior members, projects take holders for review. DDS will be evaluated based on various criteria but not limited to budget, time, user-friendliness, risk, integration, etc.

3. Develop

After the best or the most appropriate design has been selected, implementation starts immediately. Programmers should develop the software according to the DDS and at the same time follow the coding standards defined by the companies closely. Programming tools should be limited to those provided by the company as well to ensure all programmers can align their works. Functional Specification (FS) should be written by programmers to record all the functions that are provided at a technical level.

4. Test

Software testing should be conducted at all stages as a substrate. Nonetheless, two (2) major ones should be done by programmers, end-users, and quality assurance experts. The reason is that programmers know the best of how the program works and therefore they can identify the most vulnerable areas of the software. End-users would pay more attention to their routine tasks which can help to ensure the software can fulfill the requirements. Last but not least, quality control experts examine the software as a whole from various perspectives such as architecture, security, integration with other systems, etc. As a result, a few different types of test plans should be prepared for the three groups of testers to conduct at the test stage.

5. Deploy

The first thing to do at the deployment stage is to verify all the test cases were run to ensure successful software execution, comprehensiveness, and correctness. A final decision should be made if the software should be deployed to the production environment and therefore approval should be seeking from management at this stage. The deployment Plan(DP) should be well-defined and approved to carry out any changes that are going to make. GuidelinedocumentationsshouldalsobepreparedsuchasInstallationguide, administration guide, and user guide. Support team members should be ready to answer all sorts of questions regarding the software. Finally, Contingency Plans (CP) should be created according to the finalized software. For newly implemented software, a common solutions post posing the software launch day to redo and retest. For a running software, very likely rolling back to the previous version or post posing the launch day to fix the defects would be the choices.

SDLC Models

There are various software development life cycle models defined and designed which are followed during the software development process. These models are also referred to as Software Development Process Models”. Each process model follows a Series of steps unique to its type to ensure success in the process of software development. Following are the most important and popular SDLC models followed in the industry:

1. Waterfall Model
2. Prototyping
3. Iterative Model
4. Relational unified process
5. Timeboxing model
6. Extreme programming
7. Agile process
8. Waterfall Model:

The waterfall model is an example of a Sequential model. In this model, the software development activity is divided into different phases and each phase consists of a series of tasks and has different objectives.

It is divided into phases and the output of one phase becomes the input of the next phase. It is mandatory for a phase to be completed before the next phase starts. In short, there is no overlapping in the Waterfall model.

In the waterfall, the development of one phase starts only when the previous phase is complete. Because of this nature, each phase of the waterfall model is quite precise well defined. Since the phases fall from the higher level to the lower level, like a waterfall, It’s named the waterfall model.

Advantages of using the Waterfall model :

• Simple and easy to understand and use.
• For smaller projects, waterfall model works well and yields the appropriate results.
• Since the phases are rigid and precise, one phase is done one at a time, it is easy to maintain.
• The entry and exit criteria are well defined, so it is easy and systematic to proceed with quality. 
• Results are well documented.

Disadvantages of using the Waterfall model:

• Cannot adopt the changes in requirements 
• It becomes very difficult to move back to the phase. For example, if the application has now moved to the testing stage and there is a change in requirement, It becomes difficult to go back and change it. 
• Delivery of the final product is late as there is no prototype which is demonstrated intermediately. 
• For bigger and complex projects, this model is not good as a risk factor is higher. 
• Not suitable for the projects where requirements are changed frequently.  Does not work for long and ongoing projects. 
• Since the testing is done at a later stage, it does not allow identifying the challenges and risks in the earlier phase so the risk mitigation strategy is difficult to prepare.

2. Prototyping

The basic idea in the Prototype model is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. 

This prototype is developed based on the currently known requirements. The prototype model is a software development model. By using this prototype, the client can get an “actual feel” of the system, since the interactions with the prototype can enable the client to better understand the requirements of the desired system. 

Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help to determine the requirements. 

The prototype is usually not complete systems and many of the details are not built in the prototype. The goal is to provide a system with overall functionality.

Advantages of Prototype model: 

• Users are actively involved in the development 
• Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed. 
• Errors can be detected much earlier. 
• Quicker user feedback is available leading to better solutions. 
• Missing functionality can be identified easily.

Disadvantages of Prototype model: 

• Leads to implementing and then repairing way of building systems. 
• Practically, this methodology may increase the complexity of the system as the scope of the system may expand beyond original plans.

3. Iterative Model

An iterative life cycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model.

Advantages of the Iterative model: 

• In the iterative model, we can only create a high-level design of the application before we actually begin to build the product and define the design solution for the entire product. Later on, we can design and built a skeleton version of that, and then evolved the design based on what had been built.
• In the iterative model, we are building and improving the product step by step. Hence we can track the defects at the early stages. This avoids the downward flow of the defects. 
• In the iterative model, we can get reliable user feedback. When presenting sketches and blueprints of the product to users for their feedback, we are effectively asking them to imagine how the product will work. 
• In the iterative model, less time is spent on documenting, and more time is given to design.

Disadvantages of Iterative model: 

• Each phase of an iteration is rigid with no overlaps 
• A costly system architecture or design issues may arise because not all requirements are gathered up front for the entire lifecycle.

4. Relational unified process(RUP)

RUP Stands for “Rational Unified Process.” RUP is a software development process from Rational, a division of IBM. It divides the development process into four distinct phases that each involve business modeling, analysis and design, implementation, testing, and deployment.

The four phases are:

1. Inception — The idea for the project is stated. The development team determines if the project is worth pursuing and what resources will be needed.
2. Elaboration — The project’s architecture and required resources are further evaluated. Developers consider possible applications of the software and costs associated with the development.
3. Construction — The project is developed and completed. The software is designed, written, and tested.
4. Transition — The software is released to the public. Final adjustments or updates are made based on feedback from end-users.

The RUP development methodology provides a structured way for companies to envision create software programs. Since it provides a specific plan for each step of the development process, it helps prevent resources from being wasted and reduces unexpected development costs.

5. Timeboxing model 

In the time boxing model, development is done iteratively as in the iterative enhancement model. However, in the timeboxing model, each iteration is done in a timebox of fixed duration. The functionality to be developed is adjusted to fit the duration of the timebox. Moreover, each timebox is divided into a sequence of fixed stages where each stage performs a clearly defined task (analysis, implementation, and deployment) that can be done independently. This model also requires that the time duration of each stage is approximately equal so that the pipelining concept is employed to have a reduction in development time and product releases. 

There is a dedicated team for each stage so that the work can be done in pipelining. Thus, stages should be chosen in such a way that each stage performs some logical unit of work that becomes the input for the next stage.

In addition to the advantages of the iterative model, the time boxing model has some other advantages too. Various advantages and disadvantages associated with the timeboxing model are listed in Table.

Advantages

• Speeds up the development process and shortens the delivery time
• Well suited to develop projects with a number of features in a short time period.

Disadvantages

• Project management becomes more complex.
• Not suited to projects in which entire development work cannot be divided into multiple iterations of almost, equal duration.

6. Agile process Model

The agile development model is also a type of Incremental model. Software is developed in incremental, rapid cycles. This results in small incremental releases with each release building on previous functionality. Each release is thoroughly tested to ensure software quality is maintained. It is used for time-critical applications. Extreme Programming (XP) is currently one of the most well known agile development life cycle model.

Advantages of the Agile model: 

• Customer satisfaction by rapid, continuous delivery of useful software. 
• People and interactions are emphasized rather than process and tools. Customers, developers, and testers constantly interact with each other. 
• Working software is delivered frequently (weeks rather than months). 
• A face-to-face conversation is the best form of communication.
• Close, daily cooperation between business people and developers. 
• Continuous attention to technical excellence and good design. 
• Regular adaptation to changing circumstances. 
• Even late changes in requirements are welcomed

Disadvantages of the Agile model: 

• In the case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle. 
• There is a lack of emphasis on necessary designing and documentation. 
• The project can easily get taken off track if the customer representative is not clear what final outcome that they want. 
• Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers unless combined with experienced resources.