CIS210: Software Engineering and Development

Software Quality Assurance

1. Software Quality
1.1. Definition Software quality is called the conformance to explicitly stated functional and performance requirements, documented development standards, and implicit characteristics. Important points: - software requirements are the foundation from which quality is measured ; - specified standards define development criteria that guide the manner in which the software is engineered ; - if the software meets only the explicit requirements, and does not meet the implicit requirements, the software quality is suspect.

1.1 oftware !uality factors "perational characteristics: - correctness - does it do what I want# - relia$ility - does it do it accurately# - efficiency - will it run efficiently on my hardware# - integrity - is it secure# - usa$ility - is it designed for the user# %roduct revision: - maintaina$ility - can I fix it# - flexi$ility - can I change it# - testa$ility - can I test it# %roduct transition: - porta$ility - will I $e a$le to use it on another machine# - reusa$ility - will I $e a$le to reuse some of the software# - interopera$ility - will I $e a$le to interface it with another system#

1.& 'etrics for (rading the oftware !uality factors - audita$ility - the ease with which conformance to standards can $e chec)ed - accuracy - the precision of computations and control - communication commonality - the degree to which standard interfaces are used - completeness - the degree to which the implementation has $een achieved - conciseness - the compactness of the program in terms of lines of code - consistency - the use of uniform design and documentation techniques - data commonality - the use of standard data structures and types - error tolerance - the damage that occurs when the program encounters an error - execution efficiency - the run-time performance of the program

- expanda$ility - the degree to which the design can $e extended - generality - the $readth of potential application of program components - hardware independence - the degree of decoupling from the hardware - modularity - the functional independence of program components - opera$ility - the ease of operation with the system - security - existence of mechanisms that protect the data and the program - simplicity - the degree of understanda$ility of the program without difficulty - tracea$ility - the a$ility to trace a component $ac) to the requirements

1.* +he oftware !uality ystem The quality factors are developed in a system called a quality system, or quality management system. +he software quality system consists of the managerial structure, responsi$ilities, activities, capa$ilities and resources to ensure that the developed software products have the desired quality. +he quality management system encompasses the following activities: - reviews of the pro,ects- qualities - career development of staff - development of standards and procedures

+he concrete details of the quality management system will $e contained in a quality manual. A quality manual will contain standards, procedures and guidelines and will be influenced by external standards. - a standard is instruction of how a pro,ect document or program code is to $e displayed ; - a procedure is a step-$y-step set of instructions descri$ing how a particular software activity is to $e carried out ; - a guideline - consists of advice on $est practice.

2. Software Reviews
Software reviews are a filter to the software engineering process. Reviews are applied at various points during software development and serve to uncover defects that can be removed. . software review is a way of using a group of people to: - point out needed improvements in the product of a single person or team - confirm those parts of the product in which improvement is not desired - achieve technical wor) of more uniform quality than can $e achieved without reviews, in order to ma)e technical wor) more managea$le +here are many different types of reviews: - informal meetings - formal presentation of software - wal)throughs

+he o$vious $enefit from formal technical reviews, wal)throughs, is the early discovery of software defects so that each defect may $e corrected prior to the next step in the software engineering process. . defect amplification model can $e used to illustrate the generation and detection of errors during the steps in the software engineering process.

3. Formal Technical Reviews

. formal technical review /0+12 is a software quality assurance activity performed $y software engineers with the following o$,ectives: - to uncover errors in function, logic or implementation of the software ; - to verify that the software meets its requirements ; - to esnure that the software has $een developed according to the standards ; - to achieve uniform software ; - to ma)e pro,ects managea$le. +he formal technical review serves to promote $ac)up and continuity $ecause a num$er of people $ecome familiar with parts of the software that they may not have otherwise seen. 3ach 0+1 is conducted as a meeting and is considered successful only if it is properly planned, controlled and attended.

