Manage. Sci. 50(3) 352-364. Curtis, B., H. Krasner. N. Iscoe. 1988. A field study of the software design process for large systems.  Home/Search   Document Not in Database   Summary   ACM   TOC   Related Articles   Check

....no one architect has all the knowledge needed to design a complex system. Instead, most complex systems are designed by teams of stakeholders providing some of the necessary knowledge and their own goals and priorities. This thin spread of application domain knowledge has been identified by [19] as a general problem in software development. In complex domains even experienced architects need knowledge support. For instance, they need to be reminded which of the requirements apply to which part of the system. Even the person who specifies a requirement via CoCons does not have to have the ....

Bill Curtis, Herb Krasner, and Neil Iscoe. A field study of the software design process for large systems. Communications of the ACM, 31(11):1268--1287, 1988.

....There is also a major pressure on time to market for these software products. Other characteristics of market driven RE are release planning and prioritization, and managing the constant flow of new requirements [4, 10, 15] There are several surveys that concern or include RE issues [5, 6, 7, 8, 9, 13, 14]. However, none of these have a primary focus on market driven development. Furthermore, in most of these surveys the participating projects and organizations are fairly large, in terms of number of persons and requirements involved, as well as in terms of the duration of the projects. This survey ....

....These are divided into three sections: Characterization, Process issues and Artefact issues complying with the interview structure. The issues discussed in this paper are preliminary results of a continuing study, and will be used to find hypotheses for our future research. Although Curtis et al. [6] performed their survey on large systems development and that it was performed 14 years ago, the presented study indicates that some problems remain. Communication is still a corner stone in software development and the project s success depends on the staff. Another recent survey [8] also ....

Curtis, B., Krasner, H., Iscoe, N., "A Field Study of the Software Design Process for Large Systems", Communications of the ACM, 31(11) :1268-1287, Nov. 1988.

....knowledge of the new technology, end up frequently changing the specification of their requirements. However, it is widely recognised that changing system requirements is one of the most frequent causes of projects being late, over budget, or otherwise a technical failure or maintenance nightmare[ 14 ] This brings us to another class of project participants, software system maintenance staff. For a large system, maintenance activites go on for years. Maintenance tasks (adding functional enhancements, resolving anomalies, tuning system performance, migrating the system to other environments) ....

.... environment, as others have done [20, 49] to specify, query, simulate and analyse software processes of interest [ 18] Our approach employs a software process meta model, derived from empirical studies of computing and software development work in different organisational settings [4, 6, 8, 14, 21, 40, 42] It directly incorporates the kinds of information structures, presented earlier, to model software engineering processes and settings. This encourages us to model large team based development efforts as multi agent software processes in an open systems manner [41, 50] This ability ....

CURTIS, B., KRASNER, H., and ISCOE, N.: 'A field study of the software design process for large systems', Commun. ACM, 1988, 81, (11), pp. 1268-1287

....While formal communication is useful for coordinating routine work, informal communication is needed in the face of uncertainty and unexpected problems. Note that all three problems noted above were caused, at least in part, by lack of informal communication, typical of distributed projects [6, 8, 1]. In this paper, we describe the technical architecture for iBistro [2] iBistto is an experimentation environment that allows distributed teams to capture, structure, and retrieve information and knowledge produced in global distributed software development projects. iBistro focuses on the ....

B. Curtis, H. Krasner, and N. Iscoe. A field study of the software design process for large systems. In Communications of the ACM, volume 31(11), Nov. 1988.

....organize and communicate conceptual information. We extended this model to account for the breakdown that occurs in communication of information across boundaries of domain expertise, breakdown that is implicated as a major limiting factor of the quality of large and complex soft ware systems [1]. We are concerned with maximizing the integrity of the communication between experts in a given domain and developers working on a unit of software that will function within that domain. The root objective of any attempt at communication is to recreate the particular real world semantics ....

B. Curtis, H. Krasner, and N. Iscoe. A field study of the software design process for large systems. Communications of the ACM, 31(11):1268-1287, 1988.

....organize and communicate conceptual information. We extended this model to account for the breakdown that occurs in communication of information across boundaries of domain expertise, breakdown that is implicated as a major limiting factor of the quality of large and complex software systems [1]. Miscommunicated requirements, as noted above, are themselves a detriment to forensic software engineering [6] The model by which we analyze and characterize communicative breakdown in requirements can also be applied to investigation and reporting guidelines, as well as to the reports and ....

