Project Charter

Wings by Daedalus, 9/23/2013

Table of Contents
1 Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions and Abbreviations
1.4 References
1.5 Overview of Contents of Document
2 Project Overview
2.1 Project Sponsor
3
2.2 Business
2.3 Project Description
3 Management Proposal
3.1 Methodology Overview
3.2 Schedule
3.3 Roles
3.4 Processes
3.5 Resources
3.6 Quality Assurance
3.7 Change Management
3.8 Risk Management
3.9 Technical Methods
4 Contributors
4.1 Comments
4.2 Version History
4.3 Approvals
5 Appendices
A Deliverables
B Cost Estimate
C Partnership Guidelines

1
1
1
1
2
2
3

3
3
5
5
7
9
9
12
12
14
15
16
17
17
18
18
19
19
19
21

1 Introduction
Wings is a software development project undertaken as the culminating requirement for the
undergraduate Computer Science degrees of the team, Daedalus.

1.1 Purpose
This charter will introduce the project, define the scope of development, and propose a formal
development methodology to be used by the team over the course of the project.

1.2 Scope
This document will describe the Wings project and project sponsor, the project management
proposal, and relevant constraints and limitations on development. For a description of the team
members, refer to the project prospectus. Refer to the software requirements specification for
approved sets of requirements based on analysis of the problem and to the software design
specification for models and descriptions of the solution.

1.3 Definitions and Abbreviations

Agent - in the context of game development, a game object which possesses artificial intelligence.
API - Application Programming Interface
Artificial Intelligence - in the context of game development, algorithms and heuristics which provide
perception, planning, or reasoning abilities to non-human-controlled game objects.
CSUS - California State University, Sacramento
Defect - a flaw in software which may be indicated by incorrect behavior, failed tests, or standards
non-compliance.
Deliverable - a product which will be delivered to the project sponsor upon completion.
Integration Tests - tests which validate the compatibility of multiple software modules.
Issue - a challenge or impediment to the implementation of the software including defects, changes,
and risks.
PMP - Project Management Plan
Problem - A set of unaddressed needs and unrealized opportunities which will be satisfied and
realized by the project.
Product - an item (document or software) which will be produced by the development team.
Prototype - a functional piece of software which exemplifies a specific function or layer of a larger
system.

Project Charter 1

Regression Tests - tests which are implemented during defect resolution to automatically identify
issue recurrences.
Requirement - a specific, satisfiable criterion for the software to be considered a solution to the
identified problem.
SDS - Software Design Specification
SRS - Software Requirements Specification
STS - Software Test Specification
System Tests - tests which certify that user-level software behavior satisfies the requirements.
Unit Tests - tests which evaluate the function of a single element of software (e.g. a method).
Workgroup - one or more members of the development team tasked with performing specific
activities within a development iteration.

1.4 References
Project Charter Document R. Buckley,
athena.ecs.csus.edu/~buckley/CSc190/Project_Charter_Document.pdf
Software Project Management Plan R. Buckley, athena.ecs.csus.edu/~buckley/CSc190/SPMP.pdf
Cost Estimate Example R. Buckley, athena.ecs.csus.edu/~buckley/CostEst.pdf

1.5 Overview of Contents of Document

The remainder of this document will describe the sponsor of the project, the nature of the project,
proposed plans for managing the project, a summary of contributions to this document, and various
appendices.

1.5.1 Section 2: Project Sponsor

The project sponsor is the individual for whom the project is primarily being developed. The sponsor
is typically the manager or owner of the environment in which the system must function and is
ultimately responsible for acceptance of the project deliverables.

1.5.2 Section 3: Management Proposal

This section proposes a formal development methodology for adoption to the Wings project. The
proposed methodology is discussed in terms of schedule, roles, and processes.

1.5.3 Section 4: Contributors

This section lists each member of the team and their contributions to the development of this
document.

1.5.4 Appendix A: Deliverables

Project Charter 2

Appendix A has a table that lists and describes each deliverable that the project team is required to
produce and deliver to the project sponsor and project advisor.

1.5.5 Appendix B: Cost Estimate

Appendix B contains two tables which lists the estimated real world costs of the project if it were
being funded by a software development company.

2 Project Overview
The project sponsor is the individual for whom the project is primarily being developed. The sponsor
is typically the manager or owner of the environment in which the system must function and is
ultimately responsible for acceptance of the project deliverables.

2.1 Project Sponsor

