A failure of the sensor which detects an obstacle in front of a machine is an example of a hazard. Damage A measure of the loss resulting from a mishap. Damage can range from many people killed as a result of an accident to minor injury or property damage.
Hazard An assessment of the worst possible damage which could result from a severity particular hazard. Hazard severity can range from catastrophic where many people are killed to minor where only minor damage results Hazard The probability of the events occurring which create a hazard.
Risk This is a measure of the probability that the system will cause an accident. The risk is assessed by considering the hazard probability, the hazard severity and the probability that a hazard will result in an accident. Software failures are different from hardware failures in that software does not wear out.
It can continue in operation even after an incorrect result has been produced. This metric is sometimes called the failure intensity. MTTF The average time between observed system failures. For Mean time to failure example, an MTTF of means that 1 failure can be expected every time units. MTTR The average time between a system failure and the return of Mean time to repair that system to service.
For example, an availability of 0. The reliability specification must be structured. Transient, non- The magnetic stripe data cannot be POFOD corrupting read on an undamaged card which 1 in transactions is input. Transient, A pattern of transactions across the Unquantifiable! Should corrupting network causes database never happen in the corruption. Safety req. Ideally, these should be as small a part as possible of the whole system.
Usually there will be a number of alternative causes. The degree of required protection depends on the asset value so that a password file say is more valuable than a set of public web pages. Where appropriate, these will explicitly identified the security technologies that may be used to protect against different threats to the system. Risk analysis identifies critical hazards and classifies risks according to their seriousness.
It does NOT mean software which will always perform correctly as there may be specification errors. It is only cost-effective in exceptional situations.
Fault tolerance is required where there are high availability requirements or where system failure costs are very high.. As many software faults are transitory, this is often unnecessary. Changes are not applied until computation is complete. Essentially, selection of the actual output depends on the majority vote. They therefore ought to have different failure modes. All versions compute simultaneously and the majority output is selected using a voting system..
It is assumed that there is a low probability that they will make the same mistakes. The algorithms used should but may not be different. Some parts of an implementation are more difficult than others so all teams tend to make mistakes in the same place.
Used for reliability estimation. Have all constants been named? Should the lower bound of arrays be 0, 1, or something else? Should the upper bound of arrays be equal to the size of the array or Size -1? If character strings are used, is a delimiter explicitly assigned?
Control faults For each conditional statement, is the condition correct? Is each loop certain to terminate? Are compound statements correctly bracketed? In case statements, are all possible cases accounted for? Are all output variables assigned a value before they are output? Interface faults Do all function and procedure calls have the correct number of parameters? Do formal and actual parameter types match?
Are the parameters in the right order? If components access shared memory, do they have the same model of the shared memory structure? Storage management If a linked structure is modified, have all links been faults correctly reassigned?
If dynamic storage is used, has space been allocated correctly? Is space explicitly de-allocated after it is no longer required? Exception Have all possible error conditions been taken into Inspection checks management faults account?
Checks for loops with multiple exit or entry points, finds unreachable code, etc. Detects uninitialised variables, variables written twice without an intervening assignment, variables which are declared but never used, etc. Identifies the dependencies of output variables. Does not detect anomalies itself but highlights information for code inspection or review l Path analysis.
Identifies paths through the program and sets out the statements executed in that path. Again, potentially useful in the review process l Both these stages generate vast amounts of information.
Must be used with care. Responsible for developing and maintaining the system specification l Development team. Responsible for developing and verifying the software. The software is NOT executed or even compiled during this process l Certification team. Responsible for developing a set of statistical tests to exercise the software after development. Does not imply adequacy of testing.
Stressing the system often causes defects to come to light l Stressing the system test failure behaviour.. Systems should not fail catastrophically. The cost of verification increases exponentially as the system size increases. They must demonstrate that the system cannot reach an unsafe state. Platform experience May be significant if low-level programming is involved.
Otherwise, not usually a critical attribute. Programming language Normally only significant for short duration projects experience where there is insufficient time to learn a new language. Educational background May provide an indicator of the basic fundamentals which the candidate should know and of their ability to learn. This factor becomes increasingly irrelevant as engineers gain experience across a range of projects.
Communication ability Very important because of the need for project staff to communicate orally and in writing with other engineers, managers and customers.
Adaptability Adaptability may be judged by looking at the different types of experience which candidates have had. This is an important attribute as it indicates an ability to learn. Attitude Project staff should have a positive attitude to their work and should be willing to learn new skills.
This is an important attribute but often very difficult to assess. Personality Again, an important attribute but difficult to assess. Candidates must be reasonably compatible with other Staff selection team members. No particular type of personality is factors more or less suited to software engineering. Accepting a low profit on one project may give the opportunity of more profit later.
The experience gained may allow new products to be developed. Cost estimate uncertainty If an organisation is unsure of its cost estimate, it may increase its price by some contingency over and above its normal profit.
Contractual terms A customer may be willing to allow the developer to retain ownership of the source code and reuse it in other projects. The price charged may then be less than if the software source code is handed over to the customer. Requirements volatility If the requirements are likely to change, an organisation may lower its price to win a contract.
After the contract is awarded, high prices may be charged for changes to the requirements. Financial health Developers in financial difficulty may lower their price to gain a contract. It is better to make a small profit or break even than to go out of business.
This may be lines of delivered source code, object code instructions, etc. They depend on the estimator. Engineers whoalready understand a domain are likely to be the most productive. Process quality The development process used can have a significant effect on productivity. This is covered in Chapter Project size The larger a project, the more time required for team communications. Less time is available for development so individual productivity is reduced.
Technology support Good support technology such as CASE tools, supportive configuration management systems, etc. Working environment As discussed in Chapter 28, a quiet working environment with private work areas contributes to improved productivity. Process iterates until some consensus is reached. Can be accurate if experts have direct experience of similar systems l Disadvantages: Very inaccurate if there are no experts! ASLOC is the number of lines of reusable code which must be modified, DM is the percentage of design modified, CM is the percentage of the code that is modified , IM is the percentage of the original integration effort required for integrating the reused software.
Very low means no previous experience, Extra high means that the organisation is completely familiar with this application domain. Development Reflects the degree of flexibility in the development flexibility process. Very low means a prescribed process is used; Extra high means that the client only sets general goals.
Very low resolution means little analysis, Extra high means a complete a thorough risk analysis. Team cohesion Reflects how well the development team know each other and work together. Very low means very difficult interactions, Extra high means an integrated and effective team with no communication problems. Process maturity Reflects the process maturity of the organisation.
The computation of this value depends on the CMM Maturity Questionnaire but an estimate can be achieved by subtracting the CMM process maturity level from 5. Use existing hardware, development system and development team B. Processor and C. Memory D. More memory upgrade upgrade only experienced staff Hardware cost increase Hardware cost Experience decrease increase E.
New development F. Engineers should understand the rationale underlying a standard l Review standards and their usage regularly. Standards can quickly become outdated and this reduces their credibility amongst practitioners l Detailed standards should have associated tool support.
The review should be driven by a checklist of possible errors. Progress reviews To provide information for management about the overall progress of the project.
This is both a process and a product review and is concerned with costs, plans and schedules. Quality reviews To carry out a technical analysis of product components or documentation to find faults or mismatches between the specification and the design, code or documentation.
It may also be concerned with broader quality issues such as adherence to standards and other quality attributes. No change to the software or documentation is required.
Designer or programmer should correct an identified fault. The problem identified in the review impacts other parts of the design. Some overall judgement must be made about the most cost-effective way of solving the problem. Fan-out is the number of functions which are called by function X.
A high value for fan-in means that X is tightly coupled to the rest of the design and changes to X will have extensive knock-on effects. A high value for fan-out suggests that the overall complexity of X may be high because of the complexity of the control logic needed to coordinate the called components. Length of code This is a measure of the size of a program. Cyclomatic This is a measure of the control complexity of a program. This complexity control complexity may be related to program understandability.
The computation of cyclomatic complexity is covered in Chapter Length of This is a measure of the average length of distinct identifiers in a identifiers program. The longer the identifiers, the more likely they are to be meaningful and hence the more understandable the program. Depth of This is a measure of the depth of nesting of if-statements in a conditional nesting program.
Deeply nested if statements are hard to understand and are potentially error-prone. Fog index This is a measure of the average length of words and sentences in documents. The higher the value for the Fog index, the more difficult the document may be to understand.
However, it may be appropriate to make a distinction between calls from other methods within the object and calls from external methods. Weighted This is the number of methods included in a class weighted by the methods per complexity of each method. Therefore, a simple method may have a class complexity of 1 and a large and complex method a much higher value. The larger the value for this metric, the more complex the object class.
Complex objects are more likely to be more difficult to understand. They may not be logically cohesive so cannot be reused effectively as super- classes in an inheritance tree. Number of These are the number of operations in a super-class which are over-ridden overriding in a sub-class.
A high value for this metric indicates that the super-class operations used may not be an appropriate parent for the sub-class. Visibility Do the process activities culminate in clear results so that the progress of the process is externally visible?
Acceptability Is the defined process acceptable to and usable by the engineers responsible for producing the software product? Reliability Is the process designed in such a way that process errors are avoided or trapped before they result in product errors?
Robustness Can the process continue in spite of unexpected problems? Maintainability Can the process evolve to reflect changing organisational requirements or identified process improvements? Rapidity How fast can the process of delivering a system from a given specification be completed?
You should normally represent this graphically. Several different views e. People then may extend and change this. Examples of activities are preparing a set of test edged rectangle with no data to test a module, coding a function or a module, proof- drop shadow reading a document, etc. Generally, an activity is atomic i. It is not decomposed into sub-activities. Process A process is a set of activities which have some coherence represented by a round- and whose objective is generally agreed within an edged rectangle with drop organisation.
Examples of processes are requirements shadow analysis, architectural design, test planning, etc. Deliverable A deliverable is a tangible output of an activity which is represented by a rectangle predicted in a project plan. Role A role is a bounded area of responsibility.
Examples of roles represented by a circle might be configuration manager, test engineer, software with drop shadow designer, etc. One person may have several different roles and a single role may be associated with several different people. Exception An exception is a description of how to modify the process if not shown in examples some anticipated or unanticipated event occurs.
Exceptions here but may be represented are often undefined and it is left to the ingenuity of the as a double edged box project managers and engineers to handle the exception.
Communication An interchange of information between people or between represented by an arrow people and supporting computer systems. Communications Elements of a may be informal or formal. All chapters include my suggestions for further reading. The benefit of a general text like this is that it can be used in several different related courses. At Lancaster, we use the text in an introductory software engineering course, in courses on specification, design and critical systems and in a software management course where it is supplemented with further reading.
With a single text, students are presented with a consistent view of the subject. They also like the extensive coverage because they don't have to buy several different books. It also includes material to supplement an introductory programming text which would normally cover Unit SE1 and all material in the suggested course entitled 'Advanced Software Engineering'.
Supplements The following supplements are available: An instructor's guide including hints on teaching the material in each chapter, class and term project suggestions, and solutions to some of the exercises.
This is available in Postscript or on paper from Addison-Wesley. A set of overhead projector transparencies for each chapter. These are available in Postscript and in Microsoft Powerpoint format. Source code for most of the individual program examples including supplementary code required for compilation.
An introduction to the Ada programming language. Information on course presentation using electronically mediated communication and links to material for that approach to teaching.
If you have any problems, you can contact me by E-mail is comp. Acknowledgements I am indebted to a number of reviewers who provided helpful and constructive criticism of early drafts of this book. Thanks also to Rodney L. Rine of George Mason University. Thanks also to all users of previous editions who have provided me with comments and constructive criticism and to my colleagues in the Cooperative Systems Engineering Group and Lancaster University. Finally, a big thank-you to my wife Anne and daughters, Ali and Jay.
They have provided coffee, encouragement and occasional inspiration during the long hours I spent writing this book. Ian Sommerville August Software Engineering presents a broad perspective on software systems engineering, concentrating on widely-used techniques for developing large-scale software systems.
In seven parts, this best-selling book covers a wide spectrum of software processes from initial requirements elicitation through design and development to system evolution. It supports students taking undergraduate and graduate courses in software engineering and software engineers in industry who need to update their knowledge on new techniques such as requirements engineering, distributed systems architectures and system dependability.
Extensive market research has ensured that this new edition is useful and relevant for both students and practising software engineers. The sixth edition has been restructured and updated, important new topics have been added and obsolete material has been cut. Reuse now focuses on component-based development and patterns; object-oriented design has a process focus and uses the UML; the chapters on requirements have been split to cover the requirements themselves and requirements engineering process; cost estimation has been updated to include the COCOMO 2 model.
Functional design has been incorporated in the new chapter on legacy systems. The book's web site www.
It includes an instructor's manual, overhead transparencies, source code of the program examples and additional material on CASE and formal specification. He has more than 20 years of experience in software engineering education and research. His current areas of interest include computer-based systems engineering, requirements engineering, system dependability and software evolution. Convert currency. Add to Basket.
Springer, Softcover. Book Description Hardcover. Condition: New. Seller Inventory X More information about this seller Contact this seller. Book Description Condition: new.
Book is in NEW condition. Satisfaction Guaranteed! Fast Customer Service!!. Book Description Condition: New. Connect with us to learn more. We're sorry! We don't recognize your username or password. Please try again. The work is protected by local and international copyright laws and is provided solely for the use of instructors in teaching their courses and assessing student learning.
You have successfully signed out and will be required to sign back in should you need to download more resources. Out of print. Software Engineering, 6th Edition. If You're an Educator Additional order info. Overview Features Contents Order Overview.
0コメント