Rapid Application Development Dr Rahim Khan Assistant Professor

Rapid Application Development Dr. Rahim Khan Assistant Professor Department of Computer Science UCSS, AWK University Mardan

Main Reading Materials • Steven Mc. Connell, Rapid Development WP Publisher and Distributors • Net. Beans : The Definitive Guide, Tim Boudreau, Jesse Glick, et al, 2003

Software engineering • It is concerned with theories, methods and tools for professional software development • It is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. ²All aspects of software production § Not just technical process of development. Also project management and the development of tools, methods etc. to support software production

FAQs about software engineering Question Answer What is software? Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market. What are the attributes of good software? Good software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable. What is software engineering? Software engineering is an engineering discipline that is concerned with all aspects of software production. What are the fundamental software engineering activities? Software specification, software development, software validation and software evolution. What is the difference between software engineering and computer science? Computer science focuses on theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. What is the difference between software engineering and system engineering? System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this more general process.

FAQs about software engineering Question Answer What are the key challenges facing software engineering? Coping with increasing diversity, demands for reduced delivery times and developing trustworthy software. What are the engineering? software Roughly 60% of software costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs. What are the best software engineering techniques and methods? While all software projects have to be professionally managed and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. You can’t, therefore, say that one method is better than another. What differences has the web made to software engineering? The web has led to the availability of software services and the possibility of developing highly distributed servicebased systems. Web-based systems development has led to important advances in programming languages and software reuse. costs of

Essential attributes of good software Product characteristic Description Maintainability Software should be written in such a way so that it can evolve to meet the changing needs of customers. This is a critical attribute because software change is an inevitable requirement of a changing business environment. Dependability and Security Software dependability includes a range of characteristics including reliability, security and safety. Dependable software should not cause physical or economic damage in the event of system failure. Malicious users should not be able to access or damage the system. Efficiency Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency therefore includes responsiveness, processing time, memory utilisation, etc. Acceptability Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable and compatible with other systems that they use.

The software process • A structured set of activities required to develop a software system. • Many different software processes but all involve: – Specification – defining what the system should do; – Design and implementation – defining the organization of the system and implementing the system; – Validation – checking that it does what the customer wants; – Evolution – changing the system in response to changing customer needs. • A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

Software Process Descriptions • When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities. • Process descriptions may also include: – Products, which are the outcomes of a process activity; – Roles, which reflect the responsibilities of the people involved in the process; – Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced.

Plan-driven and agile processes • Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan. • In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements. Rapid Application Development

Software process models • The waterfall model – Plan-driven model. Separate and distinct phases of specification and development. • Incremental development – Specification, development and validation are interleaved. May be plan-driven or agile. • Reuse-oriented software engineering – The system is assembled from existing components. May be plandriven or agile. • In practice, most large systems are developed using a process that incorporates elements from all of these models.

Systems development concepts • Method: A prescribed set of tasks that uses specific techniques and tools to complete a systems development activity • Technique: a way of doing a particular task in the systems development process • Tool: automated tools to help systems development

Systems development concepts Methodology: • a collection of procedures, techniques, tools and documentation aids which assist systems developers to implement a new information system • a methodology consists of phases, and these consist of subphases • a methodology helps developers plan, manage, control and evaluate information systems projects

Alternative Routes through a Methodology • Model-Driven Development (MDD) • Rapid Application Development (RAD) • Commercial Off-the-Shelf Software (COTS) • Maintenance and Reengineering or hybrids of the above

Model-Driven Development Route • Modeling is the act of drawing one or more graphical representations (or pictures) of a system. Modeling is a communication technique based upon the old saying, “a picture is worth a thousand words. ” • Model-driven development techniques emphasize the drawing of models to help visualize and analyze problems, define business requirements, and design information systems. – Structured systems analysis and design — process-centered (traditional SDLC approach) – Information engineering (IE) — data-centered – Object-oriented analysis and design (OOAD) — object-centered (integration of data and process concerns)

Traditional SDLC • a formalised method for building information systems (the oldest one: early 1970 s) • the "waterfall" model : feasibility study system investigation systems analysis systems design implementation review and maintenance

Traditional SDLC • the SDLC has a number of phases, each consisting of a number of sub-phases, activities • many variants • the system is generally developed sequentially, but some tasks in earlier phases may be revisited, and some tasks may be done in parallel • formal division of labour between users and IS staff and amongst IS staff • formal sign-offs required at the completion of each major stage

Traditional SDLC Useful for: • providing a base guideline for systems development which can be modified to suit specific requirements • building large transaction processing systems (TPS) and management information systems (MIS) where requirements are highly structured and well defined • building complex systems which need rigorous and formal requirements analysis, predefined specs, and tight controls over the systems building process

