Download Software Engineering - Project Reports | CMSC 435 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity!
CMSC 435 Class Group Projects Version 4.0 – April 15, 2009
Everyone in the class will be assigned into groups of 4 or 5 students. Grades for the project will be the same for all members of the group. For each phase, everyone will be reassigned into different groups. Part of the learning experience in CMSC 435 is to learn how to work within groups and to negotiate so that everyone comes out ahead.
The overall project is to enhance the TSAFE prototype air traffic control system with 3 new features. The basic TSAFE system can be downloaded from the class webpage. This document describes the four phases of the project and what each group has to do within each phase.
General guidelines:
All submissions shall be to the submit server (submit.cs.umd.edu). You can submit as many times as you want, up to the deadline, so submit early and often. There is no penalty for multiple submits. However, for each group only the support manager shall submit a single zip file representing the submittal from the group.
Members of each group shall take on 5 roles:
- Programmer or software designer – Every group member shall assume this role as needed.
- Manager – Major decision maker for group. The manager is specifically charged with developing a work breakdown structure (WBS) of the group and estimating the effort needed to complete the project.
- Chief Programmer – Chief designer or implementer of the group
- Support manager – In charge of the documents required to be submitted and is charged with submitting the final product of the group
- Quality manager – Develops test plan for the group
The four phases are:
- Design – Due February 24, 2009, 11:59pm. – Develop designs for the new TSAFE features.
- Implementation – Due March 26, 2009 11:59pm – Implement the new features.
- System test – Due April 16, 2009, 11:59pm – Test an implementation.
- Packaging – Due May 4, 11:59pm – Prepare an implementation for delivery and self-installation.
Details of each phase: I. Design phase due February 24: Design the changes needed to be made to TSAFE. Everyone on the team needs to help on all the deliverables as needed. Deliverables include: − Manager – WBS of the implementation part of the project, risk assessment for the implementation, and an estimate of the development time and effort. − Chief programmer – A list of TSAFE classes that need to be modified and a design document for each describing the changes. Manager can assign others in the group to help with the design of individual java classes. − Support manager – Responsible for packaging all the deliverables and submitting them to the submit server on time. − Quality manager – Develops a series of test cases that can be used to test the implementation later. − Everyone – A time sheet filled out. (See class website) − Everyone – A group evaluation form (See class website). However , everyone should separately submit this to the submit server rather than collectively as part of the group submittal.
WBS structure
The WBS needs to be an estimate of phase 1 activities, phase 2 activities by class or activity, and the rest of the project (by phase). Your WBS should be a table similar to the following:
ITEM Who Implementation (Hours) Manage project John 12. Quality manager Amy 15. Support manager George 18. Overall design (Chief Prog) Julie 22. Class designs All 23.
Management Phases 2 37. Chief programmer Phase 2 16. Class1.java Phase 2 4. Class2.java Phase 2 6. Class3.java Phase 2 2. Class4.java Phase 2 3. Class5.java Phase 2 8.
System testing Phase 3 40. Packaging Phase 4 20.
II. Implementation phase due March 31: Access the 7 designs submitted by the groups as part of Phase I. They will be available in the private part of the class website sometime on Wednesday, February 25. Perform a feasibility study on all of the 7 submitted designs and choose one of the 7 to implement. At most three groups can implement any one design so get your requests in (as email to Dr. Zelkowitz to [email protected]) as soon as you can. Once your choice has been approved, implement the designs. Earliest email arrival time will determine which group gets access to a project in case 4 or more groups request the same project to implement.
Each team can choose their own roles, provided no one has the same role as during Phase I.
By the deadline, the manager of the group will submit a single ZIP file to the submit server.
The ZIP file shall contain the following artifacts:
- A readme.txt file giving the contents of the submitted zip file (not the TSAFE zip file).
- A zip file of the modified TSAFE (TSAFE 2.x, where x is your group number). It should have a similar structure as the original TSAFE zip file and installation of TSAFE should be in the same manner. This TSAFE should have all of the implemented enhancements installed. If you are unable to implement all of the enhancements, your TSAFE should have as much implemented as you can manage.
- A feasibility study describing how you picked the version of phase I to implement.
- A modification of the design document you obtained from phase I corrected to the version that you implemented. This included information on which Java classes were modified or added.
- Additions of the tests you developed in addition to the test data you were given from phase I.
- An errata document describing errors you found in your phase I input, which you had to correct.
Each person is expected to help on all phases of the delivery.
Tasks:
- Document specialist
- Prepare a readme.txt file which says how to install TSAFE
- Prepare a word document with a simple users guide to using the product
- Prepare any other documentation that you think necessary
- Library specialist
- Build the final delivery zip file. The zip file should not contain any embedded zip files. The directory structure once unzipped should be the same as in the original tsafe with the following additions:
- At the root level, in addition to datafiles, lib, and tsafe directories, there is an additional doc directory with all of the documents that are to be included.
- At the root level is also a jar file with the name tsafe.jar which is an executable version of the tsafe product. It should be executable via the command “make run” or by clicking on the jar file.
- At the root level is also a copy of server.jar and a sample test1.txt data for the server.
- Presentation specialist
- Prepare a PowerPoint presentation giving the virtues of the product you have packaged. This PowerPoint presentation should be included in the doc directory of the deliverable.
- Organize the presentation to the class (see below).
Each group will prepare a 10-15 minute presentation of the product they are evaluating in order to convince others to “buy” and use that product. These presentations will occur on the last 2 classes of the semester – May 5 and 7. At least two or more of the team members should participate in the class presentation. The presentation can be simply the PowerPoint presentation, but may also include a live demonstration of the product, showing its interesting features. (Note: During phase 3 you are to try and find defects in the product you test. But in phase 4 you are a promoter of the product. That doesn’t mean you can lie about its virtue, but you should not intentionally show defects and flaws in the system. You are trying to get people to use this product.)
Requirements for TSAFE upgrades:
1. Command line interface:
The current graphical output for TSAFE is not designed for showing more specific data like the detailed position of a plane, it’s speed, or it’s heading. A textual output can show you all these details, which makes testing the system much easier and more comfortable.
A command line and a command interpreter extend the functionality of the textual output window, so that the user has the same possibilities as in the graphical client.
Requirements:
- Create a new client module including a new textual output window for presenting the results (e.g. flight data^1 ); updates are in the same interval as in the graphical client module
- Each client module should be able to run by its own.
- On each update show the current settings on the console and then the available flight data.
(^1) flight data includes: aircraftid and its data like longitude, latitude, altitude, speed, and heading in readable format
(e.g. 55º 67’ north for latitude). Other data like flight plan and trajectory depend on whether they should also be shown or not.
- Textual output window includes a console and a command line for typing in the commands (see syntax below)
- Develop your own InputParser for this module, which can easily be expanded for future features of TSAFE.
- On “Enter” (from keyboard or button “Enter”): read in text from command line and parse input. If parsing is successful, clear command line and execute given command. If settings were changed, confirm these changes; when command doesn’t conform to syntax return an error message and show it on console.
- If a command has more parts than necessary, it should be handled like an invalid command.
- Whenever the settings are changed, these are valid for both output windows. Thus when a change was made in the textual output window, it also affects the graphical output window and vice versa.
- Show adequate warning in console when danger ahead (color, font size / type) Use a JTextPane for the console. As a default style for the different font types use javax.swing.text.StyleContext.DEFAULT_STYLE. Show the flight id in size 16 and in bold. For each flight list the flight id followed by the current flight position, and if existing, the information about the flight plan, trajectories and the flight’s conformance status. If the plane is blundering, highlight this by showing the conformance status and the flight id in red.
Example for output on console:
1.1 Syntax for the Command Line Interpreter
Keywords:
their separation. Loss of separation could lead to a dangerous situation. Therefore, the Loss-of- Separation detector will identify all planes that are too close to each other so that appropriate instructions can be given to the pilots either by an air traffic controller or by the software itself.
Requirements: To check if two planes are in conflict, the detector will start with the current position and then it will advance the two planes’ trajectories in given time steps till a maximum probe time is reached. On every time step, the detector will calculate the horizontal and vertical distances and compare them to the specified threshold values. For each plane, TSAFE uses one of two ways to calculate the trajectory. The nominal assumes that the plane stays on its flight plan. The dead- reckoning calculates the trajectory depending on the speed and heading of the flight. If TSAFE has determined that a plane with a flight plan is not blundering, then the detector will use the nominal trajectory; otherwise it will use the dead reckoning trajectory. On every update of the user output, the detector will compare every plane with every other plane.
On the GUI, every plane that conflicts with another will appear in orange. If the plane is also blundering it will appear in pink.
As part of this change request, a new option tab for the Loss-of-Separation detector will be added in the “Tsafe Preferences” window (menu bar: Parameters). It will be possible to turn the detector on and off and to set the distance thresholds (default: 22,000 meters horizontal distance, 1,000 meters vertical), the interval size (default: 10 seconds) and the probe length (default: 4 minutes).
Algorithms: To calculate the distance between two points, given in latitude and longitude, you will use this formula:
cos *cos *sin 2
2 * *arcsin sin
distanceinmeters
Latitude Longitude 6 , 367 , 000 (radiusoftheearthinmeters)
2 2 1 1 2
2 δ 2 δ (^1) δ δ λ^ λ
δ λ
G R
G
R
Extensions: There are some improvements that will be implemented to increase the usability of the detector:
- Instead of changing the color of the plane when separation is lost, draw a red circle in the size of the minimal horizontal distance around it.
- To make it more obvious what flights are in conflict, add a red line connecting the two flights.
- To make it easier to test the new feature, add a textual output that shows every conflicting pair of flights in the following way:
“Conflict: Flight1: LHA675 Flight2: US652 Distance: 300 feet and 3 nm at the current time +30 seconds” (replace these example values with real values)
Change data: The following data demonstrates two planes show loss of separation after some time.
0000000000000000TZ LOSFL1 300 040 4130N/07255W 0000000000000000TZ LOSFL2 300 040 4131N/07134W 0000000000000000TZ LOSFL1 300 040 4135N/07252W 0000000000000000TZ LOSFL2 300 040 4140N/07144W 0000000000000000TZ LOSFL1 300 040 4143N/07246W 0000000000000000TZ LOSFL2 300 040 4145N/07154W 0000000000000000TZ LOSFL1 300 040 4150N/07241W 0000000000000000TZ LOSFL2 300 040 4152N/07204W 0000000000000000TZ LOSFL1 300 040 4159N/07234W 0000000000000000TZ LOSFL2 300 040 4159N/07217W 0000000000000000TZ LOSFL1 300 040 4206N/07228W 0000000000000000TZ LOSFL2 300 040 4206N/07230W 0000000000000000TZ LOSFL1 300 040 4214N/07220W 0000000000000000TZ LOSFL2 300 040 4211N/07242W 0000000000000000TZ LOSFL1 300 040 4222N/07213W 0000000000000000TZ LOSFL2 300 040 4220N/07254W 0000000000000000TZ LOSFL1 300 040 4230N/07204W 0000000000000000TZ LOSFL2 300 040 4226N/07307W 0000000000000000TZ LOSFL1 300 040 4238N/07157W 0000000000000000TZ LOSFL2 300 040 4231N/07315W 0000000000000000TZ LOSFL1 300 040 4246N/07148W 0000000000000000TZ LOSFL2 300 040 4240N/07326W 0000000000000000TZ LOSFL1 300 040 4253N/07138W 0000000000000000TZ LOSFL2 300 040 4248N/07339W 0000000000000000TZ LOSFL1 300 040 4259N/07131W 0000000000000000TZ LOSFL2 300 040 4253N/07346W
Replace the content of the test1.txt file in the server folder with this data and start server.jar in order to run it.
3. Dynamic Maps:
TSAFE is currently using the map of Massachusetts, and cannot be used for flights that fly elsewhere. Therefore TSAFE will be extended with functionality in order to make it possible to change the map dynamically during run time without interrupting its operations.
Requirements:
- Insert into the menu the option to change maps while running TSAFE by adding a new tab to the “Parameters” dialog called “Dynamic Maps.” This tab should include a combo box
06300W
File format of the text file with extra maps:
Washington
file washington.jpg
latmin 4524N
latmax 4912N
lonmin 12500W
lonmax 11630W
North Dakota
file north_dakota.jpg
latmin 4542N
latmax 4912N
lonmin 10418W
lonmax 09724W
New Mexico
file new_mexico.jpg
latmin 3100N
latmax 3712N
lonmin 10930W
lonmax 10248W
TsafeTools.tar.gz: This is a tool for creating flight test data that you can run through TSAFE to test your version.
