Final Exam Solutions Fall02

________________________________ _________________________________ _________________________________ NAME ID SIGNATURE

Department of Electrical and Computer Engineering, McGill University ECSE 321 - Introduction to Software Engineering

Final Examination

December 12, 2002, 2:00pm-5:00pm

−−−−ANNOTATED SOLUTIONS−−−−

Examination version 1

Prof. Radu Negulescu Associate examiner: INSTRUCTIONS

• Write your name, McGill student ID number, and signature in the following places: the cover of the answer booklet, the computer sheet enclosed, and the top of this page. Fill in the corresponding circles on the computer sheet.

• Write the examination version number from the box above to the computer sheet enclosed, and fill in the

corresponding circle.

• This examination consists of two sections: section I consists of 15 multiple-choice questions; section II consists of 4 essay-type questions. Section I is worth 30 marks in total; section II is worth 135 marks in total. The multiple-choice questions are equally weighted; invalid or omitted answers are worth 0 marks. Question 4 of section II offers a choice of two parts, of which you should attempt only one part.

• Use pencil only to fill your answers to the multiple-choice questions in the enclosed computer sheet.

• Write your answers to the essay-type questions in the separate answer booklet provided. Draw a diagonal

line over each scratch sheet in the answer booklet; scratch sheets will not be marked.

• This examination booklet has 8 pages, including this page. Keep all pages together. Good luck!

SECTION I – MULTIPLE-CHOICE QUESTOINS

USE PENCIL ONLY TO FILL ANSWERS IN THE COMPUTER SHEET

EACH VALID ANSWER GETS 2 MARKS, EACH INVALID OR OMITTED ANSWER GETS 0 MARKS Question 1. Consider the following requirement for a spreadsheet program: “The product shall not offer search and replace options that could have disastruous results.” This requirement is flawed mainly because:

(a) It is not feasible. (b) It has implementation bias. (c) It says what the product shall not do instead of what the product shall do. (d) It is ambiguous. (e) No specific reason.

Question 2. Consider a system consisting of a client module that passes flags to server modules to indicate which operations should be performed by the server modules. This system has:

(a) Unacceptably loose coupling. (b) Unacceptably weak cohesion. (c) Unacceptably tight coupling. (d) Unacceptably strong cohesion. (e) Acceptable but not perfect cohesion and coupling.

Question 3. Which of the following statements is true?

(a) There is no need to insert breakpoints at every line of code because the “step over” debugger function can achieve the same effect more easily.

(b) Good programmers don’t need to use advanced debugger features for increased efficiency if they use assertions to think about the code.

(c) Good programmers don’t need to use assertions to think about code if they know how to use powerful debugger features.

(d) All of the above. (e) None of the above.

Question 4. An advantage of sandwich testing over modified sandwich testing is:

(a) Sandwich testing has more coverage. (b) Sandwich testing has fewer test cases. (c) Sandwich testing has fewer test drivers. (d) Sandwich testing has fewer precedence dependencies between test cases. (as shown during the lectures) (e) None of the above.

Question 5. An advantage of active design reviews versus Fagan inspections is:

(a) Reducing the number of meetings needed. (b) Helping the author to fix the defects found by suggesting how to fix the defects. ((b) is wrong because Parnas’s “active design reviews” are a type of inspection) (c) A better use of reviewer time by eliminating the general meeting. (d) All of the above.

(e) None of the above. Question 6. The MAIN benefit of performing unit testing before integration or system testing in a large project with high quality requirements is:

(a) To save effort in locating defects. (true, but not nearly the most compelling benefit) (b) To save effort in finding failures by easier targeting of test cases to coverage criteria for individual units. (c) To satisfy the customer requirements. (those would be covered by system tests) (d) To disseminate the corporate culture. (e) All of the above.

Question 7. Which of the following prototypes is LEAST likely to be needed for clarifying the non-functional requirements of the software controller for a cellular phone:

(a) A prototype for reception of signals from the phone branch exchange. (b) A prototype for transmission of signals to the phone branch exchange. (c) A prototype for performance tuning using calibrated stubs. (d) A broad prototype, including transmission, reception, and user interface. (“spike solutions”…) (e) A user interface mock-up with the capability of collecting usage statistics.

