Post on 02-Apr-2018
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)
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
what development methodology to use if any to support development of a particular project.
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
Pravin Duggal Guidelines to support choice of development methodology
• 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
Pravin Duggal Guidelines to support choice of development methodology
• 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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
• 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
Pravin Duggal Guidelines to support choice of development methodology
[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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
The aim of the project was to investigate what factors should be considered when deciding
what development methodology to use if any to support development of a particular project.
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
[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
Pravin Duggal Guidelines to support choice of development methodology
[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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
Practiv Staff Questionnaire
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
Pravin Duggal Guidelines to support choice of development methodology
Practiv Staff Questionnaire
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
Do you think the type of staff available has an impact on the choice of development methodology for a particular 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
Pravin Duggal Guidelines to support choice of development methodology
What do you think are the most important factors to consider when selecting a development methodology for a particular project?
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?
Are there any particular development methodologies that you prefer to use? if so please state why
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
Pravin Duggal Guidelines to support choice of development methodology
Practiv Staff Questionnaire
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.
Do you think the type of staff available has an impact on the choice of development methodology for a particular project?
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.
What do you think are the most important factors to consider when selecting a development methodology for a particular project?
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?
Are there any particular development methodologies that you prefer to use? if so please state why
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
Pravin Duggal Guidelines to support choice of development methodology
Practiv Staff Questionnaire
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
Pravin Duggal Guidelines to support choice of development methodology
Appendix D
Practiv Case Study 1
69
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
• 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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
Appendix D
Practiv Case study 2
77
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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
Pravin Duggal Guidelines to support choice of development methodology
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