CHAPTER 1 SOLUTIONS 1.2 1.

What is the most important differences between generic software product development and custom software development? What might this mean in practice for users of generic software products? The essential difference is that in generic software product development, the specification is owned by the product developer. For custom product development, the specification is owned and controlled by the customer. The implications of this are significant the developer can quickly decide to change the specification in response to some external change (e.g. a competing product) but, when the customer owns the specification, changes have to be negotiated between the customer and the developer and may have contractual implications. For users of generic products, this means they have no control over the software specification so cannot control the evolution of the product. The developer may decide to include/exclude features and change the user interface. This could have implications for the users business processes and add extra training costs when new versions of the system are installed. It also may limit the customers flexibility to change their own business processes.

1.6.

Explain why there are fundamental ideas of software engineering that apply to all types of software systems. Because of all software systems have common quality attributes, including availability, modifiability, performance, security and safety, testability and usability, the fundamental software ideas provides common solutions or tactics to support those qualities.

1.5

Based on your own knowledge of some of the application types discussed in the textbook (chapter 1, section 1.1.2), explain, with examples, why different application types require specialized software engineering techniques to support their design and development. Different application types require the use of different development techniques for a number of reasons: a) Costs and frequency of change. Some systems (such as embedded systems in consumer devices) are extremely expensive to change; others,must change frequently in response to changing requirements (e.g. business systems). Systems which are very expensive to change need extensive upfront analysis to ensure that the requirements are consistent and extensive validation to ensure that the system meets its specification. This is not cost effective for systems that change very rapidly. b) The most important non-functional requirements. Different systems have different priorities for non-functional requirements. For example, a real-time control system in an aircraft has safety as its principal priority; an interactive game has responsiveness and usability as its priority. The techniques used to achieve safety are not required for interactive gaming; the extensive UI design required for games is not needed in safetycritical control systems. The software lifetime and delivery schedule. Some software systems have a relatively short lifetime (many web-based systems), others have a lifetime of tens of years (large command and control systems). Some systems have to be delivered quickly if they are to be useful. The techniques used to develop short-lifetime, rapid delivery systems (e.g. use of scripting languages, prototyping, etc.) are inappropriate for long-lifetime systems which require techniques that allow for long-term support such as design modelling.

c)

1.3 What are the four important attributes that all professional software should have? Suggest four other attributes that may sometimes be significant.
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.

1.8 Discuss whether professional engineers should be certified in the same way as doctors or lawyers.

Advantages Competitive since they have been trained according to the standardize training procedure. Legal binding from the source of certification can ensure the that the software engineer is trusted.

Disadvantages Certification may not reflect the performance of the software engineer. No assurance that certified software engineer will guarantee fool-proofed project.

1.4 Apart from the challenges of heterogeneity, business and social change, and trust and security, identify other problems and challenges that software engineering is likely to face in the 21st century (Hint: think about the environment).

Problems and challenges for software engineering (p13) Developing systems for multicultural use Developing systems that can be adapted (make suitable) quickly to new business needs (or market requirement) Designing systems for outsourced development (maybe Oral) Developing systems that are resistant to attack (information security) Developing systems that can be adapted and configured by end-users (user can design or assemble what they want)

1.9 For each of the clauses in the ACM/IEEE Code of Ethics shown in Figure 1.3, suggest an appropriate example that illustrates that clause.

Advantages of certification l l l Certification is a signal to employers of some minimum level of competence. (2,3) Certification improves the public image of the profession. (1,5) Certification generally means establishing and checking educational standards and is therefore a mechanism for ensuring course quality. (3,8)

l l

Certification implies responsibility in the event of disputes (argue). (4) Certifying body is likely to be accepted at a national and international level as speaking for the profession. (6)

Certification may increase the status of software engineers and attract particularly able people into the profession. (1)

1.10 To help counter terrorism, many countries are planning or have developed computer systems that track large numbers of their citizens and their actions. Clearly this has privacy implications. Discuss the ethics of working on the development of this type of system.

CHAPTER 2

