Software Engineering - Project Reports | CMSC 435, Study Guides, Projects, Research of Software Engineering

Download Software Engineering - Project Reports | CMSC 435 and more Study Guides, Projects, Research Software Engineering in PDF only on Docsity! 1 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: 1. Programmer or software designer – Every group member shall assume this role as needed. 2. 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. 3. Chief Programmer – Chief designer or implementer of the group 4. Support manager – In charge of the documents required to be submitted and is charged with submitting the final product of the group 5. Quality manager – Develops test plan for the group The four phases are: 1. Design – Due February 24, 2009, 11:59pm. – Develop designs for the new TSAFE features. 2. Implementation – Due March 26, 2009 11:59pm – Implement the new features. 3. System test – Due April 16, 2009, 11:59pm – Test an implementation. 4. 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. 2 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.0 Quality manager Amy 15.0 Support manager George 18.0 Overall design (Chief Prog) Julie 22.0 Class designs All 23.0 Management Phases 2 37.0 Chief programmer Phase 2 16.0 Class1.java Phase 2 4.3 Class2.java Phase 2 6.5 Class3.java Phase 2 2.0 Class4.java Phase 2 3.5 Class5.java Phase 2 8.0 System testing Phase 3 40.5 Packaging Phase 4 20.5 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 mvz@cs.umd.edu) 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: 1. A readme.txt file giving the contents of the submitted zip file (not the TSAFE zip file). 2. 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. 3. A feasibility study describing how you picked the version of phase I to implement. 4. 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. 5. Additions of the tests you developed in addition to the test data you were given from phase I. 6. An errata document describing errors you found in your phase I input, which you had to correct. 5 - 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: 6 all, blundering, conforming, disable, enable, fixes, flights, horiztim , none, parameter, routes, select, selected, set, show, thresang, threslat, thresres, thresspe, thresver, trajectories, withplans and “*” (asterisk) Select output: Select one or more flights from all available flights: select <flightid> 2 select <flightid1> <flightid2> <flightid3>… Select all flights: select * Change output settings: show fixes [ all | none ] 3 show flights [ all | selected | withplans | conforming | blundering | none ] show routes [ all | selected | conforming | blundering | none ] show trajectories [ all | selected | withplans | conforming | blundering | none ] Change parameters: set parameter <parameter name> <value> enable parameter <parameter name disable parameter <parameter name> Parameter names are: threslat Lateral Threshold thresver Vertical Threshold thresang Angular Threshold thresspe Speed Threshold thresres Residual Threshold horiztim Time Horizon Not all parameters can be enabled or disabled. Check with the menu in the graphical client. 2. Loss of separation: To assure safety in the air, each plane needs to have a minimum horizontal and vertical distance to every other plane. If the distance between two planes falls below this threshold, they have lost 2 words between < and > are parameters / variables 3 [ … | … ] signifies that you have to choose one of the items in square brackets, e.g. select fixes [ all | none] can be select fixes all or select fixes none 7 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: ( ) ( )               − +      − = = === 2 sin*cos*cos 2 sinarcsin**2 metersin distance meters)inearththeof(radius000,367,6LongitudeLatitude 122 21 122 λλδδ δδ λδ RG 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: