Standards & Practices for the software and system engineers /

Standards & Practices for the

software and system engineers /

professionals

professionals

John Walz [email protected]

IEEE Computer Society 1st _VP

IEEE S ft & S t E i i St d d C itt IEEE Software & Systems Engineering Standards Committee

Systems and Software Technology Conference (SSTC 2009) Wednesday, 22-Apr-09

Objective & Audience

• Advancing the knowledge, practice, and skills of

engineering professionals

engineering professionals

• Software and system engineers & professionals

– Acquisition Professionals

– Program/Project Managers

Programmers

– Programmers

– System Developers

– Systems Engineers

y

g

– Process Engineers

Standards & Practices Abstract

• Cultivate, improve, and deploy

best practices to meet business goals,

ti

l d li

t

ti fi d

t

h

– timely delivery to satisfied customers, whose

payments result in profit margins.

• Practices follow

– defined policies, processes, conventions, and

procedures.

• Practices are influenced by

Practices are influenced by

– HR selection criteria,

– Tool acquisition, and

It

ti

i

t

– Iterative improvements

• Improvement projects start with a gap analysis

Standards & Practices

Practices deal with practitioners’

• skills

• skills,

• work processes, &

work products both created and acquired

• work products, both created and acquired

Work Processes uses Standards for

Work Processes, uses Standards for

• documented process definitions,

• measure definitions, &

Building for Business Success

Improvement Methods Lean Six Sigma

Process Definitions

Management System IDEAL

SM

CMMI®

Practices Measurements

Artifact templates Tools & Techniques

Six Sigma Controls

Records

Life Cycle Model Lean Methods

Process Measures Policies & Procedures

Tower of Babel

St

d d

•

Standards

•

Practices

•

Best Practices,

R

d d P

ti

Recommended Practices,

Generic Practices,

Specific Practices

C

t G

•

Goals, Generic & Specific

•

Processes, Activities, Tasks

•

Frameworks

•

Corporate Governance

Practices,

•

Marketplace Practices,

Enterprise Practices

•

Life Cycle Model

•

Methodology

•

Work Products / Artifacts

Enterprise Practices,

Business Practices,

Software & Systems

Engineering Practices

•

Conformity Assessment

•

Projects, Organizations,

Enterprise, & Industry

Process / Org Mat rit

Engineering Practices

_•

_{Process / Org. Maturity}

Simple Business Model

for Standards and Practices

for Standards and Practices

Std Std

Customer

Talent

Suppliers

Best Practices

Tools

Product improvements require improving

Processes guide stakeholders

through the life cycle

Process

improved

Q

lit

P

l &

Technology

Quality

&

Productivity

People need to be skilled in techniques

People &

Behaviors

Technology,

Tools

y

People need to be skilled in techniques

What is a standard?

• A

standard

• Standards

– Solve product compatibility issues

designed to ensure that a material, product, method, or service meets its purpose and consistently performs to its intended use

– Address consumer safety and health concerns

– Represents consensus expert opinion – Simplify product development and

•

reduce non-value-adding costs – Increase a user's ability to compare

competing products – Provide assurance of

i t ti it d i t bilit

interconnectivity and interoperability and provide credibility of new

products

– Verify new markets thus enabling the rapid implementation of technology

• Standards

What is a Practice?

• (1) an activity that contributes to the purpose or

outcomes of a process or enhances the

p

capability of a process

• (2) requirements employed to prescribe a

disciplined uniform approach to the software

development process

www.computer.org/sevocab

1. ISO/IEC 15504-1:2004 Information technology -- Process assessment

-- Part 1: Concepts and vocabulary, 3.27

2 ISO/IEC 24765 S t d S ft E i i V b l

More Definitions

IEEE, ISO, IEC

• Base practice

CMMI-DEV

• Specific Practices

Base practice

• Generic practice

• Conventions

Specific Practices

• Generic Practices

• Process area

• Methodology

• Life Cycle Model

y

Practices examples

• Football example

– Hole assignments and

g

player numbering is used

to assign who will be the

main ball carrier and

main ball carrier and

where the play will go

– Passing tree is the

Passing tree is the

