`
`IBG 1024
`CBM of U.S. Pat. No. 7,685,055
`
`
`
`Oxford University Press, Walton Street. Oxford OX2 6DP
`Oxford New York
`Athens Auckland Bangkok Bogota Bombay
`Buenos Aires Calcutta Cape Town Dares Salaam
`Delhi Florence Hongkong Istanbul Karachi
`KualaLutnpur Madras Madrid Melbourne
`Mexico City Nairobi Paris Singapore
`Taipei Tokyo Toronto
`and associated companies in
`Berlin lbadan
`
`Oxford is a trade mark of Oxford University Press
`
`Published in the United States
`by Oxford University Press Inc.. New York
`
`12' Market House Books, 1983. I986. 1990. 1996
`
`First published 1 993
`Reprinted 1983, 1984. 1985
`Second Edition 1986
`Third Edition I 990
`Reprinted I990, I991 (twice), 1992
`Fourth Edition I 996
`
`All rights reserved No part of this publication may be
`reproduced. stored in a retrieval system. or transmitted. in any
`form or by any means. without the prior permission in writing of Oxford
`University Press. Mthin the UK. exceptions are allowed itt 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 tertns 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-l9—853855-3
`
`Text prepared by Market House Books Ltd. Aylesbury
`Printed in Great Britain by
`Biddles 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 system (and is therefore
`normally supplied by the manufacturer), and
`‘applications software specific to the partic-
`ular role performed b_v the computer within a
`given organization.
`
`Software Best Practice See ESSI.
`
`Software capability 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 t_vpi-
`cally followed by a period of preliminary
`investigation and high-level design. It is then
`possible to identify 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 by 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 b_v 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 engneerlng 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 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 s_vs-
`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