The project sponsor for Wings is Josh Klint, CEO of Leadwerks Software. Leadwerks Software is a game
engine development company based in downtown Sacramento, CA. The primary product of the
company is Leadwerks 3, a game engine based on OpenGL and Newton Dynamics.
Josh Klint
Chief Executive Officer
Leadwerks Software
joshklint@leadwerks.com
1715 I Street
Sacramento, CA 95811

2.2 Business
Leadwerks Software develops and distributes the game engine Leadwerks 3. Leadwerks 3 provides a
C++ application programming interface for game designers, as well as a visual toolset which allows
designers to script games using Lua. The engine is object-oriented and general purpose. Leadwerks 3
is also cross-platform, with support for development on Windows and OSX and deployment to
Windows, OSX, Android, and iOS. The Leadwerks 3.1 update will add support for Linux development
and deployment. Leadwerks is marketed online and through the Steam software distribution service.
Game designers are using Leadwerks around the world to develop a diverse range of games.

2.3 Project Description

Leadwerks 3 emphasizes generality and performance. The API is relatively flat and game objects are
uncomplicated. One consequence of this focus is that the engine provides only the foundations for
advanced artificial intelligence in games, leaving the designers to implement complex algorithms
independently. The lack of standardization of high level behaviors can also make it difficult for
designers to reuse and share useful modules between games.

2.3.1 Problem Statement

The current extent of artificial intelligence in Leadwerks 3 is a set of pathfinding and navigation
methods based on the Recast pathfinding library. This set of methods gives game objects the ability
Project Charter 3

to generate the shortest path to a destination based on a special purpose data structure, the
navigation mesh, and then to follow that path. Essentially, all Leadwerks game objects can be
special-purpose navigation agents employing a single heuristic pathfinding function. These
behaviors are specific to game objects which use the character controller, only function with perfect
knowledge of the navigation mesh, and can only be used for moving between locations in the game
world. Additionally, the pathfinding algorithm is tightly bound into the core of the engine, making it
expensive for designers to replace.

2.3.2 Vision
To enable designers to create actions, goals, and agents explicitly. To provide a set of robust,
efficient, and standardized artificial intelligence techniques for use with Wings agents. To support
the development of smarter, more entertaining games.

2.3.3 Goals
1. To develop and deliver software which solves the problems identified and achieves the
vision of the project sponsor.
2. To provide the team with practical experience in formal software engineering, artificial
intelligence, and game development.
3. To achieve the degrees of bachelors of science through successful completion of the senior
project.
4. To enable and empower innovative game designers.

2.3.4 Constraints

Leadwerks 3 is implemented in C++. The Wings project must be directly compatible with
Leadwerks on multiple platforms, therefore Wings must be implemented in portable C++.
Advanced artificial intelligence will not be necessary for all games built with Leadwerks.
Wings must be modular to minimize coupling with the core engine.
The Leadwerks API is object oriented and has established coding standards. Wings must
conform to established organization and practices where it is reasonable to do so.
Wings should employ, and must not interfere with, existing performance optimization
functions in Leadwerks.
Wings must not make use of proprietary or restrictive open-source technology and should
not depend upon paid software (except Leadwerks) during development or use.
The Wings project must be complete by the end of the second semester. No extensions can
be made and no ongoing maintenance responsibilities are assumed by the team.
The Computer Science department of CSUS reserves the right use senior project products as
examples of student work.
Delivery of the project documentation, software, and supporting materials to the sponsor is a
condition of the completion of the project. Upon delivery, the senior project is assumed to
be jointly owned by the development team and the project sponsor in the absence of a
specific agreement regarding ownership.
Wings will be distributed primarily by Leadwerks. No distribution system is required to be
developed during the project.
Project Charter 4

Wings will be used by game designers with Leadwerks. Sufficient documentation must be
provided for programmers and technical users to understand the software.
All team members must have access to the Leadwerks API and toolset. Source code access
may be required for development of GUI components. The project sponsor will decide upon
the terms and means of providing access.

2.3.5 Conditions and Limitations

Wings will not provide every possible or useful algorithm for game designers.
Wings will not modify the Leadwerks API.

Disclaimer: All students majoring in Computer Science at California State University, Sacramento are
required to complete a two semester senior project. The proposed project, Wings, is expected to
fulfill this requirement for the project team of Tim Shea, Ethan Weidman, Chris Lawson, Ken Barnett,
and Tate Chamberlain. While the intent of the team is to deliver a high quality product that meets
the sponsors expectations, neither the students, faculty, advisor, or CSUS can be held responsible
for any errors in the delivered software, failure to meet any of the specified requirements, or failure
to deliver the software. Furthermore, due to the academic nature of the experience and its
requirement for graduation, students can not be paid for the work associated with the project.

