UCI 202 Topic 7 Notes
UCI 202 Topic 7 Notes
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).
– Level 2—Repeatable: Project management processes and practices are established to track project
costs, schedules, and functionality.
– 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.
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
advantages
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
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.