2.1. 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. A system to control anti-lock braking in a car. A virtual reality system to support software maintenance A university accounting system that replaces an existing system An interactive system that allows railway passengers to find train times from terminals installed in stations. A system to control anti-locking in a car. Spiral model. Since this type of system is a safety-critical system, we need to designed a perfect system with no errors since error may lead to a lifethreatening situation

A virtual reality system to support software maintenance. Waterfall model. The requirement of this type of system is rarely change or perhaps fix. Therefore, it is better to develop a waterfall model to swift the progress. (We want to focus on maintaining software not focusing on the virtual system performance and esthetics)

A university accounting system that replaces an existing system. Iterative model. Since the this type of system might be a legacy system, we have to iteratively develop part of the system one by one and integrate it to the existing system concurrently.

An interactive system that allows railway passengers to find train times from terminals installed in stations.

Prototype model. User requirements may likely to change and fast delivery is essential to be implemented. Therefore, prototype model can save time of development to focus on essential function first to be later completed.

2.2. Explain why incremental development is the most effective approach for developing business software systems. Why is this model less appropriate for real-time systems engineering? Business software systems usually complex, software intensive, and frequently being changes when business goals or processes are changed. So incremental development is better. Real-time systems usually involve many hardware components which are not easy to change and cannot be incremental. Also real-time systems usually safety critical which needed be built based on well planned process. 2.3 Why

reuse-based process model is essential to have two separate requirements engineering activities in the process?
To make the reuse software engineering a complete model we need to add two more activities of the software process because if we look at the process stages of reuse engineering it starts at component analysis and thenRequirement modification. So we need to have Requirements before being able to modify it. In other words how can we modify a requirement before establishing a requirements and also same is true for validation because at the end the system is required to be validated before delivery.

2.4 Suggest why it is important to make a distinction between developing the user requirements and developing system requirements in the requirements engineering process. There is a fundamental difference between the user and the system requirements that mean they should be considered separately. a) The user requirements are intended to describe the systems functions and features from a user perspective and it is essential that users understand these requirements. They should be expressed in natural language and may not be expressed in great detail, to allow some implementation flexibility. The people involved in the process must be able to understand the users environment and application domain. b) The system requirements are much more detailed than the user requirements and are intended to be a precise specification of the system that may be part of a system contract. They may also be used in situations where development is outsourced and the development team need a complete specification of what should be developed. The system requirements are developed after user requirements have been established.

2.7. Explain why systems developed as prototypes should not normally be used as production systems. ANSWER: Here one should note that prototypes are often used as production systems, due to the pressures of development. However, they have several faults. a) The user interface may be minimal and not intuitive. b) There may be no error detecting or handling code. c) Such error messages as there are will likely be vague. d) Generally, prototypes are not viewed as high quality products, but just tools to aid the development process.

2.8. (i) Its justification in terms of problems with waterfall methods. (ii) The main elements of the method and how it should be progressed. (iii) An important part of the spiral method is risk analysis and management. Define the types of risk associated with a software development project and discuss whether it is possible to manage the risks involved.

What are the advantages of providing static and dynamic views of the software process as in the Rational Unified Process?
2.9

The Rational Unified Process recognizes that a single process model presents only a single view, so the RUP incorporated three perspectives, two of them being dynamic, that describes the phases of the model as time progresses, and static, that describes the activities that are enacted. The strength in using both is that phases of the development process are not tied to any one specific workflow, so the entire process can be understood.

3.1 Explain why the rapid delivery and development of new system is often more important to business than the detailed functionality of theses systems Rapid delivery focuses on the delivery of the system. It is good for a system that is required to show the result of the system. It is good for business since the system can be used early if the essential functionality is available and be later improved as the user requirements change. Rapid delivery can make profit swiftly. However, rapid delivery is not good for critical-system development since the delivery of the system needs to be perfect and without failures.

