"R&I" (Receiving and Inspection) refers to the verification of the conformity of the work with the request stated in the validated design file. R&I is a rigorous, methodological process carried out upon receipt of the order. It is carried out in accordance with the inspection file established by the client, a compilation of the documents that design the way in which the work must be inspected. Sometimes, R&I is considered provisional during a time period called the warranty period.
This stage ends on expiration of the warranty period by drafting a receipt document (record of final receipt) signed by the contractor and the client, containing the client's comments, and, if applicable, the client's refusal to accept the work if it does not conform to the specifications.
Testing consists of verifying the conformity of the capabilities of the work with the client's technical specifications.
Setting up pilot sites allows you to test the work in its technical dimensions and in terms of the organization and user response. The experience of pilot sites allows for preparation for deployment, a better understanding of the requirements, and early identification of difficulties.
This refers to mass deployment of the work at the end users' locations. Successful deployment at pilot sites does not automatically mean that the general deployment will be successful. In fact, during experimentation, users have a motivation that the end users lack. Additionally, each malfunction of the work is recorded during experimentation. deployment generally implies changes in the way the users work, which is an obstacle for acceptance of the product by the users. In fact, end users generally look for a psychological motivation in their professional lives (increase in revenue and hierarchical position) and job security. A change in their work habits is an obstacle to these objectives.
Thus, "change management" is used to refer to all elements that allow you to ensure that the end users will really use the product, and therefore change their habits. This term encompasses, among other things, the training of users in the use of the product, as well as user support (hotline).
On the other hand, if the project is intended for a large number of end users, it is not always feasible to go directly from experimentation to general deployment. Depending on the work, it may be necessary to do tests on increases in output, i.e., simulate a gradually increasing number of users in order to estimate whether the product is potentially able to tolerate the total output (simultaneous use by the number of users provided for in the specifications).
The capitalization phase consists of taking inventory of the product by capitalizing, i.e., archiving, the technical know-how derived from the project in order to improve the efficiency of the managment of future projects. Thus, it is indispensable at the end of the project to organize the "remembering" of this information and to allow them to be recovered. This process of organizing is called "knowledge management, generally abbreviated as "KM".
An debriefing on the project is beneficial for those involved, because it allows for a review of all of the project's deviations and the corrective measures taken.
Maintenance refers to all modification operations carried out on operational software, leaving its basic functionalities intact. Thus, maintenance allows you to keep a system in operation while correcting anomalies in the work and taking into account the users' requests for improvements.
A distinction is generally made between corrective maintenance, which consists of correcting errors of the system, and upgrade maintenance , which consists of modifying the system to add new functionalities.
Results for Project implementation phase
Results for Project implementation phase
Results for Project implementation phase
Results for Project implementation phase
Results for Project implementation phase
Results for Project implementation phase