A software development process is a framework for building software. The process imposes a structure on how and when software development activities are performed.
It has been a longstanding goal to find a process that repeatedly and predictably produces good software.
There are many different software development philosophies.
The waterfall model is a classic software development process with specific sequential steps.
The waterfall model proceeds from step to step in a fixed sequence. When using the model, the developer is supposed to complete each step in full before moving on to the next step.
CSE4312 Software Engineering Requirements
In this phase, the requirements analyst needs to work with the customer to determine precisely what the software is supposed to do (but not how it will do it).
Most software is interactive (responds to requests). A use case is a description of a system's behavior when it responds to a request. Uses cases treat the system as a black box, and they specify what the user does and what the user sees; this forces the author to describe what the system does, not how the system does it.
Ideally, specifications are written in exacting detail. For example, the specifications for the space shuttle software reportedly runs some 40,000 pages.
CSE 3311 Software Design
After the requirements have been finalized, the design phase determines how the system will handle each use case.
For non-trivial problems, this phase involves identifying the components (classes) that are needed, and the interaction between the components (methods). Note that the components may not exist, and will need to be created in the next phase.
After the design has been finalized, all of the designed components must be implemented and tested.
Newly created components (classes) are tested in this phase in a process called unit testing. Section 7.2 introduces some aspects of unit testing.
CSE 4313 Software Engineering Testing
In the testing phase, the software system is assembled from its implemented components and is tested as a whole to validate its correctness.
Deployment involves packaging the software, delivering and/or installing the software for the customer, and maintenance.
A significant problem in the waterfall model is that errors in the early phases may not be detected until a later phase. This means that several (or all!) phases must be re-done.
It is an interesting fact that many customers do not know or are unable to accurately communicate their software requirements. Changes in requirements affects every subsequent phase, and may make it very difficult or impossible to accomodate in later phases without restarting the entire process.
An example of architectural risk is an interoperability problem among classes or an inconsistency among use cases (requirements or design phase problems). Such problems may not be detected until the integration testing phase.
Some writers have called design a "wicked problem": a problem that is sufficiently unclear that it is not entirely understood until it is solved.