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
Information
|
UR
|
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)
|
|
SR/AD
|
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)
|
|
DD
|
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)
|
|
TR
|
|
|
OM
|
to be defined
|
|
|