*.1. +he 1eview 'eeting 3very review meeting should a$ide $y the following constraints: - $etween * and 4 people should $e involved in the review ; - advance preparation should occur $ut should require no more than & hours of wor) for each person ; - the duration of the review meeting should $e less than & hours. 1ather than attempting to review the entire design, wal)throughs are conducted for modules or for small groups of modules.

+he focus of the 0+1 is on a product- a component of the software. +he review meeting is attended $y the review leader, all reviewers, and the producer. +he producer organi5es a 6wal) through6 the product, explaining the material, while the reviewers raise issues $ased on their advance preparation. 7hen errors are discovered, the recorder notes each. .t the end of the review the attendees decide whether to accept the product or not, with or without modifications.

*.&. 1eview 1eporting and 1ecord 8eeping During the 0+1, the reviewer actively records all issues that have $een raised. 0inally, a review summary report is produced. *.*. 1eview (uidelines (uidelines for the conduct of formal technical reviews must $e esta$lished in advance, distri$uted to all reviewers, agreed upon, and then followed. .n example set of guidelines is the following: - review the product, not the producer - set an agenda and maintain it - limit de$ate and re$uttal - enunciate pro$lem areas, $ut don-t attempt to solve every pro$lem noted - ta)e written notes - limit the num$er of participants and insist upon advance preparation - develop a chec)list for each product that is li)ely to $e reviewed - allocate resources and time schedule for 0+1s - conduct meaningful training for all reviewers - review your early reviews

*.9. 1eview :hec)lists :hec)lists are used to assess products that are derived as part of the software development process. System Engineering phase: a system specification is prepared - are ma,or functions defined in unam$igous fashion # - are interfaces $etween the system elements defined # - have performance $ounds $een esta$lished # - has the $est alternative $een selected # - is the solution technically feasi$le # - has a mechanism for system validation and verification $een esta$lished # - is there consistency among the system components #

Software ro!ect lanning phase: a software pro,ect plan is prepared - is software scope unam$iguously defined and $ounded # - are resources adequate for the scope # - are resources readily availa$le # - have ris)s in all important categories $een defined # - is a ris) management plan in place # - is the $asis for cost estimation reasona$le #

Software Requirements Analysis phase: preparing requirements specification - is information domain analysis complete, consistent, and accurate # - is pro$lem partitioning complete # - are external and internal interfaces properly defined # - does the model properly reflect data o$,ects, their attri$utes and relations # - are all requirements tracea$le to system level # - has prototyping $een conducted for the user # - are requirements consistent with schedule, resources, and $udget # - are validation criteria complete #

Software "esign phase: preliminary design reviews - are the software requirements reflected in the architecture # - is effective modularity achieved # - are interfaces defined for all necessary modules # - is the data structure consistent with the information domain # - is the data structure consistent with the requirements # - has maintaina$ility $een considered # - does the algorithm accomplish the desired function # - is the algorithm logically correct # - is the interface consistent with the architectural design # - is the logical complexity reasona$le # - are local data structures properly defined # - is design detail amena$le to the implementation language #

Software #oding phase: source code - has the design $een properly translated into code # - has proper use of language conventions $een made # - is there compliance with coding standards for the language style # - are data types and data declarations proper # - have all the items on the design wal)through chec)list $een reapplied #

Software Testing phase: test plan - have ma,or test phases properly $een identified # - are ma,or functions demonstrated early # - is the test plan consistent with the overall pro,ect plan # - are test resources identified and availa$le # - has tracea$ility to validation criteria $een esta$lished as part of the software requirements analysis#

$aintenance phase: test plan - have side effects associated with change $een considered # - has the change, once made, $een documented and reported # - have appropriate 0+1s $een conducted # - has a final acceptance review $een conducted #

4. Software Quality Standards

+he most general standards are: I " ;<<1 and =ritish tandard Institute = 4>4< +he relevant standards for the industry are: I " ;<<1 : !uality ystems-'odel for !uality .ssurance and Design I " ;<<<-*: (uidelines for the application of I " ;<<1 to the Development, upply and 'aintenance of oftware I " ;<<9-&: !uality 'anagement and !uality ystem 3lements