Professional Documents
Culture Documents
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.
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
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.
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.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.
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.
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.
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.
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.
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.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
9/9/2013 - 9/30/2013
Iteration I
9/30/2013 - 12/20/2013
Planning
SRS 0.1
9/30 - 10/21
Modeling
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
1/27 - 2/10
Modeling
2/10 - 2/17
Construction
Wings 0.2
2/17 - 3/3
Delivery
3/3
Iteration III
3/3/2014 - 4/7/2014
Planning
3/3 - 3/17
Modeling
3/17 - 3/24
Construction
Wings 0.3
3/24 - 4/7
Delivery
4/7
Iteration IV
4/7/2014 - 5/12/2014
Planning
4/7 - 4/21
Modeling
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
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
Builder
Project Manager
Advisor
Sponsor
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)
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
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
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.
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.
Project Charter 13
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.
Likelihood
Risk Mitigation
Impact
Contingency
Sponsor
withdraws from
the project.
10
Team member
withdraws from
the project.
Major
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.
Realized level of
effort
significantly
exceeds
estimates for the
project.
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
Sections
Contributors
9/18/2013
Tim
9/19/2013
Tim, Ethan
9/20/2013
Tim, Tate
9/21/2013
Tim, Ken
9/22/2013
Tim, Ken
9/23/2013
Tim
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
Charter
Software Requirements
Specification
Software Design
Specification
User Documentation
Explains the software, its purpose, its functions, and how to use it in
a format sufficient for end users.
Software
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
$75
Project Website
10
$150
50
$750
75
$1,125
25
$375
Prototypes
40
$600
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
Project Charter 21