0% found this document useful (0 votes)
13 views

UCI 202 Topic 7 Notes

Uploaded by

aroridouglas880
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views

UCI 202 Topic 7 Notes

Uploaded by

aroridouglas880
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

Topic 7: Information Systems Development

7.1 Introduction
 A system development process is a set of activities, methods, best practices, deliverables, and automated tools
that stakeholders use to develop and maintain information systems and software.
 The overall process by which information systems are designed and implemented within organizations is referred
to as systems analysis and design (SA&D).

7.2 The Capability Maturity Model


 The Capability Maturity Model (CMM) is a framework to assess the maturity level of an organization’s information
system development and management processes and products. It consists of five levels of maturity as measured
by a set of guidelines called the key process areas.

– Level 1—Initial: System development projects follow no prescribed process.

– Level 2—Repeatable: Project management processes and practices are established to track project
costs, schedules, and functionality.

– Level 3—Defined: A standard system development process (sometimes called a “methodology”) is


purchased or developed, and integrated throughout the information systems/services unit of the
organization.

– Level 4—Managed: Measurable goals for quality and productivity are established.

– Level 5—optimizing: The standardized system development process is continuously monitored and
improved based on measures and data analysis established in Level 4.

1.3 Principles of problem Solving


1) Get the owners and users involved.
2) Use a problem-solving approach.
3) Establish phases and activities.
4) Establish standards.
5) Justify systems as capital investments.
6) Don’t be afraid to cancel or revise scope.
7) Divide and conquer.
8) Design systems for growth and change.

1.4 Where do Information Systems Project Come from?


 System owners and system users initiate most projects. The impetus for most projects is some combination of
problems, opportunities, and directives.
 Problems are undesirable situations that prevent the organization from fully achieving its purpose, goals, and/or
objectives.
 Opportunities are chances to improve the organization even in the absence of specific problems.
 Directives are new requirements that are imposed by management, government, or some external influence.
The PIECES Problem-Solving Framework
 Framework used to classify problems:
P the need to improve Performance
I the need to improve Information (and data)
E the need to improve Economics, control costs, or increase profits
C the need to improve control or security
E the need to improve efficiency of people and processes
S the need to improve service to customers, suppliers, partners, employees, etc.

1.5 Systems Development Life Cycle versus Development Methodology


 A system life cycle divides the life of an information system into two stages, systems development and systems
operation and support.
 A system development methodology is a very formal and precise system development process that defines (as
in CMM Level 3) a set of activities, methods, best practices, deliverables, and automated tools that system
developers and project managers are to use to develop and maintain information systems and software.

1.6 System Development Methods


 Many options exist for developing information systems, but the most popular alternatives are structured analysis,
which is a traditional method that still is widely used, object-oriented (O-O) analysis, which is a more recent
approach that many analysts prefer, and agile methods, also called adaptive methods, which include the latest
trends in software development.
 Other Development Methods:
1. Joint application development (JAD)
2. Rapid application development (RAD)
3. Might encounter other systems development techniques
4. Rational Unified Process (RUP®)
5. Microsoft Solutions Framework (MSF)

Structured System Analysis and Design


 Breaks the development process into distinct stages called phases.
 Each stage defines its activities and outcomes.
 Hierarchical in nature – uses a top-down view in the development cycle.
 A set of full documentation is produced as part of analysis and design.
 The stages vary but typical ones include: systems investigation, systems analysis, systems design, implementation
and maintenance.
Disadvantages of SSAD
1. real projects rarely follow sequential flow

2. iteration hard to incorporate

3. difficult for customer to give requirements explicitly

4. working software comes late in project

5. developers can be delayed by other members of team

6. Delays detection of errors up to the end


Advantages
1. Clearly defined methods and techniques

2. Good documentation standards

3. Well defined deliverables at each stage

4. Good project management and planning

5. Provides means of checking quality

Rapid Application Development

Business modelling

Data
Business modelling modelling

Process
Data modelling
modelling

Application
Process generation
modelling

Applicatio Testing
n
generation

Testing
 high-speed adaptation of linear sequential model achieved by using component construction.

Disadvantages

1. requirements must be well understood

2. project scope must be constrained

3. need scalable scope and modularisable project

4. need many people for multiple teams

advantages

 gives early delivery

1. Object-Oriented analysis
 Whereas structured analysis treats processes and data as separate components, object oriented analysis
combines data and the processes that act on the data into things called objects.
 Systems analysts use O-O to model real-world business processes and operations. The result is a set of software
objects that represent actual people, things, transactions, and events.
 Using an O-O programming language, a programmer then writes the code that creates the objects.
 An object is a member of a class, which is a collection of similar objects. Objects possess characteristics called
