Edge Time Glider Simulation Project

Preliminary Project Plan

0707250dc090a14d198c41e66637ba16.doc

March 15, 2006

Rochester Institute of Technology

Powered By Rochester Institute of Technology Glider Simulation – Draft 1

Revisions

Version Primary Description of Version Date Author(s) Completed 0.01 Matthew Mullin Initial revision 12/3/05 1.00 All Merged reviews between all team members 12/15/05 1.01 Matthew Mullin Refined document and added content to all 12/26/05 sections 2.00 Matthew Mullin Made minor changes based on feedback 1/11/06 2.01 Matthew Mullin Fixed typo in configuration management sec- 1/30/06 tion. Added location of Vision and Scope document in scope section. 2.02 Matthew Mullin Changed glider name from Schweizer I-26 to 2/1/06 Schweizer 1-26, and added operating system information in platform section. 3.00 Matthew Mullin Updated process methodology and the metrics 3/15/06 section.

Review & Approval

Project Plan Approval History

Approving Party Version Signature Date Approved Norman Smith (Soar- ing Museum) Dr. Hawker Dr. Kochersberger

Contents

REVIEW & APPROVAL...... II

1 INTRODUCTION...... 1

1.1 OVERVIEW...... 1 1.1.1 Product Function...... 1 1.1.2 Platform...... 1 1.1.3 Stakeholders...... 1 1.1.4 Schedule...... 1 1.1.5 Goals...... 2 1.1.6 Scope...... 2 1.2 DELIVERABLES...... 2 1.3 ASSUMPTIONS AND CONSTRAINTS...... 3

2 MANAGEMENT STRUCTURE...... 4

2.1 PROJECT LIFECYCLE...... 4 2.2 PROJECT ORGANIZATION...... 4 2.2.1 External Interfaces...... 4 2.2.2 Internal Structure...... 5 2.2.3 Roles and Responsibilities...... 5 2.3 COMMUNICATION...... 6 2.4 RISK AND ASSET MANAGEMENT...... 6

3 PLANNING AND CONTROL...... 7

3.1 ESTIMATE...... 7 3.1.1 Estimation Process...... 7 3.2 RESOURCE ALLOCATION...... 7 3.2.1 Work Breakdown Structure...... 7 3.3 TRACKING AND CONTROL...... 8

4 TECHNICAL PROCESS...... 9

4.1 ENGINEERING...... 9 4.1.1 Environment...... 9 4.1.2 Methods, Tools and Techniques...... 9 4.2 TECHNOLOGY...... 9 4.2.1 Environment...... 9 4.2.2 Methods, Tools, and Techniques...... 10 4.3 PROJECT ARTIFACTS...... 10

5 CONFIGURATION MANAGEMENT AND QUALITY ASSURANCE PLANS...... 11

5.1 CONFIGURATION MANAGEMENT...... 11 5.2 QUALITY ASSURANCE...... 11 5.2.1 Goals...... 11 5.2.2 Ask Questions...... 11 5.2.3 Metrics...... 12

6 GLOSSARY...... 13

6.1 GLOSSARY...... 13

This project plan is the top-level controlling document for the glider simulation project.

1.1 Overview The National Soaring Museum (NSM) in Elmira, NY has sponsored a multi-disciplinary senior design project at RIT through the College of Engineering to construct a flight simulator for a Schweizer 1-26 glider. This simulator will be based around 3-degrees of freedom motion platform provided by The NSM, and is intended for use as an exhibit in the museum. During the initial design phase of this project, a number of desired features were identified which would require extensive software design and development. The original project schedule, team size and skill set did not allow for the inclusion of such a software project. As a re- sult, the College of Engineering requisitioned a Software Engineering (SE) Senior Project team to work in conjunction with them to complete the project.

