Introduction to SPI
Systems and Software Engineering (SE/SWE) Process Improvement

Resume | Papers | Courses | Consulting | ContEd | HW/SW | Tech Interests (Quality)
SPI Overview -- Deming Bio | 14 Points -- CMM and CMMI | SEH | ITIL -- Process Models | Tools
 

Introduction to SPI Approaches to Software Process Improvement Software Engineering Process Group (SEPG) Relationship to other Quality Approaches Deming Six Sigma Malcolm Baldrige Steven Covey's 7 Habits BPR SPICE ISO-9001-2000 Additional References

Introduction to SPI:

Kaizen (Ky 'zen) is a Japanese term made famous by Masaaki Imai in his book, Kaizen: The Key to Japan's Competitive Success. This term means gradual unending improvement by doing little things better, by setting and achieving increasingly higher standards. Historically, SPI was used to refer to Software Process Improvement. As CMMI (and other methods evolved), some organizations added an "S" to expand the scope to System and Software Process Improvement (or SSPI). Other organizations replaced "Software" with "Systems," to keep the same acronym: Systems Process Improvement (SPI), and include HW, SW, FW, and WW.  Whatever you call it, SPI is a specialization (or subset) of business "process improvement": CMMI-Dev focuses on software/systems development, the "front half" of the engineering life cycle (see separate CMMI pages) ITIL focuses on the operation and sustainment after delivery, the "back half" of the engineering life cycle (see more on Standards page) ISO 9001 is a higher-level standard (generally domain independent) which focuses on the Quality Management System, the monitoring the process capability and improvements (see history below and also Standards page) However, it is important to recognize that Software quality initiatives have some key differences from the heritage of hardware quality initiatives by "real engineers": software engineering is a fairly new discipline, and is arguable if it is yet an engineering discipline (as opposed to "black art" or craft) software is invisible (hard to see, harder to measure) software development (generally) lacks the constraints (and Laws) of physics--instead, its foundation is based on "softer" sciences of mathematics, logic, complexity theory, human psychology, and design [which allow for a wider range of opinion and disagreement, plus a wider variance in individual capability] software defects, with the greatest impact to quality, are typically introduced in conception and design process; where the major hardware defects are typically introduced in production process software "manufacturing" (although an over simplification) is typically developing only one product and reproducing it through a fairly error free disk copy; hardware manufacturing is typically a production line generating multiple products; therefore, hardware improvement models focus on the manufacturing process (e.g., measuring the variance of  tolerances in a component or final product) software improvement models focus on the development process (e.g., measuring the variance of  the process of how the product is built from conception); although the product is important, waiting to measure product defects is too late, and not cost-effective in improving the current software product. software development produces many intermediate work products, which can drastically impact the final product, but may not be "deliverables" to the customer software development, at least in common practice, is usually a human-intensive process, which is aggravated by several factors: engineers are generally suspicious of tools and tool vendors (i.e., "snake oil salesmen"), because they have seen the unsubstantiated claims made by marketing (sometimes by their own company) software engineers are suspicious of automated tools, because they know the nature of software and suspect the products were developed by less mature process then they use tool vendors tend to target their marketing to management (those that have the money), and do not address the needs of the true user [or vice versa] therefore, the software industry suffers from what has been called, "the plumbers wife syndrome" or "the cobbler's kids syndrome": After fixing everyone else's "sink" they do not have the energy left at the end of the day to fix their own They are too critical of other "craftsmen" to pay them to do it They fail to invest in their own processes (especially on "over-head" money) However, software quality initiatives have some key similarities with other quality initiatives: product quality is dependent on how the product is produced by the development "system" each person involved in producing a product have their own capability/effectiveness distribution (they have good days and bad days) the population (of people involved in producing a product) has its own capability/effectiveness distribution (you have high-achievers, early adopters, and you have sluggards, and most reward systems increase, rather than reduce, the variance the development "system" has a capability distribution (with a mean and standard deviation) -- the "system produces what the system produces" only management can enable (or prevent) changes to the system to improve the mean or the standard deviation (i.e., change the system and its capability) once the process is defined, measurements can be defined to measure the process once the process is measurable, it can be placed under Statistical Quality Control

Software Process Improvement Approaches:

There are three major approaches (or paradigms) to systems/software process improvement (SPI) that can be used independently or in combination. These include: Model-Based Improvement Bottom-Up Process Improvement Business Process Reengineering (or Revolution) Model-Based Improvement uses a set of industry-accepted practices (either common practice, "best practice" or minimal standards) as a model for improving an organization, which is not adhering to these practices. The two most frequently used models are Software Engineering Institute's Capability Maturity Model® Integration (CMMI®) and the International Organization for Standardization's ISO-9000 set of quality standards. ISO-9001:2000 Certification is roughly equivalent to CMMI Maturity Level 3 and defines the "floor" which you should not go below (rather than a "ceiling" which you should desire to obtain). CMMI Maturity Levels 4 and 5 of the focus more on measurement, statistical quality control, and continuous improvement. Bottom-Up Process Improvement involves making measured improvements based on lessons learned and empirical data. An organization measures size, effort, productivity, defects, reusability, and other process indicators (as baseline data). When potential improvements are identified, a change is implemented (typically on a subcomponent of the organization), and the effect of the change measured to determine if an actual (significant) improvement occurred. The results are then used to drive organizational change. For example, the Trend Chart below can be used to set limits on the product size for a Peer Review. See also Six-Sigma approach below. Business Process Revolution, is similar to a Bottom-Up Approach, but typically pushes for radical (revolutionary) improvements, rather than incremental change [see BPR approach below].

Software Engineering Process Group (SEPG^sm):

Software Engineering Process Group was the original name, and a service mark of SEI, given to the "group responsible for the organization's software process activities". Companies who did both hardware and software (especially after the creation of CMMI), have used a number of variations on the name to include systems engineering: a.k.a. SEPG -- Systems Engineering Process Group a.k.a. SSEPG -- Systems and Software Engineering Process Group a.k.a. SSPG -- Systems and Software Process Group a.k.a. PEG -- Process Engineering Group a.k.a. PIG -- Process Improvement Group a.k.a. QIG -- Quality Improvement Group a.k.a. PTIG -- Process and Technology Improvement Group or similar variations The concept of an SSPG is discussed in Organization Process Focus (OPF) and Organization Process Definition (OPD) Process Areas within CMMI Maturity Level 3, Defined. Although not "required" for CMMI Maturity Level 2, many organizations find it beneficial to establish an SSPG to focus the SPI effort. An SSPG should be built using senior systems and software engineers with a balance of experience in all technical and management aspects of software development (e.g., domain experience, requirements, design, configuration management, quality assurance, project management, testing, etc.). Members of the SSPG may be assigned full-time or may "straddle the fence" between SSPG and development on a part-time basis, to assure awareness of current organizational needs and help "buy-in". SSPG members typically... Define and manage Action Plans based on results from internal process reviews, quality assurance audits, SCAMPI Appraisals, project data (cycle time, performance, defect rates, etc.), project tailoring of processes, approved deviations, suggestion program, issue log, lessons learned, and other opportunities for improvement. Facilitate the definition, maintenance, and improvement of the software processes used by the organization, typically through Process Action Teams (PATs) which address specific issues on the Action Plan Participate on or facilitate (functional area) working groups of professionals in similar roles in order to share ideas, mentor, solicit possible alternatives, etc. Establish the organization's set of standard processes (OSSP) Establish organizational metrics plan, standards, and collection vehicles Assist in the installation and "institutionalization" of processes within the organization through mentoring and training Monitor the changing needs of the organization and assure that the OSSP is consistent with those needs SSPG members may also be members of a SPIN or TWIST (and other Professional or Quality Organizations) or hold one or more professional certifications.

Relationship Between SPI and
Other Quality Approaches:

CMMI | Deming | Six Sigma | Baldrige | Covey | BPR | SPICE | ISO-9000

Deming, et al   As mentioned above, Software Process Improvement approaches are similar to those pioneered for manufacturing. However, the first seeds can be traced back to Carl Frederick Gauss (1777-1855) who introduced the concept of the normal curve. In the 1920's, Walter Shewhart used sigma (or population variance) as a measurement standard. He showed that three sigma (3s) from the mean, in product variation, is the point where a process requires correction. In process improvement, you are dealing with two general goals: Improve the capability of process or some set of quality characteristic of the product decrease defects (and related rework) increase customer satisfaction decrease cycle time, i.e., time to market increase return on investment (ROI) Improve predictability (or confidence) of that set of characteristics These two goals are related to three key statistical measures: Mean (or average) is the center or location of a "population" the population mean, is indicated by statisticians as: m (lower case Greek letter "mu") a sample mean, an estimate of the population, is indicated as: ў, read "y-bar" Variance is a measure of the "spread" of values around the mean the population variance, is indicated by statisticians, using the lower case Greek letter "sigma": s2, read "sigma squared" a sample variance, an estimate of the population, is indicated as: s2 Standard Deviation (sd) of a population is √s2 or s (the positive square root of the population variance) These three measures enable statistical control of a "population"... Control limits can be calculated [these are set three sigma (3s) from the mean based on Shewart's work] Any measures outside the control limits are identified are identified as special causes of variance [prevents wasting time on "correcting problems" within the "noise" (variance) of the normal distribution] The data is analyzed to determine the possibilities for mitigation or correction Once all variation is inside the control limits (within 3s), the process has been brought under statistical control All variance can then be attributed to common causes of variance Causes are identified Causes are ranked in their relative importance in improving the quality characteristics of value to the business Potential changes can be proposed and evaluated Selected changes can be piloted The performance of the proposed "to be" process can be measured and compared to the current "as is" process Then the distributions can be statistically compared to determine, if the change actually produces a measurable (statistically significant) improvement in the difference between the mean performance of the two distributions, or reduction in variance and significant business-driven improvement, with an acceptable return on investment Only then can true process improvement begin! Measuring the process capability variance and distribution enables a statistical determination of if a process or product change is really an improvement! These principles led to advances by Crosby, Deming, Juran, Ishikawa, and others. The concepts were incorporated into the Capability Maturity Model for Software (SW-CMM). Maturity Levels 2 and 3 prepare a foundation (partially to overcome the "uniqueness" of the software product described above). However, the purpose is to allow statistical control (Maturity Level 4), with the goal of continuous improvement (Maturity Level 5). These concepts were incorporated into successors of SW-CMM, including CMMI. The Software Engineering Institute adapted Shewhart's PDCA Cycle to create their IDEAL model for continuous improvement (see also quality tools). Trying to apply CMMI (or any other method) without an understanding of these foundational principles, will neither be effective nor sustaining. See discussion of the Architecture of CMMI for a mapping to some of Deming's principles. All improvements require change, but not all changes are improvements.

