ɷ[david gustafson] schaum's outline of software engineering

Download ɷ[david gustafson] schaum's outline of software engineering

Post on 07-Apr-2016

217 views

Category:

Documents

5 download

Embed Size (px)

DESCRIPTION

[david gustafson] schaum's outline of software engineering

TRANSCRIPT

  • TEAMFLY

    Team-Fly

  • Want to learn more?

    We hope you enjoy this McGraw-Hill eBook! If youd like moreinformation about this book, its author, or related books and web-sites, please click here.

  • SCHAUMSOUTLINE OF

    Theory and Problems of

    SOFTWARE

    ENGINEERING

  • This page intentionally left blank.

  • Theory and Problems of

    SOFTWAREENGINEERING

    DAVID A. GUSTAFSONComputing and Information Sciences Department

    Kansas State University

    Schaums Outline SeriesMcGRAW-HILL

    New York Chicago San Francisco Lisbon London Madrid Mexico CityMilan New Delhi San Juan Seoul Singapore Sydney Toronto

  • Copyright 2002 by The McGraw-Hill Companies,Inc. All rights reserved. Manufactured in the United States of America. Except as per-mitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by anymeans, or stored in a database or retrieval system, without the prior written permission of the publisher.

    0-07-140620-4

    The material in this eBook also appears in the print version of this title:0-07-137794-8.

    All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a trademarkedname, we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of infringement of thetrademark. Where such designations appear in this book, they have been printed with initial caps.

    McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate train-ing programs. For more information, please contact George Hoare, Special Sales, at george_hoare@mcgraw-hill.com or (212) 904-4069.

    TERMS OF USEThis is a copyrighted work and The McGraw-Hill Companies, Inc. (McGraw-Hill) and its licensors reserve all rights in and to thework. Use of this work is subject to these terms. Except as permitted under the Copyright Act of 1976 and the right to store and retrieveone copy of the work, you may not decompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon,transmit, distribute, disseminate, sell, publish or sublicense the work or any part of it without McGraw-Hills prior consent. You mayuse the work for your own noncommercial and personal use; any other use of the work is strictly prohibited. Your right to use the workmay be terminated if you fail to comply with these terms.

    THE WORK IS PROVIDED AS IS. McGRAW-HILL AND ITS LICENSORS MAKE NO GUARANTEES OR WARRANTIES ASTO THE ACCURACY, ADEQUACY OR COMPLETENESS OF OR RESULTS TO BE OBTAINED FROM USING THE WORK,INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK VIA HYPERLINK OR OTHERWISE,AND EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McGraw-Hill and its licensors do notwarrant or guarantee that the functions contained in the work will meet your requirements or that its operation will be uninterrupted orerror free. Neither McGraw-Hill nor its licensors shall be liable to you or anyone else for any inaccuracy, error or omission, regardlessof cause, in the work or for any damages resulting therefrom. McGraw-Hill has no responsibility for the content of any informationaccessed through the work. Under no circumstances shall McGraw-Hill and/or its licensors be liable for any indirect, incidental, spe-cial, punitive, consequential or similar damages that result from the use of or inability to use the work, even if any of them has beenadvised of the possibility of such damages. This limitation of liability shall apply to any claim or cause whatsoever whether such claimor cause arises in contract, tort or otherwise.

    DOI: 10.1036/0071406204

    abcMcGraw-Hill

  • vSoftware Engineering is not just surveys of techniques and terminology; it includestechniques that students must master. This book is designed for college studentstaking courses in software engineering at the undergraduate and graduate level.During my 25+ years of teaching software engineering at both the undergraduateand graduate level, I have realized the need for solved examples and for guidanceto help students with these techniques.

    This book is intended to be used in conjunction with a textbook or lecture noteson software engineering. The background and motivation for diagrams, notationsand techniques are not included. Included are rules about proper construction ofdiagrams. Instructions on using techniques are given. Rules are included aboutapplying techniques. Most important, examples and solved problems are given fordiagrams, notations, and techniques.

    Writing this book was not a solitary eort. Many people have inuenced thisbook. In particular, I wish to acknowledge the following: Karen, my wonderfulwife, for all of her support and help in creating this book. Without her help, thisbook would not have been done. Steve, who took time from his PhD studies tocritique many of the chapters. My students, who provided the original inspirationfor writing this material and who have read these chapters as individual readings,have found mistakes, and have oered suggestions. I would like to thank Ramon,who suggested this book, and the McGraw-Hill editorial sta for their help andsuggestions.

    DAVID A. GUSTAFSON

    Copyright 2002 The McGraw-Hill Companies, Inc. Click Here for Terms of Use.

  • This page intentionally left blank.

  • vii

    CHAPTER 1 The Software Life Cycle 11.1 Introduction 11.2 Software Life Cycle Models 3

    CHAPTER 2 Software Process and Other Models 72.1 The Software Process Model 72.2 Data Flow Diagrams 92.3 Petri Net Models 102.4 Object Models 112.5 Use Case Diagrams 142.6 Scenarios 152.7 Sequence Diagrams 152.8 Hierarchy Diagrams 162.9 Control Flow Graphs 162.10 State Diagrams 172.11 Lattice Models 19

    CHAPTER 3 Software Project Management 303.1 Introduction 303.2 Management Approaches 303.3 Team Approaches 313.4 Critical Practices 323.5 Capability Maturity Model 333.6 Personal Software Process 343.7 Earned Value Analysis 353.8 Error Tracking 363.9 Postmortem Reviews 37

    CHAPTER 4 Software Project Planning 474.1 Project Planning 47

    Copyright 2002 The McGraw-Hill Companies, Inc. Click Here for Terms of Use.

    For more information about this book, click here.

  • 4.2 WBSWork Breakdown Structure 474.3 PERTProgram Evaluation and Review

    Technique 504.4 Software Cost Estimation 54

    CHAPTER 5 Software Metrics 725.1 Introduction 725.2 Software Measurement Theory 735.3 Product Metrics 765.4 Process Metrics 835.5 The GQM Approach 83

    CHAPTER 6 Risk Analysis and Management 916.1 Introduction 916.2 Risk Identication 916.3 Risk Estimation 926.4 Risk Exposure 926.5 Risk Mitigation 946.6 Risk Management Plans 94

    CHAPTER 7 Software Quality Assurance 997.1 Introduction 997.2 Formal Inspections and Technical Reviews 997.3 Software Reliability 1017.4 Statistical Quality Assurance 102

    CHAPTER 8 Requirements 1128.1 Introduction 1128.2 Object Model 1128.3 Data Flow Modeling 1138.4 Behavioral Modeling 1148.5 Data Dictionary 1168.6 System Diagrams 1178.7 IEEE Standard for Software Requirements

    Specication 118

    CHAPTER 9 Software Design 1279.1 Introduction 1279.2 Phases of the Design Process 1289.3 Design Concepts 1309.4 Measuring Cohesion 1329.5 Measuring Coupling 1359.6 Requirements Traceability 136

    CHAPTER 10 Software Testing 14510.1 Introduction 145

    CONTENTSviii

  • 10.2 Software Testing Fundamentals 14510.3 Test Coverage Criterion 14610.4 Data Flow Testing 15410.5 Random Testing 15510.6 Boundary Testing 157

    CHAPTER 11 Object-Oriented Development 16911.1 Introduction 16911.2 Identifying Objects 17111.3 Identifying Associations 17511.4 Identifying Multiplicities 178

    CHAPTER 12 Object-Oriented Metrics 18312.1 Introduction 18312.2 Metrics Suite for Object-Oriented Design 18412.3 The MOOD Metrics 189

    CHAPTER 13 Object-Oriented Testing 19913.1 Introduction 19913.2 MM Testing 20013.3 Function Pair Coverage 201

    CHAPTER 14 Formal Notations 20814.1 Introduction 20814.2 Formal Specications 20814.3 Object Constraint Language (OCL) 210

    INDEX 219

    CONTENTS ix

    TEAMFLY

    Team-Fly

  • This page intentionally left blank.

  • SCHAUMSOUTLINE OF

    Theory and Problems of

    SOFTWARE

    ENGINEERING

  • This page intentionally left blank.

  • 1The Software Life Cycle

    1.1 IntroductionThe software life cycle is the sequence of dierent activities that take place duringsoftware development. There are also dierent deliverables produced. Althoughdeliverables can be agreements or evaluations, normally deliverables are objects,such as source code or user manuals. Usually, the activities and deliverables areclosely related. Milestones are events that can be used for telling the status of theproject. For example, the event of completing the user manual could be a mile-stone. For management purposes, milestones are essential because completion ofmilestones allow, the manager to assess the progress of the software development.

    1.1.1 TYPES OF SOFTWARE LIFE CYCLE ACTIVITIES

    1.1.1.1 FeasibilityDetermining if the proposed development is worth-while.Market analysisDetermining if there is a potential market forthis product.

    1.1.1.2 RequirementsDetermining what functionality the softwareshould contain.Requirement elicitationObtaining the requirements from theuser.Domain analysisDetermining what tasks and structures arecommon to this problem.

    1.1.1.3 Project planningDetermining how to develop the software.Cost analysisDetermining cost estimates.SchedulingBuilding a schedule for the development.Software quality assuranceDetermining activities that will helpensure quality of the product.

    Copyright 2002 The McGraw-Hill Companies, Inc. Click Here for Terms of Use.

  • Work-breakdown structureDetermining the subtasks necessaryto develop the product.

    1.1.1.4 DesignDetermining how the software should provide the func-tionality.Architectural designDesigning the structure of the system.Interface designSpecifying the interfaces between the parts ofthe system.Detailed designDesigning the algorithms for the individualparts.

    1.1.1.5 ImplementationBuilding the software.

    1.1.1.6 TestingExecuting the software with data to help ensure that thesoftware works correctly.Unit testingTesting by the original developer.Integration testingTesting during the integration of the soft-ware.System testingTesting the software in an environment thatmatches the operational environment.Alpha testingTesting by the customer at the developers site.Beta testingTesting by the customer at the customers site.Acceptance testingTesting to satisfy the purchaser.Regression testingSaving tests from the previous version toensure that the new version retains the previous capabilities.

    1.1.1.7 DeliveryProviding the customer with an eective software solu-tion.InstallationMaking the software available at the customersoperational site.TrainingTeaching the users to use the software.Help deskAnswering questions of the user.

    1.1.1.8 MaintenanceUpdating and improving the software to ensurecontinued usefulness.

    1.1.2 TYPICAL DOCUMENTS

    1.1.2.1 Statement of workPreliminary description of desired capabil-ities, often produced by the user.

    1.1.2.2 Software requirements specicationDescribes what the nishedsoftware will do.Object modelShows main objects/classes.

    CHAPTER 1 The Software Life Cycle2

  • Use case scenariosShow sequences of possible behaviors fromthe users viewpoint.

    1.1.2.3 Project scheduleDescribes the order of tasks and estimates oftime and eort necessary.

    1.1.2.4 Software test planDescribes how the software will be tested toensure proper behavior.Acceptance testsTests designated by the customer to determineacceptability of the system.

    1.1.2.5 Software designDescribes the structure of the software.Architectural designThe high-level structure with the intercon-nections.Detailed designThe design of low-level modules or objects.

    1.1.2.6 Software quality assurance plan (SQA plan)Describes the activ-ities that will be done to ensure quality.

    1.1.2.7 User manualDescribes how to use the nished software.

    1.1.2.8 Source codeThe actual product code.

    1.1.2.9 Test reportDescribes what tests were done and how thesystem behaved.

    1.1.2.10 Defect reportDescribes dissatisfaction of the customer withspecic behavior of the system; usually, these are software fail-ures or errors.

    1.2 Software Life Cycle ModelsThe four dierent software life cycle models presented in the following sections arethe most common software life cycle models.

    1.2.1 THE LINEAR SEQUENTIAL MODELThis model, shown in Fig. 1-1, is also called the waterfall model, since the typicaldiagram looks like a series of cascades. First described by Royce in 1970, it was therst realization of a standard sequence of tasks.

    There are many versions of the waterfall model. Although the specic develop-ment tasks will occur in almost every development, there are many ways to dividethem into phases. Note that in this version of the waterfall, the project planning

    CHAPTER 1 The Software Life Cycle 3

  • activities are included in the requirements phase. Similarly, the delivery and main-tenance phases have been left o.

    1.2.2 THE PROTOTYPING MODELThis software life cycle model builds a throwaway version (or prototype). Thisprototype is intended to test concepts and the requirements. The prototype will beused to demonstrate the proposed behavior to the customers. After agreementfrom the customer, then the software development usually follows the same phasesas the linear sequential model. The eort spent on the prototype usually pays foritself by not developing unnecessary features.

    1.2.3 INCREMENTAL MODELD. L. Parnas proposed the incremental model.1 The goal was to design and deliverto the customer a minimal subset of the whole system that was still a useful system.The process will continue to iterate through the whole life cycle with additionalminimal increments. The advantages include giving the customer a working systemearly and working increments.

    1.2.4 BOEHMS SPIRAL MODELB. Boehm introduced the spiral model.2 The image of the model is a spiral thatstarts in the middle and continually revisits the basic tasks of customer com-munication, planning, risk analysis, engineering, construction and release, andcustomer evaluation.

    CHAPTER 1 The Software Life Cycle4

    Feasibility

    Requirements

    Design

    Implementation

    Testing

    Fig. 1-1. Waterfall model.

    1 D. Parnas. Designing Software for Ease of Extension and Contraction. IEEE Transactions on Software

    Engineering (TOSE) 5:3, March 1979, 128138.

    2 B. Boehm.. A Spiral Model for Software Development and Enhancement. IEEE Computer. 21:5, May 1988,

    6172.

  • Review Questions

    1. How does a phased life cycle model assist software management?

    2. What are two required characteristics of a milestone?

    3. For each of the following documents, indicate in which phase(s) of the software lifecycle it is produced: nal user manual, architectural design, SQA plan, module speci-cation, source code, statement of work, test plan, preliminary user manual, detaileddesign, cost estimate, project plan, test report, document...