Traditional SDLC Limitations: • is resource intensive – a large amount of time spent gathering information and preparing detailed specifications and sign-off documents – could take years to develop a system. . requirements change before the system is operational • is inflexible and inhibits change – the time and cost required to repeat activities encourages freezing of specifications early in the development. . locks users into something that may no longer be appropriate

Traditional SDLC Limitations: • hard to visualize final system – users sign off specification documents without fully understanding their contents or implications • is ill-suited to decision-oriented applications – decision-making is often unstructured. . there are no well-defined models or procedures – being forced to develop formal specifications can be very inhibiting

Traditional SDLC Limitations: • not well suited to most of the small desktop systems that will predominate in the future • does not encourage user participation • management and strategic needs ignored • focus on technical aspects

Prototyping A prototype: • a working model of some aspect(s) of an information system Prototyping: • an iterative process of building an experimental system quickly, for demonstration and evaluation so that users can dynamically determine their information requirements and explore and test the design of the system

Prototyping Can be used in various phases of the SDLC – Initiation. . to test the feasibility of a particular technology that might be applied for an IS – Analysis. . to discover the users requirements by ‘painting’ screens and reports to solicit feedback – Design. . to simulate the ‘look and feel’ of the system, and evaluate how easy it is to use and learn – Implementation. . where the prototype evolves directly into the production system, to train users

Prototyping • a prototype is designed with an expectation of change • need appropriate technology • types of prototypes: features e. g. external design throw away evolutionary

Prototyping Useful: • when there is uncertainty about requirements or design solutions. . is able to capture requirements in concrete, rather than verbal or abstract form – users are more likely to be able to state their detailed requirements when they see and use a prototype – users are more likely to get what they want • when there are several stakeholders • because it encourages user participation • because it is easier to identify behavioural issues when users are using the prototype

Prototyping Limitations: • tends to skip through analysis and design phases too quickly. . lack of thorough understanding of the problems – a tendency to avoid creating formal documentation of system requirements which can then make the system more difficult to develop into a production system • can discourage consideration of a wide range on alternative design options. . tendency to go with the first one that the user likes • often lacks flexibility, technical efficiency and maintainability because of hasty construction

Prototyping Limitations: • not suitable for large applications which have large amounts of data and multiple users. . hard to control • often built as stand-alone systems, thus ignoring issues of data sharing and interactions with other existing systems • checks in the SDLC are bypassed so tendency to gloss over essential tasks eg. standardisation, documentation, testing, security, etc. . • can become too specific to the user representative and difficult to adapt to other potential users

Joint Application Development (JAD) • is actually analysis and design • originated in late 1970 s at IBM • bring together key users, managers, systems analysts in a group interview with a specific structure of roles and agenda • purpose: collect key system requirements develop system design • group meeting: avoid distractions identify areas of agreement and conflict resolve conflicts during the period of sessions

Joint Application Development (JAD) • JAD participants: • facilitator: organise and run the sessions • scribe(s): takes notes on a PC, CASE tool etc • users: understand the system requirements • managers: organisational overview • systems analysts: technical knowledge, learn about the system • sponsor: senior executive who commits and funds the process

Joint Application Development (JAD) JAD sessions: • from one to five days • structured meeting room with white boards etc. , CASE tools • located away from users’ workplace • outcome is documents detailing the system: workings of/requirements for the system/design

Joint Application Development (JAD) Preparing for JAD sessions: • JAD leader prepares and distributes agenda and documentation about scope and objectives • Agenda specifies issues to be discussed and time allocated to each • Ground rules for running the sessions are made clear • Ensure users who attend are knowledgeable about their business area

Joint Application Development (JAD) Conducting JAD sessions: • • • Avoid deviating from the agenda Keep to schedule (time for topics) Ensure scribe takes adequate notes Avoid using technical jargon Use conflict resolution strategies Allow ample breaks Encourage group consensus Encourage participation vs individuals dominating Ensure ground rules are adhered to

Joint Application Development (JAD) Benefits: • reduced time to move requirements/design forward (group vs one-on-one, details worked on between meetings) • key people work together to make important decisions • commitment is focused and intensive, not dissipated over time • conflicts and differences can be understood and resolved

Rapid Application Development Route • Rapid application development (RAD) techniques emphasize extensive user involvement in the rapid and evolutionary construction of working prototypes of a system to accelerate the system development process. RAD is based on building prototypes that evolve into finished systems (often using time boxing) – A prototype is a smaller-scale, representative or working model of the users’ requirements or a proposed design for an information system. – A time box is a nonextendable period of time, usually 60 -120 days, by which a candidate system must be placed into operation. (From WHITTEN, J. L. , BENTLEY, L. D. and DITTMAN, K. C. (2001) 5 th ed. , Systems Analysis and Design Methods, Irwin/Mc. Graw-Hill, New York, NY, Chapter 3. )

Rapid Application Development (RAD) : • A systems development methodology created to radically decrease the time needed to design and implement information systems E. g. James Martin (1991) RAD methodology

