1. Rapid Application Development
1.1. Rapid application development is a software development methodology that uses minimal planning in favour of rapid prototyping. In RAD model, the functional modules are developed in parallel as prototypes and are integrated to make the complete product for faster product delivery. Since there is no detailed pre-planning, it makes it easier to incorporate the changes within the development process. RAD projects follow iterative and incremental model and have small teams comprising of developers, domain experts etc. Who are working progressively on their component or prototype. The most important aspect of this model to be successful is to make sure that prototypes are reusable.
1.1.1. RAD model distributes the analysis, design, build and test phases into a series of short, iterative development cycles. - Business Modeling: The business model for the product under development is designed in terms of flow of information and the distribution of information between various business channels. A complete business analysis is performed to find vital information for business, how it can be obtained, how and when is the info processed and what are the factors driving successful flow of information. - Data Modeling: The information gathered in the Business modeling phase is reviewed and analysed to form sets of data sets is identified and defined. The relation between these data objects are established and defined in detail in the relevance to the business model. - Process Modeling: The data objects sets defined in the Data modeling phase are converted to establish the business information flow needed to achieve specific business objectives as per the business model. `the process model for any changes or enhancements to the data objects sets is defined in this phase. Process descriptions for adding, deleting, retrieving or modifying a data object are given. - Application Generation: The actual system is built and coding is done by using automation tools to convert process and data into actual prototypes. - Testing and Turnover: The overall testing time is reduced in the RAD model as the prototypes are independently tested during every iteration. However, the data flow and the interfaces between all the components need to be thoroughly tested and complete test coverage. Since most of the programming components have already been tested, it reduces the risk of any major issues.
1.1.1.1. RAD Model Application: - RAD should be used only when a system can be modularised to be delivered in an incremental manner. - It should be used if there is a high availability of designers for modeling. - It should be used only if the budget permits use of automated code generating tools. - RAD SDLC model should be chosen only if domain experts are available with relevant business knowledge. - Should be used where the requirements change during project and working prototypes are to be presented to customers in small iterations of 2-3 months.
1.1.1.2. Advantages: - Changing requirements can be accommodated. - Progress can be measured. - Iteration time can be short with use of powerful RAD tools. - Productivity with fewer people in a short time. - Reduced development time. - Increases reusability of components. - Quick initial reviews occur. - Encourages customer feedback. - Integration from very beginning solves a lot of integration issues.
1.1.1.3. Disadvantages: - Dependency on technically strong team members for identifying business requirements. - Only system that can be modularises can be built using RAD. - Requires highly skilled developers/designers. - High dependency on modeling skills. - Inapplicable to cheaper projects as cost of modeling and automated code generation is very high. - Management complexity is more. - Suitable for systems that are component based and scalable. - Requires user involvement throughout the life cycle. - Suitable for project requiring shorter development times.
2. Agile Methodologies
2.1. Agile model believes that every every project needs to be handled differently and the existing methods need to be tailored to best suit the project requirements. In Agile, the tasks are divided to time boxes (small time frames) to deliver specific features for a release. Iterative approach is taken and working software build is delivered after each iteration. Each build is incremental in terms of features; the final build holds all the features required by the customer.
2.1.1. Advantages: - Very realistic approach to software development. - Promotes teamwork and cross training. - Functionality can be developed rapidly demonstrated. - Resource requirements are minimum. - Suitable for fixed or changing requirements - Delivers early partial working solutions. - Good model for environment that change steadily. - Minimal rules, documentation easily employed. - Enables concurrent development and delivery within an overall planned context. - Little to no planning required. - Easy to manage. - Gives flexibility to developers.
2.2. Most popular Agile methods: - Rational Unified Process - Scrum - Crystal Clear - Extreme programming - Adaptive Software Development - Feature Driven Development - Dynamic systems development method.
2.3. Agile Manifesto principles: - Individuals and interaction: In Agile development, self-organisation and motivation are important, as are interactions like co-location and pair programming. - Working Software: Demo working software is considered the best means of communication with the customers to understand their requirements, instead of just depending on documentation. - Customer collaboration: As the requirements cannot be gathered completely in the beginning of the project due to various factors, continuous customer interaction is very important to get proper product requirements. - Responding to change: Agile development is focused on quick responses to change and continuous developments.
2.3.1. Disadvantages: - Not suitable for handling complex dependencies. - More risks of sustainability, maintainability and extensibility. - An overall plan, an agile leader and agile PM practice is a must without which it will not work. - Depends heavily on customer interaction, so if customer not clear, teams can be driven in the wrong direction. - There is a very high individual dependency, since there is minimum documentation generated. - Transfer of technology to new members maybe quite challenging due to lack of documentation.