Choosing a project
A good project choice is critical to the success of this coursework. Although the choice of project is up to you there are some guidelines which must be followed. These are to help you choose a project which is manageable but will also meet the requirements for the top grades –
- There must be an end user who will be willing to take an active role on the project
- The project must not be too simple! It MUST have a substantial coding element to it
- The project should not be too ambitious!
- You must fully understand what the user wants and understand the area of business they represent.
The end user
The end user must take an active role in the project. You will need to interview them, get them to test your program and they must be willing to do a bit of writing! It is very likely you will be in active contact with the user over the period of a year. You must be able to get in contact with them quickly either face to face, email or over the phone.
It works better if the end user is known to you or your family. Parents, older siblings, uncles / aunts or friends of the family are normally more willing to give you the time needed to implement a system. It also helps if they have their own business or are self-employed as they will normally not have any custom built software due to the cost. Users who work for small companies may also fall into this category.
Your user must also require a system! It is possible to re-design part of an existing system for them but this is more difficult. The normal categories for a system are –
- Converting a paper based system into a computerised system
- Automating parts of a current system
- Implementing a new system for a need which is currently not met
- Upgrading an old legacy system.
When talking to potential users you may wish to ask the following questions –
- Is there any part of your system / work which is paper based?
- Is any part of your job repetitive?
- Do you use an old or very slow system?
Note - DO NOT select a user who works for a large company! They will normally have a working system or the new system will be highly complex.
Note 2 – NEVER try and integrate more than one piece of software together, especially if it is legacy software or not office based. These projects tend to go tits up!
What makes a good project
This list IS NOT exhaustive! It is merely to give you an idea of what you could do.
- An interactive website / content managed website
- Booking systems (either online or app based)
- Anything which requires data to be stored in categories (like school resources)
- Automated email system / systems which generate emails
- Customer / order management systems
What makes a bad project
These projects tend to go south very quickly!
- Online stores (due to complexity)
- Games (hard to justify a end user and hard to get documentation marks on)
- Games! (they are also hard to program!!)
- Anything flash based or Microsoft Office based (again hard to get marks on)
- Anything which has a large GUI! (Becomes hard to manage and is time consuming without getting you any extra marks)
- Address books or anything which stores data in just one or two tables.
- Anything involving concurrency or threads!!
- Expert systems.
Scope of the project
Projects vary in size from trivial to highly complex. The key to a good project is to pick one which is in the middle. It is also important to bare in mind your skill level. If you are a seasoned veteran when it comes to programming you can be more ambitious. In order to decide if you can do a project you need to do have an idea on how you could make it. This is where your teacher can guide you!!
One thing to remember is that large ambitious projects can be cut down to make them more manageable. It is much harder to add extras to a small simple project.
Understand what the user wants
You will, later on, perform fact finding to find out exactly what the new system will do. However that takes time and if you find out at the end of that process that the project will not work then you will have wasted a lot of time! We need to look at the feasibility of the project.
You must have a good idea of what the user wants before you start analysing the system. You should be able to answer the following questions
- What sector does your user work in?
- What problems do they currently face?
- Which of the problems are you going to solve?
- How does their business work?
- Who is the project aimed at?
This means you will have to discuss, at length, how your user works and what they do. Never simply get a rough idea and then hope it will all fit into place. The more time spent on this will mean less time is needed later on.