Question 1: Testing

The following diagram depicts the primary test phases of a solution; each test phase may be broken in to multiple iterative test cycles.

Unit Testing Build

Integrati on Testing

Accepta nce Testing

Defect Resolution

Regression Testing

Integration Testing
Integration testing is the next step on from Unit testing, it aims to establish tests that are integrated across multiple parts of the solution to ensure that the individual components of the solution work in an integrated way with each other. Integration testing is usually carried by the development team; either by the Developer(s), his/her peers or indeed a specific testing team or organisation. Depending on the size of the project, it also possible for the client or customer to be involved in the integration testing, this may be focused on integrated process testing, as opposed to functionality testing. During integration testing it is important to ensure that the solution works in a cross functional and integrated environment this will mean that separate work streams or areas of functionality will be tested together as according to the solution design requirements.

Regression Testing
Regression testing is the formal re-testing of a previously verified solution. Normally regression testing is instigated as the result of issue resolution, a subsequent change or an upgrade to the solution. Similar to integration testing, regression testing is usually carried out by the development team. It is also common when a solution that is live; Business representatives may be involved in the regression testing to ensure the risk of negatively impacting the live solution is mitigated. Regression testing is also a common target of Automated Testing, as it is more predictable based on scripting originating from verified test cases and test results of earlier testing cycles. Regression testing will often include test scenarios from the unit test, Integration test and acceptance test phases

Acceptance Testing
Acceptance Testing, sometimes known as Business Acceptance Testing or User Acceptance Testing is formal validation of the solution against the business requirements. Acceptance testing usually focuses around usability in the real world; in particular this may centre on look and feel, performance and ease of use. Unlike Integration testing, Acceptance testing is almost always exclusively carried out by the customer with key business users being involved in this phase. In the battle for hearts and minds, this can be a very important phase for influencing opinions to a new solution; this is particularly the case where business users may be seeing the solution for the first time.

Question 2: Modern Software Development Agile Software Development

Introduction
Agile development is the grouping of popular development methods with references commonly made to Scrum, Extreme Programming (XP) and Dynamic System Development Method (DSDM). Agile development is a concept that has existed for some time, but 2001 saw the turning point and summing up in what became known as the Agile Manifesto The Agile Manifesto as published (Kent Beck et al 20011) is:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more

The key features of agile software development are a focus on the people involved in the development, and that the focus is on building a solution in small discreet work packages quickly. Essentially merging the design, build and test phases into one joined up body of work. Working software is clearly the desired outcome, and to improve the work through put, the teams in agile development are self governing, and lot less emphasis is on creating detail documentation; be it for design or build documentation. It is important that the customer is actively engaged in the build phase, and as such collaboration between the development team and the customer is critical. Co-location of customer and developers is very important (not so good if you have an offshore model). Due to the high level of customer involvement during build (essential replacing the typically signed off designed detail), a degree of change can be expected as the solution starts to evolve. This makes traditional planning difficult as it is certainly an evolving and changing plan, much like the solution that is being built.

People
The fact that the biggest impact is on the people and working environment, result in a different team make up. Due to fluid nature of design, the development team needs to be of a more senior and knowledgably base, as the shorter duration of each designbuild-test phase is quite a lot quicker, less time is available for on boarding. As part of agile, there will normally be a number of these teams all working on different components or functions of the solution; as such, regular cross-team interaction is required to ensure that all teams are working to the same goal.

Assessment
Agile development whilst surly having its merits in being able to deliver a quick solution is not likely to be appropriate in our business environment. Through my investigation, I can clearly see that Agile would work well where a solution or technology is relatively mature and low risk. But in our business environment where we are seen as a key player delivering robust, well design and tested solutions it would not play to our strengths. Not to mention the fact we do offer a offshore model, attempting to run a agile development approach would certainly be hindered by our offshore contingent (relocation would simple ruin the cost benefit we try to establish). In summary, agile development is not suited for out business as the risks it would introduce would not provide a clear advantage.

References
1) Kent Beck, 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. Manifesto of Agile Software Development [Online], 2001, http://www.agilemanifesto.org/, access on 22nd November 2009. 2) James Coplien, Kevlin-Henney. Agile Architecture is not Fragile Architecture, 10th June 2008 [Online Web cast Video] http://www.infoq.com/presentations/Agile-Architecture-Is-Not-FragileArchitecture-James-Coplien-Kevlin-Henney, accessed on 22nd November 2009. 3) Pekka Abrahamsson, Outi Salo, Jussi Ronkainen and Juhani Warsta. Agile software development methods, Review and Analysis, VTT Publications 478, http://www.vtt.fi/inf/pdf/publications/2002/P478.pdf, accessed on 22nd November 2009. 4) Agile Alliance: Agile Alliance Home [Homepage of the Agile Alliance][Online] http://agilealliance.org/home, accessed on 22nd November 2009

Question 3: Software lifecycle management

a. The incremental model
The incremental model is a software delivery lifecycle that sees the software solution delivered in multiple releases. The first base-line release will include the underlying software architecture and a specific subset of functionality. Each subsequent release will see the addition of further functionality and enhancements. The Incremental Model can be used in conjunction with either the Waterfall Model or the V Model. This model is depicted in the graph below.
Amount of functionality

The Incremental Delivery Model

Additional Functionality

Base-line Architecture

Release 1

Release 2

Release 3

Release 4

Time

Specific external circumstance that would result in the use if the incremental model are: Big Bang risk mitigation When delivering large complicated solution, it can be often seen as risky to introduce large change into a business (i.e. Big Bang change). By taking an incremental release approach, change can be delivered in a more manageable multi-release and risk averse manner. When resource constraints may be apparent (Developer or otherwise), breaking the deliverables into separated releases removes possibly overburdening the project team. (Deliver one thing well, rather than many things badly) Business conditions may make it desirable to deliver benefits early into the project. Delivering phased releases allows quick wins to be realised earlier than waiting for the whole project to be complete. By delivering a solution in multiple releases, a degree of flexibility remains in controlling and locking down of the scope of the subsequent releases. What may have been important to the business in the early days, may not be as important later on this is always particular evident after the first release Go Live.

Resource availability

Benefits realisation

Scope flexibility

b. The Boehm spiral

The essential characteristics of the Boehm spiral model of cost management are broken into the following phases: 1. Establishing what are our objectives and what the desired outcomes are. 2. Understanding how we best intend to achieve these outcomes. 3. Executing our plan and delivering the solution. 4. Assessing and measuring delivery against the stated objectives and outcomes. There is a cost associated with any project, and this increases as we proceed though each phase. In the case of a project being delivered using the Incremental model, it would be recognised that we would go through the four phases as part of each release. By using the Boehm spiral phases we can provide a gated checkpoint to review the cost of implementing each release. The will allow us to measure the cost against the benefits we expect to be realised, there by given the key stakeholder decision makers the ability to assess and justify (or not as the case may be) the project. It is possible to overlay a Boehm spiral into the Incremental Delivery Model to demonstrate this increase in cost as we progress through releases. The Boehm Spiral relationship to Incremental Delivery Model
Implementation Cost Review Cost Vector

Release 1

Release 2

Release 3

Release 4

Time

Evaluation

Objectives