A Course for Developing Personal Software Engineering Competencies

The strength of a software development team is the sum of the capabilities of each individual team member. There exist at the personal level core software engineering competencies that need to be cultivated to allow an individual to fulfill their potential as an effective team contributor. Students in a course introducing team based software engineering typically possess adequate introductory programming skills, but often lack other competencies required to execute a software project successfully. Students have rarely been introduced to concepts beyond programming, such as estimation and planning, continuous integration, detailed design, debugging and unit testing. Part of being a software engineer is the knowledge of multiple programming languages and tools; without such knowledge it is impossible to make intelligent engineering decisions. Contemporary education philosophy stresses active student initiative and personal responsibility learning. In our case, with a rapidly evolving technology landscape, students must come to realize that, as in the workplace, many skills are not so much taught as learned. This paper captures our experiences with a second year software engineering course designed to address these challenges. In addition to discussing the topics covered in the course we also present active and cooperative learning practices utilized in class activities. Introduction Our undergraduate software engineering curriculum incorporates team-based activities in all upper-division courses, as the ability to work effectively on teams is a critical aspect of software engineering practice. Effective team participation, however, assumes basic engineering competence on the part of each team member. The goal of this course is to both enhance and assess each student’s individual technical skills in preparation for the team-based courses that follow. The Personal Software Engineering course (SE350) covers individual software construction skills: planning, detailed design, programming, debugging and unit testing. Software construction is the central activity guaranteed to happen on every project.[xx] As such, the quality of the construction substantially affects the quality of the software, and knowledge of construction principles is essential whether you are engaged in construction or are responsible for another phase of the project (architecture, requirements elicitation, quality assurance, maintenance, etc.). Part of being a software engineer is knowledge of multiple programming languages; without such knowledge it is impossible to make intelligent technology tradeoffs. What is more, the language landscape evolves rapidly over time, so the ability to learn and apply new languages is an essential skill. The two languages we use are C and Ruby; we do not expect students to master either language by the end of the term, but to demonstrate competence with the core concepts in each. Why C? Well, C was one of the earliest high level languages to support efficient use of computer resources. In addition, C is the progenitor of a whole host of C like languages, of which Java is the most popular current example. This means we can focus on the unique aspects of C, particularly memory management and pointers, without having to spend much time on concrete syntax for loops, conditionals, expressions, etc. C is also the immediate ancestor of C++, the current language of choice when efficiency and direct access to hardware is critical. Those who eventually move on to engineer real-time and embedded systems will find C and C++ are pervasive in those domains. We selected Ruby since dynamic languages like Ruby and Python have established themselves as excellent tools for scripting, rapid prototyping, and flexible development where raw efficiency is not a priority. Ruby also has a rich set of defined classes which support the development of concise, clear object-oriented applications. As our students were arriving at our course with a year of Java object-oriented experience already under their belt, we only needed to spend minimal time in the review of object-oriented principles before turning them loose in the Ruby environment. Ruby is also the base for the web application framework Ruby on Rails. The section of the course devoted to Rails provides the opportunity to introduce relational database systems and web application components such as object to relational mapping. We also included this subject material as we had no other required course which directly addressed web or database applications. At minimum, the use of Rails armed our students about to begin co-op with at least basic knowledge of how web or database applications work. It also turned out that this brief introduction to Rails sparked the beginning of a number of individual student projects both inside and outside of the department. Background The students enrolled in our Personal Software Engineering course are in their second year and have already completed one year of a typical introductory computer science sequence (CS1-CS3) using Java. Prior to the creation of SE350, our Software Engineering students would take an additional Computer Science course (CS4) which dealt exclusively with C++. We found that our students emerged from this introductory programming sequence as knowledgeable programming tacticians, but lacking in good software construction habits. As students entered our sequence of Software Engineering courses, they were placed in project teams where the sometimes unbalanced distribution of programming tasks left them with limited opportunity to practice or refine their software construction skills. As a department we looked for an alternative course to CS4 that would allow us to engage our students sooner in their development as programmers so as to provide a means of personal assessment and help establish fundamental software engineering skills. Classroom Environment A section of SE350 enrolls a maximum of 40 students with one instructor and one upper division student as a course assistant. Classes are two hours in length and held twice a week in our studio labs, with one PC per student. Students are organized into groups of four; we used a “playing card” distribution to determine the groups so that for example, a class of 40 would have 10 groups (Aces, Ones, Twos, etc.) and each student in the group would be assigned a suit (spade, heart, club, diamond). [10] We enforce a strict pair programming [11] policy during class activities, but we rotate pairs within the group by announcing pair assignments for the day as “diamonds and spades” or “hearts and clubs”. The same organization also supports active learning exercises such as “jig-saws,” where students from different groups but the same suits collaborate on part of an assignment and then report back to their groups with the collective knowledge needed to complete the activity. We change groups three or four times over the term, enabling each student to meet and work with most of the other students in the class. Although we provide fully loaded Windows PC’s with powerful IDE’s in our lab, we intentionally limit class activities to a command line driven, Linux environment. Students learn (or are reacquainted with) text editors (emacs, vi, nano, etc.), bash scripts and source control we require use of SVN for every artifact they create. For our C programming activities we use the GNU compiler (gcc) and debugger (gdb), with builds defined in make files. Our rationale was that small, precise “hand tools” are sometimes more appropriate than a large, multipurpose power tool such as Eclipse. In addition, students gain a better appreciation of what an IDE is doing under the hood, allowing them to adapt to situations where their favorite IDE is unavailable. Course Outline The course spans an eleven week term; Table 1 provides a week-by-week summary of topics covered. An important goal in designing the course was to devote the majority of each two hour session to an activity that encourages student collaboration while providing rapid response to problems by an instructor or student assistant.