Solution notes: Maintenance becomes difficult, because the only way to understand the product as a whole is to read the source code of the entire product. Also, the sole documentation on an individual module is the source code of that module. In addition, lack of documentation means that the chance of a regression fault increases.
Answers to Study Questions -- Chapters 1 and 3
1.
What are the four important attributes which all software products should have ? Suggest four other attributes of software that you think are important for software engineering. Solution notes: 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.
6.
7. 2.
Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model which might be used as a basis for managing the development of the following systems: o a system to control Anti-lock braking in a car; o a virtual reality system to support software maintenance; o a university accounting system o an interactive railway timetable System
Solution notes: Because time lines for the development of modern software are getting shorter and shorter, customers are becoming more diverse (making the understanding of requirements even harder), and changes to requirements are becoming even more common (before delivery), we need a way to provide incremental or evolutionary delivery. The evolutionary process accommodates uncertainty better than most process models, allows the delivery of partial solutions in an orderly and planned manner, and most importantly, reflects what really happens when complex systems are built.
Solution notes:
o
3.
Anti-lock braking system: Safety-critical system so method based on formal transformations with proofs of equivalence between each stage. o Virtual reality system: System whose requirements cannot be predicted in advance so exploratory programming model is appropriate. o University accounting system: System whose requirements should be stable because of existing system therefore waterfall model is appropriate. o Interactive timetable: System with a complex user interface but which must be stable and reliable. Should be based on throwaway prototyping to find requirements then either incremental development or waterfall model. Explain how both the waterfall model and prototyping model of the software process can be accommodated in the spiral model. Solution notes: The waterfall model is accommodated where there is a low specification risk and no need for prototyping etc. for risk resolution. The activities in the 2nd quadrant of the spiral model are skipped. The prototyping model is accommodated when the specification phase is limited and the prototyping (risk resolution) phase predominates. The activities in the 3rd quadrant of the spiral model are skipped or reduced in scope.
4.
Explain why a software system that is used in a real-world environment must change or become progressively less useful. Solution notes: Systems must change because as they are installed in an environment the environment adapts to them and this adaptation naturally generates new/different system requirements. Furthermore, the system's environment is dynamic and constantly generates new requirements as a consequence of changes to the business, business goals and business policies. Unless the system is adapted to reflect these requirements, its facilities will become out-of-step with the facilities needed to support the business and, hence, it will become less useful.
Explain what is wrong with the notion that software engineering is too time consuming and interferes with a programmer's productivity. Solution notes: Producing a lot of code quickly is not the object of software development. The software needs to perform correctly or it will need to be rewritten. Most software products must be maintained for many years after they are developed, the time spent documenting a program and planning for changes is easily justified over the product's lifetime. Studies have shown the later a change is introduced in the development process, the more costly it is to implement. Why are evolutionary models considered by many to be the best approach to software development in a modern context?
Answers to Study Questions -- Chapters 5 and 6
1.
Explain why it is desirable to draw a distinction between a requirements definition and a requirements specification. Solution notes: The requirements definition describes the software from the end-user's view whereas the requirements specification has details of interest to technical people. Since there are these different constituencies who may read the requirements we want to accommodate both groups. By providing a relatively high-level conceptual description we can allow endusers or client management to find out what will be provided. When it comes to specifying lower-level details we want to be much more precise to cater to the technical people on both sides.
2.
Discuss ambiguities or omissions in the following statement of requirements for part of a ticket issuing system. An automated ticket issuing system sells rail tickets. Users select their destinations, and input a credit card and a PIN. The rail ticket is issued and their credit card account charged with its cost. When the user presses the start button, a menu display of potential destinations is activated along with a message to the user to select a destination. Once a destination has been selected, users are requested to input their credit card. Its validity is checked and the user is requested to input a PIN. When the credit transaction has been validated, the ticket is issued. Solution notes: Ambiguities and omissions include:
o o o o
5.
Due to a fire accident, all documentation for a product is destroyed just before it is delivered. What is the impact of the resulting lack of documentation ?
o
Can a customer buy several tickets for the same destination together or must they be bought one at a time? Can customers cancel a request if a mistake has been made? How should the system respond if an invalid card or PIN number is input? What happens if customers try to put their card in before selecting a destination (as they would in ATM machines)? Must the user press the start button again if they wish to buy another ticket to a different destination?
13. If the amount breaches either of these limits, then a message is issued which tells the customer of the maximum amount allowed and the transaction is cancelled. 14. If the amount is within limits, the requested cash should be dispensed 15. The customer’s account balance and daily card limit should be reduced by the amount of cash dispensed.
o
3.
Should the system only sell tickets between the station where the machine is situated and direct connections or should it include all possible destinations? Using the technique suggested here where natural language is presented in a standard way, write plausible user requirements for the following functions: o A unattended petrol pump system that includes a credit card reader. The customer swipes the card through the reader, then specifies the amount of fuel required. The fuel is delivered and the customer's account debited. o The cash dispensing function in a bank ATM. o The spell checking and correcting function in a word processor.
Specification: ATM/Customer functionality/FS. Section 2.1 7.2 Spell checking 7.2.1 The system shall provide a user-activated facility which checks the spelling of words in the document against spellings in the system dictionary and user supplied dictionaries.
Solution notes: 1 . Fuel delivery system
7.2.2 When a word is found in the document which is not in any dictionary, a user query should be issued with the following options:
1.1 The system should provide an unattended fuel delivery service where a specified amount of fuel is delivered to customers, The cost is deducted from the customer’s credit card account.
16. 17. 18. 19. 20.
1.2 The sequence of actions to dispense fuel should be: 4. 5. 6.
The customer selects the type of fuel to be delivered. The customer inputs either a cash limit or a maximum amount of fuel to be delivered The customer validates the transaction by providing credit card account details.
7.2.3 When a word is discovered which is not in the dictionary, the system should propose 10 alternative words based on a match between the word found and those in the dictionaries.
Rationale: The amount of fuel allowed depends on the credit limit but customers may wish to ‘fill up’ rather than have a specified amount of fuel. By specifying a maximum, the system can check if credit is available. Note that the definition does not set out how credit card details should be provided.
Specification: NewWP/Tools/FS. Section 7.2
4. 7. 8.
The pump is activated and fuel is delivered, under customer control. The transaction is terminated either when the pump nozzle is returned to its holster for 15 seconds or when the customers fuel or cash limit is reached. Rationale: Termination should not be immediate when the nozzle is returned as the customer may wish to restart the transaction e.g. to fill a fuel can as well as the car fuel tank. If a pump display is available, it may be appropriate to issue a ‘Please wait for your receipt’ message.
9. A receipt is printed for the customer. 10. The fuel stock is updated. Specification: PUMP_SYS/FS. Section 1
2 . Dispensing cash 2.1 The system must provide a facility which allows a specified amount to cash to be issued to customers. The amount is requested by the customer but the system may reduce this amount if the customer’s daily limit or overdraft limit is reached. 2.1.1 The sequence of actions to dispense cash should be: 11. The customer inputs the amount of cash required 12. The system checks this against daily card limits and the customer’s overdraft limit.
Ignore this instance of the word Ignore all instances of the word Replace the word with a suggested word from the dictionary Replace the word with user-supplied text Ignore this instance and add the word to a specified dictionary
Describe three different types of non-functional requirements that may be placed on a system. Give examples of each of these types of requirements. Solution notes: There are many possibilities here. Some suggestions are given below
Description
Non-functional
o Reviews should be held and documented as defined in process
Examples
standard 123.
o Goto statements should not be used in any programs. o The time taken by users with no previous system experience to
Requirement
Performance
Implementation
Performance requirements set out limits to the performance expected of the system. These may be expressed in different ways depending on the type of system e.g. number of transactions processed per second, response time to user requests, etc.
The system must process at least 150transactions per second.
Defines specific standards or methods which must be used in the development process for the system.
The system design must be developed using an object-oriented approach based on the UML process.
learn to use 75% of the system facilities should be less than 2 hours. (How do you measure this one?) 6. Suggest who might be stakeholders in a university records system. Explain why it is almost inevitable that the requirements of different stakeholders will conflict in some ways.
The maximum response time for any user request should be 2 seconds.
Solution notes: The stakeholders in a student records system include:
o University central administration including those responsible for registration, payment of fees, examinations and assessment and graduation. o The students whose details are recorded in the system. o University departmental administrators who supply information to the system and use information from it. o Academic staff who use information from the system. o Data protection officers (local and national). o Potential employers of students (who may require information from the system). 7. A software system is to be developed to automate a library catalogue. This system will contain information about all the books in a library and will be usable by library staff and book borrowers and readers. The system should support catalogue browsing, querying, and should provide facilities allowing users to send messages to library staff reserving a book which is loan. Identify the principal viewpoints which might be taken into account in the specification of this system and show their relationships using a viewpoint hierarchy diagram.
The system must be implemented in C++,Version 3.0. Usability
Defines requirements which relate to the usability of the system by end-users.
All operations which are potentially destructive must include an undo facility which allows users to reverse their action. (This is an example of a functional requirement which is associated with a nonfunctional requirement)
Solution notes: The viewpoints are given below. Note that system management (i.e. those responsible for installing and maintaining the computer system are a viewpoint as well as library staff and library users. Library users have been separately identified as browsers and searchers as these operations typically require different types of services.
All operations which are potentially destructive must be highlighted in red in the system user interface. Safety
5.
Safety requirements are concerned with the overall safe operation of the system.
Rewrite the following requirements so that they may be objectively validated. You may make any reasonable assumptions about the requirements. o The software system should provide acceptable performance under maximum load conditions. o The system interface should use a character set as available on the standard terminal. o If the system should fail in operation, there should be a minimal loss of data. o The software development process used should ensure that all of the required reviews have been carried out. o Structured programming should be used for program development. o The software must be developed in such a way that it can be used by inexperienced users. Solution notes: Some possible rewrites are:
o o o
All Viewpoints | | ----------------------------------------------------------| | | | | | System Library Library Management staff users | | | | -------------------------------------------------| | | | | | | | | | | | Library Cataloging Database Library Browsers Searchers Management Staff Administrator Assistants
The system must be certified according to Health and Safety Regulations XYZ 123.
The response of the software system should always be less than 2 seconds to any user request. The system interface should be based on the ASCII character set and should not include non-ASCII characters. If the system fails, only the date being processed by transactions current at the time of failure may be lost.
8.
For three of the viewpoints identified in the library cataloguing system, suggest services which might be provided to that viewpoint, data which the viewpoint might provide and events which control the delivery of these services. Solution notes: Possible viewpoints are: Viewpoint: Cataloging staff Services:Add book to catalogue Delete book from catalogue Amend classification details Find catalogue entry Check entry Data provided: Book details such as ISBN, title, date of publication, author, etc. Events: Delivery of copy of new book order Delivery of new book
Delivery of classification error form Delivery of request to delete book from stock Viewpoint: Browsers Services:Show classification structure Show library organisation Select item for browsing Show related items Display book details Data provided: Classification code Book title and author Events: None (not an event driven activity) 9.
For the services identified in the above question, identify what might be the most important nonfunctional constraints.
3.
Solution notes: Important non-functional attributes for the cataloging services might be:
o o o
Draw state machine model for a CD-player. Solution notes:
Availability (because the system may be required at any time) Security (because the books data base musn’t be corrupted) Efficiency (because the system must respond quickly to each transaction)
For the browsing services, usability is also very important as these services should be easy to use without extensive training.
Answers to Study Questions -- Chapters 7 and 8
1.
Draw a context model for a patient information system in a hospital. You may make any reasonable assumptions about the other hospital systems which are available but your model must include a patient admissions system and an image storage system for X-rays. Solution notes: There are obviously many different possibilities here depending on exactly what systems are included. One possible model is shown below
4.
Draw state machine model for an answering machine Solution notes:
2.
Based on your experience with a bank ATM, draw a data-flow diagram modelling the data processing involved when a customer withdraws cash from the machine. Solution notes: One possible model of the data processing is shown below. There are other alternatives depending on the details of the system. Note that this DFD has to include some control data as this is an event-driven system.
5.
Develop an object model including a class hierarchy diagram and an aggregation diagram showing the principal components of a PC and its system software. Solution notes: There are many possible organizations for the class hierarchy. I show a simple one below with only two levels. A three-level
hierarchy would also be OK but more than that would be too much. The aggregation diagram shows the part-of relationships between objects. This is shown in Figure 7.4. Obviously, further decomposition of the lowest level is possible.
} class ArticleStock { ... void reserve(Article article, int number) { ... } ... } class Order { ... OrderPosition giveOrderPos() { ... } ... }
6.
Consider the following Java code and draw a sequence diagram to show the execution scenario of reserve(o) in ArticleReservation class.
class OrderPosition
class ArticleReservation
{
{
...
ArticleStock as;
Article giveArticle()
void reserve(Order order)
{
{
...
OrderPosition opos = order.giveOrderPos();
}
Article art = opos.giveArticle();
int giveNumber()
int num = opos.giveNumber();
{
as.reserve(art,num)
...
}
}
...
...
}
o
Solution notes: 7.
8.
9.
Develop using C and X-windows
Explain why, for large systems development, it is recommended that prototypes should be "throw-away" prototypes. Solution notes: Large systems are usually developed by different teams and these require a common reference framework (the system requirements) for developing the system. Throwaway prototypes can be used to help develop and validate these requirements to increase confidence that these are appropriate. However, if an evolutionary approach to development is used then it is difficult to partition increments across the different teams that are involved in the system. Furthermore, large systems usually have a long lifetime and the problem with evolutionary prototyping is that it often leads to a system structure that is corrupted by change and is consequently hard to maintain. Under what circumstances would you recommend that prototyping should be used as a means of validating system requirements ?
Costs more.
o o o
Fewer problems with training. Known management strategy. Requirements likely to be wrong so needs post-delivery modification.
Evolutionary prototyping
o o o o o o
Fast feedback from users. Rapid system delivery. Readily adapted to evolving requirements. Hard to manage. Lack of standards for portability etc. Likely to be unstructured causing future maintenance problems. 11. You have developed a throw-away prototype system for a client who is very happy with it.
Solution notes: When a system that is new or unfamiliar to the organisation is being developed. In those circumstances, requirements stakeholders do not know what they require and appreciate the guidance they can get from a prototype system.
However, she suggests that there is no need to develop another system but that you should deliver the prototype and offers an excellent price for the system. You know that there may be future problems with maintaining the system. Discuss how you might respond to this customer.
Suggest difficulties that might arise when prototyping real-time embedded computer systems.
Solution notes: The problem which you are likely to face here is that customers have immediate requirements for a system and may be willing to accept long-term costs in return for short-term advantage. In the long-tern, the prototype is likely to be much more expensive to maintain (and will probably have to be scrapped after a relatively short time) and may not be reliable as a properly-engineered system. Customers, of course, should always be able to have what they are willing to pay for and, if there is no financial loss to the developer, there are no problems in delivering the prototype. However, as a professional it is important that you make clear the problems which the customer is likely to face with the system and emphasise that the system was intended as a demonstrator rather than a finished system. If possible, you should try to quantify the maintenance costs which are likely to be involved and warn the customer of the short lifetime of the system. You may wish to draw up some written agreement where you make clear that you do not take responsibility for system problems.
Solution notes: Problems in prototyping real-time systems resolve around the fact that such systems must often interact with hardware (which may be unavailable), have timing requirements which cannot be replicated in a prototyping language and have very high reliability requirements. The process structure may also have to be prototyped and this may be impossible if the prototyping language does not include concurrent programming facilities. These problems can be partially addressed by also prototyping the hardware using a simulator, and by using a model of time which corresponds to real-time but which is many times slower. Prototyping reliability requirements is very difficult. 10. A software manager is involved in a project development of a software design support system which is is intended to assist with the translation of sofware requirements to a formal software specification. The system must run on a personal computer but may be developed on another system and ported to that machine. Three possible development strategies are: o Develop a throw-away prototype using a prototyping language such as Smalltalk. Evaluate this prototype then review requirements. Develop the final system using C and X-windows. o Develop the system from the existing requirements using C and X-windows then modify it to adapt to any changed user requirements. o Develop the system using evolutionary prototyping with a prototyping language such as Smalltalk. Modify the system accorind to the user's requests and deliver the modified prototype. Comment on the advantages and disadvantages of each of these development strategies. Solution notes: Throw-away prototyping
o o o
Fast development and rapid feedback from users. Likely to result in reasonable requirements. Needs multiple development languages.
Answers to Study Questions -- Chapters 4 and 22
1.
Explain why the best programmers do not always make the best software managers. You may find it helpful to base your answer on the list of management activities given in Sommerville's section 4.1. Solution notes: Management activities such as proposal writing, project planning and personnel selection require a set of skills including presentation and communication skills, organisational skills and the ability to communicate with other project team members. Programming skills are distinct from these (indeed, it is a common criticism of programmers that they lack human communication skills) so it does not follow that good programmers can re-orient their abilities to be good managers.
2.
Explain why the process of project planning is an iterative one and why a plan must be continually reviewed during a software project. Solution notes: Project planning can only be based on available information. At the beginning of a project, there are many uncertainties in the available information and some information about the project and the product may not be available. As the project develops, more and more information becomes available and uncertainties are resolved. The project plan therefore must be reviewed and updated regularly to reflect this changing information environment.
3.
The table below sets out a number of activities, durations and dependencies. Draw and activity chart and a bar chart showing the project schedule.
Task
Duration (days)
Dependencies
T1
10
T2
15
T1
T3
10
T1, T2
T4
20
T5
10
T6
15
T3, T4
T7
20
T3
T8
35
T7
T9
15
T6
T10
5
T5, T9
T11
10
T9
T12
20
T10
T13
35
T3, T4
T14
10
T8, T9
o
T15
20
T12, T14
o o
T16
10
T15
Task bar chart
4.
In addition to the risks shown in Figure 4.12, identify six other possible risks which are likely to arise in software projects. Solution notes: Other possible risks are:
o o
Solution notes:
o
5.
Activity Chart
Technology: Communications network saturates before expected transaction limit is reached. People: Level of skill of available people is lower than expected. Organisational: Organisational changes mean that the project schedule is accelerated. Tools: CASE tools cannot handle the volume of data available for large systems. Requirements: New non-functional requirements are introduced that require changes to the system arhcitecture. Estimation: The difficult of the software is underestimated.
You are asked by your manager to deliver software to a schedule which you know can only be met by asking your project team to work unpaid overtime. All team members have young children. Discuss whether you should accept this demand from your manager or whether you should persuade your team to give their time to the organisation rather than their families. What factors might be significant in your decision? Solution notes: Issues which might be covered include the problems of finding a balance between family life and organisational demands, whether or organisations should expect people to behave as professionals. This perhaps implies working the number of hours required to complete some job but also implies that engineers should have a degree of autonomy about how they arrange their working lives (e.g. they may choose to work from home or their own working hours). Factors which affect this decision might be the financial state of the company, the general company culture and attitude, the availability of alternative local employment, particular personal circumstances (e.g. are people single parents, do they have babies which don’t sleep well, etc.)
o 6.
o
As a training manager, you are responsible for the initial programming language training of a new graduate intake to your company whose business is the development of defence aerospace systems. The principal programming language used is Ada, which was designed for defence systems programming. The trainees may be computer science graduates, engineers or physical scientists. Some but not all of the trainees have previous programming experience; none have previous experience in Ada. Explain how you would structure the programming training for this group of graduates. Solution notes: Divide group into two namely those with previous experience of an imperative programming language and those without. Teach the experienced group CHILL syntax by reference to known concepts such as assignments etc. teach the other group concepts before confusing them with syntax.
Wide selection of staff available. team members with about the same experience can be found. Critical problem so a democratic team brings a wide variety of expertise to it.
Chief programmer team should be rejected because it is too high risk. Although productivity can be as high or higher than with democratic team, the fact that a rival company is actively recruiting means that the loss of the CP or his/her deputy could critically damage the project.
9.
From a management point of view, discuss possible pros and cons of having a technical wizard in your development team. Solution notes: A major advantage of having a true wizard in the team is that he may boost team productivity. Other team members may profit from his knowledge and increase their own knowledge and skills. Potential disadvantages (which should be counteracted by proper management attention!) are:
Reason is because of knowledge organisation which separates syntactic and semantic knowledge. If you try and teach semantic knowledge when its already known it is boring. If you try and teach both at one, it is confusing.
o
7.
Explain why keeping all members of a group informed about progress and technical decisions in a project can improve group cohesiveness. Solution notes: In a cohesive group, all members have the same fundamental objective and, generally, recognise that this takes priority over other individual objectives. When there is good information exchange and a culture where problems and difficulties are shared, individuals are much more likely to be able to keep this common objective in sight and to work together to solve the problems. If information is hidden, there is a tendency for people to think that those hiding the information are doing so because of personal objectives and so they are seen as not being a subscriber to the overall group objective. This is a particular problem when the person hiding the information is the group leader - if the group leader does not promote a culture of openness, an atmosphere of suspicion is likely to arise.
Technical issues may get too much emphasis. The team may easily loose itself in beautiful technical solutions to problems that are hardly relevant to the users. o A less disciplined mode of operation may result. Proper procedures regarding documentation and configuration control may be discarded, since the team guru has all the necessary knowledge in his head. o The project may get into serious trouble if this person leaves the team. This holds especially if the previous point is not adequately dealt with. 10. Discuss the pros and cons of letting people rotate between projects from different application domains as opposed to letting them true experts in one particular application domain. Solution notes: Advantages of letting people rotate between projects from different application domains are:
o o
Of course, this doesn’t mean that everyone has to know everything. Information hiding is important. However, if people know that the information is there if they need to know it, then they will not be suspicious.
8.
You are a programming manager who has been given the task of rescuing a project that is critical to the success of the company. Senior management have given you an open-ended budget and you may choose a project team of up to five people from any other projects going on in the company. However, a rival company, working in the same area, is actively recruiting staff and several staff working for you company have left to join them.
o
The major advantage of letting people become true experts in a given application domain is their increased expertise within that domain. The productivity and quality of their work increases as their knowledge of that domain grows. Answers to Study Questions -- Chapters 9 and 10
1. Describe two models of programming team organisation that might be used in this situation and make a choice of one of these models. Give reasons for your choice and explain why you have rejected the alternative model. Solution notes: Possible team models are democratic team and chief programmer team. In a democratic team, all members participate in decision make and share out the work by consensus. In a chief programmer team, the chief programmer is very highly skilled along with a deputy and an administrator. Specialist help is drafted in as required. Chief programmer makes all the decisions. CP and deputy do most of the design work with the remainder of the team doing routine tasks. In this case, the best option is the democratic team because:
Their "stock" of useful knowledge chunks increases. They are more easily led to properly document things, since their work has to be handed over to other people. They become less easily dissatis_ed with their position, since they are regularly confronted with new challenges.
Suggest why the architectural design of system should precede the development of a formal specification. Solution notes: The architectural design is a means of structuring the system into (relatively) autonomous parts which can be separately specified using formal or other techniques. This serves to structure the specification as well as the system. Of course, the specification could be structured in some other way but then there is a problem of mapping the specification to the system structure.
2.
You have been given the task of 'selling' formal specification techniques to a software development organization. Outline how you would go about explaining the advantages of formal specifications to sceptical, practicing software engineers. Solution notes: To explain the advantages of formal specification to practicing engineers, it is important to focus on what it brings to the
Is_empty (New) = True Is_empty (Push (S, V)) = False
practice of software development rather than on more abstract advantages such as the ability to mathematically analyze the specification. Advantages that might be stressed are: 5. 1.
3.
The detailed analysis of the requirements that is necessary to produce a formal specification. This results in the discovery and resolution of ambiguities and errors at an early stage in the process. 2. The unambiguous specification of interfaces. Interface problems are one of the major problems in system integration and a reduction in such problems can significantly reduce software costs. 3. The ability to mix formal and informal specifications. The whole system need not be formally specified but only those parts where most benefit can be gained. Using the axioms given in the algebraic specification of sort List (Sommerville Figure 9.7, p.199) determine the meaning of the following expressions. Make sure at each stage you say which axiom you are using (number the axioms from 1 to 6 in the order given). o Tail ([42, 99]) o Head (Tail (Cons ([1, 2], 3))) o Length (Tail (Cons ([1], Head (Cons ([2], 3)))))
An abstract data type representing a Symbol_table has the following operations: o New: bring a symbol table into existence. o Enter: enter a symbol and its type into the table. o Lookup: return the type associated with a name in the table. o Delete: remove a name-type pair from the table, given a name as input. o Replace: replace the type associated with a given name by the type specified as a parameter. Define this abstract data type using an algebraic specification. The Enter operation fails if the name is already in the table. The Lookup, Delete, Replace operations fail if the name is not in the table. Solution notes: SYMBOL_TABLE (Name, Type) sort Symbol_Table imports NAME, TYPE
Solution notes: [x,y] == Cons (Cons (Create, x), y) This specification defines a sort Symbol_table as might be used in a compiler. It requires the specification of sorts Name and Type which are assumed to be defined in the specifications NAME and TYPE. Assume the sort TYPE has an associated Undefined value.
o
4.
Tail ([42, 99]) = Tail (Cons (Cons (Create, 42), 99)) (defn of []) = Cons (Tail (Cons (Create, 42), 99)) (axiom 6) = Cons (Create, 99) (axiom 6) = [99] (defn of []) o Head (Tail (Cons ([1, 2], 3))) = Head (Tail (Cons (Cons (Cons (Create, 1), 2), 3))) (defn of []) = Head (Cons (Tail (Cons (Cons (Create, 1), 2)), 3)) (axiom 6) = Head (Cons (Cons (Tail (Cons (Create, 1)), 2), 3)) (axiom 6) = Head (Cons (Cons (Create, 2), 3)) (axiom 6) = Head (Cons (Create, 2)) (axiom 2) = 2 (axiom 2) An abstract data type representing a stack has the following operations: o New: bring a stack into existence. o Push: add an element to the stack. o Top: evaluate the top element of the stack. o Retract: remove the top element of the stack and return the modified stack. o Is_empty: returns true if there are no elements in the stack.
The Create operation brings a symbol table into existence, the Enter operation puts a symbol into the table, the Lookup operation discovers the type associated with a name, the Delete operation removes a name, type pair from the table and the Replace operation replaces the type associated with a name. Create -> Symbol_table Enter (Symbol_table, Name, Type) -> Symbol_table Lookup (Symbol_table, Name) -> Type Delete (Symbol_table, Name) -> Symbol_table Replace (Symbol_table, Name, Type) -> Symbol_table Lookup (Create, N) = Undefined Delete (Create, N) = Create Replace (Create, N, T) = Create Lookup (Enter (S, N_1, T), N_2) = if N_1 == N_2 then T else Lookup (S, N_1) Delete (Enter (S, N_1, T), N_2) = if N_1 == N_2 then S else Enter (Delete (S, N_2), N_1, T) Replace (Enter (S, N_1, T_1), N_2, T2) = if N_1 == N_2 then Enter (S, N_2, T2) else Enter (Replace (S, N_2, T2), N_1, T_1))
Define this abstract data type using an algebraic specification. Solution notes: STACK (Elem) sort Stack imports BOOLEAN 6. This specification defines a sort called Stack which specifies an abstract data type. The operations on the stack allow a stack to be created (New), an element to be pushed onto the stack (Push), the Top of the stack to be evaluated (Top), the top of the stack to be removed (Retract) and the stack to be tested to see if it is empty. New -> Stack Push (Stack, Elem) -> Stack Top (Stack) -> Elem Retract (Stack) -> Stack Is_empty (Stack) -> Boolean Top (New) = Undefined Top (Push (S, V)) = V Retract (New) = New Retract (Push (S, V)) = S
ATMs rely on using information on the user's card giving the bank identifier, the account number and the users PIN. They also derive account information from a central database and update that database on completion of a transaction. Using your knowledge of ATM operation, write Z schemas defining the state of the system, card validation and cash withdrawal. Solution notes: The Z schemas are shown below. There are many different possibilities here depending on how much information is maintained. This is one of the simplest which assumes that customers may not withdraw money if there is an insufficient cleared balance in their account (a cleared balance is where all cheques paid in to the account have been cleared for payment). +----BankAccount-----------------------------------| | CustomerNumber: N | AccountNumber: N
| DateOpened: Date | DateClosed: Date | CustomerPIN: N | Balance: Money | ClearedBalance:Money | AvailabletoWithdraw: Money +--------------------------------------------------| DateOpened < DateClosed | ClearedBalance >= Balance | AvailabletoWithdraw <= ClearedBalance +---------------------------------------------------
+----Validate--------------------------------------| __ | \/ BankAccount | Account? N | PIN?: N | TransactionOK!: boolean +--------------------------------------------------| Account? = AccountNumber | PIN? = CustomerPIN | TransactionOK! +---------------------------------------------------
+----Withdraw--------------------------------------| __ | \/ BankAccount | Amount?: Money +--------------------------------------------------| Amount? <= ClearedBalance | Amount? <= AvailabletoWithdraw | Balance' = Balance - Amount? +--------------------------------------------------7.
9.
Solution notes: Here are some suggestions.
o
Ticket issuing system: Should have a centralized database with sub-systems to handle communications, route information and price information. Also sub-systems for statistical processing. Each ticket machine should be connected to this. o Video conferencing system: Should include a network with a range of clients/servers on it. These should include a floor controller, video server, display clients, etc. o Robot floor cleaner: Should include a centralized repository with sensors adding information to it, decision systems taking information from it and actuators using sensor information to move the machine. 10. Giving reasons for your answer, suggest an appropriate control model for the following systems: o a batch processing system which takes information about hours worked and pay-rates and prints salary slips and bank credit information; o a set of software tools which are produced by different vendors but which must work together; o a television controller which responds to signal from a remote control unit. Solution notes: The most appropriate control models for the systems suggested are:
o
Explain why it may be necessary to design the system architecture before the specifications are written.
o
Solution notes: The architecture may have to be designed before specifications are written to provide a means of structuring the specification and developing different sub-system specifications concurrently, to allow manufacture of hardware by sub-contractors and to provide a model for system costing. 8.
Giving reasons for your answer, suggest an appropriate structural model for the following systems: o an automatic ticket issuing system used by passengers at a railway station; o a computer controlled video conferencing system which allows audio, video and computer data to be visible to several participants at the same time; o a robot floor cleaner which is intended to clean relatively clear spaces such as corridors. The cleaner must be able to sense walls and other obstructions. Solution notes:
o
o o
Ticket issuing system: The most appropriate architectural model is a centralized model with a shared repository of route and pricing information. This means that changes are immediately available to all machines. As little local processing is necessary, there is no real advantage in a client-server architecture. The centralized system also allows global information and route use to be collected and processed. Video conferencing system: The most appropriate is a clientserver model. The reason for this is the need for a lot of local processing to handle multimedia data. Robot floor cleaner: The most appropriate model is a repository model where all subsystems place information in the repository for other sub-systems to use. In the case of AI systems as this
would be, a special kind of repository called a blackboard is normally used. Design an architecture for the above systems based on your choice of model. Make reasonable assumptions about the system requirements.
o
Salary system: Call return model of control. Each operation involves identifying particular options then calling subroutines to retrieve or compute the required information. There are no unexpected events to be processed Software toolset: Broadcast model of control is most appropriate. Tools need not know which other tools are available and this approach allows tools which operate on different types of computers to work together. Television controller: Centralized (polling) control model. This is the most appropriate approach as there is no need for the very rapid response required from interrupt driven systems.
Answers to Study Questions -- Chapters 12 and 14
1.
Explain why adopting an approach to design that is based on loosely coupled objects that hide information about their representation should lead to a design which may be readily modified. Solution notes: There are two major problems encountered when modifying systems. 1. 2.
Understanding which entities in a program are logically part of some greater entity. Ensuring that changes do not have unanticipated side-effects ie. a change to one entity has an undesirable effect on some other entity.
Object-oriented development helps to reduce these problems as it supports the grouping of entities (in object classes) so therefore simplifies program understanding. It also provides protection for entities declared within objects so that access from outside the object is controlled (the entity may not be accessible, its name may be accessible but not its representation or it may be fully accessible). This reduces that probability that chances to one part of the system will have undesirable effects on some other part.
2.
Solution notes: An object class is generic description of a set of entities (or objects) which have common characteristics and which are recognizably the same in some or all respects. Objects are specific instances in the real-world or in a system where values have been assigned to the characteristics defined in the object class. The set of values assigned to the object characteristics may distinguish that object from all other objects but need not do so. In the real-world, we only see objects and construct object classes as abstract entities. In programs, we often only define object classes and construct objects whose lifetime is no longer than the execution time of the program. An example of an object class is a BOOK which has attributes (characteristics) such as AUTHOR, TITLE, PUBLISHER, DATE OF PUBLICATION etc. An example of an object or instance of this object class is the specific book: AUTHOR: M.R.K. Krishna Rao TITLE: Termination Characteristics of Logic Programs EDITION: 1 PUBLISHER: Tata Institute DATE: 1993 If we wished to define a book object which was distinct from all other objects, we would need to add another characteristic to the object class such as OWNER. 3.
Under what circumstances might it be appropriate to develop a design where objects execute concurrently. Solution notes: Concurrent objects may be used in a system that you know will be distributed or in a real-time system where objects are associated with autonomous sensors or actuators. The real-time system should be a 'soft' real-time system normally as it is often difficult to compute deadlines when object-oriented programming is involved because of the unpredictable overhead when methods are called.
4.
| type_of_account | | tape_status | | balance | | tape_type | | transaction_list | | power_source | +--------------------+ +-------------------+ | open | | play | | close | | fast_forward | | give_balance | | rewind | | give_statement | | stop | | debit | | set_tape_type | | credit | | set_power_source | +--------------------+ +-------------------+
Using examples, explain the difference between an object and an object class.
Using the UML notation, design the following object classes identifying their attributes and operations. You may make any reasonable assumptions about these systems. o a telephone; o a printer for a PC; o a personal stereo system; o a bank account o a library catalogue
5.
Identify possible objects (along with their attributes and operations) in the following systems: 0. A group diary and time management system is intended to support timetabling of meetings and appointments across a group of co-workers. When an appointment is to be made which involves a number of people, the system finds a common slot in each of their diaries and arranges the appointment for that time. If no common slots are available, it interacts with the users to rearrange their personal diaries to make room for the appointment. 1. A petrol station is to be set up for fully automated operation. Drivers swipe their credit card through a reader connected to the pump, the card is verified by communicating with a credit company computer and a fuel limit established. The driver may then take the fuel required. When the fuel is delivered and the pump nozzle is returned to its holster, the drivers credit card account is debited with the cost of the fuel taken. The credit card is returned after debiting. If the credit card is invalid, it is returned by the pump before fuel is delivered. Solution notes: Objects in the group diary and time management system
Object
Attributes
Operations
Diary
year weeks_of_year days_of_week time_slots access_permissions
make_appointment cancel_appointment move_appointment make_group_appointment find_free_slot reserve_slots book_slots free_slots display_diary check_slot_status
Appointment
time duration place participants reason
User
diary
Solution notes: +--------------------+ +-------------------+ +---------------------+ | Telephone | | PC_Printer | | Library_Catalogue | +--------------------+ +-------------------+ +---------------------+ | status_on_off_hook | | paper_tray_pos | | publication_records | | number_dialled | | paper_level | | transactions | | phone_number_list | | toner_level | | date_created | | | | error_status | | date_updated | +--------------------+ +-------------------+ +---------------------+ | ring | | print | | search | | dial | | display(message) | | add_record | | re_dial | | self_test | | delete_record | | mute | | on_off | | edit_record | +--------------------+ +-------------------+ +---------------------+ +--------------------+ +-------------------+ | Bank_Account | | Personal Stereo | +--------------------+ +-------------------+ | account_number | | volume |
check_time_slot
Objects in the fuel delivery system
Object
Attributes
Operations
Pump
fuel_dispensed price hose_status trigger_status fuel_type
activate deactivate deliver_fuel stock_update
Card_reader
card_number card_type
read_card check_status
card_status credit_limit
print_receipt
Fuel_tank
current_fuel_level
add_fuel remove_fuel
Communication_system
number_dialled credit_limit
send_card_number return_card_status
System_controller
card_number card_type max_delivery price_table fuel_delivered
Price_table
6.
fuel_prices
8.
Solution notes: An application framework is typically a source code entity whereas a COTS product is often simply a black-box with an external interface. Therefore, it is easier and quicker to establish if the COTS product can be reused and to reuse it. However, the range of situations where this can be reused and the flexibility in its use is obviously less for a COTS product. 9.
Explain why the savings in cost from reusing existing software is not simply proportional to the size of the components that are reused.
10. Why are Patterns an effective form of design reuse ? What are the disadvantages to this approach to reuse ? Solution notes: Patterns are an effective form of design reuse because the reflect accumulated wisdom that has been collected over several applications rather than a single application (By definition, a pattern is something that should appear in more than one application). There are two problems with patterns for reuse. The first is knowing which patterns actually have been documented and then finding these patterns - the time taken to do this can be significant. The second is that patterns are by their nature generalizations so their performance is likely to be limited. If performance is critical, then a special-purpose tailored approach to a problem will almost always be more effective.
As the component size increases, the overhead of finding and understanding the component becomes relatively less so cost savings increase. Furthermore, the larger the component, the cost of changing the system to accommodate it also becomes relatively less so cost savings are greater. Therefore, reuse benefits are not simply proportional to size but increase as the reused component becomes larger.
Using the example of an Inventory management family shown in Figure 14.9, suggest operations that have to be added or changed to support the recording of inventory items when the level falls below some specified number. Solution notes: Inventory management system New operations: Monitor to check the level of an item against a specified level, Order to place an order for a number of new items Modified operations: Delete to call Monitor whenever an item is deleted. Delete should not do the checking as this would not be consistent with the operation.
lookup amend_price
Solution notes: The cost savings from reusing components are the cost savings from not having to write that component. Therefore, the larger the component, the greater the cost saving. However, there are costs of reuse from finding and understanding components to changing other parts of the system to accommodate the reused components. For small components, these reuse costs may actually be greater than the costs of rewriting the component so the cost savings are relatively small unless the component is very complex and difficult to write.
What is the difference between an application framework and a COTS product as far as reuse is concerned ? Why is it some times easier to reuse a COTS product than an application framework ?
Answers to Study Questions -- Chapters 15 and 16 Answer questions 1, 3, 7, 12 and at least 3 (any) of the remaining questions.
7.
Suggest the possible requires and provides interfaces for the following components. o a component implementing a Bank account ; o a component implementing a language-independent keyboard. keyboards in different countries have different key organizations and different character sets; o a component that implements version management facilities (see Ch 29).
1.
Solution notes: Bank account requires: customer.name, customer.address, branch.code provides: open, close, balance, credit, debit, account-number, canceltransaction
Solution notes:
o
Keyboard requires: character-map provides: set-language, get-key-code, get-character, click-toggle, keyrepeat-rate, key-repeat-delay Version-manager requires: diff, change-set, file.save, file.delete, file.rename provides: add-version, retrieve-version, delete-version, get-versionattributes, modify-version-attributes, create-new-branch, make-link, delete-link, get-link-attributes, modify-link-attributes
It is suggested in Section 15.1 that the objects manipulated by users should be drawn from their domain rather than a computer domain. Suggest appropriate objects for the following types of user and system: o a warehouse assistant using an automated parts catalogue; o an airline pilot using an aircraft safety monitoring system; o a manager manipulating a financial database; o a policeman using a patrol car control system.
2.
Warehouse assistant using a parts catalogue. Objects are parts, part numbers, stock, etc. o Airline pilot using a safety monitoring system. Objects are aircraft sub-systems e.g. engine sub-system and their performance parameters. o Manager manipulating a financial database. Objects are stocks, bonds, investments, interest rates, etc. o Policeman using a patrol car system. Objects are other cars, locations, types of incident, etc. Suggest situations where it is unwise or impossible to provide a consistent user interface. Solution notes: A consistent user interface may be impossible to produce for complex systems with a large number of interface options. In such systems, there is a wide imbalance between the extent of usage of different commands so for frequently used commands, it is desirable to have short cuts. Unless all commands have short cuts, then consistency is impossible.
It may also be the case in complex systems that the entities manipulated are of quite different types and it is inappropriate to have consistent operations on each of these types. An example of such a system is an operating system interface. Even MacOS which has attempted to be as consistent as possible has inconsistent operations that are liked by users. For example, to delete a file it is dragged to the trash but dragging a disk image to the trash does not delete it but unmounts that disk. 3.
o
6.
Solution notes: In general, I do not think that it is ethical to monitor users without telling them that they are being monitored and without telling them the purpose of the monitoring. Depending on the users, it is arguable whether monitoring is ethical at all in that individuals have a write to privacy and this includes how they use systems. If the users are members of the general public then I believe that this should hold; if, however, the users are all employees of the same organisation then the situation is more difficult and monitoring may be permitted (see cases where employees who have downloaded pornography from the web have been sacked.
What factors have to be taken into account when designing a menu-based interface for "walk-up-and-use" systems such as bank ATM machines? Write a critical commentary on the interface of an ATM that you use. Solution notes: Factors to be taken into account when designing 'walk up and use' systems are: 1. 2. 3.
4.
5. 6. 7.
System users may be infirm, or disabled so will not be able to respond quickly to requests. Users may not be able to speak the native language of the country where the machine is installed. ystem users may be completely unfamiliar with technology and may make almost any kind of error in using the machine. The interface must minimise the number of possible errors and must be resilient to any possible error. Some system users are likely to be intimidated by many options. On the other hand, as users gain familiarity with the system, they may expect to use it for a wider range of banking services. Different people may understand the meaning of icons in different ways. If the system has navigation options, users are almost certain to become lost. Most users will want to use the system for very simple functions (e.g. withdraw cash from an ATM) and will want to do this as quickly as possible.
There are many different ATM interfaces so each must be considered separately. Some example problems are:
What facilities they used most. What they felt about the way in which the menus (if any) were arranged. o Where they felt that they made mistakes when using the system. o Whether they used the mouse or the keyboard to issue commands. If they used keyboard shortcuts, which did they use? Did they have problems with these? Discuss whether it is ethical to instrument software without telling endusers that their work is being monitored.
The argument for monitoring, of course, is that it allows behaviour to be tracked and the system improved for users. Without monitoring, any improvements are simply guesses. Furthermore, if users know of the monitoring they may change their behaviour so therefore secret monitoring is justified. It can also be argued that it is the system and not the users that is being monitored. 7.
Discuss the pros and cons of the following approaches to UI development: o discussing manually constructed usage scenarios with prospective users; o prototyping screen displays and iteratively enhancing them; o developing the UI after the functional parts of the system are completed and accepted by the users; o formally describing and analyzing the UI prior to concurrent with the system design. Solution notes:
o o
4.
When is it possible to cancel a transaction? What happens when I do so? What will I have to re-input if I restart the transaction? o There is not usually any way of saying give me the maximum amount of money I may withdraw today. o Some machines only support single transactions - there is no way of saying I will be making several transactions and the same validation process is applicable to all of them. Discuss the advantages of graphical information display and suggest four applications where it would be more appropriate to use graphical rather than digital displays of numeric information.
o
Solution notes: Advantages are "at a glance" magnitude indication and relative magnitude indication. Any applications where these are important might be mentioned:
o o o o
5.
Temperature control Speed indicators Weather statistics Relative comparisons of cars, etc. Design a questionnaire to gather information about the user interface of some tool with wihich you are familiar.
o
Solution notes: The questionnaire should include questions which cover:
o o o o
The experience of the word processor user. The types of documents he/she produces. Are these all text, include text and graphics, use mathematical symbols, etc. Whether the user is familiar with and uses other word processors. What they like/dislike about them. The principal problems perceived by the word processor user.
o
Manually constructed scenarios with prospective users. Advantages include: user involvement from the start, real-life examples that users feel comfortable with, expressed in the language of the user, no big investments needed, quick results. Possible disadvantages include: the extent to which the scenarios cover everything needed, how to document the results, the process need not converge, it is difficult to include dynamics, and the scenarios tend to be simple ones. Iterative prototyping. The advantages include: The resulting system is more likely to fit real user needs. Bells and whistles can be identified as such. Real user requirements can (only) be identified when users have had the opportunity to work with the system. People feel more closely involved with the project and the resulting system. This increases the chances of acceptance of the system. A major disadvantage of the iterative prototyping is that longterm quality aspects (maintainability) tend to be neglected. Develop functional parts first, and only then the user interface. From a managerial point of view, this approach has definite advantages when it comes to control progress. Functionality is decided upon first, and the user interface is seen as a layer on top of this (so, while working on the user interface, no rework is needed because of wrong functionality). It also allows for a clear separation of concerns in the architecture. The biggest disadvantage is that the result need not match the real user needs, and that it takes a long time before the users `see' anything. Formal description and analysis of user interface. A major advantage of formal descriptions is that they allow for formal evaluation. However, it remains to be seen whether the user interface requirements can be sufficiently captured formally. Also, discussing formal specifications with users is not easy, and most developers are not familiar with formal techniques.
8.
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.
Suggest 6 reasons why dependability is important in critical systems. Solution notes: Six reasons why dependability is important are: 0. 1. 2. 3. 4.
9.
Users may not use the system if they don't trust it. System failure may lead to a loss of business. An undependable system may lose or damage valuable data. An undependable system may damage its external environment. The reputation of the company who produced the system may be damaged hence affecting other systems. 5. The system may be in breach of laws on consumer protection and the fitness of goods for purpose. Using an example, explain the difficulties of describing what software reliability means. Solution notes: The problems of describing what reliability really means arise because, formally, reliability is measured with respect to some specification (a system is reliable if it meets its specification). However, users of a system have not normally read the system specification but have a set of expectations about what they expect from the system that is based on their past experience, their training and what they've been told about the system. Therefore, if the system behaves in a way that is different from their expectations, they may see it as unreliable even if it is meeting its specification. The problem is compounded because different users use the system in different ways so a system may meet one user's expectation but not another's. Further complications arise because the specification may be incorrect or incomplete. Therefore, the system may fail in some way and therefore be seen as unreliable. This would not be revealed in a reliability testing process where the test set was derived from the specification.
Alternatively, two different operators could be required to independently input the dose before the machine could operate. 13. In computer security terms, explain the differences between an attack and a threat. Solution notes: 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.
Answers to Study Questions -- Chapters 17 and 18
1.
Solution notes: It is not usually appropriate to use hardware reliability metrics because of the different types of failure which normally occurs in hardware. Most hardware system failures are a result of component failures due to faulty manufacture or because a component has come to the end of its normal life. Once a component has failed, it must be replaced or repaired before normal system services can be resumed. However, most software failures are transient and are a consequence of design errors or timing problems. The component can continue to deliver normal service without repair.
A possible example is a new release of an existing system where users expect features to be the same as in previous versions. If these have changed, then they may see the system as unreliable. 10. Identify six consumer products which may contain, or which may contain in the future, safety-critical software systems. To get you kick started, an example is a microwave. Solution notes: 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 11. Explain why ensuring system reliability is not a guarantee of system safety. Solution notes: 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.
Why is it sometimes inappropriate to use hardware reliability metrics in establishing software systems reliability? Illustrate you answer with an example.
Hardware metrics such as "mean time to failure"are based on component life times and therefore cannot be applied directly to software systems. An example might be a bank teller system which includes a hardware component to open the door to deliver cash and a software component to deliver signals to that door. When the hardware component fails, the whole system is out of action until that component is repaired. If the software component fails in one specific circumstance then cash may not be delivered in that case but delivery could resume with the next transaction. 2.
Suggest appropriate reliability metrics for the following classes of software system. Give reasons for your choice of metric. o a system which monitors patients in a hospital intensive care unit; o a word processor; o an automated Vending machine control system; o a system to control braking in a car; o a system to control a refrigeration unit; o a Management report generator. Solution notes:
12. In a medical system that is designed to deliver radiation to treat tumors, suggest one hazard that may arize and propose one software feature that may be used to ensure that the identified hazard does not result in an accident. Solution notes: 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
System
Reliability metric
Suggested value
Rationale
Patient monitoring system
Availability
System should be unavailable for less than 20 minutes
The system needs to be continuously available as patients may be admitted or discharged at any time. The chosen
per month.
Word processor
Failures resulting in loss of data should not occur more than once per 100 hours of use.
Not a critical system. Faults are unlikely to cause severe disruption
POFOD
Failure acceptable in 1:5000 demands
Not a critical system so relatively high failure rate is OK
Braking system controller
POFOD
The software should never fail within the predicted lifetime of the system.
Very critical system. Failure is unacceptable at any time.
20 minutes per month
Non-stop system but not critical. Short periods of failure are not a real problem as temperature takes some time to rise.
Management report generator
Availability
ROCOF
1 fault/100 hours of use
When the maximum dose and the maximum daily dose is changed, the user should be asked to input the changed values twice. 2. If the maximum daily dose has already been set by the user then the new daily dose should be no more than 1.25 and no less than 0.75 of the previous maximum daily dose. 3. The insulin reservoir case should be designed so that it is only possible to fit the insulin bottle the right way and the case should not close unless the bottle is properly seated. 4. If the back pressure from the needle assembly is more than XX then the system should shut down and issue an audible and text warning. (this caters for blocked needles as well as improperly fitted needles). A safety Critical System for treating cancer patients has two principal components: o a radiation therapy machine that delivers controlled doses of radiation to tumor sites; o a treatment database which includes details of the treatment given to each patient. Identify four hazards that may arise in this system. For each hazard, suggest a defensive requirement which will reduce the probability that these hazards will result in an accident. Solution notes: Hazards: 2. 3. 4. 5.
6.
Explain why the boundaries in the risk triangle (Fig 17.7) are liable to change with time and with changing social attitudes.
In the insulin pump system, the user has to change the needle and insulin supply at regular intervals and may also change the maximum single dose and the maximum daily dose that may be administered. Suggest 2 user errors that may occur and propose safety requirements that would avoid these errors resulting in an accident.
Incorrect dosage of radiation computed Radiation delivered to the wrong site on patient’s body Data for wrong patient used to control machine Data transfer failure between database and therapy machine
Software protection:
Not a critical system. Faults are unlikely to cause severe disruption
Solution notes: The change of the boundaries of the risk triangle with time and social attitudes is a result of, firstly, increased affluence so that safety protection that was once thought to be too expensive is now feasible and because of the influence of the media when reporting accidents and disasters. Accidents such as railway accidents receive a high media profile so there is consequently a lot of public and political pressure to introduce new safety features. Competitive pressures from manufacturers (Car A is safer than Car B) is also a factor in giving safety a higher profile. 4.
1.
5.
Vending machine controller
Refrigeration unit control
3.
ROCOF
Examples of safety requirements to avoid these errors are:
figure is acceptable because, if necessary, critical system functions can be taken over manually.
6.
Comparison with previous doses delivered. Establishment of a maximum monthly dose which may never be exceeded. Feasibility checks (e.g. for negative dosages). Confirmation of dose to be delivered by operator. Continuous visual display of dose being delivered. 7. Comparison with delivery site in previous treatment. Light used to illuminate site of radiation delivery. Operator confirmation of site before machine can operate. 8. Patient asked to verify name, address and age before machine starts by pressing button. Issue patient with a personal treatment card which is handed over to identify patient. Maintain separate list of patients to be treated each day and correlate with patient databases. Force machine operator to verify list and database consistency before starting machine. 9. Dual display of information in therapy machine and database. Highlighting of differences in operator display. Locking of machine until information is consistent. Use of check digits and other error checking codes in the data. Duplicate communication channels between machine and database. Discuss the possible contribution of o strongly-typed languages o goto-less programming, o abstract data types, o object-oriented programming languages, and o procedures having precondition `true' to the construction of reliable software. Solution notes:
Solution notes: Possible user errors are: Maximum daily dose set wrongly Maximum single dose set wrongly Failure to replace empty insulin reservoir Insulin reservoir improperly fitted Needle improperly fitted
o
Strongly-typed languages lead to more robust programs. Illegal combinations in operands, assignments, actual parameters, etc., are detected by the compiler. Clerical typing errors often result in either type mismatches or undeclared objects as well. This all adds to the reliability of the resulting programs.
o
7.
Goto-less programming leads to clearer program structures, structures that are easier to comprehend and test, structures that are less complex. Again, this adds to the reliability of those programs. o Abstract data types offer means for a clear description of the interfaces between the ADTs and the program using those ADTs. Next to that, ADTs hide representation details, details that cannot be (mis) used by the calling program. This increases possibilities for independent testing of program units and decreases mutual dependencies between program units. o Object-oriented programming languages offer the advantage that less code needs to be written because of explicit code sharing between program entities. Also, program changes can often be accommodated through the addition of a new subclass, rather than having to tinker with existing code. o If procedures have precondition true and have been adequately tested in isolation, we know that their use will never pose any problems. Again, the mutual dependencies between program elements is decreased, thus adding to the reliability of the system as a whole. Discuss the following claim: `reliability assessment is more important than testing.' Can you think of reasons why both are needed ?
o
The problem with forward error recovery in interactive systems is the need (possibly) to re-read information. This may not be replicated exactly, particularly if timing considerations are involved. 10. It has been suggested that the control software for a radiation therapy machine should be implemented using N-version programming. Comment on whether or not you think this is a good suggestion. Solution notes: Advantages of N-version programming Increases design diversity so probability of faults that result in failures should be reduced Increases availability of the system Disadvantages Increased cost because of the need to use independent development teams Increased software complexity because of the need for a fault tolerant controller. Increased complexity increases the probability of error Improvement in reliability in practice is limited because of the possibility of common errors made by different development teams.
Solution notes: Ultimately, the actual occurrences of failures are what counts. Faults that never show up, for instance because they are located in a piece of code that never gets executed, are not important. A fault in a piece of code that gets executed many times a day is important, though. Thus, an assessment of the actual frequency of failure occurrences (= reliability) may be deemed more important than testing. On the other hand, both testing and reliability assessment are needed. Testing, if started early on in the project, can help to prevent errors, and provides for systematic means to assess software quality. At a later stage, reliability assessment helps to assess the operational quality of the system. 8.
It would not be a good design strategy for this type of software. There is no need for high availability and the increased complexity and cost would make the overall cost of the machine too high. 11. Give two reasons why all the different system versions in an N-version programming may all fail in a similar way.
Briefly describe forward and backward recovery strategies. Why is backward fault recovery is used more often than forward fault recovery ? Give two examples of classes of systems where backward fault recovery may be used. Solution notes: Backward error recovery restores system state to a known correct state which existed before the fault occurred. Forward error recovery attempts to correct the damaged system stage and compute what it should have been using some other approach.
Solution notes: There may be a specification error which is reflected in both versions. The problem may be a numeric error which has not been explicitly trapped. The specification may be slightly ambiguous and interpreted wrongly by both teams.
Answers to Study Questions -- Chapters 19 and 20
1.
Backward error recovery is more commonly used because it simply means restoring the state before the operation whereas forward error recovery requires that there is some alternative way of computing what the state should be. This is only possible in a small number of cases.
2. What pre-conditions must hold before forward error recovery can be implemented in a fault-tolerant system? Is forward error recovery possible in interactive systems ?` Solution notes: Forward error recovery involves setting the system state to a correct state which is comparable with (although perhaps a degraded form of) the state which would have been reached if the operation has terminated correctly. Recovery blocks are really a form of forward error recovery. The pre-conditions that must hold are:
Discuss the differences between verification and validation and explain why validation is a particularly difficult process. Solution notes: Verification is demonstrating conformance to the specification whereas validation is checking that the system meets the customer's needs. Validation is difficult because there are many different stakeholders who may use the system with different needs. Therefore, a system that meets one user's needs may not meet the needs of a different user. Furthermore, needs change as a system is developed so the needs as identified when the system was specified may be different by the time that the system is tested.
Examples - telephone system where a problem in a call will result in disconnection and the system state being restored to before the call started. Update transaction in a database where the transaction need not be committed if a fault has occurred. Undo in a word processor or other editing system is another example. 9.
Explain why it is not necessary for a program to be completely free of defects before it is delivered to its customers. To what extent can testing be used to validate that the program is fit for its purpose? Solution notes: A program need not be completely free of defects before delivery if: 1.
2.
o
There must be a way of distinguishing incorrect from correct states
There must be a function which can transform the state before the operation plus the given data to a correct state. Usually, this involves more computation than the normal operation (e.g. rebuilding pointers in a list) and may involve re-reading data which has been input.
Remaining defects are minor defects that do not cause system corruption and which are transient i.e. which can be cleared when new data is input. Remaining defects are such that they are recoverable and a recovery function that causes minimum user disruption is available.
3.
The benefits to the customer's business from the system exceed the problems that might be caused by the remaining system defects.
Testing cannot completely validate that a system is fit for its intended purpose as this requires a detailed knowledge of what that purpose will be and exactly how the system will be used. As these details inevitably change between deciding to procure a system and deploying that system, the testing will be necessarily incomplete. In addition, it is practically impossible for all except trivial system to have a complete test set that covers all possible ways that the system is likely to be used. 3.
5.
6.
Solution notes: A black-box testing technique in which the input domain is divided into classes of equivalent data items. Test cases are derived from combinations of elements from each equivalence class. Exhaustive testing of all input domain values is not necessary. 7.
Explain why program inspections are an effective technique for discovering errors in a program. What types of errors are unlikely to be discovered through inspections?
2.
3.
They can find several faults in one pass without being concerned about interference between program faults. They bring a number of people with different experience of different types of errors. Hence, the team approach offers greater coverage than any individual can bring. They force the program author to re-examine the program in detail - this often reveals errors or misunderstandings.
8.
Explain why an organisation with a competitive, elitist culture would probably find it difficult to introduce program inspections as a V & V technique. Solution notes: An organisation with a competitive elitist culture is unlikely to find that program inspections are effective for the following reasons:
What testing problems might arise in numerical routines designed to handle very large and very small numbers ? Solution notes: Testing problems can arise because multiplying or dividing very large or very small numbers can result in numeric overflow or underflow. It is important to test for this occurrence and not simply to test the accuracy of the numerical operations. However, it may sometimes be difficult or expensive to generate appropriate test cases using very large or very small numbers especially if these are normally generated by some other program.
The types of errors that inspections are unlikely to find are specification errors or errors that are based on a misunderstanding of the application domain (unless there are domain experts in the team). 4.
Discuss the differences between black-box and structural testing and suggest how they can be used together in the defect testing process. Solution notes: In black-box testing, the tests are derived from the system or component specification whereas in structural testing knowledge of the structure of the source code is also used to design system tests. They can obviously be used together with the developer of the code (who understands the structure) developing structural tests and an independent testing team developing black box tests.
Solution notes: Program inspections are effective for the following reasons: 1.
Visibility faults where names that should be declared as private are actually public. What is equivalence partitioning as it applies to software testing?
9.
Explain why interface testing is necessary given that individual units have been extensively validated through unit testing and program inspections. Solution notes: There are several reasons why interface testing is a necessary stage after unit testing:
o
1.
5.
Program authors are unlikely to be open about their program because it exposes them to competition. The best programmers, in particular, are unlikely to want to be involved in inspections. 2. The inspection team, rather than being cooperative, are likely to try to compete with each other to find the most errors. While competition can sometimes be helpful, in this situation if someone is obviously falling behind they may then stop participating actively in the inspection. 3. Women often feel intimidated by competitive cultures and may therefore opt out of the process. Using your knowledge of Java, C++, C or some other programming language, derive a checklist of common errors (not syntax errors) which could not be detected by a compiler but which might be detected in a program inspection. Solution notes: The list in Figure 19.7 can also be specialised for each particular programming language e.g. storage management faults need to be checked for in C and C++ but not in Java. Potential programming errors. To some extent these are languageindependent but the extent of the compiler checking varies from one language to another. 1. 2. 3.
4.
Initialisation of a variable to the wrong value (the compiler can check for initialisation but not the right initialisation). Inheritance from the wrong super-class (a problem if the inheritance is not from the root of the class hierarchy). Use of incorrect constants (e.g. previous-value instead of current-value where previous-value and current-value are of the same type). Use of incorrect conditions e.g. < rather than <=. This can't be checked by a compiler.
The interface to the module may have been incorrectly specified. The validation process is based on this specification rather than actual usage of the module or sub-system. o The assumptions made by other modules about the behaviour of a given module (A say) in response to particular interface stimuli may be incorrect. That is, these modules expect A to behave in a way in which it was never designed to operate. o Interface testing can reveal omissions in the interface design. It may be discovered, when integrated with other modules, that the interface must be augmented in some way. 10. Explain why bottom-up and top-down testing may be inappropriate testing strategies for object-oriented systems. Solution notes: Top-down testing is not appropriate for OO systems because these systems do not, in general, have a hierarchical structure. Rather, they are a loosely integrated collection of objects any one of which may be in control at any one time. Top-down testing is an inherent part of top-down development which is, essentially, most suitable for functionoriented development. When objects are loosely integrated into subsystems there is no obvious top to the system. Bottom-up testing is more appropriate for object-oriented systems as individual objects can be tested and, to some extent, individual methods within objects can be tested in isolation. However, in most object-oriented systems there is some reuse of objects and so strict bottom up testing is impossible. Furthermore, the details of these objects may be unknown so the reused objects cannot be tested in a bottom-up fashion. 11. Describe how you might stress test a bank ATM system. Solution notes: Stress testing involves stretching the limits of the system. In an ATM system there are various limits that might be tested ranging from a large number of ATMs trying to perform transactions at the same time to
more local things like pressing lots of buttons on the keypad at the same time. Other sorts of limits that could be stressed might be limits on the number of accounts that the system can manage, the maximum number of transactions per day, the maximum number of power outages that can be properly handled per day, or limits on the number or size of transactions that individuals can do (per day or otherwise).
Page organisation: Each page must include a header giving the title of the project, centred on the page and a footer including the page number and the version of the document submitted. Other information may be included in the header and footer if appropriate. 4.
Answers to Study Questions -- Chapters 24 and 25
1.
Solution notes: Again, no right or wrong answer. The organisation is interested in quantifying its software development so may collect metrics about its products and about its processes. The type of software which is developed is important as the metrics should take into account its characteristics. In this case, the company is developing database products for microcomputers so:
What are the stages involved in the review of a software design ? Solution notes: Stages in a design review are similar to the stages in a program inspection. They are:
o
1.
2.
Planning - where will the review be held; who is involved, who will be the chair, etc. 2. Pre-meeting of review team (optional) where an overview of the design is presented 3. Individual preparation - reviewers work on the design documents 4. Review meeting - walkthrough the design 5. Rework - design modifications made as proposed at the review 6. Follow-up - Check that modifications have been made; new review arrangements if necessary. Design an electronic form that may be used to record review comments and which could be used to mail comments electronically to reviewers.
o
1. 2. 3. 4. 5. 6. 7.
3.
Solution notes: Obviously there is no right and wrong answer to this question. As term projects cover a wide range of topics, the standard should focus on the report organisation. Issues which should be addressed include:
Process metrics Number of different configurations used for system testing Number of fault reports submitted Average time required to clear fault after it is reported Time required to run system regression tests 5.
o o o
Title page identifying the project and its author Introduction describing the problem being solved, the general approach adopted in the solution and problems encountered during the development of the solution Chapters giving a detailed description of the approach used. A concluding chapter which critically assesses the solution Where appropriate, appendices listing the source code of the solution and user documentation.
Title page: The title page must include the following information
o o o o o
Project title Course identifier Author name(s) Date of submission Name of instructor
Explain why design metrics are, by themselves, an inadequate method for predicting design quality. Solution notes: Because quality metrics assume that quality is only related to what can actually be measured (such as coupling). In fact, it is very difficult to say what quality really means and it is certainly related to many different program attributes. The importance of these attributes varies from system to system and from organisation to organisation.
6.
Why should software quality assurance organzation be independent of the development organzation. Solution notes: The primary task of the SQA organization is to check whether work gets done the way it should be done. Suppose the SQA organization is not independent from the developing organization, and some serious problem crops up. From an SQA point of view, some remedial action is required, which may delay delivery of the system. Such is not very attractive to the developing organization. The SQA people may then get crunched between these opposing interests. The situation is like that of an accounting department who is responsible for its own auditing.
Document structure: The document must include the following sections:
o o
As they are shrink-wrapped products, they will run on many different system configurations. Configuration dependent problems may occur. It is important that the system should not hang the machine on which it is running. As they are database products, it is important that the system does not corrupt the database.
Product metrics Product metrics should be used to judge the quality and efficiency of the software. Total number of measured faults detected by testing Total number of faults which resulted in database corruption Total number of system failures which forced a system restart Number of database transactions processed per unit time Time to read/write large DB records
Solution notes: The fields in the review form might include: Name of person raising review comment Date comment raised Contact phone number or e-mail address The review comment itself Name of comment assessor Date of comment assessment Action taken from comment (Return for clarification, invalid comment, accepted comment) 8. System change proposed 9. Person responsible for change 10. Date change made 11. Date change checked Briefly describe possible standards which might be used for reports to be submitted for a term project in a university.
Assume you work for an organization developing database products for microcomputer systems. This organization is interested in quantifying its software development. Write a report suggesting appropriate metrics.
7.
Why is it important to quantify quality requirements ? Solution notes: Suppose one of the quality requirements is `The system should be fast', a typical example of a non-quantified quality requirement. Such a requirement can not be tested; there is no way to tell whether the test `succeeds' or not. Such a requirement also easily gives rise to debates later on, when the user complaints that the system is not fast (enough). Such a requirement does not give the developer guidance either. Such a requirement is useless.
8.
1.
One quality requirement often stated is that the system should be `userfriendly'. discuss possible differences between the developer's point of view and the user's point of view in defining this notion. Think of alternative ways to define system usability in measurable terms.
2. 3.
Solution notes: The developer's view of user-friendliness is likely to be determined by technical properties of the interface: use of windows, buttons, scrollbars, pop-up menus, etc. The developer is inclined to look at user-friendliness from the inside. On the other hand, the user's main concern is to get his job done in the most effective way. User interfaces should not be friendly; they should effectively support the user at work.
Solution notes: Application domains where the SEI process model is unlikely to be appropriate include:
§
Important ways to measure the usability of a system are:
o o o o o
The time needed to learn to use the system (learnability), The time needed to perform typical user tasks (efficiency), The retention of system knowledge over time (memorability), The rate with which errors are made (safety), and A subjective assessment by real users.
4.
Requirements for these characteristics can be expressed in measurable terms. Also, tests can be devised to determine whether these requirements are met. So-called `userfriendly' systems may turn out to score well on these scales, but such is not a priori clear. 9.
Resource utilisation. The amount of resources used. E.g. the effort required to test a module. Events which occur. E.g. The number of defects discovered after a system has been delivered. <\ol> Suggest two application domains where the SEI process model is unlikely to be appropriate. Give reasons.
AI software development. In this case, the very management-dominated approach of the SEI model would be a very high process overhead. Changes are implemented quickly. § Small-scale embedded software in appliances such as washing machines, video recorders, etc. Although some of the practices are appropriate in this case, the software development might be seen as part of the hardware development process. Suggest three specialised software tools which might be developed to support a process improvement programme in an organization. Solution notes: Tools to capture process data from management information. Process model editing tools. Tools to manage a process training program. Process visualisation tools which present different process views.
Suggest process models for the following processes: 0. Lighting a wood fire; 1. Cooking a three course meal; 2. Writing a small (50 line) program. 5. Solution notes: Here is a simple sequence of activities. Obviously, there is scope for alternative descriptions such as parallelism etc. The activities can also, of course, be decomposed
Explain why a methodical process is not necessarily a managed process as defined in section 25.5. Solution notes: A methodical process is a process that is based on the application of some defined method such as OMT (object oriented) or SSADM (function oriented). A managed process is a process that has a defined process model and process checks and documentation to ensure that the process model is being followed.
Lighting a wood fire Assemble a pile of dry wood Collect easily combustible material (tinder) Arrange some or all of the dry wood around the tinder Strike match Light tinder Provide oxygen to fire and shield from drafts
While it is sometimes (not always) the case that methods have an associated process model, these are often very weak and poorly defined and users of the methods rarely follow them exactly. Furthermore, there may not be checks in place to ensure that the method process model is followed. Therefore, although a methodical approach is being used, this is not necessarily a managed process.
Cooking a three course meal Decide on menu for meal Check store cupboard for items in stock Prepare list of groceries required Buy groceries Prepare food to be cooked Cook food Serve food
Answers to Study Questions -- Chapters 23 and 26 Writing a small program Read and understand program specification Decide on data types and structures which are required Decide on processing algorithm required Prepare a rough program design Code program Review program for errors Compile program. Repeat until syntax errors removed Prepare test data Test program 10. Describe three types of software process metric that may be collected as part of a process improvement activity. Give one example each. Solution notes: 0.
Elapsed time. How long it takes to do something. Many possible examples e.g. time taken to carry out design review.
Answer questions 3, 6, 10 and at least 4 (any) of the remaining questions. 1.
Describe two metrics that have been used to measure programmer productivity. Comment briefly on the advantages and disadvantages of these metrics. Solution notes: Metrics that have been used for productivity measurement are:
o o o
Lines of source code produced per unit time Object code instructions per unit time Pages of documentation per unit time
Other possibilities are:
o o o o
Number of data dictionary entries made per unit time (may be useful if CASE tools are used) Number of mathematical definitions produced per unit time (formal specification) Number of requirements written per unit time Number of design diagrams produced per unit time
6.
Solution notes: Both adding people to the project and softening quality requirements may shorten development time. Adding people to the project should be done with care. The impact of softening quality requirements on the time schedule could be estimated (for instance, several of these turn up as cost drivers in models like COCOMO).
All of these, of course, suffer from the same problem as other metrics, that is, they don't take quality into account. 2.
How may early cost estimates influence the way in which a project is executed ?
Other ways to finish the project in time can be discerned by considering the various factors that influence cost (and, therefore, schedule):
Solution notes: An early cost estimate gives a target to aim at. As such, it will influence the project. If we know that the project is estimated to cost 10 person months, we may be inclined to sacrifice quality in order to meet the corresponding deadline. Maintenance will then suffer. If a more realistic cost estimation were given, a higher-quality product could have been delivered, with corresponding savings during maintenance. Conversely, a tight effort estimate may force developers to ignore implementation of bells and whistles, resulting in a leaner system, a system which better fits real user needs. 3.
o
Cost estimates are inherently risky irrespective of the estimation technique used. Suggest four ways in which the risk in a cost estimate can be reduced. Solution notes: Possible techniques of risk reduction include:
Suppose you are managing a project which is getting behind schedule. Possible actions include: renegotiating the time schedule, adding people to the project and softening quality requirements. In which ways can these actions shorten the time schedule ? Can you think of other ways to finish the project in time.
7.
Write less code (reuse, use of high-level languages, concentration on essential features and ignoring bells and whistles), since size is the major determining cost factor; o Employing better people; o Better working environments and other incentives for employees. It is known that programmers with adequate secretarial support and sufficient oorspace are significantly more productive than their colleagues that are worse off; o Employing (more powerful) tools; o Avoiding rework, by a conscious attention to user requirements right from the start, and regular feedback to customers (validation). Can you give an intuitive rationale for the values of the COCOMO 2 cost drivers relating to project attributes ?
o
4.
Obtain a number of independent estimates using different estimation techniques. If these are widely divergent, generate more costing information and iterate until the estimates converge. o For those parts of the system which are hard to estimate, develop a prototype to find out what problems are likely to arise. o Reuse software to reduce the amount of estimation required and to reduce overall costs. o Adopt a design to cost approach to development where the system functionality is adapted to a fixed cost. o Partition software requirements into critical, desirable and `gold plating'. Eliminate `gold plating' if necessary. Give three reasons why algorithmic cost estimates prepared in different organizations are not directly comparable.
Solution notes: COCOMO 2 mentions three cost drivers that relate to project attributes:
o o o
The use of software tools allows the developer to concentrate on his real, intellectual tasks, while all kinds of bookkeeping duties are taken care of by the tools at his disposal. This would thus result-in productivity gains. If development takes place at more than one site, this incurs extra costs: for traveling, for written documentation instead of face to face communication, and the like. The chance for miscommunication, and thus for rework, increases as well.
Solution notes:
The effort multipliers for the development schedule are somewhat more surprising: both acceleration and stretchout of the nominal schedule incur higher cost. That acceleration of the schedule incurs higher costs is quite plausible: it requires more people, with associated communication and learning cost. According to [Boehm, 1981], stretchout of the schedule primarily implies spending a longer time with a smaller frontend team to thoroughly develop and validate requirements and specifications, test plans and draft users' manuals. This would then translate into higher-quality products and/or less maintenance.
o o o o
5.
Different languages and development tools Different ways of counting lines of code Subjective complexity estimates to adjust results Different historical cost databases (e.g. different activities costed against projects) Explain how the algorithmic approach to cost estimation may be used by project managers for option analysis. Suggest a situation where managers may choose an approach that is not based on the lowest project cost. Solution notes:
o o o
It is interesting to note the differences in cost drivers between COCOMO and COCOMO 2. The multi-site cost driver was not present in COCOMO; apparently, multi-site development projects were not very common at that time. On the other hand, COCOMO had a cost driver `use of modern programming practices' (in particular information hiding); this has become common practice, and its role as a cost driver has consequently disappeared.
Produce worst, best and most likely cost estimates using simple model. Identify process and product variables such as team experience, possibility of hardware upgrade, possibility of tool purchase, etc. Build a spreadsheet model allowing the effects of these variables on the cost estimates to be computed. 8.
When there are organisational reasons, some approach which is relatively more expensive may be chosen. For example, software engineers whose experience is not ideal may be available so they may be used rather than recruit new staff.
Use of software tools, Multi-site development, and Required development schedule.
Explain why Legacy systems may be critical for the successful operation of a business. Solution notes: Legacy systems may be critical for the successful operation of a business for two basic reasons
o
9.
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. o 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. Most legacy systems use a function-oriented approach to design. Explain why this approach to design may be more appropriate for these systems than object-oriented design strategy.
12. Suggest ten questions that might be put to end-users of a system when carrying out a business process assessment. Solution notes: Ten possible questions are: 1. 2. 3.
Is there a defined process model? Who is responsible for updating and maintaining the model? Do people follow the model or do they develop their own process? 4. If a model exists, what is missing from the model? 5. How do people cope with the missing parts of the model? 6. Does the process involve repetition of work that has been done by someone else such as entering data. 7. Are there delays in the process that could be avoided? 8. Does the process involve generating paperwork that is rarely used? 9. Are there parts of the process that involve repetitive, routine work? 10. What problems arise with the software support for the process?
Solution notes: A function-oriented approach to design may be appropriate because many legacy systems are concerned with either transaction processing or with processing records from a file. The processing of each transaction or record is independent of the previous transaction and record so no system state (as would normally be held in objects) need be maintained. Therefore, functions are a suitable processing abstraction. Furthermore, the processing is often data driven based on the value of a field of a record and this data can then be used to select the function to execute. 10. Sommerville 26.6. Solution notes: A possible data flow diagram for 'Compute salary' is shown below. Obviously there are many variations to this.
11. Under what circumstances might an organisation decide to scrap a system when the system assessment suggests that it is of high quality and high business value ?
There are many other possible questions that could be valid answers here.
Answers to Study Questions -- Chapters 27 and 29 Answer questions 3, 6, 10 and at least 4 (any) of the remaining questions. 1. Give some reasons why software maintenance can't be avoided. Solution notes: Systems must change or become progressively less useful for a number of reasons: o The presence of the system changes the ways of working in its environment and this generates new requirements. If these are not satisfied, the usefulness of the system declines. o The business in which the system is used changes in response to market forces and this also generates new system requirements. o The external legal and political environment for the system changes and generates new requirements. 2. Explain the difficulties of measuring Program maintainability. Why is it simplistic to measure maintainability in terms of complexity ? Solution notes: Program maintainability is difficult to measure because the maintainability is related to several different factors. These include: o Control complexity o Data complexity o Program naming o Program comments o System documentation o Background of the maintainer o Programming language used o Programming language constructs used o Programming language style Because it is probably the case that the importance of these factors vary from program to program, it is simplistic to relate maintainability simply to complexity. 3.
Explain why encapsulating a mainframe legacy system and using it as a server should only be considered as a short-term solution to the problem of architectural evolution. Solution notes: Servers should serve a single purpose such as a database server, a mail server, etc. and hence have a coherent role in a system architecture. If a mainframe system is encapsulated then it is multi-purpose (database + application logic + maybe user interface) so either there is duplication of function (if the practical use of the encapsulated legacy system is as a database) or logically related functions are split across the encapsulated system and other components of the architecture.
4.
Two major international banks with different customer information databases merge and decide to provide access to all customer information from all bank branches. Giving reasons, suggest the most appropriate strategy for providing access to these systems. Solution notes: Assuming that neither of the databases is accessible through the Internet already, the simplest solution to this problem is to provide a common
Solution notes: There is no hard and fast answer to this as obviously it depends on local circumstances. Examples of where software might be scrapped and rewritten are:
o
o o
When the cost of maintenance is high and the organisation has decided to invest in new hardware. This will involve significant conversion costs anyway so the opportunity might be taken to rewrite the software. When a business process is changed and new software is required to support the process. When support for the tools and language used to develop the software is unavailable. This is a particular problem with early 4GLs where, in many cases, the vendors are no longer in business.
internet interface to both databases, encapsulate each database as a separate server then use some middleware to sort out which database is actually being accessed. The overall model is as shown Below. The GUI to character convertor changes the original character interface into a webbased GUI interface so that there is no need to alter the actual code in the database application. 5.
Discuss advantages of Software configuration control support during software maintenance. Solution notes: During maintenance, changes are made to existing artifacts (design descriptions, code, etc). This results in different versions of those documents. Software configuration management helps keep track of revision histories and versions. Older versions remain available, so that changes can be undone, and the revision history itself can be of help during maintenance. Additional support for building executables both optimizes this process (unchanged components need not be compiled anew) and helps to get the right executables (those that contain the most recent version).
6.
Discuss the possible contributions of object-oriented software development to software maintenance. Solution notes: Object-oriented software development emphasizes the modeling of a problem, rather than any particular solution to that problem. The structure of the resulting system should then better reflect the structure of the problem domain. Stable entities are the focus of attention, and volatile functionality is implemented through operations on objects. This should help to reduce maintenance effort. At the code level, systems written in OO languages tend to be shorter because of the code sharing that results from inheritance. Smaller programs require less maintenance. Finally, changes to programs can be realized through subclasses, rather than through tinkering with existing code. On the negative side: OO programs may be more difficult to comprehend, because the thread of control is more difficult to discern. The inheritance mechanism may make it more difficult to decide which parts of the system `apply' at a given point. Excessive use of inheritance is likely to make the system really difficult to comprehend and maintain, hence the slogan `Inheritance is the goto of the 1990's'.
7.
8.
Can you think of reasons why a 10% change in a 200-line program would take more effort than a 20% change in a 100-line program ? Solution notes: Changing a program involves three subtasks: 1. comprehending the program, 2. making the change, and 3. retesting the program. Subtasks 1 and 3 require an effort proportional to the length of the program; this effort is hardly, if at all, affected by the size of the change. Subtask 2 may be expected to incur a cost proportional to the size of the change. If the cost of activity i is Ci per line of code, then a 10% change in a 200 LOC program is the more costly one if: 200C1 + 20C2 + 200C3 > 100C1 + 20C2 + 100C3 This inequality is true for any nonnegative value of C1 to C3. Discuss the differences and similarities between configuration management during development and maintenance. Solution notes: The major tasks of software configuration management (SCM) are the same during development and maintenance. In both cases, SCM is concerned with identifying and controlling changes. In both cases, it must ensure that changes are properly implemented and reported to interested parties. Major differences between SCM during development and maintenance are: o Most of the identification and definition of configuration items takes place during development; o During development, change requests are issued by both developers and users. During maintenance, most change requests will come from users. o During development, the assessment and handling of change requests is impacted by the necessary orderly progress of development. During maintenance, continuation of the system's operation is a major criterion. o During maintenance, the operational baseline must be thoroughly separated from the version that is being changed
because of bugs reported or changes that need to be incorporated. Thus, version control plays an even more important role during maintenance. 9.
Discuss the possible differences between configuration management in waterfall development and evolutionary development. Solution notes: Software configuration management (SCM) is concerned with: identification, control, status accounting, and auditing. For these activities, the main differences between a traditional development model and an evolutionary model are: o (identification) In an evolutionary model, there are many variants of components in use at the same time; in a traditional model, usually one or only a few such variants are in use. SCM must be able to distinguish between all those variants. o (control) In evolutionary development, multiple versions of baselines are deployed at the same time, and multiple versions of components and baselines are under development simultaneously. In traditional development, there is one baseline and, usually, one version of each component. o (status accounting) Is challenged as well in evolutionary development, with its multivariate product in various simultaneous stages of development and deployment. o (auditing) Has to be done frequently and quickly in evolutionary development. Baselines change rapidly, and the results of audits must be promulgated timely to baselines in use and in development.
10. Explain why you should not use the title of a document to identify the document in a software configuration management system. Suggest a document identification scheme that may be used for all projects in an organization. Solution notes: The title should not be used as it is not a unique identifier (several documents from different sub-projects could have the same title). A possible numbering scheme could have the form :::::: 11. Describe 5 factors which must be taken into account by engineers during the process of building a release of a large software system. Solution notes: Have all components been included? Is the right version of all components been included? Are all configuration/data files included? Is the right version of the system building tools used? Are there any problems with full path name references? 12. Describe two ways in which system building tools can optimise the process of building a system from its components. Solution notes: Two ways of optimising the system building process are: Reuse of derived elements. If an element has already been compiled, use the compiled version rather than re-compiling. Parallel building. Different components of the system can be built on different nodes of the network. Derived elements may be reused by maintaining a derived element pool which associates descriptors with derived elements. These descriptors uniquely identify the source element used to create the derived element so different versions of the derived element can be maintained in the derived element pool. Parallel building is supported by maintaining a list of possible build platforms and, when a build is initiated, choosing a machine from this list. The files to be processed are down-loaded to this machine before processing.
