COM00008I

BSc, BEng, MEng Examinations, 20132014 DEPARTMENT OF COMPUTER SCIENCE S OFTWARE E NGINEERING P ROJECT (SEPR) Group Open Assessment Issued: Aut/2/Wed, 9 October 2013 Submission due: 12 noon, Assessment 1: Aut/7/Wed, 13 November 2013 [22.5%] Assessment 2: Spr/3/Wed, 22 January 2014 [22.5%] Assessment 3: Spr/7/Wed, 19 February 2014 [22.5%] Assessment 4: Sum/3/Wed, 7 May 2014 [22.5%] Feedback and marks due: Assessment 1: Aut/10/Wed, 4 December 2013 Assessment 2: Spr/6/Wed, 12 February 2014 Assessment 3: Spr/10/Wed, 12 March 2014 Assessment 4: Sum/7/Wed, 11 June 2014 All students should submit their answers through the electronic submission system: http://www.cs.york.ac.uk/student/assessment/submit/ by 12 noon, on the submission date (above). An assessment (or part of an assessment) submitted after this deadline will be marked initially as if it had been handed in on time, but the Board of Examiners will normally apply a lateness penalty to the whole assessment. The feedback and mark dates are guided by departmental policy but, in exceptional cases, there may be a delay. In these cases, all students expecting feedback will be emailed by the module owner with a revised feedback date. The date that students can expect to see their feedback is published on the module descriptor: http: //www.cs.york.ac.uk/modules/ Your attention is drawn to the Guidelines on Mutual Assistance and Collaboration in the Departmental Statement on Assessment: http://www.cs.york.ac.uk/student/assessment/ policies/#AcademicMisconduct All queries on this assessment should be addressed to by email, to ona.polack@york.ac.uk. Answers that apply to all students will be posted on the module webpage. Rubric:

COM00008I
Do not include exam numbers anywhere in your submission. These are private to individuals. Answer all questions. Note the page limits for each question. Parts of answers that go beyond the page limit may not be marked. References must be listed at the end of the document and do not count towards page limits. The four team assessments account for 90% of the total module mark. The nal 10% is for the Individual Report, which is issued Sum/1/Mon, and due to be submitted by Sum/4/Wed. All deliverables should start with the teams name (the three-letter code that appears on the team lists). The examination numbers of team members must not appear anywhere in the assessment deliverables.

COM00008I

1 SEPR Assessment Structure

The Software Engineering Project (SEPR) module assessment comprises four team open assessments and an individual report. This document denes the four team assessments. All the team assessments are related, and are based on the scenario in Section 5; they constitute a complete software engineering project, and require teams to follow a lifecycle process and develop software. SEPR runs for the full academic year; the last assessment submission is the Individual Report in Summer week 4. Teams are also required to make a presentation of their nal product (Summer week 4) to an external client: the date and details will be published on the SEPR website and notied by email to all students. The presentation is not assessed, but a prize will be awarded. The purpose of the SEPR team project is to give you experience in the requirements, design and implementation of software using a team approach and using modern software engineering methods and tools. The structure mirrors many aspects of realworld software engineering, in a controlled way. In this document, Section 2 outlines team set-up and marking arrangements; Section 3 describes the four team assessments, and outlines the deliverables required for each task; Section 4 addresses pass-fail criteria and reassessment; Section 5 describes the scenario and requirements for the project.

2 Project Teams and Team Marks

The project is designed to be undertaken by teams of 5, 6 or 7 students. Guidance and rules for SEPR teams are given on the module website, http://www-module.cs.york.ac. uk/sepr/Teams/TeamInfo.html. For the purposes of team management, it is up to the team to develop its own structures and arrangements. By analogy to project teams in some development companies, the lecturers (Dr Fiona Polack, Prof. Tim Kelly, Prof. Richard Paige) form a higher management level, and should be consulted for things beyond the control of the team, for instance where team arrangements do not work effectively, or workload becomes unbalanced and the team cannot reach an equitable readjustment. The module lecturers (Dr Fiona Polack, Prof. Richard Paige, Prof. Tim Kelly) are the nal arbiters in any dispute arising from the composition, performance or size of teams, and the distribution of marks to members of a team.

