留学生论文开发软件文档使用技术:系列

论文类型：留学生论文

论文字数：

论点：3.5,References,3.3

论文概述：

Developing Techniques for Using Software Document 留学论文 s:A Series of Empirical Studies Ph.D. Thesis Proposal Forrest J. Shull University of Maryland Abstract This proposal presents an empirical method for developing reading techniques t

论文正文：

Developing Techniques for Using Software Documents: A Series of Empirical StudiesPh.D. Thesis ProposalForrest J. ShullUniversity of MarylandAbstractThis proposal presents an empirical method for developing “reading techniques” that give effective,procedural guidance to software practitioners. Each reading technique is tailored so that it can be used toaccomplish a specific software-related task (e.g. defect detection) using a specific kind of softwaredocument (e.g. requirements). This empirical method can be followed to create and then continuallyimprove reading techniques, since it explicitly builds and tests underlying models of how developers use aparticular software document in a particular environment. That is, our approach for developing readingtechniques checks the underlying assumptions about:· Specific tasks for which the document will be used· Aspects of the document that must be understood to support those tasks· Aspects of the environment affecting tasks using the documentThis empirical approach avoids the mistake of applying assumptions that are true in other environments toa context in which they have not been tested.We illustrate the development method by discussing how it was used to create two readingtechniques (one for finding defects in requirements, and a second for reusing design and code from anObject-Oriented framework in a new system). We describe a series of studies by which we and otherresearchers have assessed the effectiveness of these techniques in practical situations. These studies showthat these reading techniques are useful and effective guidelines for accomplishing real softwareengineering tasks, and thus demonstrate the effectiveness of the empirical development method.Finally, this proposal discusses how indications from these studies have been used to begin toformulate higher-level hypotheses about reading techniques. We discuss the results from these earlierstudies as well as important questions that have not yet been addressed. We propose a further study that isdesigned to test potential improvements to one of our reading techniques and, in the process, shed somelight on the unanswered questions from our earlier studies.1Table of Contents1. Introduction 21.1. Problem Statement 31.2. Proposed Solution 41.2.1. Definitions 41.2.2. Focusing on Software Documents 51.2.3. An Empirical Approach 81.2.4. A Process for Developing Reading Techniques 91.2.5. An Example 161.3. Validation Plan 201.3.1. Evaluating Reading Techniques 201.3.2. Evaluating the Process for Developing Reading Techniques 212. Completed Work 242.1. Investigating a Technique for Analysis of Requirements: PBR 252.1.1. Introduction 252.1.2. Related Work 252.1.3. Modeling 262.1.4. Mapping Models to Procedure 272.1.5. Description of the Study 292.1.6. Evaluation of Effectiveness in the Environment 312.1.7. Evaluation of Level of Specificity 322.1.8. Evaluation of Measures of Subject Experience 332.1.9. Evaluation of Tailoring to Other Environments 342.1.10. Conclusions and Indications for Future Research into PBR 362.2. Investigating a Technique for Reuse of Code and Design: SBR 372.2.1. Introduction 372.2.2. Related Work 382.2.3. Modeling 382.2.4. Mapping Models to Procedure 392.2.5. Description of the Study and Analysis 402.2.6. Evaluation of Effectiveness in the Environment 422.2.7. Evaluation of Level of Specificity 442.2.8. Evaluation of Measures of Subject Experience 462.2.9. Evaluation of Tailoring to Other Environments 472.2.10. Conclusions and Indications for Future Research into SBR 472.3. Summary of Completed Work 493. Proposed Work 513.1. Introduction 513.2. Modeling 533.3. Mapping Models to Procedure 533.4. Description of the Study 553.5. Evaluating the Reading Techniques 574. Summary 59References 60AppendicesA. Sample requirements 65B. PBR procedures 67C. SBR procedures 70D. New versions of PBR, for proposed work 74E. Data collection forms and questionnaires, for proposed work 8021 IntroductionThis proposal presents a body of research that makes two main contributions to software engineering:1. It presents an iterative process for creating and improving reading techniques, which are proceduraltechniques that give effective guidance for accomplishing a specific software-related task. We refer tothis process simply as the Reading Technique Development (RTD) process. As will be explained ingreater detail in the rest of this chapter, reading techniques created by the RTD process provide aneffective way to use a given software document (such as requirements) for a particular task (forexample, defect detection).2. It presents two reading techniques that have been tailored to different documents and tasks. Asidefrom providing a demonstration of the effectiveness of the RTD process, these techniques alsorepresent useful and effective procedures that can aid in accomplishing some common tasks insoftware engineering.This proposal also discusses a series of studies that provide an empirical evaluation of particularreading techniques, and uses the experimental results to begin building a body of knowledge about this typeof technique and their application. As part of this discussion, we demonstrate that our understanding of theexperimental methods and results can be packaged in a way that allows others to learn from and extend ourfindings.This proposal is organized as follows: Section 1.1 motivates why the RTD process is useful andnecessary, by discussing the specific problem it addresses. Section 1.2 presents the RTD process as ourproposed solution, provides the relevant definitions, and defines the scope of this work. Section 1.3outlines how we intend to provide an empirical validation of our proposed solution.The remaining chapters of this proposal are concerned with studying the effects of our proposedsolution in practice. Chapter 2 provides an overview of work we have already undertaken in this area,identifying common themes and explaining the most important open research questions. Finally, chapter 3proposes a new study to continue this work.31.1 PROBLEM STATEMENTSoftware practitioners are interested in using effective software development processes, and for this theyhave many tools and processes from which to choose. The field of software engineering has producedmany such options, ranging from large sweeping process changes (e.g. moving to an Object-Orientedprogramming paradigm) to detailed refinements of a particular aspect of the software lifecycle (e.g. using aformal notation rather than natural language to record system requirements). In trying to quantify thisphenomenon, some sources have counted that, since the 1970s, “literally hundreds” of different workpractices have appeared and have been claimed to somehow improve software development [Law93].Relying on standards bodies to identify effective processes does not greatly simplify the situation, sinceover 250 “standard practices” have been published in software engineering [Fenton94].The dilemma, of course, is how the practitioner is to know which tools and processes to invest in,when almost all of them come with claims of enhanced productivity. All too often, the wrong decision ismade and both software practitioners and researchers invest time and money in tools and processes thatnever see significant use. Tools and processes can fail to find use for several reasons:· they are too difficult to integrate into the standard way of doing things for an organization;· they do not pay adequate attention to the needs of the user;· they require the developer to invest too much effort for too little gain;· they incorporate techniques or technologies that are not effective in the particular environment;· the limits of their effectiveness are simply not understood.Actually, all of these reasons are inter-related. The common theme is that the tools and processesin question simply do not match the requirements of the environment in which they are to be used. Often,even the developers of an approach do not know how effective it will be in a given environment, what itslimitations are, or to what classes of users it is best suited.This situation could be avoided if process development and tools selection were based on anempirical characterization of what works and what does not work in a particular environment. Such anempirical foundation avoids ad-hoc selection of software tools and techniques based upon assumptions(about the tasks developers need to do, about the types of information developers need to understand, aboutcharacteristics of the product being developed) that are never checked. In their paper, Science andSubstance: A Challenge to Software Engineers, Fenton, Pfleeger, and Glass dwell on the plethora of tools,standards, and processes available before pointing out that “much of what we believe about whichapproaches are best is based on anecdotes, gut feelings, expert opinions, and flawed research.” What isneeded, they conclude, is a careful, empirical approach [Fenton94].Basili described the basics of such an empirical approach in his paper, The Experimental Paradigmin Software Engineering. To develop an understanding of the effectiveness of software processes in aparticular environment, he stresses the necessity of starting from a real understanding of the softwaredevelopment process, not from assumptions. He advocates:· modeling the important components of software development in the environment (e.g. processes,resources, defects);· integrating these models to characterize the development process;· evaluating and analyzing these models through experimentation;· continuing to refine and tailor these models to the environment. [Basili93]As demonstrated in this chapter, we use these guidelines as the basis of our empirical approach.41.2 PROPOSED SOLUTION1.2.1 DefinitionsThis dissertation proposal presents an empirical approach for developing tailored techniques for use bysoftware practitioners. We refer to these techniques as “reading techniques.” The word “reading” waschosen to emphasize the similarities with the mental processes we use when attempting to understand anymeaningful text; a reading technique is a process a developer can follow in attempting to understand anytextual software work document. It is important to note that, while “reading” in software engineering isoften assumed to apply only to code, in fact any document used in the software lifecycle has to be readeffectively. (For example, requirements documents have to be read effectively in order to find defects ininspections.) We address the problem space in more detail in section 1.2.2.More specifically, a reading technique can be characterized as a series of steps for the individualanalysis of a textual software product to achieve the understanding needed for a particular task [Basili96b].This definition has three important components:1. A series of steps: The technique must give guidance to the practitioner. The level of guidance mustvary depending on the level best suited to the goal of the task, and may vary from a specific step-bystepprocedure to a set of questions on which to focus.2. Individual analysis: Reading techniques are concerned with the comprehension process that occurswithin an individual. Although the method in which this technique is embedded may requirepractitioners to work together after they have reviewed a document (e.g. to discuss potential defectsfound individually in a document), the comprehension of some aspect of the document is still anindividual task.3. The understanding needed for a particular task: Reading techniques have a particular goal; they aim atproducing a certain level of understanding of some (or all) aspects of a document. Thus, although wemay think about CASE tools to support a technique as it evolves, the focus of this research is not onthe tools themselves but on the developer’s understanding of artifacts (whether supported by tools ornot).The research presented in this proposal demonstrates a proof of concept that our approach todeveloping software reading techniques can be effective, by providing empirical evidence concerning theeffectiveness of the specific techniques developed. We also propose to validate our approach by testingwhether it can be used to build up knowledge about reading techniques in general. These goals are broadbut we narrow them to more detailed evaluation questions in section 1.3.To be as clear as possible about the scope of the work presented in this proposal, we use thefollowing definitions:· Technique: A series of steps, at some level of detail, that can be followed in sequence to complete aparticular task. Unless we qualify the phrase, when we speak of “techniques” in this proposal we arereferring specifically to “reading techniques,” that is, techniques that meet the three criteria presentedat the beginning of this section.· Method: A management-level description of when and how to apply techniques, which explains notonly how to apply a technique, but also under what conditions the technique’s application isappropriate. (This definition is taken from [Basili96].)· Software document: Any textual artifact that is used in the software development process. Thisdefinition encompasses artifacts from any stage of the software lifecycle (from requirements elicitationthrough maintenance), either produced during the development process (e.g. a design plan) orconstructed elsewhere but incorporated into the software lifecycle (e.g. a code library).Our definitions sharply differentiate a technique from a method. Perspective-Based Reading(PBR), discussed in section 2.1, provides a useful example of each. PBR recommends that reviewers useone of three distinct techniques in reviewing requirements documents to find defects. Each of thesetechniques is expressed as a procedure that reviewers can follow, step by step, to achieve the desired result.PBR itself is a method, because it contains information about the context in which the techniques can beeffectively applied, and about the manner in which the individual techniques should be used in order toachieve the most thorough review of the document.51.2.2 Focusing on Software DocumentsOne of the most important characteristics of our approach to developing reading techniques is the focus onproviding guidance for how developers use software documents. Software documents are importantbecause they contain much of the relevant information for software development and are used to supportalmost all of the developer’s tasks. Developers are required every day not only to construct workdocuments associated with software development (e.g., requirements, design, code, and test plans) but alsoto analyze them for a variety of reasons. For example:· requirements must be checked to see that they represent the goals of the customer,· code that was written by another developer must be understood so that maintenance can beundertaken,· test plans must be checked for completeness,· all documents must be checked for correctness.In short, software documents often require continual understanding, review, and modification throughoutthe development life cycle. The individual analysis of software documents is thus the core activity in manysoftware engineering tasks: verification and validation, maintenance, evolution, and reuse. By focusing onsoftware documents we focus on the sources of information that are crucial for the entire developmentprocess.For example, our primary research environment in the NASA Software Engineering Laboratory(SEL) uses a model of software development that consists of eight different phases (requirementsdefinition, requirements analysis, preliminary design, detailed design, implementation, system testing,acceptance testing, maintenance & operation). Each phase is characterized by specific tasks and theproducts that they produce [SEL92]. From observation of this environment we draw two importantconclusions about software documents: