[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | Alpha Verification conference |
Notice: | QTV Bug Chasers! Practicing the fine art of defect detection, reporting and reproduction... |
Moderator: | STAR::JFRAZIER |
|
Created: | Wed Mar 20 1991 |
Last Modified: | Tue Jun 03 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 487 |
Total number of notes: | 2459 |
486.0. "Hardware Evaluation Template - Revised" by STAR::S_MARCHESANO () Mon May 05 1997 15:26
Hardware Project Evaluation Template
Please make sure all of the questions are answered. If any question is not
applicable indicate that, but make sure they have been asked and answered.
--------------------------------------------------------------------------------
1.0 General Information
Name of project:
Date of this evaluation:
Engineering contact:
Evaluator:
Targeted Release:
Project Priority for the release:
Purpose of Project:
2.0 Hardware Description
- Is this a new piece of hardware or platform?
- If the project is a DSR platform or adapter/controller enhancement
describe what the changes/enhancements are?
3.0 Type of Validation Effort and priority
- Will this project require a validation or is it an inuse project?
- If this is an inuse and does not require a validation plan, briefly
list the areas that will be target tested.
4.0 QTV Hardware Reguirements
Identify the hardware required for this project. The list should include
currently supported hardware and proto type hardware if this is a new
hardware validation. Remember to include cluster, network and storage
needs.
- Who will provide the prot hardware for QTV?
5.0 Development Status
What stage of Life of a Project (LOP) product development stage
is the project currently in? Put an X preceding the development stage.
Project Phase Status (%complete/not planned/n.a.)
------------- ------------------------------------
____ Problem Statement
____ Investigation
____ Draft Plan & Design
____ Detailed Project Planning
____ Detailed Design/Functional Spec
____ Implementation
____ Validation Testing
____ Assess Doneness
Page 2
Which project documents are currently available? ("D"=Draft, "F"=Final)
State if the doc isn't applicable, or the info is in another plan.
Document Location/Comments
-------- -----------------
____ Investigation Report
____ Product Requirements
____ Project Plan
____ Functional Specification
____ Design Specification
____ Development Plan
____ Defect Containment Plan
____ Unit Test Plans
____ Test/Validation Plan
____ Integration Test Plan
____ Final Qualification Plan
____ Doneness Criteria
____ Others (specify)
6.0 OpenVMS Changes Required for Support
List any facilities affected by this project and indicate if the
code is modified or new.
New/
Module Facility Description LOC Modified
7.0 Defect Containment Status
Briefly describe the defect containment activity by answering the
following questions. If there isn't any defect containment activity
planned or implemented please indicate that also. To estimate the
project defects use the following formula:
projected number of defects = # uncommented source code lines
-------------------------------
100
Defect Identification Goals: % Completed to date
---------------------------- -------------------
%code inspected:
%code unit testing:
%code integration tested
%code(features?) validated
Defect Data
Estimated number of defects for this project:
# Defects found by
------------------
Design reviews/inspections
Code reviews/inspections
Unit Test
Integration Test
# of defects found to date
Page 3
8.0 Configurations
Briefly describe or list the supported configurations or options for this
project.
- How will this project be supported?
Mixed Architecture Cluster Impact:
- Could/will this project impact a Mixed Architecture VMScluster
features, performance, reliability or interoperability?
Are there any firmware dependencies for this project?
Supported Options/Configurations list:
9.0 Risks
List any risks for this project during this release.
Software:
Hardware:
Resources:
10.0 Dependencies
List any dependencies that may have a negative impact on this project
during this release.
Software:
Hardware:
Resources:
Page 4
11.0 Inputs to be considered for the Statement of Quality.
Use the following list of quality factors as a guide when writing
the statement of quality for this project.
efficiency - How well does the product respond? Is the
performance consistent with other (similar) aspects
of the system? If there are any explicit performance
requirements, are they met?
reliability - How reliable is the product when operated under
load or stress conditions? Does the product perform
consistently over an extended duration? Does the
product perform as expected under negative conditions?
(no data corruption, no innocent bystanders effected)
correctness - Does the product meet its requirements? Are
all supported functions present and working as expected
based on the product description and on the user
documentation?
integrity- Is access to data provided when appropriate? Is
access to data prevented when appropriate? Are there
any explicit security requirements on the product?
Are they met?
usability - How easy to use is the product? Does the ease of
use match expectations (based on experience with
similar products)? How does the product match up to
any explicit ease-of-use requirements?
interoperability - How does the product interact with other
production systems? Do all explicit interoperability
aspects of the product work as expected? How does the
product perform in a Mixed Architecture Cluster?
T.R | Title | User | Personal Name | Date | Lines
|
---|