Guidelines to support choice of development methodology · Pravin Duggal Guidelines to support...

Pravin Duggal Guidelines to support choice of development methodology

The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others.

I understand that failure to attribute material which is obtained from another source may be considered as plagiarism.

(Signature of student)__________________________

1

Guidelines to support choice of development methodology

Pravin DuggalInformation Systems BSc

Session (2005/2006)


Summary

The aim of this project is to investigate what factors should be considered when deciding

what development methodology to use if any to support development of a particular project.

The project will investigate the different types of development methodologies in existence

and look to see how they are used in practice. It will look at why they are needed and what

influences have shaped their development through the years if any. This will be done through

extensive background literature research. The report will then aim to draw what conclusions if

any can be made from this research into development methodologies. A case study will then

be introduced to see if these conclusions drawn from the literature and prior research are

actually true for real life projects. The main question that will then be asked is why some

development methodologies are chosen over others and what factors influence these

decisions.

The project will seek to draw answers to this question from both the literature and case study

material. A set of guidelines will then be created to help assist in the selection of which

development methodology to use if any for a particular project.

2


Acknowledgements

I would like to thank Julika Matravers my supervisor throughout the project for all the

help and advice she has given me.

I would also like to thank Practiv and everyone who helped me there, in particular

Wai Lok who provided much of the material used in the case study.

3


Table of Contents

SummaryAcknowledgements

1. Chapter One: Introduction 11.1 The problem 11.2 Project aim 11.3 Objectives 11.4 Minimum requirements 11.5 Further enhancements 21.6 Methodology 21.7 Project Schedule 31.8 Project outline 3

2. Chapter two: Background 52.1 Information Systems and Methodologies 52.2 Pre methodology era 52.3 Structured methodologies 62.3.1 Systems Development Life Cycle (SDLC) 62.3.2 Waterfall model 62.3.3 Advantages 72.3.4 Disadvantages 82.4 Evolutionary development 92.4.1 Prototyping and Iterative development 92.4.2 Other evolutionary ideas 92.4.3 Advantages 102.4.4 Disadvantages 112.5 The need for an agile approach 122.6 Agile Development 122.6.1 Rational Unified Process 132.6.2 Extreme Programming 142.7 Human factors 14

3. Chapter three: Background literature analysis 163.1 Structured approach analysis 163.2 Evolutionary approach analysis 173.3 Agile approach analysis 183.4 Human factors analysis 193.5 Overall conclusions and predictions 20

4. Chapter four: Case study 214.1 Purpose of case study 214.2 Introduction to external company for case study 214.3 Practiv’s development approach 224.4 Previous Practiv reports 254.5 Case study example reports to be analysed 264.6 Staff questionnaire 26

5. Chapter five: Review of case study 29

4


5.1 Previous projects 295.1.1 Project 1 295.1.2 Project 2 315.2 Staff questionnaire results analysis 33

6. Chapter six: Guidelines 366.1 Outline of guidelines 366.2 What are the guidelines suitable for 386.3 How do they work in practice 396.4 Evaluation of guidelines 406.5 How can they be refined 40

7. Chapter seven: Conclusions 427.1 Conclusion 42

8. Chapter eight: Evaluation 448.1 Evaluation criteria outline 448.2 Evaluation of criteria 44

Bibliography 47

Appendix A 50Appendix B: Project schedule 52Appendix C: Staff questionnaire results 53Appendix D: Case study example projects 60

5


Chapter 1: Introduction

1.1 The Problem

Information systems are taking on ever increasing importance for today’s businesses and

organisations. They are increasingly becoming reliant on their use in order for them to

provide services and operate. With the use of information systems ever growing there is

therefore increasing pressure on the organisations which build them to ensure they develop

them correctly first time around. In order to ensure they do this most system builders will use

a development methodology to ensure the system is built correctly. At present there are a

wide range of development methodologies in existence and the problem that faces developers

is how they decide which methodology to use if any.

1.2 Project Aim

The aim of this project is to investigate what factors should be considered when deciding


1.3 Objectives

The objectives of the project are to:

• Examine a range of IS development methodologies in terms of their characteristics,

benefits and drawbacks.

• Identify why methodologies are used to support development

• Examine how changing needs and recent developments in technology have

influenced the way development is carried out.

• Gather research on the development approach used by the case study

• Propose own initial guidelines to assist in the selection of which development

methodology to use for a particular project

1.4 Minimum Requirements

The minimum requirements are:

• Exploration of a range of current existing development methodologies

• Exploration of recent trends associated with modern day development

• Gather date from external company used for case study to show why particular

development approaches are chosen

6


• Proposal of guidelines to help assist in the selection of which IS development

methodology to use.

1.5 Further Enhancements

Additional deliverables if time permits:

• Enhancements that could be made to further develop the proposed guidelines

• Find a further case study in order to apply guidelines

1.6 Methodology

The main methodology used for the background literature chapter is the gathering,

understanding, analysis and presentation of source material. This will be carried out by the

literature searching of journals, books, reports and periodicals contained both in the library

and on the internet.

As an external case study is being used for the project then it is important that a data

gathering technique is used in order to gather all the material required for the project. I have

selected the SQUIRO method as it is most suited to a research project. This method includes

sample documents, questionnaires, interviews, research and observation. [7]

Before commencing work on the actual project it is important that the work is well planned

and thought out prior to the commencement of it therefore a methodology will be used to help

with this.

As the sole deliverable for this project is the report it made sense to use a structured

methodology that would allow me to work through the project in a series of stages. Two

methodologies have been identified that could be used for this; they are the Rational Unified

Process (RUP) [22] and the Systems Development Lifecycle (SDLC). [6] Both of these

methodologies work by breaking down the project into individual cycles or phases which can

then be worked through in order. Both of these approaches will however need to be modified

as their stages don’t directly translate into the steps I will be taking to complete the project. I

have decided to use the SDLC as I feel that the stages that make up this approach are more

suited to the steps I will be taking to complete the project.

Avison and Shah (2003) [6] identify the 6 stages of the SDLC as:

7


• Feasibility study

• System investigation

• System analysis

• System design

• Implementation

• Review and maintenance

The advantages of this approach centre on being able to analyse and evaluate each phase

individually before progressing onto the next. Another key advantage is that a timescale can

be placed on each phase making it easier to construct a project schedule. [4]

The above phases will however need to be adapted to suit this project. The first phase will

comprise of identifying the problem, aims and objectives. Following on from this the system

investigation will be comprised of the background literature review and also the data gathered

from the case study. The analysis of this relates to what conclusions can be drawn from that

data with the actual design of the system comprising of the guidelines that will be created

from all the prior work. The implementation translates into how the guidelines can be tested

and analysed in practice. The final stage of this is review and maintenance which will

comprise of the projects conclusion and evaluation. So although the stages in the SDLC are

different to the stages that will comprise this project they can be modified to fit it as

demonstrated above.

1.7 Project Schedule

This is contained in appendix B.

1.8 Project Outline

The project will seek to understand what information systems and methodologies are and why

they are required. A range of current IS development methodologies will be explored to

determine their characteristics, strengths and weaknesses. This information will be examined

to see what conclusions if any can be drawn from this. Following on from this an external

company will be used as the focus of a case study The case study will be examined to identify

their own development approach and also examples of projects will be used which will enable

me to see why particular methodologies may be used for certain projects. This will be

particularly in relation to e – commerce development as the case study being used will be an e

– commerce development company. Other research will be carried out in the form of a

8


questionnaire to staff members working at the case study. From the data obtained through

this, the project examples and the background literature conclusions can be drawn. These

conclusions will help me to construct a set of guidelines to assist in the selection of a

methodology for a particular project. These guidelines can then be examined and following

on from this will be a conclusion and evaluation of the project.

The purpose of this project is to satisfy the aims, objective and minimum requirements of the

project. These are being carried out because to my knowledge there isn’t another report which

is setting out what I am trying to achieve in the same way as me.

The report will be comprised of 8 chapters with the first being this chapter.

Chapter 2 will be a background literature chapter to help with the understanding of what a

development methodology is and why they are used. A range of current development

methodologies will be explored to determine their characteristics, strengths and weaknesses.

Chapter 3 will examine the information from the previous chapter to see what conclusions can

be drawn from it.

Chapter 4 will introduce the company being used for the case study. It will detail the purpose

of the case study and why this company is suitable for the project. Their preferred

development approach will be explained and examples of previous projects will be detailed.

Following on from this the staff questionnaire will be introduced which will detail not only

the questionnaire but the purpose of it and the strengths and limitations of it.

Chapter 5 will be a review of the case study material. Examples of real life projects provided

by the case study will be presented as well as which development methodology was selected

for the project and the reasons why. These reasons will be examined to see what conclusions

can be drawn from them. The second part of the chapter will focus on the answers to the

questionnaire and will analyse the results to see what can be drawn from them.

Chapter 6 will contain the actual presentation of the guidelines to assist the selection of which

approach to use. They will be explained and the inclusion of each point will be justified. The

second part of the chapter will focus on the analysis of them and will detail what the

guidelines are actually suitable for as well as examining how they work in practice. The

chapter will finish with an evaluation of the guidelines and how they could be refined in the

future.

9


Chapter 7 will be a conclusion for the whole project.

Chapter 8 will be an evaluation of the project. The evaluation criteria will be identified and

then evaluated against.

10


Chapter2: Background

2.1 Information Systems and Methodologies

Information systems are commonplace in all businesses throughout the world. Avison and

Shah (1997) define an information system as “the effective design, delivery, use and impact

of information technology in organisations and society” [4]. All organizations have

information systems of some form or another whether it be a large scale conglomerate or a

charity. Avison and Fitzgerald (2003) say “An information system in an organization provides

processes and information useful to its members” [6].

This encompasses a wide variety of systems and ranges from general everyday systems

that are used in most organizations such as payroll or invoicing systems, to multi million

pound information systems tailored specifically for organizations such as an airline ticket

reservation system [14].

Avison and Shah (1997) define a methodology as “a collection of procedures, techniques,

tools and documentation aids which will help systems developers in their efforts to produce a

new information system, It will consist of phases, themselves consisting of sub phases, which

will guide the systems developers in their choice of the techniques that might be appropriate

at each stage of the project and also help them plan, manage, control and evaluate information

systems projects. A methodology represents a way to develop information systems

systematically” [4].

Although each methodology is different in the processes and techniques used, often the main

differences are more fundamental than this. Some methodologies will emphasise the human

aspects of IS development while others will concentrate on the technical aspects of

development. Essentially, however, most methodologies are similar and many of the

techniques used in one methodology are likely to used in other methodologies. Avison and

Shah (1997) define a technique as “a way of doing a particular activity in the systems

development process and any particular methodology may recommend techniques to carry out

many of these activities” [4].

Broadly speaking methodologies usually fall into one of three main categories. These are

structured, evolutionary and agile.

2.2 Pre methodology era

In the 1960’s and 1970’s computer applications were being developed and implemented

without the use of any formal development methodology. Developers usually concentrated on

11


the technical aspects of the problem rather than the business and organizational aspects in

which the systems were implemented. This brought about the problem the actual designs of

the systems didn’t meet the needs and requirements of the users properly. Programmers often

didn’t integrate as a team and their approach was individualistic. This resulted in poor

management, communication and control of projects. This also meant that often the emphasis

was on maintaining existing systems rather than developing totally new systems and

responding to the changing needs and requirements of system users. It was these limitations

that eventually led to a new more disciplined approach to developing information systems.

The end result of this was the first development methodologies which were based on the

systems development life cycle (SDLC) [5].

2.3 Structured Methodologies

2.3.1 Systems development life cycle (SDLC)

The development of an individual information system involves a number of phases which are

often collectively referred to as the information systems development life cycle

It is the overall process of developing information systems through a multi step process from

investigation of initial requirements through analysis, design, implementation and

maintenance.

The most commonly used example of the systems development life cycle is the Waterfall

model [8]

2.3.2 Waterfall Model

The Waterfall model is often considered as a classic approach to systems development and is

one of the most widely known development approaches.

The Waterfall approach outlines the series of steps that should occur when building a system.

It divides the development process up into a series of manageable parts. These parts are

organised in a sequential way going downwards like a Waterfall hence the name. The steps

usually occur in a pre defined order with a review at the end of each stage before the next can

be started [7] [8] [14]

A typical representation of the Waterfall approach is provided below.

12


Fig 1.1 Diagram showing a typical representation of the Waterfall model and its stages [34]

Although this diagram is a typical representation of the Waterfall approach the number of

stages in the model often differs depending on either what the model is being used for and

also depending on the users of it. A further key difference that should be noted is in the

intended meanings of each of the stages. Often the different stages may have the same names

but the intended meaning of the stages are different or different things may be encompassed

in the stages. [8]

Although the Waterfall model is one of the most classic approaches, there are still many

advantages as well as disadvantages. These are summarised below.

2.3.3 Advantages:

As the model is split up into several clearly defined phases this immediately provides an

advantage when it comes to identifying problems. For instance if a problem is identified in

the requirements or specification phase then it is more economical to fix it in terms of money,

time and effort at that stage then it is later on in the process. [26]

The initial design and requirements contain an abstract of the complete system. This provides

the advantage that any changes can be analysed to see what effect if any they may have on the

whole system. This may be useful for example if someone wanted to change something in the

database, all the components of the system that rely on the database can be checked to see

what the potential effects may be. [26]

13


Although the early work may be time consuming, the Waterfall model should produce a

highly detailed design if followed through properly. This should mean that later on in the

project when it comes for various parts of it to be integrated then in theory it should result in

less problems. [5]

The use of this approach can also be time saving for the organisations that the project is being

developed for. This is down to the clear rigid structure of the approach. Rather than having

