1 / 30

Quality and productivity issues in information systems development:

Quality and productivity issues in information systems development: RAD, application packages, outsourcing. References. HOFFER, J.A., GEORGE, J.F. and VALACICH ( 2001 ) 3r d ed., Modern Systems Analysis and Design , Prentice-Hall Chapter 19

holmesl
Télécharger la présentation

Quality and productivity issues in information systems development:

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Quality and productivity issues in information systems development: RAD, application packages, outsourcing

  2. References • HOFFER, J.A., GEORGE, J.F. and VALACICH (2001) 3rd ed., Modern Systems Analysis and Design, Prentice-Hall Chapter 19 • AVISON, D.E. & FITZGERALD, G. (2003). Information Systems Development: Methodologies, Techniques and Tools. (3rd ed), McGraw-Hill, London Chapters 6.4, 22.1, 22.3, 22.4, 8

  3. Quality and productivity “solutions” include: • user participation • JAD (Joint Application Design) • prototyping • automated and other tools • RAD (Rapid Application Development) • Application packages • outsourcing • reuse

  4. Rapid Application Development (RAD) 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

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

  6. 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?

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

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

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

  10. 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”

  11. 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.)

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

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

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

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

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

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

  18. Choosing application packages: Issues • Cost • Functionality • Vendor Support • Viability of Vendor • Flexibility • Documentation • Response Time • Ease of Installation

  19. Choosing application packages : Process • identify products which may suit specified requirements • solicit, evaluate and rank vendor proposals • select the best vendor proposal • establish requirements for integrating the vendor’s products

  20. Choosing application packages: Criteria • Identify criteria by which to evaluate hardware and software • cost, functionality,vendor support, vendor viability, quality of documentation, ease of learning, ease of use, ease of installation, response time, throughput, version?, ease of customisation, number of current installations, licensing arrangement, training, internal controls, database size limitation, maintenance contracts, customer references • to help identify criteria you can use • past experience, trade magazines and journals, information services, potential vendors ..bias

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

  22. Application packages • Useful: • because the design specification is fixed, so 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

  23. 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 multi-purpose 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

  24. Application packages: ERP • Enterprise Resource Planning (ERP) Systems • A large scale application package: a series of software modules for business processes including financial, organisational (e.g. HR), production, inventory functions etc e.g. SAP is the market leader • Fully integrated system enabling standardisation and data integrity • Internet and e-commerce technologies • Software can be configured for industry sectors e.g. banking, universities, airlines etc. (Avison & Fitzgerald 2003, pp 131-132)

  25. Application packages: ERP Enterprise Resource Planning (ERP) Systems • Disadvantages: long implementation times, huge investment, impact of widespread change, costs, tendency to change the organisation’s processes to fit the software Key differences from typical software package purchases: • Complexity causes organisations to forego customisation • Tends to be driven by top corporate managements (Avison & Fitzgerald 2003, pp 131-132)

  26. Outsourcing • The practice of turning over some or all of an organisation’s IS applications and/or operations to an outside firm. • Why? • May be cost-effective • May be specialist in your business area • To overcome operating problems • Running IS/IT is not part of core business (core competencies) • Need to be aware of the pros and cons

  27. Outsourcing Differing definitions of outsourcing e.g. : The commissioning of a third party (or a number of third parties) to manage a client organisation’s IT assets, people, and/or activities to required results Fitzgerald & Willcocks (1994) • Focus is on the specified service, not on how the service is to be carried out • Growing tendency for organisations to outsource some or all of their systems development • Difficulties in gathering and accurately specifying requirements in particular • Issues and problems in defining and negotiating contracts and responsibilities • Growth of “offshore outsourcing”

  28. Reuse • reuse of code (software) • reuse of analysis and design components • reuse of application shells and templates • reuse of project management modules benefits: - lower costs - reduction in development time - increased quality enterprise-wide planning for reuse is necessary

  29. Reuse • software reusability: the ability to design software modules so that they can be used again and again in different systems without significant modification • a repository of reusable components: - access mechanisms – modification mechanisms - integration mechanisms • object-oriented technology facilitates reuse • CASE tools facilitate reuse

  30. Reuse • methods of reuse: - adapt a generic design - building blocks - combination • incorporating reuse techniques into SDMs, e.g. Information Engineering recommends reuse in its later versions

More Related