1. Paul Bourke (Paul.Bourke@dit.ie)
DT211/3 & DT228/3 Team Project
Paul Bourke
Module Web Page:

2. Aims of this module
This module offers the students the opportunity to use the knowledge and skills they have developed over the previous stages in the development of a complex software system.
This module aims to: group students into small teams and familiarise them with a range of skills and knowledge necessary, to take a software application through its life cycle.
21/04/2017

3. Learning outcomes Demonstrate group interaction
Demonstrate ability to deliver individual objectives within a team structure
Demonstrate leadership and team collaboration skills
Demonstrate an ability to follow development processes from initiation through design, implementation, test and delivery
Implement a project design in an appropriate format from a requirements specification
Demonstrate a choice of appropriate technology
Implement role functionality
Determine group integration.
Develop presentation skills
21/04/2017

4. Assessment (100% CA) Determined by:
Group submission of project documentation artefacts (such as design documents, test plan, testing logs and project plans)
Group presentation and defence of
the design (prior to implementation)
the final deliverable (including demonstration)
Individual submission of a project journal
Individual interview of each student within a group by the lecturer
21/04/2017

5. Grading
“A student’s final mark will be composed of 40% of their group mark and 60% of their individual mark.”
21/04/2017

6. Phase I: Groups of 4 students, each assigned a separate project
Scrabble
Sopwith Redux
Multi-User Calendar
Hotel Booking System
NCT Management System
Uber-Vision DVD Rental Management System
Surgery Appointment Management System
E-Learning Tool
Tag Cloud Generator
Physics as a Gameplay Element
Simple client system
Basic Word processor
Library Management System
Chess game
Auto Repair Shop
An E-Voting system
21/04/2017

7. Phase I: Win the business
Each student is assigned to a group
Group should meet together for discussions
Identify owner of key roles within the group (Team manager/Coder/Tester/Documenter etc)
Identify a group name (building on the group letter)
Identify preferred project & 2 alternates
Each group can pick any project
However only 1 group will be allocated a project…
Note: I will assign each group to a project next Monday
21/04/2017

8. For Friday - 3rd February (Worth 10%)
Submit a 1 page description of the approach your team would take if allocated your requested project.
Team makes presentation in the Lab (10 mins max)
All team members should be involved in the presentation
Suggested Content:
Introduce team name, members & roles
How roles where assigned
How decisions are to be taken/disputes resolved
Identify preferred project
Briefly describe your approach to project
Why is your team best suited
Identify 2 alternate projects
Give your lab supervisor a hardcopy of the 1 page submission and presentation
both documents to:
21/04/2017

9. Points to note: We are your customer LAB attendance is mandatory
Deliver what the customer wants – not necessarily what you want.
If the project doesn’t do what was agreed – the project will be “canned”.
You need to keep your customer happy
Agree what you will deliver, communicate it to your customer, manage expectations!
It is better to deliver a completed average project than not deliver a brilliant project.
This project has an absolute deadline which cannot slip
Unlike most commercial projects!
LAB attendance is mandatory
21/04/2017

10. Points to note II: This is a team based project
Roles must be allocated across the team
Be realistic about strengths – not everybody has to be a superstar coder or design guru.
Using the project plan document create a plan for the entire project.
Track changes as you go through the project.
Non-performers drag down the team.
There is an individual component to the grading
There are no extra marks for monopolising the project.
Keep a “Project Journal” every week
A list of tasks completed with brief description and comments on what has been learnt.
21/04/2017

11. Open Source, design patterns
It is normal practise in the software industry to use Open Source projects, design patterns etc.
However, ensure that
Verify it is available for use
Just because it is on the web doesn’t mean you can use it.
You fully document both the components of the project that you have used and the components that you have written yourselves including:
Design Patterns
Code
User interfaces
21/04/2017