How does Scrum (Agile) differ from the spiral methodology of software development?

Each software product development goes through a software development life cycle (or simply SDLC). The SDLC begins with the decision to create a product and ends with the final product created.

There are different types of SDLC models, each of which has a different set of strengths and weaknesses. However, each type of SDLC corresponds to the main stages of software product development: planning, design, development, testing, and deployment.

Some SDLC models include a waterfall model, a V-shaped model, an evolutionary prototyping model, a spiral method (SDM), an iterative and incremental method, and an Agile (flexible) development.

Agile development also includes SCRUM, Extreme Programming (XP), Crystal, Dynamic Systems Development Method (DSDM), Feature Development (FDD) and Lean Development.

Here we try to consider and differentiate the Scrum (Agile) method with the spiral method, to find their similarities between differences and scope, advantages and disadvantages.

SPIRAL MODEL

A spiral life cycle model is a type of iterative software development model that is typically implemented in high-risk projects. This was first proposed by Barry Bam in 1986 in his article “The Spiral Model of Software Development and Improvement” [3]. In this approach, we combine the characteristics of both the waterfall model and the prototype model. In the spiral model, we can organize all development activities in the form of a loop or spiral.

Each cycle in a spiral indicates a development stage (and we can have any number of cycles depending on the size and nature of the project). Each cycle has four quadrants: the first quadrant is used to define goals, alternatives, and constraints. Here we are trying to understand product intentions, design changes, and cost, technology, and schedule constraints. The second quadrant indicates risk analysis and evaluation of alternatives. Here we are trying to find out what other methods can be implemented to implement the identified constraints. Here are important operational and technical problems. At this stage, the focus is on identifying risks and mitigating their effects. And based on these factors, future actions are determined. The third quadrant indicates the completion of this phase of development. Now we are developing a planned product. Testing is also given the same value. For software development, you can consider waterfall or a gradual approach. The fourth quadrant helps plan the next stage. Here we evaluate progress and make decisions considering all limitations. At this stage, the developer has the right to decide whether to continue the project or stop working with the project. If solvable problems are identified, they can be solved and the necessary steps to proceed can be planned. Sequential loops of the spiral model include similar phases. Analytical and engineering efforts are applied here. Huge, expensive or complex projects use this type of life cycle. At any given time, if someone believes that the risk associated with the project is large and uncontrollable than expected, there is a condition to interrupt it. Assessments at different stages can be performed by an internal person or an external client.

Spiral - Meta Model

The spiral model is also called a meta model because it combines the properties of other SDLC models. Basically, waterfall and prototype models are taken into account. Here we systematically develop software over cycles (after approaching a waterfall), and at the same time we create a prototype and show it to the user after completing various stages (as well as a prototype model). In this way, we can evaluate and reduce risks, and also follow a systematic approach.

The risk-based approach of the spiral model helps the model adapt any type of model-oriented model-based or any other transformation-oriented approach to software development. Similarly, risk management factors help us determine the amount of time and effort that is performed for other projects, such as planning, change management, quality factors, official technical reviews, testing, etc.

The high point of this model is that each of its cycles ends with a fruitful interaction between customers and developers associated with the project. Although this model has many positive points, as usual, the model also has many negative sides. Let's summarize the advantages and disadvantages of this model as follows:

advantages

The spiral life cycle model is one of the most flexible SDLC models. Development phases can be determined by the project manager depending on the complexity, size and type of project.

· Project supervision is very simple and active. Each phase, or each cycle, requires a review of the relevant organs. This makes the model more obvious.

· Risk management is one of the main characteristics of the model, which makes it more reliable than other models.

· Changes can be announced later in the life cycle.

· Project expectations in terms of schedule, cost, quality, etc.

· It is most suitable for high-risk projects, where business needs may be unstable and not predictive in nature.

· High risk product can be designed using this.

disadvantages

· The cost involved in this model is usually unpredictable.

