Browsing by Author "Groener, Markus K."
Now showing 1 - 7 of 7
Results Per Page
Sort Options
- Adding Value to the Software Development Process: A Study in Independent Verification and ValidationArthur, James D.; Groener, Markus K.; Hayhurst, Kelly J.; Michael Holloway, C. (Department of Computer Science, Virginia Polytechnic Institute & State University, 1998-08-01)Independent Verification and Validation (IV&V) is best viewed as an overlay process supporting a software development effort. While the touted benefits of a properly managed IV&V activity are many, they specifically emphasize: (a) early fault detection, (b) reduced time to remove faults, and (c) a more robust end-product. This paper outlines a study funded by NASA-Langley Research Center to examine an existing IV&V methodology, and to confirm (or refute) the touted beneficial claims. In the study two distinct development groups are established, with only one having an IV&V contingent. Both groups are tasked to produce a software product using the same set of requirements. Within each phase of the development effort, fault detection and fault removal data are recorded. An analysis of that data reveals that the group having the IV&V contingent: (a) detected errors earlier in the software development process, and (b) on the average, required significantly less time to remove those faults. Moreover, a test for operational correctness further reveals that the system developed by the group having the IV&V component was substantially more robust than the one produced by the other development group. A statistical analysis of our results is also provided to establish significance.
- An Assessment of SEES Based on Operational ExperiencesArthur, James D.; Groener, Markus K. (Department of Computer Science, Virginia Polytechnic Institute & State University, 1997-03-01)During the Fall of 1995 a modified form of SEES (Software Engineering Evaluation System), denoted SEES, was defined and used in a study to examine the value added of Independent Verification and Validation. A follow-on study, and topic of this report, focuses on an assessment of SEES based on operational experiences gained from the 1995 study. The report partitions its findings relative to phases of the software development process.
- Confirming the Effectiveness of the Requirements Generation ModelGroener, Markus K.; Arthur, James D. (Department of Computer Science, Virginia Polytechnic Institute & State University, 2002)Product quality is directly related to how well that product meets the customer’s needs and intents. It is paramount, therefore, to capture customer requirements correctly and succinctly. Unfortunately, most development models tend to avoid, or only vaguely define the process by which requirements are generated. Other models rely on formalistic characterizations that require specialized training to understand. To address such drawbacks we introduce the Requirements Generation Model (RGM) that (a) decomposes the conventional “requirements analysis” phase into sub-phases which focus and refine requirements generation activities, (b) constrains and structures those activities, and (c) incorporates a monitoring methodology to assist in detecting and resolving deviations from process activities defined by the RGM. The results of an industry-based study are also presented and substantiate the effectiveness of the RGM in producing a better set of requirements.
- An Operation Model Supporting the Generation of Requirements That Capture Customer IntentArthur, James D.; Groener, Markus K. (Department of Computer Science, Virginia Polytechnic Institute & State University, 1999-11-01)Product quality is a direct reflection of how well it meets the cutomer's needs. Hence, the ability to capture customer requirements correctly and succinctly is paramount. Unfortunately, within software development frameworks the gathering of requirements is one of the more ill-defined and least structured processes. To address this inadequacy, our paper (a) proposes a refinement (or decomposition) to the requirements generation phase that admits to detailed examination and promotes a better understanding of where requirements generation goes wrong,(b) using the results of a preliminary study, identifies where and how miscommunication and requirements omission occur, and (c) outlines a more structured process that can be applied early in the requirements generation process to minimize requirement faults.
- Reducing the Mean Time to Remove Faults Through Early Fault Detection, an Experiment in Independent Verification and ValidationArthur, James D.; Gupta, Sanjay; Groener, Markus K.; Cannon, Martha; Khan, Zakia (Department of Computer Science, Virginia Polytechnic Institute & State University, 1996)This paper presents the results of a study investigating the extent to which Independent Verification and Validation (IV&V) impacts early fault detection, and consequently, the mean time to remove faults. Two separate development groups, one with an IV&V team, are tasked to produce a software system from the same set of requirements. For each development phase, fault detection and removal data are recorded. An analysis of that data reveals that the group having the IV&V contingent: (a) detected errors earlier in the software development process, and (b) on the average, required substantially less time to remove those faults.
- Report on Quasi-Experiment for Evaluating SEESArthur, James D.; Frakes, William B.; Gupta, Sanjay; Cannon, Martha; Groener, Markus K.; Khan, Zakia (Department of Computer Science, Virginia Polytechnic Institute & State University, 1995-12-01)The purpose of this document is to describe the design and execution of the quasi-experiment conducted in the Department of Computer Science, Virginia Tech, in accordance with the procedures described in the document, "An Experimental Design for Evaluating SEES" prepared for NASA under contract NASI-19610, Task 17. (Hereafter that report is called the general design document.) The quasi-experiment serves three important purposes. First, the quasi-experiment is the proof of concept of the general experiment design. It shows that the procedures defined in the general experiment design can be implemented. Second, provides details for setting up a true experiment: identifying the research hypothesis, designing the investigation, selecting various variables, procedures, and controls, measuring the variables, and evaluating the results. Third, any insights revealed during the course of the quasi-experiment can be incorporated in the costly true experiment, thus providing a cost-effective experimental methodology. This report contains sufficient information so that the quasi-experiment can be replicated at an appropriate level of abstraction. We also document and interpret all the results of the quasi-experiment.
- A Study and Project-Based Evaluation of the Software Engineering Evaluation System (SEES)Arthur, James D.; Frakes, William B.; Gupta, Sanjay; Cannon, Martha; Groener, Markus K.; Khan, Zakia (Department of Computer Science, Virginia Polytechnic Institute & State University, 1997-02-01)The purpose of this document is to describe the design and execution of the quasi-experiment conducted in the Department of Computer Science, Virginia Tech, in accordance with the procedures described in the document "An Experimental Design for Evaluating SEES" prepared for NASA under contract NAS1-19610, Task 17. (Hereafter, that report is called the general design document.) The quasi-experiment serves three important purposes. First, the quasi-experiment is the proof of concept of the general experiment design. It shows that the procedures defined in the general experiment design can be implemented. Second, provides details for setting up a true experiment: identifying the research hypothesis, designing the investigation, selecting various variables, procedures, and controls, measuring the variables, and evaluating the results. Third, any insights revealed during the course of the quasi-experiment can be incorporated in the costly true experiment, thus providing a cost-effective experimental methodology. This report contains sufficient information so that the quasi-experiment can be replicated at an appropriate level of abstraction. We also document and interpret all the results of the quasi-experiment.