CMP by keralaguest

VIEWS: 13 PAGES: 17

									Configuration Management Plan
     For PennDOT ATX Studio Project


               Version 0.6




             Team Stalagmite:
               Dan Abramovich
                   Jeff Ditillo
               Andrew Guletsky
               Oksana Schubert
              Alexey Stolpovskikh
                 Dehua Zhang
Configuration Management Plan



Document Details
 Title              Software Configuration Management Plan
 Author(s)          Team Stalagmite
 Reviewer(s)        Dan Abramovich
                    Jeff Ditillo
                    Andrew Guletsky
                    Oksana Schubert
                    Alexey Stolpovskikh
                    Dehua Zhang
 Team name          Stalagmite
 Team members       Dan Abramovich
                    Jeff Ditillo
                    Andrew Guletsky
                    Oksana Schubert
                    Alexey Stolpovskikh
                    Dehua Zhang
 Project mentors    Tony Lattanze, Eric Nyberg
 Editor(s)          Amanda Rooker




Document Revisions
 Revision      Date             Author(s)                               Comments
 0.1         03/10/03    A. Guletsky                 Added title page and headers and footers.
                                                     Added Document Details, Document Revisions
                                                     and Table of Contents sections. Incorporated
                                                     feedback from Jeff.
 0.2         03/15/03    A. Rooker                   Merged IEEE template with existing 0.1
                                                     version.
 0.3         03/20/03    A. Guletsky                 Incorporated feedback from 0.1 version review:
                                                      Improve clarity;
                                                      Spell out who does what;
                                                      Spell out SourceSafe operations;
                                                      Differentiate initial phase vs. steady state;
                                                      Specify 24 hour feedback time limit.
                                                      Add history support to Rational Rose
                                                         document.
                                                      Moved unused sections into Appendix.
 0.4         04/08/03    A. Guletsky                 Incorporated feedback from Jeff and Dan:
                                                      Amended 24-hour deadline for feedback
                                                         with rules for deadline extension
                                                      Owner must check out the file at the
                                                         beginning of the revision.
 0.5         05/01/03    A. Guletsky                 Incorporated feedback from Amanda and
                                                     Oksana. Clarified a few points about 24-hour
                                                     feedback deadline. Reduced the amount of bold



Team Stalagmite                           Page 2 of 17                                    10/27/2011
Configuration Management Plan


                                           text per feedback from Amanda.
 0.6         05/03/03                      Added details to Create/Update Code Units,
                                           Code Review, and Perform System Build
                                           sections, added Defect Tracking section




Team Stalagmite                 Page 3 of 17                                   10/27/2011
Configuration Management Plan



Table of Contents

Introduction ................................................................................................................... 5
    Purpose ................................................................................................................................. 5

Tools, Techniques, and Methodologies ...................................................................... 5
    Updating Documents through SourceSafe............................................................................. 5
      Prerequisites..................................................................................................................... 5
      Procedure for Revision ..................................................................................................... 6
       Initial state ....................................................................................................................... 6
       Steady State .................................................................................................................... 6
    Updating Documents through Encoded Filenames ................................................................ 7
      Prerequisites..................................................................................................................... 7
      Procedure for Revision ..................................................................................................... 7
       Initial state ....................................................................................................................... 7
       Steady state .................................................................................................................... 7
    Document Update Process customizations ........................................................................... 8
      Process customization for PennDOT Use Cases.doc ....................................................... 8
      Process customization for atx_usecase.mdl ..................................................................... 8
    Create/Update Code Units ....................................................Error! Bookmark not defined.8
    Code Review .........................................................................Error! Bookmark not defined.8
    Perform System Build ............................................................Error! Bookmark not defined.8

Appendix ...................................................................................................................... 12




Team Stalagmite                                          Page 4 of 17                                                       10/27/2011
Configuration Management Plan



Introduction
Purpose
This Configuration Management Plan (CMP) shall provide an update mechanism for documents.
The objective for CMP is to:
   Resolve repeatedly identified problems through scripts.
   Provide simple instructions and clear sequences of steps.
   Define process defaults while allowing for customization to specific needs.
   Promote feedback and encourage team participation.
   Allow for quick turnaround between revisions.

All team artifacts are updated using one of two following approaches:
(1) Through configuration management software (Microsoft Visual SourceSafe).
(2) Using encoded filenames.


