SOFTWARE ENGINEERING TEAM STUDIOS. Jaime Niño Computer Science, University of New Orleans New Orleans, LA

Transcription

1 SOFTWARE ENGINEERING TEAM STUDIOS Jaime Niño Computer Science, University of New Orleans New Orleans, LA ABSTRACT Training of students on software engineering methods and practices demands more than the development of a project by a team. It demands effective training and monitoring on the software process, process tracking and team dynamics. Furthermore, lack of a dedicated space for team activities acerbates software development by teams and does not foster team effectiveness. We established a set of Software Engineering Team Studios with the vision to provide an environment in which to bring to focus issues that arise in the development of software by teams and which allows us to put into practice lessons learned in the classroom on software engineering methods and best practices. INTRODUCTION One of the topics in a software engineering course, among others, is the teaching of methods for the software processes, project development and tracking by teams as well as team dynamics. With funds provided by the Louisiana Board of Regents, the department of Computer Science implemented 4 software engineering team studios. The Software Engineering studio s vision is in par with the Department s effort to provide students with practical educational experiences with the goal to enhance the learning and understanding of complex and abstract issues presented in a classroom setting. Specifically the overall objective of these set of studios is to provide an environment for the training of future software engineers in the software process and the life-cycle phases sustained during the development of software products by teams of programmers. In tandem we aim to provide an environment for software development by teams and team dynamics. A software engineering team consisting of three-four students will have access to a studio where all team activities can be carried out in an environment where such activities are best supported. In the rest of the paper we provide the motivation for such environment as well as a description of the actual laboratory facilities implemented. We also include an initial reaction from part of the students and finish the paper with a look into the future of these facilities. NATURE OF COMPUTING SYSTEMS Computer systems and their associated software have become immersed in all facets of society: in government, banking and finance, education, transportation, entertainment, medicine, agriculture, law, down to our own personal lives. The number, size, and application domains of computer programs have grown dramatically; as a result, hundreds of billions are being spent yearly on software development, and the livelihood and lives of most people depend on the effectiveness of this development [MB97]. As a consequence there has been increasing demand for

