ST07

CMM CMMI

CFICSE 2002 – ST07

Michelle L. Crane

CFICSE 2002 / ST07 - 2

ReferencesReferencesJames W. Moore, Software Engineering

Standards: A User’s Road Map, IEEE Computer Society, 1998.

www.software.org/quagmire www.sei.cmu.edu

publicationsCMM, etc.

Walker Royce, CMM vs. CMMI: From Conventional to Modern Software Management, www.therationaledge.com

Winifred Menezes, To CMMI or Not to CMMI: Issues to Think About. CrossTalk. Feb 2002.

CFICSE 2002 / ST07 - 3

OutlineOutline

Review of MotivationReview of SW-CMM

SW-CMM Maturity LevelsKey Process Areas (KPAs)Evaluation

SCESCDE

Problems with SW-CMM

CFICSE 2002 / ST07 - 4

Outline (cont’d)Outline (cont’d)

Other Capability Maturity ModelsSA-CMMP-CMMSE-CMMSSE-CMMIPD-CMM

CMMIPurpose of CMMICMMI Maturity LevelsRepresentations

CFICSE 2002 / ST07 - 5

Standards We Will LoveStandards We Will LoveDoD-Std2167A

ISO/IEC12207

EIA/IEEEJ-Std-016

Mil-Std498

IEEE/EIAStd 12207

Reference: http://www.software.org/quagmire/

SW CMM

ISO 9000series

supersedesbased onuses/references

CFICSE 2002 / ST07 - 6

But Not Just SW CMMBut Not Just SW CMM

SW CMM

CFICSE 2002 / ST07 - 7

SW-CMMSW-CMM

CFICSE 2002 / ST07 - 8

SW-CMM HistorySW-CMM History November 1986, the SEI and Mitre Corporation

begin developing process maturity framework 1987, a short article and questionnaire released

provide vehicle to identify areas in need of process improvement

1991, the Software Capability Maturity Model (SW-CMM) version 1.0 released; 1993, SW-CMM version 1.1 released (31 drafts to this point)

1996, work on SW-CMM version 2.0 begins; ends in October 1997 with draft ‘C’

CFICSE 2002 / ST07 - 9

Review of MotivationReview of Motivation

CFICSE 2002 / ST07 - 10

Motivating ObservationsMotivating Observations

productivity and quality gains from methodologies and technologies not near what was expected

difficult to do better in a chaotic processin undisciplined organizations, most projects

produce poor resultsin undisciplined organizations, some projects

produce excellent resultsusually the result of heroic effortrepeating the result means repeating the heroics

CFICSE 2002 / ST07 - 11

The Immature OrganizationThe Immature Organization

processes improvisedif process specified, it is not followedmanagers focuses on “fighting fires”schedules and budgets routinely exceededquality and function compromised to meet

scheduleno objective basis for judging product

qualityquality-related activities often eliminated

due to schedule pressures

CFICSE 2002 / ST07 - 12

The Mature OrganizationThe Mature Organization

organization-wide ability for managing development and maintenance

process communicated to staff; staff follow process

processes are “fit for use”processes are updated as necessary

CFICSE 2002 / ST07 - 13

The Mature Organization (cont’d)The Mature Organization (cont’d)

improvements developed through controlled pilot projects or cost/benefit analysis

managers monitor quality against an objective basis

schedules and budgets are realisticexpected results are usually achieved

CFICSE 2002 / ST07 - 14

Review of SW-CMMReview of SW-CMM

CFICSE 2002 / ST07 - 15

SW-CMM (or CMM)SW-CMM (or CMM)

Capability Maturity Model for Softwaremodel for

judging the maturity of the software processes of an organization

for identifying the key practices that are required to increase the maturity of these processes

developed by the software community with stewardship by the SEI

has become a de facto standard for assessing and improving software processes

Reference: www.sei.cmu.edu/cmm/cmm.html

CFICSE 2002 / ST07 - 16

SW-CMM (cont’d)SW-CMM (cont’d)

used as a standard for appraising the current state of an organization’s software process

used as a guide for identifying and prioritizing the actions comprising the software process improvement effort

made up of 5 levels and 18 key process areasa CMM-based maturity questionnaire may be

used to assess the software capability of a particular organization

CFICSE 2002 / ST07 - 17

