Abstract
Software Quality Assurance (SQA) Plan specifies the SQA standards and methodology which will be followed during each phase of the project to ensure the delivery of quality product. This document also specifies the tools and process that will be used to achieve the defined standards and methodology. This document is based on the SQA processes discussed in the class combined with the past experience of the team members.
The enclosed SQA document details the following areas:
- Standards and Methodologies
- Organizational Roles and Their Responsibilities
- SQA Tasks and Activities
- Configuration Management and Change Control Process
- Test Approaches
- SQA Tools and Training
This JFree5 Software Quality Assurance Plan has been designed to be comprehensive, examining all of the areas that are important for a quality process and product. This plan is intended to be a stepping-stone to help the JFree5 team to refine their quality assurance processes in realization of their goals.
Version History
Version Number | Date | Author | Comments |
1.0 | 02/03/05 | Jfree5 Team | First Version |
1.1 | 02/18/05 | Jfree5 Team | Change Control modified, Updated the date, Review schedule deleted, SQA standard and methodology modified, Test Approaches modified |
1.2 | 03/21/05 | JFree5 Team | Modified sec. 2.6 |
Table of Contents
1.0 Introduction………2
1.1 Purpose and Scope….2
1.2 Plan Structure……..2
2.0 SQA Standards and Methodology…..3
2.1 Standards and Methodologies…..3
2.2 Organizational roles and their responsibilities…..3
2.3 SQA Tasks and Activities…..3
2.4 Configuration Management and Change Control Process……4
2.4.1 Problem Reporting, tracking and corrective actions…..4
2.4.2 Change Control….4
2.5 Test Approaches4
2.5.1 Cross Functional Testing….4
2.5.2 Unit Testing…..4
2.5.3 System Testing…..4
2.6 Metric used…..5
3.0 SQA Tools And Training…..6
4.0 References….7
List of Tables
Table 2 Correctness metric Format….5
Table 3 SQA Tools and Training….6
Introduction
Software Quality Assurance Plan describes the necessary steps for the smooth execution of the JFreeChart project. Writing the Software Quality Assurance Plan provides a structured framework for thinking about how the project will be conducted, and for considering the steps to be taken for delivering the quality product. Having a comprehensive plan may require the involvement of a range of functional experts and it often requires the involvement of decision makers.
Purpose and Scope
The goal of the project is to develop a part of the system that assists developers in using the JFreeChart package effectively. The Software Quality Assurance Plan is used to describe the process that will be followed during each phase of the software lifecycle to achieve this goal. It is used to communicate software quality processes and procedures to be used throughout the project.
This document lists all the applicable standards and methodologies that are applied during the software process. Document also defines for each member of the Project team, the organizational roles and their responsibilities. It further defines the process that should be followed when issues are identified and the review process to be followed to solve those issues.
The Configuration Management and Change Control Process tell us how different versions of the files will be maintained. Test Approaches discuss different strategy that will be followed to deliver a quality product. These strategies are selected to ensure that both the documentation and the end user product meet the customer expectations. Correctness is the only metric that will be tracked during this project. Section 2.6 discusses how this will be achieved.
Finally the SQA Tools and Training section focuses on the commercial tools that will be used for carrying out SQA activities. It also considers the training that might be required for the team member for the effective use of the tools.
Plan Structure
The project management plan includes:
- Standards and Methodologies
- Organizational Roles and Their Responsibilities
- SQA Tasks and Activities
- Configuration Management and Change Control Process
- Test Approaches
- SQA Tools and Training
- References
QA Standards and Methodology
Standards and Methodologies
The development methodology used for the JFreeChart Assistant Tool will be based on the proven IEEE SQA Plan, as follows:
- Purpose
- Reference Documents
- Documentation
- Standards, Practices, Conventions and Metrics
- Reviews
- Test
- Problem Reporting and Corrective Action
- Tools, Techniques and Methodologies
- Training
- Risk Management
The IEEE standard helps to ensure production of high-quality software that meets end-user needs within time. For more details refer to [2].
The iterative model used is shown and described in the Project Management Plan.
Organizational roles and their responsibilities
All the team members share the responsibility to assure that a high quality product is delivered to the customer. The quality manager is different for each phase of this project. All individuals will be participating in the scheduled reviews, code walkthroughs, unit and black box testing. The individuals involved will provide feedback on their work, limitations (if any) and also participate in taking corrective actions to ensure quality.
An issue once raised should be solved in the stipulated time. In case of further doubts a team meeting can be called by the phase manager and the issue would be put forward. There may not be universal agreement on the solution, in which case, the phase manager will be responsible for taking a decision. The phase manager can either decide on a particular solution or can record it for further discussion off-line.
The review team has to do the review work before the final review meeting. It may not be necessary for everyone to participate in the review meeting. The members of the meeting may be limited to the number of reviewers and the phase manager.
The review team will follow the review guidelines to assure quality of the product and integrity of the team. For more details refer to [1].
SQA Tasks and Activities
Reviews will be internal peer to peer reviews. Walkthroughs will be internal and performed by fellow team members. Documents and models are due for review on the scheduled date (mentioned in the Project Management Plan), and should not last for more than one day. All changes made to the documents must be approved by everyone or at least the review team and the phase manager in case of conflicts. This is to ensure completeness and correctness and to reduce conflicts and discussions on arguable solution.
Configuration Management and Change Control Process
Problem Reporting, tracking and corrective actions
In each phase, problems will be reported on the JFree5 group email, with the issue as the subject line. Depending on the criticality of the problem, the phase manager can call in a meeting of the team members immediately. All the problems will be tracked and stored in the excel file, “Defects.xls”, with one sheet for each phase. All the artifacts changed, due to the removal of the defects will be stored as explained in change control section.
Change Control
All the documents will be stored in the group repository. The team repository is located at /proj/cs/cs_se6354/JFree5/ASEProject, the server space provided to JFree5 team. CVS will be used for version controlling during all the phases. The final copies of all the documents are also uploaded on the group site (JFree5 yahoo groups) for the backup purposes.
Test Approaches
Test Approaches describe the testing strategy and approach which will be used to validate the quality of the product prior to release. It should be flexible enough to promote the creativity and customization of the system. At the same time, the strategy must be rigid enough to promote reasonable planning and management tracking as the project progresses. We will use different test approaches in our project.
Cross Functional Testing
In JFree5 project, cross functional testing is employed. The work of one person is reviewed by the team as a whole. Additions, corrections, testing are done on that part; hence the final work is evolved through cross functional way.
Unit Testing
JFree5 project will be tested through Unit Testing. In this, each software unit will be tested by the developer. Using the Detail Design document as a guide, important control paths will be tested to uncover errors within the module.
System Testing
System Testing is the testing of complete system prior to delivery. JFreeChart project will be system tested after integration. The purpose of system testing is to identify defects that will only surface when a complete system is assembled. That is, defects that cannot be attributed to individual components or the interaction between two components. We will use Black Box testing which focuses on the functional requirements of the project. It will enable us to derive sets of input conditions that will fully exercise all functional requirements for a project
Metric used
Metrics provide a quantitative background to measure the quality of software development process and its final product. It is a measure of the degree to which a system, component or process possesses a given attribute. Metrics are used throughout a software project to assist in estimation, quality control, productivity assessment and project control. JFreeChart project will use Correctness as a metric.
Correctness is the extent to which a program satisfies its specification and fulfills the customer’s objectives. It is the degree to which a system or component is free from faults in its specification, design, and implementation. For each phase of the project the Quality Manager of that phase will analyze ‘Correctness’. The Checklist provided by the customer will be used for correctness. For each phase, a table will be formed indicating the defects found against each item of the checklist during the internal and customer reviews.
One implication is that the software and process to develop the software must be error free. Errors are located by inspections and other peer reviews, by unit testing, and by integration and system testing. The correctness metric is shown as:
Defect Information |
Defect Number |
Defect Component |
Defect Description |
Phase Detected |
Date Detected |
Assigned To |
Verified By |
Criticality |
Date Closed |
Status |
Table 2 Correctness metric Format
We maintain the excel sheet Defects.xls which will track correctness metric for the JFreeChart project.
SQA uses this metric in order to qualify the software and help management take corrective actions even before testing starts. The metrics for correctness lend themselves to a number of risk projections. For more details on correctness metric refer to [3].
SQA Tools And Training
Activity | Tool Used | Training | Comments |
Configuration Management | CVS (Concurrent Versions System) | Common lab tutorial to all the students of CS6354 on 6th Feb from | Maintaining proper versions of all the documents and code files is a major quality issue so as to keep track of all the changes made to any of the document/code when, why and by whom. |
Defect Reporting and Tracking | MS Excel | Basic understanding of Excel. | For reporting and resolving defect in a deliverable whether it is a document or code, we will be maintaining an excel sheet “Defects.xls” which will enlist defects with description, phase detected, person responsible ( for solving, testing and closing), date opened, date closed. |
Issue Reporting and Tracking | Yahoo Group (JFree5) and Emails | None. | For reporting issues the Project Management Plan Section 7.1 has proper description of how the issue will be reported, tracked and resolved. The Yahoo Group email is used to intimate all the team members about any Issue raised, meeting called to resolve the issue and to track the status. Since this is a small project and all the team members will be actively participating in all the phases this seems to be the most effective way of keeping track of issues. |
Table 3 SQA Tools and Training
===============================================MyCASE TOOL
Quality Assurance Plan
Version: 6
Instructor: Dr. Kendra Cooper
Team A Summer 2003
Team Members:
Jake Breedlove Ryan Lange
Qun Li Hongxu Liu
Li Liu Fei Xiao
Jim Xu Hongyan Yu
ABSTRACT
This document presents the quality assurance plan for the MyCASE Tool project. The quality assurance plan contains a detailed quality assurance mechanism for the MyCASE Tool. It describes the objectives of Software Quality Assurance (SQA) in the project, the SQA standards and methodology, SQA tasks and activities, SQA tools, and training for the MyCASE project.
TABLE OF CONTENTS
2 Development Methodology and Standards Use……7
2.1 Standard and Methodology……7
2.1.1 Object-Oriented Process……7
2.1.2 Business Modeling and Requirements……8
2.2 Organizational roles and their responsibility……13
2.2.3 Quality Assurance Engineer……14
2.2.4 Document organizer and reviewer……14
2.2.5 Website Administrator……14
2.3 SQA Tasks and Activities……15
2.3.2 Standards, Practices, Conventions, and Metrics……15
2.3.3 Reviews and Audits and Inspections……16
2.3.5 Problem Reporting and Corrective Action……18
2.3.6 Configuration Management Plan……20
LIST OF FIGURES
Figure 1 RUP Software Object-Oriented Process……8
Figure 2 Organization Structure of MyCASE……13
Figure 3 Configuration Management tool……20
LIST OF TABLES
Introduction
The Quality Assurance Plan describes the procedures to ensure the deliverables meet the standards set forth. Quality of conformance, an attribute measured in quality assurance, is the degree to which the system conforms. Here are major quality attributes the MyCASE Team will be examining:
- Correctness
- Consistency
- Completeness
- Usability
- Efficiency
- Reusability
The MyCASE project will not be implemented with an adhoc approach, the product will be designed with a software engineering model. The product will be developed with quality in mind during the entire lifecycle, including requirement elicitation, analysis, architecture, implementation, unit testing and integration testing. The Quality Assurance Plan will provide the blueprints to produce successful deliverables throughout the lifecycle of the project.
This document describes the software quality assurance plan that is to be followed during the development of the MyCASE tool. The SQA standards and methodology that are to be followed by the whole team will be identified first. An organizational hierarchy for this project, including responsibility, will then be described. A set of activities to be performing to ensure the quality of product will be defined. Finally, the necessary SQA tools and additional training requirements for the group members will be.
Development Methodology and Standards Use
Standard and Methodology
Object-Oriented Process
MyCASE will use Java as the primary implementing language. MyCASE will use the Unified Modeling Language (UML) notation to design the product. To support object-oriented development approaches, MyCASE will use the Rational Unified Process (RUP) as the basis for the UML object oriented activities. RUP is attractive because it defines the following steps:
- Develop software iteratively
- Clearly define the roles and responsibilities within each process
- Create activities within each process
- Develop the work products as the result of the execution of the process
- Create a risks plan associated with the process
- Setup Configuration/Control Management
The RUP has been tailored for the MyCASE project, as shown in Figure 1, so that full advantage can be derived from the Rational Rose Modeling tools. The RUP describes an incremental iterative approach for developing object-oriented system. It describes different activities of the software life cycle, detailing what tasks are performed and what products are produced during each activity. The project life cycle phases of Figure 1 progress from left to right. The names are taken directly from RUP. The software development activities progress from top to bottom. MyCASE will only be able to implement an iteration of phase due to a limit of time.
Figure 1 RUP Software Object-Oriented Process
Business Modeling and Requirements
The MyCASE software development effort will use a United Modeling Language (UML) Use Case Diagram to depict the requirements via Rational Rose. Rational Rose, which runs in the Windows PC environment, is the core tool of the UML-based analysis and design approach being used for the MyCASE project.
Analysis and Design Methods
MyCASE software development effort will use the following UML techniques:
Constructing a design model with class diagrams
Constructing a design model with sequence diagrams
Constructing a software design document
Implementation and Testing
Design, coding, and testing will be performed within a Windows PC environment. The Net Beans Integrated Development Environment (IDE) will be used to create Java 1.4 compatible software.
Deployment
There is no additional deployment tool need.
Configuration and Change Management
The MyCASE software development effort will use CVS. CVS is UNIX based configuration management tool that keep track of different version of code.
Project Management
The MyCASE software development effort will use Microsoft Project and an additional Microsoft Word Document to keep track of its process.
Development Tools Summary
Table 1 below is complete summary of MyCASE development process and the tools it used. Software development for the MyCASE uses available tools on the machines in the school lab.
Table 1 Support Tools
Tools | Vendor | Primary Uses | Platform | Development Phases | |||
Win | Reqs Des Code Test | ||||||
Rational Enterprise Edition | IBM | Integrated suite of products for Software Design and Development | |||||
Rose | Analysis & design modeling | · | · | · | |||
Purify | Run time error detection | · | · | ||||
Pure Coverage | Code coverage monitoring | · | · | ||||
Microsoft Word | Microsoft | Proposal, Quality Assume Plan, Requirement, Testing | · | · | · | · | · |
Microsoft PowerPoint | Microsoft | Status Report, Presentatation | · | · | · | · | · |
Microsoft Project | Microsoft | Status progressive | · | · | · | · | · |
NetBeans IDE | NetBeans | IDE for code development and debugging | · | · | · | ||
CVS | Configuration/Change Management | ||||||
Standards Used
The following sections describe the Rose Modeling standards and Java coding standards for MyCASE software development.
Rose Model View
Use Case View
The use case view describes functional requirements of MyCASE. Functional requirements are described by means of actors and use cases.
Actor
An actor is an outside user who interacts with the system. An actor within the use case model describes a set of actor instances.
Included Use Cases
The included use cases are ones that include other use cases (to be reused).
Sequence Diagrams
Does not show a class name on object instance
Object instance name should start with lower case letter and subsequent name should start with capitalized letter. The Object instance should be underlined.
Class Diagrams
Attribute names should following Java coding standard
Operation names should following Java coding standard
The first letter of each word should be capitalized in a class name.
Java Coding Standard
The Java Coding Standard is taken from the real-world experiences on the third party online documentation.
File
Java files must have the same name as the primary class contained in the file appended by “java”.
Example: Project.java
Package
Java package must have a single lowercase name.
Example: project mapping
Classes
Capitalize the first letter of the name and first letter of the subsequent words of the name.
Example: NewProject.java
Attributes
Class attributes will always be declared as private. Lowercase will be used for the first letter of the attribute and uppercase for the first letter of the subsequent words of the name followed with an underscore.
Example: myAttribute_
Variable
Each variable will be declared on a separate line and initialized to NULL.
Comment
Use C++ style (//) comments. Separating function by a comment line (//--------).
File Header
Every file will begin with a standard documentation header.
Example: //---------------
// class name
// description:
Constants
Constants will be all capital letters.
Class Order
Class layout should have the following order:
Constructor
Destructor
Public method
Protected method
Private method
Private attributes
Organizational roles and their responsibility
The following is a diagram depicts the organization structure.
Website Administrator Deliverable 1 Deliverable 1 Deliverable n Project Manager …… 
Figure 2 Organization Structure of MyCASE
The project manager will control and manage the development process of the project. A website administrator will maintain the project website. Each deliverable will consist of assigned team members creating a subgroup of the organization. Each team member can be a developer, SQA engineer, or a document organizer. Some subgroups may have a team lead (who could also be a developer, SQA engineer or document organizer) and will report to the project manager.
The following are the responsibilities of each role.
Project Manager
Developer
Developers are responsible for the implementation phase. They need to be involved in all phrases of development, including requirement elicitation, analysis, system design, implementation and unit testing. They also need to follow the standards specified in this document to ensure consistent quality.
Quality Assurance Engineer
Each of the quality assurance engineers is responsible for follow the test standard listing in the Quality Insurance Plan. The Quality Assurance Engineer needs to verify unit testing on the each module. Once all the individual modules meet the standard listing in SQA Plan, the modules are integrated and the integration testing is performed in final system.
Document organizer and reviewer
He/She will be responsible for all document presented are format, proofread and organize in consistent manner.
Website Administrator
The website administrator needs to create, maintain, and frequently update the project website. The administrator will also need to notify the project manager and team of website related problems.
Team Lead
He/She is responsible for one deliverable. He/she is coordinate and makes sure every developer, quality assurance engineer of each team got necessarily resources they need.
He/she is also coordinate and makes sure every module in that deliverable is done on time. He/she is also responsible open communication between developer, tester and project manager.
SQA Tasks and Activities
QA tasks shall include but not limited to:
Documentation
Standards, Practices, Conventions, and Metrics
Reviews and Audits
Test
Problem Reporting and Corrective Action
Configuration Management Plan
These tasks are detailed in this document.
2.3.1 Documentation
2.3.1.1 Purpose
The purpose of this section is to define the documentation that will be used to ensure quality.
2.3.1.2 Minimum Documentation Requirements
The following documentation will be produced:
SQAP: Software Quality Assurance Plan (this document)
SPMP: Software Project management Plan
SRS: Software Requirements Specification
SDD: Software Design Document
STP: Software Test Plan
User’s manual
2.3.2 Standards, Practices, Conventions, and Metrics
2.3.2.1 Purpose
This section describes the standards, practices, conventions, and metrics to be used for the MyCASE project. These are intended not only to ensure quality of MyCASE project, but also to obtain quantitative metric data on the QA process itself.
2.3.2.2 Content
Standards: The IEEE standards, with appropriate modifications, are to be used for documentation.
Practices:
- Because the quality of project would affect the final grade of each member in the team, and we have no time to repeat the works several times within a short semester. The delaying quality is strongly to be avoided. Each team member should apply quality precepts while working rather than as an afterthought.
- All project artifacts are inspected and all are made easily available to the team. This is done by placing artifacts under configuration management, where the contents can be seen at any time.
- All processes are to be reviewed at least once for improvement and the written results should be kept for the post-mortem review.
Conventions: Where feasible, writing conventions should conform to the suggestions in Writing for Computer Science: The Art of Effective Communication by Justin Zobel (Springer Verlag; ISBN: 9813083220).
Metrics: At least two metrics will be maintained for every process, and every document.
- Time spent by each group on every artifact, it compares the estimate time with the actual time.
- Number of major defects per documentation based on professor’s evaluation, not more than 4 major defects.
All data are collected by each group’s team leader, and the data are stored in website.
2.3.3 Reviews and Audits and Inspections
2.3.3.1 Purpose
The purpose of reviews and audits is to provide a means of focusing the attention of team members on quality of the application as it develops. Reviews carry this out in a scheduled and thorough manner.
2.3.3.2 Minimum Requirements
Refer to the SPMP for the schedule of reviews detailed herein.
2.3.3.2.1 Software Requirements Review
This review will be led by the project leader and will be a walk-through of all the requirement documents. This review is not an alternative to any inspections. The project leader will be in charge of seeing that all inspections are carried out.
2.3.3.2.1A Software Requirements Inspection
All requirements will be inspected in accordance with the IEEE industrial standard.
2.3.3.2.2 Preliminary Design Review
This review will be conducted by the whole development team, led by the project leader. This review will review alternative architectures. It is expected that the team will provide feedback, which will be reflected in the final design.
2.3.3.2.3 Critical Design Review
This review is a group inspection of the proposed architecture. The project leader shall oversee that every aspect of the proposed architecture is covered in the meeting. The architecture will have been inspected prior to this review. If possible, the architecture will be decomposed into detailed designs of its parts, and these will undergo separate critical design reviews.
2.3.3.2.4 SVVP Review
There will be no SVVP review for this project.
2.3.3.2.5 Functional Audit
Prior to delivery, the project leader shall be responsible for checking that the product being delivered satisfies the requirements in the SRS.
2.3.3.2.6 Physical Audit
Prior to each delivery, the QC leader shall be responsible for checking that the physical software and its documentation designated for delivery are indeed delivered.
2.3.3.2.7 In-process Audits
Project personnel should expect random audits of their work. The subject of these audits will be the current work of teams and individuals that has been allocated to the project.
2.3.3.2.8 Managerial Review
The MyCASE project shall be reviewed every week. Individuals and project leaders will participate in the review.
2.3.3.2.9 SCMP Review
The QC leader shall review the status of CM every week basis in a manner independent of the procedures specified in the SCMP (in the later section of this document)
2.3.3.3 Inspections
All artifacts of the MyCASE project will be inspected.
2.3.4 Test
The QA leader, appointed by the team leader and approved by the majority of the group members, will be responsible for performing all of the Quality Control (QC) functions. The QA leader may request additional personnel for assistance by contacting the team leader. Engineers are also responsible for testing their own codes before submitting them to the QA leader. Refer to the Software Testing Plan for more information on testing for the MyCASE Tool System.
2.3.5 Problem Reporting and Corrective Action
Team members use Problem Reporting Form to report software problem generated by QA, and use a Defect Management Tool for the website to post defects. Problem Reporting Form should contain the following:
- Defect Identified
- Priority
- Phase Detected
- Phase Introduced
- Defect Author (proposed by)
- Assigned To (responsible person)
- Due Date
- Status
- Modules Affected
The documentation defect type are missing material, unclear, ambiguous, incomplete, redundant (with or between documents), and contradictory. The code defects type are syntax, logic, data (i.e., allows a wrong variable value), and insecure (allows unacceptable security breach).
An inspection will consist of at least one inspector. The inspector shall enter defects into the defect management tool. The author will accept or reject defects and fix accepted defects.
The author will advance the status in the defect management tool to "Ready" and notify the inspector. The inspector will advance the status to "Verified" or degrade the status to "Not Ready" and inform the SQA Engineer and the author. The SQA Engineer will ensure the process has been followed and advance the status to "Closed" for "Verified" defects.
The following is an example to illustrate how this works:
There is a potential defect in the sequence diagram because there was no actor icon in the screen shot for the proposal. So, the person who identified the problem would follow the procedure identified in the SQA document.
Enter the defect with details first, followed by [Ryan Lange] selecting yourself as the author , [Ryan Lange] then select the Assigned person, the fill in the Due Date[Ryan Lange] with the following format MM/DD/YYYY. Upon completion of entering the defect an e-mail should be sent to the group identifying the new defect and the assigned person to the defect. Upon completion of the fix of a defect the status should be updated to "Ready." The author should notified of the "Ready" status and then verify the defect is fixed. If the defect is not "Ready," the status should be set back to Assigned and a notification should be sent out. If the defect is "Ready," the status should be set to "Verified," and the SQA should be notified. The SQA should make the final check, upon approval the status should be set to "Closed." All defects shall remain in the system for historical data analysis and collection of metrics.
Actual data that will show up on the website:
Defect Identified: Monday, June 16 2003, 07:57 pm
Priority: High
Phase Detected: Requirements
Phase Introduced: Requirements
Defect Author: Ryan
Assigned To: Hongxu
Due Date: 06/17/2003
Status: Assigned
Modules Affected: Proposal
The proposal needs an updated project deliverable schedule.
The screen shot of website is as follows:
Figure 3 Configuration Management tool
2.3.6 Configuration Management Plan
2.3.6.1 INTRODUCTION
This Software Configuration Management Plan (SCMP) describes how artifacts will be managed for the MyCASE Tool System model.
2.3.6.1.1 Acronyms
CI: configuration item – an item tracked by the configuration system.
CM: configuration management – the process of maintaining the relevant versions of the project.
SCMP: Software Configuration Management Plan – this document
2.3.6.1.2 Terms
Approved Cis: CIs signed off by project management
Artifact: A final or interim product of the project (e.g. a document, source code, object code, test result)
Master File: A particular designated file for this project
2.3.6.2 SCM MANAGEMENT
2.3.6.2.1 Organization
The Project Leader will specify a team member designated the “configuration leader” for the duration of the project.
2.3.6.2.2 SCM Responsibilities
2.3.6.2.2A Configuration Leader
The configuration leader is responsible for managing the CIs. The configuration leader will discuss the various details of CM plans with the development team. In addition, the configuration leader will keep this document (SCMP) updated for all group members.
2.3.6.2.2B Project Leader
The project leader has the authority to assume the position of the configuration leader under exceptional circumstances. The project leader is responsible for overseeing the whole project and ensuring the advancement of the project is as smooth as possible.
2.3.6.2.2C Team members
All team members must abide by the CM rules that the configuration leader establishes.
2.3.6.2.3 Applicable Policies, Directives, and Procedures
1. All project releases are subjected to review and peer inspection.
2. All versions of CIs will be retained.
3. The master file (see Section 2.3.6.3.1.2) must be secured at all times.
4. The project leader and CM leader shall have access to all documents.
5. Announcements are to be posted on the team message board.
2.3.6.3 SCM ACTIVITIES
2.3.6.3.1 Configuration Identification
2.3.6.3.1A Identifying Configuration Items
The project leader is responsible for identifying all CIs. Team members should propose his or her CIs through e-mail or schedule a meeting with the project leader.
2.3.6.3.1B Naming Configuration Items
The team members shall have the responsibility for labeling all CIs. Naming convention shall be finalized before any coding begins. The file conventions should follow the following format:
Root directory: MyCASE
Subdirectory: SRS or SDD or …
Filenames: V-V-VVV.xxx corresponding to version V.V.VVV
For example, version 1.2.3 of the SDD will be store in MyCASE/SDD/1-2-3.txt
The text file Built.txt in the root directory will contain the versions of the CIs that comprise the current and previous states of the project. Example:
Project Release | SRS | SDD | … |
2.3.6.3.1C Acquiring Configuration Items
Team members requiring CIs should contact the project leader for proper access. Team members should not transfer any CIs directly to anyone without prior consent from the project leader.
2.3.6.3.2 Configuration Control
2.3.6.3.2A Requesting Changes
Team members may request changes to CIs by sending the proposed changes to the team leader via e-mail. The team leader will then inspect these proposed items and will announce these proposed changes on the team message board, where all team members will be able to input their opinion or suggestions.
2.3.6.3.2B Evaluating Changes
The team leader and the entire team members will evaluate all proposed changes. The team leader will have the authority to refuse the proposal if the proposed changes will degrade the overall project quality or performance.
2.3.6.3.2C Approving or Disapproving Changes
The team leader must approve proposed changes before the changes are implemented. If the team leader could not be reached for more than 48 hours, the proposed changes will be posted by the requestor on the team message board and undergo a vote by the team members.
2.3.6.3.2D Implementing Changes
Once proposed changes are approved, the team leader will be responsible for coordinating the implementation of these changes. The team leader has the authority to assign particular team members to implement these changes. This should be done in compliance with the Software Test Document. All versions cannot be released without the approval of the team leader.
2.3.6.3.3 Configuration Status Accounting
The team leader shall update the configuration summary on the team message board at least once a week.
2.3.6.3.4 Configuration Audits and Review
The team leader shall schedule weekly project meeting to review CM status and other relevant information that concerns the project.
2.3.6.3.5 Interface Control
The CM system interfaces with the team message board. The message board shall be moderated by the message board administrator in conjunction with the team leader.
2.3.6.4 SCM RESOURCES
Configuration leader will be responsible for updating the CIs weekly. When the configuration leader is not available, the project leader will function as configuration leader temporarily.
2.3.6.5 SCM PLAN MAINTENANCE
All modification to this document must be approved by the entire CM team and must be approved by the project leader before any modifications are made.
The configuration leader will perform the following for the CM process improvement sessions:
- Review the effectiveness of this plan
- Analyze the cost of the defects in this plan
- Investigate new solutions or improvement
- Suggest specific improvements
- List the benefits of improvements
- Provide estimates on the effects of the improvements
3 SQA Tools
The MyCASE Tool project will use Rational RoseTM for design, and will be implemented in Java. Object-orientation is to be used throughout. Javadoc will be used for documentation as much as possible. Rational® Robot is to be used for testing.
· Rational Enterprise Edition
· Microsoft Project
· Microsoft Word 2000
· Microsoft PowerPoint
· NetBeans IDE
· CVS
· Pure Coverage
· Purify
· Rose
4 Training
The SQA organization will conduct an initial two-hour orientation on quality for the development team. This will include a presentation on the metrics to be used, and a workshop on how to use tools for recording them. SQA will also conduct weekly two-hour tutorial for development team members to keep them informed of quality goals, tools and techniques.
Orientation, Q&A, tutorial and lecture sessions have been arranged.
- Orientation on quality: 8:00 p.m. – 10:00 p.m. Thursday June 4/03, main lab on ground floor
- Extra Q & A session to answer questions about the RUP: 9:00 a.m. - 10:00 a.m. Saturday June 7/03, EC 2.203
- CVS Tutorial: 10 a.m. - 11 a.m. Saturday June 7/03, main lab on ground floor
- UML Tutorial: 11 a.m. - noon Saturday June 7/03, main lab on ground floor
- Java, Netbeans Tutorial: 10 a.m. - 11 a.m. Saturday June 14/03, main lab on ground floor
- Rational Rose Tutorial: 11 a.m. - noon Saturday June 14/03, main lab on ground floor
REFERENCES
[2] Eric J. Braude, Software Engineering, An Object-Oriented Perspective, John Wiley & Sons, 2001.
[6] http://www.object-refinery.com/jfreechart
[7] http://www.utdallas.edu/~kcooper
[8] http://www.togethersoft.com/services/practical_guides/umlonlinecourse/
[10] http://www.rational.com/media/whitepapers/rup_bestpractices.pdf
