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.

1.1.1 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
 implementation is complete, consistent, and suitable with respect to the System Definition, the
System Requirement Specification, and the Design Documents.

1.1.2 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.

1.1.3 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
 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 30.
4. 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
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 19.2. 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).

Fi
Integration options

4
 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
 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
 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
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
 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.

1.5.1 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
 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.

1.5.2 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
 • warranty work

1.5.3 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.

1.5.6 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
 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.

1.6.1 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
 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.

1.6.2 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.
1.6.3 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
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
9000-3) 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