MANAGING IT: DOES AGILE SOFTWARE DEVELOPMENT SOLVE BUYER NEEDS?
Abstract
A variety of innovations in software development practices, referred to by the collective term agile, have arisen in recent years partly as an attempt to deal with the considerable amount of complexity inherent in many software development projects. These agile approaches to software development are increasingly gaining acceptance with suppliers of software development services. Agile, in its various forms, appears to be a range of supplier responses to a set of problems traditionally incurred in contracted software development projects. Yet the extent to which the needs of the public sector (as one category of procurer) are faced is more questionable. Are the needs of a public sector procurer really satisfied with agile methods and practices as the framework for software development? Is agile really the solution to the original problem set?
Downloads
References
Bellamy, C. and Taylor, J.A. (1998) Governing in the Information Age. Open University Press,Buckingham.
Callender, G., Twomey, A., Chong, S. and Huang, X-Z. (2008) Influencing government contracts: What the media said about success. Proceedings of 17thIPSERA Conference, Perth,March, pp 343-8.
Commonwealth of Australia (CoA) (2009) Commonwealth procurement guidelines.Department of Finance & Deregulation, Canberra.Retrieved: 20 March 2009 fromhttp://www.finance.gov.au/publications/fmg-series/procurement-guidelines/index.html
Glass, R.L. (2005) IT Failure Rates –70% or 10-15%?IEEE Software, 22 (3)pp 110-12.
Glass, R.L. (2006) The Standish Report: Does it really describe a software crisis?Communications of the ACM, 49 (8)pp 15-16.
Highsmith, J. (2002) Agile Software Development Eco-Systems.Addison-Wesley, Boston, MA.
Jamieson, D., Vinsen, K. and Callender, G. (2006) Agile procurement and dynamic value for money to facilitate agile software projects. Proceedings of 32ndEUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO‘06), Cavtat/Dubrovnik, August/September, pp 248-55.
Jørgensen, M. and Moløkken-Østvold, K. (2006) How large are software cost overruns? Areview of the 1994 CHAOS report, information and software technology.Amsterdam, 48 (4)pp 297-301.
The Manifesto for Agile Software Development (2001)Retrieved: 22 March 2009 from http://www.agilemanifesto.org
Naur, P. and Randell, B. (1969) Software engineering.Report of a conference sponsoredby the NATO Science Committee, Garmisch, October.
Principles behind the Agile Manifesto (2001).Retrieved: 22 March 2009 fromhttp://www.agilemanifesto.org/principles.html
Royce, W.W. (1987) Managing the development of large software systems. Proceedings of 9thInternational Conference on Software Engineering,Monterey, CA, March/April, pp 328-38.
Schach, S.R. (2007) Object-Oriented andClassical Software Engineering (7thEdition). McGraw Hill Higher Education, Boston, MA.
Sliger, M. and Broderick, S. (2008) The Software Project Manager’s Bridge to Agility. Addison-Wesley Professional, Reading,MA.
The Standish Group International (1994) The Chaos Report, 1994. TheStandish Group International.
Sykes, M. and Callender, G. (2009) Deconstructing the public-private mix in procurement: Apreliminary study. Presentation to 18thIPSERA Conference, Oestrich-Winkel, April.
Thorp, J. (2008) IT project cancellations: Pay now or pay later. Information Systems Control Journal,1 (Jan)pp18-19.
Downloads
Published
How to Cite
Issue
Section
License
Copyright (c) 2009 The journal of contemporary issues in business and government
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
You are free to:
- Share — copy and redistribute the material in any medium or format for any purpose, even commercially.
- Adapt — remix, transform, and build upon the material for any purpose, even commercially.
- The licensor cannot revoke these freedoms as long as you follow the license terms.
Under the following terms:
- Attribution — You must give appropriate credit , provide a link to the license, and indicate if changes were made . You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
- No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
Notices:
You do not have to comply with the license for elements of the material in the public domain or where your use is permitted by an applicable exception or limitation .
No warranties are given. The license may not give you all of the permissions necessary for your intended use. For example, other rights such as publicity, privacy, or moral rights may limit how you use the material.