number system used

for the passing routes

Value of Standards

What is “testing”?

A standard is a

A standard is a

Name

Name

for an

for an

otherwise fuzzy concept

otherwise fuzzy concept

_{otherwise fuzzy concept}

otherwise fuzzy concept

multidimensional

… a standard gives

_{a name to a}

• Practitioners needs standards to assign names to practices or collections of practices. trade space of solutions ...

a name to a

bounded region.

communication between Buyer and Seller

It defines some

characteristics that a

b

t

• Standards represent the “minimum level of

responsible practice” Jim Moore, 2004-03 CSEE&T Panel 7

buyer can count on.

Most successful standard: ISO 9001

• Product is defined as “result of a process”

• Process is defined as “set of interrelated

ocess s de

ed as set o

te e ated

or interacting activities which transforms

inputs into outputs”

pu s

o ou pu s

• “Say what you do and do what you say.”

– Conformance is all about following processes;

Conformance is all about following processes;

– Any tool that enforces some type of process,

will help an organization maintain its

p

g

Model of Engineering

Control

Process

Steps to Success in

software & system engineering

C

li

t P

E

i

i

- Compliant Process Engineering

1 your businessUnderstand 2

Look to Models for Process 3 Look to Framework 4 Look to Supporting

Practical Support for CMMI®-SW Project Documentation: Using IEEE Software Engineering Standards

your business processes

for Process Completeness

3 Framework Standards for Life

Cycle Definition 4 Supporting Standards for Process Detail 5 Build or Refine Your Process Architecture 6 Execute Your Processes 7 Measure Your Results - Modify Processes as Necessary 8 Confirm Your Status With Independent Appraisals Necessary 3 3 3 3 Appraisals

Using IEEE S2E Standards

• Select relevant Software & System

Engineering (

S2E

) processes

Engineering (

S2E

) processes

from Model and Framework,

• Define S2E processes using best

p

g

practices and standards

• Perform gap analysis of S2E processes

g p

y

p

• Improve existing S2E processes,

• Ensure process conformance to Model

Ensure process conformance to Model

(e.g. CMMI

®

Maturity Level, IS 15504,

ISO 9001)

)

What are IEEE S2E Standards?

• Represent

industry best practices

– Codifies industries best practices for all critical

software & system engineering processes and their outputs

y

g

g p

p

– Developed by domain experts with broad expert consensus

• Specify content

p

y

– Provide

detailed procedure explanations

and

offer section by section

guidance

on building the necessary

documentation

– with no recommendation of exact techniques or formats

– Used as tools to help in the painful process of

‘self-documentation’

• Specify the minimum required contents for each

IEEE Std 730, Software Quality Assurance Plans

IEEE Std 828, Software Configuration Management Plans IEEE Std 830, Software Requirements Specifications

IEEE Std 982 1 Dictionary of Measures to Produce Reliable Software IEEE Std 982.1, Dictionary of Measures to Produce Reliable Software IEEE Std 1008, Software Unit Testing

IEEE Std 1012, Software Verification and Validation Plans IEEE Std 1016, Software Design Descriptions

IEEE Std 1028 S ft R i

IEEE

Software & System

IEEE Std 1028, Software Reviews

IEEE Std 1044, Classification for Software Anomalies IEEE Std 1045, Software Productivity Metrics

IEEE Std 1061, Software Quality Metrics Methodology

y

Engineering

Standards

IEEE Std 1062, Software Acquisition

IEEE Std 1074, Developing a Software Project Life Cycle Process IEEE Std 1228 , Software Safety Plans

IEEE Std 1420, Software Reuse

Plus nine other

IEEE standards at the

,

IEEE Std 1471, Architecture Description

IEEE Std 1517, Software Life Cycle Processes—Reuse Processes IEEE Std 1633, Software Reliability

IEEE/ISO/IEC 12207 Software Project Life Cycle Process

software and systems level

IEEE/ISO/IEC 12207, Software Project Life Cycle Process

IEEE/ISO/IEC 12119, Software packages - Quality requirements and testing IEEE/ISO/IEC 14764, Software Life Cycle Processes -- Maintenance

