The coordination in a software engineering project is a critical issue to deliver a successful software product, while the constraints of time, functionality and budget are considered. An approach to address this problem consists in the use of process modeling techniques to capture, evaluate, and redesign the software process. The appraisal in a process-based view of software projects made in the software engineering course at CICESE, helped to discover the weakness and strength of the process. This paper shows the evaluation of laboratory sessions, the steps to improve software development, and preliminary results of process enactment in the analysis phase of the software project.

Keywords: Software engineering, software process, process modeling, project-based software engineering teaching.

Software engineering has the purpose of generating and maintaining software systems within the time restrictions, functionality, and cost agreed with the client. The goals of this technological discipline are to improve the quality of developed products and to increase the productivity of software engineers. The degree of formality and the time assigned to a software project, vary according to the size and complexity of the product that will be developed.

As the complexity and the size of the project increase, the communication between the software engineers, administrators, and clients also increases. This makes the coordination among them difficult (Fairley, 1985; Kraut and Streeter, 1995). In the educative scope, the research of Upchurch and Sims-Knight (1998) indicates that the students that have just got their bachelor degree, in general, ignore how to apply the principles of software engineering to the development of products by means of teamwork. We are concerned about this issue, because effective coordination is essential to obtain a successful software system.

There are many strategies used in teaching software engineering. Some of them are based only on a bibliographical review, without applying the knowledge that was acquired in the development of a software project (Tomayko, 1987). Other techniques are based on teamwork and their main objective is that each student gains experience during the development of a product for a real client. Students make decisions according to the circumstances and available resources, and face the aspects of typical communication and coordination of group work (Upchurch and Sims-Knight, 1997).

A recurrent problem is that the success of projects in these courses depends on the ability and experience of the instructor to manage them. It is likely that different instructors obtain different results with the same model. Similarly, the same instructor may obtain different results with different groups of students. Furthermore, in some of these courses, instructors usually emphasize the importance of a good architecture and implantation, without integrating the aspects of quality assurance or management. These problems suggest that many software engineering projects have deficiencies in their software development process (Collofello, Kantipundi and Kanko 1994).

The software-development process is the collection of activities, methods, practices and transformations used to develop and maintain software and associate products (Paulk, M. C., Weber, C. V., Curtis, B. and Chrisis, M. B., 1995). A well-defined and effective process facilitates the development of a software product, and increases the productivity of the development group (Clark, 2000). In fact, modeling and executing a software development process, are some of the main research areas in software engineering (Maurer and Kaiser, 1998). Their purpose is to propose solutions to problems in the organizational context by applying coordination and integration technologies (Warboys, Kawalek, Robertson, and Greenwood, 1999).

Diverse approaches have been used in the search for quality in teaching process-based software engineering. For example, one of them is to give students the requirement specification document. Its intention is that students carry out the indicated work and cover all the stages of the product development. In this case, the process is described in textual format. (Upchurch and Sims-Knight, 1998).

Other researchers have modeled the software development process using object-oriented techniques to understand in detail the complexity of the process (Oktaba and Ibargüengoitia, 1998). They have also used standards and accepted methodologies to introduce the software development process. (Robillard, 1998; Jaccheri and Lago, 1997; and Mayr, 1997). Some experts recommend the integration of processes and group work to design software engineering curricula (Bagert, Hilburn, Hislop, Lutz, McCracken and Mengel, 1999).

The Center for Scientific Research and Higher Education of Ensenada, CICESE, offers the required course Programming Engineering and Methodology (software engineering), within the computer science masters' program. The features of the course are suitable to generate an improving process project. This article describes the application of process-modeling techniques for the practical part of the course. This is useful to identify the strengths and weaknesses of the process used during the course. It also describes the actions used to mitigate detected problems. Section two explains the methodology this work used to evaluate the process, proposes improvements, and provides a visual representation of it. The third section presents the steps that were followed during the study of a development process. This process was based on the stages of a process improvement project. It also explains how to adapt it to satisfy specific requirements for the case under study. The fourth section reports the general characteristics of a laboratory session during the course. During that session, students develop a software system and point out deficiencies detected in the coordination of activities among participants. The fifth section indicates the actions that were taken to solve the detected problems. The sixth section presents the results we achieved after applying the improved process. Finally, section seven gives a description of some research directions to improve the process and presents some concluding remarks.

