Difference between revisions of "Software development lifecycle"

From Knowledge Kitchen
Jump to navigation Jump to search
m (Process models)
(Implementation: Implementing implementation)
(Tags: Mobile edit, Mobile web edit)
 
Line 13: Line 13:
 
* '''System requirements''' - details of how a system should function internally and technical constraints on its operations.
 
* '''System requirements''' - details of how a system should function internally and technical constraints on its operations.
  
===Development===
+
===Implementation===
 
The software is constructed to meet the specification.  This is the design and programming part!
 
The software is constructed to meet the specification.  This is the design and programming part!
  
Line 21: Line 21:
  
 
Development results in either a completed system (if following a Waterfall process) or a completed increment of a system (if following an Agile incremental process).
 
Development results in either a completed system (if following a Waterfall process) or a completed increment of a system (if following an Agile incremental process).
 
  
 
===Validation===
 
===Validation===

Latest revision as of 08:25, 9 September 2019

Core activities

Although the exact details, duration, and sequence of the activities involved in the creation of any given software engineering project depend upon the process model being followed, virtually all software engineering projects do address a common set of high-level steps. Each of these steps contains multiple sub-activities that again vary depending on the process model in use.

Specification

The functionality of the software and constraints on its operation are defined. While the details of these specifications differ wildly depending upon methodology, this activity invariably results in some form of documentation that serves as a specification of what a system or a component is supposed to do and any constraints on how it should be built.

Specification often involves interviews with core stakeholders to understand their requirements for the system, and may involve prototyping of a mock product to show the client a proposed idea in a somewhat tangible form to solicit their feedback. Feedback is used to inform the requirements, which are then drafted. There are a variety of formalized methods for extracting requirements for each methodology.

Specificion usually results in documentation of two different types of system requirements:

  • User requirements - tasks or goals that a user of the system must be able to perform or achieve.
  • System requirements - details of how a system should function internally and technical constraints on its operations.

Implementation

The software is constructed to meet the specification. This is the design and programming part!

Developers may first design and model the system to be built. These may be formal diagrams of the technical architecture and component designs of the system (as often in a Waterfall process) or only "as-needed" informal designs (as often in an Agile process).

Software involving a user interface will also see the interface design at this step. And software that requires the use of a database may follow a database design exercise to be sure the database is properly structured for its intended use.

Development results in either a completed system (if following a Waterfall process) or a completed increment of a system (if following an Agile incremental process).

Validation

The software is tested and validated to ensure that it is a correct implementation of the specification.

There are a variety of different types of tests that address different levels of a system:

  • unit tests - tests of individual components, or units, of a system to make sure they function as expected
  • integration tests - tests to discover errors from unanticipated interactions of sub-components of a system
  • system tests - tests of the system performance as a whole to make sure it can handle its operations, load, and stress
  • user tests - tests that make sure that the intended end-users can easily use the system. These are sometimes called alpha tests
  • beta tests - tests by allowing a limited pool of potential end-users to give feedback on the system

Evolution

The software evolves to meet changing customer needs or new changes in technology.

Each process model has a preference for how changes - either bug fixes or new features - are introduced into the development cycle, and how these changes are then delivered to end-users.

Activity dependencies

As indicated above, many activities in software engineering depend upon, or benefit from, the successful completion of other activities. For example, it is difficult to develop a component in code if there is no specification for what that component is supposed to do. This may seem obvious if you think of software development as a systematic empirical process.

However, it is not uncommon, in practice, to be asked to build something that has not been specified at all. It is the software engineers role to understand the "known unknowns" in such a situation and make an effort to introduce and abide by a systematic process, although in many cases there may be a lot of organizational pressure against this. An ability to diplomatically argue for a cause is critically important in winning over opponents to a proposed software engineering process.

Process models

Most projects engage in a common set of stages, phases or steps as part of the engineering of software. The sequence of these phases, and the details of which tasks and artifacts are involved in each step, is called a "process model" or methodology.

Process models represent accumulated wisdom about software development.

While there are many software engineering process models, two families of process models are commonly discussed in polite industry society today. They are the Waterfall and Agile methodologies.

Waterfall

The waterfall process model. From Software Engineering, 10th edition, by Ian Sommerville

The Waterfall process model, sometimes referred to as Big Design Up Front (BDUF), values a clear sequence of activities and a complete specification of the entire system to be built completed before any development begins. The basic activities in software engineering are arranged sequentially, with each step being completed in full and "signed off" by the client before the next step is embarked upon.

Very often a client will be involved to help draft the specification documents and only become involved again with the project once the system is complete.

Any significant changes to the specification after it has been "signed off" by the client may trigger a need to backtrack to the specification stage to modify it and get new approval, which risks delaying a project significantly. As a result, most involved try to avoid changes once a project has been specified, even when known flaws are discovered. This often leads to poor quality software.

While most see the Waterfall model as "what to avoid" in a software engineering process, it is not uncommon to encounter some or all of its sequential approach in practice.

Incremental

The incremental process model. From Software Engineering, 10th edition, by Ian Sommerville
incremental delivery. From Software Engineering, 10th edition, by Ian Sommerville

The incremental process models value iterative work towards a goal with constant involvement from the client. Work is produced in small batches. The system thus undergoes incremental improvement, gathering feedback from the client and customers all along the way, and adding new features in cycles until the system is declared complete. Documentation is kept to a minimum.

This process model was formalized as a reaction to the perils and rigidity perceived in the Waterfall process. Incremental processes have the advantage of involving the client for their feedback and suggestions throughout the process, and changing requirements are welcomed.

However, incremental-oriented developers face the challenge of creating elegant, easy to maintain systems, in an environment where parts of software are being slapped on-on-top-of-another in a piecemeal fashion. This requires constant refactoring of old code so that new code integrates structurally with the existing codebase in a reliable, maintainable way.

Just as few teams follow a pure Waterfall model, it is rare to see a completely incremental-style team that does not perform some activities in a Waterfall-like way. Client organizations may find it difficult to budget for and receive internal approve for work that is not clearly specified up-front, and client organizations may not want to be constantly involved in every cycle of work as incremental process models require.

The "Agile" software development methodology represents today's gold standard incremental-style approach.

References


What links here