Contents

1. Project Overview ................................................................................................................................... 2

1.1. Mission and Scope of the project ................................................................................................. 2
2. Project Panning ..................................................................................................................................... 3
2.1. Summary of Methodology ............................................................................................................ 3
2.2. Work Breakdown Structure and Estimates (Ovo moze da se preskoci) ....................................... 4
2.3. Deliverables................................................................................................................................... 5
2.4. Detailed Project Plan (Tasks) ........................................................................................................ 5
2.5. Risk Management ......................................................................................................................... 5
3. Requirements and Specification ........................................................................................................... 8
3.1. Stakeholders / Actors .................................................................................................................... 8
3.2. User Stories (Ovo moze da se preskoci ) ....................................................................................... 9
3.3. Functional Requirements .............................................................................................................. 9
3.4. Non-Functional Requirements ...................................................................................................... 9
3.5. Use Cases .................................................................................................................................... 12
4. Design.................................................................................................................................................. 14
4.1. (UML) Structural Design .............................................................................................................. 14
4.2. (UML) Behavioral Design............................................................................................................. 14
5. Implementation and Testing ............................................................................................................... 15
5.1. Implementation technologies ..................................................................................................... 15
5.2. Testing Methodology .................................................................................................................. 15
6. Deployment and Installation............................................................................................................... 16
6.1. Release Checklist......................................................................................................................... 16
6.2. Installation / Quick Start Guide ................................................................................................... 17
1. Project Overview

1.1. Mission and Scope of the project

What problem does this project address?

2-4 SENTENCE PROBLEM

What is the goal of this project?

2-4 SENTENCE GOAL

What is the scope of this project?

2-4 SENTENCE SCOPE

What development methodology is being used?

See our software development methodology document.

2. Project Panning

2.1. Summary of Methodology

What general development approach will be used?

THREE TO FIVE SENTENCES OR BULLETS HERE. COVER GENERAL APPROACH, IMPORTANT ASSUMPTIONS,
KEY PRACTICES, AND PROJECT COORDINATION CONTROLS.

How will the project team be organized?

The development team will consist of ...

The change control board will consist of ...

What development and collaboration tools will be use?

We plan to use the following tools extensively through out the project:

 Project website

 Project mailing lists

 Issue tracking system

 Version control system

 Automated build system

 Automated unit test system

How will changes be controlled?

Requests for requirements changes will be tracked in the issue tracker

The change control board (CCB) will review requested changes and authorize work on them as
appropriate

After the feature complete milestone, no new features will be added to this release.

After the code complete milestone, no entirely new product source code will be added to this release.

All source code commit log messages must refer to a specific issue ID, after the feature complete
milestone.

How will this plan be updated?

This project plan will be updated as needed throughout the project. It will be placed under version
control and instructions for accessing it will be on the project website. Any change to the plan will cause
an automatic notification to be sent to a project mailing list.
2.2. Work Breakdown Structure and Estimates (Ovo moze da se preskoci)

Step Description Estimate

1. Preparation
1.1. Developer training 30h
2. Inception
2.1. Requirements gathering 30h
2.2. Requirements specification 20h
2.3. Requirements validation 10h
3. Elaboration
3.1. High-level design 5h
3.2. Low-level design (break down by component)
3.2.A. Object design 10h
3.2.B. User interface design 10h
3.2.C. Database design 3h
3.3. Design review and evaluation 5h
4. Construction
4.1.A. System implementation
4.1.A.1. Implement COMPONENT-NAME 1 25h
4.1.A.2. Implement COMPONENT-NAME 2 25h
4.1.A.3. Implement COMPONENT-NAME 3 25h
4.1.A.4. Implement COMPONENT-NAME 4 25h
4.1.A.5. Integrate Components (mostly done during component 5h
implementation)
4.1.B. Technical documentation (break down by component) 10h
4.1.C. User documentation (break down by component) 10h
4.1.D. Testing
4.1.D.1. Test planning 10h
4.1.D.2. Test code implementation (break down by component) 30h
4.1.D.3. Test execution 10h
4.2. Implementation review and evaluation 15h
5. Transition
5.A. Release packaging 3h
5.B. Documentation for other groups 3h
6. Reflection
6.1. Postmortem report 10h
Total 329 hours

2.3. Deliverables
Deliverable Name Description Delivery Date

2.4. Detailed Project Plan (Tasks)

2.5. Risk Management

Major risks

Name Description Likelihood Impact Plan Status Owner

Requirements Requirements are Medium Critical to Requirements will be Amber Requirements
only partly known Catastrophic detailed first for the top Lead
at project start. priority goals. Indicator:
Customers may not Track the rate at which
allocate sufficient requirements are
resources to discovered.
exploring Contingency: request
requirements. more customer effort.
Goals Stakeholders goals Medium Critical Keep an explicit list of Green Customers
may conflict. stakeholders goals. The
project manager will
report progress to each
declared goal.
Communication Communication Medium Critical Use these tools to help Green QA lead
problems in communication. The
development team. main indicator of
 They are dispersed miscommunication will
