Software development lifecycle models have different strategies and methodologies for the software development process and I wrote about the different types of development models, please review this article for more information, we also discussed how to select the most suitable model based on your project context.
Regardless, what model you have selected, these models are sharing mostly the same development phases with different arrangements, a more or a less phase. Furthermore, they can be implemented in an iterative and incremental model.
In this article, we will discuss the most common phases across all SDLC models. I will add other articles to discuss each phase in details 🙂
1- Requirements elicitation
Requirements elicitation is the practice of collecting the requirements of a system from users, customers, and other stakeholders. The practice is also sometimes referred to as “requirement gathering“
The common issue of software engineers now that they use requirement gathering as a phase name, while in the practice, requirements elicitations is not only a process of collecting requirements, it has a lot of techniques and required skills to extract and generate the requirements, for example, observations, workshops, brainstorming and making prototypes and analyze the feedback.
At this phase, we define the requirements which will shape the software regardless if the process model itself. Moreover, we assume here that there is the scope definition has been done and the business case for why we need to develop and implement this software.
It is a common fact now that most of the software projects fail because of the requirement elicitation phase and that requirements are unclear, unprioritized, incomplete, unreflective of business goals and objectives.
2- Architecture and Design
System design is the process of defining the architecture, modules, interfaces, and data for a system to satisfy specified requirements.
Software design usually involves problem-solving and planning a software solution. This includes both a low-level component and algorithm design and a high-level, architecture design.
Software design is depending on the business requirements and architecture design decisions have been taken, in this regards it is very important to define the requirements well or you will have a failure or not agile design. At this phase, you continue analyzing the requirements and you may need other iterations for requirements refinement and changes.
The design phase has a lot of design disciplines, like data design, User interaction and experience design, process design, and others.
3- Construction
This is considered the longest phase as we turn the requirements and design elements to actual code.
This is also known as coding or building or developing phase. It is known as implementation phase at most of Software engineering blogs, while it may be correct from developers perspective not from the overall process perspective as we will see that the implementation phase has different activities. do you agree?
Similarly to other phases, The construction phase can be done in an iterative way to have early business value to the customer. Moreover, we can back again to design and refine requirements as well, while this will depend mainly on the SDLC model selected.
4- Testing
Testing has a life cycle by its own know as Software testing life cycle STLC and it is called also verifications and validation phase or stabilizing phase, as we ensure that we are doing things right according to the specifications and we are doing the right things from the customer perspective.
In this phase, we make all types of testing, for example, unit testing, integration testing, quality attributes testing, and others.
Furthermore, it is an iterative process and always there is a feedback loop to other phases to fix the bugs and issues found during this test. And it has a lot of techniques to calculate the required test cases and how to ensure an acceptable test coverage.
5- Deployment
The main goal of the Deploying Phase is to place the solution into a production environment. Supporting goals include deploying the solution technology and components, stabilizing the deployment, and transitioning the project to operations and support.
Deployment can be iterative as well and need continues testing to ensure that software functionalities are working correctly in the production environment. Currently, most of the startups use a continuous delivery and continuous integration approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software faster and more frequently.
Deployment has different approaches as well, we should deploy first in staging environment especially in critical projects, which simulates the production environment and we continue performing our testing activities and validation process based on this environment.
6- Implementation
The Implementation Phase has a lot of supporting activities include training end-users and administration, The software will need observations and smart detections of issues and bugs which we could not detect during the previous phases. The implementation phase also may include the deployment phase as the main activity and change management process for users who will use the software which is a huge challenge for software and IT project success.
7- Operation and Maintenance
The purpose of the Operations and Maintenance Phase is to ensure that the information system is fully functional and performs optimally until the system reaches its end of life.
In this phase, the software become one of the core components of the organization baseline architecture and users start to use the software to benefit from its functionalities and the business values it delivers for them.
The operation phase also can be merged with the implementation phase activities. During this phase, some issues and bugs may be discovered and it is important to solve them to ensure business continuity.
Now, we hear about DevOps and how the roles of developers and operation support engineers are merged together to achieve the continuous delivery approach and establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.
8- Retirement
This phase is not common in the development process, and it is neglected usually. The goal of the Retirement Phase is the removal of a software release from production, it is also known as system decommissioning or system sunsetting. The retirement of systems is a serious issue faced by many enterprises today as legacy systems are removed and replaced by new systems. You must strive to complete this effort with minimal impact on business operations and you need to assess the other solutions are depending on this software. A software is retired for several reasons:
- The software is being replaced.
- The software is no longer to be supported or obsolete.
- The software no longer supports the current business model.
- The system is redundant.
- The system has become obsolete.
You can always add your findings and notes in the comments section below 🙂
References
- Chemuturi, M. (2012). Elicitation and Gathering of Requirements. In Requirements Engineering and Management for Software Development Projects (pp. 33–54).
- Gomaa, H. (2011). Software Life Cycle Models and Processes. In Software Modeling and Design: UML, Use Cases, Patterns, and Software Architectures (pp. 29-44). Cambridge: Cambridge University Press. doi:10.1017/CBO9780511779183.005
- Software testing. (2017, June 09). Retrieved June 12, 2017, from https://en.wikipedia.org/wiki/Software_testing
- Phase 8: Implementation – COTS Multiple Release Project. (n.d.). Retrieved June 12, 2017, from http://doit.maryland.gov/SDLC/COTS/Pages/Phase08Multiple.aspx
- CONSTRUCT PHASE. (n.d.). Retrieved June 12, 2017, from https://www.lifecyclestep.com/open/430.0CONSTRUCTPHASE.htm
- Chapter 1: Deploying Phase. (n.d.). Retrieved June 12, 2017, from https://technet.microsoft.com/en-us/library/bb496997.aspx
- Application retirement. (2017, March 14). Retrieved June 12, 2017, from https://en.wikipedia.org/wiki/Application_retirement
- B. P. (n.d.). 5 Reasons Software Projects Fail. Retrieved June 13, 2017, from http://www.seilevel.com/requirements/5-reasons-software-projects-fail-hint-its-often-due-to-incomplete-incorrect-requirements
- List of failed and over budget custom software projects. (2017, June 01). Retrieved June 12, 2017, from https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects
Help to do more!
The content you read is available for free. If you’ve liked any of the articles at this site, please take a second to help us write more and more articles based on real experiences and maintain them for you and others. Your support will make it possible for us.
$10.00
ThankU Sir .It helped me..
Thanks for putting this together!
My son has been taking a class where they learn how to develop their own software, and it made me really curious about how it is done. That is great that they have a phase where you define the requirements of the software. It is almost like building a home! You have to have the framework done first. That’s really cool! Thank you for all the great information!
I’m glad for that and thank you for your comment
thank you so much sir..
Anytime 😉