The methodology that we use to improve the process in the software engineering course considers the following phases: definition, capture, evaluation, redesign, and enactment (Wastell, White and Kawalek 1994; Caputo, 1998; Arthur, 1992; Sommerville, 1995; Warboys et al., 1999). The definition phase establishes the objectives of a process, limits its size, shows the main inputs and outputs, indicates the clients who receive the benefits, as well as the input suppliers. The representation and capture phase models the process in a detailed way. It gathers the information from the interviews, document reviews, and plans. It uses this information to generate a graphical representation of the process. The evaluation phase analyzes and evaluates the process to find its weaknesses and inefficient or ineffective components that jeopardize the fulfillment of process goals. The results obtained from the evaluation facilitate the redesign of the process. The process redesign uses a comprehensible modeling language for users. The organization implements the redesigned process to verify that it really satisfies the established goals.

Process modeling is based on four views: functional, behavioral, organizational, and informational (Curtis, Kellner and Over, 1992). The functional view considers the activities of the process that are being carried out and the flows of the main documents. The performance or behavioral view observes the duration of each activity, as well as the way they are achieved (conditions, sequence, and iterations). The organizational view of the process focuses on the physical place within the organization, where the activities are performed. It also centers its attention on the person who has the responsibility to carry out these activities. Finally, the informational view approaches the contribution of documents in the communication and coordination among roles.

There are many ways to describe a process; even a graphical language can be used to describe it. Graphical models help to represent a process, they reduce its complexity, allow common understanding among participants, and allow the study of alternatives (Miers, 1996); also, graphical models can be used to influence, control, and manage events that take place in the real world (Warboys et al. 1999). In the organizational context, graphical models allow the capture of the process's behavior which facilitates its analysis; they also act as knowledge deposits of the organization, which facilitate learning about the organizations and their processes (Ould, 1995).

This paper uses the Role Activity Diagram (RAD) technique to model the software development process. This technique describes the process from the role point of view (Ould, 1995). Those who play the roles, execute activities and make decisions in agreement with the organization rules; they can carry out their activities in parallel and interact with other roles to reach the process goals. Often, these activities include the use or generation of information and documents. In most cases, the modeled process leads to an immediate identification of redesign options (Miers, 1996).

The success of the project in the course depends on the collaboration among students. It is essential to coordinate the participant's efforts according to their positions to fulfill the goals of the course. The study of the interactions, activities, positions, and documents that take place during a project allows improving the software development process.

The objective of this investigation is to systematize the software development process that we use in our software engineering course. To improve the process, it is necessary to identify the useful actions and to determine the weaknesses of the process. Although there exist many approaches to solve software engineering problems, the improvement of processes seems to be an alternative to increase the productivity of software engineers and to generate products of better quality (Hersleb, Zubrow, Goldenson, Hayes and Paulk, 1997; Clark, 2000).

To improve the process in the course, the software engineering goals (Fairley, 1985; Pressman, 1993) were considered to release a product with the functionality requested by the client, the required quality, and within the stipulated time. Thus, a successful software development project in the course is the one that fulfills these goals. This study is based on the stages of a process-improving project. Table I summarizes the application of this framework to the software engineering course.

Table I. Stages of the software development process and the improvement of the activities related to the analysis phase of the project

The definition stage handles the software development process as a unit that integrates the following activities: quality assurance, management, and product engineering. The investigation of the software development process starts when each student is assigned a role. The investigation ends when the client receives a functional product. The first stage of the study determines the status of the process and generates models of the activities and interactions of each agent. The second stage evaluates the software development process and proposes improvements for it. This stage also sets the process in motion and it is based on the models generated during the redesign of the system analysis phase.

The capture and representation stage focuses on knowing about the present status of the process through different sources of information. For the particular case of this investigation, the sources of information are the documents generated during the projects of previous courses, interviews to participants, and the review of course notes:

a. Documentation of former projects. The software engineering course has been offered at CICESE since 1994. First year masters students developed the former projects in this course. The two projects in which the software development process was based on are DASIS (January to April) and GENSIS98 (September to December), both developed in 1998. We chose these projects because all the information generated during the projects is available in electronic format, the documents are organized according to each role, and they have a good structure. Unlike previous projects, the chosen projects capture the profile of each agent in the software project and in the documents generated during the project. Another factor that was considered is the similarity between the projects; both projects were developed using the same platform, they used the same design and analysis methods, and the types of technical reviews had the same structure. In addition, the first author participated as a student in project DASIS and as an assistant during the second project. The information of the projects corresponds to: 1) strategic planning (mission, vision, values, and rules). It is carried out at the beginning of the course, 2) description of the profile of each agent (goals, activities, relation with other participants, support tools, and bibliography); and 3) documents associated with the project (requirements, software specifications, design, modules of code, user manual, working plans of each of the functions, minute of technical meetings, activities status reports, among others).

b. Semi-structured interviews. A script was prepared to interview students who occupied a position in projects DASIS or GENSIS98. The design of the script incorporates the analysis of the profile of each agent and the information based on the bibliography of this technological discipline, rather than on practical experience (the students at the beginning of the course gathered this information). A sample of 10 students, out of 28 students (14 in each project) was taken, each of them playing a different position. In this way, the information about the 10 positions available in the course was obtained. The interviews took place from July 23rd to the 29th, 1999. The duration of each interview was approximately one hour. The interviews discovered the activities that were actually performed, their order of execution, and the interactions with other positions. The objectives of the interviews were to verify and complete each agent profile. The interviews also included questions about the problems each agent's had to face and asked suggestions to improve the laboratory part.

c. Theoretical documentation of the course. We analyzed the material presented in the theoretical part of the course, the bibliographical references, and the sequence of the subjects. The objective of this analysis was to verify that the course covered all the topics that are required to carry out the activities in the lab. The subject that was reviewed with a higher degree of detail was system analysis, since it is essential to redesign the process.

The capture and representation of the process is based on the analysis of the sources described in the previous paragraphs. They allow the generation of several models to understand the development process. The support diagrams that we used to focus in the different perspectives of the process were: The rich picture. It gives a detailed image of the problem (Warboys et al., 1999; Wastell et al., 1996); 1) The general diagram of the software development process. It groups the activities of quality assurance, development, and management areas (Donaldson and Seigel, 1997). 2) The transition state diagram. It identifies the dynamic behavior of the process. 3) The role-activity-document matrix. It identifies the responsibilities of each position, the relations among them and the documents that are generated or used in each activity.

The debugged information of the activities conducted by each agent were represented in RAD diagrams. These diagrams consider the interaction that took place among agent and documents or products that were generated during the life cycle of the project. The approach we used to represent the process was based on the activities performed by each agent (Ould, 1995; Kawalek, 1994).

The evaluation and the redesign of the process focused on the activities that are performed in the analysis phase of the life cycle of a software project. We deal with this stage because it is the first phase of the project and the students are not yet familiarized with the process that is being used. In addition, a previous study indicates that considerable time is dedicated to this phase of the project (34% in DASIS and 46% in GENSIS98) and the activities of coding and system tests are neglected (García Mireles and Rodríguez Jacobo, 2000).

We used the basic bibliography of software engineering (Sommerville, 1995; Pressman, 1993; Fairley, 1985) and specialized literature (Dorfman and Thayer, 1990; Ayer, 1992) to evaluate the analysis process. It was very useful to review the subjects related to interview questionnaires, requirements identification and classification, content and format of documents for client's requirements and software specifications. In addition, we analyzed material related to the management of the above subjects: quality criteria applied to this stage of the life cycle of the project, and the relation of these necessities with project planning and configuration management.

The redesign of the process was the result of the previous stage. It shows the information in RAD. This improvement phase of the process is based on the analysis stage of the traditional life cycle (waterfall) of a software project. It is divided in three parts, in agreement with the objectives of this phase of the project and with the requirement management stage: preparation of the requirement document, validation of this document by the client, and preparation of software specifications.

