Project 1 - Fall 2012

Due Date1	Assignment2	Value3
Sun 9/9	Concept & Plan	10
Sun 9/165	Competitive Research	5
Sun 9/235	Preliminary Requirements	5
no later than Fri 9/28	Concept Presentation	10
no later than Fri 9/28	Requirements Elicitation	15
no later than Fri 9/285	Requirements Analysis	10
Sun 9/30	Final Proposal	10
Sun 9/30	Post-Mortem Report	10
n/a	management	5
n/a	individual contribution4	20

¹ Submissions are due by mid-night of the due-date, and must be e-mailed to cs181f@cs.pomona.edu .
² Unless otherwise specified, all written materials should be submitted as URLs to ASCII text files on GitHub.
Work-products will be considered to have been submitted at the time of last commit and push.
To make it clear what versions you want graded, you can tag the commits to be graded for each submission with the name of the submission (e.g. "Project1A").

³ less 10% for each unexcused late day.
⁴ part of each individual's grade is based on the quality and timeliness of their contributions.
⁵ If you submit these early enough, we will try to turn them around quickly enough to enable you to improve your final proposal based on the feedback from these earlier assignments.

Table of Contents

1. Introduction
2. Major Activities and Deliverables
3. Rules

• A concept is something that can be discussed.
• A proposal is something that can be acted on.

• developing an understanding of the problem to be solved
• developing a description of the work to be done
• verifying the feasibility and likely value of the proposed work
• developing a plan for the investigation to be performed

The primary goal of this project is to give you real experience with the development of a concept, the gathering, organizing and prioritizing of requirements, and the development of a proposal for a software product. A secondary goal is to develop your abilities to intelligently plan a group endeavor, effectively manage it, and critically evaluate the completed effort.

2. Major Activities and Deliverables

There are several major parts to this project, each of which has its own goals, processes, and deliverables:

1. Initial concept and plan
   You will develop a preliminary concept, and a plan for turning it into a proposal.
2. Competitive Analysis
   You will research existing products in this area, position your proposal against this field, and develop a competitive value proposition.
3. Preliminary requirements development
   You will identify potential users for your product, and explore their needs and the characteristics a product would require in orer to satisfy those needs.
4. Concept Presentation
   You will develop a brief presentation to introduce people to the type of product you are exploring.
5. Requirements Elicitation
   You will present your concept to potential users, gather input from them on their needs, and their reactions to your proposal.
6. Requirements Analysis
   You will synthesize the feedback from the requirements elicitation in to a clear set of prioritized and validated prodoct requirements.
7. Final proposal
   You will combine all of the above into a final proposal (what will be built, why it will be successful) to be submitted to get funding for further investigation.
8. Post Mortem
   You will review the processes you followed in this project, to see what lessons you can learn for how to do things more effectively in the future.
9. Project Management
   All of the above will be planned, documented, and managed.

• a concept for something to do
• a plan for exploring the concept

2.1.1 Deliverables

A concept document is a very brief description of what you propose to do and a justification for why it is worth doing.

The living document that lays out the plan (du-jour), its progress, and its evolution over the course of the project is the Management Plan.

2.1.1.1 Concept

Write up a brief (e.g. 1/2 page) description of your idea, including justifications for why you believe it to be:

• valuable as a product
• something that could actually be built and used
• something that you will be capable of designing
• fun for you to work on

2.1.1.2 Management Plan

Most of the individual sub-tasks associated with this project can be done in a couple of hours by one or two people. But there are a great many of these tasks to be performed, and (you will discover) not a great deal of time in which to get them done. The only way you will succeed is if you have a plan (who is going to do what, when, and then who will do what with it) for the entire project.

Each team will prepare a task-breakdown, identify the dependency relationships between tasks, and owners for each sub-task, assign due-dates, and schedule regular reviews of both work-products and progress (to enable adequate time to deal with the problems that will happen).