properties, which the object inherits from its class or possesses on its own.
 Object-oriented methods usually follow a series of analysis and design phases that are similar to the SDLC,
although there is less agreement on the number of phases and their names.
 In an O-O model, the phases tend to be more interactive. The planning, analysis, and design tasks interact
continuously to produce prototypes that can be tested and implemented. The result is an interactive model that
can accurately depict real-world business processes.
 O-O methodology is popular because it provides an easy transition to O-O programming languages such as Java,
Smalltalk, C++, Python, and Perl.

Agile Methods
 Agile methods, in contrast, attempt to develop a system incrementally, by building a series of prototypes and
constantly adjusting them to user requirements.
 As the agile process continues, developers revise, extend, and merge earlier versions into the final product.
 An agile approach emphasizes continuous feedback, and each incremental step is affected by what was learned
in the prior steps.
 Although relatively new to software development, the notion of iterative development can be traced back to
Japanese auto firms that were able to boost productivity by using a flexible manufacturing system, where team-
based effort and short-term milestones helped keep quality up and costs down.
 Agile methods typically use a spiral model, which represents a series of iterations, or revisions, based on user
feedback.
 As the process continues, the final product gradually evolves.
 An agile approach requires intense interactivity between developers and individual users, and does not begin with
an overall objective. Instead, the agile process determines the end result.
 Proponents of the spiral model believe that this approach reduces risks and speeds up software development.
 Spiral models initially were suggested in the 1990s by Barry Boehm, a noted software engineering professor. He
stated that each iteration, or phase, of the model must have a specific goal that is accepted, rejected, or changed
by the user, or client. Thus, each iteration produces feedback and enhancements, which enable the team to reach
the overall project goal.
 Typically, each iteration in a spiral model includes planning, risk analysis, engineering, and evaluation, as shown
in the table below:
TASKS
Activity

1. Define objectives, constraints, and deliverables

2. Identify risks and develop acceptable resolutions

3. Develop a prototype that includes all deliverables

4. Perform assessment and testing to develop objectives for next iteration

 The repeated iterations produce a series of prototypes, which evolve into the finished system.
 Notice that these phases resemble SDLC tasks, which also can be iterative.
• Other Development Methods
1) Joint application development (JAD)
2) Rational Unified Process (RUP®)
3) Microsoft Solutions Framework (MSF)
7.7 The Structured System Analysis and Design Life Cycle

Investigation phase
 This stage may involve consideration of proposals generated by a business/IT planning process.
 The investigation stage also includes the preliminary feasibility study of proposed information system solutions to
meet a company’s business priorities and opportunities.
 Because the process of development can be costly, the systems investigation stage typically requires the
development of a feasibility study.
 At this stage, this is a preliminary study where the information needs of prospective users and the resource
requirements, costs, benefits, and feasibility of a proposed project are determined.
 Studies include:
(i). Operational feasibility - assessment focuses on the degree to which the proposed development project fits
in with the existing business environment and objectives with regard to development schedule, delivery date,
corporate culture, and existing business processes.
(ii). Schedule feasibility – determines if the system can be developed within a reasonable time frame.
(iii). Economic feasibility - to determine the extent to which the proposed system will provide positive economic
benefits to the organization. This determination involves the identification, and quantification, of all benefits
expected from the system, as well as the explicit identification of all expected costs of the project.
 The assessment of economic feasibility typically involves the preparation of a cost/ benefit analysis. If
costs and benefits can be quantified with a high degree of certainty, they are referred to as tangible; if
not, they are called intangible .
(iv). Technical feasibility- focused on gaining an understanding of the present technical resources of the
organization and their applicability to the expected needs of the proposed system.
(v). Human Factor Feasibility - In this category, we assess the degree of resistance to the proposed system, the
perceived role of the end users in the development process, the degree of change to the end users’ working
environment as a result of the new system, and the current state of human resources available to conduct the
project and to manage and use the system on completion.
(vi). Legal and political feasibility - includes a thorough analysis of any potential legal ramifications resulting
from the construction and implementation of the new system.

Systems analysis
 Systems analysis is not a preliminary study; however, it is an in-depth study of end-user information needs that
produces functional requirements that are used as the basis for the design of a new information system.
 Systems analysis traditionally involves a detailed study of:
(i). The information needs of a company and end users like yourself.
(ii). The activities, resources, and products of one or more of the present information systems being used.
(iii). The information system capabilities required to meet your information needs, and those of other business
stakeholders that may use the system.
 Analysis categories include:
(i). Organizational Analysis –in order to develop a new system ,members of a development team have to
have a thorough understanding of the organization, its management structure, its people, its business
activities, the environmental systems it must deal with, and its current information systems.
(ii). Analysis of the present system – done to uncover the strengths and weaknesses of the present system
so as to come up with a better system.
(iii). Logical analysis - One of the primary activities that occur during the analysis phase is the construction
of a logical model of the current system.
 The logical model can be thought of as a blueprint of the current system that displays only what
the current system does without regard for how it does it.
 By constructing and analyzing a logical model of the current system, a systems analyst can
more easily understand the various processes, functions, and data associated with the system
without getting bogged down with all the issues surrounding the hardware or the software.
(iv). Functional analysis – done to understand use’s information requirements that are not tagged to the
computer hardware , software or network.
 They include:
a) User interface requirements
b) Processing requirements
c) Storage requirements
d) Control requirements

Systems Design
 The purpose of the systems design phase is to create a physical model that will satisfy all documented
requirements for the system.
 At this stage, you design the user interface and identify necessary outputs, inputs, and processes.
 In addition, you design internal and external controls, including computer-based and manual features to guarantee
that the system will be reliable, accurate, maintainable, and secure.
 During the systems design phase, you also determine the application architecture, which programmers will use to
transform the logical design into program modules and code.
 The deliverable for this phase is the system design specification, which is presented to management and users
for review and approval
 Design include: user interface design, database design and processes design

 System specifications formalize the design of an application’s user interface methods and products, database
structures, and processing and control procedures. Therefore, systems designers will frequently develop
hardware, software, network, data, and personnel specifications for a proposed system.
 Below are examples of system specifications:
Systems Implementation
 The purpose of this phase is to deliver a fully functional system.
 Activities include :
(i). Acquire (or develop) hardware and software.
(ii). Test the system, and train people to operate and use it.
(iii). Convert to the new business system.
(iv). Manage the effects of system changes on end users.
System Maintenance
 Use a postimplementation review process to monitor, evaluate, and modify the business system as needed.
7.8 System Conversion
Strategies
 The initial operation of a new business system can be a difficult task. This typically requires a conversion
process from the use of a present system to the operation of a
 Four major forms of system conversion include:
(i). Parallel conversion
(ii). Phased conversion
(iii). Pilot conversion
(iv). Direct conversion

Direct conversion
 The simplest conversion strategy, and probably the most disruptive to the organization, is the direct cutover (or
slam dunk or cold-turkey) approach.
 Using this approach, the old system is just turned off, and the new system is turned on in its place.
 This method is as abrupt as its name implies.
 Although this method is the least expensive of all available strategies and may be the only viable solution in
situations where activating the new system is an emergency or when the two systems cannot coexist under any
conditions, it is also the one that poses the greatest risk of failure.
Parallel conversion
 Here, the old and new systems are run simultaneously until the end users and project coordinators are fully
satisfied that the new system is functioning correctly and the old system is no longer necessary.
 Using this approach, a parallel conversion can be effected with either a single cutover, where a predetermined
date for stopping the parallel operation is set, or a phased cutover, where some predetermined method of
phasing in each piece of the new system and turning off a similar piece of the old system is employed.
 Although clearly having the advantage of low risk, the parallel approach also brings with it the highest cost. To
execute a parallel approach properly, the end users must literally perform all daily functions with both systems,
thus creating a massive redundancy in activities and literally double the work.
 Parallel conversion may be the best choice in situations where an automated system is replacing a manual one.

Pilot conversion
 In some situations, the new system may be installed in multiple locations, such as a series of bank branches or
retail outlets. In other cases, the conversion may be able to be planned from a geographic perspective. When
these types of scenarios exist, the possibility of using a pilot conversion strategy exists.
 This approach allows for the conversion to the new system, using either a direct or parallel method, at a single
location.
 The advantage to this approach is that a location can be selected that best represents the conditions across the
organization but also may be less risky in terms of any loss of time or delays in processing.
 Once the installation is complete at the pilot site, the process can be evaluated and any changes to the system
made to prevent problems encountered at the pilot site from reoccurring at the remaining installations.

Phased Conversion
 A phased or gradual conversion strategy attempts to take advantage of the best features of both the direct
and parallel approaches, while minimizing the risks involved.
 This incremental approach to conversion allows for the new system to be brought online as a series of functional
components that are logically ordered to minimize disruption to the end users and the flow of business.
 Phased conversion is analogous to the release of multiple versions of an application by a software developer.
 Each version of the software should correct any known bugs and should allow for 100 percent compatibility with
data entered into or processed by the previous version.
 Although it has the advantage of lower risk, the phased approach takes the most time and, thus, creates the most
disruption to the organization over time.

You might also like