Neil Iscoe

Bio: Neil Iscoe is an academic researcher from University of Texas at Austin. The author has contributed to research in topics: Domain knowledge & Application domain. The author has an hindex of 2, co-authored 5 publications receiving 2255 citations.

A field study of the software design process for large systems

Abstract: The problems of designing large software systems were studied through interviewing personnel from 17 large projects. A layered behavioral model is used to analyze how three of these problems—the thin spread of application domain knowledge, fluctuating and conflicting requirements, and communication bottlenecks and breakdowns—affected software productivity and quality through their impact on cognitive, social, and organizational processes.

Modeling the Software Design Process

Abstract: There are many levels at which the software development process can be modeled. MCC-STP’s Empirical Studies Team has developed a layered behavioral model to guide our analyses of these processes. We have performed empirical studies of processes at each of these levels. At the level of individual cognitive problem-solving processes, we conducted a thinking aloud protocol study wherein software professionals were given a specification for an elevator system (a lift) and instructed to design a control system for it to the level of detail that they would hand over to a competent programmer for implementation. In this Lift Experiment we were seeking to determine the primary breakdowns experienced during design to determine the functionality that should be explored in developing prototypes of design tools. At the team and project levels, we videotaped three months worth of requirements and design meetings of a project team designing an object server. We analyzed these tapes to determine how group dynamics altered the processes we observed during individual design problem-solving, and what types of design technology should be provided in the group meeting environment. Finally, at the organizational and business milieu levels we conducted on-site interviews with personnel from 17 large software development projects to gather case study information on actual design processes. Transcripts of these interviews were analyzed to model factors affecting the processes of making design decisions and communicating them across the project. In this paper models of the software process developed at each of the levels are described and the aggregation of their effects across levels are discussed.

Domain-specific programming: an object-oriented and knowledge-based approach to specification and generation

Abstract: Programmers must have an understanding of both programming knowledge and application domain knowledge to write application programs. But while programming is well enough understood to model and teach, application domain knowledge is not yet well understood, and is codified only in an informal ad hoc manner. Because representations that precisely characterize application domain knowledge do not currently exist, errors are frequently made when gathering and mapping specifications from the informal to the formal. This dissertation defines a meta-model for application domain knowledge and describes a methodology for its instantiation into domain-specific models. Domain models are representations of application domains that can be used for a variety of operational goals in support of specific software engineering tasks or processes. The meta-model and methodology in this dissertation facilitate understanding and analyzing application areas and eliciting and formalizing software requirements and specifications. The emphasis is on general characterization techniques that can be used to instantiate models from different application domains.

Reuse: A knowledge-based approach

Abstract: This paper describes our research in automating the reuse process through the use of application domain models. Application domain models are explicit formal representations of the application knowledge necessary to understand, specify, and generate application programs. Furthermore, they provide a unified repository for the operational structure, rules, policies, and constraints of a specific application area. In our approach, domain models are expressed in terms of a transaction-based meta-modeling language. This paper has described in detail the creation and maintenance of hierarchical structures. These structures are created through a process that includes reverse engineering of data models with supplementary enhancement from application experts. Source code is also reverse engineered but is not a major source of domain model instantiation at this time. In the second phase of the software synthesis process, program specifications are interactively synthesized from an instantiated domain model. These specifications are currently integrated into a manual programming process but will eventually be used to derive executable code with mechanically assisted transformations. This research is performed within the context of programming-in-the-large types of systems. Although our goals are ambitious, we are implementing the synthesis system in an incremental manner through which we can realize tangible results. The client/server architecture is capable of supporting 16 simultaneous X/Motif users and tens of thousands of attributes and classes. Domain models have been partially synthesized from five different application areas. As additional domain models are synthesized and additional knowledge is gathered, we will inevitably add to and modify our representation. However, our current experience indicates that it will scale and expand to meet our modeling needs.

Process modeling