COM00008I
2.1 Team marks and self-assessment
Each assessment is marked out of 100. Each team assessment is weighted as 22.5% of the module mark. The mark awarded to each student is the sum of the team mark, the self-assessment mark, any applicable bonus marks, and any individual penalty (section 2.2). This section explains the self-assessment mark. Each assessments deliverables may include a self-assessment table. If no self-assessment table is included in the deliverables for an assessment, or if a submitted table is incomplete, or the self-assessment marks are not correctly allocated, or the table is not signed by all members of the team, then the selfassessment mark for each member of the team is 10. A team can elect to recognise unequal contribution to the team work and the assessment deliverables. To do so, the members must consult the team rules and guidance. Teams are strongly encouraged to contact the module lecturers (Dr Fiona Polack, Prof. Tim Kelly, Prof. Richard Paige) for assistance, as soon as a problem becomes apparent. Module lecturers (the management) can be consulted at any point during the year, and timely intervention has been shown to resolve or mitigate most team problems. If a team, after due consideration and consultation, decides that an unequal self-assessment mark is appropriate for one of the team assessments, the team must include in the deliverables a self-assessment table laid out as shown in Table 1. The Self-assessment Mark for each member of the team must be an integer in the range 0 to 10 (i.e. {0, 1, 2, ..., 10}).

Table 1: Self-assessment Table Team Name: Assessment: NAME SIGNED Self-assessment Mark ... ... ... ... ... ... e.g. D. Duck [a signature] 2

NOTE: If a team allocates a low mark to one or more team members, it is likely that the team would be asked to justify its allocation to the module lecturers. This is important, as it would allow checking of the fairness of marking, and, more importantly, will identify, and promote mitigation of, team problems that could affect subsequent assessments.

COM00008I
2.2 Individual Penalties
It is important that all problems with participation in team work and assessment activities are discussed in a timely manner with the management (as above). Problems can be raised at any time , not only during an assessment activity. Whilst the module lecturers can help, they cannot force equal participation. So, a student who does not participate adequately in team work and assessment activities, for whatever reason, or who is awarded a low self-assessment mark for an assessment, or who otherwise misses a substantial part of SEPR, may have marks deducted from one or more team assessments. Individual penalties are applied by the module lecturers. It is normal that penalisation only occurs after discussion with the individual concerned. Total non-participation results in a zero mark (a zero assessment mark, no team bonus marks and no self-assessment mark) for the individual student, for all affected team assessments.

3 The Team Assessments

Each team assessment addresses specic software engineering aspects of a game based on air trafc management (ATM, as described in Section 5). Teams must bear their own costs (if any), and are responsible for all aspects of management of their own work. Teams should take special note of the constraints on the software environment outlined in Section 5; there are no other restrictions on the software engineering methods, techniques, tools, etc. that teams can use. The deliverables of later assessments build on the deliverables of earlier assessments. Teams may reuse and extend previous deliverables, including (in Assessments 3 and 4) all material provided with a selected software product. For example, each software deliverable requires a brief user manual; this can reuse or extend the existing manual as appropriate. 3.0.1 Electronic Submission All assessment deliverables are to be submitted electronically, and must conform to the requirements for electronic submission set out on the submission site, http: //www.cs.york.ac.uk/submit/. Your submission for each team assessment must be one .zip ziple. The details of what the ziple should contain for each assessment are given below. The ziple must be named using the team acronym, e.g. WAW.zip, CDG.zip.

COM00008I
3.1 Assessment 1: Requirements specication and design, due: noon, Aut/7/Wed
Assessment 1 covers the early stages of requirements specication and design, including high-level specication, planning and risk assessment. As part of the assessment, each team will need to (at least) identify appropriate software engineering methods and techniques, set up a regular meeting schedule, and allocate tasks to team members according to the available resources (e.g., team member availability and skills). 3.1.1 Deliverables for Assessment 1 The format requirements for the deliverables are summarised in Table 2.

1. 2.

