project phase 1

DAW Project

Goal

The DAW project is comprised by the analysis, design and implementation of an information system to manage project issues and associated information. Its development is divided into 3 phases, with incremental requirements published before the beginning of each phase.

• Phase 1 will focus on providing an HTTP-based Application Programmers Interface (API).
• Phase 2 will be the creation of a browser-based client application.
• Phase 3 will consist of deployment, operational, and access control requirements.

Domain and functionality

• A project is a long-running development activity, such as "DAW Project" or "LS Project". It is characterized by:

  • An unique name.
  • A short description.

• An issue is a task that needs to be done in the context of a project, such as adding a new functionality, resolve an error, add a test, create a final release. An issue always exists in the context of a project. It is characterized by:

  • An unique identifier.
  • A name.
  • A short description.
  • A creation date and an optional close date.
  • A set of labels, such as defect, new-functionality, or exploration.

• An issue has a state. The set of available states and the set of possible transitions between states is configurable per project.

  • The set of available states must include the closed and archived states. It should always be possible to transition from the closed to the archived state.
  • The set of available states must also define a single start state.

• An issue has a sequence of issue comments, ordered in chronological order. A comment is characterized by a short text. A comment cannot be added to an archived issue.

• Issues can have zero or more labels. The set of allowed labels is defined per project.

Phase 1 requirements

• Issue management functionality should be exposed via an HTTP API, including possible states and transitions.

• Storage should use a relational database management system, preferably PostgreSQL.

• Authentication should use the HTTP Basic scheme. Better authentication mechanisms will be introduced in future releases.

• Error information should use the format described in the Problem Details for HTTP APIs specification, whenever possible.

• The phase 1 delivery must also include all the API documentation required to use it. Namely, it should be possible to create an API client just by using this documentation or the external documents referenced by it (e.g. media type formats). However, the documentation should not hinder the API evolution.

Evaluation and Delivery

• The evaluation focus will be on the HTTP API documentation and implementation.

• Phase 1 must be delivery until April 8, via the creation of a 0.1.0 tag on the group's GitHub repository.