Rapid Application Development (RAD) RAD claims to offer: • a development lifecycle for much faster systems development • better and cheaper systems • more rapid deployment of systems as developers and users work together in real time RAD relies on: • • • extensive user involvement JAD sessions Prototyping I-CASE tools (integrated CASE tools) Code generators

Rapid Application Development (RAD) Evolution of RAD: • Pressures for businesses to speed up and compete in a changing, global environment • Diffusion of high-powered prototyping and CASE tools: Why wait 2 or 3 years to develop systems likely to be obsolete upon completion?

Rapid Application Development (RAD) James Martin’s four pillars of RAD: • • Tools People Methodology Management

Rapid Application Development (RAD) Tools: • I-CASE tools with prototyping and code generation facilities, • Visual development environments People: • Manager and user participation in JAD type workshops, • Developer roles: Workshop leader, project leader, scribe, repository manager, construction or SWAT (Skilled With Advanced Tools) team

Rapid Application Development (RAD) • Methodology: • to guide and control the use of RAD techniques • Should be automated for ease of use, adaptabilty and flexibility • Management: • Executive sponsor • Facilities and support for the RAD team

Rapid Application Development (RAD) RAD lifecycle • Requirements planning phase (JRP) • User design phase (JAD) • Construction phase • Cutover phase • Is evolutionary: • Uses timeboxing • Avoids “feature creep” • Avoids requirements “gold plating”

Rapid Application Development (RAD) Martin’s (1991) RAD lifecycle • Requirements planning phase • managers, executives, key users determine requirements in terms of business areas and business problems, • JRP workshops to agree requirements, overall planning • User design phase • end users and IS personnel use I-CASE for rapid prototyping of system design, • JAD sessions to develop basis for physical design, • users sign off on CASE-based design (no paper-based spec. )

Rapid Application Development (RAD) Martin’s (1991) RAD lifecycle • Construction phase • IS personnel now generate code using I-CASE tool, • end users validate screens, design, etc. • Cutover phase • delivery of new system to users: testing, training, implementation, • can be combined with construction in small systems

Rapid Application Development (RAD) • Uses timebox approach: • system to be developed divided into components that can be developed separately • have the easiest and most important 75% of the system functionality produced in the first timebox (90 day cycle) • forces users to focus on the necessary and most well-defined aspects • Users experience this component first and other component requirements may then change • Functionality is trimmed: “gold plating” is avoided • Avoids “feature creep”: more and more requirements creep in during development than originally specified

Rapid Application Development (RAD) • Timeboxing vs traditional approach: traditional approach every possible requirement is implemented together leading to increased complexity and long delays • Martin claims RAD can produce a system in 6 months that would take 24 months using traditional development methods • Small development teams are essential for RAD to work

Rapid Application Development (RAD) advantages • quick development: • cost savings, • higher quality/improved performance as easier and most important functions targeted first, • avoids feature creep, • aligned with business changes disadvantages • detailed business models/understanding neglected: inconsistencies, misunderstandings • programming standards, scalability, system administration issues neglected e. g. database maintenance/reorganisation, backup/recovery, distribution of system updates

Rapid Application Development (RAD) advantages • quick development: • cost savings, • higher quality/improved performance as easier and most important functions targeted first, • avoids feature creep, • aligned with business changes disadvantages • detailed business models/understanding neglected: inconsistencies, misunderstandings • programming standards, scalability, system administration issues neglected e. g. database maintenance/reorganisation, backup/recovery, distribution of system updates

Application packages • purchasing or leasing a set of pre-written application software programs that are commercially available • may range from simple PC systems to complex mainframe systems

Application packages • Useful: • when you need an information system for a common company function eg. payroll • when information systems resources for in-house development are in short supply • when the application software package is more cost effective than in-house development • because the most of the design and implementation tasks are done. . significant time saving • because the system and documentation are usually maintained by the vendor

Application packages • Useful: • because the design spec. is fixed !!!! no endless reworking. . users have to accept it • politically because: – external work is often perceived as being superior to an in-house effort. . easier to get new systems into the company – easier to get management support because of fixed costs – problems can be attributed to the package rather than internal sources. . ends endless source of internal conflict

Application packages • Limitations: • very rare to find a package that can do everything well that a user wants • often need to develop specialised package additions because the multipurpose packages do not handle certain functions well • conversion and integration costs can sometimes be so significant as to render the project infeasible • some vendors refuse to support packages which have been customised by the users. . and most packages need some customisation • customisation can be so extensive that it would have been cheaper to develop the system in-house

Enhancing existing systems • can use any development approach. . most organisations have a maintenance - development cycle • the main issues are: – urgency – integration – updating documentation • tendency to jump in and code, with little thought to surrounding development tasks

Alternative development approaches • There are many different ways of developing information systems. . . the difficulty is finding the right blend of approaches and techniques to suit the organisation’s business, social and political systems development environment