Agile Enterprise Development

The business community required that the IT industry respond to their dynamic operating environment which obliges them to continually adapt their structures, strategies and policies (Abrahamsson et al, 2003, Nerur et al, 2005). Agile enterprises are the result of these developments (Baskerville and Siponen, 2002).

This necessitated the progression of IT systems to the current instalment, BPM, which is characterised by agile development methods.

4.5.1 Agile Software Characteristics

The agile movement is broad in scope and is characterised by three features.

First, it possesses a chaordic perspective which arises from the unpredictable software development environment. Project goals are defined whilst the details remain unpredictable. Second, it has collaborative values and principles in which Agile processes capitalise on individual and team strengths. Third, it uses the concept of barely sufficient methodology to establish the development structure needed. Agile methods balance flexibility, structure and bare sufficiency to reduce costs, through streamlining, whilst increasing innovation through incorporating the chaordic perspective (Highsmith, 2002). There have emerged numerous agile development methods.

4.5.2 Agile Software Methods

Agile software development is both incremental and iterative with short release cycles which enable fast verification and correction. There is close customer and developer interaction which results in a collaborative working style. Its methods are simple and provide sufficient documentation and are regarded as adaptive because they can react to last moment changes. Its goal is to increase the ability to react and respond to changing business, customer and technological needs at all organisational levels (Abrahamsson et al, 2003).

Examples of agile development methods include Adaptive Software Development (ASD); Extreme programming (XP); FDD and Internet-speed development (ISD)

(Gotterbarn, 2004, Abrahamsson et al, 2003, Highsmith, 2002). Some of their objectives are briefly described. The ASD method replaces the traditional plan-design-build lifecycle with a dynamic speculate-collaborate-learn cycle and is dedicated to continuous adaptation (Beznosov and Krutchen, 2004, Highsmith, 2002). It promotes an adaptive paradigm and claims to provide sufficient guidance to prevent chaos but without suppressing emergence and creativity (Abrahamsson et al, 2003). XP provides a set of recognized engineering practices, which enable software development despite changing requirements. It is characterised by small releases, rapid and continuous feedback, integration and close developer / client relationships. FDD is a process-driven method for developing business critical systems. It typifies the iterative development approach and emphasises quality through accurate monitoring of the project process (Highsmith, 2002, Abrahamsson et al, 2003). ISD is typified by short development cycles which produce fast released software. It draws from the ‘synch-and-stabilise’ approach of Microsoft that aims to cope with rapid software development and emergent organisations (Abrahamsson et al, 2003). These agile methods rely on the gradual emergence of the design and requirements and emphasise collaboration. They differ fundamentally, in concept, from traditional software development methodologies (Nerur et al, 2005).

4.5.3 Agile versus Traditional Software Development Methods

The agile software development trend is enduring and adopting it into organisations immersed in traditional software development methodologies presents challenges because the two are conceptually opposite.

A rational, engineering-based approach has dominated the traditional software development environment which assumes that problems are fully specifiable and solutions are optimal and predictable. It is process-centric and focuses on variance-elimination through continually controlling and refining the process in a PDCA cycle. The waterfall or spiral lifecycle models are generally used which specify tasks and their outcomes. Communication occurs with the customer during the specification phase and through the formal specifications documentation.

Agile software development methods are people-centric which deal with unpredictability through short, iterative development cycles. Product features,

and delivery of sub-projects. Developers work in small teams and the customer is an active participant, therefore, communication is continuous through the evolutionary-delivery lifecycle. Formal documentation is discouraged (Nerur et al, 2005, Turner and Boehm, 2003).

These differences create organisational culture and management issues. Culture wields significant influence during decision-making and management strategies.

Traditional cultures provide clear policies and procedures within a production-line like environment. The roles of the stakeholders are defined and empowered by providing an operational comfort zone. Agile cultures, however, empower through the degree of freedom provided, in a classic craftsman environment, to define and complete work projects. Agile methods need a leadership-and-collaboration style of management to facilitate its dynamic features instead of the traditional style of command-and-control. Both traditional and agile development projects need their customer representative to be Collaborative, Representative, Authorised, Committed and Knowledgeable (CRACK) within their own organisation to enable the developers to deliver acceptable products (Nerur et al, 2005, Turner and Boehm, 2003).