1.1.1 Product Function The task that the Software Engineering team was primarily requisitioned for was to produce a visual display simulating the view from within the cockpit of a Schweizer glider. This display is to be presented to the simulator pilot and serve as a visual front-end for the flight dynamics engine of the simulator. It must therefore accept attitude and positional data and align the vir- tual camera appropriately. In addition, the team is to design a user interface for the flight simulator. This interface must allow the simulator to act as a standalone exhibit enabling museum visitors to enter and exit the simulator between flights. The NSM would like the view from the glider to be as accurate and close to the real world as possible. This includes adding landscape that is representative of the NSM airport as well as adding a tow plane that will take the glider up into the air and release the glider. (see Soft- ware Requirements Specification (SRS) for complete list of product functionality)

1.1.2 Platform Microsoft Windows XP with service pack 2.

1.1.3 Stakeholders See Vision and Scope Document located at: http://www.se.rit.edu/~edgetime

1.1.4 Schedule See the Edge Time Glider Simulation Microsoft Project file located at http://www.se.rit.edu/~edgetime

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 1 Powered by CxOne from Construx Software – Version 2.0 Rochester Institute of Technology Glider Simulation – Draft 1 1.1.5 Goals The project related goals for this project shall include creating a working visual display for a glider simulation. Creation of the visual display shall include working closely with stakeholders of the project as well as support of the multi-disciplinary College of Engineering team (MDCOE) in their portion of the project. It is also a goal that the project shall be completed on time, the product shall contain all of the desired functionality and all stakeholders shall be delighted with the quality of the finished product. The visual display shall be usable to a wide variety of users ranging from children to glider experts, and shall be as realistic as possible. The individual goals for this project include: learning how to work with a multi-disciplinary team on a larger scale project and gaining experience in all areas of the Software Engineering process to better prepare ourselves for our upcoming careers.

1.1.6 Scope See Vision and Scope Document located at: http://www.se.rit.edu/~edgetime

1.2 Deliverables At project completion, deliverables shall include: functional software, documentation, a pre- sentation and a poster. Table 1.1 lists the deliverables for this project.

Deliverable Description Source Code The source code required to build a visual display that accurately re- flects the movement and physical appearance of a Schweizer 1-26 glider. Project Documen- The updated project work products produced during each increment in- tation cluding the project plan, risk management list, project schedule Product Documen- The updated product work products produced during each increment in- tation cluding the SRS, design document, testing documentation Presentations The team presentations (one at the end of the Winter and Spring quar- ters) that give the details of the SE process being used for the project. Poster A poster shall be delivered at the end of the project to capture an overview of the project.

Table 1.1 Project deliverables

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 2 Powered by CxOne from Construx Software – Version 2.0 Rochester Institute of Technology Glider Simulation – Draft 1 1.3 Assumptions and Constraints The first assumption with this simulation is that the SE team shall be using a third-party software package to help with the development of the simulation. There is not enough time available to produce a high quality flight simulator package as well as implement all of the additional requirements from the NSM and the MDCOE. Using this third-party software, howev- er, constrains the SE team to the features that are available in the package. Another constraint is that this project is highly dependent on the work of the MDCOE team. This includes everything from the SE team’s requirements to the SE team’s development work since this project has to interface with the physical simulator hardware, and so any hardware design decisions can greatly affect the design decisions of the software. It is imper- ative that the MDCOE team produces a quality product on time so that any integration concerns can be addressed, and the project can reach completion by the end of the Spring 2006 quarter. It can be assumed that this project shall require significant schedule flexibility to allow for requirement/design changes by the MDCOE team.

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 3 Powered by CxOne from Construx Software – Version 2.0 Rochester Institute of Technology Glider Simulation – Draft 1 2 Management Structure

2.1 Project Lifecycle The project lifecycle shall be a combination of two process methodologies, the waterfall with subprojects and the design-to-schedule. Since the requirements have remained stable throughout the project, the waterfall model suffices up to the design stage. At the design stage, the major features of the project shall be broken off into subprojects so that each team member can be accountable for a specific feature, and all team members can work in parallel on their respective features. The design-to-schedule component of this methodology is used to prioritize the features of this project. Since there are a large number of features, there is a good chance that all of them may not be implemented due to the time constraint. Therefore, the design-to-schedule shall prioritize the features, and those features shall be implemented in order until the project deadline is reached. This process shall be incremental, and at the end of each increment evolutionary prototypes shall be produced to ensure that the entire glider simulator group (both MDCOE and SE teams) is in agreement with the graphical design and interfaces. Specific tasks, estimates, and activities in each increment shall vary depending on feature priority levels, and time remaining in the project.