IEEE/ISO/IEC 16326, Software Project Management Plans

IEEE/ISO/IEC 24765 Glossary of Software Engineering Terminology IEEE/ISO/IEC 24765, Glossary of Software Engineering Terminology IEEE/ISO/IEC 26514, Software User Documentation

Framework Standards

Standards are conceptual,

not implemented Practices

not implemented Practices

Standards: a set of mandatory requirements employed and enforced to

prescribe a disciplined uniform approach to software development, that is, prescribe a disciplined uniform approach to software development, that is, mandatory conventions and practices – IS 24765

IS 12207 Software life cycle processes

• 43 S2E Processes with 123 Process Activities

• Purpose provide a defined set of processes to facilitate communication among acquirers suppliers and other stakeholders in the life cycle of a among acquirers, suppliers and other stakeholders in the life cycle of a software product. (1.2)

• An organization would adopt the standard and supplement it with appropriate procedures, practices, tools and policies. (5.1.4)

• Process has purpose and outcomes and consists of multiple activities,

each having multiple tasks (5.2.1)

– Process outcomes are used to demonstrate successful achievement of the purpose of a process (5 2 1)

purpose of a process. (5.2.1) – Distinct forms of a task (5.1.11):

• "Shall" is used to express a provision required for conformance,

• "Should" to express a recommendation among other possibilities, and

• "May" to indicate a course of action permissible within the limits of this standard.

• Life cycle processes and activities are selected and employed in a stage to fulfill the purpose and outcomes of that stage (5.1.12)

IS 12207 6.2.1 Life Cycle Model

Management Process

Management Process

Purpose

•

Define, maintain, and assure availability of policies, life cycle

lif

l

d l

d

d

f

b th

processes, life cycle models, and procedures for use by the

organization

•

Provide life cycle policies, processes, and procedures that are

consistent with the organization's objectives, that are defined,

g

j

,

,

adapted, improved and maintained to support individual project

needs within the context of the organization, and that are capable of

being applied using effective, proven methods and tools.

Outcomes of successful implementation:

Outcomes of successful implementation:

•

a) policies and procedures for the management and deployment of

life cycle models and processes are provided;

•

b) responsibility, accountability and authority for life cycle

t

d fi

d

management are defined;

•

c) life cycle processes, models and procedures for use by the

organization are defined, maintained and improved; and

Software Engineering

Body of Knowledge SWEBOK

Software Requirements

Computer Engineering

8 Related Disciplines

10 Knowledge Areas

Body of Knowledge SWEBOK

Software Requirements

Software Design

Software Construction

Computer Engineering

Computer Science

Management

So

a e Co s uc o

Software Testing

Software Maintenance

g

Mathematics

Project Management

Software Configuration Mgmt

Software Eng. Management

Quality Management

Software Ergonomics

S

t

E

i

i

Software Engineering Process

Software Eng. Tools & Methods

Software Quality

Systems Engineering

Software Quality

Allocation Of IEEE And ISO Software Engineering Standards To

SWEBOK

Knowledge Areas

Knowledge Areas

Knowledge Areas

S

TT

AND

AA

RDS

Standards for S2E Product Realization

Processes guide stakeholders

through the life cycle

Process

Standards Vocabulary

P St d d

Process Standards

S2E Body Of Knowledge

improved

Quality &

Productivity

P

l &

Technology

Certification Standards Tools Standards

Productivity

People need to be skilled in techniques

People &

Behaviors

Technology enables

Technology,

Tools

S2E Project Management & Support

•Quality

•Productivity

• Objectives

•Productivity

•Risk Reduction

j

• People

• Processes

•Degree / Curriculum

•Certifications

• Processes

• Standards / Practices

Certifications

•Sftw Dev Prof - CSDP -IEEE •Sftw Dev Assoc. - CSDA -IEEE •Sftw Quality Engr - CSQE -ASQ

Sft P j M CSPM QAI

•Sftw Prj Mgr - CSPM -QAI •Sftw Prj Mgr - SwPM -SQI

•Project Mgmt Professional -PMI

•Training

•Training

Practitioners Skills related to

S2E Standards

