Flowchart for Choosing the Optimal Software Development Methodology

Introduction

How to choose a methodology? Often, when it is necessary to make a decision on the choice of methodology in the head, there is too much heterogeneous information and it is hard to understand exactly what is best for the project. In this article, I present a flowchart for choosing the optimal methodology, as a kind of hint that allows you to draw attention to some of the most important aspects.




First of all I want to note that there is no universal set of conditions for all situations when choosing one or another methodology. In each case, you should focus on the specifics of your project. This block diagram will only outline the main aspects and allow you to recall the features of the main methodologies. In no case do I call to treat it as the only correct guide for choosing a methodology. Moreover, you should not extend it to such complex projects as the creation of operating systems, aircraft avionics, modeling of nuclear reactions.
')
Secondly, choosing a methodology, do not blindly follow it. Often it is necessary to “finish” it, adapting it to your project. Something can be thrown out, something to add from other methodologies, to bring something of our own. For example, no one bothers you to use this practice as pair programming in a waterfall model, if it benefits you. On Habré there is an excellent article on the adaptation of Skram and Kanban to a specific project, which illustrates this principle well.

In the next chapter I will very briefly talk about the methodologies and models of the life cycle mentioned in the article for those who hear about them for the first time. More details about each of them can be found in Wikipedia. If you already know them, you can safely move on to Chapter 2: “Analysis of the flowchart”.

1. Brief Description

The life cycle model is a general description of how the development process proceeds.

Methodology - a more detailed set of rules, practices and principles, as a way to implement a particular model. For example, the Scrum methodology implements an iterative development model.

The process framework is, roughly speaking, a methodology containing a large number of rules, but in which it is not necessary to use them all, but you can choose only what you need and build your development process. They have in their composition special applications that allow you to view and edit rules. Examples: RUP, EssUp.

Cascade model (or waterfall model, Waterfall) - characterized by the fact that the stages of development, such as: analysis, design, implementation, testing, go after each other. Allows you to quickly create a system without additional overhead costs for the organization of the development process. However, it works only when the requirements are stable and do not change during the development, because we immediately describe all the requirements, and then immediately design the entire system.

V-Model - invented in Germany and the United States, as a way to improve the cascade model for use in government projects. V-Model has the specifics of projects for state bodies: fixed requirements, cost and time. The difference is that the analysis and design stage is related to the testing phase. For example, during the analysis of requirements, testing approaches are studied at the same time, during the design of the system architecture, high-level plans and test scripts are developed, during the design of the system components, methods for testing components and their interaction are developed, test scripts are created, utilities are written that help in testing, instructions, scripts, etc. All this helps to better understand the requirements and design the system. However, here, as well as in the cascade model, it is undesirable that requirements change during development.

Spiral model (Spiral) - focused on projects in which there are serious risks. Development is presented in the form of a spiral. Each turn of the spiral is an iteration. The coil of a spiral consists of four stages: planning, risk analysis, development, evaluation by the customer. At the end of each iteration, it is decided whether to continue the project. A characteristic feature is that at the stage of risk analysis, prototypes, concepts, models are created that are designed to resolve the risk at an early stage. The farther the spiral movement, the more product development and fewer prototypes and concepts. A typical application of this model is research projects. It is a very expensive model, and is not justified in systems where risks are minor.

Iterative model - focused on projects where the requirements may change in the course of development. The project consists of iterations (from 1-2 to 6 weeks). Each iteration may include the stage of analysis, design, implementation, testing. It has a large overhead on the organization of the process than the cascade model, but the cost of correcting errors depending on the duration of the project is not so high. The following methodologies implement an iterative model: Scrum, XP, partly Kanban.

Scrum Methodology - The iteration is called a sprint. The team consists of 3 roles: the product owner (customer representative), the scrum master (following the process), the rest of the team members. Sprint begins with a planning rally, when the team selects and distributes tasks for the iteration, forming a backlog of sprints. The sprint ends with a sprint review where a product is shown and a sprint retrospective rally is held to discuss improvements. 15-minute scrum meetings are held daily.

Extreme Programming Methodology (XP) - consists of 12 practices: pair programming, development through testing, refactoring, simple architecture, collective code ownership, continuous integration, customer in a team, frequent releases, planning game, 40-hour work week, coding standards , system metaphor. Be sure to use all 12 practices.

