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.

http://www.cs.rug.nl/search/uploads/Teaching/RE2009Fall/paper/1988_Curtis_ACMC_A%20Field%20Study%20of%20the%20Software%20Design%20Process%20for%20Large%20Systems.pdf

A field study of the software design process for large systems

• 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 …

Process modeling

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.

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

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.

/pdf/towards-modelling-and-reasoning-support-for-early-phase-48szrigqxo.pdf

Towards modelling and reasoning support for early-phase requirements engineering

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.

Coordinating Expertise in Software Development Teams

Breakdowns and processes during the early activities of software design by professionals

Communication breakdowns and boundary spanning activities on large programming projects

ompetitive pressures on the software industry from home and abroad have encouraged organizations to examine the effectiveness of their software development and evolution processes. This examination is occurring within the context of establishing performance baselines, setting improvement goals, explicitly defining the normally implicit processes and measuring progress toward improvement goals. A typical objective of a company engaged in a software improvement initiative focused on achieving higher capability maturity levels is to document the current software process (i.e., \"as is\" baseline) and define one or more ideal processes (i.e., \"to be\" goal) to strive for. Software process modeling is the technique used to define and analyze the significant aspects of these processes. It is done in order to facilitate human understanding of the process, support process management and continuous process improvement and facilitate automated guidance and enaction of resulting process definitions. From observations gathered during rigorous studies of actual software development situations at the Microelectronics and Computer Technology Consortium (MCC), Curtis and Krasner et al. concluded that processes such as opportunistic design, learning, technical communication , negotiation, and customer interaction are among those which are most crucial to project success but are poorly provided for in most existing process models [7]. As a result of the detailed field study of large software projects, Curtis, Krasner, and Iscoe concluded that having an agreed-upon and commonly shared software development process model is a major factor in a project's software development effectiveness [6]. Unfortunately , a recent analysis of the data collected by the Carnegie Mel-lon University Software Engineering Institute (SEI) indicates that the vast majority of software development organizations in the U.S. do not possess and/or use a defined, shared development model [11]. Software process management in the context of improving organizational maturity is simply defined as establishing a process infrastructure to uniformly support and guide a project's work [10]. This involves process definition , process execution, data gathering and analysis and process control. It is related to an overall organizational contextual situation (e.g., business goals and software policies), existing project management discipline and technology support for software and process engineering. The emerging discipline of software process management and its terminological framework is defined in the context of continuous software quality and process improvement by [ 14] and in the SEI's Capability Maturity Model (CMU/SEI-91-TR-24 and TR-25). Many of the research issues emerging from the formulation of this new discipline have been identified …

Herb Krasner

Papers

A field study of the software design process for large systems

Breakdowns and processes during the early activities of software design by professionals

Communication breakdowns and boundary spanning activities on large programming projects

Lessons learned from a software process modeling system

A methodology for studying software design teams: an investigation of conflict behaviors in the requirements definition phase