B. Curtis, H. Krasner, and N. Iscoe. A field study of the software design process for large systems. Communications of the ACM, 31(11):1268-1287, 1988.

....communicate team and project status, resulting in many crises detected late. Lack of status information and informal contacts between sites made it di#cult to manage crises once they were identified. Researchers have already noted the importance of communication in software development [4, 12, 15]. In a field study, Curtis et al. 4] observed that documentation does not reduce the need for communication, in particular, during the early phases of the project, when stakeholders coordinate their conventions and create informal communication networks. They also observed that obstacles in ....

....in many crises detected late. Lack of status information and informal contacts between sites made it di#cult to manage crises once they were identified. Researchers have already noted the importance of communication in software development [4, 12, 15] In a field study, Curtis et al. [4] observed that documentation does not reduce the need for communication, in particular, during the early phases of the project, when stakeholders coordinate their conventions and create informal communication networks. They also observed that obstacles in informal communication (e.g. ....

B. Curtis, H. Krasner, and N. Iscoe. A field study of the software design process for large systems. Communications of the ACM, 31(11), Nov. 1988.

....affected the objectivity of the results. Our study differs from more traditional field studies of work settings in that our data is purely based on electronic communication and archive material. We do not provide any detailed description of workplace activities and work context as for instance in [7 9]. On the other hand, we believe our study provides an insight into the overall distribution problem found in most of the development projects now a day. The only data accessible to the researcher in these settings is normally the electronic communication and archival material. Our study is guided ....

....most of the collaboration in such projects is informal [10] However, we have tried to look at the transition from the informal collaboration to the formal design, where we believe the main challenges exist for support tools. This transition is acknowledged by many previous studies of engineers [4, 6, 7, 11 13]. 4. OBSERVATIONS This section presents our observations done after the project was finished in January 1998. We have focused on observations that we believe are important for the type of collaboration support that can be provided for similar future situations. Informal collaboration Mailing ....

[Article contains additional citation context not shown here]

Curtis, B., H. Krasner, and N. Iscoe, A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 1988. 31(11): p. 1268-1287.

....important thing is that feedback was not only provided by the end user, but also by the technical staff, especially on the future functionality of the system. Access to experts The availability of experts, with domain or technical knowledge, is crucial for the progress of a development project [3]. One major advantage of using email in Alpha was the easy access to different kinds of tacit knowledge. This would have been extremely difficult without mailing lists due to the geographical distribution of the participants. The proper experts were there when a question was asked, and would ....

Curtis, B., H. Krasner, and N. Iscoe, A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 1988. 31(11): p. 1268-1287.

....e#ort for any organization, the frequent solution is therefore to simply not store this information explicitly in the first place. In general, distributed organizations su#er from reduced informal communication, which in turn results in the need to make implicit organizational knowledge explicit [2, 5]. Ideally, the information about the organization (e.g. Who is programmer, tester, or maintainer for what ) is made explicit for every artifact in every tool, especially in a globally distributed project. The key issue that we address in this paper is how to minimize redundancy in the ....

B. Curtis, H. Krasner, and N. Iscoe. A field study of the software design process for large systems. Communications of the ACM, 31(11), Nov. 1988.

....While formal communication is useful for coordinating routine work, informal communication is needed in the face of uncertainty and unexpected problems. Note that all three problems noted above were caused, at least in part, by lack of informal communication, typical of distributed projects [1, 5, 8, 12]. To address these problems in the classroom, we propose to further apply our approach of learning by doing . In this paper, we describe iBistro, an experimentation environment that allows instructors and students to capture, structure, and retrieve knowledge produced during informal ....

B. Curtis, H. Krasner, and N. Iscoe. A field study of the software design process for large systems. In Communications of the ACM, volume 31(11), Nov. 1988.

....practices could lengthen the useful life of a software system, thus providing a greater return on investment with respect to the system s original development costs. In examining software maintenance processes for improvement opportunities, an obvious choice is information flow. Curtis et al. [3] have shown that information flow is a key factor in the success of software development and maintenance efforts. In maintenance in particular, obtaining accurate, up to date, and useful information about the system being maintained is a major task. It is also a difficult task because these ....

Curtis, Bill, Herb Krasner, and Neil Iscoe. "A field study of the software design process for large systems." Communications of the ACM, 31(11):12681287, November 1988.

