Unit II Software Testing and Quality Assurance

UNIT II PCS 34 SOFTWARE TESTING AND QUALITY ASSURANCE II-MSc –Computer Science, Thiruvalluvar University, Vellore- 632 115

of 28

Periyar Government Arts College, Cuddalore- 607 001

UNIT-II

Quality Standards: Quality Standards, Practices and Conventions -

Software Configuration Management - Reviews and Audits - Enterprise

Resource Planning Software.

2.1 QUALITY STANDARDS, PRACTICES AND CONVENTIONS:

1. Software

2. Software Testing

3. Software Quality Assurance

4. Software Quality

5. Software Standards

6. Software Practices

7. Software Conventions

1. Software

Software is a set of programs which is designed to perform a well

defined functions or it is an sequence of instructions written to solve a

particular problem.

2. Software Testing

Software testing is an method of assessing the functionality of a

software program.

2.1 Types

Dynamic Testing:

Conducted at the program‟s execution.

Static Testing:

Examinations of the program code and associated documentation.

3. Software Quality Assurance

Quality assurance system is the organizational structure,

responsibilities, procedures, processes and resources for

implementing quality management.

“Conformance to explicitly stated functional and performance

requirements, explicitly documented development standards, and

implicit characteristics that expected of all professional developed

software.”


of 28


4. Quality

Quality refers to any measurable characteristics such as correctness,

maintainability, portability, testability, usability, reliability, efficiency,

integrity, reusability and interoperability.

4.1 Five views of Software Quality

Transcendental view

User‟s view

Manufacturing view

Product view

Value-based view

4.2 Quality Concepts

Quality of Design:

Quality of Design refers to the characteristics that designer‟s specify

for an item.

Quality of Conformance:

Quality of Conformance is the degree to which the design

specifications are followed during manufacturing.

Quality Control:

Quality Control is the series of inspections, reviews and tests used

throughout the development cycle to ensure that each work product meets

the requirements placed upon it.

Quality Policy:

Quality policy refers to the basic aims and objectives of an

organization regarding quality as stipulated by the management.


of 28


Quality Assurance:

Quality assurance consists of the auditing and reporting functions of

management.

Cost of Quality:

Cost of Quality includes all costs incurred in the pursuit of quality or

in performing quality related activities such as appraisal costs, failure costs

and external failure costs.

Quality Planning:

Quality planning is the process of assessing the requirements of the

procedure and of the product and the context in which these must be

observed.

Quality Assurance Plan:

Quality assurance plan is the central aid for planning and checking

the quality assurance.

Quality Assurance System:

Quality assurance system is the organizational structure,

responsibilities, procedures, processes and resources for implementing

quality management.

4.3 Cost of Quality

Prevention costs include

quality planning

formal technical reviews

test equipment

Training Internal failure costs include

rework

repair

failure mode analysis

External failure costs are

o complaint resolution o product return and replacement

o help line support

warranty work


of 28


5. Software Standards

It is an standard protocol, or other common format of a document, file

or data transfer accepted and used by one or more software developers while

working on one or more than one computer programs.

5.1 Some Standards Organizations:

o ANSI: American National Standards Institute

( Does not itself make standards but approves them).

o AIAA: American Institute of Aeronautics and Astronautics

(e.g. AIAA R-013-1992 Recommended Practice for Software

Reliability).

o EIA: Electronic Industries Association

(e.g. EIA/IS-632 Systems Engineering).

o IEC: International Electrotechnical Commission

(e.g. IEC 61508 Functional Safety - Safety-Related Systems)

o IEEE: Institute of Electrical and Electronics Engineers

Computer Society Software Engineering Standards Committee

(e.g. IEEE Std 1228-1994 Standard for Software Safety Plans)

o ISO: International Organization for Standardization

(e.g. ISO/IEC 2382-7:1989 Vocabulary-Part 7: Computer

Programming)

6. Practices

6.1 The Basic Practices

Functional Specifications

Reviews and Inspection

Formal entry and exit criteria

Functional test - variations

Multi-platform testing

Internal Betas

Automated test execution

Beta programs

'Nightly' Builds

Functional Specification

A functional specification often describes the external view of an

object or a procedure indicating the options by which a service could be

invoked. The testers use this to write down test cases from a black box

testing perspective.


of 28


Reviews and Inspection

It is argued that software inspection can easily provide a ten times

gain in the process of debugging software.

Formal Entry and Exit Criteria

The idea is that every process step, be it inspection, functional test, or

