Software Engineering Lab
Software Engineering Lab
Engineering Curriculum
Mira Balaban Arnon Sturm
Computer Science Software and Information Systems
Ben Gurion University of the Negev, Engineering
Israel Ben Gurion University of the Negev, Israel
[email protected] [email protected]
The two right columns in Table 2 summarize the average score With respect to Experiencing Software Quality, students
in each of the aspects described before. Here the columns of indicated that they felt that too much attention was paid to unit-
"Lrn" indicate either importance of aspect, lesson learnt, and test coverage (2017).
understanding of different viewpoints (i.e., of students and With respect to Experiencing Training and Coaching, students
instructors). In all aspects, the results of the students of both in both cohorts indicated that group meetups are generally
cohorts indicate an improvement in both learning and good, although guidance is sometimes limited to checking
practicing (above the mean (4) in the post questionnaire). In whether version requirements are met (2016, 2017). Several
general, the students were satisfied with the SE lab course. students suggested reducing the load (2017) in order to
However, as we asked them to provide ways to improve the provide more in-depth guidance (2016, 2017) and to increase
course, they provide us with issues that require further synchronization among course coaches.
attention. When examining in detail the various results for each
of the questions as appear in the Appendix, we had the
following observations. 5 DISCUSSION AND LESSONS LEARNED
With respect to development processes, the overall average We believe that the SE-lab course achieves its goals largely. In
score of the two cohorts was 4.21, yet the discussions on the all desired aspects, student responses indicate improvement, in
pros and cons of various processes and tools (average score = both learning and clarifying SE methods and in practicing these
3.48) can be improved. With respect to development in teams methods. Moreover, the instructors of the yearlong capstone
the overall average score was 4.59, yet, the students' results project course that follows the SE-lab note that they observe
indicated that the team work was not optimize (average score meaningful improvement of student knowledge and skills.
= 3.2). With respect to design the average score was 4.38, the Some aspects that constantly worry us, as course instructors,
results indicate that not much of design reviews was performed refer to teaching and evaluation. Although team meetings are
(average score = 2.7). With respect to implementation, the pre-planned and are associated with clear evaluation criteria,
average score was 4.44, however, the results of the 2016 cohort individual personality, character, training, experience and
indicate that not much of code reviews was performed (average knowledge of coaches still have their own impact. Naturally,
score = 2.5). With respect to software quality, the average score coaches tend to emphasize elements of their expertise. Some
was 4.52, yet, it seems that the unit testing was not planned in coaches spend more time on software models, some prefer
advance (average score = 3.24). checking coding or validation aspects, and others have
We next moved to read the student comments in order to get difficulties in conducting a discussion and lean towards an
further insights. It should be noted that these are anecdotal as undesirable test atmosphere, following the written meeting-
most students did not provide detailed comments. In the protocol. Clearly, it is impossible to expect that all coaches will
following, we refer to these comments divided into the relevant be ideal and identical: Knowledgeable, mature, self-confident,
aspects, as discussed before. In brackets we indicate the cohort open, and friendly. In the post-version staff meetings, we
from which the comments were issued. discuss relevant issues and try to reduce variability in version
With respect to Experiencing Development in Teams, some grading. In the future, we aim at having a more detailed meeting
students indicated that while teamwork is generally positive, it plan that precisely defines the content and procedure of team
allows free riders, since no tight monitoring of the actual work meetings. Yet, we must leave room for creativity, individual
was applied. Monitoring was mainly via team commit logs, and differences, and personal variety.
it might be better to determine the various roles within the The annoying phenomenon of free riders is still not solved. In
team more rigorously (2016). order to reduce the number of students with minimal or close
With respect to Experiencing Software Design, some students to zero contribution, we have conducted the procedure of self-
indicated that issues of planning and design received lesser organizing teams, assuming that at their third year of studies,
emphasis, as the focus was on the code (2017). They most students already belong to naturally created teams. This
commented that it would be beneficial to get more insight into procedure was positively accepted by the students, but there
actual usage of design patterns (2017).
are always teams that are administratively created, or students self-directed and self-motivated learning [10]. In [9] for
that are added to existing teams by the SE office. Besides, example, the studios are organized similarly to a capstone
students differ in their capabilities, devotion, and available projects. Furthermore, the SE principles according to which the
time. Efforts to pinpoint the individual contribution of team studios were designed are not explicated.
members sometimes create unpleasant, dense atmosphere in Barzilay at al [11], indicate that an advanced summary course
meetings. Some coaches have a softer character, and feel uneasy in software that synthesizes all aspect of SE is still missing. In
to embarrass students in public. Such activities spoil our their work they propose a course with attempts to address the
intention to create constructive friendly discussions in team fundamentals of SE, practices and tools, productization, and
meetings. Consequently, although we encourage coaches to try technology evolution. Nevertheless, it seems that the course
to locate free riders, we avoid explicit individual member refers only to a sub-set of the development lifecycle and less
testing. emphasizes the abstractions required is SE.
Considering the student comments, although the general
reaction is highly positive, there are several comments that
deserve attention. We discuss these following the aspects we 7 CONCLUSION
followed throughout the paper. We described an SE-lab course that fulfills the standard role of
Experiencing Software Development Processes: Some an engineering lab course: Offer lab experiments for practicing
students perceived that their actual engagement into a specific methods and techniques, in a planned environment that
development process was limited. enables integration and investigation, with team-based
Experiencing Development in Teams: The importance of guidance. We analyzed the ideals, principles and goals of the SE-
teamwork is appreciated by all. Yet, in practice, there were lab, and explained how they are realized in the lab content. The
cases in which the work was divided or performed by only few SE-lab evaluation shows that students consider it to be a highly
members of the team. This has caused frustration among the relevant core course in the program.
students as well as extra workload. We have already discussed We pointed to several aspects that deserve further attention,
the problematics of free riders. mainly with relation to balanced team instruction and to
Experiencing Requirements Management: Some students, in student grading. Another challenge involves continuing the SE-
particular from the last cohort, indicated that expected version lab ideal and principles in the capstone project. This goal
content was not well defined. Our conjecture is that in the last requires coordination with the capstone project instructors,
cohort, the course staff and the project theme have changed, and mainly further efforts during the SE-lab teaching, towards
and thus version contents were not clearly defined. embedding these software development values.
Experiencing Software Design: Some students expressed the
need for more in-depth focus on discussing design alternatives.
Experiencing Software Implementation: It seems that the ACKNOWLEDGMENTS
notion of code review was not sufficiently practiced, and there
is a need to look for ways to integrate that experience into the We thank Achiya Elyasaf and Avi Hayoun for their help in
course. managing the SE-lab and for their valuable insights.
Experiencing Software Quality: In general, it seems that the
issue of software quality turns to be addressed very well and
that the students absorb the importance of a quality software. REFERENCES
1. P. Bourque, R. E. (Dick) Fairley, SWEBOK 3.0, 2014.
APPENDIX
Pre SE Lab Questions
Experiencing Software Development Processes Expose to principles of quality modeling (e.g., design patterns)
Learned about software development processes Implement principles of quality modeling
Implemented software development processes Experiencing Software Implementation
Integrated approaches and tools in software development processes Consider you implantation to include non-functional properties
Analyze the pros and cons of tools in the context of software development Decide upon the technology to implement the software
Experiencing Development in Teams Implement the software based of the preliminary modeling
Develop software in team larger than two students The implementation fitted the preliminary modeling
The work is team was a challenge Expose to principles of code quality (e.g., design patterns, bad
smell)
The work in team supported the software development Implement principles of code quality
Experiencing Requirements Management Experiencing Software Quality
Learn about requirements management Focus on testing development for the software you
implemented
Learn about development of a software that is partially defined Track the requirements vs. the code and the testing
Develop a software that is partially defined Check the software flexibility for introducing new requirements
Pay attention to the testability of the requirements Check the models you developed
Prioritize, decompose, and estimate the requirements Execute the testing on the code you developed
Use tool for requirements management Execute the testing for non-functional requirements
Experiencing Software Design Develop the testing in parallel to the code
Learn about design considerations in software development Experiencing Training and Coaching
Implement design considerations in software development Guide on the system you develop
Learn about design considerations originated from non-functional requirements Guidance in software development is important
Implement design considerations originated from non-functional requirements The actual guidance has helped you
Post SE Lab Questions
Experiencing Software Development Processes Experiencing Requirement Management
We examined various development processes We were not required for requirement analysis
The development process was defined in advance The project requirements were clear
We fully followed the chosen development process We analyzed the requirements
We partially followed the chosen development process We prioritize the requirements
We did not follow the chosen development process We took care of the requirements testability
We integrated various methods for software development The requirements were only used to define the project
We manage the requirement throughout the entire
We examined the pros and cons of the various techniques project
We examined the pros and cons of the various tools We used various tool to manage the requirements
Requirements traceability is important when these are
We did not examine the pros and cons of the various techniques changing
There is no need to trace the requirements as these are
We did not examine the pros and cons of the various tools changing frequently
We manage the relationship between the requirements
The importance of the development process was not clear and design
We manage the relationship between the requirements
It is important to have a development process and code
The development process was clear Experiencing Software Design
We used design consideration during the software
We adequately followed the development process development
Experiencing Development in Teams The design considerations consist of non-functional
requirements
We did not succeed to coordinate among the team members Modeling was the major means for specifying the design
There were team members with limited contribution Design patterns played an important role during the
design
We succeed to coordinate among the team members to a large extent The design was performed before coding
The teamwork helped us to fast advancing with the development Code organization is the design
The role division was effective The code was aligned with the design throughout the
entire project
The role division did not support the development We discussed design alternatives
All team members equally contribute to the development The project design was known at the beginning
We learn new things when working in a team From the view point of the students, the design is the
major part of the project
The teamwork improved my communication skills From the view point of the instructors, the design is the
major part of the project
The teamwork facilitated discussion on alternative solutions We performed design reviews
There was a need for a leader We followed software engineering principles throughout
the project design
The teamwork supported the due dates deliverable Experiencing Software Quality
Experiencing Software Implementation Unit testing were written before coding
We were required to select a technology for implementing the project Unit testing were written along with the coding
The code we had took into consideration the non-functional Unit testing were written after the coding
requirements
The code followed the models we had We had a high testing coverage
The code followed the design we had We had an exhaustive testing coverage
Design patterns were considered throughout the coding We had a low testing coverage
Bad smell were avoided throughout the coding We had integration testing
The code was reviewed by another team member We had system testing
The coding was done after determining coding rules We had automated testing
From the view point of the students, the code is the major part of the The testing were executed after each change
project automatically
From the view point of the instructors, the code is the major part of the The testing architecture was discuss in details
project
We performed code reviews The testing checked the system functionality with
respect to the requirements
We followed software engineering principles throughout the coding The testing checked non-functional requirements
The code was exhaustively documented The testing checked flexibility to changes
Experiencing Training and Coaching The testing checked reusability
The joint lectures discuss the various tools for executing the project The testing checked the user interface
The joint lectures discuss problems raise during the project From the view point of the students, the testing is the
major part of the project
The joint lectures contribute to the project From the view point of the instructors, the testing is the
major part of the project
The group meetups were used as an examination of the project
The group meetups were used as a focused forum for consulting and
guidance
In the group meetups we focused on understanding the requirements
In the group meetups we focused on testing
In the group meetups we focused on coding and problem solving
In the group meetups we focused on a discussion on alternatives for
design and implementation
In the group meetups we focused on the project management
The group meetups contribute to the project