....the software. In general, open source developers are experienced users of the software they write. They are intimately familiar with the features they need, and what the correct and desirable behavior is. Since the lack of domain knowledge is one of the chief problems in large software projects [7], one of the main sources of error is eliminated when domain experts write the software. It remains to be seen if this advantage can completely compensate for the absence of system testing. In any event, where the developers are not also experienced users of the software, they are highly unlikely ....

CURTIS, B., KRASNER, H., AND ISCOE, N. 1988. A Field Study of the Software Design Process for Large Systems. Communications of the ACM, vol. 31, 1268-1287.

....concerning cognitive support, and little emphasis was placed on more formal, rigorous testing of the basic support ideas. In addition, there was substantial cultural bias against social sciences related issues in academic computing regarding tool design (e.g. see Curtis [158] Curtis et al. [159], or Green [263] Consider two simple but illustrative historical examples of the above principle. Early programming environments were batch oriented rather than interactive , so that programmers normally wrote programs on paper, submitted them to a keypunch operator, and then (much later) ....

Curtis, B., Krasner, H., and Iscoe, N. A field study of the software design process for large systems. Communications of the ACM, 31(11), Nov. 1988, pp. 1268--1287.

....Ad Hoc Communication There is good reason, however, to be skeptical about claims that distance makes no difference to R D work. One reason is provided by the findings from studies of work that show that informal, unplanned, ad hoc communication is extremely important in supporting collaboration [7, 12, 14, 19]. For example, in their study of telecommunications engineering, Perry, Staudenmayer and Votta [19] found that developers spent over 15 of their time communicating with their colleagues informally. A study of several projects by Curtis, Krasner and Iscoe [7] found that breakdowns in informal ....

....supporting collaboration [7, 12, 14, 19] For example, in their study of telecommunications engineering, Perry, Staudenmayer and Votta [19] found that developers spent over 15 of their time communicating with their colleagues informally. A study of several projects by Curtis, Krasner and Iscoe [7] found that breakdowns in informal communications could lead to misunderstandings in design conventions and rationale. Further, they suggest that separation in time and organizational distance can lead to these kinds of breakdowns. As Kraut and Streeter [14] observed, in their survey of 65 ....

Curtis, B., H. Krasner, and N. Iscoe. A Field Study of the Software Design Process for Large Systems. Communications of the ACM 31, 11, 1988, 126g- 1287.

....of a program. The idea is to raise program editing to a higher level, not to build a design language. Refactorings do not force upon a designer a rigid, top down design style. Experience has shown that the development of a large software program does not proceed in a purely top down manner [38, 89]. Software design is in many ways an informal process [63] Refactorings support iterative conceptual shifts. For example, the refactoring that defines an abstract superclass generates a common design abstraction from low level implementation; this design abstraction can then be used for further ....

Curtis, Krasner, and Iscoe. A field study of the software design process for large systems. Communications of the ACM 31:11, pages 1268 1287, 1988.

....communication [14] i.e. since the teams are not physically together, they can not meet around the water cooler, in the hallway or in other public areas. Empirical studies suggest that informal communication is very important to coordinate teams in uncertain tasks such as software development [8][20] In other words, software developers rely also on informal, ad hoc communication to fill in details, handle exceptions, correct mistakes and bad predictions, and manage the effects of all these changes [14] As this type of communication is absent in global software development the ....

Curtis, B., Krasner, H. and Iscoe, N. A Field Study of the Software Design Process for Large Systems. Communications of the ACM 31(11):1268-1287, November 1988.

....changes may be more important than maintaining awareness about the team s internal processes; changes in the expectations of a team s customers , those who make use of the team s product, seem to be especially important. Failure in managerial decision making teams [7] software engineering teams [6], and new product development teams [3] seems to result when teams ignore changes in their environment. How should passive awareness information be presented The goal of an awareness tool is to help teams monitor changes to important resources while imposing minimally on their attention. ....

Curtis, B., Krasner, H., & Iscoe, N. A field study of the software design process for large systems. Communications of the ACM 31(11), 1988, 12681287.

....more importance is given to the first stages of development by adding new activities to these stages. These models have centered their representations in three characteristics of the process: the activity, the product and the agent (human and computarized) 23] although it is empirically shown [8, 26, 17, 30, 16, 9, 28, 4] the great influence of other characteristics in the production process such as human roles and organization. In general, the first is partly included in the existing software process models [14] The second is considered an independent characteristic of those applied for the software process ....

B. Curtis, H. Krasner and N. Iscoe, "A field study of the software design process for large systems". Communications of the ACM 31, 11 (November 1988) 1268-1287.

