Get documents about "Moderator's report
Document Sample
School of Computing & Engineering Systems
SA0931A – Internet Development
L Ball
Coursework
Unit - 2
Instructions:
Please submit your completed assessment by one of the following methods :
Posting it in the Submission Box : You may 'post' it in the 'Coursework
Submission Box' on level 4 of the Kydd
Building, outside the School Office,
Room 4523.
Posting it by Recorded Delivery to: School of Computing & Engineering Systems
University of Abertay Dundee
Kydd Building
Dundee
DD1 1HG
The latest hand-in time for all courseworks is 4 pm.
For all courseworks submitted by 4 pm an electronic receipt will be sent to your University email
account by the end of that working day.
School of Computing & Engineering Systems
SA0931A
Database and Internet Application Design
Unit 2 : Coursework
Part 1 – Dynamic Internet Site
Instructions
Additional Materials
Examiner(s) M Mactavish
Moderator(s) D Carmichael
SA0931A Database and Internet Application Design
Coursework
Dynamic Internet Site
This module, and the related SA0932A Server Side Internet Development, is based on a
project-based learning approach. You will plan and develop a major Internet
application. A project plan / schedule is attached as Appendix 2, and a specification of
the project is attached as Appendix 3.
The coursework element of SA0931A asks you to undertake the structural and strategic
analysis, planning and design of your application. This assessment takes the form of a
series of reports. These are due for submission on various dates during semester 1.
The application will be developed during semester 2 in module SA0932A. This
document provides information only about the coursework for SA0931A.
WHAT YOU HAVE TO DO
Your work will consist of three reports that form the project plan for the module. Your
reports should discuss the following aspects of the structural analysis and design of the
application that you will plan in SA0931A and construct in SA0932A. The three stages
are:
1. Data and structure plan (due by 16/10/2009)
2. A site plan with details of all of the templates that are required (due by
06/11/2009)
3. Full database schema plus optimised functional plan (due by 27/11/2009)
These three reports should be submitted by the deadlines noted. They are formative.
That is, they are designed to help you build your learning over time. You will receive
feedback on each report within three weeks of the submission date. You will also
receive an 'indicative grade'.
A complete set of all three reports MUST also be submitted by Friday 15
January 2010. This will be the formal submission and can include any updates you
make as a result of feedback provided for the individual reports.
Your reports should be aimed at a client that may have commissioned the project and
should explain your approach as simply as possible. Each report will consist of a mix
of text, diagrams, etc as appropriate to the content that is being delivered.
Each report should be in a format that is appropriate to its content:
Report 1 should be mainly text and be about 3-4 pages long
Reports 2 and 3 are mainly diagrammatic. You should supply 2-3 pages of text
that explains your logic, and attach your diagrams, etc. as appendices.
Bear in mind the ultimate product of modules SA0931A and SA0932A – a
COMPLEX, dynamic internet application.
The purpose of this coursework is to produce a well thought out structural plan and
functional design for your application.
For that reason, it‟s extremely important to think about content, data structures, etc.
SUBMISSION NOTES:
All elements of the coursework should be submitted, in accordance with the Coursework
Submission Procedure of the School of Computing & Engineering Systems, by the deadline
stated on the first page of this document.
GRADING SCHEME:
This assessment will contribute 50% of the overall grade for this module.
Indicative grades will be issued for each of the three stage reports. These are for feedback
purposes. The actual grade for this assessment will be based on the final submission of all
three reports that you submit by 15 January 2010.
LEARNING OUTCOMES
The learning outcomes assessed in this coursework:
1. Analyse application requirements and design appropriate
Yes
conceptual database models
2. Analyse the fundamental principles, concepts and techniques Partly
relevant to modern database technologies
3. Evaluate different options available in planning database- Yes
driven Internet solutions.
DISTRIBUTION OF GRADES
Grades will be allocated according to the general provisions of the university‟s Modular
Scheme.
The table in Appendix 1 provides information about the distribution of grades.
Feedback will be provided after the indicative grading of each stage has been completed.
Students are encouraged to revise their reports, taking account of feedback provided, to
improve any remaining reports and to present the best possible final submission. Feedback
will also be provided after grading of the final submissions has been completed.
Appendix 1. Grading Scheme
Stage Report
Description of the (3 reports)
Grade
Grade 50% in aggregate
A Excellent Outstanding An excellent submission that shows complete
performance – an understanding of the principles and practise of
excellent grasp of the Internet application planning and design. All of
subject matter. the topics and points contained within the
project schedule for the submitted stage are
addressed, with excellent use of diagrams, lists,
descriptive narrative, etc.
B Very Good A very good grasp of A sound submission that shows a high level of
the subject matter. understanding. The topics and points
contained within the project schedule for the
submitted stage are addressed to a high
standard, with very good use of diagrams, lists,
descriptive narrative, etc.
C Good Generally sound grasp A competent submission that shows a good
of the subject matter, level of understanding. The planning and
exceeds the threshold design processes are well explained. Most of
standard. the topics and points contained within the
project schedule for the submitted stage are
addressed to a good standard, with effective
use of diagrams, lists, descriptive narrative, etc.
D Satisfactory A satisfactory A satisfactory submission that shows
performance overall, reasonable understanding. The planning and
but limited grasp of design processes are explained adequately.
some areas of the Many of the topics and points contained within
subject matter. Has the project schedule for the submitted stage
achieved the threshold are addressed, some to a good standard, with
level. some use of diagrams, lists, etc. as well as
descriptive narrative.
MF Marginal Fail Performance just A fair submission that shows some
below the threshold understanding. The planning and design
standard. A reasonable processes are outlined. Some of the topics
expectation that a pass and points contained within the project
is achievable by schedule for the submitted stage are
reassessment without addressed, some but not all to an acceptable
the need to repeat the standard. There may be a limited use of
module. diagrams, lists, etc to supplement descriptive
narrative.
F Clear Fail Performance well The submission has little commend it. It shows
below the threshold little understanding and provides little insight
level. Some limited into the planning and design processes. Few
evidence of of the topics and points contained within the
achievement of the project schedule for the submitted stage are
outcomes. addressed to an acceptable standard. Content
is limited in quantity and scope, and the use of
diagrams, lists, etc. is limited.
LA Little Evidence Little evidence of The submission shows little or no
of Any achievement of the understanding and little insight into the
Achievement learning outcomes. planning and design processes. Few of the
Work presented is topics and points contained within the project
skeletal and/or schedule for the submitted stage are
irrelevant. addressed. Content is limited in quantity and
scope, and there is sparse use of diagrams,
lists, etc.
NS No submission No assessments
submitted.
I Incomplete Assessment incomplete
due to valid mitigating
circumstances.
Appendix 2. Project Plan
STAGE 1 (Data Analysis & Structural Plan)
SUBMISSION DATE: 16 OCTOBER 2009
WHAT TO DO WHAT TO INCLUDE
1: Develop an Outline Your understanding of the topic
Proposal
Your understanding of the functional
requirements?
What would you provide that would make users
want to use your application rather than other
similar ones?
How will it work (in overview)?
How will you monitor and modify if necessary your
project goals?
How will you plan & control your work?
How will your project satisfy the learning
outcomes for this module (see the „Module
Descriptor‟ – this is available from the „Module
Profile‟ page)?
2: Acquiring Information Where will you source material for your site?
(the following are some examples of possible
sources):
Existing web resources
Old newspapers, magazines, etc
Monitoring „new‟ news
Maps
Images – photos. Logos, etc (watch out for
Intellectual Property Rights such as Copyright,
and get permission to use any protected imagery
Books (UAD and public libraries, National Library
of Scotland, British Library, etc – remember that
you can use the UAD library to obtain resources
from elsewhere through the inter-library loan
scheme)
Interviews, phone calls, emails, etc.
3: Organising Your You now need to break your content up into areas
Information that will be presented to users in different ways:
Text (of course)
What might be best presented in tabular format?
What might be best presented in charts?
Should you supply some in spreadsheet format?
Photos
Other graphics – outsourced and self-generated
What about animated objects?
IMPORTANTLY AT THIS POINT:
Show how will the information be structured?
Show how will it be navigated?
Show the various Access Paths to reach critical
data? (i.e. show how users can get to the various
pieces of information. If there are multiple routes
to the same piece of information, show all of
them)
4: Develop Coherent Which pieces of information will you actually use?
Structures
The following two items will help you work out
how the content in your application will be split up
for database storage and for navigation:
How will information be split into groups
and categories?
What will be the relationships between
these items?
The next two items will help you think about how
much „programming‟ you will need to undertake.
Don‟t worry if you don‟t know how to program it
yet – just think about what you would like to
achieve:
What information will be presented in „raw‟
format (i.e. as you found or stored it)?
What other processing requirements will
have to be covered?
CONTENT OF YOUR REPORT
At this point, you should be able to produce a report that shows whether your plans for
your project is feasible (a „runner‟). You should have a good idea of the architecture of
your application and know roughly how both the data and interface will be structured.
This Stage Report should cover the points listed above. It should also show that:
1. you have actively engaged with the assessment
2. there is enough „meat‟ to let you meet the demands of both assessments
3. your project is realistic in terms of scope – it‟s easy to be over-ambitious and if I
think that this is the case, I‟ll be able to talk things through with you. This will
save you doing a lot of unnecessary work later in the session. the size of your
data set,
4. how you will present the content to users,
5. how users will be able to access the content (i.e. the navigation system),
6. what portions of content will have to be processed by your system
STAGE 2 (Site Plan & Templates)
SUBMISSION DATE: 06 November 2009
WHAT TO DO WHAT TO INCLUDE
5: List Your Page At this stage, you should prepare a schedule of
Templates page templates. A „page template‟, means „a
dynamic web page that will be used to output
more than one set of information‟.
For example, a „product details‟ page in a
shopping system will be a single „template‟ that
can be populated with information about any of
possibly hundreds of products in a catalogue. You
can show any number of items by providing links
to a previous and/or next page that will display
the next batch. This concept will be described in
class.
You need to decide what content will be static
(pages containing information that is unlikely to
change) and what will be dynamic (pages whose
content likely to change in the short/medium
term)
At the end of this task, the complete structure of
the final site will have been defined.
CONTENT OF YOUR REPORT
At this point, your project will have been developed to the extent required to construct
a static web site. YOU DO NOT HAVE TO CONSTRUCT IT.
The intention is that the structural design of your application will have been identified.
When you develop your application, you should be able to simply follow your plan. You
shouldn‟t have to rework any major components, and hence you will save a lot of time
and effort.
Think of it as a building contractor would a block of flats. Once they have erected the
steel framework, it‟s too late to go back and rethink the foundations. So make sure
your foundations are properly laid out before you start erecting your steelwork!
This Stage Report should cover the points listed above. It should also show that:
1. you have covered all of the items contained in the functional specification,
2. you have thought through all appropriate 'data access paths' that different users
might have in their 'mental model' of your web,
3. you have your files in logical groups and have thought about relationships
between functions as well as content
STAGE 3 (Database Schema and Functional Plan)
SUBMISSION DATE: 27 November 2009
WHAT TO DO WHAT TO INCLUDE
6: Prepare A Database Define your tables, including attribute (column,
Schema field) names, data types, relationships, etc.
Populate the database with a small amount of data
(enough for developing, testing, etc.)
7: Prepare a Schedule of Business Processes are simply the processes that
Business Processes will make your application „work‟ – for example, if
a shopping cart is required, you would need
processes to store items in the user‟s cart,
processes for the checkout, etc. Think about the
things you want to do (refer back to what you
wrote at step 5 for example) and identify what
processes are required (section by section)
Prepare sketches, diagrams, or other notes, to
show how you will perform these data
transformations. If a cart system is needed, you
would think about to display items to the user,
how to provide additional information, add items
to the basket and keep track of these items,
calculate totals, add VAT and carriage, etc. If you
will have a payment system, think about how that
will work, how you will record orders, and so on.
You DO NOT have to write any code at this point.
But you DO need to have thought about what you
need to do and how you would go about it. The
„add VAT‟ section, for example, would say
something like “get the total for the purchases and
multiply by the VAT rate to find the VAT amount”.
Identify processes that are used multiple times –
you will be taught to write applications in ways
that mean you write a processes once, and use it
many times.
You DO NOT have to produce the code for any of
these processes – this is what you will learn in the
term 2 module SA0932A. For now, you only need
to think about what processes your application will
need, and break them down into logical steps.
The ultimate idea is that, when you start to
develop your application, you will be able to
concentrate on implementation. The design will
already have been completed, and you just have
to go back to your notes and figure out how to
translate the ideas into working code!
CONTENT OF YOUR REPORT
The two steps that lead to stage report 4 will complete the structural and strategic
analysis, planning and design of your project. Stage report 4 is the final component of
the coursework for SA0931A.
This Stage Report should cover the points listed above. It should show that you have
thought through the basic concept of reusing bits of functionality. Think about this in
terms of the current task of writing up your data transformations … you can start to use
this principle already. Let‟s say you want to calculate VAT in ten different places in your
application. For this stage report, would you write out the process ten times on ten
sheets of paper? Or would you write the process once and, in the other ten places, say
„refer to sheet x for details of this process. Make it easy on yourself - write it once and
make a note of where else it is used.
Appendix 3. Project Specification
Bicycles Direct is a forthcoming new chain of shops for all grades of cyclists. Initially, there will
be 20 shops but, within two years, there will be upwards of 100, distributed right across the UK.
The company expect that a high proportion of their total sales will be generated by a web site.
In preparation for this, they have acquired the domain name ' bicycles-direct.co.uk '.
They have asked you to develop a prototype of their new application and have prepared the
following outline specification.
The application requires the development of a range of pages.
A number of pages that will have 'static' content – the information on these pages will not
change in the short or medium term. These files include:
1. entry/home page
2. about us
3. contact us
4. register (a form)
5. log-in (also a form)
The rest of the site will operate via a collection of dynamic template pages. These files include:
1. list of shops, with address, phone number and email address
2. categories of goods for sale (cycles, spares, clothing, accessories, etc)
3. variants of each category (mountain bikes, racing bikes, children's bikes, etc)
4. online shopping facility (explained in more detail below)
5. user registration and log-in
6. a forum (explained in more detail below)
7. a feedback/comments system (explained in more detail below)
8. an administration area where management can insert, update and delete data
Content should be of a quantity and type that is representative of the live application.
All of the dynamic pages should work as they would in the final application.
In the final application, users should be able to browse through the company's ranges of goods
for sale. Brief details of each item in a range/category/other subdivision (e.g. cycle helmets)
should be displayed, along with a small image, on a 'thumbnails' page. This would ideally show
a grid of, say, 8 items per screen and have controls that allow users to move to the next or
previous set of 8.
Optionally, you might want to have a 'best sellers' feature where, when the user selects a
category or range, the grid of thumbnails is accompanied by a short list of the best selling
products in that category or range.
Selecting an item should take the user to a 'details' page on which a large image is shown,
together with more detailed information about the chosen item. This page should allow the user
to add the item to their' shopping basket' and, if appropriate, select their preferred variant (e.g.
colour, size, etc.). The basket should be capable of holding many items, all being bought in the
same visit to the 'shop'.
The company would like to include a feature where, if a customer adds a bike to their 'basket',
they will be shown accessories etc. that might appeal as 'extras'. Customers should see the
suggested products and add any they like to their basket.
Once an item has been added to their 'basket' they should be able to change or delete it.
Once the user has completed their order, they should be taken to a 'checkout' page on which
they can commit to purchase their order. Customers should not have to register with the
application before they can place an order. However, those who do register will be given a 5%
discount on all purchases. The 'checkout' page should have a 'log-in' option where registered
users can log in. Those who do not wish to register, and those who are not currently registered
and want to register, will need to supply their contact information. We want to collect the
following information:
name
address (with street, area, town, postcode input and stored separately)
home phone number OR
mobile phone number
email address
When a 'registered' customer makes a purchase and logs in, the system should deduct their
discount from the total price of the order.
All orders should be recorded in the database, with the customer's registration ID, date and total
cost PLUS details of ALL of the items ordered. The intention is that customers' purchases would
be tracked over time and special offers relating to their known preferences would be sent to
them by email. This will NOT be part of the practical implementation coursework (SA0932A), but
the database design and functionality should support the future intention.
When users 'check out', they should pay online. The module has a facsimile payment gateway –
'AberPay' which emulates online payment systems. Your prototype should submit each payment
request to AberPay, get the result generated by AberPay and use that to either approve or
decline the order. Details of how to use the AberPay system are available at
http://m513042.cct.abertay.ac.uk/AberPay/help.htm or from the 'Practicals' page of the module
Intranet site.
When the order and payment are complete, details of the order should be sent by email to the
selected shop (e.g. dundee@bicycles-direct.co.uk) with a copy to the customer.
There should be a feedback area where customers can 'rate' a product on the menu. The idea is
to let users tell other users what's hot! If I really liked a particular bike pump, I could give it 8
bells (or whatever) out of 10. If I disliked the turbo-charged unicycle, I could give it 2 bells out
of 10. If they wish, they should be able to leave a comment that supplements their rating.
Customers would only be able to leave a rating or comment after they log in. Thus we can be
sure that only genuine customers can contribute AND any offensive comments can be tracked to
the user who submitted it.
Finally, there should be an administration area, and this should be written in your secondary
coding environment. This should require an administrator to be authenticated. Once logged in,
they should see a page that displays the jobs the administrator can perform. These should
include:
add, update and delete any item from the menu
edit and delete users
edit and delete customer feedback
get summary information about orders –
get the total sales between two dates input by the administrator
get the total number of orders in the last four weeks for all shops, ranked by number
of sales
get the total sales in the last four weeks for all shops, ranked by value of sales
This is quite an adventurous specification. WE DO NOT EXPECT YOU TO PROVIDE EVERY
ELEMENT IN THE COMPLETED PROJECT. It is an aspiration, and you should try to implement as
many features as possible.
However, for this coursework (SA0931A) you MUST plan to include the required functionality.
This is a 'thinking' module and it is the complexity of the requirements that presents the
challenge of this assessment.
