Julian Ashworth Software Product Services Ltd.

Transcription

1 Developing RADical SAS Applications Julian Ashworth Software Product Services Ltd. Higher quality, at lower cost, within a shorter time frame, are the pressures exerted on today's application developers. RAD is presented as a development approach that provides some relief from these pressures. RAD is seen as a means to develop better business systems faster. To date, though, there is no such thing as a commonly acknowledged definition as to what constitutes a RAD methodology. It means different things to different people. This has meant that vendors promote their tools, often misleadingly, as a RAD tool, rather than as a tool to be used in the RAD process. The end result is confusion in the market place as to what RAD is all about. This paper has two objectives. Firstly to give an understanding of why attention is being focused upon RAD and to outline the key features of the process. That it can be seen as a viable project management technique and not something quick and dirty. Project Managers should be aware that not all applications lend themselves to a RAD approach. The second objective is to explore how the SAS System can be used in the RAD process. Those features of the SAS System that lend themselves.. to the RAD approach,. such as prototyping, object oriented programming and iterative development, will be discussed. Businesses in the 1990's are facing an ever increasing variety of issues: corporate volatility, technological change, consumer power, cost control, political change and globalisation to name a few. These issues are relevant to all departments and the IT department is no exception. This applies whether the IT department is developing or modifying an application for the internal market (user of an internal department) or for sale on the external market. For the IT department developing applications the business issues most relevant are: 1) Improving the speed of development. That is reduce the time to market for applications to meet critical business needs. Rather than a one year life span, applications are required in a 3-6 months' time frame. 2) Reducing costs. The IT department is not immune from the drive to reduce costs. One way is to reduce the development and maintenance costs as far as possible. 3) Improving quality. The application must meet the business and customer needs. In a more business focused world just having a neat technical application will not suffice, it must meet the core business requirements. 3

2 Is Change Required? A significant number of IT projects are based around using traditional methodologies. Traditional methodologies are characterised by a sequential process of investigation, analysis, design, development and implementation. Hence a traditional approach is often called.a waterfall approach; one process flowing and leading into another. An important question to review is, are the current traditional methodologies responding to these challenges? The evidence seems to suggest not as; '80% of IS projects go over budget and schedule because system changes occur after requirements are frozen.' Source: ComputerworldlFirst Market Research. In the '1993 Fixed Price Contracting Survey' from the Computer Software and Services Association (CSSA) several factors were identified as being the reasons for overrunning projects. The figures below indicate the percentage of all respondents: Poor specification: Estimating: Change Control: Project Management: Price Pressure: 69% 33% 22% 17% 17% Asked as to what effect the overruns had, a range of answers were presented: Customer Relationships Suffer: Profit and Loss: Loss of quality: Loss of reputation: Late delivery: Staff Moral: 65% 54% 30% 22% 15% 13% So what is it about traditional methodologies that potentially may cause these problems. There are several characteristics of the traditional development process that may result in the problems identified above. Process too Complex For many the process is too complex. This results in a time consuming process with the effect that by the time the system has been developed the business requirements have changed. In a rapidly moving business it is important to get the application out quickly to meet the current business needs. The complexity of the process also means that there are volumes of documentation to contend with and manage, Keeping documentation in order is difficult even in the most well organised systems. I 1 4

3 r i ~ l ~ r' Lack of User Involvement Even where projects are completed on time, and hopefully to budget, other accusations are levied. One is the business needs are poorly met as the users are not adequately involved. After initial input at the start of the process the user requirements are often frozen. They then tend to have no other involvement until the' application is delivered months or years later. To compound this problem users are often unable to define their precise requirements so early in the development cycle. It is only later when they have a chance to use' the system do they start to clarify their requirements. At this stage the cost of change is demonstrablyhlgher than early on in the development cycle. Most users would rather have input at various stages of the development cycle rather than a big bang approach at the start. Difficulty of Testing Testing all the application at the end of a long development cycle is difficult to do well. There are pressure on the developers to get the system delivered before it is properly tested. Defining what tests should be carried out, getting hold of test data and expected results can easily lead to delays. Add to this the testing required because of change control makes the testing cycle complex and often takes longer than most people schedule. The complexity of the process, the lack of user involvement and the difficulty of testing are just three areas where the traditional methodologies have been criticised. Having identified areas of concern does not make it any easier to find alternative approaches. One of the reasons why the traditional approaches are popular is the comfort feeling they give to both client and developer. For the client the comprehensive documentation details the system to be delivered, for the developer it puts boundaries around their responsibility. This is especially so in the fixed priced projects that are becoming increasingly popular. The Alternatives So what are the alternatives? At the opposite end of the spectrum to the traditional methods is the 'just code it' approach. The pressure to start coding is usually high. Customers are spending money and they like to see someone coding early on in the project. Starting to code too early is often a bad mistake. At the start developers rarely have a full understanding of the business requirements and this usually results in considerable re-work occurring at some point in the future. Therefore something is required between the two extremes of 'just code it' and the traditional approaches. This is where RAD comes into play. Giving a precise definition for RAD is difficult. Computing is renowned for presenting ideas that are continually evolving. The concept of RDBMS as defined by Codd has undergone some modifications as has his definition of OLAP, redefined by SAS Institute to be OLAP++. Object Oriented programming too is a concept that many people have adapted to their own requirements. Similarly RAD is also a concept where there is no commonly agreed definition and many vendors, consultants and indeed businesses have come up with their own interpretation. This paper is not so ambitious as " i' 5

4 to define and detail a RAD methodology. Presented here is a look at the essential components of a RAD process. Proto typing Prototyping is, perhaps, the essential ingredient of the RAD process. Initially 4GL languages were identified as being appropriate tools for speeding up the coding process. The natures of these languages readily lend themselves to prototyping a system. In the early stages prototypes were often used to gain afeel for the application and then discarded. A typical approach these days, however, is to continually enhance the prototype building upon it until the application is completed. As a consequence RAD is often described as being an iterative development process, or evolutionary development. ' t::) Coding however involves only a small part of the overall development cycle. Therefore any methodology that only focuses on this element will have limited suitability. But RAD is more than this as it is aimed at the whole development cycle. Also, because you can build systems quicker does not mean that you can build them better. One measure of quality is the degree to which the system meets the business needs. User Involvement To achieve a higher level of quality, user involvement should be ongoing during the development cycle. This is one of the important concepts behind the RAD approach. Any RAD methodology should identify when and how the user can work along side the developer. The benefit is that as development progresses users can start to clarify their requirements and keep the project focused on the business issues. Also when the system is delivered user acceptance will be high due to their close involvement in the project. A process that combines the concept of proto typing with a high level of user involvement would seem to present a powerful approach to developing applications. There are several benefits to prototyping. It allows changes of mind, it clarifies the requirements on an ongoing basis, it reduces costly changes at the end, it gains commitment from the user, and it reduces the chance of any unwanted surprises at the end. What is required, however, is,some structure around which such a prototyping approach is run and managed. Without some sort of formal control the likelihood of a project being completed successfully is still limited. This control is exercised by the idea of timeboxing. Timeboxing Once the scope of the project is identified the project must be broken down into small and separate tasks. The rationale being, the smaller the task the easier it is to estimate so reducing the possibility of overrunning. A timebox is the period during which a task will be completed. Understanding the activities within a timebox is important. Typically these are: 6

5 1) An initial discussion between the user and the developer lasting half to one day where the task to be delivered is discussed. Here the user explains what he/she expects from the system and the developer can ask any questions. 2) After that initial meeting the developer quickly (possibly within 2-3 days) builds a prototype of that part of the application to be completed within the timebox. The prototype is then given back to the user to test it and review (.5 day). The user can then give feedback to the developer who will then incorporate the ideas into the next iteration of the prototype. Typically this iteration can occur two to three times in a timebox. 3) The timebox comes to conclusion with a meeting to demonstrate the deliverable from the task. The meeting should include a cross section of the business and IT project team. If re-work is required the deliverable is reassigned to a further timebox. If the prototype is accepted then it may be signed off as satisfactory. The signed off prototype may then become the primary starting point for another timebox. The walkthrough at the end of each timebox is extremely powetful. It means that constant testing is undertaken as well as the users accepting that part of the application as complete. The code can then be put under configuration management. The Way Forward Prototyping, a high level of user involvement and timeboxing are essential ingredients to a RAD process. However, whilst some vision of a new way forward can often be seen it is sometimes difficult to identify the next steps forward. The following techniques and approaches are considerations to take into account when approaching a RAD project. Select a Suitable Project Some projects are more suited to RAD than others. The types of project where RAD is appropriate are: i) Small to medium sized projects, typically in the 3-6 months time frame or shorter. ii) Systems that have a user driven front end and incorporate the newer approaches such as Graphical User Interface, Client Server or Object Oriented programming - typically those projects that involve a 4GL. Select an Appropriate Tool The SAS System is a powerful tool that can be used in the RAD process. To be especially useful in the RAD process any 4GL tool must, however, be more thai). a powetful programming language. The SAS System goes beyond the basic RAD requirements by providing the capability for Object Oriented Programming. In particular the availability in the SAS System of re-usable business objects is of great benefit to the RAD process. The ability to access a wide range of data sources is also an element in selecting the SAS System for your development tool Often time is lost because software cannot access all the necessary data. 1

6 Appropriate tools should allow transparent access to virtually any data sources. Not only can the SAS System provide access to flat files and indexed files but with SAS/ACCESS read, write and update access is possible to a variety ofrdbmss like Oracle, Ingres, Sybase and DB2. Flexibility is also important especially in two critical areas: client server and portability. The key issue that lies behind client server is to ensure that the most appropriate hardware platform is chosen to perform particular tasks. The respected Gartner Group has identified five client server models. Whilst many tools can accommodate some of the models, the SAS System is one of the few tools that can easily handle all five. Having invested in the development of a business application it is important that the application is not locked into one particular hardware configuration. IT is a dynamic world and therefore any application should have the potential to be moved to alternative platforms thereby protecting the investment. The SAS System helps protect this investment due to the wide range of platforms it currently supports. An additional benefit of the SAS System's portability is that the initial development can be undertaken on, for example PCs, before moving to a production platform such as UNIX. Any tool should not restrict the user in terms of what they can have. The SAS System can provide a comprehensive range of ready made techniques from report writing to advanced statistical analysis. The greater breadth and depth of the SAS System over other tools is especially seen when more specialist applications are required, such as complex statistical analysis, decision support, or multimedia capabilities. With the SAS System users can get the system they want and not one tailored to what the software can provide. Initial Study Prior to development one problem is how to define the system required without the need for the detailed paperwork required for traditional approaches. Some view of what the system will look like is obviously of importance. Consequently even with the RAD approach there has to be an initial study of the requirements. On a 3-6 month project estimates of 3-4 weeks for an initial study are considered appropriate. The outcome from this work is essentially a graphical representation of what the system will look like. Typical of this approach is the SystemCraft use of Business Function Diagrams (BFD). The purpose of diagrams such as the BFD is to describe the key functionality required by the business from the application. Little thought is given to what part IT will play in the process at this stage; the focus is on the business needs. As it is a graphical representation the users find it easier to follow than copious pages of text. The benefits are real: they are simple and easily understood by everyone on the project, particularly users who may not be that keen on entity diagrams; they define the scope of the system; they provide an excellent tool for planning and reporting progress; plus they shows the breadth of the system. The more complex the application the greater the number and level of diagrams and charts that can be defined. If required the graphical diagrams can go down to the level of data entity diagrams. Text need not be forgotten as it can be used to back up any diagrams as required. Joint Development Sessions 8