· This is a complex method, especially for projects with a clear specification (SRS).

The skills needed to evaluate and analyze a project from time to time need high experience.

· Procedures and protocols must be properly followed to effectively implement this model. Following such activity, the project period is indeed a threatening aspect.

Thanks to the different settings that are acceptable to the client at any time, using the same prototype in other projects, will invariably influence in the future.

· This is not a proposed model for low-risk projects.

· Compliance with economic and planning requirements is dangerous if this way of development is practiced.

· The volume of documentation required at the intermediate stages of the project is the management complex.

AGILE model

The Agile model is a modern trend in software development methodology used to accelerate the delivery of operating products / systems within a planned time frame using a set of values ​​that include adaptability, transparency, simplicity and unity in an efficient and light weighted form. The flexible model is a widely used model that often uses an approach to simplify the process, dividing it into short and light weighted phases, such as requirements, specifications, architecture, design, implementation, testing, deployment and maintenance, which leads to the creation of effective software systems. There are many special flexible development methods. Most encourage development, team spirit, association, and process alignment throughout the project life cycle.

Flexible methods break down tasks into small increments with minimal planning and are not directly related to long-distance planning. Iterations are very short time frames, also called time cells, which usually vary from one to four weeks. Each iteration includes a cross-functional group that works in all tasks, such as project planning, requirements analysis, system and architectural design, coding, unit level testing, and finally, acceptance testing. At the end of each iteration, the work product is verified by interested parties. This allows you to minimize the overall risk and allows the project to quickly adapt to changes. It may take a lot of iteration to release a product. A model showing the flexible life cycle and the risk analysis phase is shown in Figure 2.

Some of the well-proven and used flexible methods of software development include:

· Crystal Clear

· Dynamic Systems Development Method or (DSDM)

· Extreme Programming (XP)

· Feature Development (FDD)

· Kanban (development)

· Software development for beginners

· Scrum

advantages

· Customer satisfaction is guaranteed by delivering the necessary software quickly and continuously.

· People and interactions are accented, not process and tools. Customers / users, developers, and testers interact with each other all the time.

Work software is shipped regularly (weeks, not months).

· Face-to-face conversation is the best adapted form of communication.

· The closure and daily interaction and collaboration between business people and developers was detected.

· Continuous attention to technical excellence and good design is taken into account.

· Regular adaptation to changing conditions is accepted.

· Welcomes changes in requirements even at later stages.

disadvantages

· In the case of large software projects, it is really difficult to assess the effort required to begin the software development life cycle.

· There is a lack of focus on the necessary design and documentation.

The project can easily change the track if the client does not know about the final result that they need.

· Only senior programmers are able to make the necessary decisions during the development process. Therefore, it is not a place for beginners or junior programmers, if they are not combined with experienced resources.

GENERAL RISK FACTORS EVALUATED DURING SDLC

Risk is always defined as a term that creates potential future harm that may arise from certain ongoing activities. Risk management is the most important problem associated with software development. Risk management consists of various processes, methodologies and tools that are used to solve various risk factors in the SDLC software development process. It is also defined as an activity that identifies risk, assesses risk, and determines strategies to minimize or mitigate risk. Risk management can also be defined as the practice of systematically determining cost-effective approaches to minimizing the consequences of a threat and maximizing opportunities in the future.

Some of the major factors associated with program risk are:

Risks affect aspects that can harm project outcomes.

· Risk is a direct consequence of uncertainty. If there is no uncertainty, it is never called risk - it is known as certainty.

· Risk analysis is used to help the team understand the various forms of uncertainty that may affect project results.

· Risk management (sometimes referred to as “risk mitigation”) is a method that a team sets itself to predict and mitigate the consequences of risk for a project.

An important aspect to remember is that even in simple projects, everything is going wrong, and you need to plan to minimize the impact of these events when they occur. Main activities or steps in risk:

Risk identification

Risk classification

