This milestone concludes the initial iteration in which the team focuses on planning and designing the project, as well as on setting up their development environment.
To facilitate communication among your mentor, manager, and team, your team must create a list of requirements that describes the system’s functionality. Follow these criteria:
Requirements format: Your requirements may be documented in the form of user stories, a structured list of natural language specifications, or use cases.
Granularity: Requirements should be documented at a level of granularity appropriate for dividing up and managing the work (e.g., they should be reasonably estimable).
Mentor-driven: You must elicit the requirements from your mentor. This will likely require back-and-forth communications with your mentor.
Mentor readable: All requirements should be understandable to your mentors (no technical jargon or implementation details).
Complete set: For your initial plan, you must make the set of requirements as complete as possible (understanding that they will probably change as the project moves along).
Status tracking: Your team must maintain this set of requirements throughout the project, keeping them up to date. The status of each requirement must be recorded (e.g., “not started”, “in progress”, “completed”).
Your mentor must approve the set of requirements in your team’s plan (prior to the milestone deadline).
Prioritize the requirements and note the dependencies between them. Then, list the features expected to be completed during each development iteration (and, if relevant, how polished the features will be).
Your team must create rough sketches of what the various system interfaces will look like.
Sketch quality: Lo-fi renderings are preferred at this stage. For example, hand-drawn pictures with notes are fine. Sketches done in, say, PowerPoint would also be acceptable.
Well detailed: Your sketches should be as complete as possible (include all key features, interaction dynamics, effects of button clicks).
Basic and advanced versions: Designs may include different levels of refinement (e.g., “basic” and “advanced” versions), enabling you to incrementally build up the system.
Your mentor must review and approve your interface designs (prior to the milestone deadline).
Your team must describe what software components you will implement and how those components will interact.
You have some flexibility in how you communicate this. For example, data flow and/or deployment diagrams are probably appropriate.
Model user: Make it clear where the users fit in.
Technologies: Specify all hardware/software technologies to be used in implementing your system.
Languages and platforms: Specify all programming languages and/or platforms (e.g., LAMP, Jakarta EE) that you will use, and how they fit into your design.
High-level: Keep your descriptions somewhat high level; for example, I’m not looking for detailed class diagrams.
If your system will use a database, create a database design (i.e., a detailed data model of the database).
Design notation: You may represent the model as an object-oriented class diagram, an entity–relationship diagram or other common database modeling notation.
Well refined: Make your tables/design as complete as possible. For example, if you will use a relational database, such as MySQL, design all the tables, keys, etc.
Your team must define what policies and procedures will be followed and what technologies will be used to ensure that the software built is of good quality—especially from the perspective of the mentor.
Software testing: A plan for testing must be included (both unit and system testing).
Manual vs automated: Be clear about which verification/validation provisions are automated versus manual.
Tools: Describe any specific tools to be used for verification/validation.
Mentor involvement: If part of the plan involves the mentor, make sure that the mentor is OK with it (prior to plan-review meeting).
Your team must define what policies and procedures will be followed in managing and handling feedback received. Also, the team must set up a system for managing feedback and provide the mentor and instructors access.
See the Feedback Collection and Management document for detailed instructions.
Your team must define a plan for communication both among the team members and with the mentor. The plan should address questions, such as
As your team plans the project, you will find that there are key unknowns, things may not work as planned, or things that could just plain go wrong. These are risks to the success of the project, and your team must identify them early. Common categories of risks are as follows:
Technical risks: Some features of project may be technically risky—that is, it is not clear whether their design can be implemented successfully. For example, the team may expect to use a 3rd-party API to implement their software; however, it is not known for certain that the API provides all the functionality needed and expected.
Volatility risks: Some requirements and design decisions may be more stable than others—that is, the mentor may be likely to change their mind about certain things. For example, novel user-interface designs run a higher risk of needing to be changed, because usability problems with such interfaces are often revealed once users begin using the interfaces.
Collaboration risks: Each and every team member is expected to make a substantial contribution to the project each iteration. For example, a risk in this case may be that only one of the team members know how to use a particular technology and the rest need to learn it.
Additionally, you should consider the following for each risk:
Difficulty: Classify the difficulty of each risk: for example, “no idea how to do” versus “probably doable.”
Importance: Classify the importance of each risk: for example, “showstopper” versus “nice to have, but not vital.” Focus on the most important risks.
Plan for addressing: For each risk, tell how the team plans to address it.
Eliminate ASAP: If a risk can be eliminated by talking to the mentor, do so ASAP (prior to milestone deadline).
Track status: Plan to keep track of the status of each risk as the project progresses (e.g., “eliminated”, “open”).
To ensure that your team is ready to “hit the ground running” in Development Iteration 1, it is critical that you have a working code skeleton ready prior to the start of Iteration 1. This skeleton will give your team’s members a place to begin adding their functionality. What sort of skeleton is appropriate varies by project, but there should clearly be enough there for teammates to easily begin integrating functionality.
Executable skeleton: Although the code skeleton may have few or no features, it should at least execute cleanly as, for example, a “hello world” sample application.
Setup frameworks: If your application is built upon a significant framework (e.g., Android), the framework must be set up and working (at least sufficiently to support the limited functionality of your code skeleton). For example, in the case of Android, I would expect that a “hello world” app can be run in both a development emulator as well as on an actual Android device. Similarly, in the case of a web app, the skeleton should be set up such that a hello world page can be served up and displayed in a web browser.
Pushed to repos: Your code skeleton must have been pushed to your central version-control repository so that team members can immediately begin contributing and sharing code.
Full task planning and outcome reporting must be part of each iteration and milestone. See the Individual Assignment Specification document for detailed instructions.
Since the way to access the various milestone artifacts may vary from team to team, each team must submit a document containing instructions to the instructors regarding how to access each artifact. This document must be submitted to an eCourseware dropbox by the milestone deadline.
Teams must use the following template. Create a Markdown file (i.e., a text file with the file extension “.md”), and paste in the template below. Each team should submit only one Instructions-to-the-Instructors file that is shared by all team members. For the file locations, give the file name(s) and location(s) of each item in your team’s repository (e.g., “/misc/user_stories.docx”). Feel free to leave additional explanations/instructions as sub-bullets.
# Milestone 0 - Instructions to the Instructors
- Team: xxx (Team Name)
- GitHub Repo URL: xxx (URL)
## File Locations in Repository
- Requirements specifications: xxx
- Prioritization and Schedule of Requirements Implementation: xxx
- User interface designs: xxx
- Architectural design: xxx
- Database design (if system will have a DB): xxx
- Quality assurance plan: xxx
- Feedback management plan and setup: xxx
- Collaboration plan: xxx
- Risks: xxx
- Code skeleton: xxx
- Milestone 0 individual assignment outcomes: xxx
At the end of each iteration, each team member must provide an evaluation of each other team member. Instructions and forms for performing these teammate evaluations will be communicated by email near the end of the iteration.
[ ] Requirements specifications (Section 1.1)
[ ] Mentor must have reviewed and signed off on
[ ] Prioritization and Schedule of Requirements Implementation (Section 1.2)
[ ] User interface designs (Section 1.3)
[ ] Mentor must have reviewed and signed off on
[ ] Software design (Section 1.4)
[ ] Architectural diagram(s)
[ ] Database design (if system will have a DB)
[ ] Quality assurance plan (Section 1.5)
[ ] Feedback management plan and setup (Section 1.6)
[ ] Collaboration plan (Section 1.7)
[ ] Risks (Section 1.8)
[ ] Code skeleton (Section 1.9)
[ ] Individual assignment outcomes (Section 2)
[ ] Instructions to the instructors, submitted to eCourseware dropbox (Section 3)
[ ] Teammate evaluations (Section 4)
Mentors: Please indicate your approval of the following items—but ONLY if you agree 100% with the statement for the item.
If you have ANY disagreement, do not give your approval. Instead, provide the team with feedback, and have them resolve whatever issue is preventing your approval.
I have reviewed the requirements specifications, and they meet the following criteria:
[ ] I can understand all of them
[ ] There are no significant requirements missing
[ ] There are no unwanted requirements added by mistake
I have reviewed the interface designs, and they meet the following criteria:
[ ] I can understand all of them
[ ] There are no significant features missing
[ ] There are no unwanted features added
[ ] I am happy with the design of all the interfaces
[ ] I have been given access to the version control system that the team will use to manage the source code.
[ ] I have been given access to the system that the team will manage the feedback that I and others give them.
[ ] I have reviewed any other parts of the Milestone 0 plans and designs that interest me, and am happy with them.