IS 556 Fall 2003 1

IS 556 Project Management

Week 7 - Software Development Standards

Readings: On Time Within Budget - Chpt 9

Case: Bell South

David Lash

2David LashCS 556 - Winter

Overview Why use standards What are main standard bodies

IEEE - Institute of Electrical and Electronics Engineers

ISO - International Standards OrganizationDOD - US Department of Defense.

Using Standards

3David LashCS 556 - Winter

Software Development and Standards

A necessary evil? Limit developer freedom One-size-fits all danger

Why create standards? Makes software management manageable Help software developers understand others work E.g., Perl standard will document regular

expressions. if ( /^[01]d/[0123]d/2ddd$/ ) {

if (/^[01]d/ # look for month mm

/[0123]d/ # day mm

/2ddd$/w ) { # Year yy - century

4David LashCS 556 - Winter

Why Standards?Case from Text

Aereola development. XT2000 need new user interface.Estimate between 1.5-2 years to develop4 hot-shot developers propose add-on PC interface

• 2-3 months to develop• temporary until “real” one developed• Cut corners on standard to get done on time.

4 years later user interface not done, no original 4 around

New team created -> No idea of design, missing source, code hacked up.

5David LashCS 556 - Winter

Does that really happen

Maintaining Web-based form packagePackage keeps track of quality records for

inspections. Only 1 developer for 2-3 years. No design, no code reviews, no code controlDevelop leaves company, new person assigned Has to reverse engineer designDiscovers ugly code, f-file based instead of DB. Corrupted form states.

6David LashCS 556 - Winter

Which Standard to Use?

Moore (98) - There are > 300 development standards maintained by > 50 organizations

Most common IEEE - Institute of Electrical and Electronics

Engineers ISO - International Standards Organization DOD - US Department of Defense.

7David LashCS 556 - Winter

IEEEOne of first software engineering standards: 1984

Included 4 development standardsrequirements, quality assurance, testing and configuration

management. Fifth volume later include standard definitions & terms

1999 - 4 volume standards collection Standard can be used for

A recommended practice, A guide, a standard or supplement to standard

1999 volumes (contained 40 standards)Customer and terminologyProcessProduct standardsResource and technique

8David LashCS 556 - Winter

IEEE 1999 SE Stds - Volume 1

IEEE std 610.12-1990 IEEE Standard Glossary of software engineering terminology

IEEE std 1062, 1998 edition IEEE Recommend Practice for Software Engineering

IEEE std 1220, 1998 IEEE Recommend Standard for the application and management of the system engineering process

IEEE std1228-1994 IEEE Stanard for software Safety plans

IEEE std 1233 1998 IEEE Guide for developing systems requirements

IEEE std 1362 – 1992 IEEE Guide for IT – System definition- concept of operations

IEEE std 12207.0-1996 Software life cycle processes

IEEE std 12207.1-1997 Software life cycle processes – life cycle data

IEEE std 12207.2 – 1997 Software life cycle processes – implementation considerations

•Customer and Terminology Standards

•Pages 192-193 list Process standards, product standards and resource and technique standards

9David LashCS 556 - Winter

IEEE Standard Layers

Figure 9.2

10David LashCS 556 - Winter

An example standard - IEEE Std 830

Software Requirements Specification Basic Characteristics Started in 1983 and upgraded many time since

Does each requirement accurately represent the expectation of the customer? (correct)

Is each requirement clear and does it have the same interpretation for all who read it? (unambiguous)

Are all requirements documented, have we ensured that no "verbal" understandings remain? (complete)

Can we prove in a reasonable manner, and at a reasonable expense, that each requirement has been met? (verifiable)

Does any requirement conflict with another requirement? (consistent) In determining future trade-offs, has the relative importance of each

requirement been assigned? (ranked) Is the requirements specification documented in a way that will enable

it to be easily corrected or changed later? (modifiable) Are the origins of each requirement clear (backward traceability), and

can the testing and design documents be later traced to requirements? (forward traceability)

Has the requirement specification been written so that it can be understood not only by the organization writing it, but also by the software maintenance organization? (usable)

Best use for non-evolutionary models.

11David LashCS 556 - Winter

An Example IEEE StandardIEEE 610.12 - Glossary of standard

Terminology Covers 1300 Software Engineering terms:

compilersconfiguration management Operating systemErrors, faults, failuresQuality attributes

Some terms with multiple definitions such as: Quality - 2 separate definitions - 1 related to requirements

another related to customer expectationsPatch - 4 separate definitions

Not the only definition set others include ISOand DOD.

12David LashCS 556 - Winter

IEEE Software lifecycle standards

Std 12207 Purpose: to establish common framework for software life

cycle processes. Contains

software processes, activities and tasks for software acquire, development, operation, support

Centers on 5 views of software lifecycle contract, engineering, operating and maintenance,

supporting processes (E.g., documentation, configuration, q/a) Organizational (management, infrastructure, training)

13David LashCS 556 - Winter

Fig 9.5 STD12207 Software Life Cycle Processes

14David LashCS 556 - Winter

ISO - International Organization for Standards

Initially European body now have world wide membership

ISO members offered to national bodies Bodies apply and adapt standard to country USA is represented by ANSI (American National Standards

Institute)Famous for ISO 9000 - Standard concerned with Quality

Management ISO 9001 – business ranges from design to build to install to

service ISO 9002 – business does not design and develop ISO 9003 – business does testing and inspection

15David LashCS 556 - Winter

ISO vs IEEEStandards are similar to IEEE with differing

terminologyOverall guide is ISO 9000

Software also falls under the 9001-9002 guides depending on company

ISO 9004 describes quality management4 additional volumes of standards define quality

terminology, quality plan standards, configuration management, quality audit plans

ISO 9000 are developed an maintained by technical committee 176

Has been American Society of Q/C (ASQC)

16David LashCS 556 - Winter

IEEE StandardsAdvantages

Flexible - can adapt as needed Standards may be used independently Relatively easy to use - Examples are given

Disadvantages Not used worldwide Allow too much flexibility

Implementers define how they are used

17David LashCS 556 - Winter

ISOAdvantages

Extensive coverage - Cover everything and more Adopted - Many are used by IEEE Detailed - Detailed and not very flexible Acceptance - Wide International acceptance Certification - Adoption can lead to ISO 9000

certificationDisadvantages

More difficult to use - Cover everything and moreDetailed and not very flexibleComplicated

18David LashCS 556 - Winter

DOD and other

Bodies such as DOD, NASA and European Space Agency (ESA) Std 2167A Create own standards for areas consider ill-defined

DOD - An extremely large software customer. Much work done before stnds bodies firmly

established (eary 1980s) Std 2167 - specified software documentation,

reviews. STD2167 supervision toolSTD2167A developer toolEventually became IEEE 12207

19David LashCS 556 - Winter

STD 2167A In 1985 for mission critical defense software systems. A leader until 1998 and IEEE/EIA 12207 adopted.

Objective: establish uniform requirements throughout project lifecycleInclined to phased methodologies such as Waterfall (but

with some difficulty can use others)Data Item descriptions defines project document

standards. E.g., • software development plan, requirements specification, design

document, interface description, version description, test plan, test report, operators manual, users manual, etc.

Review and audit control tools built inwhere decisions are finalized

20David LashCS 556 - Winter

More on STD 2167AMajor baseline (gates)

fucntional baseline - finalizes users view of system allocated baseline - finalizes software requirements Critical design baseline - finalize design product baseline - finalizes the software development

Contractors required to tailor the standarddone by deleting non-applicable items

2167 “issues”Generated a lot of paperworkNot well suited to small projectsBut customer was involvement in process

21David LashCS 556 - Winter

Fig. 9.6 DOD STD 2167A

DOD 2167a software development approach

22David LashCS 556 - Winter

Using Standards

A standard should provide a framework for good practices When practice inefficient should support

replacement Needs to be implemented correctly

Enforcing standard use can be difficult Often requires upper management Need to figure out how to measure if being

used. Expect resistance to change

23David LashCS 556 - Winter

Summary Why use standards What are main standard bodies

IEEE - Institute of Electrical and Electronics Engineers

ISO - International Standards OrganizationDOD - US Department of Defense.

Using Standards