Implementing the IEEE Software Engineering Standards

Transcription

1

2 Implemetig the IEEE Software Egieerig Stadards ;

3

4 Implemetig the IEEE Software Egieerig Stadards ; Michael Schmidt 800 East 96th Street Idiaapolis, Idiaa 46290

5 Copyright 2000 by Sams Publishig All rights reserved. No part of this book shall be reproduced, stored i a retrieval system, or trasmitted by ay meas, electroic, mechaical, photocopyig, recordig, or otherwise, without writte permissio from the publisher. No patet liability is assumed with respect to the use of the iformatio cotaied herei. Although every precautio has bee take i the preparatio of this book, the publisher ad author assume o resposibility for errors or omissios. Neither is ay liability assumed for damages resultig from the use of the iformatio cotaied herei. Iteratioal Stadard Book Number: Library of Cogress Catalog Card Number: Prited i the Uited States of America First Pritig: October Trademarks All terms metioed i this book that are kow to be trademarks or service marks have bee appropriately capitalized. Sams Publishig caot attest to the accuracy of this iformatio. Use of a term i this book should ot be regarded as affectig the validity of ay trademark or service mark. Figures reprited with permissio from IEEE Std 1074; 1490; ; ; 829; 1016; 982.1; 982.2; 1028; Copyright 2000, by IEEE. The IEEE disclaims ay resposibility or liability resultig from the placemet ad use i the described maer. Warig ad Disclaimer Every effort has bee made to make this book as complete ad as accurate as possible, but o warraty or fitess is implied.the iformatio provided is o a as is basis.the author ad the publisher shall have either liability or resposibility to ay perso or etity with respect to ay loss or damages arisig from the iformatio cotaied i this book. Associate Publisher Michael Stephes Acquisitios Editor Steve Agli Developmet Editors Laura N.Williams Heather Goodell Maagig Editor Matt Purcell Project Editor Daw Pearso Copy Editor Mary Elle Stepheso Idexer Sheila Schroeder Proofreader Katheri Bidwell Techical Reviewers Charles Ashbacher Tathagat Varma Team Coordiator Pamalee Nelso Iterior Desiger Kare Ruggles Cover Desiger Ala Clemets

6 IEEE Stadards Trademarks & Disclaimers The IEEE believes the iformatio i this publicatio is accurate as of its publicatio date; such iformatio is subject to chage without otice.the IEEE is ot resposible for ay iadvertet errors. IEEE Stadards Copyright Iformatio The IEEE Stadards refereced i this book are copyrighted by the Istitute of Electrical ad Electroics Egieers, Ic. All rights reserved. IEEE Stadards Iformatio Network Edorsemet Disclaimer The IEEE Stadards Iformatio Network (IEEE-SIN) edorsemet i this publicatio does ot reder this publicatio a cosesus documet. Iformatio cotaied i this ad other works has bee obtaied from sources believed to be reliable ad reviewed by credible members of IEEE Techical Societies, Stadards Committees ad/or Workig Groups ad/or relevat techical orgaizatios. Neither the IEEE or its authors guaratee the accuracy or completeess of ay iformatio published herei ad, either the IEEE or its voluteers, members ad authors shall be resposible for ay errors, omissios or damages arisig out of use of this iformatio. Likewise, while the IEEE ad its voluteers ad members believe that the iformatio ad guidace give i this work serve as a ehacemet to users, all parties must rely upo their ow skill ad judgmet whe makig use of it. Neither the IEEE or its voluteers or members assume ay liability to ayoe for ay loss or damage caused by ay error or omissio i the work, whether such error or omissio is the result of egligece or ay other cause. Ay ad all such liability is disclaimed. By edorsig this publicatio, it should be uderstood that the IEEE ad its voluteers ad members are supplyig iformatio through this publicatio, ot attemptig to reder egieerig or other professioal services. If such services are required, the assistace of a appropriate professioal should be sought.the IEEE is ot resposible for the statemets ad/or opiios advaced i this publicatio. IEEE Review Policy The iformatio cotaied i IEEE-SIN publicatios, ad others publicatios edorsed by the IEEE-SIN, is reviewed ad evaluated by peer reviewers of relevat IEEE Techical Societies, Stadards Committees ad/or Workig Groups ad/or relevat techical orgaizatios.the publisher addressed all of the reviewer s commets to the satisfactio of both the IEEE-SIN ad those who served as peer reviewers for this documet. v

7 The quality of the presetatio of iformatio cotaied i this publicatio reflects ot oly the obvious efforts of the authors, but also the work of these peer reviewers.the IEEE-SIN ackowledges with appreciatio their dedicatio ad cotributio of time ad effort o behalf of the IEEE. To order IEEE publicatios, call IEEE or, visit our web site at To order The IEEE Stadards refereced herei, call IEEE or, visit the IEEE Stadards web site at Edorsed by The IEEE Stadards Iformatio Network Implemetig the IEEE Software Egieerig Stadards' by Michael Schmidt is recogized by the Software Egieerig Stadards Committee of the IEEE Computer Society as a useful guide for software practitioers applyig software egieerig stadards. vi

8 Dedicatio To my family: My parets, Jürge ad Haa My wife, Elizabeth My childre, Emily, Eva, ad Erica Ackowledgmets I would like to thak the coutless IEEE members who cotributed to ad reviewed the stadards collectio over the years.without their efforts we would have o stadards. I would also like to thak my editors, Laura Williams, for ecouragig me, ad puttig up with me, ad Heather Goodell, for her help i completig the project. Special thaks to Jim Moore, who provided ivaluable feedback o the cotets of the book. I take credit for ay remaiig rough spots. vii

