Document classification for software quality systems

Laitinen, Kari

doi:10.1145/141874.141882

Cited by 13 publications

(6 citation statements)

References 5 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Kipyegen and William as well as Laitinen [17,18] put forward that software development is supposed to be documentation-oriented, which means that documents are considered to be the most essential and valuable products of the development process. On the other hand, a product such as executable machine code is regarded as a by-product in the development process, because in a development environment we can always derive correct executable machine code when we have the correct documents.…”

Section: Related Literature Reviewmentioning

confidence: 99%

Software Template for Evaluating and Scoring Software Project Documentations

Chomal¹,

Saini²

2015

IJCA

View full text Add to dashboard Cite

Significant documentation is been formed with almost all software projects, irrespective of application. Software project documentation is a perspective whose purpose is to communicate information about the software system. For research purpose documentations of final year students of Masters level course have been considered for the research purpose. These documentations consist of the artefacts like requirement analysis, technical environment, database design, structural and object oriented modelling techniques, screen layouts and testing techniques along with test case and data. The results were compiled from 505 large software project documentations developed during a period of academic years from 2001-2002 to 2011-2012. The duration of these software projects was six months. Errors from these software project documentations were found and these errors were classified into 11 broad error categories. After compilation of results and studying various artefacts in software project documentations 103 software attributes were recognized. These software attributes were classified into two broad classes (a) Quantifiable attributes and (b) Non-quantifiable attributes. Out of 103 software attributes, 39 were quantifiable attributes and 64 non-quantifiable attributes. Subsequent to categorization, weights were assigned to these quantifiable software attributes only for which a survey was conducted. The basic goal of assigning weights to these quantifiable attributes was to score software project documentation. Further, software template is been proposed for evaluating and scoring student"s software projects documentation.

show abstract

Section: Related Literature Reviewmentioning

confidence: 99%

Software Template for Evaluating and Scoring Software Project Documentations

Chomal¹,

Saini²

2015

IJCA

View full text Add to dashboard Cite

show abstract

“…The development of this work has been both and more, as our engagement with TrollCo's Issue Description Versions One, two, three Scrapped Version two saw the removal of a "contain" facet that referred to contents such as geometry, words, and numbers Refined Manifestation, refined from single facet to two covering electronic and physical. The use of the MIT process handbook functional concerns rather than local division names Additional sources Additional sources such as the ISO9001 standard (ISO9001, 2000), the MIT process handbook (Malone et al, 2003;Laitinen's, 1992) documents has evolved, facets have been, scrapped and refined and as new work has come to our attention additional facets have been added. Some of the facets were derived from the document corpus and this corpus itself was the acid test of whether preconceptions and conceptions held up against the data.…”

Section: Documents With Faceted Approachesmentioning

confidence: 99%

Describing engineering documents with faceted approaches

Wild

Giess

McMahon³

2009

Journal of Documentation

View full text Add to dashboard Cite

Purpose -The purpose of this paper is to highlight the difficulty of applying faceted classification outside of library contexts and also to indicate that faceted approaches are poorly expressed to non-experts. Design/methodology/approach -The faceted approach is being applied outside of its "home" community, with mixed results. The approach is based in part on examination of a broad base of literature and in part on results and reflections on a case study applying faceted notions to "real world" engineering documentation. Findings -The paper comes across a number of pragmatic and theoretical issues namely: differing interpretations of the facet notion; confusion between faceted analysis and faceted classification; lack of methodological guidance; the use of simplistic domains as exemplars; description verses analysis; facet recognition is unproblematic; and is the process purely top-down or bottom-up. Research limitations/implications -That facet analysis is not inherently associated with a particular epistemology; that greater guidance about the derivation is needed, that greater realism is needed when teaching faceted approaches. Practical implications -Experiences of applying faceted classifications are presented that can be drawn upon to guide future work in the area. Originality/value -No previous work has reflected on the actual empirical experience used to create a faceted description, especially with reference to engineering documents.

show abstract

“…Only by revisiting and The general notion of there being documents that are tied to the quality process was derived from the document corpus. The specific facets and ranges were adopted from an existing paper on software quality documentation (Laitinen, 1992), as they are generic enough to describe key design documents Descriptions-description appendices BU TD 5…”

Section: Article In Pressmentioning

confidence: 99%