SW-CMM Maturity LevelsSW-CMM Maturity Levels

Initial(1)

Repeatable(2)

Defined(3)

Managed(4)

Optimizing(5)

Basic ManagementControl

ProcessDefinition

ProcessMeasurement

ProcessControl

CFICSE 2002 / ST07 - 18

The Five Levels of SW-CMMThe Five Levels of SW-CMM

Level 1—Initialsoftware process is ad hoc, maybe even chaoticfew processes are defined; success depends on individual effort and heroics

Level 2 – Repeatablebasic project management practices to track cost, schedule, functionality

necessary process discipline is in place to repeat earlier successes on projects with similar applications

Reference: www.sei.cmu.edu/cmm/cmm_sum.html

CFICSE 2002 / ST07 - 19

The Five Levels of SW-CMM (cont’d)The Five Levels of SW-CMM (cont’d)

Level 3 – Definedsoftware process for both management and engineering activities is documented, standardized, integrated into a standard software process

all projects use an approved, tailored version of the organization’s standard software process for developing and maintaining software


CFICSE 2002 / ST07 - 20

The Five Levels of SW-CMM (cont’d)The Five Levels of SW-CMM (cont’d)

Level 4 – Manageddetailed measures of the software process and product quality are collected

both the software process and products are quantitatively understood and controlled

Level 5 – Optimizedcontinuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies


CFICSE 2002 / ST07 - 21

SW-CMM StructureSW-CMM Structure

CFICSE 2002 / ST07 - 22

Key Process Areas (KPAs)Key Process Areas (KPAs)

each maturity level (except 1) is decomposed into several key process areas that indicate the areas an organization should focus on to improve its software process

a cluster of related activities which collectively achieve a set of important goals

when the goals are accomplished on a continuing basis, the KPA is said to be institutionalized

CFICSE 2002 / ST07 - 23

Key Process Areas (cont’d)Key Process Areas (cont’d)

KPAs are enhanced in succeeding levelsto achieve a maturity level, the KPA for

that level must be satisfiedthere are other processes deemed to be

not key to achieving a maturity level; they are not addressed by the model

CFICSE 2002 / ST07 - 24

Key Process Areas (KPA)Key Process Areas (KPA)

Level 1 has none by definition

Level 2software project concerns related to establishing basic project management controls

requirements managementsoftware project planningsoftware project tracking and oversightsoftware subcontract managementsoftware quality assurancesoftware configuration management


CFICSE 2002 / ST07 - 25


Level 3address both project and organizational issues

organizational process focusorganizational process definitiontraining programintegrated software managementsoftware product engineeringintergroup coordinationpeer reviews


CFICSE 2002 / ST07 - 26


Level 4focus on establishing a quantitative understanding of both the software process and the software work products being built

process measurement and analysisquality managementdefect prevention


CFICSE 2002 / ST07 - 27


Level 5cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement

technology innovationprocess change management


CFICSE 2002 / ST07 - 28

Key PracticesKey Practices

each Key Process Area is described in terms of the key practices that contribute to satisfying its goals

describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the key process area


CFICSE 2002 / ST07 - 29

Common FeaturesCommon FeaturesCommitment to Perform (CO)

groups all generic practices related to creating policies and securing sponsorship for process improvement efforts.

Ability to Perform (AB)groups all generic practices related to ensuring that the project

and/or organization has the resources it needs to pursue process improvement.

Directing Implementation (DI) groups the generic practices related to collecting, measuring, and

analyzing data related to processes. The purpose of these activities is to provide insight into the performance of processes.

Verifying Implementation (VE) groups all generic practices related to verifying that the projects

and/or organization’s activities conform to requirements, processes, and procedures.

CFICSE 2002 / ST07 - 30

State of the IndustryState of the Industry

Goal for most organizations is to achieve Level 3.

Royce

CFICSE 2002 / ST07 - 31

EvaluationEvaluation

one instrument for assessing is a software capability evaluation (SCE)

determines whether the organization “says what it does and does what it says”

by evaluating its software process (usually in the form of policy statements) and project practices

process captures “say what you do”project implementations demonstrate “do what you say”

Reference: Royce, CMM vs. CMMI

CFICSE 2002 / ST07 - 32

Back to the MapBack to the Map

CFICSE 2002 / ST07 - 33