The new models generated for the system analysis stage were presented to two students involved in these activities. They had previously occupied the positions of analyst and quality control engineers of the evaluated projects. We had some informal talks with them (at the end of August of 1999 with a duration of 30 minutes, approximately) to validate the clarity and the complete redesign of the process. We explained to them the purpose of the model and the meaning of each graphical element. According to their perception of the development process, they indicated that the model was appropriate.

The goal of model generating is to execute the process. The improvement of the analysis process was applied during the period September-December of 1999, in the software engineering course. Fifteen new students of the masters program participated in this course. A lecture regarding the software development process was presented and the models were given to all the students, so they became familiar with the activities related to systems analysis. After the class, an informal interview was done to three of the students that were directly involved in the activities at this stage (requirements engineer, system architect, and quality control engineer). At the end of the course, we prepared an opinion questionnaire and interviewed the students responsible for the analysis stage in the course. Its purpose was to know the impact of the process approach in the course.

• The developed system's date of delivery is regulated by the school calendar (approximately 3 months).
• The students attend other courses (three, in average) during the same period.
• Some students have not taken previous courses related to this technological discipline. · The analysis methodology and object oriented design that is used is the Unified Modeling Language (UML).
• The development platform for the software system is the World Wide Web (WWW); for this reason, students must be familiar with the programming languages focused on this platform.
• It is required that the participants generate a centralized repository of information in the WWW platform.
• In addition, they are provided with e-mail accounts to support electronic communication.

The evaluation of the resulting software process model and the comparison of the activities performed by each position allow for distinguishing the problematic areas of the process that is used at CICESE. In addition, the interviews indicate an absence of standards, a lack of reliable information and updated bibliographical references, deficient hardware and software resources, and an excess of formal reviews. These deficiencies negatively impact the project's calendar and delay the release of the software system.

Although the software development process model was generated with the information of the practical part of the software engineering course, the deficiencies also affected the theoretical part. The update of the theory consisted of changing the order in which the topics are presented, according to the order of the stages in the software project. Also, sessions of process engineering were added to help students to understand the models that are presented in the lab.

The results of the interviews and the evaluation of the generated models showed scarce visibility in the analysis phase of the project. By such reason, the theory of systems analysis was emphasized: the essential aspects to determine requirements and specifications and their management during the life cycle of the project, quality attributes that are reviewed in the documents produced during the analysis stage, and the types of technical reviews that can be applied.

Finally, recent bibliography about analysis methods and techniques used in software engineering was provided to the students. This bibliography is organized according to class topics. Between two and five essential references for each topic presented in class were provided. Also an additional bibliography was included to help students to understand the activities assigned to their positions.

In the practical part of the course, the improving strategy implies redesigning the sub-processes that correspond to the analysis stage, because of the impact this phase has in the development of the software system. In order to verify the precision of the generated models, participants of the previous courses validated them. In the new proposal, the responsibilities of the analyst were assigned to the requirement engineer and the architect of the system. The goal of the requirement engineer is to identify the requirements that the software system must satisfy. Afterwards, he has to draft the document of requirements. In this stage, a good communication with the client is crucial. The goal of the architect of the system is to propose a solution to the necessities of the client. This solution is represented in a system analysis language (UML).

The generated models combine the tasks that are performed during the analysis stage of the project and the interactions that are carried out among participants. The models allow the creation of the requirement document, the validation of requirements, and the construction of the specification of the software system (see Figure 2). With this new process definition, students have a better understanding of their activities, the products they must provide to their teammates, and the products they must receive. The processes are divided in roles. A role involves a set of actions that are carried out by an individual or a group within the organization. Additionally, a role includes the logic that controls the actions according to the rules of the organization. Also, a role has the basic resources to achieve its activities (Ould, 1995).

Figure 2. RAD describing the elaboration of requirement document