A good plan will ensure that all work is done before the due date, but allow people a reasonable amount of slack in when they have to do each particular task. A plan to defer everything to the last minute is likely to fail when last-minute problems are discovered. An aggressive plan that people won't be able to achieve guarantees a fire-drill in a few weeks when it finally becomes clear that it cannot be followed.

Experience has shown that vague plans are easier to create up-front, but create problems down-stream (when people turn out to have been unclear about exactly what they were supposed to do, by when, and in what form they were to deliver their output). Similarly if you do not specifically map out the dependency relationships among the tasks, you may find that your schedule is unrealistic, because it does not allow sufficient time for sequential tasks.

The key to ensuring problems are detected before it is too late is regular communication, and continuous comparison of actual progress vs the plan. A good management plan will include regular status checks, the results of which should be recorded in the plan document. As your understanding of the problem evolves and you respond to unanticipated events, you will have to revise your plan. If deadlines are missed, or deliverables fail to pass review, the fact, as well as the causes and the plan to remedy them must be documented.

You can prepare and submit this plan in any form you like, but the sort of information I had in mind was:

Task/Deliverable	Due Date	Owner	1st Draft	Review Due	Final Version	Dependencies	Risks	Comments
concept	9/9	Algernon	9/6	9/6	9/6	none	it will be too hard to spec/design	discuss implementability in our review
management plan	9/9	Zebulon	9/7	9/7	9/8	careful reading of assignment	leave something out	multiple people read assignment, review against deliverables and grading standards
competitive research	9/16	Xenophon	9/9	9/12	9/15	concept	miss important competitors/features	start early, more time, careful review
...

• We will have a face-to-face meeting every Tuesday after class to review our plan for the week.
• We will have a 5 minute IRC chat each day at 8PM for a quick status check.
• Other working meetings will be scheduled as needed.
• If something goes wrong, send-email to the rest of the team that day.

2.1.2.1 Product Concept

• 40% clarity - I understand what you propose to do.
• 20% value proposition - I understand why I (or someone else) would find it valuable.
• 20% practicality as a product - I believe it could be successfully built.
• 20% practicality for this project - I believe you can specify and design it.

2.1.2.2 Management Plan

• 40% good use of time and resources (work apportioned reasonably over the available time)
• 20% specificity of plan (clear responsibilities: who, what, when)
• 20% provisions for early detection of problems, and time to deal with them
• 20% completeness

    Team: name-of-your-team

    Members: person1, person2, person3, person4

    Project: 1A - Concept and Plan
       Concept: https://github.com/your_repo/...
       primary author: person1
       Plan:    https://github.com/your_repo/...
       primary author: person2

       if you have other files to submit, please include a brief
       description of each.

    Late points:
        if this submission is late, who is using up how many late points

2.2.1 Deliverables

Write up a brief description of the existing products, along with notes on their key strengths and weaknesses. Note the (positive or negative) lessons you can learn from each of these products. Write up a list of feasible and valuable improvements that you could reasonably make in a new product, and briefly justify their value and practicality.

Note that this is a list of ideas, and will be graded on organization, quality of analysis, and clarity of insight. It will not be graded as prose.

2.2.2 Grading

1. 40% how well you identified competing, similar or related products.
2. 40% the clarity and credibility which you understood and characterized their capabilities.
3. 20% the practicality and value of your proposed improvements

2.2.3 Submission

    Team: name-of-your-team

    Members: person1, person2, person3, person4

    Project: 1B - Research Report
       Report: https://github.com/your_repo/...
       primary author: person1

       if you have other files to submit, please include a brief
       description of each.

    Late points:
        if this submission is late, who is using up how many late points

The specific form in which you choose to represent these requirements is up to you. Basic capabilities may be best captured by simple declarative sentences. Complex or role based interactions may be best captured by use cases. Use the forms that you think best capture the requirements in question.

As you gather new requirements from customers, clarify them, validate them, reconcile conflicts, and prioritize them, I recommend that you make these changes in successive versions of a single requirements document. This will clearly show us the work you did in evolving and refining your requirements, and ensure that you receive full points for these activities.

Again, there is no need for this document to be any more than organized notes.

