Development Process for Web-Enabled Applications – Release & Delivery

Software Release and Delivery

Objective

The purpose of this procedure is to ensure that the Software Items and documents delivered to the client are of the correct version and of required quantity.

 

Scope of the Procedure

This document describes LinksMultiple’s method of handling the process of Release and Delivery of products. If any deviation from the described methodology is to be taken the same must be identified in the project specific project plan and approval from the concerned superior.

 

Users of the Procedure

The users of this document are:

·         Project Managers

·         Project Leaders

·         Team members

·         Quality Personnel

·         Quality Manager

 

Entry Criteria

Release and Delivery Process starts when:

 

·         Properly tested and corrected software, manuals, or any other deliverable ready for release to customer

 

Process Description

The delivery process involves the delivery of both Software and documents (Deliverables) to the client.

 

This process is a two-stage activity. In the first stage, the Project Manager releases the deliverable. The deliverable could be a document or a code. In the case of code releases, the form Appendix A1 - Software Release Note should be used. In the case of document releases, the Appendix A3 – Document Release Note should be used.

 

The Project Manager will coordinate this activity, with participation from QA and the Project team. During the release of the deliverable, the Project Manager should ensure that all the programs/items have been passed by QA and have been correctly copied onto the media of delivery (CD, tapes or diskettes.) The PM should verify that the version of the programs/items that is being delivered to the client is correct.

 

The second stage is the physical shipment of the software to the client. This process is divided into the following important sub-activities, they are:

·         Replication

·         Packaging

·         Release

 

Replication

Project Team should replicate the items to be delivered, by referring to the Contract/ Proposal. The following aspects should be considered during replication.

 

·         Number of copies of each item to be delivered

·         Type of media , recording format

·         Copyright and licensing concerns

·         Contractual obligations with respect to the documents to be delivered with the released items

·         Custody of master and back-up copies, including disaster recovery plans

 

Packaging

PM should ensure that depending on the type of item (documents or media containing software) appropriate packaging of the items is done. Documents should be properly packed. The packet containing the documents is to be securely sealed with packing tape or with any other suitable item. To prevent any physical damage to the media article containing software, proper packing material is to be used. The destination and the return address including the telephone number should be marked on the cover of the package.      

 

Wherever it is applicable and required, the media containing software should be registered with the staff in the commercial department, for customs clearance.

 

Release

For software releases, a Software Release Note (REL-F001) should be prepared. For release of documents, the Document Release Note (REL-F003) should be prepared. Additionally, an entry should be made in the Release Log (REL-F002), which gives a summary of all the releases effected, over a period.   

 

Once the release is authorized by the Project Manager and the Quality Manager, the back up of the software and all other associated documents shall be taken and a release baseline shall be established. For more details on release baseline, refer to the Configuration Management procedure (MT/TECH/CM).

 

The Project Manager should inform the System administrator to take the back up of the software and all other associated documents and archive them at 2 different locations. Refer to MT/SUP/SAM for disaster recovery and storage of software.

 

Release Authorization

The releases of documents and code (deliverables) are made by the project manager to the customer. Before such releases are made, the QA manager should certify the release of the deliverable. This is done on the Software Release Note (REL-F001). The QA manager checks to see if the testing has been adequately done, if test results have been tracked to closure, etc., before certifying the release to the customer.

 

It could so happen that the QA manager stops the release of the deliverable. In such cases, the project manager should re-work the item and produce the item for certification by the QA manager. On the QA manager being satisfied with the quality of the deliverable, the project manager can release the same to the customer. The project manager does not have the authority to release the deliverable, if the QA manager has held up release.

 

Situations could warrant that the defective deliverable needs to be released to the customer, without correction, due to pressures from the customer. In such situations, the matter is referred to the CEO, who has to then certify that the product can be released after recording the defects in the product. These defects should be sent to the customer along with the release, indicating that they are being worked on.  Such a release is termed as a “Guarded” release. The release forms have provisions to record this information. In a Guarded release, a document is prepared with all the known bugs / defects / problems and sent to the customer. This will ensure that the customer knows that there are problems with the release. Once the problems are corrected, a Normal” release is made.

 

 

 

 

 

Back to the LinksMultiple eBay Auction | eBay Shopping home page

Copyright 2005 LinksMultiple - all rights reserved. No part of this information may be copied or reproduced without prior written permission.