SCESCE

Software Capability Evaluationpublished: Version 3.0, April 1996

method for evaluating the software process of an organization to gain insight into its process capability

version 3.0 based on SW-CMM version 1.1SCE team conducts a document review and

extensive interviewsobserved strengths and weaknesses are formally documented and then used to determine risk for a particular development

Reference: www.software.org/quagmire

CFICSE 2002 / ST07 - 34

SCE (cont’d)SCE (cont’d)

SCEs are designed to be used insource selection

help select a qualified contractorcontract monitoring

identify risksmeasure performance for incentive feesbaselining organizational performance

SCE does NOT determine an SEI SW-CMM Level


CFICSE 2002 / ST07 - 35


CFICSE 2002 / ST07 - 36

SCDESCDESoftware Development Capability Evaluation

published: 15 Jun 95structured methodology for assessing an

organization’s ability to develop software for mission-critical computer resources

primary purpose is to reduce acquisition risk for software-intensive systems

conducted as an integral part of the source selection process

addresses each offerer’s ability to develop the software required by a specific Request for Proposal


CFICSE 2002 / ST07 - 37

Problems with SW-CMMProblems with SW-CMM

CFICSE 2002 / ST07 - 38

Issues with the CMMIssues with the CMM

key process areas (KPAs) focus mostly on activities and supporting artifacts associated with a conventional waterfall process

requirements specifications, documented plans, quality assurance audits and inspections, and documented processes and procedures

very few of the KPAs address the evolving results (i.e., the software product) and associated engineering artifacts (use case models, design models, source code, or executable code)


CFICSE 2002 / ST07 - 39

Issues (cont’d)Issues (cont’d)

no emphasis on the architecting/design process, assessment process, or deployment process

which have proven to be key discriminators for project success

also overemphasizes peer reviews, inspections and traditional Quality Assurance “policing” methods

although manual reviews and inspections may be capable of uncovering 60% of errors, they rarely uncover the architecturally significant flaws…


CFICSE 2002 / ST07 - 40


most implementations of CMM drive organizations to produce more documents, more checkpoints, more artifacts, more traceability, more reviews, and more plans

thicker documents, more detailed information, and longer meetings are considered better


CFICSE 2002 / ST07 - 41


hard to accurately measure an organization’s current maturity level

CMM takes an activity based approach to measuring maturity

set of foundation project activities = Level 2

set of activities as an organization = Level 3

nothing that characterizes or quantifies whether you do these activities well enough to deliver the intended results


CFICSE 2002 / ST07 - 42

More Short-Comings of CMMMore Short-Comings of CMM

not a silver bulleta mature process is no guarantee of a quality product

not well suited for smaller companies/projects

Personal Software Process (PSP) is one attempt to address this need

crude and harsh 5-point scaleif you fail just one of the KPAs, you fail the level

CFICSE 2002 / ST07 - 43

Evolution of CMMEvolution of CMM

initial Capability Maturity Model was developed specifically to address software process maturity

it was successfully adopted and used in many domains

other CMMs were developed for other disciplines and functions

CMMs now exist for software, people, software acquisition, systems engineering, and integrated product development

CFICSE 2002 / ST07 - 44

Other Capability Maturity Models

Other Capability Maturity Models

CFICSE 2002 / ST07 - 45


CFICSE 2002 / ST07 - 46

SA-CMMSA-CMMSoftware Acquisition Capability Maturity Model

published: Version 1.01, December 1996a model for benchmarking and improving the

software acquisition processfollows the same architecture as the Capability

Maturity Model for Software (SW-CMM), but with a unique emphasis on

acquisition issuesneeds of individuals/groups planning software

acquisition effortsfocused on the Buyer’s or Acquirer’s Software

Acquisition Process


CFICSE 2002 / ST07 - 47

SA-CMM Maturity LevelsSA-CMM Maturity LevelsLevel Focus Key Process Areas

Level 5Optimizing

Continuous process improvement

Acquisition Innovation ManagementContinuous Process Improvement

Level 4Quantitative

Quantitative management

Quantitative Acquisition ManagementQuantitative Process Management

Level 3Defined

Process standardization

Training ProgramAcquisition Risk ManagementContract Performance ManagementProject Performance ManagementProcess Definition and Maintenance