CMMI | Deming | Six Sigma | Baldrige | Covey | BPR | SPICE | ISO-9000

Six-Sigma® (6s) Overview | History | Basics | Differences Overview: The Six-Sigma (6s) process is a Bottom-Up approach that uses statistical control of the operating processes. Current capability ("as-is" process), and potential improvements ("to-be" process) are typically tracked by measuring qualities like: total defect density, user-visible defects, cycle time, and other similar characteristics. The strategy optimizes the production processes, while assuring high productivity, by bringing them into statistical control. The objective of Six Sigma Quality is to reduce process output variation so that over the long term, the customer's aggregate experience, will be near error-free products and services. ® Six Sigma, is a registered trademark of Motorola Corporation. Overview | History | Basics | Differences History: The Six Sigma approach is built on the same basic principles that were pioneered by Gauss, Shewhart, and others. In the late 1970's, Dr. Mikel Harry, a senior staff engineer at Motorola's Government Electronics Group (GEG), began to experiment with problem solving through statistical analysis. The term "Six Sigma" and related concepts were developed, beginning about 1984, by Bill Smith and other engineers at Motorola. The approach evolved from three important observations from Motorola's production measurements: Process and Product are Related -- the reproducibility of a critical-to-quality characteristic is fully dependent on the “goodness of fit” between the operating bandwidth of the process and the corresponding bandwidth of the performance specification A Change in the Process distribution, negatively impacts the Product -- the quality can be substantively and consequentially disturbed by process centering error When considering the performance tolerance of a critical design feature, the performance “cushion” has to be sufficient to absorb a sudden shift in "capability" of the process Bill Smith hypothesized that the typical shift was on the order of 1.5s (relative to the target value) Tighter tolerance control was required -- if the target is a long-term capability of 4s, then the actual short-term capability of critical processes must qualify at the 6s level. Therefore, the "Sigma" comes from statistically measured standard deviation, and "Six" comes from the target goal (from the third observation) The target is no more than 3.4 defects per million opportunities (DPMO), where any sample from the population, the probability of finding a defect is greater than six sigma (or standard deviations from the mean) Based on success in GEG, Motorola began to formulate a method for applying the techniques throughout the company.  Dr. Harry produced a paper titled, "The Strategic Vision for Accelerating Six Sigma Within Motorola."  Since then, other groups within Motorola, other companies like GE and AlliedSignal (Honeywell), professional organizations like ASQ, and other practitioners have contributed to the evolution of Six Sigma. Overview | History | Basics | Differences Some Basics: The unit of measure is usually defects per million opportunities (DPMO) A defect is defined as a unit (product or process) that is "out of standard" or "deviates from its specification" An "opportunity" is defined operationally, based on points in the life cycle where a defect could be inserted (e.g., intermediate steps, hand-offs between processes, etc.) and the number of units produced or executed. The DPMO is converted to a "Sigma Level", based on a look-up table. Most company's processes typically operate at 2-3 sigma just to be competitive Therefore, setting a "stretch goal" of 6 Sigma will require substantial improvement! Goals for reduction in defects are usually coupled with goals to reduce "cycle time" (e.g., 2x in n months, or 10x in n years). Therefore, an organization (typically) applies the Six Sigma Process for radical process or quality improvements (compared to the incremental changes which are the basis of CMMI or ISO 9001) The aim is high, in order to force people to evaluate the "as is" process, and think out of the box to look for fundamentally new ways of doing business--called the "to be" process. [This approach is similar to BPR.] Six-Sigma (6s) approach uses a life cycle called DMAIC, which is similar to the approach used by ISO or CMMI. Six Sigma is very compatible with (and provides techniques for facilitating) improvement programs based on: CMMI  (especially at Maturity Levels 4 and 5), and ISO 9001 (especially if applying some of the Quality Management Systems Guidelines continual improvement practices in ISO 9004) Overview | History | Basics | Differences Six Sigma is Different: Dichotomy:  "Our greatest strength is also our greatest weakness" (and vice versa) 6s: Cert-Body : Org : Individuals : Data : Cross-Domain : Open Six Sigma does not have a single certification body: Weakness: Not at true "standard" in the usual sense, but a widely accepted statistical approach to quality and process improvement (see Organizations page for "owners" of other Standards) Without an accreditation mechanism for courses and certifications, the content, expertise of instructors, domain experience of consultants, and other factors can vary greatly between vendors Strength: There are choices in approaches and vendors Motorola University (www.mot.com/MU/ ) is not the only certification body Other providers include: ASQ Six Sigma Academy, and GE See also: www.isixsigma.org for additional vendors and consulting companies 6s: Cert-Body : Org : Individuals : Data : Cross-Domain : Open Six Sigma does not define "certification" for organizations Weakness: A standard (external) appraisal method is not defined Techniques from other methods could be applied, but there is no standard or process to: audit for compliance to "Pass" some minimum standard "s level" [like an ISO 9001 Audit] appraisal or rating method to determine the s level = 3.5 Sigma [like a SCAMPI] certify an operation at some predetermined level: "operating at Six Sigma" or "at least x.y sigma level"  [like Underwriters Laboratories] Without a standard appraisal method, executed with some independence (or at least objectivity), comparing results between companies, and even groups within a company, is speculative Care should be taken (as with any method) when evaluating the claims of suppliers, subcontractors, or competitors: Many companies claim they are "doing Six Sigma", meaning they are attempting to apply the "Six Sigma Method" as an approach for improvement Some organizations define a goal to achieve "Six Sigma Quality", but having the goal is substantially different than achieving that goal Even the short term measured achievement of "Operating a process at Six Sigma", is substantially different than achieving long term sustainment of all critical processes under Six Sigma Control! Compare with SCAMPI, SCAMPI Class Types, or ISO/IEC-15504 Strength: Six Sigma is a great tool for internal process improvement, so that is how it should be used.  The lack of organizational certification helps "protect" it (some) from being manipulated by political or industry pressure (e.g., by setting an arbitrary sigma level as a contract requirement, as has been done with CMM, CMMI, and ISO-9001). 6s: Cert-Body : Org : Individuals : Data : Cross-Domain : Open Individuals are certified in Six Sigma principles Strength: Change agents or facilitators, within an organization, can acquire training and certification from multiple vendors Certification "levels" or "degrees" differ in: The number of hours (depth) of instruction in Six Sigma practices, and Criteria for an improvement project they are required to manage to completion (e.g., size of the projects, savings/ROI that must be realized) Certification "level" names are based on the "belts" used in martial arts; see Certification page for a general description of each level. Weakness: Results vary. 6s: Cert-Body : Org : Individuals : Data : Cross-Domain : Open Six Sigma is statistically-based and data-driven Strength: Six Sigma's statistical basis is well known and has been proven in theory and in practice for many applications; the formulas provide some objectivity Weakness: The figures don't lie, but the liars figure! Although the formulas are objective, the numbers can still be "gamed" by adjusting what is selected as "opportunities" and "defects" Sigma Levels will be calculated differently if an Opportunity is defined as one life cycle phase, one process, one "hand-off," one procedure (one process step), one procedure step, one version of a deliverable, a single peer review, or some other definition Similarly, changing the definition of defects or the counting process can change the Sigma Levels measuring a Defective Product (which could have multiple defects) vs. counting each component out of specification; treating all Defects as equal vs. separating based on a severity level (major, minor, trivial defects) or variance from standard, or impact to safety, reliability, hazard, or other requirements; distinguishing the symptom (failure) from the cause (bug, fault) single work product (causal analysis, debugging) Mitigation: Focus on improvement, rather than the numbers; get cross-functional buy-in from all "suppliers" and "consumers" (stakeholders); have peer review of all calculations; keep all calculations public if possible or at least reviewable and auditable 6s: Cert-Body : Org : Individuals : Data : Cross-Domain : Open Six Sigma is not constrained to a specific domain Strength: "Sigma Level" provides a domain-independent quality measure, which can be used to integrate the process improvement efforts of different departments and stakeholders to look at "end-to-end" quality can be "translated" for both the techie and non-techie worlds [e.g., it can be used, by an "internal" IT shop, to help integrate its CMMI or ITIL based process improvement with the business operation or production processes it serves] can be leveraged to cross development and production barriers can bridge the subcontractor/supplier divide Weakness: Six Sigma does not provide... a list of best practices, acceptance criteria, or domain-specific guidance on how to improve 6s: Cert-Body : Org : Individuals : Data : Cross-Domain : Open Six Sigma quality definitions are "open" Strength: Six Sigma does not force a particular definition for "opportunity" and "defect"; therefore, it can be tailored to the business needs of an organization, processes, a product line, or a department with different quality measures and priorities Weakness: There are guidelines, but the granularity of the definitions of "opportunity" or "defect" can impact the measured Sigma Level; since companies can choose the scope of their own appraisal, the definition of defects, and the definitions of opportunities, equal sigma levels do not necessarily imply comparable effectiveness Overview | History | Basics | Differences 6s: Cert-Body : Org : Individuals : Data : Cross-Domain : Open

CMMI | Deming | Six Sigma | Baldrige | Covey | BPR | SPICE | ISO-9000

Malcolm Baldrige National Quality Award www.quality.nist.gov Defined by The Malcolm Baldrige National Quality Improvement Act of 1987 - Public Law 100-107 Administered by NIST's Baldrige National Quality Program (BNQP) See Standards page

CMMI | Deming | Six Sigma | Baldrige | Covey | BPR | SPICE | ISO-9000

Covey's 7 Habits Steven Covey's Seven Habits of Highly Effective People, and related books, address personal improvement, leadership, and life balance. Although not promoted as a "quality approach", Covey's approaches share a number of common concepts with Deming's 14 Points and the management principles implied by the CMMI. Habit 1: Be Proactive--The CMMI approach focuses first on projects (at Maturity Level 2), which is typically under the control of a Project Manager who can Be Proactive within their Circle of Influence (rather than concerning themselves with things outside of their control). At Maturity Level 3, the Circle of Influence enlarges to include the organization. Habit 2: Begin with the End in Mind--The CMMI approach applies Habit 2, by defining goals for each process area, mapped to industry proven practices and subpractices that provide a series of obtainable steps to enable an organization to reach the goals. Habit 3: Put First Things First--Using CMMI as a "staged" model provides five Maturity Levels, which build on each other, providing guidance for organizations to prioritize the goals, and execute around those priorities. The focus at Maturity Level 2 is mainly on management and planning (Quadrant IV activities), which creates the time necessary to concentrate on the technical and organizational issues at the higher levels. This is also an application of the Pareto Principle. Habit 4: Think Win-Win--This habit is critical in obtaining Maturity Level 3, which involves establishing improvement goals based on organizational business goals, and establishing organizational processes from project-level processes that address everyone's needs. "Everyone gets their say, no one gets their way" as Richard, our congregation's evangelist, always says. This applies to processes, systems, and teams: You don't build processes for "process sake" or because "the model says so". The solutions and alternatives must make business sense--if you "get the level" but not "get the next job"--that's win-loose! Another application is the "balanced scoreboard"--there are competing measures of quality, system requirements that conflict, trade-offs to be evaluated through Decision Analysis and Resolution (DAR) Safety, Security, and Reliability Size vs. Speed Simplicity and Capability Good, Fast, or Cheap -- Pick any two Habit 5: Seek First to Understand--The goal is not to make a change, but to make an improvement! Changing increases variance, reduces quality, and increases rework. The only way to know if it is an improvement is to measure before and after (and figure how soon you can recover the cost of changing). CMMI Maturity Level 4 focuses on measuring, determining the distribution (mean and standard deviation), and understanding when an "event" is part of the normal distribution or an outsider (a special causes of variation) that should be addressed. As Covey would say, "Diagnose before you Prescribe" As Shewhart would say, "Check before you Act" As the Software Engineering Institute's IDEAL model would say, "Diagnose, Establish a Plan, then Act" As the P.R.O.G.R.E.S.S. method would say, "Research and Obtain Root Causes before Generating Possible Improvements" As Pareto or Juran would say, "Focus on the cause that fixes the most problems" (20% effort for 80% fixes) As Watts Humphrey would say, "If you don't know where you are, any map will do!" or "You have to know where you are, before you can determine which way to go" Habit 6: Synergize--A solution, where the sum of the parts is greater than the whole, requires the application of of a different perspective -- Finding the Third Alternative. Finding a way to optimize Win-Win Valuing the Differences Establishing long term relationships based on loyalty and trust [see Deming's 14 Points]. Leveraging diverse teams (which have been demonstrated to be the most productive and innovative) "When two people have the same opinion, one is redundant" -- Covey "Problems cannot be solved at the same level of awareness that created them." -- Einstein Habit 7: Sharpen the Saw--Renewal, effectiveness, maximizing long-term beneficial results, P/PC balance (Production vs. Production Capability), not killing the goose to get the golden egg,   SEI's directive is to focus on quality (not the rating), it is a continuous improvement cycle Organizational Training at Maturity Level 3 includes both initial and continuing education, Deming's Point 13 The goal is not "a level" -- the highest maturity level is not a "goal" (a noun), but a state of constant improvement (a verb) Optimizing, Levels 1-4 are steps to reach the end-state See Deming's Point 5--Improving constantly and forever, Kaizen! If you don't constantly improve, you loose ground because your environment changes If you are not growing, you are dead! For more information on Covey's time management and leadership work, see: Franklin Covey Company http://www.franklincovey.com/ formed by a merger of: Covey Leadership - prioritization, mission statements Franklin Quest - time management schedulers and tools Poor on Macintosh support for automated solutions! Books/Tapes Seven Habits of Highly Effective People - Steven R. Covey Connections: Quadrant II Time Management - A. Roger Merrill and Rebecca R. Merrill First Things First - Steven R. Covey, A. Roger Merrill, and Rebecca R. Merrill Principle Centered Leadership - Steven R. Covey Seven Habits of Highly Effective Families - Steven R. Covey How to Develop A Family Mission Statement - Steven R. Covey What Matters Most - New from FranklinCovey My personal links Bowen Family Mission Statement Seven Habits of Highly Effective Christians Covey Quotes

CMMI | Deming | Six Sigma | Baldrige | Covey | BPR | SPICE | ISO-9000

CMMI | Deming | Six Sigma | Baldrige | Covey | BPR | SPICE | ISO-9000

CMMI | Deming | Six Sigma | Baldrige | Covey | BPR | SPICE | ISO-9000

CMMI vs. Deming | Six Sigma | Baldrige | Covey | BPR | SPICE | ISO-9000
Intro | Approaches to SPI | SEPG | Relationships | Additional References

Additional References:

See other Quality links on Technical Interests Index Related Topics in Systems Engineering Dictionary: Other Quality-related information on this Systems/Software Engineering website: Engineering Standards Standards Organizations Professional Organizations - Organizations who provide publications, certification, and other components for professional development Standards of Professionalism Development Methods SPI-related Companies PAL Tools

©1994-2007 Gregory M. Bowen, CSDP