Tools, Techniques, and Methodologies
Updating Documents through SourceSafe

Prerequisites

Each revision of a document requires a revision owner (or owner). The owner’s duties are provided in
detail in the “Procedure for Revision” section:
   Initial state
    - Create the first draft of the document.
   Steady state
    - Distribute the latest version to the team for contributions;
    - Solicit and consolidate feedback from team members (or team);
    - Provide any special care instructions to the team;
    - Update the history of the document;
    - Release the new version of the document;
    - Perform any post-release steps.
    - Ensure that the master version and all changes conform to formatting and notational standards for
         the document.
    Each revision encourages feedback from team members (or team). The team’s duties include:
    - Follow owner’s procedures for finding the document to be reviewed. Use defaults if no
         instructions are provided.
    - Provide revisions, questions and comments.
    - Return the document to the owner for consolidation. Use defaults if no instructions are provided.
    - Approve the consolidated revisions.




Team Stalagmite                          Page 5 of 17                                     10/27/2011
Configuration Management Plan


Procedure for Revision

Initial state

1. The owner will create an initial draft of the document. If a template is available, the owner is
   responsible for using the template. Default: if a template is not available, the owner should use a
   format similar to our other documents or request the necessary template from the technical writer.

2. The owner will distribute the initial draft of the document to the team. The owner will choose the
   distribution mechanism. The preferred distribution mechanism is broadcast email. The alternative
   mechanism is placing the file in a folder on \\dogbert\penndot\all file share. In this case the owner is
   encouraged to send a broadcast email with the pointer to document location.

    When distributing the initial draft of the document, the owner will specify the return mechanism for
    revisions. If the owner does not specify anything, the default mechanism to be used is email.

3. The team will provide feedback. All revisions are welcome from everyone. For more details, go to
   step 4 of Steady State.

Steady State

1. The owner will determine the scope for revision suggestions and comments, which will be collected
   using a collaborative approach (usually either a round robin or a broadcast approach). If the owner
   does not specify a scope for revision, the default is that all revisions are welcome from everyone.

2. The owner will specify the return mechanism for revisions to the team (for example, email or file
   sharing). If the owner does not specify a mechanism, the default is to return revisions by email.

3. When a revision is identified, the owner will Check Out the document using SourceSafe. This will
   maintain the integrity of the changes and serve as an indication to the rest of the team that a revision
   is in progress. To check out a document from SourceSafe:
       Highlight the document;
       Select SourceSafe -> Check Out (Ctrl+K) menu command;
       Specify (if necessary) the working folder;
       Press OK.

4. For individual updates, the team will get the latest version of the document from SourceSafe or use a
   revised copy distributed from the owner. To get the latest version from SourceSafe:
      Highlight the document;
      Select SourceSafe -> Get Latest Version (Ctrl+G) menu command.
      In the dialog that comes up, check Make writable checkbox.
      Press OK.

5. The team will perform updates and submit them back to the owner. Individual updates of Word
   documents should be done with Track Changes turned on. This command is located under Tools ->
   Track Changes.

    When finished, the team will submit updates to owner for consolidation. Refer to step 2 for delivery
    mechanism. The submitted file name should be tagged with reviewer’s name or email alias.




Team Stalagmite                             Page 6 of 17                                       10/27/2011
Configuration Management Plan


    ALL UPDATES SHOULD BE DONE WITHIN 24 HOURS FROM THE BEGINNING OF
    REVISION. If a team member wants to contribute but cannot do so in the 24 hour period, the team
    member is responsible for requesting a deadline extension within 24 hours. The owner may accept
    late changes or request the author of the late changes to integrate them into the latest revision.

6. The owner is responsible for integrating individual contributions and preparing a draft of the new
   version.

    The recommended tools for integration are:
      Microsoft Word. The command to merge files is located under Tools -> Compare and Merge
       Documents.
      Rational Rose. The tool to merge files is called Model Integrator. It is located under Tools ->
       Model Integrator.

7. The owner will distribute a new draft to the team for final comments. The new draft should have an
   updated history for the team to see what changes where made.

    ALL TEAM COMMENTS SHOULD BE MADE WITHIN 24 HOURS OF DISTRIBUTION. If a
    team member wants to contribute but cannot do so in the 24 hour period, the team member is
    responsible for requesting a deadline extension within 24 hours. The owner may accept late changes
    or request the author of the late changes to integrate them into the latest revision.