people involved throughout the whole project they only need to be involved during the initial

planning stage and then again once the programming has been completed. This is particularly

beneficial to small medium enterprises (SME) whose time is likely to be limited and this will

allow them to make best use of the time they have available for the project. [8]

A further advantage of using this approach as opposed to something like an Iterative

approach is that if the project is abandoned for one reason or another then there will be some

form of documentation which can be saved even if the project is halted in its very early

stages. If a different approach is used, it may mean that the documentation is created as the

project progresses rather than in a set order, if the project is then abandoned then there wont

be much in the way of documentation which could be used in the future if the project was to

start up again. This is effectively a waste of time, resources and money if this occurs. [9]

2.3.4 Disadvantages:

Although the rigid structural nature of the model can provide advantages it can also work the

other way. The main example of this would be that real projects will rarely follow the

sequential flow that the model proposes. This is often because the correct information or

people might not be available to follow the stages through in order. [8]

Often at the beginning of a project the requirements and specifications aren’t fully known and

there is often a great deal of uncertainty about them. This makes it difficult to specify the

correct criteria and details; the model doesn’t accompany this very well. [5]

Using this model could lead to a loss of knowledge once the project goes into its

programming stage. This is because it is likely that the analysts and architects who design the

system will not be the ones programming it. When paper documents are passed across to the

programmers it is inevitable that there may be a loss of information as it is difficult to

communicate everything fully through documentation alone. [23]

14


A further drawback of the model is that if there is a poor design then this may not be realised

until much later on in the project, possibly only in the final stages. This could result in months

of work being undone and the costs to amend this in terms of both money and resources could

be huge. [26]

2.4 Evolutionary Development

The problems associated with the Waterfall model led to the demand of a different approach

to development. People wanted a way of developing systems which would be faster, require

less up front information and offer increased flexibility. One of the main reasons for this was

because it is often difficult to identify all the requirements at the start of a project, but in most

cases they will know what functions they wish to address with the system while they may not

necessarily know the features or capabilities of it. This approach takes this into account and

provides results without requiring detailed information upfront. Instead of following phases

through in a sequential order and ensuring each phase is completed fully before moving onto

another phase such as in structured development, evolutionary development takes a rather

different approach. [5] [9]

2.4.1 Prototyping and Iterative development

Iterative development and Prototyping are essentially similar. Iterative development has

evolved from Prototyping. They share many of the same characteristics and the benefits and

drawbacks of the two approaches are also similar.

This approach works on the basis of continuous development from the start with the end

result being a series of working iterations of the system which can then be improved upon

until the project is complete. It is a very fast approach to development and as such the initial

planning is only likely to consist of a broad outline of the business objectives and a rough

framework for the overall project components. [9] [20]

Projects are broken up into small parts which can then be worked on continuously. This

approach means that results will be available to see much earlier on in the project as the end

result will be a working prototype or iteration. Each part of iteration of the project can in itself

be run as a mini Waterfall model and this approach will results in a series of working

prototypes or iterations. The purpose of these iterations is in order to test various aspects of

the design, demonstrate features and ideas and also to gather feedback. The feedback that is

then generated will influence the way the next stages of the project are developed and helps to

reduce further design flaws. Often when feedback is given on a particular iteration or

prototype and a lot of refining is required the code is discarded and new code is generated in

15


order to satisfy the feedback given on previous incarnations. This is a very fast approach to

development and as such the initial planning [20]

2.4.2 Other evolutionary ideas

Although the two approaches summarised above are the main ideas behind this approach it is

worth mentioning that they are not the sole ideas behind this approach. Other ideas include

Rapid Application Development (RAD) which works in small tightly knit teams where the

main idea is to get short iterations out as quickly as possible, often this can mean that this

approach compromises in the issues of usability, features and/or execution speed. Another

important idea is Joint Application Development (JAD). This method instead focuses on

bringing together all parties early on in the project into a series of focused workshops to

identify the requirements before then carrying it on as a series of short iterations. [35]

The main advantages and disadvantages of this approach are summarised below.

2.4.3 Advantages:

This method helps to reduce development time and costs. This is because feedback is given

on each new iteration so any changes to the design can be quickly carried out. This saves both

money and time in the long run.

An early working prototype is usually available very early on in the project life cycle. This

means feedback can be provided on an actual working system which is much better in

practical terms than giving feedback on paper documentation. This will also result in a greater

level of communication between the developers and users of the system, which should help to

produce a system that accurately reflects the user’s needs and ensures that changing

requirements are incorporated into the design. [9]

As new iterations are being continuously developed then it should make it easier to spot any

design flaws earlier on in the process. Once they are spotted early they can be corrected

before they have an affect on other areas of the project and also long before the project goes

into the testing phase.

This development approach tends to use the same team throughout so any changes that are

required from the feedback given on previous iterations will be carries out by themselves.

This will mean that there is little knowledge loss over the whole project as the team will all be

working together from start to finish. An added benefit of this is that it reduces the time spent

working on paper documentation which would have been required in order to prepare others

16


for working on a different phase. This will allow them to spend more time planning and

working on the programming of the project. [26]

As the same people are going to be working on the project from beginning to end then they

know that all the early work they do will affect the successful completion of the project. This

should increase productivity as the team will have a sense of ownership over the final version

of the product, likewise it should increase their motivation. [26]

This method should in theory result in higher user satisfaction due to the system being

tailored to suit them using the feedback that was provided on previous prototypes. It should

also facilitate the implementation of the system because users know what to expect from the

prototypes they have seen previously and also because they know the feedback they have

been giving the developers will be taken into account for future builds of the system. [20]

2.4.4 Disadvantages:

A lot of the time when managers see a prototype they often find it difficult to understand that

it isn’t a finished version and that a finished version may in fact not actually be available for a

long time. [9]

It can often lead to a poorly designed system. This is because of the way this approach works,

it relies on rapid development based on feedback from system users. This can often make the

system suffer due to the rapid development because less attention is being placed on ensuring

that all parts of the system will integrate fully when the project is finished. [26]

Often designers of the systems pay too much attention to the design of the interface without

fully capturing the requirements and needs of the business. [9]

If the project is being worked on across a range of geographical areas then it can be difficult

to ensure that everything integrates properly together. Co-ordinating a large distributed

project is made even more difficult by the lack of planning documents [6]

As this approach relies on rapid feedback changes are constantly being made to the project in

order to react to changing needs and requirements. There are often no formal deadlines to

implement these changes and new features so it is important that the project leader monitors

them closely otherwise the project will constantly be evolving and there may never be a fully

finished project to deploy. [26]

17


As this approach revolves around constant change and evolution of the various phases it can

be difficult to say exactly what can be accomplished within a certain timescale, this is simply

because the features change depending on the feedback given [9] [26]

There isn’t much in the way of documentation for this approach. If a project is shelved or

stopped halfway through then there won’t be much documentation to go on if the project is

started up again. The lack of documentation may also show if for instance new people join the

team halfway through the projects development. [26]

2.5 The need for an agile approach

The use of an agile approach to development has been increasing in recent years. This has

been particularly true for e-commerce development. One of the main reasons behind this

change has been because in previous times developers had more time to get things right. This

is not the case in the present time. Information systems are becoming more important for

organisations. The role they plan in organisations is also changing. Traditionally they were

used for specific background tasks and if the system failed then humans could be used instead

albeit less efficiently. Nowadays most organisations entire operations depend on them. They

are what their customers use to interact with the organisation and without them they can’t

operate. It is these things that have influenced the changing nature of methodologies away

from the traditional structured approach. An example that illustrates the radical shift away

from traditional development is Web 2.0. This is a relatively new way of development and it

mainly works in an ad hoc way whereby functions are added to a system to see how users

respond to them, if it’s positive they will stay and if it’s a negative reaction they will simply

be removed from the system. [19] [36]

As the nature of E – Commerce is rapidly changing and becoming more entwined with the

World Wide Web then it is important to have a development approach that is more applicable

for this. This is why an agile approach is particularly suited to e – commerce development

because it can take into account the constant changing needs and requirements that are

associated with e – commerce development today. A traditional structured approach doesn’t

allow for updates to the needs and requirements in such a flexible way as an agile

development approach does so therefore it isn’t particularly well suited to rapidly evolving e

– commerce projects. [17]

2.6 Agile Development

18


Agile development isn’t encompassed by one single methodology in such a way that the two

previous approaches were. Instead there are a range of common characteristics which help us

to understanding what agile development actually is. [37]

In the late 1990’s there was a range of methodologies which were slowly becoming more

prominent. They all had a variety of ideas some old and some new. They did however all

share some similar characteristics and it was this that led to the creation of agile development.

In 2001 various practitioners and originators of these methodologies came together for a

conference in America to discuss what their ideas had in common. The eventual result of this

conference was that something called the “Manifesto for Agile Software Development” was

created which was the first official coining of the term agile. The most important part of this

was a statement of shared values of characteristics of agile development. [37]

The first of these is close collaboration the development team and business experts and

organisation the project is being developed for. The second involves having working software

which is frequently delivered in cycles so it is possible to see early deployments of the system

rather than simply starting out with extensive documentation. The third main characteristic

involves being able to respond to change quickly and not allow any changes to have a

detrimental affect on the project. The last main principle involves ensuring that the projects

are built around motivated individuals who should receive all the support they require and

then be left alone to ensure the project is completed. [37]

2.6,1 Rational Unified Process

A popular agile approach to development is the Rational Unified (RUP). [1]

RUP is an agile software development process created by Rational Software Corporation

which is now owned by IBM. Krucheten (2002) says that RUP is “a software engineering

process aimed at guiding software development organisations in their endeavours”.

RUP is a process framework which can be adapted and customised to suit the needs of the

organisation which is adopting it. It is designed so companies can either use it straight out of

the box or but it can also be easily modified to accommodate specific needs or requirements

of the organisation. The RUP process breaks down the project into individual cycles and then

further breaks these down into phases. This helps to plan and coordinate development. RUP

normally consists of four phases. [2] [22]

19


The first phase is the inception phase where the idea starts. Here the developers define the

scope of the project and construct a business case. Often this phase is repeated in order to

ensure that the business case meets the requirements and needs of the organisation fully. [21]

[22]

The second phase is the elaboration phase. In this phase the developers will analyse the

projects requirements in further detail. The main architecture of the system will also be

designed in this phase. This is really the last phase where the project can be cancelled or

redesigned. After this point cancelling or changing the system becomes high risk and

expensive in terms of both resources and money. [21] [22]

The third phase is the construction phase whereby the building of the system takes place. That

majority of the coding is completed in this phase and it is also the first phase whereby at least

part of the working system is made available. [21] [22]

The fourth and final phase is the transition phase. This is where the transfer of the system to

the end users takes place. Often end users are encouraged to test the system to ensure it meets

all the necessary requirements. [21] [22]

The designing coding and testing in each phase will be followed through in an iterative

manner.

The Main benefits of RUP are that it is based on best practices which have been taken from

many years of experience on projects. This means that it has successfully been implemented

by many organisations in many domains. [23]

2.6.2 Extreme Programming (XP)

This approach has probably garnered the most interest of any of the agile approaches so far

and is also one of the most widely used. [15]

The author of XP Kent Beck states that “XP is a lightweight methodology for small to

medium sized teams developing software in the face of vague or rapidly changing

requirements”. In simple terms XP is a set or values, rights and best practices that support

each other in incrementally developing software. [19]

Although this gives us a broad explanation of what XP is it doesn’t give us any details of the

best practices that define XP itself. Highsmith (2002) says “XP is defined at least in part by

20


its 12 practices: the planning, game, small releases, metaphor, simple design, refactoring, test-

first development, pair programming, collective ownership, continuous integration, 40 hour

week, on site customer and coding standards”. [19]

The main core features which XP emphasises are communication, simplicity and feedback.

These are shown in the best practices above. Not all the best practices however relate to this

and many may even sound foreign. It is however a combination of all these best practices that

provide the main benefit of using it and demonstrates why it has now become so popular.

[11]

2.7 Human Factors

Although it is important in itself to choose the right development approach there are also

human factors which need to be taken into consideration. Human factors can be though of as

people issues which impact the use and implementation of development approaches. [27]

Firstly there is the organisation itself and the culture that shapes it. Many development

approaches are increasingly moving away from central management control and are moving

towards greater collaboration instead. Many project managers may be unwilling to relinquish

the control they previously had which can influence the choice of development approach

used. This is best demonstrated in agile methods which rely on a tight knit team to operate so

a controlling leader would not fit in with an agile approach. [18] [27]

There are also people issues which need to be considered. Most approaches are characterized

by good communication and collaboration between workers. This is perhaps the most critical

factor for adopting a successful approach. Nehur et al (2005) emphasise this and say “For

programmers accustomed to solitary activities or working with relatively homogenous groups

of analysts and designers, the ideas of shared learning, reflection workshops, pair

programming and collaborative decision making maybe overwhelming”. This shows the

importance of having the right staff for the approach. It is also one of the most critical success

factors for agile development, without the right people to suit them, they simply won’t work.

In addition to this many approaches require customers who will participate in the project

themselves as often close consultation is required between the development team and the

customer. [11] [18] [27]

Using anything other than a structured model will also change the whole development process

and relies on people who are willing and able to follow a process where the future is often

uncertain. Nehur et al (2003) say “One of the biggest barriers to migration is the change in a

21


process model from a life cycle model to one that supports feature based development using

evolutionary and iterative development”. This king of change radically alters existing work

practices and tools and completely changes the development process and some people may

not feel comfortable with this. [11] [18] [25] [27]

22


Chapter 3: Background literature analysis

The background literature presented in the previous chapter explored a range of development

