J. Software Engineering & Applications, 2010, 3: 495-502
doi:10.4236/jsea.2010.35056 Published Online May 2010 (http://www.SciRP.org/journal/jsea)
Raising Awareness of the Constituents of Software
Design – The Case of Documentation
Lavy Ilana, Yadin Aharon
Management Information Systems, Emek Yezreel Academic College, Emek Yezreel, Israel.
Received December 6th, 2009; revised December 21st, 2009; accepted December 23rd, 2009.
ABSTRACT
This research was performed within a software engineering workshop for Computer Science students. For addressing the
soft skills issues required by the industry, the course was delivered as a workshop with various (inter and intra) team
based activities. An additional objective of outlining the importance of software maintainability issues was achieved
through team-based role play. There were three assignments in which each team had to continue the work performed by
another team, thus creating a dependency between the teams as might happen during maintenance. The main research
study objective was to examine the effect of employing this kind of a team-based role-play peer-review on the students’
learning process regarding maintainability. Data referring to the students’ perceptions is presented and analyzed in
addition to student reflections on the workshop which demonstrate their expanded understanding of the design and
application process.
Keywords: Team-Based Role Play, Software Engineering, Peer Review, Maintainability
1. Introduction
The term software engineering appeared first at a NATO
conference in 1968 [1] and it was intended to ignite dis-
cussions on the process of developing correct, testable,
and understandable computer programs. At that time, the
“software crisis”, that was partially caused by the rapid
developments in computer technologies combined with
more, complex user requirements, and the lack of “engi-
neering” methodologies for software development [2].
Since then the process of software engineering has ma-
tured and is accepted as a proven learning discipline. The
Software Engineering course is an important part of the
Computer Science (CS) and Information Systems (IS)
curricula, however many students regard it as less appli-
cable in their future careers [3]. Information systems and
software based systems in general, require follow-up
maintenance due to the existence of potential bugs that
will have to be corrected, the high likelihood of functional
enhancements to be introduced to the programs. For
lowering the costs associated with these ever increasing
needs for software maintenance adoption of proper soft-
ware engineering methodologies is required. Thus soft-
ware maintainability plays a critical function in the soft-
ware engineering process, not unlike the role of software
development itself.
Cognizant of the students’ difficulties regarding non-
technical knowledge such as critical thinking, interper-
sonal and team based skills, the Software Engineering
workshop structure employs many inter-team and in-
tra-team activities. Furthermore, to raise the students’
awareness to the importance of documentation and the
role it plays in maintainability, the workshop employs an
incremental life-cycle involving each team in three ac-
tivities: design (including documentation), development,
and testing. However, unlike the ordinary software de-
velopment life-cycle, in which each team performs the
three activities for the same project the workshop struc-
ture employs a team-based role play. By team-based role
play we mean that the design, development and testing is
swapped among the teams. Initially all the teams are given
the same project, and each team prepares his own design.
The second assignment consists of developing the system
according to the design specifications, but each team
develops a system that was designed by a different team
and not the system it has designed. The third assignment
consists of defining the test specifications and testing the
system, however, once again, each team tests a system
designed by one team and developed by another. When
proceeding to the next assignment, the team is required to
ignore their prior knowledge or ideas and to concentrate
only on the system as it has been designed (or developed)
by another team of their peers.

Raising Awareness of the Constituents of Software Design – The Case of Documentation 496
The main research study objective was to examine the
effect of employing this kind of a team-based peer-review
on the students’ learning process in a software engineer-
ing workshop with special emphasis on their perception
regarding documentation. This paper describes the work-
shop structure and the quantitative and qualitative results
obtained from employing it.
2. Theoretical Background
Software development is a collaborative task that employs
teams of developers working together [4]. To enhance
software readability and maintainability, software engi-
neering practitioners have been striving to improve ex-
isting tools and methodologies. Among these various
practices, documentation - used to describe the required
software, its structure, logic and performance - is high on
the list [5,6]. Without the proper documentation, the fu-
ture maintainer will find it extremely difficult to under-
stand the system or its processes. Poor and missing
documentation is a major contributor to software quality
degradation and aging, compounding an increase in
maintenance costs [7]. In spite of this, many students fail
to recognize the importance of documentation on main-
tainability [3].
Software engineering is an integration of many prac-
tices, methodologies and tools.. One of the initial practices
is software documentation. However, even at present
many systems are still developed and released without
proper documentation [8]. In response, several method-
ologies have been developed to address the unsolved
problem of the documentation lag [9]. The Agile Mani-
festo, for example, puts greater emphasis on the devel-
oped product while ignoring detailed documentation. This
methodology welcomes change and stresses fast delivery
of useful software, based on the close collaboration be-
tween developers and customers.
Software documentation is a general term that refers to
two types of documentation: 1) documenting the user
requirements that provide the basis for designing the
system to be developed, and 2) documenting the software
to be developed, or that was developed, for aiding de-
velopment or future maintenance activities. These main-
tenance activities, according to many studies, are the most
expensive part in the software development life-cycle [10].
The Agile methodology is helpful in reducing the amount
of work needed during the first documentation process
(requirement elicitation and project development). How-
ever, for future maintenance of the developed software,
proper documentation is still required. For that reason, the
documentation required to the Agile methodology is done
at the end of the project and remains inadequate for
maintenance purposes [11]. For years educators and
practitioners have stressed the importance of documenta-
tion (during the design phase or after project completion),
however many projects are still released without proper
maintenance documentation.
2.1 Software Maintenance
A common definition for maintenance is that it is per-
formed after product delivery. Software maintenance, as
well, refers to the activities carried out after the devel-
opment’s completion. However, software maintenance is
very different from “ordinary” equipment maintenance.
While in other engineering disciplines maintenance in
intended to fix a problem [12] and keep the equipment
running so it will continue to provide the original func-
tionality, software maintenance, in many cases is required
to enhance the functionality based on the ever changing
requirements due to the operational environment, the
competition, and the business climate. Meeting these new
and changing requirements is unique and basic software
characteristic, as defined in Lehman’s laws of software
evolution [13,14]. Furthermore, software is constantly
being modified to utilize new hardware equipment and for
integration into new environments.
Introduction of the software development life-cycle has
led several researchers to consider activities related to
software maintenance, which are initialized while the
software is being developed and not only after delivery.
Additionally, some researchers emphasize that starting the
maintenance activities after completing development
leads to an unnecessarily more complex and costly task
[15,16]. Others define software maintenance as a mix of
activities, some performed after delivery and some per-
formed during development. The pre-delivery activities
include the necessary planning for the post-delivery ac-
tivities [17].
2.2 Students’ Perception Regarding Maintenance
There has been a great deal of improvement in software
development over the last decade. Many new techniques,
methodologies, languages and tools have been created to
advance the development processes. Software mainte-
nance, however, lags behind mainly due to its reactive
nature. Introducing systemic approaches to software
maintenance is inherently problematic [18]. The required
software maintenance (error corrections or introductions
of new features) cannot be postponed or circumvented. By
nature software maintenance is a disorganized process
which deteriorates the software’s architecture (Lehman’s
second law of software evolution [13]). This deterioration
is due in part to missing knowledge which is required for
maintenance. In addition, any changes introduced dete-
riorate the system architecture further, making future
maintenance even more difficult. The lack of correct and
updated documentation is one of the main causes for this
missing knowledge.
During their first and second years of study, students
become acquainted with these facts, however in spite of
the lecturers’ efforts; software documentation continues to

