CSC 405: Software Engineering Capstone II

Instructor

Gene Fisher (gfisher@calpoly.edu)
Office: 14-210, 756-2416
Office Hours: M 2-3PM, Tu 9-11AM, WF 10-11AM, other times by appointment

Objectives

• refine requirements from Fall 2011
• design and implement requirements in two phases, using extant prototype as basis
• release each to selected clients, and gather feedback
• fully document design and implementation, using Javadoc
• define a formal JML model
• implement and conduct functional tests, based on JML model
• implement and conduct user-level acceptance tests, based on department-specific data
• refine requirements scenarios into end-user documentation

Refining Requirements

The requirements we produced in the Fall are not perfect, but we'll only spend about a week refining them. We'll then proceed with Winter Phase 1 of program design and implementation.

This means we will follow a requirements process somewhere in the middle of the spectrum between traditional and agile development. We begin with a reasonable though not exhaustive requirements document. We will have a one-week iteration of requirements refinement, then proceed with Winter Phase 1 implementation. We will follow the same process of brief requirements refinement, then implementation for winter Phase 2. The proposed time line for the development phases follows.

Design and Implementation Phases

Due to the somewhat "mission critical" nature of our product, it is not realistic to expect actual clients to adopt our tool in an incremental fashion. That is, we will not expect clients to use the Scheduling Tool to generate a real working schedule until we can demonstrate convincingly that we have a stable, production-quality version of the product. "Production quality" means fully testing. We will discuss the details of testing throughout the quarter.

The proposed phases of product delivery for both Winter and Spring 2012 are as follows:

Product	Delivery Date
Solid Prototype	Friday 3 February
Beta-Version Program	Friday 9 March
Production Program	Friday 18 April
Production Program, Enhanced	Friday 18 May

The "solid prototype" must have the following features fully implemented, and user-level tested:

1. successfully enter instructor, course, and location resource data adequate for generating Fall 2011 and Winter 2012 schedules

2. generates conflict-free schedules for Fall and Winter, that meet a liberally- defined goodness measure

3. allows the generated schedules to be edited to the precise form as published for those quarters

4. allows the schedules to be saved and re-opened at will

Winter Releases to Clients

The proposed form of Scheduler Tool releases for Winter quarter are as follows:

1. Whenever possible, schedule an in-person demonstration, and accompanying Q/A session

2. Leave the software installed for the clients to play with, and ask them to complete a brief usability questionnaire

3. Have 309 students perform in-lab usability testing, inviting any an all clients who would like to participate.

Javadoc Documentation

Some of it is done now. Over the course of Winter quarter, we need a more meticulous treatment, suitable for use by ITS or other campus personnel who may assume project maintenance next year and beyond. Hence, the audience for the Javadoc is for those we will maintain and enhance the product, on the Cal Poly campus in particular.

JML Formal Model

We will use the Java Modeling Language to define formal specification of Scheduler Tool. We will discuss the use of JML starting the second week of the quarter.

JML/JUnit Functional Tests

JML provides a tool for semi-automated generation of JUnit tests. The gist of the tool's output is code generated from the postcondition of a specified method, where the code is an implementation of the unit testing oracle. We will discuss details of this during weeks 2 through 4 of the quarter.

User-Level Acceptance Tests

In addition to functional JML/JUnit testing, we will perform acceptance testing through the end-user interface of the Scheduler Tool. Some of such testing can be automated, but there will always be a level of qualitative testing that must be performed by a human user.

The focus on department scheduling data will provide a useful focus for acceptance testing. Its benefits are two-fold:

1. the test are based on actual real-world data, with very precisely defined target result, i.e., the schedules published for particular past quarters of instruction

2. using department-specific data will provide clients with pre-defined databases, thereby alleviating potentially tedious data entry, and hopefully helping to engender some client goodwill.

Requirements Refined to End-User Documents

End-user documentation we provide will be in the form of user-selectable online-line help. We need to develop an interface framework for this, which we will do during the second half of Winter quarter.

The style of end-user documentation will be very similar to the UI-based requirements scenarios. From well-written sections of the scenarios, we extract the narrative immediately follows the initial Figure for each UI screen. This narrative is put in a closeable side-bar or separate pop-up help window. Again, we will discuss details beginning in Week 6 of the quarter.

Course Evaluations

I will provide bi-weekly written evaluations of all team members's work. The evaluations will be delivered in private online directories.

Draft Project Time Line

Week	Activities
1	organize, determine work assignments
2	requirements refinement; initial acceptance testing
3	phase 1 design/implementation/specification/testing
4	phase 1 design/implementation/specification/testing
5	phase 1 design/implementation/specification/testing; client release
6	requirements refinement/enhancement
7	phase 2 design/implementation/specification
8	phase 2 design/implementation/specification
9	phase 2 design/implementation/specification; client release
10	documentation production
11	analysis of client feed back