Focus on Process Standards

1
Focus on Process Standards

• CFICSE 2002 ST02
• Michelle L. Crane

2
References

• James W. Moore, Software Engineering Standards A
  Users Road Map, IEEE Computer Society, 1998.

3
Outline

• how to create a standard
• scope of SWE standards
• application of standards
• contexts of SWE standards
• life cycle standards
• history
• levels of process abstraction
• assessment methods
• standards we will love

4
How To Create a Standard

• varies widely by standards body
• typically
• establish strategy
• form small working groups
• create draft
• distribute draft
• revise draft
• built test implementation
• revise draft
• implement and enforce standard
• evaluate effectiveness
• periodically update, revise, retire

5
Scope of SWE Standards
Reference Moore, p.7, from Magee97
6
Application of Standards

• voluntary
• organization decides to adopt a standard
• regulatory
• imposed by processes similar to law
• mandated
• e.g., military standards required as a
  precondition of doing business with a dominant
  customer

Reference Moore, p.8
7
Contexts of SWE Standards

• relate software engineering standards to
  different contexts
• computer science
• quality management
• project management
• systems engineering
• dependability
• safety
• resources
• products
• customers
• processes

8
Computer Science Context

• most computer science standards are outside the
  area of software engineering
• language design
• operating system design
• communications
• all described in non-SWE standards
• SWE standards relating to computer science are in
  the areas of
• terminology
• relatively low-level techniques

Reference Moore, p.93
9
Quality Management Context

• two ways to view quality
• presume that product quality will be the natural
  result of developing strong quality management
  and quality assurance systems (ISO 9000)
• process-based view of the organization
• a well-defined engineering process is more likely
  to create high-quality products than a poorly
  defined one
• directly define and measure product quality
  characteristics (discussed under product context)

Reference Moore, p.97
10
Project Management Context

• project management
• system of management procedures, practices,
  technologies, skill, and experience applied to
  managing an engineering project
• applicable standards relate to
• project management body of knowledge
• software engineering measurement
• configuration management
• software engineering plans

Reference Moore, p.111
11
Systems Engineering Context

• some systems engineering standards are
  appropriate for usage in software-intensive
  projects
• topics such as systems engineering, system life
  cycle processes
• some standards are relevant to SWE and systems
  engineering
• topics such as guides for concept of operations
  documents, architectural description, developing
  system requirements
• some SWE standards have a relationship to systems
  standards
• topics such as software life cycle processes,
  life cycle data, implementation considerations

Reference Moore, p.121
12
Dependability Context

• dependability
• collective term for product characteristics that
  encompass
• all aspects of availability performance
• and its factors of
• reliability performance,
• maintainability performance, and
• maintenance support processes
• term is deliberately non-quantitative
• responsibility for dependability shared between
  supplier and customer

Reference Moore, p.131
13
Dependability Context (contd)

• dependability standards cover such areas as
• vocabulary
• dependability programme management
• software aspects of dependability
• risk analysis techniques
• system and software integrity levels
• software reliability
• verification and validation plans
• classification of anomalies
• software quality metrics

Reference Moore, p.131
14
Safety Context

• safety standards traditionally written for
  application to specific industry sectors by
  standards groups representing those sectors
• debate about whether or not it is appropriate to
  attempt to develop generic software safety
  standards
• some standards are more amenable to
  generalizations, covering topics such as
• hazard analysis
• functional safety (safety management, safety life
  cycle, safety assessment)

Reference Moore, p.143
15
Resources Context

• resources (or technologies) are used in the
  execution of processes to develop products on
  behalf of customers
• topics such as
• terminology and taxonomy
• notations
• e.g., how to draw state transition diagrams
• techniques
• e.g., classification of anomalies
• process information products
• e.g., software test documentation, requirements
  specification
• reuses libraries
• tools
• e.g., CASE tools

Reference Moore, p.161
16
Products Context

• a few standards actually deal with software as a
  product
• topics such as
• product evaluation
• metrics
• product characteristics
• packaging a product (making it marketable)
• user documentation, quality requirements and
  testing
• software functionality
• requirements specification
• product quality
• quality assurance plans, VV, safety

Reference Moore, p.177
17
Customers Context

• software engineering activities are performed as
  a result of an agreement with a customer
• can also look at standards from different
  perspectives
• acquirer
• e.g., life cycle processes, software acquisition
  recommended practices, documentation
• systems engineers
• software must be placed within the context of a
  system (at least a processor)
• e.g., system engineering, software safety, life
  cycle
• stakeholders
• those with an interest in the productive
  deployment of software should be able to
  participate
• e.g., concept of operations documents,
  architectural descriptions

Reference Moore, p.1
18
Processes Context

• process is receiving the most attention
• implementation of a sound software development
  process is strongly correlated with the
  production of high-quality software
• focus of the standards we will cover

Reference Moore, p.187
19
History of Life Cycle Standards
20
History

• 1970 Winston Royce wrote a paper recognizing
  that some crucial aspects of software development
  had to be rigorously defined and enforced
