Software product realization quality framework (T-0660) (MFN 2934)

Abstract

ISO 9001:2000 Quality Management System has become a significant standard for achieving and improving quality of any organization. ISO documentation requirements contain instructions that whatever an organization is producing it can implement QMS. ISO 9001 does not stress its customers to follow the entire documentation requirements however it suggests to implement documentation requirements as much as you can keeping in view the size and scope of your organization. ISO 9001:2000 enables each organization to develop the less amount of documentation for an effective Quality Management System [1].

The European Standard ISO 9001:2000 has eight clauses in all. Each clause consists of some sub clauses also. Requirements given in the standard are difficult to understand for proper implementation and achievement of an effective Quality Management System. Although complexity lies with all its clauses yet clause 7 for Product Realization is chosen for providing a framework for software organizations to implement it with satisfaction. Similarly framework for rest of the clauses can also be proposed on the same pattern. Clause 7 has been selected from the British Standard for the reason that it is deeply connected with software industry as software is also a product to be realized for proper development with proper documentation. Documentation requirements given in the standard for clause 7 (Product Realization) are silent about the implementation details because it is thought by European Committee for standardization that consultancy can bridge the gap between documentation requirements and guidelines for implementation.

Software Product Realization Quality Framework is being proposed due to complications that people face during the determination of procedures and processes in software organizations. ISO 9001:2000 has a less documentation requirement standard for continuous improvement in quality and it is not enough for software organizations to generate complete documentation for software.

Clause 7 of ISO that is about Product Realization defines documentation requirements and guidelines for planning, designing and development of any product but a software product development required maturity for maintaining documentation. Although clause 7 defines about the guidelines for the documents which should be prepared and maintained but in case of software development people get confused for the maintenance of the documents properly so “Software Product Realization Quality Framework” will show the right path to software organizations with implementation details in the light of documentation requirements given in the clause.

Software Product Realization Quality Framework is being proposed for specifically software organizations. Software organizations follow the clause 7 that is product realization during the development of any software but it is not enough in developing software because we need huge documentation during the development of new software.

For example a software product needs to have Risk Management Plan and Configuration Management Plan also. There is nothing regarding Risk and Configuration Management Planning in the documentation requirements of clause 7 of ISO 9001:2000. So in Software Product Realization Quality Framework the guidelines and identification for each type of document necessary for the development with implementation details is provided.

Initial Software Product Realization Quality Framework speaks about different steps. The steps are actually to understand the philosophy of preparation of documents for software with respect to documentation requirements. First step is about the Planning of Product Realization. Planning of Product Realization shall be consistent with the requirements of the other processes of the Quality Management System. The guidelines for all documents involved in planning are defined.

Software development is initiated from planning of product realization and from the very beginning concentration is given to project area in which feasibility report is prepared for developing any type of software product. After preparing a feasibility report, we move forward for the preparation of project or product contract. Product contract document contains the information about the deal with the customer regarding a software product. Product or Project charter is prepared then for developing and producing matured software. The following activities are performed before developing a Software Project Plan for achieving a software product within proper budget, resources and proper timeframe. Some other activities and practices are also evaluated for getting an efficient and effective software product plan.

Project or Product Work Breakdown Structure has an important role in consistent documentation for software product. Roles and Responsibilities matrix is also prepared. Arrow Diagramming Method or Predecessor Diagramming Method documents should be prepared at the end.

Second step is performed about the determination of requirements related to the product. In determination of requirements, Requirement Statement is prepared according to the Requirements Management Plan. SRS is prepared after getting requirement statement which is also known as Software Requirement Specifications. Then a requirement model is prepared.

In review of requirements, a document called Requirements Review is prepared. From the past experience of implementing ISO 9001:2000 in a software organization, the above mentioned documents must be prepared for achieving matured software.

Regarding designing phase we should have design and development plan, design and development inputs, design and development outputs and design and development review.

The practices given in the standard in clause 7 related to design phase are already matured and there is no need yet to identify their documents and to suggest a framework including design practices.

However Sub clauses 7.3.5 that is design and development verification, 7.3.6 design and development validation and 7.3.7 control of design and development changes, deals with Quality Assurance practices up to some extent.

Adopting Quality Assurance practices properly, following documents should be prepared to have a check and balance that either software is being developed according to the requirements or not.

First of all Test suit is prepared and then move forward to build an Errol log report. Error status reports are prepared without breaking the consistency of documents. Review reports are prepared, and then audit reports are generated. After generating these all error reports, Configuration Management Plan is developed that deals about the change management. A Base line list is prepared at the end.

Another important aspect which covers all plans includes Software Project Plan, Requirements Management Plan, Test Plan, Software Quality Assurance Plan; Risk Management Plan and Maintenance & Installation Plan.

“Software Quality Assurance (SQA) is defined as an organized approach and requires that all software products assure that products and procedures conform to the standards and plans” [2].

An understanding of the fundamentals of software engineering with a focus on collaborative software development validates the following observation. Collaborative software engineering development, like any other engineering discipline, can generally be divided into two aspects. These aspects are the product created and the process involved in the creation of this collaborative software product. Consequently the role involved, activities performed and documents generated can be classified within two sets. One set is involved directly in the collaborative software engineering product and consists of the requirement analysis, design and coding. These people may be termed as “those who do it”, directly and visibly creating the software product. The other set involved in ensuring that the processes established are optimal in delivering the required product, the software quality assurance. This set of people may be term as “those who help ‘those who do it,’ do it”, indirectly creating the software product.