Purpose
Achieve concurrence among all stakeholders on the lifecycle objectives for the project. The inception phase is of significance primarily for new development efforts, in which there are significant business and requirements risks which must be addressed before the project can proceed. For projects focused on enhancements to an existing system, the inception phase is more brief, but is still focused on ensuring that the project is both worth doing and possible to do.

Artifacts

Business Case

The purpose of this document is to introduce the Business Case information for the “getTogether Project”. This document contains the high-level abstract description of the project’s position in the deployment company’s business plan.

Software Architecture Document

This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.

Software Development Plan

This document provides a comprehensive overview of how to project is to be developed system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.

Use Case Realization for 'Login'

The purpose of this document is to lay out the Use-Case-Realization Specification for the Use Case 'Login'. This document presents the role of Use-Case 'Login' within the scope of the getTogether project.

Use Case Realization for 'Register'

The purpose of this document is to lay out the Use-Case-Realization Specification for the Use Case 'Register'. This document presents the role of Use-Case 'Register' within the scope of the getTogether project.

Use Case Model Survey

This report describes the use-case model comprehensively, in terms of how the model is structured into packages and what use cases and actors there are in the model.

Vision Document

The purpose of this document is to collect, analyze, and define high-level needs and feature of the “getTogether Project”. It focuses on the capabilities needed by the stakeholders and the target users, and why these needs exist. The details of how the “getTogether Project” fulfills these needs are detailed in the use-case and supplementary specifications.

Risk List

A sorted list of known and open risks to the project, sorted in decreasing order of importance and associated with specific mitigation or contingency actions.

Purpose
Baseline the architecture of the system to provide a stable basis for the bulk of the design and implementation effort in the construction phase. The architecture evolves out of a consideration of the most significant requirements (those that have a great impact on the architecture of the system) and an assessment of risk. The stability of the architecture is evaluated through one or more architectural prototypes.

Artifacts

Business Case (version 2)

The purpose of this document is to introduce the Business Case information for the “getTogether Project”. This document contains the high-level abstract description of the project’s position in the deployment company’s business plan.

Software Development Plan (version 2)

This document provides a comprehensive overview of how to project is to be developed system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.

Use Case Realization for 'Login' (version 2)

The purpose of this document is to lay out the Use-Case-Realization Specification for the Use Case 'Login'. This document presents the role of Use-Case 'Login' within the scope of the getTogether project.

Use Case Realization for 'Register' (version 2)

The purpose of this document is to lay out the Use-Case-Realization Specification for the Use Case 'Register'. This document presents the role of Use-Case 'Register' within the scope of the getTogether project.

Vision Document (version 2)

The purpose of this document is to collect, analyze, and define high-level needs and feature of the “getTogether Project”. It focuses on the capabilities needed by the stakeholders and the target users, and why these needs exist. The details of how the “getTogether Project” fulfills these needs are detailed in the use-case and supplementary specifications.

Risk List (version 2)

A sorted list of known and open risks to the project, sorted in decreasing order of importance and associated with specific mitigation or contingency actions.

Purpose
Clarifying the remaining requirements and completing the development of the system based upon the baselined architecture. The construction phase is in some sense a manufacturing process, where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality. In this sense the management mindset undergoes a transition from the development of intellectual property during inception and elaboration, to the development of deployable products during construction and transition.

Artifacts

Test Case Document

The purpose of the Master Test Plan for the complete lifecycle of the is to provide a central artifact to govern the planning and control of the test effort. It defines the general approach that will be employed to test the software and to evaluate the results of that testing, and is the top-level plan that will be used by managers to govern and direct the detailed testing work. It also provides visibility to stakeholders in the testing effort that adequate consideration has been given to various aspects of governing the testing effort, and where appropriate to have those stakeholders approve the plan.

User Source

The ASP source code for the user section of the system.

Admin Source

The ASP source code for the administration section of the system.

Front Page Source

The PHP source code for our entry page.

Help Source

The Websphere source code for the help section.

Purpose
Ensure that software is available for its end users. The Transition Phase can span several iterations, and includes testing the product in preparation for release, and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback should focus mainly on fine tuning the product, configuring, installing and usability issues, all the major structural issues should have been worked out much earlier in the project lifecycle.

Due to time constraints we were not able to produce any documentation for this period.

Purpose
Documents that we produced that do not fit evenly into one of the other four categories.

UML Diagrams (version 1)

Our project's UML Diagrams. Requires Rational Rose to view.

(version 2)

(version 2.1)

(version 3)

(version 4)

Selected diagrams in jpg format:

Use-Case Model

The use-case model is a model of the system's intended functions and its environment, and serves as a contract between the customer and the developers. The use-case model is used as an essential input to activities in analysis, design, and test.

'Edit Friends' Activity Diagram 'Register' Activity Diagram

Activity diagrams show the procedural flow of control between two or more class objects while processing an activity. Activity diagrams can be used to model higher-level business process at the business unit level, or to model low-level internal class actions. In my experience, activity diagrams are best used to model higher-level processes, such as how the company is currently doing business, or how it would like to do business. This is because activity diagrams are "less technical" in appearance, compared to sequence diagrams, and business-minded people tend to understand them more quickly.

'Login Successful' Sequence Diagram

Sequence diagrams show a detailed flow for a specific use case or even just part of a specific use case. They are almost self explanatory; they show the calls between the different objects in their sequence and can show, at a detailed level, different calls to different objects.

'Register' Collaboration Diagram

Collaboration diagrams focus upon the relationships between the objects. They are very useful for visualizing the way several objects collaborate to get a job done and for comparing a dynamic model with a static model. Collaboration and sequence diagrams describe the same information, and can be transformed into one another without difficulty. The choice between the two depends upon what the designer wants to make visually apparent.