(183 K)

"Lehr und Kunst." This is the motto of Worcester Polytechnic Institute (WPI), which I joined this fall as a professor of practice. Literally, the motto means "learning and skilled arts," but I prefer to paraphrase it as "theory and practice." The greatest challenge in teaching computer science students to prepare for an industry career is to provide them with a proper balance of both theory and practice. With more than thirty-five years of experience in industrial settings, I am very knowledgeable and confident about the "practice" side of the equation. And for the "theory" side, I draw on my academic background, being mindful of what I've actually applied in a work setting from courses I've taken over the years.

Yet when I began planning my first undergraduate class at WPI, an object-oriented analysis and design (OOAD) course, I felt unsure about what makes a good balance. WPI's academic year consists of four seven-week terms, and at the start of each new term, I have the feeling that it is almost over already. I knew that I wanted to use a project as the centerpiece of the course, but how could I devise one that would provide the right balance of theory and practice for such an enormous subject in such a short time?

I didn't want to assign a trivial project that asked students to assemble a "toy" application. But realistically, how much code could I expect students to write in seven weeks? Most of them were taking two other courses, and some were working on long-term projects as well. Fortunately, my pondering ultimately led to a solution that provided my students with a different and interesting educational experience that included invaluable lessons about software development in the "real world."

Collaborative work expands learning opportunities

Most students in the course were senior computer science majors who had taken previous software engineering courses as well as a course in object-oriented programming with Java. My goal was to extend their knowledge of analysis and design techniques, with an emphasis on architecture and design patterns.

I recognized that in the time available, students would not be able to complete a moderate-sized project on their own. Therefore, I designed a project that forced them to collaborate with other teams and integrate their components in order to implement the complete project. This collaboration would serve several purposes. First, the students would get to work on a larger project than they might otherwise be able to tackle in seven weeks. Second, they would learn valuable lessons about how larger projects rely on effective subsystem integration. Third, they would learn how to purchase software and manage vendor relationships.

During the first week of the term, I asked the students to form teams of two to five students; the optimum size was three or four. By the end of the week they had divided themselves into fifteen teams. Some were composed of students who knew each other or had previously worked together. Others were groups of students who had never interacted. On most of the teams, at least one person took on the responsibility of ensuring that the work would get done.

The project I devised was fun, interesting, and practical, too: Students would build a software system, which we named WPI Marketplace. Each team would build a subsystem of WPI Marketplace and then interact with other teams in order to "sell" their software.

To simulate the way things work in the real software marketplace, I did a little pre-course work. I divided the system into six component subsystems and assigned my two teaching assistants to implementing the data subsystem; the student teams would implement the remaining five subsystems (see Figure 1). As there were fifteen teams, this meant there would be three versions of each subsystem, and teams would compete with one another for business.

Figure 1: WPI Marketplace component subsystems

The component subsystems were to have the following functions:

• The Product subsystem would let teams identify their products, the features of these products, and prices, availability, and so on.
• The Account subsystem would let the instructor create individual and team accounts. It would also let individuals maintain their account information.
• The Finance subsystem would maintain the bank accounts for each of the teams. The instructor would have special privileges to initialize the account balances and modify them when necessary.
• The Contract subsystem would allow teams to negotiate and agree upon contracts. When a contract was executed, the Finance subsystem would be notified to perform the appropriate transfers. The Contract subsystem would also provide features to let teams initiate legal action; the instructor would serve as the judicial authority.
• The BulletinBoard subsystem would provide a communication forum for individuals and teams. This subsystem would also provide advertising areas for teams to publicize their products.
• The Data subsystem would be a simple interface to a relational database. We had a MySQL server available in the department that we used for the project.

The teams drew subsystem names out of a hat to determine which one they would build--and each team also had to deliver a complete software product. This meant they had to "buy" the four subsystems they did not build themselves from other teams, choosing the products they felt were best for their needs, and negotiating prices with the "suppliers" (teams) that developed them. Each team started with $1,000 WPI (whoopee dollars) that it could use to purchase the other subsystems. At the end of the term, the team that had accumulated the most money would get prizes--T-shirts donated by a software company--but the amount of money they earned would not be tied to their grade. (Although in business we are graded on the profits we generate, this is not the right metric for an academic setting.)

I gave the teams a Vision statement as a starting point. ¹ We then held requirements elicitation sessions during class so that students could identify the people they needed to talk with in order to refine the requirements. To help them simulate the interaction required to do this, I adopted different personae, using a technique I first encountered at the Wang Institute for Graduate Studies in 1986; I put on different hats to indicate which of the four people I was role playing, including: ²

• Russell Customer, the primary client who contracted for the software.
• J.J. Draco, vice president of software development, whom the teams reported up to.
• Professor Pollice, who would assign their grade for the project.
• Gonzo, the technical consultant who would provide (sometimes not too helpful) technical hints.

I was not sure whether the project was too ambitious for the seven-week term, but since I urged students to take an iterative, incremental approach to building the system, I knew that they could deliver some amount of working software. However, I always told them that they were on the hook for delivering a complete system.