9 About the Author Michael Schmidt was bor i Cologe, Germay i His father, Jürge Schmidt, a well-kow mathematicia, moved the family to the Uited States i 1967 o a Fulbright-Hays teachig fellowship. Mike graduated from the Kikaid School i Housto,Texas, i 1977; received a B.A. i Mathematics from the Uiversity of Califoria at Berkeley i 1980; ad a M.A. i Mathematics from the Uiversity of Washigto at Seattle i I 1980, as a studet iter, Mike worked as a programmer o the cyclotro cotrol system at Lawrece Berkeley Laboratories. After receivig his degree at UW, Mike took a positio as a software egieer at Bi-M Istrumets, a start-up compay i Housto developig ballast cotrol systems for offshore oil rigs. I 1981, Mike was recruited by Varia Associates i Palo Alto to work o the software for a ext-geeratio liear accelerator for ocology care. At Varia, Mike was promoted to project egieer, leadig the team for the cotrol system software. I 1986, Mike was recruited to aother start-up compay,trasimage Corporatio i Melo Park, as a staff software egieer to develop a sophisticated optical-character-recogitio system. I 1987, Mike joied Siemes Medical Systems, agai as a project egieer to head the software team developig a ext-geeratio cotrol system for a liear accelerator for ocology care. Mike was promoted to maager of the software egieerig departmet at Siemes Medical Systems, Ocology Care Systems, with resposibility for all software developmet i five major product areas. I 1994, Mike started Software Egieerig Services, Ic., a software cosultig busiess specializig i fixed-price projects for software i the medical device, pharmaceutical, ad biotechology idustries, ad other idustries for which software plays a safety-critical role. SES has a log list of well-kow cliets i these idustries, ad has developed ad validated software for umerous sophisticated applicatios. Mike also has bee teachig computer sciece classes at Uiversity of Califoria Berkeley Extesio, ad Diablo Valley College, icludig C++ programmig, ad classes o the IEEE Software Egieerig Stadards. I 2000, Mike joied Zeiss Humphrey Systems, a leadig maufacturer of ophthalmic istrumets, as the software egieerig maager. Mike is a IEEE member. viii