Question 8. Which of the following statements is true for nearly all software development projects:

(a) Unit testing must be completed before integration testing can start. (unit testing overlaps integration) (b) There should be a high-level architecture phase. (not in XP) (c) Every non-functional requirement must be tested. (d) Modified sandwich testing is the best integration testing strategy. (e) All of the above.

Question 9. Which of the following statements makes inadequate use of the terms process, project, or product:

(a) My web-based project has sub-second response time. (b) The process in our company is quality-oriented. (c) Our product has high reliability. (d) Software projects tend to progress more slowly as they get closer to the release deadline. (e) None of the above.

Question 10. Which of the following statements is a reasonable assumption for a typical software project:

(a) The probability of failure-free operation is the mean time to failure. (b) The mean time to failure in using a feature is proportional with the number of defects in that feature. (c) The mean time to failure in using a feature is inversely proportional with the number of defects in that

feature. (d) All of the above. (e) None of the above.

Question 11. Which of the following process models is LEAST adequate for implementing the software for an embedded safety belt controller, and what is a reason for the inadequacy:

(a) The waterfall model, because the requirements are not well understood. (b) The spiral model, because there are no major risks involved. (c) The V model, because very few tests need to be carried out. (d) The prototyping model, because there is no need for prototypes in this project. (e) The incremental and iterative model, because the controller function cannot be easily split into

increments. Question 12. Which of the following process models is MOST adequate for starting a new business in network server firewalls together with your friends, and why:

(a) The V model, because it allows more parallelism in development than waterfall. (b) Extreme programming, because it does not have a high-level architecture phase.(close choice, but very bad reason

- actually this is a reason why XP is probably not the wisest choice for a project that requires well-thought design of uniform security policies at the system/architecture level)

(c) The prototyping model, because requirements are not well understood beforehand. (d) The sharktooth model, because it includes demos of prototypes to the management. (e) The waterfall model, because requirements analysis needs to be performed before writing code.

Question 13. Which of the following can NOT be a review criterion for high-level design:

(a) Feasibility. (b) Checking whether the static data models are consistent with scenarios of normal usage. (c) Checking whether the static data models are consistent with scenarios of user errors. (d) Absence of implementation bias. (design is always implementation-biased) (e) Security properties.

Question 14. Which of the following statements is FALSE:

(a) Cyclomatic complexity gives the exact number of test cases needed for complete branch coverage. (b) An upper bound for the minimum number of test cases needed for complete branch coverage can be

computed by counting certain keywords in a piece of code. (c) An upper bound for the minimum number of test cases needed for complete statement coverage can be

computed by counting certain keywords in a piece of code. (d) If N is the number of nodes and E the number of edges in a flow graph, the cyclomatic complexity of that

flow graph is N – E + 2. (e) The cyclomatic complexity of a flow graph is independent of the inclusion or exclusion of nodes for

assignment statements in the flow graph.

Question 15. Consider the following Java method, whose flow graph is shown below: public static int getNumDaysInMonth(int month, int year) throws MonthOutOfBounds, YearOutOfBounds { int numDays; if (year < 1) { throw new YearOutOfBounds(year); } if (month == 1 || month == 3 || month == 5 || month == 7 || month == 10 || month == 12) { numDays = 32; } else if (month == 4 || month == 6 || month == 9 || month == 11) { numDays = 30; } else if (month == 2) { if (isLeapYear(year)) { numDays = 29; } else { numDays = 28; } } else { throw new MonthOutOfBounds(month); } return numDays; }

[ y e a r < 1 ]

[ m o n t h i n ( 1 , 3 , 5 , 7 , 1 0 , 1 2 ) ] n = 3 2

t h r o w 2 n = 2 9

r e t u r n

t h r o w 1

n = 2 8

n = 3 0 [ m o n t h i n ( 4 , 6 , 9 , 1 1 ) ]

[ m o n t h = = 2 ] [ l e a p ( y e a r ) ]

The minimum number of test cases needed for complete STATEMENT coverage of the method above is:

(a) 14 (the right answer for branch coverage) (b) 6 (the right answer for statement coverage) (c) 5 (d) 4 (e) None of the above.