Raising Awareness of the Constituents of Software Design – The Case of Documentation 497
be insufficient. More troubling is the fact that students do
not assimilate the need for, and importance of, proper
documentation [3]. Many students consider the develop-
ment stage as the most important activity in the software
development life cycle, totally ignoring the fact that suc-
cessful software will have to be maintained for a long
time.
2.3 Peer Review in Higher Education
Peer review is a form of external evaluation carried out by
professional colleagues [19]. Peers can be experts in the
field but can also be classmates who poses the same level
of knowledge and assess the work of fellow students. Peer
review is a widely practiced form of certifying quality in
higher education [20], and has been described as a for-
mative evaluation process in which participants work
collaboratively to strengthen a product [21]. Peer review
is generally said to encourage critical examination, pro-
mote the exchange of ideas, reduce non-academic inter-
ference, guide academic discourse, and reinforce aca-
demic values [22]. Peer review assumes the existence of
norms by which a peer’s work may be judged. Through
critical examination, norms are used to compare a peer’s
work to accepted practices. If a peer’s work deviates sig-
nificantly from accepted norms, then an attempt to correct
it will likely occur. Being aware of the advantages of peer
review, it has been incorporated as an integral part of the
workshop. The inter-team and intra-team peer review was
used to enhance the students’ learning abilities and to
enforce critical thinking. However, In addition to the
common peer review, the workshop requires the students
not only to evaluate and assess their peers work, but also
build on it. The students’ success in performing their
assignments depends on their ability to understand the
work or their peers. This elevates the assessment process
to a new and more important level.
3. The Study
In what follows we discuss the study performed while
addressing the participating students’ the workshop’s
structure including the assignments and the grading
scheme.
3.1 About the Study Participants
The workshop is a mandatory course taken during the
second year of study. A total of twenty-six college stu-
dents participated in the present study. In the workshop
the students were divided into seven teams (five teams of
four students and two teams of three students). At this
stage the students have already learned software modeling,
UML usage, etc. In addition to the standard topics of the
software engineering course, one of the workshop’s im-
portant objectives is to prepare the students for their Final
Project and the real world challenges they will face.
3.2 The Course
The systems engineering workshop’s general objectives
are to introduce software development life cycle concepts
to the students while enhancing their understanding of
documentation and product maintainability. Since soft-
ware is considered one of the most complex systems
produced by humans [23], students have to adopt proper
working procedures for lowering the development risks
and the high maintenance barriers. Documenting their
ideas and thoughts during the design phase is crucial for
future understanding of the software to be developed.
Other objectives relate to 1) practical understanding of
the software development stages required for develop-
ment of a modern Information System; 2) implementing
these stages in a small project; 3) understanding the
problems associated and caused by working in teams, and
4) developing the required “soft skills” (critical thinking,
team work, interpersonal relationships, etc). For that
reason, the workshop augments knowledge and under-
standing gained in current and previous courses, and is
practical, “hands-on,” and team-based.
All seven teams received and worked on an identical
project. The project was a general description of a re-
quired system that was to be developed (an Internet based
electronic auctions, or e-bidding system). As part of the
first assignment, the students had to study the existing
systems, address and assess various alternatives, and
suggest ways (and a software based system) of providing
an agreed upon functionality. The workshop structure
followed the software development life-cycle and was
based on three incremental assignments.
Each assignment required personal and individual work
followed by team activities (in person or by using various
collaborative tools).The students had four weeks for each
assignment throughout the process the students consulted
their instructor (via email, the workshop web site, and
personal meetings) on various issues related to their as-
signment. In order to reinforce the importance of docu-
mentation and maintainability, the teams were engaged in
role-based development in which the teams shared all
responsibility for their success. While a specific project
was designed by one team, developed by another team and
tested by a third team, in the end each team had to work
not only on the three stages of the assignment but on each
one of the three design solutions (Figure 1). This way,
each team was involved in developing a system designed
by another team while trying to understand some of the
undocumented intentions expressed in the design. This
forced them to seek help from the designing team. On the
other hand, this developing team had to help another team
that was trying to develop the system based on their de-
sign document. The interdependence of these stages was
stressed and made apparent to all teams. This workshop
structure was designed to enhance the students’ under-

