`CBM of U.S. Patent No. 7,212,999
`
`0001
`
`
`
`Oxford University Press, Walton Street. Oxford OX2 6DP
`Oxford New York
`Athens Auckland Bangkok Bogota Bombay
`Buenos Aires Calcutta Cape Town Daressalaam
`Delhi Florence HongKong Istanbul Karachi
`Kuala Lumpur Madras Madrid Melbourne
`Mexico City Nairobi Paris Singapore
`Taipei Tokyo Toronto
`and associated companies in
`Berlin Ibodan
`
`Oxford is a trade mark of Oxford University Press
`
`Published in the United States
`by Oxford University Press Inc.. New York
`
`E? Market House Books, I 983. 1986. I990. 1996
`
`First published I 993
`Reprinted I 983, I984. l 985
`Second Edition I 986
`Third Edition I990
`Reprinted I 990, 1991 / twice), I 992
`Fourth Edition 1996
`
`All rights reserved No part of this publication may be
`reproduced, stored in a retrieval system, or transmitted. at any
`form or by any means. without the prior permission in writing of Oxford
`University Press. Within the UK. exceptions are allowed in respect ofany
`fair dealingfor the purpose ofresearch or private study. or criticism or
`review, as permitted under the Copyright, Designs and Patents Act. 1988. or
`in the case ofreprographic reproduction in accordance with the tcnns of
`licences issued by the Copyright Licensing Agency. Enquiries concerning
`reproduction outside those terms and in other countries should be sent to
`the Rights Department. Oxford University Press. at the address above.
`
`This book is sold subject to the condition that it shall not,
`by way of trade or otherwise. be lent, re-sold. hired out. or otherwise
`circulated without the publisher ‘s prior consent in anyform ofbinding
`or cover other than that in which it is published and without a similar
`condition including this condition being imposed
`on the subsequent purchaser.
`
`A catalogue recordfor this book is availablefrom the British Library
`
`Library of Congress Cataloging in Publication Data
`( Data available)
`ISBN 0-I9-853855-3
`
`1'ext prepared by Market House Books Ltd. Aylesbury
`Printed in Great Britain by
`Bt'ddles Ltd, Guildford & King 's Lynn
`
`0002
`0002
`
`
`
`459
`
`SOFTWARE ENGINEERING ENVIRONMENT
`
`software A generic term for those compo-
`nents of a computer system that are intan-
`gible rather than physical. It is most com-
`monly used to refer to the programs executed
`by a computer system as distinct from the
`physical hardware of that computer system,
`and to encompass both symbolic and execut-
`able forms for such programs. A distinction
`can be drawn between "systems software,
`which is an essential accompaniment to the
`hardware in order to provide an effective
`overall computer s_vstem (and is therefore
`normally supplied by the manufacturer). and
`‘applications software specific to the partic-
`ular role performed by the computer within a
`given organization.
`
`Software Best Practice 5:: ESSI.
`
`Software capability and Maturity Model
`See Capability and Maturity Model.
`software component specification A pre-
`cise statement of the effects that the software
`component of a system is required to achieve.
`When developing a system. production of the
`‘software requirements specification is typi-
`cally followed b_v a period of preliminary
`investigation and high-level design. It is then
`possible to identif_v any necessary hardware
`components of the system and to produce the
`software component specification for
`the
`software component.
`specification
`A software
`component
`should be detailed, focusing on what the soft-
`ware is to do rather than how this is to be
`done. The traditional use of natural language
`for this purpose is being superseded b_v use of
`more formal notations.
`
`software development environment (pro-
`grammer workbench) The set of ‘soft-
`ware tools collected together (sometimes
`using a common database or user interface as
`in an ' IPSE) for use by a software developer,
`or team of developers, when developing soft-
`ware.
`
`software development process model
`(SDPM) A model that indicates a set of soft-
`ware processes — manual or automated — to be
`used in a software development project. The
`model should indicate the interdependencies
`that exist between the development processes
`including the products generated by each
`
`process, and the information (including
`products generated by other processes)
`required by each process.
`
`software engineering The entire range of
`activities used to design and develop soft-
`ware, with some connotation of “good prac-
`tice". Topics encompassed include user
`requirements elicitation. software require-
`ments definition, architectural and detailed
`design (set program design), ‘program speci-
`fication, program development using some
`recognized approach such as *structured
`programming, systematic ‘testing tech-
`niques, ‘program correctness proofs, ‘soft-
`ware quality assurance, software project
`management. documentation, performance
`and timing anal_vsis, and the development
`and use of "software engineering environ-
`mcnts. Further, software engineering is gen-
`erally expected to address the practical prob-
`lems of software development.
`including
`those encountered with large or complex sys-
`tems. Thus. while there is some emphasis on
`formal methods. pragmatic techniques are
`employed where necessary. In its entirety,
`software engineering addresses all aspects of
`the development and support of reliable and
`efficient programs for the entire range of
`computer applications
`
`software engineering environment A soft-
`ware system that provides support for the
`development, repair, and enhancement of
`software, and for the management and con-
`trol of these activities. A typical system con-
`tains a central database and a set of ‘software
`tools. The central database acts as a reposi-
`tory for all information related to a project
`throughout the lifetime of that project. The
`software tools offer support for the various
`activities, both technical and managerial, that
`must be performed on the project.
`Different environments vary in the gener-
`al nature of their databases and in the cover-
`age provided by the set of tools. In particular,
`some encourage (or even enforce) one specif-
`ic software engineering methodology, while
`others provide only general support and
`therefore allow any of a variety of methodol-
`ogies to be adopted. All environments, how-
`ever, reflect concern for the entire ‘software
`
`0003
`0003