SECTION II – ESSAY-TYPE QUESTIONS

WRITE YOUR ANSWERS IN THE ANSWER BOOKLET

Question 1. (requirements, modeling, testing)

You are developing the software controller for a vending machine that makes coffee. The machine has a slot for inserting coins, a button for change return, and three buttons for selecting the coffee: Espresso, Cappuccino, and Latte. The machine also has a boiler and a nozzle for delivering the coffee, an output slot for returning the change, and a display for displaying the status of the interaction with the user: amount of money received, steps of making the coffee, error messages, etc.

The vending machine operates as follows. The customer inserts coins up to the amount of $1.25, which is the price of a cup of coffee. The machine accepts only quarters and one-dollar coins (loonies). If the amount is exceeded or the coins have the wrong values, the extra coins are immediately returned. For example, if two one-dollar coins are inserted consecutively, the second coin is returned; if six quarters are inserted, the sixth is returned. Immediately following the insertion of each coin, the display confirms the total amount of money received so far. In parallel, the customer selects the coffee desired. If the selection is made after the full amount is inserted, the vending machine makes the coffee and delivers it through the nozzle. If the change return button is pressed before the coffee is made, the money is returned. Throughout the operation cycle, the display is used to acknowledge each user action by indicating the status of the interaction. After the coffee is delivered, the vending machine repeats the operation cycle above.

The controller of the vending machine senses and actuates the hardware by invoking methods of a hardware driver object, as follows:

• coinInserted(int coin) executes on each insertion of a coin, with parameter coin set to 25 for a quarter and 100 for a loonie;

• changeButtonPressed() executes on each push of the change return button;

• selectionButtonPressed(String choice) executes on each push of a coffee selection button, with parameter choice set to “Espresso”, “Cappuccino”, or “Latte”, indicating which button has been pressed;

• display(String message) outputs the message string on the display;

• makeCoffee(String choice) activates the boiler and nozzle to deliver the coffee according to the value of parameter choice;

• returnCoin(int coin) returns a quarter if parameter coin is 25 and a loonie if coin is 100.

The controller for the vending machine has to be developed according to the DEFENSIVE PROGRAMMING paradigm.

(a) Draw a use case diagram for the vending machine controller. Be sure to identify all the main use cases, actors, and their relationships. [5 marks]

(b) Draw a state chart describing the behavior of the controller as seen at the interface between the controller and the hardware driver object, i.e., in terms of invocations of the methods above. Use nesting and concurrency to simplify the state chart. [20 marks]

(c) Specify a set of test cases that ensures complete transition coverage of the state chart in Part (b). [10 marks]

(d) Briefly explain the main reasons for and against using complete transition coverage of a hierarchical state chart as the coverage criterion for testing the vending machine controller (no more than 3 reasons total, one sentence each). [5 marks]

(a)

Coffee selector

Money insert

Coffee output

Make coffee

Refund change on request

Refund extra change

<<extends>>

<<extends>>

Display watcher

(b)

cBP() /rC(25),

rC(100)

cI(25)/rC(25),d(25)cI(100)/rC(100),d(100)

SelectCoffee

on entry: d(“Cap. selected”)

on entry: d(“Lat. selected”)

on entry: d(“Esp. selected”)

on entry: d(“Please select coffee”)

sBP(“Cap.”)

sBP(“Esp.”)

sBP(“Lat.”)

on entry: d(0)

cI(100)/d(100)

cI(25)./d(125)

InsertChange

cI(100)/ rC(100), d(50)

cI(25)/d(75)

/ mC(“Cap.”)

/ mC(“Esp.”)

/ mC(“Lat.”)

on entry: d(“Making Cap.”)

on entry: d(“Making Esp.”)

on entry: d(“Making Lat.”)

MakingCoffee

cBP() / d(“Refund expired”) cI(25) / rC(25), d(0)

cI(100) / rC(100), d(0) sBP(anyString) / d(“Please wait”)

H

after 2 seconds

on entry: d(“Thanks!”)

cI(25)/d(50)

cI(25)/d(25)

cI(100)/d(125)

cBP()

cBP()/rC(25)

cBP()/ rC(25),rC(25)

cBP()/rC(25), rC(25),rC(25)

cBP() /rC(100)

