Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

ASL template

VIEWS: 11 PAGES: 14

									Name Best Practice               Configuration management plan maintenance
IDnr                             204_BP_E
Date adjusted                    November 23th, 2006
Description of the content       Configuration management plan used in an offshore environment
Type of document                 Example
ASL Process                      Configuration management
Size of the application
management team:                 √ Medium    √ Large
Small (number fte < 10),
Medium (number fte 10 – 20)
and/or Large (number fte> 20).
Remarks
Configuration management plan maintenance
<Example>




Place
Date
Author
Status      Concept 0.1




                                            561c3710-a5d6-42ae-873c-
                                            f57a4f7844ff.doc
                                             14 mei 2012
                                            2/14
Version control

Version   Date    Author   Description
0.1                        Initial document




Distributionlist
Version   Date    To
0.1




                                              561c3710-a5d6-42ae-873c-
                                              f57a4f7844ff.doc
                                               14 mei 2012
                                              3/14
Table of contents

1      Introduction ...................................................................................................5
    1.1      Overview of the Documents .....................................................................5
    1.2      References and Prior Readings ...............................................................5
    1.3      Abbreviations and Acronyms ...................................................................5
2      Configuration Management..........................................................................6
    2.1    Central Repository ...................................................................................6
    2.2    Project Specific Directory Structure .........................................................6
    2.3    Configuration Management Responsibilities ...........................................8
    2.4    Software Life Cycle Data Management Plan ...........................................8
    2.5    Naming and Identification of CIs ..............................................................8
    2.6    Base-lining of Documents ........................................................................9
    2.7    Baselining of Source Code before Release .............................................9
    2.8    Base-lining of Source Code / System Releases ....................................10
      2.8.1     System Testing And Acceptance Testing .......................................10
      2.8.2     Branching Strategy And Forward Port: ...........................................11
    2.9    Incident (Change) Management Plan ....................................................13
    2.10     Configuration Audits ...........................................................................14
    2.11     Project Specific Backup & Recovery Strategy ...................................14




                                                                                                                           561c3710-a5d6-42ae-873c-
                                                                                                                           f57a4f7844ff.doc
                                                                                                                            14 mei 2012
                                                                                                                           4/14
1        Introduction




1.1      Overview of the Documents

This document describes the configuration control process that is to be used for
requesting and managing changes to work products created or maintained by the
members of <> project.
This document will facilitate communication about Configuration identification,
Configuration control, Configuration status accounting & Configuration audits and
reviews of <> project, and reduce the uncertainty around the existence, state,
and outcome of a change / defect that has been requested / reported in a work
product.
Change requests for various applications are put into different Work Orders to
<Offshore facility>. A single work order can have many CRs for the same
application. Moreover, a single application can have many CRs distributed in
separate Work Orders.
The latest version of every application is provided to <Offshore facility> for the
development environment set up.


1.2 References and Prior Readings



1.3 Abbreviations and Acronyms

 Abbreviation /Acronyms               Description / Definition
 CI                                   Configurable Item
 CR                                   Change Request
 PID                                  Project Initiation Document
 SLA                                  Service Level Agreement
 VSS                                  Visual SourceSafe
 WO                                   Work Order




                                                                                     561c3710-a5d6-42ae-873c-
                                                                                     f57a4f7844ff.doc
                                                                                      14 mei 2012
                                                                                     5/14
2          Configuration Management




2.1 Central Repository

 1.      Configuration Management Tool(s) used in the project   Microsoft Visual SourceSafe
 2.      Full path of Project Central Repository including
         server name for documents
 3.      Full path of Project Central Repository including
         server name for Source Code
 4.      Who is responsible for maintaining this Central
         Repository?



2.2 Project Specific Directory Structure

