Clicktricity 5D is our unique agile application development methodology that drives our delivery of cost-effective, repeatable, quality solutions in an adaptable framework that suits software development and application implementations for both small and large enterprises.

Our 5D methodology allows us to consistently provide the following:

• Accurately determine your business and commercial requirements
• Design a solution that meets your short and long terms needs
• Develop a quality application, on-time, on-budget
• Implement the solution with minimal impact to your ongoing business operations
• Provide comprehensive handover and ongoing support of the delivered solution

Our 5D methodology is an iterative process consisting of the following standard phases, which may be repeated as necessary for each phase and sub-phase of a project.

Our analysts and solution architects will work closely with you to understand and accurately document your business, commercial and operational requirements. We will map out the project timeline, risks, impact and deliverables. We also divide the project up into short, medium and long term achievable and measurable milestones in order that progress can be accurately tracked, monitored and managed.

The detailed design stage builds upon the initial discovery analysis and describes in detail exactly what is required, how it will be achieved and the process that will be used to produce the final result.

Using an iterative cyclical process, we develop, test and QA the solution according to our strict quality and development standards. In addition, we keep you, the customer involved in every step of the development process including functional prototypes and pre-release candidates.

Our consultants deliver the completed solution and install it in the customer's environment. We then work with the customer to complete acceptance tests and verification of functionality.

We work closely with your resources to deploy the application, complete the handover and provide any user training that is required. We will also complete a comprehensive post-project review to ensure that we have met every requirement.

In addition to our own 5D methodoloogy, we are always happy to follow our client's own preferred methodology where appropriate. In this respect, our consultants have experience includes the following:

• Prince
• SSADM
• DSDM
• CMMI SW-CMM
• XP Extreme Programming
• Agile Software Development
• Oracle Method

In software engineering, agile software development or agile methods are low-overhead methodologies that accept that software is difficult to control. They minimize risk by ensuring that software engineers focus on smaller units of work.

One way in which agile software development is generally distinguished from 'heavier', more process-centric methodologies, for example the 'waterfall method', is by its emphasis on values and principles, rather than on processes.

Typical cycles are from one week to one month, and at the end of each cycle they re-evaluate the project priorities - a feature it shares with 'iterative development' methodologies, and most modern theories of project management

Clicktricity makes use of both extreme and traditional methodologies according to the individial needs of projects and customers, and the distinct components of these projects. For example: a project may include core database technology that needs extensive planning to mitigate risk, but it may also contain a rapidly evolving user interface where progress needs to be demonstrated quickly, even if not all the functionality is available immediately.

The two most important core values of Extreme Programming are Communication and Simplicity.

Communication

It is recognised that poor communication in software teams is one of the root causes of failures within projects – whether it be schedule slips, botched requirements, misunderstandings, faulty development assumptions, and the like. Extreme Programming mitigates this by stressing good communication between all project stakeholders – customers, team members, and project managers (or “coaches”) – on a consistent basis. A representative from the customer should be available as much as possible to answer questions and clarify project requirements. Programmers often work simultaneously in pairs, with each programmer reviewing the other's work.

Simplicity

One of the most common XP slogans is "YAGNI" or 'You Aren't Going to Need It'

The principal of YAGNI is that you shouldn't develop any code that will only be used by a feature that is needed tomorrow. This does not exclude development of flexibility, but it should be kept in check and only functionality that is required now is actually developed.

When we select the Extreme Programming model, we try to follow these principles:

User Stories

User stories are short, simple descriptions of required functionality that are written by the customer, rather than our interpretation of what the customer wants. The descriptions should only contain sufficient detail to allow development of an accurate estimate for planning purposes, development of unit tests, and are used instead of large unwieldy requirements documents. When we develop and implement the user stories, the developers will work face-to-face with the customer to determine the specific detailed requirements.

Planning

The Planning phase of development is performed in two parts – firstly the “user stories” described above are elicited from the customer. Secondly, the development team estimates development effort for each story. The customer then decides on priorities and agrees what user stories will be implemented in the next release. This defines the project schedule.

Small Releases

The planning phase determines small units of functionality that make good business sense and can be released into the customer's environment early in the project. This is critical to getting valuable feedback in time to have an impact on the system's development.

Design Simplicity

The overwhelming aim is to make things as simple as possible. The only code being worked on should be the code that is absolutely necessary to implement the latest user stories, and no more (see YAGNI, as described previously). The drive for simplicity leads to continual refactoring of code, as described below.

Testing

Testing, and in particular writing test specifications from the user stories before coding is another essential component of this technique. Traditional development techniques that follow a "code first, test later" technique are prone to only testing a limited part of the development. In addition it is common that as schedules become tight - thorough testing is often dropped in the intetest of expediancy, leading to low quality, error prone code. Our technique is to define and develop automated tests before coding ensuring that untested code cannot be released.

Pair Programming

In pair programming, one member of the pair will write code while at the same time another programmer is critiquing the work at hand, and at the same time offering insight as to the next step as well as exposing trivial defects with the code. In tests, pair programming has been shown to be 30% more productive when quality is taken into account, than the combined productivity of two developers working separately.

Refactoring

Once it becomes apparent to the development team that the system design, a module or piece of individual code is becoming too complex, the code is refactored. The refactoring process is one by which the system functionality remains stationary – all tests that pass prior to refactoring should pass after refactoring is completed – but the code base becomes greatly simplified. This may involve eliminating shared code, redesigning model hierarchies and relationships, or simply renaming variables to fit a particular metaphor.

No Overtime

A standard working week with no overtime is strictly adhered to, based on the assertion that development teams are able to produce high-quality product when they are comfortable and not overly-exerted. This principle serves to complement the idea of both pair programming and communication amongst the development team and their customer.

Customer Availability

It is not enough to have only occasional access to a customer and a customer representative should be continuously available to the development team. This ensures that all unanticipated questions or requirements can be immediately resolved and eliminates the need to produce exhaustive and definitive (and probably still incomplete and non-definitive) specifications at the beginning of the project. This also allows the customer to interact with the development and help in the evolution of the product. Maximizing customer availability makes it possible to minimize the time spent on preliminary planning and focus on development, and maximize feedback, thereby increasing the value delivered to the customer.

Coding Standards

The entire development team agrees to maintain a common set of rules concerning the maintenance and creation of new code. These standards greatly simplify communication through common naming conventions and generate shared ownership and responsibility among all developers.

For more information on the principles of Extreme Programming, please see

• Extreme Programming: A Gentle Introduction
• Agile Software Development - Wikipedia