SUPPORTING LARGE PROJECTS IN A SMALL COLLEGE COMPUTER SYSTEMS MANAGEMENT PROGRAM Ellen L. Walker and Oberta A. Slotterbeck Computer Science Department Hiram College Hiram, OH 44234 {walkerel,obie}@hiram.edu ABSTRACT Many large universities have the luxury of well-developed computer science and software engineering programs that include team projects at several levels, from group work in an introductory data structures or software engineering course through a multi-course team project for an external client. In this paper, we will discuss our computer systems management curriculum that exposes students to large software engineering (analysis, design, programming, and user interface) projects within the time and budget constraints of a typical small college program. In the curriculum, we have two courses where students do full group design and analysis projects, Database Design and Systems Analysis. Other courses emphasize specific aspects of the software engineering process that tend to be impossible to experience in a limitedterm project. Finally, we have a capstone course where students use all that they have learned to develop systems on their own. Students are responsible for all phases of the capstone project, from recruiting a client and specifying the project through delivery, documentation, and client evaluation. 1. INTRODUCTION Software engineering is the process of designing, building, and maintaining large software systems [2]. Most useful software systems are too large and too involved for students, even working in groups, to complete within the bounds of a single semester. Yet we are required by the constraints of our curriculum to break students educational experiences into semesterlong chunks. Many large universities can work around these constraints by incorporating multiple team projects and even allowing for development classes that work on projects for multiple terms for external clients [1]. While working with real clients is the most realistic possible project type, client management takes significant time and effort on behalf of the faculty and staff of the course [4]. In our program, we have the constraints inherent in small schools: limited faculty, no graduate assistants, relatively limited laboratory facilities, and classes that are taught on a twoyear rotation; yet we want to provide our students with useful and realistic software engineering experiences. Our program has the additional constraint that it is geared toward non-traditional students who work during the week and take classes only on weekends. These students are working towards a Computer Systems Management degree, which is less programming-intensive than a traditional Computer Science or Software Engineering degree and includes significant coursework in Management and Communications. Because the degree is aimed at future
managers of technology, it is very important that the students fully understand the complete system development life cycle, from requirements elicitation through software maintenance in as realistic a manner as possible. To do this, we have developed a curriculum that includes three types of project-oriented courses: those with full team projects, focused courses, and a capstone. Students do full team design and analysis projects in two courses: Systems Analysis, and Database Design. In Systems Analysis, they specify a software system to satisfy a (hypothetical) client s needs. The hypothetical situation is set up as fully and realistically as possible. In Database Design, they develop a database to meet an on-campus client s needs. For both of these projects, the students work in teams of 4-5 students and deliver their results in a phased manner. However, it is not possible to fully complete the development process in a single onesemester class. Therefore, we have additional focused courses that emphasize areas that are generally not allocated much time in the team projects. These include software evaluation (of existing packaged software), project management, verification and testing, and interface design. In these courses students work on both focused complete projects and projects that fall within a larger context to connect the focused courses to the broader systems development cycle. Finally, every student is required to perform an individualized capstone project, which must be specified and formally proposed, implemented, delivered, and evaluated by the student. Students present the results of their capstones orally, as well as delivering a written paper. The remainder of this paper will discuss our courses, with emphasis on the project requirements in each. Full-semester project courses will be discussed first, then focused courses, and finally the capstone. 2. SYSTEMS ANALYSIS Because the computer systems management curriculum is not programming-oriented, the emphasis in this class is not on the implementation of a system, but on the analysis and design needed to solve a business problem. Students work in teams of 4-5 students to specify a software system to satisfy a client s need. All teams in the class are given the same scenario, which is purposely too big, too complex, and too vaguely specified for any team to tackle completely within the given time frame. Therefore, students must use the skills that they are learning to determine what type of system can be developed within the scope of the class to satisfy the customer s needs. 2.1 Problem definition Some of the materials provided by the professor were a high level description of a problem encountered by a department in a hypothetical company, sketches of the personalities of the major players which could impact possible solutions to the problem, memos and meeting notes from the various players about the problem, and information about the client requesting a
solution with reasons for concern.. There was enough material that each team could, and in fact did, solve the problem in different ways. The first encounter the teams had with the material required pairs of teams to act in a role-playing fashion, once as the client and once as the system analysis team. These sessions were used to help both teams clarify the problem and provided a first pass on drawing up a Problem Definition Report. A feasibility analysis and a project plan were not required because they were covered in the Project Management course. All students were exposed to some general principles and guidelines in class about these topics. 2.2 The phases of the project The project was broken down into three phases, with a deliverable and a team presentation after each phase. Phases ended two weekend classes apart, which allowed about a month for each part. One of the first deliverables was the Problem Definition Report. As was expected, the major difficulty that teams had was in limiting the project scope and setting constraints. Class presentations by the different teams highlighted this and created many scope revisions that helped with the later work. The second phase of the project concentrated on modeling the existing system. Because businesses in our area are just beginning to shift to object-oriented analysis and design, both traditional and object-orient modeling methods were introduced to the class. Interestingly, most of the teams chose to follow an object-oriented approach, perhaps because the first programming experience for most of the students was with an object-oriented language. The second deliverable was a model of the existing system. Again, pairs of teams worked together in client-analysts roles to clarify that the modeling made sense before class presentations by each team were made. All of the students were struck by the diversity exhibited in this phase, even though the different models were essentially capturing the described system. The final deliverable had to include three models of proposed systems with one being described in detail with appropriate charts, diagrams, dictionaries, etc. Although costs were not emphasized, the models were supposed to be an expensive, a moderate cost, and a low cost model. Most of the teams again chose to do object-oriented design techniques. 2.3. Difficulties encountered Students on a questionnaire administered at the end of the class spoke positively about the experience. As we have found repeatedly with our weekend college students, one of the major difficulties was communication between team members. Many of the teams met in restaurants central to each of their homes, came before class or stayed after class, and, of course, used instant messaging and email extensively. Surprisingly, one of the teams that did the poorest in the class was one made up of traditional students living on campus! This anomaly can only be attributed to the personality of the students.
3. DATABASE DESIGN In database design, students work in groups to solve database problems posed by members of the college community, but not members of the computer science department. Recent projects have included: a database to track internships for the psychology department, a database to track information about gravestones for a research project, a database to track community service of students and other campus constituents, and a corporate contact database for the development office. These projects were carried out by groups of students (generally 4 or 5 students) who were assigned to the project by the instructor. One class was assigned based on the students; in the second class the students were assigned based on project preferences. Both assignment methods worked well, although some groups had difficulty finding times to meet because of incompatible work schedules. This information will be collected and used for group assignment in the future. 3.1 Client recruiting The professor recruited clients based on an all-campus email solicitation. In this email, it was made very clear that the results would not be guaranteed, and that the client would be expected to make him or herself available to the group for frequent discussion and evaluation. Even so, more potential clients showed interest than were needed for the projects. Interested clients were asked for project descriptions that were reviewed by the professor. The main goal of the review was to determine that the project was appropriately sized for a group of beginning database students to complete a reasonable prototype within a 12-week period. In most cases, the projects were more ambitious, but that wasn t considered a reason to abandon the project. Instead, prospective clients were made aware that students would be discussing priorities with them. In one case, the project was too simple and straightforward to be appropriate for a database implementation. The professor worked with this client to beef up the project description to the point where it would be appropriate for the class. In retrospect, the client found that the beefed up database was of more use to her than her original proposal. In general, clients have been very available to our students. We did, however, have one case where a group s direction had to be changed because the primary client realized early in the semester that he didn t have sufficient time to work with the group. The same client had proposed a project that was too large and constantly growing. Luckily, an alternative somewhat related project was available for the group, and the problem was discovered early in the semester so they were able to shift projects. 3.2 Structuring the Project The database project was very strongly structured based on materials from Arizona State [3]. Each project was a complete database, delivered on the group s choice of platform. Deliverables included a requirements document accepted by the group and the client, data models (ER and relational), proof of normalization, and relevant queries in both SQL and
Relational Algebra, in addition to the database itself and complete user-level documentation. Most groups chose Microsoft Access for their platform, but one group whose client wanted a strong web presence delivered their project using Microsoft SQL Server and a website based on ASP. Our class met for seven alternate weekends, and the project had three sets of deliverables. During weeks 2, 4, and 6, preliminary deliverables were submitted for feedback, and during weeks 3, 5, and 7, final deliverables were submitted for grading. Week 7 s final submission included a panel presentation for each project to which the external clients were invited. Students were asked to present the data model, to demonstrate the project and also to reflect on the project s development. What would they do differently if they were to start over? What would they do next if they had more time? 3.3 Limitations of a 12-Week Project Naturally, during a 12-week project, students don t have nearly enough time to complete and deliver a production-quality product. Not only are they held back by the short timeframe and the limited amount of effort that can be devoted to one class, but they are also learning the concepts of database design and implementation just in time for the delivery. For example, they study ER diagrams one week and deliver their ER diagram the following week. Similarly, normalization and SQL are studied just one week before students must deliver the relevant aspects of their projects. The clear advantage to this is that students immediately see the relevance of each new topic they learn to an ongoing design project in which they have a significant emotional investment. But the disadvantage is that students are limited to doing their development in lockstep with the class. They can t adapt their project schedule to their life schedule because it really isn t possible to get ahead, even if they have extra time to devote one week. Another slight disadvantage is that the students don t have a lot of time to reflect on and assimilate their new knowledge before they apply it. In the database projects, the portions of development that get extremely limited attention are the user interface and testing, both functional and user interface. Because students don t have enough background to finish the project until the last two weeks of the term, they are implementing the basic functionality at the end of the term. While all teams are asked to demonstrate their projects to their clients before the third and final deliverable, only the best teams have full functionality before the last few days before delivery. Also, because of the client recruiting process, students don t get the full brunt of the requirements elicitation phase. By the time the students meet their client, the professor has already worked with the client to make sure the project is close to the right scope, and that a database is the appropriate implementation for this particular need. 4. FOCUSED COURSES Focused courses involve students in only one aspect of the software engineering life cycle. While students still do some project work, it is necessarily of a much smaller scope than the projects in Systems Analysis and Database. When possible, we try to present the project
within a larger scope, or connected to another project. Each of these courses is presented in an intense, 3-weekend format. 4.1 Interface Design The user interface is one of the aspects of a database or other software system for which there is little time at the end of a one-semester project. Our Interface Design course focuses on the design, prototyping, implementation and evaluation of user interfaces. The course has two projects, both web-based. The first was an interactive web site, done individually. Deliverables included a user profile, a paper prototype for in-class walkthroughs, and an implementation, and a report of user testing. The second was a front-end to an existing database. Each student team was given a database and a client profile, and asked to develop an appropriate front-end for the specified client, using the JavaScript and PHP that they had learned. These databases were demonstrated in class and evaluated by the other students. The first project was designed to take students through all steps of a user interface development project, from specification of the client s needs through evaluation. The second project was designed to emphasize to the students how an interface design could fit into the framework of a larger project. We had originally hoped to use student-developed databases from a prior database class, but the plan failed for both technical and administrative reasons. Instead, we hired a student to develop simplified databases specifically for the interface class. 4.2 Project Management Project planning is another aspect of system development that doesn t easily fit into a one-semester project. In this course, students investigate management issues of large projects and project planning techniques. Teams of 4-5 students design a Project Plan for one of two scenarios, the design of an automatic advising system or a web-based registration system for a small college. Student teams deliver their plan with both a class presentation and a paper on the last weekend. The emphasis was on feasibility assessment and teams were required to include a costbenefit analysis, a SMART analysis, and a risk analysis to a proposed solution to the chosen project. The project description included a work breakdown structure for the project, using MS Project, either function point or a COCOMOII analysis of projected costs, and a discussion of ramifications of the critical path produced by the MS Project software on team construction and configuration. The next time this course is taught, the plans are to use the Problem Definition Reports from the Systems Analysis course. Some students who had the Project Management course first provided Project Plans for their System Analysis proposals so there was some cross-fertilization between the courses. We hope to make this more structured in the future. 4.3 Testing and Verification
Testing and verification is another phase that is rarely allocated time in a one-term project. Like interface design, we teach it in a focused course, asking students to perform testing and verification on requirements, specifications, and code that was developed earlier. The original plans for this course were to introduce some automated testing software such as Rational Suite Teststudio, but the short timeframe of the course did not permit both introduction of new software and general testing concepts. Instead, one assignment was to investigate automated testing tools, writing a position paper justifying the purchase of one of three competitive tools chosen from a single category. Many students evaluated trial versions of their software. At the end of the course, several students said they gave their position paper to their actual supervisor and, in some cases, the recommendation was acted upon favorably! Additionally, students were given small, intense experiences designed to push the theme that testing before coding can find many errors and to emphasize the need to plan for testing as part of design. Representative exercises included the following: 1) Using the requirements specified in a System Analysis Problem Definitions Report, test the proposed system design using a mock walkthrough; 2) Given the requirements as specified to a data structures class, perform black box, dynamic testing using executable images of the code written by students in the class; and 3) Given requirements for a piece of code and a copy of the code, perform a formal review of the code. Anecdotal evidence gleaned from comments of the students and a questionnaire administered at the end of the course, showed that the students had experienced a major shift in their attitudes towards testing during the course. While a pre-course questionnaire indicated that most students thought testing was easy and was performed to prove software worked, a postcourse questionnaire clearly showed that students found testing to be more intricate than they had suspected and that the major goal of testing was to expose errors. 4.4 Software Evaluation While the majority of our courses focus on software or system development, it is also important for our students to be prepared to incorporate existing software into their systems as needed. In our software evaluation course, we have asked students to describe a (small) business problem and to evaluate several competing software applications that might address this problem. For example, a student might look at multimedia software for enhancing a commercial web site. The students develop both functional and non-functional requirements, rank them, and then evaluate each package based on the requirements. In addition to the small evaluations, we looked at two larger examples as a group: evaluating a software development environment for our introductory classes, and evaluating a college-wide information system for our campus. The software development environment evaluation was done as a full-class role-playing exercise. The project manager for our college s real selection process presented the college-wide information system decision as a guest lecture.
This provided a window into a much larger-scale evaluation than we could have easily done otherwise. 5. CAPSTONE The third pillar of our complete program is the capstone course. In this course, students are required to specify, implement, and evaluate a complete system of their choosing, using both their technical and management-related skills. While it is not required, most capstone projects are similar to the large projects students do in either Systems Analysis or Database. For a Capstone project, however, we require more technical depth and more of an evaluation component than we do for even the longer group projects. Although many software engineering capstones are group projects, our capstone is an individual project for several reasons. First of all, nearly all the other projects that students do are group-based, so this gives each student a chance to try something on his or her own. Secondly, most of our students work full-time, and we encourage them to find capstone projects that will be supported by their employers. Since few of our students work together, these projects work best if done individually. Finally, the individual capstone project ensures that every student has at least one project for which they contributed to all aspects of the project. Often, what the student proposes as a capstone project is a component of a larger project. This is particularly true of projects that are done in the course of employment. One student developed a database for inventory as part of a larger inventory management system. Another developed web and database materials to help one part of the company implement six sigma quality strategies. Other projects are based on individual needs. A manager in one company developed a system to help her track the training of her reports. Other students develop projects for their own or others small businesses, for example a database and website for managing a dog breeding business. This year, two of the four database projects will be extended by capstones as well. One project, which involved tracking students observations of biological phenomena, was extended to let students take a PDA into the field, record their observations and report them to the central database. Another project, which tracked schedule information, will be integrated with additional information from the college s enterprise administrative system. The capstone project involves a formal proposal, implementation, evaluation, paper and presentation. Students are required to propose methods of evaluation before they can begin the project. They are encouraged to phase their project along the lines of the structured projects they have done in Systems Analysis and Database, and most do so. We have been pleased to see students demonstrate their mastery of techniques from their other courses when they present their capstones. In fact, in nearly every case, a capstone presentation is a celebration of what a student has learned. While students work very hard on the capstones, they often surprise themselves with how much they have accomplished, when forced to look back and evaluate what they have done for the presentations. Informally, feedback from the students has been that the variety of group and independent projects in all of their courses has been instrumental in their ability to carry out their capstone projects.
6. CONCLUSION Although we are a small college and cannot mount major multiple-term projects, we have been able to develop a curriculum that through one-term projects and focused courses provides students with the skills and tools to carry out full-scale software lifecycle projects on their own. Many of these skills are demonstrated by the students in their capstone projects. In the focused courses, we have found that smaller projects that are lightweight but complete (such as the simple user interfaces) can be combined with incomplete projects presented in a larger context (such as the database interface projects) to provide students with a more complete overall picture of the software development lifecycle. 7. ACKNOWLEDGEMENTS This material is based on work supported by the National Science Foundation under Grant No. 9952749. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation. REFERENCES [1] J.A. Preston, The Real World Lab: A Software Engineering Practicum, 1998. Online Internet. http://www.cc.gatech.edu/classes/rwl/web/rwl_description.html, [2] I. Somerville, Software Engineering, 5 th ed., Addison Wesley, 1998. [3] S.D. Urban and S.W. Dietrich, Integrating the Practical Use of a Database Product Into a Theoretical Curriculum, in Proceedings of SIGCSE 1997, (1997), 121-125. [4] J.C. Williams, Moderator, Client Sponsored Projects in Software Engineering Courses, in Proceedings of SIGCSE 2003, (2003), 401 402.