Raising Awareness of the Constituents of Software Design – The Case of Documentation 498
standing regarding the importance of documentation
through their own experience.
Figure 1 depicts the workshop’s structure. The long
horizontal rectangles represent the seven versions of the
same project, while the three vertical columns represent
the assignments (A1, A2 and A3). As can be seen, each
project consists of the three assignments performed by
three different teams. Each team, on the other hand,
worked on all three assignments, each one belonging to a
different project.
The workshop requirements included two types of de-
liverables: 1) team assignments, and 2) a personal as-
signment.
3.2.1 Team Assignments
The software development life-cycle activities were di-
vided into three team based assignments: 1) project defi-
nition and design; 2) project development, and 3) project
testing.
3.2.1.1 Project Definition and Design
The first assignment started with a very brief description
of the project, the functionality and the required devel-
opment activities. The students studied available e-bid-
ding systems, documenting their functionality, and used
them as a basis for the system they were required to de-
velop. Since such a large project cannot be completed
during the semester, the students had to identify at least
five different users to be supported by the system and for
each user a set of Use-Cases had to be defined. In addition
to the Sequence Diagrams supporting these Use-Cases,
the students had to define the non-functional requirements
associated with these Use-Cases. The system analysis
phase (which is part of this assignment) included a high
level design (System architecture and the Class Diagram)
as well as a detailed design (Activity Diagram followed by
a Program Design Language definition for the described
functionality). All these activities required a great deal of
individual work as well as collaborative work in which
each student assessed and approved the work performed
by other team members.
3.2.1.2 Project Development
The second assignment consisted of the development of
the system according to the Project Definition and design
document (the first assignment). However, instead of
developing the system according to their own design, each
team had to develop the system as it was defined by an-
other team. The developing team had to carefully follow
the document they received, ignoring all their prior
knowledge or ideas they may have expressed in their first
assignment. Small code modifications were permitted,
provided that the definition in the document they received
was erroneous and could not be implemented. After
completing the development, each team had to compile a
‘difference’ document, outlining the changes between the
Figure 1. The Workshop’s Structure
implementation and the document as received, with spe-
cial emphasis placed on the reason behind these changes.
At this stage stress is not placed on enhancing the product
to be developed, but rather on developing it according to
the exact specifications outlined in the definition docu-
ment. An additional document which was part of this as-
signment was a short evaluation of the first assignment’s
quality as it was reflected in the implementation. The last
document to be submitted as part of this assignment was a
Unit Test Plan for each of the methods developed.
3.2.1.3 Project Testing
The third assignment consists mainly of the testing phase.
The students have to implement the Unit Test Plan as was
designed by the previous team. Due to time constraints the
workshop addresses only part of the required project de-
velopment, so for testing the software pieces developed by
the previous team, the testing team had to include addi-
tional developments (a test generator and a stub). These
additional developments were required for building the
testing infrastructure for the developed software pieces.
As part of this assignment the team is required to correct
mistakes that were discovered during the testing. The
corrected code has to be tested once again. This process is
repeated until everything runs according to the specifica-
tions, as outlined in the project definition document (the
first assignment of this project). This third assignment
also includes the testing report that summarizes the
problems discovered and their corrections. In addition,
this assignment includes a system test plan with at least
ten detailed test cases. This plan is for the Quality As-
surance staff, so it has to be detailed and based on the
system functionality as derived from the project definition
document (first assignment). The last part of this assign-
ment is a quality test plan that concentrates on the
non-functional attributes of the system, with a special
Team 6Team 7Team 2
Team 5Team 3Team 7
Team 4Team 6Team 1
Team 7Team 1Team 4
Team 3Team 5Team 6
Project 5
Team 1Team 2Team 3
Team 2Team 4Team 5
Project 3
A1: Project
design
A2:Develop
-ment
A3: Testing
Project 1
Project 2
Project 4
Project 6
Project 7

