第1页 / 共74页
第2页 / 共74页
第3页 / 共74页
第4页 / 共74页
第5页 / 共74页
第6页 / 共74页
第7页 / 共74页
第8页 / 共74页
软件工程第8版课后题答案（英文）.pdf
1
Software Engineering
8th edition
Solutions to selected exercises
These solutions are made available for instructional purposes only. They may only be distributed to
students and it is a condition of distribution that they are only distributed by accredited instructors
using ‘Software Engineering, 8th edition’ as a textbook.. The solutions may be made available to
students on a password-protected intranet but must not be made available on a publicly-accessible
WWW server.
NOT FOR PUBLIC DISTRIBUTION
2
Solutions to the exercises are organised by chapter and I have provided solutions for 6 or 7 exercises
for each chapter in the book. In some cases, where the material is likely to be unfamiliar or where I
have found students to have particular difficulties, a larger number of solutions are given. Overall, I
have provided solutions for about 60% of the exercises. For exercises concerned with ethical issues,
there are of course, no definitive solutions. For these exercises, I have included issues that might be
addressed.
However, the solutions here are simply indications of what might be expected from students
attempting the exercises. Many of the exercises have been deliberately designed so that they may be
adapted to local situations; therefore they are not specified in a rigid way. Instructors, therefore, may
use these solutions as a guide but many other possible, equally valid, solutions may also be
generated.
There are still a small number of chapters where there are fewer than 6 solutions to exercises. These
additional solutions will be available in the next release of this document in October 2006.
NOT FOR PUBLIC DISTRIBUTION
© Ian Sommerville 2006
3
Introduction
Chapter 1
Solutions provided for Exercises 1.2, 1.3, 1.4, 1.6, 1.7 and 1.8.
1.2
The essential difference is that in generic software product development, the specification is
owned by the product developer. For custom product development, the specification is owned
by the customer. Of course, there may be differences in development processes but this is not
necessarily the case.
For important attributes are maintainability, dependability, performance and usability. Other
attributes that may be significant could be reusability (can it be reused in other applications),
distributability (can it be distributed over a network of processors), portability (can it operate
on multiple platforms) and inter-operability (can it work with a wide range of other software
systems). Decompositions of the 4 key attributes e.g. dependability decomposes to security,
safety, availability, etc. are also possible answers.
A software process is what actually goes on when software is developed. A software process
model is an abstraction and simplification of a process. Process models can be used to help
understand real processes and to identify which aspects of these processes could be supported
by CASE tools.
Method support provided by CASE tools:
1.3
1.4
1.6
Editors for specific graphical notations used
Checking of the 'rules' and guidelines of the method
Advice to tool users on what to do next
Maintenance of a data dictionary - all names used in the system
Automatic generation of skeleton code from the system models
Generation of reports on the design
1.7
Problems and challenges for software engineering
Developing systems for multicultural use
Developing systems that can be adapted quickly to new business needs
Designing systems for outsourced development
Developing systems that are resistant to attack
Developing systems that can be adapted and configured by end-users
Finding ways of testing, validating and maintaining end-user developed systems
There are obviously lots of other problems that could be mentioned here.
Advantages of certification
Certification is a signal to employers of some minimum level of competence.
Certification improves the public image of the profession.
Certification generally means establishing and checking educational standards and is therefore
a mechanism for ensuring course quality.
Certification implies responsibility in the event of disputes.
Certifying body is likely to be accepted at a national and international level as ‘speaking for
the profession’.
Certification may increase the status of software engineers and attract particularly able people
into the profession.
Disadvantages of certification
1.9
•
•
•
•
•
NOT FOR PUBLIC DISTRIBUTION
4
•
•
•
•
Certification tends to lead to protectionism where certified members tend not to protect others
from criticism.
Certification does not guarantee competence merely that a minimum standard was reached at
the time of certification.
Certification is expensive and will increase costs to individuals and organisations.
Certification tends to stultify change. This is a particular problem in an area where technology
developments are very rapid.
These are possible discussion points - any discussion on this will tend to be wide ranging and touch
on other issues such as the nature of professionalism, etc.
NOT FOR PUBLIC DISTRIBUTION
© Ian Sommerville 2006
5
Chapter 2 Computer-based system engineering
Solutions provided for Exercises 2.1, 2,2, 2.3, 2.4, 2.6, 2.7, and 2.8.
2.1
Other systems in the system's environment can have unanticipated effects because they have
relationships with the system over and above whatever formal relationships (e.g. data
exchange) are defined in the system specification. For example, the system may share an
electrical power supply and air conditioning unit, they may be located in the same room (so if
there is a fire in one system then the other will be affected) etc.
This is an inherently wicked problem because of the uncertainties associated with the
problem. It is impossible to anticipate exactly when and where a disaster will occur, the
numbers of people involved, the effects on the environment, the technology available to the
emergency services, etc. Planning can only be in very general terms and detailed software
specifications to cope with specific situations are almost impossible to write.
When a car is decommissioned, not all of its parts are worn out. Software systems can be
installed in the car to monitor the different parts and to compute the lifetime which they are
likely to have left. When the car is to be decommissioned, the parts which can potentially be
reused can then easily be discovered.
An overall architectural description should be produced to identify sub-systems making up the
system. Once these have been identified, they may be specified in parallel with other systems
and the interfaces between sub-systems defined.
2.2
2.3
2.4
2.6
2.7
The key features of the solution are:
Database with different types of data
•
Video control system
•
Operator console system
•
•
River data collection
• Weather system links
•
See Figure 2.1.
Possible issues covered in the solution might be:
Communication control system
• Museums are conservative places and some staff may resent the introduction of new
technology.
• Existing museum staff may be asked to deal with problems of the equipment not working
and may not wish to appear unable to deal with this.
• Other areas of the museum may oppose the system because they see it as diverting
resources from their work.
• Different museums may have different preferred suppliers for the equipment so that all
equipment used is not identical thus causing support problems.
• The new displays take up a lot of space and this displaces other displays. The maintainers
of these displays may oppose the introduction of the system.
• Some museums may have no mechanism for providing technical support for the system.
NOT FOR PUBLIC DISTRIBUTION
6
Met office.
Weather info
system
River
sensors
Other services
Sensor data
collection
Comms
controller
Video
cameras
Camera control
system
Weather
data
Site data
Contacts
data
Tide
tables
River
data
Resources
data
Operator display
manager
Video
switcher
System
database
Operator
communications
(phone, radio, etc)
Operator
displays
Video
monitors
Figure 2.1 Block diagram of the flood control system
2.8
Legacy systems may be critical for the successful operation of a business for two basic reasons
• They may be an intrinsic part of one or more processes which are fundamental to the
operation of a business. For example, a university has a student admissions process and
systems which support this are critical. They must be maintained.
• They may incorporate organisational and business knowledge which is simply not
documented elsewhere. For example, exceptions on student admissions may simply have been
coded directly into the system with no paper record of these. Without this system, the
organisation loses valuable knowledge.
NOT FOR PUBLIC DISTRIBUTION
© Ian Sommerville 2006
7
Chapter 3 Critical systems
Solutions provided for Exercises 3.2, 3.5, 3.6, 3.7, 3.8, 3.10 and 3.11.
3.2
3.5
3.6
3.7
3.8
3.10
Six reasons why dependability is important are:
a) Users may not use the system if they don't trust it.
b) System failure may lead to a loss of business.
c) An undependable system may lose or damage valuable data.
d) An undependable system may damage its external environment.
d) The reputation of the company who produced the system may be damaged hence affecting
other systems.
e) The system may be in breach of laws on consumer protection and the fitness of goods for
purpose.
Internet server: Availability as failure of availability affects a large number of people,
reputation of the supplier and hence its current and future income.
A computer-controlled scalpel: Safety as safety-related failures can cause harm to the patient.
A directional control system: Reliability as mission failure could result from failure of the
system to perform to specification.
An personal finance management system: Security because of potential losses to users.
Possible domestic appliances that may include safety-critical software include:
Microwave oven
Power tools such as a drill or electric saw
Lawnmower
Central heating furnace
Garbage disposal unit
Food processor or blender
Ensuring system reliability does not necessarily lead to system safety as reliability is
concerned with meeting the system specification (the system 'shall') whereas safety is
concerned with excluding the possibility of dangerous behavior (the system 'shall not'). If the
specification does not explicitly exclude dangerous behavior then a system can be reliable but
unsafe.
Possible hazard is delivery of too much radiation to a patient. This can arise because of a
system failure where a dose greater than the specified dose is delivered or an operator failure
where the dose to be delivered is wrongly input.
Possible software features to guard against system failure are the delivery of radiation in
increments with a operator display showing the dose delivered and the requirement that the
operator confirm the delivery of the next increment. To reduce the probability of operator
error, there could be a feature that requires confirmation of the dose to be delivered and that
compares this to previous doses delivered to that patient. Alternatively, two different
operators could be required to independently input the dose before the machine could operate.
An attack is an exploitation of a system vulnerability. A threat is a circumstance that has
the potential to cause loss or harm. An attack can lead to a threat if the exploitation of the
vulnerability leads to a threat. However, some attacks can be successful but do not lead to
threats as other system features protect the system.
NOT FOR PUBLIC DISTRIBUTION
8
3.11
The ethics of delivery of a faulty system are complex. We know that this happens all the
time, especially with software. Issues that might be discussed include the probability of the
fault occurring and the consequences of the fault – if the fault has potentially serious
consequences then the decision may be different than if it is a minor, easily recoverable fault.
Other issues are the price charged for the system (if its low, then what level of quality is it
reasonable for the customer to expect). The recovery mechanisms built into the system and the
compensation mechanisms that are in place if consequential damage occurs. Making the
customer aware of the fault is the honest decision to make but may be unwise from a business
perspective.
Claims about the reliability of the software should not be made in such circumstances as the
software provider does not know how the software will be used and so cannot estimate the
probability of occurrence of the fault.
NOT FOR PUBLIC DISTRIBUTION
© Ian Sommerville 2006
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