8. The owner will update the document in SourceSafe. To update the document in SourceSafe:
   - Highlight the document;
   - Select SourceSafe -> Check In (Ctrl+U) menu command.
   - In the dialog that comes up, paste into Comment: field identical comments from document
      history.
   - Press OK.

9. The owner will perform post-update tasks. These tasks are document-specific. For example, a Word
   document may be converted into a web page and published on team’s website. It is also good practice
   to send an email to relevant stakeholders notifying them of the new version, identifying the changes
   in the new version, and informing them where they can access it.


Updating Documents through Encoded Filenames

Prerequisites

The prerequisites for updating documents through encoded filenames are the same as those listed in
Updating Documents through SourceSafe.


Procedure for Revision

Initial state

The initial state is the same as the state listed in Updating Documents through SourceSafe.

Steady state



Team Stalagmite                            Page 7 of 17                                       10/27/2011
Configuration Management Plan


These steps match those listed in Updating Documents through SourceSafe with following exceptions:

3. For individual updates, the team will copy the latest version of the document from a subfolder on
   \\dogbert\penndot\all file share. All updates should be done using the private copy of the document,
   unless otherwise is specified by owner.

    The owner has a right to distribute his/her private version of the document to the team.

7. The owner will update the document on file share. To update the document on file share:
   - Rename current master document to include version number in the file name. For example,
      requirements_specification 0.3.doc.
   - Copy the new master document to the file share.


Document Update Process customizations

Process customization for PennDOT Use Cases.doc

   The document is updated through SourceSafe. The latest version is located under docs/Requirements
    folder in team’s SourceSafe database (\\dogbert\penndot\all\vss).
   If no revision owner is specified, the default revision owner is Jeff Ditillo (jditillo@cs.cmu.edu).
   Special care instructions are used when performing updates.
    1) Use case titles should be bookmarked with usecaseN. This is necessary for integration between
        the document and the Rational Rose model. To insert a bookmark in Microsoft Word:
            Highlight the use case title;
            Select Insert -> Bookmark… menu item. If it is not visible, select the chevron at the bottom
             of the Insert menu;
            Type the bookmark name in Bookmark name: field;
            Press Add button.
   Post-update tasks include publishing the document on the team’s website. This is necessary because
    the web page will be referenced by the Rational Rose model.

Process customization for atx_usecase.mdl
  The document is updated through SourceSafe. The latest version is located under docs/Rational folder
   in team’s SourceSafe database (\\dogbert\penndot\all\vss).
  If no revision owner is specified, the default revision owner is Dehua Zhang (zhangdh@cs.cmu.edu).
  Special care instructions are used when performing updates.
   1) Naming convention:
           Use strong verbs for use cases names and following capitalization: Withdraw money.
           Use strong verbs for associations and following capitalization: Enter PIN.
   2) Associations:
           In a class diagram, there should be only one association between classes.
           If you need to delete an association, use Ctrl+D, not Del. If this practice is not followed, we
            will have many dangling associations. Use Del only if you are certain that the association is
            reused in other class diagrams.
   3) Whenever a package is changed by the team:
           The team is responsible for specifying modifications for that package.
           The owner is responsible for consolidating modifications from the team and posting them in
            Documentation field for the modified package. There are two ways to insert text into
            Documentation field:



Team Stalagmite                            Page 8 of 17                                        10/27/2011
Configuration Management Plan


           1. Right mouse click on the package and select Open Specification item in the context
               menu. The Documentation field is located in the dialog that appears (General property
               page).
           2. Select the package in the Browser pane on the left. Type in the window below Browser
               pane.
          All packages should be checked in separately.
   4) If new use cases are added, they should be matched with a verbal description in PennDOT ATX
      Use Cases.doc and coordinated with its owner. The person creating new use cases is also
      responsible for inserting hyperlinks that point to a web page with a verbal use case description.

Create/Update Code Units

