Notes on Project Selection for Project-Based Software Engineering Classes

Michal Young University of Oregon v0.2, 2009-11-18

specication or with rapid prototyping, but it is more important to understand why the value and appropriateness How should one select a project for a project-based so- of formal specications and rapid prototyping dier from ware engineering class? What additional criteria apply to project to project. a course in which instruction and student teams are distributed across institutions, cultures, and time zones? In this short note I attempt to describe criteria I have used Encourage continued learning. No course or sequence for the simpler case of a conventional project-based so- of courses will convey the whole breadth of soware enware engineering course, and how those criteria might be gineering knowledge. A calculus sequence or a compilmodied and augmented for the more dicult case of a ers course can at least convey a basic knowledge sucient to solve certain well-dened classes of problems. e best distributed course. we can realistically hope for in soware engineering is to provide students with motivation and intellectual tools to 1 Introduction continue to learn from experience in the eld. Providing students with intellectual tools is why the project should A course project is a vehicle for teaching, so we begin by illustrate principles. For motivation, it is essential that stuconsidering pedagogical goals. dents see value in those principles: ey should perceive that they can solve problems that could not solve previIllustrate principles. Ideally, the project experience ously, just as a student in a calculus or compiler construcshould illustrate to students the principles that the course tion course perceives that they are solving problems that is designed to teach. If the project is distributed, the por- they could not have solved without grasping the content tions undertaken at each site should illustrate those funda- of those classes. mental principles, as should the distribution of portions to It is easy enough for a calculus instructor to devise sites. We must distinguish between illustrating principles mathematics problems that a student has no chance of and providing practice in skills. While both are desirable, solving without calculus, but can easily solve by applying the former is essential and the latter must sometimes be techniques learned in that class. e instructor of a comsacriced. For example, it is essential to understand some piler construction course can likewise devise a project that, fundamental principles of project management, such as though quite straightforward, would be nearly impossiprocess visibility. It may be useful to learn some particular ble to tackle without an understanding of lexical analysis, soware process model, such as a spiral model or scrum, parsing, and related techniques. e student in a combut that is much less important than understanding that piler construction course never says we could have imsoware process models address a set of common prob- plemented a more complete compiler, and done it faster, lems. It is useful to have some experience with formal if we werent required to produce a well-formed grammar 1

Abstract

le. In soware engineering, on the other hand, there is a signicant danger of asking students to perform tasks that appear to them as impediments rather than aids to their progress. e absolute worst outcome of a soware engineering project class is that students perceive soware engineering as a set of bureaucratic practices that, though oen required, slow soware development and suck the fun out of it. Considering this danger, we must rene the rst criterion above, which is that a soware project should illustrate principles to be taught in a class. It must illustrate those principles in ways that expand rather than limit what students can accomplish. Above all we must avoid asking students to apply techniques that are inappropriate to the projects in which they are engaged. For projects that t in a single academic term, this will usually mean producing fewer and shorter documents. Even if we must sacrice some things that we would like students to know at the conclusion of a project-based course in soware engineering, it is more important to leave them with the conviction that applying and expanding their knowledge of soware engineering is a worthwhile pursuit throughout their professional career. Facilitate grading. Other things being equal, we desire projects that facilitate not only teaching soware engineering principles, but also objectively measuring the extent to which those principles have been grasped and applied. In other words, we would like to be able to assign grades in a way that is fair and valid. e larger the class, the more important it becomes to also make grading ecient. Unfortunately, requiring students to apply soware engineering techniques only when they are actually useful may make grading harder. One cannot, for example, grade an extensive requirements document or design document separately from the soware product. It sends exactly the wrong message if a student can better his course grade by, for example, producing an elaborate set of requirements that are not met by the product. In fact, if it is possible to produce a better product faster by some approach that deviates from the approach prescribed by the instructor, then we must consider that deviation an improvement rather than an error. e solution to this conundrum, I believe, is appropriately dening the soware product to be delivered by stu2

