The material offered from this page was developed under DUE-9555042 from the National Science Foundation.
Designing Process-Based Software Curriculum. Proceedings of the Tenth Conference on Software Engineering Education and Training, Virginia Beach, VA, April 13-16, 1997. Los Alamitos: IEEE Computer Society Press. p. 28-38
A Model for the Software Engineering Education Process. (Work in Progress)
Integrating Software Process in Computer Science Curriculum. Abstract Frontiers in Education Conference, November 5-8, 1997 in Pittsburgh, PA.
Program Comprehension Work in Progress
In Support of Student Process Improvement. Proceedings of CSEE&T'98, February 22-25, 1998 in Atlanta, Georgia.
The Acquisition of Expertise in Software Engineering Education. Frontiers of Education Conference, November 4-8, 1998 in Tempe, Arizona.
Here are the latest versions of material developed for use in a sophomore computer science course. The comprehension lab uses a code review process model which will be reused later in the semester. Within the initial pages are additional links to material that is also available from this server. There are certain forms that have been disabled. We are currently working to make our forms validate prior to submission.
I am trying to maintain a configuration history for those wishing to track or use the material, so people can see easily what has changed over time.
As an initial activity, students are asked to think about how they go about working on projects. This is a structured form they complete.
Based on the first years data we revised the preliminary survey. We added additional material related to the way students work, and did considerable rework of the wording and structure of the survey. As the document grew it was broken into parts making delivery and processing easier. All the forms now support validation via Javascript. Adding a class list simply requires using a server-side include.
All student work is posted to an electronic design notebook. This provides opportunities for students to review their thoughts during the semester. One task that is an integral part of the course plan, is a pre/post work survey. At the end of the semester students are asked to repeat the survey and compare the results obtained during the first week of class.
The strategy is to have students review the project assignment as a requirements inspection. The process establishes roles for the students are to have and what the expected outcomes are.
On receiving a project, the project is distributed to class members. The assignee should review the project as submitted against the checklist provided. The intent is for the results to be directed to the project author. The author can review the remarks and determine whether the project is ready for submission. Currently exploring this as part of the postmortem. Would like to see students voluntarily conducting such prior to project submission.
The problem the students are to work has been elaborated to a partial SRD. They are to conduct a requirements inspection. This problem statement will be revised and defects, errors, and omissions will be in place. At the end of the inspection a discussion of defect removal effectiveness is in order.
A requirements inspection was conducted as specified by the process. The collected problems were used to revise the SRD. The revision history details, by section, what changes were made. The students were given the list of problems with traceability to the changes in the requirements document prompted by those issues. This was a nice implementation using html since each issues could then be linked using an HREF to its associated anchor in the revisions document.
In maintaining a philosophy for defect detection and prevention it seemed reasonable to inject reviews in the development activity to help the students leverage from each other. The notion of reviews as a potential learning device has enormous potential. This strategy also feeds to the idea of inch pebbles and helping student "plan" by requiring an interim product be complete by a certain date. Along this line I developed a type inspection process for Project 2. During the requirements inspection it became clear that the students needed, could use, help insuring that all the details were there. This required a checklist as a guide for the reviewers.