Level 2Repeatable

Basic project management

Transition to SupportEvaluationContract Tracking and OversightProject ManagementRequirements Development and ManagementSolicitationSoftware Acquisition Planning

Level 1Initial

Competent people and heroics

No KPAs at this levelReference: www.software.org/quagmire

CFICSE 2002 / ST07 - 48


CFICSE 2002 / ST07 - 49

P-CMMP-CMM

People Capability Maturity Modelpublished: July 2001

describes the key elements of managing and developing the work force of an organization

describes an evolutionary path from an ad hoc approach to managing the workforce

to a mature, disciplined development of the knowledge, skills, and motivation of the people that fuel enhanced performance


CFICSE 2002 / ST07 - 50

P-CMM (cont’d)P-CMM (cont’d)

purpose is to enhance the readiness of software development and information systems organizations to undertake increasingly complex applications by helping them to attract, grow, motivate, deploy, and retain the talent necessary to improve their software development capability


CFICSE 2002 / ST07 - 51

P-CMM Maturity LevelsP-CMM Maturity LevelsLevel Key Process Areas

Level 5Optimizing

Continuous Workforce InnovationCoachingPersonal Competency Development

Level 4Managed

Organizational Performance AlignmentOrganizational CompetencyManagementTeam-Based PracticesTeam BuildingMentoring

Level 3Defined

Participatory CultureCompetency-Based PracticesCareer DevelopmentCompetency DevelopmentWorkforce PlanningKnowledge and Skills Analysis


CFICSE 2002 / ST07 - 52

P-CMM Maturity Levels (cont’d)P-CMM Maturity Levels (cont’d)Level Key Process Areas

Level 2Repeatable

CompensationTrainingPerformance ManagementStaffingCommunicationWork Environment

Level 1Initial

No KPAs at this level


CFICSE 2002 / ST07 - 53


CFICSE 2002 / ST07 - 54

SE-CMMSE-CMMSystems Engineering Capability Maturity Model

published: November 1995describes the essential elements of an

organization’s systems engineering process that must exist to ensure good systems engineering

18 process areas (PAs) are grouped into categories

EngineeringProjectOrganization


CFICSE 2002 / ST07 - 55

SE-CMM (cont’d)SE-CMM (cont’d)still 5 levels (counted in each PA?)

1 – Generic Practices2 – Planned and Tracked3 – Well-Defined4 – Quantitatively Controlled5 – Continuously Improving

built onto the Software CMM frameworkbut used the two-axis architecture of the ISO SPICE model

replaced SECM merged systems engineering model (EIA/IS 731)


CFICSE 2002 / ST07 - 56


CFICSE 2002 / ST07 - 57

SSE-CMMSSE-CMM

Systems Security Engineering CMMpublished: 1 Apr 99 (Version 2.0)

describes the essential characteristics of an organization’s security engineering process that must exist to ensure good security engineering

objective is to advance security engineering as a defined, mature, and measurable discipline

…


CFICSE 2002 / ST07 - 58


CFICSE 2002 / ST07 - 59

IPD-CMMIPD-CMM

Integrated Product Development Capability Maturity Model

published: no longer published; halted in Nov 1997

developed by Enterprise Process Improvement Collaboration (EPIC)

to serve as a framework for improvement of

processes for the entire product life cycle and processes for integrating product development efforts across the enterprise


CFICSE 2002 / ST07 - 60

IPD-CMMIPD-CMM

built on a continuous model architecture like the Systems Engineering CMM

adds the concept of organizational stages, similar to organizational maturity levels in the SW-CMM

development halted in Nov 1997model had serious problems with complexity, overlap with other models, and lack of IPD content beyond team practices

EPIC decided to end the development and provide content to the CMMI effort


CFICSE 2002 / ST07 - 61

So Many CMMsSo Many CMMs

many organizations found these models to be useful

but struggled with problems caused by overlap, inconsistencies, and integration

many organizations also confronted conflicting demands between these models and ISO 9001 audits or other process improvement programs


CFICSE 2002 / ST07 - 62


CFICSE 2002 / ST07 - 63

IntegrationIntegration

CMM Integration (CMMI) project was conceived as an initiative to integrate the various CMMs into a set of integrated models

reduce redundancy and eliminate inconsistency experienced by those using multiple standalone models