2.3.6 Success Criteria

Wings will provide the following features in order to achieve the vision of the project.
1. Designers can create agents, goals, and actions within the Leadwerks graphical toolset.
2. Designers can develop agents using an object oriented API and set of standardized AI
techniques, such as perception, flocking, or conversation.
3. Designers can develop agents which reason about or interact with non-agents in a game.
4. Designers can access agent features from within the Leadwerks Lua scripting engine, or access
Lua scripts from agents.
5. User documentation will be sufficient to ensure that programmers and technical users
without specific knowledge of artificial intelligence can understand and utilize Wings
productively.

3 Management Proposal
This section proposes a formal development methodology for adoption to the Wings project. The
proposed methodology is discussed in terms of schedule, roles, and processes.

3.1 Methodology Overview

We propose an iterative and incremental methodology incorporating rapid prototyping techniques
for the development of the Wings project. The methodology consists of three phases of work:
inception, iteration, and completion. During inception, the entire team works together to understand
and prepare for the project. Iteration is composed of four processes and is repeated several times,
with each iteration incrementally contributing to the documentation, the design, and the
functionality of the system. During each iteration, two team members are assigned to a prototyper
workgroup and delegated the task of producing the set of requirements for a functional increment.
Project Charter 5

Another two team members are assigned to a builder workgroup responsible for designing and
constructing the increment. The last team member coordinates and facilitates the two workgroups in
the role of project manager. Upon delivery of the final iteration, the entire team again works
together during the completion phase to finalize the documentation and present the project to the
sponsor.

Figure 3-1 Development Methodology Model

The proposed development methodology is modeled in Figure 3-1. Major phases of development are
shown in the top row. The processes within each iteration are expanded between the dotted lines,
and products are attached via dashed lines.

3.1.1 Benefits
The proposed methodology is rigorous. Documentation and deliverables are formally specified.
Development progress can be assessed throughout the project. Decisions, defects, and changes are
tracked to support traceability.
The methodology is efficient. Big Design Up Front is widely recognized to be risky if project
requirements are unstable. The iterative approach will minimize the effort invested into the least
Project Charter 6

well-understood aspects of the project, as these aspects are the most likely to change. Rapid
prototyping supports efficient requirements engineering by allowing the team and the sponsor to
review a concrete product early in the iteration.
The methodology is flexible. The iteration schedule can be modified while maintaining the overall
structure to allow for different complexities within increments. Time permitting, the team can
undertake additional iterations, or can develop multiple increments within a single iteration. If
requirements change, the affected iteration can be revisited after the current iteration is complete.
Finally, the methodology is consistent with industry standards and best practices. Incremental
processes allow student teams to gain experience that is more consistent with real-world software
engineering than a waterfall model.

3.1.2 Risks and Challenges

One of the risks of prototype-driven requirements engineering is that insufficient effort will be
invested in fully understanding the requirements or developing the design: the prototypes become
the only documentation of the process. Discarding the prototypes mitigates this risk, as the team is
required to translate the knowledge encapsulated in the prototype into english before
implementing it.
Another risk of a prototype driven planning process is that too much time and effort might be spent
on the construction of the prototype which detracts from the time spent on actually documenting the
requirements gleaned from the prototype. It could also have the effect of narrowing the focus of the
team onto one small aspect of the overall product causing the team to lose sight of the larger view of
the product as a whole.
The greatest risk associated with the iterative model is the potential that issues may arise late in
development which will be incompatible with decisions made early. There is no universal
preventative measure for this risk. In fact, even with Big Design Up Front this can undermine a
project. Under the proposed method it will be mitigated through an initial high level analysis and
through continuous integration providing early detection.
An additional challenge related to incremental development is the need to integrate each
development increment into the core system. Under the model, integration would be performed
continuously alongside construction of each increment. Although deferring integration to a
penultimate phase was considered, it was rejected due to the high risk of incompatibility.
Continuous integration will minimize incompatibilities and ensure a viable product exists throughout
the entire project.

3.2 Schedule
The iterative development methodology results in incremental completion of products. At the
delivery deadline for each iteration, incremental products will be ready for review. At the project
completion, the integrated products will be ready for delivery. Four iterations are planned, with an
extended first iteration. The development schedule is provided in Table 3-1.
Project Charter 7

Process

Products (Deliverables)

Dates

Inception

Prospectus, Charter, PMP

9/9/2013 - 9/30/2013

Iteration I

9/30/2013 - 12/20/2013

