IT3101- Rapid Application Development

Course Details Lectures – 30 hours Practical - 60 hours

Learning Outcomes At the end of the module the student will be able to: Explain Rapid Application Development (RAD) concepts Determine environments where RAD is suitable and applicable Use best practices in RAD Use RAD tools and environments for software application development

Outline Syllabus Introduction to RAD Common issues in RAD RAD tools and environments Estimation and scheduling in RAD RAD best practices RAD development project (Using Netbeans, Visual Studio or similar tools)

Assessment Criteria Continuous Assessment ◦ Classroom discussions and assignments - 15% ◦ Self directed RAD development project – 45% End of semester examination ◦ Structured examination paper - 40%

Reference Whitten, Jeffrey L.; Lonnie D. Bentley, Kevin C. Dittman. (2004). Systems Analysis and Design Methods. 6 th edition. ISBN X. Steven McConnell, Rapid Development, WP Publishers & Distributors (P) Ltd. ISBN:

Supplementary reading pt.pdf

IT3101- Rapid Application Development Week1- Introduction to RAD

What is Rapid Development ? Software development process that allows usable systems to be built within a short period (as little as 2-3 months), often with compromises, without harming the quality, cost, performance or maintainability. It is a generic term with the meaning “speedy development” or “Shorter schedule”

Some of the Principles behind the definition 20/80 rule - Sometimes a usable 80% solution can be produced in 20% of the time required to produce a total solution. Sometimes the business requirements for a system can be fully satisfied even if some of its operational requirements are not satisfied. Some times the acceptability of a system can be assessed against the agreed minimum useful set of requirements

Issues in Traditional Software Development Cost and schedule overruns Cancelled projects High turn over Friction between managers, developers and customers Product not fit for business

Typical reasons for software projects failure a) Risks associated with teams. if a team of developers, end users, and systems maintainers have not worked together before and do not learn to communicate effectively, they are not likely to develop a successful system without schedule delays or cost overruns. Other risks are associated with the lack of well-defined or well-understood processes.

b) Risks associated with technology. Teams that pursue a new technical approach (for example, the first venture into client-server computing) finds that the lack of experience with a new technology, architecture, or development approach contributes to failure.

Typical reasons for software projects failure cont. c) Risk associated with requirements. most often-cited reason for failure is poor management of requirements characterized by frequently changing requirements, requirements that are not well understood, and requirements explosion.

Problems Addressed by RAD With Conventional methods, – there is a long delay before the customer sees any results – developments can take a long time and some times a business may change during that period – there is nothing until 100% of the process is finished.

History of RAD Spiral Model Evolutionary life cycle RIPP-Rapid Iterative Productive Prototyping RAD - Early 90’s

Classic mistakes To achieve rapid development you need to avoid making any big mistakes. Some inefficient development practices have been chosen so often with such predictable bad results that they deserve to be called “classic mistakes”. They have been made so often and their consequences have become easy to predict. The classic mistakes rarely produces the results that people hope for.

Project was riddled with mistakes and all the king’s managers and tech leads couldn’t rescue the project for any one’s sake

People related classic mistakes Undermined motivation Weak personnel Uncontrolled problem employees Heroics – Mid-level management placing a higher premium on can-do attitude than steady and consistent progress and meaningful progress reporting. As a result, impending schedule slips, acknowledged or reported up the management chain at the last minute.

People related classic mistakes Adding people to a late project Noisy, crowded offices Friction between developers and customers Unrealistic expectations

People related classic mistakes Lack of effective project sponsorship – Without executive sponsor, the higher management may force to accept unrealistic deadlines. Lack of stakeholder buy-in Lack of user input

People related classic mistakes Politics placed over substance – Politics placed over substance : “Politicians” concentrating on relationships with their managers. “Isolationists” keeping to themselves, creating project boundaries kept close to non-team members. Wishful thinking Closing eyes and hoping some thing works when there is no reasonable basis for the thinking. Undermines meaningful planning.

Product Related Classic Mistakes Requirements Gold Plating: Some projects can have more requirements than they needs. Feature Creep: Average project goes through about 25% change in requirements over the project life. Such changes can be fatal to RAD. Developer gold plating: Developers are fascinated by new technology and some times keen to try out new features of a language or environment etc irrespective of the real need.

Product Related Classic Mistakes Push-me, pull-me negotiation: o A manager approves a schedule slip on a project that is progressing slower than expected and then adds completely new tasks. Research Oriented Development: ◦ If the project strains the limits of computer science by requiring the creation of new algorithms or new computing practices, it is software research. ◦ Software development schedules are predictable; software research schedules are not even theoretically predictable.

