The Agile System Development Life Cycle

The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used to describe a process for planning, creating, testing, and deploying an information system. The systems development lifecycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. (Wikipedia)

On the basis of SDLC, Clear Systems Asia team are working consistency with Agile methodology.This SDLC is comprised of six phases: Concept Phase, Inception/Iteration 0, Construction, Transition/Release, Production, and Retirement. A more realistic life cycle is captured bellow.

1. Concept Phase: Pre-Project Planning
Clear Systems Asia team will focus on: Define the business opportunity, Identify a viable for the project and Assess the feasibility.
Concept Phase activities can and should be as agile as you can possibly make it – you should collaborate with stakeholders who are knowledgeable enough and motivated enough to consider this potential project and invest in just enough effort to decide whether to consider funding the effort further.

2. Inception Phase: Warm Up
The first week or so of an agile project is often referred to as "Iteration 0" (or "Cycle 0") or in The Eclipse Way the "Warm Up" iteration. Your goal during this period is to initiate the project by:
- Garnering initial support and funding for the project.
- Actively working with stakeholders to initially model the scope of the system.
- Starting to build the team.
- Modeling an initial architecture for the system.
- Setting up the environment.
- Estimating the project.

3. Construction Iterations:
construction iterations agilists incrementally deliver high-quality working software which meets the changing needs of our stakeholders. We achieve this by:

Collaborating closely with both our stakeholders and with other developers: We do this to reduce risk through tightening the feedback cycle and by improving communication via closer collaboration.

Implementing functionality in priority order: We allow our stakeholders to change the requirements to meet their exact needs as they see fit. The stakeholders are given complete control over the scope, budget, and schedule – they get what they want and spend as much as they want for as long as they're willing to do so.

Analyzing and designing: We analyze individual requirements by model storming on a just-in-time (JIT) basis for a few minutes before spending several hours or days implementing the requirement. Guided by our architecture models, often hand-sketched diagrams, we take a highly-collaborative, test-driven design (TDD) approach to development (see Figure 9) where we iteratively write a test and then write just enough production code to fulfill that test. Sometimes, particularly for complex requirements or for design issues requiring significant forethought, we will model just a bit ahead to ensure that the developers don't need to wait for information.

Ensuring quality: Disciplined agilists are firm believers in following guidance such as coding conventions and modeling style guidelines. Furthermore, we refactor our application code and/or our database schema as required to ensure that we have the best design possible.

Regularly delivering working solutions: At the end of each development cycle/iteration you should have a partial, working solution to show people. Better yet, you should be able to deploy this solution into a pre-production testing/QA sandbox for system integration testing. The sooner, and more often, you can do such testing the better. See Agile Testing and Quality Strategies: Discipline Over Rhetoric for more thoughts.

Testing, testing, and yes, testing: An agilists do a significant amount of testing throughout construction. As part of construction we do confirmatory testing, a combination of developer testing at the design level and agile acceptance testing at the requirements level. In many ways confirmatory testing is the agile equivalent of "testing against the specification" because it confirms that the software which we've built to date works according to the intent of our stakeholders as we understand it today. This isn't the complete testing picture: Because we are producing working software on a regular basis, at least at the end of each iteration although ideally more often, we're in a position to deliver that working software to an independent test team for investigative testing. Investigative testing is done by test professionals who are good at finding defects which the developers have missed. These defects might pertain to usability or integration problems, sometimes they pertain to requirements which we missed or simply haven't implemented yet, and sometimes they pertain to things we simply didn't think to test for.

4. Transition phase: The "End Game

During Transition, also known as the "end game" or deployment, we release the solution into production. There are several important aspects to this effort:

Final testing of the system. Final system and acceptance testing should be performed at this point, although as I pointed out earlier the majority of testing should be done during construction iterations (ideally, you just need to rerun your regression test suite to see that it works). You may choose to pilot/beta test your system with a subset of the eventual end users.

Rework. There is no value testing the system if you don't plan to act on the defects that you find. You may not address all defects, but you should expect to fix some of them.

Finalization of any system and user documentation. Some documentation may have been written during construction iterations, but it typically isn't finalized until the system release itself has been finalized to avoid unnecessary rework Note that documentation is treated like any other requirement: it should be costed, prioritized, and created only if stakeholders are willing to invest in it. Agilists believe that if stakeholders are smart enough to earn the money then they must also be smart enough to spend it appropriately.

Training. We train end users, operations staff, and support staff to work effectively with our system.

Deploy the system.

5. Production Phase:
The goal of the Production Phase is to keep systems useful and productive after they have been deployed to the user community. This process will differ from organization to organization and perhaps even from system to system, but the fundamental goal remains the same: keep the system running and help users to use it. Shrink-wrapped software, for example, will not require operational support but will typically require a help desk to assist users. Organizations that implement systems for internal use will usually require an operational staff to run and monitor systems.

This phase ends when the release of a system has been slated for retirement or when support for that release has ended. The latter may occur immediately upon the release of a newer version, some time after the release of a newer version, or simply on a date that the business has decided to end support. This phase typically has one iteration because it applies to the operational lifetime of a single release of your software. There may be multiple iterations, however, if you defined multiple levels of support that your software will have over time.

6. Retirement Phase

The goal of the Retirement Phase is the removal of a system release from production, and occasionally even the complete system itself, an activity also known as system decommissioning or system sunsetting. Retirement of systems is a serious issue faced by many organizations today as legacy systems are removed and replaced by new systems. You must strive to complete this effort with minimal impact to business operations. If you have tried this in the past, you know how complex it can be to execute successfully. System releases are removed from production for several reasons, including:

The system is being complete replaced. It is not uncommon to see homegrown systems for human resource functions being replaced by COTS systems such as SAP or Oracle Financials.

The release is no longer to be supported. Sometimes organizations will have several releases in production at the same time, and over time older releases are dropped.

The system no longer needed to support the current business model. A organization may explore a new business area by developing new systems only to discover that it is not cost effective.

The system is redundant. Organizations that grow by mergers and/or acquisitions often end up with redundant systems as they consolidate their operations.

The system has become obsolete.

In most cases, the retirement of older releases is a handled during the deployment of a newer version of the system and is a relatively simple exercise. Typically, the deployment of the new release includes steps to remove the previous release. There are times, however, when you do not retire a release simply because you deploy a newer version. This may happen if you can not require users to migrate to the new release or if you must maintain an older system for backward compatibility.

For more information, don't hesitate to contact us for free consultancy here.