Planning

SRS 0.1

9/30 - 10/21

Modeling

SDS 0.1, STS 0.1

10/21 - 11/11

Construction

Wings 0.1

11/11 - 12/16

Delivery

12/16 - 12/20

Iteration II

1/27/2014 - 3/3/2014

Planning

Prototype 1, SRS 0.2

1/27 - 2/10

Modeling

SDS 0.2, STS 0.2

2/10 - 2/17

Construction

Wings 0.2

2/17 - 3/3

Delivery

3/3

Iteration III

3/3/2014 - 4/7/2014

Planning

Prototype 2, SRS 0.3

3/3 - 3/17

Modeling

SDS 0.3, STS 0.3

3/17 - 3/24

Construction

Wings 0.3

3/24 - 4/7

Delivery

4/7

Iteration IV

4/7/2014 - 5/12/2014

Planning

Prototype 3, SRS 0.4

4/7 - 4/21

Modeling

SDS 0.4, STS 0.4

4/21 - 4/28

Construction

Wings 0.4

4/28 - 5/12

Delivery
Completion

5/12
Wings Final, User Documentation, SRS, SDS,
STS, Project Log, Final Presentation

5/12/2013 - 5/23/2013

Table 3-1 Development Schedule

In addition to the development processes described in the schedule, the team will meet on at least a
weekly basis. For the first semester, the team meetings will be conducted at 9:00 AM in Riverside
Project Charter 8

5029. The team will additionally meet with the advisor on a weekly or biweekly basis. Arrangements
for these meetings are unconfirmed. The project manager and one or more team members will meet
with the sponsor to elicit requirements and deliver products at least six times during each semester.
These meetings will be conducted electronically when possible and will be scheduled at the
convenience of the sponsor.

3.3 Roles
The Wings project will be undertaken by a team of five students on behalf of the project sponsor and
under the supervision of an advisor. The team consists of Tim Shea, Ethan Weidman, Chris Lawson,
Ken Barnett, and Tate Chamberlain. The team name is Daedalus. The project sponsor is Josh Klint.
The project sponsor is described in Section 2.1. The advisor is Ahmed Salem, the senior project
coordinator for 2013/14 and a professor at CSUS.
Members of the development team fulfill three basic roles within each iteration of the development
methodology: Prototyper, Builder, and Project Manager. The prototyper performs planning and
analysis activities at the beginning of the iteration. The builder conducts modeling and construction
activities. The project manager facilitates and coordinates the actions of the workgroups. After each
iteration, team roles will be rotated according to experience and workload. Table 3-2 summarizes the
responsibilities of each role.
Role

Responsibilities

Prototyper

Conducts research, develops a rapid prototype, elicits and specifies

requirements.

Builder

Designs, implements, tests, and integrates module.

Project Manager

Supports documentation processes, facilitates sponsor reviews,

coordinates prototyper and builder workgroups, ensures adequate
implementation of the project management plan.

Advisor

Provides project guidance, reviews progress, assesses deliverable quality.

Sponsor

Makes provisions for requirements elicitation, accepts deliverables.

Table 3-2 Project Roles Summary

3.4 Processes
Each development iteration consists of four processes: planning, modeling, construction, and
delivery. Within each process, team members or workgroups will have specific responsibilities. The
four processes will incrementally develop and document the project. The first iteration of the
method is unique because the goal is to produce an integration target for subsequent iterations.
Effort estimates in work hours are shown in Table 3-3 for each process in an iteration.

Project Charter 9

Activity

Estimated Effort
(Person-Hours)

Estimated Duration
(Weeks)

Planning

24

2 (2 People)

Research

Prototyping

10

Requirements Engineering

10

Modeling

12

1 (2 People)

Design

10

Test Specification

Construction

24

2 (2 People)

Implementation

10

Testing

Integration

10

Delivery

(1 Person)

Iteration Total

64

5 (5 People)

Table 3-3 Estimated Level of Effort for Development Activities

3.4.1 First Iteration
The proposed development methodology relies upon a functional decomposition of the project and
the existence of a core software module, or integration target, with which to merge each incremental
development. Additionally, effective rapid prototyping requires working familiarity with the
environment and tools to be used. Therefore, the first iteration will maintain some of the same
structure as subsequent iterations, but will be extended and all five members of the team will
contribute to each development process. The planning process will include an initial high-level
analysis of the system requirements. The modeling process will include designing the general
context and interactions for future increments, as well as identifying and mapping functional
modules to each iteration. The first implementation iteration will produce the integration target for
future iterations and the first testing iteration will establish basic functionality tests. There will be no
integration process for the first iteration.

