SE361 Project Deliverables

Notes on Project Deliverables (unless otherwise directed by your instructor)

• Team Project Deliverables are due noon the day before the session indicated on the schedule.
• If your classes are Mon-Wed, deliverables are due noon on Sunday, Tues-Thurs classes are due noon on Monday.

· Your instructor will clarify the format and manner in which project deliverables are submitted (e.g. via dropbox, Wiki or other)

Note: the instructions below may refer to the use of a Wiki as the project delivery mechanism. However, if your section is not using Wikis, then you shall still comply with the deliverables but instead use the mechanism defined by your instructor.

Weekly Status

The team must is responsible for keeping the project on track. To support this, the team is required to submit the following on a weekly basis:

1. Activity Tracker (submitted as directed by your instructor) with all identified weekly project deliverables/status/effort and Scheduled tasks for the upcoming week. Reference project specific artifacts- “Update test plan to include test cases for credit card payments (Frank & Edit; estimated 4hrs)” not just “product” related work. Note that whenever a task is created, it should be assigned to a specific team member(s) and the estimation should be made by them as to how much effort that item will require. Refer to the “Instructions” tab on the spreadsheet for more info. Update the tracker incrementally over the course of the week as tasks get completed and assigned instead of trying to recall everything that happened in the minutes before the report is due.
2. Outstanding issues (risks) regarding the project in terms of release scheduling, personnel, computing resources, etc. to be recorded under your team’s Wiki. Create a section at the top of the “Project Planning” page and label it “Risks/Issues” and make sure to keep this list updated.  Projects typically track “risks” or detrimental things that might occur – “Half the team will be away the weekend before Release 1, this will impact integration and testing efforts”. Each risk must record a “mitigation” plan that when executed minimizes the impact of that issue on the project- “Hold an integration session on Thursday, remaining team members will complete testing over the weekend, absent members available via phone.” When applicable it may be helpful to assign the risk to a particular individual to ensure that it gets resolved. For these items you should add them to your Activity Tracker as they will require effort.
3. Status Report  to be recorded under your team’s Wiki “Project Planning”.  Status reports need not be verbose, a list of bulleted items is sufficient. They essentially are a common sense set of accomplishments or salient issues. For the same reasons as above, you should update the report incrementally as well. For each Status Report create a separate section with the Week number the status pertains to (i.e. “WEEK 1”, “WEEK 2” , etc.). For readability, keep the latest week at the top of the document that way you will not have to scroll down to find the most current information.

Week 2

Project Delivery mechanism or Wiki Operational

• Each team member verifies they can access and edit the project team wiki.
• In the Project Planning page for your team, update the page to include each team member’s:
• Name
• RIT email address
• Role on the project
• Optionally you may also want to use this area to post alternate contact (screen name, etc.) or scheduling constraints for each team member.
• Create an initial status report that includes risks (and potential mitigation plans) that may impact your project.
• Your instructor will post a comment on the Project Planning page as feedback.

Review the project’s Statement of Needs document

Week 3

Initial Project Plan (Project Plan document)

• List the planned features for each release, use the same feature name as defined in the Requirements Document
• Include any notes that help to clarify why features are included in each release, or if parts of the same feature are being split between releases.

Initial Requirements Document (Requirements document)

• Identify the stakeholders of your product.
• Identify each feature by a unique identifier (i.e. “Place Order”) you can reference consistently in status reports and other project artifacts.
• Describe each feature in 2-3 sentences.
• Draw a UML use case context diagram of your system.
• Write the UML use case for the highest priority feature for Release 1. Verify the use case you are writing with your instructor. Apply the use case format used in the class requirements activity. Be sure to account for all known alternate scenarios in addition to the success scenario.

Week 4

Initial Test Plan (Test Plan document)

• Create a Test Plan (based on the template above) and containing the information given below
• Write an acceptance test case for each of the features being delivered in Release 1.
• Test cases for the Place Order use case should cover both success and alternate scenarios.
• At minimum, your test case should reference the feature being tested; pre-conditions required to run the test, a test case description and expected results.

Design Document (Design document)

• Create a Design Document (based on the template above) with the following sections
• Section 1 : Descriptions for each class including the state (attributes) it maintains and the behavior it is responsible for
• Section 2 : UML class diagram capturing the relationships between classes. It is only necessary to show methods that are publically accessible by other classes. Only show an instance variable of a class if it is publically accessible.
• Section 3 : UML sequence diagram for the Place Order use case
• Section 4 : Design Notes – A running list of issues that arise as your design process proceeds. This is an important section of the design document as it captures the thought process of the product’s designers. It includes why or why not (rejected solutions) a design decision was made and supports future changes to the product. It should be updated whenever a design change occurs.

Week 5

Document Updates

• In addition to your weekly status, your instructor will identify any updates which need to be made.

Week 6

Release 1 – Project Deliverables (Your instructor will clarify how to submit your R1 deliverables)

• Up-to-date requirements, test plan and design documents. Where the design is consistent with the requirements and the code is consistent with the design. .
• The product and test source code for the release.
• Command Line Interface to the System. (Graphical User Interace is part of R2).
• Executed acceptance test cases for each delivered feature with color coded cells and comments under the corresponding release column.
• JUnit test cases for each class.
• Screen image file(s) [JPG or PNG format] with properly labeled mockups/graphics/screenshots of your products GUI concepts or prototype.

* Unless directed by your instructor to follow a different mechanism, submit the Word and Excel versions of all release documents/artifacts pertaining to this release into the repository and tag them with: “Release-1”

Release 1 – Presentation

• This is a technical presentation to other engineers in the company, as such, focus on the planning, design, construction, and testing approaches you used. In particular, present (using diagrams or graphs) the conceptual design and discuss how you tested it.
• The amount of time for each team may depend on the number of teams in the section; typically each team should plan on 10-12 minutes for the presentation (including any demo) and 5 minutes for questions.
• It is good idea to have few slides to talk off that include an agenda of topics to be covered.
• Every team member will participate in a significant way in the presentation.
• Give a short product demo of features you have completed (note that none of the project GUI components need to be shown for this release)

Release 1 - Reflection

• Prepare the team reflection report for next class and submit it has directed by your instructor. Part of the next class will be devoted to discussing the project so far with each team.
• Be prepared to discuss with your instructor the status of your project, what is working and what is problematical, and any other issues related to the project's successful completion.
• Each team member is to prepare a peer evaluation for all the members by the end of the day tomorrow. To do this follow the Peer2Peer link on the myCourses home page to find and complete the peer evaluation survey.

Week 7

Release 2 Planning

• Update your project documents (Planning, Requirements, Test and Design) to reflect your plans for the product’s second release (R2).
• R2 is an extension of your existing R1 functionality. The initial overhead will not be as significant as in R1.
• R2 should initiate the development of a graphical user interface.
• Build on your experience with R1 when estimating the R2 effort.
• At the end of Week 8 your team will produce a Beta Release of your product to be tested externally by another team in the class during Week 9. Prioritize your development so that you produce a functional version of your product by Week 8. It is OK to have missing or partial functionality at that point so long as it is properly identified at the time of the release. This is a good opportunity for your team to receive constructive feedback prior to the final release in Week 10.

Week 8

Inspection Report

Submit team inspection reports as directed by your instructor.

R2 Beta Release

Each team must prepare a release for cross-team testing - that is, for testing by one of the other teams in its section. To do so, each team will create a minimal web site in the team account's public_html directory. This is how your final release will be deployed, so it is a good time to test not only your application, but your deployment procedure as well.

First make sure this release is checked in to your repository and properly tagged.

* Unless directed by your instructor to follow a different mechanism, submit the Word and Excel versions of all release documents/artifacts pertaining to this release into the repository and tag them with: “Release-2beta”

Now, assuming the team account is team x361-yyy, the contents of public_html are accessible to a browser using the URL http://www.se.rit.edu/~x361-yyy/. In this directory you will place the following items for use by the test team:

1. An executable JAR (Java ARchive) file with the executable version of your product (Eclipse has commands to help you build this file).

2. A copy of your acceptance test plan document

3. A copy of your requirements document

4. A README.txt text file with:

a. Release notes - bugs you know of, any limitations, etc.

b. The names of the other files in public_html (the jar file, the requirements, and the acceptance test).

c. Instructions on how to use the software (this may be as simple as java file.jar).

d. Note that if your application requires additional components (database support, etc.) you need to provide instructions on how to install them as well.

e. The name and email address of one of your team members who will act as test liaison (responding to queries, perhaps helping the team directly). This person must be available over the coming weekend, and must check his or her email account frequently to respond to support requests from the test team.

Your team must ensure that the jar file and documents can indeed by downloaded by the other team. A frequent problem is incorrect permissions, which keeps the Apache web server from accessing the directories and files. The following commands, executed in the team's account home directory, should set the permissions adequately:

chmod a+rx public_html

chmod a+r public_html/*

Week 9

Cross Team Testing

• Teams execute the test plans of their testing partners and return the results of the test plan, along with any additional tests by Session 2 of Week 9.
• Minimally each team should complete the test plan supplied and add 2-3 additional test cases.
• Teams should indicate in their test plans what test cases are not yet supported.
• Also submit the test plan as directed by your instructor. Include at the bottom of the test plan any notes on what worked, what didn't, and any problems encountered.

Software Engineering Freshman Seminar Testing (Fall Quarter Only)

• In addition to cross-team testing, your Beta Release will also be tested during Week 9 by the current SE Freshman Seminar (SE101) class.
• Your instructors will solicit SE361 teams to attend the SE101 class to observe the execution of your test plan and offer technical assistance as needed.

Week 10

Release 2

The final Project Presentation is similar to the previous release, except this time the presentation is to the customer. The focus is will not be on the internal design or implementation, but rather on the functionality provided and the value to the customer:

• Teams will give a customer focused demonstration of their product.
• Presentation should be based on your Acceptance Test Plan as it validates each functional requirement in your system.
• The focus is on user functionality, not design details and development activities.
• Presentations are 15 minutes in length with 5 minutes for questions.

* We recommend that you copy the above together with all your program files to a flash/thumb drive to avoid any logistics during setup of presentation. Be ready to present from it. As soon as your team is called upon you are being evaluated.

• Project Deliverables (Your instructor will clarify how to submit your Release deliverables. It is your responsibility to verify with your instructor the content and format in advance of your release).

The deliverable consists of two parts.

The first part will include:
•    Source code located in your SVN repository tagged as “Release-x” (where "x" is the number of the release). All classes should be compliant with java naming conventions, contain javadocs markup and be well documented.
•    JUnit test cases for each class that ALSO are to be tagged in your svn repository as “Release-x” (where "x" is the number of the release), and be readily available for execution.

For the second part you must zip together all files corresponding to this “Release-x”. This zip file should include:
•    Up-to-date requirements, test plan and design, where the design is consistent with the requirements and the code is consistent with the design. These are THREE different documents to be submitted according to your instructor’s instructions. Make sure

to include the feature list for this release. Of course the information contained in them should be in synch with each other and reflect all updates implemented in Release product/executable.
•    The product (a self-contained executable JAR file) that is ALSO tagged in your svn repository as “Release-x” (where "x" is the number of the release). Your program must run on the target classroom lab Machines.
•    Executed Acceptance Test Plan cases for each delivered feature. Complete a right-most column labeled "Rx status" (where "x" is the number of this release) with the cell corresponding to each row marked as GREEN or RED to reflect pass or fail. Failed tests must have an associated comment.
•    A text file named "README.txt". This is considered a synopsis of your overall program with simple instructions and any special notes on how to execute your code. Minimal sections:

1) Installation:  From the zip.. and include target environment

2) Known bugs and disclaimers.

3) Known missing “Release-x“ features

4) Basic execution instructions (logins & passwords)

•     PowerPoint or equivalent file with your Presentation slides.

* Your instructor may require you to update your team Wiki as well as your team website (~w361-01a as described in the Week 8 Beta Release instructions).

Postmortem

• Every team member must complete a final peer evaluation of all the members of his or her team. As with release 1, the peer evaluation is done by following the Peer2Peer link on the course home page under myCourses. You have until the end of the day of the Session 1 of Week 10 to complete your evaluation.
• Reflect on the team's activities and performance through the entire project.  Capture these reflection thoughts in this Word document.  You must address the items listed in the document, but feel free to add others the team believes significant. Submit the document as directed by your instructor before the last class meeting.
• Plan a 10 minute presentation on the project as a whole, led by the team - not your instructor, based on your reflection document. In addition, during the discussion, each team member will summarize his or her role. Would you select this role again? Did you fulfill the role's responsibilities? How well was this area handled by the team as a whole?

FINALLY NOTICE: Project accounts will be purged during exam week. Create a personal copy of anything you wish to retain.