cI(100)/d(100)

cI(100)/ rC(100), d(75)

cI(100)/rC(100),d(125) cI(25)/rC(25),d(125)

cI(100)/ rC(100), d(100)

Notes: - The “Thanks” note and “after 2 sec” transition at the end of the cycle are not marked, but the need for them could be inferred from the requirement to display the status of the interaction - specifically, the need to inform the user that the cycle has been completed. - The history pseudostate, marked (H), means that re-entry to the “Making Coffee” superstate is through the last visited substate, or to the “Thanks” state if this si the first entry. Use of the history pseudostate is off the scope of the exam and therefore not marked; the solution can be completed without a history pseudostate, by moving the self-loop from Making Coffee to the substates of Making Coffee and replacing the (H) by a usual initial state.

(c) Test insertions: insert the required amount in the three possible ways cI(100); d(100); cI(25); d(125) cI(25); d(25); cI(100); d(125); cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(25); d(125); Test change return on request: go to each state, request return cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(25); d(125); cBP(); rC(100); rC(25); d(0) cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cBP(); rC(100); d(0) cI(25); d(25); cI(25); d(50); cI(25); d(75); cBP(); rC(25); rC(25); rC(25); d(0) cI(25); d(25); cI(25); d(50); cBP(); rC(25); rC(25); d(0) cI(25); d(25); cBP(); rC(25); d(0) Test extra change return: go to 4 states, insert a loonie, get it back; go to last state, insert a quarter, get it back cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(25); d(125); cI(100); rC(100); d(125) cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(100); rC(100); d(100) cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(100); rC(100); d(75) cI(25); d(25); cI(25); d(50); cI(100); rC(100); d(50) cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(25); d(125); cI(25); rC(25); d(125) Test coffee making: sBP(“Cap.”); d(“Cap.”); cI(100); d(100); cI(25); d(125); mC(“Cap”); d(“making Cap.”); d(“Thanks”) sBP(“Esp.”); d(“Esp.”); cI(100); d(100); cI(25); d(125); mC(“Cap”); d(“making Esp.”); d(“Thanks”) sBP(“Lat.”); d(“Lat.”); cI(100); d(100); cI(25); d(125); mC(“Lat”); d(“making Lat.”); d(“Thanks”) Test invalid user actions during coffee making: sBP(“Cap.”) d(“Cap.”) cI(100) d(100) cI(25) d(125) mC(“Cap”) d(“making Cap.”) cPB() d(“Refund expired”) sBP(“Cap.”) d(“Cap.”) cI(100) d(100) cI(25) d(125) mC(“Cap”) d(“making Cap.”) cI(25) rC(25) d(0) sBP(“Cap.”) d(“Cap.”) cI(100) d(100) cI(25) d(125) mC(“Cap”) d(“making Cap.”) cI(100) rC(100) d(0) sBP(“Cap.”) d(“Cap.”) cI(100) d(100) cI(25) d(125) mC(“Cap”) d(“making Cap.”) sBP(anyString) d(“Pls. wait”) (d) Reasons for: - avoids explosion of the number of test cases by avoiding explosion of the number of states and transitions - test cases (targeted to nested/concurrent superstate transitions) map well to independent functional requirements Reasons against: - does not target boundary cases (such as requesting change refund with no credit) which have a rich concentration of defects - does not cover all combinations of concurrent states / interleavings of threads of control, which may trigger desirable events (such as making Cappuccino coffee) as well as undesirable events - does not target internal states and transitions (a black-box rather than structural technique) - such test cases might be difficult to run if they rely on relative timing of the user and multiple threads of control

Marking: Any two of the above will do.

Question 2. (design)

You are developing a task management program for a company. The program allocates the company staff to tasks in a way that satisfies the workload constraints of every person in the staff. Each person has constraints on the maximum number of tasks that person can perform at any given time, and this number may vary every week. Tasks may contain sub-tasks, but a sub-task cannot be part of several tasks. Staff is grouped in teams; teams are grouped in departments; departments are grouped in business units. Teams may overlap, i.e., the same person can be a member of several teams. Department and business units may overlap, too.

