IT3101- Rapid Application Development. Course Details Lectures – 30 hours Practical - 60 hours.

IT3101- Rapid Application Development

Course DetailsLectures – 30 hoursPractical - 60 hours

Learning Outcomes

At the end of the module the student will be able to:Explain Rapid Application

Development (RAD) conceptsDetermine environments where

RAD is suitable and applicableUse best practices in RADUse RAD tools and environments

for software application development

Outline SyllabusIntroduction to RADCommon issues in RADRAD tools and environmentsEstimation and scheduling in RADRAD best practicesRAD 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. 6th edition.

ISBN 025619906X.Steven McConnell, Rapid

Development, WP Publishers & Distributors (P) Ltd. ISBN: 81-7853-013-9

Supplementary reading http://www.stevemcconnell.com/rdcntnt.htm http://www.hallogram.com/menus/RAD_Tools.html http://www.stevemcconnell.com/rdkind.htm http://www.itmweb.com/essay520.htm http://www.codegear.com/products/jbuilder http://www.easyeclipse.org/site/distributions/ http://msdn2.microsoft.com/en-us/vstudio/products/

bb931214.aspx http://developers.sun.com/jscreator/ http://www.functionx.com/ http://www.homeandlearn.co.uk/NET/vbNet.html http://searchwindevelopment.techtarget.com/sDefinition/

0,,sid8_gci930076,00.html http://www.netobjectives.com/files/events/download/

rup_xp_scrum_pc_030326_ppt.pdf http://www.codeproject.com/KB/architecture/

scrum.aspx#Introduction0 http://searchsoftwarequality.techtarget.com/sDefinition/

0,,sid92_gci214246,00.html

IT3101- Rapid Application DevelopmentWeek1- 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 behindthe definition20/80 rule - Sometimes a usable 80% solutioncan be produced in 20% of the time required toproduce a total solution.

Sometimes the business requirements for asystem can be fully satisfied even if some of itsoperational requirements are not satisfied.

Some times the acceptability of a system can be

assessed against the agreed minimum usefulset of requirements

Issues in Traditional SoftwareDevelopmentCost and schedule overruns Cancelled projects High turn over Friction between managers,

developersand customers Product not fit for business

Typical reasons for softwareprojects failurea) Risks associated with teams. if a team of developers, end users, and systemsmaintainers have not worked together beforeand do not learn to communicate effectively,they are not likely to develop a successfulsystem without schedule delays or costoverruns. Other risks are associated with thelack of well-defined or well-understoodprocesses.

b) Risks associated with technology.Teams that pursue a new technicalapproach (for example, the first ventureinto client-server computing) finds thatthe lack of experience with a newtechnology, architecture, or developmentapproach contributes to failure.

Typical reasons for softwareprojects failure cont.c) Risk associated with requirements.most often-cited reason for failure is poormanagement of requirementscharacterized by frequently changingrequirements, requirements that are notwell understood, and requirementsexplosion.

Problems Addressed by RADWith Conventional methods,

– there is a long delay before the customersees any results– developments can take a long time and sometimes a business may change during that period– there is nothing until 100% of the process isfinished.

History of RADSpiral Model Evolutionary life cycleRIPP-Rapid Iterative Productive

PrototypingRAD - Early 90’s

Classic mistakesTo achieve rapid development you need

to avoid making any big mistakes.Some inefficient development practiceshave been chosen so often with suchpredictable bad results that they deserveto be called “classic mistakes”.They have been made so often and theirconsequences 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’smanagers and tech leads couldn’t rescue the project forany one’s sake

People related classic mistakesUndermined motivation Weak personnelUncontrolled problem employeesHeroics

– Mid-level management placing a higherpremium on can-do attitude than steady andconsistent progress and meaningful progressreporting. As a result, impending scheduleslips, acknowledged or reported up themanagement chain at the last minute.

People related classic mistakesAdding people to a late project Noisy, crowded officesFriction between developers and

customersUnrealistic expectations

People related classic mistakesLack of effective project

sponsorship– Without executive sponsor, the higher

management may force to accept unrealistic deadlines.Lack of stakeholder buy-inLack of user input

People related classic mistakesPolitics placed over substance

– Politics placed over substance : “Politicians”concentrating on relationships with theirmanagers. “Isolationists” keeping tothemselves, creating project boundaries keptclose to non-team members.

Wishful thinking Closing eyes and hoping some thingworks when there is no reasonable basisfor the thinking. Undermines meaningful planning.

Product Related ClassicMistakesRequirements 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 ClassicMistakesPush-me, pull-me negotiation:o A manager approves a schedule slip on aproject that is progressing slower thanexpected 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 ClassicMistakesSilver 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 improveproductivity by giant leaps irrespective ofthe new tools they acquire. New tools areassociated with learning curves.

Technology Related ClassicMistakesSwitching 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 classicmistakesOverly optimistic schedules

Setting an overly optimistic schedule sets aproject up for failure by underscoping theproject, undermining effective planning, andabbreviating critical upstream developmentactivities.

Insufficient risk managementContractor failure Insufficient planningAbandonment of planning under pressureWasted time during fuzzy front end

◦ Time normally spent in the approval and budgeting process

Process related classicmistakesShortchanged 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 ClassicMistakesShortchanges 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 ClassicMistakesPremature 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 20-30 percent.

Planning to Catch up laterCode-like-hell programming

Different Life Cycle ModelsWaterfall modelSpiral ModelEvolutionary prototypingRADAgile DevelopmentEtc.

Choosing most rapid life cyclemodelChoosing 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 cyclemodel 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 RADGood reasons– To converge early towards a designacceptable to the customer and feasible forthe customer– To save development time, possibly at theexpense of economy or product quality(Criterion for Acceptance : Fit for Business!)

Why use RADBad reasons– To prevent cost overruns – RAD requiresproduct development teams alreadydisciplined in cost management– To prevent runaway schedules - RADrequires product development teams alreadydisciplined in time management

What kind of RAD?Effect of development approach on

Development Approach

Schedule Cost Product

Average practice

Average Average Average

Efficientdevelopment(balancedapproach)

Better thanaverage

Better thanaverage

Better thanaverage

Efficientdevelopment (withbest schedule)

Much betterthanaverage

Much betterthanaverage

Much betterthanaverage

All-out- rapiddevelopment

Fastestpossible

Worse thanaverage

Worse thanaverage

RADRAD - a revolutionary software model ofthe 1990's, while living up to its promiseis still an active area for continued researchRAD is a approach typically relying onsmall well trained teams, use ofevolutionary prototypes, and rigid limits on development time frames.RAD has proven to be a valuablesoftware strategy.

RADIt is not without pitfalls and risks. Requires the right mix of methodologies,tools, personnel and management andthe correct use of best practices. Its use depends upon complexity of thedomain or application, theorganizational environment, the skills ofstaff and management and thearchitectures and infrastructuresavailable

RADThe optimal is a team of users and developerswho can communicate effectively andsuccessfully develop their products withoutschedule delays or cost over runs.experience counts!An experienced team, developing a similarsystem 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 intensivesystems on time and at cost.

RADManagement's function is to eliminateunnecessary tasks, streamline activities, andincrease work time while the development staffreduces time per taskHence, having a well trained, fully collaborativeteam is an essential ingredient for success in aRAD 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)