among several be software defects
sites, and have not detected by our QA
worked together activity.
before.
Acceptance Customer may Medium Critical Customers are asked to Green Customers
accept delivery of declare acceptance
the system criteria as each release
although it does is planned.
not really meet
their goals.
Scope The total features High Marginal Assign levels of Green Customers
requested may be important to the use
beyond what the cases. Make the first
development team review of project scope
can deliver in the after 12 months.
time available.

Minor Risks

Name Description Likelihood Impact Mitigation Strategy Status Owner

Estimate The development team Medium Marginal The development team Green Project
might not be able to will gain experience in Manager
estimate the work estimating the work, and
time, preventing deliver the first estimates
customers from after 12 months. We will
deciding priorities compare estimated work
effectively. to actual work.
Retention Some developers may Medium Marginal Employing locations Green Project
leave the project should provide support Manager
before it is finished. for continuing
professional
development. The project
manager will discuss
career goals with each
developer, and try to
assign tasks
appropriately.
Correctness The system as Low Catastrophic State of the art QA Green QA Lead
delivered may have activity. Contingency:
low take-up because of stop development of new
a lack of confidence in facilities until the quality
 its correctness.
Usability The system as Low
delivered may have
low take-up because of
poor usability.
Desire The stated Low
requirements might
not match the
customers' desires and
ambitions for the
system.
Changes After requirements Low
have been
documented and
agreed, development
activities begin to
based on them, first
design then
implementation. If the
requirements change
later then effort is
wasted.
Process Some developers may Low
not cooperate in
common standards
and processes.
Maintainability The system as Low
delivered might be
hard to maintain.
of the existing code is
assured.
Critical We will have a UI style Green UI design
guide. Most of the lead
development of the front
end will be in close
contact with customers.
We will review usability
later in the project.
Critical Incremental delivery of Green Customers
versions will provide
experience of using the
system, which will help
the customers to identify
the real requirements.
Indicator: a developer
saying "I think they mean
...", a customer saying
"They know what I
mean". Contingency:
request customer review
of requirements.
Critical A change control Green Project
procedure is required, so Manager
changes are only made
when the cost is
worthwhile. Indicator:
compare cost of change
to new development.
Contingency: request
customer review of
requirements.
Critical QA to check Green QA Lead
conformance, then
discussions in
development team
meetings to change the
standard or the actual
practice as appropriate.
Marginal We will review the code Green Lead
for maintainability. Developer
3. Requirements and Specification

Introduction
Provide a brief overview of this release of the product. You can copy text from the project proposal,
paste it here, and shorten it.

3.1. Stakeholders / Actors

All

All stakeholders share the following key needs:

1. Security against abuses by other site visitors

2. Convenient access to the site any time over the Internet

Player

Players want to have fun. That means a sense of discovery, challenge, satisfaction, and community.
Some players who become involved in clans will spend a few hours a week, while others will spend over
20 hours a week. So, they need new content posted often to keep them interested. Players involved in
clans are often power users and have high expectations for the functionality and quality of the site, but
they may not have much knowledge of computer science.

Key needs:

1. Easily find information about clans

2. Keep in touch with members of his/her own clan

3. Understand the date and time of tournament play

4. Easily report cheaters

Player > Advanced player

Advanced players seek more challenges to continue the sense of discovery. They tend to play over 20
hours a week. They have seen more of the game details, now the need to see the "big picture".

Key needs:

1. View metrics that compare multiple clans

2. Understand relationships between clans

3. Understand overall schedule of tournaments

STAKEHOLDER1

PARAGRAPH

STAKEHOLDER2

PARAGRAPH

STAKEHOLDER3

PARAGRAPH

3.2. User Stories (Ovo moze da se preskoci )

invited-to-join

John has gotten pretty good at SuperShooter by playing on public servers about 8 hours a week for the
last 3 weeks. John has chatted with Bob about strategies and they have enjoyed some duels. Bob is a
member of the RedDawn clan. That clan plays a tournament on a private server Friday nights. Bob
invites John to visit the RedDawn website and join. (Source: INTERVIEWEE)

finding-the-tournament

Bob is visiting his friend. He tries to use his friend's computer to log onto the RedDawn SuperShooter
tournament. But, he does not remember the exact name of the server. So, he visits the RedDawn clan
website to find that information. (Source: PERSONNAME)

STORYNAME1

PARAGRAPH

STORYNAME2

PARAGRAPH

STORYNAME3

PARAGRAPH

3.3. Functional Requirements

3.4. Non-Functional Requirements

What are the usability requirements?