software design, has a precise entry and precise exit criteria.

These are defined by the development process and are watched by

management to gate the movement from one stage to another.

It is arguable as to how precise any one of the criteria can be, and

with the decrease of emphasis development, process entry and exit

criteria went out of currency.

Functional Test – Variations

Most functional tests are written as black box tests working off a

functional specification. The number of test cases that are generated

usually are variations on the input space coupled with visiting the

output conditions.

A variation refers to a specific combination of input conditions to yield

a specific output condition.

Multi-Platform Testing

Many products today are designed to run on different platforms which

create the additional burden to both design and test the product.

When code is ported from one platform to another, modifications are

sometimes done for performance purposes.

The net result is that testing on multiple platforms has become a

necessity for most products.

Therefore techniques to do this better, both in development and

testing, are essential.

This best practice should address all aspects of multi-platform

development and testing.


of 28


Internal Betas

The idea of a Beta is to release a product to a limited number of

customers and get feedback to fix problems before a larger shipment.

For larger companies, such as IBM, Microsoft and Oracle, many of

their products are used internally, thus forming a good beta audience.

Techniques to best conduct such an internal Beta test are essential

for us to obtain good coverage and efficiently use internal resources.

This best practice has everything to do with Beta programs though on

a smaller scale to best leverage it and reduce cost and expense of an

external Beta.

Automated Test Execution

The goal of automated test execution is that we minimize the amount

of manual work involved in test execution and gain higher coverage with a

larger number of test cases.

‘Nightly’ Builds

The concept of a nightly build has been in vogue for a long time. While

every build is not necessarily done every day, the concept captures frequent

builds from changes that are being promoted into the change control

system.

7. Conventions

Coding conventions are a set of guidelines for a specific programming

language that recommend programming style, practices and methods

for each aspect of a piece program written in this language.

These conventions usually cover file organization, indentation,

comments, declarations, statements, white space, naming

conventions, programming practices, programming principles,

programming rules of thumb, architectural best practices, etc. These

are guidelines for software structural quality.

Software programmers are highly recommended to follow these

guidelines to help improve the readability of their source code and

make software maintenance easier.

Coding conventions are only applicable to the human maintainers and

peer reviewers of a software project.

http://en.wikipedia.org/wiki/Programming_language

http://en.wikipedia.org/wiki/Programming_language

http://en.wikipedia.org/wiki/Programming_style

http://en.wikipedia.org/w/index.php?title=File_organization&action=edit&redlink=1

http://en.wikipedia.org/wiki/Indent_style

http://en.wikipedia.org/wiki/Comment_(computer_programming)

http://en.wikipedia.org/wiki/Declaration_(computer_science)

http://en.wikipedia.org/wiki/Statement_(programming)

http://en.wikipedia.org/wiki/Whitespace_(computer_science)

http://en.wikipedia.org/wiki/Identifier_naming_convention

http://en.wikipedia.org/wiki/Identifier_naming_convention

http://en.wikipedia.org/wiki/Best_Coding_Practices

http://en.wikipedia.org/wiki/Category:Programming_principles

http://en.wikipedia.org/wiki/Category:Programming_rules_of_thumb

http://en.wikipedia.org/wiki/Software_quality_model

http://en.wikipedia.org/wiki/Programmer

http://en.wikipedia.org/wiki/Readability

http://en.wikipedia.org/wiki/Source_code

http://en.wikipedia.org/wiki/Software_maintenance

http://en.wikipedia.org/wiki/Peer_review


of 28


Conventions may be formalized in a documented set of rules that an

entire team or company follows, or may be as informal as the habitual

coding practices of an individual.

Coding conventions are not enforced by compilers. As a result, not

following some or9 all of the rules has no impact on the executable

programs created from the source code.

2.2 SOFTWARE CONFIGURATION MANAGEMENT:

In software engineering, software configuration management (SCM)

is the task of tracking and controlling changes in the software.

Configuration management practices include revision control and the

establishment of baselines.

1. Maintenance is a set off software engineering activities that occur

after software has been delivered so the customer.

2. Software configuration management is a set of tracking and control

activities that begin when a software projects begins.

3. It terminates only when the software is taken out of operation.

Software Maintenance

1. The maintenance of existing software can account of over 60% of all

effort expended by a development organization.

2. The ubiquitous nature of change underlies all software work.

3. Change is inevitable when computer based system are built.

4. Their external environment, making enhancement requested by

user and reengineering an application.

5. When maintenance is considered to encompass all of these

