Organisations continue to change at a dramatic rate. Many organisations rely on application systems to underpin and support business processes, and staff are dependent upon applications in order to perform their day-to-day roles. To meet business needs and achieve organisational goals, it is necessary to assure that the software development and maintenance processes are sufficiently agile, catering for business demands in a turbulent environment.
A recent study of over 200 application development projects indicated that in greater than 50% of cases, there was no evidence of the original development plans on which to measure project performance. It was concluded that conforming to plan was no longer the primary development goal. The focus has changed in favour of satisfying customer at the time of delivery, rather than at project initiation. For example, even within a development project's life-cycle, there are often major changes in scope, requirements, and technology that are outside of the project team's control.
On the assumption that Boehm's life-cycle cost differentials theory is valid - the real issue is not how to stop change early in a development project, but how to better handle inevitable changes throughout the systems life-cycle.
Applications development is the methodical and systematic approach to planning, analysis, design, construction, implementation and evolution of an application system.
An application is usually considered to be a bounded set of related systems that address a particular type of problem. Example of application domains, include:
Traditional approaches have assumed that a complete set of requirements could be defined early in the lifecycle and that development costs could be controlled by managing change. However, eliminating change can mean being unresponsive to business conditions. A new strategy is required which recognises that change is inevitable whilst attempting to minimise the costs of responding to them and moreover retaining quality.
Agile development methods are a response to business expectations, with the goal of reducing the cost of change throughout a development project. For example, Extreme Programming (XP) calls for developers to:
Agile development methods stress quality in design, and even with more traditional approaches, design has been usually considered a problem solving technique and a key aspect of applications development.
The use of an appropriate form of modular structuring makes it possible for a given problem to be considered in terms of a set of smaller components. This principle has long been established in engineering and is generally only possible where a well-defined set of interface standards exist.
To make good use of a modular structure, defining interfaces is not enough, the design process needs to be based on a separation of concerns, by grouping functions within modules in such a way that their interdependence is minimised. Such a grouping results in a less complex interface to the module. There are a number of benefits to this approach:
The successful use of modularity should be reflected in quality characteristics, including: maintainability, testability, usability, and reliability.
Two quality measures used since the 1970's for assessing the extent of modular structuring in applications software are: 'coupling' and 'cohesion'. They are useful from a management perspective also, in that they can be used to identify the complexity of a system in terms of the form and interdependence of the component modules, and such evidence can inform risk management activities.
A further consideration, which may be used in conjunction with the concept of modularity, is that of incremental delivery. Such an approach may significantly reduce the level of risk, but it should also be recognised that such an approach needs to be reflected in the investment analysis and benefits realisation profile.
Why we need to change (Why it is important)
To improve the quality of the systems planning, analysis, delivery, and evolution of applications, it is necessary to focus on software development and maintenance processes, and support developers with process engineering technologies, tools and methods.
Accelerated and agile development methods are increasingly popular to deal with the dynamics of the business environment, changing goals and objectives. They are often preferred for those applications where the project scope is constrained, reliability is not a critical factor and where the delivery date is a critical factor.
In general terms, accelerated application development methods adopt a three-phase life-cycle model: accelerated analysis and design, time-boxed development, production and implementation. The methods are usually underpinned by information/software engineering technology, and rely on joint (analyst-user) sessions, and prototyping to quickly define requirements and create a working prototype to simulate the proposed application. It should be noted that components of accelerated applications development are not unique to this method. It is the configuration of components - work plan, tools, project management, and user involvement to create a highly effective working environment, that makes this a powerful method.
From a business perspective, the use of modular design and incremental delivery by applications developers means that a distinct part of the overall project can be delivered before the development team are in a position to complete the project. This approach offers early benefits to the business, and provides an opportunity for both the business and development team to discover emergent system properties and learn from their experience.
Accelerated and agile development methods embodying modular design and incremental delivery, can be used to reduce both development and implementation risks. The actual projects may not necessarily be easier to manage, but they can facilitate implementation and acceptance, offer more options for contingency, enable developers to deal with changing business requirements and environmental conditions, and provide both milestones and decision points for project control purposes.
Traditional approaches to modularity can help reduce risk and deliver some of the benefits above, but there are cost considerations that need to be offset in terms of delay in delivering the full business benefits.
The business drivers include the need for:
These drivers are addressed by rapid application development (RAD) methods, e.g. DSDM.
RAD methods address the business drivers in that they overcome the long delay associated with conventional methods, before the customer sees any results. In reducing the lead-time for the development, there is less risk that the customers business has fundamentally changed by the time the system is delivered.
Who is involved?
Applications development is normally undertaken as a 'project' and therefore involves a 'project manager' and associated roles, e.g. project sponsor, Senior Responsible Owner (SRO) etc.
The project team usually consists of developers, undertaking technical roles, including: analysis, design, programming, technical authorship (documentation), testing, and configuration management.
Business management, users and customers may be directly involved in applications development, the extent of which is dependent upon the development methods employed by the team.
For COTS applications and application services, e.g. systems integration, modification etc., procurement staff, specialist advisers and contract managers may also be involved.
Application development can be broken down into technical stages and managerial phases. To further facilitate the overall management and delivery of the application systems, design modules can be identified which may be support incremental development and delivery plans.
Rapid application development methods can be used to:
Important RAD constraints, include:
The use of accelerated development methods requires skilled, multidisciplinary teams, who are able to advise on when to apply such approaches.
Application developers need to be able to react efficiently to the business need for evolution and innovation and proactively engage in shaping the business processes and work-force culture. Development managers need therefore, to address any applications development backlog.
For a successful application development process, it is imperative that the developers understand the user's requirements, and that communication difficulties between users and analysts are resolved, and customers and users can contribute effectively to the convergence process for designing an effective business solution.
A defined applications development process that is visible, repeatable, well understood, and workable geared towards improving application systems quality and performance is essential.
Agile and accelerated applications development methods have an increasingly important role, but they also create additional management responsibilities for effective deployment, for example:
For agile and accelerated development methods to be applied successfully, a mature approach to risk consideration and management is required by both the business and the development team. The business and developers need to be prepared to adopt a 'build and learn' approach which may involve both incremental development of designed modules, and incremental delivery. In such instances, management need to carefully plan their communications and release strategy in order to gain the necessary feedback from trials in a controlled and managed environment.
The applications development process needs to be placed into the overall business development context, as described below:
Planning - in which the strategic IS vision in support of the organisation's business plans and objectives is developed. Planning should also consider the business infrastructure and needs, and identify ways of maximising the ROI of any technology-based solution
Analysis in which a rigorous, logical model of data, process, and behaviour is developed that will address the requirements of the business. The analysis should result in high level design for each application, and input to the detailed planning process in terms of the definition, prioritisation and schedule for application development projects, as necessary.
Application development - undertaken using project management disciplines, in which the detailed requirements are refined and design specification produced on which to base the construction of the application, and its subsequent testing.
Application support - this is concerned with ensuring that the necessary infrastructure is in place. The design of the IS infrastructure, and training programmes are usually undertaken in parallel with the application design, but can sometimes be managed as a separate project.
Implementation - in which the production environment is established and the application is migrated for operational use and systems performance is monitored and business benefits realised.
Accelerated development methods, e.g. DSDM have an iterative and incremental life-cycle which means that the application may not necessarily be delivered to the organisation in one go, but rather in a series of increments. This can benefit the business in that urgent requirements can be addressed earlier than if they had to wait until all requirements could be delivered. Other benefits include early validation of deliverable quality.
DSDM recognises five phases: feasibility study, business study, functional model iteration, design and build iteration, and implementation. The feasibility and business studies are done sequentially and set the ground rules for any subsequent development.
Comparison of conventional and accelerated Applications Development
| Category | Conventional Development |
Accelerated Development |
| General approach |
Sequential phases |
Evolutionary |
| User resource commitment |
±15% throughout the project |
100% throughout project for project sponsor,±30% for selected others |
| Risk |
Higher - longer term project problems may not emerge until well into the development project |
Lower - problems surface early in the development process, requiring quick resolution |
| Executive sponsorship |
Has approval authority, but not actively involved |
High participation - sets scope, reviews progress, and resolves issues |
| Use of joint session, iteration and prototyping techniques |
Optional |
Required |
| Developer skills |
Specialists, some with limited experience acceptable |
Highly experienced, multi-skilled professionals required |
| Use of process support technology, e.g. CASE tools |
Optional |
Required |
| Team structure |
Usually large with specialised skill sets |
Usually small with general skill sets, supplemented by specialists as needed |
| Rigorous scope management |
Necessary |
Critical |
| Phase structure |
4-5 phases |
3 phases |
| Individual accountability |
Difficult to assess |
Precise accountability |
Further detailed stage-based guidance for this subject can be found in the Requirements Workbook and the Risk Management Workbook.
DSDM - Dynamic Systems Development Methodology.
SSADM - Structured Systems Analysis and Design Method and Business Development Method.
PRINCE2 - Projects in a controlled environment.
Project management, analyst, developer, tester, and support roles.
Business Modelling - For example, UML.
Systems thinking (representations and abstraction). Peter Checkland, Brian Wilson references.
Design strategies (modularity).
Dealing with constraints (time, cost, quality etc.)