Raising Awareness of the Constituents of Software Design – The Case of Documentation 499
emphasis on the metrics to be used or defined.
3.2.2 Personal Assignment
The personal assignment is mainly an activity summary
report, in which each student describes 1) the work done
during every stage of the project; 2) his/her part in these
activities; 3) the problems they (as a team) encountered
during the project and 4) the problems he/she encountered
personally. There is also a short reflection on the work-
shop, as well as a one sentence summary about the
workshop’s results. The last part reflects on the work
distribution among the team members (100 points that the
student divides between the other team members to ex-
press their relative contribution toward each of the three
assignments).
3.3 The Workshop Grading Scheme
Since one of the important workshop goals is to strengthen
team work, most of the grades are based on the team’s
activities. Each of the first two assignments makes up
33% of the grade, while the third, which is simpler, com-
prises 24%. The personal report, including the short re-
flection, contributes an additional 10%.
The grading scheme took into consideration the work
distribution as was described by each team member. Five
points (out of the 90 points allocated for team activities)
were used as floating points among the team members,
based on their average contribution to the team’s success
4. Learning Process Evaluation Methodology
The evaluation method included a comparison between
two questionnaires. The first questionnaire was part of a
survey conducted during the workshop’s first lecture, in
which students were asked to rate their perception re-
garding the relative importance of the three project phases
expressed by the planned assignments. A similar survey
was conducted during the last lecture producing the sec-
ond questionnaire. Since the end of semester question-
naire was identical to the questionnaire used in the first
lecture, its intention was to measure the workshop’s in-
fluence regarding the perceived importance of the three
phases and especially the importance of documentation
and testing on the software engineering activities. In ad-
dition, the evaluation process analyzed the student’s re-
flections on their workshop experiences.
For implementing a successful inter-team role play, the
workshop was highly structured. In addition, pre-defined
templates were used for all the team based assignments.
However, in contrast to these pre-defined templates the
personal reports were composed of free style answers. The
only data provided were the points to be addressed in
these reflections. This open format encouraged students to
concentrate on the issues s/he felt were important and
offered a better understanding of the students’ achieve-
ments during the workshop.
5. Results and Discussion
In what follows we present data and discuss the effect of
the workshop’s structure on the students’ perceptions
regarding the importance of documentation on the pro-
ject’s success, as well as their reflections regarding the
benefits of the workshop.
5.1 The Assignment’s Relative Importance
The first questionnaire results are outlined by Figure 2. It
is no surprise that CS students regarded development as
the most important activity (70% of the project). Testing
was perceived to be of secondary importance (16%) and
documenting the design phase was perceived to be the
least important (14%) in the design and development of
software.
The students explained the relatively low importance of
documentation by citing the fact that the methodology and
the tools used (UML – Unified Modeling Language as
well as the code itself) provide all the necessary docu-
mentation. The results obtained in this survey were no
different when compared to the results from the previous
year. These consistent results were the trigger for the
workshop structure and one of its objectives was to con-
vince students, through their own practical experience
about the importance of documentation.
As was demonstrated by the first questionnaire (Figure
2), most students view development as the most important
activity of a project (70%). However, the second ques-
tionnaire revealed that the students began to realize the
importance of the subsequent components and the role
they play in determining the project’s success. Therefore,
by the semester’s end, development’s perceived impor-
tance was reduced by 31% (to 48% of the project), while
the relative importance of the documentation assignment
increased by 59% (from 14% in the first questionnaire to
23% in the second questionnaire). Testing’s perceived
importance also increased - by 83% (from 16% in first
questionnaire to 29% in the second).
Figure 2. Relative Assignment Importance (1st Lecture)
Ducumentation
Development
Testing

