Software quality assurance

Management

A good software practise requires a measure of independence for the software quality assurance group (SQA).

SQA should have the freedom to go to any heights to ensure that the quality of the product is not jeopardized. They can directly report their concerns to CIO or the top management. The quality assurance team works best to ensure problems encountered are resolved at the project level.

The figure below shows the software quality assurance organization. This section describes the management organizational structure, its roles and responsibilities, and the software quality tasks to be performed.

Tasks

The following describes the functional groups that influence and control software quality.

Program Management or sponsor is responsible for the following items:

  1. He or she should establish a quality program by committing the project to implement the Software Engineering Process Policy.
  2. He/she reviews and approves the MPC project SQA Plan.
  3. Resolving and following-up on any quality issues raised by SQA team.
  4. He should identify a group or individual independent from the project to audit and report on the project's SQA function.
  5. The PM identifies the quality factors to be implemented in the system and software.
  6. Fill-in additional functional responsibilities.

Project Manager is responsible for:

  1. Implementing the quality program in accordance with requirement review document.
  2. Identifying the SQA activities to be performed by SQA.
  3. Reviewing and approving the MPC project SQA Plan.
  4. Identifying and funding an individual or group independent from the project to perform the SQA functions.
  5. Resolving and following-up on any quality issues raised by SQA.
  6. Identifying and ensuring the quality factors to be implemented in the system and software.
  7. Identifying, developing and maintaining planning documents such as the Program Management Plan, as per the user documentation and requirement review Test Plans, and this SQA Plan.

System Engineers are responsible for:

  1. Reviewing and commenting on the MPC project SQA Plan.
  2. Implementing the quality program in accordance with this SQA Plan.
  3. Resolving and following-up on any quality issues raised by SQA related to software engineering activities.
  4. Identifying, implementing, and evaluating the quality factors to be implemented in the system
  5. Implementing the engineering practices, processes, and procedures as defined in reference and other program/project planning documents.
  6. Fill-in additional functional responsibilities.

Software Design/Developers are responsible for:

  1. Reviewing and commenting on the MPC project SQA Plan.
  2. Implementing the quality program in accordance with this SQA Plan.
  3. Resolving and following-up on any quality issues raised by SQA related to software design and development.
  4. Identifying, implementing, and evaluating the quality factors to be implemented in the software.
  5. Implementing the software design/development practices, processes, and procedures as defined in reference and other program/project planning documents.
  6. Fill-in additional functional responsibilities.

Software Testers are responsible for:

  1. Reviewing and commenting on the MPC project SQA Plan.
  2. Implementing the quality program in accordance with this SQA Plan.
  3. Resolving and following-up on any quality issues raised by SQA related to software test.
  4. Verifying the quality factors are implemented in the system, specifically software.
  5. Implementing the software test practices, processes, and procedures as defined in reference and other program/project planning documents.
  6. Fill-in additional functional responsibilities.

Logistic personnel is responsible for:

  1. Reviewing and commenting on the MPC project SQA Plan.
  2. mplementing the quality program in accordance with this SQA Plan.
  3. fill-in additional functional responsibilities.

Documentation Standards

All documentation utilized within MCP related to the management system itself, or to the execution of individual customer contracts is controlled to ensure that it is issued to the appropriate personnel, under the correct level of authority, is revised and reissued as necessary, and all obsolete versions are removed from the point of use.

The Quality Assurance Manual, Procedures and Quality Plans are maintained by the Quality Manager who ensures that the appropriate items, at the correct revision levels, are issued to all who need them within MCP.

International Standards, Codes of Practice are listed in the MCP corporate policy manual and maintained by the designated Quality control staff who provide governance and ensure that appropriate documents are available within MCP, and are issued at the correct revision levels. External suppliers of documentation are contacted regularly to ascertain that the documents held remain current.

The distribution of standard documents is controlled and recorded on Distribution Lists, which also show the current issue status. The Distribution Lists are reviewed and updated as changes occur.

All changes to documents are reviewed and approved by the person responsible for the original issue and, where appropriate, the nature of the change is indicated on the document. Master copies of the revised documents are retained as records of the changes and renewed as necessary to ensure clarity.

Each contract has a File which contains all relevant information. Information is also held on the company's computer system for ease of access and manipulation.

MCP projects must product at a minimum the following documentation during the life of the project to ensure the that software product is developed satisfies the requirements.

The minimum set of documentation is:

  • Software Development Plan
  • Test Plan
  • Software Requirements Specification
  • Software Architecture Documentation
  • User Documentation (manuals, etc)
  • Configuration Management Plan

