Project Milestones

You've been assigned to work in teams to design and develop a database web application using Java EE 6 technology -- in particular JPA, EJB, JavaServer Faces, and Facelets. There are several milestones that you will be required to complete on your way to the final submission of your project. This web page provides overviews of these milestones, some of which you would have been introduced to in your software engineering class.

Software Requirements Specification

The Software Requirements Specification (SRS) is the first milestone of the project; it provides a thorough description of the web application. First, it is expected that you will collect information from the research that you conduct and the decisions that you take as a team regarding the functionality of your web application.

In a software requirements specification, you are to state what your web application will and will not do. A requirements document is written to describe the purpose of a software product. It does not state how the functionality of the software is implemented. Thus, this document states what can be done with the web application, including what takes place when a user performs some function. The results of all user interactions are to be described in this document. Note that this document does not attempt to propose solutions, rather, it describes all functionality required.

You should incorporate all of the following in the SRS:

A detailed specification of your proposed application. This needs to include enough information so that a reader understands the main services/functionality provided by your application. The specification must also be thorough and in particular make clear what the application will and will not do. You should include a description of the motivation for the web application. Again, explain what the application will do and stay away from explaining how the functionality will be achieved. It is best if you provide the functionality in a hiearchical numbered list, see articles mentioned below for sample templates.
A detailed list of individual duties and areas of responsibility for each teammate. As you start working in your team, you need to share with each other the areas of expertise. As a team, you will then need to determine the duties and areas of responsibility that each team member will have based on your skill sets. This is not typical for a SRS, however, it is required that you include it.
If appropriate, you should also include a set of UML Use Case diagrams that describe the different ways in which users will interact with your application.

Everyone should read the article Writing Software Requirements Specifications to gain additional understanding of what an SRS document entails. It also provides templates that I strongly recommend you use.

For additional information about what goes in a complete software requirements specification, you should read the IEEE Recommended Practice for Software Requirements Specifications (CSULB has a license to the IEEE Explore Digital Library). In particular, the document describes the characteristics of a good software requirements specification.

Correct
Unambiguous
Complete
Consistent
Ranked for importance and/or stability
Verifiable
Modifiable
Traceable

Object Oriented Design

In this document you will provide the OO model of your application. This is a UML Class Diagram of the entities in your web application. You may use this sample UML class diagram for the academic programs of a University(PDF) and the accompanying documentation of the University academic programs (PDF) of the model to review the use of UML in designing models.

Web Application Architecture

Describe all of the elements (HTML static pages, JSF Facelets, Servlets, JavaBeans, EJB's, etc) planned for the application and their interactions in the application. Include a diagram showing how the elements are related and how they relate to a database and any other existing applications or systems if present. In the site architecture diagram, elements are connected by the actions which cause the user to navigate from one page to another. Be sure to include all elements that will be used in your application.

Site Diagrams: Mapping an Information Space -- article from the website Boxes and Arrows: The design behind the design. Boxes and Arrows is a site dedicated to discussions of design and this particular article is about designing site diagrams. This article can be used as a guideline for designing your own site diagram.
Visual Vocabulary for Information Architecture by Jesse James Garrett, author of the book The Elements of User Experience: User-Centered Design for the Web. This page includes a stencil shape library for Visio that can help in creating the diagrams.
Architecture of the Sample Application -- Section 11.4 from Designing Enterprise Applications with the J2EE Platform, 2nd edition. This section includes a discussion of Application Web Site Architectures, using a Java Pet Store Application as an example.
Microsoft Visio has a shape library for creating Web Diagrams: Conceptual Web Site. The Conceptual Web Site shape library is best suited for creating your site architecture diagrams. You can read the section of the Microsoft Office Online Help on Conceptual Web Site for brief help. There is also a Web Site Map shape library that automatially discovers the link structure of an existing web site and creates a diagram on the fly. Unless you have a completed web site, you won't be able to use this, however, it has a larger set of shapes that will be useful in creating your own site diagram.

Intermediate Project Review

This milestone consists of a demonstration of your web application thus far. This demonstration occurs with approximately five weeks left for the completion of the project. While the milestone is graded, the goal of the review is to give the project manager an idea of the progress completed so far, assess team dynamics, and it's an opportunity for each team to assess the priorities of the project given the final deadline.

You will need to demonstrate what has been completed thus far and you should also seek feedback from your classmates. You will also submit a snapshot of all of your work (all code making up the project) completed up to this point.

Final Project

A debugged, documented, "graduating student"-quality application with a short user's guide and thorough documentation. The user's guide is expected to be part of your web application -- in an about.html page for example.

Demonstrations

Each team will have about 30 to 40 minutes for their demonstration. All members of the team need to participate in the demonstration and questions may be addressed to specific members. Reserve time to organize the demonstration and to determine what parts are presented by each of you. You should also rehearse to have your presentation be smooth.

Teams should focus their presentation on a demonstration of the web application. Each team should also pick one or two non-trivial parts of the application and explain how you implemented it. To do this you should show your object model, database, and also source code.

Demonstrate the functionality of your application. It is your job to determine the actual parts of the web application that you'll demonstrate, each project will be graded separately after the presentation for completeness and correctness of all proposed functionality.

Documentation

Your web application should be well documented throughout (i.e. JavaDoc style comments in your source code).

Each team must submit one final team report. This report should include the information listed below.

For each major requirement that you submitted in your requirements document, list the requirement and specify the level of completeness reached.
- completed with minor changes
- completed with significant changes (briefly state changes)
- not completed (provide explanation for not completing it)
While you may be tempted to use lack of time as the reason you modified a requirement or for completing a requirement you proposed, you must explain what went wrong in the planning that lead the team to run out of time.
For each team member, indicate how much of the project can be attributed to the team member along with a justificiation for the amount being attributed. Specify each amount as a percentage of the project such that all contributions add up to 100%. All teammates must agree on the amounts specified in this report. The justification of these amounts should explain the meaning of the values specified for contributions to the project. So, for example, if a report states that a teammate can be attributed with 35% of the project on a team of four students, then the justification has to describe specific reasons to justify this number. Similarly, if a report states that a teammate can only be attributed 10% of the project, then this amount must be justified. All amounts must be justified, even if a team reports that each team member can be attributed with an equal share.
Supply all the information needed in order to thoroughly test the application. To use each of the web applications a user has to specify values in order to access different aspects of the application. For example, usernames and passwords are needed in order to be authenticated as a user. The report must include all such information needed in order to test the application thoroughly.

Grading of your project

The members of the class and other invited guests will evaluate your project based on the presentation given. This will account for part of the grade of your project. Since you will be evaluating other projects, you're expected to be attentive while others are presenting -- do not work on your project and/or presentation during another team's presentation as your grade will be negatively affected!!!

Each team member will also be evaluating her work as well as the work of the other members in the team. This evaluation will only be seen by the instructor.

Your project will be tested thoroughly after the presentation, specifically to test parts of the project that were either not demonstrated or that were minimally shown.

The entire source code will be retrieved from the Subversion repository and all will be inspected and graded for correctness, style, consistency, etc. This includes all aspects of software writing that you would have learned about throughout your CECS education.