2.3.1 Deliverables

Document

• the various types of people who might want to use your product.
• the goals that each user would have.
• the needs, abilities, and expectations different types of users would bring.
• the types of users to which you feel best able to respond
• the requirements your product would need to meet to satisfy those customers

1. 20% how well you understood who your users might be
2. 40% how well you anticipated their likely needs
3. 40% how well you were able to capture these needs in requirements

    Team: name-of-your-team

    Members: person1, person2, person3, person4

    Project: 1C - Preliminary Requirements
       Report: https://github.com/your_repo/...
       primary author: person1

       if you have other files to submit, please include a brief
       description of each.

    Late points:
        if this submission is late, who is using up how many late points

2.4.1 Deliverables

A brief (3-6 minutes) prepared presentation (including slides and/or other visual aids) introducing the product concept as background for the requirements elicitation.

2.4.2 Grading

• 20% logical/information presentation structure.
• 40% its effectiveness in establishing context (the interviewees understand the form, purpose, and use of the intended product).
• 10% the extent to which it does not otherwise contaminate or prejudice the clients.
• 10% how effectively it stimulates interest in the product, making them eager to provide input.
• 10% how good an impression it makes (polished and professional).
• 10% its length: 3-6 minutes

This presentation will be given at the start of your requirements elicitation session, but any prepared materials (e.g. slides) must be prepared and made available for review prior to the actual elicitation.

You may prepare and deliver this presentation in any form you choose, but the written submission should be in some relatively universal format (e.g. pdf, power-point, HTML, Googledoc) and submitted via URL (so that it is easily viewable by others). When you are ready to submit your presentation for grading, make sure it is publically readable, fill out the following form, and e-mail it to the submission alias.

    Team: name-of-your-team

    Members: person1, person2, person3, person4

    Project: 1D - Concept Presentation
       Presentation: http://URL for your presentation

       if the format is non-obvious, please provide instructions
       for viewing your presentation.

       if you have other files to submit, please include a brief
       description of each.

    Late points:
        if this submission is late, who is using up how many late points.
	Note that even with late points, this must be submitted BEFORE 
        the elicitation session.

2.5.1 Deliverables

1. Briefly (in less than 60 seconds) introduce yourselves and the agenda
2. Give your concept presentation
3. Start with open-ended information gathering about the educational goals in question, how they pursue them, what problems they encounter, the gaming activities of students, their computer use, etc.
4. Then move into more specific questions, following up on interesting points raised in the open-ended questions, and posing the more directly product-focused questions that you have come up with.
5. Get their comments on information you have gained from other sources. Note: It is possible that, in the process of giving you their own requirements, the customers will actually touch on all of your own previously gathered requirents. If this is the case, when you get to that part of the agenda, specifically affirm that they have reiterated (or how they have changed) that prior input.
6. Present a summary of the key messages you have gotten from them today, and give them the opportunity to correct/amend those.
7. Thank them for their participation.

• Moderator: Leads the meeting, discussions, etc.
• Scribe: Takes notes
• Others:
  All team members will play important parts in making this a success. The moderator and scribe will typically be too busy to actually think about and process what is being said in real time. Other team members should
  • Distill long discussions into punch-lines for the summary.
  • Keep track of points that need further clarification before we are done.
  • Check off comments that relate to previously suggested requirements, and maintain a list of requirements that still require validation.
  • Watch the agenda and the clock, and help the moderator keep to the agenda and make sure that nothing is missed (because it is very difficult to think while talking).

• 35% the extent to which you are able to adhere to the process (which will be described, in the reading, given to you in writing, and demonstrated in class).
• 50% the extent to which you are able to obtain useful information from the clients about their needs and perceptions in this area.
• 15% the extent to which you are able to validate and clarify prior assumptions and questions about requirements.