Reviews and audits

MCP review and audit plan section of the Quality Assurance Plan will be a joint management and developer effort. Reviewing aspects of the project and the responsibilities, and conduct review meeting with pass or fail criteria consisting of;

  • Functional Configuration audit to verify all requirements in the software requirement system have been met.
  • Physical configuration audit to verify that the software and the documentation are complete
  • Process audits
  • Process reviews
  • Managerial reviews (Project approval review, Project Plan review)
  • Post mortem review (lifecycle milestone review, project acceptance review)

Reviews

MCP Management review of the suitability and effectiveness of the Quality System will take place at least twice per year. During the management meetings actions are allocated and minuted to record the development of the Company's management system.

The objectives of Management Review are:

  • To confirm that the Quality Management process is achieving the expected results and meeting the MCP's requirements, that MCP continuing to conform to the Standard, continuing to satisfy the customer's needs and expectations, and functioning in accordance with the established Operating Procedures.
  • To expose irregularities or defects in the System, identify weaknesses and evaluate possible improvements.
  • To review the effectiveness of previous corrective actions, and to review the adequacy and suitability of the management system for current and future operations.
  • To review any complaints received, identify the cause and recommend corrective action if required.
  • To review the finding of internal/ external audits and identify any areas of recurring problems or potential improvements.
  • To review the reports of nonconforming items and trend information to identify possible improvements.

Audits

Internal audits of the Quality System are undertaken at least once per annum to confirm that the function concerned is adhering to the MCPs Procedures. A comprehensive Audit Programme is compiled at least a year in advance however, should particular needs be identified, the frequency of audit may be increased at the discretion of the Quality Manager.

Audits are undertaken by auditors who are trained in auditing and not directly responsible for the functions being audited within that Company. Non-conformance observed is brought to the attention of the person responsible, and is recorded, documented and subject to timely corrective action to ensure full rectification.

Configuration Items

Configuration items are considered as all documentation and software created during the development project. The initial documentation and software will be used as baseline items. All changes to these items will be overseen by a Change Control Board (CCB).

The following points illustrate the strategy which the team will implement for its configuration management process:

  • The team will log all configuration items and changes to these items in a special database (TRK) created for this purpose.
  • Each item will be numbered automatically by the system according to the numbering format used by MPC and will therefore be easily identified
  • In order to properly control and track changes to configuration items, each item will be made the responsibility of only one person on the CCB who will make any required changes to the item and who will be responsible for ensuring that the item is properly updated and maintained
  • TRK will allow authorized read-only access to an item by all project members. However, TRK will allow 'writable' access to an item only to the individual given responsibility for that item but requires two authorization procedures for this to occur. The second authorization procedure will involve the confirmation of the 'writable' access by the General Configuration Manager or the Configuration Change Verifier.
  • During a write operation, the database will not allow concurrent access to the item. The item will be locked and when it is released it will reenter the system with a revision marker appended to it to signify that it is a revised version of the last approved version of the item.
  • Each version of an item or even the link between different items can be retrieved from the database via queries. Once changes which affect more than one item are made, the related documents will automatically be updated to reflect the change and the individual responsible for the related, updated items will be identified and notified by the TRK system and by the CCB.
  • All users of an item will be notified of the changes (latest version) by email, official letters, special announcement and/or word of mouth.

Problem Reporting and Corrective Action

After the quality audits have been conducted, there may be need for changes to some of the development procedures or even changes to the software or some of the documents. The specific procedures for handling problems or changes to product/process during development or to the software product or any deliverables after development will be as follows (Andrews, 2009).

DURING DEVELOPMENT:

  1. A formal change request document with a description of the requested change or the recommendation will be filled out and submitted to the CCB
  2. The CCB will evaluate the request and determine its effects on the project (e.g. on cost and time schedules) should it occur, as well as, the possible effects on the project if the change is not implemented. Evaluation will definitely include the consideration of quality assurance principles. The CCB will also identify during this process all other products and persons that would be affected by the requested change. Persons affected by the change and who understand the effects of the change will be included in determining the impact of the change on the project and whether the change should be approved.
  3. If the benefits of implementing the change outweigh the cons, then the change is approved and a formal approval form will be filled out by the board and returned to the configuration manager. The configurations Manager will then order that the necessary changes be implemented by the individual responsible for the configuration item or the process.
  4. After implementation of the change, a change completion document will be filled out by the configuration manager and verified by project manager who will also check the changes and record findings accordingly. This form will then be reviewed by the CCB to ensure that the change did not result in any unexpected changes/events except those identified during the first review. Once accepted, a revision marker, according to the numbering system in the database, will be appended to the last number of the revised documents (process documents may also be included) when they are re-entered in the database. The change, the reasons for it and the impact of the change will also be recorded in the project plan
  5. All parties affected by the change, including the entire project team, will be notified of the changes through status reports and other means previously identified.