methodologies, their characteristics, strengths and weaknesses. From looking at these it is

clear that each approach is unique and therefore some approaches are better suited to some

development projects than others.

3.1 Structured approach analysis

Although in recent years there has been a growing shift away from the more traditional

structured development approach approaches such as the Waterfall model, they still hold

relevance in modern day development.

They still hold relevance in modern day development because they offer an alternative to

other approaches. There are two main features of this approach which are not used in either

evolution or agile development approaches. The first of these is that they rely on extensive

and detailed planning being used at the start of the project. The second feature is that

development is done in a series of pre determined phases with a review at the end of each

phase before moving onto the next one. The main difference between this and other

approaches is that it doesn’t work on iterations and therefore embrace change, it relies on the

requirements to be clearly defined at the start of the project in order for the approach to be

successfully implemented into a project. These features of the approach make it more suitable

for large scale projects where the functions and requirements are clearly defined at the start of

the project. It is suited to projects like this because with large scale projects it is likely they

will have a bigger development team and this approach supports that. Secondly if the

functions and requirements are clearly defined then the rest of the project can be planned out

and developed through the use of phases which structured approaches support.

This type of approach however isn’t particularly suited for development projects such as those

of e – commerce or other projects where the requirements are liable to change frequently.

This is because the major strength of this approach is the detailed planning that is carried out

at the beginning of the project which allows the rest of it to be developed through the use of

several pre defined phases. If the requirements aren’t clearly defined then the rest of the

project can’t be planned at the beginning and the benefits of the approach are then not being

utilised so it makes little sense to carry on using it. The effect of changing requirements on a

project using a structured development approach are likely to include a longer development

time and higher costs in terms of both resources and money. This is because if they

requirements change for instance mid way into the project then the developers will need to go

23


back to the beginning phase in order to update the documentation, this will take up more

resources and increase the costs of development for the project.

3.2 Evolutionary approach analysis

Evolutionary development approaches were created primarily to deal with the shortfalls of the

structured development approaches and represent how the changing needs and developments

in technology have influenced the way development is carried out. This is because the nature

of development is changing, it is no longer possible for many organisations to determine their

requirements up front so a more flexible approach was required which is how the origins of

evolutionary development started.

.

The main defining characteristic of evolutionary development approaches identified in the

previous chapter was that the project is being continuously developed in the form of iterations

or prototypes of the system. This makes it ideally suited to development projects where the

requirements are liable to change such as e – commerce and web development projects.

The use of development in iterations lends itself to supporting e – commerce and web

development because the requirements for these projects are often uncertain and susceptible

to change. The requirements of these types of systems are often liable to change because they

are not usually being developed solely for the organisation but for use by the end user.

Therefore it is vital that changing requirements are quickly responded to but the developers

also need to ensure that the system has a high degree of usability in order for the end user to

be satisfied with it. The use of iterations helps with both of these points as feedback is

generated from each iteration which then influences the development of future iterations and

so forth.

Although this type of approach is ideally suited to e – commerce and web development for

the reasons outlined above caution does still need to be taken. This is for two main reasons.

Firstly it is important to gain the right kind of feedback and pick the most suitable beta group

for the testing of each iteration. Poor quality feedback can lead to the code being scrapped

altogether and started again which is likely to hinder the deployment of the project. In the

worst case scenario a rival may be able to steal a competitive edge and offer a particular

function before anyone else does. The second element of caution that needs to be taken relates

to the final integration of the system. Many of the iterations are likely to be worked on and

developed independently of each other and the integration may not always be a smooth

transition. This is likely to hinder the deployment of the system and is most likely to occur in

24


a system where there are a large number of functions which have frequently changed

throughout the project.

If these drawbacks are likely to occur in the project then it begs the question of whether the

correct development approach has been chosen and these issues need to be considered before

deciding on which development methodology to use. If they are likely to seriously affect the

success of the project then it may be that a different development approach should be

considered altogether which either directly addresses these drawbacks or takes a new

approach to them. One such type of development that will take a new approach to the project

is agile development.

3.3 Agile approach analysis

Agile development methods are relatively new in development terms and offer an alternative

to structured and evolutionary development approaches. They have come about because of

recent trends in modern day development and the need for an alternative approach to be

available. Although they are similar and share many of the same traits as evolutionary

approaches there are two key characteristics which differentiate agile methods from

evolutionary methods. The first of these is the emphasis on close collaboration between the

client and development team while the second of these is related to the make up of the team

which is based around having highly motivated individuals who can be left to get on with

their work.

These two key differences and particularly the first one are vital to the success of a project

where the requirements frequently changes. Close collaboration should ensure that both the

quality of feedback is improved as the well as the ability to use that feedback to influence

future iterations and therefore benefit the development of the project. This addresses the

potential shortfall associated with evolutionary development of receiving poor feedback but

doesn’t necessarily address the problem of system integration. The only type of approach that

does this is a structured approach but then that doesn’t provide the benefits of the other

approaches and further demonstrates the importance of choosing the right approach for the

project.

Agile approaches also embrace change and attempt to do this without it have a detrimental

affect on the overall quality of the project. This make them ideally suited to e – commerce

and web development projects where the requirements often change but evolutionary

approaches also offer this. The difference being with agile methods that close collaboration is

used in conjunction with the willingness to be adaptable and open to changing requirements.

25


So although both approaches embrace change agile approaches also have provisions to ensure

good communication is kept between the client and development team which should also lead

to little or no knowledge loss between team members. All of this is likely to mean that agile

approaches are not only able to respond more quickly to change but there is also a higher

chance of getting these changes right due to the emphasis on close collaboration and

maintaining good communication links. This is less likely to be true for evolutionary

development approaches.

From looking at these benefits it is clear that agile development approaches would suit the

development of both e – commerce and web systems developments. They may even be more

suitable for web systems development which is more likely to have requirements that change

more frequently than those of e – commerce systems because the changes will often relate to

rapidly moving technology and response to changing market conditions. The close

collaboration will also ensure that the usability of the system is high which is particularly

important if they are being developed for the end user, new functions may be added quicker

as well. This is because agile methods often have daily meeting between the client and

development team whereas evolutionary approaches may only have these meetings once a

week so therefore won’t be updated as often leading to a slower development time for new

functions. Drawbacks of this however are that agile approaches often work with small teams

of 10 or less people and the lack of documentation is often a concern for some organisations.

Therefore the selection of which development approach to use needs to be given close

consideration as although it may seem suitable in some respects if the drawbacks are likely to

have a major affect on the success of the project then it may be more beneficial to choose a

different type of approach and this is the problem that is facing developers.

3.4 Human factors analysis

The human factors should certainly not be underestimated when deciding on which

development approach to use.

Each of the three types of development approaches which have been identified have their own

characteristics, strengths and weaknesses which lend them to be more suitable for some times

of systems development than others. Human factors will however still play crucial roles in the

selection of a development approach because although the approach may have the features

required for the project they still need a development team to implement them. The benefits

and features of each approach can only be fully realised if they correct team are chosen to

implement it. For instance if an agile approach is being used there will be close collaboration

between the development team and client occurring frequently, it is therefore important that

26


the people who will be in collaboration with the client have good personal and

communication skills otherwise the advantages gained from close collaboration will be lost

and may end up hindering the project. The reasons for selecting that approach may have

rested on that feature as well at the expense of other features so all the main reasons for

selecting that approach have been lost and the developer and client may feel they would have

been better off choosing a different approach altogether in the first place. Likewise with

structured approaches that require a lot of planning the development team may not be familiar

or used to doing it which will obviously affect the project overall. Things like this raise the

issue of how it could be to have staff who have prior experience with the approach or staff

who are willing to embrace change and learn new features.

From looking at the above it can be said therefore that it is important that these factors are

considered alongside the technical features of development approaches, only then should the

developers make a decision as to which approach to use.

3.5 Overall conclusions and predictions

From looking at the above it is clear that some approaches are better suited to some projects

than others. It can also be said that success is not solely down to choosing an approach that

fits the project, that approach need to be implemented successfully into the project and to do

this the correct development team needs to be chosen for the project.

As the project is mainly concentrating on e – commerce development it is expected that the

case study will have used either evolutionary or agile approaches to develop its projects. This

is because the company being used for the case study is primarily involved with the

development of e – commerce systems. As agile and evolutionary approaches have been

identified as being synonymous with this type of development it is expected that the company

will also use these approaches but is not guaranteed.

Although the literature that has been read for this project hasn’t really highlighted how

important human factors may be in deciding which approach to use, it is expected that the

importance of these will be highlighted in the case study. This is partly because it has been

shown and demonstrated above that technical features alone aren’t justification enough for

selecting a development approach but also because a questionnaire will be used to gather

information from developers at the case study. An opportunity will therefore be presented to

ask directly about how important these factors may be in deciding which development

approach is selected and it is expected that the importance of them will be confirmed inline

with the information gathered from the literature.

27


Chapter 4: Case Study

4.1 Purpose of case study

A case study will be used as a basis for part of this project. This is because it will give me a

real life example of how IS development methodologies are used in practice and in what

circumstances they are used. Without using a case study I will be unable to fulfil my aim and

objectives of the project, this is because the literature alone isn’t enough to come up with the

series of guidelines to support selection of a development methodology.

A case study is an in depth exploration of a certain situation or topic. It brings a great deal of

benefits with the main one being that the information gathered from the case study represents

information that is being used in a current existing situation. The main limitation of using a

case study is the lack of control of individual variables. You may find out that the information

you receive is not quite what you are expecting or looking for. This can have an effect that

aim and structure of the work may need to be adapted slightly in order to carry on with the

project. [39]

I am using an e-commerce systems development company as my case study for this project. I

believe this company is suitable to use for two reasons. Firstly because the company have

previously been involved in the development of numerous suitable e – commerce system

applications. The second reason is the size of the company. Although the company has offices

in both the UK and New Zealand the total number of staff is less than a hundred so the

company is still relatively small. This will mean that it will be easier to gather research and

information on their previous projects and then perform analysis on it.

4.2 Introduction to external company for case study

The name of the external company being used for the case study is Practiv.

They are a company which provides consultancy, marketing and application development

services to the insurance industry.

The company has its head office in the UK but also has a second development site located in

New Zealand and they also have an administration office located in Australia.

They are primarily an e-commerce systems development company but to complement this it

is important that they also offer a consultancy service to accompany their development. This

allows them to analyse the problem before proposing a solution. They specialise in the

28


insurance industry which makes them reasonably distinct in the sense that there are few

companies based in the UK at the present time which specialise in development for insurance

industry.

One aspect of the company that makes them suitable for this project is that they have multiple

clients who each have different needs and requirements. This means that each client is treated

differently and therefore a different approach is taken to development in order to adapt to the

requirements of a particular project. Different approaches are used for different clients

because each client will have a unique set of requirements which mean some approaches to

development may not be suitable for their needs. An example of this may be a project that can

only be done stage by stage which is likely to have an effect when choosing a development

approach whereas another project may not be reliant on prior work to be completed before

other work can take place so here a different approach is likely to be used. By seeing how

they approach development over different projects will enable me to have some real life

information about how they choose what approach to take. This will help me when I come to

propose my own guidelines to help assist in the choice of a development methodology for a

project.

They are also different in their development approach in that they use co – development so

projects are being worked on continuously around the clock. Projects can be developed and

worked on in the UK office and NZ office simultaneously and with the time difference means

round the clock development is possible. Due to this nature of development a greater

importance will be attached to the approach used for developing and building their projects.

This is almost a unique way of developing as very few companies practice this. It does

provide many benefits namely that the final product should be ready quicker but there are also

disadvantages to it as well. The main disadvantage is the time difference and the

communication problems that are associated with it. Although there is the co development

occurring on most Practiv project the NZ office doesn’t usually have interaction with the

clients as these are usually based in the UK. They will therefore use the same methodology to

develop their work that the UK office uses if they are working on the same project. [33]

4.3 Practiv’s development approach

Practiv try to select a development approach that they believe will be not only of most benefit

to the actual development of the system but also what will be of benefit to the organisation

involved. They try to use a framework which is tailored to the individual’s programme which

is based on three things. These are:

29


The clients existing standards and best practices

The teams skills mix and experiences

The client’s existing tools and environment

Although Practiv selects a development approach in accordance with the three things above,

there are several best practices which they believe are beneficial to adhere to when

developing projects and which they try to observe wherever possible. These best practices are

taken from the Extreme Programming, Rational Unified Process and Rapid Application

Development development approaches. Although their development isn’t only consigned to

using these three approaches these are the ones they have most experience and success of

developing with and have thus drawn what they feel are the best practices from each

approach. These best practices are shown in the table below.

Fig 3.1 Table showing Practiv’s preferred best practices [31]

Practiv define the objective of their development methodology where the goal is to” deliver

efficiently and effectively without sacrificing quality. Quality is defined as not only in terms

of the actual deliverables, but more importantly quality in terms of the final result which must

meet the programme original vision and goals and meets the user’s needs and expectations”.

[31]

30


They prefer to use an agile approach because they use iterations to develop the project.

Practiv believe that this is preferred to a structured approach because each iteration can be

repeatedly developed to ensure the requirements are mapped into the final system. A

comparison diagram showing how iterations can be used to integrate three requirements into a

system using agile approaches is provided below, the diagram also shows how these would be

integrated into a system using the Waterfall model and demonstrates the distinct advantage

and iterative led approach has over the Waterfall model in this respect. [31]

Fig 3.2 Diagram showing how requirements are developed into a system using both a

Waterfall and agile led approach

[31]

Practiv prefer to manger their projects wherever possible by aligning to something called

Prince2 which can be defined as a structured method for effective project management. An

example diagram of this is provided below.

31


