Due: Tuesday, May 11 in Distribution Center
|Student ID:||YOUR ID NUMBER|
Effort estimation is the practice of making accurate estimates of how long it will take to complete a piece of work. Software developers are notoriously bad at this. You will practice by estimating how long it takes you to complete a task.
|2||YOUR ESTIMATE||YOUR ACTUAL|
|3||YOUR ESTIMATE||YOUR ACTUAL|
|4||YOUR ESTIMATE||YOUR ACTUAL|
|5||YOUR ESTIMATE||YOUR ACTUAL|
|6||YOUR ESTIMATE||YOUR ACTUAL|
|Total||ESTIMATED TOTAL||ACTUAL TOTAL|
Calculate the error percentage: ((YOUR ACTUAL) - (YOUR ESTIMATE)) / (YOUR ESTIMATE)
TYPE YOUR ERROR PERCENTAGE HERE
A. Describe two types of software product where prototyping would not be useful.
TYPE YOUR ANSWER HERE: 2 PARAGRAPHS
B. Imagine that your team produced a throw-away prototype for a system that will be used inside your company. Your boss sees the prototype and realizes that the system was a bad idea in the first place. He decides to cancel the project and reassign developers to other projects. Is that a successful or failed use of prototyping, and why?
TYPE YOUR ANSWER HERE: 1 PARAGRAPH
Write in the suggested axioms for this algebraic specification of a stack data structure.
Hints: Algebraic specification deal with mathematical equations, not sequences of commands or assignments. You can use nested operations on both sides of the equals sign. You do not need any if-statements for this specification.
A stack is a list where items are both added to and removed from the same end of the list. The operations are:
|New -> Stack||Create a new stack|
|Empty(Stack) -> Boolean||True if the stack is empty|
|Push(Stack, Elem) -> Stack||Pushes an element onto the stack|
|Top(Stack) -> Elem||Return the top-of-stack without removing it|
|Drop(Stack) -> Stack||Remove the top-of-stack and return the modified stack|
|Swap(Stack) -> Stack||Switch the top-most and second-to-top element and return the modified stack, otherwise no effect|
The axioms are:
|Empty(New) = True||A new stack is empty|
|Empty(Push(s, x)) = False||Any stack with anything pushed onto it is not empty|
|Top(New) = Undefined||The top of a new stack is undefined|
|WRITE YOUR AXIOM HERE||The top of the stack is the item most recently pushed|
|WRITE YOUR AXIOM HERE||Dropping an item from a stack that had an item pushed is the same as the stack before the push|
|WRITE YOUR AXIOM HERE||Dropping an item from a new stack is undefined|
|WRITE YOUR AXIOM HERE||The result of swapping a stack with x and y pushed onto it is the same as the stack with y and x pushed.|
|WRITE YOUR AXIOM HERE||Swapping a new stack that had one item, x, pushed onto it should return the same stack with x still there.|
|Swap(New) = New||Swapping a new stack is still a new stack|
Problems 4, 5, and 6 relate to this product: a multi-space parking meter.
Draw a UML class diagram for the design of the multi-space parking meter. Include class names, attributes, and key operations. Show associations with multiplicity and aggregation. Include exactly four classes: Meter, ParkingSpace, Car, and RatePlan. Do not model the DMV, cameras, UCI parking office, parking enforcement officers, or tickets.
USE ArgoUML OR Rational Rose TO MAKE A DIAGRAM, PRINT IT, AND STAPLE IT TO THESE PAGES.
The following decision tree uses headings to consider all combinations of the state of each feature of a parking space and its associated display. Fill in each leaf of the tree with a precise description of the contents of the display for that parking space in the specified situation. Do not leave any description unspecified: if the display is supposed to be blank, write "Blank".
Draw a UML state chart for a parking space and its associated display. Include named states and transitions with events, guard conditions, and actions. Use one UML state for each distinct value in the decision tree above.
USE ArgoUML OR Rational Rose TO MAKE A DIAGRAM, PRINT IT, AND STAPLE IT TO THESE PAGES.sample use case templateexample test plan templateProject plan template