未命名
Outline:
Assignment 2 takes the form of substantial written report which shows
how the plan/proposal submitted for assignment 1 (Project Proposal) was
executed. To gain a high mark, your artefact and the report that describes it
must be of the highest standard.
Assignment 3 (see Assignment 3 documentation) is a practical
demonstration given to your first and second marker where you
demonstrate the artefact, or project solution, that has been described in this
project report.
The emphasis for assignments 2 and 3, as with assignment 1, is on
working independently, with the support of a supervisor, to achieve a set
aim. For the assignment presented here, you should work independently to
fulfil the project goals that were set out in your project proposal. Through
this process, you are expected to demonstrate the application of practical
and analytical skills, innovation and/or creativity, and the synthesis of
information, ideas and practices to generate a coherent problem solution.
The generation of an artefact that represents an output from two or more
stages of the software development life cycle is a key requirement of this
assessment documentation.
The Project Report should stand alone without the need for the reader to
refer back to the project proposal.
This assessment is marked based on the following sections and weightings:
1. Introduction – (10%)
The purpose of the introduction is to set the scene on what the project is
about, what problem does it address and what is the rationale for this
project. Within this section you should also give a
�
background to the work, what is the subject domain of the work you’re
doing?
Aims an Objectives should also form part of this section, even if they
have not changed since your project proposal, they need to be included
here.
2. Literature Review of related work and context – (15%)
The literature review is an essential requirement of any academic project.
A comprehensive review of the literature will provide further background
to the project. The literature review is where you contextualise your work
with respect to existing published literature.
A literature review is an account of what has been published on a topic by
accredited scholars and researchers. In writing the literature review, your
purpose is to convey to your reader what knowledge and ideas have been
established on your chosen topic, and what their strengths and weaknesses
are. As a piece of writing, the literature review must be defined by a
guiding concept (e.g., your research objective, the problem or issue you
are discussing). It is not just a descriptive list of the material available, or a
set of summaries.
3. SDLC – All stages, with emphasis on those you focused on – (65%)
This section should include all aspects of the Software Development
Lifecycle (SDLC) for the particular methodology you have selected. This
includes all stages from Requirements gathering, design, implementation,
testing, evolution and deployment. However, each project will be
inherently different and may focus on a specific part(s) of the SDLC, thus
this element will be more substantial than the others, and be the focus of
this part of your report.
Your report should also cover other details and content as detailed below:
3.1. Methodology
This section will cover a number of sub-sections – where appropriate. Not
all projects will require every section – discuss this with your supervisor.
Your supervisor will recommend the most appropriate structure for this
section of your report. The key thing is that you demonstrate critical
awareness of all of the processes that you have employed in your work.
Project Management.
Some awareness of project management should be demonstrated in all
projects. This section should outline the nature of your project and the
specific characteristics that need to be considered in determining what
project management methodology you should use. You should identify the
specific demands of your project in terms of project management, and
support your rationale for the selection of a methodology with appropriate,
recent academic references.
Software Development.
There should be a methodological analysis of software development
approaches used. The determining factors for selection will, amongst other
things, be the particular characteristics of the software to be developed, the
nature and predisposition of the client (if applicable) and the computer
environment requirements.
�
�
It is important to note that what is NOT required here is a pedestrian
account of popular software/IS development methodologies or a simplistic
review of their strengths and weaknesses. You are to work from the
specific requirements of your project and explain how these might
determine approaches for software /IS methodologies. Where relevant, you
should give serious thought to the proper design of research and
requirements capture approaches. This may include surveys,
questionnaires and interviews.
You should identify the specific demands of your project in terms of
software development, and support your rationale for the selection of a
methodology with appropriate, recent academic references. DO NOT
produce a simple discussion of software development, or explain how
typical methodologies work – (spiral, waterfall, etc.) – your first and
second markers already know this.
Research Methods.
You should include a section that investigates the types of research
methods necessary to validly answer the research questions that your
project addresses. You should cite relevant sources to justify your choices.
For example:
Were quantitative or qualitative research methods more appropriate? Why?
Do you need to have objective, observable data, or subjective, self-
reported data? Or a mixture of both?
Should the form of your data be nominal, ordinal, interval or ratio?
How do you intend representing your results? – this will have an impact on
your study design.
If you are doing an experimental analysis:
What are your independent and dependent variables?
Is a between-groups or within-groups approach most appropriate? Do you
need to statistically analyse your results?
Consult your supervisor when drawing this section up.
3.2. Design, Development and Evaluation
This section of the report will vary significantly in both structure and
content, depending on the type of project you are undertaking. For
example, a Games project may include a Game Design Document.
However, it must be noted that if your project contains significant software
development work, this should be presented in the structure expected of a
formal development report. If your project involves an experimental
evaluation – especially if that evaluation involved human participants –
you are expected to write this work up in the format expected of a
scientific research report. Some projects will include both software
development and experimental evaluation with human participants. In this
case, you are expected to discuss both procedures with sufficient detail.
Software development projects.
For projects that involve significant software development components, it
is expected that you discuss: 1. Requirements elicitation, collection and
analysis
2. Design
3. Building or coding
4. Testing
5. Operations and maintenance
Research projects.
For projects that include primary research components it is expected that
you present this work in a manner appropriate to a scientific report.
1. Participant recruitment
2. Evidence that ethical procedures have been followed. Include informed
consent documentation.
3. Study design (short summary of research methods section) – including
hypotheses.
4. A detailed description of the procedure that each study participant
experienced. Include every detail that would be needed in order to
replicate your work.
5. Results of experiment – present in the format of a scientific report.
6. Analysis of results. Consider the results of your work with respect to
both your own specific hypotheses and wider context identified in your
literature review.
Evaluation
Evaluation: Your artefact is the key deliverable in the project, so there
must be an evaluation carried out to determine how effective and
efficient your “solution” is at addressing the problem identified.
Appropriate metrics should be considered for this evaluation along with an
appropriate audience(s). Changes or amendments that may be required to
the original delivered artefact should be discussed here, pointing out how
and why these changes might have been effected if time or opportunity
presented itself.
4. Reflective Analysis – (10%)
Finally, the report should conclude with a critical reflection on the process
of completing the project. How did things go? What might have been done
differently, given 20:20 hindsight? What went well and why? What went
badly, why was that and how were any problems addressed? What more
could have been done, had time and circumstances not been constraints?
Consideration of the theory versus the practice in terms of methodological
process requires discussion. This is the only section of your report that can,
justifiably, be written in the first person.
5. References
The report will conclude with a List of References, in accordance with the
University of Lincoln Harvard Referencing Guide. Any Appendices will
appear after the List of References.
� �
Useful Information
Word Count: For a dissertation of this magnitude, a rough rule of thumb
for word count is 8,000 –
12,000 words. Remember, this a guide to help you understand roughly the
amount of work expected.
You won’t be marked down specifically for going over 12,000 or under
8,000 words. However, if your report is significantly above or below those
values you may wish to discuss this with your supervisor, it could be that a
large portion of your work is code, or it could be that you’ve missed
something substantial, or indeed if you are vastly over this word count,
you may need to be more succinct.
Please go to the library and read through some recent project reports in
order to ensure that you have included all relevant sections and to see how
appendices have been used. If you have included huge amounts of
information in appendices – for example, code from an application you
have built – it is fine to attach this as a DVD or memory stick, rather than
printing hundreds of pages.
This assignment must be presented according to the Lincoln School of
Computer Science guidelines for the presentation of assessed written work.
Students should ensure that they have a clear understanding of the grading
principles for this component, as detailed in the accompanying Criterion
Reference Grid (CRG). If students are unsure about any aspect of this
assessment component, they should seek the advice of their supervisor (in
the first instance) or, if the supervisor is unclear, that of a member of the
delivery team.
Submission Instructions
The deadline for submission of this work is included in the School
Submission dates on Blackboard.
An electronic submission ONLY is required for this assignment. The
electronic submission to Blackboard must be made before the cut-off date
and time set out in the Submission Deadlines spreadsheet on Blackboard.
Late penalties will be applied if your submission is after the deadline
without an approved extension.
DO NOT include this briefing document with your submission.