The details of the folders under the Maintenance directory are explained below:

      1. Audits: This folder contains audit related files and folders that are
         conducted as per quality standards laid out by the organization. It
         contains the following sub-folders.
             a. Audit_CheckLists (Contains the following checklists)
                       i. Project_SelfAssessment
                      ii. Knowledge_Transfer
                     iii. PMR
                     iv. MasterAudit
             b. Audit_NCs (Contains any NCs that are raised in the audits
                 conducted for the project)

      2. Customer Supplies (Contains the code and documents supplied by the
         customer)
             a. DBSetup
             b. Documents
             c. Samples
             d. Source_code

      3. Minutes Of Meetings: The Minutes of the weekly status calls (or any
         other meetings) that are held regularly.

      4. KnowledgeStore: To store downloads and reusable components used
         in the project
              a. Reusable Components
                        i. WEBCOE: Documents related to WEBCOE procedure


                                                                                              561c3710-a5d6-42ae-873c-
                                                                                              f57a4f7844ff.doc
                                                                                               14 mei 2012
                                                                                              6/14
       b. Templates: Contains the templates that are followed throughout
          the maintenance project.
       c. Cookbook: This directory contains the coding guidelines and
          code review checklists that have to be followed throughout the
          maintenance project. Many documents have been provided to
          <Offshore facility> in this regard. A consolidated cookbook is in
          the process of being created which will be followed going
          forward.
5. Releases: Any documents that are released for the maintenance project
   as a whole against individual work orders. For example Maintenance
   Plan document, consolidated cookbook etc.

6. Plans: The plan documents that are maintained for the maintenance
   project.
       a. Configuration Management Plan
       b. Developer’s Handbook
       c. Maintenance Plan
       d. SLA
       e. Risk Management Plan
7. Project Initiation: Contains documents pertaining to project initiations.
       a. KickOff
       b. Estimations
       c. WorkOrders
                 i. Approval: Contains the approval mails from customer
                    approving the work orders.
                ii. Acceptance: Contains the mails from customer
                    accepting the work orders.

8. Reporting_and_tracking: Contains records and reports that are
   maintained for tracking the project.
      a. Action Log
      b. Schedule Log
      c. Review Log
      d. Test Log
      e. Change Request Log
      f. Release Log
      g. Support Log
      h. Weekly Status Report
      i. Gross Margin
      j. SLA Metrics

9. Review Records: Contains the review records of the documents
      a. Configuration Management Plan
      b. Maintenance Plan
      c. Developer’s Handbook

10. Billing: Contains the billing details of the project under various sub
    headings.

                                                                               561c3710-a5d6-42ae-873c-
                                                                               f57a4f7844ff.doc
                                                                                14 mei 2012
                                                                               7/14
              a. Infrastructure
                       i. Purchase_Indent
                      ii. Purchase_Order
                     iii. Invoice
              b. Translation
                       i. Quotation
                      ii. Invoice
              c. Timesheet
                       i. Approval
              d. Monthly_Invoice


2.3 Configuration Management Responsibilities

 Role                                                       Name of the Person(s) Responsible
 Who constitutes the Change Control Board/ Who
 approves changes to requirements or scope
 Who is responsible for Check-in and Check-out of all
 Cis
 Who is responsible for closing all change requests
 Who is responsible for closing all defects



2.4 Software Life Cycle Data Management Plan

 Data Type            Data Management mechanism                                Responsible
 Project Artifacts    All artifacts of the project are stored in the central
                      folder only. Access is restricted to only team
                      members. On a case-to-case basis this access is given
                      to other team members on a prior approval.
 Customer             Database Dumps, Source code, Functional designs,
 Supplied items       PDM, BPM, Cast documentation, CR, sample data files
                      for testing.
 Status Reports       Weekly status Reports to be placed in ePlace
 Reports to           Weekly status reports, Timesheet, MOM, SLA Metrics,
 Customer             Invoice, Release schedule




