Seabase I Case Study

Module B

At the end of the third week of the project (Sept. 17), JoAnn and Bob meet with Nancy Smith, another professor from the ME department. She explains the makeup and functions of the other two groups working on the crane project. Each team is composed of one Electrical Engineering student and three Mechanical Engineering students. One team will develop the Stewart platform to simulate the wave action/ship motion; the other team will build the crane itself.

Minutes of Sept. 17 meeting with Nancy Smith

She tells the CS team that the other groups should have a requirements document prepared by the following week. Pending receipt of those documents, Smith provides the CS team with some general information:

  • The crane will have both input and output from computer to machine.
  • The platform will be just output from computer to machine.
  • Sensors on the crane gather information and act on it (independently of user actions)
  • There are "algorithms that probably will be added much later", and an important aspect of the project is to "leave it open to customization later".

Dr. Smith also shares some of her opinions on the project. She thinks the CS students could help with the platform also, and asks the CS team to stay open to working on the platform. She also agrees that the platform will not materialize until next term and crane might materialize this term. Concerning the scope of the CS end of the project, Dr. Smith thinks the GUI design is a good project for the CS team, and that working on only the crane controller would be "too simple".

To try to stay on track, JoAnn tells the CS team that they will hear from the ME crane team next week, and that if they do not, "Dr. Smith will prod them".

The next Wednesday, September 22, an email list for the CS team becomes active.

 

  1. What is a requirements document? What would you (as a CS student) expect to see in it?
  2. Nancy Smith states that the mechanical crane and platform will not materialize until later.
    • As a member of the CS team, how would this affect: your timeline/milestones?
    • Your perceived risks?
    • Your sense of urgency?
  3. What do Dr. Smith's comments contribute to your understanding of the project?
    • How would you use that information?
    • How would you record it?
    • How would you verify it? (With whom, and why?)
  4. Who is "in charge" here? Dave, Hank, Nancy? One (or more) of the developer teams?
    • How would you go about finding out?
    • What are the consequences?
  5. The CS team activates an email list.
    • What would have been gained by activating it earlier?
    • Who would you place on this list?

This module:

  • complicates pre-existing "turf" questions: with the appearance of Nancy Smith, it is no longer clear who the "go-to" person in ME is.
  • introduces the need for documentation (which will be ongoing). Here, the CS team is cast as the recipient of documentation from other teams.
  • brings up the issue of shared communication, through the establishment of the email list.

It is important to get across the interdepartmental nature of the project --- something CS majors will need to get used to. What can the CS students do to get accustomed to the world of ME? How can they find out more about the power relationship between Nancy Smith and Hank, without stepping on any toes?

Looking ahead, we see that Nancy Smith's participation ends up being fairly limited. The instructor can make use of that foreknowledge, posing Smith as the "lead contact" at this point, then asking later what difference it makes when Hank becomes more involved.

Nancy Smith makes some strong claims about the CS team's project. Looking ahead to the next module, we see that Hank makes claims contradictory to hers. It is interesting to see how these clashing views of the project affect the CS team's schedule and risks.

The CS team awaits documentation from the other crane teams. This raises two important issues:

  • the role of documentation in software development, both as something to produce and as something to use. The CS team is dependent on others' documentation for their own success. By reflecting on their role as documentation users, students can be motivated to produce quality documentation for others.
  • the uncertainty implicit in a complex project with multiple teams: in particular, depending on others for materials (physical or logical). The CS team is hampered to a certain extent by the lack of input from other teams: currently by a lack of documentation, possibly in the future by a lack of crane hardware. This emphasizes the importance of communication between teams.

After reading the module outside of class, students should be able to respond with ideas on:

  • how to deal with other departments and their demands;
  • the content of the requirements document, and why it is important;
  • who they think is running the project, and who they should go to in order to get things done

Another item to discuss is the importance of shared communications.

  • Why wait until the fourth week to set up the email list? What is lost in waiting so long?
  • Discuss who should be on the list, and why. Perhaps there are different audiences with different needs; should there be more than one list?