Raising Awareness of the Constituents of Software Design – The Case of Documentation 500
Figure 3. Relative Assignment Importance (Last Lecture)
There are many factors affecting the relative importance
of the various life cycle stages and the amount of time
required for each one. These factors, for example may
include customer requirements, project type, the software
development life cycle methodology, the programming
languages and CASE tools, etc. In most cases the devel-
opment stage requires less than 30% of the project esti-
mated time. Glass [24] uses 20% for requirements elici-
tation, 20% for design, 20% for coding and 40% for test-
ing. The requirements elicitation is not part of this work-
shop since the project and its general requirements were
predefined and the students had to study available solu-
tions and decide which parts to design and implement. At
the end of the semester, the students still regard coding
(development) as the most important component, but it is
significantly (31%) less than its importance at the begin-
ning of the semester. The end of semester percentages are
closer to the numbers used by researchers and practicing
software engineers.
The change in the students’ perception regarding the
relative importance of the various project components is
directly linked to the workshop’s structure. There were
many instances during the second stage of the workshop,
in which the students were trying to drop the design spe-
cifications they received from the previous team, claiming
these specifications will not produce a viable solution and
the project cannot be developed. In all cases it proved to
be wrong. The solutions described in these design speci-
fications provided a workable solution, however they
were not properly documented, which hampered the stu-
dents understanding. After discussing the design specifi-
cations with the responsible team, the project was devel-
oped as intended, with some minor modifications. This
misunderstanding was repeated on the third stage, in
which students had to design and execute the system
testing. However, for designing the test environment and
the test scenarios a full project understanding was re-
quired. In addition to the extra work needed due to the
missing documentation it also changed the students’ per-
ception regarding the importance of the non-development
activities.
The significant increase in the perceived testing im-
portance (83%) can be explained by the fact that during
the third stage the student had to design and develop the
stub and the scenarios for the system to be checked. In all
cases where the system did not function according to the
specifications, the testing team had to correct the code and
run it once again. This means that the testing team had to
be familiar with the design specifications as well as with
the developed code. The testing students acted as the
“gate-keepers” making sure that only the fully functional
system is released. Performing this task properly, in the
workshop, requires some additional analytical skills for
finding and correcting various bugs which may have been
introduced during the development or the design stages.
Unlike the real world situation, where in case of problems,
Quality Assurance people usually return the system to the
developers, here the testing team had to fix it by them-
selves, which led to their higher appreciation of the testing
task and its elevated importance in the development
process.
5.2 The Student’s Perspective
Analysis of the students’ reflections revealed emphasis of
three main issues: 1) the importance of documentation; 2)
team-based activities and 3) contribution to future voca-
tion.
5.2.1 The Importance of Documenting the
Project
Improving the students’ understanding regarding docu-
mentation and the role it plays in the project and its future
maintainability, was addressed by many of the reflections.
For example:
“I understood (unfortunately through bad ex-
perience) the importance of a development
project’s documentation.”
“It was only during the workshop that I began to
grasp the importance of understanding and
documenting the requirements.”
From the above students’ excerpts we can conclude that
they developed a sense of appreciation for documentation,
mostly arising from the need to spend many more of their
own resources when it was missing. Furthermore, without
proper documentation, the project may not be successful
and might not deliver the expected outcome. The fact that
they realized, for example, that undocumented specifica-
tions are misleading is consistent with Williams [25]
stressing that students no longer view the teaching staff as
their sole conduit of technical information.
5.2.2 Team-Based Activities and Implications
Students pointed out several advantages regarding their
experience of working in teams, as well as what was re-
quired of them. Here are some common reflections:
“Working in a team provided me with many
Ducumentation
Development
Testing

