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
Page 1 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.”

Page 2 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.

Page 3 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

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

Page 5 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.

Page 6 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.

Page 7 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

Page 8 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.

Page 9 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

Page 10 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.

Page 11 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

Page 12 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.

Page 13 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.

Page 14 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.

Page 15 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.

Page 16 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

Page 17 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

Page 18 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.

Page 19 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

Page 20 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

Page 21 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

Page 22 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.

Page 23 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

Page 24 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

Page 25 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

Page 26 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.

Page 27 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.

Page 28 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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Unit II Software Testing and Quality Assurance

Ähnlich wie Unit II Software Testing and Quality Assurance (20)

Mehr von VinothkumaR Ramu

Mehr von VinothkumaR Ramu (9)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Unit II Software Testing and Quality Assurance