Your SlideShare is downloading. ×
Overview
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Overview

268
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
268
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Software Project Management Plan Version 1.0 March 25, 2006 Trinity Team Team Members: Eunyoung Cho Minho Jeung Kyu Hou
  • 2. Document Information Document Name Software Project Management Plan Property 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 creation 2 0.2 February 26, 2006 Minho Jeung Team review 3 0.3 March 24, 2006 Minho Jeung Mentor’s review 4 0.4 March 25, 2006 Minho Jeung English correction 5 1.0 March 26, 2006 Minho Jeung Team review
  • 3. Software Project Management Plan Trinity Team Table of Contents 1 OVERVIEW.............................................................................................................................................5 1.1 PURPOSE, SCOPE, AND OBJECTIVES...........................................................................................................5 1.2 ASSUMPTIONS AND CONSTRAINTS...............................................................................................................5 1.3 PROJECT DELIVERABLES..........................................................................................................................5 1.4 SCHEDULE SUMMARY..............................................................................................................................6 2 REFERENCES........................................................................................................................................7 3 ACRONYMS............................................................................................................................................8 4 PROJECT ORGANIZATION...................................................................................................................9 4.1 TEAM INTERFACES..................................................................................................................................9 4.2 ROLES AND RESPONSIBILITIES...................................................................................................................9 5 REQUIREMENT MANAGEMENT PLAN...............................................................................................10 5.1 REQUIREMENTS MANAGEMENT ORGANIZATION.............................................................................................10 5.1.1 Configuration Control Board.....................................................................................................10 5.1.2 Tools, Environment, and Infrastructure....................................................................................10 5.2 THE REQUIREMENTS DEVELOPMENT PROCESS............................................................................................10 5.2.1 Requirements Identification.....................................................................................................10 5.2.2 Prepare for Requirements Cycle..............................................................................................11 5.2.3 Elicit Requirements..................................................................................................................11 5.2.4 Analyze Requirements.............................................................................................................11 5.2.5 Formalize Requirements..........................................................................................................12 5.2.6 Verify and Validate Requirements............................................................................................12 5.3 REQUIREMENT TRACKING.......................................................................................................................12 5.3.1 Maintaining Requirements’ Traceability and Tracking Requirements’’ Status..........................12 5.3.2 Requirements Attributes ..........................................................................................................13 5.4 REQUIREMENTS CHANGE MANAGEMENT.....................................................................................................14 5.4.1 Entry Criteria............................................................................................................................14 5.4.2 Tasks.......................................................................................................................................14 5.4.3 Verification ..............................................................................................................................14 5.4.4 Exit Criteria..............................................................................................................................14 5.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.............................................................................16 6.2 THE REQUIREMENTS RESPONSIBILITIES......................................................................................................16 6.3 RISK MANAGEMENT MODEL DESCRIPTION..................................................................................................17 6.3.1 Risk Identification.....................................................................................................................17 6.3.2 Risk Analysis............................................................................................................................17 6.3.3 Plan..........................................................................................................................................18 6.3.4 Tracking...................................................................................................................................18 6.3.5 Control.....................................................................................................................................18 6.4 RISK COMMUNICATION ..........................................................................................................................19 7 CONFIGURATION MANAGEMENT PLAN...........................................................................................20 7.1 SCM ORGANIZATION & RESPONSIBILITY...................................................................................................20 7.2 SCM ACTIVITIES.................................................................................................................................20 7.2.1 Configuration Identification.......................................................................................................20 7.2.2 Configuration Control...............................................................................................................21 7.2.2.1 Configuration Control Board................................................................................................................21 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 3/26
  • 4. Software Project Management Plan Trinity Team 7.2.2.2 Baseline Control..................................................................................................................................21 7.3 SCM TOOLS AND NAMING CONVENTIONS.................................................................................................21 7.3.1 SCM Tools...............................................................................................................................21 7.3.2 Naming Conversions................................................................................................................22 7.3.2.1 Meeting Documentations....................................................................................................................22 7.3.2.2 Deliverable Documentations...............................................................................................................22 7.3.2.3 Java Source Codes.............................................................................................................................22 7.3.2.3.1 Packages......................................................................................................22 7.3.2.3.2 Classes or Interfaces....................................................................................22 8 QUALITY ASSURANCE PLAN.............................................................................................................24 8.1 DESIGN REVIEW..................................................................................................................................24 8.1.1 Purpose and Scope................................................................................................................24 8.1.2 Roles and Responsibilities......................................................................................................24 8.1.3 Design Review Process...........................................................................................................24 8.2 CODE REVIEW.....................................................................................................................................25 8.2.1 Purpose and Scope................................................................................................................25 8.2.2 Roles and Responsibilities.......................................................................................................25 8.2.3 Code Review Process..............................................................................................................25 8.3 TESTING............................................................................................................................................25 8.3.1 Purpose and Scope.................................................................................................................25 8.3.2 Roles and Responsibilities.......................................................................................................25 8.3.3 Testing Process.......................................................................................................................26 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 4/26
  • 5. Software Project Management Plan Trinity Team 1 Overview POSDATA 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 & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 5/26
  • 6. Software Project Management Plan Trinity Team 1.4 Schedule Summary ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 6/26
  • 7. 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 & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 7/26
  • 8. Software Project Management Plan Trinity Team 3 Acronyms CCB Change Control Board CCB Configuration Control Board CI Configuration Item CM Configuration Management CMU Carnegie Mellon University ICU Information and Communication University IT Information Technology MSE Master of Software Engineering OMP Overlay Multicast Protocol SCM Software Configuration Management SI System Integration SQA Software Quality Assurance SRS Software Requirements Specification ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 8/26
  • 9. 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 Roles Fall 2005 Spring 2006 Summer 2006 Team Leader Minho Jeung Eunyoung Cho Kyu Hou Planning Manager Kyu Hou Development Manager Kyu Hou Eunyoung Cho Minho Jeung Customer Interface Manager Risk Manager Minho Jeung Quality/Process Manager Minho Jeung Eunyoung Cho Kyu Hou ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 9/26
  • 10. Software Project Management Plan Trinity Team 5 Requirement Management Plan The 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 & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 10/26
  • 11. 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 & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 11/26
  • 12. 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. 1 Provide a simple representation of the interdependencies among all forms of requirements and requirement expression, 2 Serve as a starting point for any requirement change estimation. 3 Track the status of completion of any requirement at any given time The requirement traceability and status matrix will have the following structure: 1 Requirement ID – the ID to identify the requirement uniquely. 2 Requirement Description – the description of the requirement. 3 Quality Attribute Name – The Quality Attribute Name. 4 Priority – The priority of requirement 5 Responsibility – the team member responsible for the requirement. 6 Date of Delivery – the promised date of delivery for the requirement. 7 Completion Status – completion status as an approximate percentage. 8 Completion Status Date – the date when the completion status was recorded. 9 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 & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 12/26
  • 13. 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 The order of requirements according to its importance. High High means the system will not succeed without a particular Medium Priority requirement. Medium means the system manage to run, but Low customer wish to apply it soon. Low means that the customer satisfaction is ok, and the requirement can be handled later. The current requirement’s feature. Proposed indicates the Proposed requirement is not reviewed by customer. Approved means the Approved requirement is officially accepted by customer. Incorporated Incorporated Status means the requirement is incorporated into the implementation. Validated Rejected means that the requirement is not accepted by CCB. Rejected Cancelled means that customer cancels the requirement. Cancelled The degree of difficulties of the requirement to be implemented in High terms of the technical and business complexity. Medium Difficulty High indicates that the requirement takes more than 3 days to Low implement. Medium takes 1~3 day. Low takes less than 1 day. An indicator of how likely the requirement will change in the High future. High indicates the customer is confident that the Medium Stability requirement will not change. Medium means that the customer Low may change the requirement. Low means the customer are very likely to change the requirement. Assigned to The name of developer who is responsible to the requirement. N/A Origin The source of the requirement N/A ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 13/26
  • 14. 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 Request The customer communicates the change request to the Trinity team. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 14/26
  • 15. 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 & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 15/26
  • 16. Software Project Management Plan Trinity Team 6 Risk Management Plan Risk 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. • Taxonomy • Risk action • Risk form • Risk correction Identify • Routine periodic risk reporting Control POSDATA Trinity Team ze Communication • Criteria filter aly Track • Comparison risk ranking An • Risk Metric • Nominal group technique • Status indicators • Triggers Plan • Review and assign • Periodic tech reviews • Strategize 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 Owner Client  Provide input into risk management plan such as Seong-Yong Choi (POSDATA) ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 16/26
  • 17. 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 risks Team leader  Monitoring and managing all aspects of the risk Minho Jeung (2006 Spring Semester) management process  Verification and agreement of the risks and mitigation plan for each risk  Support to action of coping strategy for each risk Risk  Development of risk management plan Minho Jeung Manager (2006 Spring Semester)  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 Developers  Developing the coping strategy for each risk All members  Execution of mitigation plan for each risk 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 & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 17/26
  • 18. 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 semester Medium Next few months within the same semester Long 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 & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 18/26
  • 19. 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 & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 19/26
  • 20. 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. Organizational unit SCM activities 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 & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 20/26
  • 21. 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 2002 ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 21/26
  • 22. 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 : POSDATAStudioMeetingDoc 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 : POSDATAStudioDeliberables Abbreviated artifacts name CCB Change Control Board CCB Configuration Control Board SCM Software Configuration Management SQA Software Quality Assurance SRS Software Requirements Specification SOW 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 Class names should be nouns, in mixed case with the first letter of each internal word capitalized. ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 22/26
  • 23. Software Project Management Plan Trinity Team File Name : <class or interface name>.class e.g.) MapingNavigationMenu.class ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 23/26
  • 24. 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 similar designs Lead the formal design review for the first draft of detailed design of the first instance out of similar designs Review 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 review Update 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 & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 24/26
  • 25. 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 errors Ensure 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 cases Implement (Porting of DSP & VR, Generate Simple test program) Conduct unit testing and Fix bugs ICU & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 25/26
  • 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 & CMU Master of Software Engineering Last Updated: 7/15/2010 2005-2006 26/26