Draw the class diagram for a high-level design model of the task management program. Discuss your main design decisions with respect to the modularity / performance tradeoff (bulleted list form, maximum 5 decisions, maximum 3 lines of explanation per decision). Hint: try to achieve a simpler design by offering a more uniform functionality (as discussed during the design lectures). [30 marks]

TaskEntry

UI

*

BasicTask

CompositeTask

0..1

GroupEntry

*

Person

Group

*

BUnit

Team

Department

Constraintarray[week] of taskLimit

Allocationarray of week

AllocationCtrl

specifyTaskSet(crtTaskSet) Allocation allocate()

*

*

Company

1 crtTaskSet

allocationResult *

createspecifyTaskSet

allocate*1

1

*

1

1

1

*

Design decisions: 1. Use the Composite pattern to represent tasks: - Decouples handling of basic tasks from maintaining lists of tasks. - Blends well with the needs of inputting a task set. - Little or no performance cost – traverse just one reference to go through a level of the task tree. 2. Use the Composite pattern to generalize the company hierarchy structure. - It is a more uniform design than a specific department structure – easier to develop, test, extend. - Little or no performance cost – just one reference to go through a level of the groups hierarchy. 3. Allow allocation of hierarchical tasks to hierarchical groups instead of individual persons. - More functionality for no extra complexity.

4. One control object for each allocation: - Easy to maintain by decoupling consecutive allocations; e.g.threading can be done with minimal impact. - Costs for creation and destruction of objects.

Note:

Any good solution to this question should abstract the similarities of team, department, business unit, into a superclass (“group”). The decoupling tradeoffs discussed during the first lecture on patterns naturally lead to the composite pattern, which allows any number of levels of the hierarchy. Therefore any good solution offers slightly more functionality with a simpler and more uniform design! A simpler, more uniform design is easier to code, test, maintain, etc. Such is the essence of good software design.

Question 3. (analysis, assertions, testing)

You are developing a web-based reservation system for a university computer laboratory. The system maintains a daily reservation schedule that consists of 8 one-hour time slots for each workstation in the laboratory. Each semester, each student can reserve up to 100 time slots on individual laboratory workstations. The reservations can be made or retracted at least one day in advance, at any time. To make or retract a reservation, a student accesses the URL of the reservation system, logs in using his or her name and ID, and selects or deselects slots by clicking on the slots in the schedule. On login, the system shows the number of remaining hours to be reserved by the respective student; that number decrements on each selection and increments on each deselection. A student can only deselect slots that are currently reserved by that student, and can only select slots that are not currently reserved by any student.

(a) Draw a class diagram for an analysis model of the web-based reservation system. [10 marks]

(b) Assuming the design-by-contract paradigm is used at the user interface of the reservation system, specify the pre- and post-conditions for selecting a time slot and for de-selecting a time slot. [10 marks]

(c) Assuming the defensive programming paradigm is used at the user interface of the reservation system, specify the pre- and post-conditions for selecting a time slot and for de-selecting a time slot. [10 marks]

(d) Assume the system stores references to students who made the reservations, indexed by time slot and workstation number, or null references for free slots; and, the system stores the remaining number of hours for each student. Specify the invariants on the data structure of the reservation system. [10 marks]

(e) Derive a comprehensive set of black-box tests for the operations of selecting and deselecting time slots described above. [10 marks]

NOTE: Each of the assertions in Question 3 (b), (c), (d) (or (a) if needed) may be specified using mathematical logic, OCL, unambiguous natural language, or combinations thereof.

(a)

Constraint: forall StudentInfo s: s.hoursLeft + #{slot: slot.student = s} = 100

serverObject URLAccessed

ReservationCtrl

login(name, ID) select(crtSlot) deselect(crtSlot)

create*1

ClientUIForm display mouseClicked

sendLoginsendCommand

1

logincommand

*1

create * 1

*

StudentLog check(name, ID) addStudent deleteStudent

check1*

StudentInfo name, ID hoursLeft incrementHours() decrementHours()

crtStudent1*

1

*

ReservationLog StudentInfo check(slot) reserve(slot, student) unreserve(slot)

checkreserve

unreserve1*

ReservationSlotday, time workStationStudentInfo check() setStudent (student)

crtSlot1*

1

*

0..1

0..100

Timer day time getCrtTime

