Download the document is about system analysis and design and more Study notes Computer Science in PDF only on Docsity!
EDO UNIVERSITY IYAMHO
Department of Computer Science
CSC 223 System Analysis and Design
Introduction of Lecturer/ Lecture:
John Temitope Ogbiti, email: [email protected]:
Wednesday, 2am 4 pm, NLT1, phone: (+234) 8034883386–
Office hours: Tuesday, 9AM to 3.30 PM , Office: FOS Room A010.
Grading:We will assign 10% of this class grade to home works & lecture notes,
10 % for the programming projects, 10% for the mid-term test and 70% for the final
exam. The Final exam is comprehensive.
General overview of Lecture
System concept; System Development Life Cycle. Analysis: Fact gathering
Techniques, data flow diagrams, Process description data modeling. System
Design: Structure Charts, form designs, security, automated Tools for Design. What
is object-orientation modeling Concepts, requirement Capture, requirement,
refining the requirements model, object interaction, specifying operations, system
design development methodology.
Learning Outcome: This course is intended to give the students a thorough
knowledge of design techniques and tools for modern design. This course covers
advanced topics such as planning, analysis, designand Implementation. Finally
Design some system like computerized students course registration system
CHAPTER ONE: Phase I (planning):
The systems development life cycle (SDLC)
Introduction to Systems Analysis and Design
Introduces the systems development life cycle (SDLC), the fundamental four-phase
model (planning, analysis, design, and implementation) common to all information
system development projects. Secondly, it describes the evolution of system
development methodologies. Thirdly, overviews object-oriented systems analysis
and design and describes the Unified Process and its extensions.
The systems development life cycle (SDLC )
Is the process of understanding how an information syst supporem (IS) can t
business needs by designing a system, building it, and delivering it to users. If you
have taken a programming class orgr he proav ammed on your own, this probably
sounds pretty simple. Unfortunately, it is not. A 1996 survey by the Standish
Group found that 42 percent of all corporate IS projects were abandoned before
completion. A similar study done in 1996 by the General Accounting Office found
53 percent of all U.S. government re abandoned. Unfortunat y, IS projects we el
many of the systems that aren’t abandoned are delivered to the users significantly
late, cost far more than planned, and he av fewer featur than originally planned.es
The key person in the SDLC is the systems analyst, who analyzes the business
situation, identifies opportunities for improvements, and designs an information
system to implement them. Being a systems analyst is one of the most interesting,
exciting, and challenging jobs around. Systems analysts work with a variety of
people and learn how they conduct business. Specifically, they work with a team of
systems analysts, programmers, and others on a common mission. Systems
analysts feel the satisfaction of seeing systems that they designed and developed
which rely upon techniques that produce deliverables ( specific documents and
files that provideunderstanding aboute project). th
For example, when you apply for admission to a university, all studentsgh go throu
the same phases: information gatherthese ing, applying, and accepting.Each of
phases has steps information gathering includes steps such as searching for
schools, requesting information, and reading broures. Students then use ch
techniques (e.g., Internetsearching) thatapplied to steps (e.g requesting can be.,
information) to create deliverables (e.g., evaluations of different aspects of
universities).
Planning
The planningphase is the fundamental process of understanding why an information
system should be built and determininghow the project team will go about building it.
It has two steps:
1. During projectinitiation ,
thesystem’s business value toe organization is th
identified: how will it lower costs orincreas erevenues? Most ideas forw systneems
come from outsiderketing department, accthe IS area (from the ma ounting
department, etc.) iof a n th forme system
request. A system request presents a brief
summary ofa business need, and it explains how a system that supports the need
will create business value. The IS department works together with the person or
departmentthat generated the request (called the project sponsor ) to conduct a
feasibility analysis
. The feasibility analysisexamines keyaspects of the proposed
project:
o The idea ’
s technical feasibility (Can we build it?)
o
The economic feasibility (Will provide business value?)it
o The organizationalfeasibility (If we buildwill it,it be used?)
The system request andfeasibility analysisare presented to an information
systems approval committee (sometimes called a steering committee), which
decides whether the project should be undertaken.
2. Once the project is approved, it enters project management. During project
management, the project manager creates a work plan, staffs the project, and puts
techniques project thrin place to help the project team control and direct the ough
the entire SDLC. The deliverable for project management is a project plan, which
describes how the project team will go about developing the system.
Analysis
The analysis phase answers the questions of who will use the system, what the
system will do, and where and when it will be used. s During thi phase, the project
tm ea investigates any current system(s), identifies improvement opportunities,
and develops a concept for the new system
This phase has three steps
- An analysis strategy is developed to guide the project team’s efforts. Such a
strategy usually includes an analysis ofnt the curre syst (called the em as-is
system ) and its problems, and then ways to design a new syst (called the em
to-be system ).
- The next step is requirements gathering (e.g., through interviews or
questionnaires). The analysis of this information—in conjunction with input
from project sponsor and ny other mapeople—leads to the development of
a concept for a new system. The system concept is then used as a basis to
develop a set of business analysis models, which describe how the business
will operate if the new system is developed. The set of models typically
includes models that represent the data and processes necessary to
support the underlying business process.
- The analyses, system concept, and models are combined to a document in
called the system proposal, which is presented to the project sponsor and
other key decision makers (e.g., members of the approval committee) who
decide whether the project should contin to move ueforward.
This collection of deliverables (architecture design, interface design, database and
file specifications, and program design) is the system spec ifica tion that is handed to
the programming team for implementation. At the end of the design phase, the
feasibility analysis and project plan are reexamined and revised, and another
decision is made by the project sponsor and approval committee about whether to
terminate the project or continue.
Implementation
The nal phase fi in the SDLC is the implementation phase , during which the system
is actually built (or a packaged software design). This purchased, in the case of is
the phase that usually gets the most r most attention, because fo systems it is e th
longest and most expensive single part of the development process. This phase has
three steps:
- System construction is the rst step. The systfi em is built and tested to
ensure it per- forms as designed. Because the cost of bugs can be
immense, testing is one of the most critical steps in implementation. Most
ganizations orgive more time and attention to testing than to writing the
programs in the rst fi place.
- The system is installed. Installation is the process by which the old system
is turned off w an th ned e one is turned. It may include a ondirect ver cuto
approach (in which replaces th nee w system immediately the d system), a
ol parallel conversion approach n which (ibotneh e thold d an w systems
are operated for a month or two until i is clear t that there are no w bugs n
th ne i e system), or a phased conversion rategy st(in which the w system is
ne installed in one part of the organization as an initial tradually ia anl d
then gr installed in others). One of the most important aspects of
conversion is the development of a training plan to teach users how to use
the w system neand help manage the changes caused by the new system.
- The analyst team establishes a support plan for the system. This plan
usually includes a formal or informal post-implementation review as well as
a systematic way for identifying major and minor changes needed for the
system.
System Development Methodology
A methodology is a formalized approach to implementing the SDLC (i.e., it is a list
of steps and deliverables). There are many different systems development
methodologies, and each one is unique, based on the order and focus it places on
each SDLC phase. Some methodologies are used by government formal standards
agencies, whereas others have been developed by consulting firms to sell to clients.
Many organizations have internal methodologies that h the ave been honed over
years, and they explain exactly how each phase of the SDLC isin to performed be
that company.
There are many ways to categorize methodologies. One way is by looking at
whether they focus on business processes or the data that support the business. A
process-centered methodology emphasizes process models as the core of the
system concept. For example, process-centered methodologies would focus first on
defining the processes (e.g., assemble sandwich ingredients). Data-centered
methodologies emphasize data models as concept. In data the core of the system
centered methodologies would focus rst fi on defining the contents of the storage
areas (e.g., refrigerator) and how the contents By contrast, were organized.
objectoriented methodologies attempt to balance the focus between process and
data by incorporating both into one model.
The two key advantages of the structured design waterfall approach are that it
an identifies system requirement long before programming begins
and it
minimizes changesto ththe requirements ase project proceeds.e two key Th
disadvantages are thatth e design mus t be completely specified before
programming begins and that a long time elapses between the completion of
the system proposal in the analysis phase and the delivery of thesystem
(usually many months oryears).
2. Parallel Development:
Parallel development methodology attempts to address
theproblem ofe long delays between the analysis phaseand the delivery ofth
system. Instead of doing design and implementation in sequence, it performs a
general design for the whole system and then divides the project into a series
of distinct subprojects that can be designed an d implemented inpa rallel. Once
all subprojects are complete, there is a nalfi integr ation of the separate pieces ,
and the system is delivered shown below.
The primary advantage of this methodology is that it can reduce the schedule
timeto deliver a system; thus,there is less chancethe business ofchangesin
environment causing rework. However, the approach still suffers from problems
caused by paper documents. It also adds a new problem: Sometimes the
subprojects are not completely independent; designdecisionsmade in one
subproject mayaffect another, and the end of the project may require significant
integration efforts.
A ParallelDevelopment–based Methodology
Rapid ApplicationDevelopment (RAD)
A second category of methodologies includes rapid application development(RAD) –
based methodologies. These are a newer class of systems development
methodologiesthat emerged in the 1990 s. RAD-based methodologies attempt to
address bothweaknesses of s uctured design methodolog s by adjustingLC tr ie the SD
phases to get some part ofthe system developed quicklye and into the hands ofth
users. In thisway, the usersn cabetter understand sugges revisions d thesysteman t
that bring the system closer to whatis needed.
Most RAD-based methodologies recommendthat analysts us e special techniques
and computer tools to speed up theanalysis, design, and implementation phases, such
as CASE tools, joint application design (JAD)sessions,fourth-generation/visual
programming languages that simplifyg., Visual and speed up pro gramming (e.
Basic), and code generators that automatically produce programs from design
specifications. The combination ofe of these the changedSDLC phasesand the us
tools and techniques improve the speed and quality of systems development.
However, there is one possible subtle problem with RAD-based methodologies:
managing user expectations. Due to the use of the tools and techniques that can
improve the speed and quality of systems development, user expectations of what is
possible may dramatically change.
program that provides a minimal amount offeatures. The
fi rst prototype is
usually the
first part of thesystem thatown to the users and the project sponsor, isused. Thisis sh
who pro- vide comments. These comments are used toreanalyze, redesign, and re-
implement a second prototype, which provides afew more features. This process
continues in a cycle until the analysts, users, and sponsor agrthat the prototype ee
provides enough functionalityto beor installed and usedthe in ganization. After the
prototype (now called the system) is installed, refinementoccurs until it is accepted as
the new system (see Figure below).
A Prototyping-based Methodology
o
Advantage : Provides a system for the users to interact with, even if it is not
initially ready for use.
o
Disadvantage : Often the prototype undergoes such significant changes that
many initial design decisions prove tobe poorones.
Throwaway Prototyping
Throwaway prototyping – based methodologies are similarto prototyping-based
methodologies in that they include the developmentof prototypes;however,
throwawayprototypes are done at a different point in theSDLC. These prototypes are
used for a very different purpose than thosepreviously discussed, ande a verthey hav y
different appearance (see Figure below).
A Throwaway Prototyping–based Methodology
Agile Development
A third category of systemsdevelopment methodologies isstill emerging today: agile
development.
These programming-centric methodologies have few rules and
practices, all of which arefairly easy to follow. They focusstreamlining the onSDLC
by eliminating much of the modeling and documentation overhead and the time spent
on those tasks. Instead, projects emphasize simple, iterdevelopment. ative application
Examples of agile development methodologies include extreme programming, Sc rum,
and the Dynamic Systems Development Method (DSDM). The agile development
approach, as described next, typically is usedinconjunction with object-oriented
methodologies.
Selecting the Appropriate Development Methodology:
Selecting a methodology is not simple, as no one methodology is lwa ays best.
Many organizations have their own standards.
The next figure summarizes some important methodology selection criteria.
Clarity of user Requirements:
RAD methodologies of prototyping and throwaway prototyping are usually
more appropriate when user requirements are unclear as they provide
prototypes for users to interact with earlyin the SDLC.
Familiarity with Technology:
If the system is designed without some familiarity with the base
technology, risks increase because the tools may not be capable of doing
what is needed.
System complexity:
Complex systems require careful and detailed analysis and design.
Project teams who follow phased development-based methodologies tend to
devote less attention to the analysis of the complete problem domainthan they
might if they were using other methodologies.
System Reliability:
System reliability is usually an important factor in system development.
Throwaway prototyping-based methodologies are most appropriate when
system reliability is a high priority. Prototyping-based methodologies are
generally not a good choice as they lack careful analysis and design
phases.
Short Time Schedules:
RAD-based methodologies are well suited for projects with short time schedules
as they increase speed.
Waterfall-based methodologies are the worst choice when time is essential as
they do not allow for easy schedule changes.
Schedule Visibility:
RAD-based methodologies move many of the critical design decisions earlier in
the project; consequently, this helps project managers recognize and address risk
factors and keep expectations high.
Project team Skills and Roles:
Projects should consist of a variety of skilled individuals in order for a
system to be successful.
Six major skill sets an analyst should have include:
o
Technical
o
Business
o
Analytical
o
Interpersonal
o
Management
o Ethical
Categories of Analysts:
o Business Analyst
o Systems Analyst
o Infrastructure Analyst
o Change Management Analyst
o Project Manager
CHAPTER 2: PROJECT
INITIATION:
This chapter describes Project Initiation, the point at which an organization creates and
assesses the original goals and expectations for a new system. The rst stfi ep in the
process is to identify a project that will deliver value to the business and to create a
system request that provides basic information about the proposed system. Next, the
analysts perform a feasibility analysis to determine the technical, economic, and
organizational feasibility of the system; appr the systifopriate, em is select and the ed
development project begins.
INTRODUCTION
The first step in any new development project is for someone a manager, staff
member, sales representative, or systems analyst to see an opportunity to improve
the business. New systems start rst and fi foremost from a business need or
opportunity. Many ideas for new systems or improvements to existing ones arise from
the application of a new technology, but an understanding of technology is usually
secondary to a solid understanding of the business and its objectives.
Project Identification
A project is identified when someone in the organization identifies a business need to
build a system. This cn a business ould occur withi unit or IT, come from a stg eerin
committee charged w h identifyg business opportunities, or evolve from a itin
recommendation made l consultants. by externa Examples of business needs include
supporting a new marketing campaign, reaching out to a new type of customer, or
improving interactions with suppliers. Sometimes, needs ar e from issome kind of
―pain‖ within the organization, such as a drop in market share, poor customer service
levels, or increased competition. Other times, new business initiatives and strategies
are created, and a system is required enabltoe them.
Business needs also can surface when the organization identifies unique and
competitive wa ys of using IT. Many organizations keep an eye on emerging
technology , which is technology that is still being developed and is not yet viable for
widespread business use. For example, if companies ay st abreast of technology such
as the Internet, smart cards, and scent-technology in their earliest stages, they can
develop business strategies that leverage the capabilities of these technologies and
introduce them into the marketplace as a fi rst mover. Ideally, thtaey can ke advantage
of this first-mover advantage by making money and continuing to innovate while
competitors trail behind.
System Request
A system request is a document that describes the business reasons for building a sys-
tem and the value that the system is expected to provide. The project sponsor usually
completes this form as part of a formal system project selection process within the
organization. Most system requests include five elements: project sponsor, business
need, business requirements, business value, and special issues (see Figure below). The
sponsor describes the person who will serve as the primary contact for the project,
and the business need presents the reasons prompting the project. The business
requirements of the project re business capabilities efer to th that the system will need
to have, and the business value describe ths e benefits that the organization should
expect from the system. Special issues are included on the document as a catch-all for
other information that should be considered in assessing the project. For example, the
project may need to be completed by a specific deadline. re of any special Project
teams need to be awa circumstances that could affect the outcome of the system.
Figure below shows a template for a system request.