Create New Code Unit
         a. The assigned developer is responsible for reviewing the architecture and clarifying the
            relationship between architectural components and the target code unit with other team
            members (e.g. the architect) as needed.
         b. (Optional) The developer will create an appropriate UML diagram to document the
            design of the code unit
         c. The developer will create one or more java source files with related architecture
            descriptions included in the header of the file(s) and a design description included in the
            header of each class. Inputs and outputs for public methods should also be documented.
         d. Code shall be written in adherence to Stalagmite Coding Standards
         e. Each unit shall be tested by the developer to ensure satisfaction of related software
            requirements.
         f. Each unit of code shall be tested by creating a test class and executing this class using
            JUnit software (included in JBuilder).
         g. The developer is responsible for submitting the unit to at least one other team member for
            review.
         h. After a review is performed (and issues resolved) and the JUnit test is run without defects
            or defects that can not be resolved (e.g. dependencies on other unfinished components)
            are logged in the defect tracking system, the source code is ready to check into the code
            management system (SourceSafe)
         i. All source files and related documents should be Checked In to SourceSafe within the
            project structure defined by the Configuration Manager.
         j. Check-in notification should be emailed to the rest of the team with the following
            information:
                  i. Task ID (from Stalagmite Summer Schedule)
                 ii. Brief Code Unit description
                iii. Source files added/deleted/updated
                iv. Defects filed/fixed
                 v. Affected documents added/deleted/updated
                vi. Test class names
               vii. Author name
              viii. Reviewer name
                ix. Comments

Update Code Unit

       When revision identified, the developer will Check Out the related source file(s) using
       SourceSafe. This will maintain the integrity of the changes and serve as an indication to the rest
       of the team that a revision is in progress.


Team Stalagmite                           Page 9 of 17                                       10/27/2011
Configuration Management Plan




Code Review
           k. Team members who accept the role as a reviewer are required to respond to the
              developer within 24 hours of the request.
           l. If for some reason a team member cannot act as a reviewer, the requesting developer
              should be notified immediately.
           m. Code units should be reviewed to ensure that the design adheres to the system
              architecture, the design is clearly understood, the design appeals to the reviewer’s sense
              of reason, and the code adheres to the Stalagmite Coding Standards.
           n. The reviewer should respond either verbally or via email to the developer.
           o. The developer is required to address all issues agreed upon in the review before the code
              is considered complete. If this is not possible, the developer must log all remaining issues
              in the defect tracking system to be resolved as soon as possible.

Perform System Build

Daily Build and Test

       At a designated, non-peak hour of each day, an automated build will be launched using (TBD)
       software. This build will involve the following:
               Check out the latest version of all existing source files to the defined working directories
       in SourceSafe
               Perform build using Ant software with the build script maintained by the Configuration
       Manager.
               Output results to a file identified with the date and time of the build that identifies any
       errors or warnings encountered in the build.
               After the build is successfully completed, the test classes for each code unit will be
       executed automatically using Borland JUnit (See PennDOT ATX Test Plan for details). These
       tests are referred to as Regression Tests.

Integration Builds

       On the dates identified in the Stalagmite Summer Schedule and as needed (identified by the Test
       Mgr – for example, bug fix releases), the Configuration Manager will perform Integration builds
       that will involve the following:
               Check out the latest version of all identified source files to the defined working
       directories in SourceSafe
               Perform build using Ant software with the build script maintained by the Configuration
       Manager.
               Output results to a file identified with the date and time of the build that identifies any
       errors or warnings encountered in the build.

Defect Tracking

   Defects will be logged into the Defect Tracking system for the following reasons:
    Issues are identified during design/code/review that can not be resolved before the code is
      checked-in due to circumstances beyond the developer’s control (e.g. dependency on other
      unfinished code). In this case the developer is responsible for logging the defect and assigning it
      to himself/herself.



Team Stalagmite                           Page 10 of 17                                        10/27/2011
Configuration Management Plan


      Test Manager discovery of errors when reviewing results of nightly regression tests. These will
       be assigned to the responsible developer to be completed before any new coding tasks are started.
   Issues discovered during Test Manager’s review of JUnit test classes and results. Issues to be
   identified include unresolved errors listed in results or deficient test classes. These will be assigned to
   the responsible developer to be completed before any new coding tasks are started.




Team Stalagmite                            Page 11 of 17                                        10/27/2011
Configuration Management Plan



Appendix
All text below comes from IEEE Software Configuration Management Plan (SCMP) template. It
is included as reference during document development.

NOTE: This section will be deleted upon review of the above process description by Team
Stalagmite at the onset of the implementation phase.