dent teams. e instructor can suggest students write precise requirements and interface specications before coding, but grading cannot depend on this sequencing (except to the extent that it aects other groups in the case of a collaborative project). e instructor can, however, insist that the delivered product be suitable not only for use, but for extension and modication by future teams of developers. What follows. In the remainder of this note, I discuss attributes of student projects that, in my view, make them more eective in illustrating soware engineering principles and encouraging continued learning. Each section rst considers the attribute generically for soware engineering project courses, and then separately discusses additional considerations for distributed soware development (DSD) courses in which soware teams are distributed across institutions, perhaps in dierent cultures and time zones. I do not discuss grading further, but assume that any project is to be delivered in a form suitable for further development.

2 Coolness
While students may be motivated by many factors degree requirements, grades, future employment prospects, etc. they engage most deeply in a project class when they nd the project inherently cool. In addition to putting more sustained eort into a cool project, their greater degree of engagement makes them more active learners who absorb more of the content of the class, especially but not only as it is directly applicable to their project. A project can be cool because it oers students a chance to learn and apply some new, popular technology (and can become uncool if it uses technology that students perceive as pass or already well-known by them). For example, in 2009 smartphone soware frameworks are cool, while typical database-backed web sites are generally uncool by the time students reach a senior level project course (though they can still be cool projects in an introductory database course). A project can also be cool by virtue of the application domain. While a discrete event simulation of a physical system may be technologically almost identical to the physics engine of a video game, the context of the game

makes the physics engine cooler than the simulation in a dierent context. Social import also contributes to the coolness of a project. Reimplementing a product that will not actually be used by anyone reduces the coolness of a project. Having (at least potentially) a real user increases coolness, and having a potentially positive social impact increases coolness signicantly. us, building a product that will be used by the local public library is more appealing than building an application that will be used by a local convenience store, but building an application that might actually be used by the convenience store is more appealing than building an application that will denitely not be used by anyone. Building an application that will help blind or handicapped persons use the local library is better yet, but may not be enough to overcome the uncoolness of totally boring or obsolete technology. Association with charismatic organizations may substitute for social impact. An application that might actually be used by (or compete with) Google or Amazon is almost as cool as an application that might actually be used by blind wheelchair users. Oen a student project is a part or revision of a larger project. It is important that student teams be able to identify their own meaningful contributions to the product. Even if they have revised a Google application that helps blind wheelchair users access public libraries, they will not be strongly motivated if they cannot show their friends and family what the application does now, with their revision, that it did not do before. Considerations for DSD A project for distributed development must be cool for each participating group. Perceptions of cool technology and charismatic organizations may dier between groups. For example, Microso may be a charismatic organization for one group and not for the other. Moreover, no group should feel that all the fun and challenging parts of a project belong to the other.

soware engineering issues. e most disastrous project choice I have made in a soware engineering course (circa 1995) was an engine for a exible, programmable data ow analysis engine, treating data ow analysis as a generic graph transformation problem (by making no inherent distinction between edges and attributes, or nodes and values). I hoped my undergraduate students would produce a rst prototype of a system that would evolve into a research project, and I had convinced myself that the programming challenge was modest (as it could have been, had they understood what they were building). What I did not anticipate was that my undergraduate students, who had taken only a very basic compiler construction course, would be completely perplexed by data ow analysis, and further lost because the project required viewing ow analysis dierently than the way it was presented in compiler textbooks. I had imagined that I would sketch it for them in a lecture or two and then move on. Few, or maybe none of the students ever really understood what they were building. My generic ow analysis project would not have been such a disaster if my students had merely failed to produce useful implementations of the system I had asked them for, but they spent the whole 17-week semester struggling with the concept, ignoring all the soware engineering that I was attempting to teach. Teamwork was a mess. Modular structure was a mess. Project schedule and management was a mess. Most of the projects were complete failures. A couple teams managed to implement something, more or less oering up snakes and tree trunks as approximations of the elephant I asked for. Lesson learned: Background knowledge required for a project must be limited so that it does not become the topic of the course. It helps a lot if students can imagine what a successful project outcome would be without any explanation beyond a brief description.

