Lessons Learned from Teaching Software Engineering ... - IEEE Xplore

2 downloads 0 Views 27KB Size Report
180 Park Avenue, Room 2C37. Florham Park, NJ 07932 [email protected] Abstract. Teaching provides many challenges. Presenting Software Engineering ...

Lessons Learned from Teaching Software Engineering to Adult Students James Cusick AT&T Labs✥ Shannon Laboratory 180 Park Avenue, Room 2C37 Florham Park, NJ 07932 [email protected]

Abstract Teaching provides many challenges. Presenting Software Engineering to students brings a teacher face to face with a most unwieldy subject. Packaging this subject for delivery to adult students in a continuing education setting has proven both rewarding and difficult. This paper attempts to communicate the specific approach used to teach Software Engineering as part of an applied technology program. The context of the course is presented including the program setting, course goals, and student body composition. The specifics of the course are summarized in outline along with a discussion of the content evolution over a four-year period. Extensive coverage of the project workshop portion of the course is also included. Finally, several “lessons learned” are offered for consideration.

1. Introduction A recent survey of computer professionals found that over half described themselves as “Software Engineers” while at the same time educational requirements for such a field remained unclear [1]. Early in 1993 the Computer Technology and Applications Program (CTA) of Columbia University’s Division of Continuing Education began planning a new course focused on software design, planning, and testing to address the call for software engineering skills. Over the next four years the course emerged as QC1205 Software Engineering and was taught to over 120 adult students. This paper details the development of the course, its content, and the lessons learned through teaching this subject to this population. Software Engineering education as a whole has matured during the time this course was developed. Initially, fewer references were available on Software Engineering as a subject. Today, most Computer Science departments offer a Software Engineering course at both the graduate and undergraduate level. Recently, Software Engineering education has been the subject of continuing debate [2][3]. However, it remains rare to see this subject offered in a continuing education setting. Experiences with QC1205 at Columbia suggest that offering such a course can provide an important missing element to an applied technology education.



The author is also a part-time instructor at Columbia University’s CTA Program.

2. The Setting The CTA is a four-semester, non-credit, “certificate” program offering specialties in Software Development, Relational Database Design, Business Applications, Network Management, and more. The program concentrates on the development of graduates possessing highly competitive skills in these areas. Graduates go on to positions in development departments of major corporations, government agencies, and software houses. Entrance requirements include an undergraduate degree, a passing score on the CTA entrance examination, and more. The student body current enrolls over 500 students per term. 2.1 Software Development Specialty QC1205 was first offered as a seminar series and later as an elective. In 1995 the course was converted to a required course in the C/C++ Software Development track. Students in the programming track currently take the following courses: Programmer’s Guide to Operating Systems; Introduction to C/C++ Programming; Data Structures and Intermediate C/C++; Software Engineering; GUIs and C/C++ Applications; Object-Oriented Programming I; Application Development Lab in C/C++. Electives vary but may include: Object-Oriented Programming II; Advanced GUI Programming in C/C++; Smalltalk Programming; Java and Internet Programming; and Fundamentals of Unix Operating System. 2.2 QC1205 History & Goals Within this educational program QC1205, at its core, attempts to teach students to recognize an engineering task and respond to it with an appropriate, standard technique to produce high-quality software artifacts. Initially conceived as a lecture series on topics in Software Engineering, the course attempted to cover the history and current practice of the field in a platform-neutral manner. As an elective the course was expanded to include both breadth and depth. During this period students from any discipline (database, networking, etc.) were free to take the course. As a result, the course philosophy remained platform neutral and to a large extent de-emphasized implementation issues. As one can see from this curriculum, this track is highly applied and offers little theory or specialty topics. The principle goals of the Software Engineering course in this track is to 1) provide students with a context for using their programming skills in an engineering environment, 2) support the development of their problem solving structure in preparation for advanced software construction laboratories, and 3) provide a professional vocabulary, a broad understanding of the field’s techniques and technologies, and the interrelationships among them.

3. The Students This paper owes much to the energy, enthusiasm, and hard work of the students of QC1205. To oversimplify, three types of students take QC1205: Students; Career Changers; and Technical Tune-ups. The Students in the course come from many disciplines both technical and non-technical and seek additional computer skills or general knowledge (see Table 1). Career Changers typically have strong professional experience and have decided to transition full time to computer related work. The Technical Tune-ups represent mature and experienced programmers, analysts, and managers, looking for the latest technical knowledge to enhance or prolong their careers.