CFICSE 2002 / ST07 - 64

Overview of CMMIOverview of CMMI

CFICSE 2002 / ST07 - 65

CMMICMMI

Capability Maturity Model Integrationpublished: draft version 1.02b, Dec 2001

includedsystems engineering and softwareIPPD (integrated product and process development)

some acquisition (draft)US DoD tasked the Software Engineering

Institute (SEI) to integrate the capability maturity model

SEI is the current steward of the CMMI model


CFICSE 2002 / ST07 - 66

CMMI (cont’d)CMMI (cont’d)

source modelsSW-CMM version 2.0 draftEIA/IS 731 SECM (which replaced SE-CMM)draft version of IPD-CMM (integrated product development)

some items from SA-CMMthese sources will no longer be updated or

supported by their issuing organizationsgoal is to absorb more source models in

the same way


CFICSE 2002 / ST07 - 67

CMMI Product Suite NamingCMMI Product Suite Naming

each CMMI model is given a name consisting of “CMMI-” followed by the abbreviation for the discipline

CMMI-SE/SW – systems engineering and software engineering integrated model

CMMI-SE/SW/IPPD – systems engineering, software engineering, integrated product and process development integrated model

CMMI-SE/SW/IPPD/SS - systems engineering, software engineering, integrated product and process development, supplier sourcing integrated model

Reference: www.sei.cmu.edu/cmmi/adoption/cmmi-faq.html

CFICSE 2002 / ST07 - 68

Purpose of CMMIPurpose of CMMI

to provide guidance for improving the organization’s processes and ability to manage the

developmentacquisitionmaintenance

of products and services

Reference: www.sei.cmu.edu/cmmi/general/

CFICSE 2002 / ST07 - 69

Purpose of CMMI (cont’d)Purpose of CMMI (cont’d)

places proven practices into a structure that helps the organization

assess its organizational maturity and process area capability

establish priorities for improvementguide the implementation of these improvements

Reference: www.sei.cmu.edu/cmmi/general/

CFICSE 2002 / ST07 - 70

Purpose of CMMIPurpose of CMMI

CMMI is a framework that describes the essential elements of an effective system or software engineering process

in the software context, forms the basis forsoftware process assessmentsoftware process improvementsoftware capability evaluation

related to ISO Software Process Improvement and Capability Evaluation (SPICE) program and ISO 15504

CFICSE 2002 / ST07 - 71

Core ConceptsCore Concepts

Software Process Capabilitythe range of expected results that can be achieved by following a software process

Software Process Performancethe actual results achieved by following a software process

Software Process Maturitythe extent to which a specific process is explicitly defined, managed, measured, controlled, and effective

CFICSE 2002 / ST07 - 72

CMMI Maturity LevelsCMMI Maturity Levels

Initial(1)

Managed(2)

Defined(3)

QuantitativelyManaged

(4)

Optimizing(5)

Disciplinedprocess

Standard,consistent

process

Predictableprocess

Continuouslyimprovingprocess

CFICSE 2002 / ST07 - 73

CMMI Maturity LevelsCMMI Maturity Levels

Initial(1)

Managed(2)

Defined(3)

QuantitativelyManaged

(4)

Optimizing(5)

Disciplinedprocess

Standard,consistent

process

Predictableprocess

Continuouslyimprovingprocess

Initial(1)

Repeatable(2)

Defined(3)

Managed(4)

Optimizing(5)

Basic ManagementControl

ProcessDefinition

ProcessMeasurement

ProcessControl

SW-CMMSW-

CMM

Not capability levels

CFICSE 2002 / ST07 - 74

Levels and Process AreasLevels and Process Areas

elements of CMMI are called Process Areas (not Key Process Areas or Focus Areas)


CFICSE 2002 / ST07 - 75

The Five Maturity Levels of CMMIThe Five Maturity Levels of CMMI

Level 1 – Initialprocess maturity characterized by unpredictable results

ad hoc approaches, methods, notations, tools, and reactive management

translate into a process dependent predominantly on the skills of the team to succeed


CFICSE 2002 / ST07 - 76

The Five Maturity Levels of CMMI (cont’d)The Five Maturity Levels of CMMI (cont’d)

Level 2 – Managedprocess maturity characterized by repeatable project performance

