T52-Software Engineering

Transcription

1 T52-Software Engineering Unit - V Implementation and Integration: Implementation Phase Integration Phase - System testing Maintenance Phase. Software Quality Assurance: Quality concepts - cost of quality - Software Quality Group (SQA) -Roles and responsibilities of SQA group- Formal Technical reviews- Quality standards. Objectives: To understand about the importance and procedures of Quality Assurance. To have a deep study about the review techniques. 1.1 Implementation Phase: The implementation phase of software development is concerned with translating design specifications into source code. The primary goal of implementation is to write source code and internal documentation so that conformance of the code to its specification can be easily verified, and so that debugging, testing, and modification are eased. This goal can be achieved by making the source code as clear and straightforward as possible. Source-code clarity is enhanced by structured coding techniques, by good coding style, by appropriate supporting documents, by good internal comments, and by features provided in modern programming languages. Production of high-quality software requires that the programming team have a designated leader, a well-defined organizational structure, and thorough understanding of the duties and responsibilities of each team member Cost of implementation: The cost of product implementation is the cost of implementing, documenting, debugging, and unit testing the source code, plus the cost of completing the User s Manual, the verification plan, the maintenance procedures, and the installation and the training instructions, plus the cost of modifying and correcting the System Definition, the Project Plan, the Software Requirement Specification, the Design Specification, and the Verification Plan, plus the cost of verifying that the 1

2 implementation is complete, consistent, and suitable with respect to the System Definition, the System Requirement Specification, and the Design Documents Structured Coding Techniques: The goal of structured coding is to linearize control flow through a program so that the execution sequence follows the sequence in which the code is written. The dynamic structure of program as it executes then resembles the static structure of the written text. This enhances readability of code, which eases understanding, debugging, testing, documentation and modification of programs. It also facilitates formal verification of programs. Linear flow of control can be achieved by restricting the set of allowed program constructs to single entry, single exit construct format Single Entry, Single Exit Constructs: Sequencing, selection among alternative actions, and iteration is a sufficient set of constructs for describing the control flow of every conceivable algorithm. A sufficient set of single entry, single exit constructs fir specifying control flow in algorithm is Sequencing: S1; S2; S3; Selection: if B then S1 else S2; Iteration: while B do S; The single entry and single exit nature of these constructs are illustrated in the figure below: Fig: 5.1 single entry and single exit Standards and Guidelines: Coding standards are specifications for a preferred coding style. Given a choice of ways to achieve and effect, a preferred way is specified. Coding standards are often viewed by programmers as mechanisms to constrain and devalue the programmer s creative problem solving skills. Creatively always occurs within a basic framework of standards. Without a framework of standards to guide and channel an activity, creativity becomes meaningless chaos. 2

3 A programming standard might specify items such as: 1. Go to statements will not be used. 2. The nesting depth of program constructs will not exceed 5 levels. 3. Subroutine length will not exceed 30 lines. A guideline rephrases these specifications in the following manner: 1. The use of go to statements should be avoided in normal circumstances. 2. The nesting depth of program constructs should be five or less in normal circumstances. 3. The number of executable statements in a subprogram should not exceed Departure from normal circumstances requires approval by the project leader. Documentation Guidelines: Computer software includes the source code for a system and all the supporting documents generated during analysis, design, implementation, testing and maintenance of the system. Supporting Documents: Requirements specifications, design documents, test plans, user s manuals, installation instructions and maintenance reports are example of supporting documents. These documents are the products that result from systematic development and maintenance of computer software. 1.2 Integration Phase: The integration framework is a collection of specialized programs that enables individual CASE tools to communicate with one another, to create a project database, and to exhibit the same look and feel to the end-user (the software engineer). Portability services allow CASE tools and their integration framework to migrate across different hardware platforms and operating systems without significant adaptive maintenance. Most CASE tools in use today have not been constructed using all these building blocks. In fact, some CASE tools remain "point solutions." That is, a tool is used to assist in a particular software engineering activity (e.g., analysis modeling) but does not directly communicate with other tools, is not tied into a project database, is not part of an integrated CASE environment (ICASE). 3

4 Although this situation is not ideal, a CASE tool can be used quite effectively, even if it is a point solution. The relative levels of CASE integration are shown in Figure At the low end of the integration spectrum is the individual (point solution) tool. When individual tools provide facilities for data exchange (most do), the integration level is improved slightly. Such tools produce output in a standard format that should be compatible with other tools that can read the format. In some cases, the builders of complementary CASE tools work together to form a bridge between the tools (e.g., an analysis and design tool that is coupled with a code generator). Integration options Fi 4

