Inside a software design team

Abstract

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...

Collaborative Practice Research

“…The researchers observe and interpret the actions and beliefs of practitioners and the practitioners do not take active part in the research process. Most of the empirical literature on systems development is based on practice studies (e.g., Aaen et al 991;Bansler and B0dker 1993;Benbasat, Dexter, and Mantha 1980;Boehm and Papaccio 1988;Boland and Day 1982;Ciborra and Lanzara 1994;Curtis, Krasner, and Iscoe 1988;Elam et al 1987;Gould and Lewis 1985;Kozar 1993;Krasner, Curtis, and Iscoe 1987;Madabusyhi, Jones and Price 1993;Markus 1983;McKeen 1983;Necco, Gordon, and Tsai 1987;Stolterman 1992;Tan 1994;Waltz, Elam, and Curtis 1993;White 1984;White and Leifer 1986).…”

On the Process of Software Design: Sources of Complexity and Reasons for Muddling through

“…Instead, designers carry most project information in their heads [34,38]. This increases the reliance on oral communication and the centrality of the few people on a project who are able to reason and argue about how local changes affect the overall design.…”

A Critical Review of Challenges in Hypermedia Systems Development

“…46 Secondly, the phenomenon of vague requirements is by no means new. 47 Walz et al observe that users often "don't know what they want" and fuzzy requirements are common, 48 and of course there is the classic problem of "I'll know it when I see it" requirements that are not pre-specifiable. 49 Another aspect of a virtual user population, which is different from traditional IS development, is that end users often cannot be personally trained how to use the system.…”

“…32,34,59 Of course, skills diversity is not unique to hypermedia systems development, -many conventional projects, particularly large ones, necessitate the integration of various knowledge domains. 48 However, in conventional systems development, designers tend to be primarily "computer professionals", which is typically not the case with hypermedia systems development. This is especially true of Web-based hypermedia systems, where many developers do not have a background in traditional software design or programming.…”