S2E Standards

• Code of Ethics

– . . .

“Sh ll

ti i

t i lif l

l

i

di

th

ti

f

– “Shall participate in lifelong learning regarding the practice of

their profession”

– “Assist colleagues in being fully aware of current standard work

practices”

• Education, based on SWEBOK

– Software Engineering Computing Curricula 2004 (SE2004)

– Curriculum Guidelines for Undergraduate Degree Programs in

S ft

E

i

i

Software Engineering

– Graduate SWE Reference Curriculum (GSwERC)

• Continual education

Courseware based on SWEBOK

– Courseware based on SWEBOK

• Certifications, based on SWEBOK

– CSDP Certified Software Development Professional

CSDA Certified Software Development Associate

– CSDA Certified Software Development Associate

Work Processes

• S2E Processes

– IEEE 15288 System Engineering Processes

IEEE 15288 System Engineering Processes

– IEEE 12207 Software Engineering Processes

– IEEE Software & System Engineering Standards

Collection

• Life Cycle Model of Processes & Artifacts

S

b

100% S

i l

– Spectrum between 100% Sequential vs.

100% Iterative

• Tools: CM PM CASE etc

Tools: CM, PM, CASE, etc

• Workflow

Work Product / Artifact

• Life Cycle Model defines processes,

their relationship and Artifacts

their relationship, and Artifacts

• Definitions from CMMI

®

Work Product is any artifact produced by a process

– Work Product is any artifact produced by a process

– Artifacts can include records, files, documents, parts

of the product, services, processes, specifications,

and invoices

– A key distinction between a work product and a

product component is that a work product need not be

p

p

p

engineered or part of the end product

• Artifacts used for appraisals and audits

S2E Work Products and Records

• Documents and records provide:

– Communications within the team and to stakeholders

– Foundation for improvement

– Evidence of compliance

– Evidence of compliance

• Software & System Engineering organizations

– Have freedom on the format and content of typical

software engineering project documents

– Can chose from several frameworks standards and

Can chose from several frameworks, standards, and

methods to implement and enhance their mission and

value-added services within their company

Design Artifacts from Standards

• Use standards to define:

Use standards to define:

• Match:

– Processes for work flow

– Processes Work Products,

Match:

– Staff,

– Staff credentials,

Content and Format

– Process Records

P j

t Pl

il

t

– Process inputs,

– Process outputs,

– Project Plan milestones

_{– Project milestone,}

– Project & Process &

Configuration records

Configuration records

Improvement requires

Engineering processes to be:

Engineering processes to be:

Hot

Warm

• Well defined,

• Followed and

Neutral

• Followed, and

• Measured

Cool

Cold

Artifact Creation Example:

Software Requirements Specifications (SRS)

q

p

(

)

• IEEE 12207 7.1.2 Software Requirements Analysis

Process

Process

– Calls for SRS

• CMMI-DEV Requirements Development framework

(3 Goals, 9 Practices / 20 pg)

– Calls for SRS

• Software Requirements Specifications (SRS)

Software Requirements Specifications (SRS)

requirements from IEEE 830

• SRS document Outline from IEEE 830 appendix

pp

• SRS document Guidance from best practices

• SRS document Template from best practices

Software Requirements Specifications

A tif

t

Artifact

IEEE Standard 830, Practice for

Software Requirements Specifications

Outlines the requirements for what comprises a good Software

Requirements Specification (SRS):

• Establishes basis for agreement between customers and

suppliers on what the software product is to do

• Reduces the development effort

p

• Provides a basis for estimating costs and schedules

• Provides a baseline for validation and verification

• Facilitates transfer

Conclusions and Recommendations

• Advanced software & systems engineering

management & practices will achieve

g

p

objectives:

quality, productivity, customer

satisfaction

, and

compliance

– Quality outcomes requires Quality Processes

– Quality Processes create useful Artifacts

Formalized Intellectual Property

• Good Techniques / Methods

A ti l

bli h d

ith

i

• Articles published with peer review

• Case studies

• Good Principles

Good Principles

• Best Practices

• Workshops

• Body Of Knowledge

• Standards developed

