[29] in Athena_Backup_System
For your comments: Acceptance Criteria draft...
daemon@ATHENA.MIT.EDU (salemme@MIT.EDU)
Wed Oct 12 18:01:00 1994
From: salemme@MIT.EDU
Date: Wed, 12 Oct 94 18:00:40 -0400
To: athena-backup@MIT.EDU
Acceptance Criteria for the Athena Backup System (ABS)
[Note: This is my own PR blurb, which may or may not be appropriate here...
Tim, Diane, Jonathon, Dave, if you want to eliminate, change or add anything
anywhere in this doc, please mail me your changes and I'll incorporate them.
Also, the "Documentation" section is what Tim, Dave and I talked about
this morning, but I've thrown some other things in just to get something in
here to work with. Suggestions, comments, please!
Anne]
The Athena Backup System (ABS) will be a robust, configurable, distributed
system intended to be easy to use and manage by the Athena Systems Support
group. We want it to be an elegant addition to the Athena environment,
requiring minimal staff time for running, and minimal developer time for
maintaining. It is intended to outlast AFS and 8mm tape drives, both of which
we expect will eventually be replaced by newer technology.
The following set of Acceptance Criteria will be used for evaluating or
accepting the system throughout its developemnt and hopefully into its gradual
incorporation into the production Athena environment. We realize that as
the system evolves, this set may need revision. There are currently six areas
for which we define acceptance criteria: Documentation; Code; Bug-tracking,
fixing and regression testing; Beta test plan; Operational phase-in plan; and
Support plan.
*DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT*
This is an initial draft of Acceptance Criteria to be used for the Athena
Backup System (ABS). We would like to come up with a practical set of criteria
as soon as possible, so please send comments or suggestions to
'athena-backup@mit.edu'
*DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT*
A. Documentation
Architectural design
[Text?]
Detailed design
[Text?]
Coding Style Guide
There will be a coding style guide, based on the Free
Software Foundation's GNU Coding Standards, but modified
for the ABS.
User Guides
There will be three guides produced, each for a different
audience: Programmers Guide (for developers), Administrators
Guide (for ABS administrators), Operators Guide (for ABS
operators). Each guide will have the same overall style and
organization, and cover the UI, the Master, the Tape Slave,
and other components of the ABS in a level of detail that is
appropriate for its audience. These guides will be kept
current with each other, the code, the man pages, and the
operating environment.
man pages
There will be man pages to provide online quick references
for the ABS, each of its major components (UI, Master, Tape
Slave, and others), and for specific ABS commands. These
man pages will be kept current with the code.
B. Code
Code management
[Text? mention RCS, which compilers, debuggers, etc. we're
using?]
Unit testing
Every function will be unit-tested.
Code inspection and analysis
The code style will be consistent with the Coding Style Guide.
We will use whatever tools we can to aid in analysis of the
ABS code, and will document how such tools are used in the
ABS project. [Do we want to name any here?]
Performance verification
The ABS components will meet the specifications (?which ones?)
and will function as documented in the User Guides and man
pages
C. Bug tracking, fixing and regression testing
[Text?]
test plan
test suite (ongoing; maintained as part of project)
unit testing
functional testing
stress testing
D. Beta test plan
[Text?]
E. Operational phase-in plan
[Text?]
F. Support plan (developer involvement after ABS is in production)
[Text?]
