Supported Software Development Models

Several models exist to streamline the development process. Each one has its pros and cons, and it is up to the development team to adopt the most appropriate one for the project. Sometimes a combination of the models may be more suitable.

Waterfall model

The activities of the software development process represented in thewaterfall model. There are several other models to represent this process.
Main article: Waterfall model

The waterfall model shows a process, where developers are to follow these phases in order:

  • Requirements specification Requirements analysis)
  • Software design
  • Implementation and Integration
  • Testing (or Validation)
  • Deployment (or Installation)
  • Maintenance

In a strict Waterfall model, after each phase is finished, it proceeds to the next one. Reviews may occur before moving to the next phase which allows for the possibility of changes (which may involve a formal change control process). Reviews may also be employed to ensure that the phase is indeed complete; the phase completion criteria are often referred to as a “gate” that the project must pass through to move to the next phase. Waterfall discourages revisiting and revising any prior phase once it’s complete. This “inflexibility” in a pure Waterfall model has been a source of criticism by supporters of other more “flexible” models.

Spiral model

spiral-model

The key characteristic of a Spiral model is risk management at regular stages in the development cycle. In 1988, Barry Boehm published a formal software system development “spiral model,” which combines some key aspect of the waterfall model and methodologies, but provided emphasis in a key area many felt had been neglected by other methodologies: deliberate iterative risk analysis, particularly suited to large-scale complex systems.

The Spiral is visualized as a process passing through some number of iterations, with the four quadrant diagram representative of the following activities:

  • Formulate plans to: identify software targets, implement the program, clarify the project development restrictions
  • Risk analysis: an analytical assessment of selected programs, to consider how to identify and eliminate risk
  • Implementation of the project: the implementation of software development and verification

Risk-driven spiral model, emphasizing the conditions of options and constraints in order to support software reuse, software quality can help as a special goal of integration into the product development. However, the spiral model has some restrictive conditions, as follows:

  • The spiral model emphasizes risk analysis, and thus requires customers to accept this analysis and act on it. This requires both trust in the developer as well as the willingness to spend more to fix the issues, which is the reason why this model is often used for large-scale internal software development.
  • If the implementation of risk analysis will greatly affect the profits of the project, the spiral model should not be used.
  • Software developershave to actively look for possible risks, and analyze it accurately for the spiral model to work.

Agile development
agile-development

Agile software development poster
Main article: Agile software development

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

There are many variations of agile processes:

  • In Extreme Programming (XP), the phases are carried out in extremely small (or “continuous”) steps compared to the older, “batch” processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can’t think of any more tests that are needed. Design and architecture emerge out of refactoring, and come after coding. The same people who do the coding do design. (Only the last feature — merging design and code — is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system.

  • Scrum

© Copyright 2015. Fusion Systems Inc. All rights reserved | Design and Developed by www.qualinsoft.com