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


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


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


5/26


1.4 Schedule Summary


6/26


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


7/26


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


8/26


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


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


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-


10/26


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


11/26


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.


12/26


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


13/26


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.


14/26


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.


15/26


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)


16/26


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


17/26


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.


18/26


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


19/26


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


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


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


22/26


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


23/26


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.


24/26


8.2 Code Review


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.



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


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.



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


25/26


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.


26/26

Documents

Overview