Project 1: A Simple Calendar Application

Project Description for UO CIS 422 Software Methodologies. Revised by A. Hornof on 1-9-2019.

The first project is intentionally simple with respect to the code that must be developed. The goal is to allow team members to learn to work together, develop an understanding of the software development process.

Addendums

These are additions to the initial assignment, with the most recent added at the top.

01-16-2019 - The initial SRS/SDS/Project-Plan is due Thursday, January 17, 2019, at noon. The final submission is due Tuesday, February 5, at 10PM. Both should be submitted via Canvas, with all of the files combined into a single .zip file. One member of the group should submit the project for the entire group.

Objectives

For most teams, the hard part of this project will not be the coding, but being clear on the requirements, and organizing the team to work effectively together, in particular:

  1. Requirements: getting clear on precisely what the software should do and communicating this to all team members.
  2. Work Assignments: being precise about the tasks assigned to each person; exactly what is to be produced and when it is due.
  3. Iteration: building the code up as a sequence of meaningful subsets of the eventual functionality in a way that can easily be extended.
  4. Design: communicating the major software design decisions and their rationale.

The software to be designed is a program that can be used to maintain a simple calendar. At a minimum, a calendar holds a collection of events, each recording an event name, date, start time, end time, and description.

Initial Requirements

  1. It must be possible to add a new event to the calendar, edit existing events, and delete events.
  2. It must be possible to easily see what is on the calendar today. And tomorrow. And the next day.
  3. The program should keep track of whether any changes have been made to the calendar since it was last saved, and offer the user the opportunity to save changes when the calendar is closed either explicitly or as a result of choosing to create/open another, or quitting the program; i.e., it will not lose unsaved data without warning.
  4. It is anticipated that the calendar application will be routinely updated to add features, improve capabilities, or improve quality. It must be possible to extend and update the calendar design as requirements change.

Quality Requirements:

A useful system must meet at least the following quality requirements:

  1. Performance: The software should respond to user requests at a speed equal to or better than competing applications, in any event not to exceed 500ms.
  2. Reliability: The system should enter and retrieve or exchange properly formatted calendar data without loss or error.
  3. Standards: The calendar software should ensure that data entered is consistent with HH:MM and DD/MM/YYYY date time standard. Optionally, events might be expected to occur on the quarter hour (such as 1:15PM, 1:30PM, etc.)
  4. Consistency: It should be possible to edit the name (or other fields) at any time while keeping the associated data.
  5. Ease of change: It should be possible to make likely changes to the system without extensive re-design. Simple changes should require changes to only a single system component (module).

More Advanced Features (Likely Changes)

Once the basic functionality is implemented it is expected that the team will add one or more advanced features. The system should be designed so that such changes are easy to make. An advanced design will implement one or more of these features.

  1. Notify users of scheduling conflicts and give them options to resolve the conflicts.
  2. Allow for adding recurring events (daily, weekly, monthly, yearly)
  3. Permit users to define categories for events (such as "work", "home", etc.).
  4. Permit users to define priorities for events (such as "high", "medium" , or "low").
  5. Permit users to see events based on category and/or priority, such as to easily seewhat are the high priority events today? Tomorrow? The next day? Or, what are the low-priority work-related events today? Tomorrow? The next day?
  6. Allow users to change their time zone (and update events accordingly).
  7. Allow for multi-day events.
  8. Allow for adding all-day events.
  9. Set a default day and time for setting an event.
  10. Permit two calendars to be merged into one.
  11. Permit the user to view events by month.

Developmental Objectives

The first objective should be to build something the customer (played by the instructor) actually wants. In addition, speed of development and software quality are critical.

Suggested Subsets

Teams should employ an incremental development strategy that builds first an application with a small subset of the expected features. Subsequent increments should add additional features. Teams may decide which features to implement first but the following is a reasonable approach.

L0: Minimum Useful Subset

All teams should complete a minimum useful subset as follows:

L1: Basic Address Book

L2: Advanced Address Book

Constraints

It is required that at least two team members contribute to each of the significant artifacts. In particular, that two or more must contribute significantly to each of the following: designing the software, writing the code, creating the documentation, providing reviews, and testing results. It should be clear from the schedule and developer log which team members contributed to each artifact.

Acknowledgements

This project description was derived from work presented by Prof. Stuart Faulk.