3.4.2 Planning
Each development iteration will be initiated with a planning phase. Planning will be carried out
primarily by the prototyper workgroup facilitated by the project manager. The planning process will
be performed by a team of two over approximately 2 weeks. More prototypers working concurrently
Project Charter 10

on research or rapid prototyping is unlikely to increase development speed.

3.4.2.1 Research
Each project increment, with the exception of the integration target, will represent a functional slice
of the system along the boundaries of an algorithm or family of algorithms. The prototyper
workgroup will conduct research into the available algorithms. Alternative algorithms will be
considered according to end-user value, complexity, and project constraints. The prototyper
workgroup will present the distilled research in a knowledge transfer and feasibility review meeting
to the entire team.
3.4.2.2 Prototyping
The prototyper workgroup will produce rapid, throwaway prototypes to be used during requirements
elicitation. Rapid prototyping involves maximizing the efficiency of prototyping by investing the
minimum possible effort necessary to achieve a working prototype. Normal coding standards,
non-functional requirements (e.g. performance, stability), and integration with the larger system are
eliminated during rapid prototyping. Throwaway prototypes are those which are developed,
reviewed, and discarded, rather than merged into the core system. Throwaway prototypes yield
three opportunities for requirements elicitation: by the prototyper during development, by the team
during internal review, and from the sponsor during external review. After the elicited requirements
are documented, discarding the prototype ensures that compromised prototype standards do not
affect the quality of the system.
3.4.2.3 Requirements Engineering
The primary outcome of the planning phase is the production of a detailed set of requirements for
the development iteration. These requirements will be formalized by the prototyper workgroup and
project manager in an increment of the software requirements specification. The project manager
ensures the requirements are sufficient to begin design and facilitates the transfer to the modeling
phase.

3.4.3 Modeling
Modeling begins for an iteration once the SRS is completed. The modeling phase is performed by the
builder workgroup guided by the requirements approved in the planning phase. Prototyper input to
the modeling phase will also be essential for complex increments.
3.4.3.1 Design
The outcome of the design process is an incremental addition to the software design specification.
The SDS is to include sufficient information to understand the intended behavior of the solution and
to implement that behavior in a functional software module. In the event that multiple solutions
meet the approved requirements, these should be documented in the SDS along with the final
decision and supporting rationale.
3.4.3.2 Test Specification
Along with the design specification, the builder workgroup will generate a set of unit and integration
test cases to validate the implementation. The prototyper workgroup may also contribute system
Project Charter 11

tests during this process to validate the design and requirements.

3.4.4 Construction
The construction process begins with the completed design and ends with successful integration of
the incremental product. Construction is performed by the builder workgroup with the assistance of
the prototyper workgroup and project manager as necessary.
3.4.4.1 Implementation
Implementation consists of the process of actually programming the software specified by the SDS.
Implementation may occur concurrently with testing and integration, or may precede those
activities.
3.4.4.2 Testing
The construction process includes all activities associated with testing: programming automated
tests, running manual test routines, documenting test outcomes, logging software defects, and
resolving regressions.
3.4.4.3 Integration
The builder workgroup will additionally be responsible for integration of the development increment
with the system. The goals of integration are to maintain compatibility between the incremental
functionality and integration target and to ensure the integrated system meets the development
standards of the project.

3.4.5 Delivery
The final process within each development increment is delivery. The project manager is primarily
responsible for delivering the integrated software for review and approval to the advisor and
sponsor.
3.4.5.1 Retrospective Analysis
During the delivery process of each iteration, the team will, with the input or oversight of the
advisor, analyze the outcome of the iteration, review low priority change reports logged during the
iteration, and make any necessary alterations to the schedule or requirements.

3.5 Resources
Due to the academic nature of the project, external resources will be limited to those which are
considered essential to the success of the project by all members of the team. Some required
resources include office supplies, research materials, and development tools. The impact of these
resource requirements is considered negligible and will be dealt with individually.

3.6 Quality Assurance

In order to promote quality and consistency in the developed software, the team will implement four
types of quality assurance: performance metrics, testing, development standards, and formal review.

3.6.1 Performance Metrics

For each iteration, milestones will be set with specific criteria for acceptance. At any time, team
Project Charter 12

members will be able to measure progress towards the next milestone based on satisfied criteria.
This measure of performance will support strategic decision making throughout implementation.
Additional metrics, such as lines of code produced, defects introduced, defects resolved, lines of
code eliminated, etc. can be taken into account when available.

