程序代写代做代考 database CO2015 Worksheet 2
CO2015 Worksheet 2
Start: 10th February 2017
Deadline: 6th March 2017 5pm
Weighting: 30%
Introduction
The module now moves into a software implementation phase. Groups should start developing the system
in an agile way. Tasks 6,7 and 8 describe how you will be assessed for the software implementation.
You are also required to produce design documentation (tasks 1,2 and 3) and project management
deliverables (tasks 4 and 5).
The weighting of tasks and marking criteria are available in the rubric in Blackboard.
Hint: You should be managing the work through the product backlog. You will need to add additional stories
for deliverables for worksheet.
Task 1: Architectural Design
Max 2000 words
Create a document to describe your initial architectural design decisions. The purpose of this document is to
explain any decisions that you have made so that people working on the project can work according to
these decisions. What you include in this document depends on what you think are the most important
things for your specific project.
Things that you should consider for your architectural design:
The technologies used to implement the system including frameworks and libraries. A short
explanation for what role the technology plays in the system and why it was chosen (do not list
technologies that were chosen for you, and do not give general descriptions of the technology that
could be found by googling them).
A high-level architectural diagram showing the main components/tiers of the application and the
communication that happens between them. This could include; external APIs, databases, layers/tiers
of the application, software components, end-user devices. Examples of this type of diagram are here,
here, here, here
Which, if any external APIs will be used (e.g for mapping data, payment systems) with justification for
why they were chosen over alternatives.
Security strategy: how will you ensure that the system is secure – i.e. that users can only access what
they are supposed to and that users can’t view other users’ data.
Performance strategy: what techniques will be used to ensure the performance/speed of the
application for small and large numbers of users. (How many users do you expect to use this system?)
Any other design notes or decisions that are helpful.
Any software design patterns that you will use and why.
https://creately.com/images/landing-new/aws/aws-2-large.jpg
http://www.surroundtech.com/media/43/da8e/43da8e234bb59b64ed914c33d327edb1/accelerator-high-level-software-architecture.png
https://shiro.apache.org/assets/images/ShiroArchitecture.png
https://raw.githubusercontent.com/paulc4/microservices-demo/master/shopping-system.jpg
A decent example from last year is available as 0_docs/example-architecture.pdf in the CO2015-16-
17-Template repository (although what was asked for is slightly different so don’t copy the structure too
closely)
Submit this as 0_docs/architecture.md
Task 2: Software class diagram
Provide a class diagram for the software that has been implemented for your system so far. It is not necessary
to show the Spring controllers and views, just classes and attributes for the data that is created and viewed
by your system.
See 0_docs/class-diagram.png for a decent example from last year in the CO2015-16-17-Template
repository.
Submit this as 0_docs/implementation-class-diagram.png .
Task 3: UI Mockups
Provide mockups/sketches of the user interface for the features that you plan to develop.
Your mockups should show the layout of the screens and the type of UI controls you expect to use. You
should include some brief notes indicating what each mockup shows and the flow between the screens. The
mockups do not need to show all details, just enough to help the developer understand the layout and
controls.
You should consider your desktop and mobile interfaces.
This course from Pluralsight may be helpful – https://app.pluralsight.com/library/courses/designing-
prototypes-websites-balsamiq-mockups-2115/table-of-contents
You may use whatever tools are available for this, including pencil and paper.
An example of a mockup showing two screens on both devices is in 0_docs/example-mockup.png in the
CO2015-16-17-Template repository
Task 4: Meeting Minutes.
Continue to write minutes as you were asked for in Worksheet 1.
Task 5: Sprint Retrospective
In the last week of the worksheet, perform a sprint retrospective. You should meet to agree and document 2
things that you should stop, continue and start doing to make your team perform better next time.
The ideas should be specific and clearly actionable – i.e. it should be obvious to a team member what doing
or not doing that thing means. e.g. “communicating better” is too general. “Provide a daily update email
describing what you did that day” is better.
Submit this as 0_docs/retrospective_worksheet_2.md
Software Implementation
The following tasks refer to the ongoing implementation of the system. The group should start
implementing the system iteratively, feature by feature. For each feature you should have:
1. Requirements/Specification using gherkin scenarios (task 6)
https://app.pluralsight.com/library/courses/designing-prototypes-websites-balsamiq-mockups-2115/table-of-contents
2. Working software (task 7)
3. Testing to demonstrate that the system works (task 8)
You are not been graded on the number of features that you complete, as long as you implement at least 3
features. You will be graded more for the quality of what is produced and the methodology you follow.
There should be progress on both the desktop and mobile version of the application. N.b. for worksheet 3
you will be partly graded for the amount of progress made – e.g. how many features have been delivered to
a high quality. It’s therefore worthwhile to start making significant progress from the start, even if you are not
measured on the number of features for this worksheet.
Task 6: Specifying the system using gherkin scenarios
As each user story is implemented, a separate Gherkin feature file should be created for each story (as they
were for CO2012). Scenarios should be added for each feature to describe the behaviour of the system. You
should add as many scenarios as are required to fully describe the behaviour. For example, for a login
screen you may have scenarios for; a successful login, a missing username, a missing password, and an
incorrect password.
For this task we are looking for how well the behaviour of the system is described using feature files, rather
than whether the tests are implemented and executable.
These should be submitted in a 0_docsfeatures folder.
Task 7: Working Software
You should develop working features. For this task you will be graded on:
1. The quality of the code that is produced
2. Whether the features are fully implemented to a high quality. Fully implemented means that they
exhibit all of the behaviour from the scenarios for this feature.
The working software will be graded based on a demonstration you provide during your supervision
meeting in week 33. Be prepared to give a demonstration lasting 15 mins.
Task 8: Testing
You must ensure that each feature works by testing them. This can be done by writing automated tests using
Gherkin or another automated testing framework, and by writing and performing manual tests. It would be
ideal to use the scenarios from feature files of task 6. However it is reasonable to write alternative tests, either
in addition to or instead of those scenarios, if implementing those tests is difficult.
It is not mandatory for the gherkin tests to be able to execute on Travis-CI. Depending on the type of tests
you create – fully testing the application on Travis-CI could be difficult, although within the capability of many
of our students.
You will be asked to run any automated tests during the supervision meeting in week 33 and explain any
other testing you did.
If you opt to manually test the application as well as automated testing – an example test script is in
0_docs/manual-test-script.md in the CO2015-16-17-Template repository.
If you write a test script and results store the results in 0_docs/manual-test-script.md . Any automated
tests should be in the folder from where gradle can execute them.
Write up a brief description of your approach to testing, whether you use automated or manual tests, and
when the testing is performed (Max 300 words). Store this in 0_docs/test-strategy.md
Additional Assessment
You will also be awarded marks for the following:
1. The quality, layout, formatting of your submission. Your repository should contain a README.md file
that provides links to each of the deliverables for each worksheet, as you complete them.
2. Project monitoring. Similar to CO2012 we will be checking that you are regularly updating your
product backlog with the latest progress. The burn-up chart should also be regularly updated.