• suggested that it was possible to organize
  software development as a series of phases with
  staged objectives rather than following the
  simple-minded code and fix cycle
• managers leapt on the model and called it
  waterfall
• since then, emphasis has been broadened and
  placed on a disciplined, procedural approach to
  the overall processes for software development,
  including maintenance and operation

Reference Moore, p.187
21
History (contd)

• available standards focus on singular processes
  and life cycle frameworks
• 70s 80s proliferation of life cycle
  definitions and standards
• mostly adding details to the waterfall model
• numerous military, regulatory, commercial, and
  standards organizations wrote life cycle
  standards that were similar yet different

Reference Moore, p.188
22
US Defense Life Cycle Standards
Mil-Std 1679
Reference Moore, Figure 33, p.189
23
US Defense Life Cycle Standards
Mil-Std 1679
DoD-Std 2167
DoD-Std 2167A
EIA/IEEE J-Std-016
NSA 1703
Reference Moore, Figure 33, p.189
24
Commercial Life Cycle Standards
IEEE Std 1074
2001 ISO/IEC 12207
ISO/IEC 12207
IEEE/EIA Std 12207
Reference Moore, Figure 34, p.191
25
Levels of Process Abstraction
26
Levels of Process Abstraction

• different standards present their views of
  desired processes at different levels of
  abstraction
• three levels of abstraction in representing
  processes
• reference level
• representing agents that carry out the processes
• conceptual level
• representing the flow of control and data among
  the agents
• implementation level
• representing the implementation, both technical
  and organizational, of the agents and their
  interfaces
• these levels are not successive functional
  decompositions

Reference Moore, p.192
27
Processes are not Procedures

• processes described in the standards are not a
  series of steps (procedures) to be performed
• they are assignments of continuing
  responsibilities which persist for the duration
  of the life cycle

Reference Moore, p.193
28
Reference Level

• representing agents that carry out the processes
• decisions represented at this level are the
  selection of a coherent and cohesive set of
  activities that may be sensibly performed by a
  single agent
• such a set of activities is a process

Reference Moore, p.192
29
Conceptual Level

• representing the flow of control and data among
  the agents
• decisions at this level include the logical
  relationships among the agents both for control
  and for communication of data

Reference Moore, p.192
30
Implementation Level

• representing the implementation, both technical
  and organizational, of the agents and their
  interfaces
• decisions at this level include
• mapping the agents to the management organization
  of the particular project or enterprise and
• the selection of policies, procedures, and tools
  to enable the agents to perform their tasks

Reference Moore, p.192
31
More About the Levels

• not to be seen as functional decomposition, i.e.,
  reference level is not broken down into
  conceptual level, etc.
• any level can be refined into greater detail

Reference Level
Conceptual Level
Implementation Level
Reference Moore, p.192
32
Where Process Standards Fit
Reference Moore, p.194
33
Assessment Methods
34
Software Process Assessment Methods

• starting 1985, increased interest in both
• software process improvement (e.g., CMM)
• quality process improvement (e.g., ISO 9000)
• but now have a convergence of the two interests
• look at a few major assessment models and methods
• TickIT
• SEI CMM
• Trillium
• Bootstrap

35
TickIT

• grew from 1980s initiative by the United
  Kingdoms Department of Trade and Industry and
  the British Computer Society
• provide guidance
• construction and assessment of software
  development and maintenance process
• that meet the requirements for certification
  under ISO 9001 and ISO 9000-3

Reference Moore, p.225
36
SEI CMM

• probably best known software process assessment
  approach in US
• discussed in depth in other lectures
• only coincidental correlation with ISO 9001
• study suggests that some level 1 organizations
  might qualify for ISO 9001, but some level 3
  might not!

Reference Moore, p.226
37
Trillium

• developed by Bell Canada and partners
• to assess the development and support
  capabilities of prospective suppliers of
  telecommunications and related information
  technology products
• model being extended to address management
  information systems
• maybe even to hardware development, as well as
  manufacturing and service capabilities
• largely based on version 1.1 of CMM, additional
  practices added from ISO 9001, ISO 9000-3, and
  others

Reference Moore, p.226
38
Bootstrap

• developed by the European Esprit consortium in
  1993
• provide a mutually satisfactory method for
  software process and improvement
• version 1.0 of CMM was enhanced and refined
• material added to address quality guidelines of
  ISO 9000, among others
• intended for both software developers and their
  projects
• instead of focusing on levels of maturity,
  Bootstrap provides a quality profile indicating
  strengths and weaknesses in various areas finer
  grained analysis

Reference Moore, p.227
39
Standards We Will Love
40
Standards We Will Love
DoD-Std 2167A
SW CMM
EIA/IEEE J-Std-016
Mil-Std 498
IEEE/EIA Std 12207
ISO 9000 series
ISO/IEC 12207
Reference http//www.software.org/quagmire/
41
Summary

• how to create a standard
• scope of SWE standards
• application of standards
• contexts of SWE standards
• life cycle standards
• history
• levels of process abstraction
• assessment methods
• standards we will love

42
?