Project Deliverables CEN 6017 Engineering of Software 2

Project Deliverables CEN 6017 - Engineering of Software 2

Second Semester Deliverables (anticipated) n n n Deliverable #6 – User Interface Design and Revisited Analysis Modeling Deliverable #7 – Layered Architectural Design Deliverable #8 – Detailed Design - Iteration Planning and Use Case Realizations – Context Diagrams only. Deliverable #9 – Subsystem Design – Interaction Diagrams (both) and VOPC diagrams. Deliverable #10 –Class Design and Implementation #1; First Functional Demonstration Deliverable #11 – Final Deliverable: Complete Implementation Model and Demonstration including client testing.

Deliverable 6 due: 1/23/2012 Start of class (present on 1/25) n n Two Key Components 1. Revisiting Analysis Model n n n Use Case Specifications – Revisited Interaction Diagrams – Revisited 2. User Interface

General Details on Deliverable 6 n n Don’t forget peer reviews. This is important. If you cannot be present on the date of the deliverable, give your review (in a sealed envelope) to a team member or physically drop it off in my office prior to class date/time. Peer reviews are due on the date of this deliverable. I will be accessing your deliverable via RTC. More later. We are updating licenses now. Deliverable is to include: n Executive Summary, n Statement of Work, (who is tasked with what) n Revisited Analysis Model – ‘final form’ n n Use Case Specs Interaction Diagrams Traceability statement (more later) via Traceability Matrices User Interface Prototype (details ahead)

1. Details on Revisiting Analysis Model (1 of 2) n n n Ensure: Use Case specifications are to have hyperlinks to the Domain Model or to the definitions sections in your Glossary (domain model preferred). These links are to be relative and must be accessible on my computer. Use Case Specifications are to provide a meaningful level of detail to support follow on design. If these specs are too high level and vague, they are unsatisfactory and will not support an effective design; too low level, and they constrain design. n n All Alternatives and Exceptions are to contain hot links as appropriate, a concluding action (return to Step n or Use-case terminates here), and the complete set of behaviors. There are to be no database references in your use-case specifications unless these refer to an external system.

1. Details on Revisiting Analysis Model (2 of 2) n Interaction Diagrams – Sequence. n Ensure these are correct. Additional example(s) may be found on my web page. (I have eliminated ambiguous examples and have inserted better examples) The use-case specification text should be inserted down the left margin of your sequence diagrams approximately in line with the objects that realize the behaviors to the right. This effort supports traceability. n Ensure control classes are indeed control (orchestrate) and entity classes provide core responsibilities and functionality. (Previous deliverables indicated that there was a real disconnect in understanding what these analysis class behaviors should be. In some cases, entity responsibilities were allocated to control classes. ) Boundary classes are not to be expanded into ‘forms’ or ‘windows’ or anything resembling implementation. Remember, these will likely not morph into design classes.

2. User Interface (1 of 2) n I should be able to access (run through the templates) the UI within your deliverable submitted to me and ‘execute it’ successfully. (you will demo to the class) n n n You must demo the ability to navigate from screen to pursue some scenario from a use case. (I will select a scenario from your use case specs. ) A client should NOT have to hunt and peck and wonder… Recognize that some (a few) of the windows / displays will be / may be hard coded and that demonstrated functionality may not be totally backed up with implemented code or efficient algorithms. But the implied functionality must be clear. This design should contain much more implied functionality than in Deliverable 3.

2. User Interface – (2 of 2) n n This user interface should demonstrate the vast majority of key items of functionality as found in the use cases. In your classroom presentation, you are to demonstrate how your UI satisfies required functionality. Utility and Usability Principles as cited in the lecture slides and your text will be emphasized in evaluation. Verify your UI by ‘running it’ against your use cases to ensure all functionality is captured.