What am I required to do in this assignment?

‘Shared Power’ is an information system to help tradesmen share expensive and specialist tools rather than buying them themselves.
Registered owners add details of the tools they have available including the per day and per half day rate for each unit.  Other registered users can hire the tools.  They can search and check the availability of a tool, up to 6 weeks in advance.  If a tool is available it can booked for up to 3 days.
Although tools are usually collected by the hiring user it is possible to arrange a dispatch rider to pick-up or drop off in urgent situations.  There would be a charge for this additional service.
Returning a tool late is fined at double the day rate for every day it is missing.
Invoices are produced for all users on a monthly basis.  The invoice includes the hire charges for that month together with any delivery costs and late fees. A flat charge of £5 is added to all bills for insurance.
When tools are booked in or out notes (and possibly photos) on the condition of the tool are uploaded to the system. If there is a serious issue of damage or wear with a unit, then the insurance company investigates to determine who is at fault and if necessary pays for the repair of the tool.  When tools are being repaired they are unavailable for hire.
The following items should be submitted as your/your groups deliverables for this assignment.
1.         Requirements Analysis/Design Document
A requirements analysis document containing the following sections:
1.1.      Sea Level Use Cases
Using the techniques you have learned, you should identify system actors, the most important processes and services the system must provide and the relationships between them.
1.2.      Scenarios
You should identify and illustrate the most important scenarios or stories about how the system is used.  These should include descriptions of how the system is being used in each case.
1.2.      Fish Level Use Cases
You should identify at least two sea level use cases and create fish level diagrams for them.  Make sure that you have identified use cases that can be further analysed into Clam Level Use Cases
1.3.      Clam Level Use Cases
For the Fish Level Use Cases you have created, you should now create at least two Clam Level Use Cases.
1.4.      Activity Diagrams
You should use activity diagrams to describe the steps involved in the tasks and processes you have identified for the system.
1.5.      Class Diagrams (Optional)
You should use class diagrams to describe the structure you have identified for the system only if you use an object-oriented approach.
2.         Implementation
Having thought about how a large-scale system would work you should implement a small-scale prototype using Python.
Your system should implement the key functions you have identified.  You are not required to implement an on-line server-based system or use a graphical user interface, just a Python program which demonstrates the features you have identified. That said, bonus marks will be given for added value on implementation.
2.1.       User Interface
You may use text-based menus like the ones you may have created in the lab exercises, for example:
1)   Login
2)   Search for tools
3)   Create new account
4)   Exit
Enter your choice:
You may design a Graphical User Interface instead if you wish but it is not a requirement for you to do so.
2.2.       Functional logic
You should also write code to implement a version of the basic functions the system provides, using the techniques you have learned including appropriate data structures and techniques (extending these if you wish)
You are not required to implement a client-server model with network connection.
3.         Individual Reflective Report
This part of the assignment is based upon your individual contribution to the project together with your experience of working with your group.
Your report should include the following:
a)         Any assumptions you made about the problem. Did these assumptions prove to be valid or did they change after further evaluation?
b)         How the group was organised. Who did what?
c)         A brief account of the work you did - illustrated with diagrams and snippets of code.
d)         Any problems you faced.
e)         What did you feel were the strengths and weaknesses of your team?
f)          What lessons did you learn about yourself from your experiences of working in this team?
4.         Group Presentation
The date and time of the group presentations will be posted to BREO nearer the time but will take place in week 14 or week 15.
Your presentation should take between 15 and 20 minutes and include no more than 10 slides.  The first slide should include the name and student number for each student in the group.
The presentation should explain the solution you proposed with screenshots of the application being used.  Do not show code on the slides.
Every member of the group must participate in the presentation and there will be a question and answer session afterwards. It is strongly recommended that you rehearse your presentation beforehand.

Is there a size limit?

The individual report should be approximately 1000 (+/- 10%) words (not including appendices).

What do I need to do to pass? (Threshold Expectations from UIF)

Demonstrate your ability to work as a team of 6 people.
Demonstrate your ability to apply programming competencies contributing to at least 15% of the total work.
Demonstrate your ability to apply modelling competencies contributing to at least 15% of the total work.
Demonstrate core analysis and software development skills contributing to at least 15% of the total work.
Marking will draw on evidence in the final report (40%), peer review documents (20%) and responses
to questions (40%) during the presentation to determine your actual contribution

How do I produce high quality work that merits a good grade?

Make sure that your UML diagrams are clear without being too detailed.  They need to clearly explain the concepts you are modelling without causing confusion to the reader.
Your code should make good use of the concepts we have been covering in the lectures and practicals.  Make sure that you check all user inputs are valid.  Make use of comments in your code so ensure maintainability. Remember that others need to be able to read and understand what your code is doing.
Test your application and show evidence of how you tested it.  Get someone else to run your application as they might discover issues that you have missed.
Your individual report is your chance to explain what you did in the group. What role did you play and how did it go?  Did the group work well together? What went well and what didn’t.  Be prepared to criticise yourself and make sure that any feedback on other team members is fair and accurate.
Make sure you proof-read and spell-check your report before submitting it.  Reading work out loud is often a great way to identify sentences that don’t flow well.
Your presentation should involve everyone in the group.  Make sure your slides are well organised and not too crowded – bullet points work better than paragraphs and paragraphs of text.  Consider using screen shots of your application if you want to but don’t put code on slides.

How does assignment relate to what we are doing in scheduled sessions?

This assignment requires you to use the UML tools and techniques you have been learning and using in the lectures and practical sessions.
The assignment also requires you to demonstrate your understanding of Python using the tools and techniques you have been learning and using in the lectures and practical sessions.

How will my assignment be marked?

Your assignment be marked according to the threshold expectations and the criteria on the following page.
You can use them to evaluate your own work and estimate your grade before you submit.

	Lower 2 nd – 50-59%	Upper 2 nd – 60-69%	1 st Class – 70%+
1	Requirements Analysis/Design Document Some sea, fish and clam level use cases included and some are accurate. Some scenarios included to validate use cases. Some activity diagrams present and accurate. Some or no class diagrams are present and accurate.	Requirements Analysis/Design Document Most sea, fish and clam level use cases included and accurate. Most scenarios included to validate use cases. Most activity diagrams present and accurate. Most class diagrams are present and accurate.	Requirements Analysis/Design Document All sea, fish and clam level use cases included and accurate. All scenarios included to validate use cases. All activity diagrams present and accurate. All class diagrams are present and accurate.
2	Implementation Some of the application is functional. Text Based or Graphical User Interface. Little or no evidence of an object-oriented development approach. The application is a file-based solution. Little or no evidence of documentation/comments within the code. Little or no evidence of documentation/comments within the code.	Implementation Most of the application is functional. Text Based or Graphical User Interface. Some evidence of an object-oriented development approach. The application is a file-based solution. Some evidence of documentation/comments within the code. Some evidence of thought given to future maintainability.	Implementation Fully functional application. Text Based or Graphical User Interface. Object Oriented Development Approach. The application is a database-based solution. Code is well documented and developed in such a way as to promote maintainability.
3	Individual Report The report is missing several major sections. Little or no thought given to the requirements of the report. Report badly written and containing lots of spelling mistakes.	Individual Report Some major sections missing from the report. Some requirements of the report not fulfilled. Some spelling mistakes.  Little evidence that the report has been proof ready before submission.	Individual Report A clearly and well thought out report covering all of the areas defined above. Clear evidence of your contribution to the group. Very few spelling errors in the document.
4	Presentation Only some of the team are presenting. Badly laid out or missing slides.  Several guidelines not followed. Mediocre presentation. A few team members are able to demonstrate a reasonable working knowledge of the work carried out for the assignment.	Presentation All of the team are presenting. Some issues with the slides.  Some guidelines not followed. Reasonable presentation. Some team members are able to demonstrate a reasonable working knowledge of the work carried out for the assignment.	Presentation All of the team are presenting. Well thought out slides with all guidelines followed. Good presentation. All team members are able to demonstrate a good working knowledge of the work carried out for the assignment.