Table 2: Assessment 1 ziple contents Deliverable File Name File Format document (max 20 pages) ReqRep pdf Optional self-assessment table SelfAss1 pdf

1. A specication document of no more than 20 pages, covering the following points: Requirements and specication: a specication of the software requirements, including necessary environmental assumptions, objectives, feasibility and risks and alternatives. [25 marks] A conceptual proposal for the structure of the teams software (using, e.g. classes, objects, functions, procedures or any other appropriate building blocks), and a brief justication for the structure. [25 marks] Team organisation and project plan: a detailed SEPR project plan outlining tasks and their earliest starting date and latest nishing date; task priorities; a critical path and task dependencies. Outline and justication of proposed software engineering approaches, together with plans for use of development and collaboration tools to support the chosen tasks and team working. [25 marks] Risk assessment and mitigation: risks for the SEPR project must be carefully identied and assessed, taking into account their likelihood and impact. Mitigation for each risk must be specied. [15 marks] 2. The self-assessment table, if appropriate (Section 2). [10 marks]

COM00008I
3.2 Assessment 2: Preliminary Implementation, due: noon, Spr/3/Wed
Assessment 2 concerns the software engineering design and implementation of part of the software system, based on the requirements and specication created for Assessment 1. In Assessment 2, you must: 1. design and implement the GUI and the ight plans. Flight plans should be randomly generated and include a list of waypoints, velocities, altitudes, etc. Include checks to make sure ight plans are sensible (e.g., that an aircraft is not climbing and descending all the time). The implementation should accommodate two aircraft with different ight plans. You should include commands to: change course change altitude modify and apply separation rules turn left or right Include a timer that measures how long the game has been played for. 2. set up a website for your ATM Controller game. The purpose of the website is both to advertise the teams product, and to make available the software engineering documentation and code needed to extend, re-engineer and run the game. The website should highlight to a potential customer (i.e., a team that may choose this software) the selling points and strengths of the software. It is a reasonable assumption that a good website might attract teams to select your product. In Assessment 2, you must not exceed this brief: do not implement any other features. 3.2.1 Deliverables for Assessment 2: 1. A working implementation of the ATM Controller game, and a brief user manual explaining how to invoke and play the game. [30 marks] 2. A test plan for the implementation and evidence of appropriate testing. [23 marks] 3. A report of no more than 10 pages that explains and justies the architecture of the ATM Controller game (what classes are used, how are they connected, etc.), as well as the design of the games interactions. If the implementation does not fully address any of the features specied for the required parts of the ATM Controller game, then the report should state and explain what is missing. [25 marks]

COM00008I
4. A report of no more than 10 pages, including suitable illustrations, that explains and justies the design of the GUI. [10 marks] 5. The URL of the website for the ATM Controller game as a software product. [2 marks] 6. The self-assessment table, if appropriate (Section 2). [10 marks] The format of deliverables for Assessment 2 is summarised in Table 3.

1.

2. 3.

4. 5. 6.

Table 3: Assessment 2 ziple contents Deliverable File Name Game code A directory called Game2, containing all the les needed to run the game, including any required libraries, etc. User manual Manual2 Test plan and testing le or directory called Test2 evidence Architecture and DesRep design report (max 10 pages) GUI report (max 10 GUIRep pages) URL of website url2 Optional self- SelfAss2 assessment table

File Format ...

pdf or html les: pdf pdf

pdf txt pdf

3.3 Assessment 3: Selection, Extension and Integration, due: noon, Spr/7/Wed

Assessment 3 requires each team to work on a product other than that which the team worked on in the rst two assessments. There are thus two phases to Assessment 3, as follows. 3.3.1 Phase 1: selection: completed Spr/4/Mon at 10am After the submission of Assessment 2 (Spr/3/Wed, above), each team has a short period to consider the products of the other teams. The Spr/3/Friday lecture class will

COM00008I
be used to present team products and discuss with other teams. On Spr/4/Monday, each team is required to register their choice of product to work on in Assessment 3. The only constraint on selection is that a team is not allowed to use its own Assessment 2 software product in Assessment 3. In selecting a software product, criteria that may be considered include: (1) the overall quality of the software product; (2) estimates of effort remaining to complete the implementation; (3) clarity and quality of the requirements specication, design and implementation. A bonus of 3 marks will be added to the teams Assessment 2 mark for each registered selection of the teams software product, with the condition that no individual can attain more than 100% for Assessment 2. 3.3.2 Phase 2: extension and integration The selected product should have designed and implemented the ATM Controller GUI and ight plans, along with basic commands (as specied in Assessment 2). For Assessment 3, the selected software product must be extended to add commands to aircraft to land and take off: there must be suitable constraints on how many landings and takeoffs can happen simultaneously. The randomly-generated ight plans may include instructions to enter and land, or takeoff and leave the airspace. A scoring mechanisms should be added, to improve playability and entertainment value. The game should be modied to allow at least ten ights to be passing through, landing or taking off in your airspace. You must also update the website for the ATM Controller game. As in Assessment 2, the purpose of the website is both to advertise the teams product, and to make available the software engineering documentation and code needed to extend, re-engineer and run the product. The website is not marked directly (though marks will be lost if there is no website). It is a reasonable assumption that a good website might attract teams to select your product. In Assessment 3, teams are allowed, but not required, to extend the game by adding further features or behaviours, as desired, but these need to be fully explained and justied in the deliverables, and must not violate the requirements for the game. 3.3.3 Deliverables for Assessment 3 1. A working software application that extends the ATM Controller game selected in phase 1 of Assessment 3, meeting the additional requirements of Assessment 3. A brief user manual explaining how to invoke and play the ATM Controller game. [30 marks]

COM00008I
2. A test plan with evidence of appropriate testing, to include explicit coverage of how extensions and modications were tested. [28 marks] 3. A report of no more than 10 pages outlining the challenges that were encountered in extending the ATM Controller game and its GUI, and in implementing the requirements of Assessment 3. For each modication, the report should include the reason for the change, the affected elements of the design and implementation and detail of the change that was made, as well as a cross-reference to the relevant parts of the test plan and testing evidence. The report should also explain and justify the software engineering solutions and approaches adopted. [30 marks] 4. The URL of the website for the ATM Controller game as a software product. [2 marks] 5. The self-assessment table, if appropriate (Section 2). [10 marks]

1.

2. 3. 4. 5.

Table 4: Assessment 3 ziple contents Deliverable File Name Game code A directory called Game3, containing all the les needed to run the game, any required libraries etc. User manual Manual3 Test plan and testing le or directory called Test3 evidence Extension report (max ExtRep 10 pages) URL of website url3 Optional self- SelfAss3 assessment table

File Format ...

pdf or html les: pdf pdf txt pdf

The format of deliverables for Assessment 3 is summarised in Table 4.

3.4 Assessment 4: Selection, Requirements Change, due: noon, Sum/3/Wed

Assessment 4 requires each team to work on a product other than that which the team worked on in Assessment 3. There are two phases to Assessment 4.

10

COM00008I
3.4.1 Phase 1: selection: completed Spr/8/Mon at 10am After the submission of Assessment 3 (Spr/7/Wed, above), each team has a short period to consider the products of the other teams. The Spr/7/Friday lecture class will be used to present team products and discuss with other teams. On Spr/8/Monday, each team is required to register their choice of product to work on in Assessment 4. The only constraint on selection is that a team is not allowed to use its own Assessment 3 software product for Assessment 4. A team is allowed to use another teams Assessment 3 extension of its own Assessment 2 product, but must work from the assessment 3 version. In selecting a software product, criteria that may be considered include: (1) the overall quality of the software product; (2) estimates of effort remaining to complete the implementation; (3) clarity and quality of the requirements specication, design and implementation. A bonus of 3 marks will be added to the teams Assessment 3 mark for each registered selection of the teams software product for Assessment 4, with the condition that no individual can attain more than 100% for Assessment 3. 3.4.2 Phase 2: requirements change A small set of requirements changes will be issued on Spr/8/Monday; these may include changes to the scenario requirements and/or introduction of new requirements. Using the selected software product, the team must modify the software product to address these requirements changes. You must also update the website for the ATM Controller game. 3.4.3 Deliverables for Assessment 4 1. A working software application that implements the changed requirements on the ATM Controller game selected in phase 1 of Assessment 4. A brief user manual explaining how to invoke and play the ATM Controller game. [30 marks] 2. A test plan with evidence of appropriate testing, to include explicit coverage of how modications made to implement the required changes to the product. [28 marks] 3. A report of no more than 10 pages outlining the challenges that were encountered in addressing the requirements changes. For each modication needed to address each of the requirements changes, the report should include the reason for the change, the affected elements of the design and implementation, and detail of the change that was made, as well as a cross-reference to the relevant parts

