`
`IBG 1036
`CBM of U.S. Patent No. 7,412,416 B2
`
`
`
`Oxford University Press, Walton Street. Oxford OX2 6DP
`Oxford New York
`Athens Auckland Bangkok Bogota Bombay
`Buenos Aires Calcutta Cape Town DaresSalaam
`Delhi Florence Honglfong Istanbul Karachi
`KualaLumpur 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
`
`1’; Market House Books, 1 983. 1986. I 990. l 996
`
`First published 1993
`Reprinted I983, I984. 1985
`Second Edition 1986
`Third Edition I990
`Reprinted I990, I991 (twice). 1992
`Fourth Edition I996
`
`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. 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. I988. or
`in the case ofreprographic reproduction in accordance with the terms 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,
`b_v way of trade or otherwise. be lent, re-sold. hired out. or otherwise
`circulated without the publisher‘: 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
`I Data available/
`ISBN 0-1 9—853855—3
`
`Text prepared by Market House Books Ltd. Aylesbury
`Printed in Great Britain by
`Biddle: Ltd. Guildford & King 's Lynn
`
`0002
`
`
`
`459
`
`SOFTWARE ENGINEERING ENVIRONMENT
`
`software .-\ generic term for those compo-
`nents of a computer system that are intan-
`gible rathcr than physical. It is most com-
`monly used to refer to the programs executed
`b_v a computer s_vstem 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 by the computer within a
`given organization.
`Software Best Practice Se: ESSI.
`
`Software capability and Maturlty Model
`Ste 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 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 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 b_v 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,
`s_vstematie ‘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
`
`0003