Quantitative risk assessment

Risk planning and action

Repetition of risk based on situations.

In this article, I tried to classify the risk that is likely to occur during software development. And then conduct a comparative study of the two aforementioned models and find out the real effect of risk assessment and the effect created on these models.

Some of the main potential risk categories related to software development that I chose to study include:

Mission and purpose of the organization

· Project Management Capabilities

· Teamsters Solution

· Organizational management

· Customer / User Relationships

· Design limitations

· Software content

· Deployment Factors

· Development activities

· development environment

· Project management

· The project team

· Technology issues

· Service factors

These types of risks listed above also contain many subcategory factors. Let's look at each factor and classify risk as low, medium or high, based on their impact on software development. And then compare the Spiral and Agile model to see how their ability to evaluate performance is with so-called potential risk situations. Risk models, methods, and methods are widely used to manage risk in software development. Risk assessment leads to a positive or negative result. Bad results are risks, and good results are an opportunity to create high-quality software. Now let's see how we can conduct this risk assessment using our traditional spiral model and the new generation Agile model.

Basic structure:

Scrum is an Agile method that is structured for iterative and incremental development. Scrum defines different time periods, called sprints. Each sprint holds a set of customer requirements, and the team seeks to get results for that particular sprint. The end product is the result of continuous collaboration between multi-functional teams and customers.

The spiral model combines the characteristics of two models: prototyping models and waterfall models. This model is usually preferred for large scale, expensive and complex projects. The spiral model uses many of the same steps as the waterfall model. It follows the same scheme, divided into planning, risk assessment, and prototyping and simulation.

Type of projects:

Each project requires a different software development cycle with a unique pattern and entities involved in time.

The Agile method is usually preferable for projects requiring smaller teams, the participation of senior developers, demonstrating lower criticality and frequent changes in requirements.

On the other hand, the spiral model is better suited for projects that may have higher criticality, teams include younger developers, requirements do not change regularly, large teams are recruited, and the project template requires discipline.

Planning:

Scrum requires minimal planning. Since this is an iterative process, each sprint contains an overview of the last sprint and is based on best practices or failures, the next sprint is scheduled. Before the project reaches completion, it is subject to several planning stages.

The “Spiral” method requires a certain amount of planning before the project starts. At the planning stage, requirements such as “BRS” (business requirements specifications) and “SRS” (requirements for system requirements) are collected.

Documentation:

In the Scrum (Agile) method, rules require minimal documentation, mainly in the form of stories and product magazines. For this reason, project documentation is easily managed.

There is an excessive amount of documentation in the spiral methodology at intermediate stages. As a rule, the list of documents includes requirements for understanding the document, completed requirements, documents for highlighting risks and mitigation plans, test cases, test summary reports, defect reports and a list of final functions.

Project Size:

With Scrum, a project can be broken down into smaller cycles called sprints; each sprint ends up with workable functionality. This makes Scrum suitable for projects of any size, large or small.

SDM, on the other hand, may not be the best choice for low-risk or low-risk projects. Risk management in a spiral requires special knowledge that can only be achieved through additional training. For this reason, Spiral can be expensive and not ideal for small projects.

The final results of the project:

Scrum includes iterative cycles, known as sprints, where each sprint works towards the goal indicated in the corresponding user history. This helps in the early delivery of partial work solutions.

Модель Spiral обслуживает как краткосрочные результаты, в которых небольшие выпуски выпускаются на регулярной основе, так и более широкие контент-материалы, которые могут занять более длительный период времени для выпуска.

Вовлечение клиента:

Scrum сильно зависит от участия и взаимодействия с клиентами. Каждый спринт заканчивается встречей между командой разработчиков и клиентом, чтобы оценить прогресс, проблемы и способы управления проектом в будущем.

В спиралевидной модели клиенты обычно представляют свои требования в начале SDLC. На этапе оценки клиенты осваивают программное обеспечение и предоставляют свои отзывы или одобрения. По этой причине эта модель не требует постоянного взаимодействия с клиентами

