Traditional software phases

A software development process contains fundamental activities, or phases. This is an introduction to those phases.

Requirement engineering
We start with requirement engineering, which is the field within software engineering that deals with establishing the needs of stakeholders that are to be solved by software.

Why does this phase so important?

In general, the cost of correcting an error depends on the number of subsequent decisions that are based on it. Therefore, errors made in understanding requirements have the potential for greatest cost because many other design decisions depend on them and many other follow up decisions depend on them.

So how do we collect the right requirements?

Traditional requirement engineering does so by a set of steps:
 * 1) Elicitation: The collection of requirements from stake holders and other sources, can be done in a variety of ways
 * 2) Requirement analysis: involves the study and deeper understanding of the collective requirements.
 * 3) Specification of requirements: The collective requirement are suitable represented, organized and save so that they can be shared.
 * 4) Validation: Requirement then can be validated to make sure that they're complete, consistent, no redundant and so on. So that they've satisfied a set of important properties, for requirements.
 * 5) Requirements management: accounts for changes to requirements during the lifetime of the project.

This is an iterative process which will go and cover different phases in an iterative fashion.

Design
Now let's discuss the next phase of software development, which is software design.

Software design is the phase where software requirements are analyzed in order to produce a description of the internal structure and organization of the system. And this description will serve as the basis for the construction of the actual system.

Traditionally, the software design phase consists of a series of design activities. Which normally consists of: Notice that this is just a possible list of activities, you can characterize design activities in many different ways. But the core idea, the important point is that we go from sort of a high-level view of the system, which is the architectural design, to a low-level view, which is the algorithm design.
 * 1) Architectural design
 * 2) Abstract specification
 * 3) Interface design
 * 4) Component design
 * 5) Data structure
 * 6) Algorithm design.

These activities result in a set of design products, which describe various characteristics of the system. For example, they describe the architecture of the system, so how the system is decomposed and organized into components, the interfaces between these components. They also describe these components into a level of details that is suitable for allowing their construction.

Implementation
After we have designed our system we can implement it. In the implementation phase what we do is basically taking care of realizing the design of the system that we just created and create an actual software system.

There are four fundamental principles, four pillars that can affect the way in which software is constructed:
 * 1) Reduction of complexity: this aims to build software that is easier to understand and use.
 * 2) Anticipation of diversity: which takes into account that software construction might change in various way over time. That is that software evolves. In many cases, it evolves in unexpected ways. And therefore, we have to be able to anticipate some of these changes.
 * 3) Structuring for validation: also called design for testability. And what this means is that we want to build software so that it is easily testable during the subsequent validation and verification activities.
 * 4) Use of standards: This is especially true within specific organizations and or domains. It is important that the software conforms to a set of internal or external standards. And some examples of this might be, for example, for internal standards, coding standards within an organization, or naming standards within an organization.

Verification and validation
After we have built our system, verification and validation is that phase of software development that aims to check that the software system meets its specification and fulfills its intended purpose.

More precisely, we can look at verification and validation independently. Verification can be performed at different levels: And this is also the level at which then we will apply validation and some other testing techniques like stress testing or robustness testing and so on.
 * Validation is the activity that answers the question did we build the right system. Did we build the system that the customer wants? That will make the customer happy.
 * Verification answers a different question which is did we build the system right. So given a description of the system that is the one that we derived from the customer through the collection of requirements and then design and so on, did we build a system that actually implements the specification that we defined?
 * Unit level in which we test that the individual units work as a expected.
 * Integration level in which what we test is the interaction between the different units. So we want to make sure that the different modules talk to each other in the right way.
 * System testing in which we test the system as a whole and we want to make sure that all the system, all the different pieces of the system work together in the right way.

Maintenance
As we discussed before software development efforts normally result in the delivery of a software product that satisfies the user requirements. So normally our software development organization will release this application to its final users, however, once the software is in operation many things can happen.

So, for example, the environment might change. There might be new libraries. There might be new systems in which our software has to operate. Or they may be future requests, so the users may find out that, guess what, they want to do something different with the problem that we gave them. Or, again, and this is one of the most common occurrences, users might find problems with the software and may file bug reports and send the bug reports back to the software developer. These are the reasons why software maintenance is a necessary phase in software development.

Software maintenance is the activity that sustains the software product as it evolves throughout its life cycle, specifically in response to bug reports, feature requests and environment changes. Development organizations perform three kinds of maintenance activities:
 * 1) Corrective maintenance to eliminate problems with the code
 * 2) Perfective maintenance to accommodate feature request, and in some cases just to improve the software, for example, to make it more efficient, and finally, adaptive maintenance, to take care of the environment changes.

And after this activities have been performed, the software developer will produce a new version of the application, will release it and the cycle will continue through out the lifetime of the software. That's why maintenance is a fundamental activity and a very expensive one.