Session F2G INCORPORATING SOFTWARE ... - Semantic Scholar

1 downloads 110621 Views 27KB Size Report
course in our undergraduate computer science degree, and it is taken during the last semester of the degree. Students entering this class are graduating seniors ...
Session F2G INCORPORATING SOFTWARE QUALITY ASSURANCE IN COMPUTER SCIENCE EDUCATION: AN EXPERIMENT Massood Towhidnejad1 Abstract --- This paper describes an experiment which involved students in the undergraduate computer science senior project capstone design course, and students in the graduate software testing course. Students entering the senior project class are graduating seniors who have completed all but maximum of two required CS classes. They have already completed a one-semester software engineering class, with major emphasis on software development life cycle and software processes. Students entering the software testing course have already completed graduate courses in software engineering, project management, requirement engineering, and they may have other courses in software design and architecture. Students in the undergraduate class worked as the development team while students in the graduate class worked as the software quality assurance team, both working on a single product. This paper describes the process, product, and the out come of this experiment, in addition, student feedback and lesson learned will be discussed. Index Terms --- Software quality, capstone course, development model. INTRODUCTION

The existence of a gap between industry software engineering needs and academic software engineering education has been widely reported [1,2,3,4]. Industry needs software engineers, but universities are educating computer scientists [2]. A Software Engineering Institute (SEI) report succinctly states the problem: "Students are not prepared to make the jump between computer science or software engineering in school to software engineering in the professional world [4]." There are several reasons for the gap between what students are learning in universities and the skills required by the software industry: one is that few academic programs address the competencies expected of incoming software engineers, i.e. programming in the larger, real-life corporate environment, ability to work in teams , knowledge of process, and the ability to estimate time and labor costs and quality. Computer science education, where most software engineering education occurs, too often focuses on individual contributions rather than managed group efforts involving competencies, finally, majority of the faculty 1

teaching in the area of computer science have minimal or no industry experience developing software. Many schools have attempted to overcome this problem by introducing project courses where students are grouped into teams and assigned a “realistic” problem to solve, and hiring faculty with some industrial experience. The success of this approach depends of how closely the class environment simulates the corporate environment. This paper describes one such experiment, the computer science senior project class, at our university. COURSE O BJECTIVES

Our senior project course is considered to be a capstone course in our undergraduate computer science degree, and it is taken during the last semester of the degree. Students entering this class are graduating seniors who have completed all but maximum of two required CS classes. They have already completed a one-semester software engineering class, with major emphasis on software development life cycle and software processes. They also have the experience of working as part of a team in at least two of their previous classes. This course has the following objectives: •

Provide students the opportunity to work on a “real” problem. By the time our students register for this class, they have learned about different areas of computer science. In addition, they have learned about areas outside of the computer science, such as aviation and aerospace, engineering, humanities, and others. The students are required to apply the knowledge, techniques, methods, and processes they have already learned in other class to solve a challenging and complex “real” problem.



Re-enforce the attitude of lifelong learning. The computer science discipline is very dynamic. Successful professionals in this discipline should possess an attitude for lifelong learning. Given this objective, the project chosen for the senior project required students to learn new topics, tools, techniques and methods, on their own, and be able to successfully complete the requirements of the project.

Massood Towhidnejad, Embry-Riddle University, Dept. of Computing and Mathematics, Daytona Beach, FL 32114, [email protected]

0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 - 9, 2002, Boston, MA 32 nd ASEE/IEEE Frontiers in Education Conference F2G-1

Session F2G •

Provide students with the experience of working in a corporate environment. The experience of working in a corporate environment before graduation is an invaluable part of the undergraduate education. Some students gain this experience through the coop assignments, however, not all students are capable or qualified to spend at least one semester on coop assignment before their graduation. The senior project is set up in the fashion that provides students with a “simulated” corporate environment experience. The class is run like a small corporation, in which the instructor acts as a senior manager, and the students are required to deal with their manager, peers, and customer. THE P ROJECT

There are two major components associated with any types of project, one deals with the product that is being produced as a result of this project, and the second is the process that is used to develop the product. This section discusses both the product and the process for this project. The Product Several factors influenced the selection of the senior project, these are: • Large Multi-discipline product, one of the goals of this project was to require students to work on a product that requires development of several modules in different disciplines of computer science. The main reason for this goal is to require the student to divide a large problem into a number of smaller project, and identify the appropriate sub-discipline of computer science which best solve that specific component. Finally, students are required to integrate the smaller components in order to produce the final product. • Real problem and real customer, one of the goals of this project was to require students to work with a “real” customer. The main reason for this goal is to force students to use their (oral and written) communication skills to communicate with the audience who are not familiar with the technical computing jargons.

which they are currently register for. The system also contain additional information associate with student such as, personal contact information, the catalogue in which they study under, educational goal, and career goals. This system should be able to advise the student on what courses they should register for during the following semester. This advisement is given with consideration of the courses that have been taken or registered for up to the point of advisement, their corresponding grade points, the difficulty level of the courses, upcoming semester course offering, and other preferences of the students (i.e., educational goals, scheduling preferences). This system should be available to the students via Internet. This system should generate (recommend) a schedule for the upcoming semester, this information should be mailed (electronically) to the registration office for the actual registration.” A s you can see, this project requires three major components, these are: 1. A database component which holds information regarding the student, 2. An artificial intelligent component which is responsible for advising, and 3. A Graphical User Interface component that uses internet as its medium of communication between students, advisor, and records and registration department. The Process