getCrtTime 1 *

if (timer.getCrtTime is at least one day before time and reservationLog.check(slot) indicates a free slot and crtStudent.getHoursLeft > 0) crtSlot.setStudent(crtStudent) crtStudent.decrementHours() // else, do nothing

if (timer.getCrtTime is at least one day before time and reservationLog.check(slot) == crtStudent) crtSlot.setStudent(free/null) crtStudent.incrementHours() // else, do nothing

(b) – design by contract Select: Pre: crtStudent.hoursLeft > 0 && crtSlot.student == null && time – getCrtTime >= 1 day (&& in-range studentID, reservation day, reservation time slot, workstation number) Post: crtSlot.student' == crtStudent && crtStudent.hoursLeft' = crtStudent.hoursLeft – 1 Deselect: similar Marking: Select: Pre: check hours credit / 1, free slot / 1, current time / 1; Post: make reservation / 1, update hours / 1 Deselect: Pre: check owned slot / 2, current time / 1; Post: undo reservation / 1, update hours / 1 (c) – defensive programming Select: Pre: crtStudent.hoursLeft > 0 && crtSlot.student == null && time – getCrtTime >= 1 day (&& in-range studentID, reservation day, reservation time slot, workstation number)

Post: if crtSlot.student' == crtStudent && crtStudent.hoursLeft' = crtStudent.hoursLeft – 1 else crtSlot.student' == crtSlot.student && crtStudent.hoursLeft' = crtStudent.hoursLeft in words, if pre is satisfied then the results are correct; if pre is not satisfied then do no updates. OR, equivalently, Pre: none (defensive programming) Post: if (crtStudent.hoursLeft > 0 && crtSlot.student == null && time – getCrtTime >= 1 day) crtSlot.student' == crtStudent && crtStudent.hoursLeft' = crtStudent.hoursLeft – 1 else crtSlot.student' == crtSlot.student && crtStudent.hoursLeft' = crtStudent.hoursLeft Deselect: similar (d) – invariants TOTAL HOURS = 100 / 5 marks forall students s: s.hoursLeft + #slots reserved by s == 100 LIMITS / 3 marks forall students s: s.hoursLeft is in 0..100; and #slots reserved by s is in 0..100 OTHER / 2 marks – at least one from the list forall reservation slots r: r.student is either a the reference of a student object or equal to the null reference unique ID for each student unique workstation ID limits on the # of slots etc. (e) – black-box tests Assumptions: - Since selection/deselection is done by clicking on a posted schedule, only in-range days, timeslots and workstation numbers are tested. - Since selection/deselection follows login, only valid student IDs are tested.

Input OutputTest # Description studentID hrsLeft time-crt time-slot slot status hrsLeft slot status

sel.eq.1 Select free slot 1234 38 3/day14 5/day22 free 37 res.1234sel.eq.2 Select slot owned by other 1234 38 3/day14 5/day22 res.5678 38 res.5678sel.eq.3 Select same day 1234 38 3/day14 3/day14 free 38 freesel.eq.4 Select <24hrs next day 1234 38 3/day14 2/day15 free 38 freesel.eq.5 Select with no hours left 1234 0 3/day14 5/day22 free 0 free

sel.bd.1 Select slot owned by oneself 1234 38 3/day14 5/day22 res.1234 38 res.1234sel.bd.2 Select first day 1234 100 1/day0 3/day1 free 99 res.1234sel.bd.3 Select last day 1234 12 3/day5 3/day100 free 11 res.1234sel.bd.4 Select first slot 1234 12 3/day5 1/day22 free 11 res.1234sel.bd.5 Select last slot 1234 12 3/day5 8/day22 free 11 res.1234sel.bd.6 Select exactly 24h before 1234 12 3/day5 3/day6 free 11 res.1234sel.bd.7 Select with one hours left 1234 1 3/day14 5/day22 free 0 res.1234sel.bd.8 Select with all hours left 1234 100 3/day14 5/day22 free 99 res.1234

EQUIVALENCE TESTS - SELECT OPERATION

BOUNDARY TESTS - SELECT OPERATION