Any change requests submitted during development will be considered an emergency event by the CCB in order to prevent extensive schedule duration overruns and will be attended to immediately. Two other members of the CCB will discuss the change with the project manager and the configuration manager to gain a quick synopsis of the possible magnitude of the change and the intensity of its effect on the project. If the change is considered to be minor (have a negligible effect on the scope in terms of the project schedule and budget), then the change will be approved with the signature of these parties. Otherwise, the request will pass through the procedure outlined above.

AFTER DEVELOPMENT:

After the project has terminated, any changes to the system will be performed in more or less the same manner. Change requests will be first analyzed by the information technology department, and will determine a rough work break down structure, with cost and time schedules for the upgrade (change) project. This WBS will then be used by the general management department to determine whether the upgrade can be funded. In the event that the event can be funded, the procedure follows similarly from step 3 above onwards. The CCB will perform its functions as normal to ensure adherence to quality standards and to monitor changes to the affected deliverables. During the performance of approved upgrades, any change requests occurring at that time will be dealt with using the procedure listed formerly in the DURING DEVELOPMENT sub section. System failures that occur during the use of the system after its release will also be reported and tracked using the change request form and this very procedure.

Code control

We have divided our code control procedures according to three major sets: standards, static metrics and dynamic metrics.

Our application is composed of four different languages to which we will apply different sets of standards, static metrics and dynamic metrics.

By implementing these standards we expect to achieve of improving software quality, namely by improving our coding in terms of:

  • Readability
  • Ease ofmaintenance,testing,debugging, fixing, modification and portability
  • Lowcomplexity
  • Low resource consumption:memory,CPU
  • Robust input validation and error handling, established bysoftware fault injection

Xhtml (Extensible Hypertext Mark-up Language)

Our application user interface will be a website which we will make available to our users using the extensible hypertext mark-up language (xhtml).

We will be implementing the Xhtml 1.1 standard as defined by the World Wide Web Consortium (W3C). Additionally we will be enforcing our internal coding standards for Xhtml 1.1, namely in respect to formatting and naming conventions.

All the code produced will be validated to ensure it conforms to the standard using the tools supplied by the W3C.

We will be enforcing strict separation between content and design, which is a recommended best practice by the W3C. As such all configurations pertaining to design will have to be coded separately using Cascading Style Sheets (CSS).

Additionally we will be aiming for a successfully achieving an AAA success criteria for the Web Content Access Guidelines 2.0 (WCAG 2.0) as defined by the respective W3C working group.

A specific advantage of pursuing an AAA classification for WCAG 2.0 is that these guidelines promote overall best practices in producing xhtml code and strict separation of content and design.

For validating and verifying these standards we will pursue the usage of tools provided or recommended by the W3C as specified in their documentation. Naming conventions will be validated through peer and group review, while formatting will be enforced through the usage of our automatic formatting tools.

Exceptions to any of the standards, if accepted by the responsible party, usually the team leader or technical leader, will have to be properly documented in code, through the use of comments.

CSS (Cascading Style Sheets)

To supplement and beautify the content being provided to our end-user through the xhtml code being delivered by our website we will be using Cascading Style Sheets (CSS) coding, thus promoting the enforcement of the separation of content from design artifacts.

We will be implementing the ECMA-262 standard as defined by ECMA International. Additionally we will be enforcing our internal coding standards for JavaScript, namely in respect to formatting and naming conventions.

All the code produced will be validated to ensure it conforms to the standard using the tools supplied by the W3C.

We will be aiming at providing the best experience possible when viewing our website using the top most used generally available web browsers and assuming two of the top most used screen sizes. We will be performing coverage testing to ensure that for each template to be used by our website (and defining a template as each specific separate layout configuration, such as for example, the homepage or viewing the shopping cart detail) we will validate between one to three sample renderings of the template for each possible combination of web browser and screen size. The specific list of web browser and screen size will be detailed elsewhere.

For validating and verifying these standards we will pursue the usage of tools provided or recommended by the W3C as specified in their documentation. Naming conventions will be validated through peer and group review, while formatting will be enforced through the usage of our automatic formatting tools.