The Personal Software process (PSP) was created by Watts Humphrey [5] to address the need for individual software engineers to acquire a disciplined and effective approach to writing programs. The philosophy behind the PSP is that an organization's ability to build large-scale software systems is dependent upon the ability of its individual software engineers to develop high quality small-scale programs in a disciplined, effective manner. The PSP is designed to help engineers organize and plan their work, track their performance, manage software defects, and analyze and improve their personal process. Since 1995, we have used [6] Watts Humphrey's Introduction to the Personal Software Process [7] to teach the material in our undergraduate curriculum starting at freshman year. During the sophomore year, students are required to take the first software engineering class, were they are introduced to the The following represents the problem statement concept of Team Software Process (TSP). TSP is created by defining the product’s requirement. Students use this Watts Humphrey [8], and is aimed at teams of individuals statement as the basis for their interaction with the customer who have already been PSP trained. The TSP provides a to define the requirements of the product. well-structured process for developing software, using teams “The university records and registration department is in multiple builds. Students in the senior project were in the process of modifying their advising and registration required to follow PSP and TSP concepts for their product process. Currently, these tasks are accomplished with a development. minimum level of automation, the senior project students are The class was organized as a small software asked to design and implement an automated advising and development organization, with instructor serving the role of registration system. The system is required to hold all the senior manager, and the team leaders run competing information associated with a student, including previously development teams. Each team consists of five members, completed courses and their associated grade, and courses in each serving one of the defined roles in TSP. In addition, 0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 - 9, 2002, Boston, MA 32 nd ASEE/IEEE Frontiers in Education Conference F2G-2

Session F2G students from the software testing graduate course were required to participate in the development of the product, by providing the software quality assurance function. The graduate students in the software testing class were also divided to five competing teams, were each team cooperate with one of the development team. The remainder of this paper describes the roles and responsibilities of the students in each course, and the interaction between the students in the two classes. Roles and Responsibilities As previously mentioned, students in the senior project class were responsible for the product development, while the students in the software testing class were required to provide the Software Quality Assurance (SQA) function. It was decided that the product would be developed in two builds/cycles (following the TSP model). The main emphasis of build one was on generation of the product’s requirement, and design document, followed by the development of the first prototype. The emphasis of the second phase was the development of the final product. The V development lifecycle model [9] was used during both builds.

system in build one) sections of the system and integration test. From the educational point of view, the main purpose of the build one was to allow the development team to work with a group of students who are familiar with the appropriate techniques and methodologies of the software testing. This provided an environment of learning from the peer, by shadowing and participating in the SQA activities as the graduate students perform it. In addition, students from both classes experimented with an integrated development and quality assurance environment that exists in some industry. Build two: During the build two, students from the graduate course provided the SQA function as an independent agent (an outsider). In this case, the senior project students (development team) were responsible, to perform all the SQA activities that were performed during the build one, by the SQA team. This meant the responsibility for the inspections, and modification to system test plan, integration test plan, unit test and their corresponding test cases. In addition, students in the senior project class were responsible for the execution of their test cases. On the other hand, at this point of time, students in the software testing class have learned additional, in most cases more powerful, techniques that they could use to evaluate the quality of the product during build two. During this build, the SQA team was responsible to perform the same functions, however, in his case it was for the purpose of verifying the development team activities (i.e., independent validation and verification). From the educational point of view, the main objective of build two was to teach the students in the testing team the capability of criticizing the work product of their peers, and do so in a professional manner, that does not offend their peer. For the students in the senior project, the goal was to learn to be criticized by their peer, and do not look at the criticism as a personal attack. In another word, we wanted to accomplish an ego less development environment. Of course another objective of the build two, was to provide the students in both classes, an experience with an independent development and quality assurance environment that exists in some industry. In addition, students in the senior project class were required to use the testing and quality assurance techniques that they learned from their peers during the build one, which is one more emphasis of lifelong learning environment.