2.5 Naming and Identification of CIs

 CI Type                   Prefix                       CI Identification 1st Part   CI Identification 2nd Part
 Project Initiation        PID_
 Document – Suggested
 naming – will be
 decided by the

                                                                                              561c3710-a5d6-42ae-873c-
                                                                                              f57a4f7844ff.doc
                                                                                               14 mei 2012
                                                                                              8/14
 customer
 Service Level            SLA_
 Agreement
 Maintenance Plan         MP_
 Configuration            CMP_
 Management Plan
 Developer’s handbook     DH_
 Review Records           RR_                         <Prefix of the document>      Version of the document
 Release Notes            RN_                         Application Name              Version_BuildNo
 Migration Document       MN_                         Application Name              Version_BuildNo
 Unit Test Cases          UTC_                        Application Name              Version_BuildNo
 Business Process         BPM_                        Application Name_
 Models
 Physical Data Models     PDM_                        Database Name
 Application Write up     Overview                    Application Name
 INI Documentation        INI_                        Application Name
 Technical Design         TD_                         Application NameVersion_
 Functional Design        FD_                         Application NameVersion_
 Cookbook                 CB_
 Database stored          Refer to cookbook for
 procedures               details on naming
                          conventions followed




2.6 Base-lining of Documents

 Plans, Requirements, Designs, Drawings, Technical Notes, User Manuals, Release Notes, Test
 Cases / specs
 State of the CI        Versioning Details             Labeling           When it is called Baselined (ready for
                                                                          further use)
 Draft                  0.1                            Draft
 Final                  1.0                            Version 1.0        A document is final when all the review
                                                                          comments have been incorporated.
 Change Requests        1.1 or 2.0 (as requested by    Version 1.1        A document is final when all the change
                        the customer)                                     requests have been reviewed and
                                                                          verified.



2.7 Baselining of Source Code before Release

 State of the CI        Versioning Details            Labeling                   When it is called Baselined
                                                                                 (ready for further use)

                                                                                               561c3710-a5d6-42ae-873c-
                                                                                               f57a4f7844ff.doc
                                                                                                14 mei 2012
                                                                                               9/14
 Just Coding          Code in developers
                      workstation – Not in VSS

 Code Review          VSS Tool driven versioning.       V1.4 Build 1: Ready for   It is called Code Review Base lined
                      No separate versioning is         Code Review               when all the code review defects
                      required                                                    are tacked to closure

 Unit Testing         -Do-                              V1.5 Build 1: Ready for   It is called UT Base lined when all
                                                        Unit Testing              the UT defects are tacked to
                                                                                  closure

 Just Before IT       -Do-                              V1.5 Build 1: Ready for   The production fixes from previous
                                                        Integration Testing       release-Production Branch are
                                                                                  integrated with the newly
                                                                                  developed unit-tested code. This
                                                                                  will be baselined for IT.
 During Fixes of IT   -Do-                                                        It is called IT Base lined when all
                                                                                  the IT defects are tacked to
                                                                                  closure

 After IT fixes       The version will be as            V 1.5 Build 1: Ready      Source Code is called IT Base lined
                      mentioned in WO. A build          for System Testing        when all the integration test
                      number (1) will be added                                    defects are tracked to closure
                      to say this is first build for
                      System Test.



2.8 Base-lining of Source Code / System Releases


2.8.1     System Testing And Acceptance Testing

 State of the CI      Versioning Details               Labeling                When it is called as Baselined
                                                                               (ready for further use)



When an application is supplied to <Offshore team> against a Work Order to
implement a Enhancement Request, <Offshore team> develops the system
incorporating the targeted enhancement and increments the version number to
one specified in the Work Order by <ICT supplier> onsite team. For example,
<Offshore team> can increment the version from 1.4 to 1.5 or to 2.0 as
requested. This version is submitted to <ICT supplier> onsite team for System
Testing and is considered as Build 1.
If during System Testing, <ICT supplier> reports some issues, they are reported
to <Offshore team>, who correct the issues and release with the same version
number but with an incremented build number. In this case, version 1.5 Build 1
(with bugs in System Testing) would be corrected and re-released to <ICT
supplier> onsite team as version 1.5 Build 2.


                                                                                                 561c3710-a5d6-42ae-873c-
                                                                                                 f57a4f7844ff.doc
                                                                                                  14 mei 2012
                                                                                                 10/14
