Essay: Software Quality Assurance plan of the Registration system for faculty of IT

1.0 Purpose
The main purpose of the Software Quality Assurance plan is to ensure production of high quality end software product according to the specific requirements stated.
The Software Quality Assurance plan of the Registration system for faculty of IT establishes the goals, processes and responsibilities required to ensure high quality and on-time delivery of the project.
The results of the reviews and audits conducted in the Software Quality Assurance plan would be provided to the appropriate management of the project, so that they can track and assess the progress being made on the project.
The plan will be use which will be used throughout the software life cycle.
This plan:
‘ Identifies the SQA responsibilities of the project team and the SQA consultant
‘ Defines reviews and audits and how they will be conducted
‘ Lists the activities, processes, and work products that the SQA consultant will review and audit
‘ Identifies the SQA work product
1.1 Scope
This plan covers SQA activities throughout the Requirement analysis , Design , Implementation ,Testing , Maintenance phases of the Registration system for faculty of IT mission.
Details of the project :
This project is a registration application that enables the staff of the faculty and the student to easy conduct their tasks.
The users of the application will be as following: Dean, head of department, lecturer, student ,and registrar.
Each of the above users has to login to the system, so that they can do their tasks and access services that are available in the application
The Business Logic:
Dean
After he/she login to the system, the dean page will appear so that he/she can do the following:
Register course for any student, drop course for any student, see the student’s names in any course, add new course, open new section, print his/her time table, and print student’s names report for any course.
Head of department
After he/she login to the system, his/her page will appear so that he can do the following:
Register course for students belong to his/her department only, drop course for any student belong to his/her department only, see the student’s names in any course belong to his/her department only and print report including student’s names, print his/her time table.
Lecturer
After he/she login to the system, his/her page will appear so that he can do the following:
Register course for students belong to his/her department only, drop course for any student belong to his/her department only, see the student’s names in any course belong to his/her course only
Student
After the student login to the system using his/her id and password, the student can do the following:
Add new course (due date), drop course (due date), change course section, see the list of available courses for the current semester (including room number, date and time for each course), and print his/her time table.
Registrar
After he/she login to the system, his/her page will appear so that he can do the following:
He/she can only add new student to the faculty.
Student name, address, e-mail, telephone, mobile, date of birth, and registration date (system date)’etc.
Since the registrar register for new student the default courses have to be added to the new student.
2.0 Management
This section describes the management organizational structure, its roles and responsibilities, and the software quality tasks to be performed.
2.1 Management Organization
RSIT efforts are supported by numerous entities, organizations and personnel Relevant entities/roles that are of interest and applicable to this SQA Plan and the software assurance effort are described at a high level below.
The SQA organizational structure includes the following major roles :
‘ Project Manager (programmer)
‘ Dean
‘ Head of department
‘ Lecturer
‘ Student
‘ Registrar
‘ S/W Technical Manager
‘ S/W Quality Assurance Manager
The organizational structure also includes:
‘ The Technical Teams (one for each task), supervised by the S/W Technical Manager, responsible for product development, transfer and maintenance .
‘ The Project Secretariat, supervised by the Project Manager, responsible for documentation and records as well as overall administrative support.
‘ S/W Quality Assurance team supervised by S/W Quality Assurance Manager responsible for Formal Technical Inspectors , system testing and The users will conduct acceptance tests of the product .
2.2 Tasks
This section summarizes the tasks (product and process assessments) to be performed during the Requirement analysis, Design ,Implementation ,Testing, and maintenance of software.
The following tasks will be conducted in order to ensure quality assurance:
‘ Requirements analysis: The developer should ensure that the software requirement specification in the vision document clearly states the functionality of software and unambiguously declares the requirements that must be satisfied. In addition, descriptions of the scope should clearly outline what the software will allow and not allow.
‘ Design: The developer and SQA Manager will conduct reviews and analyses of the construction of the software. Strengths and weaknesses of various design techniques will be discussed and analyzed.
‘ Implementation: Informal code reviews will be conducted by the developer on a regular basis to ensure consistency with the design and the detection of any error. Also, Java Doc will be produced for purpose of maintainability and future work.
‘ Testing: Developer and SQA team will conduct tests as presented in the Software Test Plan to ensure the requirement satisfaction and reliability of the software
‘ maintenance :There are some issues which come up in the client environment. To fix those issues patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.
2.3 Roles and Responsibility
This section describes the roles and responsibilities for each assurance person assigned to the RSIT Project.
RESPONSIBILITIES :
SQA Manager
The manager of the project will supervise and evaluate the work of the developer on a regular timely basis. Along with the other SQA team activities, he will also measure the progress being made by the developer at each meeting.
Developer
The developer of the project will be responsible for all the documentation and software development tasks of the RSIT . The developer will also meet the project manager on a timely basis to report the progress of the project.
Tester will test all parts of the system
The users will conduct acceptance tests of the software
3.0 Documentation
This section identifies the minimum documentation governing the requirements, development, verification, validation, and maintenance of software that falls within the scope of this software quality plan. Each document below shall be assessed (reviewed) by SQ personnel.
The following documentation will be generated and updated throughout the duration of software life cycles:
Phase I:
1.) Vision Document – provides detailed description of the entire project, goals of the software, constraints and requirements for the software to satisfy.
2.) Project Plan – illustrates the major milestones and provides a rough timeline for the project and estimation on the size and effort of the project.
3.) Software Quality Assurance Plan ‘ provides plan for software quality assurance
4.)Interface Control Document(s) – provides detailed description of the interface project .
Phase II:
1.) Software Requirements Specification ‘ waterfall methodology will be used to produce this document.
2.) Test Plans (Verification and Validation) – provides description of test cases during testing
Phase III:
1.) Software User’s Guide – instructions on how to use this software
2.) Final source code – actual implemented documented source code
3.) Assessment Evaluation – assessment of reliability and performance of software
4.) Project Evaluation – review of the entire project
5.)Software Maintenance Plan- provides plan for maintenance this software
4.0 Standards, Practices, Conventions, and Metrics
This section highlights the standards, practices, quality requirements, and metrics to be applied to ensure a successful software quality program.
‘ Document standards ‘ MSE Portfolio
‘ Coding standards ‘ Java 1.4
‘ Coding Documents standards ‘ Java Documentation
‘ Test Standards ‘ IEEE Standard for software test documentation
Metrics
‘ LOC – lines of code is used to measure the size of the software.
5.0 Software Reviews
REVIEWS AND AUDITS
The main purpose of the reviews and audits is to verify the quality of the application and that this application is in the development phase, and that all documents of the project will be subject to some technical inspections to ensure that the quality of the documentation is in compliance with project
1) internal review
Internal audit of the project to make sure to walk to work properly without the presence of errors.
2) Software Code Inspections
All new modules require a code inspection.
3) Software Inspection Report
A summary report of results from the software inspections .
4) design reviews
Audit work by the team to make sure that design acceptable by users.’
6.0 Problem Reporting and Corrective Action
This section describes problem reporting mechanisms that occur as a consequence of the FTR’s that are conducted and the means for corrective action and follow-up.
Reporting mechanisms
When a problem is detected, the person who discovered the error is responsible for reporting to the Project Manager and Director of SQA.
Responsibilities
When the problem was discovered during the review, and a member of the team present SQA is responsible.
Solve the problem
When the problem is resolved notified SQA team to check whether the changes that have been made to solve the problem.
When you can not solve the problem, or can not be resolved within a reasonable period of time is due to hold a meeting with the project manager and director of SQA and captain of the team responsible. During this meeting will decide on further to deal with the problem.
7.0 Tools, Techniques and Methodologies
7.1 Software Quality Tools
The following are the tools that will be used for coding, testing and documentation:
‘ MS WORD 2010 ‘ for documentation
‘ JUnit ‘ for unit testing
‘ JMeter for performance testing
‘ Netbeans for coding
8.0 Records Collection, Maintenance, and Retention Section’
This section identifies the SQA documentation to be retained. It states the methods and facilities to assemble, safeguard, and maintain this documentation, and will designate the retention period. The implementation of the SQA plan involves the necessary approvals for the plan as well as development of a plan for execution.
A project file is established for each project in the responsible project manager office. Audit and document review records are maintained in these files along with associated documentation.
The completed Risk Checklist, Meeting minutes, weekly and monthly status reports, planning and metric records are also maintained in the project’s files.
Records are maintained for seven years from the end of the project.
9.0 Deliverables
Set of deliverables will be submitted at the end of each phase
Phase I
‘ Vision Document 1.0
‘ Project Plan 1.0
‘ Software Quality Assurance Plan
‘ vision code 1.0
Phase II
‘ Action items identified during phase I
‘ Vision Document 2.0
‘ Project Plan 2.0
‘ vision code 2.0
‘ Formal Requirement Specification
‘ Test Plan
‘ Formal Technical Inspection
Phase III
‘ Action items identified during phase II
‘ User Manual
‘ Source Code
‘ Project Evaluation
‘ Test Results
‘ References
‘ Formal Technical Inspection
10.0 Reference Documents
http://people.cis.ksu.edu/~ganti/mse_sqa.htm
http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm
http://it.umn.edu/enterprise-standards/technology-standards/documentation-information-technology
http://acis.mit.edu/acis/sqap/sqap.r1.html
https://www.emcbc.doe.gov/Content/Office/f.5.9_software_problem_reporting_and_corrective_action.pdf
http://www.rspa.com/docs/sqaplan.html