....a knowledge intensive activity involving the integration of diverse knowledge sources that undergo constant change. The knowledge required to successfully develop software systems ranges from programming methods to the tool mastery burden [7] to the critical role of application domain knowledge [11] and the diverse nature of software development processes and techniques [24] In addition, the knowledge is under constant pressure from fluctuating requirements and technology advances, causing knowledge volatility and further pressures on the knowledge mastery burden. The management of this ....

Curtis, B., Krasner, H., and Iscoe, N., "A Field Study of the Software Design Process for Large Systems," Communications of the ACM, vol. 31, pp. 1268-1287, 1988.

.... software process models have focused on three elementary process features: the activity, the artefact and the agent (human and computerised) 47] However, other characteristics, like human and organisational roles, have been empirically proven to have a big impact on the production process [32][17][14] 56] 23] 53] 40] Most of the existing software process models deal with roles partially [43] 26] while the organisation is considered as separate from the characteristics applied for modelling the software process or it is ignored [24] This is because the organisation is the software ....

B. Curtis, H. Krasner, N. Iscoe, "A field study of the software design process for large systems". Communications of the ACM 31, 11 (November 1988) 1268-1287.

....domains, no one architect has all the knowledge needed to make a complex design. Instead, most complex systems are designed by teams of stakeholders providing some of the needed knowledge and their own goals and priorities. The thin spread of application domain knowledge has been identified by [9] as a general problem in software development. In complex domains even experienced architects need knowledge support. For instance, they need to be reminded, which of the requirements apply to which part of the system. Context based constraints enforce a system s compliance with requirements. Even ....

Bill Curtis, Herb Krasner, and Neil Iscoe. A field study of the software design process for large systems. Comm. ACM, 31(11):1268-- 1287, 1988.

.... as an important factor in how developers spend their time [12] and some organizational characteristics which affect its efficiency have been suggested [3, 8] Some, but surprisingly little, of the process work in software engineering has dealt with information flow or organizational structure [1, 2, 13]. It has been postulated that informal communication is usually more 1 Flow Information Development Process information processing requirements Productivity developers spend time communicating Organizational Structure information processing channels and barriers Quality ....

B. Curtis, H. Krasner, and N. Iscoe. "A Field Study of the Software Design Process for Large Systems". Communications of the ACM, 31(11), Nov. 1988.

....developers. This paper describes a set of requirements for awareness tools to support software designers. Designers were chosen since the literature suggests that requirements and design decisions exert tremendous impact on software productivity, quality and costs throughout the life cycle[2]. The requirements were based on: # Characteristics of the activity of software development; and # Cognitive theories about designers, including theories of decision making(opportunistic design and reflection in action) and theories of human memory (limited short term memory, limited knowledge ....

....with software development of large applications. 3.1. Scale A fundamental characteristic in many software systems is that they are very large and far beyond the ability of any individual or small group to create or even to understand in detail[18] In fact, as presented by Guindon[12] and Curtis[2], the lack of domain or technical knowledge is one of the main salient problems in software development. Therefore, software development is a cooperative activity which group size can vary from five developers to more than one thousand. Furthermore, the work of these several software developers ....

[Article contains additional citation context not shown here]

B. Curtis, H. Krasner, and N. Iscoe. A field study of the software design process for large systems. Communications of the ACM, 33(11):1268--1287, Nov. 1988.

....prevent a division by zero error to occur, etc. The plans are divided in the theory into two main types: control flow plans representing, e.g. looping structures, and variable plans representing variable usage (Ehrlich and Soloway, 1984) Figure 1: Soloway s basic programming plans (adapted from Curtis, 1988). Counter variable plan PROGRAM alpha(Input, Output) VAR Count, Sum, Number: INTEGER; Average : REAL; BEGIN Count : 0; Sum : 0; READLN (Number) WHILE Number 99999 DO BEGIN Sum : Sum Number; Count : Count 1; READLN (Number) END; IF Count 0 THEN BEGIN Average : ....

