Systems V & V, Quality
and Standards
Dr Sita Ramakrishnan
School CSSE
Monash University
1
Software Standards
A Software Standard prescribes
methods
rules and
practices
used during software development
Makes it easier to measure the size, quality,
content etc of the software entity because of
the commonality of terms and methods used
in the creation of the product
© S Ramakrishnan
2
Software Standards
Sources of Software Engineering Standards
• The Institution of Electrical & Electronic Engineers
(IEEE)
• International Standards Organisation (ISO)
• North Atlantic Treaty Organisation (NATO)
• American National Standards Institute (ANSI)
• U.S. Department of Defence (DOD)
• British Standards Institute (BS)
• Object Management Group (OMG)
• Common Request Object Broker Architecture (CORBA)
© S Ramakrishnan
3
Software Standards
IEEE publishes software development standards regularly
• e.g. IEEE Std.380-1993 is the recommended practice for
SRS (Software Requirements Spec.)
– describes both the content & quality of a spec
– provides uniform method for describing the
functional & non-functional (behavioural & quality
aspects)of a software product
ISO standard (ISO6593) covers design & description
ISO 9127 - documentation
ISO 9000 series - software quality management
ANSI works with IEEE in developing industrial SE Standards
© S Ramakrishnan
4
Software Standards
DoD publishes military standards for software
• DoD Std. 2167 - SDLC model for embedded systems
Object Management Group (OMG) http://www.omg.org
• Common Request Object Broker Architecture (CORBA) was
created by OMG
• OMG produce and maintain a suite of specifications that
support distributed, heterogeneous software development
projects from analysis and design through coding, deployment,
runtime, and maintenance.
• OMG Spec. - MDA, UML, MOF, XMI, CWM, CORBA
(http://www.omg.org/gettingstarted/overview.htm )
• CORBA - OMG specification for application interoperability
independent of platform, operating system & programming
language
© S Ramakrishnan
5
Software Requirement
Specification Standard
SRS Std (IEEE Std. 830-1993) - description of a particular
software product or programs that provides a set of
functionality in a target environment
In coming up with an SRS, requirements engineer focusses
on: functionality, external interfaces, performance,
constraints re: budget, platform, quality stds etc, and
attributes such as portability, correctness, traceability,
maintainability, security,…
Refer to IEEE std 830-1993 for details
Refer to Text by J F Peters & W Pedrycz - Software
Engineering - An Engineering Approach Chapter 5
© S Ramakrishnan
6
Software Life Cycle Process,
Software Configuration Management
Software Project Management Plans
IEEE SDLC Process Std (IEEE 1074-1995) - 3 main
processes in SDLC process are: requirements, design &
implementation
Software Configuration management (SCM) tool is used to
create, control and maintain repositories of software project
documents and figures.
• Well planned Projects make use of tools such as the project
evaluation technique/critical path method (PERT) network
diagrams & Gantt time allocation charts. Audit trail reports
relate to milestones in planning charts. Plannning charts give
Proj mgmt team tools for tracking developers’ progress - Have
become an accepted aspect of SCM auditing - IEEE 1042-1987
IEEE Std. 1058.1-1987 - Std for project management plans
Refer to Text by J F Peters & W Pedrycz - Software
Engineering - An Engineering
Approach Chapter 3-5
© S Ramakrishnan
7
Software Reliability measures
Nonbehavioural features in an SRS specifies attributes such
as: reliability, reusability, portability, maintainability,
availability, security & standards compliance - detailed
enough spec. to help developers design & implement
systems that meet the requirements & to validate products
of the SDLC process
Reliability - indicator of operational readiness of a system IEEE STd. 982. 1-1998
• key to software relaibility improvement -> accurate history of
errors, faults & defects associated with software failures
Aim of an effective software process -> to track cause of
failures. Eg. of measures of reliable software are fault
density & defect density given in IEEE Std. 982.2-1988
© S Ramakrishnan
8
Software Reliability measures
IEEE Std 982.2-1988 - IEEE Guide for the use of IEEE
Standard dictionary of measures to produce reliable software
At the requirement level, a standard for fault density &
defect density can be set for a software project,
eg: 4 faults/1000 lines of source code & 6 defects per 1000
lines of design code - can be used to compare against actual
densities with set (required) densities
( See chapter 5 for measures for computing these densities)
© S Ramakrishnan
9
Software Design Elaboration
Steps in elaborating a design compromise -> Design
elaboration phase - is known as implementation process in
IEEE Std 1077-1995 (SDLC Process) and ISO 9000-3-1992
Implementation process has 4 main tasks:
• selection of test data based on test plan
• design elaboration (coding)
• V&V and Integration
Implementation process mirrors the recommendations of
the two stds - IEEE Std 1077-1995 & ISO 9000-3-1992
© S Ramakrishnan
10
Software Design:
Validation & Risk analysis
IEEE Standard for Software V&V Plans - IEEE Std 1012-1986
has 5 parts:
1. traceability analysis - trace software design to SRS identify relationships for consistency, completeness,
correctness, accuracy
2. design evaluation - evaluate attributes given in (1) plus
quality standards & practices in design
3. Interface analysis - analyse data at interface for
consistency, completeness, correctness, accuracy
4. Test plan generation
5. Test design generation
© S Ramakrishnan
11
Software Design:
Validation & Risk analysis
Evaluate consistency of design - how design meets stds
requirements can be done by checking how closely a design
process follows a prescribed standard such as
IEEE Recommended practice for software design description
- IEEE Std 1016-1987, and
IEEE Std 1016.1-1993 - IEEE Guide to Software Design
description
Risk engineering - IEEE Std 1074-1995 SDLC
IEEE Std 1044-1993 - IEEE Std classification for software
anomalies - project risk explained in terms of an appraisal of
risk relative to software defects & enhancements
© S Ramakrishnan
12