1. revise them based on customer feedback (and your evolving understanding of the problem)
2. add the new requirements gathered from customers.
3. look for ambiguous requirements, and clarify them.
4. assign a value to each requirement, and justify that assignment.
5. assign a confidence to each requirement (that you have properly understood it and/or its value).
6. look for conflicting requirements, and resolve the conflicts.
7. assign a difficulty (easy, moderate, hard) to each, and justify your assignment.
8. assign a priority to each requirement, and then ladder them priority.
9. suggest a cut-off line for release 1.0, and justify why that is the right place to draw the line.

When you sit down to come up with a final set of requirements, it is likely that you will discover that some of the input you got in your elicitation was not as clear as it seemed at the time. When this happens, you have two options:

• Go back to the person from whom you got the requirement and seek clarification.
• If it is non-critical, document the uncertainty and take your best guess.

2.6.1 Deliverables

You will submit two reports:

1. organized notes from the requirements elicitation session.
2. a requirements analysis based on the information gained from that session.

2.6.1.1 Report from Elicitation Session

From the detailed minutes (which should be under version control) the you will discuss the results and prepare a summary report that synthesizes the information gathered. The report should include:

1. When and where the session took place and who attended.
2. Interesting information gained during the open-ended information gathering.
3. Clear statements of significant new requirements that were suggested, along with an assessment of how important each is and why.
4. Significant input on previously gathered requirements, affirming, refuting, or changing them.
5. Any other useful results gained from the meeting.

2.6.1.2 Requirements Analysis

Based on the results of your requirements analysis, prepare a priority ordered list of product requirements. For each, list:

• the stated requirement
• its priority, and your justification for that determination
• its difficulty, and your basis for that assessment
• your confidence in that requirement, and where it came from

2.6.2 Grading

• 10% form (capturing who, when where, topic)
• 10% completeness (all key points captured)
• 10% understanding what the customer said (correctly, and deeply)
• 10% the analysis of this information and distillation of requirements
• 10% the clarity, organization and readability of the report

• 10% completeness of the lists
• 10% clarity of the requirement statements
• 10% reasonablness/appropriateness of the requirements
• 10% prioritizaty and traceability
• 10% clarity, organizatin and readability of the report

    Team: name-of-your-team

    Members: person1, person2, person3, person4

    Project: 1F - Requirements Elicitation Report
       Minutes:    https://github.com/your_repo/...
       primary author: scribe
       Analysis:   https://github.com/your_repo/...
       primary author: person1

       if you have other files to submit, please include a brief
       description of each.

    Late points:
        if this submission is late, who is using up how many late points

• It should include an overview of the concept.
• It should describe the key users and the needs to which your proposal responds.
• It should include competitive positioning information.
• It should include validation (from your customer interviews) of that your proposal responds to a real need and would be a compelling product.
• It should include a list of key requirements the product must satisfy.
• It should include some basis for believing this project to be feasible.

The director to whom you are submitting this proposal can be viewed as another type of user, with her own sets of needs. Your product need not respond to your director's needs ... but your proposal (if it is to be successful) must do so! This means you need some idea of who your director is and what problems she is trying to solve.

2.7.1 Deliverables

A written project proposal for the funding of a new product investigation.

This proposal will be graded much more on content than on format, so ASCII text on github is completely acceptable. If you want to submit it in a richer format (e.g. so you can include images), PDF, PowerPoint, Googledocs, or HTML are also acceptable.

Note that executives (even R&D directors) are notorious for very short attention spans ... so short and crisp is much better than long and elaborate.

2.7.2 Grading

This proposal will be graded on the basis of:

• 20% clarity and cogency of the concept
• 20% clarity and the target user descriptions
• 20% clarity and persuasiveness of the value proposition
• 10% clarity, depth, authoritativeness, cogency of the competitive analysis
• 10% clarity, prioritization, provenance of the key requirements
• 10% likelihood that I would fund this investigation
• 10% likelihood that I would hire the team that prepared this report

    Team: name-of-your-team

    Members: person1, person2, person3, person4

    Project: 1G - Final Proposal
       Product Proposal:    https://github.com/your_repo/...
       primary author: person1

       if you have other files to submit, please include a brief
       description of each.

    Late points:
        if this submission is late, who is using up how many late points