Characteristic Class Size Median Class Size Gender Age Range Median Age Education Level Professional Experience Software Skills

Value from 6 to 36 16 90% Male; 10% Female 22 to about 45 about 30 MS 5-10%; BS/A ~85-90% from 0 to 25 years from minimal to expert

Table 1: Class Profile During the student introductions of each new class it was astonishing to discover the variety of professions drawn to the CTA program. The following list shows professions and educational backgrounds of some of the QC1205 students: ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

Aeronautical Engineer Bartender Bio-Engineering Researcher Book Editor Construction Manager Database Administrator Electrical Engineer Financial Analyst Graduate Student Internet Specialist

ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

IS Manager Mechanical Engineer Musician Network Administrator Nuclear Power Technician Programmer QA Specialist System Administrator Undergraduate Student

One impact of teaching this variety of students includes a heightened need to explain the material in clear and jargon-free terms whenever possible. At the same time it is often possible to communicate with a subset of the class at a high level of sophistication. More than once students provided additional details or corrections to the lecture material. A final characteristic of these students that is critical to designing and running a course for them is that they can only afford to be students when they are in the classroom. Normally, they are working, or commuting, or parenting, or caring for an elderly parent, or countless other tasks and labors of love which night school students must engage in. In response to this QC1205 was run in a highly flexible manner and every opportunity was made to accommodate special needs.

4. The Teachers Several instructors taught all or part of this course. So far, each instructor has been a practicing software professional with prior teaching experience, mostly of programming or other technical subjects at a university or in a corporate setting. Each instructor has come from a different emphasis, including Artificial Intelligence, Object Technology, and Software Metrics.

5. The Content Early work in defining educational requirements for QC1205 suggested content covering management, engineering principles, computer science, communication skills and a project laboratory [4]. Recommendations from the SEI confirm this path [5]. QC1205 Software Engineering consists of 12 to 14 lectures (equaling approximately 30 lecture hours), 2-3 exams, 1-2 dedicated laboratory sessions, and weekly workshop sessions. Each CTA course normally meets over a 16 week period. A typical lecture outline follows below: • • • • • • • • • • •

Software Engineering: Past, Present, & Future Software System Engineering, Analysis & Specification Structured Analysis and Structured Design Object-Oriented Analysis and Design Objects Concluded and Human Factors Engineering Languages, Implementation, and Tools Testing and Quality Assurance System Testing & Reliability Software Development Management Primer Software Metrics & Process Engineering Software Maintenance and Other Topics

5.1 Course Pack and Tools Students were provided with a student guide that contained most of the view-graphs used in the course. Similar to many professional training packages, this student guide proved very popular with students. The guide reduced the amount of note taking required and created better notes since they were tied to prepared visuals and example problems. In addition to the student guide, readings were assigned from the text “Software Engineering: A Practitioners Guide” by Roger Pressman [6]. This text proved much less popular with students. It is possible that the text represented a significant change from their typical computer reading which tended towards the programming tips and tricks genre. To supplement the text a half-dozen selected articles on advanced topics were distributed but were not required reading. Finally, a CASE tool was deployed to support the design and documentation of project assignments. The tool was ParadigmPlus™ from Platinum. This tool supports many ObjectOriented Methodologies, reverse engineering, and code generation. Students were trained on the basic operation of the tool at roughly the same time they were instructed on Object-Oriented concepts and techniques. Typically, a small group of students would employ the tool in their projects. Others would use design packages from other sources.

6. Project Laboratory The project laboratory is the most critical part of the course. The focus of the course is on multi-developer software development environments and techniques. Most students have little experience in such a setting. Research suggests it is most important to their career [7]. Finding their way toward meeting fuzzy deliverables crystallizes their appreciation for the techniques and theory presented in lecture. Early versions of the lab used role plays including customer, manager/systems engineer, programmer/analyst, and test engineer. The customer role play was dropped and replaced with