• Books

• Books

• Collegiate Curriculum

• Certification of experts & organizations

• Licenses

Formalized Intellectual Property

• Technical Council on Software • Webinars

• Technical Council on Software Engineering

• Standards Committee on Software & System Engineering

• IEEE S2E Standards collection

• Webinars

– Right-Sizing Agile Development, Steve McConnell

– Standardizing Your Software Process Improvement Initiatives, by Susan K.

IEEE S2E Standards collection

• Conferences & Proceedings

– SSTC 2009 – Tech Summit 2008 • Publications p , y Land • eBooks (ReadyNotes)

– A Practical Metrics and Measurements Guide for Today’s Software Project Manager by Susan K Land William C

• Publications

– Computer

– IEEE Software

– IT Professional

IEEE Transactions on Software

Manager by Susan K. Land, William C. Hobart Jr., and John W. Walz,

• Books

– The Road Map to Software

Engineering: A Standards-Based Guide – IEEE Transactions on Software

Engineering

• Podcasts

– IEEE Talks Software Process

g g

by James W. Moore

– Practical Support for CMMI-SW

Software Project Documentation: Using IEEE Software Engineering Standards by Susan K Land John W Walz

by Susan K. Land, John W. Walz

• Certification in CSDA / CSDP

– Certified Software Development

Associate

– Certified Software DevelopmentCertified Software Development Professional

References

• CMMI® for Development, Version 1.2, SEI

• Croll04, Croll, P; Eight Steps to Success in CMMI – Compliant Process

Engineering, 16th Annual Systems and Software Technology Conference, 20-Apr-2004

• IEEE Software Engineering Standards Collection • IEEE Software Engineering Standards Collection,

Institute of Electrical and Electronics Engineers, Inc.

• IEEE Standard Glossary of Software Engineering Terminology • IEEE Standard 12207IEEE Standard 12207

• Land06, Land, S.K.; Walz, J.; Practical CMMI Software Process Documentation- Using IEEE Software Engineering Standards, John-Wiley/IEEE Press, Feb 2006

• Land08, Land, S. K.; Real World Application of International Process and IEEE Software and Systems Engineering Standards to Software Process

Improvement Initiatives; SSTC; 30-Apr-08

• Moore J W ; ‘The Role of Process Standards in Process Definition’; • Moore, J.W.; The Role of Process Standards in Process Definition ;

• Moore06, Moore, J.W.; The Road Map to Software Engineering, A Standards-Based Guide, 2006

• SESC93, Long Range Planning Group, Master Plan for Software EngineeringSESC93, Long Range Planning Group, Master Plan for Software Engineering Standards, Version 1.0, 1-Dec-1993

Webinars from IEEE Computer Society

• Similar presentations - CS Webinars series

–

http://www2 computer org/portal/web/webinars

http://www2.computer.org/portal/web/webinars

C ll f

E

t t

t CS W bi

• Call for Experts to create CS Webinars

– contact Debbie Sims

[email protected]

or

Dick Price

dprice@computer org

Acronyms used

• ASQ American Society for Quality

• CASE Computer-Aided S f

• IEEE 15288 Systems Engineering -System life cycle processes

f C f

Software Engineering

• CM Configuration Management • CMMI® _{Capability Maturity}

Model Integrated

• IEEE 12207 Life Cycle Processes for Software Engineering

• IS 15504 ISO/IEC Information Technology — Process Assessment g

• CMMI-DEV® _{CMMI for Development}

• CSDA Certified Software Development Associate

• CSDP Certified Software

• IS 24765 ISO/IEC Software and Systems Engineering Vocabulary

• ISO 9001 Quality management systems -- Requirements

CSDP Certified Software Development Professional

• CSPM Certified Software Project Manager

• CSQE Certified Software

• PM Program Management • PMI Project Manager Institute

• S2E Software & System Engineering

• SRS Software Requirements CSQE Certified Software

Quality Engineer • Engr Engineer

• IDEALSM _{Initiating, Diagnosing,}

Establishing Acting Learning

SRS Software Requirements

Specifications • Std Standard

• SWEBOK Software Engineering Body of Knowledge