e-SEM
 Life cycle    | Phase-neutral themes    | Initiation    | Definition    | Design/Implementation    | Operations    | Termination
 Design/
 Implementation
How can I reach
the goals?
Tips

 


Design/Implementation phase

  stdSEM Prototyping phase 

Phase goals

The key goals of this phase are as follows:

  • To create a release that is ready to use
  • To provide technical documentation for this release (documentation of solution) to be able to continue with subsequent development

This phase corresponds to the stdSEM Prototyping phase: Design and implementation are carried out cyclically, with ongoing validation of the results produced being performed by the client (ideally with the participation of end users).

Documents

Evaluation plan/Evaluation report, where applicable
If software that already exists in the project is to be adapted/integrated, it is advisable to perform an evaluation as early as possible (for information on how to do this, refer to stdSEM, Design phase, subphase "Design when using existing software")
stdSEM evaluation plan
stdSEM evaluation report

Styleguide
With "user-interface-heavy" projects, it is important to draw up a styleguide as early as possible and to coordinate this styleguide with the client. Experience has shown that this saves a lot of rework later on
e-SEM graphical user interface styleguide

Documentation of solution
The documentation of solution is the central document for solution design and implementation. It serves as technical document for the maintenance/further development of the solution. In the case of a first release, the documentation of solution is created for the first time (the description of the planned architecture is taken over into this document), for any subsequent releases, the document is updated accordingly.
stdSEM solution documentation

Test plan
Early planning and documentation of the testing approach is especially important in e-projects (as the time tends to run out towards the end of the project); validating intermediary results by the client/customer during development can in no way replace a system test!
The test plan (and of course also the entire test procedure, test data, etc.) should be drawn up in such a way that it can be carried over from the first release to any follow-up releases.
stdSEM test plan
stdSEM test report

Release notes/acceptance reports
Even given a close cooperation between client/contractor, it is mandatory to comply with the formal milestones (ready for acceptance, releases, intermediary releases, acceptance,...); this might save you a lot of trouble.
stdSEM release note
stdSEM acceptance report

Introduction plan, where applicable
If the project also includes preparing the solution for operation (which is frequently the case in e-projects), the introduction must be planned accordingly. For more information on how to do this, refer to stdSEM Prototyping phase, subphase "Preparation of operations").
stdSEM introduction plan

User manual, where applicable
If drawing up the user documentation is also part of the project, this documentation has to be produced in accordance with the specifications.
stdSEM user manual


Important phase-neutral themes:
.
. Inspections / reviews
With a prototyping approach, ongoing validation by the client is a key factor. 
.
Usability
The user interface has to be optimized and "frozen" at cyclic intervals and in coordination with the client.
.
Change management
Changes in requirements during development must be managed accordingly.
.
Test
Needs to be planned early, system testing is an absolute must
.
Claim management
Only a clear-cut strategy vis-à-vis the client will lead to project success
.
Configuration management
Especially important with a cyclical approach
.
Architecture
Needs to be stabilized and monitored as early as possible