Application Development / Modularity

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.

What is it?

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:

  • Payroll and personnel systems
  • Command and control systems

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:

  • Produce the first delivery in weeks, to achieve an early win and rapid feedback
  • Invent simple solutions, so there is less to modify and facilitating change
  • Improve design quality continually
  • Test early for less expensive defect detection

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:

  • Modules are easy to replace
  • Each module captures one feature of the problem, so aiding comprehension (and hence maintenance); as well as providing a framework for designing as a team
  • A well-structured module can easily be reused for another problem

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 drivers for change

The business drivers include the need for:

  • Speed - that is in reducing the lead-time on the delivery of applications. This also applies to the time taken for COTS applications to be available in the market place, and the business to benefit from COTS and bespoke application development
  • Simplicity - this goal is in many ways related to cost, e.g. Total Cost of Ownership (TCO); it is essential that the application's documentation has a 'normalised' structure, so that the documentation is readily understandable, and can be maintained relatively easily. These are considered to be key quality factors, improving both application domain knowledge, and maintenance and evolution during the application's lifetime.
  • Specificity - the applications development process must be geared towards the needs of the customers and other stakeholders, in the transformation of their needs into suitable specifications, which embrace the necessary environmental constraints and standards. This is increasingly important as the development process moves forward into the design and construction stages.

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.

Principles

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:

  • Reach or converge on a design acceptable to the customer and feasible to the development team
  • limit the project's exposure to the unpredictable elements of both business and environmental change
  • save development time, although for a successful RAD project, something other than schedule must be negotiable. (RAD has the best chance for success if the customer is willing to negotiate both economy and quality).

Important RAD constraints, include:

  • 'Fitness for business purpose' as the criterion for acceptance of deliverables.
  • Representation of all parties that can impact application requirements throughout the development process.
  • Customers, developers and management accepting informal deliverables, e.g. notes from user workshops rather than formal requirements documents.
  • Creating the minimum documentation necessary to facilitate future development and maintenance.
  • Empowerment of development teams to make decisions traditionally left to management.
  • Iteration being used in such a manner to converge towards an acceptable business solution.
  • Prototypes that can incorporate evolving requirements quickly, to gain consensus early in the life-cycle.

The use of accelerated development methods requires skilled, multidisciplinary teams, who are able to advise on when to apply such approaches.

Critical Success Factors

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:

  • Ensuring that any applications development is properly qualified.
  • Forming a working partnership between all project participants, aimed at maximising co-operation and ensuring that each participating group remains flexible and responsive to new conditions with business objectives in mind.
  • Assuring that the executive sponsor is willing to play an active role in the project.
  • Assuring the project sponsor is willing and able to represent the user community.
  • Ensuring that there are well defined and fully implemented scope management policy and procedures.
  • Ensuring that the developers are skilled and supported by comprehensive development technology.
  • Providing a supportive project environment

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.

Processes

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.

Further Information/Related Topics e.g. Roles/Techniques/Skills

 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.)