Web Design & Hosting
Application Development
Internet Marketing
IT Consulting

The Application Development Lifecycle (ADL) can be considered a generalisation of the Web Development Lifecycle (WDL) since it applies to the development of systems across the whole universe of application platforms and architectures (such as solutions that may include any combination of web, mobile, enterprise, or other customer applications, to mention but a few) - not only to web design and development solutions. For this reason, the lifecycle is introduced in more general terms than the specific lifecycle relating to the development of web applications.

Although there are a number of Application Development Lifecycle Models appropriate to different types of system and requirements, such as Waterfall, Prototyping, Spiral, Dynamic Systems Development, Iterative, and the OOD methodology, it is useful to describe the application development lifecycle in more traditional terms. Essentially, the lifecycle can be described as being composed of five generic stages whatever the platform or architecture of the system being developed on behalf of a client. These stages of development, the application development lifecycle, are introduced more fully below:

Application Requirements Analysis

To the TeCS team the most important stage of the Applications Development Lifecycle is the process of understanding the business requirements of the system that we are developing for our Client. The initial phase of the requirements analysis stage is not concerned with implementation details; only with the outputs, services, optimizations, and business benefits that the development of the application will bring to the Client.

Only when the business benefits and deliverables are established will the architects at TeCS move on to a consideration of the application, data and hardware architecture needed to deliver the required functionality. It is often incorrectly assumed that every application can be developed, given enough software developers, resources and finance. The reality is that this is not the case, and the architectural team at TeCS will make a clear assessment of the feasibility of any given project, and be frank and open in communicating their recommendation to our Client. Our reputation is very important to us, and it is our policy to only ever deliver solutions that are entirely fit-for-purpose.

Should TeCS architectural team consider an application development project to be feasible within the limits of the current state of technology, the availability of resources, and the budgetary constraints of the Client, they will then make the appropriate recommendations regarding the software and hardware architecture necessary to achieve a strong solution.

In general terms, the output from this stage of the application development lifecycle is a clear definition of the application requirements, in the form of a High Level Requirements Specification.

Communicating the Solution (Application Design)

This stage of the application development lifecycle is concerned with the delivery of a set of precise design specifications. The first type of specification are high level, serving as a clear point of reference for communication and discussion between the TeCS project team and the Client. The high level specifications are written in plain, but somewhat precise human language so that misunderstandings are kept to a bare minimum.

The second type of design specification are termed low level design documents. These are developed from the high level design, and contain the full implementation details of the required application, serving as a clear, unequivocal blueprint for the software developers, designers, and other menbers of the development team. Low level specification are expressed in technical design terminology and graphical schemas such as EBNF, Jackson Diagrams, or various other structured semantic notation are employed depending on the Application Development Lifecycle Model being utilized by the development team.

Split between being a high level specification and a low level design document, the Graphical User Interface (GUI) design offers a valuable frame of reference for both TeCS and the Client. Within this document the wireframe screen layouts would be precisely defined, and described in terms clear to the Client - enabling the Client to collaborate with TeCS and contribute to the design and process flow of the application. The GUI design document is just as useful to the development team at TeCS as it is to the Client in establishing the how the application will be presented to the application's user base.

Application Development

During this stage of the application development lifecycle low level specifications would be turned into working code under the control and scheduling of the project manager, based on their agreed project plan. The project plan is particularly important as a tool for identifying and allocating the resources required, allocating tasks, understand the dependency between tasks, and meeting delivery schedules.

Though technically falling with the Test stage of the lifecycle, it is during the development phase that all modules are unit tested to destruction using a combination of automated and manual testing procedures.

System & Application Testing

From unit testing individual modules, to testing the system as a whole, it is during this stage of the lifecycle that the team at TeCS will ensure that everything is working precisely as specified with the design specifications, and as agreed with the Client. In fact, the TeCS test team will use the design documents as a basis for developing what are termed Use Cases (documented tests that determine whether part of the system functions according to the range of expected results) in order to fully test the application. The type of application being developed, and the platform on which it will be hosted determines the type of testing that is undertaken. For instance, all applications require System and Volume testing, but in general only web applications require Cross-Browser testing.

All testing up to the time of submitting the application to the Client for approval are for the purposed of TeCS in order to ensure that we have surpassed your expectations in delivering a quality solution. Once we are TeCS are satisfied that all is working as expected, the application will be submitted to the Client for User Acceptance Testing (UAT). The Client or their agents will test the system to ensure it is fit-for-purpose from their perspective, and match the specified requirements.

Deployment

Once all parties are satisfied that the application is working as expected, the system will be deployed to its production environment or packaged for distribution depending on the type of application being released. A period of stabilisation, warranty and support will follow whereby the software company will make itself available to resolve any issues that managed to get through testing.

Why not contact us to discuss your application development requirements today.