The Postgraduate Project-V51

The Postgraduate Project
MSc (IDS, ISEB, ASE, SEM)

June 2013
Version 5.1
School of Engineering & Computing Sciences
!"#$%#$&'
!"##$%&'()*+&,(%#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#-! !"!#.(/#,0#&12#3'(42+&#('56%,02)7# """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#-! !"8#.(/#,0#,&#6002002)7#""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#-! !"-#912%#)(20#&12#3'(42+&#&6:2#3;6+27# """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#-! !"<#916&#=6:20#>('#6#5(()#3'(42+&7#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#-! 8"#?'(42+&#@25*;6&,(%0#""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#A! 8"!#B2;,C2'6D;20#""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#A! 8"8#E12#?'(42+&#@23('&# """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#F! 8"-#B26);,%20#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#F! 8"<#G&6&2=2%&#(>#H',5,%6;#9(':#6%)#I&1,+0#J33'(C6;#""""""""""""""""""""""""""""""""""""""""""""""""""""#K! 8"A#@203(%0,D,;,&,20#(>#G&*)2%&#6%)#G*32'C,0('#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#K! 8"F#G2;2+&,%5#633'(3',6&2#.6')/6'2#6%)#G(>&/6'2#""""""""""""""""""""""""""""""""""""""""""""""""""""""""#L! 8"K#J00200=2%&#M',&2',6#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#L! 8"L#?'(42+&#N6':#J;;(+6&,(%#""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#O! -"#E12#?'(42+&#?'(+200#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#!P! -"!#9(':,%5#/,&1#Q(*'#G*32'C,0('#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""# !P! -"8#?'(42+&#J+&,C,&,20#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""# !P! -"-#G(=2#R02>*;#.,%&0#>('#6#G*++200>*;#?'(42+&#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""# !!! <"##H*&+(=20#>'(=#&12#@2026'+1#N2&1()0#S#?'(>200,(%6;#$00*20#N()*;2#"""#!-! <"!#M(%)*+&,%5#&12#T,&2'6&*'2#@2C,2/#""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""# !-! <"8#U('=6&#(>#&12#HC2'C,2/#)(+*=2%&# """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""# !-! <"-#U('=6&#(>#&12#G&6&2#(>#&12#J'&#@23('&#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""# !<! A"#E12#?'(42+&#@23('&#""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#!A! A"!#G&'*+&*'2#(>#&12#@23('&#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""# !A! "#$#$!%&'()!*+,!-.)*/0()!####################################################################################################################!$"! "#$#1!203'.*4'!##########################################################################################################################################!$"! "#$#5!%6)!/*&+!07,8!79!'6)!.)-7.'!#################################################################################################!$"! "#$#:!;)9).)+4)3!#####################################################################################################################################!$<! A"8#M(%&2%&#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""# !F! "#1#$!=)4'&7+!$!>+'.7,?4'&7+!#############################################################################################################!$<! "#1#1!=)4'&7+!1!;)(*'),!@7.A!###########################################################################################################!$<! "#1#5!=)4'&7+!5!=7(?'&7+!######################################################################################################################!$<! "#1#:!=)4'&7+!:!;)3?('3!########################################################################################################################!$B! "#1#"!=)4'&7+!"!CD*(?*'&7+!#################################################################################################################!$B! "#1#<!=)4'&7+!<!E7+4(?3&7+!#################################################################################################################!$B! F"#G(*'+2#N6&2',6;#6%)#@2>2'2%+20#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""# !L! J332%),V#JW#R02#(>#6#G&'*+&*'2)#JD0&'6+&#""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#!O! $%&'()*+&,(%#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""# !O! IV6=3;2#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""# !O! J332%),V#X#I&1,+0#J33'(C6;#U('="#"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""#8!!
Page 2 of 21
()''*#$+",-.$/"#'
The purpose of the project is to provide you with the opportunity to conduct a substantial piece of academic, scientific or engineering work as an individual initiative, and to document this as a set of scholarly reports. The final paper will demonstrate your analytical and reflective skills as well as your abilities in written communication. The overall aim is to draw together knowledge, skills and techniques that have been learned throughout the MSc programme.
!"!#$%&#'(#)*+#,-%.+/)#%-012'(+34#
The work for the project as well as the assessment is actually spread across two modules. The module on Research Methods and Professional Issues is a standard 15-credit module that prepares you for your project by teaching about project-related issues, including how to conduct a project and how to evaluate it. The main Project module (60 credits) then takes place after all of the taught modules are completed. For the Research Methods and Professional Issues module, the assessment elements consist of your project plan together with a state of the art literature report that you are required to prepare for the topic of your project. For the Project module, the assessment is through presentations of your work, together with a 20-page technical paper (dissertation). Although these modules are linked by one theme (your project) they are quite separate and are assessed separately.
!"5#$%&#'(#')#1((+((+34#
There will be at least three people involved in the assessment of your project, reflecting its importance in the overall final mark (the project counts for 60 credits out of a total of 180 credits needed for the award of an MSc). These are: your supervisor, an additional internal examiner, and the External Examiner who is responsible for overseeing the standards of the MSc programme. The assessment criteria for the project module are described in Section 2.7. You will receive formative assessment feedback before and during the project period through the regular supervisory meetings between student and supervisor. In addition, during the summer vacation period a compulsory bench test (demonstration) will be scheduled, where you will be asked to demonstrate, with the aid of a computer, what you have achieved by that point.
!"6#7*+2#3%+(#)*+#,-%.+/)#)18+#,91/+4#
The project module is timetabled to run through the summer vacation period. You are normally required to be resident in Durham through all of this time. If, during this period, you need to be away, then this should be discussed with the MSc Course Director and your supervisor well in advance. In addition, for any period of absence you should: Agree meeting times with your supervisor before you leave Inform the School about how we can get in contact with you during the time that you are away from Durham
!":#7*1)#;18+(#<%-#1#0%%3#,-%.+/)4#
While projects obviously differ according to topic, there are some general characteristics that a good project can be expected to possess. These include: Achieving excellent progress against the agreed objectives (i.e. hard work) Making a major contribution to the organisation and management of your project
Page 3 of 21
Providing clear evidence of the application of knowledge, skills and critical faculties learned from the rest of the programme (this is the single most important criterion) Performing a comprehensive and thorough literature review and presenting this in a knowledgeable and analytical manner Producing a deliverable of good quality that is well tested, and with full presentation of its features A coherent and well organised assessment and evaluation of the outcomes of the project, using appropriate forms and measures Clear conclusions from the work that you have undertaken, including a reflective presentation of the successes (and limitations) of the work A demonstration of good communication and presentational skills together with an appreciation and understanding of professional issues.
Page 4 of 21
0)'1+"2%.$'3%4-56$/"#&'
This section addresses the important procedures and regulations that apply to conducting the project. Detailed questions about project procedures should normally be addressed to your supervisor.
5"!#=+9'>+-1?9+(#
This section details the deliverables for both the Research Methods and Professional Issues module and also the Project module. The reason for this is that they are meant to form part of a progressive development and are best shown together. 1. For the Research Methods and Professional Issues module, the deliverables will consist of the following two documents: a. An Overview document, maximum of four (4) pages, comprised of: i. A structured abstract ii. A project specification (including descriptions of the three levels of deliverable: basic; intermediate; and advanced) iii. A project plan (including an evaluation plan and timetable) b. A State of the Art report, length 6-10 pages, structured as: i. The review method: describing how relevant books and papers have been identified and selected for the review ii. A review and summary of the selected books and papers, usually for 4-5 of the topics associated with the project, providing a background for the project iii. A bibliography section of 15-20+ references, normally with no more than three references to web sites 2. For the Project itself, the deliverables will consist of: a. Bench Test 1: which is a progress review that takes place in the summer, where students are expected to present a summary of progress to their supervisor, and where they should be prepared to discuss: i. The main functions of their software ii. How the functions are represented in the design iii. Elements of good design practice used iv. Problems encountered and how they were overcome v. Plans for completing the project b. Bench Test 2: This is an oral examination and software demonstration that takes place in one of the University buildings at the beginning of September, and before any marking of the remaining deliverables described below. This normally takes place with both examiners present, and a student should demonstrate the software that they have produced. They should expect to present to an audience that has knowledge of the subject, but not necessarily detailed knowledge of the specific project. It is the task of the student to lead
Page 5 of 21
the oral examination and explain their achievements in terms of the objectives, with suitable illustrations. c. A Technical Report of not more than 20 pages (the format for this is provided in the next section) note that the length guidelines will be adhered to strictly, and that markers will ignore any pages after the first 20 d. Any software produced for the project, along with test/evaluation data e. The project log book Suitable templates will be provided for the Technical Report in both MS Word and LaTeX formats.
5"5#@*+#A-%.+/)#B+,%-)#
The format of the project report should conform to the template provided. It should not be longer than 20 pages in length and consists of four main elements: 1. A title and preamble, with the latter identifying the student, supervisor and degree programme. 2. The abstract. This should be structured in form (see Appendix A) and will typically be around half a page in length. 3. The main body. This will consist of a set of sections as specified in the template. We have provided suggestions for the length limits of each sections, but overall, the report must not be more than 20 pages in length. 4. The references. These should be in Harvard (author, date) format. The number of references will obviously depend upon the nature of the project, but we would normally expect a minimum of ten references. Where possible, you should avoid using references to web sites, and if this is necessary, should ensure that they are correctly cited. It is particularly important that you note the requirements of length as only the first 20 pages will be taken into consideration when marking the project.
5"6#=+139'2+(#
There are two sets of deadlines. 1. For the deliverables that form part of the Research Methods and Professional Issues module, the deadlines are the same as for any other module. These must be submitted via DUO on the last day of the module. 2. For the deliverables that form part of the Project module, the report and any other relevant material must be submitted via DUO on the date specified by the Graduate School and no later than 4pm. Late reports will not be accepted without a penalty, unless a medical certificate is supplied. If a project is submitted after the deadline, the University-wide scheme for applying penalties to late work will be applied. In particular, machine or word-processing problems will not be accepted as an excuse for late submission. Students are reminded that all software produced as part of the course (including project work) is the property of the University.
Page 6 of 21
5":#C)1)+;+2)#%<#D-'0'219#7%-8#123#E)*'/(#F,,-%>19#
Students are required to provide a signed declaration on paper that is worded as follows: I declare that all assessed work to be submitted for my degree will be the results of my own work except where group work is involved. In the case of a group project, the work will be prepared in collaboration with other members of the group. In all other cases, material from the work of others will be suitably acknowledged and all quotations and paraphrasing will be suitably indicated. Within the project report and all other documents you must clearly acknowledge any work that is included that is not original (i.e. your own), including making clear how much, if any, of the code of your project is not original. If necessary, any declarations that materials (documents and/or source code) are not your own unaided work should also be included. All references to the work of others, published or otherwise, should be clearly identified in the text using quotation marks and citation. Regardless of whether or not your project, and its evaluation in particular, involves human participants, you should also complete an Ethical Approval Form for your project. (A short version of this is available for taught postgraduate projects and is described in Appendix B.)
5"G#B+(,%2('?'9')'+(#%<#C)H3+2)#123#CH,+->'(%-#
A successful project requires that both student and supervisor work effectively together. Responsibilities of the supervisor are: To provide guidance about the nature of the project and the standard expected, about planning of the project, about literature and sources, about techniques and methods, including ethical issues, and about any questions regarding plagiarism To maintain contact via regular supervision meetings To be accessible within reason at other times for providing advice to the student To give detailed advice on project milestones To ensure that a student is made aware of any inadequacy of progress, or of standards of work that fall below what is expected To encourage the student to produce early draft sections, to comment on them critically, and to return the comments within recommended feedback timescales. (It is the students responsibility to do this.)
Responsibilities of the student are: To agree on a schedule of meetings with the supervisor and to attend such meetings or provide adequate notice if meetings need to be postponed To take initiative in raising problems, however elementary these may seem To maintain the progress of the work in accordance with the milestones and the objectives agreed with the supervisor To plan the project and to monitor progress against the plan To keep a project log for recording results, ideas, references etc., where these are acquired as the project proceeds
Page 7 of 21
To determine the contents of the report and of any oral presentations
In summary, the management of the project and the course that it takes are ultimately your responsibility, with the supervisor acting as a guide.
5"I#C+9+/)'20#1,,-%,-'1)+#$1-3&1-+#123#C%<)&1-+#
The hardware and major software components may already have been specified by the topic of the project. This may also need to be organised well ahead of the starting date so that any necessary licenses can be obtained, versions checked etc. In such a situation, it is often quite infeasible to change these decisions once the project has started. However, many projects will still require choices to be made for the use of specific types of software tools. When selecting appropriate software that is part of the project, you need to be able to quantify the reasons for your choice in an objective manner when reporting. A student may use his or her own computer for part or all of the practical work involved in a project, provided that it is suitable for the purpose (as agreed with the supervisor) and that any proprietary software used is properly licensed. Note that the Universitys site licenses for software do not normally cover students personal computers. If you are using your own computer, the responsibility for backups etc. lies entirely with yourself. Demonstrations should normally be performed using ITS-supported computers unless you have your supervisors approval to use your own computer. It is also your responsibility to arrange an adequate demonstration if you are using a personal computer. Standard precautions against importing viruses must be observed.
5"J#F((+((;+2)#K-')+-'1#
A major objective of the project is to allow you to exercise the skills, knowledge, practices and critical thinking skills acquired in the taught modules. So top priority must be given to establishing the academic context of the project, and showing how your work relates to other work in the chosen field. The individual nature of projects means that each one will need to be assessed using different criteria. The criteria identified in Section 1.2 are important ones that all projects need to address to some degree. As an example, a project may MSc projects are not research projects. There is involve building a tool to make no obligation (as in a PhD) to produce original some form of measurements upon outcomes. In addition, the product element of a source code, in order to see if these project does not need to produce successful measures help predict (say) the ease results when exploring some ideaassessment is with which the code can be altered. based upon the processes that you have followed, If your evaluation of the tool then not the outcomes. A project that competently actually shows that these measures demonstrates that an idea is not feasible (and why) are of no or little value as predictors, is every bit as valuable a contribution to then this is still a valuable result. In knowledge as one that does. (See side box.) particular, the assessment of the project is related to how well it was Assessment of project work involves the undertaken, the quality of the supervisor, another member of staff, and the software tool, and the robustness of External Examiner. Any differences that may its evaluation, and not to whether arise between marks awarded by the various the original idea proved to be examiners will be investigated and resolved with successful or otherwise. care, and all marks will need to be approved by the MSc Board of Examiners.
!
Page 8 of 21
5"L#A-%.+/)#M1-8#F99%/1)'%2#
Both the MSc Viva (Bench Test 2) and the final technical paper are marked. The MSc Viva is worth 20% of the total project marks, and the final technical paper is worth 80% of the total project marks. The work described for the design and implementation (results) in the final technical paper must reflect the software that was demonstrated in the MSc Viva. The final technical paper will be marked using the following allocation of marks. Structured Abstract (5%) which should: Provide a clear summary of the key points from your paper Be capable of being used as a stand-alone description of the report
Introduction (5%), should clearly present the rationale for undertaking this particular study, and the question(s) that it is seeking to answer. Related Work (10%), where this should demonstrate: A good knowledge of the relevant literature and research findings, demonstrating their influence upon the approach taken A clear strategy for finding that information
Note that this needs to be different to the presentation used in the State of the Art report. Solution (20%), (a chapter which is essentially a mix of research method and design issues), looking for evidence of: Adequacy of the solution (architecture/design) adopted Problem-solving ability Provision of a rationale for specific design/strategy choices
Results (20%), looking for evidence of: Adequacy of the description of the results (including implementation) Discussion of implementation issues encountered Discussion of, and outcomes from, your testing strategy and related issues
Evaluation (20%), looking for evidence of: The evaluation strategy adopted and its suitability for your task Assessment of any limitations upon conclusions Identification of any threats to validity for the outcomes
Conclusion (10%), which should discuss the outcomes and link them to the initial question, together with any recommendations for further work. Management of project work (10%), a mark allocated by the supervisor
It is necessary to submit a technical paper in order to obtain a pass in the project module.
The Postgraduate Project Page 9 of 21
7)'89%'1+"2%.$'1+".%&&'
This chapter describes how you should undertake your project.
6"!#7%-8'20#&')*#N%H-#CH,+->'(%-#
Meetings with your supervisor will occur during the following three phases. For each phase the purpose and frequency of meetings will be different. 1. During the period of the Research Methods and Professional Issues module you should have four meetings. During this period, your main task is to produce the project plan and the state of the art report, as well as to undertake the tasks associated with the state of the art report. 2. Between the end of the Research Methods and Professional Issues module and the start of the main project period you should meet approximately every four weeks. During this period you should refine the project aims; plan how you will implement the overall plan for the project, and undertake any necessary background activities (obtaining software, learning to use new tools, programming languages etc.) However, the main focus should be on the other MSc modules that you follow in this period and you should not spend less time on these. 3. Over the summer period you should meet at regular intervals (preferably weekly whenever possible). Meetings should last approximately 30 minutes. It is expected that you will take the lead for each session, providing your supervisor with a summary of what has been achieved since the last meeting. You should then work together to identify what activities you should be undertaking to prepare for the next meeting. For each meeting the supervisor or student should complete a project report form. You should retain this form as part of your project log. Your supervisor and the School Office should also have a copy. Important Note: If you get into difficulties with your project work, e.g. you feel that you face insurmountable problems, or you feel that your progress is inadequate, you must contact your supervisor or the Director of your postgraduate programme, or the Dissertation module coordinator. Do not take any hasty action that you may later have cause to regret. Do not take short cuts, or attempt to disguise any problems with your project work or report.
6"5#A-%.+/)#F/)'>')'+(#
The work of the project builds upon the plan developed as part of the Research Methods and Professional Issues module, as well as drawing upon the state of the art report that you produced for this. This means that at the start of the project you should be well positioned to concentrate on the development tasks. Here, we briefly identify some expectations of these. The Design. The design task for a project usually centres upon software design, although some of the later elements such as evaluation also involve a design element. So, activities will include: Selection of an appropriate design technique or strategy to be employed Development of a design specification that provides an efficient and extendable solution for the given task
Page 10 of 21
Use of good software engineering practices such as modularity, reuse, traceability to the requirements etc. Generation of an implementation plan
Implementation. This involves realising the design using appropriate tools and processes. It may include addressing technical challenges as well as considering user needs such as usability and user expectations. Activities include: Use of good development practices such as incremental development Use of appropriate configuration management and versioning strategies and supporting these through the use of software tools
Software testing. This is concerned with ensuring that the implementation both functions as intended and also that it meets the user needs. Testing should always involve some form of test oracle to predict the outcomes of a test in order to provide a baseline for testing. Testing activities include: Defining an appropriate set of test cases (and predicted outcomes) that will exercise different features of the implementation Maintaining a record of outcomes, highlighting any actions taken in response to problems that were identified during testing
Evaluation. Project evaluation requires both the identification of a suitable strategy and then the development of an evaluation plan. This aspect will be covered in greater detail as part of the Research Methods and Professional Issues module. Note that every student must complete an Ethical Approval Form regardless of whether they will be using human participants as part of their evaluation process. (See Appendix B.)
6"6#C%;+#O(+<H9#$'2)(#<%-#1#CH//+((<H9#A-%.+/)#
Examiners commonly find that students have lost marks quite needlessly in the management and presentation of their projects. The following list is intended to indicate some ways in which this situation can be avoided for your project. Start on the task of background reading and literature search early, preferably right at the start of the Research Methods and Professional Issues module. If this is left until later, it will be hard to make up lost time. Make the most of your supervisors knowledge by preparing for meetings and asking questions (it is often helpful to prepare a short list before the meeting). Dont waste meeting time by asking questions about organisational issues such as those addressed in this handbook, concentrate on the issues that are important for your project. Remember that the project constitutes a substantial piece of work (one third of the credits needed for an MSc), so the examiners will be looking for major progress on the chosen task and substantial deliverables. Remember that the project report carries much weight in the marking process. Start drafting this in good time and use checklists to ensure that key issues are addressed. Pay adequate attention to the Results section of your work. An implementation with no results (or evaluation) is unlikely to be interesting to the reader.
Page 11 of 21
Use diagrams in your report. Even informal diagrams can help show how elements of your project fit together, and can provide the basis for a clear and concise textual description. Do explain the use of symbols (lines, boxes etc.) in any diagrams. Pay due attention to style and grammar. In particular, do not use the first person singular, such as I did, or by me. Ensure that the report has an appropriate level of academic content and is not just a description of an implementation. In particular, do not make unsubstantiated assertions (e.g. most users of the internet make use of) and ensure that any conclusions are logically linked to your results.
Try to ensure a consistent level of abstraction in your report, avoiding excessive detail (or a complete absence of any). Put yourself into the shoes of the reader who is not familiar with you or with your project. A report should form a narrative that takes the reader through the stages of your project from the first ideas (why do this) to the outcomes of final evaluation (was it successful to have done it?). Every project sets out to investigate something within a particular context, and hence is seeking to answer some form of question (we usually try to provide a concise statement of this in the introduction and refer to it as the research question). You should ensure that at the end of your report you report back on your findings about the research question (this is very rarely a yes or no answer).
Page 12 of 21
:)'';-$."<%&'=+"<'$9%'3%&%6+.9'>%$9",&'?'1+"=%&&/"#65' *&&-%&'>",-5%'
The purpose of this module, and of its summative assessed work, is to provide you with the opportunity to plan your project and to agree with your supervisor about its deliverables. In this section, we first discuss the issue of conducting a literature review to identify the books and papers relevant to your project, and then briefly describe the main features of the deliverables.
:"!#K%23H/)'20#)*+#P')+-1)H-+#B+>'+&#
There are different approaches that can be used to undertaking a literature review, and the one that you use should be that which is most suitable for the project that you are undertaking. At one extreme, a review can be conducted as a systematic review, using formalised search strings and a pre-selected group of electronic databases of papers. At the other, it can be an expert review that is largely based upon papers that are identified by your supervisor as being particularly relevant. In many cases it will fall between these, with your supervisor suggesting where key literature might be found, search strings that might help, etc. This aspect of the review will be addressed in the Research Methods & Professional Issues module and will not be repeated in this document. However, the following aspects of how you undertook your review will need to be noted and reported. If you have searched electronic databases of papers, you should ensure that your report describes which databases, and the search strings that were employed for each one. You should also note the criteria that you used to determine which papers and books were relevant to your needs. The provenance of the material found needs to be established. For published books and papers this is not a problem (for example, for a journal paper you will need to identify which journal, the volume, issues, year, pagination etc.) Information that is only available on the web, perhaps as a technical report or similar, needs to be treated with care. Again, details of how to cite such material will be covered in the module. If you have undertaken some experimental work with particular software packages or tools, in order to determine whether or not they might be used in your project, you should again give appropriate details.
These elements are an important element of context for your review and for any analysis that you might perform in this.
:"5#Q%-;1)#%<#)*+#D>+->'+&#3%/H;+2)#
The purpose of the Overview document is to provide a concise summary of what you are going to do for your project. It should contain the following elements (see also Section 2.1). 1. A structured abstract. Details of this are provided in Appendix A to this document. For the overview document only the first three recommended headings need to be used (since there are no results at this stage and no conclusion). 2. A Project Specification. This is intended to identify what your project is setting out to do, how you will know when this has been achieved (i.e. what measures apply and hence can demonstrate that the aims have been met), and how you expect to demonstrate this (e.g. what software you expect to produce and its functionality). In particular, the specification should clearly identify a set of deliverables from the project at the levels of basic (just sufficient for a passing grade if everything works
Page 13 of 21
can be demonstrated and is well documented); intermediate; and advanced (the sort of things that a project being undertaken at distinction level might produce and report upon). 3. The Project Plan. This is essentially your strategy for producing the deliverables and will include a timetable with some milestones as well as an outline plan for how you will evaluate your project to demonstrate what has been achieved. This document should be a maximum of four pages in length and use of typefaces, headings etc. should conform to the template provided.
:"6#Q%-;1)#%<#)*+#C)1)+#%<#)*+#F-)#B+,%-)#
This document is intended to provide the underpinnings for the Overview document. For details of length etc., see Section 2.1. As with the Overview, a template is provided and should be used. The required sections are as follows.
$# A section describing the Review Method. This should explain clearly how you set
about your review and the criteria used for selecting publications that you have included in the review. If you used electronic search engines, then you should identify which ones were used, and the search terms and parameters employed for each one. If your material was recommended by others (such as your supervisor) then make this clear too. Overall, the task of this section is to explain why this set of documents are the most relevant ones for your purpose.!
1# The Review. This provides the underpinning for the project and should identify and
summarise a number of key documents. These might address different aspects of the project: some may be concerned with the technical question that the project is addressing; others might be concerned with the choice of tools, environments etc.!
5# The Bibliography. This section should identify around 15-20+ key references,
including those described in the previous section, and should be formatted using Harvard style.!
Page 14 of 21
@)'89%'1+"2%.$'3%A"+$'
The project report takes the form of a technical paper with a pre-defined format. This section outlines the format, discusses the content of the major sections, and indicates how the assessment will be performed.
G"!#C)-H/)H-+#%<#)*+#B+,%-)#
Your report should conform to the following structure. Templates for both MS Word and LaTeX are provided. Note that you must not alter font sizes or line spacing in order to fit in more text. Title and preamble, identifying author and supervisor. Abstract, in the form of a Structured Abstract. Main body of the report as a series of sections that make up a narrative description of the work that you have done, identifying key decisions and demonstrating rigorous and analytical thinking about the task. References, using Harvard format.
Templates for this are available for both Word (.doc) and also LaTeX (.tex). Note that the maximum length of the report is 20 pages. Any pages in excess of this number will not be marked. Note that your report should be accompanied by a declaration of originality and you should have filed an Ethics Approval form at the start of the main project period. The rest of this section identifies how you should organise each of the four main elements.
@)()('8/$5%'6#,'A+%6<B5%'
The title is something that you should discuss with your supervisor. The title should not be overly long and should preferably avoid any acronyms. The preamble identifies you as the author, names your supervisor, and identifies the degree for which you are submitting this (usually expressed as MSc in Internet & Distributed Systems or the equivalent for the other degree programmes).
@)()0'CB&$+6.$'
This should again be a structured abstract as described in Appendix A. However, you should now use all five headings, since you are reporting on a completed project. The abstract is normally written in past tense and should use one or two sentences per section. For this paper, it should not be more than about half a page in length (remember that this is part of the overall 20-page limit), and should be capable of forming a stand-alone summary that we can publish as part of an index to our student projects.
@)()7'89%'<6/#'B",D'"='$9%'+%A"+$'
We have identified a set of headings to be used for this and the template provided explains what should normally be included in each section. Note that the introduction and the section on related work can draw upon the Overview and State of the Art reports that you produced for the Research Methods & Professional Issues module, but these would normally be substantially condensed for this report (for example, the related work section is normally only 2-4 pages in length) and may also include new material that you have found as the project has progressed.
The Postgraduate Project Page 15 of 21
@)():'3%=%+%#.%&'
As discussed previously, these should use Harvard format and should normally include no more than three URLs (and contain no references to unrefereed or opinion sources such as Wikipedia).
G"5#K%2)+2)#
The content for the abstract is derived from that of the main sections, described below.
@)0)('E%.$/"#'('*#$+",-.$/"#'
This section should be about 2 to 3 pages in length, and should briefly introduce the project background, the reasons why the project is relevant and worth doing, the research question that you are addressing, the project objectives, and deliverables, and an indication of the outcomes. It should also introduce the terminology that is going to be used (if this is substantial, it might be better to provide a short glossary as an appendix.) Conventionally, the last paragraph summarises the contents of the remaining sections to act as a road map for the reader. The aim of this section is to persuade a reader that this paper addresses a topic of relevance and interest. It is therefore well worth spending time getting this one right, since you need to ensure that the reader has a clear picture of what you have done, and why you did it.
@)0)0'E%.$/"#'0'3%56$%,'F"+G'
This section presents a survey of existing work that is related to the problem(s) that are being addressed in your project. It should be between 2 and 4 pages in length and its objective is to set your work into contextdescribing what others have done and what they have found. Where your work builds upon that of others, you should ensure that you discuss their work in this section. You should try to be balanced, dont just cherry pick papers that support the idea that you are pursuing, if there are others that present counter-arguments, then you should acknowledge this. It is particularly important that such work is referenced properly, through such conventions as: Use of quotation where material is directly reproduced from documents. By convention such material is placed in double quote marks, and often is also set in italics, for example: this is a quote from a very relevant paper. All quotations, direct or indirect (where you use your own words) must be acknowledged by referencing (using Harvard style).
This section may be derived from the work you undertook for the State of the Art report produced earlier. However, it will be more condensed in form (focus on key papers) and it may include further material that you have identified while undertaking the project.
@)0)7'E%.$/"#'7'E"5-$/"#'
This presents the work that you have done to address the research question. In most cases this is where you describe the design of your software and discuss what happened when you implemented it. You may want to use subsections to discuss such aspects as design, choice of technology, implementation, testing etc. Overall, this should be 4 to 7 pages in length. There are some aspects of these elements that you might want to emphasise, such as: The high-level architecture of your solution
Page 16 of 21
Rationale and justification for your choices, including any trade-offs involved The processes involved (how did you develop the design, implementation etc.) Any deviations from the plan if you had to change your ideas about the design during implementation, explain what changes you made, and why you did so.
@)0):'E%.$/"#':'3%&-5$&'
The purpose of this section is to make clear what the project achieved. The results of a project can take many forms, depending upon the nature of the project. For example, if your project has resulted in the development of a software tool, then you might want to summarise the functionality of this, and provide screen-shots. For a less interactive system, you might want to demonstrate how your system copes with a number of representative scenarios of use. Overall this section should be 2 to 3 pages in length.
@)0)@'E%.$/"#'@'HI65-6$/"#'
Evaluation should address both the process aspects of your project (for example, why you made particular choices and whether they proved to be good ones) as well as the product itself. One of the needs of evaluation is some form of measure that allows you to demonstrate the outcomes of the project, whether it be the usability of a software tool, or the effectiveness of an algorithm. Both quantitative and qualitative forms of evaluation are covered quite extensively in the Research Methods module. This section should normally be 1-2 pages in length. An important point here is that you get awarded marks for how well you undertook the evaluation, not for the results of it. If your evaluation of (say) a new plug-in feature for a browser leads to the conclusion that it was not a success, this is not too critical, what matters is how effectively you did the evaluation and what confidence you can have in the outcomes.
@)0)J'E%.$/"#'J'!"#.5-&/"#'
Along with the introduction, this is one of the most important sections in terms of its influence upon the readers opinion of your work, and can be much harder to write (or to write effectively) than you might expect. The main goals of this section are to: summarise the work undertaken; interpret the outcomes in terms of the original research question(s); analyse the outcomes to identify potential extensions (with reasons for why they are worth investigating).
(Take particular care with the last one, as this needs to be more than simply highlighting any deliverables that you didnt have time to complete.) This section should not be more than one page in length.
Page 17 of 21
I"#C%H-/+#M1)+-'19#123#B+<+-+2/+(#
The Research Methods module provides a bibliography of books and papers that address many of the issues in this handbook. There are also some useful textbooks about doing, evaluating, and reporting computing projects, which are listed below. Ayres R., (1999). The Essence of Professional Issues in Computing, Prentice Hall, ISBN 0139087400. Bott F., Coleman A., Eaton J and Rowland D., (2001). Professional Issues in Software Engineering, Taylor and Francis, ISBN 0748409513. Comford T. & Smithson, S., (2005). Project Research in Information Systems: A Students Guide. 2nd edition, Palgrave/MacMillan, ISBN 1403934711. Dawson, C., (1999). The Essence of Computing Projects: A Student's Guide, Prentice Hall, ISBN 013021972XA. Dejoie R. and Fowle G., (1991). Ethical Issues in Information Systems, Boyd and Fraser, ISBN 0878355626. Oates, B.J. (2006). Researching Information Systems and Computing, SAGE, ISBN 1-4129-0224-X Ricketts, I.W. (1998). Managing your Software Project. Springer-Verlag, ISBN 3540-76046-6. Sharp, J.A., Howard, K., (1996). The Management of a Student Research Project, 2nd edition, Gower, ISBN 0-566-07706-X.
Page 18 of 21
CAA%#,/K'CL'M&%'"='6'E$+-.$-+%,'CB&$+6.$'
R2)-%3H/)'%2#
An abstract should be less than one page, and it should summarise the complete project report/research paper as concisely as possible. It should be between 150-300 words, and should include the project objectives, approach and achievements. An abstract should be treated as a separate stand-alone document that summarises another document. Indeed, abstracts are often published separately, and are then used by researchers and others to determine whether or not to read the complete report. So an abstract should present all of the key information, but in a very condensed form. Many authors (not just students) find the task of writing the abstract to be quite a difficult task. A useful structure to use for the purpose of organising the abstract is to use a set of fixed headings (a structured abstract) and to write one or two sentences for each heading that describe how the project has addressed that heading. Suggested ones to use are:
Context/Background: Previous research or rationale for a study. Why the project is useful, needed, Aims: Hypotheses to be tested or goals of the study. What the project set out to achieve. Method: Description of the type of study, treatments (including control), number and nature of the experimental units (which may be people, teams, algorithms, programs, etc). Experimental design, outcome being measured. How the task was tackled (e.g. by developing a client/server solution that used or by constructing and conducting an on-line survey of). Results: Treatment outcome values, standard deviation and/or level of significance. Can be data or what was achieved if building software Conclusions: Future work, limitations of study. How well the aims were met.
ES1;,9+#
!
;+/4/#65'CB&$+6.$'
Overoptimistic predictions are common in software engineering projects, e.g., the average software project cost overrun is about 30%. This paper examines the use of two popular general tests of optimism (the ASQ and the LOT-R test) to select software engineers that are less likely to provide overoptimistic predictions. A necessary, but not sufficient, condition for this use is that there is a strong relationship between optimism score, as measured by the ASQ and LOT-R tests, and predictions. We report from two experiments on this topic. The experiments suggest that the relation between optimism score as measured by ASQ or LOT-R and predictions is too weak to enable a use of these optimism measurement instruments to select more realistic estimators in software organizations. Our results also suggest that a persons general level of optimism and over-optimistic predictions of performance are, to a large extent, unrelated.
(The structured form of this is shown on the next page.)
Page 19 of 21
'
E$+-.$-+%,'CB&$+6.$'
Context: Over-optimistic predictions are common in software engineering projects, as the average software project cost overrun is about 30%. One possible means to reduce over-optimism in estimates is to improve the selection of people less likely to have over-optimistic predictions. This selection maybe conducted through tests of standard tests of individual optimism. Aim: To study how well standard optimism measurement instruments (Attributional Style Questionnaire (ASQ) and Life orientation Test-Reduced (LOT-R) tests) correlate with optimistic predictions provided by software engineers. Method: The first experiment involved 25 software engineering students from the University of Oslo. Information was collected about their general level of optimism towards their studies using the ASQ tool. They were also asked about their levels of optimism at certain times leading up to and after the exam. The second experiment involved 14 senior project managers from a Norwegian software development company, who were asked to estimate the most likely level of effort needed to complete a specified software project. Optimism was measured using the LOT-R tool. Results: The correlation between optimism and level of over-optimism was low. 15 of the students categorized themselves as very pessimistic. The student predictions of their exam mark changed as the exam drew nearer as they became more pessimistic. Although the project was not completed, indications from the project manager suggest that the lowest predictions may be the most realistic. There was however, little correlation between optimism and predicted effort level. Conclusions: The experiments suggest that the relation between optimism score as measured by ASQ or LOT-R and predictions is too weak to enable a use of these optimism measurement instruments to select more realistic estimators in software organizations. Our results also suggest that a persons general level of optimism and over-optimistic predictions of performance are, to a large extent, unrelated.
As in the example above, structured abstracts do tend to be longer than unstructured ones, largely because the use of headings prompts the writer to provide more detail about essential aspects of the study which in this case was lacking in the original. However, studies of their use in various disciplines (including our own) show that readers find them easier to read and understand, and there seems to be some indication that they help the writer.
Page 20 of 21
CAA%#,/K'N'H$9/.&'CAA+"I65'O"+<)'
This is available on DUO and should be completed at the start of the main project period. If you initially decide that your evaluation will not use human participants, and then later decide that this is desirable, then you should submit a new form. An image of the form is provided below.
Page 21 of 21

The Postgraduate Project-V51

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

The Postgraduate Project-V51

Transféré par

Droits d'auteur :

Formats disponibles

The Postgraduate Project

MSc (IDS, ISEB, ASE, SEM)

School of Engineering & Computing Sciences