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
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
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
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.
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
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.
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.
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
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
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.