A model of design decision making based on empirical results of interviews with software designers
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 . There is growing recognition that research on how teams actually go about making requirement deter-minations and design decisions can provide valuable insights for 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 software 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 . 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 . 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 structures 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 …
Unfortunately, ACM prohibits us from displaying non-influential references for this paper.
To see the full reference list, please visit http://dl.acm.org/citation.cfm?id=163447.