Monday, March 12, 2012

On the nature of Agile Development

The history of software development within the last twenty (20) years is littered with notable software development and implementation failures; The Denver International Airport’s Luggage Handling System; Ford’s attempts at implementing an ERP / CRM based purchasing system; Avis Europe ERP platform; Hudson Bay’s Inventory Management system and many others; (Ewushi-Mensah, 2003)[i] (Galin, 2004)[ii] Both Galin and Ewusi-Mensa outline that the underlying issues at the root of the cause of software development failures and how they fail are related to the following characteristics of development: in addition to this there is the ever present Chaos report that cites the many reasons for project failure. (Standish Group, 1995)[iii] (Matus, 2009)[iv]; basically the Standish report on metrics about software projects indicate that only 32% are successful, 44% are challenged and 24% of all projects surveyed fail; of the 24% the reasons for failure are cited as further to this the PMI agrees that around only 30% of software development project succeed; this is often due to the following reasons:

1. Stakeholder Involvement
2. Requirements Analysis and Gathering
3. Project Planning and Execution
4. Project Metrics and Analisys
5. Project Risk
6. Software Quality Assurance Planning and Testing

Within the Information technology project management module we reviewed and analysed as well as developed a formal project plan using “Earned Value Management” in conjunction with Microsoft’s Project Management software to develop and analyse Gantt charts according to estimates made with the use of Bohem’s Cocomo II models of software development using the Project Management Institutes (PMI) PMBook as a frame of reference. This in conjunction with the Software Quality Assurance module underscored the importance of two key pieces of planning information when engaging in any project. Basically the PMBook acts as method we may use to determine “How to get to point b from here, point a”; Point B, being the end of the project and the requirements define what the end of said project looks like; by applying Occam’s razor to the project and compartmentalizing the development effort of said software into small manageable segments we may then create a project plan based on real world development time using previous software projects as a means to estimate the Time, Cost and overall requirements to meet the desired development of whatever software project is required. This is done by creating the following documents and plans and including them in a formal agreement with the client.

1. The Formal Software Requirements
2. The Software Development Project Plan
3. The Software Quality Assurance Plan
4. The Software Test Plan (as completed during testing).

Generally these expectations are included in the service level agreement and development contract; often we may employ the use of “Carrots” as bonuses for early completion and limit risk by identifying formal drop dead dates and sticks (punitive damages); associated with missing or failure to deliver on said predefined mile stones.

Why is User Acceptance testing crucial? Why is having their feedback so important to the development cycle? The “Agile” manifesto defines the principles of the “Agile” methodology; the methodology was defined by Beck et al. In 2001. (Beck et al. , 2001)[v] as a means to improve upon the existing software development methods such as Rapid Application Development using RUP and the Waterfall Model’s which have plagued the software development industry for nearly 25 years.

The issues are often that what the client desires is difficult to capture, depending on business, the nature of software abstraction and the use of people as your input agents: Even with formal requirements analysis, risk registers and wireframe design; scope creep is a formidable foe to any software or IT Project and these in conjunction with the inherent risk of working in complete mathematical abstractions only compounds and aggravates the problem of software development risk. The importance of using User Acceptance Testing and Business Acceptance Testing is oft cited by Galin (Galin, 2004)[vi] and Naik et al. (Naik et al., 2011, P. )[vii] That it is critical to defining software development project success factors; in that the End user (The person whom will use your software) defines what your project success is.

These components of stakeholder involvement, constant communications, simple requirements as defined by the client and development team and the rapid application software development life cycle in the Agile development methodology are part of the iterative process thus the definition of success factors for each iterative versions as developed; combined with the rapid software life cycle are designed to foster or incubate success factors within the life cycle of the development project; or at least help change the projects course should it go awry; for whatever reasons.

The ISACA and the (ISC)2 both state that senior management sponsorship is critical to any information technology project, this is also true for any software development project; thus the key to any good development effort is to maintain a body of project knowledge in conjunction with the legal agreements to develop said software and use acceptance testing for both business and users as a means to quantify the project as developed and delivered. Further to this should the project be critical to the businesses income the real risk of failure can be the client or end user bankruptcy and the loss of income for those at the client organization. The proof of the work as requested lies in the UAT along with the “Lessons Learned” briefs as created by the quality assurance plan and software test team; regardless of the nature of development without documented knowledge of what was done or how it was accomplished would lend itself to direct fraud.

This risk is very real when your deliverables are measured in lines of code, or binary executables that are coded by geographically disperse teams of geniuses around the planet and only executed by one parent organization in the internals of some business oriented system for a large multinational organization.

We may underscore the importance of client acceptance testing as being the ability for the client organization to either maintain or adopt the proposed solution with a minimal amount of platform development transfer risk; or undertake the full development of said project with limited and known financial risk according to estimations as generated. Where possible we may even measure against the estimates as a means to deduce project risk for a given iteration.

Software development is defined as both the most profitable industry and the one with the greatest level of risk; it stands to reason that the greatest amount of riches lie in the riskiest ventures. When the success or failure of your company lies in your users ability to use your software; their signature on the hand off documentation or at least of a number of requirements which also include being able to use said platform without aggravation or frustration or complete systems failure; as we see with modern organizations such as Microsoft; Google, Facebook, LinkedIn, Amazon, Yahoo, Apple and other major incorporations whose sole core revenue generators are software; their value is defined as the ability for the average every day person to use their platforms; less the cost of creating said platforms. There we may define the importance of the client sign off, UAT and BAT: as the life blood of the organization for without it lawsuits and bankruptcies may befall such follies.

References
[i] Ewusi-Mensa, Kweku (MIT Press, August 1st 2003) Software Development Failures ISBN: 0-262-05072-2

[ii] Galin, Daniel (Pearson/Addison Welsly, 2004) Software Quality Assurance ISBN: 978-0-201-70945-2)

[iii] N.a. (The Standish Group, 1995 – 2009) The Chaos Report [Online] PDF Document, Available from: http://www.projectsmart.co.uk/docs/chaos-report.pdf (Accessed on March 10th 2012)

[iv] Mateus, Aleh (Model Us, May 4th 2009) Standish Group Chaos Report 2009 [Online] World Wide Web, Available from: http://modelus.com/Blog/post/2009/05/04/Standish-CHAOS-report-for-2009.aspx (Accessed on March 10th 2012)

[v] Beck, Kent; Mike Beedle; Arie van Bennekum; Alistair Cockburn; Ward Cunningham; Martin Fowler; James Grenning; Jim Highsmith; Andrew Hunt; Ron Jeffries; Jon Kern; Brian Marick; Robert C. Martin; Steve Mellor ;Ken Schwaber; Jeff Sutherland; Dave Thomas (Agileinfo Organization, 2001) The manifesto for Agile Development [Online] World Wide Web, Available from: http://agilemanifesto.org/ (Accessed on March 11th 2012)

[vi] Galin, Daniel (Pearson/Addison Welsly, 2004) Software Quality Assurance ISBN: 978-0-201-70945-2)

[vii] Sagar Naik, Piyu Tripathy (John Wiley and Sons, September 23rd 2011) Software Testing and Quality Assurance: Theory and PracticeSoftware Testing and Quality Assurance: Theory and Practice ISBN: 978-1-1182-1163-2

No comments:

Post a Comment