Contents
Agile development is an iterative Software Development Lifecycle (SDLC) model with a strong base in communication, which differs greatly from the high-effort deliverable-based waterfall model. It is designed for environments where the bulk of the requirements may not be known at the start of the project (or change regularly), or for small projects with a highly-communicative development team.
Where we all know and can recite the main stages to the waterfall method, stages in the agile SDLC vary from source to source. This article will examine one version of the agile SDLC.
Before looking at the agile SDLC however, we first need to understand the reasons for choosing this method over others, so we need to recognise the twelve principles of the agile manifesto (taken from agilemanifesto.org):
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity (the art of maximizing the amount of work not done) is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
In terms of client deliverables, we really only need to focus on items 1-3, which can be summed up with “frequent deliveries of working software that adapts to changing requirements and feedback from the client”. A lot of agile methods focus on using the ideal for feature development; however this will not output a working piece of software. In order to accommodate the entire manifesto, we need to deploy the agile methodology to the process as a whole.
With this in mind, we need to adopt a nested iterative approach. What this means is that we use an iterative approach to the whole project (delivering major versions of the software of the client to review frequently), then within that a second iteration for each individual feature (where a feature can be redefined multiple times within each major iteration).
Lifecycle Overview
As stated, a lot of articles regarding the agile SDLC focus on the individual feature iteration aspect, which is where an individual feature or component is designed, developed, and analysed against the requirements before repeating the process.
But how do we get to that point?
Below is one interpretation of the overall project lifecycle following an agile model:
Before we start our iterative development, we still need to perform a few tasks; the first and foremost of which being the definition of requirements. This will then be followed by the architectural design, a major system iteration, individual feature iterations, and finally deployment of the system to the client.
TCdev Snacks will be used as an example project throughout this article, focussing on the asset maintenance component. These examples will appear in block quotes like this one.
Requirements Definition
Very similar to the same stage in the waterfall model, however specific requirements for each application area should be omitted to be determined and expanded upon later. For more information on Requirements Analysis, please read the article here {LINK}.
In comparison to that article, an agile requirements overview document would not have any contract-style requirements as these are too specific at this stage. Use Cases would likely be most prominent, particularly in a situation where the requirements cannot fully be defined at the project inception.
Users must have the ability to maintain asset records within the system.
No specific data elements are required in this example, as they may not be known by the stakeholders at present. Following an iteration, this requirement can be re-evaluated.
Architectural Overview Definition
Now that our base requirements have been laid out, we should have a good understanding of how the system will be held together. Once an architectural overview has been drawn up, development on the base components of the system can begin.
Asset data will be stored in the main database, access to which will be controlled through a window in the client. Users will be able to create, modify and remove assets, all of which will have a direct impact on financial information also stored in the database.
Again in the above example, no specific data elements are defined as they are still not known. At this point we know that there will be a table in the database to hold assets, and we know that a front-end screen must be designed to interface with this.
Major Iteration
With our architectural overview defined, we can begin our first major iteration where features and components will be designed then developed (under an individual feature iteration) and finally reviewed against original requirements.
While the requirements and design of each individual feature are being drawn up, development of core components can commence (such as the creation of the database and development of a multiple document interface (MDI)).
Major Iteration Design
At this stage, we have a basic set of requirements and an architectural overview of the components and how they all link together. At the first iteration, we can skip this stage, however on subsequent iterations this will follow where we have collaborated with the client during a major review, and subsequently alter the design of various features. Potentially new features or components can also be added at this point depending on the client reaction to the system.
Individual assets must also include date of purchase and depreciation values.
The assets should not directly affect the financial data until approved by an administrator.
The example above shows the design following a major iteration and review. So we have a change in requirements and the addition of a new feature, both of which should be addressed during the next iteration.
Major Iteration Review
This stage follows the completion of an individual feature iteration cycle, and involves two main activities:
- User Acceptance Testing (UAT), where the client analyses the system against their requirements, recording any changes that may be required.
- Publishing Documentation for each feature, where any development or user documentation should be finalised and published as a major version.
During the UAT process, the client will raise new requirements that must be addressed in the major iteration design stage.
Asset maintenance fails testing, as no asset name can be entered. Screen should also include purchase date and depreciation value, and new assets must be authorised by an administrator prior to updating financial information.
This component will then be fed back in to the loop.
Individual Feature Iteration
For each individual feature, a nested iterative process should take place in order to better refine each component prior to releasing to the client. This is the main aspect of agile development.
Individual Feature Iteration Requirements
When we initially enter our individual feature iteration, we need to define (or re-define if this is not the first run-through) the feature specific requirements internally. This can now form more of a contract-style requirements list, which will inevitably be built upon in subsequent iterations.
Assets must be recorded within in the system, including the following attributes:
- Asset Name
- Asset Vendor
- Asset Price
Access to asset maintenance:
- Through a window in the client
- Available at any time the client is open
- Maintenance access granted to all users
Additional Information:
- Creation or alteration of an asset should update financial data automatically.
These would form version 0.1 of the assets feature requirements. Following an iteration, version 0.2 may include additional requirements or drop certain sub features, all determined internally.
Individual Feature Iteration Design
For an additional level of control, the feature can be designed prior to development. If the developers are capable of structured design during development, this stage can be omitted. For completeness however, it is at this point that the database fields and interface structure should be defined.
‘Assets’ table must include fields:
- AssetID (PK, INTEGER)
- AssetName (VARCHAR(50))
- Vendor (VARCHAR(50))
- Description (VARCHAR(50))
- Price (REAL)
Interface must be accessed from application toolbar
As above, in terms of documentation these would form the first version of the feature design.
Individual Feature Iteration Test-Driven Development
Test-Driven Development (TDD) is a method of development where a set of test scenarios are outlined prior to starting coding, each of which must be tested against and met when the feature is code-complete. With feature specific requirements defined in a contract-style manner, these tests have essentially already been written.
The below diagram describes this process:
As shown, this is another iterative procedure.
Define Test Scenarios
Prior to commencing development on any feature or component within the system, a series of test cases must be laid out that will clearly define whether the completed feature has met the desired requirements and design. Without pre-defining these test cases, incomplete features could be developed in to the code base, which can lead to delays throughout the SDLC.
- Assets window must be accessible at any time within the system
- The following attributes must be editable through the assets screen:
- Name
- Vendor
- Description
- Price
- Editing an asset must update the financial information
Develop Code
Once the test scenarios have been fully defined, development on the feature can begin. At this point, the developer will have three main documents to refer to:
- Individual Feature Requirements
- Individual Feature Design
- Test Scenarios
High development standards are key to this process as we want as little rework as possible.
Run Tests
Once the code is complete for the feature, the developer must use the test scenarios previously laid out to ensure that the feature has met the desired requirements. In the event that any of the tests fail, the developer will need to go back to defining the test scenarios. The reason that the cycle reverts back to defining the test scenarios and not just to the development stage is that while running tests, the developer may decide that various additional tests should have been defined at the start of development and these have not been met.
The user should not be able to enter a name more than 50 characters long.
Now this test case has been defined, the feature can be redeveloped, and then reevaluated with the updated tests.
Finalise Code / Submit Feature
Once the development is complete and all tests have passed quality assurance (QA), the code must be finalised (optimised and commented), and submitted to review.
Individual Feature Iteration Review
Following the submission of an issue, the completed feature must be reviewed against the design. This phase is optional due to the nature of TDD, however in more complex systems definitive QA testing is recommended.
As agile development is very client focussed, it may be important at this stage to analyse the feature with a view to making it more generic. This will depend on the resale ability of the system, and the effect any change will have on the development time and cost.
System Deployment
Once the client is satisfied that all requirements have been met, we leave the agile aspect of this SDLC and the system must be deployed. One issue with the agile approach is the general lack of documentation associated with each phase; therefore at this point the free development resources will have the time to dedicate to completing any outstanding design or user documentation.
Maintenance
The differences between a traditional and an agile method for system maintenance are very similar to those across the development phase, the most prominent variations between a traditional and agile method are:
- The client prioritises software defect resolutions and change requests
- The development of any changes follow a TDD method
- Minor releases are deployed instead of patches
- QA testers are to regression test around an issue following a development cycle
Following the completion of an iteration, the release must undergo UAT prior to deployment to the client site. The main focus for agile maintenance compared to other maintenance methods however is the involvement of the client throughout the development of the release, in particular frequent updates.
References
- Agile Manifesto
- Agile Modelling