Build one: During the build one, students from the software testing class, provided the SQA function as integrated members of the development team. In this case, members of the SQA team in cooperation with their corresponding development team participated in the requirement elicitation phase. The objective of the development team was to collect the requirements of the project, while the objective of the SQA team was to assure the testability of the product, this means making sure every requirement of the system is complete, unambiguous, and testable. As the development team generated the software requirement specification (SRS) document for the product, the SQA team in cooperation with the development team was responsible to perform a formal inspection of the document. In addition, the SQA team used the requirement specification document as the foundation for their system test plan with its corresponding test cases. During the design phase of the project, while the development team generated the formal Software Design Specification (SDS), the SQA team was responsible for the formal inspection of the SDS document. In the meantime, the SQA team used the SDS to produce the system integration test plan with their corresponding test cases. Finally, during the implementation O BSERVATIONS AND S UMMARY phase of the product, as the development team was generating the code for different modules of the system, the In order to monitor the interaction and behavior of the SQA team was responsible for the design of test cases that are used during the unit testing of the product. In addition, students throughout the project, the instructor attended some of the outside the classroom meetings between the two the SQA team was responsible for identification of critical groups. In addition, students were encourage to use e-mail code component, and performing formal code review on that as the preferred way of communication between the two component. Finally, the SQA team was responsible for group, and they were also required to include the instructor execution of the appropriate (completed portion of the 0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 - 9, 2002, Boston, MA 32 nd ASEE/IEEE Frontiers in Education Conference F2G-3

Session F2G on all email communications. A number of interesting observations were made as a result of this experience. The most interesting observation was related to the difference between the interaction of the two groups (development and SQA) during the build one and build two. Overall, during build one, the SQA team was viewed more as a partner, where both, development and SQA, groups are doing their best to reach a common goal, “getting the product out of the door.” On the other hand, during the build two, in most cases, students no longer recognized the “common goal”. During this build, the development team had the same goal, “getting the product out of the door”, however, the students in the graduate course goal was “to make sure that, there is no defect left in the product before it gets out of the door.” In most cases, there was an additional level of tension between the groups during the build two than build one. In one extreme case, the SQA team was viewed as an enemy, and it got to the point that the instructor has to intervene, and make sure students left their ego outside of the class. This was not a very surprising observation, since the same phenomenon is true in some cases in the industry. Another observation was related to the feasibility of incorporating the V model development lifecycle in the undergraduate project. What became obvious was the fact the in general, undergraduate curriculum does not pay appropriate attention to the issues associated with the quality of the product. In general, the undergraduate computer science curriculum does not require students to take courses associated with testing and quality assurance. As a result, students have a hard time understanding the roles and responsibilities of the SQA function, therefore, once they are faced with the existence of an SQA function, they may view them as “quality cops” or even worst “spies”. In summary, the above experiment provided and opportunity for the students in both classes to get an experience about what could face them once they graduate and join the work force. There was a wide range of comments from students, provided as part of the students’ end of the term evaluation. In one extreme one student commented “I am glad the hell is over”. However, in most part, majority of students were relatively satisfied with their experience. There was also a group of students, mainly from the graduate class, that praised the experiment. About six months after the experience, an undergraduate student sent comment praising the experience he got in the class. He mentioned, he is part of the development team which is interfacing with an independent validation and verification group, and the experience he gained through the senior project class have made it much easier to deal with his work environment. He added by saying, some of the other team members, fresh graduates, at his work place are having harder time to cope with the situation at hand. Several problems were observed as part of the experience. One of the problems relates to the fact that students typically wait until the last moment to complete an assignment. This caused a major problem during the build

two cycle, where the students in the senior project were not delivering the final deliverables before their deadline, and this left very little time for the students in the testing class to complete their assignment (final system test). This could be resolved, if the deadline for the senior project deliverables were moved forward, however, given the already crunched schedule in the senior project this is not feasible. Therefore, a better approach for the independent validation and verification of the final project (system test) could be to use the product generated by the senior project during the previous semester. The advantage of this approach is the fact that student in the testing class could start working on the final evaluation of a product before the end of the semester. Another advantage is that they will also learn to use the test plan generated by another group (students who have completed the testing class during the previous semester). The draw back of this approach is the fact that students in the testing class are forced to get familiar with an additional product. Another problem with this experiment is the fact that you need to offer the senior project and the testing class during the same semester. Also, you need to have both courses taught by the same faculty (our case), or have a very good coordination between both faculty. This may cause a major resource problem for the department. REFERENCES [1] Fenton, N., Pfleeger, S. L., Glass, R.L., Science and Substance: “A Challenge to Software Engineering”, IEEE Software, July, 1994. [2] Ford, G. and Gibbs, N. "A Master of Software Engineering Curriculum", IEEE Computer, September, 1989. [3] Jones, Capers, "Gaps in Programming Education", IEEE Computer, April, 1995. [4] Martin, Richard, et al., "Proceedings of the Workshop on Executive Software Issues", (CMU/SEI-89-TR-6), Carnegie Mellon University, Pittsburgh, PA. [5] Humphrey, Watts S., “A Discipline for Software Engineering”, Addison-Wesley, Reading, MA, 1995. [6] Hilburn, T. and Towhidnejad, M., “Integrating Personal Software Process (PSP) Across the Undergraduate Curriculum”, Proceedings of 1997 Frontiers in Education Conference, November 1997. [7] Humphrey, Watts S., “An Introduction to the Personal Software Process”, Addison-Wesley, Reading, MA, 1997. [8] Humphrey, Watts S., “Introduc tion to Team Software Process”, Addison-Wesley, Reading, MA, 2000. [9] Jorgensen, Paul C., “Software Testing a craftsman’s approach”, CRC Press, New York, NY, 1995.

0-7803-7444-4/02/$17.00 © 2002 IEEE November 6 - 9, 2002, Boston, MA 32 nd ASEE/IEEE Frontiers in Education Conference F2G-4