Rapid Application Development free essay sample

Thesis statement. In a rapid changing environment, software systems must be delivered quickly in order to meet business delivery schedules. Spending months and years developing systems to high standards is fruitless if over time requirements change beyond recognition. Software development must serve its customers. Simple value-for-money systems that work are better than expensive and complex ones delivered late, over-budgeted and difficult to maintain. Abstract. Rapid Application Development (RAD) has long been promised to be a boon to the computing community. The idea is to develop a method of designing software so that the whole process is quick, painless and nearly effortless. RAD appears to have first become topical with the publication of a text by James Martin with the same title (Martin, 1992). In his publication Martin defines the main objectives of RAD as: high quality systems, fast development and delivery and low costs. RAD is an object-oriented approach to system development that includes a method of development as well as software tools. We will write a custom essay sample on Rapid Application Development or any similar topic specifically for you Do Not WasteYour Time HIRE WRITER Only 13.90 / page RAD is very similar to prototyping. Conceptually, their main purpose is to shorten the time in a traditional SDLC (system development life cycle) between the design and implementation. RAD is a helpful approach in new e-commerce web- based environments to make the difference by delivering an application to the web before their competitors. ? Hierarchical Structure of Topics: 1. History. 2. Essential aspects of RAD. 3. When to use RAD. 4. Disadvantages. 5. Conclusion. ? 1. History: Traditional lifecycles devised in the 1970s, and still widely used today (cascading, one-way steps of Stage wise or Waterfall), are based upon a structured step-by-step approach to developing systems. These old methods required revision and approval from the user before continuing with the next phase of development. This process can take too long and the customer’s requirements can change during the development cycle. Also it takes a long time before the user can see the results and is able to use the final product. In response to these rigid models of development Barry Boehm, Chief SW Engineer at TRW, introduced his Spiral Model. Through his model, Boehm first implemented software prototyping as a way of reducing risk. Other pioneer, Tom Gilb created another approach called Evolutionary Life Cycle. This one is based on an evolutionary prototyping rationale where the prototype is grown and refined into the final product. The work of Boehm and Gilb paved the way for the formulation of the methodology called Rapid Iterative Production Prototyping (RIPP) at DuPont in the mid-to-late 1980s. Then James Martin extended the work done at DuPont and elsewhere into a larger, more formalized process, which has become known as Rapid Application Development (RAD). ? Rapid Application Development is a term originally used to describe a software development process introduced by Martin in 1991. Martins methodology involves iterative development and the construction of prototypes. RAD compresses the step-by-step development of conventional methods into an iterative process. The RAD approach thus includes developing and refining the data models, process models, and prototype in parallel using an iterative process. More recently, the term and its acronym have come to be used in a broader, generic sense that encompasses a variety of techniques aimed at speeding application development, such as the use of web application frameworks and other types of software frameworks. . Essential aspects of RAD. RAD is normally seen with three or four phases and users are involved in all the phases. The first Phase The planning phase. Users and analysts need to identify the objectives of the application or system to identify information requirements arising from those objectives. This phase requires intense involvement from both groups not just signing a proposal. It may involve users from di fferent levels of the organization. The orientation in this phase is to solve business problems and the main purpose is to reach business goals. The second phase The design workshop. It is a design and refine phase. This phase is normally hands-on for all the participants. During the design workshop users respond to actual working prototypes and analysts refine the design models based on the user responses. If during this process, experienced users and analyst are part of the process, there is no doubt that this meeting can propel development forward at an accelerated rate. The third phase The implementation phase. In this phase, analysts and users are working together intensively to design the business or non-technical aspects of the system. When these aspects are agreed on, the systems are built and refined, the new systems or part of them are tested and introduced to the organization. The cutover phase If your team follows Martin’s approach normally because your team is replacing and old system with your RAD you will see this phase. In the cutover phase the new application is run in parallel with the old one in order to be tested, train the users and make any changes to the organizational procedures before the replacement of the old system occurs. If your project is implementing a completely new system you won’t have this phase there is no old system to run in parallel That’s why sometimes you only see three phases in RAD. Martin’s phases of RAD General Phases of RAD and the outputs of each phase Rapid Application Deployment Key Deliverables / Outputs RAD Development Phases RequirementsDesign / DevelopTest / Implement ?System Architecture / Preliminary Design Document ?Final Design Document ?System Code ?Test Plan / Scenarios ?Test Results ?User Documentation? Training Classes ?Final Service Level Agreement ?Operational Readiness USER IRM Sign-Off ?Project Closure Sign-Off Software tools for RAD The RAD methodology uses both computerized tools and human techniques to achieve the goals of high-speed and high quality. The success of any Rapid Application Development project is primarily dependent on the tools used. The power tools utilized in RAD are Computer-Aided Systems Engineering (CASE) tools. CASE tools have come a long way over the last two decades, helping us to overcome a lot of the software development problems through process innovations such as Rapid Application Development. Powerfully integrated CASE software is now available, as well as software that goes beyond traditional CASE limitations. CASE Maker’s Totem 5. 0 is one such product. Also software tools for RAD are often newer and often they are object-oriented tools, they include familiar programs such as: Microsoft Access, Microsoft Visual Basics, Microsoft Visual C++, and Microsoft Net. Most RAD applications have stayed on the small, PC-based side, although their true power may be for client/server applications that need to run across multiple platforms. The tools used should be easy to learn, powerful and allow the designers to interface their freshly minted application with other applications, databases and file types. Key objectives The key objectives of RAD are high quality systems, fast development and delivery and low costs. These objectives can be summed up in one sentence: the commercial need to deliver working business applications in shorter timescales and for less investment. A number of people see RAD as a complete approach to information systems development in that it covers the entire lifecycle, from initiation through to delivery. 3. When to use Rapid Application Development (RAD) Corporations have found that work organized stepwise incurs in unavoidable delays and errors as paper is handed off from person to person. Information Technology is one of the most powerful tools for breaking with traditional assumptions and rules about today’s business. One of the most innovative and successful change in IT business practices today is RAD. This new process takes advantage of automated tools and techniques to restructure the process of building information systems. RAD replaces hand-design and coding processes. These two processes depend a lot on the skills of isolated individuals. This slows down the process of development plus if the communication between these individuals is not good this will enormously affect the outcome of the team. Rapid Application Development is a better process, as it is much faster and less error prone than hand coding. Now days most organizations are faced with a large backlog of new systems to be developed. Over 65% of the typical Information System’s budget is spent on the maintenance of existing systems. Most of the time, these systems have little to no documentation and were developed with programming languages and database systems that are difficult and time consuming to change. There are two options for these companies upgrading their aging systems or building new applications. Conventional development lifecycles, however, are too slow and rigid to meet the business demands of today’s e-commerce. A new methodology must be implemented, one that allows organizations to build software applications faster, better, and cheaper. As an analyst, you will learn that certain applications and systems work will call for certain methodologies and that there is not a one size fits all. You can consider using RAD when: 1. Your team includes programmers and analysts who are experienced with RAD. 2. The project has pressing business reasons for speeding up a portion of an application development. 3. Your team is working with a novel e-commerce application and your development team believes that the customer’s business can sufficiently benefit over their competitors if as an innovator his application is among the first to appear on the Web. 4. The users are sophisticated and highly engaged with the organizational goals of the company. RAD enables analysts and developers the use of powerful CASE software which makes it possible for developers to create systems much faster than ever before. These new integrated CASE toolsets are breaking out of the bubble of traditional software development thought. They take application development beyond generation coding, just as generation, many years ago, surpassed textual coding. These tools enable a developer to drag-and-drop previously generated code, saving that developer the time and effort of individually hand-coding the text of the application. Common components The following appear to be the common components of RAD approaches: joint application design (JAD). RAD seems to be characterized by small development teams of typically four to eight persons. Such teams are made up of both developers and users who are empowered to make design decisions. This means that all RAD team members must be skilled both socially and in terms of the business. JAD workshops are usually expected to take place away from the business and developer environments in ‘clean’ rooms, that is, places free from everyday work interruptions and full of requisite support facilities such as flip charts, post-its, coffee, computers, etc. The emphasis is on highly focused problem solving. RAD projects seem to be typically of relatively small-scale and of short duration. Also, two to six months is frequently discussed as being a normal project length. The main rationale being that any project taking more than six months to complete is likely to be overtaken by business developments. Project control is seen to involve scoping the project by prioritizing development and defining delivery deadlines or’ time-boxes’. If the projects start to slip, the emphasis will be on reducing the requirements to fit the time-box. RAD is frequently discussed in terms of incremental prototyping and phased deliverables. Prototyping is essentially the process of building a system in an iterative way. Mostly these projects are conducted on applications that are highly interactive, have a clearly defined user group and are not computationally complex. 4. Disadvantages of RAD. RAD is a useful tool for analysts and developers but like everything in life, it also has Pros (advantages) and Cons (disadvantages). It is a faster way of producing applications since the users are involved from the beginning; therefore, the system is created faster. Those are good things for fast-paced businesses but it also has Cons. Some of these might make you think if RAD is actually as good as it looks and sounds. Some analysts still believed RAD is not as good as it sounds because the method may not be useful for large or highly complex projects. It also requires a very motivated team, capable of work cohesively together. The cost of the project is hard to estimate at the beginning of the project. It also requires a lot of commitment from the users involved in the project and that might be very difficult for important users to commit (managers, VP’s and so) which is necessary for the success of the project. Among other concerns some are: 1. For large (but scalable) projects, RAD requires sufficient resources to create the right number of RAD teams. 2. RAD projects will fail if there is no commitment by the developers or the clients to rapid-fire activities necessary to get a system complete in a much abbreviated time frame. 3. If a system cannot be properly modularized, building components for RAD will be problematic. 4. Agile methods produce very little written documentation and require a significant amount of post-project documentation. 5. The client may create an unrealistic product vision and request extensive gold-plating, leading the team to over- or under-develop functionality. 6. Product may lose its competitive edge because of insufficient core functionality and may exhibit poor overall quality. Other major concerns with RAD include the costs of maintaining clean rooms and of funding the extensive user involvement required for prototyping. Many organizations have found that the culture changes required for RAD are sometimes impossible to achieve either within the business as a whole or within project teams. Software engineers, too, are reluctant to embrace a development ethos that necessitates leaving their comfort zones and subjecting themselves to the intense periods of activity and accountability required for RAD . Conclusion Since 1992, when James Martin developed the idea of RAD, this new approach is been gaining momentum and is one of the tools in today’s tool box for analysts and developers. RAD and prototyping are pushing together to move the field forward on creating high quality applications on a short period of time. Today’s computer business has the option of being at the edge of their competitive market because they don’t have to wait for years to implement new technology to increase productivity. It all looks so good but after reviewing all the literature there is still a lot of places for improvement. For example: Some developers understand RAD to mean incrementally speeding up each stage of the traditional software life cycle. To others, RAD is primarily about automation and the extensive use of software development productivity tools. Many believe RAD is only suitable for small, relatively low-key projects. Others argue that RAD principles and techniques (joint Application Development, time-boxing, prototyping, and clean rooms, to name a few) can be applied to any software project but still RAD is accused of being anti-quality. It is commonly believed speed and quality are incompatible in software development. You can have one or the other but not both at the same time. In my opinion RAD is good for small projects where the users have the capability of commit their time with the developing team.