Technology Related Classic Mistakes Silver Bullet Syndrome: o Jack and the magic beanstalk! Did the CASE tool grow into a magic beanstalk? The Naïve belief that a single tool or technology will by itself dramatically reduce development time. Too much reliance on the advertised benefits of previously unused technologies.

Overestimated savings from new tools or methods: Organizations rarely improve productivity by giant leaps irrespective of the new tools they acquire. New tools are associated with learning curves.

Technology Related Classic Mistakes Switching tools in the middle of the project: ◦ Learning curve, rework, and mistakes with a new tool cancel out benefits in the middle of a project. Lack of automated source-code control: ◦ Failure to use automated source code control exposes projects to unnecessary risks.

Process related classic mistakes Overly optimistic schedules Setting an overly optimistic schedule sets a project up for failure by underscoping the project, undermining effective planning, and abbreviating critical upstream development activities. Insufficient risk management Contractor failure Insufficient planning Abandonment of planning under pressure Wasted time during fuzzy front end ◦ Time normally spent in the approval and budgeting process

Process related classic mistakes Shortchanged upstream activities: ◦ Disastrous example: When project schedule is in trouble and the team was asked to show the design- “ We didn’t have time to do a design!!!” Inadequate Design ◦ Rushed projects sometimes undermine design by not allocating enough time. This may create a pressure cooker environment!

Process Related Classic Mistakes Shortchanges Quality Assurance: Shortcutting 1 day of QA activity early in the project is likely to cost you from 3 to 10 days of activity downstream. Insufficient Management Controls: ◦ provide timely warnings of possible schedule slips. Some times controls abandoned once schedule slip occurs.

Process Related Classic Mistakes Premature or Overlay frequent convergence ◦ Shortly before a product is scheduled to be released, there is a push to prepare the product for release. On rush projects there is a technology to force convergence early. ◦ This wastes time and prolong the schedule. Omitting necessary tasks from estimates: ◦ Lack of record keeping in previous projects. Less visible tasks gets omitted and they may add up to percent. Planning to Catch up later Code-like-hell programming

Different Life Cycle Models Waterfall model Spiral Model Evolutionary prototyping RAD Agile Development Etc.

Choosing most rapid life cycle model Choosing the most effective life cycle model for a project depends on, ◦ How well the customer and client understand the requirements at the beginning of the project? ◦ How well the system architecture is understood? ◦ How much reliability is needed? ◦ How much planning ahead and designing ahead is needed during a project for future versions?

Choosing most rapid life cycle model cont. How much risk does this project entail? Is it constrained to a predefined schedule? Does it need to be able to make midcourse corrections? Does it need to provide the customers with visible progress throughout the project? How much sophistication is needed to use the lifecycle model successfully?

Why use RAD Good reasons – To converge early towards a design acceptable to the customer and feasible for the customer – To save development time, possibly at the expense of economy or product quality (Criterion for Acceptance : Fit for Business!)

Why use RAD Bad reasons – To prevent cost overruns – RAD requires product development teams already disciplined in cost management – To prevent runaway schedules - RAD requires product development teams already disciplined in time management

What kind of RAD? Effect of development approach on Development Approach ScheduleCostProduct Average practiceAverage Efficient development (balanced approach) Better than average Better than average Better than average Efficient development (with best schedule) Much better than average Much better than average Much better than average All-out- rapid development Fastest possible Worse than average Worse than average

RAD RAD - a revolutionary software model of the 1990's, while living up to its promise is still an active area for continued research RAD is a approach typically relying on small well trained teams, use of evolutionary prototypes, and rigid limits on development time frames. RAD has proven to be a valuable software strategy.

RAD It is not without pitfalls and risks. Requires the right mix of methodologies, tools, personnel and management and the correct use of best practices. Its use depends upon complexity of the domain or application, the organizational environment, the skills of staff and management and the architectures and infrastructures available

RAD The optimal is a team of users and developers who can communicate effectively and successfully develop their products without schedule delays or cost over runs. experience counts! An experienced team, developing a similar system to one that it has previously developed, with a customer and end user with whom it can communicate well, is much more likely to produce high-quality software intensive systems on time and at cost.

RAD Management's function is to eliminate unnecessary tasks, streamline activities, and increase work time while the development staff reduces time per task Hence, having a well trained, fully collaborative team is an essential ingredient for success in a RAD project. The core of the team – should be full participants in project planning. – should stay together from start to finish. – Support tools should be provided to those who have skills in using them (SWAT)