Fig 3.3 Diagram showing the various phases involved in Pince2

[31]

4.4 Previous Practiv projects

Practiv although a relatively new company has successfully developed and deployed

numerous e-commerce applications. These have included systems for leading UK insurance

companies.

32


Examples of these systems include an extranet based system that will be part of a leading

insurance company’s website. The primary purpose of this system is to allow Independent

Financial Advisers (IFA) to submit new business and to provide Straight Through Processing

(STP) services online. IFA’s who are registered with SE as an agent will be able submit new

Protection business online and depending on the type of case, can get immediate decision and

policy cover. Internal Customer Service and Underwriting staff will use the system to support

the IFA’s and with manual underwriting respectively. [33]

They also developed a project called Columbus for Friends Provident who are a leading UK

insurance and pensions company. This was a project that automated the underwriting process

for life polices. It not only allowed more applications to be processed a day but also provided

a direct link to IFA’s who could then process the application electronically. Previously they

had to be entered manually and the average process time for this was 40 – 45 days. The

eventual outcome of the project was that underwriting average process times were reduced

and around 70% of them could now be dealt with in 48 hours with the majority of the rest

cleared within two weeks. [40]

4.5 Case study example projects to be analysed

I will be using two projects as the focus of the case study. The details of the projects are as

follows:

The first project is a product which is an intelligent application form builder and renderer. It is

designed for insurance product provider companies to construct electronic application forms

and distribute them easily and cost effectively. The intelligent form which is in XML format

contains validation rules and defined xml message format for electronic submission. The form

enables “white labelling” therefore different look and feel can be applied to the same

application form. It supports rapid change in a cost effective way. [29]

The second project is an e-commerce website developed for a client offering financial

information, product application and product servicing. The website will be interactive and

some of the individual features include being able to apply for new products which will

include having online application forms with rule validations and online submission. The

product servicing function will allow customers to check their investments, change address

and switch investment funds among other things. There will also be an online financial

calculator to calculate pension amounts, insurance requirements as well as the ability to offer

real fund time price information. Additional functions of the website will include the ability

to offer an online portfolio which the customer can use to keep track of their investment and

33


net wealth as well. Information on products, claim form and guides to other details such as

inheritance tax will also be provided. [30]

The two projects introduced above are both different in nature and I felt that it was important

to ensure that two markedly different projects were used. This is because even though the

development approach could be the same for each project there is at least going to be different

reasons for using that approach.

4.6 Staff questionnaire

A questionnaire has been chosen in order to investigate further the factors which impact on

the selection of which development approach to use for a project.

Using a questionnaire will enable me to ask direct questions about issues which have arisen

from all the prior research carried out to far on the project and to establish further criteria

which are considered important in the selection process of a development approach that may

not have been identified previously. For instance human factors were identified previously as

being important in the selection process and using a questionnaire will enable these to be

asked about these directly along with other issues that have arisen from the research carried

out on the project so far.

The use of a questionnaire was chosen over other data gathering methods such as interviews.

This is because although an interview would also give me the same information and perhaps

more as I could ask reflex questions to their answers they were not possible to conduct. This

was due to time constraints on the developers and also the location of their office which

would have required extensive travelling to reach. The time constraints on the developers is

also what stopped interviews from taking place on the phone. A questionnaire it was decided

could be distributed and then filled out in the developers own time. It was decided that to

ensure they were answered as quickly as possible a timeframe of one week was given to the

staff to complete them. This was agreed with the projects contact at the case study and he

agreed to ensure responsibility for their return in that timescale.

The questions that will be asked will be opinionated questions rather than factual ones. This is

because factual questions aren’t really appropriate for this task as I am trying to gain opinions

on their thoughts regarding a number of key issues which have been identified as crucial to

consider when selecting a development methodology. Having opinionated questions is also

likely to lead to a wider variety of answers and allows the developers to clearly express their

thoughts on the subject matter. The target group is the developers at the project and the

projects contact at the case study has also taken on the responsibility of ensuring that a variety

34


of developers with different roles and project experiences will be fill out the questionnaire in

order to gain as objective a view as possible.

Each of the questions have been designed so that direct thoughts can be given on a variety of

issues which have been identified as important to consider when choosing a development

approach. The first question enables thoughts on just how vital a methodology is to support

development which addresses the problem of whether they are required or not to support

project development. The second question asks about the human issues mentioned previously

which have been predicted to be more important than the literature showed. The third

question directly addresses the task and will lead to information that will be vital when

putting together the final guidelines. The final question is again related to human issues and

the developers own personal preferences as it is important to ensure the staff are willing to

work and motivated as this is one of the characteristics of agile development and all the

developers have used agile methods previously as this is the case studies preferred

development approach.

Limitations of the questionnaire include not getting a full response to the questions so little

conclusions can be drawn from them if that is the case. Also with a questionnaire that is filled

out in their own time there isn’t the capacity to ask reflex questions in response to their

answers.

An example questionnaire is included in appendix C along with the questionnaires that were

filled out and returned to me.

35


Chapter 5: - Review of case study

5.1 Previous projects

5.1.1 Project 1

The first project examined through the case study is the electronic application form builder

and renderer. An Extreme Programming (XP) and agile approach was chosen for the product

development. This methodology was chosen for the following reasons: [29]

• Team size – A small development team works well without the need for heavy

documentation

• Individual / team experiences – The development team consists of experienced

developers all of whom have used an XP approach to development in previous

projects.

• Stakeholder visibilities – The stakeholder has clear direct visibilities to the projects

progress and therefore reporting is frequent and without the need of documented

reports and formal measures

• Cost – XP and agile are more cost effective to implement. As this was an in house

project the budget was limited.

• The requirement to adopt for changes quickly makes XP and agile the preferred

methodology. They embrace changes rather than resist it.

• Release cycle – Testing and quality is a key part of the release cycle as patch releases

are costly. XP agile supports a test driven approach to development and continuous

integration.

• Requirements – Product ideas from sales don’t come in use cases. More often they

are discussed in “round tables” or “over a cup of coffee. Therefore a use case

approach is preferable.

• Resource management – XP and agile has a more flexible approach in resource

management which is better suited to the project.

There have been a total of eight reasons put forward in total as to why an XP agile approach

was taken to development for this project.

The first three factors which influenced the choice of development approach can be

considered as human factors. The size of the team was small which is often the case with

agile methods as they usually work with a small tightly knit team. Larger teams are usually

36


associated with structured approaches where more detailed documentation and planning is

required and often the project is larger overall. The next reason relates to previous staff

experience on working with that approach. This is important because XP is made up of

several best practices which some developers may not be familiar with, if this is the case then

they may not integrate well with a team who has previous experience of that approach. The

last human factor reason put forward is in relation to the organisation and their involvement in

the project. If an organisation would like to visibly see progress over documentation then this

will impact on the chosen approach as one must be chosen to satisfy the organisation and how

they would like to see project progress. This is a key point as the level of collaboration

particularly when requirements may change is vital to ensure the project is developed

smoothly. These three reasons demonstrate the importance of human factors and need to be

taken into consideration firstly before anything else. This is because it is crucial to see which

staff will be working on the project and also the level of experience they have with using that

approach. Without taking these into account first a development approach cannot be chosen.

The next reason relates to cost, this approach was considered more cost effective to

implement. This can be particularly true if the development team have previous experience

with this approach as no training is required, this was the case with this project.

The other reasons all relate to the best practices of the approach. The first of these is the

requirement to be adaptable and open to change. This is a key factor in all agile approaches

that they should embrace change. Without this the development time of the project is likely to

be significantly longer as any changes will mean that the project will need to go back to the

early planning stages. The next reason was the release cycle and how XP supports continuous

development and integration. This ensures that deploying problems later on in the project are

likely to be reduced. With an in house project where the budget is limited this is crucial in

order to ensure there are no integration or testing problems later on that can hinder

deployment of the project. In addition to this the requirements were coming from informal

discussions so it was important to capture them correctly. Requirements were mapped from

these into use cases which can then be used in the final build of the system. The final reason

was that XP has a flexible approach to resource management. This is required in conjunction

with being flexible to requirements otherwise poor management of both of these will result in

an inefficient use of resources that is not best equipped to deal with change.

Although these final reasons are important and demonstrate the importance of choosing an

approach whereby the features will be beneficial to the project they cannot be chosen before

the human factors have been taken into consideration. The right people need to be chosen that

37


are suitable to use these features. For example when capturing requirements through informal

discussions it is important that the development team are familiar with interacting with the

business people, some are better at this than others. If they aren’t used to this then they may

not fully capture the requirements as intended which will make the project suffer in the long

run. Likewise the development team needs to be one who are willing to embrace change and

strive towards other features such as continuous integration and a test driven approach. It is

therefore essential that consideration is given first to ensuring that the correct people are

chosen who are able to work with the other features of that approach.

The key practices followed by the development team were:

• Fine scale feedback – short daily meetings for communication and feedbacks, test

driven development, developers work in pairs to discuss ideas and solutions.

• Continuous process – continuous integration, continuous design improvement, small

iterations.

• Shared understanding – coding standard, shared ownerships

[29]

The key practices above illustrate in more detail how the development team worked on the

project. It illustrates how the interaction worked between the stakeholders and developers in

the form of daily progress meetings. This allowed a constant level of communication which

helped to support continuous integration and improvement. If constant communication isn’t

maintained then continuous improvements and iterations will suffer as they rely on rapid

feedback in order to progress. The shared understanding between developers will help with

integration due to having coding standards which each developer adheres to and makes it

simple to understand and interpret other team member’s work.

5.1.2 Project 2

The second project examined through the case study is the e – commerce website for a client

which offers various functions such financial information, product application and product

servicing. The Rational Unified Process was used to develop this project. The project

followed the four phases of the process and artefacts were produced in each of the four

phases. These are outlined below: [30]

• Inception – flexibility study, impact analysis, impact analysis, project plan

• Elaboration – use cases, wire frames,

38


• Construction – HTML click through, technical design documents

• Transition – training documentation when necessary

The four phases above were identified earlier on in the project and it is interesting to see how

they work in a real life example. The inception phase is where the project starts and the

activities above relate to that. All of them relate to the initial idea and contribute towards the

creation of a business case. The elaboration phase is where it was identified that the main

architecture of the system would be designed. This is the case with this project as the

requirements are mapped out in the form of use cases and wire frames which will be used to

construct the initial architecture of the system. The construction phase is where the system

building takes place and here this is translated into HTML click through which is the building

of the website. The final phase is transition and this was previously identified as the transfer

of the system to end users. Here this is shown that it takes place through training

documentation in order to make a smooth transition of the system to the end users. All these

phases may work a little differently in a real life project to how they work in theory but

nevertheless the idea behind each phase has remained the same as is shown in the phase

descriptions in this project.

The Rational Unified Process (RUP) was chosen to support development of this project for

the following reasons:

• The size of the team and heavy involvement of other individuals in the company that

are not necessarily part of the project team.

• Stakeholder interest of people who may not necessarily be directly involved in the

project. This process can provide clear visibility of project status to them.

• Due to the client’s organisation structure, a well established and broad industry

accepted methodology was required.

• Release cycle – iterative development was the key to the project. Ration Unified

Process (best practices) uses iterative and incremental development.

• Visually model – UML diagrams are used to communicate ideas. This is again a

Rational Unified Process best practice.

• Requirement control – The use of use cases is a good way of capturing user

requirements. Rational Unified Process supports the use of use cases and managing

requirement and change control.

• Standard template documents – Rational Unified Process has well defined template

documents to assist the team through development of the system.

39


[30]

Once again the first three reasons put forward for using the RUP to assist in the development

of this project are human factors. The first of these is the size of the team and individuals

being involved who aren’t part of the project team. As the RUP is a framework that can

simply be used out of the box this makes it easier for other people to become involved in the

project as there are no major learning difficulties associated due to it being designed for ease

of use so people can pick it up and start using it right away. The second reason is associated

with the first and as there are clearly defined phases in the RUP it makes using this approach

easier for stakeholders to get a clear view of the progress of the project by looking at the work

completed in each phase. The other reason relates directly to the client and their organisation

structure, they wanted an approach to be used that is widely accepted. Using something such

as the RUP which is industry accepted satisfied and would also satisfy them with regards to

visible project progress that they and other stakeholders required.

The other reasons for choosing the RUP are all directly related to the features of it. The

release cycle was done in iterations which was considered vital to the project, UML was used

which is an RUP best practice, the project used use cases and it also used the document

templates to assist the team all the way through the development of the project. The team for

this project wasn’t selected on the basis of their previous experience with the RUP and this is

shown in that it was selected partly because of the templates which are well defined enough

such that no previous experience with the approach is necessary.

The reasons above outline why the RUP was selected to assist in the project development.

The first three reasons are I believe the key points here that need to be considered first. Firstly

the organisation wanted an approach that was established and industry accepted. This needs to

be considered first and foremost above all the other points as the project is ultimately being

developed for the client. The other two reasons relate to other people becoming involved in

the project and being able to monitor project progress, these should also be considered before

individual features are. This is because if other people are becoming involved in the project or

need to see the project status then only certain approaches will allow people to do this who

don’t have prior development experience or experience with the RUP. After these have been

considered then the number of approaches that are suitable for use with the project will be

limited. It is at this point that other features such as the release cycle and requirements control

should be noted and an approach found which encompasses these practices.

5.2 Staff questionnaire results analysis

40


The five people who completed and returned the questionnaire had a variety of roles and

experience. There was a mixture of technical and managerial project development experience

while the experience levels varied considerably ranging from three years to 13 years

development experience and from working on only three projects to having worked on more

than twenty projects. The differing roles and levels of experience should mean that each of

