Integrating Software Process in Computer Science Curriculum

Accepted - Frontiers in Education 97

Abstract

Software process - planning, evaluation and modification of development activities based on metrics and measurement - concepts must be integrated into the computer science curriculum if we are to stay apace with the needs of modern software organizations. Software process activities should be modeled after those practices identified as essential to support good software development efforts.

Our curricular goal is to establish a learning environment where process is prominent. We are applying techniques of cognitive apprenticeship to focus on software process in the third course in the computer science major. Students use practices, such as postmortem analysis and measurement-based planning, in gaining control over their development activities. Electronic design notebooks that include pre/post surveys and postmortems on activities are kept for each student. Data from programming projects, collected during postmortems and reviews, are used by the students in planning for next project. By making the development process visible, we hope to make process improvement part of the students' working knowledge in software development.

The structure and material we describe in this paper may be widely useful because they can be piggybacked on courses having a programming component.

Contents

• Introduction
• Process Foundations
• Instructional Foundations
• Curricular Activity
• Conclusions
• References

I. Introduction

Most students enter computer science programs as a means of gaining access to a lucrative job in software development. The skills that students must acquire to be successful include not only programming skill, but also skill in planning, evaluating, and monitoring the progress of the project. Software projects that do not take into consideration software process are more expensive, take longer to complete, and are more likely to produce unusable software than projects that incorporate process (as shown by use of the Capability Maturity Model [7]).

Unfortunately, in computer science education software development is typically the curricular stepchild. Publicly we extol its importance, but it is given very low status. Most computer science curricula have three ingredients that are claimed to prepare students for careers as software engineers--instruction in programming, instruction in the mathematical bases of computing, and a capstone course in software engineering. To rationalize the value of programming instruction for students' careers as software engineers, we ensure that each of our computer science courses contains "significant" programming projects. This attitude is reinforced by accreditation guidelines suggesting "significant" design experience. Typically these projects are small, less than one thousand source lines of code (KSLOC), and completed in a short time period by a single individual. These programs are usually assessed solely on the output produced and on the structure of the coded solution. There is no real concern for how the student solved the problem, only that a solution is submitted. Broader issues related to the software development process used by students don't enter into the grade deliberation. Little attention is paid to process, either explicitly or implicitly.

The belief that learning the mathematical foundations of computer science will make students better software engineers is based on the assumption that this knowledge transfers to actual practice. Issues of transfer of learning have been widely studied in cognitive science research and it is clear that automatic transfer is the exception, not the rule. Transfer of learning requires explicit, often extensive, instruction, which is typically absent from computer science curricula (see [1] for a review of the conditions that affect transfer of learning).

When a process orientation is present it is typically found in a capstone course, usually software engineering or project practicum, taught late in the student's academic career. This is typically accomplished by assigning real, or at least realistic, projects to students working in groups. The assignment is typically to specify, design, implement, and deliver a product to a real customer. In this context the students begin to focus on process, the interaction of process with product, and the influence these various factors have on product. In this one course, students must learn to 1) use software development methodologies, 2) create high level designs and implement them, and 3) test a large-scale product. All of this is done while also learning 1) to work in teams, 2) to work with customers, 3) to plan and coordinate the efforts of the group members, and 4) to define and distribute tasks to individuals. In our case, the one semester experience is daunting for both faculty and students. In our view, one course, late in a student's program of study, is not sufficient to allow the development of the complex cognitive skills needed. By the latter part of the program of study students have developed numerous bad habits. Perhaps worse, they have been successful with these habits; thus, it is increasingly difficult to persuade them that other approaches are more effective. We argue for a new paradigm that strikes at the foundation of computer science education and addresses what we feel are some of the inadequacies of computer science education, as it relates to preparing students for the "real" world. At the same time, we argue for an approach that makes pedagogical sense [14].

II. Process Foundations

The assimilation of good practices [2][15] into an existing process requires a differently educated practitioner. A software developer must be prepared to a) understand the development process or processes; b) conceptualize a desired process; c) establish process improvement actions; d) plan the improvement activities; e) find the resources needed by the plan; f) execute the plan, and g) repeat the improvement process [6]. The mandate is to learn the skills necessary to control their work processes by being empowered to evaluate and modify them. Such considerations should be grounded in metrics and measurement [10]. A process focus, supported by measurement, makes students' development activity visible to them. By making the process visible, it becomes understandable, accessible, and eventually controllable [5].

III. Instructional Foundations

The goal of our instructional project is to help students to learn to focus on the processes underlying the development activity. The framework for the instructional context is provided by the cognitive apprenticeship model [3][4]. The techniques applied in this model are designed to explicitly support students in learning the mental habits of skilled practitioners, as medieval artisans developed their skills through apprenticeship to masters. As with standard apprenticeship programs, students first watch while an expert demonstrates the activity. During this expert modeling, the expert not only talks through the task as it is being done, but s/he also talks about how s/he thinks about and makes decisions about how to proceed. This increases the visibility of the thought processes that are common in the solution process. Students, usually in small groups, practice on a similar task under the watchful eye of the expert. The expert acts as coach for these groups, providing guidance but not solutions. The situation must encourage students to articulate both their knowledge and their understanding of the process by which the task gets done. Likewise, this encourages students to reflect upon the proposed solutions and think about alternatives in nonpunitive ways.