organization uses foundation disciplines forrequirements managementproject planningproject management and controlsupplier agreement managementproduct and process quality assuranceconfiguration managementmeasurement/analysis

key process focus is on project-level activities and practices


CFICSE 2002 / ST07 - 77


Level 3 – Definedprocess maturity characterized by improving project performance within an organization

consistent, cross-project disciplines for Level 2 key process areas are emphasized to establish organization-level activities and practices

additional process areasrequirements development

multi-stakeholder requirements evolutiontechnical solution

evolutionary design and quality engineering


CFICSE 2002 / ST07 - 78


product integration continuous integration, interface control,

change managementverification

assessment techniques to ensure that the product is built correctly

validation assessment techniques to ensure that the

right product is builtrisk management

detection, prioritization, and resolution of relevant issues and contingencies


CFICSE 2002 / ST07 - 79


organizational training establishing mechanisms for developing more

proficient peopleorganizational process focus

establishing an organizational framework for project process definition

decision analysis and resolution systematic alternative assessment

organizational process definition treatment of process as a persistent, evolving asset

of an organizationintegrated project management

methods for unifying the various teams and stakeholders within a project


CFICSE 2002 / ST07 - 80


Level 4 – Quantitatively Managedprocess maturity characterized by improving organization performance

historical results for Level 3 projects can be exploited to make trade offs with predictable results

additional Level 4 process areas includeorganizational process performance

setting norms and benchmarks for process performance

quantitative project management executing projects based on statistical quality-control

methods


CFICSE 2002 / ST07 - 81


Level 5 – Optimizedprocess maturity characterized by rapidly reconfigurable organizational performance

as well as quantitative, continuous process improvement

additional Level 5 process areas includecausal analysis and resolution

proactive fault avoidance and best practice reinforcement

organizational innovation and deployment establishing a learning organization that

organically adapts and improves


CFICSE 2002 / ST07 - 82

Representations (cont’d)Representations (cont’d)

two representationsprovide alternative approaches to process improvement for familiarity with either approach

represent two different philosophical approaches to process improvement

Reference: Menezes, CrossTalk; www.stsc.hill.af.mil/cmmi/more_cmmi.asp

CFICSE 2002 / ST07 - 83


1. focus on the organization as a whole and provide a road map of successive stages aimed at improving the organization’s ability to understand and control its process

staged view (comparable to SW-CMM)2. focus on individual processes, allowing

the organization to choose which process or set of processes need to have more capability

continuous view (comparable to systems engineering and IPD models)

Reference: Menezes, CrossTalk

CFICSE 2002 / ST07 - 84


each representation is a 600 page document

equivalent stagingsometimes desirable to convert an organization’s capability level achievements into a maturity level

can translate back and forth betweenCMMI includes rules for determining which capability levels must be satisfied in each process area to achieve each maturity level

Reference: Menezes, CrossTalk; www.stsc.hill.af.mil/cmmi/more_cmmi.asp

CFICSE 2002 / ST07 - 85

ContinuousContinuous

groups process areas intoprocess managementproject managementengineeringsupport

for each process area, assigns a rating from 0 to 5, according to an organization’s performance

CFICSE 2002 / ST07 - 86

StagedStaged

groups process areas by maturity levelallows an overall assessment leading to

an assessment of the maturity level observed in an organization

CFICSE 2002 / ST07 - 87

Some Differences between RepresentationsSome Differences between Representations

Continuous Staged

process areas organized by process area categories

process areas organized by maturity levels

six capability levels (0-5) five maturity levels (1-5)

improvement is measured using capability levels that reflect incremental implementation of a particular process area

improvement is measured using maturity levels that reflect the concurrent implementation of multiple process areas

additional appendix describing equivalent staging; allows translation of a target profile into a maturity level

no equivalence concept to go from maturity level to a target profile

Reference: www.sei.cmu.edu/cmmi/adoption/cmmi-faq.html

CFICSE 2002 / ST07 - 88

SummarySummary

Review of MotivationReview of SW-CMM

Problems with SW-CMMOther Capability Maturity Models

SA-CMM, P-CMM, SE-CMM, SSE-CMM, IPD-CMM

CMMIPurpose of CMMICMMI Maturity LevelsRepresentations

CFICSE 2002 / ST07 - 89

??

Technology

ST07