MHonArc v2.5.0b2 -->
docbook-tc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Gary to investigate ISO 9000 regarding guidelines for accepting or rejecting requests...
Hi guys,
This is a bit undercooked as I am in the process of moving countries and
have so much to do, gosh! However, hopefully I made a worthwhile start...
I found out the ISO 9000 compliances would just mean documenting the steps
properly (I would suggest as series of forms to automate this) and writing a
quality procedure document (to properly document and explain the processes).
The rest of this mail is a start at suggested some useful structure elements
for:
1. The Forms
2. The Quality procedure document
...it needs quite a bit more work done but I am interested firstly to see
what people think before I spend more time reworking some of the
architecture:
PART1: CHANGE/FEATURE THREE PHASE FORM SUBMISSION
+ Submission Phase
+ Change/Feature Proposal Form
+ Control Information
- Raised date: (system generated)
- Change Proposal number: : (system generated)
+ Identification
- Requested by: (mandatory from originator)
- Company: (optional from originator)
- Department: (optional from originator)
- Email: (mandatory from originator)
- Address: (optional from originator)
- Telephone: (mandatory from originator)
+ Summary of changes:
- Title: (mandatory from originator)
- Purpose: (optional from originator)
- Description of problem issues: (mandatory from originator)
- Justification of change: (optional from originator)
- Current workaround: (optional from originator)
- Change Type: (code | documentation)
+ Assessment Phase
+ Change management Control
- Request for change (RFC) initial notification date:
- Embargoed by:
+ level of industry support
- priority:
+ likely impact
- Configuration items potentially affected by change:
- Impact on documentation:
- related changes:
+ solicit views
- Synopsis of change
- Implementation notification required:
- Proposed Release date/or implementation date:
+ Approval Phase
+ reject
- unreasonable implementation time:
- unreasonable cost:
- no industry support:
- other reasons:
+ defer
- unreasonable implementation time:
- unreasonable cost:
- no industry support:
- other reasons:
+ approve
- Allocated to:
- Allocated by:
- Date proposed for system Testing:
- Date proposed for Live running:
- Action by:
- Functionality checked by:
- Code/Standards checked by:
- Other systems impact checked by:
- Comments
+ evaluated
+ fixed
+ tested
PART2: CHANGE/FEATURE REQUEST PROCEDURE DOCUMENT
+ Introduction
- Definition: Formal Change/Feature Proposal for docbook
+ Objectives to formally document
- Desired change to the docbook.
- Rationale for the change.
- Requestor of the change.
+ Benefits
- Clarification of request
- Requestors contact details
+ Contents
- Requestor, Request Date, Change Request Identifier, Priority etc.
Rationale, Impact, Status, etc.
+ Responsibilities
- Evaluator: (Members of TC)
- Implementer: (Members of TC)
- Tester: (Members of TC)
+ Process Steps
- Feature/Change request received from web Form
- Send Confirmation of received request
- Raise Feature/Change request for assessment at telecom
- Agree, reject or defer democratically in TC
- Post implementation checks
- Amend Request Status
+ Change/Feature request overview diagram:
- (add process diagram here)
+ Preconditions
- Change request form must have been filled in correctly
- The change control meeting achieves quorum
- etc...
+ Guidelines
- Automated Forms and database
- templates
- standards
+ Conventions
- Work Flow
- Content and Format Standard
- Template
- Inspection
Kind Regards,
Gary Cornelius
--
+----------------+-------------------+
| Gary Cornelius | gary@cornelius.bz |
+----------------+-------------------+
| 15 Queensberry Street, Apt. #21 |
| Boston, MA, 02215, USA |
| Telephone: 617 670 3907 |
+------------------------------------+
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]