You get a bonus - 1 coin for daily activity. Now you have 1 coin

Software development process (waterfall, iterative and spiral development model), development methodology

Lecture



  • Basics of the software development process
  • Software Development Methodologies
  • Software development cycle in popular methodologies
  • The concept of environments (environments) and working with them

The software development process (eng. Software development process , software process ) is the structure according to which software development is built.

There are several models of such a process, each of which describes its own approach, in the form of tasks and / or activities that take place during the process.

  • 1 Steps of the process
  • 2 Process Models
    • 2.1 Waterfall (cascade, sequential) model
    • 2.2. Interactive model
    • 2.3 Spiral model
  • 3Notes

Process steps

The development process consists of many subprocesses, or disciplines, some of which are shown below. In the waterfall model, they go one after another, in other similar processes their order or composition changes.

  • Requirements Analysis → Software Specification
  • Software design
  • Programming
  • Software testing
  • System integration (System integration)
  • Software Implementation (or Software Installation)
  • Software maintenance

Process models

Waterfall (cascade, sequential) model

Waterfall life cycle model (born waterfall model ) was proposed in 1970 by Winston Royce. It provides for the consistent implementation of all phases of the project in a strictly fixed order. The transition to the next stage means complete completion of work at the previous stage. Requirements defined at the stage of formation of requirements are strictly documented in the form of technical specifications and fixed for the entire time of project development. Each stage ends with the release of a complete set of documentation sufficient for the development to be continued by another *** developer.

Software development process (waterfall, iterative and spiral development model), development methodology

Stages of the project in accordance with the cascade model:

  1. Formation of requirements;
  2. Design;
  3. Implementation;
  4. Testing;
  5. Implementation;
  6. Operation and maintenance.

Benefits :

  • Complete and consistent documentation at each stage;
  • Easy to determine the timing and costs of the project.

Disadvantages :

In the waterfall model, the transition from one project phase to another implies the full correctness of the result (output) of the previous phase. However, the inaccuracy of a requirement or its incorrect interpretation as a result leads to the fact that it is necessary to “roll back” to the early phase of the project and the required processing not only knocks out the project *** from the schedule, but often leads to a qualitative increase in costs and, not excluded to the termination of the project in the form in which it was originally conceived. According to modern specialists, the main misconception of the authors of the waterfall model is the assumption that the project goes through the whole process once, the designed architecture is good and easy to use, the implementation project is reasonable, and implementation errors are easily eliminated as far as testing. This model assumes that all errors will be concentrated in the implementation, and therefore their elimination occurs evenly during the testing of components and the system [1] . Thus, the waterfall model for large projects is not very realistic and can only be effectively used to create small systems [2] .

Iteration model

An alternative to the sequential model is the so-called iterative and incremental development model (English iterative and incremental development, IID ), which also received from T. Gilba in the 1970s. name of the evolutionary model . Also, this model is called an iterative model and an incremental model [3] .

Software development process (waterfall, iterative and spiral development model), development methodology

The IID model involves splitting a project's life cycle into a sequence of iterations, each of which resembles a “mini-project,” including all development processes as applied to creating smaller pieces of functionality, compared to the project as a whole. The goal of each iteration is to get a working version of the software system, including the functionality defined by the integrated content of all previous and current iterations. The result of the final iteration contains all the required functionality of the product. Thus, with the completion of each iteration, the product is incremented - increment - to its capabilities, which, therefore, evolve evolutionarily . In this case, iteration, incrementality, and evolutionality are the expression of the same meaning in different words from slightly different points of view [2] .

As T. Gilba puts it, “evolution is a device designed to create the appearance of stability. The chances of successfully creating a complex system will be maximized if it is implemented in a series of small steps and if each step contains a clearly defined success, as well as the possibility of a “rollback” to the previous successful step in case of failure. Before putting into operation all the resources intended for creating the system, the developer has the opportunity to receive feedback signals from the real world and correct possible errors in the project ” [3] .

The IID approach has its negative sides, which, in fact, is the flip side of merit. First, a holistic understanding of the possibilities and limitations of the project has been absent for a very long time. Secondly, during the iterations, it is necessary to reject part of the work done earlier. Thirdly, the conscientiousness of specialists in the performance of work is still declining, which is psychologically explicable, because they are constantly carried by the feeling that “all the same, everything can be redone and improved later” [2] .