Both approaches affect information security issues which is of special interest to this research. Traditional methods exploit a ‘plan-build-implement’ model whilst agile methods use a ‘speculate-collaborate-learn’ approach. Traditional approaches use the waterfall lifecycle model whose planning and design features promote security assurance and external security certification. However, the agile method feature of de-emphasising intense documentation is contrary to system certification (Beznosov and Kruchten, 2004). There are a variety of methods which address agile security assurance. FDD is an agile development approach that is used in a variety of agile security and assurance solutions and it is pertinent to briefly examine its approach.

4.5.4 Feature Driven Development

Feature Driven Development (FDD) is an agile software development method. It provides concrete modelling techniques and accepts the concept of software development as a people-centric process. FDD provides an agile and adaptive systems development approach. It focuses on the lifecycle phases of design and build and is cooperative across development activities whilst maintaining a

process-model independence. It is an iterative development approach which uses industry best practices. Quality is continually emphasised through frequent deliverables and accurate monitoring (Beznosov and Kruchten, 2004, Gotterbarn, 2004, Siponen, Baskerville and Kuivalainen, 2005, Nerur et al, 2005, Highsmith, 2002, Palmer and Felsing, 2002).

Figure 4.2 - Design and Build by Feature Phases Source Abrahamsson et al (2003)

Feature Driven Development comprises processes which are both sequential and iterative as illustrated in Figure 4.2. Its sequential processes are used during the system design and implementation while its iterative processes support agile development through rapidly adapting to changing business needs. The five processes of FDD are (Palmer and Felsing, 2002):

• Develop an overall model during which the overall system scope and context is established and decomposed into object models. These are continuously reviewed and refined;

• Build a features list during which a comprehensive list of features is constructed using the domain object models;

Design by Feature/Build

By Feature iteration Group of

Features Feature

Set

Design Design

Inspection

Coding Unit Testing Integration

Code Inspection Main Build

• Plan by feature during which a high-level plan is developed to sequence feature sets by their priority and dependencies and which assigns their goals, schedules and deliverables;

• Design by feature during which the feature design packages are produced. It is an iterative process;

• Build by feature which entails coding the features, performing unit testing, integration and code inspection.

The Design and Build by Features phases are re-iterative and comprise the development engine room. A features list is built using the object models and documented requirements and includes client-valued functions or features for each domain area. Features are client-valuedand, in a business system, a feature maps to a step in an activity within a business process. The features list is reviewed by the system stakeholders for validity and completeness. Features are expressed in Client-valued terms, using the <action><result><object> syntax.

Their level of granularity is specified and they allow measurable, visible progress which improves project confidence and enables early feedback opportunities.

Examples are ‘RETRIEVE the BALANCE of an ACCOUNT’ and ‘VALIDATE the PASSWORD of a USER’ (Palmer and Felsing, 2002).

The FDD approach provides a resilient conceptual framework. The iterative and self-organised Design and Build by Feature phases provide an agile operational environment that is adaptable (Palmer and Felsing, 2002). The best practices that comprise FDD are not original but, it is claimed, their specific combination makes the FDD processes unique. Each practice complements and reinforces the others.

These practices comply with FDD development rules, however, their use is based on the experience of the development team (Palmer and Felsing, 2002). The benefits of FDD and its place within the current milieu of agile methods are relevant to this research.

4.5.5 Relevance of Feature Driven Development

Feature Driven Development is considered by many practitioners to be the epitome of agile software development methods because it meets many of the specified agile criteria. It is highly iterative and co-operative, delivering frequent and quantifiable results together with accurate progress reports. It is considered to

be a people-centric approach whilst remaining documentation-light. It is seen as flexible to changing business needs (Palmer and Felsing, 2002). It is used as a basis for a variety of security solutions because it provides the means to integrate security features into the agile development process (Siponen et al, 2005). Its applicability is further examined in the research solution presented in Chapter Five.

The FDD approach emphasises quality from two interrelated aspects. Internal quality from the system viewpoint of the developer, and external quality from the system viewpoint of the user. Its incremental approach emphasises the role of internal quality. The design must be sufficiently strong to accommodate any extended functionality without needing rework. The short cycle time and early testing of features together with monitoring and metrics tools are methods used by FDD to enhance quality throughout the development process (Palmer and Felsing, 2002).