10 About the Techical Reviewers Charles Ashbacher has bee programmig for early 20 years, which makes him experieced ad well-rouded rather tha old ad cyical. He is co-editor of Joural of Recreatioal Mathematics ad a regular cotributor to Joural of Object- Orieted Programmig. Charles teaches computig at all levels: corporate traiig, college, ad commuity educatio ad is presidet ad CEO of Charles Ashbacher Techologies ( His backgroud also icludes stits writig commercial code ad software to coduct scietific research. Tathagat Varma received a M.Sc. Computer Sciece (Software) degree from J.K Istitute of Applied Physics ad Techology, Uiversity of Allahabad, Idia i He the worked with the Defece Research ad Developmet Orgaizatio, Govermet of Idia, as a computer scietist util Durig this teure, he also participated i the III Idia Scietific Expeditio to Atarctica, where he stayed for 16 moths! I August 1995, he joied Siemes Commuicatio Software, Bagalore, where he worked i telecommuicatio software developmet for over a year. Sice December 1996, he has worked with Philips Software Cetre, Bagalore. Philips Software Cetre is the software arm of the Royal Philips Electroics,The Netherlads. I the last three years with Philips, he has worked with Medical Systems ad as SPI ad QA Maager. Curretly, he is maagig a project that ivolves developmet of embedded software for digital set-top boxes. He is formally traied i CMM, ISO Tick-IT, ad Philips Assessmet Method. He is also a active reviewer for the IEEE Software magazie. ix

11 Table of Cotets Itroductio 1 Purpose 1 Scope 2 Orgaizatio of Implemetig the IEEE Software Egieerig Stadards 3 1 Beefits of Software Egieerig Stadards 5 Software Quality 6 Tamig Project Cost ad Schedule 7 Achievig Compliace 10 Improved Maageability of Software Projects 10 Summary 11 2 Guidelies for Software Process Improvemets 13 Research Applicable Regulatios 14 Compile Data from Previous Projects 15 Pla the Scope of the Process Improvemets 16 Obtai Maagemet Commitmet 17 Build Groud-level Support 17 Draft Stadard Operatig Procedures 18 Coduct a Team Review 20 Approve ad Cotrol the Stadard Operatig Procedures 20 Specify the Phase-i of the Process Improvemets 21 Trai Persoel i the Process Improvemets 21 Moitor Use of the Process Improvemets 21 Evaluate the Success of the Process Improvemets 22 Summary 23 3 A Overview of the IEEE Software Egieerig Stadards 25 The SESC Framework 26 A Simplified Orgaizatioal Model 33 Iformatio Flow Betwee Documets Specified by Core Stadards 35 Applicability of Stadards 37 Missig Stadards 46 Summary 47 x

12 Cotets xi 4 Software Life Cycle Processes 49 IEEE/EIA , the Priciples Stadard 50 IEEE Std 1074, Developig the Software Life Cycle Process 58 The Black Box Model 62 The Waterfall Model 62 Spiral Model 70 Modified Waterfall Models 75 Summary 79 5 Work Product Stadards 81 User Documetatio Overview IEEE Std Requiremets Specificatios Overview IEEE Std Test Documetatio Overview IEEE Std Desig Descriptios Overview IEEE Std Metrics ad Measures Overview IEEE Std ad IEEE Std Process Stadards 135 Project Maagemet 136 Software Reviews 146 Quality Assurace 170 Verificatio ad Validatio 182 Cofiguratio Maagemet Practical Lessos 203 Stadard Operatig Procedures 204 Project Maagemet 205 Requiremets Aalysis 206 Desig 207 Cofiguratio Maagemet 209 Traiig 211 Outsourcig 212 Summary 213 A List of IEEE Software Egieerig Stadards 215 Volume 1: Customer ad Termiology Stadards 215 Volume 2: Process Stadards 216 Volume 3: Product Stadards 217 Volume 4: Resource ad Techique Stadards 217 B A List of Additioal Stadards 219 Idex 221

13 Tell Us What You Thik! As the reader of this book, you are our most importat critic ad commetator.we value your opiio ad wat to kow what we re doig right, what we could do better, what areas you d like to see us publish i, ad ay other words of wisdom you re willig to pass our way. As a Associate Publisher for Sams, I welcome your commets.you ca fax, , or write me directly to let me kow what you did or did t like about this book as well as what we ca do to make our books stroger. Please ote that I caot help you with techical problems related to the topic of this book, ad that because of the high volume of mail I receive, I might ot be able to reply to every message. Whe you write, please be sure to iclude this book s title ad author as well as your ame ad phoe or fax umber. I will carefully review your commets ad share them with the author ad editors who worked o the book. Fax: (317) etworkig_sams@macmilliausa.com Mail: Michael Stephes Sams Publishig 201 West 103rd Street Idiaapolis, IN USA xii

14 Itroductio Purpose The Istitute of Electrical ad Electroics Egieers (IEEE) Software Egieerig Stadards provide a comprehesive set of stadards for developig ad validatig software.the stadards are a fatastic resource, represetig coutless ma-years of effort.there is a ogoig program to ehace ad exted the stadards (approximately five ew stadards are developed each year). Amog the most highly regarded software egieerig stadards available today, the IEEE stadards are widely recogized i regulated idustries such as the medical device idustry. Proper use of the stadards ca help orgaizatios improve their software developmet ad validatio process, ad help implemet a effective software quality system. Ufortuately, idividuals or orgaizatios ofte fid it difficult to get started applyig the IEEE stadards, for three reasos: The collectio cosists of a large umber of stadards. Each stadard cotais detailed ad substatial iformatio. The IEEE itroductio ad the top-level stadard (IEEE/EIA ) are themselves complex ad do ot provide tutorial iformatio o adoptig the processes ad practices i a graduated fashio. This book is iteded to help overcome these hurdles. Implemetig the IEEE Software Egieerig Stadards will allow idividuals to lear the IEEE software egieerig stadards much faster ad with fewer missteps. For a orgaizatio phasig i use of the stadards, this book will provide a excellet road map.the iteded audiece icludes Software egieerig maagers ad egieers Software quality assurace maagers ad egieers Project maagers Implemetig the IEEE Software Egieerig Stadards was writte for the reader who has a workig kowledge of software developmet ad validatio, at least from a iformal eviromet. Previous experiece with the IEEE Software Egieerig Stadards is ot required to uderstad the material. 1

15 Scope Not all the stadards are discussed i the book.we will focus o the most importat priciples i the IEEE Software Egieerig Stadards collectio, to show the easiest way to phase i the stadards. Software process improvemets should be itroduced icremetally, ad use of the etire IEEE stadards collectio caot be realistically achieved all at oce. The stadards aalyzed provide the most iitial beefit to the user. Core stadards for such critical activities as specifyig software requiremets, documetig software testig, ad performig software verificatio ad validatio activities are preseted i detail. Beefits resultig from use of the stadards are described, to help readers motivate others i their orgaizatio. Commo pitfalls that ca jeopardize the successful implemetatio of the stadards are discussed. Issues relatig to harmoizig use of the stadards with curret idustry software developmet practices are explored, because the stadards should ot be a hidrace to efficiecy. This book does ot provide a comparative aalysis of the IEEE Software Egieerig Stadards relative to other atioal or iteratioal stadards for the same subject. Several scholarly books already serve this purpose icely. No attempt is made to establish a mappig betwee the IEEE Software Egieerig Stadards ad specific idustry regulatios such as the U.S. Quality Systems Regulatios for medical device maufacturers or to quality stadards such as the ISO-9000 stadards. Applicatio of the IEEE stadards ca be a extremely effective meas for achievig compliace with such regulatios ad quality stadards. But, may factors, such as the size of the orgaizatio ad the iheret risks associated with the software, determie what is required for a reasoable ad prudet software process model. Use of the IEEE stadards to achieve compliace i specific idustries should be evaluated idividually for each orgaizatio. This book does ot cotai a copy of ay of the stadards discussed.the most recet editio of the IEEE Software Egieerig Stadards ca be purchased directly from IEEE: IEEE Customer Service 445 Hoes Lae, PO Box 1331 Piscataway NJ USA (i the U.S. ad Caada) (outside of the U.S. ad Caada) customer.service@ieee.org 2

16 I additio, IEEE provides the Software Egieerig Stadards electroically via the Web through IEEE Stadards O-Lie Subscriptios.The Web site at provides details o this service. Orgaizatio of Implemetig the IEEE Software Egieerig Stadards Chapter 1, Beefits of Software Egieerig Stadards, is ot oly iteded to motivate the reader to implemet the stadards, but also to help the reader justify his use i his ow orgaizatio. Software process improvemets commoly meet resistace; overcomig it with educatio ad other positive techiques is essetial. Chapter 2, Guidelies for Software Process Improvemets, provides recommedatios based o years of the author s experiece i dealig with may differet orgaizatios attemptig process improvemets, drawig o both successes ad failures. Chapter 3, A Overview of the IEEE Software Egieerig Stadards, describes the stadards as a whole, icludig the relatioship of specific stadards to each other.this chapter is iteded to complemet the itroductory sectios of the most recet editio of the IEEE stadards, which cotai a descriptio of fudametal priciples ad a framework for the stadards. Although the IEEE itroductio is excellet i its geerality, it is ot optimized for a orgaizatio attemptig its first use of the stadards.this chapter provides a overview of the IEEE stadards for someoe lookig at them for the first time. Chapter 4, Software Life Cycle Processes, provides a framework for the sequece of activities to be performed for software projects.this chapter describes IEEE/EIA , which represets the top-level stadard i the IEEE collectio.this chapter also describes differet software life cycle models (SLCMs), relative to which idividual projects are plaed. Chapter 5, Work Product Stadards, presets key stadards for preparig importat work products, such as documets ad source code, durig the software life cycle. Oly the most importat such stadards, correspodig to deliverables required i ay software project, are discussed.these stadards are the easiest oes to uderstad, because they do ot presuppose ay great uderstadig of the software developmet ad validatio process.the impatiet reader might wat to proceed directly to Chapter 6 for a quick start. Chapter 6, Process Stadards, presets fudametal stadards that describe activities performed as part of the software life cycle. I some cases, these stadards also describe documets, but these represet plas for coductig activities. Agai, oly 3

17 the most importat process stadards, correspodig to activities expected i ay software project, are discussed. Idividuals who do t have persoal experiece with several substatial software projects ofte fid process stadards difficult to uderstad. Eve the, it ca be difficult to recocile persoal experiece iside of your orgaizatio with the termiology of the IEEE stadards. Chapter 6 attempts to make uderstadig the fudametal process stadards as easy as possible. Chapter 7, Practical Lessos, fiishes the book by discussig the author s experieces over the years with use of the IEEE stadards i idustry.this chapter discusses pitfalls as well as positive experieces, to help you get started. Idustry practices are maily orieted toward maximizig productivity, ad miimizig cost ad schedule. It is the author s opiio that best rapid software developmet practices ca be recociled with best software quality practices usig the IEEE Software Egieerig Stadards. 4

18 1 CHAPTER Beefits of Software Egieerig Stadards Software egieerig stadards defie the process by which software is developed ad validated withi a orgaizatio. Not oly do the stadards specify which plas, specificatios, reports, ad other documets shall be created durig a software project, they also specify how such documets shall be evaluated ad approved.the stadards must spa a wide rage of topics, icludig software project maagemet, requiremets aalysis, desig, verificatio ad validatio, testig, cofiguratio maagemet, ad other importat aspects of software egieerig. The purpose of this chapter is twofold: To covice the reader that the establishmet of software egieerig stadards provides sufficiet beefits to be worth implemetig To provide the already coviced reader with additioal argumets to use for persuadig the rest of his orgaizatio to adopt such stadards

19 Chapter 1 Beefits of Software Egieerig Stadards 6 Beefits of implemetig software egieerig stadards iclude Icreasig software quality. Use of stadards helps achieve greater coformace to software requiremets, reduce the umber of software defects, mitigate risks associated with the software, ad decrease software maiteace costs. Reducig project cost ad schedule. Use of stadards provides a framework for systematic, icremetal software process improvemets, ad helps reduce the umber of defects itroduced durig early project phases.this reduces the cost ad schedule of the testig, istallatio, ad maiteace phases. Achievig compliace. Use of stadards helps satisfy govermetal regulatios ad idustry quality stadards as they relate to software, ad is essetial for passig audits ad achievig certificatio.the eed to achieve compliace is a hard busiess reality for compaies i a umber of idustries. Improvig maageability of software projects. Use of stadards provides ehaced accuracy of project plaig, detailed meas of trackig projects, early measures of software quality, ad improved repeatability of success stories. Major beefits are explored i more detail later i the chapter. Software Quality Software egieerig stadards, if sufficietly comprehesive ad if properly eforced, establish a quality system, a systematic approach to esurig software quality, which is defied by IEEE Std as: (1) The degree to which a system, compoet, or process meets specified requiremets. (2) The degree to which a system, compoet, or process meets customer or user eeds or expectatios. A quality system should cosist of more tha just testig. A moder, comprehesive approach requires a systematic process for the etire software life cycle. Quality caot be tested ito software ay more effectively tha quality ca be ispected ito fiished maufactured goods.testig of complex software systems ca ever be exhaustive, ad a large umber of software defects idetified durig testig, eve if corrected, ivariably imply that may additioal software defects have ot yet bee discovered.

20 Tamig Project Cost ad Schedule 7 The relative importace of software quality depeds o the applicatio. However, quality is importat for ay software product. Improvig software quality has busiess advatages for the followig reasos: Icreased sales volume. Customer satisfactio, which ca oly be expected if the software meets the customers eeds ad expectatios, should lead directly to icreased sales. Decreased support costs. If the umber of software defects ca be reduced, costs associated with software istallatio, maiteace, service, ad support ca be decreased. Reduced liability. I some applicatios software defects ca potetially lead to ijury or death, or result i damage to property or equipmet. I these cases, busiesses face sigificat liability issues. Assurig software quality becomes essetial for mitigatig such risks. Software reuse. If of sufficiet quality to be reused, software compoets ca represet a sigificat orgaizatioal asset. Software reuse ca improve the time to market for later projects, a importat cosideratio for fast cycle time projects such as Iteret applicatios. Software egieerig stadards should ot remai froze idefiitely.they should be reevaluated periodically for possible software process improvemets. Data should be collected to provide some measure of the software quality achieved i previous software projects. Metrics such as the umber of defects idetified durig testig ad the umber of problem reports received from users may be used for this purpose. Such iformatio should be carefully aalyzed to idetify ay weakesses i the process model ad to target icremetal improvemets to the quality system. Tamig Project Cost ad Schedule Software projects are otorious for cost ad schedule overrus. Historically, may compaies with excellet track records i developig hardware products have experieced software project failures of gargatua proportios. Software projects, if ot maaged properly, ca simply ru out of cotrol. Maagig software developmet projects differs from maagig hardware projects. Maagemet techiques that worked i the past for other egieerig disciplies have prove ieffective for software. A primary challege of software egieerig lies i addressig the very high complexity associated with most software. Defects ca be itroduced durig may tasks i differet phases of a software developmet project, through a umber of itermediate documets attemptig to specify the

21 Chapter 1 Beefits of Software Egieerig Stadards 8 software, or i the software source code itself. May software programs cotai so may source code statemets that it is essetially impossible for ay oe perso to read through ad comprehed their etirety. Although the egieerig tasks are similar for hardware ad software developmet, software egieerig requires its ow uique termiology, ad a eve greater emphasis o systematic verificatio ad validatio. Based o may years of experiece, we ow kow the reaso why may large software projects failed:they were executed without ay guidig stadards whatsoever! The lack of stadards reflected maagemet iability to uderstad the process of software developmet ad resulted i the settig of ureasoable goals. Without a process model, without software egieerig stadards, a software developmet project becomes a black box. First, the acquirer attempts to describe the desired software fuctioality as best as possible to the supplier. Next, the acquirer is forced to wait for the software product to fially be delivered by the supplier. Software validatio cosists oly of acceptace testig, to determie whether the acquirer s eeds ad expectatios were met. If they were ot, the acquirer must decide whether it is worth repeatig this fallible, legthy, ad costly process. Maagemet ufamiliar with the software developmet process might ot be able to cotrol a software project eve withi their ow orgaizatio ay more effectively tha what was just described. Cotaiig project cost ad schedule begis with the ability to accurately estimate them before a project starts. For this purpose, it is essetial to uderstad what tasks must be performed, i what order, ad what persoel ad other resources are required for these tasks. Stadardizatio of the process allows usig actual cost ad schedule iformatio from previous projects to estimate the ext project. Defiig milestoes helps make sure that everyoe iterprets the schedule i the same way. Eve whe a simple software process model is already established, sigificat cost ad schedule overrus ca occur. Frequetly, this happes whe a more ambitious software project is attempted, ad a steady stream of software defects keeps the project i the implemetatio ad testig phases. Defects are discovered durig testig, ad the software is set back for rework (revisitig the implemetatio phase).the corrected software is set back for more testig, but more software defects are discovered.this cycle, eve if well defied, ca go o much loger tha origially plaed. Experiece has show that software defects are ofte itroduced durig the requiremets aalysis ad desig phases. Defects i the deliverables of these early project phases have a greater cost ad schedule impact tha implemetatio errors if ot detected prior to testig.this is because of a cascadig effect: A mistake i defiig the requiremets might imply o-trivial redesig, i tur requirig sub-

22 Tamig Project Cost ad Schedule 9 statial recodig of the software. I compariso, a codig error might require correctio of a sigle software module, with o chages to the desig or requiremets specificatio. Software testig is a iefficiet mechaism for detectig defects itroduced durig requiremets aalysis ad desig. Other types of desig cotrols particularly reviews ad ispectios of itermediate work products, such as Software Requiremets Specificatios ad Software Desig Descriptios help idetify such defects earlier. Reviews ad ispectios mitigate the project cost ad schedule impacts of defects more effectively tha testig aloe. Idustry experiece has show that ivestmet of sufficiet persoel resources for effective desig cotrols early i a project is more tha offset by the associated savigs durig the implemetatio, testig, ad maiteace phases. Figure 1.1 illustrates typical savigs that ca be achieved. Effort 10-40% reductio 15% icrease with ispectios Time without Figure 1.1 Expected cost ad schedule improvemets usig ispectios. Busiesses ofte hesitate to formalize their software developmet process, fearig that this would result i more busy work, ad thus icrease project cost ad schedule. Such fears are frequetly heard both from maagemet ufamiliar with software developmet projects ad from programmig staff uaccustomed to the use of software egieerig stadards. Admittedly, busiesses must be profitable; they caot afford iefficiet programs that icrease software quality but also icrease project cost ad schedule sigificatly. A effective quality system should reduce both project cost ad schedule, while improvig the quality of the software products. Just as software quality should be measured ad aalyzed for possible software process improvemets, measuremets should quatify the positive or egative impact of the quality system i terms of project cost ad schedule. Icremetal process improvemets should be attempted to achieve reduced project cost ad schedule, while maitaiig or improvig software quality.

23 Chapter 1 Beefits of Software Egieerig Stadards 10 Achievig Compliace I certai idustries, establishig effective software egieerig stadards is madatory. For example, the U.S. Quality System Regulatio govers medical device software.the Ceter for Devices ad Radiological Health of the Food ad Drug Admiistratio provides guidelies for software developmet ad validatio i accordace with this regulatio. Failure to comply with govermetal regulatios ca have disastrous busiess cosequeces, icludig recalls of products, closure of maufacturig facilities, ad eve priso seteces for executives resposible for the violatios. The ISO-9000 stadards also require a systematic process for software developmet ad validatio. ISO-9000 certificatio is a busiess ecessity i may cases, particularly for compaies targetig the Europea market, ad for software suppliers to ISO-9000[d]certified compaies. These types of regulatios ad stadards do ot specify the software developmet ad validatio process to be used. Each orgaizatio ca develop its ow process model, as log as it satisfies geeral requiremets imposed by the regulatios. Each orgaizatio is expected to describe its ow process model by meas of a set of iteral software egieerig stadards, which must be mapped to the exteral regulatios ad stadards. The IEEE Software Egieerig Stadards ca be used i cojuctio with some iteral stadard operatig procedures to satisfy exteral regulatios ad stadards. The IEEE Software Egieerig Stadards are specific, for example, regardig templates for creatig Software Requiremets Specificatios somethig o govermetal regulatios would specify i such detail.the IEEE Software Egieerig Stadards are widely recogized ad respected, ad their use ca help achieve compliace i a timely ad effective maer. Achievig a effective quality system ca be difficult if process compliace is the oly goal. Emphasis should also be placed o improvig the quality of the fiished software products, ad o icorporatig idustry best practices ito the process model. Miimal process stadards implemeted oly to satisfy exteral process requiremets caot be expected to yield substative quality beefits. Improved Maageability of Software Projects Use of software egieerig stadards allows more effective maagemet of software projects. Project plaig with software egieerig stadards is more accurate, because the tasks to be performed, ad the order i which they are to be performed, are more

24 Summary 11 clearly specified. Project persoel are more likely to uderstad task assigmets correctly, because of the descriptios provided by the stadard process model. Project trackig with software egieerig stadards is more meaigful, because the life cycle model defied by the stadards will specify uambiguous milestoes ad the meas of verifyig their achievemet. Software egieerig stadards allow evaluatig software quality early i the software life cycle.verificatio activities durig early project phases ca idetify systemic quality problems, permittig corrective actios to be take i a timely maer. Successes with previous projects ca be repeated by followig the same process used before. Failures i previous projects ca be aalyzed, ad improvemets to the process model ca be attempted so as ot to repeat mistakes. Software egieerig stadards allow precise defiitio of a process, ad thus provide the framework for process improvemets. Summary To ayoe who has worked o software projects for years, the advatages of usig stadards will be self-evidet. Coscietious software egieers will develop persoal stadards i the absece of orgaizatioal stadards. For larger software projects ivolvig teams of people, ad from the poit of view of the orgaizatio coductig such projects, stadards are essetial. Stadards provide commo termiology for team commuicatio. Stadards provide a well-defied referece model, relative to which maagemet ca issue assigmets ad track progress. Stadards provide a checklist of required activities, which ca be verified for quality assurace. Stadards must be followed. If a orgaizatio creates a impressive set of stadards o how to develop ad validate software, but fails to follow those stadards i actual projects, othig is gaied. I fact, failure to follow iteral stadards shows a blatat disregard for quality, ad is worse tha ot yet havig established iteral stadards. Stadards require maagemet commitmet. It is almost impossible to effectively itroduce software egieerig stadards ito a orgaizatio whose maagemet is ot firmly committed to establishig a effective software quality system. Maagemet support is a essetial prerequisite to all attempts at software process improvemets. Stadards must be maitaied.they should reflect the process maturity of the orgaizatio developig ad validatig the software. A effective software process

25 Chapter 1 Beefits of Software Egieerig Stadards 12 improvemet program will periodically review its software egieerig stadards ad target icremetal improvemets based o feedback from previous projects. Software developmet is still a ew disciplie. It has bee widely practiced as a ustructured, ofte chaotic activity, frequetly resultig i software products o which o sae perso would stake their life.we ca compare this era to the days of uregulated pharmaceuticals i the previous cetury.those times are past! Eough has bee leared about software egieerig, ad eough effort has bee ivested ito stadards such as the IEEE Software Egieerig Stadards collectio, that failure to establish ad follow a structured process model for software developmet ad validatio is, at best, uprofessioal. I certai idustries, such as the medical device idustry, it is illegal.we would ot wat our bridges built, or our airliers desiged, without proper egieerig techiques, ad we should ot expect less of the software products that have become such a itegral part of our ecoomy.

26 2 CHAPTER Guidelies for Software Process Improvemets Itroductio of ew or revised software egieerig stadards ito a orgaizatio represets a type of software process improvemet. Ay process chage carries iheret risks.the learig curve for everyoe ivolved ca jeopardize the success of a ogoig project. Ill coceived process improvemets ca compromise the efficiecy with which software is developed ad validated. Attemptig too much at oce ofte creates problems. Disechated persoel might reject ot oly recetly attempted chages, but the etire quality system. Orgaizatios are most vulerable to such istabilities whe they are first attemptig to defie their process model. This chapter provides guidelies for software process improvemets, particularly for phasig i use of a subset of the IEEE Software Egieerig Stadards. Due to the risks metioed previously, careful plaig ad proper executio is essetial. These guidelies will help you effectively phase i use of the IEEE Software

27 Chapter 2 Guidelies for Software Process Improvemets Egieerig Stadards i your orgaizatio, while avoidig commo pitfalls. More detailed iformatio will be provided for specific stadards as they are aalyzed i later chapters. This chapter presets the guidelies for process improvemets as a sequece of 12 steps (or, if you prefer, a checklist of issues to address).these are as follows: 1. Research applicable regulatios. 2. Compile data from previous projects. 3. Pla the scope of the process improvemets. 4. Obtai maagemet commitmet. 5. Build groud-level support. 6. Draft Stadard Operatig Procedures. 7. Coduct a team review. 8. Approve ad cotrol the Stadard Operatig Procedures. 9. Specify the phase-i of the process improvemets. 10. Trai persoel i the process improvemets. 11. Moitor use of the process improvemets. 12. Evaluate the success of the process improvemets. 14 Research Applicable Regulatios Before you get started with ay process improvemet, carefully research all applicable govermetal regulatios ad idustry quality stadards that you must satisfy. If ecessary, seek help i this task, because it is critical. For example, for medical device software, you will wat to look at the Web site for the FDA Ceter for Devices ad Radiological Health This site cotais documets such as Geeral Priciples of Software Validatio ad Guidace for the Cotet of Premarket Submissios for Software Cotaied i Medical Devices.These excellet guides might prove beeficial to you, eve if you are ot developig medical device software. As precisely ad realistically as possible, idetify all discrepacies betwee your orgaizatio s curret process, ad the madates of applicable regulatios. If ay such discrepacies are foud, their resolutio will represet your highest priority for process improvemets. This issue should be reexamied o a ogoig basis, wheever the regulatios or govermetal guidelies for their iterpretatio are updated.

28 Compile Data from Previous Projects 15 Compile Data from Previous Projects Iformatio from previous projects ca provide ivaluable help i plaig software process improvemets. Quatitative measuremets are ofte more helpful tha aecdotal iformatio, particularly if it is available over a statistically meaigful time period. Eve if your orgaizatio has ot systematically collected software project metrics data i the past, sigificat iformatio might be available from the followig sources: Comparisos betwee plaed versus actual project schedules. If available, fid ay schedules approved at the begiig of past projects, ad measure ay slippage i the actual completio of key milestoes. Actual project costs. Cost iformatio is sometimes difficult to capture. Time, material, ad all applicable overhead should be accouted for, or estimated to the best of your ability. Payroll iformatio, particularly if coded accordig to projects, provides a tremedous wealth of iformatio. As for schedules, comparisos should be made betwee budgeted versus actual project costs. Test icidet reports. Software defects idetified durig testig provide a measure of the software s quality. If the iformatio is available, determie how may defects were itroduced i which phase of each project. Problem reports. Software problems reported by customers or users are the most importat measure of software quality. Such problems represet failures ot oly i the software developmet effort, but also i the software validatio effort. If possible, categorize what software verificatio ad validatio activity might have bee expected to catch the problem but failed to do so. Software complexity metrics. Use automated tools to aalyze the source code from previous projects ad determie the size ad complexity of the software.the umber of lies of code ca used to measure the size of the software; take together with the actual project cost ad schedule used, the umber of code lies idicates the project s relative efficiecy. Excessive complexity of the source code is a excellet predictor of low software quality. Existece of required documets. Verify the existece of all required documets from previous projects, ad ote all discrepacies. If a software process improvemet program is already uderway i your orgaizatio, you might have far more iformatio available tha suggested here. Use all the data at your disposal!

29 Chapter 2 Guidelies for Software Process Improvemets 16 Aalyze the statistics you have collected.try to determie ay treds. Sigificat problems will be readily apparet. By providig quatitative, objective iformatio, you ca more easily justify software process improvemets to others. Pla the Scope of the Process Improvemets Based o the iformatio available to you, pla the scope of the software process improvemets. As your highest priority, you should focus o correctig regulatory o-compliace ad glarig problem treds from previous projects. Use of ew techiques ad tools to improve quality ad efficiecy might be ext o the priority list. You must limit the scope of the process improvemets to a realistic size.you might ot be able to address all the issues you have idetified, perhaps ot eve all the high-priority items! Makig your immediate process improvemets succeed ad layig the foudatio for future process improvemets are more importat tha defiig the ultimate process model for your orgaizatio. Be pragmatic! The key to success i plaig software process improvemets is to make them icremetal. Experiece has show that modest process improvemets are more successful tha completely restructurig a etire process. A orgaizatio is oly capable of a certai amout of chage at a time. Later parts of this book aalyze specific IEEE Software Egieerig Stadards i detail. By readig through the stadards ad later chapters, you ca come to your ow coclusios about which of them might be appropriate for your orgaizatio. If you have o formal software stadards i use, the easiest way to start is with certai documet stadards.the followig IEEE stadards specify the format ad cotet of key documets, which will be produced durig a software project: Software Requiremets Specificatios (IEEE Std. 830). The SRS is the sigle most importat work product developed i a software project besides the software itself. A agreemet betwee the developmet group ad its cliets at the begiig of the project, the SRS states what the software should do.the SRS uambiguously istructs software desigers durig their efforts. Fially, the SRS serves as the basis for software validatio ad testig. Software Test Documetatio (IEEE Std. 829). Although we ow recogize that software Verificatio ad Validatio (V&V) is about more tha just testig, software testig remais the most basic ad critical V&V activity.testig must be documeted i order to demostrate regulatory compliace, to repeat previous tests, ad to effectively maage the substatial cost ad schedule associated with it.

30 Build Groud-level Support 17 Obtai Maagemet Commitmet Software process improvemets are doomed if maagemet does t commit to makig them work.the cosiderable overhead ivolved i plaig ad implemetig the process improvemets must be accouted for.there are always risks associated with ay process chage, ad maagemet must be properly prepared for possible temporary setbacks, so as ot to overreact.the goals ad expectatios of the process improvemets should be clearly defied so that maagemet ca draw proper coclusios as to the relative success of the improvemets. The key cocepts behid your process improvemet pla should be summarized for maagemet, icludig: Aticipated beefits. Specify beefits of the process improvemets, icludig better software quality, reduced project cost ad schedule, regulatory compliace, ad improved maageability of software projects.the beefits should be realistic ad measurable. Descriptio of chages. You must succictly explai the curret process model ad proposed chages to it. Defie software egieerig termiology as eeded for this purpose. Process diagrams ca be helpful. Phase-i strategy. The aticipated cost ad schedule for phasig i the proposed software process improvemets must be clearly commuicated. Specify clearly what resources maagemet must provide to make the phasei a success. Evaluatio program. Defie how the software process improvemets will be moitored, ad what quatitative measuremets will be performed to evaluate their efficacy. Specify the schedule for ay reports to maagemet at the ed of the phase-i period or later. If maagemet will ot commit to the software process improvemets, do ot attempt them! Istead, explore the cocers voiced by maagemet, ad propose alteratives to your origial process improvemets based o such cocers. Build Groud-level Support After you ve obtaied prelimiary maagemet support for process improvemets, you must still build cosesus amogst the affected persoel. Depedig o the group dyamics, it might be preferable to do this prior to seekig maagemet support. I ay case, you must have the support of a majority of those who will execute the process improvemets.

31 Chapter 2 Guidelies for Software Process Improvemets 18 Developig a cosesus for process improvemets ca be a easy task, or it ca seem close to impossible, depedig o the persoalities ivolved. Suggestios for process improvemets should be systematically solicited, ad all participats should have a opportuity to voice their opiios. A presetatio ca be helpful, explaiig the reasos for ad ature of the proposed process chages. All persoel should be reassured that they will receive sufficiet traiig as eeded ad sufficiet time to lear ay ew techiques. Process improvemets should ot feel like puishmet to those attemptig to follow them! No discussio of this topic ca be cosidered complete without metioig the cyic who might exist i your orgaizatio, who systematically ridicules all attempts to formalize the software developmet process. Cyicism ca serve a positive fuctio, as a reality check, but all too ofte it becomes a detrimet to the orgaizatio as a whole. Factioalism ad decreased morale sigal uproductive cyicism. Ufortuately, there are o easy aswers for dealig with such cyicism, ad each case must be cosidered idividually. If your orgaizatio has a legitimate busiess eed for the process improvemets, ad if a employee systematically impedes their implemetatio, corrective actio is required.this might ivolve traiig, reassigmet, or, i the worst case, dismissal of the employee.this coclusio might seem uduly harsh, but may software developmet groups simply ca o loger afford to retai the ustructured programmig methodology used i the past. Draft Stadard Operatig Procedures Stadard Operatig Procedures (SOPs) should be writte to describe the software developmet ad validatio process. SOPs should specify termiology, the process model, documets to be created, techiques to be used, ad product stadards to be observed. SOPs should be Correct. Software SOPs must accurately describe the process actually followed by your orgaizatio for software developmet ad validatio. A major discrepacy would soo become apparet i ay audit, ad would be uacceptable. Uambiguous. Oly oe iterpretatio of the process should be possible so that all team members uderstad the process i the same maer. Complete. Software SOPs should provide stadards for all sigificat software developmet ad validatio activities i all phases of software projects. However, whe first itroducig SOPs, you might wat to formalize oly a subset of the tasks.

32 Draft Stadard Operatig Procedures 19 Cosistet. Software SOPs should be iterally cosistet, ad should be cosistet with SOPs from your orgaizatio s o-software processes. Verifiable. Software SOPs should be writte i such a way that they ca be verified by use i actual projects. Software developmet ad validatio SOPs should serve a umber of importat fuctios for your orgaizatio: Defie iterfaces to o-software processes. Other parts of your orgaizatio will have their ow processes, ad the termiology describig them will ot always map easily to software idustry stadards.your SOPs should defie the iterfaces betwee the software ad o-software processes i your orgaizatio, ad defie the traslatio betwee termiology used i software versus o-software tasks. Assig resposibilities. Resposibilities for key software developmet ad validatio activities should be assiged to departmets, reflectig the orgaizatio s structure. Referece specific stadards. Geerally, it is better to referece stadards such as idividual IEEE Software Egieerig Stadards, rather tha to duplicate iformatio from them. Idividual stadards, such as IEEE Std. 830 for Software Requiremets Specificatios, should be explicitly refereced if they are to be followed. Describe a life cycle model. Idustry stadards do ot specify life cycle models; rather, idividual orgaizatios should create their ow models based o their size, philosophy, ad other cosideratios.this meas you must specify a stadard life cycle model to be followed for software developmet ad validatio withi your orgaizatio. Specify tools. Your orgaizatio might cosistetly use specific tools for certai activities, such as a documet cotrol system, a bug-trackig system, or CASE tools.your SOPs should referece all such tools explicitly. Provide programmig stadards. Every orgaizatio is expected to maitai its ow detailed guidelies for programmig stadards.there is o IEEE stadard for this purpose. Diagrams, forms, ad other attachmets ca be helpful i SOPs.Whe ew persoel eter your orgaizatio, SOPs ca be a importat traiig tool to teach resposibilities to the ew team member. How may software SOPs are eeded, ad how these should be formatted depeds etirely o your orgaizatio. I geeral, it is better to separate low-level SOPs, such as programmig stadards, from high-level oes, such as oe defiig