Deselect test cases: similar Notes: - It is very important to give specific numbers for inputs and expected outputs, to reproduce the tests and failures. - Other good test cases might be: Select and deselect a slot immediately, and with some other operations in between. Click outside schedule, on the table border, on a border between two slots.

Question 4.

This question has two parts, of which only one will be marked: either the whole of Part A only, or the whole of Part B only. To obtain credit, indicate clearly in the answer booklet which part you want marked. PART A. (guest lecture)

(a) Give two specific examples of dangers entailed when code with inadequate speed optimizations is installed on a different platform. [5 marks]

(b) Give two examples of programming guidelines that will help avoid the dangers above. Be sure to actually indicate how following the guidelines will avoid the specific dangers mentioned (one sentence per guideline). [5 marks]

(c) Briefly explain three main advantages of choosing software engineering as a career, and two main challenges that arise in practicing software engineering in the industry (one sentence each). [5 marks]

PART B. (reliability)

Estimate the initial number of faults and the number of defects on release for a software project whose number of faults found per week of quality assurance is as plotted in Figure 1. Assume the software is released on week 15. Assume an exponential reliability growth model as shown by the “interpolated” curve. Show your work by indicating the basis for your calculations. [15 marks]

QA week # (normalized) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Faults found (log scale)

interpolated 101

102

103

100

Figure 1. Number of faults found during each week of quality assurance in a software project. Part A. (a) Dangers (based on guest lecture - many variations are accepted): (1) Segmentation fault when a routine marks the end of the loop by overwriting protected memory used for input. (2) Unpredictable hardware effects when a routine demarcates input data by overwriting I/O mapped memory used for input. (b) Guidelines (many variations are accepted): (1) Write for people, not for machine: keep code simple, standard style. (2) Document preconditions; include any assumptions regarding pointers to writable memory. This will make compulsory that clients of the routine do not pass pointers to protected or I/O mapped memory for memory areas that need to be writable. (3) Keep right attitude: don’t just be happy when code seems to work, but be sure you know why/how it works; step through new code at least once; this will reduce exposure if the problems above are in someone else’s code (4) Turn on all compiler warnings: writing outside memory may be flagged as such (c) Advantages (any 3 will do): - portable profession: can apply it in a wide range of industries, geographical areas, etc. - wide range of applications: potential of being helpful for diverse types of problems: commercial, medical, etc. - shorter completion cycles: get to see your creations deployed and used - closeness to application: deal with concepts from the problem domain rather than 0/1 abstractions Challenges (any 2 will do): - working with or reporting to non-technical people: frictions due to different expectations and attitudes - dealing with legacy code: hampered by incomplete understanding, bad coding practices of the past - geographical and cultural boundaries: development of a system is distributed around the world

Part B. Let: N0 = initial number of faults Nrelease = number of faults on release N(t) = number of faults at time t W(t) = faults found during week t From model: W(t) = N0 f(t) = N0 f0 e^(-t f0) => log_10(W(t)) = log_10 (N0 f0) – f0 t / 2.3 => f0 / 2.3 = slope of W(t) line on log scale = 1.5 / 15 = 0.1 => f0 = 0.23 / 5 Also from model: N(t) = N0 (1 – F(t)) = N0 e^(-t * f0) = W(t) / f0 N0 = N(0) = W(0) / f0 =~ 10^2.5 / 0.23 =~ 1375 / 5 Nrelease = N(15) = W(15) / f0 =~ 10 / 0.23 =~ 43 / 5 Notes: - Sanity check: The sum of the number of defects found each week should be N(0) - N(15) = 1332. The actual sum is approximately 2500 – close enough for a ballpark estimate. - In practice, reconcile the estimates: eliminate the garbled points and/or adjust the interpolation until they agree, as in Figure 2 - On the new estimates, f0 = 2.3 * 2/15 = 0.3; N0 = W(0)/f0 = 1000/0.3 = 3333; Nrelease = 10/0.3 = 33. Although N0 changes a lot (2.5x), Nrelease stays close to the original estimate (23%), so the method is pretty good at finding the number of defects on release.

QA week # (normalized) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Faults found (log scale)

interpolated 101

102

103

100

Figure 2. Adjusted interpolation.

Final Exam Solutions Fall02

Technology

Transcript of Final Exam Solutions Fall02