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
[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 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 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. 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
4
Prototyping
10
Requirements Engineering
10
Modeling
12
1 (2 People)
Design
10
Test Specification
2
Construction
24
2 (2 People)
Implementation
10
Testing
4
Integration
10
Delivery
4
½ (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 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
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.
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.
Major
3
The iterative process
5
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.
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. 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
5
$75
Charter
20
$300
Project Management Plan
5
$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
5
$75
Meeting Costs
70
$1,050
Printing
2
$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
