• No results found

Software Quality Assurance Plan

N/A
N/A
Protected

Academic year: 2021

Share "Software Quality Assurance Plan"

Copied!
10
0
0

Loading.... (view fulltext now)

Full text

(1)

Software Quality Assurance

Plan

for

AnthropodEST pipeline

System

Version 1.0

Submitted in partial fulfillment of the requirements of the degree of

Master of Software Engineering

Prepared by

Luis Fernando Carranco M.

CIS 895 – MSE Project

Kansas State University

(2)

1 Purpose ... 3

2 Reference documents ... 3

3 Management ... 3

3.1 Organization ... 3

3.2 Tasks ... 4

3.3 Responsibilities ... 4

4 Documentation ... 5

5 Standards, practices, conventions, and metrics ... 6

5.1 Documentation standards ... 6

5.2 Coding standards ... 6

5.3 Logic structure standards ... 6

5.4 Data structure standards ... 6

5.5 Commentary standards... 6

5.6 Metrics ... 7

6 Reviews and audits ... 7

7 Test ... 7

8 Problem reporting and corrective action ... 7

9 Tools, techniques, and methodologies ... 8

10 Code control ... 9

11 Records collection, maintenance, and retention ... 9

(3)

Software Quality Assurance Plan Version 1.0

Page 3

1

Purpose

The purpose of the present document is to specify the procedures and tasks to be performed to assure the quality for the MSE project ArthropodEST pipeline system. The Software Quality Assurance (SQA) plan will cover all the product functions that the system will automate. The pipeline system includes EST analysis requests, job submissions, email notification, report generation, and keep track of analysis done. The procedures described in this plan will be applied during inception, elaboration, production and transition phases of the development of ArthropodEST pipeline system.

2

Reference documents

• Vision Document

• Project Plan

• IEEE Standard for Software Quality Assurance Planning.

3

Management

3.1

Organization

The people that will be involved during the software project development to assurance the quality of the system is present below.

• Supervision Committee

o Dr. Daniel Andresen o Dr. Doina Caragea o Dr. Mitchell Neilsen

(4)

Page 4

o Dr. Daniel Andresen

• Technical inspectors

o Tsung-Hsi Wu o Carlos Kirkconnel

• Developer

o Luis Carranco

• Bioinformatics Center technical responsible

o Sanjay Chellapilla

3.2

Tasks

The activities for the ArthropodEST pipeline system are defined in the Project Plan document. However, the most important tasks to assure quality over the system include:

• Formal reviews will be performed through major project milestone which include the three MSE presentations at the end of inception, elaboration and production phases.

• Testing will be done during the whole life-cycle according to the planning that will be done in the inception and elaboration phase.

• Performance metrics will be collected and analyzed throughout the life-cycle, but mainly in production and transition phase, where they will be more accurate.

3.3

Responsibilities

• The supervision committee will be responsible for review the system in the presentations at the end of each phase. After each presentation, the committee will provide feedback to the developer regarding the software product.

• The major professor will be responsible for supervising the tasks and progress done by the developer during the project development.

(5)

Software Quality Assurance Plan Version 1.0

Page 5

• The formal technical inspectors will be responsible for a technical review over the architecture design system and particularly over the formal documentation generated for the project. They will produce an inspection report with feedback for the developer.

• The developer will generate all the project documentation and perform all development tasks in order to achieve the goals and requirements defined in the Vision Document. Additionally, developer will be on charge of the software testing and prepare the presentations before the committee.

• The Technical responsible from Bioinformatics Center will verify the correctness of results which are produced by the bioinformatics packages in the pipeline system.

4

Documentation

The deliverable documents that will be produced during the development of the system are:

• Vision Document

• Project plan document with work breakdown structure

• Software quality assurance plan

• Architectural design document

• Formal specification

• Test plan

• Technical inspection reports

• Assessment evaluation

• User Manual

(6)

Page 6 Documents should be cross referenced between them. They will be reviewed and approved by the committee, and they shall be consistent with requirements and functionality. All documentation will be posted by at the web site

5

Standards, practices, conventions, and metrics

5.1

Documentation standards

IEEE standards will be used as a main guideline for all project documentation. UML diagrams will be used as much as possible to depict visually the software product. Critical requirements will be shown through use cases. Sequence and class diagrams will be the standards for design documentation.

5.2

Coding standards

The new software components to be developed for the project will be coded using python. Python Enhancement Proposal (PEP) number 8 will be used as coding standards. The administration interface will be developed in PHP and its code standard will be used. For the components already developed, it will be used Perl and Bash shell coding standards.

5.3

Logic structure standards

Code files will be hierarchically in packages and modules to organize the components structure. It will be used object oriented programming to define classes in files.

5.4

Data structure standards

Mysql name standards will be used for the system database structure. Table names will start with uppercases, and field names with lowercases. Camel case will be the standard for names of fields with more than one word.

(7)

Software Quality Assurance Plan Version 1.0

Page 7 All the new software components to be developed will be commented to give a brief description of the code focusing in the main purpose of the functionality. Every module, class, and method will be commented describing the main purpose of the code. For each file, a main header comment shall be contain the author’s name, creation date, last modification date, and brief description of its purpose.

5.6

Metrics

Metrics will help to measure the progress of the software project. Some metrics to be taken during the project to future evaluation are lines of code (LOC), number of test failures, development and test hours. At the end of the project, the effort will be evaluated according to initial estimations.

6

Reviews and audits

The major reviews will be done at the three formal presentations at the end of each phase. The committee members will provide feedback and suggestions according to the produced documentation as well as the prototype demonstrations. Furthermore, the two formal technical inspectors will assess the architecture design along the formal specifications to submit a report based on their findings. Finally, the Bioinformatics Center’s technical responsible will verify that the results for the EST analysis will be produced correctly for the new implementation of the pipeline system.

7

Test

A test plan will be developed defining test activities and functions to be verified in the system. All the results must be documented and evaluated.

(8)

Page 8 All parties involved in the project should report any problem with the software system, artifacts or the process itself as soon as possible. The developer should be responsible for provide solutions and time estimation to resolving the problems. The major processor should review that the corrective action will be applied after any reported issue. All the problems will be documented as part of the final project evaluation document indicating which the problem was and how it was solved. If there is any unresolved problem, it shall be directly reported to the committee members.

9

Tools, techniques, and methodologies

Tools that will be used during the project development to assure the quality are:

• MS Word. Develop documentation

• MS Project. Project planning and keep track progress.

• MS Visio. UML documentation

• Eclipse. Support project development, compile code

• Python Unit. For unit testing

• Virtual Box. For server test environment.

• USE. Formal specification and verification

• Subversion. Keep source code repository and control versioning Techniques

• Presentations

• Formal inspections Methodologies

(9)

Software Quality Assurance Plan Version 1.0

Page 9

10

Code control

The subversion source repository system will be used for code control of the ArthropodEST pipeline system source and testing code.

11

Records collection, maintenance, and retention

All the documentation and source code produced will be recorded and versioned. This includes the detail documentation of the design, implementation and the testing data. This would certainly help the developer’s to extend, modify or repair the software in future.

At the end of the project, the final version of the documentation will be turn in to the University Library, major professor, Developer and Bioinformatics Center. The entire source code will be submitted in a CD to the major professor and Bioinformatics Center.

12

Risks

Potential risks will be identified and they will be constantly monitoring through a table risk management to mitigate their impact. The identified risks for the ArthropodEST pipeline system are described in the table below.

Risk Level Impact Mitigation Contingency

Incompatibility

bioinformatics packages in Beocat

High Project

unfeasibility

Early prototype identifies configuration and programs Beocat supports

Install supported software in Beocat cluster

ArthorpodEST pipeline scripts do not execute in Beocat

Medium Project delay

Test early prototype directly in Beocat

Identify code to adjust. Estimate time and decide which functionality modify.

Requirements creep Medium Project

delay

Review early prototype with Bioinformatics Center technical responsible reach

Committee members in the presentations decide which new requirements might be

(10)

Page 10

main goals. implemented.

Performance degradation Low Project’s goals not reached

Measure time responses during project development and compare with old implementation.

Identify bottlenecks, estimate time and decide sections to be changed.

References

Related documents

The present dissertation is an educational sociology analysis of part-time (adult) learners in five Hungarian speaking higher education institutions (namely, the

Rent or mortgage payments make up the largest portion of an American family’s budget. As there is a limited housing stock in metropolitan areas, low-income families struggle to

The objective of the research reported in this study was to evaluate the effect of different soil management treatments on olive yields, nutrient removal at harvest, nutritional

The level of financial support must be equivalent to the current voluntary extended care and support (V9) agreement pursuant to section 4037-A and in accordance with DHHS, Office

This presentation contains forward-looking statements (as defined in Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934,

disclosure as a therapeutic technique. Given the high percentage of therapists who have participated in personal therapy, understanding the impact of personal therapy on professional

In other words, we have chosen a single case study — the Russian anti-terrorist foreign policy — and our intention is to study how the evolution of this particular movement

P01 P02 P43 Patient Dataset PET CT (1) PET Hierarchical representation (2) PET/CT feature extraction Node features Node index (3) Random Forest Classification Node class