Kanban Methodology (Kanban) - task pipeline. There are only 3 rules: visualization of the development process using kanban boards, a limit on the number of tasks at each stage, constant measurement of team productivity and improvements.

The RAD (Rapid Application Development) methodology is focused on the rapid development of an application, iteratively, with the simplest architecture, minimal process costs, maximally using ready-made components and powerful tools. Has a limit on the duration of the project - 60-90 days. I like the analogy with cakes from convenience foods. So, RAD - when you need to quickly make a pie of ready-made components.

2. Analysis of flowcharts

Startups are characterized by the fact that there, especially in the initial period, everything is built on enthusiasm. Not always people work 8 hours a day. If they impose some kind of methodology and put it in a certain framework, then either all their enthusiasm will die out or no one will follow the rules. For example, it is rather silly to expect that the initiator of a startup will come in the morning on time to a scrum-rally, after a stormy night of coding. In the future, when everything is stabilized, you can proceed to the use of a suitable methodology.



Every project has risks. However, in this case, the risks are so serious that it is not known in advance whether it will be possible to implement the system at all. If such risks are present, then, most likely, you will begin development with prototypes, concepts, models, etc. to find out the fundamental possibility of our plans. In this case, the spiral model will be the best model for you. A typical example of this model is research projects. But only research projects application of this model is not limited.

An example from real practice in the field of retail: we needed to develop a mobile application that had to actively interact with certain equipment via Bluetooth. These were readers of various cards, various types of printers and barcode scanners. We did not know whether it was possible to do this on a mobile platform at all. Therefore, we started with prototypes and concepts, in which we tried to figure out the fundamental possibility of interaction with equipment and existing limitations. Then we met with the customer, demonstrated what we had and discussed workarounds for what could not be implemented.



If in your case there are no such serious risks, then the next question arises: will the requirements change? If your requirements are well known in advance, and you are sure that the customer will not make any significant changes in the development process, then you should choose a cascade development model. I recommend choosing a cascade model when the project has a short duration. In the case of clear and unchanging requirements, coupled with a short duration, the cascade model compared to the iterative model will give less process overhead. At all stages of the implementation of programmers, nothing will distract from writing code: neither the need to urgently fix bugs from the last iteration, nor the endless rallies and releases.

However, in the case of long-term projects, the cascade model will work poorly. Despite the fact that there are no risks of changing requirements, there are technical risks. For example, if you developed an incorrect architecture, chose the wrong technologies and tools, did not calculate the required performance, etc., you are more likely to find out at the end, and there may be no time to fix it. The longer the project lasts, the higher the cost of correcting the error. If at the initial stage refactorings and cardinal code changes are easy, then at the end of the project, this is already quite “painful”.

A practical example: we needed to implement a mobile application that would do the exact same thing as the same desktop application. Thus, the requirements were known and unchanged throughout the project.



The next question is whether the requirements are complex. Again, the question is not straightforward and depends on the project. When you start a project, it is sometimes useful at the analysis and design stage to think about how you will be testing. This can help identify potential problems earlier and better implement the architecture, work out requirements, etc. When the requirements are complex, it is recommended to carefully think through all the test scenarios, and at the analysis and design stage, develop test approaches, test plans and test cases. In this case, we come to the aid of the model V-Model, which is a kind of cascade model.

The use of V-Model, where the requirements are quite simple will lead to the fact that the system will be more expensive. Moreover, V-Model is criticized for generating a lot of documentation and bureaucracy and in reality serving not to create high-quality software that satisfies the customer, but to prove at the end of the project that the system works as originally required, instead of really developing what he needed.



The formalized approach is that all the processes of the application life cycle are regulated in detail. This is necessary in complex large projects with a large team.

An example is the systems on which people’s lives depend: medicine, transport, energy. Typically, such systems are developed in accordance with industry standards, repeatedly tested, subject to licensing. Light methodologies in such systems do not work. As you know, live communication is preferable to documentation in them, but, for example, if your application will be tested several times by different teams, it is better if this process is carefully documented. If there are dozens of people in a team, then no product owner (customer representative for scram terminology) will be able to constantly explain the requirements to them all.

Thus, if you need a formalized approach, then such methodologies as RUP, OpenUp, EssUp will become your choice. Such methodologies are more than methodologies and it is more correct to call them process frameworks. They were originally created for an iterative model; however, they can also be used in modifications in a cascade model.