5 Using this approach, the synergy between the tools can produce end products that would be difficult to create using either tool separately. Single-source integration occurs when a single CASE tools vendor integrates a number of different tools and sells them as a package. Although this approach is quite effective, the closed architecture of most single-source environments precludes easy addition of tools from other vendors. At the high end of the integration spectrum is the integrated project support environment (IPSE). Standards for each of the building blocks described previously have been created. CASE tool vendors use IPSE standards to build tools that will be compatible with the IPSE and therefore compatible with one another. 1.3 System Testing System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system. Although each test has a different purpose, all work to verify that system elements have been properly integrated and perform allocated functions. A classic system testing problem is "finger-pointing." This occurs when an error is uncovered, and each system element developer blames the other for the problem. Rather than indulging in such nonsense, the software engineer should anticipate potential interfacing problems and 1. Design error-handling paths that test all information coming from other elements of the system, 2. conduct a series of tests that simulate bad data or other potential errors at the software interface, 3. Record the results of tests to use as "evidence" if finger-pointing does occur, and 4. Participate in planning and design of system tests to ensure that software is adequately tested. Recovery Testing It is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed. If recovery is automatic (performed by the system itself), reinitialization, check pointing mechanisms, data recovery, and restart are evaluated for correctness. If recovery requires human intervention, the mean-time-to-repair (MTTR) is evaluated to determine whether it is within acceptable limits. Security Testing 5

6 Security testing attempts to verify that protection mechanisms built into a system will, in fact, protect it from improper penetration. To quote Beizer [BEI84]: "The system's security must, of course, be tested for invulnerability from frontal attack but must also be tested for invulnerability from flank or rear attack." During security testing, the tester plays the role(s) of the individual who desires to penetrate the system. Anything goes! The tester may attempt to acquire passwords through external clerical means; may attack the system with custom software designed to breakdown any defenses that have been constructed; may overwhelm the system, thereby denying service to others; may purposely cause system errors, hoping to penetrate during recovery; may browse through insecure data, hoping to find the key to system entry. Stress Testing: It executes a system in a manner that demands resources in abnormal quantity, frequency, or volume. Essentially, the tester attempts to break the program. For example, 1. Special tests may be designed that generate ten interrupts per second, when one or two is the average rate, 2. Input data rates may be increased by an order of magnitude to determine how input functions will respond, 3. Test cases that require maximum memory or other resources are executed, 4. Test cases that may cause thrashing in a virtual operating system are designed, 5. Test cases that may cause excessive hunting for disk-resident data are created. Performance Testing Performance tests are often coupled with stress testing and usually require both hardware and software instrumentation. That is, it is often necessary to measure resource utilization (e.g., processor cycles) in an exacting fashion. External instrumentation can monitor execution intervals, log events (e.g., interrupts) as they occur, and sample machine states on a regular basis. By incrementing a system, the tester can uncover situations that lead to degradation and possible system failure. 1.4 Maintenance Phase: The maintenance phase focuses on change that is associated with error correction, adaptations required as software s environment evolves, and changes due to enhancements brought about by changing customer requirements. The maintenance phase reapplies the steps of the definition and development phases. Four types of change are encountered during the maintenance phase: 6

7 Correction: Even with the best quality assurance activities, it is likely that the customer will uncover defects in the software. Corrective maintenance changes the software to correct defects. Adaptation: Over time, the original environment (CPU, Operating System, business rules etc) for which the software was developed is likely to change. Adaptive maintenance results in modification to the software to accommodate changes to its external environment. Enhancement: As software is used, the customer will recognize additional functions that will provide benefit. Perfective maintenance extends the software beyond its original functional requirements. Preventive: Computer software deteriorates due to change, and because of this, preventive maintenance, often called software reengineering, and must be conducted to enable the software to serve the need of its end users. Preventive maintenance makes changes to computer programs so that they can be more easily corrected, adapted and enhanced. Today, the aging software is forcing many companies to pursue software reengineering strategies. Software Maintenance Software will undergo change after it is delivered to the customer. Change will occur because errors have been encountered, because the software must be adopted to accommodate changes in its external environment or because the customer requires functional or performance enhancements. Software maintenance reapplies each of the preceding phases to an existing program rather than a new one. The linear sequential model is the oldest and the most widely used model for software engineering. Some of the problems that may arise when linear sequential model is applied are: 1. Real projects rarely follow the sequential flow that the model proposes. Although the linear model can accommodate iterations, it does so indirectly. As a result, changes can cause confusion as the project team proceeds. 2. It is often difficult for the customer to state all the requirements explicitly. The linear sequential model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects. 3. The customer must have patience. A working version of the program will not be available until late in the project time-span. A major blunder, if undetected until the working program is reviewed, can be disastrous. 7

