Share This Article:

Raising Awareness of the Constituents of Software Design – The Case of Documentation

Abstract Full-Text HTML Download Download as PDF (Size:271KB) PP. 495-502
DOI: 10.4236/jsea.2010.35056    3,398 Downloads   6,666 Views   Citations


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.

Conflicts of Interest

The authors declare no conflicts of interest.

Cite this paper

L. Ilana and Y. Aharon, "Raising Awareness of the Constituents of Software Design – The Case of Documentation," Journal of Software Engineering and Applications, Vol. 3 No. 5, 2010, pp. 495-502. doi: 10.4236/jsea.2010.35056.


[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. 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.
[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”. 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. 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.”
[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. 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.

comments powered by Disqus

Copyright © 2018 by authors and Scientific Research Publishing Inc.

Creative Commons License

This work and the related PDF file are licensed under a Creative Commons Attribution 4.0 International License.