Guide to the Software Engineering Body of
                           Knowledge


                         2004 Version



...
© IEEE – 2004 Version
Guide to the Software Engineering Body of
                           Knowledge

                                      2004...
Library of Congress Cataloging-in-Publication Data


              Guide to the software engineering body of knowledge : 2...
TABLE OF CONTENTS
FOREWORD ..................................................................................................
vi   © IEEE – 2004 Version
FOREWORD
    In this Guide, the IEEE Computer Society establishes for the first time a baseline for the body of knowledge ...
Every profession is based on a body of knowledge and recommended practices, although they are not always
defined in a prec...
ASSOCIATE EDITORS
The following persons served as Associate Editors for either the Trial version published in 2001
       ...
x   © IEEE – 2004 Version
Industrial Advisory
                        BOARD


At the time of the publication, the following people formed the Indust...
PANEL OF EXPERTS


The following persons served on the panel of expert for the preparation of the Trial version of the
Gui...
REVIEW TEAM


The following people participated in the review process of this Guide, for the Trial version and/or
for the ...
Dutil, Daniel, Canada           Gresse von Wangenheim,           Jones, Griffin, USA
Dutton, Jeffrey, USA            Chris...
Lehman, Meir (Manny), UK         Miller, Mark, USA                Phipps, Robert, USA
Leigh, William, USA              Mir...
Ryan, Michael, Ireland             Sorensen, Reed, USA             Urbanowicz, Theodore, USA
Salustri, Filippo, Canada    ...
The following motion was unanimously adopted by the Industrial Advisory Board
                             on February 6, ...
xviii   © IEEE – 2004 Version
PREFACE

Software engineering is an emerging discipline and                    has long offered a certification for comput...
example, software might be built in Fortran using              engineering for defining education and training
functional ...
users have played a part in producing the current                   the earlier consensus process. We updated the
document...
baseline for future evolution. Additionally, please note          policy makers around the world regarding the practice
th...
Alain Abran                                            Executive Editors of the                               James W. Moo...
xxiv   © IEEE – 2004 Version
CHAPTER 1
                                       INTRODUCTION TO THE GUIDE

In spite of the millions of software professio...
Knowledge (SWEBOK) was established with the                            In establishing a boundary, it is also important to...
around 500 pages of reference material, and this was the                                               included in the stu...
limitations imposed on the choice of references (see                 involving substantial non-software components, as man...
divided into structural and behavioral descriptions.                 practical considerations and the test activities.
The...
The fifth sub-area is software configuration auditing. It            change. The topics here are process infrastructure, t...
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)
Upcoming SlideShare
Loading in …5
×

Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)

8,745 views
8,581 views

