The software architecture process depends on successful teamwork involving cooperation among members of the design team, cooperation between the design team and the clients, and cooperation between the design team and the development organization. Cooperative learning is a pedagogy that directly supports this type of teamwork. Through cooperative learning students realize their interdependence, practice face-to-face communication, recognize their individual accountability to the success of the group, practice interpersonal and small-group skills, and engage in frequent reflective processing of their achievements. We have adapted cooperative learning to teach software architecture in two undergraduate software engineering programs. In traditional cooperative learning, students work on one team for an extended period. This helps foster acceptance of individual differences and promotes successful teamwork. In our courses we kept students together on the same teams, but we wanted students to play multiple roles: clients, architects, and developers. So, we let the teams change roles during the course. That is, for each project one team played the role of architects, while other teams played the roles of clients and developers. Student teams rotated roles on different projects throughout the term. A further variation in cooperative learning is that, to succeed on each project, three different teams also had to cooperate. These innovations kept the benefits of cooperative learning while also exposing the students to 3 different perspectives as they progressed through their projects. This is especially important for software architecture, where the 3 perspectives must always be kept in mind. An additional benefit was that each student participated in 3 different projects, thus experiencing greater diversity of architectural challenges than would have otherwise been possible. Some changes to the traditional classroom setting are necessary in order to practice this new method. Students need to work in small teams, 3 or 4 students at most, during regularly scheduled classroom hours. The roles of individual teams must be scheduled so that sufficient time is available for each team to play each role. Fortunately, software architecture lends itself to short periods of intense team activity, with reporting and peer review of results later. We believe that this active learning style is an effective approach for most subjects, but especially for software architecture.

Date of creation, presentation, or exhibit



Presented at the 2007 American Society for Engineering Education (ASEE) Annual Conference & Exposition "Riding the Wave to Excellence in Engineering Education" June 24-27, 2007 - Honolulu, Hawaii

Document Type

Conference Paper

Department, Program, or Center

Software Engineering (GCCIS)


RIT – Main Campus