SQA aactivity in spmytreyredfedgytrturetryu
- 1. Presentation on SQA ACTIVITIES Computer Science and Engineering INSTITUTE OF ENGINEERING AND TECHNOLOGY BUNDELKHAND UNIVERSITY , JHANSI Submitted to – Er Keshav Tiwari Submitted by – Deepak Kumar Roll num – 181381030016
- 2. What is Software Quality? • Quality is an attribute of software that implies the software meets its specification • This definition is too simple for ensuring quality in software systems • Software specifications are often incomplete or ambiguous • Some quality attributes are difficult to specify • Tension exists between some quality attributes, e.g. efficiency vs. reliability
- 3. Software Quality Attributes • Safety • Security • Reliability • Resilience • Robustness • Understandability • Testability • Adaptability • Modularity • Complexity • Portability • Usability • Reusability • Efficiency • Learnability
- 4. Software Quality Assurance • To ensure quality in a software product, an organization must have a three-prong approach to quality management: • Organization-wide policies, procedures and standards must be established. • Project-specific policies, procedures and standards must be tailored from the organization-wide templates. • Quality must be controlled; that is, the organization must ensure that the appropriate procedures are followed for each project • Standards exist to help an organization draft an appropriate software quality assurance plan. • ISO 9000-3 • ANSI/IEEE standards • External entities can be contracted to verify that an organization is standard- compliant.
- 5. SQA Activities • Applying technical methods • To help the analyst achieve a high quality specification and a high quality design • Conducting formal technical reviews • A stylized meeting conducted by technical staff with the sole purpose of uncovering quality problems • Testing Software • A series of test case design methods that help ensure effective error detection • Enforcing standards • Controlling change • Applied during software development and maintenance • Measurement • Track software quality and asses the ability of methodological and procedural changes to improve software quality • Record keeping and reporting • Provide procedures for the collection and dissemination of SQA information
- 6. Advantages of SQA • Software will have fewer latent defects, resulting in reduced effort and time spent during testing and maintenance • Higher reliability will result in greater customer satisfaction • Maintenance costs can be reduced • Overall life cycle cost of software is reduced
- 7. Disadvantages of SQA • It is difficult to institute in small organizations, where available resources to perform necessary activities are not available • It represents cultural change - and change is never easy • It requires the expenditure of dollars that would not otherwise be explicitly budgeted to software engineering or QA
- 8. Quality Reviews • The fundamental method of validating the quality of a product or a process. • Applied during and/or at the end of each life cycle phase • Point out needed improvements in the product of a single person or team • Confirm those parts of a product in which improvement is either not desired or not needed • Achieve technical work of more uniform, or at least more predictable, quality than what can be achieved without reviews, in order to make technical work more manageable • Quality reviews can have different intents: • review for defect removal • review for progress assessment • review for consistency and conformance
- 10. Review Checklist for Systems Engineering • Are major functions defined in a bounded and unambiguous fashion? • Are interfaces between system elements defined? • Are performance bounds established for the system as a whole and for each element? • Are design constraints established for each element? • Has the best alternative been selected? • Is the solution technologically feasible? • Has a mechanism for system validation and verification been established? • Is there consistency among all system elements?
- 11. Review Checklist for Software Project Planning • Is the software scope unambiguously defined and bounded? • Is terminology clear? • Are resources adequate for the scope? • Are resources readily available? • Are tasks properly defined and sequenced? • Is the basis for cost estimation reasonable? Has it been developed using two different sources? • Have historical productivity and quality data been used? • Have differences in estimates been reconciled? • Are pre-established budgets and deadlines realistic? • Is the schedule consistent?
- 12. Review Checklist for Software Requirements Analysis • Is the information domain analysis complete, consistent, and accurate? • Is problem partitioning complete? • Are external and internal interfaces properly defined? • Are all requirements traceable to the system level? • Is prototyping conducted for the customer? • Is performance achievable with constraints imposed by other system elements? • Are requirements consistent with schedule, resources, and budget? • Are validation criteria complete?
- 13. Review Checklist for Coding • Is the design properly translated into code? (The results of the procedural design should be available at this review) • Are there misspellings or typos? • Has proper use of language conventions been made? • Is there compliance with coding standards for language style, comments, module prologue? • Are incorrect or ambiguous comments present? • Are typing and data declaration proper? • Are physical constraints correct? • Have all items on the design walkthrough checklist been reapplied (as required)?
- 14. Review Checklist for Software Testing (Test Plan) • Have major test phases been properly identified and sequenced? • Has traceability to validation criteria/requirements been established as part of software requirements analysis? • Are major functions demonstrated early? • Is the test plan consistent with the overall project plan? • Has a test schedule been explicitly defined? • Are test resources and tools identified and available? • Has a test recordkeeping mechanism been established? • Have test drivers and stubs been identified, and has work to develop them been scheduled? • Has stress testing for software been specified?
- 15. Formal Technical Review (FTR) • Software quality assurance activity that is performed by software engineering practitioners • Uncover errors in function, logic, or implementation for any representation of the software • Verify that the software under review meets its requirements • Assure that the software has been represented according to predefined standards • Achieve software that is developed in a uniform manner • Make projects more manageable • FTR is actually a class of reviews • Walkthroughs • Inspections • Round-robin reviews • Other small group technical assessments of the software
- 16. The Review Meeting • Constraints • Between 3 and 5 people (typically) are involved • Advance preparation should occur, but should involve no more that 2 hours of work for each person • Duration should be less than two hours • Components • Product - A component of software to be reviewed • Producer - The individual who developed the product • Review leader - Appointed by the project leader; evaluates the product for readiness, generates copies of product materials, and distributes them to 2 or 3 reviewers • Reviewers - Spend between 1 and 2 hours reviewing the product, making notes, and otherwise becoming familiar with the work • Recorder - The individual who records (in writing) all important issues raised during the review