Weitere Artikel dieser Ausgabe durch Wischen aufrufen
In software development, there is an interplay between Software Process models and Software Process enactments. The former tends to be abstract descriptions or plans. The latter tends to be specific instantiations of some ideal procedure. In this paper, we examine the role of work artifacts and conversations in negotiating between prescriptions from a model and the contingencies that arise in an enactment. A qualitative field study at two Agile software development companies was conducted to investigate the role of artifacts in the software development work and the relationship between these artifacts and the Software Process. Documentation of software requirements is a major concern among software developers and software researchers. Agile software development denotes a different relationship to documentation, one that warrants investigation. Empirical findings are presented which suggest a new understanding of the relationship between artifacts and Software Process. The paper argues that Software Process is a generative system, which participants called “The Conversation,” that emerges out of the interplay between Software Process models and Software Process enactments.
Bitte loggen Sie sich ein, um Zugang zu diesem Inhalt zu erhalten
Sie möchten Zugang zu diesem Inhalt erhalten? Dann informieren Sie sich jetzt über unsere Produkte:
Bansler, J. P., & Bødker, K. (1993). A reappraisal of structured analysis: design in an organizational context. ACM Transactions on Information Systems, 11(2), 165–193. CrossRef
Beck, K. (2000). Extreme programming explained: Embrace change. Boston: Addison-Wesley Professional.
Bertelsen, O. W., & Bødker, S. (2002). Interaction through clusters of artefacts. 11th European Conference on Cognitive Ergonomics.
Boehm, B. (1981). Software engineering economics. Englewood Cliffs: Prentice-Hall. MATH
Bourdieu, P. (1977). Outline of a theory of practice. Cambridge: Cambridge University Press.
Button, G., & Sharrock, W. (1992). The mundane work of writing and reading computer programs. Cambridge: Rank Xerox, EuroPARC.
Button, G., & Sharrock, W. (1994). Occasioned practices in the work of software engineers. In M. Jirotka & J. Goguen (Eds.), Requirements engineering: Social and technical issues. London: Academic Press Professional.
Cohn, M. (2004). User stories applied: For agile software development. Boston: Addison-Wesley Professional.
Dittrich, Y. (2002). Doing empirical research on software development: Finding a path between understanding, intervention, and method development. In Y. Dittrich, C. Floyd, & R. Klischewski (Eds.), Social thinking-software practice. Cambridge: MIT.
Feiler, P. H., & Humphrey, W. S. (1993). Software process development and enactment: Concepts and definitions. In Second International Conference on Continuous Software Process Improvement (pp. 28–40).
Fuggetta, A. (2000). Software process: A roadmap. In Proceedings of the conference on The Future of Software Engineering (pp. 25–34).
Giddens, A. (1979). Chapter 2: Agency, structure. In Central problems in social theory: action, structure, and contradiction in social analysis. University of California Press.
Larman, C., & Basili, V. R. (2003). Iterative and incremental software development. IEEE Software, 36(6), 47–56.
Latour, B. (1986). The powers of association. In Power, action and belief: A new sociology of knowledge (vol. 32, pp. 264–280).
Lee, C. P. (2007). Boundary negotiating artifacts: unbinding the Routine of boundary objects and embracing chaos in collaborative work. Journal of Computer Supported Cooperative Work, 18(3), 307–339. CrossRef
Lofland, J., Snow, D. A., Anderson, L., & Lofland, L. H. (2005). Analyzing social settings: A guide to qualitative observation and analysis (4th ed.). Belmont: Wadsworth.
Naur, P. (1992). Computing: A human activity. New York: ACM. MATH
Nørbjerg, J., & Kraft, P. (2002). Software practice is social practice. In Y. Dittrich, C. Floyd & R. Klischewski (Eds.), Social thinking—software practice. Cambridge: MIT.
Osterweil, L. (1987). Software processes are software too. In Proceedings of the 9th International Conference on Software Engineering (pp. 2–13).
Parnas, D. L., & Clements, P. C. (1986). A rational design process: how and why to fake it. IEEE Transactions on Software Engineering, 12(2), 251–257.
Pentland, B. T., & Feldman, M. S. (2005). Organizational routines as a unit of analysis. Industrial and Corporate Change, 14, 793–815. CrossRef
Robinson, H., & Sharp, H. (2003). XP culture: Why the twelve practices both are and are not the most significant thing. Salt Lake City: Agile Development Conference.
Scacchi, W. (2001). Process models in software engineering. In J. Marciniak (Ed.), Encyclopedia of software engineering (2nd ed.). New York: Wiley.
Schwaber, K., & Beedle, M. (2001). Agile software development with SCRUM. Englewood Cliffs: Prentice Hall.
Sim, S. E., Alspaugh, T. A., & Al-Ani, B. (2008). Marginal notes on amethodical requirements engineering: What experts learned from experience. In Proceedings of the 2008 16th IEEE International Requirements Engineering Conference (pp. 105–114).
Star, S. L., & Griesemer, J. R. (1989). Institutional ecology, ‘translations’ and boundary objects: amateurs and professionals in Berkeley’s Museum of Vertebrate Zoology 1907–39. Social Studies of Science, 19, 387–420. CrossRef
Truex, D., Baskerville, R., & Travis, J. (2000). Amethodical systems development: the deferred meaning of systems development methods. Accounting, Management and Information Technologies, 10(1), 53–79. CrossRef
van Vliet, H. (2008). Software engineering: Principles and practice (3rd ed.). New York: Wiley.
- What Counts as Software Process? Negotiating the Boundary of Software Work Through Artifacts and Conversation
Marisa Leavitt Cohn
Susan Elliott Sim
Charlotte P. Lee
- Springer Netherlands
Neuer Inhalt/© ITandMEDIA, Product Lifecycle Management/© Eisenhans | vege | Fotolia