Guidelines to support choice of development methodology. Pravin Duggal. Information Systems BSc Session (2005/2006)

Transcription

1 Guidelines to support choice of development methodology Pravin Duggal Information Systems BSc Session (2005/2006) 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

2 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

3 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

4 Table of Contents Summary Acknowledgements 1. Chapter One: Introduction The problem Project aim Objectives Minimum requirements Further enhancements Methodology Project Schedule Project outline 3 2. Chapter two: Background Information Systems and Methodologies Pre methodology era Structured methodologies Systems Development Life Cycle (SDLC) Waterfall model Advantages Disadvantages Evolutionary development Prototyping and Iterative development Other evolutionary ideas Advantages Disadvantages The need for an agile approach Agile Development Rational Unified Process Extreme Programming Human factors Chapter three: Background literature analysis Structured approach analysis Evolutionary approach analysis Agile approach analysis Human factors analysis Overall conclusions and predictions Chapter four: Case study Purpose of case study Introduction to external company for case study Practiv s development approach Previous Practiv reports Case study example reports to be analysed Staff questionnaire Chapter five: Review of case study 29 4

5 5.1 Previous projects Project Project Staff questionnaire results analysis Chapter six: Guidelines Outline of guidelines What are the guidelines suitable for How do they work in practice Evaluation of guidelines How can they be refined Chapter seven: Conclusions Conclusion Chapter eight: Evaluation Evaluation criteria outline Evaluation of criteria 44 Bibliography 47 Appendix A 50 Appendix B: Project schedule 52 Appendix C: Staff questionnaire results 53 Appendix D: Case study example projects 60 5

6 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

7 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

8 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

9 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

10 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

11 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

12 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 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] 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

13 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 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

14 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] 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

15 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] 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

16 order to satisfy the feedback given on previous incarnations. This is a very fast approach to development and as such the initial planning [20] 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 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

17 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] 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

18 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

19 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

20 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] 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

21 its 12 practices: the planning, game, small releases, metaphor, simple design, refactoring, testfirst 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

22 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

23 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

24 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

25 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

26 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

27 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