Guidelines for the 1st iteration
I will be grading the first iteration based on the following criteria. You see that the first iteration is being graded only about the paperwork, but this should not discourage you from already digging into the technical details. Believe me, you have a lot to implement during the course, so I can only recommend starting early.
Mainly because - the most important is to build something that is useful for the customer/end users. If you are not going to deliver a useful and bug-free application - no amount of paperwork is going to save you.
Project vision and functional requirements. You have understood:
- Why the system will be built. What problem it will solve or what opportunity is it meant to exploit?
- Who is going to use the system?
- What type of system it will be (e.g. a Web API, a Web frontend, a mobile app, a desktop app?) and what will the system allow its users to achieve?
The above "project vision" can be written as a a preamble to the list of functional requirements or as a separate "Project Vision" entry in the Wiki.
Additionally, you have broken the functionality of the product into a set of functional requirements, (e.g. user stories). After reading the set of funtional requirements, I understand what will the system allow its users to do. The set of functional requirements is structured in a logical manner. For example, if you list 20 functional requirements, I expect that they will be arranged into 2-4 groups in a logical manner. Also, I expect that there is some logic behind the order in which the functional requirements are listed.
Non-functional requirements. You have listed the most important non-functional requirements. There is at least seven measurable non-functional requirements present. You have noted the requirements down in the Wiki. Reading the requirements, I understand how you are going to measure whether the system satisfies a given requirement.
Non-functional requirement include the initial architectural choices listing what technologies you are going to use in order to complete the project.
Project plan. First version of the project plan is present in the Wiki/Issue tracker. It contains at minimum:
- Roles in project. You have understood each team member roles and assigned responsibilities.
- Communication means. You have agreed both among yourselves and with the customer how and when and via which channels you are going to communicate.
- Work process. You have understood how you are going to work together and have explained this to me. I understand at minimum:
- How and using what materials the customer is going to understand what you are going to build
- How do you determine that the customer is accepting your solution proposal
- How you are internally going to build the accepted solution (who assigns the tasks, who is going to implement it, will the tests be written, will code be reviewed, who is going to verify, who is doing the validation, etc)
- When do you consider something ready to be published to the customer for review
- How do you gather feedback from the customer and/or end users.
- What is the definition of DONE on a task
- Scope. You have created the list of all tasks you currently foresee need to be delivered in order to complete the project. Tasks are planned into iterations or given priorities, assigned to person responsible and contain initial estimation about the amount of work involved. The descriptions of the tasks in the project plan is understandable.
- At least tasks deliverable during the second iterations must be detailed in project plan. Further iterations might not be clear enough to break them down to tasks according to your current knowledge about requirements.
- The tasks in the second iteration are defined at the proper level of granularity (90% of tasks take less than 16 hours, no task is larger than 40 hours).
Collaboration Infrastructure - VCS. VCS is in use. The repository is created with the basic project structure in it - meaning you have thought through how you structure your code, libraries, documentation, etc you are about to keep in the VCS.
There is trace of at least five commit/push operations from several project members in the repository. There is a trace of links between the tasks in issue tracker and code in VCS. The mentor must be able to access the VCS in read-only mode.
Collaboration Infrastructure - Wiki. Wiki (well, most likely a wiki, but alternatives are also possible) is in use. The requirements are entered in the Wiki. At least two of the functional requirements are detailed in the selected format (use case, specification,wireframes, ...). Links between detailed requirements and tasks in issue tracker are present. The minutes of at least the first meeting with the customer are in the Wiki. The mentor must be able to access the "wiki" in read-only mode. The wiki should be logically structured. It should be easy for the mentor to find the deliverables of iteration 1. There should be a description of the project in the front page.
Collaboration Infrastructure - Issue Tracker. Issue tracker is in use. Tasks have been opened/assigned/closed during the first iteration. Tasks for the 2nd iteration are entered and assigned to team members. Tasks in issue tracker are linked to the detailed requirements (on those requirements which are already detailed). The mentor must be able to access the issue tracker in read-only mode.
And after you have done all of the above, please make it easy for me to find everything from your Wiki.