The framework of the cognitive apprenticeship approach defines the kinds of knowledge that is important for students to learn. Table 1 shows the types of knowledge deemed important. Notice that knowing-what, specified by domain knowledge, is a small portion of the total knowledge requirement of a task. We see in Table 1 three kinds of how-to knowledge that allows practitioners to choose solution paths and coordinate their activity. In addition to the content model, cognitive apprenticeship introduces methods that support process education. There are of six basic activities (see Table 2) associated with the cognitive apprenticeship approach.

Our prior experience and success with the cognitive apprenticeship approach as an instructional model [11][12][13] leads us to believe it to be the most viable approach to software process education since it 1) structures the learning experiences in terms of identifying the skills and decomposing these into subskills that can then be modeled by experts, 2) provides supportive coaching as students engage in the various activities, 3) intentionally provides less support as the students develop their skill, 4) encourages the students to articulate aspects of their performance, and 5) requires students to reflect on their performance (in our approach based on measurement data). These latter criteria, articulation and reflection, when applied to programming projects involve explication of the development process with an eye on improvement.

IV. Curricular Activity

Our current efforts involve revising the laboratory component of two courses required of all computer science majors. The first course we have applied our strategy to is a required sophomore course. Students enter this course having completed the equivalent of CS1 and CS2. The focus in this course is the individual and individual skills, consistent with those activities suggested in the Personal Software Process [7][8]. The activities we developed are designed to be executed during the laboratory portion of the course. They use as their objects of study the programming activities normally required in this course, and thus, do not compromise the traditional content of this course.

A. Project Postmortems

The first major change for the students involves conducting a postmortem for each project (or activity). The goals of our postmortem activity were to:

• Provide an environment that supports openness and constructive criticism.
• Provide an environment that encourages improvement.
• Provide situations that use self-reflection.
• Provide an environment that encourages students to share lessons learned.
• Provide an environment that supports easy collection and archiving of information.

Provide a process that links the activities to future projects. The postmortem survey (Table 3) first asked them to revisit what happened during the project (early projects have a 1 or 2 week timeframe), and what specific tasks (item 10) they performed to complete the project. Wherever possible we made use of close-ended questions students could answer quickly and unambiguously. The postmortem was intended as a reflective exercise. Students should see it as an effort to help them realize more about how they work, and to begin to make decisions about how to work more effectively. They were then asked to identify some of the activities that they found helpful (would repeat) and detrimental (would avoid) to their work habits. These two questions were open-ended so that students would have to generate answers.

Next , students entered measurement data on the project (see Table 4). During the first trial we asked students to collect size data on the source code developed for the project. The measurement template (see Table 4) included the definitions the students required for SLOC and documentation, specifying what was included and excluded from each. In subsequent projects data collection included effort estimates also. The concluding activity of the postmortem was goal setting. The students were asked to establish a goal for the next project and identify activities they thought would help them achieve their goal.

B. Design Notebooks

All students were provided with access to a web-space secured by username and password for material. They posted their process homework electronically using web-based tools. Thus, at the end of the semester the student had a record of all survey and measurement data. The students' final writing assignment was to compare the manner in which they worked on projects at the beginning of the semester and at the end (see item 10 in Table 3 for sample activities). This was possible since the design notebooks contained the pre/post course survey, and all the data they collected during the semester.

C. Peer Reviews

Peer reviews were introduced to help students identify defects in the programs they wrote. The rationale was threefold: 1) students need the opportunity to see how others think about different types of problems, 2) they need to find strategies other than testing to identify problems, and 3) they need to learn to read and evaluate code. Establishing a formal review process, with defined roles for each team member, allowed students to establish the effectiveness of this as a defect removal strategy. Each student had the opportunity to work in each of three identified roles during the course. All three members of each team were asked to submit reports (all posted in the design notebooks). The author was responsible for summarizing the results of the review in a defect report indicating the defects found, identifying the defect type, and estimating the severity of each defect. The two other members of the review team conducted a postmortem on the reviews. The results of the review postmortem indicated that the students recognized the value of the reviews and felt effort expended for the review was very worthwhile. Students remarked that the review saved them enormous amounts of time in testing and debugging.

V. Conclusions

This project supports the acquisition of how-to knowledge in several ways. First, through expert modeling and practice students learn to create plans for how to complete their products. Second, through systematic measurement and qualitative postmortems they learn effective self-regulation techniques. Reviewing the work of others helps them to adopt attitudes of constructive criticism that they can then apply to their own work. These techniques improve on the basic cognitive apprenticeship model because they systematize and make necessary the articulation and reflection that should occur in small-group work. Those who have closely observed students working in small groups know that not all students actively engage in articulation and reflection even though the situation encourages it. By requiring that all students systematically plan, measure their process and products, and reflect in reviews and postmortems, no student can escape that difficult activity. Thus far our results support the feasibility of introducing software development process into extant computer science courses. We have found that students can attend to issues of process in their day-to-day work in a computer science course. They make gains regarding both their development activity and their own learning and they see the impact of the activities for their improvement and can articulate the influence. Such curricular innovations should help students develop a broader, more accurate understanding of the software development process, and permit them to begin to develop the process skills they will need as professionals.

