10.1 lecture 10 alternative development strategies ims2805 - systems design and implementation
Post on 19-Dec-2015
214 views
TRANSCRIPT
![Page 1: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/1.jpg)
10.1
Lecture 10
Alternative development strategies
IMS2805 - Systems Design and Implementation
![Page 2: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/2.jpg)
10.2
References
HOFFER, J.A., GEORGE, J.F. and VALACICH (2002) 3rd ed., Modern Systems Analysis and Design, Prentice-Hall, New Jersey, Chaps 1,7,11,19
HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) 4th ed., Modern Systems Analysis and Design, Prentice-Hall, New Jersey, Chaps 1,2,6,
WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-Hill, New York, NY. Chapter 3
AVISON, D.E. & FITZGERALD, G. (2003). Information Systems Development: Methodologies, Techniques and Tools. (3rd ed), McGraw-Hill, London
![Page 3: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/3.jpg)
10.3
Alternative systems development strategies
Traditional SDLC Prototyping Joint Application Development (JAD) Rapid Application Development (RAD) Application packages Enhancing existing systems
![Page 4: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/4.jpg)
10.4
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
![Page 5: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/5.jpg)
10.5
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 sub-phases
a methodology helps developers plan, manage, control and evaluate information systems projects
Avison and Fitzgerald (1995)
Systems development concepts
![Page 6: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/6.jpg)
10.6
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
(From WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-Hill, New York, NY, Chapter 3.)
![Page 7: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/7.jpg)
10.7
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)
(From WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-Hill, New York, NY, Chapter 3.)
![Page 8: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/8.jpg)
10.8
Traditional SDLC
a formalised method for building information systems (the oldest one: early 1970s)
the "waterfall" model :
feasibility study
system investigation
systems analysis
systems design
implementation
review and maintenance
![Page 9: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/9.jpg)
10.9
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
![Page 10: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/10.jpg)
10.10
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
![Page 11: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/11.jpg)
10.11
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
![Page 12: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/12.jpg)
10.12
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
![Page 13: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/13.jpg)
10.13
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
Traditional SDLC
![Page 14: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/14.jpg)
10.14
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
![Page 15: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/15.jpg)
10.15
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
![Page 16: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/16.jpg)
10.16
Prototyping
a prototype is designed with an expectation of change
need appropriate technology
types of prototypes:features e.g. external design
throw away
evolutionary
![Page 17: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/17.jpg)
10.17
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
![Page 18: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/18.jpg)
10.18
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
![Page 19: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/19.jpg)
10.19
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
Prototyping
![Page 20: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/20.jpg)
10.20
Joint Application Development (JAD)
is actually analysis and design originated in late 1970s 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
![Page 21: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/21.jpg)
10.21
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)
![Page 22: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/22.jpg)
10.22
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)
![Page 23: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/23.jpg)
10.23
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)
![Page 24: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/24.jpg)
10.24
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)
![Page 25: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/25.jpg)
10.25
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
Joint Application Development (JAD)
![Page 26: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/26.jpg)
10.26
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) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-Hill, New York, NY, Chapter 3.)
![Page 27: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/27.jpg)
10.27
Rapid Application Development (RAD) :
A systems development methodology created to radically decrease the time needed to design and implement information systemsE.g. James Martin (1991)
RAD methodology
Rapid Application Development (RAD)
![Page 28: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/28.jpg)
10.28
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
![Page 29: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/29.jpg)
10.29
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)
![Page 30: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/30.jpg)
10.30
James Martin’s four pillars of RAD:
Tools People Methodology Management
Rapid Application Development (RAD)
![Page 31: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/31.jpg)
10.31
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)
![Page 32: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/32.jpg)
10.32
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)
![Page 33: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/33.jpg)
10.33
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)
![Page 34: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/34.jpg)
10.34
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.)
![Page 35: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/35.jpg)
10.35
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)
![Page 36: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/36.jpg)
10.36
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)
![Page 37: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/37.jpg)
10.37
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)
![Page 38: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/38.jpg)
10.38
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
![Page 39: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/39.jpg)
10.39
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
![Page 40: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/40.jpg)
10.40
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
![Page 41: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/41.jpg)
10.41
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
![Page 42: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/42.jpg)
10.42
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
![Page 43: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/43.jpg)
10.43
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
Application packages
![Page 44: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/44.jpg)
10.44
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
![Page 45: 10.1 Lecture 10 Alternative development strategies IMS2805 - Systems Design and Implementation](https://reader037.vdocument.in/reader037/viewer/2022110322/56649d385503460f94a12222/html5/thumbnails/45.jpg)
10.45
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