activities. It is relatively easy to see and absorbs.

Metrics

The primary objectives for object-oriented metros are the same as

those metric derived for conventional software.

•To better understand the quality of the product.

•To assess the effectiveness of the process. •To improve the quality of work performed at a perfect level

http://en.wikipedia.org/wiki/Compiler


of 28


SOFTWARE CONFIGURATION MANAGEMENT

Describe software configuration management

Know SCM process

Define version control

Explain change control

Know configuration audit

Introduction:

Software Configuration Management (SCM) is one of the foundations

of Software Engineering. It is used track and manages the emerging product

and its versions. This is to assure quality of the product during

development, and operational maintenance of the product. SCM ensures

that all people involved in the software process know that what is being

designed, developed, built, tested and delivered. Through SCM the design

requirements can be traced to the final software product.

Software Configuration Management:

Different people defined SCM differently. The following are the some

software configuration management definitions.

Software Configuration Management is the art of identifying,

organizing, and controlling modifications to the software being

built by a programming team. The goal of is to maximize

productivity by minimizing mistakes.

Software Configuration Management is the process of defining

and implementing a standard configuration that results into the

primary benefits such as easier step-up and maintenance, less

down time, better integration with enterprise management, and

more efficient and reliable backups.

Software Configuration Management is the process concerned

with the development of procedures and standards for

managing an evolving software system product.

Software Configuration Management is the ability to control and

manage change in a software project.

Software Configuration Management is a set of procedures

meant to identify, control, provide and log the various work

products of software project.

In the simplest sense, Software Configuration Management is

the process of controlling baselines software documents and

code.


of 28


Baselines

In accordance of IEEE Standards 729, a baseline is “a specification or

product that has been formally reviewed and agreed upon, that thereafter

serves as the basis for further development, and that can be changed only

through formal change control procedures.”

The baseline uses the shared project database. It is an SCM task to

maintain the integrity of the set of artifacts. An approach to the integrity

issue is to require approval for adding items to the baselines. A second part

to maintaining integrity is dealing with modifications to items in the

database.

The following are the some typical software configuration items (SCIs)

that are identified approved, made into baselines and then stored in the

project database.

Requirements

o User defined requirements

o System requirements

Project Management Plan

o Work packages

o Schedule

o Budget

o Risk Management plan

User Manual

o User primer guide

o Operational manual

o User troubleshooting

Design

o Prototype design

o Data structure design

o Module design

o Machine interface design

o User interface design

o Object design


of 28


Source Code

o File and data structure declarations

o Subsystem 1 modules

o Subsystem 2 modules

Test Materials

o Procedures

o Cases

o Data

o Results

Operational System

o Subsystem 1 executable version

o Subsystem 2 executable version

Documents

o Documents not previously listed

Software Configuration Items

Software Configuration items that comprises all information produced

as part of the software engineering process is called a software

configuration. Artifacts produced during the process are called software

configuration items (SCIs).

Some examples of software configuration items are:

Management plans (Project plan, Test plan, etc.,)

Specification (Requirements, Design, Test Case, etc.,)

Customer documentation (Implementation Manual, User Manuals,

Operational Manuals, On-Line help files)

Source code (PL/I Fortran, COBAL, Visual Basic, Visual C, C++, JAVA,

PHP, C#, etc.,)

Executable Code (Machine readable object code, .exe‟s, etc)

Libraries (Runtime Libraries, Procedures, API‟s DLL‟s etc.,)

Database (Data being Processed, Data a program requires, test data,

Regression test data, etc.,)

Production documentation.

The SCM Process

The procedure for software configuration management are laid down

in the form of a SCM plan document. Sample structure of a configuration

management plan is provides in the following table 1.


of 28


Identification of Objects in the Software Configuration

The following are the major objectives of software configuration

standards:

o Remote system administration

o Reduced user down-time

o Reliable data backups

o Easy workstation set-up

o Multi-user support

o Remote software installation

Remote System Administration

The configuration standard should include necessary software and/or

privileges for remote system administration tools.

Introduction

Purpose

Scope

Definitions and acronym

Management

Organization

Configuration Management Responsibilities

Interface Control

Implementation of Software Configuration Management Plan

Applicable policies, Directives and Procedures

Configuration Management Activities

Configuration Identification

Configuration Control

Configuration Status Accounting

Audit and Reviews

Tools Techniques and Methodologies

Supplier Control

Records Collection and Retention


of 28


A remote administration client that is correctly and configured on the

client side is the cornerstone of the remotely administered network.

The remote tools can be used to check the version of virus protection,

check machine configuration or offer remote help-desk functionality.

Reduced user down-time

A great advantage of using standard configuration is that systems

become completely interchangeable resulting in reduced user down time.

If a given system experience an unrecoverable error, and identical new

system can be dropped into place.

User data can be transferred if the non-functional machine is still

accessible, or the most recent copy can be pulled off the backup tape with

the ultimate global being that the user experiences little change in the

system interface.

Reliable data backups

Using a standard directory for user data allows backup systems to

selectively back up a small portion of a machine, greatly reducing the

network traffic and tape usage for backup system. Also, should a

catastrophic failure occur the data directory could be restored to a new

machine with little time and effort.

A divided directory structure, between system and user data, is one of

the main goals of the configuration standard.

Easy workstation set-up

Any sort of standardized configuration streamlines the process of

setting up the system and insures that vital components are available.

If multiple machines are being set-up according to a standard set-up

most of the set-up and configuration can be automated.

Multi-User Support Although it is not common for users to share a workstation, the

system configuration is designed to allow multiple users the same

workstation without interfacing with each other‟s work.

Some software packages do not support completely independent

settings for all users; however, users can have independent data areas.


of 28


The directory structure implemented does not impose limits on the

number of independent users a system can have.

Remote Software Installation

Most modern software packages are installed in factory pre-defined

directories. While software installed in this manner will function correctly for

a single user, it will lead to non-uniform configuration among a collection of

machines.

A good configuration standard will have software installed in specified

directory areas to logically divide software on the disk.

This will lead to easier identification of installed components and the

possibility of automating installation procedures through the use of

universal scripts.

With software installed into specific directories, maintenance and

upgrading running software become less complex.

VERSION CONTROL

Version trackers are used to maintain records of revision that are

made to source code modules. When new releases, or versions, are

generated the new version can be tested and compared against past

versions, and reconstituted whenever necessary. This gives the project a

history of its source code.

There are several version trackers such as CVS, SCCS etc.,

CVS Version Trackers: Many version trackers like CVS (Control

Version System), only save the differences between the code, and not

the entire code for each version, to save storage space.

SCCS Version Tracker: Source Code Control System (SCCS) keeps

track of system modifications and different system versions. It was

originally developed for IBM 370 hardware but is now distributed with

UNIX.

The aim of SCCS is to allow different versions of the system to be

maintained without unnecessary code duplication.

SCCS control system updates by ensuring that a system component

cannot updated by more than one programmer at any one time. It also

records when updates were made, what source lines were changed

and who was responsible for the change.


of 28


CHANGE CONTROL

Change control involves procedures and tools to bring order to the

change process. Larger projects have a Change Control Board (CCB), whose

responsibility is to review and approve or disapprove change. It is the CCB

responsibility to provide the mechanism to maintain orderly change process.

Goals of Change Procedure

An effective change control procedure should:

Provide a mechanism for accepting changes that improve the product

overall while rejecting those that degrade it.

Facilitate changes to work products during their initial formative

development while avoiding unnecessary overhead or formality.

Provide revision control and backup safety for work products during

their formative development.

Allow for formal acceptance of work products after their initial

formative development has been completed.

Facilitate efficient changes to work products after their initial

acceptance, recognizing that the impact of a change to a work product

is dramatically different after the work product has been accepted.

Allow all parties materially affected by proposed changes to accepted

work products to assess the resource, schedule, and/or product

impact of the changes.

Allows changes to accepted work products to be proposed and

evaluated, schedule and quality impact assessed, and approved or

rejected into work products in a controlled manner.

Notify interested parties on the periphery of development regarding

change proposals, their assessed impact, and whether the changes

were approved or rejected.

Provide an historic trail of the development of work products,

including all proposed changes.

Change Control Process

Change control procedures ensure that changes to the system are

controlled and that their effect on the system can be predicted. To make

change, a change control form (CCF), or a software problem report (SPR), is

shifted out. The form contains data on estimation costs, the date when the

change was requested, approved, implemented, and validated. The

information on the form is defined in the SCM plan and it makes up much

of the information in the SCM database.


of 28


Need for Change Recognized

User Submits Change Request

Developer Evaluates

Change Report Generated

Change Control Board Evaluates

Request queued for action change order generated

Request Denied

Individual assigning to SCM User Informed

SCI checked out

Change made

Change Reviewed

SCIs checked in

Fig: Change Control Process

Then this form is submitted to the change control board (CCB). Then

it is examined by CCB for its validity, the impact of the change and the cost.

The change is then approved, or disapproved by the CCB. If it is approved, it

is applied to the software and regression testing is done to be sure that the

changes has not affected other parts of the system.

Records are kept of all changes approved and disapproved. This allows

for history reports to be generated when required.


of 28


CONFIGURATION AND AUDIT

Audit and reviews are used to ensure that changes have been properly

implemented.

The formal review looks at the technical correctness of any Software

Configuration Item (SCI) that has been modified. An SCI is looked at to

determine any omission, potential side effects, and its consistency with

other SCIs. Formal reviews are conducted for all but the most trivial

changes.

The audit completes the technical review by looking at the SCI for

characteristics that generally are not considered during the review. Some of

these characteristics are:

Has formal review been done?

Have all software quality standards been followed?

Have the changes been noted, dated, and author specified?

Auditing gives us a picture of how close the current software system

mirrors the software system pictured in the baseline, and the requirements

document. Auditing provides the mechanism for establishing a new

baseline. The final stage of and auditing are used to sanction the new

baseline.

Verifying and validating any changes that have occurred ensures that

a perspective baseline is consistent with the previous baseline. Baseline

auditing and sanctioning is one of the major ways to assure product

integrity in computer system and software development.

Auditing increases software visibility and establishes tractability. It

helps to avoid costly redesign and refits. The developers and customer are

able to use the audits to agree on what has been designed and built.

STATUS REPORTING

Software Configuration status reporting is the record keeping activity

of software configuration management. From the time the first SCI were

identified, all changes and current status of changes and documents are

recorded in a status accounting database. The records in the database

provide management with reports as to the current state of the project. At

any time a “snap shot” can be seen of the system‟s progress.

The configuration status accounting database holds the records

showing the product history, how the product has evolved, and where the


of 28


system is at any time in relation to the current baseline. Administration

uses status accounting to track and report on all SCIs formally identified

and controlled. The status accounting database also records to support SCM

auditing.

Due to the large amount of complex data that status accounting

tracks; it is generally supported by automated processes.

The generating of status accounting reports makes it possible for

management and the developers to appraise changes to the system. The

reports allow people to better communicate by letting them see what others

have and how things have changed in the system.

SCM STANDARDS

Before any SCM tool is decided upon for the project, all local

configuration management requirements should be determined first. The

complexity of the requirements will help to determine the type of tool, or

tools that the project will require.

Capabilities of a Good SCM Tool

A good SCM tool should have the following capabilities:

Manage versions throughout the development life cycle.

Guarantee integrity of items.

Support and manage concurrent development

Allow identification of all components that comprise a particular

change or version release.

Provide automated version building capabilities.

Provide audit facilities and reporting tools.

There are dozens of tools vendors to choose from the choice of tool will

depend entirely upon the project‟s needs. SCM Tools have been developed to

support the entire project lifecycle as well as specific parts of the

development process.

Importance of SCM Tools

The important tools of software configuration management are:

DBMS with a data dictionary

OMS (Object Management System)

Version Tracker

Consistency Controllers

System Build Tools


of 28


Here, the first two SCM tools, namely, DBMS with Data Dictionary and

OMS, can be used throughout the project life cycle whereas the last three,

namely, Version Trackers, Consistency Controllers, and System Build Tools

support specific parts of development life cycle.

DBMS with a data dictionary

An important tool for software configuration management is a

database management system with a data dictionary, such a system can be

used throughout the projects lifecycles, and helps maintain consistency and

integrity between the configuration items in the project.

Object Management System

Tools such as ECLIPSE‟s Object Management System (OMS) maintain

object hierarchies and record changes and transformation to the objects in

the system. OMS provides traceability of SCIs throughput their lifecycles.

Tools such as OMS are used for the entire lifecycle.

Consistency Controllers

Consistency controllers are used to ensure that the object code

corresponds to the source code. The dependencies amount files are recorded

so that when the source code is changed the corresponding object code is

recreated. These tools complement the version control tools.

System Build Tools

System build tools are used to set the dependencies between

components. They dictate how the project is built from the components.

They are a form of „make file‟. Build tools help to maintain consistency when

components are being linked together.

A project may have a system library. This is a repository for all

documents, code, changes, development tools, test and results, and versions

if the projects. It uses security measures to prevent unauthorized changes.

It provides many, or all, of the functions described in the tools above. It also

archives all the information that is important to the project. This data can

then be used after the project is finished to do a post analysis of the project.

One of the important system built tools in MAKE:

MAKE is a system building tool that maintains the

correspondence between source code and object code version of

a system.


of 28


It automatically re-complies source code that has been modified

after the creation date of the associated object code. The user

must described the system structure in terms if the files were

components are stored.

Sometimes, changing one file also necessitates changing some

other file or group of files. MAKE provides a mechanism for

specifying file dependencies.

One the tools have been selected the automation process should be

introduced to the organization in a non-instructive manner. The tools

should not be a burden for the developers to use.

Here is a list of some standards that are used:

IEEE 828-1990 Standard for Software CM Plans

IEEE 1042-1990 Guide for Software Configuration Management

MIL-973 DoD configuration Management Standard.

2.3 REVIEWS AND AUDITS:

Software Reviews

- Formal Technical Reviews - The Review Meeting

- Review Reporting and Record Keeping - Review Guidelines

SOFTWARE REVIEWS

What is software reviews?

- a “filter” for the software engineering process. Purpose: serves to uncover errors in analysis, design, coding, and testing. Why software reviews?

- To err is human - Easy to catch the errors in engineers‟ work A review --> a way to

- identify the needed improvements of the parts in a product - confirm the improvement parts of a product.

- achieve technical work of more uniform, predicable, and manageable. Different types of reviews:

- Informal reviews:

Informal meeting and informal desk checking


of 28


- Formal reviews: (design to an audience of customers, management,

and staff)

Walkthrough, inspection, and round-robin reviews

The terms “defect” and “fault” are synonymous --> Quality problems found after software release Software “error”

refers to a quality problem found by engineers before software release

Formal Technical Reviews (FTR)

Objectives of FTR:

- To uncover errors in function, logic, or implementation

- To verify the software under review meets its requirements

- To ensure that the software has been represented according to

predefined standards

- To develop software in a uniform manner

- To make projects more manageable

Purposes of FTR:

- serves as a training ground for junior engineers

- promote backup and continuity

Review meeting‟s constraints:

- 3-5 people involved in a review

- advanced preparation (no more than 2 hours for each person)

- the duration of the review meeting should be less than 2 hours

- focus on a specific part of a software product

People involved in a review meeting:

- producer, review leader, 2 or 3 reviewers (one of them is recorder)

Formal Technical Review Meeting

The preparation of a review meeting:

- a meeting agenda and schedule (by review leader)

- review material and distribution (by the producer)

- review in advance (by reviewers)

Review meeting results:

- a review issues list

- a simple review summary report (called meeting minutes)

- meeting decisions:

- accept the work product w/o further modification

- reject the work product due to errors

- accept the work under conditions (such as change and


of 28


review)

- sign-off sheet

Review summary report (a project historical record) answers the following

questions:

- what was reviewed?

- who reviewed it?

- what were the findings and conclusions

Review issues list serves two purposes:

- to identify problem areas in the project

- to serve as an action item checklist (a follow-up procedure is

needed)

Review Guidelines (for FTR)

A minimum set of guidelines for FTR:

- Review the product, not the producer

- Set an agenda and maintain it

- Limit debate and rebuttal

- Enunciate problem areas, but don‟t attempt to solve every

problem noted

- Take written notes

- Limit the number of participants and insist upon advance

preparation

- Develop a checklist for each work product that is likely to be

reviewed

- Allocate resources and time schedule for FTRs

- Conduct meaningful training for all reviewers

- Review your early reviews

Example by the Binac Team for Review & Audit

Purpose

All documentation and software produced by the Binac team reflects

Binac's commitment to quality. This section of the SQAP specifies how Binac

will ensure the quality of the entire product, as well as when audits and

reviews will be performed.

The SQA group ensures the product is on the track. When the

technical group has completed a phase, members of the SQA group must

check if the product can satisfy the customer's constraints. The process of


of 28


the audit is proceeded when any diversion is produced from the original

constrains. The differences are recorded in PPRs and corrections are tested

by the SQA group.

Minimum Requirements

1. SQAP - Software Quality Assurance Plan

The entire Binac team shall informally review the SQAP. Any

adjustments to the document shall be made by its authors. Once all the

adjustments have been made, the SQAP authors and the lead engineer shall

approve the final document.

Software Quality Assurance Plan (SQAP) is created to explicitly

describes the guidelines the team Favor Mark will follow in order to

guarantee a quality software engineering processing. The document provides

a criterion for all elements of the team's work to ensure all work is

consistent and traceable.

2. SRS - Software Requirements Specification

The SRS authors shall informally review the SRS. After the SRS

authors makes any needed changes, the entire Binac team shall then

formally review the SRS. Once the SRS authors make the requested

adjustments, the SRS authors shall submit the document to the client for

final approval.

Software Requirement Specification (SRS) describes the requirements

of a software product from the customer's point of view. It specifies the

required behavior of a system in term of input data, output data, required

processing and interfaces.

3. SDD - Software Design Document

The SDD authors shall informally review the SDD. After the SDD

authors makes any needed changes, the entire Binac team shall then

formally review the SDD. Once the SDD authors make the requested

adjustments, the SDD authors shall submit the document to the director for

final approval.

Software Design Document (SDD) is a software design model

consisting of four different but interrelated activities: data design, interface

design, procedural design, and architectural design.


of 28


4. PPR - Project Problem Reports

The PPR coordinator shall assign PPR's to the engineer who is

responsible for the code or document in which the problem resides. Once

the problem is fixed by that engineer, the PPR coordinator shall then submit

it to the testing group for follow up testing. When the testing group decides

the problem is fixed, they shall notify the PPR coordinator, who shall then

close the problem.

Project Problem Report (PPR) describes the deviations between the

customer's constrains and designs. The SQA group reports the differences

and tests the corrections

5. STP - Software Test Plan

The STP authors shall informally review the STP. After the STP

authors make any needed changes, the entire Binac team shall formally

review the STP. Once the STP authors make the requested adjustments, the

they will submit the document to the director for final approval.

Software Testing Plan (STP) is to guide all testing activities. It defines

all designs have to be tested.

6. Source Code

The lead engineer shall assign each software developer to code a

module. The coding auditor shall edit all source code based on Binac's

Coding Standards. In addition, code quality checks shall also be subject to

any pertinent requirements specified in the STP.

7. Project builds

Any testing requirements for the project's builds shall be detailed in

the STP

8. SUM - Software User's Manual

The SUM authors shall informally review the SUM. After the SUM

authors make any needed changes, the entire Binac team shall formally

review the SUM. Once the SUM authors make the requested adjustments,

the they shall submit the SUM to the director for final approval.

Software User Manual (SUM) is a document describing how to use the

FavorMark software product


of 28


Other

Other documents that are not directly related to the quality of the

product, but that still need to be reviewed, are listed here:

1. PMP - Project Management Plan

The PMP authors shall informally review the PMP. They shall then

make any adjustments to the document that they feel are necessary. Once

all the adjustments have been made, the final PMP shall be approved by the

PMP authors and the lead engineer.

Project Management Plan (PMP) is planned by the group leader. This

document includes development and coordination of project work scope,

setting schedules, establishing resource estimate plans.

2. SCMP - Software Configuration Management Plan

The SCMP authors shall informally review the SCMP. They shall then

make any adjustments to the document that they feel are necessary. Once

all the adjustments have been made, the final SCMP shall be approved by

the SCMP authors and the lead engineer.

Software Control Management Plan (SCMP)is a detail plan provided to

monitor the all phases of the FavorMark developing. It requires all group

members have to follow the schedule so that the software product can be

delivered on time.

3. Weekly status reports:

Every week, each team member shall approve the Weekly Status

Report.

4. Master/Weekly Schedule:

Each team member shall review the Weekly Schedule on a week to

week basis.

2.4 ENTERPRISE RESOURCE PLANNING SOFTWARE.

What is ERP?

o ERP is an abbreviation for Enterprise Resource Planning and

means, the techniques and concepts for integrated management

of businesses as a whole from the viewpoint of the effective use


of 28


of management resources to improve the efficiency of enterprise

management.

o ERP packages are integrated (covering all business functions)

software packages that support the ERP concepts.

o ERP software is a mirror image of the major business process of

an organization, such as customer order fulfillment and

manufacturing.

o ERP integrates all business functions into a single, integrated

software program that runs on a single database so that the

various departments can more easily share information and

communicate with each other.

o The integrated approach of ERP has tremendous power and

potential in improving the efficiency, productivity, and

competitiveness of the organization.

Common Myths about ERP

1. ERP means more work and procedures.

2. ERP will make many employees redundant and jobless

3. ERP is the sole responsibility of the management

4. ERP is just for the managers/decision-makers

5. ERP is just for manufacturing organizations

6. ERP is just for the ERP implementation team

7. ERP slows down the organization

8. ERP is just to impress customers

9. ERP packages will take care of every thing

10. One ERP package will suit everybody

11. ERP is very expensive

12. Organization can succeed without ERP

History of ERP

Origins in the manufacturing industry

1960‟s – Inventory and control systems

1970‟s- Material Requirement Planning (MRP) and Closed-loop

MRP

1980‟s – Manufacturing Requirements Planning (MRP II)

1990‟s – Enterprise Resource Planning (ERP_

21st Century- ERP II


of 28


Inventory Management and Control

Inventory management and control is the combination of information

technology and business process of maintaining the appropriate level of

stock in a warehouse.

The activities of inventory management include identifying inventory

requirements, setting targets, providing replenishment techniques and

options, monitoring items usages, reconciling the inventory balances, and

reporting inventory status.

Material Requirement Planning (MRP)

o Outgrowth of bill of material (BOM) processing

o Uses the master production (MPS) to find out what products are

going to manufactured.

o Gets the details of the materials required to make the products

from the bill of materials (BOM).

o Searches the inventory records to find out what items are in

stock.

o Calculate the items that need to be purchases for producing the

goods.

o MRP solves manufacturing and production planning problems

and made manufacturing of goods easier.

Closed-loop MRP

o Merger of capacity planning techniques with MRP

o Tools developed to support the planning of sales and production

levels, development of production schedules, forecasting, sales

planning, capacity planning and order processing.

o Various plant, production, and supplier scheduling techniques

for automating the process inside and outside the organization,

were built into the MRP system to create the closed-loop MRP.

o Closed-loop MRP is a series of functions for automating the

production process.

o It contains tools and techniques to address both priority and

capacity and supports both planning and execution.

Manufacturing Resource Planning (MRP II)

o Evolved from closed-loop MRP

o Contains additional capabilities like sales and operational

planning, financial interface and simulation capabilities for

better decision-making.


of 28


o MRP II is a method for the effective planning of all the resources

of a manufacturing company.

o Utilizes software applications for coordinating manufacturing

process, from product planning, parts purchasing, inventory

control to product distribution.

Enterprise Resource Planning (ERP)

o Fundamentals of ERP are the same as that of MRP II.

o ERP is broader in scope and is capable of dealing with more

business functions and has a better and tighter integration with

the finance and accounting functions.

o ERP is an enterprise-wide set of forecasting, planning and

scheduling tools, which links customers and suppliers into a

complete supply chain.

o The goals of ERP include high levels of customer service,

improved productivity, cost reduction, better inventory turnover

(just-in-time inventory), etc.

o ERP is more powerful because it applies a single set of

resources planning tools across the entire enterprise, provides

real-time integration of sales, operating and financial data and

connects resource planning approaches, to the extended supply

chain of customer and suppliers.

Reasons for the Growth of ERP

o ERP improves business performance – cycle time reduction,

inventory reduction, faster response times, streamlined and faster

order fulfillment, etc.,

o ERP supports business growth requirements like new products,

product lines, customers, multiple languages and multiple

currency support, etc.,

o ERP provides flexible, integrated, real-time decision support

o ERP eliminates limitations in the legacy systems

o ERP takes advantage of the untapped mid-market of medium-sized

organization.

Advantages of ERP

Business Integration – ERP packages integrates the information

processing and automates data updating (automatic data exchange among

applications) between related business components.


of 28


Flexibility – Diverse multinational environments such as language,

currency, accounting standards, etc. are covered in one system, which

makes the ERP systems very flexible.

Better analysis and planning capabilities- ERP system enables the

comprehensive and unified management of related business and its data.

This unification makes it possible to fully utilize many types of decision

support systems and simulation functions.

Use of latest technology - ERP vendors uses the latest developments

in the field of information technology. This technology adoption benefits the

organizations using the packages as they get better products and with better

capabilities.

Why ERP?

o ERP offers solutions for business functions

o Packages available for organizations of all sizes and types

o Global nature (multi-lingual and multi-currency support)

Over Expectations about ERP (One of the main reasons for failed

implementations)

o Conduct Gap analysis to find out company requirements and the

functions a package possesses.

o Select the right package

o Select employees with the right attitude for implementation team

o Ensure that knowledge transfer happen between consultants and

employees as well as between vendors and employees.

o Ensure that there is enough in house consultants and integrators

during operation and maintenance phase.

Unit II Software Testing and Quality Assurance

Education

Transcript of Unit II Software Testing and Quality Assurance