2 engineering professionals who can develop high-quality, cost-effective software systems. Through the years the complexity of these systems have steadily increased as well, to the point that software systems cannot be produced any longer by a single engineer in his/her garage, but rather by a team of engineers working in tandem. [HW95] Software engineering is a uniquely human activity including the customer, a software development team and associated staff support [HW95, MB97]. This activity relies fundamentally on two factors communication and teamwork. Communication of desires about a product from part of the customer to the team, plans and ideas from part of the designers to the implementors, and communication of implementation ideas by implementors in the final product which must embody the result of the 3 levels of communications. Team work accomplished by the implementors, that is, the managers and programmers. Moreover there are no self-enforced laws, from nature or software engineering, to help us in the validation of wishes, plans, and implementation ideas. Hence researchers in the field continually develop new forms of communication to help customers and software teams via problem specification languages, analysis/design languages, and better programming tools among others. In addition to these, we ought to enhance the effectiveness of software teams. In this aspect, one factor to be considered is the physical environment and its effects on team member communication and overall team effectiveness. SOFTWARE ENGINERING IN COMPUTER SCIENCE DEPARTMENTS It is our contention that software engineering students are not provided with the proper facilities to put into practice the lessons presented in the lectures. As Barry Boehm says [HW99] Software engineering is fundamentally a contact sport. In software engineering as in rugby, no amount of theory about how to succeed in a scrum is going to come close to real experience in the middle of a few scrums. Further, the theory that most current students get covers maybe 15% of the activities they encounter in practice. As he also indicates, most computer science teaching methodology is still based on practices of the 70 s. We need to educate them for situations they will increasingly encounter in the future. Pre-Studios Team Experiences Students in our department taking software engineering are divided into teams of four students. Each team is assigned a project for development. The course lecturer expects class lessons to be put into practice by the teams in their projects. In turn, each team organized its work around meetings whose agenda was used to schedule and review activities having to do with the inception, design and implementation of the project. A team s agenda would include meeting time, place and purpose. It has been noted that one component of this agenda, meeting place, usually undermined the communication effectiveness of a team and renders ineffective lessons learned about the software process while at the same time exacerbates factors affecting team dynamics. It was a common practice that teams were left on their own to find places to gather, while actual project development place and environment for a team was not addressed either. Usually the meeting place ranged from an unused classroom, a campus lounge, a team member s home, a coffee house, or some open green space on the campus grounds to name a few. All of these meeting places basically contributed only for the meeting of the minds, but by no means any of those places provided a supporting environment for more, let alone all, of the activities associated with a software team development effort (requirements analysis, design, implementation, testing, team

3 discussion along with its associated artifacts used or created during discussions) and their effective communication to all its members. A common casualty of the meeting place used was the communication effectiveness. The communication of all activities that took place during the meeting to all members was either missing, or incomplete, or inconsistent, and hard (if not impossible) to preserve for team dissemination. Furthermore, the tracking of the development state of the project was commonly found in someone s head if at all, which again lead to poor development management. The use of tools to manage team activities, such as a web log, helps in team organization and record keeping, although this job was often not seen as a team responsibility, but that of one chosen member. This fact alone undermines the kind of communication method used, as it should have reflected a team s voice and not a member s voice. Furthermore, although students were exposed to issues dealing with teams and with tools to support software development by teams, the overall experience fell short of its intended goals. Specifically, a given team broke down the project into components with little discussion on its fitness or correctness; components were implemented separately by each team member (at his/her own time and place) with little or no common record of design or implementation choices, and little or no communication among team members between meetings. Subsequent meetings were for the most part used to check progress and to submit developed components for other team members use. It was towards the project s deadline that many missed or poorly managed issues associated with software development by a team reared their ugly face: understandability of the project s purpose, appropriateness of project decomposition, component interface, component implementation correctness and quality, coding standards, (disparity of) tools used in development, component version used by other components, etc. The underlying failure common to all these was the poor communication method used, or its lack thereof. Consequently, it was a common occurrence that one or two team members end up making a herculean effort to implement what an entire team should have; their success was in part due to the reduction in communication issues (fewer people to deal with) and in the lack of dependency on others to deliver components. We strongly felt that the wrong message was being implicitly given by not having dedicated facilities for the learning and practices of team work for the development of a product. That is, that teamwork development fundamentally reduces to the breakdown of a project into its team members who will gather at the end to put all the individually developed components into one big product, and without an opportunity to learn to use the software methods and tools to keep track to develop the product correctly and to guarantee more teamwork effectiveness. There are still other factors to overcome and that impact student team cohesiveness as well: disparity of schedules, availability of a common free time to meet, and being an on-campus or offcampus student. Also the approach commonly taken to tackle team projects allows and fosters this lack of cohesiveness, as a team member can work on his/her project component on his/her own time while allowing little time for team work where all or most members are present for discussions, project development tracking, or any form of peer review. Pre-studio Team Resources At the time of the writing of the proposal all computer labs available to our students were either for general student access or limited access by students in specific course work or training different from software engineering, or by graduate research in specialized topics. Those available for general access are expected to be used for individual work and any form of team work is discouraged both, due of the nature of the lab and to avoid any form of dishonesty. Core course education is aimed at the individual programmer. Upper level courses encourages teamwork

4 development with 2-3 member teams but without any guidance or training in teamwork. Also only very few optional upper level courses make provision for facilities where teamwork can take place, and those which provide it do it via dedicated labs for the topic at hand. Software Engineering Team Studio s Vision The proposal was aimed at enhancing the effectiveness of the software engineering course as was taught in our department. More specifically one objective was to fill this glaring gap in the training of software engineering students, that is, the lack of dedicated facilities for the teaching and training of a team of developers. We proposed the establishment of dedicated facilities for the training in project development by teams, and team dynamics aimed at students enrolled in software engineering. It must be noted that the absence of such dedicated facilities in the teaching of software engineering is the rule throughout the country. The author was only able to identify a handful of institutions with such accommodations. Another objective was to provide an environment for the teaching of an effective software process methodology. We have been teaching and continue to teach an in-house version of an agile methodology based on Agile-XP practices. The facilities do provide an environment to bring this methodology to actual practice. Last but not least, the facilities provides a way to monitor team activities, including meeting regularity, project tracking, and team dynamics. SOFTWARE ENGINEERING TEAM STUDIO PROJECT In order for software teams to be effective, adequate facilities are needed to carry out team activities, as well as support and enhance their communication about the project among themselves and to others in need of knowing or interested on some aspects of the project. One fundamental role the studio will implicitly provide is to allow for a place where the project lives, and where the students can check in for its status, work on its development and evolution and see themselves as team members; in short a place where the team and the software process come to life. Two important consequences resulting from a well equipped meeting place for software engineering teams are the existence of a gathering place where the team s current results exist, and where the software process continuity is found. Although software development studios like the one proposed are extremely rare in similar institutions, we consider them an important missing component in the training of Software Engineers. Software Engineering Team Studio facilities The software engineering studio s vision is in par with the department s effort to provide students with practical educational experiences with the goal to enhance the learning and understanding of complex and abstract issues presented in a classroom setting. Specifically the overall objective of these set of studios is to provide an environment for the training of future software engineers in the software process and the life-cycle phases sustained during the development of software products by teams of programmers. A software engineering team consisting of four students will have access to a studio where all team activities can be carried out in an environment where such activities are best supported. Among the expected team activities to take place include Team s project s planning activities Brain storming activities Analysis and design meetings