Thus support during System Testing will lead to various releases with same
version number and incremental build numbers.
Once <ICT supplier> onsite team completes the System Testing, the latest build
is released to <Customer> for acceptance testing.
If during the acceptance testing, some issues are reported by <Customer> to
<ICT supplier> onsite team, <Offshore team> will rebuild the application and
release it with the same version number with incremented build numbers. For
example, suppose version 1.5 Build 3 has passed system test and is released to
<Customer> for system test, then the first accepted test fix would be released as
version 1.5 Build 4.
Further issues during acceptance testing will lead to various build versions. For
example, versions 1.5 Build 5, 1.5 Build 6 and so on.
After acceptance testing, the version is base-lined and the final build goes into
production.
If in the event of the first release being in production, a second work order is
generated for the same application, then development phase of the second work
order starts in parallel. This is done by branching in VSS – one branch is created
for the production support branch and the other branch for the development of
the second work order.
Post-production support is done by <ICT supplier> onsite team and if needed
<Offshore team> can also be involved. Any small issues reported during
production will be incorporated immediately either by <ICT supplier> onsite team
or by <Offshore team> and a patch release is made to <Customer>.
Before <Offshore team> can make the final release for the second work order, all
the production fixes made by both <ICT supplier> onsite team and <Offshore
team> are forward ported to the main development branch. This is called
merging of the two branches.

2.8.2    Branching Strategy And Forward Port:

Branching Strategy: Branching is essential so that production fixes can happen
without disturbing the further development of the application. If there are no
further developments on same application during production fixes, there is no
need of branching. In this case, the Production fixes happen in the main branch
itself but with the version naming convention as described above. When the
source code is accepted after acceptance testing, the code is transferred to
production environment. There may be further change requests on the same
code. But during production, some bugs may be reported. If these bugs are
critical errors, they may be taken as change request and fixed in main branch. If
the bugs reported are not of critical nature, without disturbing the main
development line, the accepted code can be base-lined into a separate branch
called production-fix branch. The bugs are separately fixed only on this
production-fix branch. There may be many production fixes and every fix will be
identified with separate build number added with base-lined version number from
acceptance testing. Suppose, the version number after acceptance is v1.5Build
5, the first production fix will be labeled as v1.5.1 Build 1. For new releases made
for the same production fix till the fix gets accepted, only the build number is


                                                                                       561c3710-a5d6-42ae-873c-
                                                                                       f57a4f7844ff.doc
                                                                                        14 mei 2012
                                                                                       11/14
incremented. For any further production bugs that are reported, the build will be
released and labeled as v1.5.2 Build 1, v1.5.3 Build 1 etc.
Note: For each production fix, the object touched and the location/function
modified should be tracked in an Excel sheet along with defect ID. In the code,
comment with defect ID should be added both at the beginning of the fix and end
of the fix indicating Start-Defect-ID and End-Defect-ID. This is necessary for
Forward Port during integration into the main branch.

