List view
Overview Your product is ready to be released! Most deliverables are final, consistent updates of what was initiated for project part 3. Expectation of new requirements Customers make junk up all the time, it's up to you to decide what to handle. Please document 5 NEW requirements (use-cases, OOA, OOD) and implement 2-3 of them. 3 is good if you have 3 small requirements. 2 Is good if you have a 1 small and 1 large requirements. Talk to your TA to make sure they approve the new requirements you have scheduled. Implement 2-3 requirements, document 5. Deliverables Addressing feedback: Address any TA feedback on the previous project part. Code Base of Prototype: Your final system release will be demonstrated in the lab to evaluate the usability of its user interface and the degree to which its functionality fulfills the user's needs. Built-in help should be complete and consistent with the final user interface and functionality. The source code will be inspected. The code should conform to some consistent coding convention. Deliver the updated source code to your source repository. Code Documentation: For each source file, you should have a brief introductory comment describing its purpose or role within the application or a design pattern, as well as any currently outstanding issues. Provide Javadoc interface document for your model and basic command classes and their public methods (at least). Deliver the updated compiled Javadoc documentation to your source repository. Test Cases: Provide JUnit test cases for your model classes and public methods. The tests should generally pass. Deliver the updated test code to your source repository. If you have test data files, also include those. Requirements Specification: Provide the updated textual use cases and user stories for the application. Object-Oriented Design: Document the structure of your object-oriented design using a UML class diagram (or diagrams), including detail on key attributes and methods. Include notes on the use of design patterns among the classes. The diagram(s) may be reverse engineered from the code, but must be edited, arranged, and selective (not a raw dump). As well, document the behavior of your design for a non-trivial scenario using a UML sequence diagram (e.g., something involving undo/redo and updating of multiple views). The diagrams must be developed using eUML2, and embedded as images in your team wiki. Refactoring: Run the JDeodorant tool for suggesting potential refactorings in your design. Implement the refactorings (as deemed reasonable), and describe the refactorings (done and not done) in a separate page in your team wiki. Planning: Your team's release plans will be inspected. It should be clear from the plans the coverage toward satisfying all the specified requirements, the status of your project, and the work done by the team. You will also plan for the next iteration (which you won't get around to). Reuse Statement: Document instances of software reuse. Give proper credit to the original developers. Obtain approval for the use of third-party libraries as appropriate. Enter this information in your team wiki. Bonus: Video Demo: Upload a video demo of your application to youtube or another video sharing site (or your own hosting) and embed or link to it from the front page of your wiki. This video is meant to promote your application. Max: 5 minutes The evaluation of this project part will also include a component called "relative quality". This is used to differentiate projects that meet the minimum from projects that go "the extra mile".
Due by December 2, 2013•32/32 issues closedThe project description outlines the problem and a set of needs. The entire project has three parts or stages to be delivered. Subsequent parts are generally further refinements of earlier parts, and should address any earlier feedback or concerns. Good work on last milestone. We got 100% and the TA mentioned our wiki as an example to other teams. For next milestone, there are 7 issues.. Just get this stuff done when possible. NOTE: The evaluation of this project part will also include a component called "relative quality". This is used to differentiate projects that meet the minimum from projects that go "the extra mile". NOTE: Updated milestone to reflect extension in time.
Due by November 8, 2013•19/19 issues closedThe project description outlines the problem and a set of needs. The entire project has three parts or stages to be delivered. Subsequent parts are generally further refinements of earlier parts, and should address any earlier feedback or concerns. So.. it looks like most of this stuff goes in the wiki. Just kind of keep each of the 5 issues up to date. We can figure out who's doing what soon enough.
Due by October 22, 2013•6/6 issues closed