Overall, the project was a success; below, I'll briefly describe some of the ways it prepared students for industry software development work.

Understanding the importance of standards

On the theoretical side, this project taught students to think abstractly about the value of applying standards. On the practical side, it also showed them what happens when you don't bother thinking about standards early on in a project.

Because the system had five subsystems, it required a set of standard interfaces. I provided the students with a very rough skeleton for the main program class and subsystem classes and also minimally defined behavior for the interfaces between these classes. Students had to fill in the details. Figure 2 shows the main package structure for one system they produced; note that the message package is part of the Bulletin Board subsystem.

Figure 2: Project package structure

In this system, each package has a main class that is responsible for exposing the subsystem's interface. All subsystems implemented the interface I provided, shown in Code sample 1 below.

package marketplace;
/**
* IWMPSubsystem is an interface that is implemented by all
* WPI Marketplace subsystems.
* @author Gary Pollice
* @version Sep 29, 2003
*/
public interface IWMPSubsystem { /**
* Initialize the subsystems.
* @param marketplace the instance of the WPIMarketplace
* application.
*/
public void initialize(WPIMarketplace marketplace); }

Code sample 1: Subsystem interface

This interface gives each subsystem access to the marketplace object, which is implemented as a Singleton. ³ Once a subsystem has access to the marketplace, it can also access the initialized instances of other subsystems with which it must interact. The marketplace object is responsible for initializing the subsystems in the proper order.

Of course, the skeleton I provided was not enough to get the subsystems to interact with each other. About a third of the way into the term, the teams began to realize that they needed to know more about features the other subsystems would expose and the form they would take. This offered an opportunity to educate students about the utility and importance of standards.

As you probably know, the industry does not have unanimous agreement about what you should standardize and when. But at this point in the project, the need for standards became obvious. The class was learning design patterns, such as the Adapter pattern, which you can use to lessen dependence on specific interfaces of subsystems. But students had not yet internalized the value of adapters. I hoped that one group would take the lead in driving standards, but this did not happen.

So instead, I organized an after-class standards meeting, inviting representatives from each of the project teams. In the meeting, I made a conscious effort not to define any standards; I urged the representatives to define standard interfaces on their own and acted mainly as a moderator and scribe.

Unfortunately, this meeting did not produce great results. Although we identified people who could and did propose standards (with varying amounts of detail) via the electronic forum for our class, the student community overall provided little feedback and basically ignored these proposals. Teams were too busy working on their own subsystems to think about integration issues. Of course, this proved to be a problem at the end of the project, as I will describe later.

Learning how to market a product

With fifteen teams implementing five subsystems, each team could choose from among three "suppliers" to obtain each of the subsystems they needed to deliver the final product. This provided an opportunity for each team to participate in one of the more successful and fun activities of the term: Preparing a marketing presentation and delivering it in class. This activity taught students about the critical edge that effective marketing can give a product as well as tactical ways to construct a strong marketing package and make a sales presentation memorable.

All teams were given a template ⁴ providing a basic structure for their presentation. Each team had five to ten minutes to describe what made their subsystem unique and why another team might want to choose it.

Based on student feedback, this exercise was extremely worthwhile. A tremendous amount of effort and creativity went into these presentations. Many teams came up with names for their "companies" and thought intently about how to sell their product and make a lasting impression on potential clients (i.e., the other teams). When I asked students which subsystems they chose, their answers were typically something like "the one from the Swedish Chef group" or "we liked the group with the hats." Although they didn't always remember the company (team) name, they did remember strong elements of the marketing presentations.

I was impressed by how many of the teams thought about the service aspect of their product. As part of their marketing package, many included 24x7 support ⁵ or support within a specific time limit via email or instant messenger. Some teams offered to deliver the appropriate adapters to their clients at no extra cost. Extensive support, and the ability to adapt to client needs, were primary differentiators for the team that attracted the most "clients" and accumulated the greatest profits.

Delivering the product

The most important – and also the hardest – lessons that students learned were about delivery and implementation. Although almost every team was successful at building its individual subsystem, all the teams vastly underestimated the amount of work it would take to assemble the complete product. To be graded, teams had to sign up for a thirty-minute session with me to demonstrate their work and answer questions about it. They also had to write a short paper about their experiences and lessons learned.

Predictably, there was a flurry of activity the last week of the course. As I monitored transactions among teams as well as internal team activities on the electronic forum, I frequently saw panicky messages such as, "Does anyone have a working <insert name> subsystem?"

Many teams slipped their end-of-term delivery deadlines, and everyone --on both sides of the contract--learned about the consequences. Had the term been a little longer, my guess is that some teams might even have brought "legal actions" against their vendors.

Students really came to understand how theory and practice intersect in our industry through the example of teams that took my advice about using an iterative, incremental approach. These teams did very well. They delivered working but incomplete subsystems early, and then refined them as time went on. One of these teams cornered the market for its subsystem: Every other team (except their two competitors), chose to "buy" this team's subsystem. When I asked the client teams why they chose this particular vendor, they gave several reasons:

