Teams
Team allocation is here.
Projects
Description of projects for this year is available here.
Project allocation is here.
Schedule and slides
The schedule and marking scheme are here.
This document has been updated on the 4th of March, earlier version is here.
Second update on the 20th of April, earlier version is here.
Genesys training sessions are in the four three weeks of term on Wednesdays in EAB-IT 2pm-5pm. Additional sessions are in week 4 EAB-IT, 12noon and week 8 EAB-IT, 12noon.
All the tools and materials they provide can be found here.
In week 6 you are expected to sign a requirements document. Your team effectively promises to build a system to those requirements and the client promises that a system built to those requirements is what they want. Both your team and the client are expected to sign this document.
Use of open source software
You may include open-source software in your solution, subject to the following constraints.
-
The part of your project that is an open-source component or is derived from one has to be clearly designated as such.
In particular, a maintenance manual has to have a mentioning of it, where it was obtained and its version number.
This is important for subjequent maintenance of your software.
-
The license for the software that you are using has to allow it to be used in the intended way. For instance, there could be limitations
on the way it is distributed (as an example, Microsoft prohibits SDK redistribution) or it may influence the license for your entire project. This is particularly the case for GPL licenses which
require any project linked to a GPL component be licensed in a way compatible with GPL (this means your project has to be available with
source code and anyone obtaining it has a right to modify and distribute the modified version, also accompanied by the source code).
Your client has to agree to the implications for your use of a component with a specific license.
- You do not always know how well-built a particular component is. This means you would want to dedicate some testing to
integration testing of it with your application and perhaps even do some unit testing of it. Finally, keep in mind that not everyone
building software knows anything about security, you may introduce an easy way for someone to hack into your application if you
use an arbitrary component. Web servers are routinely scanned by bad guys for specific vulnerable modules, I had a lot of this in the logs
for my web server.
-
If a component is shiny, it does not mean your client would want it. If it does not do quite what you want, you have to ask yourself
whether your solution will benefit from it, given the potential problems with license and with testing.
-
A component that you are using becomes part of your offering. Hence this component has to implement some of the stories you have
developed and you become responsible for testing it (at least to the extent you are relying on it).
Other materials
Please make sure you have looked at every single item in this list. Some of these may be very significant.
- The guide to XP is available here.
- XXM plugin is a tool that can be used to create diagrams describing the intended behaviour of the software you develop.
It is an Eclipse plugin can be downloaded here.
It works with a newer version of Eclipse than 3.4.
I plan to mention it in week 2, but the slides are avilable here.
User manual is here.
-
The sheet for team managers to fill in is here.
-
Sample requirement document from a couple of years ago is here.
-
User guides, maintenance/installation guides and test documentation from a couple of years ago are available here.
-
QA form can be downloaded here.
- Non-disclosure agreement can be found at NDA.
- Personal evaluation document is a short document from each individual covering the following:
- What went well,
- What could have been done better,
- What each team member's contribution was.
Here you need to write which tasks/modules have been completed by each team member and what you think
the relative contributions of each person was. It is not enough to mention what you did personally, you also have
to explain what each other member did.
Personal evaluation should be submitted via Mole (in plain text or .pdf formats only, no Word) until midnight at the end of Friday May 22nd.
-
During a meeting with your client, you are expected to ask questions that are best prepared in advance. You would also want to write the responses down, unless you can remember absolutely everything or you recorded the conversation (with clients' permission).
- You would typically want to describe features of your system in a form of story cards, these are useful for planning what you aim to do in each week. Stories should go to Kanban, notes to your team shared folder.
Requirements document (due in week 6) could be based on stories.
Tests for each story are a good way to check whether you have implemented that story.
- Each week you are expected to hold at least one team meeting, with both agenda and minutes available for your manager to see before Friday.
- Time spent on each task should be logged by each team member using Kanban and you should not just write "programming", it should be more like "developing a feature ... ". For pairs, each individual should log time separately, but there is no need to log time spent meeting a client or manager. This should also be done before every Friday so that your manager will see what you were doing.
- There is quite a detailed tutorial available on the use of Git here, courtesy of Robert Chisholm who found it.
- Software and tools are here.