Systems V & V, Quality and Standards

Dr Sita Ramakrishnan School CSSE Monash University

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

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

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

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

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

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