2.2 Project Organization

2.2.1 External Interfaces Figure 2.1 expresses the external interfaces affiliated with the Edge Time project team.

National Soaring Museum

Professor Kochersberger

Developer 1 Kara Developer 2 Developer 3 Ryan Developer 4 Jonah Mather Brittany Soracco Stoddard Williams

Figure 2.1 External Project Interface

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 4 Powered by CxOne from Construx Software – Version 2.0 Rochester Institute of Technology Glider Simulation – Draft 1

2.2.2 Internal Structure Figure 2.2 expresses the internal structure of the Edge Time project team.

Project Coach Professor Hawker

Christopher Guy Matthew Mullin Karen Roth Zebulon Ford-Reitz Stefan Schmid Development Engineer, Development Engineer, Development Engineer, Development Engineer, Development Engineer, Website Lead, Technical Point of Contact (SE Point of Contact Testing Lead Metrics Lead Lead Department), Risk (Soaring Museum)

Management Lead, Project Schedule Lead

Figure 2.2 Internal Project Structure

2.2.3 Roles and Responsibilities

Role Responsibility Project Coach Responsible for project assessment, and providing guidance to project developers as needed. Development Engineer Responsible for gathering requirements, system design, construction and verification of source code, unit tests, system tests and related documentation. Point of Contact ( Soaring Responsible for communicating with the Soaring Museum as need- Museum) ed. Point of Contact (SE Depart- Responsible for communicating with the SE Department as need- ment) ed. Risk Management Lead Responsible for identifying and prioritizing risks as well as ensure that mitigation strategies are implemented in the development process to deal with the top risks. Project Schedule Lead Responsible for the creation and updates of the schedule. Metrics Lead Responsible for determining the process to collect and publish metrics that are pertinent and valuable to the project. Testing Lead Responsible for organizing and overseeing the testing activities in the project. Website Lead Responsible for the creation and maintenance of the project website. Technical Lead Responsible for communications with the system administrator to ensure that the team has all of the necessary software tools.

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 5 Powered by CxOne from Construx Software – Version 2.0 Rochester Institute of Technology Glider Simulation – Draft 1 2.3 Communication A high level of inter- and intra-team communication shall be required in this project. There shall be a weekly meeting between representatives of the SE team and the MDCOE team along with the advisors for each. This meeting shall ensure that everyone in the project is on the same page. Representatives of each group shall be responsible for sharing the meeting information with their group members after the meeting. Representatives shall entertain requests for design changes and the addition or deletion of functionality, but shall not give definitive answers to the MDCOE team until after the entire team has had a chance to discuss the proposal. The software team shall also have a minimum of two weekly team meetings. The SE team shall write a weekly update letter to the Soaring Museum, so that they are kept up to date on the project and have the opportunity to provide feedback and requirements changes.

2.4 Risk and Asset Management All risk management activities shall be captured in the risk list spreadsheet. Activities include, but are not limited to, risk identification, risk exposure calculation, risk prioritization, risk mitigation strategies and risk tracking. The Risk Management Lead shall analyze the highest priority risks for each increment, and shall incorporate mitigation strategies for those risks into the software development process.

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 6 Powered by CxOne from Construx Software – Version 2.0 Rochester Institute of Technology Glider Simulation – Draft 1 3 Planning and Control

3.1 Estimate

3.1.1 Estimation Process Project work shall be divided into increments. Estimates for work to be accomplished in the first increment shall be arrived at through group consensus of the SE team, using function points and past experience as guidelines. Estimates for increments beyond the first shall be arrived at in a similar manner, with the ex- ception that additional information will be available: Project Velocity (see Metrics section) shall be used to gain an understanding of the accuracy of previous project estimates. This information shall be taken into account when estimating work to be accomplished in further increments.

