IT3101: Rapid Application Development Lec-1

What is Rapid Application Development? Software development process that allows usable systems to be built within a short period (2-3 months) Term for – “speedy development” or –“Shorter schedule”

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

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

Reasons for software projects failure a) Risks associated with teams. –have not worked together –do not learn to communicate effectively –Not consider schedule delays or cost overruns –lack of well-defined or well-understood processes. b) Risks associated with technology. –Teams that pursue a new technical approach – lack of experience with a new technology, architecture, or development approach contributes to failure.

Reasons for software projects failure 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.

RAD overcome following issues With Conventional methods, –Customer sees any results after long delay –developments can take a long time and sometimes a business may change during that period –there is nothing until 100% of the process is finished.

Classic mistakes Some ineffective development practices have been chosen so often, by so many people, with such predictable, bad results that they deserve to be called "classic mistakes.“ To achieve rapid development you need to avoid making any big mistakes

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 (overdoing) Adding people to a late project Noisy, crowded offices Friction between developers and customers Unrealistic expectations Lack of effective project sponsorship Lack of stakeholder buy-in Lack of user input.

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 RSD. 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.

Technology Related Classic Mistakes Silver Bullet Syndrome –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 Lack of automated source-code control

Process related classic mistakes Insufficient risk management Contractor failure Overly optimistic schedules –Setting an overly optimistic schedule sets a project up for failure by under scoping the project, undermining effective planning, and abbreviating critical upstream development activities.

more Page 29