Note

This project is supported, in part, by grant DUE-9555042 from the National Science Foundation. The material discussed in this paper is freely available at www2.umassd.edu/SWPI/NSF/material.html.

References

[1] Anderson, J. (1987). Skill acquisition: Compilation of weak-method problem solutions. Psychological Review, 94, pp. 192-210.

[2] Brown, N. (July 1996) Industrial-Strength Management Strategies. IEEE Software. pp. 94-103.

[3] Collins, A., Brown, J. S., and Holum, A. (1991, Winter). Cognitive apprenticeship: Making thinking visible. American Educator, pp. 6-11, 38-46.

[4] Collins, A., Brown, J. S., and Newman, S. E. (1989) Cognitive apprenticeship: Teaching the crafts of reading, writing, and mathematics. In L. B. Resnick (Ed.), Knowing, learning, and instruction: Essays in honor of Robert Glaser. Hillsdale, NJ: Erlbaum. pp. 453-494.

[5] Hsia, PP. (September 1993) Learning to Put Lessons Into Practice. IEEE Software. pp. 14-17.

[6] Humphrey, W. S. (1989) Managing the Software Process. Reading, MA: Addison-Wesley.

[7] Humphrey, W. S. (1995) A Discipline of Software Engineering. Reading, MA: Addison-Wesley.

[8] Humphrey, W. S. (1997) Introduction to the Personal Software Process. Reading, MA: Addison Wesley.

[9] Paulk, M. C., Curtis , B., Chrissis, M. B., and Weber, C. V. (1993) Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24, Software Engineering Institute, Carnegie Mellon University.

[10] Pfleeger, S. L. and H. D. Rombach. (July 1994) Measurement Based Process Improvement. IEEE Software. pp. 9-11.

[11] Sims-Knight, J. E. and Upchurch, R. L. (1993). Teaching Object-Oriented Design Without Programming: A Progress Report. Computer Science Education, 4, 135-156.

[12] Sims-Knight, J. E. and Upchurch, R. L. (April 1993). Teaching software design: A new approach to high school computer science. Paper presented at the annual meeting of the American Educational Research Association, Atlanta, GA.

[13] Sims-Knight, J. E.and Upchurch, R. L. (1992). Teaching object-oriented design to nonprogrammers: A progress report. Proceedings of OOPSLA-92 Educators' Symposium. Vancouver, British Columbia, Canada.

[14] Upchurch, R. L., and Sims-Knight, J. E. (1997) Designing Process-Based Software Curriculum. Tenth Conference on Software Engineering Education, Virginia Beach, VA. April 13-16, 1997.

[15] Yourdon, E. (1996) Rise & Resurrection of the American Programmer. Upper Saddle River, NJ: Prentice Hall.

Table 1: Knowledge Types

Table 2: Cognitive Apprenticeship Activities

Table 3: Postortem Survey

1. Were the computing resources you needed to complete the project available, and consistent with your schedule and work habits?
2. In your estimation, was the time allotted adequate for the project?
3. In your estimation, was the time you needed to complete the project consistent with the time provided?
4. What events, if any, occurred to interfere with your ability to deliver the project by the due date?
5. Were the supporting materials provided for the project adequate?
6. What additional material(s) do you wish were available?
7. Were any necessary clarifications of problem received during the
8. project?
9. Were your programming skills challenged by this problem?
10. Were your development skills challenged by this project?
11. Once the project was assigned, did you establish a plan identifying important milestones to achieve in order to complete the project by the due date?
12. Do you wish your plan was more elaborate or specific than the one you used?
13. Below are a list of activities, check those that you engaged in to complete this project.
    • Activity
    • spent time thinking about the requirements to be sure I understand what the program should do and the expectations
    • created a specification based on all the inputs and all the outputs the program should have
    • created a written design for the program using structure charts, or similar representation
    • reviewed the design before implementing
    • had a peer to review design before implementing
    • created a plan for testing the program
    • reviewed the test plan
    • wrote the code
    • debugged until the program ran
    • systematically tested using inputs from test plan
    • systematically reviewed the pre- and post-conditions for all
    • had a peer review code
    • reviewed the program documentation
    • reviewed requirements from the user's perspective
14. List at least two things you did in this project you would repeat, if you had to do this project over again. Explain your reasoning based on how these activities allowed you to produce the required product with the resources given in the time provided.
15. List at least two things you would change about your development activity, if you had to do this project over again. Please be specific, and explain why your choices would improve you development activity.

Table 4: Data Collection

Data Item

Number of Procedures and Functions

Lines of Comments

Average SLOC/Procedure

Average Lines of Documentation/Procedure

Definitions