Various variants of the iterative approach are implemented in most modern development methodologies (RUP, MSF, XP).

Spiral model

The spiral model (eng. Spiral model ) was developed in the mid-1980s by Barry Boeham. It is based on the classic Deming PDCA cycle (plan-do-check-act). When using this model, the software is created in several iterations (spiral turns) using the prototyping method.

Software development process (waterfall, iterative and spiral development model), development methodology

Each iteration corresponds to the creation of a fragment or software version, it specifies the goals and characteristics of the project, evaluates the quality of the results and plans the work of the next iteration.

At each iteration, the following are evaluated:

  • the risk of exceeding the terms and cost of the project;
  • the need to perform another iteration;
  • degree of completeness and accuracy of understanding system requirements;
  • expediency of termination of the project.

It is important to understand that the spiral model is not an alternative to the evolutionary model (IID model), but a specially developed variant. Unfortunately, the spiral model is often either mistakenly used as a synonym for the evolutionary model in general, or (no less mistakenly) referred to as a completely independent model along with the IID [2] .

A distinctive feature of the spiral model is special attention paid to risks affecting the organization of the life cycle and control points. Boeam formulates the 10 most common (by priority) risks:

  1. Lack of specialists.
  2. Unrealistic deadlines and budget.
  3. Implementing inappropriate functionality.
  4. Developing the wrong user interface.
  5. Perfectionism, unnecessary optimization and sharpening of details.
  6. Continuous flow of changes.
  7. Lack of information on external components that define the system’s environment or are involved in integration.
  8. Deficiencies in the work performed by external (in relation to the project) resources.
  9. Insufficient performance of the resulting system.
  10. The gap in the qualifications of specialists in different areas.

In today's spiral model, the following common set of control points is defined [4] :

  1. Concept of Operations (COO) - the concept (use) of the system;
  2. Life Cycle Objectives (LCO) - goals and content of the life cycle;
  3. Life Cycle Architecture (LCA) - life cycle architecture; here it is possible to talk about the readiness of the conceptual architecture of the target software system;
  4. Initial Operational Capability (IOC) - the first version of the product being developed, suitable for trial operation;
  5. Final Operational Capability (FOC) –– a finished product deployed (installed and configured) for actual operation.

Software development methodologies

Methodology is a system of principles, as well as a set of ideas, concepts, methods, methods and means that determine the style of software development.

Methodology is the implementation of a standard. The standards themselves only speak of what should be, leaving the freedom of choice and adaptation.

Specific things are realized through the chosen methodology. It determines how the development will be performed. There are many successful software development methodologies. The choice of a specific methodology depends on the size of the team, on the specifics and complexity of the project, on the stability and maturity of the processes in the company and on the personal qualities of the employees.

Methodologies are the core of software development management theory. Depending on the life cycle model used in it (waterfall and iterative methodologies), a more general classification for predictable and adaptive methodologies has been added to the existing classification.

Projected methodologies focus on the detailed planning of the future. Known planned tasks and resources for the entire duration of the project. Kom *** and hardly reacts to possible changes. The plan is optimized based on the scope of work and existing requirements. Changing requirements can lead to a significant change in the plan, as well as the design of the project. Often, an ad hoc “change management” committee is created to ensure that only the most important requirements are taken into account.

Adaptive methodologies are aimed at overcoming the expected incompleteness of requirements and their constant change. When requirements change, com *** and developers change too. Com *** a, participating in adaptive development, can hardly predict the future of the project. There is an exact plan only for the near future. Plans that are more remote in time exist only as declarations on the objectives of the project, the expected costs and results.

SCRUM - a methodology designed for small teams (up to 10 people). The whole project is divided into iterations (sprints) lasting 30 days each. A list of system functions that are planned for the next sprint is selected. The most important conditions are the invariance of the selected functions during the execution of one iteration and strict observance of the release dates for the next release, even if by the release it is not possible to implement all the planned functionality. The development manager conducts daily 20 minute meetings, which are called scrum, the result of which is the determination of the system function, implemented for the previous day, the difficulties encountered and the plan for the next day. Such meetings allow you to constantly monitor the progress of the project, quickly identify problems encountered and respond promptly to them.