Abstract: • Business process reengineering-the redesign of an organization's business processes to make them more efficient. • Coordination technology-an aid to managing dependencies among the agents within a business process, and provides automated support for the most routinized component processes. * Process-driven software development environments-an automated system for integrating the work of all software related management and staff; it provides embedded support for an orderly and defined software development process. These three applications share a growing requirement to represent the processes through which work is accomplished. To the extent that automation is involved, process representation becomes a vital issue in redesigning work and allocating responsibilities between humans and computers. This requirement reflects the growing use of distributed , networked systems to link the interacting agents responsible for executing a business process. To establish process modeling as a unique area, researchers must identify conceptual boundaries that distinguish their work from model-ing in other areas of information science. Process modeling is distinguished from other types of model-ing in computer science because many of the phenomena modeled must be enacted by a human rather than a machine. At least some mod-eling, however, in the area of human-machine system integration or information systems design has this 'human-executable' attribute. Rather than focusing solely on the user's behavior at the interface or the flow and transformation of data within the system, process model-ing also focuses on interacting behaviors among agents, regardless of whether a computer is involved in the transactions. Much of the research on process modeling has been conducted on software development organizations , since the software engineering community is already accustomed to formal modeling. Software process modeling, in particular , explicitly focuses on phenomena that occur during software creation and evolution, a domain different from that usually mod-eled in human-machine integration or information systems design. Software development is a challenging focus for process modeling because of the creative problem-solving involved in requirements analysis and design, and the coordination of team interactions during the development of a complex intellectual artifact. In this article, software process modeling will be used as an example application for describing the current status of process modeling, issues for practical use, and the research questions that remain ahead. Most software organizations possess several yards of software life cycle description, enough to wrap endlessly around the walls of project rooms. Often these descriptions do not correspond to the processes actually performed during software …

Two case studies of open source software development: Apache and Mozilla

Abstract: According to its proponents, open source style software development has the capacity to compete successfully, and perhaps in many cases displace, traditional commercial development methods. In order to begin investigating such claims, we examine data from two major open source projects, the Apache web server and the Mozilla browser. By using email archives of source code change history and problem reports we quantify aspects of developer participation, core team size, code ownership, productivity, defect density, and problem resolution intervals for these OSS projects. We develop several hypotheses by comparing the Apache project with several commercial projects. We then test and refine several of these hypotheses, based on an analysis of Mozilla data. We conclude with thoughts about the prospects for high-performance commercial/open source process hybrids.

Towards modelling and reasoning support for early-phase requirements engineering

Abstract: Requirements are usually understood as stating what a system is supposed to do, as apposed to how it should do it. However, understanding the organizational context and rationales (the "Whys") that lead up to systems requirements can be just as important for the ongoing success of the system. Requirements modelling techniques can be used to help deal with the knowledge and reasoning needed in this earlier phase of requirements engineering. However most existing requirements techniques are intended more for the later phase of requirements engineering, which focuses on completeness, consistency, and automated verification of requirements. In contrast, the early phase aims to model and analyze stakeholder interests and how they might be addressed, or compromised, by various system-and-environment alternatives. This paper argues, therefore, that a different kind of modelling and reasoning support is needed for the early phase. An outline of the i* framework is given as an example of a step in this direction. Meeting scheduling is used as a domain example.

Coordinating Expertise in Software Development Teams

Abstract: Like all teams, knowledge teams must acquire and manage critical resources in order to accomplish their work. The most critical resource for knowledge teams is expertise, or specialized skills and knowledge, but the mere presence of expertise on a team is insufficient to produce high-quality work. Expertise must be managed and coordinated in order to leverage its potential. That is, teams must be able to manage their skill and knowledge interdependencies effectively through expertise coordination, which entails knowing where expertise is located, knowing where expertise is needed, and bringing needed expertise to bear. This study investigates the importance of expertise coordination through a cross-sectional investigation of 69 software development teams. The analysis reveals that expertise coordination shows a strong relationship with team performance that remains significant over and above team input characteristics, presence of expertise, and administrative coordination.

Modelling strategic relationships for process reengineering

Abstract: 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 or redesign a process, however, one also needs to have an understanding of the "why"--for example, why do physicians 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 depended 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 have about existing processes and proposed alternatives, and how they might be addressed, in terms of a network of means-ends relationships. An agent's routines for carrying out a process can be analyzed for their ability, workability, viability and believability. Means-ends rules are used to suggest methods for addressing issues, related issues to be raised, and assumptions to be challenged. The models are represented in the conceptual modelling language Telos. The modelling concepts are axiomatically characterized. The utility of the framework is illustrated each of four application areas: requirements engineering, business process reengineering, organizational impacts analysis, and software process modelling. Advantage of i* over existing modelling techniques in each of these areas are described.