Abstracts - Presentations
can range from a one-hour talk to a full-day tutorial. Note that tutorials can be offered in shorter
forms but not necessarily vice versa.
The first section of this list of abstracts describes shorter
presentations; the second tutorials and one-day seminars.
The presentations in this section are recommended for one-hour talks
Organizations are increasingly delegating their information
technology (IT) intensive business activities to service providers, taking
advantage of the rapid evolution of the global telecommunications
infrastructure. The business processes being outsourced range from routine and
non-critical tasks, which are resource intensive and operational, to strategic
processes that directly impact revenues.
Managing and meeting client expectations is a major challenge in
IT-enabled outsourcing services and examples of failure abound. The eSourcing
Capability Model for Service Providers (eSCM-SP) contains a set of 84 best
practices that address the entire outsourcing (or insourcing) process.
The eSCM-SP is structured along three dimensions: sourcing life cycle, Capability
Areas, and Capability Levels. The sourcing life cycle dimension addresses
engagement initiation and completion activities as well as delivery and ongoing
practices. Ten Capability Areas are used to logically group the Practices.
Five Capability Levels that address performing to meet client
requirements, controlling through measurement, enhancing through innovation,
and sustained excellence. The eSCM-SP aids IT-enabled outsourcing service
providers in forming, managing and improving outsourcing relationships.
This presentation provides an overview of critical sourcing issues and eSCM-SP
version 2.
This presentation discusses some of the empirical evidence on the value obtained from investing in software process improvement using the Software Capability Maturity Model (CMM) developed by the Software Engineering Institute (SEI) at Carnegie Mellon University. Business drivers for process improvement and some challenges in organization change are described, along with data on the impact on cost, schedule, and quality of achieving the five maturity levels in the CMM. From an executive perspective, the crucial point is that continual improvement depends on systematically addressing the problems facing the organization -- regardless of the improvement framework selected. This "constancy of purpose" depends on management sponsorship, support, and investment.
The Software CMM has been criticized for being applicable only to large organizations and projects, yet many small organizations and projects have used the CMM successfully in their process improvement efforts. Some of the common problems with interpreting the Software CMM for the small project/organization include:
What does "small" mean? In terms of people? Time? Size of project? Criticality of product?
What are the CMM "requirements"? Are there key process areas or goals that should not be applied to small projects/organizations? Are there "invariants" of good processes?
The conclusion of this presentation is that the issues associated with interpreting the Software CMM for the small project/organization may be different in degree, but they are not different in kind, from those for any organization interested in improving its software processes. Using the Software CMM effectively and correctly requires professional judgment and an understanding of how the CMM is structured to be used for different purposes.
Agile methodologies have been touted as the programming methodologies of choice for the high-speed, volatile world of Internet and Web software development. They have also been criticized as just another disguise for undisciplined hacking. The reality depends on the fidelity to the agile philosophy with which these methodologies are implemented and the appropriateness of the implementation for the application environment. Extreme Programming, Scrum, and similar agile methods are disciplined processes that incorporate good engineer and management practices, albeit with extreme implementations tailored to a specific kind of environment. Many of the challenges to agile methods arise from considering how they would fit in different environments; the degree to which agile methods can be adapted without losing their emergent properties is passionately debated. The compatibility of agile methodologies with the Capability Maturity Model for Software is summarized and critiqued, with the conclusion that appropriately implemented agile methods can be useful additions to an organization's set of standard processes.
"Our greatest asset is our people." This platitude is frequently followed by announcements of layoffs, downsizing, and similar Dilbertesque decisions. If people are the most important single factor in success, how do we incorporate that fact into our process improvement programs? This presentation provides an overview of "people issues" for software engineering, management, and process improvement from an individual, team, and organizational perspective.
The software crisis has persisted for decades. Our difficulties in planning and managing software projects may be rooted in fundamental human nature, as suggested by research in rational decision making, more than in the inherent difficulty of building software. The Capability Maturity Model for Software, an application of the concepts of Total Quality Management to software development and maintenance, embodies one approach for improving the software process. The problems addressed by both the CMM and TQM seem to lie in the basic ways that human beings think and organize themselves. In many circumstances, normal human decision making can be characterized as "irrational" because of systematic biases and fallacies in the way people make decisions. Mechanisms such as those suggested by the CMM support rational decision making.
The Capability Maturity Model (CMM) for Software, developed by the Software Engineering Institute at Carnegie Mellon University, is a five-level model for improving the process capability of organizations, which has been widely adopted in the software community and beyond. Although the Software CMM is a popular improvement model, comparatively few organizations have achieved the higher levels of maturity -- levels 4 and 5.
The lack of wide-spread experience with high maturity practices has been a challenge for assessors who wish to appraise level 4 and 5 organizations and for software engineering process groups working to improve their organization's processes. The purpose of this presentation is to discuss the engineering and management practices typically found in high maturity organizations.
Delivering software products with the promised functionality on budget and on schedule is a challenge many organizations have difficulty meeting. Over the past several years, a growing number of organizations have adopted the ideas of Total Quality Management for managing their software projects and systematizing organizational learning. Perhaps the best known model for applying TQM concepts to software organizations is the Capability Maturity Model for Software. The CMM describes good engineering and management practices that an organization can use, and it prescribes an improvement path that leads to mature processes and a mature organizational capability. None of these practices need be particularly innovative; for the most part they capture common sense practices that are unfortunately sacrificed all too often under pressure.
This presentation begins with a brief discussion of the Capability Maturity Model for Software (the Software CMM), but its primary focus is on the evolution of project management as an organization matures. Software project management changes to take advantage of the organizational learning implied by the organization's moving up the maturity levels. The presentation closes with a discussion of the approach, deployment, and results associated with maturing organizations and a brief warning against abuses of the CMM.
One of the powerful tools used by high maturity organizations is process modeling. Process models can provide insight into planning, strategic management issues, process control, operational management, process improvement, technology adoption, and training. Building useful and usable models is not, however, a trivial exercise. This paper summarizes some of the lessons learned in selecting a modeling technique, identifying the important measures to parameterize the model, collecting valid data to calibrate it, and applying the insights from the model effectively.
As organizations attain the higher maturity levels according to the Software Engineering Institute's Capability Maturity Model for Software, one of the challenges they face is to establish effective and efficient customer-supplier relationships. This presentation discusses the issues that for maturity organizations in working with low maturity customers and vice versa.
The presentations in this section may be 1-hour presentations, or all
the way up to full-day tutorials. Some
of these are variants/expansions of the shorter presentations, e.g.,
"Practices of High Maturity Organizations" is almost completely
included in "Understanding High Maturity," and "Using the
Software CMM With Good Judgment" includes the
majority of the material in "Using the Software CMM in Small Organizations
and Small Projects."
Organizations are increasingly delegating their information
technology (IT) intensive business activities to external service providers,
taking advantage of the rapid evolution of the global telecommunications
infrastructure. The business processes being outsourced range from routine and
non-critical tasks, which are resource intensive and operational, to strategic
processes that directly impact revenues.
Managing and meeting client expectations is a major challenge in
IT-enabled outsourcing services and examples of failure abound. The eSourcing
Capability Model (eSCM) contains a set of 93 best practices that address the
entire outsourcing (or insourcing) process. The eSCM is structured along
three dimensions: phases, organizational elements, and capability levels.
The phases dimension addresses pre-contract and post-contract activities
as well as contract execution and overall practices. Organization
elements include organizational management, people, business operations,
technology, and knowledge management. The eSCM has five capability levels
that address performing to meet client requirements, controlling through
measurement, enhancing through innovation, and sustained excellence. The eSCM
aids IT-enabled outsourcing service providers in forming, managing and
improving outsourcing relationships. This tutorial provides an overview
of outsourcing issues and the eSCM model.
The Capability Maturity Model (CMM) for Software, developed by the Software Engineering Institute (SEI) at Carnegie Mellon University, is a model for building organizational capability that has been widely adopted in the software community and beyond. The CMM is a five-level model, which contains 18 key process areas crucial to building organizational capability. The presentation provides an overview of the five levels, the process improvement priorities that they represent, why the five levels are defined as they are, and a summary of the key process areas that describe the maturity levels in detail. This presentation is aimed at an audience that is not already familiar with the CMM.
Common concerns in interpreting the Software CMM for different environments are discussed. General principles for good process definition and management are described and then illustrated with issues in interpreting the CMM for small projects and organizations. Interpretation issues include: What does "small" mean? How do I define "project?" "Organization?" What are the CMM "requirements"? Are there key process areas or goals that should not be applied to small projects/organizations?
Professional judgment is necessary to use the CMM correctly since the practices in the CMM are informative rather than normative, but some practices should always be judged necessary for adequate processes, while others are context sensitive. Using the CMM without judgment leads to dysfunctional behavior; some of the drivers and motivations for abuse of the CMM are described.
The conclusion of this presentation is that the issues associated with interpreting the Software CMM in various contexts may differ in degree but not in kind for any organization interested in improving its software processes. Using the Software CMM effectively and correctly requires professional judgment and an understanding of how the CMM is structured to be used for different purposes.
This presentation provides an overview of the Capability Maturity Model for Software (CMM) v1.1 and ISO 9001:2000, followed by a comparison of the two. The Software CMM describes the principles and practices underlying software process maturity and is intended to help software organizations improve the maturity of their software processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. The ISO 9000 series of standards deal with quality systems that can be used for external quality assurance purposes. The Software CMM and ISO 9001 are driven by similar concerns with quality and process management and intuitively are correlated. Software CMM key process areas and ISO 9001 clauses are compared, and gaps in the coverage of each relative to the other are discussed. Questions that are addressed include: "At what level in the Software CMM would an ISO 9001 compliant organization be? Can a CMM Level 2 (or 3) organization be considered compliant with ISO 9000? Should I base my software process improvement program on ISO 9001 or the Software CMM?"
This presentation provides an overview of the current world-wide trends in the arena of software process and quality improvement. It begins with a discussion of the Capability Maturity Model for Software developed by the Software Engineering Institute and the state of the practice in software engineering. Other approaches to software process improvement are briefly discussed, including the ISO 9000 family of quality management system standards and the ISO 15504 standard being developed for software process assessment. Pros and cons of these approaches are discussed in comparison to the SEI's work.
"High maturity," in terms of the Capability Maturity Model (CMM) for Software, implies a superior process capability for a software organization, yet comparatively few organizations have achieved the higher levels of maturity -- levels 4 and 5. The lack of wide-spread experience with high maturity practices is a challenge for both assessors and process engineers. The purpose of this tutorial is to discuss the fundamental principles of the Software CMM at the higher maturity levels and some of the effective engineering and management practices typically found in high maturity organizations. At the end of this tutorial, attendees should have a better understanding of how to interpret the Software CMM at levels 4 and 5 and insight into effective implementations of high maturity practices.
As organizations improve their processes and use quantitative and statistical techniques to control and improve the way software is built, there is a growing need for software engineers to have a basic understanding of statistics. This tutorial provides an overview of software measurement, statistical concepts and terminology, statistical thinking, basic statistical tools, regression analysis, test of hypotheses, and control charts. It provides an awareness of statistical issues, including a discussion of assumptions that are made, pitfalls to be wary of, and myths and misconceptions to dismiss. This awareness should help the software professional understand the use and limitations of methods and tools that use statistics, such as cost models, statistical process control, reliability models, and rational decision making.
The Capability Maturity Model for Software, developed by the Software Engineering Institute at Carnegie Mellon University, is a model for building organizational capability that has been widely adopted in the software community and beyond. The Software CMM is a five-level model that prescribes process improvement priorities for software organizations. Level 4 in the CMM focuses on applying quantitative techniques, particularly statistical techniques, for controlling the software process.
In statistical process control, this means eliminating special causes of variation. Because the software process is not a repetitive manufacturing or service process, the application of statistical process control, specifically control charts, has been challenged by many in the software community. What the CMM has to say about statistical process management is discussed, along with the issues in applying statistical thinking to the software process, prerequisites for applying statistical control, and the specific techniques that should be considered. Examples from real-world software projects illustrate the challenges in stabilizing the software process and applying different statistical techniques.
This tutorial provides an overview of the software process work being done at the Software Engineering Institute (SEI). The SEI has developed a capability maturity model (CMM) to describe the ability of organizations to develop and maintain software. Based on the process management work of quality gurus such as Deming, Juran, and Crosby, the CMM can be applied by organizations to improve their software process via assessments and by acquisition agencies to select qualified software vendors via evaluations. The tutorial discusses the principles underlying process and quality management, performing assessments to improve the software process and evaluations to improve the supplier base, managing technological change, and understanding the CMM.
Level 4 of the Capability Maturity Model for Software focuses on quantitative management. Quantitative management implies an understanding of variation, so that data can be properly understood when doing measurement-driven decision making. Decision making based on data implies that the data is collected and analyzed frequently enough that "real-time control" of the process is possible and that the comparability of the process and product context for the data is understood. An understanding of variation is grounded in the principles of statistical thinking, and the appropriate use of statistical tools is an integral part of quantitative management. A common error in "quantitative management" is analyzing data without doing the statistical thinking that supports real insight. For software projects, real-time process control means that the data being used for control is collected, analyzed, and decisions made on the spot. Measurement and analysis on a monthly or longer basis is inadequate for real-time control, but many organizations fail to understand the impact on efficiency of immediate, informed reaction. Those who do no understand the comparability of their data may aggregate dissimilar data together. Statistical control depends on a profound knowledge of both process and product. Failing to set the product context via product lines, systematic reuse, domain-specific architectures, and similar approaches is a mistake that results in an unacceptable amount of variation in the data. It is important to know when statistical control is feasible and when approaches such as risk management are more appropriate; not every process should be statistically controlled. Organizations that are truly Level 4 understand variation, have simple but fine-grained data, have profound knowledge of their products, and use statistical control where appropriate.
This one-day seminar addresses the challenges, strategies,
and tools for managing software projects.
The seminar is structured according to the knowledge areas of the
Project Management Body of Knowledge.
Customer relationship management, decision making, earned value, critical
path, critical chain, and agile methodologies will be discussed.
Effective project management is a prerequisite for meeting
commitments, yet all too many software projects fail to meet customer
expectations for budget, schedule, functionality, and quality. Many customers now require their suppliers to
demonstrate their commitment to process improvement and quality management by
using, or being certified against, various models and standards. Project management is a fundamental
requirement to achieve Level 2 against the Capability Maturity Model for
Software or to be certified against ISO 9001.
Effective project management requires more than implementing
a set of basic functions, however. It
implies selecting qualified people who can work together effectively,
structuring decision making processes both internally and externally, managing
customer expectations, monitoring progress, managing risks, and taking
corrective action as appropriate. None
of these are easy, although there are a number of tools that can help.
This seminar is therefore a broad survey of a variant of
project management styles and techniques, as used in diverse environments. The perspective of the discussion is that of
“mature” processes, i.e., processes that are well-defined, managed, measured,
controlled, and effective.
Multi-day courses.
The “Building Mature Software Processes” course addresses the software engineering and management practices of high maturity organizations as rated against the Capability Maturity ModelÒ for Software (CMMÒ) or CMM Integration (CMMIÒ). High maturity is addressed from three perspectives: 1) recommended best practices for a variety of environments; 2) empirical data on what high maturity organizations do; and 3) interpreting the practices in models such as the Software CMM and CMMI.
In studying the concepts and practices underlying mature
processes, the course addresses the application of measurement and statistical
insight to software development and maintenance. This includes issues
associated with effectively implementing statistical process control (SPC) to
manage and improve software processes. Specific engineering and management tools
and techniques are discussed at a fairly high level of abstraction; detailed
implementation knowledge is not provided.
This course is primarily intended for software professionals responsible for assessing and/or improving software engineering processes. Secondary audiences include executives and managers sponsoring software process improvement and software professionals involved with software process management and improvement.
Participants will learn about:
· the systematic principles for organizational transformation underlying the CMM work
· practical tips for effective process definition and improvement
· integrating effective project management techniques and process improvement priorities
· a variety of approaches, e.g., agile methods, consistent with process discipline
· tips for establishing a measurement program
· adopting a measurement-driven approach to daily work
· cultural shifts intrinsic to true high maturity
This is a five-day course, running from 8:30 AM until 4:30 PM. The lecture and exercises part of the course finishes around lunchtime on Friday, and Friday afternoon is available for questions and discussions of high maturity issues.
1.
Introduction
Who is participating in this course? What are their expectations? What is a mature process?
2.
Software Process Improvement in
Context
What is the Software
CMM? Total Quality Management and standards such as ISO 9000? How do concepts
such as “adequacy” and “goodness” affect process
improvement? What is a “best practice?”
What are some useful sources of best practices?
3.
Culture, Organizational
Psychology, and Change
How do
national and ethnic cultures affect the software process? Organizational cultures? How do different cultures deal with change?
4.
The Foundation for Quality
work: People
Do we treat
people as our greatest asset in software engineering? What differences between people should we be
aware of? What systematic biases and
fallacies should be addressed? How can
we build high performance teams?
5.
Customer-Supplier Relationships
Can mature software processes function effectively with immature customers? What enables suppliers to manage immature customers? How can more mature customer-supplier relationships be built?
6.
Software Project Management
Can software projects be managed in a dynamic business
environment? What management strategies
are most appropriate for software projects?
7.
Software Engineering Processes
Can software
development and maintenance incorporate engineering discipline? What are some effective engineering
processes? Can agile methodologies such
as Extreme Programming satisfy the requirements for mature processes?
8.
Support Processes
What support
processes are necessary for mature processes to function? What are the implications of maturity for
configuration management? Quality assurance?
Peer reviews? Decision
making?
9.
Organizational Learning and
Institutionalization
What is
institutionalization? Does software
engineering exist as a profession? How
do standardization and organizational learning interact? Process discipline and
process improvement?
10.
Measurement
Should measurement be
intrinsic to mature processes? What are operational definitions, and why should I care? What factors underlie successful measurement
programs?
11.
Basic Statistics for Software
Engineers
What are the seven basic SPC tools? What is regression analysis? A test of hypotheses? Analysis of variance?
12.
Analyzing Process Behavior
What is a control chart (or process behavior chart)? How are they useful in a software environment? What do terms like rational sample and homogenous subgroup imply? What are some of the challenges to using SPC appropriately?
13.
High Maturity in the Software
CMM and CMMI
What is the relationship between Level 4 in the Software CMM and CMMI and SPC? What topics should be in those models – but aren’t? What is the relationship between Level 5 and innovation? Incremental change? How does organizational culture change at Level 5?
14.
Conclusions and Beginnings
How do I get started on building mature processes?
Ò Capability Maturity Model, CMM, and CMMI are registered with the U.S. Patent and Trademark Office by Carnegie Mellon University.