Other important aspects in process redesigning are the documents utilized as inputs or outputs for the activities indicated in the models (Curtis et al., 1992). The evaluation of documents used in this phase of the project, allowed the elaboration of standards for the client's requirement document and the document of specifications for the software system. A guidebook was developed to conduct the first interview with the client, as well as a list of quality attributes to review in the requirement document. Sommerville (1995) emphasizes the importance of the documents generated during the software development project, since they are the only tangible way to represent software in early stages of its evolution. Humprey (1989) indicates that the standardization of documents in the development process helps to reduce the training problem and facilitates the verification of the defined quality criteria.

A project of process modeling does not end with the redesign of the process, it requires training its users and evaluating its performance with the new changes. Besides the addition of the process engineering lectures to the theoretical part of the course, consultation was also provided to the students involved in the analysis stage. The idea is to answer their questions regarding the use of the process models and the standard documents. Without the suitable training, the effects of the updating of the process degrade its quality, rather than generate an effective and efficient process (Sommerville, 1995).

The improvements of the model were applied in the period September-December of 1999, in the course Programming Engineering and Methodology. Fifteen students participated in the course, all of them in their fist year of the masters program at CICESE. The strategies indicated in the previous section were achieved. At the end of the trimester, three students were interviewed (requirements engineer, system architect, and quality control engineer). They were chosen because they were in charge of executing the activities described in the redesigned models for the system analysis stage. During the interview, each student expressed his/her perception of the course through a questionnaire (Table II). The questionnaire has nine questions that are marked in a five-level Likert scale (1 is strongly disagree and 5 is strongly agree). The questionnaire focuses on the following topics: consistency between the process model and the actual activities of the project, application of standards, and training on processes.

Table II. Results of the opinion survey applied to three students on the process approach of the programming engineering and methodology course

Table II shows promising results when the new process approach is used in the course. Most of the marks are in the categories "agree" and "strongly agree". It is normal to find differences in the degree of detail between the modeled process and the real activities of the project. Caputo (1998) indicates that the goal of the improvement of processes is not to create a perfect process, but generating processes with better performance. In fact, Warboys et al. (1999) point out the differences between generic processes and adapted processes. In the study, it is fair to consider that the employed model has the fundamental elements to fulfill the goals of the process. However, due to the nature of the software-engineering course, the model is neither adapted to individuals and machines to carry out the process, nor to the particular characteristics of the project developed by the students. This could be one of the reasons why some marks are in the category "undecided".

It is a good idea to give special attention to the documents that are generated during the analysis stage. The results of the interviews indicate that the description of each part of the requirement and specification document is not clear enough. In addition, they indicate that the tool that generates diagrams in UML language can be integrated with a text processor to facilitate the generation of the software specification document.

a. Consistency between the process model and actual activities. Students indicated that diagrams were useful to know the activities associated to their positions. The diagrams allow students to easily visualize the activities that they are carrying out and focus their efforts to fulfill their goals. The degree of detail presented in the models was appropriate, since it allowed determining subsequent activities, without specifying a particular technique to execute them. The models presented in the course accomplish what Miers (1996) established: that a good process definition must focus in its essence, reflect the real world, and handle its complexity. The models also satisfy the requirements indicated by Ould (1995). He suggests that a good process description is the one that communicates in detail the activities of those who carry them out. The description must be precise enough to allow a conformity evaluation. Warboys et al. (1999) also express that RAD allows the description of complex behaviors, in a highly legible way, and permits the appropriate capture of the rules of the organization.

b. Standards in the project. The participants mentioned that the standards were a good guide to elaborate requirement and specification documents, and served as reference in the review of this type of products. This result corroborates the work of Humprey (1989), which establishes that standardization helps to reduce the training problem. Nevertheless, students suggested changing the order of some sections in the documents to improve their presentation. They also requested a complete written example to use it as a guide.

c. Training. The lectures about process engineering helped students to understand the general context of the development of software systems, although they requested the process models for each position in the company. They considered that consultation outside class allowed them to expose, in a relaxed way, the difficult aspects of the activities that they were performing and it was helpful to direct their efforts to develop the software system.

The participants appreciated the importance of sharing information in a collaborative project and identified the importance of software processes to guide the team and to make the process visible. They realized that the costs and benefits of the teamwork and understood that a software development project is not only the generation of code in a programming language.

