Groupware research and technology issues with application to software process management

Krasner, Herb; McInroy, John W.; Walz, Diane B.

doi:10.1109/21.108288

Cited by 32 publications

(11 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Such tools would provide methods for capturing design rationale [3,5,19] including scenarios of use as supplied by customers or suggested by designers. Croupware tools that allow the capture, storage, and retrieval of the design process information have been suggested for software process management [11,15,16]. Such tools may use the design process as input.…”

Section: Implications For Managementmentioning

confidence: 99%

Inside a software design team

1993

View full text Add to dashboard Cite

ore than half the cost of the development of complex computer-based information systems (IS) is attributable to decisions made in the upstream portion of the software development process; namely, requirements specification and design [20]. There is growing recognition that research on how teams actucilly go about making requirement determinations and design decisions can provide valuable insights lor improving the quality and productivity of large-scale computer-based IS development efforts [9,12,23]. Traditional models of group dynamics, group decision making, and group development are not rich enough to thoroughly explain the real-world complexities faced by software design teams. Most of this research was performed on tasks that were shorter, less complex and did not require the extensive integration of knowledge domains that characterizes soltware systems design [9,12].Knowledge is the raw material of software design teams. For complex projects, knowledge from multiple technical and functional domains is a necessity [12]. Ideally, a software design team is staffed so that both the levels and the distribution of knowledge within the team match those required for the successful completion of the project. Because of knowledge shortfalls such as the thin spread of application domain knowledge in most organizations, however, this is seldom the case [12]. In general, individual team members do not have all of the knowledge required for the project and must acquire additional information before accomplishing productive work. The sources of this information can be relevant documentation, formal training sessions, the results of trial-and-error behavior, and other team members. Group meetings are an important environment for learning, since they allow team members to share information and learn about other domains relevant to their work.Productive design activities need to revolve around the integration of the various knowledge domains. This integration leads to shared models of the problem under consideration and potential solutions. A software design team seldom starts its life with shared models of the system to be built. Instead, these models develop over time as team members learn from one another about the expected behavior of the application and the computational stiuctures required to produce this behavior. This means that team members need to be speaking the same language (or, at least, dialects whose semantics are similar enough to facilitate communication and understanding) in order to share knowledge about the system.Knowledge acquisition, knowledge sharing, and knowledge integration are significant, time-consuming activities that precede the development of a design document. The purpose of this article is to examine how these activities unfolded over time inside an actual software design team. Two related questions with respect to this team will be resolved: 1) How do the group members acquire, share, and integrate project-relevant knowledge? 2) Do the levels of participation in these activities differ ac...

show abstract

Section: Implications For Managementmentioning

confidence: 99%

Inside a software design team

1993

View full text Add to dashboard Cite

show abstract

“…132,133 Groupware encompasses computer technologies that actively facilitate groups of collaborating users. 134 Examples of groupware include electronic mail, bulletin boards, collaborative authoring tools, screen-sharing software, teleconferencing and video-conferencing systems, and various group decision support systems.…”

Section: Groups and Teams At Workmentioning

confidence: 99%

Computer Technology Applications in Industrial and Organizational Psychology

Crespin

Austin²

2002

CyberPsychology & Behavior

View full text Add to dashboard Cite

This article reviews computer applications developed and utilized by industrial-organizational (I-O) psychologists, both in practice and in research. A primary emphasis is on applications developed for Internet usage, because this "network of networks" changes the way I-O psychologists work. The review focuses on traditional and emerging topics in I-O psychology. The first topic involves information technology applications in measurement, defined broadly across levels of analysis (persons, groups, organizations) and domains (abilities, personality, attitudes). Discussion then focuses on individual learning at work, both in formal training and in coping with continual automation of work. A section on job analysis follows, illustrating the role of computers and the Internet in studying jobs. Shifting focus to the group level of analysis, we briefly review how information technology is being used to understand and support cooperative work. Finally, special emphasis is given to the emerging "third discipline" in I-O psychology research-computational modeling of behavioral events in organizations. Throughout this review, themes of innovation and dissemination underlie a continuum between research and practice. The review concludes by setting a framework for I-O psychology in a computerized and networked world.

show abstract

“…Effective surrogate agents can greatly facilitate group problem solving by providing new opportunities or enhancing current capabilities of sharing, organizing and presenting information of mutual interest. Such a class of computational tools, called group support systems or groupware, have been recognized as a key component to enhancing the productivity of cooperative groups in organizations (Greenberg, 1991;Johansen, 1991;Krasner, McInroy & Walz, 1991;Grudin, 1994;Rasmus, 1995).…”

Section: Introductionmentioning

confidence: 99%

“…The major difference between this implementation and other work on meeting scheduling (Dent, Boticario, McDermott, Mitchell & Zabowski, 1992;Kautz, Selman, Coen, Ketchpel & Ramming, 1994;Maes, 1994) is that we are more interested in efficiently automating the scheduling process rather than learning about user preferences. Krasner et al (1991) have identified several dimensions along which groupware systems can be evaluated. In the following, we rate our automated scheduling system along each of those dimensions.…”

Section: Introductionmentioning

confidence: 99%