3.2 Resource Allocation

3.2.1 Work Breakdown Structure The Work Breakdown Structure is a hybrid model that incorporates both product and process goals.

1. Project Management a. Website i. Templates ii. Content iii. Graphics iv. Site layout b. Requirements Gathering c. Presentations i. Intermediate ii. Final iii. Poster d. Design e. Implementation f. Project Scheduling g. Risk assessment i. Identification

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 7 Powered by CxOne from Construx Software – Version 2.0 Rochester Institute of Technology Glider Simulation – Draft 1 ii. Prioritization iii. Mitigation strategies h. Testing i. Unit ii. Subsystem iii. System iv. Acceptance i. Documentation i. User ii. Developer j. Metrics i. Conception ii. Gathering iii. Analysis

3.3 Tracking and Control The Metrics Lead shall be responsible for the organization of metric collection and publica- tion throughout the project. The Metrics Lead shall delegate metric-gathering responsibilities, and verify that those responsibilities are carried out. The metrics shall be published in order to provide value to the project. The entire team and other stakeholders can analyze the metrics in order to improve aspects of the current project, as well as use the metrics as bench- marks for similar future projects.

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 8 Powered by CxOne from Construx Software – Version 2.0 Rochester Institute of Technology Glider Simulation – Draft 1 4 Technical Process

4.1 Engineering The following engineering environment, tools, and methods shall be used to complete the glider simulation project.

4.1.1 Environment The environment for the MDCOE team shall be the flight dynamics lab room found in the RIT COE building. Therein shall be housed the computer and motion platform for the simulator. The environment in which the software engineering team shall be working includes the facili- ties in the Golisano College of Computing and Information Sciences building (SE lab, team rooms, and senior project room). An Edge Time exclusive computer shall be located in the senior project room. This computer shall be used primarily for development and testing of simulation code.

4.1.2 Methods, Tools and Techniques The SE team shall have a high communication and interaction rate with the MDCOE team al- lowing the team to be very agile in our development. The SE team shall also utilize an itera- tive design methodology, so that prototyping can be used gain feedback from the MDCOE team. The SE team shall have access to all of the rooms in the Golisano College of Computing and Information Sciences building (designated in the previous section), and the MDCOE team shall have access to the glider and computer in their building (also noted in the previous section).

4.2 Technology The following technology environment, tools, and methods shall be used to complete the glider simulation project.

4.2.1 Environment Computer (in COE building) 1 GB RAM (2 X 512) 80 GB HD Athlon 64 Motherboard (ASUS A8N-E ATX) DVD ROM drive Athlon 64 3700+ 1GHz FSB Socket 939 Linux OS (Ubuntu)

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 9 Powered by CxOne from Construx Software – Version 2.0 Rochester Institute of Technology Glider Simulation – Draft 1 Computer (in Senior Project Room / common labs) 1 GB RAM 20 GB HD 1.8 GHz Pentium 4 Windows OS (winxp like in labs) / dual boot with linux OS (ubuntu)(not in common labs) Code The code shall be managed using CVS and shall be written in C++ and some in XML. The graphics shall be managed in GLUT OpenGL. Compiler The software engineering team shall be using GCC to compile the code, FreeGlut for the graphics, OpenAL for audio, plib for portable libraries and scene graphics, and SimGear simulation construction tools.

4.2.2 Methods, Tools, and Techniques The software engineering team shall be using CVS for version control with the code and doc- uments. (TBD other tools such as IDE, testing etc…after platform decided upon)

4.3 Project Artifacts Artifact Name and Description Change Control Sign Off Authority Risk List X Matthew Mullin Vision and Scope X Karen Roth SRS X Karen Roth Project Schedule X Matthew Mullin User Manual X Zebulon Ford-Reitz Design Document X Christopher Guy Source Code X Stefan Schmid Metrics Stefan Schmid Test Plan X Zebulon Ford-Reitz Test Documentation Karen Roth Website Christopher Guy Project Plan X Matthew Mullin .

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 10 Powered by CxOne from Construx Software – Version 2.0 Rochester Institute of Technology Glider Simulation – Draft 1 5 Configuration Management and Quality Assurance Plans