Raising Awareness of the Constituents of Software Design – The Case of Documentation 501
new views and possibilities for solving the
problem.”
“The most important lesson I learned during the
workshop was to accept my friends’ criticism
and provide constructive feedback.”
“The success and failure of the project de-
pended mainly on the team members’ activities
and not on any single member.”
From these reflections we learn that in general students
found the teamwork method helpful in developing their
critical thinking (receiving and providing constructive
feedback) and in improving their ability to cooperate.
However, in their reflections students also pointed out the
shortcomings they experienced in team-based activities.
For example:
“Team work can be a blessing, but sometimes it
can also be a curse…”
5.2.3 The Workshop’s Contribution to Future
Vocation
Here are some student reflections regarding the contribu-
tion of the workshop’s assignments to their future em-
ployment.
“So far we learned that the most important stage
in the project is the development. Here I un-
derstood that the process is equally important.”
We conclude that the students found the detailed
documentation very helpful. Furthermore, the under-
standing gained by working in teams helped them think as
developers and enhanced the process of reaching the
problem solution.
6. Concluding Remarks
From the students’ reflections and the results received
regarding the differences in their perception as reflected in
the two questionnaires, it can be concluded that the
workshop raised the students’ levels of understanding [26],
and as a result helped them cope successfully with the
given workshop assignments. The role-based develop-
ment, in which the students had to assume responsibility
for activities partially performed by others, exposed them
to ideas which were different from the ones they had
decided to use in their own solutions. Especially, this
workshop structure effected the students’ appreciation of
documentation and the role it played in their own success.
This exposure, in many cases, made them rethink their
task and prompted them to look for better, more efficient
solutions. The collaborative team work exposed each team
member to various ideas expressed by his/her peers and as
a result caused additional thinking about available solu-
tion alternatives.
REFERENCES
[1] P. Naur and B. Randell, “Software Engineering: Report of a
Conference Sponsored by the NATO Science Committee,”
Garmisch, Germany, Scientific Affairs Division, NATO,
1968. http://homepages.cs.ncl.ac.uk/brian.randell/NATO/
nato1968.PDF
[2] R. J. Veldwijk, M. Boogaard and E. R. K. Spoor, “Assess-
ing the Software Crisis-Why Information Systems are
Beyond Control,” Vrije Universiteit, the Netherlands,
1992. ftp://zappa.ubvu.vu.nl/19920006.pdf
[3] J. Burge, “Exploiting Multiplicity to Teach Reliability and
Maintainability in a Capstone Project,” 20th Conference
on Software Engineering Education & Training, Dublin,
2007.
[4] L. T. Cheng, S. Hupper, S. Ross and J. Patterson, “Jazzing
up Eclipse with Collaborative Tools,” Proceedings of the
2003 OOPSLA Workshop on Eclipse Technology eX-
change, Anaheim, October 2003.
[5] S. C. Souza, N. Anquetil and K. M. Oliveira, “Which
Documentation for Software Maintenance,” Journal of the
Brazilian Computer Society, Vol. 13, No. 2, 2007, pp. 31-
44.
[6] S. Das, W. G. Lutters and C. B. Seaman , “Understanding
Documentation Value in Software Maintenance,” Pro-
ceedings of the 2007 Symposium on Computer human
interaction for the management of information technology,
Cambridge, Massachusetts, 30-31 March 2007.
[7] M. K. Mattsson, “Problems in Agile Trenches,” Proceed-
ings of the Second ACM-IEEE international symposium on
Empirical Software Engineering and Measurement, Kai-
serslautern, 09-10 October 2008.
[8] G. T. Daich, “Document Diseases and Software Mal-
practice”. http://www.sstc.online.org/Proceedings/2003/P
DFFiles/p961pap.pdf
[9] P. Clements, “Comparing the SEI’s Views and Beyond
Approach for Documenting Software Architectures with
ANSI-IEEE 1471-2000,” Technical Note CMU/SEI-2005-
TN-017.http://www.sei.cmu.edu/pub/documents/05.eports
/ pdf/05tn017.pdf
[10] R. C. Seacord, D. Plakosh and G. A. Lewis, “Modernizing
Legacy Systems–Software Technologies, Engineering
Processes and Business Practices,” New York, Addison-
Wesley, 2003.
[11] D. Brolund and Ohlrogge, “Streamlining the Agile
Documentation Demonstration for the XP 2006 Confe-
rence,” Lecture Notes in Computer Science, Springer, Vol.
4044, 2006, pp. 215-216.
[12] G. Canfora and A. Cimitile, “Software Maintenance.”
http://www.compaid.com/caiInternet/ezine/maintenance-c
anfora.pdf
[13] M. M. Lehman, “Lifecycles and the Laws of Software
Evolution,” Proceedings of the IEEE, Special Issue on
Software Engineering, Vol. 68, No. 9, 1980, pp. 1060-
1076.
[14] M. M. Lehman, “Program Evolution,” Journal of Info-
rmation Processing Management, Vol. 19, No. 1, 1984,
pp. 19-36.
[15] N. F. Schneidewind, “The State of Software Maintenance,”
IEEE Transactions on Software Engineering, Vol. 13, No.

