Advertisement

What Counts as Software Process? Negotiating the Boundary of Software Work Through Artifacts and Conversation

  • Marisa Leavitt CohnEmail author
  • Susan Elliott Sim
  • Charlotte P. Lee
Article

Abstract

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.

Key words

agile software development requirements documentation work artifacts software process models and enactments collaboration negotiation 

Notes

Acknowledgements

We are indebted to our field sites and the participants who consented to be observed and interviewed. Many, many thanks to Rosalva Gallardo-Valencia who was instrumental in the data collection and transcription. Thanks also to Anahita Fazl who helped with the transcription. Yvonne Dittrich provided, reviewed and guided our research direction. This research has been funded in part by the National Science Foundation (Award IIS-0712994) and the Agile Alliance Academic Research Program.

References

  1. 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.CrossRefGoogle Scholar
  2. Beck, K. (2000). Extreme programming explained: Embrace change. Boston: Addison-Wesley Professional.Google Scholar
  3. Bertelsen, O. W., & Bødker, S. (2002). Interaction through clusters of artefacts. 11th European Conference on Cognitive Ergonomics.Google Scholar
  4. Boehm, B. (1981). Software engineering economics. Englewood Cliffs: Prentice-Hall.zbMATHGoogle Scholar
  5. Bourdieu, P. (1977). Outline of a theory of practice. Cambridge: Cambridge University Press.Google Scholar
  6. Button, G., & Sharrock, W. (1992). The mundane work of writing and reading computer programs. Cambridge: Rank Xerox, EuroPARC.Google Scholar
  7. 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.Google Scholar
  8. Cohn, M. (2004). User stories applied: For agile software development. Boston: Addison-Wesley Professional.Google Scholar
  9. 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.Google Scholar
  10. 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).Google Scholar
  11. Fuggetta, A. (2000). Software process: A roadmap. In Proceedings of the conference on The Future of Software Engineering (pp. 25–34).Google Scholar
  12. Giddens, A. (1979). Chapter 2: Agency, structure. In Central problems in social theory: action, structure, and contradiction in social analysis. University of California Press.Google Scholar
  13. Larman, C., & Basili, V. R. (2003). Iterative and incremental software development. IEEE Software, 36(6), 47–56.Google Scholar
  14. Latour, B. (1986). The powers of association. In Power, action and belief: A new sociology of knowledge (vol. 32, pp. 264–280).Google Scholar
  15. 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.CrossRefGoogle Scholar
  16. 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.Google Scholar
  17. Naur, P. (1992). Computing: A human activity. New York: ACM.zbMATHGoogle Scholar
  18. 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.Google Scholar
  19. Osterweil, L. (1987). Software processes are software too. In Proceedings of the 9th International Conference on Software Engineering (pp. 2–13).Google Scholar
  20. 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.Google Scholar
  21. Pentland, B. T., & Feldman, M. S. (2005). Organizational routines as a unit of analysis. Industrial and Corporate Change, 14, 793–815.CrossRefGoogle Scholar
  22. 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.Google Scholar
  23. Scacchi, W. (2001). Process models in software engineering. In J. Marciniak (Ed.), Encyclopedia of software engineering (2nd ed.). New York: Wiley.Google Scholar
  24. Schwaber, K., & Beedle, M. (2001). Agile software development with SCRUM. Englewood Cliffs: Prentice Hall.Google Scholar
  25. 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).Google Scholar
  26. 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.CrossRefGoogle Scholar
  27. 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.CrossRefGoogle Scholar
  28. van Vliet, H. (2008). Software engineering: Principles and practice (3rd ed.). New York: Wiley.Google Scholar

Copyright information

© Springer Science+Business Media B.V. 2009

Authors and Affiliations

  • Marisa Leavitt Cohn
    • 1
    Email author
  • Susan Elliott Sim
    • 1
  • Charlotte P. Lee
    • 2
  1. 1.Department of InformaticsUniversity of CaliforniaIrvineUSA
  2. 2.Department of Human Centered Design & EngineeringUniversity of WashingtonSeattleUSA

Personalised recommendations