Project Charter

(1)

Project Charter

Wings by Daedalus, 9/23/2013

(2)

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.

(4)

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.

(5)

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 [email protected]

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

(6)

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

(7)

● 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 sponsor’s 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.

(8)

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

(9)

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.

(10)

Process Products (Deliverables₎ _Dates

Inception Prospectus, Charter, PMP 9/9/2013 - 9/30/2013 Iteration I 9/30/2013 - 12/20/2013 Planning SRS0.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 5/12

Completion 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

(11)

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.

(12)

Activity Estimated Effort (Person-Hours) Estimated Duration (Weeks) Planning 24 2(2People) Research 4 Prototyping 10 Requirements Engineering 10 Modeling 12 1(2People) Design 10 Test Specification 2 Construction 24 2(2People) Implementation 10 Testing 4 Integration 10 Delivery 4 ½(1Person)

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

(13)

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

(14)

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

(15)

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 c ases 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

(16)

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.

(17)

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.

1 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.

3 The team will uphold a set of behavior

guidelines to avoid conflict related attrition. Other

sources of attrition are assumed to be

unlikely.

7 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.

(18)

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.

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

5 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.

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

3 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.

(19)

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.

(20)

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 ____________________________________________

(21)

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.

(22)

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)

Inception

Prospectus 5 $75

Charter 20 $300

Project Management Plan 5 $75

ProjectWebsite 10 $150

Iterations I - IV

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

Completion End-User Documentation 15 $225 Presentation 5 $75 Miscellaneous MeetingCosts 70 $1,050 Printing 2 $30 Total Work: 521 $7,830

(23)

Resource Costs Resource Cost OfficeSupplies $40 Research/Reference Materials $100 DevelopmentTools $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. Be available to elicit requirements and iteratively refine them. 2. Understand and approve elicited requirements.

3. Make timely decisions about the system when requested to do so. 4. Respect developers’ assessments of scope and feasibility.

5. Set priorities for individual requirements, system features, or use cases. 6. Review prototypes, documents, and deliverables.