ISO 9000-3 Digest Thursday, 20 March 1997 Volume 01 : Number 042
In this issue:
ADVERT: New, cool QUALITY.ORG "CyberQ" teeshirts!
ADVERT: FYI: web site (fwd)
ADVERT: FYI: web site (fwd)
A serial mini-survey (No.6)
re: SW Acquisition CMM courses from SEI (fwd)
A serial mini-survey (No.7)
----------------------------------------------------------------------
From: "Bill Casti, CQA (Moderator)"
Date: Tue, 18 Mar 1997 14:01:19 -0500 (GMT-0500)
Subject: ADVERT: New, cool QUALITY.ORG "CyberQ" teeshirts!
NOTE: This is a shameless plug for our new CyberQ teeshirts. It is being
distributed to the subscribers of the email lists supported at
QUALITY.ORG, as well as to those of the one list I moderate. If you're not
interested, just delete the message(s). If you belong to more than one of
those lists, you will get more than one copy of this message. Sorry.
Regards.
Bill
- -----------
The link for the graphics for the front and back of the new teeshirts is now
available near the top of the QUALITY.ORG homepage at
http://www.quality.org/qc
Shirts are $18.00 (in US funds) each (which includes handling & USPS
Priority Mail within the US), in any size from XS to XXXL. Payment must be
in the form of check or money order made payable to me, Bill Casti. Orders
will be placed with the vendor in quantities of not less than 25.
Shipment will not be made until payment is received and the check clears
your bank.
** If you want to get your shirt in time for the ASQC Annual Quality
Congress in Orlando May 5-7, be SURE to get your order and payment into
me NO LATER THAN April 15th. You may place your order by email to:
help@quality.org
but payment must be received before any shipment goes out. Let me know in
your order if you would prefer me to bring your shirt(s) to Orlando.
There will be no reduced--or added--costs for this personal service.
Please review the webpage and place your orders! :)
Thanks for your indulgence!
Bill
=============================================================================
Bill Casti, CQA Email: help@quality.org
- Domain Owner, QUALITY.ORG Pager: +1 800 604 6149
- List Moderator, "TQM in Manufacturing and Service Industries"
- Chairman, Electronic Media
ASQC Section 0511 (Northern VA) Section Email: E-media@quality.org
- Candidate for 1997-98 Chair-elect Position for Section 0511
- Senior Administrator, Internet Systems, Fed. Emergency Mgmt. Agency (FEMA)
- -----------------------------------------------------------------------------
QUALITY RESOURCES ONLINE at: http://www.quality.org/qc
=============================================================================
------------------------------
From: "Bill Casti, CQA (Moderator)"
Date: Tue, 18 Mar 1997 18:12:59 -0500 (GMT-0500)
Subject: ADVERT: FYI: web site (fwd)
NOTE: Respond *only* to the poster's address (see below the dotted line)
or as directed in the posting, but definitely NOT to me.
Thanks.
Bill
- ---------- Forwarded message ----------
Date: Tue, 18 Mar 1997 17:51:26 -0500
From: Mitchell and Company
Subject: web site
For those of you who haven't checked out our new web site yet, we invite you
to visit http://www.fastforward400.com. It's an interactive research project
on how companies can make faster progress by changing the ways we think
about progress. We would appreciate it if you would let us know what you
think of the site and contribute your thoughts. The project is meant to be a
place where people can share their ideas.
Thanks!
Jason
jason@fastforward400.com
------------------------------
From: "Bill Casti, CQA (Moderator)"
Date: Tue, 18 Mar 1997 18:12:59 -0500 (GMT-0500)
Subject: ADVERT: FYI: web site (fwd)
NOTE: Respond *only* to the poster's address (see below the dotted line)
or as directed in the posting, but definitely NOT to me.
Thanks.
Bill
- ---------- Forwarded message ----------
Date: Tue, 18 Mar 1997 17:51:26 -0500
From: Mitchell and Company
Subject: web site
For those of you who haven't checked out our new web site yet, we invite you
to visit http://www.fastforward400.com. It's an interactive research project
on how companies can make faster progress by changing the ways we think
about progress. We would appreciate it if you would let us know what you
think of the site and contribute your thoughts. The project is meant to be a
place where people can share their ideas.
Thanks!
Jason
jason@fastforward400.com
------------------------------
From: Yingxu Wang
Date: Wed, 19 Mar 1997 10:27:54 -0800
Subject: A serial mini-survey (No.6)
Dear colleagues,
- - A Survey of Base Process Activities Towards Software Process Excellency
Thank you very much for your response! Attached please find
the mini-survey No.6.
Best regards,
Yingxu Wang
- ---------------------------------------------------------------------------
Research Centre for Systems Engineering | Email:wang_s@solent.ac.uk or
Southampton Institute | yingxu.wang@comlab.ox.ac.uk
Southampton SO14 0YN, UK | Tel: +44 1703 319773
In collaboration with IVF, IBM, and ESI | Fax: +44 1703 334441
- ---------------------------------------------------------------------------
**************************************************************************
Questionnaire 2: Base process activities on software eng. processes (2/6)
**************************************************************************
2.2 Software development processes
2.2.1 Process control
105. (2.2.1.1) Evaluate software development methodologies
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
106. (2.2.1.2) Model software process
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
107. (2.2.1.3) Describe activities and responsibilities
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
108. (2.2.1.4) Establish task sequences
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
109. (2.2.1.5) Identify process relationships
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
110. (2.2.1.6) Document process activities
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
111. (2.2.1.7) Identify control point of project
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
112. (2.2.1.8) Maintain consistency across all processes
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
113. (2.2.1.9) Develop software according to defined process
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
114. (2.2.1.10) Derive project process by tailoring organisation's
standard process
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
115. (2.2.1.11) Approval processes and equipments
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
116. (2.2.1.12) Identify special requirements in developing
special system: real-time/safety critical/etc
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
2.2.2 Requirements analysis
117. (2.2.2.1) Requirement analysis according to defined process
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
118. (2.2.2.2) Formal requirements specification
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
119. (2.2.2.3) Define requirements feasibility/testability
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
120. (2.2.2.4) Prevent ambiguities in specification
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
121. (2.2.2.5) Procedure to interpret/clarify requirements
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
122. (2.2.2.6) Specify acceptance criteria
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
123. (2.2.2.7) Allocate requirements for processes
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
124. (2.2.2.8) Adopt requirements acquisition tools
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
------------------------------
From: "Bill Casti, CQA (Moderator)"
Date: Wed, 19 Mar 1997 16:16:40 -0500 (GMT-0500)
Subject: re: SW Acquisition CMM courses from SEI (fwd)
NOTE:
Please respond as directed in the posting below.
The courses are held in Pittsburgh, PA.
- ---------- Forwarded message ----------
Date: Wed, 19 Mar 97 08:43:14 EST
From: Brian P. Gallagher
Subject: please publicize
New Course: Introduction to the Software Acquisition CMM
1997 Dates: 22-23 April
09-10 September
04-05 December
For more information:
http://www.sei.cmu.edu/technology/risk/Risk_SW_Acq/SA-CMM.html
- -----------------------------------------------------------------------
Introduction to the Software Acquisition Capability Maturity Model(SM)
(SA-CMM[SM])
Introduction to the Software Acquisition Capability Maturity
Model(SM) (SA-CMM[SM])
Who should attend this course?
. Government and industry personnel responsible for the acquisition of
software-intensive systems or their maintenance
. Team members who oversee the outsourcing of software products and
services
. Members of process action teams, software acquisition process groups, and
software engineering process groups
As an acquisition professional, do you have the visibility that you need
into the software contracts that you oversee?
Are you managing your software development contracts or are they managing
you?
The Software Acquisition Capability Maturity Model (SA-CMM) is based on the
best practices of organizations that acquire software systems and products. It
is a model that describes the key elements of managing and improving the
acquisition process in an organization. The SA-CMM outlines a managed path for
improving the process for acquiring software - from an ad hoc approach based
on individual heroics to a mature, disciplined approach in which all aspects
of the acquisition and oversight process are managed to enhance the
organization's overall performance of work.
The two-day Introduction to the SA-CMM course is designed to give participants
an overview of the SA-CMM model and its fundamental concepts. The course is
based on Version 1.01 of the model and centers around the five maturity levels
of the model and their characteristic key process areas (KPAs).
Course discussions and exercises are designed to give participants a basic
understanding of the principles and activities of the SA-CMM and to show how
use of this structured approach to process improvement can be applied to a
variety of acquisition activities in government and industry. The course
lectures are supplemented with discussions and exercises that allow ample
opportunity for student participation.
Instructors
Course instructors include Rick Barbour, Ron Damer, Jack Ferguson,
Matt Fisher, Brian Gallagher, and Larry Jones.
Related SEI Products and Services
Related Courses
CBA Lead Assessor Training
Consulting Skills Workshop
Introducing New Software Technology
Introduction to the Capability Maturity Model
Managing Technological Change
SCE Team Training (Version 3.0)
Related Publications
Capability Maturity Model for Software
Continuous Risk Management Guidebook
Software Acquisition: A Comparison of DoD and Commercial Practices
Software Acquisition Capability Maturity Model
Software Acquisition Risk Management KPA: A Guidebook
(anticipated publication date: May 1997)
Software Engineering Process Group Guide
Toward a Reform of the Defense Department Software Acquisition Policy
Related Events
SEI Conference on Risk Management
SEI Software Engineering Symposium
Software Engineering Process Group Conference
Related Service
Risk Clinic
Software Risk Evaluation
Team Risk Management
For more information about the SEI and its products and services, contact
Customer Relations
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
Phone 412 / 268-5800
FAX 412 / 268-5758
Internet customer-relations@sei.cmu.edu
(SM) Capability Maturity Model, CERT, CMM, IDEAL, Personal Software
Process, PSP, Team Software Process, and TSP are service marks of Carnegie
Mellon University.
The Software Engineering Institute is a federally funded research and
development center sponsored by the U.S. Department of Defense and operated by
Carnegie Mellon University.
------------------------------
From: Yingxu Wang
Date: Thu, 20 Mar 1997 16:13:06 -0800
Subject: A serial mini-survey (No.7)
Dear colleagues,
- - A Survey of Base Process Activities Towards Software Process Excellency
Thank you very much for your response! Attached please find the mini-survey
No.7.
Best regards,
Yingxu Wang
- ---------------------------------------------------------------------------
Research Centre for Systems Engineering | Email:wang_s@solent.ac.uk or
Southampton Institute | yingxu.wang@comlab.ox.ac.uk
Southampton SO14 0YN, UK | Tel: +44 1703 319773
In collaboration with IVF, IBM, and ESI | Fax: +44 1703 334441
- ---------------------------------------------------------------------------
**************************************************************************
Questionnaire 2: Base process activities on software eng. processes (3/6)
**************************************************************************
2.2.3 Design
125. (2.2.3.1) Design system according to defined process
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
126. (2.2.3.2) Software architectural design
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
127. (2.2.3.3) Design module interfaces
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
128. (2.2.3.4) Develop detailed design
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
129. (2.2.3.5) Establish document traceability
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
130. (2.2.3.6) Specify final design
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
131. (2.2.3.7) Define design changes procedures
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
132. (2.2.3.8) Adopt architectural design tools
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
133. (2.2.3.9) Adopt module design tools
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
2.2.4 Coding
134. (2.2.4.1) Coding according to defined process
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
135. (2.2.4.2) Choose proper programming language(s)
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
136. (2.2.4.3) Develop software modules
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
137. (2.2.4.4) Develop unit verification procedures
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
138. (2.2.4.5) Verify software modules
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
139. (2.2.4.6) Document coding standards
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
140. (2.2.4.7) Define coding styles
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
141. (2.2.4.8) Adopt coding support/auto-generation tools
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
2.2.5 Testing
142. (2.2.5.1) Testing according to defined process
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
143. (2.2.5.2) Determine test strategy
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
144. (2.2.5.3) Specify test methods
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
145. (2.2.5.4) Generate test
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
146. (2.2.5.5) Conduct testing
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
147. (2.2.5.6) Adopt module testing tools
Importance in process: (least) [0] [1] [2] [3] [4] [5] (most)
Experience: Practised [ ] Not practised [ ]
Effectiveness: Yes [ ] No [ ]
Comments (if any): ..............................................
------------------------------
End of ISO 9000-3 Digest V1 #42
*******************************
To remove yourself from this list, address a message to: MAJORDOMO@QUALITY.ORG with only the words "unsubscribe iso9000-3-digest" (without the quotes) in the BODY of your message.