ОПАСНОСТЬ ОЦЕНКИ РИСКА С СПИРАЛЬНЫМИ И АГИЛЕМОДЕЛЬНЫМИ - СРАВНИТЕЛЬНОЕ ИССЛЕДОВАНИЕ

По словам Барри Бёма и Ричарда Тернера, анализ рисков можно использовать для выбора между адаптивными (гибкими - Valuedriven) и прогнозирующими (спирально-ориентированными) методами и заключил, что каждая сторона диапазона имеет свои собственные связанные функции, как показано в Таблица 1:

В таблице 1 четко описывается разница в возможностях оценки риска спирали и Agile Model. В нем основное внимание уделяется пяти различным аспектам критичности, классу разработчиков, изменению требований, числу вовлеченных разработчиков, а также принципам и философии. В целом мы можем обнаружить, что Agile Model поддерживает общие проблемы и дает меньшую вероятность риска в течение жизненного цикла разработки.

Теперь давайте проведем сравнительную проверку различных факторов риска и связанного с ними влияния на обе модели, которые показаны в таблице 2. Эффект риска оценивается как низкий, средний и высокий на двух моделях анализа большого риска.

В таблице 2 приводятся некоторые из основных категорий рисков и связанных с ними факторов риска, на основе которых я сделал оценку воздействия риска и того, как две модели - спираль и гибкость справляются с ситуацией. Это данные, которые были собраны из различных компаний, занимающихся разработкой программного обеспечения, и провел количественное исследование на основе этих фактов.

На основе этих фактов было проведено количественное средство анализа, как показано в таблице 3. Это точно показывает процент процентной ставки риска для каждой модели. Из этой таблицы 3 видно, что уровень риска высокого риска для Agile и среднего типа больше для Spiral Model.

Чтобы сделать его более понятным, круговая диаграмма рисуется с использованием этих данных, как показано на графике 1.

Таким образом, было обнаружено, что Agile Model, в зависимости от многих факторов риска, продемонстрировала хорошее влияние на минимизацию риска и приводит к лучшему результату успеха в разработке программного обеспечения с использованием этой модели. Во время этого относительного исследования были учтены многие критерии и их вспомогательные критерии.

CONCLUSION

Из этого сравнительного исследования мы можем обнаружить, что уровень риска выше при работе со спиральной моделью или разработкой программного обеспечения по сравнению с последней легкой методологией - Agile. Хотя у нас есть представление о том, что методологии Agile неэффективны в крупных организациях и некоторых типах проектов, это, по-видимому, лучше всего подходит для разработки небольших и не последовательных проектов на основе проведенной оценки рисков. Многие организации считают, что гибкие методологии используют гибридный подход, в котором сочетаются элементы гибких и ориентированных на план действий -Спиральные подходы. Спиральная модель обнаруживает риск более высокого порядка, чем Agile Model. Даже тогда. Мы можем заключить, что в зависимости от типа проектов и его огромных размеров,

Несмотря на то, что уровень риска в модели Agile по сравнению со спиралью ниже по сравнению со спиралью, во многих условиях, таких как размер проекта, опыт работы с клиентами и характер рабочего потока, спиральная модель также учитывается при разработке программного обеспечения различными организациями в течение нескольких дней. Однако из проведенного анализа считается, что большинство современных компаний-разработчиков поддерживают Agile-модель, рассматривая ее как свою основную модель для живой, быстрореализуемой модели разработки программного обеспечения в последние годы. Оценка рисков и разработка продукта всегда идут рука об руку и без надлежащей оценки риска никогда не может быть разработан качественный продукт. Таким образом, мы можем заключить, что в зависимости от типа, сложности и размера проектов,

пишите в коментариях

Do you use any of the above methods in your software development projects?

What other differences do you encounter when using these approaches?