Published on

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,745
On SlideShare
0
From Embeds
0
Number of Embeds
105
Actions
Shares
0
Downloads
204
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Ieee,.Guide.To.The.Software.Engineering.Body.Of.Knowlewdge.2004.Version.Swebok.(2005)

  1. 1. Guide to the Software Engineering Body of Knowledge 2004 Version SWEBOK® A project of the IEEE Computer Society Professional Practices Committee © IEEE – 2004 Version ®SWEBOK is an official service mark of the IEEE
  2. 2. © IEEE – 2004 Version
  3. 3. Guide to the Software Engineering Body of Knowledge 2004 Version SWEBOK® Executive Editors Alain Abran, École de technologie supérieure James W. Moore, The MITRE Corp. Editors Pierre Bourque, École de technologie supérieure Robert Dupuis, Université du Québec à Montréal Project Champion Leonard L. Tripp, Chair, Professional Practices Committee, IEEE Computer Society (2001-2003) http://computer.org Los Alamitos, California Washington • Brussels • Tokyo © IEEE – 2004 Version ®SWEBOK is an official service mark of the IEEE
  4. 4. Library of Congress Cataloging-in-Publication Data Guide to the software engineering body of knowledge : 2004 version / executive editors, Alain Abran, James W. Moore; editors, Pierre Bourque, Robert Dupuis, Leonard L. Tripp. p. cm. 1. Software engineering. 2. Computer software--Development. I. Abran, Alain, 1949- . II. Moore, James W., 1948- . To be completed 2001005442 Copyright © 2004 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Copyright and Reprint Permissions: This document may be copied, in whole or in part, in any form or by any means, as is, or with alterations, provided that (1) alterations are clearly marked as alterations and (2) this copyright notice is included unmodified in any copy. Any other use or distribution of this document is prohibited without the prior express permission of IEEE. You use this document on the condition that you indemnify and hold harmless IEEE from any and all liability or damages to yourself or your hardware or software, or third parties, including attorneys' fees, court costs, and other related costs and expenses, arising out of your use of this document irrespective of the cause of said liability. IEEE MAKES THIS DOCUMENT AVAILABLE ON AN "AS IS" BASIS AND MAKES NO WARRANTY, EXPRESS OR IMPLIED, AS TO THE ACCURACY, CAPABILITY, EFFICIENCY MERCHANTABILITY, OR FUNCTIONING OF THIS DOCUMENT. IN NO EVENT WILL IEEE BE LIABLE FOR ANY GENERAL, CONSEQUENTIAL, INDIRECT, INCIDENTAL, EXEMPLARY, OR SPECIAL DAMAGES, EVEN IF IEEE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. To be completed Additional copies may be ordered from: IEEE Computer Society IEEE Service Center IEEE Computer Society Customer Service Center 445 Hoes Lane Asia/Pacific Office 10662 Los Vaqueros Circle P.O. Box 1331 Watanabe Bldg., 1-4-2 P.O. Box 3014 Piscataway, NJ 08855-1331 Minami-Aoyama Los Alamitos, CA 90720-1314 Tel: + 1-732-981-0060 Minato-ku, Tokyo 107-0062 Tel: + 1-714-821-8380 Fax: + 1-732-981-9667 JAPAN Fax: + 1-714-821-4641 http://shop.ieee.org/store/ Tel: + 81-3-3408-3118 E-mail: cs.books@computer.org customer-service@ieee.org Fax: + 81-3-3408-3553 tokyo.ofc@computer.org Publisher: Angela Burgess Group Managing Editor, CS Press: Deborah Plummer Advertising/Promotions: Tom Fink Production Editor: Bob Werner Printed in the United States of America © IEEE – 2004 Version
  5. 5. TABLE OF CONTENTS FOREWORD ..................................................................................................................................vii SWEBOK Committees ................................................................................................................ ix Preface to the SWEBOK Guide...............................................................................................xviii CHAPTER 1 INTRODUCTION TO THE GUIDE ..........................................................................1-1 CHAPTER 2 SOFTWARE REQUIREMENTS ...............................................................................2-1 CHAPTER 3 SOFTWARE DESIGN ...........................................................................................3-1 CHAPTER 4 SOFTWARE CONSTRUCTION ..............................................................................4-1 CHAPTER 5 SOFTWARE TESTING..........................................................................................5-1 CHAPTER 6 SOFTWARE MAINTENANCE ...............................................................................6-1 CHAPTER 7 SOFTWARE CONFIGURATION MANAGEMENT ....................................................7-1 CHAPTER 8 SOFTWARE ENGINEERING MANAGEMENT .........................................................8-1 CHAPTER 9 SOFTWARE ENGINEERING PROCESS ..................................................................9-1 CHAPTER 10 SOFTWARE ENGINEERING TOOLS AND METHODS ...........................................10-1 CHAPTER 11 SOFTWARE QUALITY.......................................................................................11-1 CHAPTER 12 KNOWLEDGE AREAS OF THE RELATED DISCIPLINES………………….….…..12-1 APPENDIX A KNOWLEDGE AREA DESCRIPTION SPECIFICATIONS FOR THE 2004 VERSION OF THE GUIDE TO THE SOFTWARE ENGINEERING BODY OF KNOWLEDGE.....................................................................................A-1 Appendix B EVOLUTION OF THE GUIDE ............................................................................... B-1 APPENDIX C ALLOCATION OF IEEE AND ISO SOFTWARE ENGINEERING STANDARDS TO SWEBOK KNOWLEDGE AREAS ...................................................................... C-1 APPENDIX D CLASSIFICATION OF TOPICS ACCORDING TO BLOOM’S TAXONOMY ................D-1 © IEEE – 2004 Version v
  6. 6. vi © IEEE – 2004 Version
  7. 7. FOREWORD In this Guide, the IEEE Computer Society establishes for the first time a baseline for the body of knowledge for the field of software engineering, and the work partially fulfills the Society’s responsibility to promote the advancement of both theory and practice in this field. In so doing, the Society has been guided by the experience of disciplines with longer histories, but was not bound either by their problems or their solutions. It should be noted that the Guide does not purport to define the body of knowledge, but rather to serve as a compendium and guide to the body of knowledge that has been developing and evolving over the past four decades. Furthermore, this body of knowledge is not static. The Guide must, necessarily, develop and evolve as software engineering matures. It nevertheless constitutes a valuable element of the software engineering infrastructure. In 1958, John Tukey, the world-renowned statistician, coined the term software. The term software engineering was used in the title of a NATO conference held in Germany in 1968. The IEEE Computer Society first published its Transactions on Software Engineering in 1972. The committee established within the IEEE Computer Society for developing software engineering standards was founded in 1976. The first holistic view of software engineering to emerge from the IEEE Computer Society resulted from an effort led by Fletcher Buckley to develop IEEE standard 730 for software quality assurance, which was completed in 1979. The purpose of IEEE Std 730 was to provide uniform, minimum acceptable requirements for preparation and content of software quality assurance plans. This standard was influential in completing the developing standards in the following topics: configuration management, software testing, software requirements, software design, and software verification and validation. During the period 1981-1985, the IEEE Computer Society held a series of workshops concerning the application of software engineering standards. These workshops involved practitioners sharing their experiences with existing standards. The workshops also held sessions on planning for future standards, including one involving measures and metrics for software engineering products and processes. The planning also resulted in IEEE Std 1002, Taxonomy of Software Engineering Standards (1986), which provided a new, holistic view of software engineering. The standard describes the form and content of a software engineering standards taxonomy. It explains the various types of software engineering standards, their functional and external relationships, and the role of various functions participating in the software life cycle. In 1990, planning for an international standard with an overall view was begun. The planning focused on reconciling the software process views from IEEE Std 1074 and the revised U.S. DoD standard 2167A. The revision was eventually published as DoD Std 498. The international standard was completed in 1995 with designation, ISO/IEC12207, and given the title of Standard for Software Life Cycle Processes. Std ISO/IEC 12207 provided a major point of departure for the body of knowledge captured in this book. It was the IEEE Computer Society Board of Governors’ approval of the motion put forward in May 1993 by Fletcher Buckley which resulted in the writing of this book. The Association for Computing Machinery (ACM) Council approved a related motion in August 1993. The two motions led to a joint committee under the leadership of Mario Barbacci and Stuart Zweben who served as co-chairs. The mission statement of the joint committee was “To establish the appropriate sets(s) of criteria and norms for professional practice of software engineering upon which industrial decisions, professional certification, and educational curricula can be based.” The steering committee organized task forces in the following areas: 1. Define Required Body of Knowledge and Recommended Practices; 2. Define Ethics and Professional Standards; 3. Define Educational Curricula for undergraduate, graduate, and continuing education. This book supplies the first component: required body of knowledge and recommend practices. The code of ethics and professional practice for software engineering was completed in 1998 and approved by both the ACM Council and the IEEE Computer Society Board of Governors. It has been adopted by numerous corporations and other organizations and is included in several recent textbooks. The educational curriculum for undergraduates is being completed by a joint effort of the IEEE Computer Society and the ACM, and is expected to be completed in 2004. © IEEE – 2004 Version vii
  8. 8. Every profession is based on a body of knowledge and recommended practices, although they are not always defined in a precise manner. In many cases, these are formally documented, usually in a form that permits them to be used for such purposes as accreditation of academic programs, development of education and training programs, certification of specialists, or professional licensing. Generally, a professional society or related body maintains custody of such a formal definition. In cases where no such formality exists, the body of knowledge and recommended practices are “generally recognized” by practitioners and may be codified in a variety of ways for different uses. It is hoped that readers will find this book useful in guiding them towards the knowledge and resources they need in their lifelong career development as software engineering professionals. The book is dedicated to Fletcher Buckley in recognition of his commitment to promoting software engineering as a professional discipline and his excellence as a software engineering practitioner in radar applications. Leonard L. Tripp, IEEE Fellow 2003 Chair, Professional Practices Committee, IEEE Computer Society, (2001-2003) Chair, Joint IEEE Computer Society and ACM Steering Committee for the Establishment of Software Engineering as a Profession (1998-1999) Chair, Software Engineering Standards Committee, IEEE Computer Society (1992-1998) viii © IEEE – 2004 Version
  9. 9. ASSOCIATE EDITORS The following persons served as Associate Editors for either the Trial version published in 2001 or for the 2004 version. Software Requirements PeterSawyer and Gerald Kotonya, Computing Department, Lancaster University, UK, {p.sawyer} {g.kotonya}@lancaster.ac.uk Software Design Guy Tremblay, Département d’informatique, UQAM, Canada, tremblay.guy@uqam.ca Software Construction Steve McConnell, Construx Software, USA, Steve.McConnell@construx.com Terry Bollinger, the MITRE Corporation, USA, terry@mitre.org Philippe Gabrini, Département d’informatique, UQAM, Canada, gabrini.philippe@uqam.ca Louis Martin, Département d’informatique, UQAM, Canada, martin.louis@uqam.ca Software Testing Antonia Bertolino and Eda Marchetti, ISTI-CNR, Italy, {antonia.bertolino} {eda.marchetti}@isti.cnr.it Software Maintenance Thomas M. Pigoski, Techsoft Inc., USA, tmpigoski@techsoft.com Alain April, École de technologie supérieure, Canada, aapril@ele.etsmtl.ca Software Configuration Management John A. Scott, Lawrence Livermore National Laboratory, USA, scott7@llnl,gov David Nisse, USA, nissed@worldnet.att.net Software Engineering Management Dennis Frailey, Raytheon Company, USA, DJFrailey@Raytheon.com Stephen G. MacDonell, Auckland University of technology, New Zealand, smacdone@aut.ac.nz Andrew R. Gray, University of Otago, New Zealand Software Engineering Process Khaled El Eman, served while at the Canadian National Research Council, Canada, khaled.el-emam@nrc-cnrc.gc.ca Software Engineerting Tools and Methods David Carrington, School of Information Technology and electrical Engineering, The University of Queensland, Australia, davec@itee.uq.edu.au Software Quality Alain April, École de technologie supérieure, Canada, aapril@ele.etsmtl.ca Dolores Wallace, retired from the National Institute of Standards and Technology, USA Dolores.Wallace@nist.gov Larry Reeker, NIST, USA, Larry.Reeker@nist.gov References Editor Marc Bouisset, Département d’informatique, UQAM, Bouisset.Marc@uqam.ca © IEEE – 2004 Version ix
  10. 10. x © IEEE – 2004 Version
  11. 11. Industrial Advisory BOARD At the time of the publication, the following people formed the Industrial Advisory Board: Mario R. Barbacci, Software Engineering Institute, representing the IEEE Computer Society Carl Chang, representing Computing Curricula 2001 François Coallier, École de technologie supérieure, speaking as ISO/IEC JTC 1 / SC7 Chairman Charles Howell, The MITRE Corporation Anatol Kark, National Research Council of Canada Philippe Kruchten, University of British Columbia, served as representative of Rational Software Laure Le Bars, SAP Labs (Canada) Steve McConnell, Construx Software Dan Nash, Raytheon Company Fred Otto, Canadian Council of Professional Engineers (CCPE) Richard Metz, The Boeing Company Larry Reeker, National Institute of Standards and Technology, Department of Commerce, USA The following persons served along with the IAB in the Executive Change Control Board for the 2004 edition: Donald Bagert, Rose-Hulman Institute of Technology, represening the IEEE Computer Society Professional Practices Committee Ann Sobel, Miami University, representing the Computing Curricula Software Engineering Steering Committee © IEEE – 2004 Version xi
  12. 12. PANEL OF EXPERTS The following persons served on the panel of expert for the preparation of the Trial version of the Guide: Steve McConnell, Construx Software Roger Pressman, R.S. Pressman and Associates Ian Sommerville, Lancaster University, UK xii © IEEE – 2004 Version
  13. 13. REVIEW TEAM The following people participated in the review process of this Guide, for the Trial version and/or for the 2004 version. Abbas, Rasha, Australia Bierwolf, Robert, The Charette, Robert, USA Abran , Alain, Canada Netherlands Chevrier, Marielle, Canada Accioly, Carlos, Brazil Bisbal, Jesus, Ireland Chi, Donald, USA Ackerman, Frank, USA Boivin, Michel, Canada Chiew, Vincent, Canada Akiyama, Yoshihiro, Japan Bolton , Michael, Canada Chilenski, John, USA Al-Abdullah, Mohammad, USA Bomitali, Evelino, Italy Chow, Keith, Italy Alarcon, Miren Idoia, Spain Bonderer, Reto, Switzerland Ciciliani, Ricardo, Argentina Alawy, Ahmed, USA Bonk, Francis, USA Clark, Glenda, USA Alleman, Glen, USA Booch, Grady, USA Cleavenger, Darrell, USA Allen, Bob, Canada Booker, Glenn, USA Cloos, Romain, Luxembourg Allen, David, USA Börstler, Jürgen, Sweden Coallier, François, Canada Amorosa, Francesco, Italy Borzovs, Juris, Latvia Coblentz, Brenda, USA Amyot, Daniel, Canada Botting, Richard, USA Cohen, Phil, Australia Andrade, Daniel, Brazil Bourque, Pierre, Canada Collard, Ross, New Zealand April, Alain, Canada Bowen, Thomas, USA Collignon, Stephane, Australia Arroyo-Figueror, Javier, USA Boyd, Milt, USA Connors, Kathy Jo, USA Ashford, Sonny, USA Boyer, Ken, USA Cooper, Daniel, USA Atsushi, Sawada, Japan Brashear, Phil, USA Councill, Bill, USA Backitis Jr., Frank, USA Briggs, Steve, USA Cox, Margery, USA Bagert, Donald, USA Bright, Daniela, USA Cunin, Pierre-Yves, France Baker, Jr., David, USA Brosseau, Jim, Canada DaLuz, Joseph, USA Baker, Theodore, USA Brotbeck, George, USA Dampier, David, USA Baldwin, Mark, USA Brown, Normand, Canada Daneva , Maya, Canada Bales, David, UK Bruhn, Anna, USA Daneva, Maya, Canada Bamberger, Judy, USA Brune, Kevin, USA Daughtry, Taz, USA Banerjee, Bakul, USA Bryant, Jeanne, USA Davis, Ruth, USA Barber, Scott, USA Buglione, Luigi, Italy De Cesare, Sergio, UK Barker, Harry, UK Bullock, James, USA Dekleva, Sasa, USA Barnes, Julie, USA Burns, Robert, USA Del Castillo, Federico, Peru Barney, David, Australia Burnstein, Ilene, USA Del Dago, Gustavo, Argentina Barros, Rafael, Colombia Byrne, Edward, USA DeWeese, Perry, USA Bastarache, Louis, Canada Calizaya, Percy, Peru Di Nunno, Donn, USA Bayer, Steven, USA Carreon, Juan, USA Diaz-Herrera, Jorge, USA Beaulac, Adeline, Canada Carroll, Sue, USA Dieste, Oscar, Spain Beck, William, USA Carruthers, Kate, Australia Dion, Francis, Canada Beckman, Kathleen, USA Caruso, Richard, USA Dixon, Wes, USA Below, Doreen, USA Carvalho, Paul, Canada Dolado, Javier, Spain Benediktsson, Oddur, Iceland Case, Pam, USA Donaldson, John, UK Ben-Menachem, Mordechai, Cavanaugh, John, USA Dorantes, Marco, Mexico Israel Celia, John A., USA Dorofee, Audrey, USA Bergeron, Alain, Canada Chalupa Sampaio, Alberto Douglass, Keith, Canada Berler, Alexander, Greece Antonio, Portugal Du, Weichang, Canada Bernet, Martin, USA Chan, F.T., Hong Kong Duben, Anthony, USA Bernstein, Larry, USA Chan, Keith, Hong Kong Dudash, Edward, USA Bertram, Martin, Germany Chandra, A.K., India Duncan, Scott, USA Bialik , Tracy, USA Chang, Wen-Kui, Taiwan Duong, Vinh, Canada Bielikova, Maria, Slovakia Chapin, Ned, USA Durham, George, USA © IEEE – 2004 Version xiii
  14. 14. Dutil, Daniel, Canada Gresse von Wangenheim, Jones, Griffin, USA Dutton, Jeffrey, USA Christiane, Brazil Jones, James E., USA Ebert, Christof, France Grigonis, George, USA Jones, Alan, UK Edge, Gary, USA Gupta, Arun, USA Jones, James, USA Edwards, Helen Maria, UK Gustafson, David, USA Jones, Larry, Canada El-Kadi, Amr, Egypt Gutcher, Frank, USA Jones, Paul, USA Endres, David, USA Haas, Bob, USA Ju, Dehua, China Engelmann, Franz, Switzerland Hagar, Jon, USA Juan-Martinez, Manuel- Escue, Marilyn, USA Hagstrom, Erick, USA Fernando, Spain Espinoza, Marco, Peru Hailey, Victoria, Canada Juhasz, Zoltan, Hungary Fay, Istvan, Hungary Hall, Duncan, New Zealand Juristo, Natalia, Spain Fayad, Mohamed, USA Haller, John, USA Kaiser, Michael, Switzerland Fendrich, John, USA Halstead-Nussloch, Richard, Kambic, George, USA Ferguson, Robert, USA USA Kamthan, Pankaj, Canada Fernandez, Eduardo, USA Hamm, Linda, USA Kaner, Cem, USA Fernandez-Sanchez, Jose Luis, Hankewitz, Lutz, Germany Kark, Anatol, Canada Spain Harker, Rob, USA Kasser, Joe, USA Filgueiras, Lucia, Brazil Hart, Hal, USA Kasser, Joseph, Australia Finkelstein, Anthony, UK Hart, Ronald, USA Katz, Alf, Australia Flinchbaugh, Scott, USA Hartner, Clinton, USA Kececi, Nihal, Canada Forrey, Arden, USA Hayeck, Elie, USA Kell, Penelope, USA Fortenberry, Kirby, USA He, Zhonglin, UK Kelly, Diane, Canada Foster, Henrietta, USA Hedger, Dick, USA Kelly, Frank, USA Fowler, Martin, USA Hefner, Rick, USA Kenett, Ron, Israel Fowler, John Jr., USA Heinrich, Mark, USA Kenney, Mary L., USA Fox, Christopher, USA Heinze, Sherry, Canada Kerievsky, Joshua, USA Frankl, Phyllis, USA Hensel, Alan, USA Kerr, John, USA Freibergs, Imants, Latvia Herrmann, Debra, USA Kierzyk, Robert, USA Frezza, Stephen, USA Hesse, Wolfgang, Germany Kinsner, W., Canada Fruehauf, Karol, Switzerland Hilburn, Thomas, USA Kirkpatrick, Harry, USA Fuggetta, Alphonso, Italy Hill, Michael, USA Kittiel, Linda, USA Fujii, Roger, USA Ho, Vinh, Canada Klappholz, David, USA FUSCHI, David Luigi, Italy Hodgen, Bruce, Australia Klein, Joshua, Israel Fuschi, David Luigi, Italy Hodges, Brett, Canada Knight, Claire, UK Gabrini, Philippe, Canada Hoffman, Douglas, Canada Knoke, Peter, USA Gagnon, Eric, Canada Hoffman, Michael, USA Ko, Roy, Hong Kong Ganor, Eitan, Israel Hoganson, Tammy, USA Kolewe, Ralph, Canada Garbajosa, Juan, Spain Hollocker, Chuck, USA Komal, Surinder Singh, Canada Garceau, Benoît, Canada Horch, John, USA Kovalovsky, Stefan, Austria Garcia-Palencia, Omar, Howard, Adrian, United Krauth, Péter, Hungary Colombia Kingdom Krishnan, Nirmala, USA Garner, Barry, USA Huang, Hui Min, USA Kromholz, Alfred, Canada Gelperin, David, USA Hung, Chih-Cheng, USA Kruchten, Philippe, Canada Gersting, Judith, Hawaii Hung, Peter, USA Kuehner, Nathanael, Canada Giesler, Gregg, USA Hunt, Theresa, USA Kwok, Shui Hung, Canada Gil, Indalecio, Spain Hunter, John, USA Lacroix, Dominique, Canada Gilchrist, Thomas, USA Hvannberg, Ebba Thora, Iceland LaMotte, Stephen W., USA Giurescu, Nicolae, Canada Hybertson, Duane, USA Land, Susan, USA Glass, Robert, USA Ikiz, Seckin, Turkey Lange, Douglas, USA Glynn, Garth, UK Iyengar, Dwaraka, USA Laporte, Claude, Canada Goers, Ron, USA Jackelen, George, USA Lawlis, Patricia, USA Gogates, Gregory, USA Jaeger, Dawn, USA Le, Thach, USA Goldsmith, Robin, USA Jahnke, Jens, Canada Leavitt, Randal, Canada Goodbrand, Alan, Canada James, Jean, USA LeBel, Réjean, Canada Gorski, Janusz, Poland Jino, Mario, Brazil Leciston, David, USA Graybill , Mark, USA Johnson, Vandy, USA Lee, Chanyoung, USA xiv © IEEE – 2004 Version
  15. 15. Lehman, Meir (Manny), UK Miller, Mark, USA Phipps, Robert, USA Leigh, William, USA Miranda, Eduardo, Canada Phister, Paul, USA Lembo, Jim, USA Mistrik, Ivan, Germany Phister, Jr., Paul, USA Lenss, John, USA Mitasiunas, Antanas, Lithuania Piattini, Mario, Spain Leonard, Eugene, USA Modell, Howard, USA Piersall, Jeff, USA Lethbridge, Timothy, Canada Modell, Staiger,USA Pillai, S.K., India Leung, Hareton, Hong Kong Modesitt, Kenneth, USA Pinder, Alan, UK Lever, Ronald, The Netherlands Moland, Kathryn, USA Pinheiro, Francisco A., Brazil Levesque, Ghislain, Canada Moldavsky, Symon, Ukraine Plekhanova, Valentina, United Ley, Earl, USA Montequín, Vicente R., Spain Kingdom Linders , Ben, Netherlands Moreno, Ana Maria, Spain Poon, Peter, USA Linscomb , Dennis, USA Mosiuoa, Tseliso, Lesotho Poppendieck, Mary, USA Little, Joyce Currie, USA Moudry, James, USA Powell, Mace, USA Logan, Jim, USA Msheik, Hamdan, Canada Predenkoski, Mary, USA Long, Carol, United Kingdom Mularz, Diane, USA Prescott, Allen, USA Lounis, Hakim, Canada Mullens, David, USA Pressman, Roger, USA Low, Graham, Australia Müllerburg, Monika, Germany Price, Art, USA Lutz, Michael, USA Murali, Nagarajan, Australia Price, Margaretha, USA Lynch, Gary, USA Murphy, Mike, USA Pullum, Laura, USA Machado, Cristina, Brazil Napier, John, USA Purser, Keith, USA MacKay, Stephen, Canada Narasimhadevara, Sudha, Purssey, John, Australia MacKenzie, Garth, USA Canada Pustaver, John, USA MacNeil, Paul, USA Narawane, Ranjana, India Quinn, Anne, USA Magel, Kenneth, USA Narayanan, Ramanathan, India Radnell, David, Australia Mains, Harold, USA Navarro Ramirez, Daniel, Rae, Andrew, United Kingdom Malak, Renee, USA Mexico Rafea, Ahmed, Egypt Maldonado, José Carlos, Brazil Navas Plano, Francisco, Spain Ramsden, Patrick, Australia Marcos, Esperanza, Spain Navrat, Pavol, Slovakia Rao, N.Vyaghrewara, India Marinescu, Radu, Romania Neumann, Dolly, USA Rawsthorne, Dan, USA Marm, Waldo, Peru Nguyen-Kim, Hong, Canada Reader, Katherine, USA Marusca, Ioan, Canada Nikandros, George, Australia Reddy, Vijay,USA Matlen, Duane, USA Nishiyama, Tetsuto, Japan Redwine, Samuel, USA Matsumoto, Yoshihiro, Japan Nunn, David, USA Reed, Karl, Australia McBride, Tom, Australia O'Donoghue, David, Ireland Reedy, Ann, USA McCarthy, Glenn, USA Oliver, David John, Australia Reeker, Larry, USA McChesney, Ian, UK Olson, Keith, USA Rethard, Tom, USA McCormick, Thomas, Canada Oskarsson, Östen, Sweden Reussner, Ralf, Germany McCown, Christian, USA Ostrom, Donald, USA Rios, Joaquin, Spain McDonald, Jim, USA Oudshoorn, Michael, Australia Risbec, Philippe, France McGrath Carroll, Sue, USA Owen, Cherry, USA Roach, Steve, USA McHutchison, Diane, USA Pai, Hsueh-Ieng, Canada Robillard, Pierre, Canada McKinnell, Brian, Canada Parrish, Lee, USA Rocha, Zalkind, Brazil McMichael, Robert, USA Parsons, Samuel, USA Rodeiro Iglesias, Javier, Spain McMillan, William, USA Patel, Dilip, UK Rodriguez-Dapena, Patricia, McQuaid, Patricia, USA Paulk, Mark, USA Spain Mead, Nancy, USA Pavelka, Jan, Czech Republic Rogoway, Paul, Israel Meeuse, Jaap, The Netherlands Pavlov, Vladimir, Ukraine Rontondi, Guido, Italy Meier, Michael, USA Pawlyszyn, Blanche, USA Roose, Philippe, France Meisenzahl, Christopher, USA Pecceu, Didier, France Rosca, Daniela, USA Melhart, Bonnie, USA Perisic, Branko, Yugoslavia Rosenberg, Linda, USA Mengel, Susan, USA Perry, Dale, USA Rourke, Michael, Australia Meredith, Denis, USA Peters, Dennis, Canada Rout, Terry, Australia Meyerhoff, Dirk, Germany Petersen, Erik, Australia Rufer, Russ, USA Mili, Hafedh, Canada Pfahl, Dietmar, Germany Ruiz, Francisco, Spain Miller, Chris, Netherlands Pfeiffer, Martin, Germany Ruocco, Anthony, USA Miller, Keith, USA Phillips, Dwayne, USA Rutherfoord, Rebecca, USA © IEEE – 2004 Version xv
  16. 16. Ryan, Michael, Ireland Sorensen, Reed, USA Urbanowicz, Theodore, USA Salustri, Filippo, Canada Soundarajan, Neelam, USA Van Duine, Dan, USA Salustri, Filippo, Canada Sousa Santos, Frederico, Van Ekris, Jaap, Netherlands Salwin, Arthur, USA Portugal Van Oosterhout, Bram, Australia Sanden, Bo, USA Spillers, Mark, USA Vander Plaats, Jim, USA Sandmayr, Helmut, Switzerland Spinellis, Diomidis, Greece Vegas, Sira, Spain Santana Filho, Ozeas Vieira, Splaine, Steve, USA Verner, June, USA Brazil Springer, Donald, USA Villas-Boas, André, Brazil Sato, Tomonobu, Japan Staiger, John, USA Vollman, Thomas, USA satyadas, antony, USA Starai, Thomas, USA Walker, Richard, Australia Satyadas, Antony, USA Steurs, Stefan, Belgium Walsh, Bucky, USA Schaaf, Robert, USA St-Pierre, Denis, Canada Wang, Yingxu, Sweden Scheper, Charlotte, USA Stroulia, Eleni, Canada Wear, Larry, USA Schiffel, Jeffrey, USA Subramanian, K.S., India Weigel, richard, USA Schlicht, Bill, USA Sundaram, Sai, UK Weinstock, Charles, USA Schrott, William, USA Swanek, James, USA Wenyin, Liu, China Schwarm, Stephen, USA Swearingen, Sandra, USA Werner, Linda, USA Schweppe, Edmund, USA Szymkowiak , Paul, Canada Wheeler, David, USA Sebern, Mark, USA Tamai, Tetsuo, Japan White, Nathan, USA Seffah, Ahmed, Canada Tasker, Dan, New Zealand White, Stephanie, USA Selby, Nancy, USA Taylor, Stanford, USA Whitmire, Scott, USA Selph, William, USA Terekhov, Andrey A., Russian Wijbrans, Klaas, The Sen, Dhruba, USA Federation, Netherlands Senechal, Raymond, USA Terski, Matt, USA Wijbrans-Roodbergen, Margot, Sepulveda, Christian, USA Thayer, Richard, USA The Netherlands Setlur, Atul, USA Thomas, Michael, USA Wilkie, Frederick, UK Sharp, David, USA Thompson, A. Allan, Australia Wille, Cornelius, Germany Shepard, Terry, Canada Thompson, John Barrie, UK Wilson, Charles, USA Shepherd, Alan, Germany Titus, Jason, USA Wilson, Leon, USA Shillato, Rrobert W, USA Tockey, Steve, USA Wilson, Russell, USA Shintani, Katsutoshi, Japan Tovar, Edmundo, Spain Woechan, Kenneth, USA Silva, Andres, Spain Towhidnejad, Massood, USA Woit , Denise, Canada Silva, Andres, Spain Trellue, Patricia, USA Yadin, Aharon, Israel Singer, Carl, USA Trèves, Nicolas, France Yih, Swu, Taiwan Sinnett, Paul, UK Troy, Elliot, USA Young, Michal, USA Sintzoff, André, France Tsui, Frank, USA Yrivarren, Jorge, Peru Sitte, Renate, Australia Tsuneo, Furuyama, Japan Znotka, Juergen, Germany Sky, Richard, USA Tuohy, Kenney, USA Zuser, Wolfgang, Austria Smilie, Kevin, USA Tuohy, Marsha P., USA Zvegintzov, Nicholas, USA Smith, David, USA Turczyn, Stephen, USA Zweben, Stu, USA Sophatsathit, Peraphon, Thailand Upchurch, Richard, USA xvi © IEEE – 2004 Version
  17. 17. The following motion was unanimously adopted by the Industrial Advisory Board on February 6, 2004. The Industrial Advisory Board finds that the Software Engineering Body of Knowledge project initiated in 1998 has been successfully completed; and endorses the 2004 Version of the Guide to the SWEBOK and commends it to the IEEE Computer Society Board of Governors for their approval. The following motion adopted by the IEEE Computer Society Board of Governors in February 2004. MOVED, that the Board of Governors of the IEEE Computer Society approves the 2004 Edition of the Guide to the Software Engineering Body of Knowledge and authorizes the Chair of the Professional Practices Committee to proceed with printing. © IEEE – 2004 Version xvii
  18. 18. xviii © IEEE – 2004 Version
  19. 19. PREFACE Software engineering is an emerging discipline and has long offered a certification for computing there are unmistakable trends indicating an increasing professionals. level of maturity: All of these efforts are based upon the presumption Several universities throughout the world offer that there is a Body of Knowledge that should be undergraduate degrees in software engineering. mastered by practicing software engineers. The Body For example, such degrees are offered at the of Knowledge exists in the literature that has University of New South Wales (Australia), accumulated over the past thirty years. This book McMaster University (Canada), the Rochester provides a Guide to that Body of Knowledge. Institute of Technology (US), the University of PURPOSE Sheffield (UK) and other universities. In the US, the Engineering Accreditation The purpose of the Guide to the Software Engineering Commission of the Accreditation Board for Body of Knowledge is to provide a consensually- Engineering and Technology (ABET) is validated characterization of the bounds of the responsible for the accreditation of undergraduate software engineering discipline and to provide a software engineering programs. topical access to the Body of Knowledge supporting that discipline. The Body of Knowledge is subdivided The Canadian Information Processing Society has into ten software engineering Knowledge Areas (KA) published criteria to accredit software engineering plus an additional chapter providing an overview of the undergraduate university programs. Knowledge Areas of strongly related disciplines. The The Software Engineering Institute’s Capability descriptions of the KAs are designed to discriminate Maturity Model for Software (SW CMM) and the among the various important concepts, permitting new Capability Maturity Model Integration readers to find their way quickly to subjects of interest. (CMMI) are used to assess organizational Upon finding a subject, readers are referred to key capability for software engineering. The famous papers or book chapters selected because they ISO 9000 quality management standards have succinctly present the knowledge. been applied to software engineering by the new In browsing the Guide, readers will note that the ISO/IEC 90003. content is markedly different from Computer Science. The Texas Board of Professional Engineers has Just as electrical engineering is based upon the science begun to license professional software engineers. of physics, software engineering should be based, The Association of Professional Engineers and among others, upon computer science. In both cases, Geoscientists of British Columbia (APEGBC) has though, the emphasis is necessarily different. Scientists begun registering software professional engineers extend our knowledge of the laws of nature while and the Professional Engineers of Ontario (PEO) engineers apply those laws of nature to build useful has also announced requirements for licensing. artifacts, under a number of constraints. Therefore, the emphasis of the Guide is placed upon the construction The Association for Computing Machinery of useful software artifacts. (ACM) and the Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) Readers will also notice that many important aspects of have jointly developed and adopted a Code of information technology, that may constitute important Ethics and Professional Practice for software software engineering knowledge, are not covered in engineering professionals1. the Guide; they include: specific programming languages, relational databases and networks. This is a The IEEE Computer Society offers the Certified consequence of an engineering-based approach. In all Software Development Professional certification fields—not only computing—the designers of for software engineering. The Institute for engineering curricula have realized that specific Certification of Computing Professionals (ICCP) technologies are replaced much more rapidly than the engineering work force. An engineer must be equipped with the essential knowledge that supports the 1 The ACM/CS Software Engineering Code of Ethics and selection of the appropriate technology at the Professional Practice can be found at: appropriate time in the appropriate circumstance. For http://www.computer.org/certification/ethics.htm © IEEE – 2004 Version xix
  20. 20. example, software might be built in Fortran using engineering for defining education and training functional decomposition or in C++ using object- requirements, classifying jobs, developing oriented techniques. The techniques for software performance evaluation policies or specifying software configuring instances of those systems would be quite development tasks. It also addresses practicing, or different. But, the principles and objectives of managing, software engineers and the officials configuration management remain the same. The responsible for making public policy regarding Guide therefore does not focus on the rapidly changing licensing and professional guidelines. In addition, technologies, although their general principles are professional societies and educators defining the described in relevant Knowledge Areas. certification rules, accreditation policies for university These exclusions demonstrate that this Guide is curricula, and guidelines for professional practice will necessarily incomplete. The Guide covers software benefit from SWEBOK, as well as the students engineering knowledge that is necessary, but not learning the software engineering profession and sufficient for a software engineer. Practicing software educators and trainers engaged in defining curricula engineers will need to know many things about and course content. computer science, project management and systems EVOLUTION OF THE GUIDE engineering—to name a few—that fall outside the Body of Knowledge characterized by this Guide. From 1993 to 2000, the IEEE Computer Society and However, stating that this information should be the Association for Computing Machinery (ACM) known by software engineers is not the same as stating cooperated in promoting the professionalization of that this knowledge falls within the bounds of the software engineering through their joint Software software engineering discipline. Instead, it should be Engineering Coordinating Committee (SWECC). The stated that software engineers need to know some Code of Ethics was completed under stewardship of things taken from other disciplines—and that is the the SWECC primarily through volunteer efforts. The approach adopted by this Guide. So, this Guide SWEBOK project was initiated by the SWECC in characterizes the Body of Knowledge falling within the 1998. scope of software engineering and provides references The SWEBOK project’s scope, the variety of to relevant information from other disciplines. A communities involved, and the need for broad chapter of the Guide provides a taxonomical overview participation suggested a need for full-time rather than of the related disciplines derived from authoritative volunteer management. For this purpose, the IEEE- sources. Computer Society contracted the Software Engineering The emphasis on engineering practice leads the Guide Management Research Laboratory at the Université du toward a strong relationship with the normative Québec à Montréal (UQAM) to manage the effort. In literature. Most of the computer science, information recent years, UQAM has been joined by the École de technology and software engineering literature technologie supérieure, Montréal, Québec. provides information useful to software engineers, but The project plan comprised three successive phases: a relatively small portion is normative. A normative Strawman, Stoneman and Ironman. An early prototype, document prescribes what an engineer should do in a Strawman, demonstrated how the project might be specified situation rather than providing information organized. The publication of the widely circulated that might be helpful. The normative literature is Trial Version of the Guide in 2001 marked the end of validated by consensus formed among practitioners the Stoneman phase of the project and initiated a and is concentrated in standards and related period of trial usage. The current Guide marks the end documents. From the beginning, the SWEBOK project of the Ironman period by providing a Guide that has was conceived as having a strong relationship to the achieved consensus through broad review and trial normative literature of software engineering. The two application. major standards bodies for software engineering (IEEE Computer Society Software Engineering Standards The project team developed two important principles Committee and ISO/IEC JTC1/SC7) are represented in for guiding the project: transparency and consensus. the project. Ultimately, we hope that software By transparency, we mean that the development engineering practice standards will contain principles process is itself documented, published, and publicized directly traceable to the Guide. so that important decisions and status are visible to all concerned parties. By consensus, we mean that the INTENDED AUDIENCE only practical method for legitimizing a statement of this kind is through broad participation and agreement The Guide is oriented toward a variety of audiences, by all significant sectors of the relevant community. all over the world. It aims to serve public and private Literally hundreds of contributors, reviewers, and trial organizations in need of a consistent view of software xx © IEEE – 2004 Version
  21. 21. users have played a part in producing the current the earlier consensus process. We updated the document. reference list so that it would be easier to obtain the Like any software project, the SWEBOK project has references. many stakeholders—some of which are formally Trial usage resulted in the recommendation that three represented. An Industrial Advisory Board, composed Knowledge Areas should be rewritten. Practitioners of representatives from industry (Boeing, Construx remarked that the Construction KA was difficult to Software, the MITRE Corporation, Rational Software, apply in a practical context. The Management KA was Raytheon Systems, and SAP Labs-Canada), research perceived as being too close to general management agencies (National Institute of Standards and and not sufficiently specific to software engineering Technology, National Research Council of Canada), concerns. The Quality KA was viewed as an the Canadian Council of Professional Engineers, and uncomfortable mix of process quality and product the IEEE Computer Society, have provided financial quality; it was revised to emphasize the latter. support for the project. The IAB’s generous support Finally, some KAs were revised to remove material permits us to make the products of the SWEBOK duplicating that of other KAs. project publicly available without any charge (visit http://www.swebok.org). IAB membership is LIMITATIONS supplemented with the chairs of ISO/IEC JTC1/SC7 and the related Computing Curricula 2001 initiative. Even though the Guide has gone through an elaborate The IAB reviews and approves the project plans, development and review process, the following oversees consensus building and review processes, limitations of this process must be recognized and promotes the project, and lends credibility to the effort. stated: In general, it ensures the relevance of the effort to real- Software engineering continues to be infused world needs. with new technology and new practices. The Trial Version of the Guide was the product of Acceptance of new techniques grows and older extensive review and comment. In three public review techniques are discarded. The topics listed as cycles, a total of roughly 500 reviewers from 42 “generally accepted” in this Guide are carefully countries provided roughly 9,000 comments, all of selected at this time. Inevitably, though, the which are available at www.swebok.org. To produce selection will need to evolve. the current version, we released the Trial Version for The amount of literature that has been published extensive trial usage. Trial application in specialized on software engineering is considerable and the studies resulted in 17 papers describing good aspects reference material included in this Guide should of the Guide, as well as aspects needing improvement. not be seen as a definitive selection but rather as a A web-based survey captured additional experience: reasonable selection. Obviously, there are other 573 individuals from 55 countries registered for the excellent authors and excellent references than survey; 124 reviewers from 21 countries actually those included in the Guide. In the case of the provided comments—1020 of them. Additional Guide, references were selected because they are suggestions for improvement resulted from liaison written in English, readily available, recent, easily with related organizations and efforts: IEEE-CS/ACM readable, and—taken as a group—provide Computing Curricula Software Engineering; the IEEE- coverage of the topics within the KA CS Certified Software Development Professional Important and highly relevant reference material project; ISO/IEC JTC1/SC7 (software and systems written in other languages than English have been engineering standards), the IEEE Software omitted from the selected reference material. Engineering Standards Committee; the American Society for Quality, Software Division; and an Additionally, one must consider that engineering professional society, the Canadian Council Software engineering is an emerging discipline. of Professional Engineers. This is especially true if you compare it to certain more established engineering disciplines. This CHANGES SINCE THE TRIAL VERSION means notably that the boundaries between the The overall goal of the current revision was to improve Knowledge Areas of software engineering and the readability, consistency, and usability of the Guide. between software engineering and its Related This implied a general rewrite of the entire text to Disciplines remain a matter for continued make the style consistent throughout the document. In evolution. several cases, the topical breakdown of the KA was The contents of this Guide must therefore be viewed as rearranged to make it more usable, but we were careful an “informed and reasonable” characterization of the to include the same information that was approved by software engineering Body of Knowledge and as © IEEE – 2004 Version xxi
  22. 22. baseline for future evolution. Additionally, please note policy makers around the world regarding the practice that the Guide is not attempting nor does it claim to and definition of engineering and software engineering replace or amend in any way laws, rules and in particular. procedures that have been defined by official public xxii © IEEE – 2004 Version
  23. 23. Alain Abran Executive Editors of the James W. Moore École de technologie supérieure Guide to the Software The MITRE Corporation Engineering Body of Knowledge Pierre Bourque Editors of the Guide to Robert Dupuis École de Technologie Supérieure the Software Engineering Université du Québec à Montréal Body of Knowledge Leonard Tripp Chair of the Professional 1999 President Practices Committee, IEEE Computer Society IEEE Computer Society (2001-2003) 2004 The SWEBOK project web site is http://www.swebok.org/ acknowledge the indispensable contribution of ACKNOWLEDGMENTS the hundreds of reviewers. The SWEBOK editorial team gratefully The editorial team also wishes to thank the acknowledges the support provided by the following people who contributed to the project members of the Industrial Advisory Board. in various manners: Mark Ardis, Yussef Funding for this project has been provided by the Belkebir, Michel Boivin, Julie Bonneau, Simon ACM, Boeing, the Canadian Council of Bouchard, François Cossette, Vinh Duong, Gilles Professional Engineers, Construx Software, the Gauthier, Michèle Hébert, Paula Hawthorn, IEEE Computer Society, the MITRE Richard W. Heiman, Julie Hudon, Idrissa corporation, the National Institute of Standards Konkobo, Rene Köppel, Lucette Lapointe, and Technology, the National Research Council Claude Laporte, Luis Molinié, Hamdan Msheik, of Canada, Rational Software, Raytheon Iphigénie N’Diyae, Serge Oligny, Suzanne Company, and SAP Labs (Canada). The team is Paquette, Keith Paton, Dave Rayford, Normand thankful for the counsel provided by the Panel of Séguin, Paul Sinnett, Denis St-Pierre, Dale Strok, Experts. The team also appreciates the important Pascale Tardif, Louise Thibaudeau, Dolores work performed by the Associate Editors. We Wallace, Évariste Valery Bevo Wandji, and would also like to express our gratitude for initial Michal Young. work on the Knowledge Area Descriptions Finally, there are surely other people who have completed by Imants Freibergs, Stephen Frezza, contributed to this Guide, either directly or Andrew Gray, Vinh T. Ho, Michael Lutz, Larry indirectly, whose names we have inadvertently Reeker, Guy Tremblay, Chris Verhoef, and omitted. To those people, we offer our tacit Sybille Wolff. The editorial team must also appreciation and apologize for having omitted explicit recognition here. © IEEE – 2004 Version xxiii
  24. 24. xxiv © IEEE – 2004 Version
  25. 25. CHAPTER 1 INTRODUCTION TO THE GUIDE In spite of the millions of software professionals worldwide and the ubiquitous presence of software in our WHAT ARE THE CHARACTERISTICS OF A PROFESSION ? society, software engineering has only recently reached Gary Ford and Norman Gibbs studied several recognized the status of a legitimate engineering discipline and a recognized profession. professions, including medicine, law, engineering, and accounting.3 They concluded that an engineering Achieving consensus by the profession on a core body of profession is characterized by several components: knowledge is a key milestone in all disciplines and had An initial professional education in a curriculum been identified by the IEEE Computer Society as crucial for the evolution of software engineering towards validated by society through accreditation professional status. This Guide, written under the auspices Registration of fitness to practice via voluntary of the Professional Practices Committee, is part of a certification or mandatory licensing multi-year project designed to reach such a consensus. Specialized skill development and continuing professional education WHAT IS SOFTWARE ENGINEERING? Communal support via a professional society The IEEE Computer Society defines software engineering A commitment to norms of conduct often prescribed as: in a code of ethics “(1) The application of a systematic, disciplined, This Guide contributes to the first three of these quantifiable approach to the development, operation, and components. Articulating a Body of Knowledge is an maintenance of software; that is, the application of essential step toward developing a profession because it engineering to software. represents a broad consensus regarding what a software (2) The study of approaches as in (1).”1 engineering professional should know. Without such a consensus, no licensing examination can be validated, no curriculum can prepare an individual for an examination, WHAT IS A RECOGNIZED PROFESSION? and no criteria can be formulated for accrediting a For software engineering to be fully known as a curriculum. The development of consensus is also a legitimate engineering discipline and a recognized prerequisite to the adoption of coherent skills profession, consensus on a core body of knowledge is development and continuing professional education imperative. This fact is well illustrated by Starr when he programs in organizations. defines what can be considered a legitimate discipline and a recognized profession. In his Pulitzer Prize-winning WHAT ARE THE OBJECTIVES OF THE SWEBOK book on the history of the medical profession in the USA, PROJECT? he states that: The Guide should not be confused with the Body of “The legitimization of professional authority involves Knowledge itself, which already exists in the published three distinctive claims: first, that the knowledge and literature. The purpose of the Guide is to describe what competence of the professional have been validated by a portion of the Body of Knowledge is generally accepted, community of his or her peers; second, that this to organize that portion, and to provide a topical access to consensually validated knowledge rests on rational, it. Additional information on the meaning given to scientific grounds; and third, that the professional’s “generally accepted” can be found below and in Appendix judgment and advice are oriented toward a set of A. substantive values, such as health. These aspects of legitimacy correspond to the kinds of attributes–collegial, The Guide to the Software Engineering Body of cognitive, and moral–usually embodied in the term “profession.”2 Books, 1982. p. 15. 3 1 G. Ford and N. E. Gibbs, “A Mature Profession of Software “IEEE Standard Glossary of Software Engineering Terminology,” Engineering,” Software Engineering Institute, Carnegie Mellon IEEE, Piscataway, NJ std 610.12-1990, 1990. University, Pittsburgh, Pennsylvania, Technical CMU/SEI-96-TR- 2 P. Starr, The Social Transformation of American Medicine: Basic 004, January 1996. © IEEE – 2004 Version 1-1
  26. 26. Knowledge (SWEBOK) was established with the In establishing a boundary, it is also important to identify following five objectives: what disciplines share that boundary, and often a common 1. To promote a consistent view of software intersection, with software engineering. To this end, the engineering worldwide Guide also recognizes eight related disciplines, listed in Table 2 (see chapter 12, Related Disciplines of Software 2. To clarify the place–and set the boundary–of Engineering). Software engineers should, of course, have software engineering with respect to other knowledge of material from these fields (and the KA disciplines such as computer science, project descriptions may make reference to them). It is not, management, computer engineering, and however, an objective of the SWEBOK Guide to mathematics characterize the knowledge of the related disciplines, but 3. To characterize the contents of the software rather what knowledge is viewed as specific to software engineering discipline engineering. 4. To provide a topical access to the Software Table 2 Related disciplines. Engineering Body of Knowledge Computer engineering Project management 5. To provide a foundation for curriculum development Computer science Quality management and for individual certification and licensing material Management Software ergonomics The first of these objectives, a consistent worldwide view Mathematics Systems engineering of software engineering, was supported by a development process which engaged approximately 500 reviewers from HIERARCHICAL ORGANIZATION 42 countries in the Stoneman phase (1998-2001) leading to the Trial version, and over 120 reviewers from 21 The organization of the KA descriptions or chapters countries in the Ironman phase (2003) leading to the 2004 supports the third of the project’s objectives–a version. More information regarding the development characterization of the contents of software engineering. process can be found in the Preface and on the Web site The detailed specifications provided by the project’s (www.swebok.org). Professional and learned societies editorial team to the associate editors regarding the and public agencies involved in software engineering contents of the KA descriptions can be found in Appendix were officially contacted, made aware of this project, and A. invited to participate in the review process. Associate The Guide uses a hierarchical organization to decompose editors were recruited from North America, the Pacific each KA into a set of topics with recognizable labels. A Rim, and Europe. Presentations on the project were made two- or three-level breakdown provides a reasonable way at various international venues and more are scheduled for to find topics of interest. The Guide treats the selected the upcoming year. topics in a manner compatible with major schools of The second of the objectives, the desire to set a boundary thought and with breakdowns generally found in industry for software engineering, motivates the fundamental and in software engineering literature and standards. The organization of the Guide. The material that is recognized breakdowns of topics do not presume particular as being within this discipline is organized into the first application domains, business uses, management ten Knowledge Areas (KAs) listed in Table 1. Each of philosophies, development methods, and so forth. The these KAs is treated as a chapter in this Guide. extent of each topic’s description is only that needed to understand the generally accepted nature of the topics and Table 1 The SWEBOK Knowledge Areas (KAs). for the reader to successfully find reference material. Software requirements After all, the Body of Knowledge is found in the Software design reference material themselves, and not in the Guide. Software construction REFERENCE MATERIAL AND MATRIX Software testing Software maintenance To provide a topical access to the knowledge–the fourth Software configuration management of the project’s objectives–the Guide identifies reference material for each KA, including book chapters, refereed Software engineering management papers, or other recognized sources of authoritative Software engineering process information. Each KA description also includes a matrix Software engineering tools and methods relating the reference material to the listed topics. The Software quality total volume of cited literature is intended to be suitable for mastery through the completion of an undergraduate education plus four years of experience. In this edition of the Guide, all KAs were allocated 1–2 © IEEE – 2004 Version
  27. 27. around 500 pages of reference material, and this was the included in the study material for the software specification the associate editors were invited to apply. It engineering licensing examination that graduates would may be argued that some KAs, such as software design take after gaining four years of work experience. for instance, deserve more pages of reference material Although this criterion is specific to the U.S. style of than others. Such modulation may be applied in future education and does not necessarily apply to other editions of the Guide. countries, we deem it useful. However, the two It should be noted that the Guide does not attempt to be definitions of generally accepted knowledge should be comprehensive in its citations. Much material that is both seen as complementary. suitable and excellent is not referenced. Material was selected in part because–taken as a collection–it provides LIMITATIONS RELATED TO THE BOOK FORMAT coverage of the topics described. The book format for which this edition was conceived has DEPTH OF TREATMENT its limitations. The nature of the contents would be better served using a hypertext structure, where a topic would be From the outset, the question arose as to the depth of linked to topics other than the ones immediately treatment the Guide should provide. The project team preceding and following it in a list. adopted an approach which supports the fifth of the Some boundaries between KAs, sub-areas, and so on, are project’s objectives–providing a foundation for also sometimes relatively arbitrary. These boundaries are curriculum development, certification, and licensing. The not to be given too much importance. As much as editorial team applied the criterion of generally accepted possible, pointers and links have been given in the text knowledge, to be distinguished from advanced and where relevant and useful. research knowledge (on the grounds of maturity) and from specialized knowledge (on the grounds of generality Links between KAs are not of the input-output type. The of application). The definition comes from the Project KAs are meant to be views on the knowledge one should Management Institute: “The generally accepted possess in software engineering with respect to the KA in knowledge applies to most projects most of the time, and question. The decomposition of the discipline within KAs widespread consensus validates its value and and the order in which the KAs are presented are not to be effectiveness”.4 assimilated with any particular method or model. The methods are described in the appropriate KA in the Guide, and the Guide itself is not one of them. Generally Accepted Practices used only for certain types Established traditional practices recommended by many organizations THE KNOWLEDGE AREAS Figure 1 maps out the eleven chapters and the important topics incorporated within them. The first five KAs are Specialized of software presented in traditional waterfall life cycle sequence. However, this does not imply that the Guide adopts or Advanced and Research encourages the waterfall model, or any other model. The Innovative practices tested and used subsequent KAs are presented in alphabetical order, and only by some organizations and those of the related disciplines are presented in the last concepts still being developed and chapter. This is identical to the sequence in which they tested in research organizations are presented in this Guide. STRUCTURE OF THE KA DESCRIPTIONS Figure 1 Categories of knowledge The KA descriptions are structured as follows. However, the term “generally accepted” does not imply In the introduction, a brief definition of the KA, and an that the designated knowledge should be uniformly overview of its scope and of its relationship with other applied to all software engineering endeavors–each KAs are presented. project’s needs determine that–but it does imply that The breakdown of topics constitutes the core of each KA competent, capable software engineers should be description, describing the decomposition of the KA into equipped with this knowledge for potential application. sub-areas, topics, and sub-topics. For each topic or sub- More precisely, generally accepted knowledge should be topic, a short description is given, along with one or more references. 4 The reference material was chosen because it is A Guide to the Project Management Body of Knowledge, 2000 Edition, Project Management Institute, Newport Square, PA. considered to constitute the best presentation of the www.pmi.org. knowledge relative to the topic, taking into account the © IEEE – 2004 Version 1-3
  28. 28. limitations imposed on the choice of references (see involving substantial non-software components, as many above). A matrix links the topics to the reference material. as three different types of documents are produced: The last part of the KA description is the list of system definition, system requirements specification, and recommended references. Appendix A of each KA software requirements specification. The sub-area includes suggestions for further reading for those users describes all three documents and the underlying who wish to learn more about the KA topics. Appendix B activities. presents the list of standards most relevant to the KA. The sixth sub-area is requirements validation, the aim of Note that citations enclosed in square brackets “[ ]” in the which is to pick up any problems before resources are text identify recommended references, while those committed to addressing the requirements. Requirements enclosed in parentheses “( )” identify the usual references validation is concerned with the process of examining the used to write or justify the text. The former are to be requirements documents to ensure that they are defining found in the corresponding section of the KA and the the right system (that is, the system that the user expects). latter in Appendix A of the KA. It is subdivided into descriptions of the conduct of Brief summaries of the KA descriptions and Appendices requirements reviews, prototyping, and model validation are given next. and acceptance tests. The seventh and last sub-area is practical considerations. Software Requirements KA (see Figure 2, column a) It describes topics which need to be understood in practice. The first topic is the iterative nature of the A requirement is defined as a property that must be requirements process. The next three topics are exhibited in order to solve some real-world problem. fundamentally about change management and the The first knowledge sub-area is software requirements maintenance of the requirements in a state which fundamentals. It includes definitions of software accurately mirrors the software to be built, or that has requirements themselves, but also of the major types of already been built. It includes change management, requirements: product vs. process, functional vs. non- requirements attributes, and requirements tracing. The functional, emergent properties. The sub-area also final topic is requirements measurement. describes the importance of quantifiable requirements and distinguishes between systems and software requirements. Software Design KA (see Figure 2, column b) The second knowledge sub-area is the requirements According to the IEEE definition [IEEE610.12-90], process, which introduces the process itself, orienting the design is both “the process of defining the architecture, remaining five sub-areas and showing how requirements components, interfaces, and other characteristics of a engineering dovetails with the other software engineering system or component” and “the result of [that] process.” processes. It describes process models, process actors, The KA is divided into six sub-areas. process support and management, and process quality and improvement. The first sub-area presents the software design fundamentals, which form an underlying basis to the The third sub-area is requirements elicitation, which is understanding of the role and scope of software design. concerned with where software requirements come from These are general software concepts, the context of and how the software engineer can collect them. It software design, the software design process, and the includes requirement sources and elicitation techniques. enabling techniques for software design. The fourth sub-area, requirements analysis, is concerned The second sub-area groups together the key issues in with the process of analyzing requirements to: software design. They include concurrency, control and detect and resolve conflicts between requirements handling of events, distribution of components, error and discover the bounds of the software and how it must exception handling and fault tolerance, interaction and interact with its environment presentation, and data persistence. elaborate system requirements to software The third sub-area is software structure and architecture, requirements the topics of which are architectural structures and Requirements analysis includes requirements viewpoints, architectural styles, design patterns, and, classification, conceptual modeling, architectural design finally, families of programs and frameworks. and requirements allocation, and requirements The fourth sub-area describes software design quality negotiation. analysis and evaluation. While there is a entire KA The fifth sub-area is requirements specification. devoted to software quality, this sub-area presents the Requirements specification typically refers to the topics specifically related to software design. These production of a document, or its electronic equivalent, aspects are quality attributes, quality analysis, and that can be systematically reviewed, evaluated, and evaluation techniques and measures. approved. For complex systems, particularly those The fifth sub-area is software design notations, which are 1–4 © IEEE – 2004 Version
  29. 29. divided into structural and behavioral descriptions. practical considerations and the test activities. The last sub-area describes software design strategies and methods. First, general strategies are described, followed Software Maintenance (see Figure 2, column e) by function-oriented design methods, object-oriented design methods, data-structure centered design, Once in operation, anomalies are uncovered, operating component-based design, and others. environments change, and new user requirements surface. The maintenance phase of the lifecycle commences upon delivery but maintenance activities occur much earlier. Software Construction KA (see Figure 2, column c) The Software Maintenance KA is divided into four sub- Software construction refers to the detailed creation of areas. working, meaningful software through a combination of The first one presents software maintenance coding, verification, unit testing, integration testing, and fundamentals: definitions and terminology, the nature of debugging. The KA includes three sub-areas. maintenance, the need for maintenance, the majority of The first sub-area is software construction fundamentals. maintenance costs, the evolution of software, and the The first three topics are basic principles of construction: categories of maintenance. minimizing complexity, anticipating change, and The second sub-area groups together the key issues in constructing for verification. The last topic discusses software maintenance. These are the technical issues, the standards for construction. management issues, maintenance cost estimation, and The second sub-area describes managing construction. software maintenance measurement. The topics are construction models, construction The third sub-area describes the maintenance process. planning, and construction measurement. The topics here are the maintenance processes and The third sub-area covers practical considerations. The maintenance activities. topics are construction design, construction languages, Techniques for maintenance constitute the fourth sub- coding, construction testing, reuse, construction quality, area. These include program comprehension, re- and integration. engineering, and reverse engineering. Software Testing (see Figure 2, column d) Software Configuration Management (see Figure 3, column f) Software Testing consists of the dynamic verification of the behavior of a program on a finite set of test cases, Software Configuration Management (SCM) is the suitably selected from the usually infinite executions discipline of identifying the configuration of software at domain, against the expected behavior. It includes five distinct points in time for the purpose of systematically sub-areas. controlling changes to the configuration and of It begins with a description of software testing maintaining the integrity and traceability of the fundamentals. First, the testing-related terminology is configuration throughout the system life cycle. This KA presented, then key issues of testing are described, and includes six sub-areas. finally the relationship of testing to other activities is The first sub-area is management of the SCM process. It covered. covers the topics of the organizational context for SCM, The second sub-area is test levels. These are divided constraints and guidance for SCM, planning for SCM, the between the targets of the tests and the objectives of the SCM plan itself, and surveillance of SCM. tests. The second sub-area is software configuration The third sub-area is test techniques. The first category identification, which identifies items to be controlled, includes the tests based on the tester’s intuition and establishes identification schemes for the items and their experience. A second group comprises specification- versions, and establishes the tools and techniques to be based techniques, followed by code-based techniques, used in acquiring and managing controlled items. The fault-based techniques, usage-based techniques, and first topics in this sub-area are identification of the items techniques relative to the nature of the application. A to be controlled and the software library. discussion of how to select and combine the appropriate The third sub-area is software configuration control, techniques is also presented. which is the management of changes during the software The fourth sub-area covers test related measures. The life cycle. The topics are: first, requesting, evaluating, and measures are grouped into those related to the evaluation approving software changes; second, implementing of the program under test and the evaluation of the tests software changes; and third, deviations, and waivers. performed. The fourth sub-area is software configuration status The last sub-area describes the test process, and includes accounting. Its topics are software configuration status information and software configuration status reporting. © IEEE – 2004 Version 1-5
  30. 30. The fifth sub-area is software configuration auditing. It change. The topics here are process infrastructure, the consists of software functional configuration auditing, software process management cycle, models for process software physical configuration auditing, and in-process implementation and change, and practical considerations. audits of a software baseline. The second sub-area deals with process definition. It The last sub-area is software release management and includes the topics of software life cycle models, software delivery, covering software building and software release life-cycle processes, notations for process definitions, management. process adaptation, and automation The third sub-area is process assessment. The topics here Software Engineering Management (see Figure 3, include process assessment models and process column g) assessment methods. The Software Engineering Management KA addresses the The fourth sub-area describes process and product management and measurement of software engineering. measurements. The software engineering process covers While measurement is an important aspect of all KAs, it general product measurement, as well as process is here that the topic of measurement programs is measurement in general. Measurements specific to KAs presented. There are six sub-areas for software are described in the relevant KA. The topics are process engineering management. The first five cover software measurement, software product measurement, quality of project management and the sixth describes the software measurement results, software information models, and measurement programs. process measurement techniques. The first sub-area is initiation and scope definition, which comprises determination and negotiation of requirements, Software Engineering Tools and Methods (see Figure feasibility analysis, and process for the review and 3, column i) revision of requirements. The Software Engineering Tools and Methods KA The second sub-area is software project planning, and includes both software engineering tools and software includes process planning, determining deliverables, engineering methods. effort, schedule and cost estimation, resource allocation, The software engineering tools sub-area uses the same risk management, quality management, and plan structure as the Guide itself, with one topic for each of the management. other nine software engineering KAs. An additional topic The third sub-area is software project enactment. The is provided: miscellaneous tools issues, such as tool topics here are implementation of plans, supplier contract integration techniques, which are potentially applicable to management, implementation of measurement process, all classes of tools. monitor process, control process,? and reporting. The software engineering methods sub-area is divided The fourth sub-area is review and evaluation, which into four subsections: heuristic methods dealing with includes the topics of determining satisfaction of informal approaches, formal methods dealing with requirements and reviewing and evaluating performance. mathematically based approaches, and prototyping The fifth sub-area describes closure: determining closure methods dealing with software development approaches and closure activities. based on various forms of prototyping. Finally, the sixth sub-area describes software engineering Software Quality (see Figure 3, column j) measurement, more specifically, measurement programs. Product and process measures are described in the The Software Quality KA deals with software quality Software Engineering Process KA. Many of the other considerations which transcend the software life cycle KAs also describe measures specific to their KA. The processes. Since software quality is a ubiquitous concern topics of this sub-area are: establish and sustain in software engineering, it is also considered in many of measurement commitment, plan the measurement the other Kas, and the reader will notice pointers to those process, perform the measurement process, and evaluate KAs throughout this KA. The description of this KA measurement. covers three sub-areas. The first sub-area describes the software quality Software Engineering Process (see Figure 3, column h) fundamentals such as software engineering culture and The Software Engineering Process KA is concerned with ethics, the value and costs of quality, models and quality the definition, implementation, assessment, measurement, characteristics, and quality improvement. management, change, and improvement of the software The second sub-area covers software quality management engineering process itself. It is divided into four sub- processes. The topics here are software quality assurance, areas. verification and validation, and reviews and audits. The first sub-area presents process implementation and The third and final sub-area describes practical 1–6 © IEEE – 2004 Version

×