11

COM00008I
of the test plan and testing evidence. The report should also explain and justify the software engineering solutions and approaches adopted. [30 marks] 4. The URL of the website for the ATM Controller game as a software product. [2 marks] 5. The self-assessment table, if appropriate (Section 2). [10 marks] The format of deliverables for Assessment 4 is summarised in Table 5.

1.

2. 3. 4. 5.

Table 5: Assessment 4 ziple contents Deliverable File Name Game code A directory called Game4, containing all the les needed to run the game, including any required libraries etc. User manual Manual4 Test plan and testing le or directory called Test4 evidence Change report (max 10 ChangeRep pages) URL of website url4 Optional self- SelfAss4 assessment table

File Format ...

pdf or html les: pdf pdf txt pdf

4 Passing and Failing

To pass SEPR, a student must reach the overall module pass mark. There is no requirement to pass any one of the component assessments. In marking each team assessment, the following criteria are considered: deliverables must be in accordance with the instructions for that element of assessment (Section 3), including ziple instructions; there should be evidence of justication and rationale in the choice of methods, techniques, languages, tests and test plans, and other aspects of software engineering that are appropriate to the assessments; documents must be clearly expressed, in concise, precise language;

12

COM00008I
supporting evidence (citations, diagrams, listings etc.) should be included: credit will be given for clear attribution and referencing (e.g. using the departments advocated IEEE Referencing style), where appropriate; design decisions and assumptions should be clearly stated; the requirements (as outlined in Section 5 and the individual assessments) should be traceable in the design, implementation and accompanying deliverables; where required by the assessment, there must be working software, with a user manual that gives a sufcient explanation for the ATM Controller game to be played by the module lecturers (Prof. Richard Paige, Dr Fiona Polack, Prof. Tim Kelly); requirements, design and implementation, as appropriate, should exhibit clarity and efcacy; the ATM Controller game should be attractive and playable; deliverables should demonstrate good and appropriate use of software engineering practices, and adoption of existing solutions where appropriate. Failure of a team assessment might be due to many things. If a team is not functioning and feels that it may not be able to complete an assessment task, or that the work is not being shared in an equitable way, then it is strongly encouraged that you contact the module lecturers as soon as possible (email ona.polack@york.ac.uk, tim.kelly@york.ac.uk, richard.paige@york.ac.uk). As outlined on the SEPR website http://www-module.cs.york.ac.uk/sepr/Teams/TeamInfo.html, there are many ways we can try to help, but we cannot help if we do not know that there is a problem, or if we only nd out at or after the submission date. Various characteristics of deliverables might result in low marks being awarded. For example: omission of required deliverables, or other failure to meet the requirements of the assessment, including ziple instructions; unclear writing and reporting; poor use of notations; illegible diagrams; poor attribution or referencing, etc.; where relevant, code that does not compile and run in the stated software environment; where relevant, code that is poorly structured, poorly commented, omits conventional preamble, ignores open-source conventions, etc.;

13

COM00008I
lack of evidence of validation between levels of abstraction, e.g. code that is not obviously an implementation of the design; inadequate test plans, unrepeatable tests, etc.; lack of clarity in rationale for, or justication of:

choice of methods, techniques, tools, languages, etc.; any tailoring of methods etc., required to accommodate the needs of the
project; where relevant, failure to provide and update the product website. A student who does not pass (and cannot compensate) SEPR will be required to take a reassessment in the summer vacation. The reassessment will be an individual exercise, based on the existing team deliverables. It is the students own responsibility to arrange access to any materials that may be held by members of their team.