3.6.1 Testing
During the modelling and construction processes, team members will contribute test cases to the
software test specification. A test case describes a single functional or behavioral test, the expected
result, and references the requirements that support the test. The system test specification will
include unit, integration, system, and regression tests.
During the construction process, automated test cases for the current iteration are implemented in
the testing framework. Manual test cases are performed by team members. Results from completed
tests are recorded in the system test specification. If a test case identifies a defect in the software, an
issue will be reported using the issue tracking tools. When the issue is resolved, a regression test
case will be added to the STS and implemented.

3.6.2 Development Standards

The PMP and SDS each define standards to which the software must conform. In the PMP,
development standards and process guidelines will establish basic conformance standards, such as
coding aesthetics and documentation formatting standards, to promote consistency between the
work products of each team member. The SDS will define operational standards derived from the
non-functional requirements. Each development product should satisfy the operational standards
prior to delivery.

3.6.3 Formal Review

Formal review of every development product is the cornerstone of the quality assurance strategy.
Four types of formal review will be performed at various stages of development. The review process
will be used to guide decisions as to whether contributions are complete or need additional work.
Contributor review will be performed at the end of each contribution. The team member making the
contribution will personally review the entirety of the submission for standards compliance. If the
contribution is software, automated test results will be reviewed at this time.
Team review will be performed at the end of each development process. The project manager and all
contributors will review the developed products. All test results and the software requirements will
be considered in this review.
Advisor review will be performed upon completion of each development product. Advisor review
may include any relevant information provided by the team and will be heavily weighted in future
decision making by the team.
Formal sponsor review is required only for deliverables. Sponsor review of the software ultimately
dictates the success of the project. As such, informal sponsor feedback will also be heavily weighted

Project Charter 13

in order to minimize the likelihood of sponsor review rejections.

3.7 Change Management

The team recognizes the inevitability that schedules and requirements will change over the course of
a year-long development effort. Changes to the project will be managed in different ways depending
upon the type and time of discovery. All change management procedures will utilize the issue
tracking tools to report, update, and resolve changes.

3.7.1 Schedule Control

During the initial planning process, functional requirements will be assigned to iterations based on
priority, level of effort, and feasibility. During subsequent iterations, as priorities shift, effort
estimates are revised, or feasibility is re-assessed, schedule change reports will be logged with the
issue tracking tools. Schedule change reports which apply to the current iteration will be marked as
high priority and team will resolve the report at the earliest possible meeting by amending the
schedule or closing the report. Schedule change reports which apply to future iterations will be
marked low priority and will be reviewed together during the delivery process retrospective analysis.
Prior to beginning the next iteration, all open schedule change reports will be considered and
resolved by the team.

3.7.2 Requirements Change

Three types of requirements will be specified throughout the project: architectural, functional, and
non-functional. Changes to architectural requirements directly affect the structure of the system and
are the highest priority. Changes to non-functional requirements indirectly affect the system and
may be more difficult to apply, therefore they are low priority. Changes to functional requirements
may affect a very large or a very small portion of the system and the priority must be determined in
context.
Architectural requirements will be elicited and analyzed during initial planning and will be used
during the initial design process and iteration planning. If architectural requirements change during
the first iteration, the related design and implementation should be immediately updated to
accommodate the change. If architectural requirements change during a subsequent iteration, a high
priority requirements change report will be recorded in the issue tracking system and reviewed as
soon as possible by the entire team. Upon review, one or more team members should be tasked with
revising the system design specification to apply the change throughout the software. During the
integration activity of the phase in which the change occurs, the updated design will be implemented
and tested and the change report will be resolved.
Non-functional requirements are elicited throughout development and capture intangible qualities
which the software should exhibit, such as responsiveness or stability. If non-functional
requirements change at any point after the first construction process, a low priority requirements
change report will be logged in the issue tracking system. During the next retrospective analysis, low
priority requirements change reports will be assessed for implementation and the reports marked as
resolved.
Project Charter 14

Functional requirements vary in scope, priority, and level of effort. As functional requirements
change, a requirements change report will be logged with the issue tracking tools. The report will be
assigned an appropriate priority based on whether it applies to previous iterations, the current
iteration, or subsequent iterations, the effort required to resolve it, and priority of the requirements
which have changed. The assigned priority will determine whether the team immediately reviews
and addresses the report or reviews it during the next retrospective analysis.

3.7.3 Change Negotiation

In the event that any change initiated by the project sponsor will result in significant impact to the
project, the change report will be assigned high priority and immediately reviewed by the team. The
team will present the sponsor with an impact assessment which will include the effects of the change
on scheduling, likelihood of success, and related components. The sponsor and the team will decide
upon the best course of action with respect to the change and the change report will be marked as
resolved.

3.8 Risk Management

The risk management strategy for the project will be to assess and track the likelihood and impact of
major risks in the project documentation. A risk reassessment will be performed by the project
manager at the completion of the first iteration. If at any time a risk is realized, an issue will be
reported which references the original risk assessment. Where the risk assessment specifies a
contingency, that plan will be applied. Once the issue is resolved, the team will reassess the risk and,
if necessary, update the risk management plan. Several identified catastrophic risks are listed in
Table 3-4.
Description

Likelihood

Risk Mitigation

Impact

Contingency

Sponsor
withdraws from
the project.

The team will maintain

communication and a
positive rapport with
the sponsor to
minimize the
likelihood of
conflict-based
withdrawal.

10

In the event the sponsor is

unable to continue with
the project, the team will
attempt to identify a
substitute, such as a
faculty member with an
interest in game
development.

Team member
withdraws from
the project.

The team will uphold a

set of behavior
guidelines to avoid
conflict related
attrition. Other
sources of attrition are
assumed to be
unlikely.

If one or two members

withdraw, the team will
adjust the schedule and
requirements. The project
is unlikely to succeed if
more than two members
withdraw.

Major

The iterative process

The requirements change

Project Charter 15

requirements
change during
later iterations.

defers effort
investment in
requirements prior to
implementation.

management procedures
will allow the team to
evaluate the most
appropriate course of
action.

Realized level of
effort
significantly
exceeds
estimates for an
iteration.

Rapid prototyping and

feasibility reviews at
the beginning of each
iteration will minimize
investment in features
which are too costly.

The schedule change

management procedures
will allow the team to
adjust the schedule as
necessary. The
methodology also allows
for additional team
members to be assigned
construction duties for
complex iterations.

Realized level of
effort
significantly
exceeds
estimates for the
project.

During the initial

planning process, the
team will attempt to
refine the effort
estimates based on
actual development
progress.

The iterative process with

continuous integration is
proposed primarily to
address this risk. Beyond
the first iteration, a
functional system that
satisfies a subset of the
requirements will exist. If
one or more iterations
must be cancelled, this
system will be
deliverable.

Table 3-4 Potential Risks and Solutions

3.9 Technical Methods

3.9.1 Methods, Tools, and Techniques
The team will produce UML use cases, state transition diagrams, sequence diagrams, and class
diagrams during the planning and modeling processes.
Defects, changes, and risks will be reported and tracked using a web-based issue tracking tool.
The software will be packaged in one or more Visual Studio or equivalent projects. Contributions to
the software will be tracked and merged using a distributed version control system.
Documents will be created and synchronized using Google Chrome apps for Google Drive, including
Docs, Sheets, and Draw.io.
Daedalus will communicate primarily through GMail. Electronic meetings will be held on Google
Project Charter 16

Hangouts or equivalent. Formal communication--submissions, reviews, and approvals--between the

team and the advisor or sponsor will be held in a project email account for traceability.

3.9.2 Software Documentation

The team will make use of a flexible strategy for project documentation. As each documentation
process begins, the project manager will be responsible for creating a template and contents list for
each document. Documentation progress will be measured against this contents list and any
subsequent modifications. This strategy will encourage contributors to make minor submissions and
corrections to the project documentation without the need for unproductive formality. The
automatic revision tracking in Google Docs will allow the team to identify specific contributions if
necessary.

4 Contributors
The following section includes development team comments, the version history of this document,
and approvals from each team member.

4.1 Comments
This document is intended to reflect the best efforts of all contributors. Decisions, errors, and
omissions in this and all subsequent documentation are the responsibility of the team and not
individual contributors.
Some sections of this document have been reorganized, removed, or merged from the instructions in
order to support the purpose of the charter and to provide greater elaboration of the methodology
proposal, which is a significant departure from the standard methodology.
Several sections have been appended to this document in order to facilitate its direct adoption as the
Project Management Plan. Upon approval by the advisor and sponsor, this document, along with any
requested amendments, can serve as the official Project Management Plan, allowing the team to
immediately begin development.

Project Charter 17

4.2 Version History

Date

Sections

Contributors

9/18/2013

Table of Contents, Headers, 1.1, 1.2

Tim

9/19/2013

2.1, 3.3, 3.4, 3.5, 4.2, 4.3, Appendix B

Tim, Ethan