If we do not need a formalized approach, then we will use so-called flexible methodologies. Speed ​​or quality? In fact, it implies a slightly more complex formulation: productivity or engineering?

By productivity is meant the fastest process of adding functionality to an application. Engineering implies a high level of development organization, innovative approaches and complex techniques that can be applied only by an experienced team. I'm talking about such practices of extreme programming as development through testing, continuous integration, pair programming, etc. The peculiarity of extreme programming is that it is necessary to use all 12 practices, only then the effect of them becomes maximum. If you do not use some kind of practice, she will definitely pull everyone else along. For example, if you refuse unit tests, then you cannot do frequent refactorings, without refactorings you cannot provide a simple architecture (as we know, a simple architecture is more difficult to develop than a complex one), etc.

However, you can use the practice of extreme programming in other methodologies, moreover, it can be very useful. For example, you can use pair programming in Scrum to help beginners quickly integrate into a project. Thus, extreme programming can provide high quality at the expense of a higher level of engineering, but if you choose this methodology, the project can be more expensive. Also, for successful application, a team that already has experience in using this methodology is required.



If you need maximum productivity, then there are also options. Scrum is focused on continuous process improvement. For this, he has a retrospective rally that takes place at the end of the sprint. Also during the sprint review, what was done well, what was bad and what was improved was discussed. If you have an experienced team, a well-established process, and you basically do not need improvement, then following the Scrum methodology will take you too much time, which you could spend more profitably. For example, according to Scrum, if the sprint lasts 1 month, then the sprint review should take 4 hours and the sprint retrospective should take 3 hours. Plus, there is a sprint planning, lasting 8 hours and daily Scrum meetings for 15 minutes.

If you have, for example, a non-cohesive team, or you are using tested technologies or an unfamiliar field of application for your application, or all together, then choosing the Scrum methodology can be a great solution. When a new project starts, you can start using Scrum, and when the process becomes more streamlined, the architecture stabilizes, the need for constant improvements disappears, then you can switch to another methodology, for example, Kanban.



If improvement is not needed and all that is needed is to concentrate on completing tasks, then RAD or Kanban will work well. RAD has a lot in common with agile methodologies, but there is a significant limitation on the duration of the project. Preferably no more than 60-90 days. Kanban is like a continuous conveyor that can last forever. It works well on support projects, but it’s bad where you need to develop a complex architecture, because focused on the rapid addition of features in the application. By features we mean a piece of functionality that is visible to the user and directly solves any of his tasks. For example, logging, optimization and scalability are not visible to the user, these are not features in Kanban terminology. But the new page, report, additional filters in the search is what is visible to the user and is a feature.

Sources:

1. Dr. Winston, W. Royce. Managing development of large software systems. 1970. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
2. W Boehm, A spiral model of software development and enhancement. 1986. http://csse.usc.edu//TECHRPTS/1988/usccse88-500/usccse88-500.pdf
3. W Boehm. Spiral Development: Experience, Principles, and Refinements. 2000. http://www.sei.cmu.edu/reports/00sr008.pdf
4. S. Belousova, I. Bessonova, Rudzhero Gilyarevsky. Introduction to software systems and their development. HSE. http://www.intuit.ru/studies/courses/3632/874/info
5. K. Schwäber, D. Sutherland.Skram Hyde. A comprehensive guide to Scrum: Rules of the game.
http://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-RUS.pdf#zoom=100
6. Rational Unified Process. Best Practices for Software. Development Teams. http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf
Introduction to OpenUP. http://epf.eclipse.org/wikis/openup/
7. H. Kniberg, M. Skarin. Scrum and Kanban: Squeeze the maximum. InfoQ. 2010
8. K. Auer, R. Miller. Extreme programming. Staging processes. - SPb .: Peter: 2004
9. Extreme programming - reality and myths. skipy.ru/philosophy/xp.html
10. M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP. APress, USA, 2003
11. James Christie. The seductive and dangerous V Model.
http://www.clarotesting.com/page11.htm
12. Adel Alshamrani. A Comparison Model SDLC Models Waterfall Model, Spiral Model, and Incremental / Iterative Model. http://www.academia.edu/10793943/A_Comparison_Between_Three_SDLC_Models_Waterfall_Model_Spiral_Model_and_Incremental_Iterative_Model