This work presents the problem of coordination of efforts of a group of participants in a software development project. It proposes a way to mitigate this problem from a process perspective in a software engineering course. Additionally, it presents a general description of the course Programming Engineering and Methodology that is offered at CICESE, the stages of the process modeling project, the interactions, activities, roles, documents, and goals. All these parts comprise the software development process of the practical part of the course.

It was observed that the process modeling techniques are effective tools to visualize processes. They allow identifying specific problems of the analyzed software projects and detect the process areas that can be improved. In this work, the models isolated the topics related to the system analysis phase, which facilitated the update of the subjects in the theoretical lectures of the course. The models also served as a guide to redesign the processes that belong to this stage of the project.

The described models helped students to understand their responsibilities in the process and allowed them to focus their efforts towards the activities that are significant in the project development. A good understanding reduces the number of interactions between the students and the instructor. The preliminary results, using redesigned processes, suggest that modeling is a powerful tool to train the participants of the project. These models facilitate the collaboration among members of the group because they explicitly define the types of interaction that exist in each development stage of a software system. Students do not have to investigate the activities that correspond to their positions, nor the positions they have to interact with during the process. They only need to understand how to perform their tasks and how to adapt them to the software development project in which they are working.

At the moment the essential processes of the second level of the Capability Maturity Model (CMM) of the Software Engineering Institute (SEI) are considered to improve the course. These processes are: requirement management, project planning, project tracking, quality assurance, and configuration management (Paulk et al., 1995). These essential processes will serve as a guide for the following course. Although the initial results indicate that process modeling is a useful tool for students (they learn the activities they must execute, especially when they have no experience in the area), it is necessary to test this model in graduate and undergraduate courses to corroborate these results.

After knowing the virtues of these models, a second step is to extend them to a distributed development environment, where students are in different geographic localities. In this environment, the research will focus on the interfaces that will have to exist in the process to work properly. Furthermore, software tools will be reviewed and recommended to support communication and coordination.

Arthur, L. J. (1992). Improving software quality: insider's guide to TQM. New York: John Wiley & Sons.

Ayer, S. (1992). Documenting the software development process: A handbook of structured techniques. New York: McGraw-Hill.

Bagert, D. J., Hilburn, T. B., Hislop, G., Lutz, M., McCracken, M. & Mengel, S. (1999). Guidelines for software engineering education version 1.0. (Technical report CMU/SEI-99-TR-032 ESC-TR-99-002). Pittsburgh, PA: Carnegie Mellon University, Software Engineering Institute.

Caputo, K. (1998). CMM Implementation guide: Choreagraphing software process improvement. Reading, MA: Addison Wesley-Longman.

Clark, B. K. (2000). Quantifying the effects of process improvement on effort. IEEE Software, 17 (6), 65-70.

Collofello, J. S., Kantipudi M., & Kanko, M. A. (1994). Assessing the software process maturity of software engineering courses. In Proceedings of the 25th SIGCSE Technical Symposium on Computer Science Education (pp. 16-20). Phoenix, AR: ACM Press.

Curtis, B., Kellner, M. I. & Over, J. (1992). Process modeling. Communications of the ACM, 35 (9), 75-90.

Donaldson, S. E. & Seigel, S. G. (1997). Cultivating successful software development: a practitioner's view. Upper Saddle River, NJ: Prentice-Hall PTR.

Dorfman, M. & Thayer, R. H.. (1990). Standards, guidelines, and examples on system and software requirements engineering. Los Alamitos, CA: IEEE Computer Society Press.

Fairley, R. (1985). Ingeniería de software. (A. Sánchez & P. L. Flores-Suárez, Trans.). México: McGraw-Hill. (Original work published 1985).

García Mireles, G. A. & Rodríguez Jacobo, J. (2000). Manual de procedimientos para la elaboración del documentos de requerimientos en el desarrollo de software (Technical report CICESE CTCCT2001, serie Electrónica y Telecomunicaciones). Ensenada, B. C.: CICESE.

García Mireles, G. A. & Rodríguez Jacobo, J. (2000, June). Propuesta para mejorar la enseñanza de la ingeniería del software basada en proyectos. Poster presented at Congreso de Educación Abierta y a Distancia (CEAD 2000). Ensenada, B. C.: ANUIES-UABC-CICESE.