Raising Awareness of the Constituents of Software Design – The Case of Documentation 502
3, 1987, pp. 303-310.
[16] W. M. Osborne and E. J. Chikofsky, “Fitting Pieces to the
Maintenance Puzzle,” IEEE Software, Vol. 7, No. 1, 1990
pp. 11-12.
[17] T. M. Pigoski, “Practical Software Maintenance–Best Prac-
tices for Managing Your Software Investment,” Wiley &
Sons, New York, 1997.
[18] M. B. G. Dias, N. Anquetil and K.M. de Oliveira, “Orga-
nizing the Knowledge Used in Software Maintenance,”
Journal of Universal Computer Science, Vol. 9, No. 7,
2003, pp. 641-658.
[19] A. Yadin and I. Lavy, “Integrated Formative Assessment as
a Vehicle towards Meaningful Learning in Systems
Analysis and Design workshop,” Paris, 2008.
[20] C. Herndon, “Peer Review and Organizational Learning:
Improving the Assessment of Student Learning,” Research
& Practice in Assessment, Vol. 1, No. 1, 2006, pp. 1-7.
[21] L. Keig and M. D. Waggoner, “Collaborative Peer Review:
Role of Faculty in Improving College Teaching,” ASHE-
ERIC Higher Education Report, Washington DC, Vol. 23,
No. 2, 1994.
[22] K. Berkencotter, “The Power and Perils of Peer Review,”
Rhetoric Review, Vol. 13, No. 2, 1995, pp. 245-248.
[23] M. Lenic, M. Zorman, P. Povalej and P. Kokol, “Alter-
native Measurement of Software Artifacts,” ICCC 2004
Second IEEE International Conference on Compu-
tational Cybernetics, Wien, 2004, pp. 231-235.
[24] R. Glass, “Facts and Fallacies of Software Engineering,”
Addison-Wesley, New York, 2003.
[25] L. Williams, “In Support of Student Pair-Programming,”
Proceedings of the 32nd SIGCSE technical symposium on
Computer Science Education, Charlotte, 2001.
[26] J. Biggs, “Enhancing Teaching Through Constructive
Alignment,” Higher Education, Vol. 32, No. 3, 1996, pp.
347-364.