www hndit com HNDIT 23073 Rapid Application Development

www. hndit. com HNDIT 23073 : Rapid Application Development

www. hndit. com Course Details • Lectures – 15 hours • Practical - 60 hours

www. hndit. com Module Aims & Objectives • To provide a firm foundation on Rapid Application Development concepts, best practices and to familiarize with software development using common RAD tools and environments. • To develop skills and knowledge required for development and deployment RAD Project in Real Time

Learning Outcomes www. hndit. com 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 • Develop Project using RAD tools

Outline Syllabus www. hndit. com 1. Traditional and modern application development methods, their advantages and disadvantages, Working with RAD GUI 2. Interface design for RAD applications using a common RAD tool 3. Issues in RAD & RAD tools 4. RAD Constraints 5. Selection & Decision in VB. Net 6. Methodologies commonly used in Rapid Application Development and RAD life cycles, 7. Project Estimation in RAD 8. Basic Object oriented Programing Concepts 9. Project Schedule In RAD 10. different methods of providing database integration and connectivity into a application 11. Team Work in RAD 12. develop database connectivity layers into an application 13. Best Practices In RAD 14. components of service oriented application architectures in a RAD environment 15. deployment technique for RAD applications and environments

www. hndit. com Assessment Criteria • Continuous Assessment – In class participation and quizzes - 10% – Self directed RAD development project- 40% • End of semester examination – Structured examination paper - 50%

www. hndit. com Reference • Whitten, Jeffrey L. ; Lonnie D. Bentley, Kevin C. Dittman. (2004). Systems Analysis and Design Methods. 6 th edition. ISBN 025619906 X. • Steven Mc. Connell, Rapid Development, WP Publishers & Distributors (P) Ltd. ISBN: 817853 -013 -9

• • • • Supplementary reading www. hndit. com http: //www. stevemcconnell. com/rdcntnt. htm http: //www. hallogram. com/menus/RAD_Tools. html http: //www. stevemcconnell. com/rdkind. htm http: //www. itmweb. com/essay 520. htm http: //www. codegear. com/products/jbuilder http: //www. easyeclipse. org/site/distributions/ http: //msdn 2. microsoft. com/en-us/vstudio/products/bb 931214. aspx http: //developers. sun. com/jscreator/ http: //www. functionx. com/ http: //www. homeandlearn. co. uk/NET/vb. Net. html http: //searchwindevelopment. techtarget. com/s. Definition/0, , sid 8_gci 930076, 00. ht ml http: //www. netobjectives. com/files/events/download/rup_xp_scrum_pc_030326 _ppt. pdf http: //www. codeproject. com/KB/architecture/scrum. aspx#Introduction 0 http: //searchsoftwarequality. techtarget. com/s. Definition/0, , sid 92_gci 214246, 00. ht ml

www. hndit. com HNDIT 23073 Rapid Application Development Week 1, 2 - Introduction to RAD

www. hndit. com 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 negotiations without harming the quality, cost, performance or maintainability. • It is a generic term with the meaning “speedy development” or “Shorter schedule”

www. hndit. com 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

www. hndit. com 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 • Risks associated with teams. • Risks associated with technology. • Risk associated with requirements. www. hndit. com

Typical reasons for software projects failure www. hndit. com 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.

Typical reasons for software projects failure cont. www. hndit. com 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. www. hndit. com 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

www. hndit. com 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.

www. hndit. com History of RAD • • Spiral Model Evolutionary life cycle RIPP-Rapid Iterative Productive Prototyping RAD - Early 90’s

www. hndit. com 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.

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

www. hndit. com Classic Mistakes • • People related classic mistakes Product related classic mistakes Technology related classic mistakes Process related classic mistakes

www. hndit. com 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. …

www. hndit. com People related classic mistakes • • Adding people to a late project Noisy, crowded offices Friction between developers and customers Unrealistic expectations …

www. hndit. com 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 …

www. hndit. com People related classic mistakes • 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.

Product Related Classic Mistakes www. hndit. com • 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 www. hndit. com • 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 www. hndit. com • Silver Bullet Syndrome: o Jack and the magic beanstalk! Did the CASE tool grow into a magic beanstalk? o The Native belief that a single tool or technology will by itself dramatically reduce development time. o Too much reliance on the advertised benefits of previously unused technologies. …

Technology Related Classic Mistakes cont. www. hndit. com • 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 www. hndit. com • 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 www. hndit. com • 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. • 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 www. hndit. com • 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 www. hndit. com • 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 www. hndit. com • 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 20 -30 percent. • Planning to Catch up later • Code-like-hell programming

www. hndit. com Different Life Cycle Models • • • Waterfall model Spiral Model Evolutionary prototyping RAD Agile Development Etc.

www. hndit. com Choosing most effective 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?

www. hndit. com Choosing most effective 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?

www. hndit. com 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!)

www. hndit. com 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? www. hndit. com Effect of development approach on Development Approach Schedule Cost Product Average practice Average Efficient development (balanced approach) Better than average Efficient development (with best schedule) Much better than average All-out- rapid development Fastest possible Worse than average

www. hndit. com 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 an 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.

www. hndit. com 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 www. hndit. com • 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.

www. hndit. com 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

www. hndit. com Reference • Steven Mc. Connell, Rapid Development, WP Publishers & Distributors (P) Ltd. ISBN: 817853 -013 -9