TDDC32 Design and implementation of a software module in Java
The aim of the project work is to give you some proficiency in object oriented programming. Since programming should be more than hacking at some code, we will use a small software development process to structure the project work.
Usually a project implies planning and dealing with a lot of project related information, in the form of project planning documents, inspection forms, meeting protocols, etc. You will get the chance to work with such artifacts in later courses, but for now we will try to keep the organisational part smaller and concentrate on design/coding.
The project should be performed in groups of 2-3 persons (preferably 3 persons) which should correspond to the size of the project. That is, your design should result in several non-trivial modules (more or less independent) and that every member of the group will be responsible for coding such a module. Note that in larger projects every member has a clear role assigned. For our purposes you might want to have a project leader for organisational purposes, however all of you should be involved in the common tasks of the project. With respect to the project phases the work should be distributed as follows.
- Reasonable, but not complete requirements specification. Common for the entire project group.
- Object oriented analysis and design. Common for the entire project group.
- Sub task implementation. Individually.
- Unit test. Individually.
- Manual, shortened integration test. Common for the entire project group.
Project meetingsYou should have at least one project meeting per week (outside the exam period) until you finish your project. (Even if you belong to the same class/group/... and see each other daily, try to make at least somewhat formal meetings where you check and document what is going on.) Besides the analysis/design/coding/testing you have to perform and report on a small project organisation task each week. The one-page report should contain a time follow-up where every member of the group indicates the time he/she spent since last meeting, and on which activities. Additionally you should do a risk assessment (3-4 sentences) where you name any risks to complete the project that have increased or decreased. This page you should send to your assistant immediately after the meeting.
For meetings where you want your assistant to be present, be sure to book them in time.
Project steps and scheduling
- Form the project group. As stated above the group should consist of 2-3 persons (preferably 3 persons). Register for the project in webreg (later you will also be able to see your results here).
Deadline: Thursday 14th of February, 12.00.
- Choose/propose a project you would like (have fun) to do. Write a
general description (max 1 A4 page) about the project idea. Make sure
to specify what are the submodules and who is going to implement
Examples of project ideas here.
Some old projects here
- Update: Hand in your project idea (by email) to
your assistant by Monday 18th of February, 12.00. If you (your project group) want a startup meeting with the
assistant, contact him/her for a booking.
- Create the requirements specification and discuss it with your
assistant. The assistant will also try to assess if the assignment
has a reasonable size compared to your group (e.g. it's not too big
to be finished during the allocated time). Don't forget that you are
responsible to book the meetings with your assistant.
What should the requirements specification contain?
Update: Deadline: Monday 25th of February, 12.00 (by email).
Your email should have the subject line “TDDC32: Requirements specification, group ‹group number›”.
Your document should be in pdf format.
The file should have the name “tddc32_reqspeq_‹group number›.pdf” (e.g. tddc32_reqspec_A02.pdf).
- Analyse the requirements specification and design your
architecture. Discuss the resulting document with your assistant.
What should the analysis and design document contain?
Update: Deadline: Wednesday 6th of March, 12.00 (by email).
Your email should have the subject line “TDDC32: Analysis and design document, group ‹group number›”.
Your document should be in pdf format.
The file should have the name “tddc32_andes_‹group number›.pdf” (e.g. tddc32_andes_B12.pdf).
- Implement the design. Test your code. Your requirements specification and design
documents might change during this phase. At the end deliver the
entire project documentation to your assistant. It should
- The requirements specification.
- The analysis and design document, updated to reflect what you really implemented.
- The documentation of your code as generated by the javadoc tool.
- The test reports. Note that every test report should have a clear expected value and test result. You should test your code for both correct, erroneous and for limit values of the input.
- A short user guide if you think one is needed.
- Demonstrate a functioning program at a final demo
Update: Deadline for implementation and demonstration is on Tuesday 7th of May (week 19). This is also the deadline for handing in the entire project documentation.
Format and Language of DocumentsThe diagrams in your documents should follow the UML specification. (See lab 3 for suggestions on UML tools.) For your documents, you might use whatever editor you like, but the documents should be handed in as pdf. A pdf can be obtained from any document. Contact your assistant if you don't know how. You can use either Swedish or English in all aspects of the project.
Project work is graded with U, 3, 4 or 5. In order to pass the course you have to pass all the examination items. The weight of the project grade in the final grade of the course is 2/3. If you don't pass the project examination you may add some completion work to the project to receive a grade of 3.
The project grade will be a combination of the documentation, the code you wrote, and also project organisation. Note that the documentation is supposed to take around 25% - 30% of your project time. Nevertheless, without a proper design you will not be able to efficiently write any good code.
The documents will be graded both on their content and the presentation with an emphasis on the former. The code will be examined both on style, correctness and reliability. Style includes how you have structured your code, how the interfaces between the modules are realised, how well you used the Java language and the API, how you commented your code, and how readable your code is (Java coding convention). Correctness is decided by how your program is following the requirements specification and design. Reliability is given by how your program is dealing with incorrect data (this includes your exception handling system).
Project organisation will only influence negatively if you don't send
the time+risk follow-ups in time, that is once per week.
Page responsible: Tommy Färnqvist
Last updated: 2013-04-29