The Basics of the Software Development Life Cycle

The initiation phase of the project begins when a business need is identified regarding a problem or opportunity. Once the business analyst analyzes and defines the problem or opportunity, a project manager may be appointed to evaluate the feasibility of the solution. If the solution is identified as doable, the project manager will then present the estimate of cost and schedule of the new solution, based on its high-level requirements in terms of features and functionalities. The initiation of a system (or a project) begins when the business need or opportunity is identified. A project manager is appointed to manage the project. This business need is documented in a concept proposal. After the concept proposal is approved, the system concept development phase begins.

When business needs are approved, the solution enters into the next phase to define and detail the solution scope. During this phase, the business analyst, project manager, and stakeholders define the boundaries and review the project for further viability and suitability. This provides more insights into high-level features, the volume of work, and the time and budget required for realizing the solution in vision and scope documents.

 

Once the rational and realistic solution scope, budget, and schedules are prepared, they have later presented to the sponsor to avail the approval for the solution. The business analyst, project manager, and stakeholders need to justify the investment in the solution by providing the detailed calculations on profitability and return on investment (ROI, payback period, break-even period, etc.)

 

Once the cost vs. benefit (Business Case) is found satisfactory, the sponsor may support solution development with or without any pre-conditions.

Project planning starts once the project manager approves funding and solution in the form of a high-level solution (business need and solution vision, and scope documents).

 

While the business analyst is busy in requirement analysis, the project manager works on resource management. It includes employees (with skills-sets) and plans for scaling-up timelines, IT resources (hardware, software, database, networking, communication channel, etc.), and other requirements to kick start solution development.

 

The project manager may need to check if any particular tool or specialized software is required for developing, testing, and deploying the solution. A detailed analysis is carried out for the legal requirements for managing data related to customers and defining the employee role with the help of the business analyst. Additionally, the project manager needs to check if any certificate and accreditation or vulnerability testing is required to validate the quality of the proposed solution.

 

The project manager will review the plan to ensure that the required capability is delivered on time and within budget. Towards that end, comprehensive project resources, schedules, activities, tools, and other data will be reviewed along with other technical team members.

In project management, the requirement analysis phase begins once the solution is completely defined, i.e., upon successful completion of documentation, presentation, scoping, verification, and validation of stakeholders’ requirements. These requirements can be structured and documented in a formal template such as a business requirement document (BRD) or a product roadmap. This template is represented as the solution definition. Furthermore, the defined solution is verified and validated against the organization’s needs and capability before it enters into the requirement analysis phase.

 

At the requirement analysis phase, the business analyst prioritizes requirements on various criteria. After prioritization of requirements, each one is fully defined in terms of functional (functionality and features), non-functional (quality requirements such as system performance, security, reliability, and maintainability), and constraints and data specifications. The requirements are further modeled using various techniques for explaining it to reduce any ambiguity. These techniques could be process or activity diagrams, state diagrams, data modeling or class diagrams, entity-relationship (E-R) diagrams, etc., as mentioned in the sections on business analysis techniques.

 

Once requirements are defined in detail as per the stakeholders (business and technical), the system design needs to proceed.

 

Each requirement must be verified against the basic criteria, i.e., to check if every requirement is measurable, testable, doable, consistent, correct, correlated, and concise to proceed. All these requirements are traced back to the original business need and solution scope to ensure that every requirement is in-line with the business need. If any requirement is found to be not related or out of scope, it is subjected to further analysis.

This phase is the “carrying out” stage, i.e. when the actual execution of the project starts. This phase begins only after the solution is defined through requirements and models, and verified and validated as viable, doable, profitable, and capable of being successfully deployed into the user community. If there is more than one solution option, each option is fully analyzed, ranked, and then selected.

 

Once the solution is defined, the project manager and team identify the physical characteristics of the system. These physical characteristics of the system and subsystem, along with the processes allocated to them, and their input and output are specified. Further, the detailed designs about the system and all related subsystems along with their characteristics are used to create a detailed structure of the system. Each sub-system is partitioned into one or more design units, modules, or components for the purpose of development, with detailed logical specifications prepared for each solution module. Everything requiring user inputs and other related approvals must be recorded after completion of the process of due diligence.

 