3.2 Explain how the principles underlying agile methods lead to the accelerated development and development of software. The principles underlying agile development are: a) Individual and interactions over processes and tools. By taking advantages of individual skills and ability and by ensuring that the development team knows what each other are doing, the overheads of formal communication and process assurance are avoided. This means that the team can focus on the development of working software. b) Working software over comprehensive documentation. This contributes to accelerated development because time is not spent developing, checking and managing documentation. Rather, the programmers time is focused on the development and testing of code. c) Customer collaboration over contract negotiation. Rather than spending time developing, analyzing and negotiating requirements to be included in a system contract, agile developers argue that it is more effective to get feedback from customers directly during the development about what is required. This allows useful functionality to be developed and delivered earlier than would be possible if contracts were required. d) Responding to change over following a plan. Agile developers argue (rightly) that being responsive to change is more effective than following a plan-based process because change is inevitable whatever process is used. There is significant overhead in changing plans to accommodate change and the inflexibility of a plan means that work may be done that is later discarded. 3.3 When would you recommend against the use of an agile method for developing a software system? Explain your answer. Agile methods should probably not be used when the software is being developed by teams who are not co-located. If any of the individual teams use agile methods, it is very difficult to coordinate their work with other teams. Furthermore, the informal communication which is an essential part of agile methods is practically impossible to maintain. Agile methods should probably also be avoided for critical systems where the consequences of a specification error are serious. In those circumstances, a system specification that is available before development starts makes a detailed specification analysis possible. However, some ideas from agile approaches such as test first development are certainly applicable to critical systems.

3.4 Extreme programming express user requirements as stories, with each story written on a card. List and explain at least two respectively, advantages and disadvantages of this approach to requirements description. Advantages

Scenarios cope with most of common operation. It is easy to identify what type of operation that is required in the users stories. (Just look for the verb in the scenario cards) Customer focus in the scenario card increase the chance that the software produced will actually meet the needs of the users Disadvantages Using scenarios on a card can bring to a function overlooked or omission which can be a time-consuming process to complete the system Two different scenarios can lead to the same function as it will be conflicted each other. Crossing out redundant scenarios can be a cumbersome tasks.

3.6 Suggest at least two reasons why the productivity rate of programmers working as a pair is roughly the same as two programmers working individually. Continuous reviewing of the program by two different individuals is more effective than one individual which may be bias and undetectable. Pair programming makes the code less defective. Encourages refactoring. The code is prone to be edited and enhanced to increase effectiveness and testing the code will outputted in a non-biased result. Increase communication in discussing the software before development results in fewer false start and less rework. The number of errors avoided by the formal inspection is such that less time is spent to repairs bugs in the testing phase.

3.10 To reduce costs and the environmental impact of commuting, your company decides to close a
number of offices and to provide support for staff to work from home. However, the senior management who introduce the policy are unaware that software is developed using agile methods, which rely on close team working and pair programming. Discuss the difficulties that this new policy might cause and how you might get around these problems. The difficulties that may arise with this policy if making employees work from home are: The benefits obtained through agile methods will be less effective. Communication gap between the members of a team The benefit of error detection and evaluation through pair programming is lost. Pair programming is not possible. Due to sudden changes in the teams, the project development may be slowed down. Rather than completely closing some offices and asking people to work from home, employees Communication within the members of the team must be improved and must communicate Information regarding project should be shared and communicated.

The measures that can be taken to get around such difficulties are: can be moved to some offices and accommodated. regularly.

4.2 Discover the 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 destination and select a credit card and a personal identification number. The rail ticket is issued and their credit account charged. 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 then requested to input their personal identifier. When the credit transaction has been validated, the ticket is issued.

Cases need to be considered for invalid credit transactions, improper cards, incorrect personal ID numbers, over-the-limit transactions, debit transactions; details could be given on how the credit information is input, either by swiping a card, inserting a card, or manually entering the numbers.

