Final Exam Questions Fall03
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Final Exam Questions Fall03

on

  • 384 views

 

Statistics

Views

Total Views
384
Views on SlideShare
384
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Final Exam Questions Fall03 Document Transcript

  • 1. ________________________________ _________________________________ _________________________________ NAME ID SIGNATURE Department of Electrical and Computer Engineering, McGill University ECSE 321 - Introduction to Software Engineering Final Examination December 11, 2003, 2:00pm-5:00pm Examination version 1 Prof. Radu Negulescu Associate examiner: INSTRUCTIONS • Write your name, McGill student ID number, and signature on the cover of the answer booklet and at the top of this page of the questions booklet. Hand in both booklets at the end of the examination. • This examination is closed book, closed notes. Faculty standard calculators are permitted. • Circle one answer only in this questions booklet for each multiple-choice question. Each multiple-choice question has only one correct answer, which earns 2 marks; incorrect answers earn 0 marks or 1 mark (partial credit). No answers or multiple answers selected in a multiple-choice question earn 0 marks for that question. • 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. Good luck!
  • 2. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 2 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.
  • 3. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 3 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.
  • 4. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 4 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.
  • 5. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 5 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.
  • 6. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 6 SECTION II – FULL-ANSWER 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)
  • 7. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 7 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:
  • 8. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 8 - 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:
  • 9. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 9 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.
  • 10. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 10 - 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.
  • 11. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 11 (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)
  • 12. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 12 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.
  • 13. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 13 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]
  • 14. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 14 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
  • 15. ECSE 321 final exam & solutions, Prof. Radu Negulescu, McGill University, Dec. 2002 Page 15 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.