Links

Planning

Planning has progressed into Phase 2 of the requirements analysis process. At the beginning of the eighth week of the quarter, we plan to release a refinement of the requirements walk-through, as well as an initial operational prototype.

Phase 2 Planning

On Friday 4 November, we sent an email announcement describing the second release of the requirements walk-through, and the new prototype. During the eighth and ninth weeks of the quarter, we are scheduling in-person demonstrations of the prototype. Since the prototype is in its earliest stage of development, we think it best to demonstrate it features in person, before we make it available for general use. Following the in-person demonstration, users can retain access to the prototype to experiment with as much as they would like.

In conjunction with the prototype visit, we would like to have a question/answer session about features of the scheduling program. The meeting to demonstrate the prototype and discuss features will last from 30 to 60 minutes. Complete details of how the interview will be conducted are available in the the script that the students use, available at http://users.csc.calpoly.edu/~gfisher/classes/402/handouts/phase2-interview- script.html The meeting does not need to follow the script exactly, but we have the script as an outline of what we would like to discuss.

Phase 1 Planing

The Phase 1 planning discussion that follows is now of an historical nature. It explains the planning for initial requirements gathering phase of the project, which has now been completed.

Three particular aspects of planning are important at the beginning of the project:

  • what to expect in the initial requirements interview
  • how we plan to communicate among project stakeholders
  • what kind of time commitment may be involved

The next three sections of this planning page are directed specifically at department schedulers. The "you" in the discussion refers to "you, the department scheduler".

The Initial Requirements Interview

The purpose of the initial requirements interview is to gather information in the following areas:

  • identify the people involved with scheduling in your department
  • get an overview of how scheduling is performed at present, including what forms of software tools are used
  • ask about any ideas you may have for features in a scheduling software tool
  • determine if there are any particular positive or negative impacts that may arise with the introduction of new scheduling software in your department
  • gather any other information you may wish to provide

You may already have some or all of this information in document form, online or on paper. If so, you can expedite the interview process by providing a brief overview of your documented material during the interview. Then you can provide the links or paper copies to the interview team, for review by them after the interview is over.

The interview will be scheduled to last 30 minutes. If you think you may have more to discuss than can be covered in 30 minutes, please feel free to request a longer time period, up to an hour. This scheduling detail will be taken care of when a student interview team makes its initial email contact with you during the first week of classes.

If you would like further details of how the interview will be conducted, you can read the script that the students will follow, at: http://users.csc.calpoly.edu/~gfisher/classes/308/handouts/interview- script.html

Communications Planning

Our objective is to maximize communication efficiency for everyone. As outlined in the People section, there are three primarily forms of communication:

  • in-person
  • email
  • webpage and forum

With everyone's busy schedule, in-person communication will be considered a particularly valuable resource. If anyone wants to talk in person with project developers, we have adequate student staff to accommodate this. However, we expect that most communication will happen electronically.

Email is an efficient means to send mass mailings of interest to all stakeholders. However, it clearly has its shortcomings in a number of areas, as most of us are well aware. Once the project is underway, most communication from the developers will be in the form of postings on the project website.

From the perspective of non-developer stakeholders, there are two forms of website communication -- passive and active. Passive communication is simply a matter of reading the website, at your convenience. Active website communication will involve using the project form, some introductory details of which are covered in the Forum section.

An important aspect of communication planning is determining how much of it everyone wants to do. For non-developers, there are roughly these three levels:

  • little or no active communication beyond the initial interview, with as much reading of the web page as desired
  • active communication via the project forum, email, or in-person meetings
  • active participation in reviewing the product prototype as it is developed throughout the quarter; more details on this communication level will come a bit later in the quarter

Determining which of these communication levels is right for you is entirely your choice. If you find using a forum is a convenient way to communicate, that's splendid. If you'd rather send an email or talk in person, that's fine too. You do not have to use the forum to be a fully participating stakeholder. If you have little time to participate actively, then you can read the project website as you have time, to keep abreast of developments.

Estimated Time Commitment

The involvement of end users is one of the most important factors for success in a software project. Alas, such involvement requires a time investment during the early stages of product development.

Ideally, we would like three additional hours of your time, beyond the initial interview. This will be divided into approximately one hour segments in each of weeks 4, 7, and 10 of the Fall quarter. The time will be spent reviewing what the project team comes up with to meet your requirements for scheduling software.

If the scheduler project produces a product that is useful to you, the time you invest during product development will be more than offset by the time that you save in future scheduling work.