them will have had different experiences of working with different development approaches

so each of their answers to the rest of the questionnaire will be influenced by different factors

and personal experiences.

The next question asked how much of an impact they thought the chosen methodology had on

a particular project. The response to this was varying but they did all agree that it has a

significant impact on the project. Most of them stressed however the importance of being able

to work successfully in collaboration with the organisation using the chosen development

approach. This was considered crucial to the success of a project, even more so than the

actual choice of methodology. Other factors given include level of staff and client experience

with the chosen approach, are the requirements clearly defined and geographical distribution

of the team. All of these factors however are not related to the characteristics of the approach

but instead look to ensure that the team and the client are able to work well together which is

felt has more impact on a project than actually choosing the correct approach.

Following this the next question asked whether the type of staff available has an impact on

the choice of development methodology for a particular project. Everybody agreed that it did

have an impact. The main issues put forward for this relate to previous staff experience and

willingness of staff to learn new approaches. These related particularly to agile methods such

as XP where it was felt that having at least one main developer who had used that approach

before was required in order to successfully use for a project. As many agile methods use best

practices which may sound foreign to some people having staff willing to learn new ideas is

crucial, without this the team may lost motivation.

The next question asked what they felt the most important factors were when selecting a

development methodology for a particular project. There were several points put forwards

with regards to this. Firstly the project delivery timescales were considered important along

with the number of people working on the project. In addition to this having clearly defined

requirements was put forward as a factor as for instance if they are clearly defined at the

beginning of a project then it may be more suited to a structured approach such as the

Waterfall model. The other reasons put forward were what the client would prefer to use and

work with, and are the staff able to implement and successfully develop a project using

41


certain approaches. Some of these factors link into the previous information given. For

instance here the preference of the client is mentioned and this is likely to be closely linked

with any previous experience with development methodologies. In addition to this previous

staff experience is likely to be linked to how successful the team may be at implementing and

developing projects with certain approaches. Whether the requirements are clearly defined

will influence the selection of methodology as well as some are suited for uncertain

requirements more so than other, this will also affect the impact a particular methodology

may have on a project.

The final question asked if they had any preference for any particular development

methodologies. The responses to this question were unanimous in that each person stated a

personal preference to work with agile development methodologies although their actual

reasons for this preference were different. These included finding them more interesting and

satisfying to work with, early releases, targeted feedback, increased collaboration which

results in reduced project risk as the organisation is kept in touch with what the development

team are doing. Personal preference because the individuals themselves prefer to work with

them is crucial here. If they enjoy working with them then this is likely to have an affect on

motivation levels and the success of the project overall. The preference for releasing the

project in cycles is a major feature of agile methods and this was as it keeps them more in

touch with the organisations needs and encourages close collaboration which was also stated

as a reason for their preference of agile methods.

The results of the questionnaire have raised many issues most of which weren’t related to the

technical aspects of development methodologies. Instead they highlighted the need to ensure

that staff with prior experience and knowledge of the approach are selected along with a team

and organisation who are able to work in a cohesive manner with the selected methodology.

The technical aspect issues that were raised included whether the requirements are clearly

defined at the start of the project and also the release cycle but this was closely linked with

personal preferences as most people stated that they preferred to work using regular releases

and close collaboration with the organisation. Although everybody stated a preference for

agile methods only two people actually stated that they preferred them over other approaches

so it may be that the others have no experience of developing projects with other approaches

but I have no way of determining this from my results.

Therefore from analysing the results it is clear that these developers all feel that the chosen

methodology has a significant impact on the success of a project but other factors also need to

be considered. These are the need to ensure the correct staff are selected which should bear in

mind their previous experience with the chosen approach and it should also be an approach

42


which the organisation are happy to work with as the success of a project depends heavily on

how the team and client work together. This is particularly true for agile methods where

communication is vital to the success of a project as they rely on rapid feedback to influence

their rapid release cycles. Although thought needs to go into the technical requirements of the

projects as with the real life projects examined above I feel that these should be considered

only after the human factors have been considered and this is supported by the results of my

case study where these factors were put forward as being more crucial to developing a

successful project than the actual choice of a development methodology itself.

43


Chapter 6: Guidelines

6.1 Outline of guidelines

The following points are what I consider to be the most important factors to take into account

when selecting a development methodology to assist with a project. The factors have been

compiled from both the review of the literature on the subject and also from the information

gathered from the company used for the external case study. Although information was used

from both these sources to construct these guidelines more weight has been given to the

information from the case study. This is because although the literature provides a valuable

and useful insight into the topic much of it was written several years back and may now be

outdated and also because it doesn’t always directly address the topic I am investigating. With

the case study the information was based on real life projects, individual experiences and

preferences and was directly related to my topic so I feel therefore that this information was

more relevant to the task I am focusing on.

• Previous staff experience with the approach

• Willingness of staff to use that approach

• Clients previous experience with that approach and personal preference

• Interaction between client and company

• Number of people working on the project

• Are the needs and requirements are clearly defined at the start of the project

• Are the characteristics of the approach needed for the project

• Will the characteristics of the approach be beneficial to the project

Previous staff experience is a crucial factor to consider when selecting the development

methodology, particularly so with many of the agile methods. This is because they often work

on best practices many of which may be unfamiliar to members of the team. If nobody has

used that approach before then the team will need to learn how it operates and this may affect

both the quality and delivery timescale of the project. The questionnaire results indicated that

at least one seed developer should have prior experience with that method in order to

effectively implement the approach. If at lease one team member has previous experience

then that can be passed across the team in order to help them familiarise with the chosen

methodology.

44


It is important to have staff that are willing to work with and use the chosen approach. This is

for several reasons. It is likely that most methods may have certain features which the

developers aren’t experienced with using so it is important that they are willing to both learn

and use any new features they may not have encountered before or the project may suffer.

Motivational levels will also be affected because willing staff are always likely to have more

motivation than unwilling staff who are resistant to developing with a certain approach. There

is no guarantee that a motivated team would be more likely to develop a successful project

but it will go a long way to helping towards it. The final reason for this is to do with

collaboration between the team and the client. Collaboration is increasingly becoming more

important especially so with evolutionary and agile development methods which use

collaboration to gather feedback on their iterations. Therefore it is important that the team are

willing to do this because it plays such a vital role in the project, they may also need to work

in collaboration with business people from their own organisation and some people are better

at this than others.

Some clients may have had previous experience with some approaches and this needs to be

taken into account. Their experience of this may have been good in which case they are likely

to be happy to use that approach again, if it has been a negative experience previously then

they may prefer not to use that approach again. They may also have a personal preference as

well as was the case in one of the case study project examples where the client wanted an

approach that was both broadly industry accepted and also one where they would be able to

get a clear indication of the projects progress.

As mentioned previously interaction between client and team is particularly important in

evolutionary and agile approaches. This needs to be reflected in the make up of the

development team as some people are better at communicating than others. As it is often used

to gain feedback on previous iterations which then influences further project development it is

vital that staff are used who are able to communicate and fully understand the needs of the

client. Some people are not well suited to this and therefore may not fully capture the

requirements which can hinder the projects development.

The number of people working on a project needs to be considered. Often agile methods work

in small tightly knit teams of 10 or less people and are more suited towards small teams and

lean development. If the team is small then there is likely to be little knowledge lost amongst

team members and this is a requirement if developing with iterations which require

information to be passed amongst team members to influence future developments. If the

project is large then naturally the project may need more people to work on it. Structured

45


methodologies for instance are best suited to larger projects where the requirements are

clearly defined. In a case like this it may be better to have a large development team working

on the project particularly if they are spread amongst several geographical locations.

Therefore it can be said that some approaches are better suited to larger teams and others

smaller teams so it is important to consider the number of staff that will comprise the

development team in order to select a method that best fits in with size of the team.

If the needs and requirements are clearly defined at the start of the project then clearly this

will have a major say in the selection of the approach. If they are stable and unlikely to

change then a structured approach may be considered the best way to proceed because the rest

of the project can then be planned out in advance. If they’re not clearly defined then an

approach will need to be used which has provisions for this, namely one which works in

iterations or release cycles which includes both agile and evolutionary approaches. This is

perhaps the main technical aspect of development as transferring the requirements into the

system will go a long way to ensuring the project is successful. Therefore is they are clearly

defined or not needs to be considered before an approach is chosen as some approaches are

best suited to defined requirements while others are more suitable for developing when the

requirements are uncertain.

There may be some characteristics of the chosen approach that aren’t required for the project

and if these are major features of the approach then serious consideration should go into

thinking whether or not the most suitable approach is being for the project. It is inevitable

perhaps that for instance if developing with XP which is comprised of 12 best practices then

not all of them may be required for the project. However if for instance a major feature of the

approach is not being utilised such as frequent release cycles or iterations and that is what

characterises that particular approach then it may be that the wrong approach has been

selected. An approach should be chosen because the main features of it will be required for

the project. This is illustrated in the case study example projects where the reasons for

selection in both projects included the main characteristics of them.

It is also important that the characteristics of the approach are beneficial to the project as a

whole. If they are providing little or no benefit then it may be an indication that the wrong

approach has been chosen. Just because they are being used it does not necessarily mean they

are providing a benefit to the project. As mentioned above its likely that not every

characteristic will be beneficial to the project but it’s important that the main ones are. This is

illustrated again in the projects examined in the case study where for instance the RUP was

chosen partly because it’s easy for the client to monitor project progress. This is a

46


characteristic of the RUP and it also showed it was beneficial to the project because it allowed

the client to easily monitor project progress which was a preference hat the client specified

before the project was started.

6.2 What are the guidelines suitable for?

The guidelines presented above are suitable for all types of development projects using all

types of development methodologies. They are however more suitable to assist in the

selection a development approach whereby the approaches being considered are either

evolutionary or agile. They are also more suited to projects which are related to e-commerce

development. This is because the project focused on e-commerce development and this was

reflected in the choice of the company to be used for the case study which was primarily an e

– commerce development company. Much of the information used to construct them was

taken from the questionnaire which was distributed to staff at the case study company and

their development experience has mostly been with evolutionary and agile approaches and e –

commerce development with only limited experience of other types of development. They can

also be deemed suitable for all types of developments and projects because research was

carried out into these earlier on in the project and this information also helped to form the

guidelines, it must also be said that of the two projects being used as examples in the case

study only one of them can be considered an e – commerce project.

6.3 How do they work in practice?

The only way I have of seeing how the guidelines work in practice is to apply them to the

projects that were examined previously in the case study material and look at the results.

The first project was the electronic and application form builder and renderer. An XP

approach was selected to help develop this project and several reasons were put forward as to

why this approach was selected.

The first three reasons put forward of team size, previous staff experience and client

preference are all points that I have included in my own guidelines. The next reason was to do

with cost and I didn’t include this as generally most projects are being developed for a client

who will be meeting the cost of the project, this was an exception as it was an in house

development project. Mention was also given as to the need to be flexible in the advent of

needing to adopt for changes and this is also included in my own points to consider. The other

reasons put forward were all related to individual features of the approach and why they were

needed. This is reflected in my own guidelines where I felt that it was important to ensure that

the main characteristics were both being utilised and beneficial to the project.

47


The second project was an e – commerce website. The RUP was chosen to help with the

development of this project. The first reason out forward was the size of the team which was

also put forward in the other project and this is included in my own points to consider. The

second reason related to stakeholder interest and the RUP being able to demonstrate to them a

clear idea of the projects progress. This isn’t directly included in my own points but this could

be considered as a characteristic of the approach which is being used and would therefore be

included in my own points. The third reason related to the clients own preferences and this

too has been included in my own point. All of the other reasons like the first project are all

related to the characteristics of the approach and the benefits they provide and this is included

in my own guidelines.

The application of my guidelines to the two projects above has shown that only one of the

reasons put forward over both projects wasn’t catered for in my own points. This was related

to the projects cost and the need to implement a cost effective approach and the reasons why

this wasn’t included are outlined above. Therefore from applying these guidelines to the two

projects above they have shown to be effective for at least these projects in assisting with the

selection process of choosing a development methodology for a particular project.

6.4 Evaluation of guidelines

Although the guidelines have successfully been applied to the projects above with positive

results they are not without their limitations.

Firstly although they were successfully applied to the above projects it was always likely that

this would be the case as much of the information provided about the selection process for

these projects was used in the creation of the guidelines. The projects that they were analysed

against only used agile approaches so there was no opportunity to test them against projects

that used other approaches so although theoretically they could be successfully applied there

is no guarantee of this. Only one case study was used so all the information has come from

one main source so what works for one company may not necessarily work for another.

There were also benefits to them namely that the material that was used to construct them had

come from examples of real life projects and personal staff experiences and thoughts. Having

information that has come from a first hand source such as this is invaluable as without it the

guidelines could only have been constructed from the literature that was available. Although

the literature presented me with plenty of material the main points would not have been

realised without the use of the case study. These were the human factors which the

48


importance of only became fully apparent when from looking at the real life project examples

and also the staff questionnaire results. The material supplied by the case study included two

types of projects so the information wasn’t solely limited to e – commerce projects which is

why it can be said that the guidelines are of at least partial use to non e – commerce

development projects. A further benefit

6.5 How can they be refined?

In order to further refine these guidelines in the future the following points should be taken

into account.

More than once case study will need to be used to ensure that the information gathered from

the case study is varied. This will mean that the information will have come from a variety of

different projects using varying approaches. The benefit of this is that the information gained

will be enriched and coming from several sources so therefore more conclusions can be

extracted from the information given.

The information that was gained from the questionnaires proved instrumental putting together

the list of points to consider. New ideas and issues were raised that hadn’t previously been

identified in the either the literature of example projects provided by the case study. This