....situation that future users of a system will be application domain experts while the design and implementation will be done by programming domain experts. The success of a computer system is many times deemed by how well the designers and programmers have understood the application requirements (Curtis et al. 1988). Several program comprehension models have also noted the importance of understanding application domain functions, data, and data dependencies (see, e.g. Brooks (Brooks, 1983) There is also evidence of using both representations at the same time. For example, Cobol and FORTRAN programmers ....

Curtis, B., Krasner, H. & Iscoe, N. (1988). A Field Study of the Software Design Process for Large Systems. Communications of the ACM 31(11): 1268-1287.

No context found.

Manage. Sci. 50(3) 352-364. Curtis, B., H. Krasner. N. Iscoe. 1988. A field study of the software design process for large systems.

No context found.

Curtis, B., Krasner, H. & Iscoe, N. (1988). A field study of the software design process for large systems. Communications of the ACM, 31, 1268-1287.

No context found.

B. Curtis, H. Krasner, and N. Iscoe, "A field study of the software design process for large systems," CACM, vol. 31, pp. 1268--1287, 1988.

No context found.

Curtis, B., H. Krasner, and N. Iscoe. 1988. A field study of the software design process for large systems. Communications of the ACM, no. Nov 88: 1268-1287.

No context found.

B. Curtis, H. Krasner, and N. Iscoe, "A Field Study of the Software Design Process for Large Systems," Communications of the ACM, vol. 31, pp. 1268-1287, 1988.

No context found.

Curtis, B., Krasner, H., Iscoe, N., "A Field Study of the Software Design Process for Large Systems," Communications of the ACM, 31(11), pp. 1268-1287, 1988.

No context found.

Curtis, B., Krasner, H., & Iscoe, N. (1988). "A Field Study of the Software Design Process for Large Systems". Communications of the ACM, 31(11): 1268-1286.

No context found.

Seattle, WA. Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large systems. CACM, 31(11), 1268--1287.

No context found.

Curtis, B., Krasner, H. and Iscoe, N. A field study of the software design process for large systems. CACM, 31 (11). 1268--1287.

No context found.

Curtis, B., Krasner, H., & Iscoe, N. (1988). "A Field Study of the Software Design Process for Large Systems". Communications of the ACM, 31(11): 1268-1286.

No context found.

Curtis, B. Krasner, H. Iscoe, N. (1988): A field study of the software design process for large systems, Comm. ACM , 31(11):1268-1287.

No context found.

B. Curtis, H. Krasner, and N. Iscoe, "A Field Study of the Software Design Process for Large Systems," Comm. ACM, vol. 31, no. 11, Nov. 1988, pp. 1268--1287.

No context found.

Curtis, B., Krasner, H. and Iscoe, N. A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 31 (11). 1268-1287.

No context found.

B. Curtis, H. Krasner, and N. Iscoe. A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 31(11):1268--1287, November 1988.

No context found.

Curtis, B., Krasner, H., Iscoe, N., "A Field Study of the Software Design Process for Large Systems," Communications of the ACM, 31(11), pp. 1268-1287, 1988.

No context found.

Curtis, B., Krasner, H. and Iscoe, N. A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 31 (11). 1268-1287.

No context found.

Curtis, B., Krasner, H. and Iscoe, N. (1988) `A field study of the software design process for large systems', Communications of the ACM, 31(11), 1268--87.

No context found.

Curtis, B., Krasner, H., Iscoe, N. "A Field Study of the Software Design Process for Large Systems," Communications of the ACM, 31(11), pp. 1268-1287.

No context found.

Curtis, Bill, Herb Krasner and Neil Iscoe (1988), A Field Study of the Software Design Process for Large Systems, Communications of the ACM , Vol. 31, No. 11, pp. 1268-1287.

No context found.

Curtis, B., Krasner, H. and Iscoe, N. (1988) A field study of the Software Design Process for Large systems, Communications of the ACM, 31(11), pp. 1268-1286.

No context found.

B. Curtis, H. Krasner, and N. Iscoe, "A Field Study of the Software Design Process for Large Systems," Communications of the ACM, vol. 31, pp. 1268-1287, 1988.

No context found.

W Curtis, H Krasner, N Iscoe, "A Field Study of the Software Design Process for Large Systems ", in Communications of the ACM v31 no 11 (Nov 88) pp 1268--1287

No context found.

B. Curtis, H. Krasner, and N. Iscoe., "A Field Study of the Software Design Process for Large Systems", Communications of the ACM, 31(11), pp. 1268-1287, 1988.

No context found.

B. Curtis, Herb Krasner, and Neil Iscoe. "A field Study of the Software Design Process for Large Systems". Communications of he ACM, 31(11), November 1988.

No context found.

W Curtis, H Krasner, N Iscoe, "A Field Study of the Software Design Process for Large Systems", in Communications of the ACM v31no11(Nov88)pp 1268--1287

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC