A COMPARISON BETWEEN
TRADITIONAL DEVELOPMENT
METHODOLOGY AND
RADICAL APPLICATION DEVELOPMENT
METHODOLOGY
by
Jacques Du P
_reez
9429670
Dissertation
Submitted as part fulfillment of the
requirements for the degree
MAGISTER COMMERCII
in
Business Management
In the Faculty of Economics and Management
Sciences
at the
Rand Afrikaans University
Study leader: Henco van Schalkwyk
TABLE OF CONTENTS
TABLE OF CONTENTS 2
CHAPTER 1 — INTRODUCTION TO RESEARCH STUDY 8
1.1. Introduction 8
1.2. Motivation for study 10
1.3. Problem Definition 11
1.4. Objective of this study 11
1.5. Methodology 12
1.5.1. The Sample 12
1.5.2. Data 12
1.5.3. Research methodology 12
1.5.4. Proposed research procedures 13
1.6. Classification of study 13
CHAPTER 2 — A LITERATURE STUDY REGARDING SYSTEM
DEVELOPMENT METHODOLOGIES 15
2.1. Introduction 15
2.2. System Development Life Cycle 15
2.2.1. Planning 17
2.2.2. Analysis 17
2.2.3. Design 17
2.2.4. Construction/Implementation 17
2.3. The Information Engineering methodology 19
2.4. System Development Components 20
2.4.1. Planning 20
2.4.1.1. Planning consist of the following stages 21
2.4.1.2. Techniques used during planning 23
2.4.2. Analysis 23
2.4.2.2. Analysis Techniques 25
2.4.3. Design 25
2.4.3.1. Techniques used during design 25
2.4.4. Construction 26
2.4.4.1. Techniques used during Construction 26
2.4.5. Implementation 26
2.5. The Role of CASE tools 27
2.6. The Benefits of using CASE tools 28
2.7. Benefits of Information Engineering 29
2.7.1. Better information systems by 29
2.7.2. Faster development because of 29
2.7.3. Reduced data processing costs 29
2.8. Summary 30
CHAPTER 3 — RAPID APPLICATION DEVELOPMENT METHODOLOGY
FRAMEWORK 32
3.1. Introduction 32
3.2. User Satisfaction and Product Quality 34
3.2.1. Close to the User 35
3.2.2. Product Quality 38
3.3. Timeboxed Project Management 39
3.3.1. Timeboxed projects 40
3.3.2. Evolutionary planning 40
3.3.3. Careful project initiation 40
3.3.4. Risk Management 40
3.3.5. Contained Chaos 40
3.3.6. Measurements, Review and Adjustment 41
3.4. The Evolutionary Delivery Process 41
3.6. Dedicated Teams 44 3.7. A Rapid Application Development (RAD) Project Lifecycle
Example 45
3.7.1. Project Selection 45
3.7.2. Getting started — Produce Version 1.0 45 3.7.3. Project Initiation consist of the following activities 45
3.7.4. Project Planning 45
3.7.5. Obtain project approval 46
3.7.6. Prepare for development 46
3.7.7. Develop the Application 47
3.7.7.1 Specify, design, develop and deliver Version 1.0 47 3.7.7.2 Specify, design, develop and deliver Version 2.0 47 3.7.7.3 Specify, design, develop and deliver Version 3.0 48 3.7.7.4 Specify, design, develop and deliver Version 4.0 48
3.8. Summary 49
CHAPTER 4 — SYSTEM LIFE CYCLE OF A LEADING BANK IN SOUTH
AFRICA 51
4.1. Introduction 51
4.2. The "1-4-9" Concept of Information Engineering 51 4.3. Introduction to the Definition Project 52
4.3.1. Confirm Business Rationale 53
4.3.1.1. Identify Key Theme 54
4.3.1.2. Identify Business Objectives 54
4.3.1.3. Identify the Critical Success Factors 55
4.3.1.4. Identify the Goals 55
4.3.1.5. Identify Business Processes 55
4.3.2. Identify Information Needs 55
4.3.3. Review Business Motivation and Requirements 56 4.3.4. Conduct Current Information Systems Assessment 56
4.3.5. Determine the Overall Options Available 56
4.3.6. Identify the Project Scope 57
4.3.7. Perform Function Point Analysis 57
4.3.8. Prioritise Project 57
4.3.9. Compile and Approve Definition Project Report 58
4.3.10. Conduct a Formal Project Review 58
4.4. Analysis & Conceptual Design Process 59
4.5. Develop the Data Model 60
4.5.1. Develop the Interaction Model 60
4.5.2. Design User Interface 60
4.5.3. Create Screen Flow Diagrams 60
4.5.4. Create Detailed Design and Construction Strategy 61 4.5.5. Produce Quality Assurance Documentation 61 4.5.6. Compile and Approve the Functional Specification 61
4.5.7. Perform Function Point Analysis 61
4.5.8. Conduct a Formal Project Review 62
4.6. Summary 62
CHAPTER 5 — THE RAPID DEVELOPMENT CENTRE METHODOLOGY 64
5.1. Introduction 64
5.2. The Solution 64
5.2.1. Partnership 65
5.2.2. Lead with the Business Problem, Follow with Technology 65 5.2.3. Delivery Rapid Development Centre (RDC) Style 65 5.2.4. The Rapid Development Centre (RDC) Process 66
5.2.4.1. Ownership 66
5.2.4.2. Visualisation 66
5.2.4.3. Iteration 67
5.3.1. User Focused Delivery 67
5.3.2. Relationships 68
5.3.3. Openness 68
5.3.4. Leadership 68
5.3.5. Growth 68
5.4. The Rapid Development Centre Methodology 69
5.4.1. Rapid Implementation Plan (RIP) 69
5.4.1.1. Rapid Implementation Plan Process - Definition Phase 69
5.4.1.1.1. Site Visit 69
5.4.1.1.2. Preparation Meeting 70
5.4.1.1.3. Rapid Implementation Planning Workshop 70
5.4.1.1.4. Checkpoints 71
5.4.1.1.5. Team Meetings 71
5.4.1.1.6. Feedback Forms 71
5.4.1.1.7. Rapid Implementation Planning Workshop Rules 72 5.4.1.1.8. Rapid Implementation Planning Workshop Deliverables 72 5.4.1.1.9. Rapid Implementation Planning Workshop Modus Operandi72 5.4.2. Design — Business and Technical Analysis 74
5.4.2.1. Preparation Meeting 74
5.4.2.2. Analysis Purpose 75
5.4.2.3. Analysis — Workshop Characteristics 75
5.4.2.4. Analysis — Workshop Components 76
5.4.2.5. Analysis Deliverables 76
5.4.2.6. Analysis Modus Operandi 76
5.4.2.7. Review Sessions 77
5.4.3. Implementation 77
5.4.4. Production 78
CHAPTER 6 - CONCLUSION 80
CHAPTER 1 -
INTRODUCTION TO RESEARCH STUDY
1.1. Introduction
Business is living through some of the most turbulent years in history. This turbulence in the work environment is caused by significant changes in people, methods, and goals, which occur so fast that the work force is unable to operate effectively. In such an environment, the frequency and complexity of major changes such as advancing technologies, the energy crisis, economic instability, government regulations, new products and markets, and new employee expectations exceed the workers capacity to adjust. Skills to respond effectively to these changes have become essential survival tools for most organisations.
Information is one of the main types of survival tools that are available to most organisations. Information can be managed just as any other resource and interest in this topic stems from two influences. First, business as discussed above has become more complex, and second, the computer has achieved improved capabilities.
Business has always been complex, but it is more so today than ever before. All companies are subject to international economic influences and compete in a world-wide marketplace, the technology of business is becoming more complex, the time frame for taking action is shrinking, and there are social constraints.
Compared to today's computers, the first models were dinosaurs in terms of their size and speed. The giant computers of the 1950's and 60's were located down the hall, to be touched only by the firm's computer specialists. Users never came in direct contact with the hardware, but this arrangement suited the users just fine. In many cases, users did not know how to use the computers, and many were afraid to learn.
Today's users, on the other hand, most likely have either keyboard terminals or microcomputers in their offices. Many of the workstations are connected to other workstations in a network.
Not only are the computers available, the users know how to use them. Today's user does not regard the computer as something special but as a necessary piece of office equipment, just like a fax machine or a telephone.
The system development methodology used by companies is not always the most optimal decision. The requirements for successful system development are not always met. This results in defective, incomplete and inadequate systems.
The development of systems consists of different components. To be successful in system development these components must be used to the optimum to ensure rapid and efficient system development.
Planning
Planning establishes the definition of the user that needs to be supported, the projects to be performed, and the strategy we will pursue. Planning is a high-level activity and its results describe needs from a high-level perspective.
0-, Analysis
For a defined business area within the scope of the overall Strategic Systems Information Plan (SISP), a detailed study is conducted of its data; its functions and the information required fulfilling those functions. This leads to identification of processes, their inputs and outputs and the objects about which data have to be kept.
-• Design
Design does not start from scratch. It is totally based on the business requirements as stated during Business Area Analysis (BAA) and evolves from there.
17-■ Construction
For each design area a system is constructed. This includes installation of equipment, setting up files, defining procedures, specifying, coding and testing programs. Construction aims to develop a system, as defined in the technical specification, within time and budget, of an acceptable quality. These systems can be regarded as complete when it is accepted, based on predefined criteria by the user.
1.2. Motivation for study
The art of information system development has undergone a difficult and tortuous evolution over the past two and a half decades (Texas Instruments;1988:17). For the participants in this software development struggle, it has been frustrating to watch the quantum leaps made in the computing hardware arena, while advances in software quality and productivity have shuffled along at a considerably more modest pace.
It is now the time to step across the threshold into a new approach in the evolution of system development one in which the right problems are solved, and high-quality solutions are produced very quickly.
The new approach starts with understanding the business problem and then applying the most appropriate technologies to meet the business challenge.
The approach must not be locked into any one type of technology but rather work with the user and outside vendors to determine the combinations of hardware, software and custom software development that will supply the highest quality solution.
The specific goal of this study is to determine the most effective approach to system development to focus on the single most important thing: solving business problems in a way that exceeds user's expectations.
1.3. Problem Definition
To address today's critical business issues — increased competition, rapidly changing market conditions, and the need for business process re-engineering — information systems must become more flexible, able to meet changing user requirements quickly and precisely. This can only be achieved when:
System development takes place in the presence of all components of system development.
System development methodology adjusted for each individual project
The proposed system development life cycle gives a basic description of the components of the system development process, the research project will determine if the model is practical notwithstanding, and the short coming's of the model and the system development process.
1.4. Objective of this study
The research has a primary goal to determine how companies must use the most optimum approach to system development:
The secondary goal of this research is as follows:
The first secondary goal is to determine the impact of system development on an organisation.
Secondly to find the appropriate methodology for system development in an organisation.
1.5. Methodology
1.5.1. The Sample
The research consists of the results and findings as obtained from the Rapid Development Centre at a leading South African Bank.
1.5.2. Data
The data of the research consists of the following:
The results and experience of the Rapid Development Centre that is currently using a rapid development process for system development.
The process of system development before the establishment of the Rapid Development Centre.
Literature study of the available literature regarding Rapid Application Development Technologies.
1.5.3. Research methodology
The research project will take the form of a literature study compared to a practical example.
The method that will be used:
The gathering of results and information regarding the methodology of system development in the department of the Rapid Development Centre.
A literature study regarding relevant subjects as being discussed in the research project.
1.5.4. Proposed research procedures
The research will look at application development before the use of the rapid system development methodology. The rapid system development methodology will be used in the Rapid Development Centre.
The findings and results regarding the system development in the Rapid Development Centre will be analysed to determine the benefits and disadvantages of the rapid system development methodology.
The research procedure will be as follows:
Research and evaluation of the "old" system development methodology. Execution of the "new" system development methodology.
The comparison between the two different methodologies.
1.6. Classification of study The layout of the study is as follows: Lt Chapter 2
In this chapter a literature study will be done to set a theoretical foundation regarding traditional system development methodologies used in the past. The importance of all the system development components will be discussed in detail.
1■
_ Chapter 3In this chapter a literature study will be done to set a theoretical foundation regarding the RAD (Rapid Application Development) methodology. A Rapid Application development framework will be used as the basis of discussion in this chapter. This will include a example of a typical Rapid Application Development Lifecycle.
♦ Chapter 4
This chapter will cover the current system application development methodology used at a leading South African Bank.
Chapter 5
This chapter will cover the system application development methodology used in the Rapid Development Centre at a leading South African Bank.
♦ Chapter
In this chapter the results of the research will be summarised to make conclusions regarding systems development and to make some recommendations for the implementation of a radical software development methodology.
CHAPTER 2 -
A LITERATURE STUDY REGARDING
SYSTEM DEVELOPMENT METHODOLOGIES
2.1. Introduction
An information system in an organisation is similar to the nervous system in the human body. It is the mechanism which co-ordinates and controls the components so that the organism as a whole can survive and adapt to its environment. Information systems exist to support organisational functions and strategies.
The aim is to develop a system to support the organisation in the environment it operates. System development is the process of turning the detailed plan into a functioning system. It has been the practise to search for the ideal development approach for the organisation. Information system development methodologies have been bought, adapted and tailor made to fit the requirements of each organisation.
The purpose of this chapter is to identify the components for successful system development. The study will start of from Information Engineering (IE) as a broad system development methodology. It provides techniques for identifying and organising business requirements at the highest possible level. Based on those requirements, it provides tools for building application systems to satisfy the requirements. The study will show how system development has changed over the years.
2.2. System Development Life Cycle
Information Engineering (IE) differs from the traditional system development approach in many ways. The traditional system development life cycle assumes that the designer can distinguish between what the system must do
Information Strategy Planning Business Area Analysis Business System Design Technical Construction
and how the system will do it. The establishing of what and how are distinct and separate processes within the traditional system development life cycle.
Information Engineering (IE) is the integration of new information methods and old information methods combined, producing the least cost method of system development. Information Engineering (IE) is a methodology, which allows any individual to crate a matrix in which masses of unorganised data are placed in categories that allow one to accumulate answers by examining various dimensions.
The definition of the word "Information" is "the communication or reception of knowledge or intelligence." The definition of the word "Engineering" is "the art of managing engines, science by which the properties of and the sources of energy in nature are made useful to man." In the 1980's these two words were applied to a new methodology which assisted in making raw data useful to man. The term Information Engineering (IE) was born (Fuller RB. 1996).
Figure 2.1: A Theoretical System Development Model
The Information Engineering (IE) development life cycle encompasses 4 major phases:
2.2.1. Planning
Planning provides a way to plan and manage the use of information, just as one might plan and manage the use of any other resource. During planning, planners build the framework for satisfying information requirements (Texas Instruments Incorporated. 1990).
2.2.2. Analysis
During analysis, analysts perform a detailed analysis of a selected area of the business. Developers use the results of analysis in successive stages of Information Engineering (IE) to provide the systems needed to manage the enterprise's information resources.
2.2.3. Design
During design, designers use the information discovered during analysis as the basis for describing an information system that can satisfy the users needs (Texas Instruments Incorporated. 1990).
2.2.4. Construction/Implementation
Included in construction are the development of programs, database and screens. In short, all of the pieces necessary for an application system to run in the selected target environment.
Each of these phases is divided into various stages and every stage consists of tasks, supported by various structured techniques resulting in work products or deliverables. These stages are generic in the sense that they are not associated with any specific development path but rather are the basic components of development projects in general.
Each stage consists of a set of related tasks, with each task serving a single purpose and having clearly defined prerequisites and deliverables. Each of the stages has a different scope. In the planning phase, the early stages address broad areas of the business at a strategic level.
As development progresses through the phases, the scope narrows and the level of detail increases. At the end of each phase, developers determine the highest priority areas for further work and complete analysis tasks that determine the scope of future stages.
A selection of tasks is necessary for each project, depending on the path to be followed. For example, when a project is aimed at the selection of software package different tasks are completed than for an in-house development project.
Each task needs one or more deliverables. These deliverables are often prerequisites for a task that follows. Techniques describe how a task should be performed and how its results should be presented. A single technique may be used in a number of tasks, sometimes at different levels of detail. The most widely used techniques use diagrams.
A subset of techniques may be chosen to meet the needs of the specific situation. Techniques are not independent of one another. They are designed so that the results of one technique support another.
2.3. The Information Engineering methodology
Information Engineering (1E) is called a methodology because it consists of a collection of integrated techniques based on a set of well-understood principles. These principles have been employed because experience has demonstrated that they work (Fuller RB. 1996).
For a set of procedures to be a methodology, it must be able to grow through experience, to gather knowledge about its results. A methodology evolves and improves itself through the experience gained.
In using a methodology, the principles used must enable us to achieve our objectives. We develop ways of measuring success and improving weaknesses, in order to evolve and learn. The Information Engineering (IE) pyramid represents the information needs of the organisation.
'- Divide and Conquer
Information Engineering (IE) starts by looking at high level, then proceed to collect more information about smaller portions ending with a manageable system. Information Engineering is also called top down development.
-* Divide into phases
Information Engineering (IE) divides the development of systems into manageable chunks or phases - planning, analysis, design and construction. Information Engineering examines the data and activities and the interaction between them.
-• People
Information Engineering (IE) relies on the organisation's best information: the people who understand it. The users active participation enables the developers to ensure that the systems actually meet the users requirements.
Diagrams
Diagrams are used to aid understanding and to interface with the users. Each deliverable leads to the following phase or deliverable.
Iteration
By means of iteration the developers repeat complex tasks to derive a meaningful picture. Iteration is applied in a controlled way in the methodology to the different tasks, enabling to grasp the areas being analysed.
2.4. System Development Components
2.4.1. Planning
The systems development life cycle is, in effect, a plan, or structure, for conducting the systems development project. Planning for overall information systems support is critically important in any organisation. However, the focus of this discussion is on the planning that occurs within the context of a development project. In this setting, planning involves the identification of all the major segments, or phases of a project. These phases are then subdivided into specific activities and individual jobs, or tasks. Together, theses are the assignments that must be completed in the course of a project.
Planning establishes the definition of the users needs that the project must support, the projects to be performed, and the strategy we will pursue. Planning is a level activity and its results describe needs from a high-level perspective. Since such a plan often involves extensive changes to the information-processing environment the project must have the support of the top management of the company. Because each enterprise is unique planning must be tailored for each project to the particular enterprise being studied.
During planning the culture and political environment should be handled with care otherwise the project is condemned to fail. The overall result or deliverable of Planning is a set of architectures defining the organisation's Strategic Information Systems Plan (SISP).
2.4.1.1. Planning consist of the following stages: Strategy Analysis
Current environment assessment Initial Systems Analysis
Determine business areas
I. Strategy Analysis
In the Strategy Analysis stage the following activities will take place:
Define mission
The enterprise's mission is a general statement of the purpose and nature of the enterprise. Each enterprise can be characterised by a single mission.
Define goals
A goal is a specific target the enterprise wishes to reach at a specific point in time. Each goal of the enterprise supports a single strategy.
Define objectives
An objective is a broad, longer-term result that the enterprise wishes to achieve to support its mission.
Define critical success factors
A critical success factor is a factor that has a major influence on whether the enterprise will achieve a particular objective or goal.
Identify information need
An information need is an unstructured statement describing a type of information required by an organisational unit to meet its objectives and support its functions (Texas Instruments Incorporated. 1990).
II. Current environment assessment
Assess current application
The current system is a collection of automated procedures that already support some aspect of the enterprise. For each system, its name and a short description must be recorded.
Assess current data store
A data store is a repository of data of which users are aware and from which data may be read repeatedly and non-destructively. Thus, current data stores are the permanent files and databases that presently support the enterprise. The planners should only be concerned with identifying the data stores name and a short description.
Ill. Initial Systems Analysis
Analyse subject areas
A subject area is an area of interest to the enterprise centred on a major resource, product, or activity. It summarises things in which the enterprise is interested.
Develop enterprise data model
The enterprise is viewed at various levels from a largely data, as opposed to process, perspective. The various data requirements of each level of the overall enterprise combine to form a synergistic data system.
IV. Determine business areas
Partition process and data models
The data models describes the thighs of interest to the business and the relationships between them (Texas Instruments Incorporated. 1990).
-• Define business areas and priorities
Changing business conditions motivate a request for new or improved computer system support. The needs must be prioritised.
2.4.1.2. Techniques used during planning
Association matrices are used to record information about the mission, goals, critical success factors etc. of the system. Subject Area Modelling represents the natural subdivisions of organisation and covers resources, products, activities or external entities. Function/Process Decomposition and Function/Process Dependency Analysis represent the breakdown of functions and the relationship between them.
2.4.2. Analysis
For a defined business area within the scope of the overall Strategic Information Systems Plan (SISP), a detailed study is conducted of its data; its functions and the information required fulfilling those functions. This leads to identification of processes, their inputs and outputs and the objects about which data have to be kept.
These are analysed and documented. It is imperative that involvement of users in the analysis of any area is encouraged. Existing systems and files are analysed in order to enable transition from the current to the proposed system.
At the end of a Business Area Analysis Project, a business area description has been prepared, showing the processes performed, the entity types, relationships and attributes pertaining to the area, as well as a cross reference between these two major components. The properties of all these objects are documented, providing input to the Information Architecture.
This information is used to select particular processes for computerisation and to design the systems and data structures needed to support these processes.
2.4.2.1. The objectives of Analysis are:
Developing a thorough understanding of the business area.
Ivy Producing a set of business models that reflect the business area
understanding.
ly Identifying specific user requirements.
Identifying priorities to be applied to the implementation of these requirements.
Identifying and prioritising systems needed to fulfil the requirements. Drafting a conceptual systems design for the proposed system(s).
Conceptual Systems Design is kept independent of the technology used during implementation. Prototyping techniques may be used to accelerate many of the tasks traditionally performed in this stage. It requires agreement of the users on the ways in which they will interact with the system.
The final product from the Analysis phase is a system specification showing all the documentation prepared for the data and process models as well as user procedures for each business process, the dialogue design, screens, reports and other user interfaces. From this, a detailed scope of the proposed design is prepared together with a project plan for the next stage.
2.4.2.2. Analysis Techniques
Entity Modelling represents, in a detailed and structured manner, the results of data analysis. Entity analysis documents entities and their attributes, relationships, properties etc. The results are in an entity relationship diagram or entity model. Current Systems is used to examine systems in order to re-engineer the business model that underlines current systems.
2.4.3. Design
The design stage gets down to the nitty-gritty and describes how the system will satisfy the requirements set (Williams N. 1995). Design does not start from scratch. It is totally based on the business requirements as stated during Business Area Analysis (BAA) and evolves from there. The design phase consist of the following activities:
Define physical environment that includes the hardware, software, workstations and communications infrastructure
Generate physical database by creating the entity model. This activity includes designing the data structure
Design application models
Finalise I/O design by using screen layouts
Design systems interfaces by using a interface diagram
isolo Verify the design
Design a test plan and schedule of all tasks in carrying out a full test on a system
Prepare operating procedures
2.4.3.1. Techniques used during design
Data Structure Design converts an entity relationship diagram to a data structure diagram that conforms to the target database management system. Prototyping of inputs and outputs are performed.
Data Storage Structure Design determines how data will be organised in storage. Data storage structure determines how systems will perform in their use of data, but is independent of the programs themselves. Structure charts are prepared for program modules and interface diagrams depict interaction between this and other systems.
2.4.4. Construction
For each design area a system is constructed. This includes installation of equipment, setting up files, defining procedures, specifying, coding and testing programs. The Construction phase aims to develop a system as defined in the technical specification, within time and budget, of an acceptable quality. The system can be regarded as complete when it is accepted, based on predefined criteria by the user.
Prepare physical environment Specify development standards Construct database and files Generate data modules
Generate test data and documentation
2.4.4.1. Techniques used during Construction
Tasks during construction includes preparing a test plan, replicating the test conditions, developing test data and determining how to interpret expected results.
2.4.5. Implementation
Implementation is the phased replacement of existing systems, procedures and files with the new system procedures and data structures. This is usually the longest and most costly phase of the project, and involves the operating of the system (Harding A. 1996). It is carefully monitored by a steering committee according to a set plan. Implementation is complete
when the system operates for a specified period without hand holding from IS, within defined performance levels, error rate and usability and passes its post-implementation review.
The main objective of construction is that the completed system meets requirements stated in the specifications. Meeting informal or assumed expectations will enhance the overall result.
For systems developed using the Information Engineering (1E) life cycle, it may be required to loop through parts or all of the planning, analysis, design and construction phases. The ability to build systems that evolve, rather than ones that must be thrown away and completely redeveloped each time requirements change, saves costs and time.
After the system has been implemented and running, a system review or evaluation must be conducted every 3 — 6 months to determine whether:
User requirements have been met Costs have not been exceeded Benefits have been accrued
2.5. The Role of CASE tools
In simple layman terms, CASE is a tool, which aids a software engineer to maintain and develop software. Much like a mechanic who uses the aid of his/her tools to maintain and develop vehicles, but obviously using respective techniques.
A more formal definition of CASE can be found in the Software Engineering Notes of April 1990, 'Terminology for Software Engineering and Computer-aided Software Engineering by B.Terry & D.Logee, whereby CASE is defined as: "Individual tools to aid the software developer or project manager during one or more phases of software development (or maintenance)."
Diagrams contain combinations of words/symbols, which define complex situations in an easy to understand simple format. Using diagramming techniques gives us a picture that is:
Easy to understand Quick to Update
Precise, concise and clear Structured
Logical etc.
Because of the iterative nature of development work, diagrams need automation and should be created with the aid of the computer. A standard notation is essential in defining the minimum requirements when capturing diagrams and other related documentation. These requirements have led to the use of CASE Tools for documenting information (Stobart S. 1998).
2.6. The Benefits of using CASE tools
The introduction of CASE into any organisation can cause considerable changes to the time taken by each phase and the distribution of cost within the software life cycle. CASE has a greater emphasis on analysis and design, thereby having a vast impact on reducing maintenance costs.
Business requirements are entered into the CASE tool, stored as diagrams and text format. Users should be able to understand these diagrams. They provide a sound basis for verification and for communication between people (Stobart S. 1998).
Diagrams offer a far more concise specification of the processes and data in the business than using text. Diagrams record the analyst/users understanding of the business and can be used to ensure its correctness.
The documented information forms the basis for automated systems generation. Information in a timely manner and this information will facilitate
focusing on organisational (rather than departmental) goals, problems, critical success factors.
Information Engineering (IE) productivity tools/techniques will enable systems to be designed and implemented quickly before data and process modelling of the organisation is completed. As projects are completed the corporate model will evolve, instead of waiting for the corporate model to complete and then starting individual projects.
2.7. Benefits of Information Engineering
The benefits of using the Information Engineering (IE) methodology is as follows:
2.7.1. Better information systems by: Improved data quality and accessibility Elimination of analysis errors and design Closer fit to user's business needs
Incorporation of new or changed requirements with minimal disruption to existing systems.
2.7.2. Faster development because of:
Re-usable code and models already in the encyclopaedia Quick and easy documentation
Structured approach Integration of phases Code generation
2.7.3. Reduced data processing costs:
Lower maintenance costs through improved systems, database structures and documentation
Reduced operating costs by controlled data redundancy
Reduced human resource costs of development through increased productivity and re-use of common components
2.8. Summary
An information system is the mechanism that co-ordinates and controls the information in an organisation. The aim of system development is to develop a system that supports the organisation in the environment it operates. Successful system development is possible only if the correct system development methodology is used.
The study starts of from Information Engineering (1E) as a broad system development methodology. Information Engineering (IE) differs from the traditional system development approach in many ways. Information Engineering is the integration of new information methods and old information methods combined, producing the least cost method of system development.
The Information Engineering (IE) development life cycle encompasses 4 major phases, planning, analysis, design and construction. Planning provides a way to plan and manage the use of information, just as one might plan and manage the use of any other resource. During planning, planners build the framework for satisfying information requirements. During analysis, analysts perform a detailed analysis of a selected area of the business. Developers use the results of analysis in successive stages of Information Engineering (IE) to provide the systems needed to manage the enterprise's information resources. During design, designers use the information discovered during analysis as the basis for describing an information system that can satisfy the users needs. Included in construction are the development of programs, database and screens. In short, all of the pieces necessary for an application system to run in the selected target environment.
Because of the iterative nature of development work, diagrams need automation and should be created with the aid of the computer. A standard notation is essential in defining the minimum requirements when capturing
diagrams and other related documentation. These requirements have led to the use of CASE Tools for documenting information.
The introduction of CASE into any organisation can cause considerable changes to the time taken by each phase and also the distribution of cost of the software life cycle. With each CASE there is a greater emphasis on
analysis and design and a vast reduction in maintenance cost.
The benefits of using the Information Engineering (IE) methodology is improved data quality and accessibility to the data. Information Engineering also ensures a structured approach to system development. Although Information Engineering (IE) ensures lower maintenance cost through improved systems, database structures and documentation the development time frame is still to long. Using Information Engineering (IE) does still not satisfy the need for rapid development.
CHAPTER 3 -
RAPID APPLICATION DEVELOPMENT
METHODOLOGY FRAMEWORK
3.1. Introduction
Traditional life cycles devised in the 1970's and still widely used today are based upon a structured step-by-step approach to developing systems. User requirements are identified; a solution is designed; the requirements and design are frozen; and the system is coded, tested, and implemented.
This process can be very slow. Users are primarily involved in the requirements phase with little involvement in subsequent phases. User requirements are often frozen 12 to 18 months before a system becomes operational, so that by the time the system is implemented, it may not meet the current needs of the business.
Most organisations are faced with a large backlog of new systems to be developed. Over 65 percent of the typical Information Systems budget is spent on the maintenance of existing systems.
These systems have little documentation and were developed with programming languages and database management systems that are difficult and time consuming to change. Although business dynamics and technology are rapidly evolving, most mission critical systems have not changed significantly since they were built 10 to 20 years ago.
Organisations faced with upgrading these ageing systems or building new applications are finding traditional development life cycles too slow and rigid to meet business demands that are constantly changing.
The Rapid Application Development (RAD) methodology is considerably different from traditional methodologies. Active user involvement throughout
the Rapid Application Development (RAD) life cycle ensures that business requirements and user expectations are clearly understood.
Rapid Application Development (RAD) takes advantage of powerful application development tools to develop high quality applications rapidly. Rapid Application Development (RAD) techniques are also very successful when faced with unstable business requirements or when developing non-traditional systems.
Giving a team a clear objective, concentrating the resources, and getting obstacles out of the way is often half the secret in making rapid development successful. There are four key aspects to reengineering the software development process:
is* The overall process, the software development life cycle, must undergo
a transformation from a static, documentation orientation to a dynamic, evolutionary, product orientation;
Doing activities faster requires a skill at timeboxed project management techniques. Timeboxed development allows development teams to quickly build the core of the system and implement refinements in subsequent releases (Bayer S. and Highsmith J. 1994).
An evolutionary life cycle will not produce the desired benefits without promoting high performance, dedicated teams;
Transformation to a Rapid Application Development (RAD) approach does not mean abandoning the critical software and information engineering skills gained in the last 15 years. Instead, these skills need to be redirected into continuous application engineering.
3.2. Client Satisfaction and Product Quality
Many approaches to accelerated software development begin with high-powered tools, or Joint Application Development (JAD) sessions.
While all of these play an important part in Radical Software Development, the focal point for rapid system development is results, from the perspective of the clients of the application.
Qualit Results Productivity User Satisfaction Plan Focus Build Process
Timeboxed Project Management
Foundation Dedicated Professional Team
Continuous Application Engineering Powerful Development Tools
Figure 3.1: A Theoretical Rapid Application System Development Model Source: Radical Software Development. A Framework. Sapiens. 1994
In the triangle of components that make up radical development, the peak is results, client satisfaction, product quality, and productivity. Rapid Application Development (RAD) focuses on the customer, product and process. The focus increases the chances of project to be successful.
3.2.1.Close to the User
Getting close to the user has been a key management focus. Many organisations have not received the message. Organisations stress "user involvement" in projects because getting closer to the user means living in the customer's world and talking his language (Radical Software Development. A Framework. Sapiens. 1994).
Organisation attitudes stand in the way of achieving real customer satisfaction. In many Information Systems (IS) Departments, it's the attitude "if we build it, they will buy". These attitudes are natural in many ways. Developing software is very hard. Keeping up with the technology, trying to use the myriad of tools to build something useful, and trying to maintain some sense of comfort and control all leave little time to think about the user.
What makes matters worse is that a dispute also occurs within the Information Systems (IS) Department. Stovepipe organisational structures within Information Systems (IS) Department, database managers, data modelers, system analysts, programmers, security, operations, and data administration work at odds with each other by design.
This is great in an organisation wanting appropriate checks and balances to ensure there are no mistakes during the development process. It also ensures that no development projects are ever delivered quickly.
Getting close to the customer can mean many things, but a simple model is:
Create a user satisfaction vision. Make sure everyone in the development department recognises who the user is.
Encourage user input. Give the user a variety of ways to express their needs and their satisfaction levels with current products and services.
MOO Listen and act. It is better not to encourage input at all than to encourage it and deny the results. Listen to what the users have to say and act on it.
Provide timely feedback. Users become discouraged during lengthy development processes. Consistent, frequent feedback is important for good user relationships.
To begin the process of becoming user driven, an organisation needs to assess it's current status. Often there is a general "feeling" that users are satisfied and therefore the Information Systems (IS) Department must be doing a good job. The first task, therefore, is to get past the generalisations about user relationships and find out where the strengths and weaknesses are, from the users perspective.
Tools to gather the information are:
User Satisfaction Surveys
These surveys can take a variety of forms, from written questionnaires to individual interviews. Each has benefits and shortcomings, but the key issue is measurement. The users should rank their product and process satisfaction on a relative scale from 1 to 7 (Bayer S. and Highsmith J. 1994).
Such a ranking will yield adequate qualitative data, and more quantitative measures can be developed as areas of concern are highlighted by the qualitative measure results.
JAD (Joint Application Development) Sessions
Joint Application Development (JAD) sessions have been used successfully in organisations for the past ten years. They are an integral part of any Rapid Application Development (RAD) project.
Joint Application Development (JAD) sessions have been touted for years as an important technique for gathering specifications (or design or other information) for software applications. Joint Application Development (JAD) sessions engage users and developers in a common dialog and speed the development process.
The key shortcoming of the process is untimely feedback. Users attend Joint Application Development (JAD) sessions, usually get documented results, usually feel pretty good about the sessions, but product results are still ephemeral. Without an evolutionary development cycle (which will be discussed later) that produces interim product versions, the benefits of Joint Application Development (JAD) quickly disintegrate.
Joint Application Development (JAD) sessions need to be followed quickly by product versions and then the next user oriented technique, the focus group meeting.
User Focus Groups
Like Joint Application Development (JAD) sessions, user focus groups are special meetings with several imperatives:
Each session is a review of the product itself, not a document. The objective of each session is to find and record user change requests.
Developers must act if they are behind one-way glass be seen, not heard
Everything is a success. Whether comments are positive or negative, something is learned about the product.
In a variety of projects, focus groups have proven to be remarkably successful. Users like the fast turnaround; they evaluate a product rather than some indecipherable diagram; their comments are taken seriously.
The bottom line is that users become involved (Bayer S. and Highsmith J. 1994).
3.2.2. Product Quality
The broader philosophical arguments of how best to ensure product quality, i.e. choosing a particular development method, is addressed in the next sub-section. This section however, defines two views of the factors of product quality.
The first view puts product quality factors into three categories. These are firstly, those attributes stated in the requirement specification, such as portability.
Secondly, those implied as cultural factors. For example, usability, which is not in the requirement specification, but is expected of a system.
Thirdly, quality factors which may be of interest to the developer, but not immediately to the user, for example, reusability. The developer may use this to gain an advantage over rivals, if the same user wanted to either enhance or have another system built, in the future. The developer may be able to reuse some of the modules of the users existing system.
The second product attribute definition of quality can be categorised as: Product Operation: This is the Information System (IS) operational characteristics. These include:
Correctness: Does it satisfy the system specification.
Usability: The effort required by the user to learn, operate, prepare input and interpret output, of the system.
Reliability: How robust and accurate the software is, in performing the system functions.
Integrity: Can access to the system be controlled and how secure can it be made, by administrators.
Efficiency: Can the resources and the code be reduced, in performing the functions.
Product Revision: This is the Information System (IS) adaptability to new environments. These include:
Maintainability: The effort required to locate and fix an error.
Testability: The effort required to modify.
Flexibility: The effort required to test the system.
Product Transition: This is the ability of the Information System (IS) to undergo change. These include:
Portability: The effort required transferring the program from one hardware and/ or systems software environment to another.
Reusability: The extent to which the system or parts of it can be reused in other applications.
Interoperability: The ease to interface the system with another.
3.3. Timeboxed Project Management
Project Management is one of the foundation skill areas needed to successfully complete a Rapid Application Development (RAD) project. Accelerated time frames force the project team to deal with issues quickly and efficiently. In a more traditional project, these issues might not affect
the results too adversely if not handled quickly, but in a Rapid Application Development (RAD) project the time delay can prove very costly.
As with software engineering, project management may be less formal, less detailed, and less well-documented in a Rapid Application Development (RAD) project, but the key personnel and task management activities that make projects successful must still be well executed. The critical project management success factors in a Rapid Application Development (RAD) project are:
3.3.1. Timeboxed projects
Time, 6 to 9 months or less, is established as the least flexible project objective.
3.3.2. Evolutionary planning
Versions of the application are planned prior to planning the tasks themselves.
3.3.3. Careful project initiation
Team members, sponsors, and clients need to reach early agreement. Setting up a "Project Team Work Area" is another key initiation item.
3.3.4. Risk Management
Risk analysis is an integral part of the evolutionary planning. The team must keep track of risk areas and constantly work to reduce the possible impact of adverse conditions.
3.3.5. Contained Chaos
Rapid Application Development (RAD) projects tend to be chaotic. Don't attempt to eliminate the chaos, but merely contain it.
3.3.6. Measurements, Review and Adjustment
Tightly coupled feedback loops provide flexibility and early error correction.
The user must be encouraged to prioritise requirements and concentrate development on the most critical elements of the application.
This allows the development team to quickly build the core of the system and implement refinements in subsequent releases. System functionality may have to be trimmed back to complete development within the allotted time frame.
3.4. The Evolutionary Delivery Process
The heart of radical software development is the Evolutionary Delivery Process. Whereas the waterfall life cycle's focus is on managing interim products, the waterfall approach has been blamed for freezing system requirements, up to 18 months before the system comes into operation and by which time, the business requirements may have changed, resulting in an obsolete system (Radical Software Development. A Framework. Sapiens. 1994).
Both development and management of this Rapid Application Development (RAD) process is very different, and it is easy in the beginning to get a confused understanding by over concentration on traditional methodologies.
Traditionally, the model for software development has been the "waterfall" model. This "waterfall" model describes the life cycle as a series of steps in which all description levels between the problem and the implementation are found, starting from the definition and ending with operation and maintenance. Each step is linked to the next step to represent chaining and to the previous step to represent corrections by feedback. Each step is associated with a verification phase, the purpose of which is to check that the selected solution conforms to the step input specifications. Any lack of
conformity will mean that the step or the results of the previous step has to be revised.
Most of the commercially available methodology products follow this approach. While waterfall methods brought some stability and order to the chaos of earlier development efforts, their shortcomings are lost in the "swamp' of waterfall development.
Maintainability and life cycle costs have been a major reason for installing software engineering techniques and methodologies. One issue often raised with rapid development is that of maintainability due to poor design or architectural planning.
If rapid development is implemented as a return to coding without thinking, then the issue is valid. Done properly, maintainability in an evolutionary environment is even better.
The essence of evolutionary development is change, incorporating a large volume of customer changes, as the project progresses is required of the process. In order to do these effectively, the development approach focuses on making change easy, including good design, architecture, coding guidelines, etc.
This test the change process over and over again as the project progresses. Done properly, evolutionary development produces more maintainable products.
The evolutionary model produces appropriate documentation but focuses on delivering versions of the product. The documentation produced is more appropriate to the phase at hand, and it "evolves" just like the product.
For example, the first release might include a "sketch" of a data model, and the final release might include a complete data model.
Evolutionary development speeds the process and improves feedback. It can:
Establish applications that can evolve over time Accommodate changing business needs
Adapt development processes to the application Deliver earlier benefits to customers
Reduce the risks of major failures
Help in gaining customer confidence early in the process
3.5. Continuous Application Engineering
Some proponents of rapid development methods see them as a replacement for software and information engineering techniques. In addition, many writers of iterative and prototyping methods avoid formal techniques.
But abandoning what we have learned about building high quality systems is not the answer. Many of the frustrations with software engineering have come about from two sources (Radical Software Development. A Framework. Sapiens. 1994).
First there is the confusion between the techniques themselves (data flow modelling, entity relationship modelling, object modelling) and the "Methodologies" that have been developed to incorporate many of these techniques. No matter what kind of project is undertaken, some analysis work is required. We need to use whatever appropriate techniques we have in our tool bag to accomplish that analysis.
Secondly, because these tools are used by analytical people who not only believe in high quality but often in the higher calling of perfection, the tendency is to use the technique far in excess of any overall project benefit.
"Good enough" is not in the Rapid Application Development (RAD) vocabulary. Combined with a lifecycle that confuses deliverables with activities, we end up with an endless list of detail about the wrong things.
3.6. Dedicated Teams
Much of the process described in this framework is oriented towards a high performance team environment. From Joint Application Development (JAD) sessions to daily team interactions, much of the speed and quality of development depends on building good teams. This parallels the emphasis in many organisations today on "teams" (Bayer S. and Highsmith J. 1994).
For Rapid Application Development (RAD) projects, fewer than ten should be the core team. The intense interaction necessary for a team to 'jell" is impossible with larger groups. In selecting the team, a multi-disciplinary approach with respect to skills needs to be taken. The skills include technical skills, user business skills, problem solving and decision-making skills and interpersonal skills.
Core team members should be dedicated to the project full time. Given the realities of most organisations, full time may not mean 100%, but it should at least be 85%. Part of the reason Rapid Application Development (RAD) works is that it demands an organisation abandon much of the staff fragmentation so general when projects take years to complete.
Concentration of resources is key to speed. Depending on the project, and again organisational reality, user involvement on a core team may be somewhat less. A key point here is that the user core team member needs daily involvement with the team.
The team also needs to be co-located. Again, part of the reason Rapid Application Development (RAD) projects are faster is the intense interaction and communication between team members. High levels of feedback on progress, both with users and among team members are critical. Many organisations set up team rooms to be used for projects.
3.7. A Rapid Application Development (RAD) Project Lifecycle Example
3.7.1. Project Selection
Project selection insures the project conforms to the criteria that help insure the project is successful. The most basic criteria are:
An involved executive sponsor
More weighted towards information processing rather than scientific work
A significant user interface
3.7.2. Getting started — Produce Version 1.0
Usually, a major objective of version 1.0 is to engage the user in the development process. The team needs to stress getting the project off on the right track, engaging the user(s), and refining the process to their particular project and organisation.
3.7.3. Project Initiation consist of the following activities:
Identify the Executive Sponsor Review the project data
Assemble a dedicated professional team Conduct product training
Conduct Rapid Application Development (RAD) training
3.7.4. Project Planning
The initial Joint Application Development (JAD) session is one of the most important activities in the project. During this session both project management and application specifications information are gathered. Some of the documentation may be accomplished in smaller core team meetings
after the actual Joint Application Development (JAD) session. Project planning consist of the following activities:
Review the business direction Determine project scope
a High level business functions
a Context diagram, Entity Relationship Diagram (ERD), process model, key outputs
a Analyse data requirements a Analyse system architecture Estimate the project size
Estimate the resource this includes people and time Develop quantifiable measures of success
Conduct project risk assessment Create the Version plan
3.7.5. Obtain project approval
A brief session with the executive sponsor and other involved managers to review the results of the project kick-off and Joint Application Development (JAD) sessions and get approval to proceed with at least version 1.0 of the application.
3.7.6. Prepare for development
Once the initial Joint Application Development (JAD) session and project planning has been accomplished, the core team must rapidly get ready for starting development. With only 3-4 weeks usually allowed for the first version, some of the preparation work may need to start even earlier.
For example, finding a war room often requires several weeks of primary time. The activities included in the preparation for development is as follows:
Define project management structure and assign roles Establish the technical environment
Identify project standards Numbering standards Naming conventions Documentation standards User interface standards
Define a change management strategy Conduct data administration activities
3.7.7. Develop the Application
Specific components of the version plan would replace the develop online/batch and develop client/server tasks below.
3.7.7.1 Specify, design, develop and deliver Version 1.0
Develop Basic Object Models — Context diagram, Entity Relationship Diagram (ERD), process model, key outputs, design models
Develop online/batch components Develop client/server components
Prepare for Focus Group — unit and system testing Conduct Version 1.0 focus group
Conduct technical walkthrough
Specify Coding techniques and standards
Review overall technical design architecture strategy Produce detailed Version 2.0 plan
Revise overall project plan Develop the Application
3.7.7.2 Specify, design, develop and deliver Version 2.0 Develop Basic Object Models
Develop online systems Develop batch systems
Conduct data administration activities Test data creation/administration
External data conversions and migration
Conduct Version 2.0 focus group Conduct technical walkthrough Coding techniques and standards Critical path performance
Produce detailed Version 3.0 plan Revise overall project plan
Develop the Application
3.7.7.3 Specify, design, develop and deliver Version 3.0 Develop Basic Object Models
Develop online systems Develop batch systems Conduct data administration Test data creation/administration
External data conversions and migration
Prepare for Focus Group — Unit and system testing Conduct Version 3.0 Focus Group
Conduct technical walkthrough Full Performance Audit
Capacity Planning
Produce detailed Production Version plan Revise overall project plan
Completing It — Produce Version4.0 Develop the Application
3.7.7.4 Specify, design, develop and deliver Version 4.0 Develop Basic Object Models
Develop online systems Develop batch systems Conduct data administration Test data creation/administration
After completion of Version 4.0 the following activities still needs to be completed:
External data conversions and migration Conduct Unit and System Integration Testing Implement security
Prepare training materials and user documentation Conduct Final Quality Assurance and Release Conduct Project Acceptance Testing
Conduct final system integration testing and tuning a Performance stress testing
a Multi-user testing a Regression testing
a Exercise backup and recovery procedures Conduct Product Rollout
a User training a System testing
a Operational Plan
a Technical documentation
Develop technical support and maintenance plan Post-mortem
3.8. Summary
The traditional life cycles methods still used to today can be a very slow process. User requirements are often frozen and by the time the system is completed the users requirements changed.
Because of the competitive nature of the business environment today more information is needed faster and more accurate than ever before. This creates the need for better and faster systems. The draw back to this is that most of the Information Systems departments budget is spent on maintaining current systems. The result is a backlog of systems. Rapid Application Development (RAD) is the only answer to this problem.
Rapid Application Development (RAD) is considerably different from traditional methodologies. Rapid Application Development (RAD) deliver solutions designed to meet the users needs today and propel them into tomorrow's business marketplace.
The central theme of Rapid Application Development (RAD) is that it is a "User-Centric" philosophy of application development. All the attention and focus of the development effort is geared towards managing and satisfying the clients expectations.
Rapid Application Development (RAD) is an iterative process. As the symbol earlier shows, PLAN, BUILD, and FOCUS. And then do it again. The basics are just that simple —focus on the client and iterate through a plan, build, focus cycle until its right. The rest is all details.
The primary focus in a Rapid Application Development (RAD) project is "timeboxing" projects. Making time the least flexible success criteria, and making trade-offs in other dimensions such as feature set.
Probably the most difficult concept for many developers and managers accustomed to more traditional approaches to interpret is that the chances of a software development getting it "right" the first time are very small. In a Rapid Application Development (RAD) process different versions of the program are developed.
Rapid Application Development (RAD) is less about technology than it is about process and people. The project team consists of resources that are more general in skills rather than specialised skills.
To ensure that there is quality in system development it is important to enforce standards, structure and discipline. The Rapid Application Development (RAD) methodology lays out a prescribed process to project managers to make sure it is accomplished.