The architectural diagrams are prepared, presented, and approved for the development work.

Once the sub-system and modules are identified and defined, the project release is planned based on requirements, priority, relevance, and resource availability. Sometimes stakeholders or business priorities are specified while planning for release. The software is built in a series of releases, iterations, or modules. It simply means the solution is built through an incremental process (software coding, communication, and hardware), unit-by-unit. Each of these units could be a small functionality, process, or piece of code. Each unit is systematically tested, integrated, and retested (regression testing) by the software engineer. Once the software is tested, it is assembled with hardware and retested for the entire module.

Once the execution level solution is built with one or more modules, those modules are integrated and retested successfully using regression testing before being shifted to testing or sandbox environments.

 

If additional work is related to integration, the testing is required before transferring it into the sandbox environment; it must be completed at this stage. The integrated solution must be presented, verified, and validated by the technical team on business, technical, and quality-related criteria. The quality-related criteria such as software quality defined by the internal or external entities are checked.

The testing team must ensure that the module is tested against the business, technical, and quality-related criteria that are specified in functional requirement documents using various testing methods. Any bugs or issues that are identified must be reported, fixed, and validated for quality thereafter.

 

The business analyst plans and conducts the user acceptance testing (UAT), and provides the results to the technical team. Therefore the technical team can continue to work if any requirement is either unworkable or not in-line with the requirements specified in functional requirement documents. Issues, fixes, and related results in UAT are verified and documented.

 

Once the testing team and users approve the solution, the system undergoes a certification and accreditation process.

Before deploying the solution into the user community (operations or production environment), the pre-deployment requirements (also known as transition requirements) are defined, developed, and integrated with the solution.

 

The implementation phase continues until the solution settles down in the user community. During the settling-down phase, the reported bugs and issues are fixed, tested, and validated. This is to ensure delivering a better-quality solution and supporting a smooth operation in the future. Typically, it may take up to three months for the solution to settle down in the user community, depending on the solution and its complexity.

 

The implementation phase is complete once the solution becomes operational upon confirmation that it is fully functional and free of bugs, defects, or any other issues.

This may be referred to as the “closing” phase, and it is ensured that temporary activities related to the project are closed systematically. The business analyst, along with the project manager, completes the post-closeout project documentations. The stakeholders review these post-closeout documents and sign them off to formally close the project. These post-closeout documents are maintained in the project library for future reference.

The operations and maintenance phases are monitored on an ongoing basis for its performance as mentioned in the business requirement documents.

 

The solution is enriched and enhanced to make it effective and efficient on a continuous basis so long as the solution stays in the user community or operations. These enhancements come from high-priority requirements categorized as out-of-scope or low-priority, with new changes being required to accommodate or replace due to an increase in capability to accommodate new situations or demands.

 

The change or new enhancement may enter into the planning phase, depending on the size, risk, and complexity of the initiative. Once it enters into the planning phase, it goes through every phase mentioned until it becomes operational i.e. completes the cycle. The process of enrichment and enhancement continues as long as the system can adapt to the organization’s needs on a continuous basis. Once the solution becomes obsolete due to outdated technology or business, it can either be decommissioned or terminated in an orderly manner.

Decommissioning implies the termination phase that is carried out in an orderly manner. It requires fulfilling organizational, local, and federal standards to preserve important data, information, and documentation. If required, the data retained can be easily retrieved and utilized in the future. Therefore, the data must be organized and structured for archiving. Proper planning for structuring, archiving, accessing, and documentation is required. The data is stored as per the organization’s standards regarding information management systems, regulations, and policies.

 

The business analyst must perform a return on investment (ROI) again to validate the estimated business case against the original business case.

 

The ROI, business case validation, and other data related to technical and business issues can be sent to a project library for archival under the “lessons learned” section for future reference. The data regarding unique issues or situations related to risk management, change management, and scope management also needs to be archived under the same category.

In this article, we have learned in detail the different phases in the software development lifecycle. I hope it was very useful, and please try to implement these phases in your projects as well. Please share your feedback in the comments section.