Graduation date: 1994

Thesis (M.S.)--Virginia Polytechnic Institute and State University, 1992. / Vita. Abstract. Includes bibliographical references (leaves 94-96). Also available via the Internet.

published_or_final_version / Computer Science / Master / Master of Philosophy

Thesis (M. Phil.)--University of Hong Kong, 1995. / Includes bibliographical references (leaf 66-74).

Thesis (M.S.)--Virginia Polytechnic Institute and State University, 1992. / Vita. Abstract. Includes bibliographical references (leaves 88-94). Also available via the Internet.

Report (M.I.S.)--Virginia Polytechnic Institute and State University, 1993. / Vita. Abstract. Includes bibliographical references (leaves 93-105). Also available via the Internet.

What kind of software documentation a systems needs and how much documentation that is necessary are questions that has a lot of different answers depending on a number of variables. Traditional software development methodologies claims that software needs a lot of documentation and more agile approaches claims that it is better to write less documentation since most documentation is never used. According to studies a ratio of 11% of software projects costs are spent on documentation alone. The purpose of this study is to create a cost efficient software documentation strategy for an existing web system with a focus on deciding what information are relevant to document in order to keep a high ROI. This study was conducted as a single case study and made in collaboration with a company. The data collection was done by interviewing key people working in the system and doing participants observations. The result shows that information documented in a high level is what is most needed. Artifacts relevant to document are the source code, requirements of updates, functional tests, high-level architecture, reference manual and an end-user manual. The result also shows that new processes need to be implemented for the documentation strategy to be efficient. Recommendation for further research is to create a method of how to calculate the ROI for software documentation based on a number of organizational variables. / <p>Validerat; 20160615 (global_studentproject_submitter)</p>

During software development various forms of software documentation can be produced to make the software easier to understand and maintain after the software have been developed. One of these forms of software documentation is code comments, which is a form of software documentation that is produced to make source code easier to read and maintain. Although code comments make the code easier to read and maintain, code comments can become outdated and inconsistent with their corresponding code. Outdated and inconsistent code comments increase the probability for future bugs and when these comments are encountered, developers could lose the confidence for all other comments. In order to reduce the amount of outdated and inconsistent code comments, a program named the comment validator is presented in this study. The comment validator provides developers with the opportunity to manually validate code comments by segmenting code into three segments of code that needs to be manually validated: classes, methods and properties. The comment validator identifies when code segments have been modified after validation, therefore indicating that the code segments corresponding code comments could be outdated and inconsistent. The comment validator were evaluated through functional testing and through a field study in order to test that the comment validator could reduce the amount of outdated and inconsistent code comments. The evaluation showed that the comment validator did remove outdated and inconsistent code comments when it were used according to the description presented in this study, therefore providing a new way to reduce the amount of outdated and inconsistent code comments in software development projects.

The practice of literate programming is not widespread because existing literate programming systems have some undesirable characteristics such as programming language and text processor dependence and lack of flexible tools for viewing and manipulation of the source file. This dissertation describes the literate programming system AOPS (Abstraction Oriented Programming System) which addresses both of these problems. AOPS is programming language and text processor independent literate programming system. AOPS tools include a hypertext browser, a lister with the ability to select what is presented and what is suppressed, and a filter to extract the program code from the AOPS source file. AOPS introduces the notion of a phantom abstraction that enhances the understandability of the literate program and when used in conjunction with the browser greatly extends the capabilities of AOPS. We also discuss how the design of AOPS supports extension of the concept of literate programming to encompass the entire software life cycle. Finally we describe an experiment which showed that literate programs contain more documentation than traditional programs. / Graduation date: 1993

To incorporate users' opinions into the evaluation phase early in the software documentation development stage, the critical incident technique was used to identify usability problems in a fault free software user document. The critical incidents were used to modify the original document to improve its usability. To test whether the modified document was better in usability than the original document, an experiment was conducted to compare objective measures and subjective ratings. Four objective measures included number of errors, task completion time, document reading time, and number of personal helps requested. In addition, subjective ratings on ease of use, accuracy of information, inconsistencies, ease of learning, completeness, helpfulness of figures, and ease of understanding were compared between the two documents. The analyses showed that for 3 of 4 objective measures and 7 out of 9 subjective ratings, the new document was better and easier to use. In some cases, this difference was task specific. Generally, easier tasks accounted for better objective measures and more favorable subjective ratings. / Master of Science