Selecting Software Development Methodology for DVLA
TABLE OF CONTENTS
1 INTRODUCTION ……………………………………………………………… 3
2 SOFTWARE DEVELOPMENT METHODOLOGIES …………………………. 3
2.1 Hard Methodologies ……………………………………………………. 4
2.1.1 SSADM/Waterfall Development Life Cycle …………………… 6
2.2 Soft Methodologies ……………………………………………………… 7
2.3 Hybrid (Socio-Technical) Methodologies ……………………………… 8
2.3.1 DSDM Development Cycle ……………………………………. 9
3 SELECTION OF METHODOLOGY …………………………………………. 10
3.1 Techniques for DVLA System …………………………………………. 13
3.1.1 Prototyping ……………………………………………………. 14
3.1.2 Time Boxing ……………………………………………………. 14
3.1.3 MoSCOW Rule ………………………………………………… 15
4 CONCLUSION ……………………………………………………………….. 16
References
1 INTRODUCTION
To provide stability, control and organization to a software development process, some sort of methodology needs to be adopted. It is recognised in the software development fraternity that a standard approach using proven analysis and design techniques improves the ‘quality’ of system. By methodology we mean a coherent and logical approach or process for undertaking particular types of tasks or solving particular problems. Methodologies are paradigms in action, which means that they are often based or inspired on a certain concept or set of ideas e.g. systems thinking, learning, participation. It is a series of predictable steps, a road map that helps u create a timely, high-quality result. It is chosen based on the nature of the project and application, and the controls and deliverables that are required. Each method address the generic phases that are required; the definition phase, the development phase and the maintenance phase (Pressman, 1997).
2 SOFTWARE DEVELOPMENT MTHODOLOGIES
Over the years, many different methodologies for information systems development have evolved. These are represented as the “methodology tree” in figure 1 and are broadly categorised as:
- Hard methodologies
- Soft methodologies
- Hybrid/Socio-technical Methodologies
- Specialised methodologies (Toole, 2006)
Since specialised methodologies such as Knowledge Acquisition and Documentation Structuring (KADS) are only applicable to the projects of specific nature such as developing expert systems etc., these will not be the focus of discussion in this report, rather the hard, soft and hybrid methodologies are discussed and evaluated for the proposed DVLA project. These are described below:
Source: Toole, 2006
Figure 1: The Methodology Three
2.1 Hard Methodologies
The failure of the systems and inefficiencies of the ‘ad-hoc’ methods (e.g. ‘code and fix’) used for the early IS development led to the adoption of more formal, systemic and efficient methods of systems development. Influenced by the methods adapted to develop complex machines in Second World War, these methodologies seek to develop high quality information systems by applying pure scientific and engineering principles. Due to their strict codes of practice, these are termed as ‘Hard Methodologies’. Almost all of these are derived from the ‘waterfall model’ of systems development. Here the ‘waterfall model’ and ‘hard methodologies’ are further explained using the example of one of such established methodologies, SSADM (Zieliński and Szmuc, 2006).
SSADM (Structured Systems Analysis and Design Methodology) is used in the analysis and design stages of systems development (Brough, 2002) and is an excellent example of the waterfall model of information systems engineering. It covers the Feasibility, Analysis and Design stages of the waterfall project lifecycle. The Waterfall model derives its name due to the cascading effect from one phase to the other as is illustrated in the Figure (2). Each phase in Water fall model has well defined starting and ending point, with identifiable deliveries to the next phase (Zieliński and Szmuc, 2006; Pressman, 1997).
Source: Zieliński and Szmuc (2006)
Figure 2: Different phases of Water Fall Model
2.1.1 SSADM/Waterfall Development Life Cycle
SSADM suggests the following phases for the development of information systems (Zieliński and Szmuc, 2006):
Requirements analysis: At this stage, the problem and constraints are specified along with the desired service objectives (goals) and final system specifications are produced and agreed upon.
System Design: The system specifications are translated into a software representation. This includes defining the data structures, system architecture, algorithmic detail and interface. The hardware requirements are also determined at this stage.
Implementation/Coding: The designs are translated into the software domain. Detailed documentation from the design phase can significantly reduce the coding effort.
Integration and System-Testing: All the program units are integrated and tested to ensure that the complete system meets the software requirements.
Maintenance: This is usually the longest stage of the software. In this phase the software is updated to meet the changing customer needs and hardware and software components are regularly serviced.
SSADM provides strict control of the development process where all activities are well defined, documented and controlled. Each phase has specific deliverables that mark the end of that phase and can be used to gauge quality standard required. Most UK government departments use SSADM. External contractors producing software for the government also have to use SSADM (Allen et al., 2004).
2.2 Soft Methodologies
Soft methodologies emphasise on social aspects of the software development project for example the Soft Systems Methodology (SSM) and ETHICS. In this section the example of SSM is used to further elaborate the soft methodologies.
The Soft Systems Methodology was developed in the 1960s by Peter Checkland at Lancaster University (Checkland, 1990). It is aimed at solving complex unstructured human problem situations based on holistic analysis and systems thinking. SSM is a participatory methodology that helps different stakeholders to understand each other’s perspectives. It has been used to facilitate change processes in many large private and public sector organizations (Travis, 1998). The SSM premise is that if people participate in the process of finding out about the problem situation and learning about ways to improve it, then they are more likely to understand the improvements being suggested, feel ownership of them and be committed to change.
The methodology is based on a seven-stage process (figure 3) that moves from clarifying an unstructured or messy problem situation through designing ideal or conceptual human activity systems that would help improve the situation (Checkland, 1990). These conceptual models are then compared with the problem situation in order to identify desirable and feasible change. The methodology integrates thinking about the logic of how to improve a situation with what is socially and politically feasible (López-Díaz et al., 2004).
Figure 3: Seven Stages of Soft System Methodology
2.3 Hybrid (Socio-Technical) Methodologies
The problems with the linear and hard methodologies forced the corporate and commercial software development teams to look for more dynamic and flexible approach towards the software development. The key challenge for software developers is get the high-pressure development schedules under control without compromising on the quality of the products (Kock, 2006). This led to the evolution of Socio-technical or Hybrid methodologies that aim to combine the benefits of both hard and soft methodologies while avoiding their drawbacks. This section further explains the hybrid methodologies with the example of Dynamic Systems Development Method (DSDM).
DSDM is an organized, common-sense process focused on delivering business solutions quickly and efficiently (Clifton, 2003). It focuses on delivery of the business solution, rather than just team activity. It makes steps to ensure the feasibility and business sense of a project before it is created. It stresses cooperation and collaboration between all interested parties. DSDM makes heavy use of prototyping to make sure interested parties have a clear picture of all aspects of the system (Kock, 2006).
2.3.1 DSDM Development Cycle
The DSDM development process consists of 7 phases (Hutchings, 1996). The first one is before the project has officially started. Then there are the project studies, which in this document are considered to be one phase. Then there are three more phases that consist of iterative cycles, which are repeated as necessary to complete the project. Then there is the post-project phase, where the project is maintained (Zieliński and Szmuc, 2006).
Source: Hutchings (1996)
Figure 4: The DSDM Development Process
Pre-Project: In the pre-project stage, the project is conceptualized, and the decision is made to start the project.
Feasibility Study: At this phase it is considered of the system can be completed within the constraints of time and resources.
Business Study: In this phase, the team prepares the business case for the project. The stakeholders are analysed and technologies needed to build, test, deploy and support the system are identified.
Functional Model: In this stage, functional prototypes of the system are developed and reviewed. A functional prototype is a simulation of the functions the system is intended to perform.
Design and Build: In this stage, the product is designed and developed in iterations. In each iteration a design model is made of the area being developed, and then that area is coded and reviewed.
Implement/Deploy/Maintain: In the last phase, the product is wrapped up, documentation is written, and a review document is drawn up, comparing the requirements with their fulfilments in the product. The users are trained in how to use the system, and the users give approval to the system.
Post-Project – Maintenance: After the product is created, maintenance will inevitably need to be performed. This maintenance is generally done in a cycle similar to the one used to develop the product.
3 SELECTION OF METHODOLOGY
Careful consideration of the methodologies discussed above shows that the selection of methodology depends on the nature, scope and scale of the project. For example SSM works best when the situation at hand is chaotic, complex and poorly defined. It therefore aims to make sense of such situations and makes it easier for the project team to understand the problem and achieve consensus about its solution (López-Díaz et al., 2004). In the case of proposed upgrades to the DVLA system, objectives are broadly defined and agreed by all, these are not very complex and there is no chaos. Therefore SSM would not be the best choice for this project. This leaves project team with Hard Methodologies (e.g. SSADM) and Hybrid Methodologies (e.g. DSDM). This section therefore considers the pros and cons of both and concludes with the selection and justification of the appropriate methodology (Zieliński and Szmuc, 2006).
Major advantage of following SSADM is its emphasis on monitoring and control of development process by providing strict deadlines for the deliverables to be produced at each stage and standard documentation of the whole process. This may suits the organizational culture of DVLA which is quite bureaucratic and hierarchical with strict command and control structures in place. Other advantages include ensuring technically high quality system, availability of CASE (Computer Aided Software Engineering) tools, easy to learn and use being an open standard and making more effective use of experienced and inexperienced staff while at the same time making project resilient to the loss of staff (Bocij at al., 2005).
However SSADM is criticized for being based on a ‘linear world view’ of the system development process that assumes that the users know what is needed and a technical solution is the best solution to achieve pre defined ‘business objectives’. In reality often the personal agendas and concerns of those affected by the system define their attitude towards it (Myers and Young, 1997) and this is something SSADM fails to take into consideration. Therefore the limited participation and consultation with important stake holders results in lack of ownership and commitment on their behalf to help system succeed. The methodology is criticised for lack of flexibility and being rigid. It is for example very costly and time consuming to make any changes to the system design if required at the implementation stage. SSADM also fails to study strategic, organizational, human and social parameters of the business environment and its lack of guidance in implementation, testing and quality assurance are its major disadvantages (Bocij at al., 2005).
DSDM on the other hand views IS development process as an intervention in the organization and emphasizes on the social dynamics and the human needs throughout the development process which may over ride the technical systems embedded in them. Organisations are therefore seen as social systems that rely to varying extents on technology and implementing such systems is thus viewed as a multidimensional process of social change that may have various social effects for example changing the power structure within the organisation (Zieliński and Szmuc, 2006). It therefore adds the ‘user participation’ to the system development process. It believes that the context and immediate environment in which an information system works has significant bearing on the success of the system. The reality of the organization is shaped by the informal information systems that exist in every organization and perceptions of various key stake holders are critical to understand the true nature of problem. It also warns that a solution imposed on the users may result into resentment and resistance by the users to adapt it. This view is also supported by research in cognitive psychology (Norman, 1986). Therefore socio-technical approach emphasizes on the ‘fit’ between the technical and social sub systems in the organization and suggests consultative, representative or consensus oriented methods of user participation.
The DSDM aims to combine the strengths of both hard and soft approaches to system development and avoid their shortfalls. It has been very useful in dealing with the biggest dilemma in software engineering i.e. how to get the user requirements right. It is often seen that the customer does not know the exact system specifications at the start of the project or the requirements change in the middle of the project that makes it very costly and time consuming for the project team to back track and make changes in the design when following structured methodologies like SSADM. However, in the case of DSDM, the system is developed in iterations and it evolves over time in the light of user feedback. Each iteration allows the system to be changed in the light of user feedback (Kock, 2006).
In the case of DVLA, although the situation is not complex or chaotic enough to warrant the use of SSM, however the inherent uncertainty of software development process is still present. The users of the current system need to be involved in to process of making changes to the system to make sure that they are happy with these and to avoid any chances of user resistance. The iterative approach followed by DSDM and involvement of users in the design and implementation of the upgrades to the system will brighten the chances of the success of project. It is evident from investigations into a number of Software/Information system failures that the hard methodologies are inadequate to respond well enough to the modern day life where the problems are increasingly complex and environment constantly changing (Millington, 2002). A survey of over 8000 projects found that the top three reasons that the projects were delivered late, over budget and with less functionality then desired all had to do with requirement management practices, lack of user input, incomplete and changing requirements (Standish group 1994).
3.1 Techniques for DVLA System
Within the DSDM framework there are a few generic techniques that may be used to help manage the project.
3.1.1 Prototyping
This technique uses the initial design of the system to construct a prototype or a simulation of the system. This Prototype is evaluated by the customer & used to refine the requirements. Iteration occurs as the prototype is tuned according to customer needs; at the same time developer better understands what needs to be done (Pressman ,1997). This allows flexibility in the development process and involves the users in the process.
Evolutionary prototyping: Evolutionary Prototyping is an iterative process in which the prototype going through many iterations is developed to be a complete working system (Zieliński and Szmuc, 2006).
Throw away prototype: A throwaway prototype is a prototype that is discarded after its use and is thus called throwaway prototype. It is normally used when a quick development of a prototype is not possible in the programming language or software tools selected for the development of the actual system.
Lo-Fi Prototype: Normally prototypes are build using software however, Lo-Fi is the only prototyping technique (Retting, 1994) which is independent of any computer system. It is built using the normal stationary material e.g. drawing sheets, post it notes, colour markers, glue, sticky tape etc. A working model of the system is built using these pencil and paper techniques and is then tested by moving the screens as the result of actions performed by the user (Kock, 2006).
3.1.2 Time Boxing
Time boxing (Mc Connell, 1996) is a development practice that helps to infuse a sense of urgency in the development team and helps to keep the projects focus on its most important or ‘core’ feature. Developers implement the most-essential features of the project first and the less-essential as time permits. In the words of Mc Connell:
“The system grows like an onion with the essential features at the core and the others in the outer layers”.
To apply time boxing to DVLA case, the functions of the intended system must be prioritized to help developers know which are less-essential, essential and most essential to achieve the objectives of the system. By making the schedule ‘absolutely fixed’, it assumes that ‘the time limit’ or ‘the time box’ is so important that it overrides all other considerations. If the project scope conflicts with the time limit, it is reduced to fit the time limit. Time Boxing helps developers finish a working ‘fit for purpose’ product in time rather than spending time on cosmetics or beautification which is normally termed as developers gold plating.
However Time boxing depends on the managements and end-users willingness to cut features rather than stretch the schedule and their being able to prioritize the features. That’s why it is only suitable for projects fulfilling these requirements.
3.1.3 MoSCOW Rule
MoSCOW is an abbreviation of Must Have, Should Have, Could Have and Would Have. It is a highly useful technique to prioritise the system functions by categorising them in to the above mentioned categories. ‘Must have’ are the functions without which the system cannot achieve its objectives, ‘Should have’ are slightly less important, however these are useful in achieving system objectives, ‘Could have’ are those which can be implemented if time permits and ‘Would have’ are to be included in the next version of the system. MoSCOW rule complements the Time Boxing technique. By focusing on developing the most essential features the development time can be tremendously reduced or at least it can be temporarily be reduced by developing the product in stages or by using a higher-level language or tool set so that it requires less code (Kock, 2006).
4 CONCLUSION
The report evaluates various software development methodologies. Specialised methodologies focus on the development project of specific nature e.g. expert systems etc. Soft methodologies are normally appropriate for situations that are too complex or chaotic. Hard methodologies such as SSADM provides systemic approach to systems development and allow firm control and monitoring of development process however they lack consideration of social factors such as power structure and other organisational aspects. The hybrid methodology e.g. DSDM aims to combine the strengths and avoid the weaknesses of both hard and soft methodologies. It involves the users at all stages of the development process and provides a flexible way to design and develop software. It is therefore recommended for the DVLA system. The techniques such as prototyping, time boxing and MoSCOW rule are recommended to all maximum user participation and ensure the completion of project within specified resources.
References
Allen, D and McKenzie, W and Thomson G (2004) Managing Information, Chartered Institute of Personnel and Development, CIPD Publishing, USA.
Bocij,P and Chaffey, D and Hickie, S and Greasley A(2005) Business Information Systems: Technology, Development and Management for the E-business, Pearson Education, UK
Brough, M. (2002) Other SMD Approaches: (Online) http://www.keele.ac.uk/depts/cs/Staff/Homes/Mdb3/courses/SD2001/other.pdf
Checkland, P. and Scholes, J. (1990) Soft Systems Methodology in Action: John Wiley and Sons Ltd.
Clifton, M. (2003) A concise summary of the Dynamic Systems Development Method. (Online) http://www.codeproject.com/gen/design/dsdm.asp#Introduction0
Hutchings, T. (1996) Introduction to DSDM. (Online) http://www.comp.glam.ac.uk/pages/staff/tdhutchings/Default.htm
Kock, N (2006) Systems Analysis & Design Fundamentals: A Business Process Redesign Approach, Sage Publications, UK
López-Díaz, M and Gil, M and Grzegorzewski, P and Hryniewicz, O and Lawry, J(2004) Soft Methodology and Random Information Systems, Published by Springer, USA.
Millington, D (2002) Developing a RAD Standard. (Online) http://www.agilealliance.org/articles/articles/DevelopingARADStandard.pdf
Norman, D. (1986) User centered system Design. London: Lawrence Erlbaum Associates, Inc.
Pressman, R. (1997) Software Engineering: A Practitioners Approach: New York: McGraw-Hill.
Standish group, (1994) Charting the sea of Information Technology: The Standish group
Toole, S. (2006) The Methodology Tree, Cambridge University website, http://www-mmd.eng.cam.ac.uk/people/ahr/dstools/control/softsm.htm
Travis, V (1998) An introduction to soft systems methodology: Lawrence Erlbaum Associates, Inc.
Zieliński, K and Szmuc, T(2006) Software Engineering: Evolution And Emerging Technologies, IOS Press, USA.