8 Each of these problems is real. But still the classic life cycle model has a definite and important place in the software engineering work. It provides a template into which methods for analysis, design, coding, testing, and maintenance can be placed. The classic life cycle remains the most widely used process model for software engineering. Cost of software maintenance The cost of software maintenance is the sum of the costs of performing product enhancements, making adaptations to new processing requirements, and fixing bugs. Each of these activities may involve modifying and correcting any or all of the supporting documents and running a large number of test cases to verify the correctness of the modification. Maintainability Software maintenance accounts for more effort than any other software engineering activity. Maintainability is the ease with which a program can be corrected if an error is encountered, adapted if its environment changes, or enhanced if the customer desires a change in requirements. A simple time-oriented metric is mean-time-to change (MTTC), the time it takes to analyze the change request, design an appropriate modification, implement the change, test it, and distribute the change to all users. On average, programs that are maintainable will have a lower MTTC (for equivalent types of changes) than programs that are not maintainable. Managerial Aspects of Software Maintenance Successful software maintenance, like all software engineering activities, requires a combination of managerial skills and technical expertise. One of the most important aspects of software maintenance involves tracking and control of maintenance activities. Maintenance activity for a software product usually occurs in response to a change request filed by a user of the product. A change request may entail enhancement, adaptation or error correction. Major enhancements and major adaptations may require extensive analysis and negotiation with the customer. They are often handled as new development projects rather than as routine maintenance activities. A change request is first reviewed by an analyst. In some cases, the request may report a user problem that is not caused by the software being maintained. In this situation, the analyst notifies he user and, with the concurrence of the user, closes the change request. Otherwise, the analyst submits to the control board the change request, the proposed fix, and an estimate of the resources 8

9 required to satisfy request. 1.5 Software Quality Assurance: SQA encompasses: (1) A quality management approach, (2) Effective software engineering technology (methods and tools), (3) Formal technical reviews that are applied throughout the software process, (4) A multitier testing strategy, (5) Control of software documentation and the changes made to it, (6) A procedure to ensure compliance with software development standards (7) Measurement and reporting mechanisms Quality Concepts: The American Heritage Dictionary defines quality as a characteristic or attribute of something. As an attribute of an item, quality refers to measurable characteristics things we are able to compare to known standards such as length, color, electrical properties, and malleability. Software quality is defined as: Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software. Quality of design refers to the characteristics that designers specify for an item. Quality of conformance is the degree to which the design specifications are followed during manufacturing. User satisfaction = compliant product + good quality + delivery within budget and schedule Quality Control Quality control involves the series of inspections, reviews, and tests used throughout the software process to ensure each work product meets the requirements placed upon it. 9

10 Quality Assurance Quality assurance consists of the auditing and reporting functions of management. The goal of quality assurance is to provide management with the data necessary to be informed about product quality, thereby gaining insight and confidence that product quality is meeting its goals Cost of Quality The cost of quality includes all costs incurred in the pursuit of quality or in performing quality- related activities. Quality costs may be divided into costs associated with prevention, appraisal, and failure. Prevention costs include quality planning formal technical reviews test equipment training Appraisal costs include activities to gain insight into product condition the first time through each process. Examples of appraisal costs include in-process and interprocess inspection equipment calibration and maintenance testing Failure costs are those that would disappear if no defects appeared before shipping a product to customers. Internal failure costs includes: rework repair failure mode analysis External failure costs includes: complaint resolution product return and replacement help line support 10

11 warranty work Software Quality Group: The SQG serves to emphasize three important points: 1. Software requirements are the foundation from which quality is measured. Lack of conformance to requirements is lack of quality. 2. Specified standards define a set of development criteria that guide the manner in which software is engineered. If the criteria are not followed, lack of quality will almost surely result. 3. A set of implicit requirements often goes unmentioned (e.g., the desire for ease of use and good maintainability). If software conforms to its explicit requirements but fails to meet implicit requirements, software quality is suspect Roles and responsibilities of SQA group SQA Activities Software quality assurance is composed of a variety of tasks associated with two different constituencies the software engineers who do technical work and an SQA group that has responsibility for quality assurance planning, oversight, record keeping, analysis, and reporting. SQA plan for a project.: The plan is developed during project planning and is reviewed by all interested parties. Quality assurance activities performed by the software engineering team and the SQA group are governed by the plan. The plan identifies: evaluations to be performed audits and reviews to be performed standards that are applicable to the project procedures for error reporting and tracking documents to be produced by the SQA group amount of feedback provided to the software project team 1. Participates in the development of the project s software process description. 2. Reviews software engineering activities to verify compliance with the defined software process. 3. Audits designated software work products to verify compliance with those defined as part of 11

