0707

0707.321– Principles of Software Engineering Exam #1 Name: Section: Part I – Multiple Choice 1. [1 point each] Designate the following requirements as one of: (a) functional (b) non-functional (product requirement) (c) non-functional (organizational requirement) (d) non-functional (external requirement)   The ATM customer shall be able to choose make the cash withdrawal from any of a number of bank accounts. [(d) functional] The ATM shall not let the customer check their account balances until their PIN has been validated. [(d) security constraint  external requirement. Because of phrasing, (a) is also acceptable.] The ATM shall communicate with the bank computer via a standard telephone line and modem. [(d) interoperability constraint  external requirement. Because it also touches on portability, I accepted (b).] The software must run on Microsoft Windows 2000. [(c) implementation  organizational requirement.] The software must be ready in six months. [(c) delivery  organizational requirement.] The word processor program shall include online documentation. [(b) usability  product requirement.] To improve reliability (defending against a machine crash), the spreadsheet program should periodically make a checkpoint copy of any open spreadsheet. [(b) reliability  product requirement. Because of phrasing, (a) is also acceptable.] The air traffic control system should run on a computer costing no more than $5,000,000. [(b) usability  product requirement.] The computer vision system should work in low light. [(b) usability  product requirement.] The web browser must be able to display all legal HTML documents. [(d) interoperability  external requirement.]         Page 1 of 7 Part II – Short answer (~25 words) [4 points each = 36 points total] 2. Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model (i.e., one mentioned on the "cheat sheet") that might be used as a basis for managing the development of the following systems: a. A system to control a car's anti-lock braking system It is safety-critical that a car’s anti-lock braking system work, so a method based on formal transformations (with proofs of equivalence between each stage), would be the most appropriate here. Partial credit was given for “Incremental” or “Spiral” if accompanied by a reasonable rationale. Smaller partial credit for Waterfall. b. A virtual reality system to support software maintenance A virtual reality system would be cutting edge, and its usability would depend heavily on the quality of its user interface. One would be hard-pressed to be able to specify all the requirements in advance of design/implementation, so following a “Waterfall” or “Formal” process model would be difficult. Feedback from the users would be essential. An Evolutionary Model seems ideal here, but nearly-full credit was given to “Incremental” or “Spiral” if justified in the prose. c. A university accounting system that replaces an existing system Since this new system will be replacing an established system, eliciting requirements in advance of design/implementation is quite feasible. The resulting system will also be quite large. Both of these conditions lead one to conclude that a Waterfall-type process model would be the most appropriate here. “Incremental” or “Spiral” received substantial partial credit. Many people decided that upgrading the existing system was the right approach, and spoke about using reusing components of the existing system. That approach was rewarded as well, even though one can’t rely on being able to reuse components of an existing system if reuse wasn’t a consideration when it was developed. d. An interactive system, running in kiosks in train stations, for railway passengers that finds train times. An interactive timetable system with a complex user interface but which must be stable and reliable. The stability/reliability implies something like “Waterfall” or at least “Incremental”, but the presence of a user interface (which requires user feedback to be developed) is problematic. The best approach would probably be to employ a throw-away prototype to find requirements and then use a Waterfall or Incremental model. Partial credit was given for “Evolutionary Development”. One problem with evolutionary development is that the final system might not be as robust as it needs to be. One point in its favour is that the user interface will need to evolve during development, as its requirements are refined. Page 2 of 7 3. Rewrite these requirement specifications so that they are verifiable, splitting them into multiple requirements if you deem that appropriate. The goal of this question was to transform these requirements into something that could be objectively tested against an implementation later in the Process. Typically, the answer took the form of replacing the adverbs and adjectives in the supplied requirement with an objective metric. The values are arbitrary. (See Sommerville Section 5.1.2 for more info.) a. The ATM should authenticate the cardholder quickly The ATM should authenticate the cardholder in [some reasonably short time period]. b. The word processor's user interface should be intuitive to the new user After [reasonably short time period] of use with the word processor, a new user should be able to correctly use the system’s features [some high frequency value] of the time. c. The word processor should be able to run well on consumer computers The word processor should be able to run on popular operating systems (e.g. Windows 2000) on low-end computers (such as are sold at retail outlets like Radio Shack or Best Buy). When running on such low-end computers, most, i.e., [high-percentage], of the features should be able to run in [short time period]. d. The new bank transaction system should be able to handle our expected traffic for the next five years The new bank transaction system should be able to handle [high-performance quantity] of transactions, which is our projected load for five year’s hence. e. The air traffic control system shouldn't crash, and if it does, it should be able to "reboot" immediately The mean-time to failure of the ATC system should be [very high time period, e.g. a month] under [quantify] standard workloads. If it crashes, it should reboot automatically within [very short time period]. Page 3 of 7 Part III - Medium-length (~100 words) answer [10 points each] 4. What are the benefits of testing software system components individually (unit and module testing) before assembling them into a complete system? Here is a short list of the benefits, with how many points raising each was worth. Notice the two “bonus” items.       Bugs are found earlier in development (2) When bugs are found, better idea where (in the code) the problem lies (4) Problems at integration time will be integration related (2) From higher-level, harder for tests to rigorously exercise all features (2) Components might be reused, component test results still valid (+2) Each Component small enough to exercise rigorously, by the coder(s) who developed it (+2) 5. What are the benefits of conducting ethnographic studies as part of the requirement elicitation process? What are the risks? An ethnographic study discovers the personal and social behavior of the targeted user base. It might discover requirements that too intuitive to have been mentioned, or involving interpersonal/social interactions or organizational factors that would not have been considered important in more formal requirements elicitation exercises. (6 points) The primary risk is that requirements elicited from an ethnographic study reflect the current behavior of the target user base. Habits, both good and bad, shaped by the existing work environment, which might change when the new system is installed, are reinforced. (4 points) Page 4 of 7 6. Based on your experience with ATMs, draw a data-flow diagram modeling the data processing involved when a customer withdraws cash from the machine. Here is a rough breakdown of where the points went:      2 pts for the authentication session 2 pts for the details of the withdraw session 2 pts for withdrawal transaction completeness (checking balance; updating balance, etc.) 2 pts for explicit exception handling (bad PIN, insufficient funds, etc.) 2 pts for overall diagram clarity 7. Explain why, for large systems development, it is recommended that prototypes should be 'throw-away' prototypes. [6 points for how throw-away prototypes are good for large-systems development. 4 points for why evolutionary prototypes are bad for large-systems development.] Large systems are usually developed by different teams and these require a common reference framework (the system requirements) for developing the system. Throw-away 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. Page 5 of 7 Part IV - Time-consuming Question Answer only one of these questions below. Use the back of the page if necessary. [14 points] 8. Discuss the problems of using natural language for defining user and system requirements and show, using small examples, how structuring natural language into forms can help avoid some of these difficulties. The main problem with expression requirements in natural language is the ambiguity that results. Vague terms can be interpreted differently by different viewpoints. Further, programmers and customers might use the same word to mean different things (e.g., “fast” is likely to refer to response time for users, but efficiency for programmers). Some ways to mitigate these problems:  Use a standard format (or a form) for the requirements. Makes them easier to read and understand the role of the sentences within a requirement specification  Use consistent language. E.g., “must” implies a mandatory requirement, “should” a desirable requirement  Avoid use of computer jargon Natural language is a more serious problem in the specification of system requirements, where more detail and precision is required. Structuring the text into standard forms helps here. A form would include standardized fields; this forces the writer to answer certain questions, and helps the reader find the answers quickly. A standard form could include the following fields:  Description of the function or entity being specified in this requirement  Description of the function inputs, and the constraints on their values (pre-conditions)  Description of the function outputs, and the constraints on their values (post-conditions)  Description of any side-effects. An example of a form can be seen in figure 5.13 (p. 112) of Sommerville. Page 6 of 7 9. Discover ambiguities or omissions in the following statement of requirements for part of a ticket issuing system: An automatic ticket issuing system sells rail tickets. Users select their destination, and input a credit card and a personal identification number. 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 then requested to input a personal identifier. When the credit transaction has been validated, the ticket is issued. Ambiguities and omissions include:           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 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? Should the system only sell tickets between the station where the machine is situated and direct connections or should it include all possible destinations? What type of input device (touchscreen vs. keyboard)? Ticket prices Room on train (assumes tickets have times on them) Train departure and arrival times. Do customers buy tickets for a specific train? Or for any trip along the route? (If the latter, then no way to tell if all the seats on a train are sold out, nor can you do seat assignments.) Seat assignments (see above) Print receipt?   Answers generally earned two points for each substantial criticism. Page 7 of 7