"Despite 50 years of progress, the software industry remains years-perhaps decades-short of the mature engineering discipline needed to meet the demands of an information-age society" (Gibbs, 1994, p. 86) Authors of software engineering articles and books typically call this situation: 1) the software crisis, 2) software's chronic affliction, or 3) the state of practice. The debate over the "correct" descriptive moniker continues, as does the software industry's inability to produce quality software on time and within budget. The more spectacular failures, such as the Denver International Airport, receive national attention in the press.
Analysis of the software industry indicates that much of the problem stems from the assumption that technology is a panacea (Curtis, Kellner, and Over, 1992) and from the failure to attend to the development context, which includes the people, the problem, and the product characteristics (Lai, 1994; Cain and Coplien, 1992). To improve the outcome, one must improve the process, and to improve the process one must understand the current process and be able to make it visible to all concerned (Humphrey, 1989).
The assimilation of good practices into the existing process or the modification of existing processes to accommodate new practices and methods will require a differently educated, prepared, software engineer (Mills, 1988). A software engineer needs to be prepared to 1) understand the current status of the development process or processes; 2) develop a vision of the desired process; 3) establish a list of required process improvement actions, in order of priority; 4) produce a plan to accomplish the required actions; 5) commit the resources to execute the plan; and 6) repeat the activity (Humphrey, 1995). This coupled with the need to assess and measure (Pfleeger and Romback, 1994) puts the software engineer of the future solidly in the position of scientist. The software developer who survives in the new order must be able to handle measurement and empirical studies to determine the effectiveness of those changes recommended and implemented. It will not suffice to merely implement change, it will be mandatory to evaluate the results. Results from NASA's Software Engineering Laboratory (McGarry, et. al., 1994) and the University of Maryland (Basili, Caldiera, Rombach, 1994) support this view. This paradigm shift strikes at the heart of how we do what we do in computer science (Potts, 1993) and software development.
The shift will also require serious changes in educational practice as well as industrial practice (Hsia, 1993). Computer science education does not teach all the intellectual skills necessary for the task of software development. The educational preparation we provide students is typically from the scientific/mathematical tradition of computer science, and it is hoped that the foundations provided therein are sufficiently mature and robust to support the emergent, and/or existing, commercial practices. We tend to leave the activity of transfer from this scientific tradition to actual practice as an exercise, to be endured by the student, in the form of programming activities. Students are expected to be able to apply classroom knowledge (how it works) to tasks (how to do it), even though Anderson (e. g., 1987) has shown quite definitively that such transfer does not occur automatically (see Reder and Klatzky, 1994 for a review of the conditions that affect transfer of learning). Furthermore, both students and faculty have a product orientation, that is, they are primarily concerned with whether the program works or whether it includes a "good" algorithm ("good" by the criterion of supporting efficient use of resources, for example).
Little attention is paid to process (i. e., how to go about solving the problem), either explicitly or implicitly. Although providing documentation of a program might teach students about process, students persistently code first and write documentation (including the high level design) at the end, just before turning in the project. Thus, the students do not attain the foundations necessary to evaluate and reason about practice. They don't understand process activities so they cannot see how their activities influence the project overall. Thus, it is nearly impossible to provide a mechanism that would allow a discussion of potential changes and speculation over the implications of changing a process. Topical areas and knowledge units conceal the need to provide systematic attention to process throughout the curriculum, without which our students will not be adequately prepared to become software professionals.
A process orientation is not typically found prior to a capstone course, usually software engineering, taught late in the student's academic career (Boardman and Mathur, 1994; Modesitt, 1994; Gotterbarn and Riser, 1994). In this context the students begin to see the interaction of process with product, and the influence various factors have on good process and a resulting good product. This is accomplished by assigning real, or realistic, projects with customers to students working in groups. The requirement is typically to specify, design, implement, and deliver a product. Thus, in this one course students must learn 1) various software engineering methodologies, 2) to work in teams, 3) to work with customers, 4) to create high level designs and implement them, and 5) to create a large-scale product. Obviously, one course is insufficient. Yet, many authors (Brooks, 1987; Mills; 1988) see the education of future practitioners as the singular critical factor in resolving the problems of the software industry.
This proposal requests funds to provide extensive and integrated attention to process issues throughout the five-course software sequence of our computer science curriculum. We propose to attain this by the two separate goals listed below.
Goal 1: Increase the influence of software process on the undergraduate computer science curriculum.
Objective 1.1: Design laboratory component for the software track of the undergraduate major to incorporate explicit activities related to software process.
Objective 1.2: Develop standards and procedures manual for software development activities.
Objective 1.3: Design an on-line student portfolio and experience database.
Objective 1.4: Design activities to utilize student measurement data for process assessment.
Goal 2: Establish the infrastructure needed to support on-going software process education for computer science majors.
Objective 2.1: Develop training program for use with faculty.
Objective 2.2: Develop an on-line database of problem/project related information accessible by faculty (referred to as the Problem Book in this proposal).
Objective 2.3: Provide mentoring support for faculty incorporating software process activities in coursework.
The major impact of this project, if successful, will be to provide an environment in which students can develop cognitive skills critical to their success in the software industry, and, in the long run, critical to the software industry itself. Although we do not downplay the importance of on-the-job training, such training in the current software industry has the same inadequacies as computer science curricula. Therefore, if they do not develop reflective reasoning in their computer science major, it is unlikely that they will receive adequate compensatory training. Some people, of course, develop such skills on their own, but recent assessments of the software industry indicate that most do not.
If the curricular changes proposed here do not result in more effective software engineering practices by students, the extensive formative and summative evaluations will point the way to improvements. In that case, the major outcome of the project will be an assessment of what works and what doesn't plus a significant cognitive analysis of the reasons for failures and a series of recommendations that direct us towards solutions. From our perspective this is clearly a win-win situation.
This approach does not require massive reconceptualization of the computer science software offerings nor does it require that students learn less about core computer science theory to accommodate attention to practice-oriented skills. Adding laboratory components to preexisting courses is efficient, because the lessons of process can be incorporated into assignments designed to teach programming or algorithmic skill. Furthermore, because the laboratory components can be piggybacked on a variety of specific exercises, they will be highly portable to curricula in other institutions.
Shaw (1990) provides an interesting tour of the growth of engineering professions in general. Her analysis takes the reader from the craft tradition, which is marked by virtuosos and talented amateurs making haphazard progress utilizing brute force with extravagant use of materials, through commercialism, which is marked by skilled craftsmen following established procedure directed at pragmatic refinement with concern for cost and supply of materials, toward professional engineering, which is marked by educated professionals whose progress relies on a scientific basis through the use of analysis and theory. The emergence of an engineering profession relies on establishing a scientific basis for practice, and a merger of the supporting science with the commercial paradigm. Software engineering today, in Shaw's model, is in the commercial area, not far from the craft tradition.
The manner in which we assign and assess work products in our curriculum seems consistent with most of the software industry. The industry is product oriented with management oversight on issues of process. This current industrial perspective has had numerous critics recently. Furthermore, the crisis/chronic affliction discussion has inspired a process improvement wave world-wide. Process improvement is seen, by managers and practitioners, as the path to quality products, increased efficiency, increased effectiveness, reduced costs, and improved staff satisfaction (White, 1993). In the United States, the Software Engineering Institute has developed the Capability Maturity Model (CMM) to assess the quality of a project's or organization's development process (Paulk, Curtis, Chrissis, and Weber, 1993). The process assessment provided by this framework rates certain activities, referred to as key practices (Paulk, Weber, Garcia, Chrissis, and Bush, 1993). Similar in spirit to CMM is SPICE (Software Process Improvement and Capability dEtermination) developed by the European Software Institute (http://www.esi.es/) with field trials beginning in 1995. SPICE (Paulk and Konrad, 1994) succeeds the Bootstrap project (Haase, Messnarz, Koch, Kugler, and Decrinis, 1994), and builds on the work of the European Space Agency, the University of Graz, and ISO 9000 (Paulk, 1995). It is clear from the direction taken by the groups in both Europe and the United States that fundamental, base-level change is certain in the software industry.
Results from the use of the CMM framework in industry supports the claims of the inadequacy of the software industry. The CMM assessment results from 1991 indicated that 88% of 296 projects reviewed were at level 1 (the lowest level on the scale, sometimes referred to as chaos). Furthermore 98% of the projects were in the first three of the five levels (Arthur, 1993). Clearly, with results such as this either the industry must change or it will go the way of other craft industries (Yourdon, 1993). Certainly this is not the type of industrial practice which we should imitate in education.
More importantly, what is truly becoming clear is that our fascination with technology may be the source of some of our problems in producing software. Our assumption(s) that introducing new technology is a panacea that cures poorly functioning process is flawed (Curtis, Kellner, and Over, 1992). Brooks (1987) identified the situation cleverly, by claiming that there is no silver bullet to slay the werewolves. Researchers in software process have identified the need for organization to take precedence over methodology, and methodology over technology (McGarry, et. al., 1994; Fischer, et. al., 1995). Equally important is the realization that the correct process must be determined from the development context which includes the people, the problem, and product characteristics (Lai, 1994; Cain and Coplien, 1993). Furthermore, to improve process one must first make the current process visible to all those involved. In fact, Humphrey (1989) includes knowledge of the current process as the first principles for process change.
A major source driving curricular design is the Association for Computing Machinery (ACM). As a professional organization it provides periodic reports on the status or core of computer science, and presents recommendations that structure our thinking regarding the nature of computer science education (Denning, et. al., 1988, 1989; Tucker, et. al., 1992) In the most recent reports, the task force representing the ACM listed nine subareas of computing, one of which was software methodology and engineering. The software methodology and engineering area, recommended at 44 hours of lecture, covers algorithmic problem solving, the software development process, requirements and specifications, design and implementation, and validation and verification. The lecture topics provided in the reports combined with the suggested laboratories continue to promote an isolation of how it works from how it's done. In lecture we describe the a body of knowledge, then in lab the students produce an artifact following a set of prescribed guidelines (such as phases in a life-cycle model). This approach is being strongly criticized (Denning, 1992; National Research Council, 1992) and there is much action toward curriculum reform (Denning, Menasce and Gerstner, 1995; Center for the New Engineer, 1995; Prey, Cohoon, and Wulf, 1994; Knight, Prey, and Wulf, 1994; Moore and Potts, 1994). For instance, Prey and colleagues (Prey, et. al., 1994) characterize the computer science curriculum as 1) constructing small programs, 2) building from ground zero each time, 3) lacking modern tools, 4) programming in isolation using informal approaches, and 5) believing that a working program is the only criterion for acceptance.
There are several strategic positions from which to confront the "business as usual" education in computer science, especially as it relates to our concerns for producing competent practitioners. The first position is the realism problem. Those whose desire for curriculum reform centers on merging computer science with software engineering (e. g., Denning, et. al., 1995; Moore and Potts, 1994) argue convincingly for a tighter coupling between the type of problems given students and that encountered in the work environment. Furthermore, they suggest that these problems be tackled using groups, which allows students to experience the problems associated with group activity and thus gain an appreciation of the process of large-scale software development. What is not appreciated is that, if and only if the they are appropriately structured, groups have tremendous potential for improving learning (Cohen, 1994).
A second position focuses more on the processes underlying the development activity (Werth, 1994; Robillard, Mayrand, and Drouin, 1994). Though process reformers still advocate "realistic" problems, they are willing to compromise on realism to permit more learning about process. In particular, Werth (1994) encourages the use of lab time for students to practice team techniques and advocates providing team members with role definitions and responsibilities. Other variations of the process-oriented approach include the level of structuring on student roles and tasks and the type and amount of guidance provided by the instructor. The common theme in the process view is giving the students a better understanding of the process and the impact of process on the development activity itself.
Our local history in this endeavor parallels activities nationwide. The PIs have been teaching software engineering at the university since 1982. Initially this was a three credit course for computer science majors, usually taken in the junior or senior year. Group projects were assigned by allowing the group to negotiate a topic with the instructor. The groups completed the project by following the waterfall life-cycle from requirements to delivery, perhaps. Documents were the deliverables at each milestone. The instructor's role was to supervise, manage, and referee. Group dynamics were more of tales to be told than lessons to be learned. Team scheduling problems and lack of team rapport were the order of the day. It was argued successfully within the department to change the course from three credits to four credits in 1988. The rationale for the change was to add a laboratory component to the course. In the laboratory component several things could occur: 1) introduction of and support for improved technology use (NSF Instructional Laboratory Improvement - Undergraduate Software Design Laboratory, 89-51328, $82,740: May 1, 1989-October 31, 1991), 2) a fixed block of time for team meetings, and 3) introduction of reviews by the instructor and other teams.
Coinciding with these modifications was a change in structure. The instructor adopted a different approach to choosing problems. Instead of having the student teams choose their problems, he solicited problems from faculty and staff at the university and assigned each team a problem with a real customer. The customer owned the problem, and the task for the students was to determine the structure of a software solution for the customer's problem. The combination of lab time and projects with real customers presented the students with a more realistic working environment. The instructor would work with the groups to attempt to make the problem manageable in the semester time frame. The lessons learned by the students in this activity were more related to organization and management than with technology. The legacy documents from the teams at the conclusion of the semester included contributions from each team member regarding technical and managerial lessons learned. The bulk of these comments were related to the difficulty of managing and working in the group context and depending on others.
In teaching this course over the years, we had increasing discomfort over the preparation of the students entering the course. A review provided us with the realization that this junior level course was indeed a capstone course in our curriculum; it capped the programming learned in the freshman year. The courses taken during the sophomore and first semester of the junior year do not contribute to their software "knowledge" per se, the practice component if you will. Hence, we are asking the single course in software engineering to deal with 1) all life-cycle activities, such as maintenance, quality assurance, and comparisons of paradigms; 2) group dynamics and their influence on software process; 3) improved technological support for all activities; and 4) contextual problem solving in realistic situations. What we had encountered was the tension between what we teach, that is, mainstream computer science, and our desire to produce students for the software workforce (the majority of graduates move directly into the workforce). Strikingly, in our courses the theme of design and design education was omitted or, perhaps worse, left as an exercise even though design is considered a major thread in the ACM model of computer science education (Tucker, et. al, 1991).
The departmental curriculum committee has reviewed the situation and proposed assigning five courses to the software track in the undergraduate major (beginning with the equivalent of CS2). The problem is still what and how to map as content (knowledge units using ACM language) to the intended software courses. Our solution to this dilemma and the focus of this proposal is not to concern ourselves directly with course content. Rather we propose to provide thematic, threaded laboratory activities related to software development that can piggyback on a variety of activities in these software-related courses. In the spirit of Richardson (1988) and Prey, Cohoon, and Fife (1994), we want to engage our students early and repeatedly with concerns of software process (including process modeling, measurement, and typical development tasks such as design, coding, software quality assurance and maintenance). Some recent preliminary explorations in this area by the PIs have produced encouraging results. Over the past two years we have experimented with development activities during two courses, notably CS2 and a software course taken during the sophomore year. In these courses we have tried team design groups, design review sessions, and more formal design strategies. Our observations, though anecdotal, indicate the direction as correct, and essential from both the instructors and the students views. What is needed, especially to become part of the establish curriculum, is provide systematic support for software process activities across the curriculum.
An explicit notion in this effort is to attend directly to the students' ability to reflect upon their process, the process they used to produce artifacts. Professional programmers have difficulty understanding their own product code (Haase et. al., 1994), so it would be presumptuous of us to expect students to gain this ability for process without serious intervention. The fundamental strategy we intend to follow is to develop first the students' understanding of their software process (Humphrey, 1995). We believe that students can best develop their sense of what they do how this relates to the outcome when they work independently. Thus, we will establish the foundation using individual projects and later will add team/group activities. Initial activities will be to motivate the students to collect process and product data for the projects they are assigned. To gather their projects and form a portfolio, we will create a database system. The portfolio will contain not only the collected artifacts produced by the student but also the measures collected and analyzed with any reflective writings included. We see the portfolio as the historical record of the student's work and thus the baseline from which the student can begin to reason about his/her strategies and activities during development.
When the students begin to work in teams on larger projects, the portfolio will serve as the object of study so that students can consider questions such as "How do I alter the way I work since I am now part of the group?" and "How should the group organize to work together effectively?" and "What are characteristics should the individual charged with working on a particular activity have?" By designing the educational activity in this manner we contextualize it and make the students active partners in the evaluation.
The field of instructional research, in the last thirty years, has yielded some rather substantial gains in our understanding of what is important for students to learn and what learning environments promote that learning. We know, for example, that if we are to foster true intellectual development in students, we must explicitly attend to basic cognitive skills, such as how to assimilate textual material, how to write effectively, how to solve problems, or how to plan a strategy. Concomitantly, we have learned that students can not learn these skills passively, by listening to lectures, or reading the text, or by viewing videos. Rather students must actively practice these skills with feedback from others. Perhaps the best learning environment for promoting development along the lines we propose are cooperative work groups (Brown and Palincsar, 1989; Slavin, 1990; and Cohen, 1994). We intend to use teaching techniques similar to that found in Palincsar and Brown's method of teaching reading comprehension (1984, Brown & Palincsar, 1989), Bereiter and Scardamalia's teaching of writing (1987, Scardamalia, Bereiter, & Steinbach, 1984), and Schoenfeld's method for teaching mathematical problem solving (1983, 1985), and formalized as the cognitive apprenticeship model by Collins, Brown, and their collaborators (Collins, Brown, & Holum, 1991; Collins, Brown & Newman, 1989). It includes three major features common to all three of these disparate, but effective teaching techniques: modeling the expert reasoning process, providing scaffolding and coaching for student learning, and having the students work in small groups. Our prior experience with this approach in teaching high-level design (Sims-Knight and Upchurch, 1992, 1993; see Results from Prior NSF Support Section) suggests it will also be effective in this context. This model encourages both instructors and students to focus on right set of issues--the way people do things--and provides procedures whereby instructors can identify the behaviors the students need and effectively promote students' development of those behaviors (see Results from Prior NSF Support Section for an example of this).
Students will be taught to create and maintain a personal project portfolio consistent with the demands of what Basili et. al. (Basili, Caldiera, and Rombach, 1994) referred to as the experience factory. In this database students collect information on their activities on various projects as they progress through the courses. Clearly, this portfolio is more than examples of student work, it is part and parcel of our approach to making our students into reflective practitioners (Moore and Potts, 1994). Learning to collect the right kinds of data requires that we develop laboratories that assist students in learning about measurement and metrics (Ford, 1993). Furthermore, having data does not mean we can reason about change effectively. These are learned behaviors and our proposed curriculum must pay explicit attention to developing the students' skills in these areas. Laboratory activities will include students reviewing their data on various projects, and preparing comments and recommendations regarding their behaviors.
Another critical element in our curricular development plans is a repository for collecting historical information on what problems/projects faculty use and how they are used, which we call the problem book. We believe the problem book has enormous potential as an instructional resource and is a necessary resource for process education. In the problem book, we capture not only the problem but the type of activity given for this particular problem (e. g., coding, maintenance, testing, inspection, etc.). The problem book should evolve to a robust resource where faculty can choose the type of problem for a given activity and have some preliminary data on expectations from the activity. For instance, a given problem may have code in some particular, or variety, of programming languages plus a design document. Hence, the problem book would become a rather sophisticated set of case study material similar to that of Linn and Clancy (1992). This problem book can be extended to include defect lists (defects that can be introduced into the source so the program could be used as a testing or code inspection activity). But fundamental in developing the problem book is that it maintain the baseline data on student development activity for projects over time. This is the historical record of activity from the faculty's perspective and can then be used for planning and curriculum re-engineering.
We foresee the problem book in combination with the personal project portfolio as an eventual source of data for the new fronts in software engineering education. For example, questions of reuse (Basili, Briand, and Thomas, 1994) such as "What is needed, from a student's perspective, to document a resource for potential reuse?" and "What are the impediments to reuse?" can be posed. Another example is that we will gather data that permit the comparison of development paradigms, say object oriented and procedural (such comparisons would also allow discussion of the nature of empirical assessment using different samples which would bring us back to the issues related to research in software engineering (Potts, 1993; Computer Science and Technology Board, 1990). These two databases, the problem book and the student portfolio, will permit us to construct a curriculum that promotes the reuse of experiences contained therein. We believe what is needed in preparing future practitioners is an increase in the number and type of development experiences which, from research such as Guindon's (1990), translates directly into improvements in productivity. On the science side, we would have the type of experience repository here that allows for planning and assessment using empirical principles (and in so doing avoid the biases mentioned by Stacy and MacMillan, 1995). Thus, through a focus on process education, we should arrive at an improved software practice and science of software.
The various objectives stated below provide an effective representation of the concurrent activities for the curriculum development we propose. The goals and objectives described are elaborated in more detail below by assigning for each goal and objective a series of tasks. The laboratory development activity is further refined to indicate how our user-based design strategies support the curriculum design effort.
Goal 1: Introduce a software process component in the computer science curriculum.
Objective 1.1: Design a laboratory component for the software track of the undergraduate major to incorporate explicit activities related to software process.
Task 1: Review software process modeling research for strategies and techniques (see the work conducted by Experimental Software Engineering Group at University of Maryland (http://www.cs.umd.edu/SoftEng/tame/), Informatics Process Group Department of Computer Science at University of Manchester, UK (http://www.cs.man.ac.uk/ipg/index.html), Software Engineering and Information Systems at Leiden University, the Netherlands (http://www.wi.leidenuniv.nl/CS/SEIS/oogis.html), Project E3 at Politecnico di Torino in Italy (http://ulisse.polito.it/~e3maint/), and Software and Systems Research Center at AT&T Bell Laboratories (http://www.research.att.com:80/orgs/ssr/areas.html)). This review of process modeling is work in progress, supported by the Naval Undersea Warfare Center under Intergovernmental Personnel Act agreements with the PIs (Green and Upchurch). The material assembled under this activity can be found at http://www2.umassd.edu/SWPI/swpipage.html. We expect significant progress on this activity prior to the start date for this project.
Task 2: Evaluate process models that are appropriate for computer science education (individual, team, and group), select candidates for adoption, conduct feasibility study to determine potential for use, and document findings.
Task 3: Identify and select process and product metrics that would be useful with undergraduate CS majors (see Humphrey, 1995; Ford, 1993; and Florac, 1992) and consistent with the models from Task 2 for individual, team, and group.
Task 4: Identify roles, tasks, and activities in the process models identified in Task 2, and develop tutorial and practice material for students.
Task 5: Design laboratories for software track courses. This task is actually a combination of specify, construct, test, and evaluate. We follow a user-based development strategy so we tend to specify and construct partial products and then test these with smaller groups of students prior to preparing for whole class laboratories. User-based prototyping design has been shown to result in more usable products, with fewer errors to be corrected after the development process is complete, at a lower development cost, and often with less development time (see, e.g., Gould, Boies, Levy, Richard & Schoonard, 1987 for an example in software design; Powell, 1989; Mantei & Teorey, 1988 for industrial design). The timeline in Table 1 demonstrates the way this task distributes for the five software courses across the four years of the project. This allows for multiple iterations through the cycle for some of the laboratories under development (see Results of Prior NSF Support for a discussion of our experiences in utilizing this approach in developing instructional material) .
Objective 1.2: Develop standards manual for software development activities.
Task 1: Review existing collections of artifact standards, such as those produced by Taligent (1994), and style guidelines (code, design, test, etc.), such as that on C style maintained at ftp://archive.cis.ohio-state.edu/pub/style-guide/.
Task 2: Develop or adopt standards for artifacts that will be good examples for students to learn to follow.
Task 3: Publish standards manual.
Objective 1.3: Develop an on-line student portfolio and experience database.
Task 1: Specify the requirements for an on-line portfolio experience system (Basili, Briand, and Thomas, 1994).
Task 2: Evaluate our existing database products for suitability.
Task 3: Design portfolio system prototype and evaluate.
Task 4: Construct portfolio system.
Task 5: Integrate use of portfolio system into software track laboratories.
Objective 1.4: Design activities to use student measurement data for process assessment.
Task 1: Review findings and results from Objective 1.1:Task 5.
Task 2: Identify measurement activities that are appropriate to individual, team and/or group process.
Task 3: Integrate the use of measurement into process laboratories.
Task 4: Prepare capstone activities for upper division software courses moving students from individual process models to team models.
Goal 2: Establish the infrastructure needed to support on-going software process education for computer science majors.
Objective 2.1: Develop training program for use with faculty.
Task 1: Survey department faculty to ascertain level of understanding of software process and apparent role in the preparation of our students.
Task 2: Evaluate results of needs assessment.
Task 3: Define training and support needs for faculty.
Task 4: Design training material to support faculty in using software process activities.
Objective 2.2: Develop an on-line database of problem/project related information accessible by faculty (referred to as the Problem Book in this proposal).
Task 1: Elaborate requirements for the database.
Task 2: Validate requirements.
Task 3: Design database system (the results of Objective 2.1:Task 2 are useful in determining if our existing database products support this activity).
Task 4: Construct Problem Book system.
Task 5: Implement use of problem book in software courses.
Objective 2.3: Provide mentoring support for faculty incorporating software process activities in coursework.
Task 1: Conduct training on software process for department faculty.
Task 2: PIs team with faculty in teaching laboratory component of courses.
Task 3: PIs serve as review committee on software projects.
Elaboration
The development of the student portfolio system will be completed over the course of the second year of the project, though the initial requirements will be defined during our initial laboratories with the students. We will construct this system in a manner similar to the strategy we use with other materials, user-based. It is vital that we construct a portfolio system that students can not only use, but will use. Early input from students regarding items that facilitate use versus those that impede use are essential for this activity. With preliminary requirements in place we can then turn our attention to the issues surrounding the integration of the use of the portfolio system with the laboratories we prepared and tested during the first year of the project. Having the initial encounters with the laboratories include data regarding use by students should make it easier for us to weave the use of the portfolio into the pedagogy. Furthermore, it may facilitate student activity since the on-line system will relieve the student of certain other routine tasks.
Our activities under goal 2, infrastructure, are aimed at facilitating the integration of software process activities into courses taught by faculty without the commensurate preparation in software engineering and/or software process. Early interactions and discussion with the department faculty may identify unforeseen obstacles to this endeavor. Curricula reform such as we propose is not in the normal academic tradition, hence we intend to prepare a technical report, with this proposal as its beginning, as discussion document for the department and conduct a faculty seminar on software process modeling in the fall of 1995. The intent is to collect the reactions to both the perceived problem and the recommend solution prior to initiating formal project activities. We firmly believe that the risks associated with this project are grounded in the perceptions of the faculty, thus we must strive with all possible diligence to provide the necessary development activities for our colleagues. It is through this type of activity we expect to first, prevent the development of curriculum that cannot be delivered by those other than the PIs, and second, move towards the creation of a critical mass of faculty concerned with software process education.
There are a number of artifacts resulting from the project activities. Though we do not wish to downplay the production of physical work products, we do wish to stress outcomes in the nature of curriculum and in the activities in individual courses. Perhaps more significant, if we can affect such radical change, would be a positive change in attitude, such as that suggested by Hsia (1993), on the part of a majority of the teaching computer science faculty. Our focus on process and the resulting student focus on process should result in changing perspectives on the part of the faculty. What we should establish is a system that encourages a process orientation and the resources to realize goals. A more detailed collection of results is related to the evaluation component of the project and can be found in the Evaluation section below.