prove.,2-11

'8 andJf the180ft.

:tured981).

, "Angs of

;ility,

lSure->4-73

ring,"

;wareitute,

Soft-neer.

iruy-

mentware[arch

.allylSa~thSEImse'ISOsive

sys.IonSEI'wc,Igy-

;ion.ingmd:ac-19i-entIve-ingled

luse of standards of excellence for software engineeringpractice.

The institute explores promising solutions to poten-tially significant problems, selects the best candidate solu-tions, and works on them to determine their value. ln somecases, the SEI works to overcome the limitations that pre-vent a solution from being of general use in the softwarecommunity. Finally, the SEI moves mature solutions ofproven value into widespread use; examples include theCapability Maturity Model@ for Software (SW-CMM@),described below, and a model curriculum for a master'sdegree program in software engineering that has beenadopted by universties across the country.

SEI activities are grouped into two principal areas: soft-ware engineering management practices and softwareengineering technical practices.

SOFTWARE ENGINEERING MANAGEMENT PRACTICES

The ability to effectively manage the acquisition, develop-ment, and evolution of software-intensive systems is a cri-tical requirement of software-intensive sys~ms and thusis emphasized in the SEI program of work. Success inthis area increases the ability of software engineeringorganizations to predict and control quality, schedule,cost, cycle time, and productivity when acquiring, build-ing, and enhancing software systems.

The most widely known aspect of this work is Capabil-ity Maturity Modeling@. Capability Maturity Models(CMMs) provide structured, integrated collections of bestpractices that organizations can use to improve their per-formance. The SW-CMM is a model for assessing thematurity of the software processes of an organizationand for identifying the practices that are required toincrease the maturity of these processes. The SW-CMMhas become a de facto standard for assessing and improv-ing software processes and has been adopted by more than5,000 organizations worldwide.

The CMM approach for improvement has been appliedto disciplines other than software development, such assystems engineering and integrated product and processdevelopment (IPPD). As organizations have sought a wayto successfully and easily integrate their CMM-basedimprovement activities, the SEI has collaborated with gov-ernment and industry organizations to develop a means ofintegrating maturity models and their associated products(training, assessment instruments, etc.). The CapabilityMaturity Model Integration (CMMIsM) project, sponsoredby the Office of the Under Secretary of Defense and theNational Defense Industrial Association (NDIA), is inte-grating several CMMs into a more general framework tosupport enterprisewide improvement.

The SEI has also developed the Team SoftwareProcessSM, which enables development teams to reducesystem-test time and increase software quality by an orderof magnitude.

SOFTWARE ENGINEERING TECHNICAL PRACTICES

SEI technical work aims to improve the ability of softwareengineers to analyze, predict, and control selected func-

--

SOFTWARE ENGINEERING BODY OF KNOWLEDGE PROJECT 1401

tional and nonfunctional properties of software systems.Work is primarily focused on defining, maturing, andaccelerating the adoption of improved technical engineer-ing knowledge, processes, and tools.

One SEI initiative concentrates on "survivable sys-tems"-ensuring that appropriate technology and prac-tices are used to prevent successful attacks on networkedsystems and to limit the damage caused by successfulattacks. This work builds on SEI experience with theCERT@ Coordination Center (formerly the ComputerEmergency Response Team), which counters intrusionsinto systems connected to the Internet, identifies securityflaws that permit intrusions, and works to eliminate thoseflaws.

Another SEI initiative focuses on techniques for pre-dicting the effect of software architecture decisions on aset of desirable system properties. Still others address avariety of technical issues: identifying and exploiting com-monalities that exist across software systems in particulardomains, evaluating and integrating commercial off-the-shelf (COTS) components into mission-critical systemswhile preserving key qualities, and performing incremen-tal and online system upgrades even in the presence offaults caused by the upgrades. .

The SEI believes that software organizations will con-tinue to be expected to do more with less. The SEI programwill continue to concentrate on key software engineeringproblems and on facilitating the widespread adoption ofimprovements that bring management discipling andengineering insight to the practice of software engineering.

STEPHEN E. CROSS

SEI

SOFTWARE ENGINEERING BODYOF KNOWLEDGE PROJECT

Identifying an agreed body of knowledge is an essentialstep in moving software engineering from an ideal to arecognized profession. Sponsored by the IEEE ComputerSociety.and managed by the Université du Québec àMontréal, the Software Engineering Body of Knowledge(SWEBOK) project is developing a guide to the body ofknowledge of software engineering. A trial version of theguide is currently available without charge at http://www.swebok.org. Following an additional two years oftrial usage and feedback, the project will revise the Guide.

This article will begin by discussing the desiredcharacteristics of a profession for software engineering.Then the objectives and contents of the Guide aredescribed. Finally, the SWEBOK project and its futurewill be described.

A SOFTWARE ENGINEERING PROFESSION

ln spite of the millions of software professionals worldwideand the ubiquitous presence of software in our society,software engineering has not yet reached the status of alegitimate engineering discipline and a recognized profe-ssion. ln his Pulitzer-prize-winning book on the history

1402 SOFTWARE ENGINEERING BODY OF KNOWLEDGEPROJECT

ofthe medical profession in the Unites States, Starr (1982)states that:

The legitimization of professional authority involves three dis-tinctive daims: first, that the knowledge and competence oftheprofessional have been validated by a community of his or herpeerSj second, that this consensually validated knowledgerests on rational, scientific grounds; and third, that the profe-ssional'sjudgment and advice are oriented toward a set ofsub-stantive values, such as health. These aspects of legitimacycorrespond to the kinds of attributes-collegial, cognitive andmoral-usually cited in the term "profession."

Starr's description notes the importance of consensuallyvalidated knowledge. How is that knowledge to be applied?Gary Ford and Norman Gibbs (1996) studied severalrecognized professions including medicine, law, engineer-ing and accounting. They concluded that an engineeringprofession is characterized by several components:

. An initial professional education in a curriculumvalidated by society through accreditation. Registration of fitness to practice via voluntary cer-tification or mandatory licensing. Specialized skill development and continuing profe-ssional education. Communal support via a professional society. A commitment to norms of conduct often prescribedin a code of ethics

The SWEBOK project was formed to address the first threeof these components. Articulating a body of knowledge isan essential step toward developing a profession becauseit represents a broad consensus regarding what a softwareengineering professional should know. Without such a con-sensus, no licensing examination can be validated, no cur-riculum can prepare an individual for an examination, andno criteria can be formulated for accrediting a curriculum.The development of the consensus is also prerequisite tothe adoption of coherent skill development and continuingprofessional education programs in organizations.

ORGANIZATION OF THE SWEBOK GUIDE

The purpose of the SWEBOK Guide is to provide a consen-sually validated characterization of the bounds of the soft-ware engineering discipline and to provide a topical accessto the body of knowledge supporting that discipline. Thebody of knowledge is subdivided into ten knowledge areasand the descriptions of the knowledge areas are designedto discriminate among the various important concepts,permitting readers to find their way quickly to subjectsof interest. Upon finding a subject, readers are referredto key papers or book chapters selected because they suc-cinctly present the knowledge.

The content of the SWEBOK Guide is markedly differ-ent from computer science. Just as electrical engineeringis based upon the science of physics, software engineeringshould be based on computer science. ln both cases,though, the emphasis is necessarily different. Scientists

extend our knowledge of the laws of nature while engi-neers apply those laws of nature to build useful artifacts,under a number of constraints. Therefore, the emphasis ofthe guide is placed on the construction of useful softwareartifacts. .

Many important aspects of information technology arenot covered in the guide, for example, specific program-ming languages, relational databases and networks. Thisis a consequence of an engineering-based approach. ln aIlfields-not only computing-the designers of engineeringcurricula have realized that specific technologies arereplaced much more rapidly than the engineering workforce. An engineer must be equipped with the essentialknowledge that supports the selection of the appropriatetechnology at the appropriate time in the appropriatecircumstance. For example, software systems might bebuilt in FORTRAN using functional decomposition or inC++ using object-oriented techniques. The techniquesfor integrating and configuring instances of those systemswould be quite different. But, the principles and objectivesof configuration management remain the same. TheSWEBOK Guide therefore does not focus on the rapidlychanging technologies, although their general principlesare described in relevant knowledge areas.

Therefore, the SWEBOK Guide does not cover aHknowledge that is essential to the practice of software engi-neering. Practicing software engineers will need to knowmany things about computer science, project managementand systems engineering-to name a few-that fall out-side the body of knowledge characterized by this guide.However, stating that this information should be knownby software engineers is not the same as stating that thisknowledge falls within the bounds of the software engi-neering discipline. The SWEBOK Guide characterizesonly the body of knowledge falling within the scope ofsoftware engineering.

The emphasis on engineering practice leads theSWEBOK Guide toward a strong relationship with thenormative literature. Most of the computer science, infor-mation technology and software engineering literatureprovides information useful to software engineers, but arelatively smaH portion is normative. A normative docu-ment prescribes what an engineer should do in a specifiedsituation rather than providing information that might behelpful. The normative literature is validated by consen-sus formed among practitioners and is concentrated instandards and related documents. From the beginning,the SWEBOK project was conceived as having a strongrelationship to the normative literature of software engi-neering. The two major standards bodies for software engi-neering (IEEE Software Engineering StandardsCommittee and ISOIIEC JTC1/SC7) are represented inthe project. [See INTERNATIONALSTANDARDSORGANIZATIONS,

SOFl'WAREENGINEERINGSTANDARDS,INSTlTUTEOF ELECI'RlCAL

ANDELECTRONICSENGINEERS(IEEE).] Ultimately, it is hopedthat software engineering practice standards will containprinciples trace able to the SWEBOK Guide. To this end,ISOIIEC JTCl/SC7 has taken steps to initiate the adoptionof the Trial Version of the Guide as an ISOIIEC TechnicalReport.

~

TObjectives of the SWEBOK Project

The SWEBOK Guide should not be confused with the bodyof knowledge itself. The body of knowledge already existsin the published literature. The purpose of the guide is todescribe what portion ofthe body ofknowledge is generallyaccepted, to organize that portion, and to provide a topicalaccess to it.

The Guide to the Software Engineering Body of Knowl-edge (SWEBOK) was established with the following fiveobjectives:

1. Promote a consistent view of software engineeringworldwide.

2. Clarify the place-and set the boundary-of soft-ware engineering with respect to other disciplinessuch as computer science, project management, com-puter engineering, and mathematics.

3. Characterize the contents of the software engineer-ing discipline.

4. Provide a topical access to the software engineeringbody of knowledge.

5. Provide a foundation for curriculum developJ.1lentand individual certification and licensing material.

A development process that has engaged approximately500 reviewers from 42 countries supported the first ofthese objectives, the consistent worldwide view of softwareengineering.

The second of the objectives, the desire to set a bound-ary, motivated the fundamental organization of theSWEBOK Guide. The material that is recognized as beingwithin software engineering is organized into 10 knowl-edge areas:

. Software requirements

. Software design

. Software construction

. Software testing

. Software configuration management

. Software engineering management. Software engineering process

. Software engineering tools and methods. Software maintenance

. Software quality

Each of the 10 knowledge areas is described in a chapter ofthe SWEBOK Guide.

ln establishing a boundary for software engineering, itis also important to identify the other disciplines thatshare a boundary and often a common intersection withsoftware engineering. To this end, the guide also recog-nizes seven related disciplines:

. Cognitive sciencE1s.and human factors'. Computer engineering. Computer science. Management and management science

... - .. .....

SOFTWAREENGINEERINGBODY OF KNOWLEDGE PRO/ECT 1403

. Mathematics. Project management. Systems engineering

Of course, software engineers should know material fromthese fields. However, it is not an objective of the SWEBOKGuide to characterize the knowledge of the related disci-plines.

Hierarchical Organization of the Guide

The organization of the knowledge area descriptions orchapters, shown in Figure 1, supports the third of the pro-ject's objectives--a characterization of the contents of soft-ware engineering.

The SWEBOK Guide uses a hierarchica1 organizationto decompose each knowledge area into a set of topieswith recognizable labels. A two- or three-Ievel breakdownprovides a reasonable way to find topies of interest. Theguide treats the selected topies in a manner compatiblewith major schools of thought and with breakdowns gener-ally found in industry and in software engineering litera-ture and standards. The breakdowns of tapies do notpresume particular application domains, business uses,management philosophies, development methods, and soforth. The extent of each topic's description is only thatneeded to understand the generally accepted nature ofthe topies and for the reader to successfully find referencematerial. After all, the body of knowledge is found in thereference materials, not in the guide itself.

References to the Literature

To provide a topical access to the knowledge-the fourth ofthe project's objectives--the SWEBOK Guide identifiesreference materials for each knowledge area includingbook chapters, refereed papers, or other well-recognizedsources of authoritative information. Each knowledgearea description also includes a matrix that relates the

Breakdown

of Topics

Matrix of Topicsand Reference

Materials

ReferenceMaterials

rn .....Topie

Descriptions

ReferencestoRelated

Disciplines

Oassiftcationby Bloom'sfuonomy

Figure 1. Organization of knowledge areas.

1404 SOFTWAREENGINEERING BODY OF KNOWLEDGE PROJECT

reference materials to the listed topics. The total volume ofcited literature is intended to be suitable for masterythrough the completion of an undergraduate educationplus four years of experience.

It should be noted that the guide is not comprehensivein its citations. Much material that is both suitable andexcellent is not referenced. Materials were selected be-cause they are written in English, readily available, easilyreadable, and-taken as a whole-provide coverage of thedescribed topics.

Depth of Treatment

ln its depth of treatment, the SWEBOK guide followsan approach that supports the firth of the project'sobjectives-providing a foundation for curriculum deve-lopment, certification, and licensing. It applies a criterionof generally accepted knowledge, which is distinguishedfrom advanced and research knowledge (on the groundsof maturity) and from specialized knowledge (on thegrounds of generality of application). A second definitionof generally accepted cornes from the PMI: "The generallyaccepted knowledge applies to most projects most of thetime, and widespread consensus validates its value andeffectiveness (Project Management Institute, 1996).

However, generally accepted knowledge does not implythat one should apply the designated knowledge uniformlyto aIl software engineering endeavors-each project'sneeds determine that-but it does imply that competent,capable software engineers should be equipped with thisknowledge for potential application. Additionally, theknowledge area descriptions are somewhat forward-looking-the guide considers not only what is generally-accepted today but also what could be generally acceptedin three to five years.

Ratings

As an aid notably, to curriculum developers, and in sup-port of the project's firth objective, the SWEBOK guiderates each topic with one of a set of pedagogical categoriescommonly attributed to Benjamin Bloom (1956). The con-cept is that educational objectives can be classified into sixcategories representing increasing depth: knowledge,comprehension, application, analysis, synthesis, andevaluation.

References to Related Disciplines

The knowledge area descriptions may also contain refer-ences to subjects within the seven related disciplines.

OVERVIEW OF THE SWEBOK GUIDE

Figure 2 maps the 10 knowledge areas and the importanttopics incorporated within them. The tirst five knowledgeareas are presented in tradition al waterfall life-cyclesequence. The subsequent knowledge areas are presentedin alphabetical order. This is identical to the sequence inwhich they are presented in the SWEBOK Guide. Briefsummaries of the knowledge area descriptions appear inthe next section.

Software Requirements

A requirement is defined as a property that must be exhib-ited in order to solve some problem of the real world.

The first knowledge subarea introduces the require-ments engineering process, orienting the remaining fivetopics and showing how requirements engineering dove-tails with the overall software engineering process. Itdescribes process models, process actors, process supportand management and process quality improvement.

The second subarea is requirements elicitation, which isconcerned with where requirements corne from and howthe requirements engineer can collect them. It includesrequirement sources and techniques for elicitation.

The third subarea, requirements analysis, is concernedwith the process of analyzing requirements to:

. Detect and resolve conflicts between requirements. Discover the bounds of the system and how it mustinteract with its environment. Elaborate system requirements to software require-ments.

Requirements analysis includes requirements classifica-tion, conceptual modeling, architectural design, require-ments allocation, and requirements negotiation.

The fourth subarea is software requirements specifica-tion. It describes the structure, quality and verifiabilityof the requirements document. This may take the form oftwo documents, or two parts of the same document withdifferent readership and purposes. The tirst document isthe system requirements definition document, and the sec.ond is the software requirements specification. Thesubarea also describes the document structure and stan-

dards and document quality.The firth sub-area is requirements validation, whose

aim is to pick up any problems before resources are com-mitte.d to addressing the requirements. Requirementsvalidation is concerned with the process of examining therequirements document to ensure that it defines the rightsystem (Le., the system that the user expects). It is subdi-vided into descriptions of the conduct of requirementsreviews, prototyping, model validation, and acceptancetests. .

The last sub-area is requirements management, whichis an activity that spans the whole software life cycle. Itis fundamentally about change management and themaintenance of the requirements in astate that accuratelymirrors the software to be, or that has been, built. Itincludes change management, requirements attributesand requirements tracing (see REQUIREMENTSMANAGE-MENT).

Software DesignÎ

Software design is an activity that spans the whole soft-ware life-cycle (see DESIGN).The knowledge area is dividedinto six subareas.

The tirst one presents the basic concepts and notionsthat form an underlying basis to the understanding ofthe role and scope of software design. These are general

..----..---...--...

-~

Guide to the Software Engineering Body of Knowledge(Version 0.9)

Requirement r SoftwareDesign r = ;;;pt;;:d Management of

tO-

...................

r- Softwarea"alityEngineeringBasicConcepts

-the SCM Process Management

Engineering Software Toois 1 ConceptsProcess Definitions ProcessConcepts_""""""",,,0 --- T_

Maintenance Software ProcessIProject Process

r- Definition &Requlrements Key Issues ln1

........eo....-. Process Management Infrastructure _Oeo91T_ PlanningforQuallty- TestLevels ConfigurationElicitation SoftwareDesign Identification _eo....-."""""""""""'"

T_ 1 r Technlqu9s

- KeyIssuesln Software ProcessSoftware Engineering Measurement _T_T_ RequiringTwo orRequirement SoftwareStructure .

LMaintenance Software Measurement More People

Test Techniques Configuration -..............Anatysis andArchitecture Control T_

-"""""""'" Techniquesfor ProcessDefinition -- r-SupporttoOther- Maintenance _T_ Technlqu&s...

Software Design

1

Fom1IIConIINctionSoftware

Requirements Test-Related SoftMre0u8IIy TooIIC> Specification

QualityAnatysis - Measures Configuration Qualitative Process

_ .J TestlngSpecial toVI And Fvs:ahlAtinn Status Aooounting AnatysisV....."""""""'" _T_ SQAorV&.V- Process --

Requlrements Software Designf.

Structuring for ManagingtheTestSoftware

Implementation_T_

Jr- DefectFindlngValidation Notations ,- Process Configuration

andChange -- TechniquesAudlting T__eo....-. MI8ceI81eouITootM_ -L. Software Design

1

- °Requirements ........Management

Strat&giesand -Methods """"eo....-. Dellvery ---Useof Extema!

_M_- FOfmIIIIMetI'Iod8

-"""""""'"-- _M_FonnII Conttructlon ---- -""""eo....-.--

(a) (b) (c) (d) (e) (1) (g) (h) (1) 0)

Figure 2. Breakdown ofknowledge areas in the SWEBOKguide. (@ IEEE-Stoneman (version 0.9)-February 2001.)

1406 SOFTWAREENGINEERING BODY OF KNOWLEDGE PROJECT

concepts, the context of software design, the design processand the enabling techniques for software design.

The second subarea presents the key issues of softwaredesign. They include concurrency, control and handling ofevents, distribution, error and exception handling, inter-active systems and persistence.

The third subarea is software structure and architec-ture, in particular architectural structures and view-points, architectural styles, design patterns, and finallyfamilles of programs and frameworks.

The fourth subarea describes software design qualityanalysis and evaluation. While a whole knowledge areais devoted to software quality, this subarea presents theOOpiesmore specifically related 00 software design. Theseaspects are quality attributes, quality analysis, andeValuation tools and measures.

The firth one is software design notations, which aredivided inOOstructural and behavioral descriptions.

The last subarea covers software design strategies andmethods. First, general strategies are described, followedby function-oriented methods, then object-oriented meth-ods, data-structure centered design and a group of othermethods, such as formal and transformational methods.

Software Construction

Software construction is a fundamental act of software

engineering: the construction of working meaningful soft-ware through a combination of coding, validation, and(unit) testing.

The first and most important method of breaking thesubject of software construction inOOsmaller units is 00recognize the four principles that most strongly affectthe way in which software is constructed. These principlesare the reduction of complexity, the anticipation of di ver-sity, the structuring for validation and the use of externalstandards.

A second and less important method of breaking thesubject of software construction inOOsmaller units is tarecognize three styles/methods of software construction,namely, linguistic, formal and visual.

A gynthesis ofthese two views is presented and techni-ques are classified by principle and approach.

Software Testing

Software testing consists of the dynamic verification of thebehavior of a program on a finite set of test cases, suitablyselected from the usually infinite executions domain,against the specified expected behavior (see TESTMANAGE-MENTANDORGANIZATION).It includesfivesubareas.

It begins with a description of basic concepts. First, thetesting terminology is presented, then the theoreticalfoundations of testing are described, with the relationshipof testing 00 other activities.

The second subarea is the test levels dealing with test-ing corresponding 00 levels of integration as weIl as testingfor specific objectives.

The third subarea describes the test techniques them-selves. A first category describes tests based on some spe-cified base of material; a second category describes teststhat are implemented in ignorance of the implementation.

A discussion of how to select and combine the appropriatetechniques is presented.

The fourth subarea covers test-related measures. Themeasures are grouped inOOthose related 00the evaluationof the program under test and the evaluation of the testsperformed.

The last subarea describes the management specific00the test process. It includes management concerns andthe test activities.

Software Maintenance

Once in operation, anomalies are uncovered, operatingenvironments change, and new user requirements surface(see MAINTENANCE).The maintenance phase of the life cyclecommences upon delivery but maintenance activities occurmuch earlier. The software maintenance knowledge areais divided inOOfour subareas.

The first one presents the domain's basic concepts,including definitions, the main activities, and the pro-blems of software maintenance.

The second sub-area describes the maintenance process,based on the standards IEEE 1219 and ISOIIEC 14764.

The third sub-area treats key issues related 00softwaremaintenance. The OOpicscovered are technical, manage-ment, cost and estimation, and measurement issues.

Techniques for maintenance constitute the fourth sub-area. Those techniques include program comprehension,reengineering, reverse engineering, and impact analysis.

Software Configuration Management

Software configuration management (SCM) is the disci-pline of identifying the configuration of a system at distinctpoints in time for the purpose of systematically controllingchanges 00 the configuration and maintaining the integrityand traceability of the configuration throughout the sys-tem life cycle (see CoNFIGURATION MANAGEMENT). This knowl-

edge area includes six subareas.The first subarea is the management of the SCM pro-

cess. It covers the OOpicsof the organizational context forSCM, constraints and guidance for SCM, planning forSCM, the SCM plan itself, and surveillance of SCM.

The second sub-area is software configuration identifi-cation, which identifies items 00be controIled, establishesidentification schemes for the items and their versions,and establishes the oools and techniques 00 be used inacquiring and managing controlled items. The OOpiesinthis subarea are the identification of the items 00be con-trolled and the software library.

The third sub-area is the software configuration control,which is the management of changes during the softwarelife cycle. The OOpiesare, (1) requesting, evaluating, andapproving software changes; (2) implementing softwarechanges; and (3) deviations and waivers.

The fourth subarea is software configuration statusaccounting. Its OOpicsare software configuration statusinformation and status reporting.

The fifth sub-area is software configuration auditing,consisting of software functional configuration auditing,software physical configuration auditing, and in-processaudits of a software baseline.

--

T'

.aa.

--

The last subarea is software release management anddelivery, covering software building and software releasemanagement.

1

t

Software Engineering Management

While it is true to say that in one sense it should be possibleto manage software engineering in the same way as anyother (complex) process, there are aspects particular tosoftware products and the software engineering processthat complicate effective management (see PROJECfMAN-AGEMENT).There are three subareas for software engineer-ing management.

The first is organizational management, comprisingpolicy management, personnel management, communica-tion management, portfolio management, and procure-ment management.

The second subarea is process/project management,including initiation and scope definition, planning, enact-ment, review and evaluation, and closure.

The third and last subarea is software engineering mea-surement, where general principles about software mea-surement are covered. The first topics presented are. thegoals of a measurement program, followed by measure-ment selection, measuring software and its development,collection of data and, finally, software measurementmodels.

Software Engineering Process

The software engineering process knowledge area is con-cemed with the definition, implementation, measurement,management, change and improvement of the softwareengineering process itself (see CAPABILITYMATURITYMODELFORSOFTWARE).It is divided into six sub-areas.

The first one presents the basic concepts: themes andterminology.

The second subarea is process infrastructure, where thesoftware engineering process group concept is described,as well as the experience factory.

The third subarea deals with ineasurements specifie tosoftware engineering process. It presents the methodologyand measurement paradigms in the field.

The fourth subarea describes knowledge related to pro-cess definition: the various types ofprocess definitions, thelife-cycle framework models, the software life-cycle mod-els, the notations used to represent these definitions, pro-cess definitions methods, and automation relative to thevarious definitions.

The firth subarea presents qualitative process analysis,especially the process definition review and root causeanalysis.

Finally, the sixth subarea concludes withprocess imple-mentation and change. It describes the paradigms andguidelines for process implementation and change, andthe evaluation of the outcome of implementation andchange.

S~ftware Engineering Toois and Methods

The software engineering tools and methods knowledgearea includes both the software development environ-

- - --

SOFTWAREENGINEERINGBODY OF KNOWLEDGE PROJECT 1407

ments and the development methods knowledge areasidentified in the Strawman version of the guide (see SOFT-WARE TOOLS]

Software development environments are the computer-based tools that are intended to assist the software devel-opment process. Development methods impose structureon the software development activity with the goal ofmak-ing the activity systematic and ultimately more likely to besuccessful.

The partitioning of the software tools section uses thesame structure as the Trial version of the Guide to the

Software Engineering Body of Knowledge. The first ninesubsections correspond to the other nine knowledge areas.Two additional subsections are provided: one for infra-structure support tools that do not fit in any of the earliersections, and a miscellaneous subsection for topies, such astool integration techniques, that are potentially applicableto all classes of tools.

The software development methods section is dividedinto four subsections: heuristic methods dealing withinformaI approaches, formal methods dealing with mathe-matically based approaches, prototyping methods dealingwith software development approaches based on variousforms of prototyping, and miscellaneous method issues.

Software Quality

The final chapter deals with software quality considera-tions that transcend the life-cycle processes. Softwarequality is a ubiquitous concern in software engineering,so it is considered in many of the other knowledge areasand the reader will notice pointers to those knowledgeareas through this knowledge area (see QUALITYAsSUR-ANCE).The knowledge area description covers four subareas.

The first subarea describes the software quality con-cepts such as measuring the value of quality, the ISO/IEC 9126 quality model, dependability, and other specialtypes of system and quality needs.

The second subarea covers the purpose and planning ofsoftware quality assurance (SQA) and V&V (verificationand validation). It includes common planning activities,and both the SQA and V&V plans.

The third subarea describes the activities and techni-

ques for SQA and V&V. It includes static and dynamictechniques as well as other SQA and V&V testing.

The fourth subarea describes measurement applied toSQA and V&V. It includes the fundamentals of measure-ment, measures, measurement analysis techniques, defectcharacterization, and additional uses of SQA and V&Vdata.

THE SWEBOK PROJECT

From 1993 to 2000, the IEEE Computer Society and theAssociation for Computing Machinery (ACM) cooperatedin promoting the professionalization of soft:ware engineer-ing through their joint Software Engineering CoordinatingCommittee (SWECC). One important product of theSWECC was a Code of Ethics completed through volunteerefforts in 1997. The SWEBOK project was initiated by theSWECC in 1998, although the ACM subsequently decided

1408 SOFTWAREENGINEERING BODY OF KNOWLEDGEPROJECT

to withdraw from participation. The SWEBOK project'sscope, the variety of communities involved, and the needfor broad participation suggested a need for full-timerather than volunteer management. For this purpose,the IEEE Computer Society contracted the Software Engi-neering Management Research Laboratory at the Univer-sité du Québec à Montréal (UQAM) to manage the effort.

The project team consists of personnel from the IEEEComputer Society and from UQAM. Leonard Tripp (Boe-ing), the 1999 President of the Computer Society, is theChair of the SWECC. Alain Abran (UQAM) and JamesW. Moore (The MITRE Corporation) serve as ExecutiveEditors, with primary responsibilities for representingthe project. Pierre Bourque (École de Technologie Supér-ieure) and Robert Dupuis (UQAM) are the project editors,with primary responsibility for managing the project.

Like any software project, the SWEBOK project hasmany stakeholders-some of whom are formally repre-sented. An Industrial Advisory Board-eomposed of theIEEE Computer Society, representatives from industry(Boeing, the MITRE Corporation, Rational Software,Raytheon Systems, and SAP Labs-Canada), and researchagencies (National Institute of Standards and Technology,National Research Council of Canada)-has providedfinancial support for the project. The financial support per-mits making the products of the SWEBOK project publiclyavailable without any charge. !AB membership is supple-mented with the chair of the appropriate internationalstandards committee, ISOIIEC JTC1/SC7, and the chairof the Computing Curricula 2001 initiative. The !ABreviews and approves the project plans, oversees consen-sus building and review processes, promotes the project,and lends credibility to the effort. ln general, it ensuresthe relevance of the effort to real-world needs. From the

outset, it was understood that an implicit body of knowl-edge already exists in textbooks on software engineering.Ta ensure taking advantage of existing literature, SteveMcConnell, Roger Pressman, and lan Sommerville-theauthors of three best-selling textbooks on software engi-neering-served on a Panel of Experts to provide adviceon the initial formulation of the project and the structureof the SWEBOK Guide. ln all cases, the project soughtinternational participation to maintain a broad scope ofrelevance.

The project team developed two important principlesfor guiding the project: transparency and consensus.Transparency implies that the development process isitself documented, published, and publicized so thatimportant decisions and status are visible to all concernedparties. Consensus implies that the practical method forlegitimizing a statement of this kind is through broad par-ticipation and agreement by all significant sectors of therelevant community.

The project plan includes three successive phases:Strawman, Stoneman, and Ironman. An early prototype,Strawman, demonstrated how the project might be orga-nized. The publication of the current trial version of theSWEBOK Guide marks the end of the Stoneman phaseof the project. Development of the Ironman version willcommence after trial application of the current SWEBOKGuide.

The project team organized the development of theStoneman phase into three public review cycles. The firstreview cycle focused on the soundness of the proposedbreakdown oftopics within each knowledge area. The sec-ond review looked at the contentS of the guide from impor-tant viewpoints (e.g., educator, practitioner). The thirdreview focused on the coherency of the guide as a whole.ln aH, roughly 500 reviewers-about half from the UnitedStates and the remainder from 41 other countries-haveprovided nearly 10,000 comments. AlI review materialand comments are available on the project Web site.

FUTURE PLANS

The current trial version of the SWEBOK Guide repre-sents an enormous step in .consensus building, but is notyet proved by trial usage. The results of a two-year periodof field testing will be considered by the project team in for-mulating plans for the Ironman phase of the project. Dur-ing the Ironman phase, the document will be revised andreviewed through additional rounds 6f-consensus forma-tion.

Already some changes seem likely. An additionalknowledge area for component integration might directlyaddress software reuse and COTS component integration.Some reviewers have suggested a knowledge area forhuman-computer interface. The principles of the softwarequality knowledge area might be distributed among theother knowledge areas in order to achieve a tighter rela-tionship. The description in the current tools and methodsknowledge area is already organized by knowledge area; alogical next step might be to distribute the materialsamong the referenced knowledge areas. FinaHy, some nas-cent knowledge areas may emerge. ln three years, a com-munity consensus on the nature of software architecturemight lead to the development of a distinct knowledgearea.

ACKNOWLEDGMENTS

Portions of this article are adapted, with permission, from Guideto the Software Engineering Body of KnowlOOge, Trial version(version 0.9), February 2001, @ Copyright 2001, Institute of Elec-trical and Electronics Engineers.

BIBLIOGRAPHY

B. S. Bloom,00., TCJX()nonyof Educational Objectives;The Classi-fication of Educational Goals, Handbook 1, Longmans, Green,New York and Toronto, 1956.

G. Ford and N. E. Gibbs, A Mature Profession of SoftwareEngineering, Technical report CMU/SEI-96-TR-004,SoftwareEngineering Institute/Carnegie-Mellon University, Pitts-burgh, PA, 1996.

Project Management Institute, A Guide to the Project Manage-ment Body of Knowledge, Project Management Institute,Upper Darby, PA, 1996. Available at: http://www.pmi.org/publictn 1pmboktoc.htm 1.

--kJ

11

!

1

t

1

P. Starr, The Social Tranformation of Amercian Medicine, BasicBooks,New York, 1982, p. 15.

JAMES W. MOORE

The MITRE Corporation

PIERRE BOURQUE

École de Technologie Supérieure

RoBERT DUPUIS

ALAIN ABRAN

Université du Québec àMontreal

LEONARD TmPP

Boeing

SOFTWARE ENGINEERING ENVIRONMENTS

INTRODualON

A software factory is meant to be capable ofproviding com-puter support for the coordinated work of software deve-lopers in large software development projects. The termsoftware factory hence denotes a number of things: peopleand their respective roles in software development; com-puter supported tools and their combined use in softwaredevelopment; and a co-ordination process model to guidepeople in their proper use of tools and in their properjoined work integration as depicted below (see Fig. 1).

Recent developments have led from closed environ-ments, comprising fixed sets of tightly coupled tools forspecific phases, to open environments that enable the plug-ging of new tools as the requirements evolve (see also SoFI'-WARE FACTORY).

To cope with this new dimension in CASE technology,standards organizations intend to support the effort withreference models; for example, the Information SystemsEngineering Reference Model (ISE/RM) of the ISO; theStandards Manual of the Object Management Group(OMG), ECMA's Reference Model for Computer AssistedSoftware Engineering Environment Frameworks; ECMA'sSupport Environment for Open Distributed Processing(SE/OPD); and OSF's Distributed Computing Environ-ment (OSF/DCE).

The concepts presented in this article have been pri-marily developed in the Eureka Software Factory (ESF)

SOFTWAREENGINEERING ENVIRONMENTS 1409

project. This article hence carries the flavor of that projectin the way it introduces software factory concepts and inthe way it explains these concepts in the larger contextof computer-aided software development (see also EUREKASOFTWARE FACTORY).

Computer support in a software factory will be providedby a software system that is called factory support environ-ment (FSE). ln order to support software development inthe manner outlined above, the FSE is needed to providea number of integration services. FSE integration serviceswill be explained first by introducing a conceptual view of asoftware factory and later on as an architectural view.The conceptual view, called the software factory core,introduces a number of integration stages: interworking,interaction, interoperation, and interconnection. Thearchitectural view introduces the mechanisms thatsupport integration at the respective stages.

THE SOFTWAREFAaORY CORE

What the ESFCoRe Contains

The ESF CoRe is a road map of the Software Factorydomain. As such, it embodies a view of what industrialsoftware production means: what sorts of entities andevents ought to be distinguished in software factories,and how these relate to each other. Concretely, the CoReconsists of a set of definitions, some arguments as towhat those definitions imply, and some pictures showinghow the definitions are interrelated.

The structure of the CoRe derives from a strategic deci-sion ta view industrial software production as supportedby layered communication processes. Two views result:

. A conceptual view, using an extended OSI layermodel to distinguish leveIs of factory communicationand the kinds of work that can be conducted at eachlevei.

. An architectural view, which categorizes the entitiesthat communicate through and across each of thelayers, and places them in an evolutionary context.

The conceptual view hence introduces an extendedreference model for factory communication and the archi-tectural view the essential ingredients of a software fac-tory support environment.

Process model

People Computers Figure 1. Software factory model.

- -- --

ENCYCLOPE DIA OFSOFTWARE ENGINEERING

SECOND EDITION

VOLUME 2

John J. Marciniak, Editor-in-chief

(ID1" A Wiley-Interscience Publication

John Wiley & Sons, Inc.P SE ) R é F190 f]o~rlv, J.-

-- - -- -

This book is printed on acid-free paper. @

Copyright (Q 2002 by John Wiley & Sons Inc., New York. AlI rights reserved.

Published simultaneously in Canada.

No part ofthis publication may be reproduced, stored in à retrieval system or transmitted in anyform or by any means, electronic, mechanical, photocopying, recording, scamiing or otherwise,except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, withouteither the prior written permission of the Publisher, or authorization through payment of theappropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA01923, (978) 750-8400, fax (978) 750-4744. Requests to the Publisher for permission should beaddressed to the Permissions Department, John Wiley & Sons, Inc., 605 Third Avenue, New York,NY 10158-0012, (212) 850-6011, fax (212) 850-6008, E-Mail: PERMREQ@WILEY.COM.

For ordering and customer service, calIl-800-CALL-WILEY.

Library of Congress Cataloging-in-Publication Data is available.

Marciniak, John J.Eneyclopedia of Software Engineering, Second Edition

ISBN -Volume 1 0-471-21008-0ISBN - Volume 2 0-471-21007-2ISBN - Set 0-471-37737-6

Printed in the United States of America.

10 9 8 7 6 5 4 3 2