|
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 “ |
|
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.