Forward Port:
Forward port is a method to add the fixes done in production branch into the
development branch. If there are some production fixes done keeping version 1.5
Build 5 as base line, and a next set of development is done for new WO, which
may be labeled as v1.6, there is a need to add the changes made in production
line into newly built code. This is done after unit testing of v1.6 and before
releasing it for system test. This phase is called Integration. The developed code
is checked out into build-integration directory or working directory, the changes
made on v1.5 Build 5 production branch is added to the new version source
code. The application is tested after integration. This becomes baseline for
system testing.

 State of the CI         Versioning Details          Labeling / Tagging       When it is called as Baselined
                                                                              (ready for further use)
 Code after              The accepted code is        V1.5 Build x             1. The released version is base lined
 Acceptance              labeled as v1.5.Build x     Production (where x      for Production Fixes.
                         where represents build      represents build
                         number that was             number that was          2. If there is any further
                         accepted by <Customer>      accepted by              CR/development on same application,
                                                     <Customer>)              this code becomes baseline for
                                                                              development branch also. This code
                                                                              will be labeled based on WO during
                                                                              system release.

 Fixing defects in                                   Include Defect ID in     <ICT supplier> onsite team will usually
 Production.                                         comment                  do this, but <Offschore team> might
                                                                              be also involved in some cases.

 After fixing            Version as V1.5.1 Build x   V1.5.1 Build x (where        1.   This is baseline for production.
 Production bugs                                     x represents build
                                                     number that was              2.   If there is any further
                                                     accepted by                       development on same
                                                     <Customer>, so if                 application, this becomes base
                                                     only the third                    line for Forward Port during
                                                     delivery was                      integration till the time more
                                                     accepted this is Build            production issues are
                                                     3)                                reported.

 Next set of             Version as V1.5.2 Build 1   V1.5.2 Build 1
 production Fixes                                    Include Defect ID in
                                                     comment.
 After fixing next set   Increment the build         V1.5.2 Build x (where        1.   This is baseline for production.
 of Production bugs      number to along with        x represents build

                                                                                                 561c3710-a5d6-42ae-873c-
                                                                                                 f57a4f7844ff.doc
                                                                                                  14 mei 2012
                                                                                                 12/14
                          version number.            number that was
                                                                                     2.   If there is any further
                                                     accepted by                          developments on same
                                                     <Customer>)                          application, this becomes base
                                                                                          line for Forward Port during
                                                                                          integration.

 Source code in           V1.6 Build 1               V1.6 Build 1 Ready              Unit Tested code becomes baseline
 development                                         for IT                          for Integration
 branch

 Integration or           V 1.6 Build 1              V1.6Build 1 After               Add production branch fixes to unit
 Forward Port                                        Forward Port                    tested v1.6 code. This becomes
                                                                                     baseline for Integration Testing

 After IT                 version as v1.6 Build 1    V 1.6 Build 1 Ready             Base line for System test.
                                                     for release
 System test release      Release version as V1.6    V1.6 Build 1                    Base lined for system test
                          Build 1




2.9 Incident (Change) Management Plan

 Change Type                        Mechanisms to Analyze & Control Changes                 Responsible
 Requirements/ Scope Change         Onsite Change Manager creates CR in the form of         Onsite Change Manager
                                    Work orders
 Changes due to resource            -NA-
 constraints (Tools Etc)
 Change in the Schedules /          Changes are adapted in the WO and the schedules         CP + PM + onsite Change
 Effort due to Delay in             are revisited.                                          Manager
 customer Supplies
 Functional Design Changes          <ICT supplier> maintains the functional design          <ICT supplier> onsite team
                                                                                            Functional designers
 Technical Design Changes           <Offshore team> maintains the technical design          TL
 Acceptance Criteria Changes        Changes are adapted in the WO and schedules are         CP+ PM + Onsite Change
                                    revisited.                                              Manager
 Changes due to Bugs Reported       A web-based tool (WEBCOE) is used to report and         TL
 by <ICT supplier> onsite team      track bugs reported by <ICT supplier> onsite team
 and <Customer>                     and <Customer>
 Infrastructure changes             <Customer> will communicate Infrastructure              Onsite Change Manager
                                    changes (OS version, DBMS version) with Onsite
                                    Change Manager. If these changes have
                                    consequences for offshore team Onsite Change
                                    Manager creates a Work Order
 Changes due to production          Onsite Incident Manager will manage all incidents       Incident Manager
 fixes requested by                 reported by <Customer> and will delegate
 <Customer>                         incident solving to either onsite team or offshore
                                    team



                                                                                                    561c3710-a5d6-42ae-873c-
                                                                                                    f57a4f7844ff.doc
                                                                                                     14 mei 2012
                                                                                                    13/14
 Database changes (including    Changes to physical data model and production   <Customer> DBA
 stored procedures)             database can only be done by <Customer> DBA.
                                For details, see database synchronization
                                procedure



2.10     Configuration Audits

Configuration Audit related checks are conducted as part of project audits &
Release Checks.


2.11     Project Specific Backup & Recovery Strategy

Backups are stored in a backup server located in a safe location that is
accessible only for administrators and <Customer> Team Members.




                                                                                       561c3710-a5d6-42ae-873c-
                                                                                       f57a4f7844ff.doc
                                                                                        14 mei 2012
                                                                                       14/14

								
To top