Sequoia it development methodology
 | welcome page | projects | contact us | get  the free off-line version |

REALIZATION, ACCEPTANCE, LAUNCH

Phase RA.4 Follow-up and upgrade.

RA.4.1 Purposes

(-)  Set up the conditions in order that the application evolves correctly in the future

(-)  The future evolution will come:

either from the correction of mistakes and nonconformities

or from improvements suggested by the analysis of the activity and marketing reports

or from de market evolution

customers requirements & habits

competitors advances

or from the evolution of the technology

(-)  Set up the conditions:

(-)   the next changes should ensure

that they respect the quality and reliability purposes and norms, the methodology fixed by the Architecture Design, the Preliminary Study and the Detailed Study, together with the coherence of the whole;

that the Architecture Design, the Preliminary Study and the Detailed Study will be updated whenever required.

(-)  the next updates must be launched in production without raising problems, by respecting the acceptance criteria.

RA.4.2 Realization actions

(-)  The updates and add-ons must be brought to the different levels of analysis and realization:

(-)  System Architecture Design

(-)  Preliminary Study

(-)  Detailed Study

(-)  Realization

RA.4.3 Project management actions

(-)  perform an individual follow-up of every change request; estimate the needed resources

follow as well the change requests coming from the users as those coming from the IT department self

Rank the requests; manage the priorities; set up a planning

(-)  Do a clear distinction between errors corrections and new or complementary requests; control the resources used by all three types of intervention.

RA.4.4 Quality assurance actions

(-)  Open the Changes follow-up file

(-)  Analyze the request before any realization

Identify as precisely as possible the components affected by a change request

search for the real cause of the detected dysfunction symptoms

evaluate systematically the impact of every change on the different analysis levels; if there is an impact, adapt the concerned analysis parts

let validate the change request by the due responsibility level

Identify all possible consequences of a change

(-)  links between several revisions

(-)  requirement of a conversion/correction of the existing data

(-)  revision of the documentations

(-)  change in the operating mode; requirement of new training.

(-)  Inform systematically the people having raised a change request of its follow-up

(-)  Launch in production of the revisions.

(-)  Test the revision

(-)  take care that all unit tests are correctly passed

(-)  control the possible consequences on the performances

(-)  when links exist between several components, take care that they are all installed at the same time

(-)  Inform:

deliver the documentation

inform about the changes in the operation mode

Inform systematically the people at the origin of the change request when it is launched in production

Inform systematically of all changes the key-users and the people in charge of the operations and of the help desk

(-)  When revisions are launched in emergency, without that all quality actions are performed:

make sure that the due quality actions will be applied as soon as possible

these revisions must be specially traced; the reason and the responsibilities must be noticed.


copyright (c) séquoia sprl (www.sequoia.be), belgium, 1999-2000. all right reserved.