included ideas such as individuals own personal preferences and the importance of the

development team and the client working together in a cohesive manner. Without using

questionnaires this information would not have been learned so proved an important tool in

the gathering of relevant information as it allowed for direct questions to be asked which may

not have been answered in prior research. In order to improve this more questionnaires should

be given out which would then likely lead to a greater variety of information being provided.

This would work well in conjunction with the first point as if more case studies are being

used then the opportunity to question more individuals in more companies will be presented.

In addition to this a second questionnaire could be provided to developers in order to gauge

reaction to the guidelines that have been created and also to fill out any gaps there may have

been in the research.

The final thing that I think would be beneficial in order to refine them would be to have the

guidelines applied to several real life projects in a variety of organisations. This would then

give a better measure of how applicable they are to all types of development projects and

approaches. If any critical factors arise which were not included in the original guidelines

then these could be added, likewise if any factors aren’t shown as being particularly relevant

in the selection process then these could be removed.

49


Chapter 7: Conclusions

7.1 Conclusion

In setting out to determine the major factors which influence the choice of which

development methodology to use for a particular project, it became clear from the literature

review that there is a void in this kind of information. To my knowledge nobody else has

previously set out to determine these factors and this is what has been attempted here.

It has become clear through this project that the major factors which have been identified that

influence the selection of a development approach for a particular project are not all related to

the technical aspects of development approaches as had been thought at the beginning of the

project. Much of the literature that was reviewed highlighted many of the technical aspects

associated with systems development methodologies but gave no real indication of just how

important the human factors associated with them are. The literature concentrated on the

features of each approach along with descriptions of their various strengths and weaknesses

but little information was available regarding their implementation into a successful project.

The information contained in the literature gave me a thorough understanding of the various

approaches but what I could draw from it was limited when related to what the project was

trying to achieve. I could determine the characteristics of each approach and relate that to

what types of projects they may be best suited to but could not determine exactly why that

approach may be selected for a particular project over other similar approaches. I therefore

had to make the conclusion in chapter 3 which would then give me something to test against.

The use of a case allowed me to examine these conclusions in further detail. Material was

supplied which outlined their preferred development approach and why and this gave me my

first insight into development in practice. Then further material was supplied which detailed

information on real life projects, what approach was used to develop them and why. In

addition to this a questionnaire was distributed to staff at the case study company which gave

me further information on my task, and also helped me to understand further the existing

information I already had by linking them together to produce my final guidelines.

It is clear from working on this project that there are many factors which influence the

decision of which development approach to use and some of these factors are more important

than others. The project has identified the major factors from both the literature and case

study material and both proved essential in being able to address and tackle the problem. The

major factors that have been identified have been presented as a series of guidelines in chapter

6 and represent the final part of the solution to the project. In this respect the major factors

50


have been identified however further work would still need to be completed in order to

develop these further. Identifying the main issues to consider is really just the start of the

problem, they need to be tested in real life example projects in order to understand just how

effective they are and what measures if any need to be taken in order to improve them.

Therefore it can be said that the main issues to consider when selecting which development

approach to use have been identified using all the material available and the project aim has

been satisfied, however further work could be carried out which would allow further

development of the guidelines which were presented in chapter 6.

51


Chapter 8: Evaluation

8.1 Evaluation criteria outline

This project is difficult to evaluate due to it being a dissertation as opposed to a project where

a system is built and tested. Another project or investigation that takes the same approach as

my own project has not been found which means it can’t be evaluated against other projects

of a similar nature. Therefore the evaluation criteria has been laid out is as follows:

• Have the minimum requirements proposed at the start of the project met.

• Were the objectives proposed at the start of the project met.

• Was the aim of the project met

• Was the project conducted out objectively without bias

• Could further enhancements be made to improve the project

• Was the project methodology and schedule followed

8.2 Evaluation of criteria

The minimum requirements that were laid down at the start of the project have all been met

and surpassed.

The first minimum requirement was the exploration of a range of current IS development

methodologies. This was met mainly through the background literature chapter which

gathered together a range of primary and secondary sources and explored the methodologies.

However in addition to this a wider context was given in that it was explained what they are

and why they are used and also how they are used to support development. Conclusions were

also drawn from the exploration of methodologies and suggested uses for them were also put

forward in chapter 3.

The second minimum requirement was an exploration of recent trends associated with

modern day development. This again was met through the background literature chapter. It

explained how the nature of projects has changed in recent times and also how this has come

about. Further to this an exploration of the approaches that have come about in response to

these trends and why. Details were also given on how these approaches were supportive to

some types of development which have been increasing in recent times such as e – commerce

and also why this type of developed has been increasing and taking on more growing

importance.

52


The third minimum requirement was to gather data from the external case study to show why

particular development approaches are chosen. This was done by examining examples of real

life projects used by the case study and the reasons why a particular development approach

was chosen to assist the project. A questionnaire was also conducted to learn developers at the

case studies thoughts on the major issues which had been identified as important to consider

when choosing a development approach. These issues had been identified previously from the

conclusions which had been drawn from the literature. In addition to this an explanation was

given as to why the case study was used, their preferred development approach and additional

information was presented for the real life project examples. This showed not only how a

methodology was used to support development but also key practices that were followed by

the development team.

The final minimum requirement was a proposal of guidelines to help assist in the selection of

which IS development methodology to use. This was done in chapter 6 and the presentation

of them also included an explanation of each guidelines as well as reasons as to why that

guideline was chosen. In addition to this there were sections which talked about what these

guidelines were suitable for, how they work in practice, how they could be refined as well as

an evaluation of them.

In addition to these minimum requirements further enhancements were proposed. These were

details on how the guidelines could be refined in the future and also to find an additional case

study to apply them to. Only the first of these was achieved and the possible refinements to

the guidelines are detailed in chapter 6.

I believe that the objectives that were laid out at the start of the project have been met. The

objectives all need to be completed in order to help me achieve the minimum requirements.

Each of these was met and exceeded by additional work being carried out to ensure that not

only the objective was achieved but also that further information was included so that

conclusions could be drawn from each objective. This is perhaps best illustrated by the third

objective which was to examine how changing needs and recent developments in technology

have influenced the way development is carried out. With this the objective was examined

and met by looking at how the nature of development has changed in recent years and why

and what development approaches were created in response to this. Conclusions were then

drawn to demonstrate how these approaches were more suited to some types of development

then others.

53


The aim of the project was to investigate what factors should be considered when deciding


This aim has been met as the final guidelines demonstrate the factors which have been

identified that need to be considered when deciding upon a development approach. It was also

satisfied in that it was determined early on in the project that a methodology was required due

to the benefits and assistance they provide in project development.

The project was conducted more or less objectively without bias. However in some cases bias

can be seen such as discussing the human factors and the role they play in the selection of a

development approach. Here although the literature didn’t identify them as being as important

as they turned out to be, I felt that they were and this bias was reflected in my choice of

questions for the questionnaire where I concentrated on these more than the technical aspects

of development. Reflecting back on this it is clear this bias didn’t have a detrimental affect on

the project as a whole as it turned out the bias was eventually justified as the human factors

turned out to be pivotal in the selection process fro a development methodology. I believe

however that all research projects need to have some bias involved in order to demonstrate

you understanding of some issues.

It is possible that further enhancements could be made to the project. Possible enhancements

that could be made to the final guidelines have already been presented in chapter 6 so there is

no need to discuss those again here but there are other things that could be done to enhance

the project. Firstly a second literature review could have been conducted to concentrate on

key points and ideas that had arisen as the result of the first literature review. This would have

given me a better idea then of key issues which could be checked against the material from

the case study. If this had been done then it may also have influenced my choice of questions

in the questionnaire as different key areas may have been identified to the ones that were in

this project, this would have been reflected in my choice of questions. In addition to a second

questionnaire could have been conducted in response to the answers given in the first one.

This would have allowed me to target key issues even further. Also another case study could

have been used at this point so that the guidelines were constructed from examples of several

real life projects. If all of this had been done then it would almost certainly have improved the

project and given me more information from which to construct my final guidelines with.

The project methodology which was settled on at the beginning of the project was the

Systems Development Life Cycle (SDLC), the various phases involved in this which were

presented in the introduction to the project were followed through in sequential order. The

initial project schedule contained in appendix B however did prove to be a little ambitious and

54


progress was hampered by having to wait for some information to come through from the

case study before I could proceed. However this is true to life for the SDLC as the delay of

one phase in it then causes a delay for the further phases and that proved to be that case in this

project.

55


Bibliography

[1] Abrahamsson P et al (2002) Agile software development methods: review and analysis, VTT publications

[2] Amber S, (2005), A managers introduction to the Rational Unified Process (RUP), Ambysoft

[3] Avgerou A and Cornford T. (1998) Developing Information Systems - concepts issues and practice. 2nd ed. Macmillan Press Ltd

[4] Avison and Shah. (1997) The information systems development life cycle, McGraw-Hill Book Company, Europe

[5] Avison D and Fitzgerald G, 'Where Now for Development Methodologies' ,Communications for the ACM, 46(1), Jan 2003

[6] Avison and Fitzgerald (2003) Information systems development – Methodologies, techniques and tools, 3rd ed. McGraw-Hill Education

[7] Bennet S et al (2002) Object-Orientated systems analysis and design using UML, 2nd edition, McGraw Hill

[8] Bocij P et al (2003) Business Information Systems – Technology, Development and Management for the e – business. 2nd ed. Prentice Hall

[9] Changeman S, Iterative development made easy, Corporate Consulting Services (2003)

[10] Cobham and Curtis (2005) Business information systems: analysis, design and practice, Addison-Wesley

[11] Cockburn A (2001), Agile software Development: Software through people, Addison Wesley

[12] Cusumano M and Selby R, How Microsoft builds software, Communications of the ACM 40(6), June 1997

[13] Fortune J and Peters G. (2005) Information Systems: Achieving success by avoiding failure, John Wiley and Sons Ltd, Europe

[14] Gough T G (1997) Notes on information system design, 2nd ed. School of Computing studies, Leeds University

[15] Grenning J (2002), Extreme Programming and Embedded software development

[16] Hidding G, Reinventing methodology: who needs it and why, Communications of the ACM, 40(11), November 1997 pp 102-109

56


