Seabase I Case Study

Module C

On Wednesday of the fourth week of the semester (Sept. 22) the leaders of the three crane project teams meet with Hank Taylor and Nancy Smith. They decide that since the "point of meeting is to get regular coordination of the teams, they will continue the meeting of team leaders on Wednesday from 12-1 on". Representing the CS team are JoAnn, Ken, and Bob; Matt and Ben come for the crane builders; and Jon is there to talk about the platform.

Minutes of Sept. 22 Crane Team Leaders meeting

The items on JoAnn's summary of the meeting are:

  • The CS team will work on crane, not on the platform, this term.
    • In a discussion of scope of the CS team's part, Hank says the crane part is the "biggest, nastiest" part and he thinks the GUI for the platform will take about an hour and is the easiest part.
  • Some discussion of the CS code functionality:
    • CS code takes three inputs: operator input, measure platform motion input, and swing measurement input.
    • The code generates new commands to the crane that cancel out the ship's motion.
  • The DSpace application comes with an integrated development environment with widgets that can be dropped into a GUI quite quickly.
  • Hank gives the CS team a CD with the controller code for the Albuquerque crane. Some comments on the code:
    • "Global variables were used and were put in the header file."
    • "Half the code is not applicable to our crane, instead it's related to transmitting information."
    • "flag in c code (ex: flag1, flag2) sets what function in template is called"
    • "Bob asks: want scaling factor in the code for controller? Hank answers: no, but might be interesting"
  • There is a discussion of what the CS team should be expected to do:
    • "Example CS requirements could be: no bugs, works under xyz conditions, fast enough for real time running"
  • Hank raises the possibility of computer support for the CS team:
    • "When Hank gets the money for the project, he'll be getting a laptop for each team which will have simulink, matlab, and d-space and CS team can use that."

The CS team writes up a "to-do" list based on the discussion:

  • share the MATLAB application given to them by Nancy, and check it out
  • use the helpdesk option in Simulink, particularly looking for instruction on writing S-functions
  • try to get familiar with DSpace
  • "CS team will go through code from previous model crane looking at flow and low level stuff, and then meet with Hank to decide which functionality is still relevant to this crane project."
  • Following that, they will do a flow plan/chart of functions that are needed, "so ME's have way to see what's happening with the control".
  • "Hank will send an example of an S-function." They will review example code from Hank. Then, they can "come up with block diagram of how to chunk the functions into s-functions and write the s-functions and test."
  • Some team management issues:
    • "Hank to meet with us on Monday, Sept. 27 at noon in his office"
    • Need to "change meeting with Hank (too soon)"
    • benchmarking, timeline, brainstorming requirements
    • select CS team leader?

They also create a list of current project risks.

Risk Document for Week 3

  1. Can you recap the project so far?
    • What information has been conveyed?
    • What questions remain about what has to be done?
    • What would you do to answer those questions?
  2. How would you characterize the interactions among Hank, Nancy, and the team members?
  3. It's interesting that Hank says that the "crane part" is going to be "the biggest, nastiest part", and that the GUI design will be easiest. On the other hand, Nancy seems to be saying the opposite: the controller will not be very difficult, and the GUI will be more challenging. Why might they have such different opinions? How can the CS team resolve this difference?
  4. The CS team attends a Team Leader meeting. What might be the value of this kind of meeting, instead of just meeting with Hank?
  5. Critique the to-do list as given in the minutes.
    • What purpose does it serve?
    • Is there more information that you would add?
  6. Critique the risk document, in a similar fashion.

This Module:

  • (Re)establishes Hank as the "go-to" guy. Note that Nancy Smith is relatively silent at this meeting (at least according to the minutes).
  • Reveals a clear disagreement among the ME faculty about what the challenges in this project are. This is an excellent opportunity to discuss the common phenomenon of differing requirements or expectations among stakeholders.
  • Introduces two types of team-internal documentation: "to-do lists" and "risk documents".

A critique of the team's documentation should include an acknowledgment of their use in keeping on track and assigning responsibilities. On the other hand, the documents do not establish deadlines for action or assign responsibility for particular tasks to particular team members.

At the Team Leaders meeting, there is a discussion of requirements for the software that the CS team is to produce. However, it is clear that there are no hard requirements in place at this time. It may be worth discussion how this affects

  • the timeline of the CS team, and
  • the general impression of the level of commitment to the CS team

The prospect of creating documentation for the ME students is raised. It is interesting to consider the kind of documentation ("flow plans/charts") that ME students are accustomed to. The difference between CS and ME documentation of this sort turns out to be an obstacle for the CS team. A possible out-of-class exercise: do a search for "flowcharts" of various types (in ME and other disciplines), then report on the differences between these and the kinds of flowchart documentation that CS students are familiar with.

The CS team is asked to wade into unfamiliar waters here: go through the Albuquerque crane code; learn about S-functions; play with Matlab, Simulink, and DSpace. It turns out that the CS team has a hard time starting this process.