In topic 1 it was mentioned that some specific SQM processes are defined in the IEEE
12207.0-96 standard:
* Verification Processes
* Validation Processes
* Review Processes
* Audit Processes
Based on (SWEBOK, Guide to the Software Engineering Body of Knowledge, 2004
Version “http://www.swebok.org/pdfformat.html”)
1. Please submit a contribution describing your response, considering the following:
to. Select one of the two processes (Review and Audit) and investigate. Describe
what it refers to, how it is defined and its main characteristics.
b. Integrate a response with your research and your personal contribution and conclusion
and post it as your contribution in the discussion forum.
SOLUTION:
Software quality assurance is an activity that is applied throughout the software
development process. SQA comprises procedures for the effective application of methods
and tools, formal technical reviews, and testing strategies.
REVIEW PROCESS: The objective of a Software Item Review is to evaluate the
software or project status to identify discrepancies from planned outcomes and
recommend improvements where appropriate.
* Its objective is to evaluate the status and products of one or more activities in one or
more projects.
* They are carried out at the management and technical levels and throughout the life
cycle.
* Can be done by either party
One party (reviewing party) reviews the actions of the other (reviewed party).
Reviews serve to:
• Point out the need for improvements to the product of a single person or a team.
• Confirm the parts of a product where improvement is not necessary or desirable.
• To achieve technical work of a more uniform, or more predictable, quality than can be
achieved without reviews, in order to make technical work more manageable.
Formal technical reviews
• Discover errors in the function, logic, or implementation of any representation of the
software.
• Verify that the software under review meets its requirements.
• Ensure that the software has been represented according to certain predefined standards.
• Achieve uniformly developed software.
• Make projects more manageable.
The review meeting:
• Between 3 and 5 people should be called for the review.
• It should be prepared in advance, but without requiring more than 2 hours of work from
each person.
• The duration of the review meeting should be < 2 hours.
Roles:
• The producer
• Reviewer
• The review chief
• The registrar
Review Record and Report:
Prepare a review summary
• What was reviewed?
• Who reviewed it?
• What was discovered and what were the conclusions?
• Identify problem areas within the product.
• Checklist of action items for corrections.
Guidelines for a review:
1.- Review the product, not the producer.
2.- Set an agenda and stick to it.
3.- Limit debate and challenges.
4.- State problem areas, but do not try to solve any problem that arises.
5.- Take written notes.
6.- Limit the number of participants and insist on advance preparation.
7.- Develop a checklist for each product to be reviewed.
8.- Have resources and an agenda for formal Technical Reviews.
9.- Carry out proper training of all inspectors.
10.- Review previous reviews.
THE SOFTWARE AUDIT PROCESS
1. Objective. As indicated, it is to provide confirmation of the conformity of products
and processes to certify adherence to standards. Guidelines, specifications and
procedures.
2. Summary. The audit is carried out in accordance with documented plans and
procedures. The audit plan establishes a procedure for directing the audit and for follow-
up actions on audit recommendations.
3. Special responsibilities. It is the responsibility of the audit team leader to organize
and direct the audit and coordinate the preparation of the audit report items. The team
leader must ensure that the audit team is prepared to carry out the audit, and that the
procedures and the different points are carried out and reflected in the reports according
to their scope.
4. Entry.
The purpose and scope of the audit.
Objective audit criteria, such as contracts, requirements, plans, specifications, procedures,
guidelines and standards.
The software elements and processes to be audited and any relevant background.
Additional information regarding the organization responsible for the products and
processes to be audited (for example, organizational charts).
5. Starting criteria.
The need for an audit to be initiated must be due to one of the following events:
6. Procedures:
1. A special project milestone has been reached. The audit is initiated by previous plans
(for example, quality assurance plan, software development plan).
2. External parties (e.g. regulatory agencies or end users) requesting an audit at a
specific date or project milestone. This may be due to the fulfillment of a requirement of
a contract or as a prerequisite to a contractual agreement.
3. An element of the local organization (for example, the project manager, functional
management, systems engineering, quality assurance or internal control) has requested
the audit by establishing a clear and specific need.
4. A special project milestone, calendar date, or other criterion has been reached and is
within the audit organization's planning requirements for initiation of an audit.
* Planning
* Introduction.
* Preparation.
* Exam.
* Reports.
* Termination criteria
* Departures.
* Adaptability
OBJECTIVES OF QUALITY AUDITS
* Set the status of a project.
* Verify the ability to perform or continue a specific job.
* Check which applicable elements of the. Quality Assurance Program or Plan has
been developed and documented.
* Verify the adherence of these elements to the Quality Assurance program or Plan.
QUALITY PROCESSES
* Quality of products and services.
* Adequate delivery time.
* Cost within the established limits.
QUALITY PROCESSES
Goals Main principles included
AUDIT OF SOFTWARE QUALITY SYSTEMS
The purpose of a Quality System audit, or a quality assessment program, is to provide an
independent assessment of the conformance of a Software Quality assurance plan.
The audit should be directed to ensure that:
to) Coded software products (such as a software element) will reflect what is
designed in the documentation.
b) The acceptance review and testing requirements prescribed by the documentation are
adequate for the acceptance of the software products.
c) The test data meets the specification.
d) The software products were successively tested and met their specifications.
e) Test reports are correct and discrepancies between the results achieved and those
expected have been resolved.
f) User documentation complies with the standards as specified.
g) The activities have been carried out in accordance with the applicable requirements,
plans and contract.
h) The cost and. the schedule conforms to established plans.
CONCLUSION:
Software reviews are an effective means of discovering bugs and improving software
quality. The benefit they bring is early discovery of errors and verification that the
software meets system requirements.
The review allows us to:
• Detect defects in the “early stages” of software product development
• Reduce correction costs in later stages
• Detect missing or misinterpreted functionalities
• Lower the rate of defects introduced in test case design and coding due to
misinterpretation of requirements specifications
Therefore these processes are defined in the SQA and the objective of quality assurance
is to provide management with the necessary data to be certain that the product is being
made with quality.
http://www.buenastareas.com/ensayos/Seguridad-En-El-Software-Sqa/213734.html