5 Individual and pair programming Code inspections and walkthroughs Project tracking Project assessment and report development Project presentations Meetings with instructor and customers Project post-mortem evaluation Each studio is equipped with the appropriate hardware, software and supplies to support the team s software project development activities. These facilities include: Significant white board space with color markers Bookcase with reference materials Corkboard space Digital projector Computer access for pair programming, consisting of two networked PCs nodes. Live connections for other nodes as needed Internet connectivity (wired and wireless access) External hard disc for software backups Copy machine Color printer Scanner Digital camera Modelling supplies Locker with key Flash drives for temporary storage of development components. These facilities are provided with several programming languages, programming environments, source control tools, documentation development software, unit and functional testing software. One fundamental role a studio implicitly provides is a place where the project lives, and where the students can check in for its status, work on its development and evolution and see themselves as team members working in conjunction in a common project. In short a place where the team and the software process come to life and students learn to deal with team s dynamic issues while immerse in the development of a project by a team of programmers. Preliminary Evaluation We have run one session of the software engineering course with the studios. Student evaluation of the studios was very positive. As expected, students welcomed the fact that there was a place for their meeting and associated activities and work on their project. Students indicated as well the studios enhanced their meeting frequency and team communication. At this time we cannot yet accurately measure the studio effectiveness with respect to the final product delivered by the students, as we have only run the course only once with the studios. But we can report that more teams did finish their project successfully by the end of the semester, and team members seemed to know themselves better and work more effectively. From the instructor point of view, the studio provided a venue to meet teams for discussions on project development. Clearly, the studios facilitated our communication and discussions as we had the space and tools that supported them. We also had an opportunity to witness agile methods

6 being put into practice, or not, by the teams, such as pair-programming, continuous testing, state of project by presence of builds, UML use, and level of code ownership. New Teaching Opportunities presented by the studios The studios provided instructors for hands-on tutorials (tools, pair programming, code refactoring, unit/functional testing, test-driven design, UML use mentoring).these tutorial were run with all team members present and clearly provided an environment that nurture team cohesion. For the future we are planning on an advance course using agile methods in a simulated but realistic development environment. Also, we are planning on acquiring new development platforms [GPGPU, Cell] besides of multi-core PC s, to provide students with experiences using commodity platforms for parallel programming which they will surely encounter soon. CONCLUSION The existence of a teaching environment for students to participate in software development by teams brings home many of the issues addressed in the classroom and clearly provides an environment for their practice and monitoring. Although the studios also provide an extra level of duties from the part of the instructors, it is a very rewarding experience to see effective learning by the students who will shorty after join software houses in industry. Much of the teaching of software development by teams is unfortunately still based around practices of the 70 s and 80 s with some sprinkles via buzzwords or nifty tools from the 90 s. Facilities such as the studios we implemented bring home a great opportunity to take theory into practice and provide students with environments and experiences they will encounter or maybe even bring to their future jobs. BIBLIOGRAPHY [BK99] Beck, K. extreme Programming explained: Embrace Change. Addison-Wesley [Cell] [FM97] Fowler,M. UML Distilled.Addison-Wesley [FM99] Fowler,M. Refactoring. Improving the Design of Existing Code. Addison-Wesley [GPGPU] [HW95] Humphrey Watts. A Discipline for Software Engineering. Addison-Wesley [HW89] Humphrey Watts. Managing the Software Process. Addison-Wesley [KP2000] Kruchten, P. The Rational Unified Process. 2nd Ed. Addison-Wesley [LeB2004] LeBanc, R et al. Computing Curriculum- Software Engineering. The Join Task Force on Computing Curricula. IEEE Computer Society. ACM [MB97] Meyer, B. Object Oriented Software Construction. 2nd. Ed. Prentice Hall