Results 1 - 10
of
458
Modeling Strategic Relationships for Process Reengineering
, 1995
"... Existing models for describing a process (such as a business process or a software development process) tend to focus on the \what " or the \how " of the process. For example, a health insurance claim process would typically be described in terms of a number of steps for assessing and appr ..."
Abstract
-
Cited by 545 (40 self)
- Add to MetaCart
Existing models for describing a process (such as a business process or a software development process) tend to focus on the \what " or the \how " of the process. For example, a health insurance claim process would typically be described in terms of a number of steps for assessing and approving a claim. In trying to improve orredesign a process, however, one also needs to have an understanding of the \why " { for example, why dophysicians submit treatment plans to insurance companies before giving treatment? and why do claims managers seek medical opinions when assessing treatment plans? An understanding of the motivations and interests of process participants is often crucial to the successful redesign of processes. This thesis proposes a modelling framework i (pronounced i-star) consisting of two modelling components. The Strategic Dependency (SD) model describes a process in terms of intentional dependency relationships among agents. Agents depend on each other for goals to be achieved, tasks to be performed, and resources to be furnished. Agents are intentional in that they have desires and wants, and strategic in that they are concerned about opportunities and vulnerabilities. The Strategic Rationale (SR) model describes the issues and concerns that agents
A Safe, Efficient Regression Test Selection Technique
- ACM TRANSACTIONS ON SOFTWARE ENGINEERING AND METHODOLOGY
, 1997
"... Regression testing is an expensive but necessary maintenance activity performed on modified software to provide confidence that changes are correct and do not adversely affect other portions of the software. A regression test selection technique chooses, from an existing test set, tests that are d ..."
Abstract
-
Cited by 221 (64 self)
- Add to MetaCart
Regression testing is an expensive but necessary maintenance activity performed on modified software to provide confidence that changes are correct and do not adversely affect other portions of the software. A regression test selection technique chooses, from an existing test set, tests that are deemed necessary to validate modified software. We present a new technique for regression test selection. Our algorithms construct control flow graphs for a procedure or program and its modified version, and use these graphs to select tests that execute changed code from the original test suite. We prove that under certain conditions, the set of tests our technique selects includes every test from the original test suite that can expose faults in the modified procedure or program. Under these conditions our algorithms are safe. Moreover, although our algorithms may select some tests that cannot expose faults, they are at least as precise as other safe regression test selection algorith...
Cost Models for Future Software Life Cycle Processes: COCOMO 2.0
- ANNALS OF SOFTWARE ENGINEERING
, 1995
"... Current software cost estimation models, such as the 1981 Constructive Cost Model (COCOMO) for software cost estimation and its 1987 Ada COCOMO update, have been experiencing increasing difficulties in estimating the costs of software developed to new life cycle processes and capabilities. These inc ..."
Abstract
-
Cited by 121 (7 self)
- Add to MetaCart
(Show Context)
Current software cost estimation models, such as the 1981 Constructive Cost Model (COCOMO) for software cost estimation and its 1987 Ada COCOMO update, have been experiencing increasing difficulties in estimating the costs of software developed to new life cycle processes and capabilities. These include non-sequential and rapid-development process models; reuse-driven approaches involving commercial off the shelf (COTS) packages, reengineering, applications composition, and applications generation capabilities; object-oriented approaches supported by distributed middleware; and software process maturity initiatives. This paper
Verifying and validating software requirements and design specifications
- IEEE Software
, 1984
"... This paper presents the following guideline information on verification and validation (V&V) of software requirements and design specifications: Definitions of the terms "verification " and "validation, " and an explanation of their context in the software life-cycle; A descr ..."
Abstract
-
Cited by 105 (0 self)
- Add to MetaCart
(Show Context)
This paper presents the following guideline information on verification and validation (V&V) of software requirements and design specifications: Definitions of the terms "verification " and "validation, " and an explanation of their context in the software life-cycle; A description of the basic sequence of functions performed during software requirements and design V&V An explanation, with examples: of the major software requirements and design V&V criteria: completeness, consistency, feasibility, and testability; An evaluation of the relative cost and effectiveness of the major software requirements and design V&V techniques with respect to the above criteria; An example V&V checklist for software system reliability and availability. Based on the above, the paper provides recommendations of the combination of software requirements and design V&V techniques most suitable for small, medium, and large software specifications. I. OBJECTIVES The basic objectives in verification and validation (V&V) of software requirements and design specifications are to identify and resolve software problems and high-risk issues early in the software life-cycle. The main reason for doing this is indicated in Figure 1, (1). It shows that savings of up to 100:1 are possible by finding and fixing problems early rather than late in the life-cycle. Besides the major cost savings, there are also significant payoffs in improved
An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks
- IEEE TRANSACTIONS ON SOFTWARE ENGINEERING
, 2006
"... Much of software developers’ time is spent understanding unfamiliar code. To better understand how developers gain this understanding and how software development environments might be involved, a study was performed in which developers were given an unfamiliar program and asked to work on two debug ..."
Abstract
-
Cited by 103 (14 self)
- Add to MetaCart
(Show Context)
Much of software developers’ time is spent understanding unfamiliar code. To better understand how developers gain this understanding and how software development environments might be involved, a study was performed in which developers were given an unfamiliar program and asked to work on two debugging tasks and three enhancement tasks for 70 minutes. The study found that developers interleaved three activities. They began by searching for relevant code both manually and using search tools; however, they based their searches on limited and misrepresentative cues in the code, environment, and executing program, often leading to failed searches. When developers found relevant code, they followed its incoming and outgoing dependencies, often returning to it and navigating its other dependencies; while doing so, however, Eclipse’s navigational tools caused significant overhead. Developers collected code and other information that they believed would be necessary to edit, duplicate, or otherwise refer to later by encoding it in the interactive state of Eclipse’s package explorer, file tabs, and scroll bars. However, developers lost track of relevant code as these interfaces were used for other tasks, and developers were forced to find it again. These issues caused developers to spend, on average, 35 percent of their time performing the mechanics of navigation within and between source files. These observations suggest a new model of program understanding grounded in theories of information foraging and suggest ideas for tools that help developers seek, relate, and collect information in a more effective and explicit manner.
How Effective Developers Investigate Source Code: An Exploratory Study
- IEEE Transactions on Software Engineering
, 2004
"... ©2004 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other wo ..."
Abstract
-
Cited by 99 (15 self)
- Add to MetaCart
(Show Context)
©2004 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
Security Models
- Encyclopedia of Software Engineering
, 1994
"... this article we focus on the primary use of security models, which has been to describe general confidentiality requirements. We then give pointers to security model work in other areas. 2 Models of Confidentiality ..."
Abstract
-
Cited by 90 (2 self)
- Add to MetaCart
(Show Context)
this article we focus on the primary use of security models, which has been to describe general confidentiality requirements. We then give pointers to security model work in other areas. 2 Models of Confidentiality
Automatic generation of suggestions for program investigation
- In Proc. Joint Europ. Softw. Eng. Conf. and ACM SIGSOFT Int’l Symp. Foundations Softw. Eng
, 2005
"... Before performing a modification task, a developer usually has to investigate the source code of a system to understand how to carry out the task. Discovering the code relevant to a change task is costly because it is an inherently human activity whose success de-pends on a large number of unpredict ..."
Abstract
-
Cited by 83 (2 self)
- Add to MetaCart
(Show Context)
Before performing a modification task, a developer usually has to investigate the source code of a system to understand how to carry out the task. Discovering the code relevant to a change task is costly because it is an inherently human activity whose success de-pends on a large number of unpredictable factors, such as intuition and luck. Although studies have shown that effective developers tend to explore a program by following structural dependencies, no methodology is available to guide their navigation through the typically hundreds of dependency paths found in a non-trivial pro-gram. In this paper, we propose a technique to automatically pro-pose and rank program elements that are potentially interesting to a developer investigating source code. Our technique is based on an analysis of the topology of structural dependencies in a program. It takes as input a set of program elements of interest to a developer and produces a fuzzy set describing other elements of potential in-terest. Empirical evaluation of our technique indicates that it can help developers quickly select program elements worthy of inves-tigation while avoiding less interesting ones.
Representing Concerns in Source Code
, 2003
"... Many program evolution tasks involve source code that is not modularized as a single unit. Furthermore, the source code relevant to a change task often implements different concerns, or high-level concepts that a developer must consider. Finding and understanding concerns scattered in source code is ..."
Abstract
-
Cited by 78 (7 self)
- Add to MetaCart
(Show Context)
Many program evolution tasks involve source code that is not modularized as a single unit. Furthermore, the source code relevant to a change task often implements different concerns, or high-level concepts that a developer must consider. Finding and understanding concerns scattered in source code is a difficult task that accounts for a large proportion of the effort of performing program evolution. One possibility to mitigate this problem is to produce textual documentation that describes scattered concerns. However, this approach is impractical because it is costly, and because, as a program evolves, the documentation becomes inconsistent with the source code. The thesis of this dissertation is that a description of concerns, representing program structures and linked to source code, that can be produced cost-effectively during program investigation activities, can help developers perform software evolution tasks more systematically, and on different versions of a system. To validate the claims of this thesis, we have developed a model for a structure, called concern graph, that describes concerns in source code in terms of relations between program elements. The model also defines precisely the notion of inconsistency between a concern graph and the
Formalised systems development methodologies: a critical perspective
- Information Systems Journal
, 1996
"... Systems development issues occupy a position of central importance in the information systems field and, indeed, much has been prescribed in the quest for successful systems development. However, given the well-documented "software crisis", success is far from guaranteed for system ..."
Abstract
-
Cited by 64 (8 self)
- Add to MetaCart
(Show Context)
Systems development issues occupy a position of central importance in the information systems field and, indeed, much has been prescribed in the quest for successful systems development. However, given the well-documented "software crisis", success is far from guaranteed for systems development projects. Many researchers see the solution to the software crisis in terms of increased control and the more widespread adoption of rigorous and formalised system development methodologies. This paper first presents some arguments and pressures which support the use of methodologies. Some evidence of the literature bias which favours methodologies is also provided. However, the problems associated with the use of methodologies have not perhaps received as much attention in previous research. This paper identifies a number of arguments and pressures which question the value of methodologies, and reports the results of a field study which investigated the role of methodologies in practice. The critical perspective adopted in this paper shows that, contrary to the predominant literature view, the assumption that increased adoption of methodologies would help address the problems inherent in systems development is by no means proven.