12 the software process. 4. Ensures that deviations in software work and work products are documented and handled according to a documented procedure. 5. Records any noncompliance and reports to senior management. Software Reviews A review any review is a way of using the diversity of a group of people to: 1. Point out needed improvements in the product of a single person or team; 2. Confirm those parts of a product in which improvement is either not desired or not needed; 3. Achieve technical work of more uniform, or at least more predictable, quality than can be achieved without reviews, in order to make technical work more manageable. 1.6 Formal Technical Reviews The objectives of the FTR are (1) To uncover errors in function, logic, or implementation for any representation of the software; (2) To verify that the software under review meets its requirements; (3) To ensure that the software has been represented according to predefined standards; (4) To achieve software that is developed in a uniform manner; (5) To make projects more manageable The Process of FTR The individual who has developed the work product the producer informs the project leader that the work product is complete and that a review is required. The project leader contacts a review leader, who evaluates the product for readiness, generates copies of product materials, and distributes them to two or three reviewers for advance preparation. Each reviewer is expected to spend between one and two hours reviewing the product, making notes, and otherwise becoming familiar with the work. Concurrently, the review leader also reviews the product and establishes an agenda for the review meeting, which is typically scheduled for the next day. The review meeting is attended by the review leader, all reviewers, and the producer. One of the reviewers takes on the role of the recorder; that is, the individual who records (in writing) all important issues raised during the review. The FTR begins with an introduction of the agenda and a brief introduction by the producer. The producer then proceeds to "walk through" the 12

13 work product, explaining the material, while reviewers raise issues based on their advance preparation. When valid problems or errors are discovered, the recorder notes each The Review Meeting Every review meeting should abide by the following constraints: 1. Between three and five people (typically) should be involved in the review. 2. Advance preparation should occur but should require no more than two hours of work for each person. 3. The duration of the review meeting should be less than two hours Review Reporting and Record Keeping A review summary report answers three questions: 1. What was reviewed? 2. Who reviewed it? 3. What were the findings and conclusions? The review issues list serves two purposes: (1) Identify problem areas within the product (2) To serve as an action item checklist that guides the producer as corrections are made. An issues list is normally attached to the summary report. Review Guidelines Guidelines for the conduct of formal technical reviews must be established in advance, distributed to all reviewers, agreed upon, and then followed. 1. Review the product, not the producer. 2. Set an agenda and maintain it. 3. Limit debate and rebuttal. 4. Enunciate problem areas, but don't attempt to solve every problem noted. 5. Take written notes. 6. Limit the number of participants and insist upon advance preparation. 7. Develop a checklist for each product that is likely to be reviewed. 8. Allocate resources and schedule time for FTRs. 9. Conduct meaningful training for all reviewers. 10. Review your early reviews. 13

14 1.7 Quality Standards: A quality assurance system may be defined as the organizational structure, responsibilities, procedures, processes, and resources for implementing quality management. Quality assurance systems are created to help organizations ensure their products and services satisfy customer expectations by meeting their specifications. These systems cover a wide variety of activities encompassing a product s entire life cycle including planning, controlling, measuring, testing and reporting, and improving quality levels throughout the development and manufacturing process. ISO Approach to Quality Assurance Systems ISO 9000 describes the elements of a quality assurance system in general terms. These elements include the organizational structure, procedures, processes, and resources needed to implement quality planning, quality control, quality assurance, and quality improvement. However, ISO 9000 does not describe how an organization should implement these quality system elements. Consequently, the challenge lies in designing and implementing a quality assurance system that meets the standard and fits the company s products, services, and culture. The ISO 9001 Standard ISO 9001 is the quality assurance standard that applies to software engineering. The standard contains 20 requirements that must be present for an effective quality assurance system. Because the ISO 9001 standard is applicable to all engineering disciplines, a special set of ISO guidelines (ISO ) have been developed to help interpret the standard for use in the software process. The requirements delineated by ISO 9001 address topics such as management responsibility, quality system, contract review, design control, document and data control, product identification and traceability, process control, inspection and testing, corrective and preventive action, control of quality records, internal quality audits, training, servicing, and statistical techniques. In order for a software organization to become registered to ISO 9001, it must establish policies and procedures to address each of the requirements just noted (and others) and then be able to demonstrate that these policies and procedures are being followed. 14