4.1 KISS
If you do not know what this means, nd out! This project requires a non-trivial but reasonable amount of design and implementation effort. You are STRONGLY DISCOURAGED from adding any additional features, bells and whistles, etc. A key principle of software engineering is that products should meet their requirements. There is no merit in producing something that goes beyond what is required.

14

COM00008I

5 Scenario: Air Trafc Management (ATM) Controller Game

The game involves the control and management of ights (taken by commercial civilian aircraft) in a particular airspace. The game is from the perspective of a single air trafc controller (ATCO) who must give instructions to aircraft in order to ensure safe passage of a ight through their airspace. You are referred to [1] for a brief introduction to the terminology of air trafc control, and [2] for a more comprehensive description. Your game will ultimately have the following capabilities. A graphical user interface (GUI) showing an airspace (real or invented, e.g., near Manchester airport) and active ights within the airspace. The ability to specify a static ight plan for a particular ight (involving a particular aircraft with specic characteristics, e.g., air speed, weight, crew). A ight plan consists of a routing from originating airport to destination airport. The routing is made up of a number of waypoints. Between two waypoints an aircraft has a velocity and an altitude. For the ATM Controller game, you need to consider in detail the part of the ight plan that relates to your airspace. The capability for ights to enter and exit the airspace of your game. When they enter the airspace, they are under the responsibility of the spaces ATCO. Entry of ights to the airspace is a part of the game design, and is discussed below; ights exit the airspace according to their static ight plan (above). The ability to monitor separation rules for ights to ensure that they maintain safe distance. Separation rules are mandated by aviation authorities (e.g., the CAA in the UK for civilian aircraft) and apply within regulated airspace under the control of an ATCO. Separation rules are used to avoid aircraft having the potential to collide; there is a point in a separation violation where collision becomes unavoidable: this is the ultimate fail! The ability to calculate a score, e.g., based on how long the game has been played for, or based on more sophisticated calculations that take into account the average number of ights in an airspace, etc. The basic operation of your game will be as follows. 1. When the game starts, the GUI is presented, displaying your airspace of choice, and any controls you may want the ATCO to use. There are no aircraft in the space at start up.

15

COM00008I
2. Flights enter the airspace randomly i.e., at random times and from random entry points. Your airspace must have at least three dened entry points and at least three dened exit points. Entry and exit points may be the same (though separation rules will obviously apply). The airspace must include at least ten intermediate waypoints. Eventually, your airspace should be capable of containing many ights, but you may initially assume that the airspace contains no more than ve ights. 3. Once a ight has entered the airspace, its behaviour is dened according to its ight plan. You may initially assume that ight plans are perfect. You may also assume that the ATCOs instruments and monitors are infallible and perfect. 4. The ATCO may send commands to each ight to change its ight path. The minimal nal list of commands is given below. You may assume that the aircraft responds to each command immediately. 5. The GUI is updated regularly (e.g., every 30ms) to show current positional information for all aircraft in the airspace. 6. Separation rules for vertical separation and lateral separation minima are checked regularly (e.g., every 10s), and after each command. 7. The game must assess separation rule violation. If a collision is inevitable, the game is over. In the nal game, an ATCO can issue at least the following commands. Each command will take as argument a ight (e.g., QF11) and any other necessary values. Change course: provide the aircraft with a new heading (e.g., change course to 035 degrees) Change altitude: the aircraft will ascend or descend to a new altitude Land at airport Take off from airport Turn left by a particular degree Turn right by a particular degree

16

COM00008I

References
[1] P.E. Lewis, A Condent Argument for the Human Air Trafc Controller, MSc SCSE Thesis, University of York, 2011. http://www.cs.york.ac.uk/library/proj_les/2011/ MScSCSE/pel501/A%20condent%20argument%20for%20the%20human% 20controller.pdf [2] M.S. Nolan, Fundamentals of Air Trafc Control (4th edition), Brooks/Cole, 2004.

17