---
This section shall:
      1. Identify the CM documentation to be retained
      2. State the methods and facilities to be used to assemble, safeguard, and maintain this
           documentation. As part of this, identify any off-site backup facilities to be used
      3. Designate the retention period

Scope
Use this section to identify the software items to be produced and used, the organizations, the
activities, and the phases of the software life cycle to which the plan applies.


Definitions and Acronyms
            CMP                    Configuration Management Plan
            CCB                    Configuration Control Board



References
This subsection shall:
      1. Provide a complete list of all documents referenced elsewhere in the CMP.
      2. Identify each document by title, report number, if applicable, date, and publishing organization.
      3. Specify the sources from which the referenced documents can be obtained.



Management
This section shall describe the organization, and associated responsibilities.


Organization
This subsection shall describe the organizational structure that influences the configuration
management of the software during the development and the operation and maintenance phases.
This shall:
      1. Describe each major element of the organization together with the delegated responsibilities.
           Organizational dependence or independence of the elements responsible for CM from those
           responsible for software development and use shall be clearly described or depicted.
      2. Include an organizational chart or list for the project, which illustrates the structure for
           program/project/system management.
      3. Describe the organization responsible for CM during the operation and maintenance phase.
      4. Describe the interface between the developing organization and the using organization, if any,
           with particular emphasis on the transfer of CM functions in the operations and maintenance
           phases.


Team Stalagmite                            Page 12 of 17                                      10/27/2011
Configuration Management Plan


      5. Specifically cover the organizational relationships with the Configuration Control Board (CCB)
         in the development and the operation, and maintenance phases.


CMP Responsibilities
This subsection shall describe:
      1. The organizational responsibilities for each CM task; for example, identification, control, status
          accounting, and reviews and audits.
      2. The relationships with software quality assurance, software development, and other functional
          organizations required to ensure delivery of the approved final product configuration.
      3. The responsibilities of the users and developer/maintenance activity in the review, audit, and
          approval process during each phase of the life cycle.
      4. Any CM responsibilities of the representatives from each organization participating in the
          product development.
      5. The overall responsibility of the Configuration Control Board.
      6. Any unusual responsibilities such as special approval requirements necessary to meet CM
          requirements.


CMP Implementation
This subsection shall establish the major milestones for implementation of the CMP.

Example milestones include the establishment of:
    1. The configuration control board
    2. Each configuration baseline
    3. Schedules and procedures for CM reviews and audits
    4. Configuration management of related software development, test, and support tools.


Applicable Policies, Directives, and Procedures
This subsection shall:
      1. Identify all applicable CM policies, directives, and procedures which are to be implemented as
          part of this plan. The degree of implementation of each shall be stated.
      2. Describe any CM policies, directives, and procedures that are to be written and implemented
          for this project.

Examples of material which may be covered by policies, directives, and procedures are:
        Identification of levels of software in a hierarchical tree
        Program and module naming conventions
        Version level designations
        Software product identification methods
        Identification of specifications, test plans and procedures, programming manuals, and other
           documents
        Media identification and file management identification
        Document release process
        Turnover or release of software products to a library function
        Processing of problem reports, change requests, and change orders
        Structure and operation of configuration control boards
        Release, and acceptance of software products




Team Stalagmite                           Page 13 of 17                                      10/27/2011
Configuration Management Plan


              Operation of software library systems to include methods of preparing, storing, and updating
               modules
              Auditing of SCM activities
              Problem report, change request or change order documentation requirements describing
               purpose and impact of a configuration change, or both
              Level of testing required prior to entry of software into configuration management
              Level of quality assurance; for example, verification against development standards, required
               prior to entry of software into configuration management.


CM Activities
This section shall describe how the following requirements for CM shall be satisfied:


Configuration identification

Configuration control

Configuration status accounting and reporting


Configuration audits and reviews


Configuration Identification
This subsection shall:

      1. Identify the software project baselines (that is, the initial approved configuration
         identifications) and correlate them to the specific life-cycle phases. For each baseline, the
         following shall be described:
      2. The items which form each baseline (for example, software requirements specifications,
         deliverable software, etc.).
      3. The review and approval events, and the acceptance criteria associated with establishing each
         baseline.
      4. The users' and developers' participation in establishing baselines.

             Elements of a baseline definition might include the following:
               Product name and nomenclature
               Product identification number
               For each new version release, the version release number, a description of the new changes,
                the change release vehicle, the changes to any support software, and the changes to the
                associated documentation.
               Installation instructions
               Known faults and failures
               Software media and media identification