9/20/2013

1.3, 1.5, 2.2, 3.1, 3.2, Appendix A

Tim, Tate

9/21/2013

2.3, 3.1.2, 3.6, 3.7, 4.1

Tim, Ken

9/22/2013

1.3, 1.5, 4.1, Appendix B, Review and Revision

Tim, Ken

9/23/2013

Review and Revision

Tim

Table 4-1 Version and Revision History

4.3 Approvals
Upon signed approval by all members of the development team, the advisor, and the sponsor, the
descriptions and methodology proposal contained in this document will be officially adopted for the
Wings project.
1. Team Members
a. Tim Shea

____________________________________________

b. Ethan Weidman

____________________________________________

c. Chris Lawson

____________________________________________

d. Ken Barnett

____________________________________________

e. Tate Chamberlain

____________________________________________

2. Advisor
a. Ahmed Salem

____________________________________________

3. Sponsor
a. Josh Klint

____________________________________________

Project Charter 18

5 Appendices
Appendix A: Deliverables
Product

Description

Prospectus

Describes the goals of the CSUS Computer Science senior project, of

the team, and of the members. Provides the qualifications of the
team members.

Charter

Describes the Wings project and includes a project management

proposal. Establishes the milestones, roles, and processes for the
project.

Project Management Plan

Details the schedule, roles, and processes proposed in the charter.

Establishes guidelines, standards, and team member
responsibilities. Describes risks and risk management contingencies.
Describes issue tracking procedures. Specifies models, tools, and
standards to use in project documentation. Estimates resource and
labor requirements.

Software Requirements
Specification

Specifies the users, interfaces, and functions the software must

perform and the properties it must exhibit at a level of detail
sufficient to develop a software design.

Software Design
Specification

Specifies the architecture and behavior of the software from a

variety of perspectives. Describes alternative designs. Provides
rationale for design decisions. Specifies languages, tools, and
methods to be used during construction.

Software Test Specification

Specifies unit, integration, and system tests which the software

should satisfy. Specifies the testing methods and tools to be used.

User Documentation

Explains the software, its purpose, its functions, and how to use it in
a format sufficient for end users.

Software

The systems, applications, or libraries and the documented source

code of the project.

Table A-1 Project Deliverables

Appendix B: Cost Estimate

We are a five person development team with a total of 31 weeks to create the final product. Our pay
per individual would correlate to what an intern in the software development industry would make,
which is estimated at $15/hr. While the weekly commitment per team member varies, each team
member will spend on average 6-7 hours per week on the project.
With respect to the information given above Table B-1 describes a cost estimate for each deliverable
Project Charter 19

that will be produced during the course of the project. Each deliverable includes the the
approximate hours it will take to produce and how much that product will ultimately cost to produce
based on those hours. The second half of the table estimates the cost of resources that will be
consumed during the course of development.
Disclaimer: This section is included as an example of cost estimation and, as such, does not represent
actual costs incurred or costs for which reimbursement is sought.
Direct Labor Costs
Deliverable

Hours

Cost ($15/hr)

Prospectus

$75

Charter

20

$300

Project Management Plan

$75

Project Website

10

$150

Software Requirements Specification

50

$750

Software Design Specification

75

$1,125

Software Testing Specification

25

$375

Prototypes

40

$600

Wings Software Product

200

$3,00

End-User Documentation

15

$225

Presentation

$75

Meeting Costs

70

$1,050

Printing

$30

521

$7,830

Inception

Iterations I - IV

Completion

Miscellaneous

Total Work:

Project Charter 20

Resource Costs
Resource

Cost

Office Supplies

$40

Research/Reference Materials

$100

Development Tools

$200

Total:

$340

Grand Total:

$8,170
Table B-1 Estimated Project Costs

Appendix C: Partnership Guidelines

B.1 Requirements Guidelines for Project Sponsors
The project sponsor has the right to:
1. Expect the team to understand the business and business objectives.
2. Have the team explain requirements development processes.
3. Expect the team to treat you with respect and to maintain a collaborative and professional
attitude.
4. Have the team present ideas and alternatives.
5. Be given good-faith estimates of the impacts and trade-offs when you request a change.
The project sponsor has the responsibility to:
1.
2.
3.
4.
5.
6.

Be available to elicit requirements and iteratively refine them.

Understand and approve elicited requirements.
Make timely decisions about the system when requested to do so.
Respect developers assessments of scope and feasibility.
Set priorities for individual requirements, system features, or use cases.
Review prototypes, documents, and deliverables.

Project Charter 21