IMS 5006 — Information Systems Development Practices Quality

IMS 5006 - Information Systems Development Practices Quality and productivity issues in information systems development: RAD, application packages, outsourcing

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

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 3

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 4

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

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

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 7

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 8

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

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

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 11

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 12

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 13

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 14

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 15

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 16

Choosing application packages: Issues § § § § Cost Functionality Vendor Support Viability of Vendor Flexibility Documentation Response Time Ease of Installation 17

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 18

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 19

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 20

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

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 22

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) 23

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) 24

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 25

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” 26

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 27

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 28

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 29

References § HOFFER, J. A. , GEORGE, J. F. and VALACICH (2001) 3 rd ed. , Modern Systems Analysis and Design, Prentice-Hall Chapter 19 § AVISON, D. E. & FITZGERALD, G. (2003). Information Systems Development: Methodologies, Techniques and Tools. (3 rd ed), Mc. Graw-Hill, London Chapters 6. 4, 22. 1, 22. 3, 22. 4, 8 30