Integration Management Plan
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Integration Management Plan as PDF for free.
More details
- Words: 1,965
- Pages: 12
Integration Management Plan Document ID:
Date
Author
Description
Approved by
Approval date
This material is proprietary of COMPANY. Any unauthorized reproduction, use or disclosure of this material, or any part thereof, is strictly prohibited. This material is meant solely for the use of COMPANY employees and authorized COMPANY customers.
Doron Bar
Integration Management Plan
List of Changes Revision n.m Section / Paragraph
Change / Addition • •
Doron Bar http://softwaretestersblog.blogspot.com 2008 Doron Bar All Rights Reserved – Document can be used freely only without changing this footer!!! Page 2 of 12
Doron Bar
Integration Management Plan
Table of Contents 1. GENERAL........................................................................................................... .....................4 1.1. Purpose of this Document........................................................................................... .........4 1.2. Major Milestones ......................................................................................................... .......4 1.3. References....................................................................................................... ....................4 2. INTEGRATION APPROACH............................................................................................. ....4 2.1. Objectives................................................................................................................... .........4 2.2. Assumptions and dependencies.................................................................... ........................5 2.3. General Approach.................................................................................................... ............5 2.4. Detailed Approach ............................................................................................. .................6 2.4.1. Build - 1.............................................................................................. ........................6 2.4.2. Build - 2.............................................................................................. .........................6 2.4.3. Build - 3.............................................................................................. .........................6 2.5. System sanity.................................................................................................................... ...7 2.6. Integration activities................................................................................... .........................7 2.7. Building the components and application................................................................. ............7 2.7.2. Sanity testing - will be repeated in every development cycle.......................... ..............7 2.7.3. Procedure for deliveries between main releases................................................. ..........8 2.7.4. KIT and installation procedure............................................................. .......................8 2.8. Defect life cycle..................................................................................................... ..............9 3. MANAGEMENT...................................................................................................... ................9 3.1. Participants and Responsibilities.............................................................. ...........................9 3.1.1. Integration Team – list of participants............................................................. ............9 3.2. Integration Breakdown Structure (IBS).................................................. ...........................10 Tracking and control..................................................................................................... ...........10 3.2.1. Review of documents:..................................................................................... ............10 3.3. Risks........................................................................................................................... .......11 3.4. Resource Needs...................................................................................... ...........................11 3.4.1. Staffing................................................................................................... ....................11 3.4.2. Environmental Needs............................................................................................ ......11 3.4.3. Hardware Needs.................................................................................... .....................11 3.4.4. Software Needs....................................................................................... ....................11 3.5. Integration Documentation........................................................................................ .........11 3.5.1. General................................................................................................................. ......11
Doron Bar http://softwaretestersblog.blogspot.com 2008 Doron Bar All Rights Reserved – Document can be used freely only without changing this footer!!! Page 3 of 12
Doron Bar
Integration Management Plan
1.General 1.1.Purpose of this Document This document describes the management plan for integration activities for the
1.2.Major Milestones Work
Date
DR
Comments
Breakdown Structure
1.3.References No.
Document Title
[1]
Integration management plan
[2]
Integration sanity test template
Document Location
Author
2.Integration Approach 2.1.Objectives 1. Create an environment and ability to create builds and kits in accordance to the new products tree. Doron Bar http://softwaretestersblog.blogspot.com 2008 Doron Bar All Rights Reserved – Document can be used freely only without changing this footer!!! Page 4 of 12
Doron Bar
Integration Management Plan
2. System integrity – Internal and external verification of all components and applications with each other and within InSight. 3. Validate kit and installation instructions. 4. Testing readiness - Basic verification of major requirements by running predefined system sanity tests in order to announce system and service test readiness. (And prevent unnecessary effort & resource consumption in later stages of acceptance tests). 5. The upgrade pass in integration phase will be performed by kits from the same versions. If upgrade from old releases is needed so different plan should be create with the PM.
2.2.Assumptions and dependencies 1. The builds will take place on a designated build server; the integration testing will be done on a separate server. 2. Integration is part of the development life cycle as defined in the development life cycle document 3. All builds must PASS unit test and PI in the development group and will be delivered to the integration after CM.
2.3.General Approach The integration sanity testing will be done in cycles (in accordance to the release service plan / build plan). Every cycle the manual sanity will be done. The integration test plan will be based on the ... The testing in the project will follow the integration every release and in order to prevent duplicate testing, the testing and integration manager will define the scope of testing and integration. The service manager should verify that a Private Integration in the development phase is made for the service before entering to integration formal labs. The environment of the integration testing will be: 1. On the
Doron Bar http://softwaretestersblog.blogspot.com 2008 Doron Bar All Rights Reserved – Document can be used freely only without changing this footer!!! Page 5 of 12
Doron Bar
Integration Management Plan
The service will be installed on the integration system by integration team only, and only components included in a formal release received from the service build manager. An integration representative should be part of readiness meetings for all builds. The integration is responsible to create Service Configuration kit. If a private integration is needed it will be performing on different machines. (Should be on the private integration lab)
2.4.Detailed Approach This paragraph specifies the integrations, in more detail.
2.4.1. Build - 1 Start Date: dd/mm/yy till – dd/mm/yy Entry criteria: Readiness passes successfully Content: Sanity for <product X> only
2.4.2.Build - 2 Start Date: dd/mm/yy till – dd/mm/yy Entry criteria: Readiness passes successfully Content:
Feature
Description
Comment
2.4.3.Build - 3 Start Date: dd/mm/yy till – dd/mm/yy Entry criteria: Readiness passes successfully Content: Doron Bar http://softwaretestersblog.blogspot.com 2008 Doron Bar All Rights Reserved – Document can be used freely only without changing this footer!!! Page 6 of 12
Doron Bar
Integration Management Plan
Feature
Description
Comment
2.5.System sanity A system sanity will be done following each build and installation. The scope of the test will grow according to the build plan. The integration will run sanity that will cover the … The document that describes the tests can be found in …
2.6.Integration activities The detailed procedure that describes the build procedure, creating the kit and the sanity can be found in the integration procedure document
2.7.Building the components and application Requires a controlled environment, all sources are labeled, the files used for running the build are part of sources. 2.7.1.1Entry criteria and inputs •
Build readiness
•
Unit tests run successfully
•
Build request filled and reviewed
•
Labeled products
•
Auto kit
•
Updated installation scripts file for the kit
2.7.1.2Output •
Export – All tars for the installation
•
Documentation for the build
2.7.2.Sanity testing - will be repeated in every development cycle Every release some new component or functionality will be introduced into the system, and will be covered by the Components automatic unit tests and sanity testing for the application. Doron Bar http://softwaretestersblog.blogspot.com 2008 Doron Bar All Rights Reserved – Document can be used freely only without changing this footer!!! Page 7 of 12
Doron Bar
Integration Management Plan
2.7.2.1Entry Criteria and inputs •
Kit
•
Approval of sanity description
•
Documentation describing the additional functionalities, fixed bugs, etc.
•
System sanity document – regressions and system functionality
•
Automatic Unit tests for components
2.7.2.2 Output & deliverables •
Documentation – Installation and configuration instructions, list of bugs
•
Open Test Incident Reports.
•
Sanity report.
2.7.2.3Exit Criteria •
Unit tests run successfully on integration server
•
In case of basic functionality bugs, the decision to continue to the testing lab will be done by the Testing TL and the project management.
2.7.3.Procedure for deliveries between main releases In case bugs that are considered as show stoppers are found while integration testing is done, it is necessary to enable placing the fixes on the integration system, although they are not part of a main release. It may also be necessary to conduct part of the testing of the fix, before the component is “labeled”, because the problem can be reproduced only on the integration system. •
In order to have control on the system in this case, all installations will be done by the integration team only.
•
If during the fix, a debugging session is necessary, the developer will work on the system accompanied by an integrator.
•
No configuration changes will be done except by the integration team, and these changes will be recorded.
2.7.4.KIT and installation procedure 2.7.4.1Objective •
Create an environment that will auto install the application and it dependency
•
Installation according the service installation instructions.
•
Updated installation instructions and configurations Doron Bar http://softwaretestersblog.blogspot.com
2008 Doron Bar All Rights Reserved – Document can be used freely only without changing this footer!!! Page 8 of 12
Doron Bar
Integration Management Plan
•
The kits will be made using the cookbook and will use the Octopus technology.
•
Opening bugs when needed.
2.7.4.2Entry Criteria •
Documentation contain KIT changes for all kits (new Octopus parameters)
•
KIT review by the integrator before the kit is sent to the CM.
•
Private Iintegration to the KIT.
•
Integration test document updated with the new release content.
2.7.4.3Output & deliverables •
Installation of the service kits.
•
Updating installation and configuration instructions
•
Running the Integration Test Description and the service critical bugs corrections (according the installation instructions)
•
Update the Documentation and the ITD.
2.8.Defect life cycle The Integration process should handle a defect correction process which take place usually when discovering major defects or when many defects were accumulated. Basically those defects are reported to the developers for bug correction. Clear quest bug tracking system will be used. Bugs found during a release integration system, will be reported, including retest instructions. After the bug is analyzed by the relevant developer, the priority of the bug will be decided by the integration manager /integrator. Usually bugs found in this phase are major or critical. In case the bug is a critical one, the fix may be installed on the integration system and tested before being formally added to the release.
3.Management 3.1.Participants and Responsibilities 3.1.1.Integration Team – list of participants
Doron Bar http://softwaretestersblog.blogspot.com 2008 Doron Bar All Rights Reserved – Document can be used freely only without changing this footer!!! Page 9 of 12
Doron Bar
Name
Integration Management Plan
Responsibility
Extension
3.2.Integration Breakdown Structure (IBS) In this section the breakdown of the integrations that will be done according to the release plan of the server and client. Topic
Integration team Comments estimated effort
Build 1 Build 2 Build 3
Tracking and control Will be done as part of the project status meetings.
3.2.1.Review of documents: • Review of IMP • Review of system sanity description (ITD) • Review of integration Gantt
Doron Bar http://softwaretestersblog.blogspot.com 2008 Doron Bar All Rights Reserved – Document can be used freely only without changing this footer!!! Page 10 of 12
Doron Bar
Integration Management Plan
3.3.Risks The following table lists the integration risks and its proposed resolution: N o
Risk description
Prob.
Impact
Result
Resolution
Remarks
1 2
3.4.Resource Needs 3.4.1.Staffing 3.4.1.1Required support Support of relevant developers will be required during the integration. This must be taken in account in their work plans 3.4.1.2Training
3.4.2.Environmental Needs The integration activities will take place in the formal Integration lab
3.4.3.Hardware Needs 3.4.4.Software Needs
3.5.Integration Documentation 3.5.1.General The release documentation regarding the integration process shall include the following types:
Doron Bar http://softwaretestersblog.blogspot.com 2008 Doron Bar All Rights Reserved – Document can be used freely only without changing this footer!!! Page 11 of 12
Doron Bar
Integration Management Plan
No .
Document
Responsible
1.
Integration Planning Documents
1.1.
Integration Management Plan (this document)
2.
Integration Procedures
2 .1.
System sanity document
3.
Report and Tracking
3.1.
Integration progress reports – to the release manager
3.2.
Soft copies of all sanity reports
Location
Doron Bar http://softwaretestersblog.blogspot.com 2008 Doron Bar All Rights Reserved – Document can be used freely only without changing this footer!!! Page 12 of 12
Related Documents
Integration Management Plan
November 2019 19
Project Integration Management
November 2019 18
Technology Integration Plan
November 2019 23
Integration Of Merchandising Management
October 2019 19
Ch04_project Integration Management
May 2020 17