[17[ Highsmith J and Cockburn A, Agile software development: The business of innovation. Computer Society, Sep 2001, pp 120-123

[18] Highsmith J and Cockburn A, Agile software development: The people factor Computer Society, Nov 2001, pp 131-133

[19] Highsmith J, What is agile software development, Crosstalk: The journal of defence software engineering, October 2002, pp 4-9

[20] Larman C (2003), Agile and iterative development, Addison Wesley

[21] Kroll, P. and Kruchten, P (2003), The Rational Unified Process Made Easy, A Practitioner’s Guide to the RUP. Addison Wesley

[22] Kruchten P (2001), What is the Rational Unified Process, Rational software, The Rational Edge

[23] Kruchten P, From Waterfall to Iterative Lifecycle – A tough transition for project managers, Rational Software White Paper, TP – 173 5/00

[24] Laudon K and Laudon J (2002) Management Information Systems – Managing the digital firm. 7th ed, Prentice Hall

[25] MacCormack A., Product-Development Practices That Work: How Internet Companies Build Software, MIT Sloan Management Review, 42 (2), Winter 2001, pp 75-84.

[26] Marks D, Development methodologies compared, N Cycles software solutions whitepaper, Dec 2002

[27] Nerur S, Mahapatra R. and Mangalara G., Challenges of Migrating To Agile Methodologies, Communications of the ACM, 48 (5), May 2005, pp 73-78.

[28] Olle T, et al (1988) Information Systems Methodologies: a framework for understanding, Addison Wesley publishing company

[29] Practiv – Case study 1

[30] Practiv – Case study 2

[31] Practiv – Development approach

[32] Shang S and Seddon P, Assessing and managing the benefits of enterprise systems: the business managers perspective, Info Systems Journal 12 2002, pp 271-299

[33] www.practiv.com(last accessed on 07/12/2005)

57

http://www.practiv.com/


[34] http://courses.cs.vt.edu/~cs3604/support/Writing/Waterfall.gif (last accessed on 23/02/05)

[35] Kettemborough C, What is Rapid Application Development (RAD), Casemaker Totem

[36] http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html What is web 2.0 (last accessed on 30/04/06)

[37] http://agilemanifesto.org/ Agile Manifesto (last accessed on 28/04/06)

[38] http://www-306.ibm.com/software/awdtools/rup/ IBM Rational Unified Process (last accessed on 22/04/06)

[39] Smithson and Cornford (2005) Project research in IS, Palgrave Macmillan

[40] http://www.practiv.com/pdf/friends_provident_case_study.pdf (last accessed on 20/04/06)

58

http://www.practiv.com/pdf/friends_provident_case_study.pdf

http://www-306.ibm.com/software/awdtools/rup/

http://agilemanifesto.org/

http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html What is web 2.0

http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html What is web 2.0

http://courses.cs.vt.edu/~cs3604/support/Writing/Waterfall.gif


Appendix A

When the projects were first being chosen back in September 2005 I decided that I wanted to

do a research project as I feel this is where my skills best lie and I also had a general interest

in the topics being covered as well, which had stemmed from the modules in the School of

Computing which covered this project.

I did however find the project very tough particularly in the early stages where a lot of general

planning and research was required. This was partly because I found it difficult to motivate

myself in the early stages of the project as the deadline was still some way away. However

that was not the only problem that I encountered early on in the project. The first problem was

settling on a methodology to use to plan and co ordinate the project. As I wasn’t building an

actual system I found it difficult to find one that was appropriate for the task I was addressing.

Even when I had settled on one I found it difficult to implement effectively into my project

and to follow it through. The end result of that was that I had a project schedule that I

couldn’t meet although there were other reasons for this as well namely that I had to wait on

information to come through from the case study before I could proceed. The second problem

I encountered early on was that the range of literature available to me on my chosen subject

was huge and the major problem then was sifting through it to find what was relevant to the

task and what wasn’t. I had to decide what I felt was most relevant to the project as the

background literature review formed the basis of the rest of my project, if this had been

poorly selected then it may have hindered the rest of the project. Those were the two main

problems I encountered. There were also other problems. As I was using an external case

study and the information they supplied me was crucial to the project progressing I found I

had to sometimes wait or was unable to get through to my contact at the company. This

proved to be particularly frustrating if I needed something clarifying. Another problem I

encountered although this was totally my own fault was that when writing the majority of the

project I didn’t source it as I went along which meant this had to be done at a later stage and

was particularly time consuming as I forgot which sources were used for which bit of the

project.

I have however improved my own personal skills from the project. I feel that particularly my

research and analytical skills have improved as these were required in order for me to decide

what and how my research was relevant to the project. My overall knowledge of the subject

area has also of course vastly improved due to working on the subject area for so many

months. My writing skills and level of vocabulary in the subject area have also improved.

59


There are some valuable lessons that can be learnt from this project. To start with I found the

project immensely difficult particularly at the start for the reasons outlined above. I would

recommend to anyone doing a project that they choose one where they already have an

interest in the subject like I did. This is because if I hadn’t had an interest in the subject area

already then the project would have become even more difficult. It was because I had an

interest in the subject area that I was able to get through most of the literature available

because I had an interest in reading it. Therefore if you choose a project because for instance

you think it is easy and have no real interest in it then you may find that you struggle in parts

because you have no interest in leading further about the subject matter. Also if anyone is

thinking of using a case study in their project then it is important to ensure it is one where

firstly you are certain that they will be able to provide you with the correct information

necessary for your project. Secondly it is vital to ensure that there are good communication

links between you and the case study as this hindered my project. Also it is vital to ensure that

the project is properly planned at the start and time isn’t underestimated that some tasks may

take to complete. I found this out the hard way with my project and left myself with less time

than I had planned for on some of the later stages.

So to summarise I would recommend having a vested interest in the project first, this will

help with motivation levels particularly if you find the going tough early on like I did. If a

case study is going to be used then make sure the correct choice is made for not only the

material they will supply you but also how you can communicate with the case study. It is no

good them having the information if you can’t get hold of them to get it. I would also

recommend ensuring the project is properly planned so you don’t run out of time as even once

the project is finished it can take several days to make adjustments. In relation to anyone

wishing to undertake a project similar in nature to this one I would recommend that they

firstly do all of the above and then look at how my final solution could be refined. This was

presented in chapter 6 and gives valuable information as to how this particular project could

be refined and further developed in the future.

Overall although I found the project extremely challenging I also found it enjoyable and

thoroughly enjoyed the experience.

60


Appendix B

Project Schedule

Task Estimate completion date Actual Completion dateIdentify aims and requirements

30/10/05 01/12/05

Decide on project methodology

05/12/05 25/01/06

Complete background literature work

05/12/05 18/02/06

Present background literature work

05/12/05 18/02/06

Background literature conclusions

15/01/06 18/02/06

Case study background info and reasons for selection

25/01/06 18/02/06

Details on case study’s preferred development approach

18/02/06 05/03/06

Details on real life projects from case study

19/03/05 08/04/06

Staff questionnaire results 07/04/06 10/04/06

Analysis of case study material

10/04/06 17/04/06

Guidelines 17/04/06 24/04/06Analysis of guidelines 20/04/06 26/04/06Project conclusion 27/04/06 28/04/06Project evaluation 29/04/06 30/04/06

As can be seen in the project schedule I fell behind early on the project and had to make up a lot of ground, I did this in the middle of February. After this work had been completed I was reliant on the material from the case study being available and I had to wait for this which then meant subsequently the rest of the project was delayed.

61


Appendix C

Staff Questionnaire results

Practiv Staff Questionnaire

Name: Nigel Collis

Role: Senior Product Consultant

Experience: 13 yearsNorth West Water ’93-’95 IT Trainee

Churchill Insurance ’95-’99 Printing System Team Lead/Support/EnhancementAccounts/Payments System Team Lead/Support/EnhancementHalifax Branding ProjectTele-Mandating ProjectVarious small enhancement projects

Sun Microsystems ’99–’04 Y2K Conversion Logistics Application web conversion (Lead)Part Planning tool performance optimisation (Lead)Logistics real-time monitoring application (Lead)

Practiv ’04–‘06HBOS In-Site ImplementationIn-Site product developments (Lead)Form development service (Lead)Framework For Application Development (Technical Lead)

How much of an impact do you think the chosen methodology has on a particular project?

The chosen methodology can have a significant impact on the cost and delivery timescales of a development project and on the ongoing support costs. In some circumstances it can have an impact on the success of a project, but that is more usually down to the people involved and the project management methodology.

Do you think the type of staff available has an impact on the choice of development methodology for a particular project?

The lead staff will decide the methodology for projects in companies where development processes are not tightly controlled. Some people are not well suited to using Agile or XP methodologies so if the appropriate and experienced staff are not available another more traditional methodology may be more suitable.

62


What do you think are the most important factors to consider when selecting a development methodology for a particular project?

CThe type of deliverable and the working environment.

A large multi-million pound project for a core system meant to latst a decade, with clearly defined requirements in a regimented working environment such as the civil service would suit a more traditional development methodology such as waterfall. A small or medium sized project for a web front end, with requirements which are not clear at the beginning, and constantly changing business needs would be more suited to agile techniques.

Are there any particular development methodologies that you prefer to use? if so please state why

My preferred method is Agile and even when working in projects which are more waterfall in nature I would use many of the techniques of an agile methodology such as test lead development and continuous builds.

Any other comments

63



Name: Stuart Barker

Role: Solution Architect

Experience: (Please state this in number of years and projects worked on)9 Years, 20+ Projects - varying sizes/value

How much of an impact do you think the chosen methodology has on a particular project?Significant.

Do you think the type of staff available has an impact on the choice of development methodology for a particular project?Yes.

What do you think are the most important factors to consider when selecting a development methodology for a particular project?Project Delivery Timescales.Number of people working on the project.Client requirements – e.g. Public Sector client may require more ceremony/documentation.

Are there any particular development methodologies that you prefer to use? if so please state whyI have found Agile Development practices the most interesting in recent years. Well conducted/disciplined projects utilising these techniques typically yield much higher productivity (e.g. Components completed faster, more robust code, cleaner logic implementations resulting in faster rate of change and easier maintenance). They’re also more satisfying, both from a developers viewpoint and client viewpoint – I’ve been fortunate to experience both.

Any other commentsAlistair Cockburn’s “Agile Software Development” is a very good book on the topic of software development methodologies and the factors to consider when designing/selecting methodologies.

64



Name: Ross Duncan

Role: Software Engineer, developer, sometimes team lead, sometimes Technical Project Manager

Experience: (Please state this in number of years and projects worked on)5 years, 6 Significant Projects

How much of an impact do you think the chosen methodology has on a particular project?Depends really on a few things:

• Maturity of the project (different methodologies have a different impact at different points in the project life)

• Level of staff experience with chosen methodology and willingness/ability to use it)

• Level of client experience with the chosen methodology and willingness to learn and to engage with development team through it

• Geographic and political distribution of the team members:o Are the developers and business people working for the same company

or different companies? o Are they located all in the same place, or are they split across different

sites and/or different time zones. o Will the developers and analysts have easy access to the business

people for gathering and refining requirements, feedback, etc• How clear is the vision that the client (business sponsor) has for project, future

software? Will they need a lot of help, and potentially take many iterations to establish the final requirements for the system, or can they clearly define these up front to the development team?

• Is the client looking to simply automate or replicate an existing business process, or are they looking to transform their business processes into something new and improved through the course of the project


Yes, particularly their :• Past experience• Willingness and ability to learn new methods• Willingness and ability to interface with non technical people (some

people are better suited to this than others)

65



1. Need to consider all of the above things with respect to the chosen methodology. Will using this methodology improve our chances of delivering this project on time and on budget?

2. Is experience with this methodology going to help you to deliver future projects of a similar and different nature better?


I am particularly interested in Agile methodologies as these focus on frequent and regular deliveries, resulting in frequent and well targeted feedback. Project risk is reduced for both the development team and the business as the business is never too far out of touch with what the development team are doing, and the developers cannot deviate too far from what is most important to the business. There is also a strong focus on producing artefacts that are of real value. By this I mean that the project team spends more of their time and effort producing and improving software rather than producing and trying in vain to maintain documents about the software, that may or may not have been written

Any other comments

Good luck, hope things are going well for you!

Ross

66



Name: Derek Troy-West

Role: Technical Project Manager

Experience: (Please state this in number of years and projects worked on)

6 years experience, 5 significant projects

How much of an impact do you think the chosen methodology has on a particular project?

While a methodology is important (iterative v waterfall for instance), what’s more important is the ability for both the client and the company to operate in a cohesive manner using that methodology.

Given an environment where both the client and company is experienced with a range of methodologies, choosing one over another could have a large impact on the project – and risk management.


Staff experience is absolutely key when choosing a methodology. Adopting a new one is a gradual process, cherry picking the flavour-of-the-month at mobilisation time will only fail. A successful consulting company must have a (or possible a number of) project templates that can be put into place depending on the nature of the engagement. These templates are a methodology that are refined over time – without such depth, any company is just flailing in the dark.


Is the methodology tried and tested? Does it come from a stable of project templates that have been successfully used previously. Are the staff capable of putting this methodology in to practice.

Most importantly – Does the methodology fit the engagements risk profile?


Agile methodologies are the flavour of the month. They rely hugely on inter-personal skills and a team which is very capable (both of which are lucky to have at BUPA). I’d love to be able to investigate further.

Any other comments

Hope things are going tickity-boo for you Pravin.

67



Name: Julian

Role: Project Manager

Experience: (Please state this in number of years and projects worked on)6 months tech lead18 months tech project manager at FP12 months business project manager / solution architect for BUPA

How much of an impact do you think the chosen methodology has on a particular project?Massive. But what’s bigger is how it fits with the engagement model and, as a part of that, client’s flexibility in engagement

Do you think the type of staff available has an impact on the choice of development methodology for a particular project?Yes. E.g. you can do XP and TDD more easily if you have at least one ‘seed’ developer who has previous experience with that approach.

What do you think are the most important factors to consider when selecting a development methodology for a particular project?What the client will be amenable to, the platform, developer profile and client interface points (are they developing? Etc)

Are there any particular development methodologies that you prefer to use? if so please state whyScrum, with XP (or other Agile method such as Crystal Clear). It delivers early visibility of ‘potentially shippable software’ and advocates clear communication across the disciplines.

Any other commentsTraining!

68


Appendix D

Practiv Case Study 1

69


Introduction

This case study looks at an in-house product development project by Practiv.The Product is an intelligent electronic application form builder and renderer. It is design for Insurance Product Provider companies to construct electronic application forms and distribute them easily and cost effectively. The intelligent form which is in XML format contains validation rules and defined xml message format for electronic submission. The form enable “white labelling” therefore different look and feel can be applied to the same application form. It supports rapid changes in a cost effective way.

Project Background

An opportunity to develop a product was identified following some market research. There were functionality gaps between user expectation and what was on offered in the market place. Practiv have decided to develop a product to fulfil this gap. To maximise return on investment Practiv must made its new product available in the market quickly and before any of the existing provider identify similar findings and enhance their product to meet the market demand.The product development that Practiv was about to embark consists with a suite of tool sets and must conform to a defined industrial standard. In addition further vendor specific enhance functionality must also be developed offering Unique Selling Points (USP).A Product Development Manager was appointed and given the responsibilities for planning, management, architecture and delivery. Two other highly experienced developers were recruited to form the three person product development team. A further Product consultant was also employed at later stage of the development.The sales and marketing team were engaged and created interest in the market place. The development team was given 2 months to develop the first of the four part toolset for trial integration with a client and demonstration.Further development for the remaining three parts of the toolset continued with pre-sales consultancy, client integration, post-sales consultancy and support & maintenance work running in parallel.

70


Project Challenges

Requirements

Requirements arrive to the development team at various stage of the release cycle with different priority. This made it very hard for planning and tracking progress. It was therefore necessary to sort requirements into one of the following four categories:

1 Planned activities – These activities that are well know ahead and must be completed according by a specific release. For example: Industry Standard Change Requests.

2 Unplanned activities – These activities that is not known before hand but are required from the next release. Such as client enhancement. Also will include some pre-sales activities.

3 Urgent activities – Such as urgent service releases and problem diagnosing. Also will include some pre-sales activities.

4 Off-the-shelve activities – These are small to medium tasks that doesn’t tie to any releases; often are low priority.

Functional Requirements

The functional requirements are in two folds. 1 To ensure that the product meets all functional standards defined

by the industry’s standard body. This is documented in a technical standard document.

2 To develop enhance functionalities identified as a result of market research, matching competitor offering or specific client request.

3 To provide immediate service releases for any defects.

Non-functional Requirements

Non-functional requirements including performance, scalabilities, compatibilities with other software are conducted in isolation with the client whenever possible. In some cases such as performance and compatibilities analysis are also conducted with the client in ad-hoc bases either as a product evaluation or problem diagnosing exercise.

Resources

Resource planning was challenging due to unpredictable activities. It is important that there are available resources available for unplanned and urgent activities at the same time to achieve maximum team utilisation. It was therefore important that individuals working in the team can perform a range of activities and willing to work in a dynamic environment.

Roles

• Product Development Manager – responsible for the delivery of the product, planning and day-to-day management. The individual was also involved in Sales and Marketing activities and development work. When necessary post-sales Consultant.

• 2 Senior Developers/Architect – responsible for the design and development of the product. When necessary client integration

71


• 1 Product Consultant (join in later stage) – responsible for client integration, post-sales consultancy and development.

Release Cycle

Standard product public release is scheduled half yearly. It includes functional and non-functional enhancements and any service releases. The team continues to work in fortnightly milestones and targets to ensure progress. As part of the Service Level Agreement (SLA) with the customer Practiv is committed to address issues raise within matter of days. Therefore unplanned service releases are also required.

Change Request

Change Requests can arrives from 4 sources.4 Industry Standard Body – Practiv is a member of the Standard

Working Group and therefore were actively involved in shaping the standard. Changes Requests from this source are normally well planed and agreed between all members.

5 Sales and Marketing Team – This could be performance analysis, sales meeting and additional functionality as part of the sales agreement.

6 Client Requests – This would mainly be be-spoke enhancements funded by the client.

7 Development team – Task such as Refactoring, continue technical improvement such as performance and scalabilities.

The Product team is consistently under pressure to meet the various Change Requests submitted from various sources. It is important that the different stakeholders with their independent and unrelated interests are satisfied.

Testing

Two parts of the toolset are design as an end-user product that will be installed and used by a large number of mobile user. It is therefore important that the product are fully tested in teams of its functionalities as well as it compatibilities with other software and Operation Systems. Service release and support calls can be very expensive for large group of mobile uses on uncontrolled laptops.

72


Development Process

Early Developments

During the early stage of the development project planning was very straight forward. There were little interferences as there was no establish client and no sales meetings. The main objective for the development team is to ensure the delivery of agreed functionalities within 2 months for the trial integration and demonstration. All process and measure were to prevent any risk of delay.Functionalities were solely orientated around the Industry Standard along with a few enhance function concluded by the market research. The development work was split up amongst the 3 member of the team working closely together with frequent discussion on design and ideas. Iterative development plan was agreed with fortnightly milestones. Light Project documentation and artefacts allows the team to concentrate on development and meeting the set milestones. There were no need for requirement documents and all information was set out in the Standard documentation. A simple check list of functional items with target days, estimates and developer’s name associated with it where sufficient to keep track on the project.

Follow on Developments

Follow on successful delivery and promising sales activities a client list is beginning to establish. Sales and Marketing activities were also in the up to generate more interest in the market place. Unplanned and urgent activities were becoming more frequent and unpredictable. They are causing a substantial impact to the normal development path. Functional items listed in the checklist and fortnightly milestones were frequently missed. Even with the aid of a project plan that is published to various stakeholders the development team still found it difficult to achieved the set out milestones while trying to met stakeholder expectations. The unpredictable nature and scales of these unplanned and urgent activities make project planning difficult. There is a dangerous or assign too little time for these unplanned and urgent activities casing a slip in targets or assign too much time for these activities resulting in lower utilisations. It was also extremely difficult to priority change request submitted to the development team. This is mainly due to the fact that the various stakeholder and isolated interest and don’t share common views.Although the method of development work conducted by the development has not changed but uncontrolled external factors is creating a impact of its effectiveness. It was obvious that further processes were necessary to maintain control and provide a better structure for the development team to work with. At the same time project team objective is no longer limited to meeting delivery. Further responsibilities such as providing licensee support, service release, documentations and product testing have also become a major focus. Requirement documents were also becoming necessary for client be-spoken enhancements.As well as defining the Requirement categories to help with planning changes to the development team has also adopted test driven development methodologies to minimise error and improve testing.

73


The check list and project plan previously developed is no longer flexible enough for the nature of the project at this stage. The induction of “off-the-shelve” activities allow for flexible planning for swapping out with unplanned and urgent activities. The basic principle is:

• Identified all planned activities that must go into the next release

• Estimate Maximum and Minimise unplanned and urgent activities required.

• Identified off-the-shelve activities

• Include all planned activities in the project plan, and then allocate the minimum unplanned and urgent activities in the planned. Finally allocate off-the-shelve activities that are no lesser then the difference between the Maximise and minimum unplanned and urgent activities.

By following the above principles appropriate resource can be allocated to ensure that all Planned activities gets completed and that if unplanned and urgent activities is not as demanding as expected then the developer can be working on the off-the-shelve activities. The key point in this plan is flexibilities. Allow the plan to change to handle foreseeable but un-estimate-able activities yet able to deliver full commitment and service level.Development documentation was still kept to its minimum. For example development team member is often sent to work closely with client onsite for be-spoken enhancement rather then in isolated offices relaying mainly on requirement documents, use case and activities flows. This type of collaborative working model with the client promotes ideas and understanding. It will also allow the client to see progress.

74


Software Methodology

A XP and Agile approached was chosen for the product development. This methodology was chosen for the following reasons:

8 The requirement to adopt for changes quickly makes XP and Agile the prefer methodology. The embrace changes rather then resist it.

9 Team size: a small development team works well without the need for heavy documentation.

10 Individual/team Experiences: The development team consists of experienced developer which all has used XP development in pass projects.

11 Stakeholder visibilities: The stakeholder has clear direct visibilities to the project’s progress and therefore reporting is frequent and without the need of documented reports and formal measures.

12 Cost: XP and Agile are more cost effective to implement. As a in-house project budget was limited.

13 Release Cycle: Testing and Quality is a key part of the release cycle as patch release are costly. XP Agile supports a test driven approach development and continuous integration.

14 Requirements: Product Ideas from Sales don’t comes in Use Case. More often they are discussed in “Round Tables” or “Over a cup of coffee”. Therefore Use Case approach is preferable.

15 Resource Management: Agile and XP has a more flexible approach in resource management which is better suited for the project.

16

The key practices followed by the development team are:• Fine scale feedback

• Short Daily Meeting for communications and feedbacks

• Test Driven Development

• Developer works in pair to discussed ideas and solution

• Continuous process

• Continuous Integration

• Continuous Design Improvement

• Small iteration

• Shared Understanding

• Coding Standard

• Shared Ownerships

• Requirement Management

• A Gate keeper to all incoming requirement allowing the development to focus on delivering the release

75


Outcome and Experiences

The product has been very successful and the team have leant valuable experience during the development. In the early stages of development although a project plan was in place but with the absents of the four activities categories the development team find themselves constantly working in unplanned and urgent activities being a backlog of planned activities and at causing mire unplanned and urgent tasks. With the introduction of the activities categories and new planning principle it becomes easier for resources and activities planning. The team could operate in a more controlled environment.The adoption of test driven development and continuous integration although required upfront investment but it ensure quality and reduce urgent activities. It offers massive long term benefits.It is important to knowledge that process must evolve with development reflecting project nature, risk, team structure/size/experiences and method of deliveries.

76


Appendix D

Practiv Case study 2

77


Introduction

This case study looks at a client eCommerce website development offering financial information, product application and product servicing.

Project Background

Practiv was appointed to development an eCommerce website for a financial client. The project consists of Business Team, Development Team, Testing Team, Configuration Management Team and Production Support Team.

• Business Team – Responsible for Requirement, Legislation, Marketing, Training and Program Planning (7 members)

• Development Team – Responsible for Development Planning, System Architecture and Design and Implementation (10 members)

• Testing Team – Responsible for Test Planning, Developing Test Cases and performing re (3 members)

• Configuration Management Team – Responsible for Maintaining Change Control Systems, Build and Deployment process. (group shared services)

• Production Support Team – Responsible for Disaster Recovery Planning, Service monitoring and services, Software and hardware upgrades and routine backups. (group shared services)

The project is planned with iterative development approach. With first release delivering majority of the fundamental functionalities and subsequent releases will further enhance the website.

78


Project Challenges

Requirements, Release Cycle, Change Request, Resources/cost, … etc

Requirements

Requirements are identifies with different priorities and target releases when entered in Configuration Management system:

• Do it now – Must be done now. This type of requirement could be patch releases to the Live system.

• Show Stopper – Must be completed for the next release.

• High

• Medium

• Low

Both functional and non-functional requirement are captured with in the detailed Requirements Document produced by the business. The document also includes Use Cases, Activity diagrams and Data flow diagrams.

Planning and Resources

Planning and originations is vital due to the scale of the project and the wide involvement both externally and internally of the client’s origination. Activities such as Marketing and Training heavily involves external parties are required to be planned ahead.Some services such as Configuration Management and Production Services are provided as shared services by the client origination and therefore their resource and services are required to be planned ahead.

Roles

There are large numbers of Roles and Responsibilities involves in a project of this scales. Below are lists of key Roles.

• Program Manager – Over all program management.

• Requirement Manager – Over see all requirements.

• Marketing Manager – Manages all marketing activities.

• Technical Project Manager – Over all technical responsibilities and planning.

• Testing manager – Responsible for all testing activities and plans.

• Configuration Manager – Ensuring required resources and support for configuration management is available and managed.

• Production Service Manager - Ensuring required Production Service resources and support for available and managed.

Release Cycle

The project uses a time-boxed approached development. Releases are scheduled for every 2 months.

79


Some legislation changes may require releases either to be created in between the normal release cycle or to extend the release cycle. Legislation changes are often well planned activities and therefore can be scheduled into plan appropriately.

Change Request

Change Request will either be created by the Business Team or by the Development team.

17 Business Team – These will normally be new functionalities, Legalisation changes or new default identified in pervious releases.

18 Development team – Task such as Refactoring, continue technical improvement such as performance and scalabilities.

Requirement tends to be very well controlled as it is filter by the Business Team and prioritised. Configuration Management System is used to ensure that all Change Request (CR) are tracked, assigned and monitored. CR life cycle is defined with well defined process for the transition between CR statuses. CR Life cycle includes:

• Entered – CR is created but not being assigned a resolver.

• Assigned – The CR is assigned to a resolver.

• Resolved – The work required for this CR is completed.

• Tested – The work completed is tested

• Concluded – The business is satisfied with the work and testing that is conducted.

• Rejected – The CR has been rejected because it is no longer required.

• Duplicate – The CR is a duplicate of an existing CR.

Testing

A separate test team is employed for both User Acceptance Testing and Regression Testing. The testing team will use requirement document produced bay the business to form the bases of their test cases. Testing are conducted both manually and automatically using script testing tools. All defects are recorded in the testing system with detail information of the fault. This is then tracked and resolved by the developer for retest. Daily meeting are setup to review testing progress and test results.

80


Development Process

The process developed for the project has been very stable since the beginning of the project. This is mainly because of little changes on how requirements are received and project release cycles. Requirements document is very much the beginning of the process. It is attached with the Change Request (CR). Further meetings will normally be set up between the developer and the business to resolve any ambiguities. The requirement will then be use for technical analysis and scoped.Resource and Planning meeting will then determine the target release date for the CR. Form here on Technical Design and Implementation will follow leading into testing and signoff. CR is normally kept with in the timeframe of the Release Cycle. Therefore most CR can be complete with in 2 months. This is aim to minimise parallel developments and avoid unnecessary complications.

Artefacts

Due to the scale of the project and the wide involvement across the origination and externally documentation becomes the main source of communication. Large effects are often spent to keep the document up to date.

• Plans

• Program Plan

• Business Stream Project Plan

• Marketing Stream Project Plan

• Technical Stream Project Plan

• Testing Plan

• Development

• Requirement Documents (inc Use Case)

• Flexibility Study

• Impact Analysis (When necessary)

• Wire Frames

• HTML Click Through

• Technical Design Document

Risks

Project of this scale require careful planning and coordination with various area of the business and external companies. Failing to plan and coordinate appropriately will result in unnecessary long delay and may have large impact to the project and business. It is therefore import that the process and methodologies used not only will ensure qualities deliveries but to also support coordinated planning.

81


Software Methodologies

The Rational Unified Process (http://www-306.ibm.com/software/rational/) was chosen for this development of this project. The project follows the four phases of the process and artefacts were produced in each of the four phases:

• Inception Phase

• Flexibility Study

• Impact Analysis

• Project Plan

• Elaboration Phase

• Use Cases

• Wire Frames

• Construction Phase

• HTML Click Through

• Technical Design Documents

• Transition Phase

• Training Documentation when necessary

RUP was chosen for the following reasons:19 The Size of the Team and heavy involvement of other individuals in

the company that is not necessary part of the project team.

20 Stakeholder interest but not necessary involved directly with the project. The process can provide clear visibility of project status.

21 Due to the Client’s organisation structure a well established and board industry acceptance methodologies was required.

22 Release Cycle: iterative development was the key to the project. RUP (best practices) uses iterative and incremental development.

23 Visually Model: UML diagram is used to communicate ideas. Again this is RUP best practices.

24 Requirement Control: The use of use cases is a good way of capturing user requirements. RUP supports the use of use cases and managing requirement and change control.

25 Standard Templates document. RUP has well defined templates document to assist the team.

26

82


Outcome and Experiences

With appropriate investment on Configuration Managements and a well defined Change Request process this project demonstrates how a larger scale project can still be very responsive to market changes and satisfying business requirements. Although a lot of effects and resource is required for planning and producing the various artefacts but it would be unthinkable to operate a project of this scale without them. Communication is the key of success and with many external and internal parties involved plans and documentation will avoid any misunderstanding. Streamline process should be allow for some CR when necessary to minimise overhead. The process and methodology need to be flexible enough to support this.

83


84


85


86


87


88


89


90


91


92


93

Guidelines to support choice of development methodology · Pravin Duggal Guidelines to support...

Documents

Transcript of Guidelines to support choice of development methodology · Pravin Duggal Guidelines to support...