In general

This category includes features, usability, and documentation. In some cases users will be divided into more than one group (e.g., in a system with administrative and end users). In other cases (e.g., a computer game) there is only one group of end users.

• Feature set: The features implemented should be well-chosen and effective for the purpose of the application. If the product is meant to replace a manual process, the implemented features should be sufficient to make replacement practical and attractive. If the product competes with other available products, it must be “better enough” in some ways to be a good choice for some identifiable group of users. (In some cases this might be a “good enough” free application to compete with commercial alternatives.) A game should be fun and unique enough to attract players.
• Usability: The user interface should be designed and implemented so that the application is accessible, efficient, and pleasant for its intended user group. The user group should not be artificially restricted. (For example, while it could make sense to create an application specifically for iPhone or for Android, a web service that should be available to everyone should not be restricted to one mobile platform.) To the extent feasible, the product should be accessible to people with disabilities.
• Adequately documented: The amount and kind of user documentation required will vary a great deal depending on the application and users. An application designed for occasional, casual use should be usable without any external documentation, but should have extensive internal documentation. An application for managing critical information may need an extensive user manual. If an application has multiple sets of users (e.g., administrators and end users), they may have different documentation needs. You should consider user needs and create what is appropriate.
• Robustness: Your product should be of high quality. I'd rather have fewer features than more features with bugs. (See also 'tests' under product for future developers.)

Adapted to Project 1, Spring 2017

This project is intended as a minimal viable product (MVP) of a team formation program, and as such I expect that you will have focused on prototyping some aspects of the application and done a bare bones implementation of others. Some teams may have focused on the team selection algorithms, and others may have focused on the user interaction, or on something else. If it is clear what you have focused on and why, I will adjust my expectations for other aspects of the product. The whole thing must work (that's the 'V' of 'MVP'), but some parts may be much more 'M' than others.

In General

This category includes materials needed by someone who might fix or extend your product. It includes the organization of your repository and the process for building and deploying your product, as well as aids such as test cases and documentation used by developers.

• README.md: The README file of your repository should be brief but should give me everything I need to determine what your project is, who its authors (you) are, and a basic outline of what the build process and the resulting product are. It may contain links to additional material.
• Requirements and design documentation: A person who considers fixing or extending your system needs to understand what it was intended to do (requirements), including not only what has been implemented in the current release but also plans for future development. They need to understand how the software is organized, sufficient to know what code they might need to read to add or fix a feature, and what code they can ignore, and they need to be able to understand how a new feature or change would fit into your system and be consistent with it (architectural design).
• Build and deployment process: It should be as easy and understandable as possible to check out your repository, build your product, and deploy it. The build process should be as automated as practical. Manual steps should be clearly documented, starting with a README that may refer to further documentation as needed. Your repository should be organized in a way that supports the build and deployment process. For example, target-specific and platform-specific choices should be factored out, not mixed in with core code of your application. Your system should not have unnecessary dependecies, and to the extent possible the repository should include only sources for the system under development. Intermediate products (e.g., compiled code) and external dependencies (e.g., libraries) should be avoided as far as possible.
• Tests: A developer should be able to easily test that they have created a working version of the application and that whatever changes they have made have not broken it. Tests should be automated to the extent practical, and should be documented. Manual tests require more extensive documentation than automated tests.
• Organization: Your repository should be organized to support the needs described above, e.g., it should be easy to find code that needs to be changed, and the organization should support your build and deployment processes.

Adapted to Project 1, Spring 2017

• I have increased the weight of this category from the usual 40 points to 50, in light of the product being intended primarily as the basis for further development.
• While I appreciate automated tests, I will be lax about requiring them until we have discussed testing in class.
• As we discussed in class, the amount of required documentation is not voluminous, but it must meet the needs described above.

In General

A good process will typically be reflected in the product, and a poorly managed project will almost always lead to problems in the product, but there are a few things that I want to check independently.

• Developer logs. I prefer these in the repository wiki, but versioned files in the repository are ok if your README tells me where to find them. I insist on versioned files because I want to see that the developer logs were incrementally updated during the project, now fabricated at the end.
• Version history. I want to see that each team member has been making regular contributions, and that the product was not cobbled together in a frantic final day of hacking. If there is a legitimate reason that the version history looks different (e.g., June and Joe pair-programmed and always committed from June's account), this should be supported with documentation, including commit messages. Commit messages should be meaningful.
• Project management. Provide any other evidence useful in seeing that your project was well-managed. This could be meeting notes, a narrative account of your progress, a Gantt chart showing planned and actual progress, or something else appropriate for your project. I'll expect to find this in your wiki unless your README file tells me to look somewhere else.

Adapted to Project 1, Spring 2017

• I have reduced this item from 20 points to 10, since I am requiring less documentation of process.
• Developer logs are not required.
• I will still look at the git history. If it's wacky, you should explain it.
• You are not required to provide progress logs or a wiki, but you may do so if it helps explain the state of the project and the git repository.