Seabase I Case Study

Module E

On Monday, Sept. 27, the CS team hold two meetings. The first is a "brainstorming what-to-do meeting" in the hall. Present are Ken Lundy, Bob Marin, JoAnn Durst, and Arnie. At this meeting they try to"get our heads straight about what we're doing and should be doing."

Minutes of Sept. 27 CS Team brainstorming meeting

From JoAnn's minutes, at this meeting:

  • They try coming up with milestones to put in a time line.
  • They realize that they cannot come up with milestones because they are unclear about what Dave wants/expects or what the ME crane team wants/expects.
  • They decide their next move must be to clarify how to proceed. First, they agree that they need to get the ME crane team requirements document. JoAnn is assigned to ask Nancy Smith for this:
Dear Nancy:
		
Our computer science crane team would please like to have a copy of the crane
requirements. We think it might help us understand the big picture and help us
write our requirements. 

See you Wednesday noon at the team leader's meeting.
Thank you for helping us get the crane requirements.

Sincerely, JoAnn
  • There is a general discussion of how quickly to move into coding or work with matlab. There is an indication that at least some team members think "we should be doing more planning and big picture... rather then leaping into coding as sounds like Hank thinks we should??"

After that, they meet with Hank Taylor to go over the code from the model crane in Albuquerque, a "code functionality meeting."

Minutes of Sept. code functionality meeting with CS Team and Hank

At the meeting with Hank Taylor, the purpose is to go over the code from the model crane in Albuquerque. (Listen in on the meeting as they dissect the code.)

There is also a lot of discussion about learning Matlab. (Listen to the discussion and follow along with the meeting minutes.)

  • The CS Team asks Hank how to run the simulation he sent them. Hank explains, and Bob agrees to try this with the copy of Matlab from Nancy Smith. Hank stresses that the point of the simulation he sent is to help the students understand S-functions. It is not a crane simulation, it is from another, simpler project.
  • The team shows Hank the header file of functions from control1.h with one-line comments of what they do in control1.c. Hank says they need all the functionality in control1. The team can skip the functionality in the other file, pcs.c.
  • In the code, "solution" is the main function that gets called and is the link function between the pcs and control code
  • The team asks about how to write subroutines in Matlab/Simulink. Hank replies that there is no good way to have a call to a subroutine. Instead Hank pops copies of useful subroutines (e.g. a matrix multiplication routine) into the front of each s-function so each s-function has them
  • Hank recommends figuring out exactly what are the seven things that are sent to "control" when pcs calls control and understand those seven things. Can get control to run and test with seven "pretend" inputs to see if it's working.
  • Hank asked if the students know how to go about the crane controller now, and Ken answered that he thinks we need to get more big picture, a flow chart, understand the terminology
  • Hank explains some basic crane-related terminology: slew, luff, hoist
  • As before, Hank indicates he would like a flow chart of the code to have visual representation to help with maintenance
  1. Discuss the outcome of each meeting.
    • What conclusions did they reach?
    • Could having roles (facilitator, agenda keeper, minute taker/poster, etc.) improve effeciency of meetings?
    • If so, how should these jobs be distributed?
  2. The term "big picture" arises twice: once at the brainstorming meeting, then later at the code functionality meeting. The CS team seems to want more of a "big picture" of the project, while (at least in the view of the CS team) Hank is encouraging them to "leap into coding".
    • What additional "big picture" information might Hank be able to provide? What value (if any) would it be to the CS team?
    • What (if anything) might the students gain from "leaping into coding"?
  3. Did they resolve things they discussed at the "brainstorming meeting" by meeting with Hank? Which things were, which were not?
  4. Look back at the "Function List." Does it make more or less sense now, based on the two meetings?
  5. Look back at the Risk Document from Module C.
    • Do you see any risks being played out?
    • What are the students doing to mitigate them? Is it working?
    • Are there any risks that should be added to or removed from the document?

A lot goes on in this week, so it is broken into three modules. Module F covers Ken and JoAnn's discussion the next day, when JoAnn and Ken try to make sense of what they got from Hank. Module G covers the activity of the rest of the week. Break it up as necessary for classroom use.

There are two meetings in this module: the brainstorming meeting, where they develop questions for Hank, and the functionality meeting with Hank. Look across the two, and watch for connections between what CS is looking for and Hank's responses.

There is an interesting tension here: Hank is clearly keen in the CS team getting involved with real code; yet the team still wants more high-level information. Since Hank has been involved with the project for some time, perhaps he is having difficulty seeing the CS Team's point of view. At the same time, the CS Team is having trouble getting a hold of certain concepts without trying Matlab and Simulink (this becomes ever clearer as time goes by).

JoAnn mentions "requirements" twice in her email message:

  • She makes a request for "crane requirements". It is interesting to look ahead and see when these requirements materialize.
  • She makes this request so that the CS Team can write their requirements. The CS Team seems to have taken on the job of writing their own requirements. It is not clear who assigned them this task. It is probably worthwhile to discuss the problems with developers writing their own requirements.

There is a ton of code information in this module and the following two. The interaction aspect is also very rich, as the CS team develop questions, pose them (in this module), then unpack the answers (in the next module). One class activity might be to form small groups, and have some groups look at the code and other project specific stuff, and have other group look at how successful the team is at posing questions, getting answers, and putting that information to use. The groups could report their findings back to the class as short presentations, including critique and suggestions for improvement, and discuss (across groups) what they found. Most reading and analysis should be done outside of class. Because of volume, may want to spend more time on these. Good introduction to project planning, and the need to understand the "foreign" language of ME (Matlab).