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)
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.

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.
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.

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

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
*
BUnitTeam DepartmentConstraint
array[week] of taskLimit
Allocation
array of week
AllocationCtrl
specifyTaskSet(crtTaskSet)
Allocation allocate()
* *
Company
1
crtTaskSet
allocationResult
*
create
specifyTaskSet
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
sendLogin
sendCommand
1
login
command
*1
create
* 1
*
StudentLog
check(name, ID)
addStudent
deleteStudent
check
1*
StudentInfo
name, ID
hoursLeft
incrementHours()
decrementHours()
crtStudent
1*
1
*
ReservationLog
StudentInfo check(slot)
reserve(slot, student)
unreserve(slot)
check
reserve
unreserve
1*
ReservationSlot
day, time
workStation
StudentInfo check()
setStudent (student)
crtSlot
1*
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 Output
Test # 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.1234
sel.eq.2 Select slot owned by other 1234 38 3/day14 5/day22 res.5678 38 res.5678
sel.eq.3 Select same day 1234 38 3/day14 3/day14 free 38 free
sel.eq.4 Select <24hrs next day 1234 38 3/day14 2/day15 free 38 free
sel.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.1234
sel.bd.2 Select first day 1234 100 1/day0 3/day1 free 99 res.1234
sel.bd.3 Select last day 1234 12 3/day5 3/day100 free 11 res.1234
sel.bd.4 Select first slot 1234 12 3/day5 1/day22 free 11 res.1234
sel.bd.5 Select last slot 1234 12 3/day5 8/day22 free 11 res.1234
sel.bd.6 Select exactly 24h before 1234 12 3/day5 3/day6 free 11 res.1234
sel.bd.7 Select with one hours left 1234 1 3/day14 5/day22 free 0 res.1234
sel.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

More Related Content

What's hot (20)

Similar to Final Exam Solutions Fall02 (20)

More from Radu_Negulescu (14)

Recently uploaded (20)

Final Exam Solutions Fall02