Exceptions to any of the standards, if accepted by the responsible party, usually the team leader or technical leader, will have to be properly documented in code, through the use of comments.

JavaScript

To enrich the user experience of our end-user we will make use of JavaScript and dynamic xhtml as appropriate.

We will be implementing the CSS 2.0 standard as defined by the World Wide Web Consortium (W3C). Additionally we will be enforcing our internal coding standards for CSS 2.0, namely in respect to formatting and naming conventions.

We will be aiming at providing the best experience possible when viewing our website using the top most used generally available web browsers and assuming two of the top most used screen sizes. We will be performing coverage testing to ensure that for each template to be used by our website (and defining a template as each specific separate layout configuration, such as for example, the homepage or viewing the shopping cart detail) we will validate between one to three sample renderings of the template for each possible combination of web browser and screen size. The specific list of web browsers and screen sizes will be detailed elsewhere.

In addition we will enforce the implementation of the some of the metrics to be measured for our usage of the Java language. Specifically we will pursue the gathering, monitoring and review of the following metrics for the JavaScript coding: code coverage; cohesion; coupling; cyclomatic complexity; code to comments ratio; number of bugs per line of code. Whenever one of these metric significantly deviates from our usual standards for JavaScript code or indicates a potential problem a formal code review will be initiated and the appropriate documentation will be produced.

Exceptions to any of the standards, if accepted by the responsible party, usually the team leader or technical leader, will have to be properly documented in code, through the use of comments.

Java

The Java programming language will be used to support the rendering of the presentation layer as well as the business layer and all access to the database layer, as well as providing support for the implementation of all interfaces with external applications.

All Java code will be coded in order to be executed by a container implementing the Java Standard Edition 6 and Java Enterprise Edition 6, namely through the use of supporting Java Runtime Environments.

We will be enforcing both our internal Java coding standards as well as the publicly available Java coding standards from Sun. These coding standards detail formatting, identifier naming and coding best practices and will be either validate or enforced by the use of our current tooling.

Additionally we will be adopting our internal best practices and guidelines for authorization, authentication, intrusion prevention, data loss protection as detailed in our coding manuals. These best practices will be promoted and monitored by our team leader and/or technical leaders.

We will also be monitoring a series of static metrics, comparing them to our internal standards and analysing any deviations from the standards or any alarm signal, leading to a formal code review to be initiated and the appropriate documentation to be produced.

We will be measuring:

  • code coverage
  • cohesion
  • coupling
  • cyclomatic complexity
  • code to comments ratio
  • depth of inheritance tree
  • weighted methods per class
  • number of overriding operations
  • number of bugs per line of code

Quality Summary

Our quality assurance plan is an outline of the measure that we are to implementing in order to ensure certain quality levels within our software development effort.

This plan will be used as the baseline with which to regulate and maintain the desired levels of quality during our development process.

If at any time the desired levels of quality are not achieve this will trigger the necessary reactions by our management as detailed within this plan and generally within our quality management procedures.

It is through the implementation of this quality assurance plan that we expect to achieve the creation of a set of understandable and maintainable software artefacts, both code and documentation.

Within this document we have strived to define the procedures that will affect planning, designing, writing, testing, documenting, and maintaining our software project so that the end result can be evaluate both by ourselves and our customer as of high quality.

We have defined the project's organization structure, tasks associated with each node of this structure as well as its responsibilities.

We have defined the standards, practices, conventions and metrics that we which to apply to our coding efforts and also how those items should be monitored and assured.

Additionally we have defined how documents to be produced for our projects should be validated and evaluated for adequacy, providing where possible the criteria and the identification of the review or audits by which a specific document will be confirmed.

We have also provided details on how our project configuration management process should be implemented, defining team responsibility and process steps, as well as detailing the measures for supporting problem reporting and corrective actions.

In conclusion it is our belief that by implementing and adhering to the guidelines established in this document and additional relevant documentation the project development team will be able to provide an end-product which will not only meet the functional expectations of our client but overall exceed its general expectations by delivering a product of irreprehensible quality which will benefit the client not only in the present but also in the future by reduce maintenance costs and ease with which the customer will be able to further adapt the product to its needs.

References.

  • Andrews, A. (2009) "The Development and Implementation of CusDem Information system", Project Management Module Project. Available from: University of Liverpool/Laureate Online Education VLE.

Please be aware that the free essay that you were just reading was not written by us. This essay, and all of the others available to view on the website, were provided to us by students in exchange for services that we offer. This relationship helps our students to get an even better deal while also contributing to the biggest free essay resource in the UK!