7 Where several users are involved the concept of Joint Development Sessions (IDS) can be beneficial The principle here is to get both users and developers together for half to one day sessions focused on planning and designing the system. The outcome from the meetings is a clear idea of the functionality required by the system. The deliverable can be something like the BFD. Defining the Timebox length Once the application has been designed the next step is to break the project down into separate tasks. Each task will be completed within a timebox. How long the timebox should be is one area for discussion. Some observers argue that a three week time span is appropriate. However if the situation dictates it a one or two month timebox may be appropriate. Several factors dictate the length of the timebox. Getting a high degree of user involvement can be difficult. hntially users are enthusiastic but as the project progresses other factors take up their time leaving them less committed to the project. Therefore it is important to have an appreciation of the time required for such user involvement. As a result it is often important to get senior management approval when adopting a RAD approach. For a three week timespan a user commitment is high. If it is difficult to get user involvement then a longer timebox may be appropriate. This obviously means the task is more complex than would be required for a three week timespan. Another reason for selecting a longer timebox is that development may take place some distance from the users. It may be advantageous for all if the developers build the application off-site. Having a timebox of three to four weeks, with three iterations of the prototype, is not practical in this scenario. What is more practical is to have, say, a timebox of one month with one iteration planned before a formal walkthrough. Not to be underestimated is the level of Project Management required especially if a three week timebox is selected. With such a short timebox the level of work requires careful monitoring and planning. The planning is particularly challenging as whilst the user is assessing one iteration of the prototype the developer may be working on another task. Consequently the level of Project Management required can be significant. Fixed Priced RAD Many oftoday's projects are undertaken on a fixed price basis. For the developer, reducing the project down into small and manageable tasks gives the project a very tight focus. With a timebox of three weeks there is a reduced chance that parts of the project will overrun. With a longer timebox the complexity of what is to be coded increases and therefore this leads to an increased chance of overrunning. This for the developer is naturally of concern due to the extra costs incurred. However, it should also be a concern to the client. Surely it is better to have a 90% complete application delivered on time than a 100% one delivered late. Rare is the application that does not go through some modifications soon after delivery as the business needs change. 9

8 With a longer timebox, therefore, one alternative is to list in order of priority the functionality required. Then select a date in the future that will be the cut-off day. The developer then codes as much of the functionality as he/she can into the system prior to the cut-off day. The cut-off day is firm so even if not all the functionality is coded the prototype is then subject to a walkthrough. This approach still ensures the key components of the system are incorporated into the application. It is acknowledged that this approach requires trust between the user and developer, but it can be an extremely productive approach and can be considered fair to both sides. Conclusion Traditional methodologies may still have their place but with IT projects renowned for overrunning a fresh look at the way we approach application development is possibly required. The newer technologies of 4GL languages, graphical user interfaces, Client Server and Object Orientation also suggest an alternative approach is feasible. RAD provides an alternative that in principle overcomes some of the deficiencies of the traditional approach. It is all about developing systems faster and developing better quality systems in a rapidly changing business environment. RAD provides a complete project management methodology that defines a flexible process by which an application is built and continually refined. The blending of proto typing and user involvement throughout the development cycle suggest a powerful combination for developing applications. The use of the timebox, where the developer and user can work together, gives a framework around which the project can be run and managed. RAD is a method that can be modified to meet your needs. The concept of the RAD does not mean quick and dirty. It is an approach that offers real returns in speedier delivery of quality systems. 1. For more infonnation on SystemCraft call UK ; or DSDM call UK All trademarks are acknowledged. Julian Ashworth Software Product Services Ltd Regent House The Broadway Woking, Surrey GU215APUK Tel: Fax: Compuserve ,1352 May