`CBM of U.S. Pat. No. 7,676,411
`
`
`
`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 Ibadan
`
`Oxford is a trade mark of Oxford University Press
`
`Published in the United States
`by Oxford University Press Inc.. New York
`
`6 Market House Books, 1983. 1986. I990. 1996
`
`First published 1 993
`Reprinted l 983, I984. 1985
`Second Edition I986
`Third Edition 1990
`Reprinted I 990, 1991 ( twice), I992
`Fourth Edition 1996
`
`All rights reserved No part of this publication may be
`reproduced. stored in a retrieval system, or transmitted. t'n 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 tenns 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-! 9453855-3
`
`Text prepared by Market House Books Ltd. Aylesbury
`Printed in Great Britain by
`Biddle: Ltd, Guildford & King 's Lynn
`
`
`
`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-
`monl_v 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 system (and is therefore
`normally supplied b_v the manufacturer), and
`‘applications software specific to the partic-
`ular role performed by the computer within a
`given organization.
`
`Software Best Practice Se: ESSI.
`
`Software capahllity and Maturity Model
`5:: 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 by 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
`desigfl (see 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 analysis, and the development
`and use of "software engineering environ-
`ments. 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