The nature of the product development and production process.<\/p>\r\n\r\n
The environmental characteristics of SQA involves contract conditions and commitments defining the contents and timetable. The conditions of the customer\u2013supplier relationship, realized by the need for consultation with the customer and the acquisition of his approval. Need for cooperation and coordination with other software and hardware. Need for interfaces with other software systems. Need to continue carrying out a project when team members change. Need to conduct maintenance of the software system for several years.<\/p>\r\n \r\n
In software quality assurance, Software, is the combination of computer programs, procedures, documentation, and data necessary for operating the software system. Software quality, is the degree of conformance to specific functional requirements, specified software quality standards, and Good Software Engineering Practices. Software quality assurance, is the systematic, planned set of actions to provide adequate confidence that a software development process conforms to established functional technical requirements as well as the managerial requirements of keeping to schedules and operating\u00a0within the budget. Assuring, with acceptable levels of confidence, conformance to functional technical requirements. Assuring, with acceptable levels of confidence, conformance to managerial requirements of scheduling and budgets. Initiating and managing activities for the improvement and greater efficiency of software development and SQA activities. The issues related to the various attributes of software and its use and maintenance, can be classified into content groups called Quality Factors. McCall\u2019s factor model classifies all software requirements into 11 software quality factors. The 11 factors are grouped into three categories \u2013<\/p>\r\n\r\n<\/div>\r\n
- \r\n \t
- \u00a0Product operation factors: Correctness, Reliability, Efficiency, Integrity, Usability.<\/li>\r\n \t
- Product revision factors: Maintainability, Flexibility, Testability.<\/li>\r\n \t
- Product transition factors: Portability, Reusability, Interoperability.<\/li>\r\n<\/ul>\r\nTwo factor models, appearing during the late 1980s, considered to be alternatives to the McCall classic factor model.\r\n
- \r\n \t
- The Evans and Marciniak factor model<\/strong><\/li>\r\n \t
- The Deutsch and Willis factor model<\/strong><\/li>\r\n<\/ul>\r\n
SQA components, are employed to challenge the multitude of sources of software errors and to achieve an acceptable level of software quality. The components are:<\/p>\r\n\r\n
- \r\n \t
- Pre-project quality components<\/li>\r\n \t
- Project life cycle quality components<\/li>\r\n \t
- Infrastructure error preventive and improvement<\/li>\r\n \t
- components Software quality management components<\/li>\r\n \t
- Standardization, certification and SQA assessment<\/li>\r\n \t
- components Organizing for SQA \u2013 the human components<\/li>\r\n<\/ul>\r\n
Contract review activities must include a detailed examination of the project proposal draft and the contract drafts. Contract review activities include:<\/p>\r\n\r\n
\r\n- \r\n \t
- Clarification of the customer\u2019s requirements.<\/li>\r\n \t
- Review of the project\u2019s schedule and resource requirement estimates.<\/li>\r\n \t
- Evaluation of the professional staff\u2019s capacity to carry out the proposed project.<\/li>\r\n \t
- Evaluation of the customer\u2019s capacity to fulfill his obligations.<\/li>\r\n \t
- Evaluation of development risks.<\/li>\r\n<\/ul>\r\n
Once a software development contract has been signed or a commitment is made to undertake an internal project for the benefit of another department of the organization, a plan is prepared of the project (\u201cdevelopment plan\u201d) and its integrated quality assurance activities (\u201cquality plan\u201d). Eleven types of elements constitute a development plan:<\/p>\r\n\r\n<\/div>\r\n
- \r\n \t
- Project products<\/li>\r\n \t
- Project interfaces<\/li>\r\n<\/ul>\r\nProject methodology and development tools\r\n
- \r\n \t
- Software development standards and procedures<\/li>\r\n \t
- Mapping of the development process<\/li>\r\n<\/ul>\r\nProject milestones\r\n\r\nProject staff organization\r\n
- \r\n \t
- Required development<\/li>\r\n \t
- facilities Development risks<\/li>\r\n \t
- Control methodology<\/li>\r\n \t
- Project cost estimates.<\/li>\r\n<\/ul>\r\n
Quality assurance activities happens in conjunction with the completion or examination of activity milestones, which require review of the product development activities previously completed. SQA professionals should be acquainted with the various software engineering so that they can prepare a quality plan that is properly integrated into the project plan. The four models of the software development are discussed.<\/p>\r\n\r\n
- \r\n \t
- The Software Development Life Cycle (SDLC)<\/li>\r\n \t
- model The prototyping model<\/li>\r\n \t
- The spiral model<\/li>\r\n \t
- The object-oriented model.<\/li>\r\n<\/ul>\r\n\r\n
The SDLC Model is the classic model. It provides the most comprehensive description of the process available. It displays the major building blocks for the entire development process, described as a linear\u00a0sequence. The SDLC Model can serve as a framework within which the other models are presented. The Prototyping Model is based on replacement of one or more SDLC model phases by an evolutionary process, where software prototypes are used for communication between the developer and the users and customers. The Spiral Model provides a methodology for ensuring effective performance at each of the SDLC model phases. It involves an iterative process that integrates customer comments and change requirements, risk analysis and resolution, and software system planning and engineering activities. The Object-Oriented Model incorporates large-scale reuse of software by integrating reusable modules into new software systems. In cases where no reusable software modules are available, the developer may perform a prototyping or SDLC process to complete the newly developed software system.<\/span><\/p>\r\n\r\n<\/div>\r\nFactors Affecting SQA activities includes:\r\n\r\n \r\n\r\nProject factors:<\/strong>\r\n\r\n \r\n\r\nMagnitude of the project\r\n\r\n \r\n\r\nTechnical complexity and difficulty\r\n\r\n \r\n\r\nExtent of reusable software components\r\n\r\n \r\n\r\nSeverity of failure outcomes if the project fails\r\n\r\n \r\n\r\nTeam factors:<\/strong>\r\n\r\n \r\n\r\nProfessional qualification of the team members\r\n\r\n \r\n\r\nTeam acquaintance with the project and its experience in the area\r\n\r\n \r\n\r\nAvailability of staff members who can professionally support the team Familiarity with the team members.\r\n\r\n \r\n
\r\nQuality assurance activities examine three different aspects of quality by means of software product verification, validation and qualification. Verification examines the consistency of current development activities with the products from previous phases. Validation represents the customer\u2019s interests by examining the extent to which the customer\u2019s original requirements have been fulfilled. Qualification reviews project application of professional standards and coding procedures, based on the assumption that applying these standards facilitates maintenance.<\/p>\r\n\r\n<\/div>\r\n
A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Reviews acquire special importance in the SQA process because they provide early detection and prevent the passing of design and analysis errors \u201cdownstream\u201d, to stages where error detection and correction are much more intricate, cumbersome, and therefore costly.<\/p>\r\n \r\n\r\nThe various types of review objectives are:\r\n\r\n \r\n\r\nThe Direct Objectives:<\/strong>\r\n
- \r\n \t
- To detect analysis and design errors.<\/li>\r\n \t
- To identify new risks expected to affect the completion of the project. To identify deviations from templates and style procedures.<\/li>\r\n \t
- To approve the design product, allowing the team to continue to the next development phase.<\/li>\r\n<\/ul>\r\n \r\n\r\nThe Indirect Objectives:<\/strong>\r\n
- \r\n \t
- To serve as an informal meeting place for the exchange of knowledge about development tools, techniques etc.<\/li>\r\n \t
- To promote and support the improvement of development methods by supplying new data for analysis of design errors.<\/li>\r\n<\/ul>\r\n\r\n
Formal design reviews, variously called \u201cdesign reviews\u201d, \u201cDRs\u201d and \u201cformal technical reviews (FTR)\u201d, differ from all other review instruments by being the only reviews that are necessary for approval of the design product. Without this approval, the development team cannot continue to the next phase of the software development project. The review leader should have: Knowledge and experience in development of projects of the type reviewed. Seniority at a level similar to if not higher than that of the project leader. The review team: The entire review team should be selected from among the senior members of the project team together with appropriate senior professionals assigned to other projects and departments, customer\u2013user representatives, and in some cases, software development consultants. Team members are expected to review the design document and list their comments prior to the review session. In cases where the documents are sizable, the review leader may ease the load by assigning to each team member.<\/p>\r\n\r\n<\/div>\r\n
In follow-up process the person who follows up the corrections is required to determine whether each action item has been satisfactorily accomplished as a condition for allowing the project to continue to the next phase. Follow-up should be fully documented to enable clarification of the corrections in the future. Formal design reviews are authorized to approve the design documents so that work on the next stage of the project can begin. This authority is not granted to the peer reviews, whose main objectives are detecting errors and deviations from standards. Two peer review methods are defined as Inspections and Walkthroughs. Expert opinions, prepared by outside experts, support quality evaluation by introducing additional capabilities to the internal review staff. The organization\u2019s internal quality assurance activities are thereby reinforced. Outside experts transmit their expertise by either:<\/p>\r\n\r\n
- \r\n \t
- Preparing an expert\u2019s judgement about a document or a code section.<\/li>\r\n \t
- Participating as a member of an internal design review, inspection or walkthrough team.<\/li>\r\n<\/ul>\r\n
![\"\"](\"http:\/\/csp9.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/54\/2018\/07\/pic-6.png\")
\r\n\r\n ","rendered":"The Uniqueness of the Software Development Process, the fundamental differences between software products and other products are caused by:<\/p>\n
- \n
- The higher product complexity.<\/li>\n
- The invisibility of software.<\/li>\n<\/ul>\n
The nature of the product development and production process.<\/p>\n
\nThe environmental characteristics of SQA involves contract conditions and commitments defining the contents and timetable. The conditions of the customer\u2013supplier relationship, realized by the need for consultation with the customer and the acquisition of his approval. Need for cooperation and coordination with other software and hardware. Need for interfaces with other software systems. Need to continue carrying out a project when team members change. Need to conduct maintenance of the software system for several years.<\/p>\n
<\/p>\n
In software quality assurance, Software, is the combination of computer programs, procedures, documentation, and data necessary for operating the software system. Software quality, is the degree of conformance to specific functional requirements, specified software quality standards, and Good Software Engineering Practices. Software quality assurance, is the systematic, planned set of actions to provide adequate confidence that a software development process conforms to established functional technical requirements as well as the managerial requirements of keeping to schedules and operating\u00a0within the budget. Assuring, with acceptable levels of confidence, conformance to functional technical requirements. Assuring, with acceptable levels of confidence, conformance to managerial requirements of scheduling and budgets. Initiating and managing activities for the improvement and greater efficiency of software development and SQA activities. The issues related to the various attributes of software and its use and maintenance, can be classified into content groups called Quality Factors. McCall\u2019s factor model classifies all software requirements into 11 software quality factors. The 11 factors are grouped into three categories \u2013<\/p>\n<\/div>\n
- \n
- \u00a0Product operation factors: Correctness, Reliability, Efficiency, Integrity, Usability.<\/li>\n
- Product revision factors: Maintainability, Flexibility, Testability.<\/li>\n
- Product transition factors: Portability, Reusability, Interoperability.<\/li>\n<\/ul>\n
Two factor models, appearing during the late 1980s, considered to be alternatives to the McCall classic factor model.<\/p>\n
- \n
- The Evans and Marciniak factor model<\/strong><\/li>\n
- The Deutsch and Willis factor model<\/strong><\/li>\n<\/ul>\n
SQA components, are employed to challenge the multitude of sources of software errors and to achieve an acceptable level of software quality. The components are:<\/p>\n
- \n
- Pre-project quality components<\/li>\n
- Project life cycle quality components<\/li>\n
- Infrastructure error preventive and improvement<\/li>\n
- components Software quality management components<\/li>\n
- Standardization, certification and SQA assessment<\/li>\n
- components Organizing for SQA \u2013 the human components<\/li>\n<\/ul>\n
Contract review activities must include a detailed examination of the project proposal draft and the contract drafts. Contract review activities include:<\/p>\n
\n- \n
- Clarification of the customer\u2019s requirements.<\/li>\n
- Review of the project\u2019s schedule and resource requirement estimates.<\/li>\n
- Evaluation of the professional staff\u2019s capacity to carry out the proposed project.<\/li>\n
- Evaluation of the customer\u2019s capacity to fulfill his obligations.<\/li>\n
- Evaluation of development risks.<\/li>\n<\/ul>\n
Once a software development contract has been signed or a commitment is made to undertake an internal project for the benefit of another department of the organization, a plan is prepared of the project (\u201cdevelopment plan\u201d) and its integrated quality assurance activities (\u201cquality plan\u201d). Eleven types of elements constitute a development plan:<\/p>\n<\/div>\n
- \n
- Project products<\/li>\n
- Project interfaces<\/li>\n<\/ul>\n
Project methodology and development tools<\/p>\n
- \n
- Software development standards and procedures<\/li>\n
- Mapping of the development process<\/li>\n<\/ul>\n
Project milestones<\/p>\n
Project staff organization<\/p>\n
- \n
- Required development<\/li>\n
- facilities Development risks<\/li>\n
- Control methodology<\/li>\n
- Project cost estimates.<\/li>\n<\/ul>\n
Quality assurance activities happens in conjunction with the completion or examination of activity milestones, which require review of the product development activities previously completed. SQA professionals should be acquainted with the various software engineering so that they can prepare a quality plan that is properly integrated into the project plan. The four models of the software development are discussed.<\/p>\n
- \n
- The Software Development Life Cycle (SDLC)<\/li>\n
- model The prototyping model<\/li>\n
- The spiral model<\/li>\n
- The object-oriented model.<\/li>\n<\/ul>\n\n
The SDLC Model is the classic model. It provides the most comprehensive description of the process available. It displays the major building blocks for the entire development process, described as a linear\u00a0sequence. The SDLC Model can serve as a framework within which the other models are presented. The Prototyping Model is based on replacement of one or more SDLC model phases by an evolutionary process, where software prototypes are used for communication between the developer and the users and customers. The Spiral Model provides a methodology for ensuring effective performance at each of the SDLC model phases. It involves an iterative process that integrates customer comments and change requirements, risk analysis and resolution, and software system planning and engineering activities. The Object-Oriented Model incorporates large-scale reuse of software by integrating reusable modules into new software systems. In cases where no reusable software modules are available, the developer may perform a prototyping or SDLC process to complete the newly developed software system.<\/span><\/p>\n<\/div>\n
Factors Affecting SQA activities includes:<\/p>\n
<\/p>\n
Project factors:<\/strong><\/p>\n
<\/p>\n
Magnitude of the project<\/p>\n
<\/p>\n
Technical complexity and difficulty<\/p>\n
<\/p>\n
Extent of reusable software components<\/p>\n
<\/p>\n
Severity of failure outcomes if the project fails<\/p>\n
<\/p>\n
Team factors:<\/strong><\/p>\n
<\/p>\n
Professional qualification of the team members<\/p>\n
<\/p>\n
Team acquaintance with the project and its experience in the area<\/p>\n
<\/p>\n
Availability of staff members who can professionally support the team Familiarity with the team members.<\/p>\n
<\/p>\n
\nQuality assurance activities examine three different aspects of quality by means of software product verification, validation and qualification. Verification examines the consistency of current development activities with the products from previous phases. Validation represents the customer\u2019s interests by examining the extent to which the customer\u2019s original requirements have been fulfilled. Qualification reviews project application of professional standards and coding procedures, based on the assumption that applying these standards facilitates maintenance.<\/p>\n<\/div>\n
A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Reviews acquire special importance in the SQA process because they provide early detection and prevent the passing of design and analysis errors \u201cdownstream\u201d, to stages where error detection and correction are much more intricate, cumbersome, and therefore costly.<\/p>\n
<\/p>\n
The various types of review objectives are:<\/p>\n
<\/p>\n
The Direct Objectives:<\/strong><\/p>\n
- \n
- To detect analysis and design errors.<\/li>\n
- To identify new risks expected to affect the completion of the project. To identify deviations from templates and style procedures.<\/li>\n
- To approve the design product, allowing the team to continue to the next development phase.<\/li>\n<\/ul>\n
<\/p>\n
The Indirect Objectives:<\/strong><\/p>\n
- \n
- To serve as an informal meeting place for the exchange of knowledge about development tools, techniques etc.<\/li>\n
- To promote and support the improvement of development methods by supplying new data for analysis of design errors.<\/li>\n<\/ul>\n\n
Formal design reviews, variously called \u201cdesign reviews\u201d, \u201cDRs\u201d and \u201cformal technical reviews (FTR)\u201d, differ from all other review instruments by being the only reviews that are necessary for approval of the design product. Without this approval, the development team cannot continue to the next phase of the software development project. The review leader should have: Knowledge and experience in development of projects of the type reviewed. Seniority at a level similar to if not higher than that of the project leader. The review team: The entire review team should be selected from among the senior members of the project team together with appropriate senior professionals assigned to other projects and departments, customer\u2013user representatives, and in some cases, software development consultants. Team members are expected to review the design document and list their comments prior to the review session. In cases where the documents are sizable, the review leader may ease the load by assigning to each team member.<\/p>\n<\/div>\n
In follow-up process the person who follows up the corrections is required to determine whether each action item has been satisfactorily accomplished as a condition for allowing the project to continue to the next phase. Follow-up should be fully documented to enable clarification of the corrections in the future. Formal design reviews are authorized to approve the design documents so that work on the next stage of the project can begin. This authority is not granted to the peer reviews, whose main objectives are detecting errors and deviations from standards. Two peer review methods are defined as Inspections and Walkthroughs. Expert opinions, prepared by outside experts, support quality evaluation by introducing additional capabilities to the internal review staff. The organization\u2019s internal quality assurance activities are thereby reinforced. Outside experts transmit their expertise by either:<\/p>\n
- \n
- Preparing an expert\u2019s judgement about a document or a code section.<\/li>\n
- Participating as a member of an internal design review, inspection or walkthrough team.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n","protected":false},"author":4,"menu_order":37,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[],"contributor":[],"license":[],"class_list":["post-300","chapter","type-chapter","status-publish","hentry"],"part":3,"_links":{"self":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/chapters\/300","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/wp\/v2\/users\/4"}],"version-history":[{"count":1,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/chapters\/300\/revisions"}],"predecessor-version":[{"id":302,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/chapters\/300\/revisions\/302"}],"part":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/chapters\/300\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/wp\/v2\/media?parent=300"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/chapter-type?post=300"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/wp\/v2\/contributor?post=300"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/wp\/v2\/license?post=300"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- The Deutsch and Willis factor model<\/strong><\/li>\n<\/ul>\n
- The Evans and Marciniak factor model<\/strong><\/li>\n
- The Deutsch and Willis factor model<\/strong><\/li>\r\n<\/ul>\r\n
- The Evans and Marciniak factor model<\/strong><\/li>\r\n \t