Since my great disaster I have made it a rule that the short project description that I provide students must be enough to convince them of its coolness. If they are not able to immediately grasp both what a system is for and 3 Modest Technical Challenge how it might work (on at least a conceptual level), it is not While some technical challenge is necessary for coolness, suitable for a course whose real topic is soware engineerexcessive technical challenge risks stealing attention from ing. 3

Considerations for DSD Students in dierent institutions may have varying backgrounds. We could to some extent exploit those dierences, giving one group parts of a project for which only they, and not the other group, has appropriate background to tackle. is would have the virtue of simulating one of the main reasons that real soware projects are divided among geographically distributed teams. However, the danger of being distracted from soware engineering issues seems no smaller in a distributed environment than in a conventional course, and in general it seems wise to prefer a project that all groups fully understand.

constructed rst and then iteratively enhanced up to the end of the academic term. is is partly a requirement for the instructor in devising the project, but should also be an explicit goal of student teams. Students should understand that some modular structures are more suitable than others for expansion and contraction [1]. Considerations for DSD Just as a scalable project is partly a risk control strategy for a conventional soware project class, in a distributed project course we will need to use the scalability of a project to guard against team members at one site being too handicapped by slow or incomplete work at another site. It seems reasonable to design a project such that only the minimal core functionality produced at one site is really necessary for satisfactory completion of the project at another site, and moreover for each sites core requirements to be demonstrable without dependence on the other. It is less clear how separable the additional increments of functionality should be. My current thinking is that enhancements beyond the core at site A should depend on the core functionality at site B and vice versa, but it is best for enhancements at each site to have minimum dependence on the other. If there is a suciently small core (or a microcore, by analogy to a microkernal of an operating system), a version of it may be prepared in advance by the instructors and either provided as a starting point or held in reserve in case of insuperable problems at one site or another.

4 Scalable Challenge
Student development groups may vary considerably in ability and background, particularly if self-organized. Moreover, if a project is being done for the rst time, it can be dicult to accurately predict how much eort and expertise it requires. To avoid the twin risks of a project that is insuciently challenging for strong teams or insurmountably challenging for weaker teams, it is best to devise a project that can accommodate many levels of diculty, creativity, and achievement. A scalable project should have a core part that can be successfully completed by any reasonably competent student team with a moderate level of eort. Also, if the instructor has miscalculated the diculty of some parts of the project, at the least the core should be free of unpleasant surprises. e core part should be described in sucient detail that students can produce an acceptable implementation without requiring much insight or imagination. us, every team can experience success if they expend reasonable eort and apply a certain level of soware engineering discipline (e.g., planning and monitoring progress). A scalable project should also provide ample opportunity for strong teams to go well beyond the minimum requirements. Good teams should challenge themselves, and great teams should produce something very rewarding. ere should be room for increasing levels of creativity in designing features beyond the core requirements. e core system and enhancements should be designed in a modular fashion, so that an acceptable core can be 4

5 Summary
A project for a project-based soware engineering course can be an important factor in whether the course is dull and convinces students only that soware engineering is something to be avoided or endured, or whether students internalize some foundational principles and then construct a richer grasp of the eld over the extent of their careers. A good project is a vehicle for illustrating soware engineering principles, in a way that demonstrates their value and encourages continued learning. Students learn most eectively from a project they are enthusiastic about, and learn more from success than from failure. A project should therefore be cool, present modest tech-

nical challenges, and provide incremental reward for each increment of eort and creativity. Acknowledgments Stuart Faulk noted that the decomposition of a distributed project must be done in a manner that meets all the constraints (relation to principles taught, scalability, etc.) at each site and not just overall. Preparing a microcore solution to reduce risk was also Stuarts suggestion, addressing a concern raised by David Weiss.

References
[1] D. L. Parnas. Designing soware for ease of extension and contraction. IEEE Transactions on Soware Engineering, SE-5(2):128138, Mar. 1979.