2.8.1 Deliverables

A report, summarizing the key issues raised in your post-mortem, and the conclusions you came to. Your post-mortem discussion should include:

• the concept definition, research, and brainstorming activities
• the customer requirements elicitation planning, execution, and results analysis
• the organization and creation of the final proposal
• the planning and ongoing management of these activities
• the overall project as an educational exercise.

Note that if you make no mistakes, you will not be able to earn any points on the post-mortem. Fortunately, no teams have ever found it necessary to deliberately make mistakes in order to have something to analyze.

2.8.2 Grading

• 50% whether or not you meaningfully discuss each of the required activities.
• 20% whether or not you identify all of the important incidents.
• 30% the extent to which you are able to derive and articulate useful lessons (and good future advice) from those experiences.

    Team: name-of-your-team

    Members: person1, person2, person3, person4

    Project: 1H - Post-Mortem
       Plan:    https://github.com/your_repo/...
       primary maintainer: person1
       Report:  https://github.com/your_repo/...
       primary editor: person2

       if you have other files to submit, please include a brief
       description of each.

    Late points:
        if this submission is late, who is using up how many late points

2.9 Management

The team will be graded on how effectively they managed themselves and the work:

1. Perform the work according to the plan.
   We will determine when work was done by looking at the dates of the final check-ins.
2. Monitor progress and detect problems.
   Monitoring plans should be included in your project plan. Status should be reviewed regularly, and logged as updates to the project plan. Problems that come up should be recorded as updates to the project plan and discussed in your post-mortem.
3. Reasonably adjust the plan in response to problems.
   Detected problems and responses should be discussed in your post-mortem, and reflected in revisions to the plan.

Any assignment that is not turned in by its due date, will have its grade reduced by 10% (of its nominal value) for each late day. I understand that problems happen, and so each student is granted three slip days. A team of four students would have twelve slip days between them.

One slip-day will excuse one deliverable being late by one day. If a design is one day late, and that delays the design review by a day, then you may find that you need two slip-days. Don't make the mistake of using up your slip-days too soon, because the pressures generally get tighter later in the course.

When a team needs to use slip-days, they need to decide who's days they are using. However you decide is OK with me, but we will be tracking the slip days per student. If will be using any slip days on a deliverable, tell me in advance that you will be doing so (so that I don't nag you about whether or not I lost your submission message).

3.2 Team and Individual Grades

When we tackle big projects, we succeed or fail as a team. Consequently, the majority of the grade you earn on a team project will be based on the overall quality of the team's product. But a team can only be successful if everybody is working towards producing quality results. Thus, a non-negligible portion of your grade will be based on individual contributions:

criterion	value
quality of primary authorships	10%
share of project work	5%
personal on-time performance	5%

3.3 Primary Authorship

The ability to organize large collections of information into a coherent narrative is an important skill, and each team members should take primary authorship for multiple work products. The quality portion of the individual contribution grade is based on the work products for which that person was the primary author (presided over a process, or wrote at least 2/3 of the text in a document).

Each work product submission must include an indication of the primary author (or authors if no individual produced 2/3 of the text). Note, however, that since the whole team will be graded on the quality of each work product, it is only prudent for the entire team to review any high-value work product before it is submitted.

3.4 Share of Project Work

I will keep these as confidential, and average them together to get a sense of the individual contributions to each team's efforts.

3.5 Collaboration and Citation

This is a team project, but different individuals will have primary responsibility for different processes or work products (or different parts of a single work product or process). Each team will be working on a different type of product. You are free to talk your team members (and for that matter other teams) about the processes you are following. You may review your work products with your own team members, and revise them based on their feedback ... but ...

1. If you are the primary author of a work-product, you must cite the source of text you did not write (if it is more than a sentence), or any information that did not originate within your team or from your interviews.

   You will be doing research to develop your product definition and requirements. I expect that many of the ideas for your product will come from this research. Cite all of your sources for each work product, and explain how each source contributed to your work products.

2. You may not share any of your work products (other than as required for reviews) with members of other teams.