Module Handbook Software Development Project SDP3333 2016-17 ________________________________________   Information in alternative formats This handbook can be found online at: Disclaimer The material in this handbook is as accurate as possible at the date of production however you will be informed of any major changes in a timely manner. Other Documents Your module handbook should be read and used alongside your programme handbook and the information available to all students on the Moodle including the Academic Regulations and Student Charter.   Contents Contents 4 TABLE 1:KEY DATA and DEADLINES FOR PROJECT MODULES 5 CMT3333 INTRODUCTION and OVERVIEW 6 Introduction 6 Contacting the Module Leader 8 UniHelp 8 Rationale Including Aims 8 Learning Outcomes 8 Teaching and learning strategies 9 General Guidance on Project Content and Structure 10 Contact with your project supervisor 12 Project Meeting Log CMT3333 14 Assessment Guidelines (General) 15 The Progress Milestones 16 Attendance Requirement 16 Study hours 16 COURSEWORK 17 Details of Coursework 17 Deadline for Submission of Coursework 19 Failure and resubmission 19 Where to submit Coursework 19 Intellectual Property 19 Feedback to students on coursework 20 Academic Dishonesty 20 Plagiarism 20 Electronic plagiarism detection 21 Feedback to students on work and progress 22 Coursework return 22 Confidentiality/ Non-disclosure 22 Useful Information 24 MyUniHub 24 Reading Materials 24 Appeals 24 Brief Guide to Web-based Module Material 24 Appendix A: Cover Page and statement of originality (2 pages). 25 Appendix B : Project Report Format 27 Appendix C: Project Report Layout 28 Appendix D: Examples of previous Student Project titles 29 Appendix E: Appeals 30 Appendix F: Change of individual Project 30 Appendix G : The BCS self-Assessment Grid 31 TABLE 1: KEY DATA and DEADLINES FOR PROJECT MODULES ► SUBMISSION OF COURSEWORK 1 One must be uploaded to the Moodle. There is no paper submission. ►DUE DATE Week 5 – Monday 10/10/16 Students who omit to submit an online copy will fail. ► SUBMISSION OF COURSEWORK 2 One copy of this report must be uploaded to the Moodle. It will include a background/literature review and other development work as agreed with the supervisor. There is no paper submission. ►DUE DATE Week 12 – Monday 05/12/16 Students who omit to submit an online copy will fail. ► SUBMISSION OF COURSEWORK 3 A fully labelled copy of the following items project report , final version + ancillary material including copies of Appendices A (both pages) together with electronic version on a CD including TURNITIN report and the complete source and an executable version of the software. A full electronic copy of all work must also be uploaded to the Moodle. ►DUE DATE Week 26 – Monday 17/04/17 Additinal requirements: fully labelled CDs must be housed in secure pockets in the strong plastic report covers. Submissions without TURNITIN reports will not be accepted by student office. Students who omit to submit an online copy will fail. ►VIVA VOCE In this compulsory oral examination, students will be asked to demonstrate software and possibily asked to clarify or explain any part of their written work. This may be recorded on video. ►As Timetabled during Exam period This must be attended during the examination period. Late submission of any coursework without formal Deferral or extenuating circumstances issued in accordance with procedures at the CNWL Will incur penalties Coursework deferrals Students must follow normal procedures and apply to the Student Office presenting any required documentation ACADEMIC STAFF CANNOT GIVE DEFERRALS OR EXTENSIONS TO COURSEWORK DEADLINES SDP3333 INTRODUCTION and OVERVIEW Introduction Welcome to the Project Module ! The main purpose of this handbook is to guide the execution of your project by suggesting the structure that should be followed in order to meet the main requirements. Project work offers you a major opportunity to consolidate your understanding of much of the material drawn from various parts of taught material - the specialist theory, concepts, principles, analysis and design methods, and programming and evaluation skills. Your project will probably be the largest piece of work you have done by yourself, so it is an opportunity to really demonstrate your ability. For this reason it is a standard talking point in job interviews and is possibly the most important single module you will take during your degree. Your approach to project work must exhibit an appropriate degree of professionalism. You will be expected to consider and be guided by precepts relating to organisations and the environment, ethical and legal principles, and business techniques, and not merely the pure application of computing science and technology. Your engagement in project work essentially involves a considerable degree of autonomy: you have considerable control over the precise content of your project work, and the tools you choose to develop a solution. You will need to accept responsibility for planning and executing your work. But having said all this, it remains that by the time you start your project, you will have already acquired skills in using most if not all the tools that you will need in your project including analysis and design and programming skills. In addition, you may have had practice in using these tools in PDM2426 - the group project development module. Equally, you may find that you need to master new tools and/or develop various skills appropriate to the tasks in hand. The core of your project will involve software engineering including requirements specification, analysis and design, and implementation and testing of a software artefact (e.g. a program). This format does not preclude doing research; it is a question of emphasis as long as the core of the project involves software development that is relevant to the title of the programme being studied. It is likely that you will have started to think about areas of project work of interest to you well before the start of the individual project module. By the end of your second year of studies on the programme, some issues, problems of interest, or particular aspects of the subject material in some of your taught modules might lead you to want to work on a specific topic. During PDM2426, you may have engaged in group project work and you will have been assigned, or have chosen, a particular role as a team member within the project activity. You will have learned about project management and have reflected upon the relevance of several general, non-technical issues that might bear not only on developments in the group project, but are relevant to your own individual project. These considerations should help you define how your intended project has a role in a particular organisation, any ethical issues that might arise from the implementation of your system, and so on. In addition, you will have learned the basics of how to present the results of a complex technical system in such a way that the key ideas are communicated effectively to a variety of audiences using a variety of media. By the time you receive this handbook, you should be starting work on identifying a specific project title. You will have been assigned a supervisor, and they will be happy to offer their subject-specific views on your initial proposals. Although a few students produce fantastic project work with little input from their supervisors, this is the exception, not the rule. For the vast majority of project students, the relationship with their supervisor is of critical importance, particularly in the early stages of defining problems and choosing methodologies for their solution. Uniquely, project modules provide students continuing close contact with teaching staff, all of whom have considerable research and/or industrial experience. Your supervisor will certainly have an interest in your chosen project area, although he or she may not have specialised experience in some aspects of your project execution. Supervisors will help you to identify possible additional skills, knowledge and understanding required at later stages of the project. But do not expect supervisors to provide in depth knowledge on all aspects of your project or debug your software or evaluate your test results. Finally, always keep in mind that an individual project is every bit as much a test of your personal organisation skills as it is a test of your academic and practical ability. Experience shows that students who apply themselves at a steady and consistent pace throughout the project development invariably obtain the best results. Office hours: 09.00 – 16.00, Monday – Friday Module Aims Rationale Including Aims The aim of this module is to give individual students the opportunity to demonstrate how effectively they have consolidated their knowledge and skills from other computer science modules via an individual project which must involve the production of a useful software artefact which is relevant to the title of their degree programme. Learning Outcomes On completion of this module, the successful student will be able to: Knowledge 1. Demonstrate an understanding of the complete software life cycle, including requirements elicitation, conceptual modelling, design and development, software testing and system evaluation, making appropriate use of software support tools and graphical notations 2. Formulate and test hypotheses; collect and analyse qualitative and quantitative data to form evidentially supported conclusions in a computing context 3. Demonstrate an understanding of the factors involved in successful management of a software project, and recognise the professional, legal and ethical issues involved in the design and development of software systems Skills 4. Effectively retrieve information from a range of sources (including electronic sources such as the Internet, CD-ROM and electronic catalogues), including scholarly reviews and research materials, and be able to cite and reference information sources appropriately for different audiences 5. Learn independently in a variety of situations with a spirit of critical enquiry, effectively planning and managing resources and time for the purposes of continuing professional development 6. Prepare detailed software system design reports, including all phases of the software development method Teaching and learning strategies Students should meet regularly with their supervisors throughout the project. The supervisor will provide oral feedback on all aspects of the work as the project proceeds and should advise on the setting objectives and milestones. Provisional versions of project proposals are formulated by the end of Level 2 in the Professional Project Development and Management module. Students are encouraged to reflect on and develop their project ideas prior to the start of this module. The scope and content of student projects will be negotiated with and approved by their supervisors in the first four weeks. Students will submit their final project proposals (Coursework 1) by the end of the nineth week in the Autumn term. This will be assessed (learning outcomes 1 & 6) and contributes 10% of the total project marks. The next deliverable of the project will be the interim report (Coursework 2) to be submitted by the end of week 16. This written report must include a subject/literature review. It should also cover other substantial development work such as requirements, analysis and design, and implementation or other documentation as agreed with your supervisor. This should be a written report that documents what is submitted (i.e. where diagrams and code are submitted they must be described and/or explained). The student will be required to attend a viva voce examination with their supervisor to discuss their report. These assessments contribute 20% of the total project marks. (Covering learning outcomes 1 - 6). Student work will culminate in the submission of a final, formal project report. This is assessed and contributes 40% of the total project marks. A viva and practical demonstration based on the student's project will be assessed and contribute 30% to the final total project marks. (Covering learning outcomes 1- 6) General Guidance on Project Content and Structure SDP3333 projects generally will follow the same pattern and have the same general structure to the report. Below the structure of a typical software development project report is given. This structure is not prescriptive, it may be varied. Projects do not have to follow a waterfall model where each stage of the software lifecycle is followed sequentially as shown below, but the document should reflect the model used. For example with an iterative model where a number of iterations of the software lifecycle are made, each iteration could correspond to a chapter. Thirdly the fact that the project is in software development does not preclude addressing a research question. For example significant research effort could be put into requirements specification (e.g. task analysis), or a program may be developed to do extensive evaluation (e.g. test a range of interaction techniques) etc. It is just a question of emphasis. The bottom line is that the core of the project must involve software development and produce a software artefact (e.g. a program) that is relevant to the title of the programme being studied. . Typical Report Structure Title page – Includes Module code, Title, student name and number, and supervisor's name, see Appendix A. Abstract This should be an approximately one page summary of the whole project from start to finish, typically including a statement of the problem to be solved, how the problem was addressed, how the project was evaluated and what conclusions could be drawn from the work. The abstract should be left to last because it is a summary of what you actually did. Introduction Should include a brief introduction to the project, a clear definition of the problem to be addressed, and guide to rest of the report. Background and literature review. This should describe the context of the project and should attempt to establish the state of the art in the project area. This should show evidence of scholarly activity in demonstrating the ability to research, collate and integrate information into a coherent document that uses referencing and quotations correctly such that an intelligent computer literate person should be able to quickly understand the background to the project. Requirements specification This should be as detailed as possible a specification of the requirements for the development of your program. In some cases the requirements may come from tutors or users outside of academia and more formal techniques for requirements elicitation may be needed. In other cases the student will define these requirements. This may include a test plan. Analysis and Design This chapter should document your analysis of the requirements and the design using an appropriate method. Usually this will be UML (e.g. class diagrams, sequence diagrams etc), but other methods can be used if appropriate. It should include a commentary on how design decisions are made. Implementation and Testing This section should give details of how your design is actually implemented and how testing has been planned and conducted. For real world applications testing can be very detailed, but in student projects it is often fairly brief. You can choose to make this a feature of the project if you wish (for example you could use the Test Driven Development methodology). Software performance could also be measured against an test plan. (e.g. acceptance testing for the given stakeholder) developed at the requirements stage. Demonstration/Evaluation In this chapter you have the opportunity to show off your program in action and evaluate how well it fulfils the requirements specification. The reader should be able to get a clear idea of what the program does and looks like without having to run the code. Some indication of program performance is expected her (e.g. screen shots, results, collated results or other output, analysis of performance, graphs etc as appropriate) are expected here in order to demonstrate and evaluate the work. However a detailed users guide to the software (if the work warranted it) or lengthy numeric analysis would usually appear as an appendix. The management of the project should also be discussed with reference to the Gantt chart/s produced, and variances from the proposed milestones and deliverables should be accounted for. Conclusion The project should conclude with a critical and reflective evaluation of both the process and outcomes of the work. It should detail the lessons learned, how the project would be conducted if it was started over, and what future work could be done to improve the project. Appendices Appendices should include your references and cover some standard entries such as a guide to the materials on the submitted CD, but also any other materials too detailed to be included in the main text (up to a maximum of twenty pages). A guide to how to compile, configure and run the software is essential. Note that references from un-validated sources such as Wikipedia and similar sites are not acceptable. Further information regarding the formatting of the report is given in Appendices B and C. Book Recommendations Dawson C. "Projects in Computing and Information Systems: A Student's Guide" Addison Wesley, 2009, ISBN-10: 0273721313, ISBN-13: 978-0273721314 Recommended Bennet, McRobb & farmer. Object-oriented systems analysis and design using UML, 3rd Edition, 2005, McGraw Hill Higher Education ISBN 0077110005   Assessment Guidelines (General) In considering the assessment the following areas are of specific interest: • an abstract with containing a clear definition of the subject • introduction providing explanation of all project objectives • the problem definition and its context - i.e. an explanation of the identified problem to be addressed • evidence of understanding and application of the concepts underpinning the project • evidence of use of literature to support and develop argument • research relevant to the problem addressed • the approach, methods and tools used throughout the project and their justification • thoroughness and completeness of requirements analysis and design specifications • an unbiased critical approach • the soundness of the product or results • an evaluation each of the product and the project process • a valid conclusion and critical reflections on the problem as defined and recommendations for future work • the quality of the written report in terms of articulate use of language • the effective use of the formal impartial academic style • the presentation of data and citation of references • using the mutually defined progress milestones, supervisor(s) will be able to assess: o evidence of self-management of the entire project o ability to work within problem domain o level of commitment o ability to deal with deliverables and to manage time o level of on-going development of the students understanding and organisation and self management of the work The Progress Milestones These are a set of mutually agreed goals or work objectives that mark key stages to be achieved in the evolution of the project. The specific details of the milestones and time frames will be mutually set by the project supervisor and student after discussion and agreeing the project specification. Study hours The total study hours for a 30 credit point module is 300 hours. This module has no time-tabled activities so the duration of out-of-class project implementation activity is also 300 hours.   COURSEWORK Details of Coursework Coursework 1 - Project proposal - 10% Deadline: End of week 5 - 10/10/16 It should contain: • A description of the project you wish to undertake • A brief description of the deliverables • A brief explanation of the problem you are addressing • A brief explanation of how you can evaluate your work • A Gantt chart clearly showing milestones and deliverables • A list of resources required • A list of relevant books and article/publications (at least 6) It will typically be about 1000 words and a supervisor may expect additional material if they have provided you with an outline proposal. One copy should be uploaded to the Moodle. There is no paper submission. Assessment Mechanism: assessed by Supervisor for overall clarity and quality at the undergraduate level, Consequence of Failure: : Students will be advised to revise the proposal in the light of feedback, making adjustments necessary to ensure the project can move forward and has a realistic prospect of a successful outcome on the basis of the revisions made. There will be no formal resubmission. Coursework 2 – Background/Literature Review and initial development - 20% Deadline: End of week 13 - 05/12/16 This written report must include a literature review. It should also cover other substantial development work such as requirements, analysis and design, and implementation or other documentation as agreed with your supervisor. This should be a written report that documents what is submitted (i.e. where diagrams and code are submitted they must be described and/or explained). The student will be required to attend a viva voce examination with their supervisor to discuss their report. The report should include commentary on progress achieved relative to the original Gantt Chart, and for many students will include an updated Gantt chart to accommodate performance to date. One copy should be uploaded to the Moodle. There is no paper submission. Assessment Mechanism: assessed by Supervisor according to mutually agreed deliverables to include background/literature review (5%) and other designated work (15%). Consequence of Failure: This assessment component does not have to be passed as an individual activity, so students can proceed with the remainder of the project work despite the fail mark recorded at this stage. It will be very important that they act on the formal feedback received and further advice provided informally by the supervisor at project meetings. ?????????????????????/ Coursework 3 - Final report - 40% Deadline: End of week 26 10/00/17 The final set of "deliverables" for an individual project will include the following: • The final Project Report. • The Turnitin report – see Appendix A. • A CD/DVD containing: o An electronic copy of the final Project Report o The software artefact, preferably compiled on CD, but also including all source files needed to compile the project, and instructions on how it can be rebuilt, plus any other documentation not contained in the report. • A completed BCS self-assessment grid ; if the student wishes to be considered for BCS professional project exemption. NOTE: One fully labelled copy of all materials; i.e. report , Turnitin Report, CD s of report and the source and an excutable of software, are to be submitted according to the procedures operating at the CNWL. In addition an electronic version is required - all project materials should be zipped up into a single zip file and uploaded to the Moodle. Assessment Mechanism: assessed by Supervisor and second marker. Consequence of Failure: This assessment component does not have to be passed as an individual activity, though because of its weighting in the overall assessment, failure will have serious implications for the overall grade. Viva Voce and Demonstration 30% Deadline: At some time immediately after the exams. This will be immediately following the exam period. Individual sessions will be arranged for each student. It is essential that students make themselves available during this period to participate. This is an essential part of the project and anyone failing to attend for their viva will automatically receive a fail grade." Your examiners will ask you questions about your project in order to establish the quality of your software, and to assess your understanding of the work achieved and presented in your project. You will primarily be asked to demonstrate your software but you could equally be asked to clarify or explain any part of the written work. The viva should last no longer than 20-30 minutes and may be recorded on video. Assessment Mechanism: assessed by Supervisor and second marker according to the two criteria given above, quality of software (15%), and your understanding of the work achieved and presented (15%). Consequence of Failure: A viva and practical demonstration based on the student's project will be assessed and contribute 30% to the final total project marks. (Covering learning outcomes 1- 6). Consequence of failure: This assessment component does not have to be passed as an individual activity. However, a student who fails to attend for it will gain grade 20. Deadline for Submission of Coursework Submission Deadlines are listed above and also in table 1, "Key Data for Project Modules", at the beginning of this handbook. Sometimes deadlines from different modules will come at the same time and it is important to plan your workload to meet these deadlines. Failure and resubmission Following a failure in the module, The examination board will decide on the form of resubmission possible and the required date of submission. Where to submit Coursework Written assessed coursework must be submitted to the Student Office or the following the standard procedures of the CNWL. Electronic versions of the final thesis and all supporting materials should be uploaded to the Moodle. Students should attach a Cover Page – see Appendix A. Submission of work will produce a dated receipt. Students are strongly advised to keep their receipts safely. Project reports occasionally become mislaid. A receipt is your proof of delivery. Do not hand written assessed coursework directly to a tutor. If, in an emergency, students have to send in written assessed work by post; they must carefully label the work and send it by recorded delivery addressed to the Student Office and keep the Post Office receipt. It will be deemed to have been submitted on the date of the postmark. Coursework Forms containing receipts for work submitted outside opening hours will be issued according to the procedures of the CNWL. Intellectual Property In most cases, students hold the intellectual property rights in the work they produce for assessment. There are some exceptions such as where the work is commercially-sponsored, or the aim of the module is to develop intellectual property, or where the student is sponsored or employed, or on placement. Feedback to students on coursework Students will receive continual formative feedback over the course of the project from their project supervisor. Students should receive summative feedback verbally from their supervisor and also will receive their marking forms with written feedback for the IPP and the Interim Report. The nature of the feedback shall be helpful and informative, consistent with aiding the learning and development process. The nature of the feedback shall be determined at Subject/Programme level but may take a variety of forms including: written comments; proforma comments; individual and group tutorial feedback; or other forms of effective and efficient feedback. Feedback to students will normally be provided within 15 working days of the published coursework component submission date. Academic Dishonesty Taking unfair advantage in assessment is considered a serious offence by the CNWL, which will take action against any student who contravenes the regulation through negligence, foolishness or deliberate intent. Academic dishonesty is a corrosive force in academic life; it jeopardises the quality of education and devalues the degrees and awards of the CNWL. Plagiarism Plagiarism is one specific form of cheating. It is typically discovered in coursework or laboratory assignments that are required to be completed by reliance on students' own individual effort. It is interesting to note that one dictionary defines a plagiarist as a kind of thief: "one who steals the thoughts or writings of others and gives them out as [his/her] own". When such 'theft' is additionally used to gain academic credit to which a student is not entitled, a further level of dishonesty is clearly present that makes the original act on the student's part even worse. Definition of Plagiarism The presentation by the student as their own work of a body of material (written, visual or oral) which is wholly or partially the work of another, either in concept or expression, or which is a direct copy. Note: The work presented for assessment must be the candidate's own, or the work of a project group as requested by the tutor. Plagiarism is the representation of another person's published or unpublished work as the candidate's own by unacknowledged quotation. It is not an offence if the material is acknowledged by the candidate as the work of another through the accurate use of quotation marks and the provision of detailed references and a full bibliography, although the Assessment Board will not expect work to rely heavily on direct quotations." If students are found guilty of plagiarism, the repercussions are very serious indeed. Students should take steps, therefore, to understand what plagiarism is, how it can be identified and how they can avoid committing it. Electronic plagiarism detection The CNWL uses "TURNITIN ", an external web based service which operates a "detection of plagiarism" facility. The detection efficiency is very high. Students must submit their project report drafts to this service. The service returns a report indicating the total percentage of "similar" (copied) material, itemises the sources from which it has been copied, and indicates the amount copied from each source. In order to improve processing speed and to reduce the "similarity" percentage reported by TURNITIN, references, graphics and bibliographies should be excluded from the TURNITIN submission. Note currently TURNITIN has an input file size limit of 9 MBytes. This is another reason to remove all graphics before submission. Students must then take the required corrective action and resubmit the work for re-screening. This procedure must be repeated as often as required, until all significant plagiarised material has been eliminated. A copy of the final TURNITIN report must be bound in the project report as a labelled appendix and also be submitted on a CD accompanying the project report. Project reports which are submitted without a TURNITIN report will not be marked. This will have serious repercussions for the student's SDP3333 grade and will result in a requirement to resubmit. Our experience with this service shows that even after several iterations though the "check ; correct ; recheck " cycle have been made, there remains a residual noise level of "similarity " reported by TURNITIN due to linguistic and semantic similarities within the topic area i.e. use of common terminology, similar phrases, jargon etc. From these observations an empirical guidance rule has been implemented as follows: A reported residual total "similarity "of not more than 15 % is acceptable as a termination point for the "check ; correct ; recheck " cycle , if the "TURNITIN " report indicates: a) The "similar" material is distributed throughout the report, and not concentrated in any one or two specific areas. b) No single reported source has generated more than 1 % similarity – but see Note (1) below. Note (1). Students are allowed to quote directly from other sources provided the quotation is enclosed by "quotation marks" and the source is properly referenced. In addition it is strongly recommended that you use italics and enclose all quotations in a table box so that it is abundantly clear to the reader. For example: ……. As Professor Einstein stated in his excellent 1909 paper on special relativity [113], "The major findings in the mass/time speed domain is that what goes up must come down unless it encounters a discontinuity, in which case it will end up in Dr. Who's Tardis…….etc" The source of reference [113] must then be included in the references at the end of the report. Up to a staggering 20% of the report (by word count) is allowed for quotations so there is absolutely no sense in plagiarising when you can quote extensively without penalty. TURNITIN will record the quotations as similarities but this should be ignored. So for example if your TURNITIN report shows a 5% similarity to a properly quoted source, the 5% does not count towards the maximum 15% you are aiming for. Note (2) Whilst the initial check can take of the order of 1-2 hours to generate a report, subsequent checks can take more than 24 hours. Sufficient lead time for several iterations should be allowed. Note that delays in operation of the TURNITIN sevice are not a valid reason for submitting a late project report. CONVICTION OF PLAGIARISM OR COPYING MATERIAL INTO A STUDENT'S PROJECT; FROM ANY SOURCES, WILL CAUSE THE STUDENT TO FAIL, WITH THE IMPOSITION OF FURTHER SEVERE PENALTIES. Feedback to students on work and progress Supervisors will give feedback at regular meetings and each milestone session, and after the examination board if resubmission is required. Coursework return No project reports will be returned .Reports are kept for review by examiners and for quality assurance purposes. All projects are kept for 6 months. Students are advised to keep an electronic copy as well as a hard copy Your project may be made available in the library for other students to view. Confidentiality/ Non-disclosure Should your work and/or project report involve material of a confidential nature, you can arrange for non-disclosure, either in part or whole. This must be agreed by the module leader, your supervisor.   Department of Computing, Maths, Business & Science Programme Title Foundation Degree in Computing (Software Engineering) Unit Title Software Development Project Unit Ref. No. SDP3333 Candidate's Name: Assessor's Name: Verifier's Name: Mantee Vasanthakumaran Date of IV of Brief: Signature of IV: Issue Date: 25/09/2014 Due Date: 20/04/2015 Plagiarism: Where there is evidence of plagiarism the assignment will be rejected and the candidate will not have an opportunity to re-submit the work. This will, inevitably, jeopardise your chances of completing the unit. Deadlines: Work that is not handed in on time will be subject to College policy on late submission of work and may not be graded or marked. This could result in you failing the course unless there are exceptional circumstances which must be explained to your tutor and agreed by the Curriculum Manager. All decisions or grades are subject to internal and/or external verification and may be modified. If you feel that an assessment decision is unjustified, you are entitled to appeal. For further details on any of the above please refer to your Course Handbook Assignment No. & Title Learning Outcomes Targeted Date Issued Hand In Date Resubmission Date(s) (if necessary) Project 1,2,3,4,5,6 25/09/2014 20/04/2015 Candidate's Declaration: I certify that the work submitted for this assignment is my own and research sources are fully acknowledged. Candidate's signature: Date: Assessor signature Date IV Signature Date This sheet, with the assignment brief, must be handed in with your work to the faculty assignment box by 16.00hrs of the final date for submission.   Department of Computing, Business Maths & Science ……………………………………………………………………………… (Student Name)… Student Id No……………………………………………………. Module number…………SDP3333……………………………. I hereby confirm that the work presented here in this report and in all other associated material is wholly my own work. I confirm that the report has been submitted to TURNITIN and that the TURNITIN results are on CD attached to this report. I agree to assessment for plagiarism. Signature…………………………………………… Date…………………………………………………… Appendix B : Project Report Format Appendix C: Project Report Layout PROJECT REPORT LAYOUT Paper Size A 4 Printing Margins LHS ; RHS 1 Inch 25 mm Binding Margin ½ Inch 12 mm Preferred Binding system Comb binding Header and Footer ¾ Inch 18 mm Printing Single Sided Basic Font Size 12 Point Line Spacing 1.5 Fonts Arial Project report Page Limit excluding contents, appendices, bibliography, references, proformas etc 8000 words MAXIMUM A project tutor may at his/her discretion, increase this limit by max of 20% if they consider specific circumstances warrant. And they confirm in writing Appendices: max page allowance 20 Pages MAXIMUM A project tutor may at his/her discretion, increase this limit by max of 20% if they consider specific circumstances warrant. And they confirm in writing Appendices content All miscellaneous data , Documented computer listing Students exceeding page count limits Could incur penalties CD with TURNITIN report MUST be attached to the report If the CD does not contain the TURNITIN report THE PROJECT WILL NOT BE MARKED. Loose unlabelled CDs will result in penalties No contents /pagination Will attract penalties No abstract Will attract penalties   Appendix D: Examples of previous Student Project titles Final project title Procedural modelling of flocking behaviour of 3D entities. Modelling of fire and smoke using particle effects. Using augmented reality to produce novel games interfaces. How does the use of sound affect the sense of immersion in a driving game? The development of a computer aided learning environment to learn a language. Using neural nets techniques to classify radar images. Appendix E: Appeals Students cannot appeal against an academic judgement of a particular grade unless there is a recorded medical reason or some work was not assessed and there is evidence that this has NOT been taken into account in the assessment. Since the whole marking of a project is subject to academic judgement students cannot appeal against the grade for a project, unless the following conditions can be proven to apply: (1) A student can show the presence of material that has not been assessed (2) A breakdown of the relationship between student and supervisor In the case of (2) appealing after the event is not enough. Student must have drawn it to the attention of the course Leader, in writing, well before submission. The documented existence of extenuating circumstances which though not in themselves sufficient for a deferral, may be considered as adverse to the students overall performance. Appendix F: Change of individual Project Having selected a project topic and completed the Project proposal, A change must be agreed with the supervisor. The module leader must also be informed. A change after teaching week 3 is not normally permitted. Appendix G : The BCS self-Assessment Grid To all undergraduate project students: If you are seeking British Computer Society or Institute of Engineering and Technology professional project exemption by virtue of having completed SDP3333, you must complete the self-assessment grid and bind completed grids into all copies of the reports. The project report gives you the opportunity to demonstrate an appropriate level of professional competence in the practical development of a suitable application, tool or similar product or the generation of meaningful results. While all projects are different, we have attempted to come up with a generic checklist (which conforms to the requirements of the British Computer Society for professional projects) and which may be used as an aid in considering the components of your project. Please complete this list which may be used as part of the assessment of your project. And bind a copy into each copy of the project report Please enter your comments below explaining to your supervisor and second marker how you considered/addressed the following: Elucidation of the problem and the objectives of the project (objectives need to be clearly stated and if possible measurable upon completion). An in-depth investigation of the context/literature/other similar products. A clear definition of the problem A clear description of the stages of the life cycle undertaken (if this is a development project), or the ordering of the project activities. Please note that this refers to a structured approach for deriving a solution, involving a number of stages. It does not imply a sequential development pattern, but rather refers to a focus on the development process and on multiple identifiable phases. A description of the use of appropriate tools and the choice of methods to support the development process, the information gathering and/or the investigation (should also address the range of potential tools/methods and reasons why final selection was made).   A description of how verification and validation were applied at all stages (with a particular emphasis on test plans and their derivation). Consideration of the quality of the solution or findings -- if a product is being developed, it is often expected that it will exhibit the attributes of quality, reliability, timeliness and maintainability A critical appraisal of the project, indicating the rationale for design/implementation decisions or other choices and lessons learnt during the course of the project. Evaluation (with hindsight) of the product and the process of its production (including a review of the plan and any deviations from it and self evaluation of the work). You may also want to consider future work. References Appendices - technical documentation Professional projects imply pride in the products that you develop. Please remember to acknowledge all contributions and cite your sources. It is normally necessary to rely on work developed by other people. This can be used to support and advance your argument. Acknowledging the original contributors suggests that you know where to look, what is relevant, and are using it to support your opinion and strengthen your position. The quality of presentation The use of language The fact that critical appraisal, rationale, justification and lessons derived from the effort in the final evaluation can be applied to both the product (artefact, solution or result) and the process used to deliver it