Our main criteria for making the system usable is the difficulty of performing each high-frequency use
case. Difficulty depends on the number of steps, the knowledge that the user must have at each step,
the decisions that the user must make at each step, and the mechanics of each step (e.g., typing a book
title exactly is hard, clicking on a title in a list is easy).

The user interface should be as familiar as possible to users who have used other web applications and
Windows desktop applications. E.g., we will follow the UI guidelines for naming menus, buttons, and
dialog boxes whenever possible.

PARAGRAPH

Details:

 Government customers will demand section508 compliance

 Support learnability with principles of Instructive Interaction

 The customer wants extensive on-line help, but is not demanding a printed manual.

What are the reliability and up-time requirements?

PARAGRAPH

PARAGRAPH

Details:

 DETAIL

 DETAIL

 DETAIL

What are the safety requirements?

PARAGRAPH

PARAGRAPH

Details:

 DETAIL

 DETAIL

 DETAIL

What are the security requirements?

Access will be controlled with usernames and passwords.

Only administrator users will have access to administrative functions, average users will not.

Details:

 Passwords must be 4-14 characters long

 We will not use encrypted communications (SSL) for this website

 DETAIL

What are the performance and scalability requirements requirements?

PARAGRAPH

PARAGRAPH

Details:

 DETAIL

 DETAIL

 DETAIL

What are the maintainability and upgradability requirements?

Maintainability is our ability to make changes to the product over time. We need strong maintainability
in order to retain our early customers. We will address this by anticipating several types of change, and
by carefully documenting our design and implementation.

Upgradability is our ability to cost-effectively deploy new versions of the product to customers with
minimal downtime or disruption. A key feature supporting this goal is automatic download of patches
and upgrade of the end-user's machine. Also, we shall use data file formats that include enough meta-
data to allow us to reliably transform existing customer data during an upgrade.

Details:

 DETAIL

 DETAIL

 DETAIL

What are the supportability and operability requirements?

Supportability is our ability to provide cost effective technical support. Our goal is to limit our support
costs to only 5% of annual licensing fees. The product's automatic upgrade feature will help us easily
deploy defect fixes to end-users. The user guide and product website will include a troubleshooting
guide and checklist of information to have at hand before contacting technical support.

Operability is our ability to host and operate the software as an ASP (Application Service Provider). The
product features should help us achieve our goal of 99.9% uptime (at most 43 minutes downtime each
month). Key features supporting that are the ability to do hot data backups, and application monitoring.

Details:

 DETAIL

 DETAIL

 DETAIL

What are the business life-cycle requirements?

The business life-cycle of a product includes everything that happens to that product over a period of
several years, from initial purchase decision, through important but infrequent use cases, until product
retirement. Key life-cycle requirements are listed below.

Details:

 Customers must be able to manage the number of licenses that they have and make informed
decisions to purchase more licenses when needed

 The product shall support daily operations and our year-end audit

 The customer data shall be stored in a format that is still accessible even after the application
has been retired

3.5. Use Cases

- List of Use Cases

- Use Case Description

Example:

UC-00: Configure the site

Summary: The administrator navigates to the site configuration page and uses it to change
the behavior of the web application. Specifically, the user-visible timezone is
being set.

Priority: Essential

Use Frequency: Rarely

Direct Actors: Admin: Web-site administrator

Main Success Scenario: 1. visit SiteConfiguration page

2. see site configuration options

3. enter timezone abbreviation for date displays

4. submit form

5. confirm changes

6. see SiteConfiguration page again, with updated values

Alternative If the timezone abbreviation is incorrect, an error message will be displayed and
no changes will be made.
Scenario Extensions:

Notes and Questions How will administrators know the right timezone abbreviation? They would know
it if they live in that timezone. Maybe we could provide a drop-down list of all
choices, but each would need some explanation.

- Use Case Diagram

4. Design

4.1. (UML) Structural Design

Class diagrams

4.2. (UML) Behavioral Design

State Diagrams

Sequence Diagrams

Collaboration Diagrams
5. Implementation and Testing

5.1. Implementation technologies

5.2. Testing Methodology

Test Cases

Test case list and test case description

6. Deployment and Installation

6.1. Release Checklist

Table with what has been planned and what has been delivered.

Example:

Marketing / Product Management

Item Status Comments

All new requirements for this release have been tracked Pending

All prior defects needing resolution in this release have been tracked Pending

All marketing documents have been updated Pending

Marketing / Product Management is satisfied with this release Pending

Development

Item Status Comments

All needed design work has been completed Pending

All needed design work has been reviewed Pending

All development work has been completed Pending

All development work has been reviewed Pending

All defects assigned to this release have been fixed Pending

All development documentation has been updated Pending

All unit test code has been updated Pending

The development team is satisfied with this release Pending

6.2. Installation / Quick Start Guide