Herbsleb, J., Zubrow, D., Goldenson, D., Hayes, W. & Paulk, M. (1997). Software quality and the capability maturity model. Communications of the ACM, 40 (6), 30-40.

Humphrey, W. S. (1989). Managing the software process. Reading, MA: Addison-Wesley.

Jaccheri, M. L. & Lago, P. (1997). Applying software process modeling and improvement in academic setting. In Proceedings of the 10th Conference on Software Engineering Education and Training (pp. 13-27). Virginia Beach, VA: IEEE Computer Society Press.

Kawalek, P. (1994). Comments on the use of RADs in case studies. Available: ftp://ftp.cs.man.ac.uk/pub/IPG/pk94.zip (June 10, 2000).

Kraut, R. L. & Streeter, L. A. (1995). Coordination in software development. Communications of the ACM, 38 (3), 63-81.

Licea, G., Rodríguez, J. & Favela, J. (1996). Evolución de procesos de desarrollo en la enseñanza de ingeniería de software. In Memorias del V Congreso Iberoamericano de Educación Superior en Computación (pp. 223-231). México: Facultad de Ciencias, UNAM.

Maurer, F. & Kaiser, G. (1998). Software engineering in the internet age. IEEE Internet Computing, 2 (5), 22-24.

Mayr, H. (1997). Teaching software engineering by means of a "virtual enterprise". In Proceedings of the 10th Conference on Software Engineering Education and Training, (pp. 176-184). Virginia Beach, VA: IEEE Computer Society Press.

Miers, D. (1996). Use of tools and technology within a BPR initiative. In C. Coulson-Thomas (Ed.), Process re-engineering: Myth and reality (pp.142-165). London: Kogan Page Limited.

Oktaba, H. & Ibargüengoitia, G. (1998). Software process modeled with objects: Static view. Computación y Sistemas, 1 (4), 228-238.

Ould, M. A. (1995). Business processes: Modeling an analysis for re-engineering and improvement. Chichester: John Wiley and Sons.

Paulk, M. C., Weber, C. V., Curtis, B. & Chrissis, M. B. (1995). The capability maturity model: Guidelines for improving the software process. Reading, MA: Addison-Wesley.

Pressman, R. (1993). Ingeniería del software. Un enfoque práctico (3rd ed.),.(C. Cervigon & L. Hernández Yáñez, Trans.) Madrid: McGraw-Hill. (Original work published 1992).

Robillard, P. N. (1998). Measuring team activities in a process-oriented software engineering course. In Proceedings of the 11th Conference on Software Engineering Education and Training. Atlanta: IEEE Computer Society Press.

Rombach, H. D. (1990). Software specifications: A framework. In M. Dorfman & R. H. Thayer (Eds.), Standards, guidelines, and examples on system and software requirements engineering (368-407). Los Alamitos, CA: IEEE Computer Society Press.

Sommerville, I. (1995). Software engineering (5th ed.). Harlow: Addison Wesley.

Tomayko, J. E. (1987). Teaching a project-intensive introduction to software engineering (Technical report CMU/SEI-87-TR-20 ESD-TR-87-171). Pittsburgh, PA: Carnegie Mellon University, Software Engineering Institute.

Upchurch, R. L. & Sims-Knight, J. E. (1997). Designing process-based software curriculum. In Proceedings of the 10th Conference on Software Engineering Education and Training (pp. 28-38). Virginia Beach, VA: IEEE Computer Society Press.

Upchurch, R. L. & Sims-Knight J. E. (1998) . In support of student process improvement. In Proceedings of the 11th Conference on Software Engineering Education and Training. Atlanta: IEEE Computer Society Press.

Warboys, B., Kawalek, P., Robertson, I. & Greenwood, M. (1999). Business information systems: A process approach. London: McGraw-Hill.

Wastell, D. G., White, P. & Kawalek, P. (1994). A methodology for business process redesign: Experiences and issues. Journal of Strategic Information Systems, 3 (1), 23-40.