Rapid Application Development (RAD) Processes 1
TABLE OF CONTENT
Rapid Application development (RAD) Processes 1
Various RAD (Rapid Application Development) Methodologies 4
1. Agile Software Development 5
2. Joint Application Development (JAD) 8
3. EXTREME PROGRAMMING (XP) 11
4. Scrum Development Process 18
5. Lean software development (LD) 22
References 26
Rapid Application development (RAD) Processes
Today, business moves faster, and clients tend to change their minds more frequently over the course of a project’s development life cycle. Of course, they expect the development team to adapt to their needs and modify the structure of an application quickly. Fortunately, the use of scripting languages like Perl and PHP makes it easy to apply other programming strategies, such as rapid application development (RAD).Rapid Application Development process deals with Software engineering/management field. It refers to the type of Software development process which minimizes the pre planning phase, and results in more rapid software development lifecycle. RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles. The idea behind this methodology is to start developing as early as possible so that clients can review a working prototype and offer additional direction. The application then gets built in an iterative process, releasing rich versions in short development cycles. RAD calls for the interactive use of structured techniques and prototyping to define user's requirements and design the final system. Using structured techniques, the developer first builds preliminary data models and business process models of the business requirements. Prototyping then helps the analyst and users to verify those requirements and to formally refine the data and process models. This results in a combined business requirements and technical design statement to be used for constructing new systems.
Figure1. Showing two different development process
Problem with Traditional style (Structure System Design and Analysis style)
RAD has a number of distinct advantages over the traditional sequential development model Figure1.
Some of the difficulties faced by the team member using traditional style of development are
· Applications took so long to build that requirements got changed before the system was complete. Resulting in inadequate or even unusable systems.
· Another problem was the assumption that a methodical requirements analysis phase alone would identify all the critical requirements, which is not very true.
· The cause of the problem was identified in the strict adherence to completion of one lifecycle stage before moving on to the next lifecycle stage. Specifically, building an application based on requirements that have been frozen at a point in time means that the longer development takes, the more likely that business needs will change and invalidate the requirements that the system being developed is based upon.
Factors for Rapid Development
Fast development does not mean a "quick and dirty" process. There should be no compromise between speed of development and quality. Several factors contribute to the success of rapid development by improving both the quality of the delivered system and the speed of delivery. Factors important for rapid development include:
* Intensive involvement of the end user in the design of the system.
* Use of prototyping, which helps users visualize and make adjustments to the system.
* Use of an integrated CASE toolset to enforce technical integrity in modeling and designing the system.
* Use of a CASE repository to facilitate the re-use of proven templates, components and systems.
* Use of an integrated CASE toolset to generate bug-free code from a fully validated design.
* User involvement in the Construction stage, allowing the details to be adjusted if necessary.
* Development of a task structure that encourages parallel project activities.
Various Stages of RAD
Requirements Planning
The Requirements Planning stage consists of a review of the areas immediately associated with the proposed system. This review produces a broad definition of the system requirements in terms of the functions the system will support. The deliverables from the Requirements Planning stage include an outline system area model (entity and process models) of the area under study, a definition of the system's scope, and a cost justification for the new system.
User Design
The User Design stage consists of a detailed analysis of the business activities related to the proposed system. Key users, meeting in workshops, decompose business functions and define entity types associated with the system. They complete the analysis by creating action diagrams defining the interactions between processes and data. Following the analysis, the design of the system is outlined. System procedures are designed, and preliminary layouts of screens are developed. Prototypes of critical procedures are built and reviewed. A plan for implementing the system is prepared.
Construction
In the Construction stage, a small team of developers, working directly with users, finalizes the design and builds the system. The software construction process consists of a series of "design-and-build" steps in which the users have the opportunity to fine-tune the requirements and review the resulting software implementation. This stage also includes preparing for the cutover to production.
In addition to the tested software, Construction stage deliverables include documentation and instructions necessary to operate the new application, and routines and procedures needed to put the system into operation.
Implementation
The implementation stage involves implementing the new system and managing the change from the old system environment to the new one. This may include implementing bridges between existing and new systems, converting data, and training users. User acceptance is the end point of the implementation stage.
Core Elements of Rapid Application Development
RAD has many core elements that make it a unique methodology including prototyping, iterative development, time boxing, team members, management approach, and RAD tools.
Prototyping
A key aspect of RAD is the construction of a prototype for the purpose of jumpstarting design and flushing out user requirements. The objective is to build a feature light version of the finished product in as short an amount of time as possible, preferably days. The initial prototype serves as a proof of concept for the client, but more importantly serves as a talking point and tool for refining requirements. Developing prototypes quickly is accomplished with Computer Aided Software Engineering CASE tools that focus on capturing requirements, converting them to a data model, converting the data model to a database, and generating code all in one tool
Iterative Development
Iterative development means creating increasingly functional versions of a system in short development cycles. Each version is reviewed with the client to produce requirements that feed the next version. The process is repeated until all functionality has been developed. The ideal length of iterations is between one day (which is closer to Agile Methodologies) and three weeks. Each development cycle provides the user an opportunity to provide feedback, refine requirements, and view progress (in focus group session meetings). It is ultimately the iterative development that solves the problems inherent in the inflexible methodologies created in the 1970's.
Time Boxing
Time boxing is the process of putting off features to future application versions in order to complete the current version in as short amount of time as possible. Strict time boxing is an important aspect of RAD, because without it scope creep can threaten to lengthen development iterations, thus limiting client feedback, minimizing the benefits of iterative development, and potentially reverting the process back to a waterfall methodology approach.
Team Members
The RAD methodology recommends the use of small teams that consist of experienced, versatile, and motivated members that are able to perform multiple roles. As the client plays a vital role in the development process, dedicated client resources must be available during the initial Joint Application Development (JAD) sessions as well as Focus Group Sessions conducted at the end of development cycles. Development teams should ideally have experience in Rapid Application Development and should have experience with the Computer Aided Software Engineering tools.
Management Approach
Active and involved management is vital to mitigate the risks of lengthened development cycles, client misunderstandings, and missed deadlines. Above all management must be stalwart and consistent in their desire to use the Rapid Application Development methodology. In addition to enforcing a strict timeline, management must focus on team member selection, team motivation, and on clearing bureaucratic or political obstacles.
RAD Tools
One of the primary objectives of the Rapid Application Development methodology developed by James Martin in the late 1980's was to take advantage of the latest technology available to speed development. Clearly the technology of the 1980's is obsolete today, but RAD's focus of the latest tools is as important today as it was when the methodology was initially created. This article has a section dedicated to tools following the process section.
Advantages
Increased Speed, As the name suggests, Rapid Application Development's primary advantage lies in an application's increased development speed and decreased time to delivery. The goal of delivering applications quickly is addressed through the use of Computer Aided Software Engineering or CASE tools, which focus on converting requirements to code as quickly as possible, as well as Time Boxing, in which features are pushed out to future releases in order to complete a feature light version quickly.
Increased Quality, Increased quality is a primary focus of the Rapid Application Development methodology, but the term has a different meaning than is traditionally associated with Custom Application Development. Prior to RAD, and perhaps more intuitively, quality in development was both the degree to which an application conforms to specifications and a lack of defects once the application is delivered. According to RAD, quality is defined as both the degree to which a delivered application meets the needs of users as well as the degree to which a delivered system has low maintenance costs. Rapid Application Development attempts to deliver on quality through the heavy involving of users in the analysis and particularly the design stages.
Disadvantages
Reduced Scalability, Because RAD focuses on development of a prototype that is iteratively developed into a full system, the delivered solution may lack the scalability of a solution that was designed as a full application from the start.
Reduced Feature, Due to time boxing, where features are pushed off to later versions in favor of delivering an application in a short time frame, RAD may produce applications that are less full featured than traditionally developed applications. This concern should be addressed as soon as possible through clear communication with the client as to what will be delivered and when.
Various RAD (Rapid Application Development) Methodologies
Different types of RAD development methodologies and utilize a selected method for a small project life cycle.
1. Agile Software Development
Agile software development methods attempt to offer once again an answer to the eager business community asking for lighter weight along with faster and nimbler software development processes. This is especially the case with the rapidly growing and volatile Interact software industry as well as with the emerging mobile application environment application. Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("time boxes") that typically last from one to four weeks. All iterations involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. Iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of iteration. An agile software project intends to be capable of releasing new software at the end of iteration. At the end of iteration, the team reevaluates project priorities. Multiple iterations may be required to release a product or new features. Team composition in an agile project is usually cross functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality iteration requires. Agile methods emphasize real-time communication, preferably face-to-face, over written documents. Most agile teams are located in a bullpen and include all the people necessary to finish the software. At a minimum, this includes programmers and the people who define the product such as product managers, business analysts, or actual customers. The bullpen may also include testers, interface designers, technical writers, and management. Agile methods also emphasize working software as the primary measure of progress.
An Introduction to Agile Software development Process
Studies have shown that traditional plan driven software development methodologies are not used in practice. It has been argued that traditional methodologies are too mechanistic to be used in detail. As a result, industrial software developers have become skeptical about new solutions that are difficult to grasp and thus remain unused. Agile software development methods, “officially” started with publication of the agile manifesto, make an attempt to bring about a paradigm shift in the field of software engineering. Agile methods claim to place more emphasis on people, interaction, working software, customer collaboration, and change, rather than on processes, tool, contract and plans. A number of promising new methodologies claiming conformance to these agile principles have been introduced. Yet, no systematic review of the agile methods has been attempted [1].
Agile methods: Embracing Change
Agile methods stress productivity and values over heavyweight process overhead and artifacts. The Agile Manifesto [3], a concise summary of agile values, was written and signed in 2001 although agile methods have existed since the early 90s. Agile methods promote an iterative mechanism for producing software, and they further increase the iterative nature of the software lifecycle by tightening design-code-test loop to at least once a day (if not much more frequently) as opposed to once per iteration [2].