Seabase I Case Study

Module H

This week starts with some emails on October 4 about the team's presentation, and includes their meeting minutes for the past Thursday:

    
Dear Dave: 
Just a reminder that you are coming to the crane team leader meeting with Nancy 
Smith and Hank Taylor this Wednesday, Oct. 6th, at noon, in MEEM 306  
The CS crane team will be presenting their timeline. Hank will be at the meeting 
and is happy to see the timeline.

--JoAnn

	    
Dear Bob and Ken: 

Sorry I was so slow with minutes and To DO list. It's helpful to see it.
Goals for today's noon meeting in Fisher HAll and for team leaders on 
wednesday are in minutes.

--JoAnn

The CS team meets on Monday, Oct. 4, and again on Wednesday (Oct. 6):

Minutes of Oct. 4 CS students meeting

The work in this meeting consists of planning for the near future: Bob is to work on the timeline and flowchart, which he will present at the upcoming Team Leaders meeting. Ken is to work on getting the inputs and outputs to the software clarified. There is a meeting planned on Oct. 11 to "brainstorm requirements".

The Team Leaders meeting takes place on Oct. 6:

Minutes of Oct. 6 team leaders meeting with guest Dave Voelker

At the meeting, there is discussion of documentation that the CS team can give to the rest of the project team members. JoAnn is in charge of sending an "introduction" document to Nancy and Hank. Bob is to work on a call graph of the existing C code, with an arc from each function to each function that it calls. On the to-do list, learning Matlab figures prominently: "faculty are starting to ask about it".

  1. Look at the meeting minutes to answer the following questions:
    • Do the input values and/or inverse kinematics need scaling?
    • Must the code done by end of the term? Why or why not?
  2. With the term nearly halfway over, the team plans a "requirements brainstorming" meeting.
    • Will further brainstorming help them?
    • What could they do apart from brainstorming to solve their problems with requirements?

Most of the minutes here show the team setting/clarifying their responsibilities and what they will be doing.

Under the "goals" for (10-6 team leader meeting), detail 5, "a good idea to clarify each CS persons role". Didn't they do this before? Shouldn't it be done by now? In any event, the CS team members now have specific responsibilities. Overall, it looks like the team is beginning to "work and play together": Bob and Ken doing presentations, etc.

Although CS team seems to be working together better, they are mostly covering old ground. There is some important information to capture in this week.

  • Responsibilities of group members.
  • Defining project requirements.
  • Trying to cope with differents paradigms of ME (Matlab, and the way ME's think) and the more familiar CS models.

In the "Questions" section, #1 is intended to "force" the students back to the original documents. They should learn to digest meeting minutes, and be able to summarize major issues from them. This is an important "real world" task: as project leaders, they will attend meetings and be expected to convey the information to co-workers at different levels.

The CS team continues to try "brainstorming", but the subject of the brainstorming seems to remain the same: nailing down the requirements. This brainstorming seems to be done solely among the CS students themselves. Two points of discussion:

  • getting clients involved in discussing requirements (complicated here by the power imbalance between the students and the ME advisors);
  • the limitations of brainstorming, and alternative strategies to brainstorming.

One big complicating factor that if not noticed by students should be made clear by Instructor: the software paradigm behind Matlab is totally foreign to CS students. Programming projects in CS are all of the "call-and-return" paradigm (at any point in time, a particular "caller" module sends a certain number of data items to a "callee" module; gets a single value as a result). Matlab follows a paradigm more like that of an electronic circuit (every module is "caller" and "callee" at every point in time; modules produce more than one result at a time). This was very hard for both the CS crane teams to understand.

Dealing with "different paradigms" is something students will encounter throughout their careers; Helping students to develop ways of coping one of the major goals of entire case study.

An interesting fact, f rom the minutes of the Oct. 6 Team Leaders meeting: the code need not be finished by the end of the term, if Bob commits to continuing the project next semester.