1
USING INDUSTRY-STYLE SOFTWARE ENGINEERING AND PROJECT MANAGEMENT IN A GROUP PROJECT
Jay-Evan J. Tevis and Kenneth Rouse LeTourneau University Longview, TX 75607 (903) 233-3343 [email protected] [email protected] ABSTRACT
This paper describes our approach for conducting a group project in a software engineering course. We organize students into an actual software development company and conduct activities that mimic real-world operations in that company. We have applied this approach to our group projects for the past four years with excellent results.
INTRODUCTION
Over the years as computer science departments added software engineering courses to their curriculums, they have also added a software development group project or capstone project course [1]. The goal of this project is for the students to work as a team to design and build a large software system for a real-world situation [2].
Because of the students’ lack of real-world project experience, they most likely will handle the group project as a typical software programming assignment (in this case a semester long one) rather than conduct it as an actual project that uses software
engineering and software project management [3]. (Note that throughout the rest of this paper we will refer to these two items as SE and SPM, respectively.)
When handled like a typical programming assignment, a group project would consist of a loosely-organized team of students getting some general direction on the software to build. The students would heroically attempt to build the software (while still figuring out what they are trying to build) and struggle to make it look like a well-designed and implemented software application by the end of the semester.
This approach produces a software application with four key weaknesses. First, it has not satisfied any baselined requirements (because none exist). Second, it has not
followed a baselined design (because none exists). Third, it has not been adequately tested because of the lack of baselined requirements and test cases. Fourth, it could not be built again the same way because of a lack of any project planning and project tracking and oversight of the time and resources to accomplish the project. In other words, the project would have used no SE and no SPM. Stated from another viewpoint, the software development effort would have been based only on the principles, theory,
2
and practices covered in a traditional computer science curriculum.
Pressman defines SE as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.” [4] Such a definition indicates that a software development project needs SE processes, methods, and tools. This includes software life cycle models, requirements gathering and analysis techniques, design methodologies, standards and metrics, specifications, formal reviews, and testing techniques. In addition, a software development project needs project planning, project tracking and oversight, requirements management, configuration management, and quality assurance.
Paulk and others first brought to light this need for SE and SPM in software
development when they published the software capability maturity model (SW-CMM) [5]. The key process areas at each of the five levels of this model indicate the need for projects to use practices beyond what are taught in computer science. These practices are needed if a company wants to build a quality product that meets user requirements, has a robust design, is adequately tested, and is finished on time and within budget.
In an effort to bring this synthesis of computer science, engineering, and project management into our SE courses, we have established a two-course sequence in SE. The first course begins by covering the SE process, the SW-CMM, and software life cycle development models. The course then covers object-oriented analysis and design for the software version of a board or card game. Each student writes a 15-page software requirements specification for the game, produces a UML-based design of the software, and then translates the requirements and design into a completed software application. In the second semester course, we cover software testing in the first three weeks. We then begin a six-week-long group software development project. After the project is done, the students use lessons learned from the group project to create a 20-page software development plan. The course concludes with an overview of software project
management techniques, using the group project as a case study.
This paper focuses on the group project portion of the second-semester course and how we use SE and SPM to conduct the project. The paper tells about the organization of a group project, the operation of a group project and the results from using this approach. The paper concludes with a summary and our plans for future work in this area. More information on how we conduct a group project and examples of the artifacts described in this paper are available on our website [7].
GROUP PROJECT ORGANIZATION
Our objective for the software development group project is as follows: given a software development problem and a software development group, the student will apply SE and SPM principles and practices in the various assigned roles required to complete the object-oriented analysis, design, construction, and testing for a software product.
3
On the first day of the group project, we present the students with an organizational chart for the company, a list of responsibilities to be fulfilled by each of the offices (i.e., teams) in the company, a task network for the organizational software development process, and a brief description of the software application that will be developed. We organize the students in the class into a software engineering directorate, which is hypothetically its own company or part of a large software development organization. The directorate is made up of teams that have specific roles to fulfill. If there are not enough students (or teams) to fulfill each role, then some students are required to take on two or more roles. We assign the roles based on three criteria: resumes submitted by the students before the project starts, each student’s individual performance on graded items in the first semester course, and the needs of the software engineering directorate. The director of the software engineering directorate is the course instructor. All team leaders in the directorate report to this software director. These teams include project management, configuration management, requirements management, quality assurance, software design, and software construction. There is also a customer liaison team that is staffed by one or more students from the class, but receives direction and reports to the director of the customer organization. The role of customer director is filled by one of the other instructors in the computer science department.
Specific students are appointed as the leaders for the teams. The team leader is the person who interacts personally with the software director, the project manager, and the leaders of each of the other teams. None of the team leaders reports to the project manager; they all report to the software director. Consequently, the project manager’s responsibilities are summed up in one statement: manage the project, not the people. The software director manages the personnel in the company through the team leaders.
The organizational structure of our group project focuses on the key process areas for a SW-CMM Level 2 organization [5]. Each of the teams in this organizational structure has specific responsibilities to fulfill. For example, one of the responsibilities for the project manager is to maintain the timeline (i.e., Gannt) chart over the life of the project by updating the status of all tasks as information becomes available.
The task network for the project follows a waterfall model. We use this model to show the usefulness of it in situations where requirements are well-defined and the risk of problems occurring is assumed to be low. If either of these criteria turn out not to be true during the project, then the students experience the limitations of this model.
We reduce project documentation to a minimum in order for the students to
experience the “process” of SE without getting bogged down in the “paper” of SE for a six-week group project. Consequently, we combine the most essential elements of the software requirements specification, the software test plan, the software test procedures, and the software test report into a single spreadsheet.
4
Formal reviews for the project are placed in the task network between each of the software development phases (i.e., analysis, design, construction, test, and delivery). These reviews provide a forum for public presentation and critique of the artifacts created during the current phase. They also ensure that the next phase of software development is not entered until the directors of the software engineering directorate and the customer organization both agree that the artifacts should be baselined.
THE GROUP PROJECT IN OPERATION
We select a proposed software application for the group project based on suggestions from faculty from other departments, students who have graduated and are now working in software development organizations, and ideas that we come up with ourselves. We strive to select a software application that has (or can have) well defined requirements, that contains features that the students have implemented before in some fashion, and that has value to a customer outside of the group project and the SE course.
The project timeline is six weeks long, with a possible seventh week if needed because of slippage of the review dates. The project manager puts together the initial timeline chart based on the project’s time constraints, the task network, and the responsibilities given to each team. The project manager then updates and maintains this timeline chart based on tasks submitted by team leaders and events that occur throughout the project. The configuration management team maintains a public website. This is where all timeline charts, requirements and testing tables, and baselined artifacts from the reviews are stored and are made available to members of the software engineering directorate. This website also has the documents containing the organizational chart, the task network, and the responsibilities assigned to each team [7].
In the requirements analysis phase, the students create a use case diagram, a problem-domain class diagram, a system-level state diagram, and an interface requirements
specification. In the design phase, the students add design classes to the problem-domain class diagram and identify the attributes and methods for each class. They also create an interface design description. In the construction phase, the students translate the design into source code. In the test phase, the students perform the test cases, note the results, and create a test report. In the delivery phase, the students provide the corrected source code, a software version description and a final class diagram. All of the artifacts from these phases are presented to the group, critiqued, modified, and baselined after the various formal reviews. They are then posted on the project website by the configuration management team.
RESULTS FROM PAST GROUP PROJECTS
We have adapted the group project each year since first experimenting with the two-semester course sequence and the group project approach in the spring and fall two-semesters
5
of 2005. We made these adaptations because of the number of students enrolled in the course, the lessons learned from previous group projects, and the feedback from the students who took part. For instance, we have found that the software engineering course needs to be held three times per week in order to have some flexibility in scheduling the formal reviews in the group project. Also, the project needs to have a written policy on the use of laptop computers during the class meetings [6].
In addition to the items above, we have found that the instructor needs to sincerely and completely fill the role of software engineering director. This includes making decisions on the direction of the project as it occurs, approving changes in the schedule, baselining project artifacts, handling dissatisfied employees in the company, and reassigning team leaders or members if a team fails to fulfill its responsibilities or needs more help. Our approach to assigning students to the various teams and the responsibilities given to each team has changed over the past four years. Asking a student which team he/she would prefer, and looking at the student’s history in other computer science coursework resulted in a better match of students to teams. This approach also created a more robust software engineering company.
Above all, the success of the projects was made possible by the software process, the defined team roles, the organizational skills of the project manager, and the performance of the team leaders. Without these elements, the projects would most likely have failed. The experience that each student gained from a group project depended on the role of their team. The project manager learned about the challenges of some teams falling behind on their tasks while other teams completed their tasks on time or ahead of schedule. The requirements management team learned about the effort it took for the team to gather and document user requirements. The design team learned about the chore of designing a software application based on pages of user requirements. The
construction team learned about the difficulties of translating someone else’s design into source code. The quality assurance team learned about the importance of well-defined and quantified requirements and well-written test cases when they performed validation and system testing on the software.
In the formal reviews, the students learned communication skills by speaking in front of a group. They learned travel skills from planning a hypothetical trip to a different venue for each review. They learned coordination skills from working on a team and with other teams. They learned leadership, followership, and delegation skills working as a team leader or a team member. They learned time management skills by following a timeline chart and seeing the consequences of getting behind in their assigned work. They experienced the dynamics of a formal review as students with specific team concerns made comments, asked questions, presented arguments for doing something a certain way, and provided counter arguments on why not to choose an approach. They also learned the art of compromise as they strove to resolve conflicts with other students and reach consensus on issues.
6 CONCLUSION AND FUTURE WORK
A group software development project should be more than just a semester-long programming assignment. When properly performed, it can be an opportunity for students to learn, experience, and use industry-style software engineering and software project management techniques in the creation of a software product.
The processes, methods and tools of software engineering and software project management can bring both order and discipline to the otherwise frequent mayhem of group projects. They can also bring job realism into the project as students experience some of the responsibilities, stress and elation that come with project work in industry. As for the future, we plan to continue incorporating industry processes, methods, and tools into the software engineering group project through feedback from students and input from industry professionals. We are also taking the first steps toward including accounting students in the software engineering group project planned for next year. These students could provide a prediction of project costs, establish a budget, track the actual dollar costs of the software development effort as the project proceeds, and bring the cost data into the decision-making discussions of the project.
REFERENCES
1. UCOSP, Undergraduate Open Source Projects, http://ucosp.wordpress.com/. 2009. 2. Guo, J., Group Projects in Software Engineering Education, The Journal of
Computing Sciences in Colleges, 24, (4), 196-202, 2009. 3. Spolsky, J., Capstone Projects and Time Management, www.joelonsoftware.com/items/2009/10/26.html, 2009.
4. Pressman, R., Software Engineering: A Practitioner’s Approach, New York, NY: McGraw-Hill, 2009.
5. Paulk, M., et al, CMU/SEI-93-TR-24, Capability Maturity Model for Software, Version 1.1, Pittsburgh, PA: CMU/SEI, 1993.
6. Wuorio, J., 7 Rules for Using Laptops in Meetings,
www.microsoft.com/smallbusiness/resources/technology/hardware, 2009. 7. Tevis, J., Software Systems and Software Engineering,
http://www.letu.edu/people/jaytevis/Software-Engineering/software-engineering.html, 2009.