• The vendor's subsystem was the first to market. Although it was incomplete, the subsystem worked. That gave clients confidence that the vendor team would live up to its commitments.
• The vendor's subsystem was relatively easy to integrate. The developers didn't try to get too fancy and add unnecessary features. They simply implemented the basic functionality as defined in the requirements.
• The vendor was easy to work with and seemed eager to help.

Indeed, the market-leading team really delivered on the last reason. When my students "took over" one of the school's computer labs during the final week of the term, that team's members were there to help other teams integrate their subsystems and make changes as necessary. The relationship they built with their clients was critical to their success.

In the end, all of the project teams delivered a complete product except for one team that left too much work for late in the term, thinking it could put the application together in a couple of days. This team's failure represented a valuable learning experience for all.

Evaluating the results

At the end of the term, none of the complete products was robust or bug-free. I didn't expect that. I did expect students to learn something about building software products and working within a team environment. I also expected them to learn how to deal with incomplete and changing requirements. Not only did they meet these expectations; they also gained additional practical knowledge that they could generalize into theoretical constructs. Overall, this made the project a success: Students learned what it means to turn theory into practice and also to extract theory from practice. They also got a taste of the challenges they will face later on in their careers as software engineers and managers.

First, they all learned that integration is hard work. If you treat it as an afterthought at the end of a project, you will most likely fail. Integration is something you must plan for and start early. It must be done continually, as part of the development process. I was pleased that students learned this lesson in an academic setting rather than on their first industry job.

Second, they discovered that successful software is not necessarily the most technically advanced software. Many factors are more important to clients than technical sophistication--stability and robustness, for example. People are usually happy with just enough features to enable them to do their jobs. Most important, they want support, and to know that you care about their success.

Third, my students learned that being first to market means a lot. If you get there first, everyone else has to catch up to you. That doesn't mean your competitors will never overtake you, but it definitely gives you an advantage. Of course, product quality is important, too. One team made it to market first but their product just wasn't ready; consequently, many of their clients lost confidence and switched to another vendor team.

Of course, all the teams experienced stress, especially at the end. Many students said they would have preferred the workload to be spread out more evenly across the term. I expected students to put in approximately fifteen hours a week on this course; the time they spent overall averaged out to that, but the workload was definitely far heavier during the last couple of weeks. Plus, some subsystems required more work than others. The Product subsystem was quite easy to build, for example, whereas the Contract subsystem involved quite a bit more effort. Next term I plan to monitor the projects more closely and require more intermediate results.

Having the teams compete for WPI dollars to simulate competition in the marketplace was effective up to a point. Some of the teams worked hard to attract business, whereas others completely ignored their dollar balances. One student suggested that all the subsystems should be open source, and then I could award a prize to the team that built the subsystem other teams used the most. I will probably do this next term.

Some students suggested that the project should have two deadlines: One about two weeks before the end of the term for delivery of the subsystems, and one at the end of the term for a complete product implementation. This certainly would help alleviate the last-minute crunch, but that might not be a good thing. After all, there is something to be said for learning certain lessons the hard way.

Right now, I'm trying to develop more projects that will give students both the skills and the savvy to succeed in our industry. If you have ideas about how to construct a good project for this type of course, please let me know about them. Remember: Anything we academic instructors can do to make our courses better will ultimately help you -- when you hire the software engineers we train.

In future columns for The Rational Edge, I'll be exploring more about the marriage of theory and practice. Some months I'll focus on the significance and implications of new technologies and techniques. Other months I'll talk about how we, in academia, are preparing students to meet the challenges they will face in the "real" world -- and how they can add value to the companies that will employ them.

Back to top

Notes

¹ See http://www.cs.wpi.edu/~gpollice/cs4233-a03/Project/Vision.html

² See http://www.cs.wpi.edu/~gpollice/cs4233-a03/Project/Stakeholders.html

³ The Singleton design pattern guarantees that just one instance of a class exists. See http://www.patterndigest.com for a description of the Singleton pattern and others mentioned in this article.

⁴ The template and marketing presentations can be found at http://www.cs.wpi.edu/~gpollice/cs4233-a03/Project.html.

⁵ I doubt whether any of the teams actually had to deliver on these promises, but they at least thought about the support issue.

About the author

Gary Pollice is a professor of practice at Worcester Polytechnic Institute, in Worcester, Massachusetts. He teaches software engineering, design, testing, and other computer science courses, and also directs student projects. Before entering the academic world, he spent more than thirty-five years developing various kinds of software, from business applications to compilers and tools. His last industry job was with IBM Rational Software, where he was known as "the RUP Curmudgeon" and was also a member of the original Rational Suite team. He is the primary author of Software Development for Small Teams: A RUP-Centric Approach, published by Addison-Wesley in 2004. He holds a B.A. in mathematics and an M.S. in computer science.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Notes
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers