1. 1 Systems V & V, Quality and Standards Dr Sita Ramakrishnan School CSSE Monash University

2. © S Ramakrishnan2 Software Standards zA Software Standard prescribes ymethods yrules and ypractices used during software development yMakes 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

3. © S Ramakrishnan3 Software Standards xSources 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)

4. © S Ramakrishnan4 Software Standards xIEEE 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 xISO standard (ISO6593) covers design & description xISO 9127 - documentation xISO 9000 series - software quality management xANSI works with IEEE in developing industrial SE Standards

5. © S Ramakrishnan5 Software Standards xDoD publishes military standards for software DoD Std. 2167 - SDLC model for embedded systems xObject 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

6. © S Ramakrishnan6 Software Requirement Specification Standard xSRS Std (IEEE Std. 830-1993) - description of a particular software product or programs that provides a set of functionality in a target environment xIn 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,… xRefer to IEEE std 830-1993 for details xRefer to Text by J F Peters & W Pedrycz - Software Engineering - An Engineering Approach Chapter 5

7. © S Ramakrishnan7 Software Life Cycle Process, Software Configuration Management Software Project Management Plans xIEEE SDLC Process Std (IEEE 1074-1995) - 3 main processes in SDLC process are: requirements, design & implementation xSoftware 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 xIEEE Std. 1058.1-1987 - Std for project management plans xRefer to Text by J F Peters & W Pedrycz - Software Engineering - An Engineering Approach Chapter 3-5

8. © S Ramakrishnan8 Software Reliability measures xNonbehavioural 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 xReliability - 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 xAim 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

9. © S Ramakrishnan9 Software Reliability measures xIEEE Std 982.2-1988 - IEEE Guide for the use of IEEE Standard dictionary of measures to produce reliable software xAt the requirement level, a standard for fault density & defect density can be set for a software project, xeg: 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 x( See chapter 5 for measures for computing these densities)

10. © S Ramakrishnan10 Software Design Elaboration xSteps 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 xImplementation process has 4 main tasks: selection of test data based on test plan design elaboration (coding) V&V and Integration xImplementation process mirrors the recommendations of the two stds - IEEE Std 1077-1995 & ISO 9000-3-1992

11. © S Ramakrishnan11 Software Design: Validation & Risk analysis xIEEE 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

12. © S Ramakrishnan12 Software Design: Validation & Risk analysis xEvaluate consistency of design - how design meets stds requirements can be done by checking how closely a design process follows a prescribed standard such as xIEEE Recommended practice for software design description - IEEE Std 1016-1987, and xIEEE Std 1016.1-1993 - IEEE Guide to Software Design description xRisk engineering - IEEE Std 1074-1995 SDLC xIEEE Std 1044-1993 - IEEE Std classification for software anomalies - project risk explained in terms of an appraisal of risk relative to software defects & enhancements