4.3 Rewrite the above description using the structured approach described in this chapter. Resolve the identified ambiguities in some appropriate way. Function Give customer a rail ticket, and charge credit account accordingly Description Determine customers destination, calculate the charge for the trip, and charge the customer the appropriate amount. If charge is complete, print the ticket, otherwise, print no ticket, and report error to customer. Inputs Destination, credit card number, personal ID number Outputs Tickets, error messages Action Ask the customer for their destination, when input, calculate the total, and prompt for swiping of a credit card, prompt customer for PIN, prompt customer that the transaction is taking place, if successful print the ticket and return to start state, if unsuccessful, ask customer to swipe their card again and re-input the PIN. If unsuccessful again, prompt that the transaction has failed, and return to start state. Requires Destination, credit card number, and PIN Pre-condition None Post-condition None Side effects Charge to the customers credit account

4.4 Write a set of non-functional requirements for the ticket issuing system, setting out its expected reliability and its response time?

The ticket system shall respond to user inputs to provide tickets and charge accounts in a timely manner. The system shall continue to function so long as roll of ticket paper is in the machine, and a network connection is provided for the destination database and credit transactions. Upon receipt of the destination from the user, the database shall be accessed to determine the distance from the units location, to the desired destination, and calculate the appropriate fee. The unit shall then prompt the user to input their card information, and the unit shall verify that the card is a credit card, is valid, and has sufficient credit to be charged. Upon successful verification, the unit shall print a ticket, and return to its ready state, for the next transaction to take place. The reliability this system relies on the durability of the physical user interface, the network connection in the area the system is placed, the size of the ticket rolls that the unit can accept, and the mechanism for dispensing the tickets. The estimated time for a complete transaction would be about thirty seconds, giving twenty for the user interactions, five for validation and verification of the users account, and five for printing and dispensing the ticket.

4.5 Using the technique suggested here, where natural language is presented in a standard way, write plausible user requirements for the following functions:

A ) An unattended petrol (gas) pump system that includes a credit card reader. The customer swipes the card through the reader and then specifies the amount of fuel required. The fuel is delivered and the customers account debited. The user shall be prompted to swipe their credit card, and enter their PIN. Upon verification of the card, the user shall be prompted to select the octane level of their fuel, and enter a desired amount requested in dollars. Pumping shall be unlocked until the fuel-cutoff is engaged, or the predetermined amount of money worth of has been deployed. In the event of the fuel cutoff engaging, any remaining money shall be refunded to the users credit account B ) The cash dispensing function in a bank ATM.

The user shall enter their bank card in the slot provided. Following the appropriate prompts for a cash withdrawal, the user shall enter the requested amount. If the amount requested is not greater than the amount in the account, cash shall be dispensed, and the card shall be returned.

C ) The spelling check and correcting function in a word processor. When the user enters a word, separated by any white space or punctuation, the spelling of said word shall be checked against an existing database. If the word is not found, the user shall be notified that the word is incorrect. If the user so chooses to correct the misspelled word, a list of closely matched words shall be provided for the user. If the user chooses a word given, it shall be replaced and the notification of the misspelled word shall be removed.

4.6 Keeping track of the relationsships between functional and non functional requirementts is difficult because non functional requirements are sometimes system level requirement are sometimes system level requirements rather than requirements which are specific to a single function or group of functions. One approach that can be used is to explicitly identify system level non functional requirements and list them separately.All system requirements which are relevant for each functional requirements should be listed.

4.7 Using your knowledge of how an ATM is used, develop a set of use-cases that could serve as a basis for understanding the requirements for an ATM system.

1. 2. 3. 4. 5. 6. 7.

The user is prompted to enter a card The user enters their card The user is prompted to enter their PIN The user enters their PIN The user is prompted to withdraw or check balance The balance is displayed If withdraw is chosen, the user is prompted to enter the amount to be withdrawn 8. If withdraw is chosen, the amount is compared with the balance, and if enough money is available, the money is dispensed 9. If withdraw is chosen, the user is prompted to take the dispensed money 10. The user is prompted to take their card 11. All transactions are complete, and display a happy message for the user

4.8 Who should be involved in a requirement review? Draw a process model showing how a requirement review might be organized. The primary stakeholders should be involved in the requirements review, as well as those involved with the development of the system, and the project managers who are in charge of the budget and scheduling of the system.

4.9