KANBAN is a task-oriented, flexible software development methodology.

  • Fundamental rules:
  • development visualization:
    • division of work into tasks;
    • use of marks on the position of the task in the development;
  • restriction of work performed simultaneously at each stage of development;
  • cycle time measurement (average time to complete one task) and process optimization.


Advantages of KANBAN:

  • reducing the number of tasks performed in parallel significantly reduces the time to perform each individual task;
  • quick identification of problem tasks;
  • calculation of the time to perform the average task.



DYNAMIC SYSTEM DEVELOPMENT METHOD emerged as a result of a consortium of 17 British companies. The whole organization develops manuals on this methodology, organizing training courses, accreditation programs, etc. In addition, the value of DSDM has a cash equivalent.

It all starts with a study of the feasibility of the program and its scope. In the first case, you are trying to understand whether DSDM is suitable for this project. It is supposed to study the field of application of the program in a short series of seminars where programmers learn about the business field for which they are to work. It also discusses the main provisions concerning the architecture of the future system and the project plan.

The process is further divided into three interconnected cycles: the functional model cycle is responsible for creating analytical documentation and prototypes, the design and engineering cycle — for bringing the system to a working state, and finally, the last cycle — the implementation cycle — ensures the deployment of a software system.

The basic principles on which DSDM is built are active interaction with users, frequent releases of versions, developers' autonomy in decision making and testing throughout the entire work cycle. Like most other flexible methodologies, DSDM uses short iterations, each lasting from two to six weeks. Particular emphasis is placed on high quality work and adaptability to changes in requirements.

MICROSOFT SOLUTIONS FRAMEWORK is a software development methodology proposed by Microsoft. MSF builds on Microsoft’s hands-on experience and describes how people and workflows are managed during the solution development process.
Basic concepts and principles of the MSF process model:

  • a single vision of the project - all stakeholders and just the project participants should clearly represent the final result, everyone should be clear about the purpose of the project;
  • trade-off management - looking for trade-offs between project resources, a calendar, and opportunities realized;
  • flexibility - readiness for changing project conditions;
  • focus on business priorities - focusing on the return and benefit that a consumer expects to receive;
  • encouraging free communication within the project;
  • Creating a base version - fixing the state of any project artifact, including program code, project plan, user manual, server settings and subsequent effective change management, project analytics.



MSF offers proven methodologies for planning, designing, developing, and implementing successful IT solutions. Thanks to its flexibility, scalability and the lack of rigid instructions, MSF is able to meet the needs of an organization or project team of any size. The MSF methodology consists of principles, models, and disciplines for the management of personnel, processes, technological elements, and issues related to all of these factors that are common to most projects.

RATIONAL UNIFIED PROCESS is a software development methodology created by Rational Software.
The methodology is based on 6 basic principles:

  • component architecture implemented and tested in the early stages of the project;
  • work on a project in a cohesive team, the key role in which belongs to the architects;
  • early identification and continuous elimination of possible risks;
  • focus on meeting customer requirements for the executable program;
  • waiting for changes in requirements, design decisions and implementation in the development process;
  • continuous quality assurance at all stages of project development.


Using the RUP methodology is aimed at an iterative development model. The peculiarity of the methodology is that the degree of formalization may vary depending on the needs of the project. It is possible at the end of each stage and each iteration to create all the required documents and achieve the maximum level of formalization, and you can create only the documents necessary for the work, up to and including their complete absence. Due to this approach to the formalization of processes, the methodology is quite flexible and widely popular. This methodology is applicable both in small and fast projects, where, due to the lack of formalization, it is required to reduce project execution time and costs, as well as in large and complex projects, where a high level of formalism is required, for example, for the purpose of further certification of the product. This advantage gives the opportunity to use the same com *** developers for the implementation of various in volume and requirements.

Thus, there are many different software development methodologies, they are not universal and are described by different principles. The choice of development methodology for a particular project depends on the requirements.

See also


Comments


To leave a comment
If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

Quality Assurance

Terms: Quality Assurance