an engineering department model where the teacher represented the customer and a multiproject manager simultaneously. Several customer contracts are then pursued to explore product development projects where the students provide the development teams. The students get the feeling that they are on a real project. The course is designed to address the technical needs they encounter during the project on a Just-In-Time-Training basis. When they begin they are normally very confused. By the end they have selectively learned what they need to succeed with the project. 6.1 Mechanics of the project laboratory The lab is divided into three parts. The students deliver, in order: a) requirements; b) detailed design and initial prototype; and c) final prototype with plans for full-scale development and test. Only one lab assignment is provided at a time allowing them to focus on immediate tasks. The class is randomly divided into groups of 3 or 4. Team leaders have been appointed and also self-organizing teams have been attempted. Both seem to work well but selecting leaders from a class of 20 without full knowledge of personalities remains a challenge. Personnel changes to teams during the course are expected due to students dropping the course, joining late, or occasionally having difficulty cooperating. Similar circumstances occur often in corporate settings so this simply adds more authenticity to the laboratory experience. The types of problems used in the past have ranged from inventory management systems, elevator traffic simulation systems, Internet based project management tools, and collaborative document sharing tools. Approximately 1/3 of each session is devoted to lab work. This eases the burden of teams getting together off-site. A review session is held one week prior to each due date. Each team meets with the teacher/manager for a real-time audit of their work. This simulates actual development practices and allows for last minute adjustments to deliverables. Real projects iterate and so does this laboratory. Requirement and design documents are normally reworked and submitted twice or three times. The prototype is often a source of confusion for the students. They are forced into making implementation choices on Operating System, language, database, etc., which is usually a new experience. Most other classes dictate the environment and language. Generally, students have little or no programming experience and this free-form element can be daunting. Students assume that they need to implement in C/C++. However, this is first and foremost a course on engineering principles and one practical principle is to use whatever works best. Thus, projects have been implemented in many languages and using a variety of supporting technologies. In the end students deliver a prototype that demonstrates the viability of their concept and a pre-defined subset of functionality must be working. 6.2 Concluding the project laboratory On the last day of class we hold a Poster Board session where each team demonstrates their prototype and displays their software design models on a display or pin-up sheet of some kind. Teacher and students listen to a brief overview from each team. This gives the team members practice giving a technical presentation and allows the other teams a chance to see the software that has been created. The project is normally seen as the most difficult and most rewarding part of the class by the students. It is meant to be fun but it is also a serious learning experience.

7. Lessons Learned 7.1 Make it Relevant Students familiar with books such as “20 Minute C++ Recipes” find it difficult to change mental gears to grapple with the fuzzy issues of requirements elicitation, formal design notations, and team dynamics. The relevance of a Software Engineering course to many CTA students is not very clear. The best placement in the curriculum remains a question. One can find research suggesting that more focus on design and economic considerations are needed in technical programs [8]. At the same time one can find research suggesting that Software Engineering should be an advanced semester elective [9]. QC1205 was presented as both an advanced elective in a late semester and as a required course in the second term. Students often commented on the course placement in the curriculum. Those taking it late said they would like to have taken it early, prior to their intensive application laboratories, and those taking it early said they would like to have taken it later since they did not have enough background to assimilate the material. The staff continues to believe that early exposure to the fundamental concepts of analysis, design, testing, and planning are essential. Anecdotal evidence suggests that for many students the material in the course is critical to professional success. Graduates have reported that their work in commercial software houses, financial institutions, and communications equipment providers, for example, has benefited from the content of the course. Others have said that it is impossible to apply many of the techniques discussed in QC1205 since the maturity level of their organization is not high enough to sustain coherent technical policies. The challenge remains to produce a Software Engineering course that clearly bridges the plainly practical with the essentials of engineering. 7.2 Make it Interesting Trite advice such as this is often difficult to follow. One student commented on QC1205’s “endless slides”. In a course like this there is much material to cover but there are limited presentation methods. Code fragments and design exercises help but the laboratories clearly provide the most interest to the students. The lab provides a dynamic, self-directed learning experience where friends are often made and students typically learn more [10]. The rare brilliant lecture moments do not quite compare. 7.3 Hook Them Early, Educate Later This course used to start with project management on the premise that understanding planning and estimating was a prerequisite to taking on a multi-developer assignment. The reality was that students found this irrelevant to their interest in programming and dropped the course. By placing this material at the end and leading instead with Object Technology, Internet Architecture, and then immediately engaging students in lab work, their appreciation for project management was heightened. 7.4 Provide Lots of Examples No matter how many examples were provided in this course, student feedback always called for more. The difficulty of course is to find good, complete examples of large scale

software artifacts. Most such material is proprietary or unsuitable for educational purposes and would require extensive effort to translate into a releasable form. The best possible solution would be to start building a large scale system and evolve it each semester as has been done elsewhere. This would provide a more realistic scale application for students to work on and would bring in other tasks like reverse engineering and maintenance. 7.5 Topics Ring True for 1 of 10 Time and again one or two students would become enthused by a specific topic. Perhaps Function Points, or Object-Oriented Design, or Software Reliability Engineering, would catch their interest. Other students would show little interest at all. In effect, instead of a core of interested students throughout the semester, there would be a floating vitality center in response to the material. The rich variety of this subject normally interests each student but only in a particular area. 7.6 Solutions not Recommendations Students normally look for concrete answers and a firm direction. Software Engineering ought to prepare them for work in which there are no concrete answers and in which they need to develop their own direction. While the lectures tend towards a declarative style the labs opt for more of a discourse in which the students discover their own answers among the choices provided by the teacher. In this way students are never told what to do and build experience exercising their engineering judgment. 7.7 Critical over Comprehensive Content A trade-off must be made between depth and breadth. This course normally provides breadth over depth. Exceptions occur in design methods, testing, and management which are presented in detail. Additionally, the lab forces students to understand a subset of issues in depth. However, since most students have not encountered this material before, it is best to provide the widest possible coverage. Further education, reading, and professional experience will need to fill in the details.

8. Conclusions and Future Directions Current studies indicate that between 70% and 80% of US software developers operate in an ad hoc manner. This means that we are preparing our graduates to act in a skilled manner above the current understanding of most of the jobs they will be entering. Contacts with former students have indicated that about 1 in 3 actually land in an environment where sophisticated design practices are used. Nevertheless, this course can be vital to their professional preparation. With the framework provided in QC1205 students can better understand the technologies they use and better prepare for the construction of their own products. The trend in US software development is toward more process and better development techniques. This course gives CTA graduates a competitive advantage in the face of such a trend.

9. Acknowledgments Many people helped in the development of this course. Bruce Tetelman, and Carl Bonomo formerly of Columbia University, were instrumental in launching the course. Dennis Green and Paul McNeil and the entire staff of Columbia’s CTA Program supported the maturation of the course. William Tepfenhart of Monmouth University, John Eddy of AT&T Labs, and Rich Dragan of PC Magazine Labs, provided invaluable comments on the course after teaching it themselves. AT&T management has always been highly supportive of this effort. The engineering experiences gathered in working on real projects there has been critical to improving the applicability of the material. Finally, the students of QC1205 earned respect and thanks by engaging fully in the challenge of learning Software Engineering.

10. References [1] Buckley, F., “Defining Software Engineering as a Profession”, ACM Computer, August1993, pp. 76-78. [2] Parnas, D. L., “Software Engineering Programs are not Computer Science Programs”, IEEE Software, November/December, 1999, Vol. 16, No. 6, pp. 19-30. [3] Demarco, T., “Point-Counter Point: It Ain’t Broke, So Don’t Fix It”, IEEE Software, November/December, 1999, Vol. 16, No. 6, pp. 67-69. [4] Jensen, R., Software Engineering, Prentice Hall, Engelwood Cliffs, NJ, 1979. [5] CMU/SEI-91-TR-2 Technical Report, “1991 SEI Report on Graduate Software Engineering Education”, Gary Ford, ed., Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, April 1991. [6] Pressman, R., Software Engineering: A Practitioners Approach, 4th ed., McGraw Hill, New York, 1996. [7] Hutchens, D., et. al., “Using Iterative Enhancement in Undergraduate Software Engineering Courses”, Twentyseventh SIGCSE Symposium on Computer Science Education, Philadelphia, PA, February 15-18, 1996, pp. 266-270. [8] Tewari, R., “Software Reuse and Object-Oriented Software Engineering in the Undergraduate Curriculum”, Twenty-sixth SIGCSE Symposium on Computer Science Education, March 1995, p253. [9] McCauley, R., et. al., “Documentation Standards in the Undergraduate Computer Science Curriculum”, Twentyseventh SIGCSE Symposium on Computer Science Education, Philadelphia, PA, February 15-18, 1996, pp. 242-246. [10] Denny, J., & Ashton, P., “Lab-Style Teaching of Computer Science””, Twenty-First SIGCSE Technical Symposium on Computer Science Education, Washington, DC, February 22-23, 1990, ACM SIGCSE Bulletin, vol. 22, no. 1, Feb. 1990.

Suggest Documents