A system or software development life cycle (SDLC) is an approach for organizing the development of a project into phases and tasks from planning to the implementation and support of the product (Brewer & Dittman, 2018). Based on a survey in 1996, the Standish Group discovered that around 42% of corporate information system projects were canceled before completion (Dennis et al., 2009). Therefore, choosing a methodology that allows the completion and delivery of the project are necessary. In this article, I will focus on the popular SDLC methodologies that have been used in the past and the modern approach to building applications using Agile.
Software Development Life Cycle Methodologies
The SDLC methodologies could be divided into two large categories. The first category is the traditional or classical methodology which concentrates more on gathering all the requirements upfront before development and creating the product in phases (Brewer & Dittman, 2018). In addition, one of the main characteristics of this approach of SDLC is that there is a comprehensive review by the key stakeholders at the end of each phase (Brown et al., 2012). The approach for the SDLC is Agile. This approach values the relationship between customers and stakeholders with the team to deliver a product incrementally using sprints (Moreira, 2013). In the following sections, some common traditional and agile methods will be discussed.
Traditional SDLC Methodologies
The traditional SDLC methodologies covered here are waterfall, spiral model, and RAD model. Also, some of the pros and cons that they possess and when the model is best applicable.
Waterfall Model
The waterfall methodology is considered the first attempt by the IT industry to have a structure in the design and development of complex systems (Tayntor, 2014). The waterfall methodology consists of finishing each step before moving to the next step (Stephens, 2015). The phases of the waterfall model are planning, analysis, logical design, physical design, implementation, and maintenance (Valacich & George, 2020). Nevertheless, the steps change between teams and authors as the main point of this approach is that phases are done sequentially and there is no going back. For instance, other authors consider the phases of the waterfall as definition, construction, and implementation (Brown et al., 2012).
Some of the strengths of this model include:
- It is easy to understand and manage (Brewer & Dittman, 2018).
- It works well with large complex applications (Brewer & Dittman, 2018).
- It works when the team members are in different locations (Brewer & Dittman, 2018).
- It does not need great experience from team members (Brewer & Dittman, 2018).
The weaknesses of the waterfall that could affect the development of a project are:
- Change is very difficult to accommodate and implement (Brewer & Dittman, 2018).
- All the requirements must be known before starting the project (Brewer & Dittman, 2018).
- It does not allow the team to make changes to a previous phase (Brewer & Dittman, 2018).
- There is little communication between users, stakeholders, and the team (Brewer & Dittman, 2018).
The waterfall can work well for the following situations:
- All the requirements are known in advance, and they won’t change (Stephens, 2015).
- All high-risk items in the requirements are resolved (Stephens, 2015).
- There is enough time to do the work sequentially and the team has experience with the same or similar projects (Stephens, 2015).
Spiral Model
The spiral model was developed by Dr. Barry W. Boehm, and it is a risk-driven model that tries to address the issues of the waterfall model (Forsberg et al., 2005). The spiral model adds a rapid development potential to the waterfall approach by developing software in a series of evolutionary releases (Pressman, 2010). The name for this model is because it is seen as a spiral when developing a product and every revolution includes an enhancement to the previous version of the software (Pressman, 2010). The activities of the spiral model are defined by the engineering team so that when they complete a revolution, they can develop or add to the prototype (Pressman, 2010).
The pros of the spiral model are summarized as:
- It allows stakeholders to review the project and make go and no-go decisions (Stephens, 2015).
- It permits change unlike the waterfall model because, after one cycle, it can adopt the new changes in the news cycle (Stephens, 2015).
- The time estimates become more accurate over several cycles and the rest are removed from the project (Stephens, 2015).
- It is good for large and complex problems as it can deal with customer feedback (Brewer & Dittman, 2018).
- Early software release in the life cycle (Brewer & Dittman, 2018).
The cons of the spiral model include:
- It could be more expensive than the waterfall when implemented (Brewer & Dittman, 2018).
- The success of the project depends deeply on the risk analysis phase (Brewer & Dittman, 2018).
- The risk analysis requires very high expertise from the analyst (Brewer & Dittman, 2018).
- It is not well-suited for small projects (Brewer & Dittman, 2018).
The spiral model works well for the type of projects that the waterfall does but with the advantage that it also works for high-risk projects and projects that could change requirements during development (Stephens, 2015).
RAD Model
Rapid Application Development (RAD) is a methodology that emerged in the 1990s and it tries to address the weaknesses of the previous methodologies by modifying the SDLC phases to develop parts of the system quickly and release them to the users (Dennis et al., 2009). By this approach, the users can understand what the system does and how it does it while also providing feedback to the engineers on what to improve (Dennis et al., 2009). This method consists of four phases that are requirements planning, user design, construction, and cutover (Tilley & Rosenblatt, 2017). In addition, there is a continuous interaction between the user design phase and the construction phase (Tilley & Rosenblatt, 2017). The code is created interactively and incrementally while deemphasizing a lot of planning (Stephens, 2015). The cutover phase is very similar to the final task of the waterfall, and it includes data conversion, testing, and implementation of the new system compressed into one phase (Tilley & Rosenblatt, 2017).
The advantages of the RAD model are:
- The system can be developed quicker than the traditional approaches of the SDLC (Tilley & Rosenblatt, 2017).
- Having customers and stakeholders as active participants in the requirements definition reduces the chances of leaving important features of the system out (Tayntor, 2014).
- It encourages customer ownership as the users work alongside the team during the development and prototyping of the system (Hentzen, 2002).
- Allow testers to catch bugs earlier in the development of major functionality (Hentzen, 2002).
However, like with other methodologies, RAD has its flaws. As developers create a prototype of the system, users might think that the work is almost completed and expect the system earlier than planned (Hentzen, 2002).
The RAD methodology works well when the team includes developers and analysts with experience (Kendall & Kendall, 2011). In addition, it is preferred over previously mentioned models when the users are sophisticated and engaged with the project (Kendall & Kendall, 2011).
Agile Methodologies
Agile development refers to a software development approach that concentrates more on reacting quickly to changes in user requirements while delivering value to the customers via incremental product updates (Wasson, 2016). The agile methodologies are a reaction to the failed approach of the traditional SDLC models which concentrated more on gathering user requirements first and creating large documentation than actually delivering the product early and gathering feedback from actual users. Some of the most popular models based on agile principles are Scrum, Extreme Programming (XP), and Kanban.
Scrum
Scrum is an agile framework that helps teams to release increments of the product by using sprints and getting feedback from customers and stakeholders as early as possible (Rubin, 2013). It was developed by Ken Schwaber and Jeff Sutherland with the concept that software development is not a defined process and focuses more on empiricism (Brewer & Dittman, 2018). As described in the Scrum Guide, empiricism is based on the idea that knowledge comes from experience, and the decisions that need to be made during the project are based on what is observed (Mcgreal & Jocham, 2018). Also, Scrum does not have an official project manager role and the work of a project manager is distributed among the members of the team. The roles in Scrum are product owner which is the one who decides the priorities of the project based on the feedback received from stakeholders. The Scrum Master oversees and makes sure that the Scrum framework is implemented correctly and avoids issues that impede the developers to accomplish their work. Finally, the other role is the developer(s) who are the ones that create the increment or the deliverables of the project.
The advantages of Scrum include:
- The project is easier to manage (Brewer & Dittman, 2018).
- The roles and responsibilities of the team members are well defined which leaves less room for conflicts (Bonocore & Singhchawla, 2022).
- All the artifacts and progress of the project are visible to everyone (Brewer & Dittman, 2018).
- Active communication of everyone involved in the project (Brewer & Dittman, 2018).
- Progress is still made when requirements are not very clear (Brewer & Dittman, 2018).
There are some disadvantages of using Scrum are:
- It is more difficult to apply Scrum in very large teams. The teams need to be divided into groups of nine or fewer members (Bonocore & Singhchawla, 2022).
- The coordination of multiple Scrum teams on different projects is very complex (Bonocore & Singhchawla, 2022).
- It requires constant monitoring of the project from the quantitative and qualitative views (Brewer & Dittman, 2018).
Scrum works best in complex projects where requirements are not very clear because it lets the team produce the product while gathering feedback from the users and making sure that the changes and upgrades made to the product are worth doing (Rubin, 2013).
Extreme Programming
Extreme Programming or XP is about short development cycles and incremental planning that is concentrated on automated tests written by programmers to monitor the development process (Valacich et al., 2015). XP is also popular because it allows rapid response to change, and it has two radical ideas that are popular today: pair programming and test-driven development (O’Docherty, 2005). Pair programming refers to the use of two programmers working and interacting on the same code and the same computer to keep each other in check and deliver software following best practices (O’Docherty, 2005). Test-driven development is about creating the test that validates the code before coding, so the developer ensures that the code follows high-quality standards (O’Docherty, 2005).
The strengths of this model are:
- It makes the project more manageable (Brewer & Dittman, 2018).
- There is an improvement in team communication (Brewer & Dittman, 2018).
Some of the drawbacks include:
- Some programmers who used to work alone find it difficult to adapt to the pair programming approach (Stephens, 2015).
- The customer must be always available as it is the person that drives the XP project (Canty, 2015).
The XP model is well served when the project only has a small or medium team and when the requirements are changing rapidly or are vague (Cohen, 2010).
Kanban
Kanban in Japanese means story card and it is a continuous flow methodology for managing and developing products (Moreira, 2013). The main difference between Kanban and Scrum is that in Scrum, you have a sprint to develop parts of the overall requirements while in Kanban, there is a continuous pull of units of work to be developed (Stephens, 2015).
While there are sprints in Scrum that all allow the teams to plan and prioritize items in the product backlog, in Kanban developers just pull the item with the highest priority from the backlog one at that time as soon as they finish their prior work (Stephens, 2015).
Some of the benefits of Kanban is that it limits the “work in progress” so developers can maximize the output of the team (Hall, 2017). Also, limiting the “work in progress” protects the team against change by lowering the sunken cost if there is something to be modified because it will be changed as soon as possible (Hall, 2017).
Traditional vs Agile Methodologies
Agile methodologies differ front the traditional SDLC in prioritizing the customer and expecting changes at any time so it can accommodate new requirements (Kale & Manza, 2013). Instead of gathering all the requirements, the system needs as the first step, agile methodologies just gather enough information to get started and show something to the customers. This lets the customer understand the direction of the application and provide feedback to correct any misunderstanding as early as possible. Therefore, the methodology requires customer involvement while developing and maintaining the system to provide timely feedback (Bansal, 2021). If the customer is not available to answer questions, a more traditional SDLC methodology is more appropriate.
Usually, the market cannot wait long for a system to be delivered which is the reason most applications are built today using agile methodologies. Getting feedback from the market and delivering value to the customers is the only way to know if what it is built is correct and what users would use (Mcgreal & Jocham, 2018). Everything leading up to releasing to customers could be considered an investment and the more it is released as early as possible, the more value it is sent to customers and more feedback is gathered to improve the application (Mcgreal & Jocham, 2018).
A good example of releasing early to get feedback from the market and being able to adapt to the users’ needs is Microsoft with Word. Microsoft released early to the market Microsoft 1.0 and Word 2.0 even though they were bugs in the system (Love, 2017). However, Microsoft was able to listen to customers and gather all the feedback necessary to develop Word 3.0 which dethroned WordPerfect as the leading word processor in 1992 (Love, 2017). Back then, there were no Agile methodologies implemented anywhere. However, Microsoft understood the need to go to market fast to learn from the users. Agile methodologies allow you to get to the market earlier than the traditional methodologies while avoiding the system being riddled with bugs and defects.
Selecting the Right Methodology by Using a Decision Support Matrix
Not all projects are the same and the success of the project could be determined by the methodology and model used for the development of the system. A project that iteratively allows you to release functionality is a good fit for agile methodologies (Harrin, 2018). However, agile methodologies won’t work for projects that need to be laboriously planned, a more traditional SDLC approach might be needed (Harrin, 2018).
A decision support matrix could help organizations on selecting the right methodology for their projects. Organizations should have a customized decision support matrix based on the resources available and the types of projects that they develop or manage.
Conclusion
Lastly, selecting the right SDLC methodology is almost as important as the project itself because the methodology selected will be responsible for the delivery of the project on time and under budget while meeting the requirements set by the users. If the requirements are not expected to change over time, a traditional software development life cycle like the waterfall, spiral, and RAD model could be useful because they allow developers to gather everything up front. Nevertheless, if the requirements are not clear or unknown at first, an agile approach will help the team understand the needs of the users while delivering incremental updates and gathering feedback from the market. Thus, both methodologies are useful, but it really depends on the types of projects.
References
Bansal, A. (2021). Computational Intelligence Techniques and their Applications to Software Engineering Problems. CRC Press, Taylor & Francis Group.
Bonocore, G., & Singhchawla, A. (2022). Hands-On Software Architecture with Java: Learn Key Architectural Techniques and Strategies to Design Efficient and Elegant Java Applications. Packt Publishing.
Brewer, J. L., & Dittman, K. C. (2018). Methods of IT Project Management (3rd ed.). Purdue University Press.
Brown, C. V., Daniel Wesley Dehayes, Hoffer, J. A., E Wainright Martin, & Perkins, W. C. (2012). Managing Information Technology (7th ed.). Prentice-Hall/Pearson.
Canty, D. (2015). Agile for Project Managers. CRC Press.
Cohen, G. (2010). Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams. Super Star Press.
Dennis, A., Wixom, B. H., & Tegarden, D. (2009). Systems Analysis Design with UML version 2.0: An Object-Oriented Approach (3rd ed.). John Wiley & Sons, Inc.
Forsberg, K., Mooz, H., & Cotterman, H. (2005). Visualizing Project Management: Models and Frameworks for Mastering Complex Systems (3rd ed.). John Wiley & Sons.
Hall, G. M. (2017). Adaptive Code: Agile Coding with Design Patterns and SOLID Principles. Microsoft Press.
Harrin, E. (2018). Project Manager: Careers in IT Project Management. Bcs, Learning & Development Ltd.
Hentzen, W. (2002). The Software Developer’s Guide (3rd ed.). Hentzenwerke Publishing.
Kale, K. V., & Manza, R. R. (2013). Advances in Computer Vision and Information Technology. I.K. International Publishing House Pvt. Limited.
Kendall, K. E., & Kendall, J. E. (2011). Systems Analysis and Design (8th ed.). Pearson Prentice Hall.
Love, B. A. (2017). IT Project Management A Geek’s Guide to Leadership. Taylor & Francis Group.
Mcgreal, D., & Jocham, R. (2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley.
Moreira, M. (2013). Being Agile: Your Roadmap to Successful Adoption of Agile. Apress.
O’Docherty, M. (2005). Object-Oriented Analysis and Design: Understanding System Development with UML 2.0. John Wiley & Sons.
Pressman, R. S. (2010). Software Engineering: A Practitioner’s Approach. Mcgraw-Hill Higher Education.
Rubin, K. S. (2013). Essential Scrum: A Practical Guide to the Most Popular Agile Process. Addison-Wesley.
Stephens, R. (2015). Beginning Software Engineering. John Wiley & Sons.
Tayntor, C. B. (2014). Six Sigma Software Development. CRC Press.
Tilley, S. R., & Rosenblatt, H. J. (2017). Systems Analysis and Design (11th ed.). Langara College.
Valacich, J. S., & George, J. F. (2020). Modern Systems Analysis and Design (9th ed.). Pearson Education, Inc.
Valacich, J. S., George, J. F., & Hoffer, J. A. (2015). Essentials of Systems Analysis and Design. Pearson.
Wasson, C. S. (2016). System Analysis, Design, and Development Concepts, Principles, and Practices. Somerset John Wiley & Sons, Incorporated.
