|A web development process can be divided into different life cycle steps. For each step certain standards and procedures can be applied. Often "in-house" standards are used regarding documents, coding etc. However it would beneficial to your company if your procedure conforms to quality standards.
In this guide the classical software life cycle model (ESA PSS-05) that was standardised by the European Space Agency is adopted as a reference model for the web development life cycle. There are some changes and additions made on the ESA PSS-05 standards.
The document complies with the Software Transfer Document (STD) from the Software Engineering Standard, as set by the European Space Agency [ESA].
This guide describes how to apply the "ESA Software Engineering Standards to small software projects" for web projects. This guide is also nickname "ESA PSS-05 lite".
Web development process
||During this phase the client (a.k.a. customer, domain expert, user) and the functional analyst (a.k.a. business analyst, analyst) discuss and define what the end product (also called an application or system) should do. All the user or business requirements are written down by the functional analyst in a requirements specification document. This document must be signed off by both parties, thus becoming a binding contract.
Output: User Requirements Document (URD)
||During this phase the software architect (a.k.a. solution architect) converts the user requirements into an architecture describing the overall solution. This solution can be seen as a blue print.
The software architect is involved in the following activities:
Defining the system
The architect decides how the system should be divided in separate components and where each component should be placed on a network. Knowledge of design patterns and which framework should be used is decided here.
Building user interface prototypes
User interface prototypes can be very helpfull to customers to visualize the agreed requirements. It also ensures that all parties have the same understanding of the application. New ideas may emerge by seeing the prototypes which may change some requirements. The prototype can later be used by the development team.
Input: User Requirements Document (URD)
Output: Software Specification Document (SSD)
||During this phase several roles are involved. The first is the lead developer who converts the Software Specification Document from the software architect into a more detailed design which the development team can use.
The lead developer should document the detailed design by putting most detailed design information into the source code and extending the SSD to contain any detailed design information that cannot be located in the source code (e.g. information about the software structure).
During the implementation phase the software architect hand over the [to be defined] documents to the developers. The developers starts coding. During this phase the developers often unit test their code.
The individual system components are integrated and tested.
During the design, inplementation and even test phase these requirements can change (often by the customer ). These changes should be documented in a Change Request document.
Input: Software Specification Document (SSD)
Output: Software User Manual (SUM)
||to be defined