Team Stalagmite                              Page 14 of 17                                     10/27/2011
Configuration Management Plan


      5. Delineate the project titling, labeling, numbering, and cataloging procedures for all software
         code and documentation.


Change Control
This subsection shall:
      1. Describe the level of authority for change approval to be used in each of the life cycle phases.
      2. Define the methods to be used to process change proposals to established configurations. As a
          part of this, this section shall:
              a) Identify the routing of change proposals during each of the software life cycle phases.
                   This may be provided in chart form with narrative support.
              b) Describe the methods of implementing approved change proposals (to include changes
                   in source and object code, and documentation).
              c) Describe the procedures for software library control including those procedures which
                   provide for:
                      Access control
                      Read and write protection for applicable baselines
                      File protection
                      File identification
                      Archive maintenance
                      Change history
                      Disaster recovery
              d) If patches must be used to change object code, describe the methods for identification
                   and control

      3. For each CCB and other change management bodies:
             a) Define the role of each; for example, change review authority
             b) Specify their authority and responsibility
             c) Identify the chairperson and the membership in the organizations, if the organizations
                 have been formed
             d) State how the chairperson and the members (and alternates) are to be appointed, if the
                 organizations have not yet been formed
             e) State the relationships of the developers and the users to the CCB(s)

      4. State the methods to be used for configuration control of interfaces with programs or projects
         beyond the scope of this CMP. If the software changes are required to be reviewed by other
         boards or teams prior to or in addition to the CCB(s), this subsection shall describe these boards
         (or teams, or both) and their relationship to the CCB(s) and to each other.
      5. State the control procedures for associated special software products, such as non-released
         software, off-the-shelf software, user-furnished software, and in-house support software.


Configuration Status Accounting
This subsection shall:
      1. Delineate how information on the status of configuration items is to be collected, verified,
          stored, processed, and reported
      2. Identify the periodic reports to be provided, and their distribution
      3. State what dynamic inquiry capabilities, if any, are to be provided
      4. Describe the means to be used to implement any special status accounting requirements
          specified by the user


Team Stalagmite                           Page 15 of 17                                      10/27/2011
Configuration Management Plan



        Some examples of information normally desired is as follows:
           Status of specifications
           Status of proposed changes
           Reports of approved changes
           Status of product versions or revisions
           Reports of the implementation of installed updates or releases
           Status of user-furnished property; for example, user-furnished operating systems




Audits and Reviews
This subsection shall:
      1. Define the SCM role in audits and reviews to be performed at specified points in the software
          life cycle defined in 1.2 of the SCMP.
      2. Identify the configuration items to be covered at each of these audits and reviews.
      3. State the procedures to be used for the identification and resolution of problems occurring
          during these audits and reviews


Tools, Techniques, and Methodologies
This section shall identify, state the purposes, and describe (within the developers' scope of
proprietary rights) the use of the specific software tools, techniques, and methodologies to be
employed to support CM on the specific project. This shall include the tools, techniques, and
methodologies used to:
      1. Identify software media and media documentation
      2. Bring documentation and media under CM control and formally release it to a user
      3. Document the status of changes made to software and associated documentation. It shall further
           define the tools, methodologies, and techniques to be used to prepare reports for various levels
           of management, such as the project manager, CCB, CM, and the user.




Supplier Control
This section shall state the provisions for assuring that vendor-provided and subcontractor-
developed software meet established CM requirements. As a part of this, this section shall:
      1. Indicate the proposed methods for control of subcontractors and vendors insofar as it impacts
           on the execution of this CMP.
      2. Explain the methods to be used:
             a) To determine the CM capability of subcontractors and vendors
             b) To monitor their adherence to the requirements of this SCMP

As a minimum, the supplier shall be required to prepare and implement a CM plan in accordance
with this standard.


Records Collection and Retention
This section shall:
      4. Identify the CM documentation to be retained




Team Stalagmite                           Page 16 of 17                                      10/27/2011
Configuration Management Plan


      5. State the methods and facilities to be used to assemble, safeguard, and maintain this
         documentation. As part of this, identify any off-site backup facilities to be used
      6. Designate the retention period




Team Stalagmite                           Page 17 of 17                                     10/27/2011

								
To top