5.1 Configuration Management Configuration management shall be handled through the use of CVS. Appropriate comments shall be added to each commitment to reflect changes. All documentation shall be versioned and added to CVS as well as code artifacts. The FlightGear software modifications shall be baselined and stored when important goals are met, deadlines are achieved, and when builds are issued to the MDCOE team to record important configurations throughout the project. Version numbers for artifacts shall be incremented as follows: artifacts shall start at version 0.01 and shall increment by hundredths after each revision. Whole number values shall be re- served for official releases. This allows for 99 revision changes between each official release. If a document has a revision history section, then the revision information shall be kept there. Otherwise, the version number of the document shall be kept in the file name.

5.2 Quality Assurance

5.2.1 Goals Ensure that deadlines for deliverables and other project milestones are met by making sure that work on the project progresses in a steady manner. Ensure that all areas of the project receive work effort, with emphasis on the important milestones. Project requirements are understood and specified as early as possible in the project to main- tain a clear picture of what tasks need to be accomplished for any of the project stakeholders. Properly scope releases, and determine scheduling.

5.2.2 Ask Questions How much progress has been made so far? Is the project group making enough progress to meet the specified deadlines and milestones? What areas of the project have received enough attention from group? What project activities should be receiving more or less attention than they are? Are all of the requirements understood and realized sufficiently? Is more requirements elicitation necessary? How much work was accomplished in the previous iteration?

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 11 Powered by CxOne from Construx Software – Version 2.0 Rochester Institute of Technology Glider Simulation – Draft 1 5.2.3 Metrics The following are a list of metrics intended to be recorded during the project to assess prob- lem areas and chart project progress. After the first quarter of work, it was determined that the original metrics chosen were not the easiest to assess for our project and not extremely useful. Three different metrics have been chosen for use in the second quarter of project work. The metrics below are labeled either 1st or 2nd quarter, appropriately.

Slippage Chart: Measure difference between project milestone scheduled completion dates and actual completion dates. Plot total slippage throughout entire project lifecycle. (1 st Quar- ter Metric) Effort by type of activity: Map effort to the area of the software development cycle with which it is associated to track what project areas are receiving enough attention and which areas may require more/less, and also determine the efficiency of the work so far. (1 st quarter metric) Requirements Volatility: Track how many requirements are modified, added, or deleted within the scope of the project to determine the effectiveness or lack thereof of the project’s requirements elicitation process. (1st quarter metric) Velocity: Track the amount of progress made in each iteration, based on the amount of function points completed. (1st quarter metric) Total number of open issues/concerns: Track the number of currently open concerns in the project. Looking at this on a weekly basis helps show the amount of progress made, as well as faults in requirements or planning if many new issues and concerns appear as time passes. Documented through Mantis issue tracker database. (2nd quarter metric) Earned value per milestone: Give significant project milestones an earned value rating on a 1 to 10 scale. This value is only added to total earned value when the milestone/issue is closed and completed. Documented through Mantis issue tracker database. (2nd quarter metric) Man hours per week: Track the total number of hours worked by the entire team weekly in the areas of planning, documentation, coding, research, testing. (2nd quarter metric).

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 12 Powered by CxOne from Construx Software – Version 2.0 Rochester Institute of Technology Glider Simulation – Draft 1 6 Glossary

6.1 Glossary Term Definition NSM National Soaring Museum MDCOE/Multi-Disciplinary COE Multi-Disciplinary College of Engineering COE College of Engineering HD Hard Drive RAM Random Access Memory OS Operating System GB Gigabyte MB Megabyte SE Software Engineering SRS Software Requirements Specification

0707250dc090a14d198c41e66637ba16.doc (03/20/06) Page 13 Powered by CxOne from Construx Software – Version 2.0