Download - Overview
Software Project Management PlanVersion 1.0
March 25, 2006
Trinity Team
Team Members:
Eunyoung Cho Minho Jeung
Kyu Hou
Document Information
Document Name Software Project Management PlanProperty of Trinity Team Document Availability Trinity website (http://azalea.icu.ac.kr/~pos/)
Document Revisions
No Revision Date Author(s) Comments
1 0.1 February 24, 2006 Minho Jeung Initial creation2 0.2 February 26, 2006 Minho Jeung Team review3 0.3 March 24, 2006 Minho Jeung Mentor’s review4 0.4 March 25, 2006 Minho Jeung English correction5 1.0 March 26, 2006 Minho Jeung Team review
Software Project Management Plan Trinity Team
Table of Contents1 OVERVIEW......................................................................................................................................... 5
1.1 PURPOSE, SCOPE, AND OBJECTIVES.....................................................................................................51.2 ASSUMPTIONS AND CONSTRAINTS.......................................................................................................51.3 PROJECT DELIVERABLES....................................................................................................................51.4 SCHEDULE SUMMARY........................................................................................................................ 6
2 REFERENCES.................................................................................................................................... 7
3 ACRONYMS....................................................................................................................................... 8
4 PROJECT ORGANIZATION..............................................................................................................9
4.1 TEAM INTERFACES............................................................................................................................. 94.2 ROLES AND RESPONSIBILITIES.............................................................................................................9
5 REQUIREMENT MANAGEMENT PLAN........................................................................................10
5.1 REQUIREMENTS MANAGEMENT ORGANIZATION..................................................................................105.1.1 Configuration Control Board..........................................................................................105.1.2 Tools, Environment, and Infrastructure............................................................................10
5.2 THE REQUIREMENTS DEVELOPMENT PROCESS....................................................................................105.2.1 Requirements Identification............................................................................................105.2.2 Prepare for Requirements Cycle......................................................................................115.2.3 Elicit Requirements........................................................................................................115.2.4 Analyze Requirements....................................................................................................115.2.5 Formalize Requirements.................................................................................................125.2.6 Verify and Validate Requirements....................................................................................12
5.3 REQUIREMENT TRACKING................................................................................................................. 125.3.1 Maintaining Requirements’ Traceability and Tracking Reqirements’ Status.........................125.3.2 Requirements Attributes..................................................................................................13
5.4 REQUIREMENTS CHANGE MANAGEMENT............................................................................................145.4.1 Entry Criteria................................................................................................................145.4.2 Tasks............................................................................................................................ 145.4.3 Verification...................................................................................................................145.4.4 Exit Criteria.................................................................................................................. 145.4.5 Change-Control Status Reporting....................................................................................14
5.5 REQUIREMENTS CHANGE PROCESS ON SOW......................................................................................14
6 RISK MANAGEMENT PLAN...........................................................................................................16
6.1 REQUIREMENTS RISK MANAGEMENT PROCESS OVERVIEW...................................................................166.2 THE REQUIREMENTS RESPONSIBILITIES..............................................................................................166.3 RISK MANAGEMENT MODEL DESCRIPTION.........................................................................................176.3.1 Risk Identification..........................................................................................................176.3.2 Risk Analysis................................................................................................................. 176.3.3 Plan............................................................................................................................. 186.3.4 Tracking....................................................................................................................... 186.3.5 Control......................................................................................................................... 18
6.4 RISK COMMUNICATION....................................................................................................................18
7 CONFIGURATION MANAGEMENT PLAN....................................................................................20
7.1 SCM ORGANIZATION & RESPONSIBILITY...........................................................................................207.2 SCM ACTIVITIES............................................................................................................................. 207.2.1 Configuration Identification............................................................................................207.2.2 Configuration Control....................................................................................................21
7.2.2.1 Configuration Control Board...........................................................................................................21ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
3/26
Software Project Management Plan Trinity Team
7.2.2.2 Baseline Control............................................................................................................................217.3 SCM TOOLS AND NAMING CONVENTIONS..........................................................................................217.3.1 SCM Tools....................................................................................................................217.3.2 Naming Conversions......................................................................................................22
7.3.2.1 Meeting Documentations................................................................................................................227.3.2.2 Deliverable Documentations...........................................................................................................227.3.2.3 Java Source Codes.........................................................................................................................22
7.3.2.3.1 Packages.........................................................................................................227.3.2.3.2 Classes or Interfaces........................................................................................22
8 QUALITY ASSURANCE PLAN........................................................................................................23
8.1 DESIGN REVIEW.............................................................................................................................. 238.1.1 Purpose and Scope.........................................................................................................238.1.2 Roles and Responsibilities..............................................................................................238.1.3 Design Review Process...................................................................................................23
8.2 CODE REVIEW................................................................................................................................. 248.2.1 Purpose and Scope.........................................................................................................248.2.2 Roles and Responsibilities..............................................................................................248.2.3 Code Review Process.....................................................................................................24
8.3 TESTING......................................................................................................................................... 248.3.1 Purpose and Scope.........................................................................................................248.3.2 Roles and Responsibilities..............................................................................................248.3.3 Testing Process..............................................................................................................25
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
4/26
Software Project Management Plan Trinity Team
1 OverviewPOSDATA Co., Ltd. (POSDATA) is an IT service provider. With the advent of the ubiquitous era, POSDATA is going a step further than just providing IT services (consisting of system integration and outsourcing services) by actively providing strategic business solutions for the future, including portable internet. POSDATA now extends their business area to DVR (Digital Video Recorder), which allows users to monitor, store, and control video streaming of images in real time from a remote location through network.
POSDATA wishes to enlarge the DVR system which is N-DVR (Next generation Digital Video Recorder) system managing, controlling, and sending and receiving large amounts of image data from traffic audit remote cameras. One objective of the N-DVR system is that many users should be able to audit the traffic status via N-DVR system at the same time. In fact, if a lot of users would like to watch the traffic status concurrently, the visual image cannot be shown smoothly because the bandwidth of the Internet might exceed the limit caused by large data transaction.
The client wants us to realize overlay multicast protocol in the N-DVR project for bandwidth efficiency of the wide area network.
1.1 Purpose, Scope, and Objectives
Objectives of this project are: Allowing N-DVR server to provide traffic video stream to users via OMP (Overlay
Multicast Protocol) and Having OMP solve the network congestion problem when many clients view the stream
at the same time.
1.2 Assumptions and Constraints
- Hardware constraints: Use Linux Server and Windows (Operating System) Clients- Development software: C or C++- The product should be implemented under royalty-free policy
1.3 Project Deliverables
- Statement of Work- Software Requirement Specification - Software Project Management Plan- Architecture: High level and low level design documents- Overlay Multicast Protocol code
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
5/26
Software Project Management Plan Trinity Team
1.4 Schedule Summary
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
6/26
Software Project Management Plan Trinity Team
2 References- IEEE Std 1233, IEEE Guide for Developing System Requirements Specification, 1998- IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications, 1998- Jon Valett and Chris Parr, Requirement Management Plan (RMP), National Archives and Records Administration, 2003
- MSE Neo team, Requirement Management Plan NEO-TR-003, 2004- MSE 4WD team, Requirements Management Plan for HMC POI Inspection Management System, 2004- MSE Rolling team, Requirements Management Plan, 2004- MSE Dumbledore team SEI ArchE System Software Requirements Specification, 2004- DI-IRSC-81433, Software Requirements Specification, 1994- IEEE Std 1540-2001, IEEE Standard for Software Life Cycle Processes-Risk Management, 2001- MSE Studio Team Rolling, Software Project Management Plan, 2004- CMU/SEI-94-SR-1, An Introduction to Team Risk Management (V 1.0), 1994- CMU/SEI-93-TR-6, Taxonomy-based Risk Identification, 1993- CMU/SEI-96-TR-012, Software Risk Management, 1996- IEEE Standards for Software Configuration Management Plans- IEEE Std 828-2005- IEEE Standard for Software Quality Assurance Plans, IEEE Std 730-2002 - Watts S. Humphrey, “Introduction to Team Software Process”, 2000- Ian Sommerville, “Software Engineering,” 7th edition, 2004- MSE Rolling team, Quality Assurance Plan, 2004- MSE Dumbledore team, SEI ArchE Sytem - Quality Assurance Plan, 2004- IEEE Std 1058-1998 IEEE standare for software project management plans- Karl E, Wiegers SOFTWARE REQUIRMENETS, 2003 Microsoft
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
7/26
Software Project Management Plan Trinity Team
3 AcronymsCCB Change Control BoardCCB Configuration Control BoardCI Configuration Item
CM Configuration ManagementCMU Carnegie Mellon University ICU Information and Communication UniversityIT Information Technology
MSE Master of Software EngineeringOMP Overlay Multicast ProtocolSCM Software Configuration Management
SI System IntegrationSQA Software Quality AssuranceSRS Software Requirements Specification
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
8/26
Software Project Management Plan Trinity Team
4 Project Organization
4.1 Team Interfaces
Roles Name Belonging
Team Members Eunyoung Cho ICU
Minho Jeung ICU
Kyu Hou ICU
Client Seong-Yong Choi POSDATA
Mentors Ho-jin Choi ICU
In-Young Ko ICU
Mel Rosso-Llopart CMU
4.2 Roles and Responsibilities
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
9/26
Roles Fall 2005 Spring 2006 Summer 2006Team Leader
Eunyoung ChoMinho Jeung
Kyu HouPlanning Manager Kyu HouDevelopment Manager
Kyu Hou Eunyoung Cho Minho JeungCustomer Interface ManagerRisk Manager
Minho JeungMinho Jeung
Eunyoung ChoQuality/Process Manager Kyu Hou
Software Project Management Plan Trinity Team
5 Requirement Management PlanThe Requirement Management Plan consists of organizing tasks and requirements, and management of requirements process and schedule. In addition, the document also includes the requirement change management including the requirements recording, modifying, and conciliation methods. By using the document, the Trinity team can establish and maintain agreement on the requirements with the client.
5.1 Requirements Management Organization
5.1.1 Configuration Control Board
The Configuration Control Board (CCB) is composed of members of the Trinity team. In this CCB, all members analyze and evaluate requirement feasibility and impact of the project.
Name Department Role
Seong-Yong Choi POSDATA Customer
Eunyoung Cho MSE Development manager
Minho Jeung MSE Project leader
Kyu Hou MSE Quality manager
All members MSE Developers
5.1.2 Tools, Environment, and Infrastructure
SRS is produced as a document (Microsoft Word) with images using Visio. Requirement identifications and defined in SRS are maintained in Microsoft Excel for traceability.
Tool Description
MS Excel Requirement management tool
Microsoft Word, Visio and PowerPoint Reporting tool
CVS Configuration management tool
5.2 The Requirements Development Process
5.2.1 Requirements Identification
Requirement identification is the task that elicits and develops requirements. To define the requirement, the Trinity team has to make requirements detail. In general, requirements development is iterative task. A series of steps is performed to elicit the initial requirements. The result of this activity will be the Software Requirements Specification (SRS). System requirements specification development consists of identification requirements, build well-
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
10/26
Software Project Management Plan Trinity Team
formed requirements, organize the requirements into an SRS, and present the SRS for different audiences shown in Figure 1.
Figure 1. SRS Development Process
The following steps constitute a complete cycle through the requirements development cycle:
5.2.2 Prepare for Requirements Cycle
To identify and evolve requirements, the Trinity team has to prepare the following The project leader defines the goal of the cycle. The acceptance criteria for the cycle are identified. The project leader defines the gathering technique with the development manager. The technique for gathering or refining requirements is as follows: brainstorming, contextual design, user conferences, interviews, and questionnaires. The trinity team has to identify stakeholders and participants. The key stakeholders are identified for requirements gathering.
5.2.3 Elicit Requirements
The development manager gathers and refines client requirements using the technique defined during the “Prepare for Requirements Cycle” activity. In this step, the Trinity team can have a set of candidate requirements, or candidate requirements refinements.
5.2.4 Analyze Requirements
In the Configuration Control Board (CCB), the candidate requirements are analyzed to form informal requirements by all members of the Trinity team. To tackle conflicts like duplicates, inconsistencies between requirements, requirements are made consistent in level and detail. An
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
11/26
Software Project Management Plan Trinity Team
initial mapping among levels of requirements is performed. This phase results a new set of requirements, and/or refinements to the existing requirements.
5.2.5 Formalize Requirements
According to this management plan, the development manager will phase requirements in “formal” requirements terminology and format. The development manager will record requirements in Excel format. Traceability matrices are defined or updated.
5.2.6 Verify and Validate Requirements
In this step, the Trinity team will inspect the requirement document and discuss about the requirements. All members verify and validate the requirements in the Configuration Control Board (CCB). And then the requirements document is confirmed by other stake holders such as customers, and mentors. When one verification and validation is finished, the next requirements development process starts.
5.3 Requirement Tracking
In requirements tracking phase, there are two major activities. The first is maintaining requirements traceability and the second is tracking requirements’ status
5.3.1 Maintaining Requirements’ Traceability and Tracking Requirements’’ Status
The trinity team will do the following activities by using Microsoft Excel.① Provide a simple representation of the interdependencies among all forms of
requirements and requirement expression,② Serve as a starting point for any requirement change estimation.③ Track the status of completion of any requirement at any given time
The requirement traceability and status matrix will have the following structure:① Requirement ID – the ID to identify the requirement uniquely.② Requirement Description – the description of the requirement. ③ Quality Attribute Name – The Quality Attribute Name.④ Priority – The priority of requirement⑤ Responsibility – the team member responsible for the requirement.⑥ Date of Delivery – the promised date of delivery for the requirement.⑦ Completion Status – completion status as an approximate percentage.⑧ Completion Status Date – the date when the completion status was recorded.⑨ Comments – comments by the team lead.
When the Trinity team decides on the deliverables for the development phase, this traceability matrix will be changed to include class names, method names, and unit and system test case references.
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
12/26
Software Project Management Plan Trinity Team
Figure 2. The figure of Requirements’ Traceability and Status Matrix
5.3.2 Requirements Attributes
Attribute Description List Values
Priority
The order of requirements according to its importance. High means the system will not succeed without a particular requirement. Medium means the system manage to run, but customer wish to apply it soon. Low means that the customer satisfaction is ok, and the requirement can be handled later.
HighMedium
Low
Status
The current requirement’s feature. Proposed indicates the requirement is not reviewed by customer. Approved means the requirement is officially accepted by customer. Incorporated means the requirement is incorporated into the implementation. Rejected means that the requirement is not accepted by CCB. Cancelled means that customer cancels the requirement.
ProposedApproved
IncorporatedValidatedRejectedCancelled
Difficulty
The degree of difficulties of the requirement to be implemented in terms of the technical and business complexity.High indicates that the requirement takes more than 3 days to implement. Medium takes 1~3 day. Low takes less than 1 day.
HighMedium
Low
Stability
An indicator of how likely the requirement will change in the future. High indicates the customer is confident that the requirement will not change. Medium means that the customer may change the requirement. Low means the customer are very likely to change the requirement.
HighMedium
Low
Assigned to The name of developer who is responsible to the requirement. N/AOrigin The source of the requirement N/A
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
13/26
Software Project Management Plan Trinity Team
5.4 Requirements Change Management
Requirement change control process is managed by following steps.
5.4.1 Entry Criteria
To start change requirements, the Configuration Control Board has to be established. The Trinity team will deal with requirements change in the Change Control Board when the team discusses the changes.
5.4.2 Tasks
In the Change Control Board, the project leader assigns a member to analyze cost, impact, risk, and hazard. This analysis ensures that the potential consequences of accepting the change are well understood. The member acting as an evaluator and the Change Control Board should also consider the business and technical implications of rejecting the change. And then, the member decides to accept requirements change or not. If the requirement change is accepted, the member will notify the change to other members.
5.4.3 Verification
The development manager will verify requirements changes through a peer review. All team members will verify the changes made in downstream work products through testing or review. Following verification, the modifier installs the updated work products to make them available to the rest of the team and redefines the baseline to reflect the changes.
5.4.4 Exit Criteria
To complete change control process, the status of the request is ether rejected or closed. The project leader and other members know the change details and the current status of the change request, and the requirement traceability matrix has been updated.
5.4.5 Change-Control Status Reporting
The quality manager and project leader make a report about the contents of the change control board.
5.5 Requirements Change Process on SOW
Any change impacting the scope of the project must be reflected in the SOW. Changes may be requested by the customer or by the Trinity team. The process to change the SOW comprises the following steps: Change Request, Change Review and Evaluation, and Change Approval/Rejection.
Change RequestThe customer communicates the change request to the Trinity team.
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
14/26
Software Project Management Plan Trinity Team
Change Review and Evaluation
The Trinity team reviews the change request submitted by the customer and evaluates feasibility of the change based on schedule, available resources and risk involved.
Change Approval/Rejection
After the review and evaluation stage, the Trinity team will arrange a meeting with the customer to discuss the change request. The change request can have three different outcomes:▫ Approved and all the change will be taken account for▫ Approved but only some of the change will be included▫ Rejected
If the request is approved, the Trinity team will include the change in the next revision of the SOW.
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
15/26
Software Project Management Plan Trinity Team
6 Risk Management PlanRisk management plan is the description of how the elements and resources of the risk management process will be implemented within an organization. To address and control any possible risk factors, the Trinity team defines a risk management plan based Software Engineering Institute (SEI) paradigm at CMU. This document defines the role and responsibility, the schedule, the process and description of risk management.
6.1 Requirements Risk Management Process Overview
The risk management of Trinity team is based SEI's model. Five phases should repeat continuously during communication. Based on the role of the risk management, all stakeholders and team members communicate for the control of the risks.
POSDATATrinity Team
CommunicationTrack
ControlIdentify
Anal
yze
Plan
•Risk action•Risk correction
•Risk Metric•Status indicators•Triggers
•Review and assign•Periodic tech reviews•Strategize
•Criteria filter•Comparison risk ranking•Nominal group technique
•Taxonomy•Risk form•Routine periodic risk reporting
Figure 3. Trinity's Continuous Risk Management based CMU SEI's paradigm
6.2 The Requirements Responsibilities
Each team member should do the following role and responsibility for the processing of the team based risk management.
Role Responsibility OwnerClient Provide input into risk management plan such as Seong-Yong Choi
(POSDATA)
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
16/26
Software Project Management Plan Trinity Team
Role Responsibility Owner
assessment of potential risks and risk mitigation
action
Verification and acceptance of risk management
plan
Support to action of mitigation the risksTeam leader Monitoring and managing all aspects of the risk
management process
Verification and agreement of the risks and
mitigation plan for each risk
Support to action of coping strategy for each risk
Minho Jeung(2006 Spring Semester)
Risk Manager
Development of risk management plan
Support to elicit the risks
Support to agreement of the risks in meeting of
managing the risks
Registration of the risks in the risks trace metrics
Report to client and project leader about risk
status
Minho Jeung(2006 Spring Semester)
Developers Developing the coping strategy for each risk
Execution of mitigation plan for each risk
All members
6.3 Risk Management Model Description
6.3.1 Risk Identification
For the identification of any preventable fact on the success of project, all concerns about scope, schedule, resource, and quality aspect should be identified. Through the team meeting, the risk statement that has a condition and a consequence should be captured. Trinity team should deal with the risk lists.
6.3.2 Risk Analysis
The following activities are required for the risk analysis. The trinity team allocates the level of impact, probability, time-frame for each risk. Also the meaning to its correspondent level should be defined.
- Impact Type Meaning
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
17/26
Software Project Management Plan Trinity Team
Catastrophic Cannot any of it (Schedule slip > 20%)Critical Cannot able to be almost of all (Schedule slip 10 ~ 20%)Marginal Cannot still meet picture of success (Schedule slip 5~10%)Negligible Can do all, some impact (Schedule slip < 5%)
- Probability Type Meaning
High > 80 %Medium ~ 50 %Low < 20 – 25 %
- Timeframe Type Meaning
Short Next few weeks within the same semesterMedium Next few months within the same semesterLong Anything about beyond the semester
For the effective risk management, each risk is prioritized and classified. The Trinity team uses a simple and easy-to-use multi-voting technique.
6.3.3 Plan
Generally, the owner should execute the coping strategies and monitor the status of risk. And the owner should report the status of his own risk in weekly or monthly meetings to the risk manager and project leader. The risk management meeting during the weekly meeting should consider and manage below items.
6.3.4 Tracking
All team members should share and monitor top 5 risk lists regularly. Any change of the risk list should discuss in the risk management meeting such as addition, deletion, and modification of risk statement.
6.3.5 Control
For the risk assessment, the trinity team applies the mitigation strategy.① Mitigation
The action is for reducing time when the risk is occurred.② Avoidance
The action of eliminating the risk by changing the project schedule or scope generally③ Acceptance
The action is ignoring the risk before the risk is appeared. ④ Transfer
The action is transfer from risk to another risk. For example, if the internal consultant can’t solve the problem, project leader could ask to external consultant.
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
18/26
Software Project Management Plan Trinity Team
6.4 Risk Communication
The continuous risk management phase is doing in biweekly risk management meeting and weekly team meeting. The owner and other developers should discuss about the following considerations for the efficient risk management.
① New risks② Impact, probability, and time frame of each risk③ Mitigation strategy④ Report of the status of each risk
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
19/26
Software Project Management Plan Trinity Team
7 Configuration Management Plan
The Software Configuration Management (SCM) Plan provides the outline for Configuration Management (CM) through the Trinity team. This document defines SCM activities, makes team members responsible for specific activities, specify the tools for execution of the CM.
The CM is applied to the products which include source codes, libraries, configuration files and various deliverables that Trinity has made during studio projects. Other support elements such as editors, operating system and IDE are not included in the CM scope.
7.1 SCM Organization & Responsibility
All members have to be involved in all SCM activities because Trinity members are only 3 individuals. Therefore, we only organize three different roles to handle SCM activities which are the minimal organization that we should have. The detail information is shown below.
SCM activitiesOrganizational unit
CCB Quality Manager Developer
Identifying/Naming configuration items V
identification of the change needs V
Analysis request V
Approval & disapproval requests V
Verification, implementation of change V V
Configuration evaluation and review V V V
7.2 SCM Activities
According to IEEE standard, SCM activities information identifies all functions and tasks required to manage the configuration of the software system as specified in the scope of the plan. Trinity team defines five traditional functions to specify SCM activities.
7.2.1 Configuration Identification
The configuration items manage during whole studio project. Trinity team specifies configuration items mainly on 2006 spring semester. The items for summer semester will be specified later. All members have a right to create or modify documentations; however for each configuration items, there is a designated person to handle these changes. Therefore all members who want to change an artifact, they should tell the designated person. The configuration items and the product owner are shown below.ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
20/26
Software Project Management Plan Trinity Team
Configuration Items Product owner Semester
SOW Eunyoung Cho 2006 Spring
SRS Kyu Hou 2006 Spring
SPMP Minho Jeung 2006 Spring
Quality Management Plan Minho Jeung 2006 Spring
Requirement. Management Plan Minho Jeung 2006 Spring
Risk Management Plan Eunyoung Cho 2006 Spring
Configuration Management Plan Kyu Hou 2006 Spring
Software Architecture Design Minho Jeung 2006 Spring
Implementation TBD 2006 Summer
Test TBD 2006 Summer
7.2.2 Configuration Control
Configuration control is conducted in order to manage change requests, carry out impact analysis, and approve/disapprove changes. Trinity team will try to optimize the changes by effective communication with customers and team members.
7.2.2.1 Configuration Control Board
The Configuration Control Board (CCB) consists of all team members. We are not going to have CCB meeting on a regular basis.
7.2.2.2 Baseline Control
The baseline is set when a configuration item has been approved or changed based on a formal review. Once initial baseline has been established labeled as _V0.1, the number of label is increased by 0.1.
7.3 SCM Tools and Naming Conventions
The using automatic configuration management tools and keeping naming conventions are mandatory to ensure the configuration management is flawless.
7.3.1 SCM Tools
The following tools are used
Microsoft Word 2002
Microsoft PowerPoint2002
Microsoft Visio Professional 2003
Microsoft Excel 2002ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
21/26
Software Project Management Plan Trinity Team
Microsoft Project Professional 2003
Eclipse 3.1 to produce source codes
Eclipse CVS for version control of source codes
Microsoft SourceSafe 6.0 for documentations
7.3.2 Naming Conversions
7.3.2.1 Meeting Documentations
The documentations include weekly meetings and client meetings. The documentation is made by Microsoft Word 2002. The detail conventions are shown below
File name : Trinity_WeeklyMeeting_YYYYMMDD.doc e.g.) Trinity_WeeklyMeeting_20051010.doc
Save location : \\POSDATA\Studio\MeetingDoc\
7.3.2.2 Deliverable Documentations
The documentations cover SOW, SRS, SPMP, etc which are all deliverables. The document names should be abbreviated.
File name : Trinity_<abbrArtifactName>_VX.X.doc e.g.) Trinity_SOW_V0.1.doc
Save location : \\POSDATA\Studio\Deliberables\
Abbreviated artifacts name
CCB Change Control BoardCCB Configuration Control BoardSCM Software Configuration ManagementSQA Software Quality AssuranceSRS Software Requirements SpecificationSOW Statement of Work
7.3.2.3 Java Source Codes
7.3.2.3.1 Packages
The prefix of packages should start with com.mse.trinity in order to be a unique package
e.g.): com.mse.trinity.util
7.3.2.3.2 Classes or Interfaces
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
22/26
Software Project Management Plan Trinity Team
Class names should be nouns, in mixed case with the first letter of each internal word capitalized.
File Name : <class or interface name>.class e.g.) MapingNavigationMenu.class
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
23/26
Software Project Management Plan Trinity Team
8 Quality Assurance Plan
Quality assurance is to establish the framework of development procedures and standards that lead to high-quality software. Trinity team will assure that the Overlay Multicast Protocol (OMP) is reliable and free of bugs by tracking this QA plan. The goal of this document is to remove the defects as many as possible earlier in this project.
8.1 Design Review
8.1.1 Purpose and Scope
The purpose of design review is to assure that the detailed designs are complete and correct, and the detailed design satisfies the customer’s requirements. While reviewing the detailed design, Trinity team can detect the defects and incorrect design earlier in the life cycle.
8.1.2 Roles and Responsibilities
Roles Responsibilities
Quality/Process manager Quality assurance manager
Development manager Proceed as a requirement manager Review the first draft of detailed design of the first instance out of similardesignsLead the formal design review for the first draft of detailed design of the first instance out of similar designsReview every first draft of detailed design documents
Ensure all the design document is consistent and complete
Team members Change his/her design that was affected by the design reviewUpdate the detailed designs based on suggestions from the design review
Review the replica of the reviewed detailed designs according to the formal review cycle (Member 1→ Member 2→ Member 3→ Member 1)
8.1.3 Design Review Process
Design review will be started to verify the detailed design. Design review meeting will be held on the needs of development manager.The process is as follows:
① Team creates the detailed design artifacts.② Each team member reviews the artifacts before design review meeting.③ Each team member shares the defects and errors which are found from each member.④ Team discuss about the defects and errors.⑤ Team revises the defects and errors.
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
24/26
Software Project Management Plan Trinity Team
8.2 Code Review
8.2.1 Purpose and Scope
The purpose of code review is to detect the defects and bugs from the code in the early time during implementation period. In addition, the reviewer should find the mismatch between specification and code.
8.2.2 Roles and Responsibilities
Roles Responsibilities
Team members as a developer Update and revise the code Distribute the code
Team members as a reviewer Detect logical errorsEnsure that implementation meets the requirements specification
Review the code before review meeting
8.2.3 Code Review Process
① Developers create the code based on the requirement specifications.② Developers distribute their code to other team members and call review meeting.③ Other team members review the code before the review meeting④ In the review meeting, team members share and discuss defects and errors.⑤ Developers collect the data from review meeting.⑥ Developers update and revise the code.
8.3 Testing
8.3.1 Purpose and Scope
The purpose of testing is to verify the quality of the Overlay Multicast Protocol which is produced and integrated. Trinity team’s customer, POSDATA, will provide test cases.
8.3.2 Roles and Responsibilities
Roles Responsibilities
Quality/Process manager Proceed as an integration tester
Perform integration tests
Team members Specify test casesImplement (Porting of DSP & VR, Generate Simple test program)
Conduct unit testing and Fix bugs
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
25/26
Software Project Management Plan Trinity Team
8.3.3 Testing Process
- Unit Test① Quality/Process and Development manager makes the unit test cases.② Each unit developer reviews the unit with the test case.③ Other developers reviews the unit with specification and test case.④ Team discuss in review meeting about the defects.⑤ Each unit developer updates and revises the unit.
- Integration Test① Quality/Process manager makes the integration test cases.② Each team member reviews the test cases separately.③ Each team member documents the defects, bugs, and errors before review meeting.④ Team discuss in review meeting about the defects, bugs, and errors.⑤ Quality/Process manager assigns the defects and due date to the developers.⑥ Developers update and revise the code.
- Non-functional Requirement① Trinity team is provided the test case requirement from customer.② Trinity makes the test application followed the test case.③ Trinity tests the test case.④ Trinity collects the defects which do not satisfy customer’s requirement.⑤ Trinity revises the defects.
ICU & CMUMaster of Software Engineering Last Updated: 4/12/20232005-2006
26/26