LECTURE 3' Approaches to System Development

1
LECTURE 3.Approaches to System Development
2
The SDLC provides an overall framework for
system development. There are many more concepts
for help, including methodologies, models, tools
and techniques. I. Methodologies, Models, Tools
and Techniques Methodologies A system
development methodology is a guidelines to follow
for completing every activity in the SDLC,
including specific models, tools and techniques.
Some methodologies are very formal, and
contain direct instruction. Everything is
defined, including the view of documentation and
content of reports. Other methodologies are
much more informal just general description of
what should be done. Models A model is a
representation of some aspect of the real world.
A model may be physical (like a model of an
airplane) or abstract (e.g. in form of
mathematical notation or in graphical form).
Most models, used in system development, are
graphical (diagrams and charts). They include
representations of inputs, outputs, processes,
data, objects, object interactions, locations,
networks, devices, or highlighting the tasks for
the project .
3

• The models, used in SDLS, may be summarized as
• Models of system components
• Flow chart
• Data flow diagram (DFD)
• Entity-relationship diagram (ERD)
• Structure chart
• Use case diagram
• Class diagram
• Sequence diagram

(2) Models to manage the development process
PERT chart Gantt chart Organizational
hierarchy chart Financial analysis model
NPV, ROI
4
Tools A tool is a software support that helps
create models or other components required in the
project. A list of tools types includes
Project management application Drawing/graphics
application Word processor/text editor
Computer-aided system engineering (CASE) tools
Integrated development environment (IDE)
Database management application
Reverse-engineering tool Code generator tool
Techniques A technique is a collection of
guidelines that help the analyst complete a
system development activity or task. It might be
step-by-step instructions or more general
advices.
5
A list of techniques used in system development
includes Strategic planning techniques
Project management techniques User interviewing
techniques Data-modeling techniques
Relational database design techniques
Structured analysis technique Structured
programming technique Software-testing
techniques (e.g. usability testing)
Object-oriented analysis and design
techniques Interaction A methodology includes a
collection of techniques used to complete
activities within each phase of the SDLC. The
activities include completion of a variety of
models Software are used to help to complete
the activities. Figure 3-1 shows the
relationships among the components of a
methodology.
6
FIGURE 3-1 Relationships among the components of
a methodology.
7
II. Three Approaches to System Development The
most general approaches to system development
are The structured approach The
Information engineering approach The
object-oriented approach They form the basis of
virtually all methodologies. 2.1 The structured
approach The structured approach is made up of
Structured programming Structured analysis
Structured design Sometimes, it is collectively
called Structured Analysis and Design Technique
(SADT). 2.1.1 Structured programming involves
some basic features Structured program
Top-down programming Modular programming A
structured program is
8

• (1) A program or program module that has one
  beginning and one ending, and each step in the
  program execution consists of one of the
  following
• Sequence (of program statements)
• Decision (where one set of statements or
  another executes)
• Repetition (of a set of statements)
• Figure 3-2 shows three constructs of structured
  programming.

FIGURE 3-2 Three constructs of structured
programming.
9
Following these rules allowed much easier to read
and modify a program, and to interpret what a
program does. (2) Another concept related to
structured programming is top-down programming.
It includes Division of complex programs into
a hierarchy of smaller, (more manageable) program
modules (see Figure 3-3) Top module calls
lower-level modules Lower-level modules deal
with lower-level detail Each module is written
using the rules of structured programming (3)
Sometimes separate programs work together as one
system. One program calls other program. Such
an hierarchy of multiple programs called modular
programming
FIGURE 3-3 Top-down or modular programming
10
2.1.2 Structured design arose as a response to
increasing the complexity of information systems
involving many different functions performed by
dozens of separate programs. It is A technique
providing guidelines for deciding what the set of
programs should be, what each program should
accomplish, and how the programs should be
organized into a hierarchy The modules and the
arrangements of modules are shown graphically
using a model called a structure chart. (Figure
3-4 is an example)
FIGURE 3-4 A structure chart created using the
structured design technique.
11
Two main principles of program modules
design (1) loosely coupled (maximal
independence of each module allows to design and
modify it without interfering with the
performance of the others) (2) highly cohesive
(each module accomplishes one clear task if
changes to the module are required, none will
accidentally affect other tasks). Assumes
designer knows what system needs to do Quality
is defined in terms of how easily the design can
be understood and modified when the need arises.
New variations -Database management
systems are used in the system and program
modules are designed to interact with the
database - Developing of user-interface
design technique to develop systems adjusted to
non-technical users 2.1.3 Structured analysis is
a techniques to define What the system
needs to do (processing requirements)
What data the system needs to store and use
(data requirements) What inputs and
outputs are needed How the functions
work together to accomplish tasks
12
Key graphical model used data flow diagram
(DFD) Shows inputs, processes, storage
and outputs and how they function together
(Figure 3-5)
FIGURE 3-5 A data flow diagram (DFD) created
using the structured design technique.
13
Another key graphical model
entity-relationship diagram (ERD) Focuses
on identifying types of things (entities) which
the system needs to store information about (e.g.
customers, items and details) Specifies
relationships between these things or entities
Used a lot for design of databases (Figure 3-6
shows an example of an ERD)
FIGURE 3-6 An entity-relationships diagram (ERD)
created using the structured
design technique.
The recent variation of structured analysis
- Defining systems processing requirements by
identifying all of the events that will cause the
system to react in some way. Figure 3-7
illustrates the sequence from structured analysis
through structured design to structured
programming.
14
FIGURE 3-7 The sequence from structured analysis
through structured design to structured
programming.
15
Weaknesses of the Structured Approach
Techniques address some but not all of the
activities of analysis and design Techniques
make system development not enough formal (not
like an engineering discipline) but rather like
an art. The transition from the data flow
diagram (in structured analysis) to the structure
chart (in structured design) did not work well in
practice. data modeling using structure chart
and ER diagram were more important than modeling
processes (using dataflow diagrams) However,
the structured approach overall still made
processes rather than data the central focus of
the system Many felt a strategic planning
technique needed to be included in the approach
to development and to determine which systems to
be built and to provide some initial
requirements. The named reasons turned
developers to using another approach
information engineering.  
16
2.2 The Information Engineering Approach A
system development methodology that focuses on
strategic planning to identify all the
organization information needs (the application
architecture plan), data modeling, and automated
tools - Focuses more on data itself than the
structured approach. But just as the structural
approach includes data requirements, information
engineering includes processes, too. The
processing model of information engineering, the
process dependency diagram, is similar to a data
flow diagram, but it focuses more on which
processes are dependent on other processes and
less on data inputs and outputs. At each step
of project development, activities are defined
the system needs to support, and models are
created of the processes and the data as well as
the ways they are integrated Provides more
complete life cycle support through the use of an
integrated CASE tools (help to automate systems
development final program code can be generated
automatically by the CASE tools) Became
popular on large-mainframe systems in the 1980s,
less used in the 1990s on smaller desktop
systems (but concepts still used by planning and
emphasis on data modeling)
17
Mainly introduced by James Martin who wrote
several books on information engineering and
developed CASE tools to support it (see Figure
3-8)
Top Management View
Planning
Select

Analysis
Select
Design
Select
Construction (Implementation)
FIGURE 3-8 James Martins Pyramid Approach to
Information Engineering
18

• Following Martin
• Information engineering uses computer tools
  (graphical) to drive the phases, starting with
  planning
• Project Planning
• Computer tools to create organization charts,
  top-level ER diagrams, function decompositions
• Analysis
• Tools for expanding project plan into data flow
  diagrams, further decompositions (e.g. Click on
  to get further details on the charts)
• From the Analysis created on-line can expand
  down to system design
• Tools designed to allow end users to participate
• Attempt to speed up design
• Automate design and add consistency checking
• Create and evolve prototypes
• Construction
• Approach takes automation one step further, to
  automatically generated code (e.g. COBOL) from
  the design specifications
• Both approaches (structural and information
  engineering) define information systems
  requirements, design and construct information
  systems by looking at processes, data and the
  interaction of these two. We will call them
  traditional approach. An object-oriented
  technology provides a completely different
  approach.

19

• 2.3 The Object-Oriented (OO) Approach
• Views an information system as a collection of
  interacting objects that work together to
  accomplish tasks. The system consists of objects
  but not of processes or programs, or data
  entities or files.
• Based on notion of objects things in the
  computer system (and the world) which have
  behavior and respond to messages
• Objects can be anything
• A menu bar, or window on the screen
• A car
• An employee
• A customer etc.!
• OO Approach includes
• -object-oriented analysis (OOA) defining
  all of the types of objects that do the work in
  the system and showing how the objects interact
  to complete tasks
• - object-oriented design (OOD) defining
  all of the additional types of objects necessary
  to communicate with people and devices in the
  system and refining the definition of each type
  of object so it can be implemented with the
  specific language or environment
• - object-oriented programming (OOP)
  writing statements in a programming language to
  define what each type of objects does
• Figure 3-9 illustrates the OOA.

20
FIGURE 3-9 The OOA to systems (read clockwise
starting with user).
21
A collection of similar objects represents a
class. For every class, there may be more
specialized subclasses (e.g. checking account
and savings account are two subclasses of the
class account). Subclasses inherit
characteristics of the class above. OOD uses a
class diagram to show all of the classes of
objects in the system (see Figure 3-10).
FIGURE 3-10 A class diagram created during OOA.
22

• Object Oriented Terms
• Class Diagram is a graphical model that shows all
  the classes of objects in the system
• For every class (grouping of related objects)
  there may be specialized subclasses
• Subclasses inherit properties of classes above
  them

CLASS
Class Car
ISA
Subclass Ford
Subclass GM
SUBCLASS
INSTANCE
Mustang
23

• History of Object-Oriented Approach
• Began with development of programming language
  Simula in Norway in the 1960s (involved objects
  like ships, buoys and tides to simulate ship
  movement in fiords).
• In the 1970s, Smalltalk language was developed
  to create graphical user interfaces that involved
  objects like menus, buttons, check boxes and
  dialog boxes
• Recent OO languages C, Java
• Advantages of OOA
• OOA is natural (intuitive) for people. Because
  people tend to think about the world in terms of
  tangible objects rather then in terms of complex
  procedures.
• OOA involves classes of objects, and many
  systems in the organization use the same objects,
  these classes can be used over and over again
  whenever they are needed.

24
III. The SDLC Variations There are many
variations in general scheme of the SDLC. Some
variations are based on the life cycle phases.
Other variations are based on the degree of
iteration that is allowed. Finally, some life
cycles differ in their emphasis on the social and
technical subsystems. 3.1 Waterfall
models Traditionally, the SDLC is based on
waterfall model. This model is characterized
by Each life cycle phase is completed in
sequence and then the results of the phase flow
on to the next phase There is no going back
once the phase is completed (like a waterfall) or
it is extremely difficult to do The key
deliverables for each phase are typically
produced on paper (hundreds of pages in length)
The decisions made at each phase are frozen,
i.e. they cannot be changed Figure 3-11 shows
the principle of the waterfall model of the SDLC.
25
FIGURE 3-11 The waterfall model of the SDLC.
26
Figure 3-12 shows some examples of life cycles
based on the waterfall model.
FIGURE 3-12 Life cycles with different names for
phases.
27
Differences in Approaches (comments to the
table) Traditional approach includes a
feasibility study at the beginning assumes the
project was unplanned rather than part of overall
strategic system planning as a result, system
investigation and systems analysis together make
up the analysis phase in the SDLC Information
engineering includes the overall strategic
planning efforts as part of the life cycle two
design phases are included business system and
technical design construction and transition are
two parts of the implementation phase. The
objectory model includes only four phases with
less traditional names The forth life cycle
model has eight phases, which are named as
activities Despite differences, the same
overall tasks need to be carried out i.e. four
traditional phases planning, analysis, design
and implementation The two key advantages of
the waterfall model Identifying system
requirements long before programming begins It
minimizes changes to the requirements as the
project proceeds
28
The key disadvantages The design must be
completely specified on paper before programming
begins A long time elapses between the
completion of the system proposal in the analysis
phase and the delivery of the system (usually
many months or years). A paper document is
often a poor communication mechanism, so
important requirements can be overlooked in the
hundreds of pages of documentation Users rarely
are prepared for their introduction to the new
system, which occurs long after the initial idea
for the system was introduced. If the project
team misses important requirements, expensive
post-implementation programming may be needed.
A system may require significant rework because
of changes in business environment since the time
the analysis phase occurred. It means going back
to the initial phases and following the changes
through each of the subsequent phases in
turn. 3.2 Parallel Model The Parallel Model of
the SDLC attempts to address the problem of long
delays between the analysis phase and the
delivery of the system. Instead of doing the
design and implementation in sequence, it
performs a general design for the whole system
and then divides the project into series of
distinct subprojects that can be designed and
implemented in parallel Once all subprojects
are complete, the final integration of the
separate pieces is delivered (see Figure 3-13)

29
FIGURE 3-13 The parallel model of the SDLS.
30
The primary advantages Can reduce the schedule
time required to deliver a system There is less
chance of changes in the business environment
causing rework The key disadvantages Still
suffers from problems caused by paper
documentation A new problem sometimes the
subprojects are not completely independent
design made in one subproject may affect another
and the end of the project may require
significant integrative efforts 3.3 Models with
Iteration Iteration means that work tasks are
done once, then again, and yet again (i.e. they
are repeated). With each iteration, the result is
refined so that it is closer to what is
needed. Iteration for the SDLC means Assumes
no one gets the right results the first time Do
some analysis, then some design, then some
implementation, then do some further analysis,
etc until you get it right (see Figure 3-14)
31
FIGURE 3-14 Iteration across life cycle phases.
32
Idea not always realistic to complete
analysis before starting design Waterfall no
longer applies - Phases become blurred
Decisions are not frozen at the end of each
phase Good for projects where requirement
specifications are hard to arrive at However,
can lead to ambiguity Harder to know how far
you are along in the project Could be hard to
manage Iteration the process of looping
through the same development activities multiple
times, sometimes at increasing levels of detail
or accuracy Information engineering can be
done with iteration Object-oriented approach
is considered to be highly iterative Spiral
model Breaks each project into smaller pieces,
each with a different type of risk (Sources of
risk from undefined requirements to complex
technology, to an uncertain competitive
environment) The project starts out small,
handling a few of the risks initially Then the
project expands in next iteration to address more
of the risks Eventually the system is
completed (all risks addressed) Figure 3-15 shows
the spiral model
33
FIGURE 3-15 The spiral life cycle model.
The project begins in the center of the spiral
where project is still small, easy to manage and
low in risk Then the project slowly
expands  Advantage The iterative nature, coupled
with the focus on reducing risk make this model
very effective.
34
3.4 Models with an emphasis on people Some
methodologies recognize that IS, in fact, are
sociotechnical systems, that is they include two
subsystems (1) social and (2) technical that
must be considered and designed together. The
SDLC emphasizes these two aspects (example
Multiview SDLC). Multiview is characterized by
User-centered design and participatory design
(see Figure 3-16) Human activity is studied in
detail Analysis and design of sociotechnical
aspects of the system are considered in one
phase The design of the human-computer
interface as a separate phase also emphasizes the
importance of the users in the development of the
system End users often participate in all
aspects of system development  
FIGURE 3-16 Phases of the multiview SDLC
35
Another approach the soft systems methodology
More emphasis on people Data and process in a
system are relatively easy to model Real world
requires including people in the model People
have different and conflicting objectives,
perceptions and attitudes making the system
behavior unpredictable (a rich picture diagram is
used in complex systems to show people and their
attitudes) 3.5 Rapid Application Development
Rapid application development (RAD) is one of
the variations of SDLC that aims to speed up the
development process. RAD emerged in the 1990s as
an attempt to address both weaknesses of the
waterfall development long development times and
the difficulty in understanding a system from
paper-based description. Some variations of RAD
approach Try to speed up the activities in
each phase (e.g. speeding the analysis phase by
scheduling intensive meetings of key participants
to get information gathered and decisions made
rapidly) Using iterative development (as spiral
life cycle model) to speed up the process of
getting to design and implementation Building
prototypes of the system during analysis and
design phases. It improves understanding of the
system requirements
36
Using CASE (computer-aided system engineering)
tools to speed up the analysis, design and
implementation phases The RAD approach may be
realized in several models 3.5.1 Phased
Development Breaks the overall system into a
series of versions that are developed
sequentially The analysis phase identifies the
overall system concept. The project team, users
and system sponsor categorize the requirements
into a series of versions The most important
and fundamental requirements are bundled into the
first version of the system. The analysis phase
then leads into design and implementation, but
only with the set of requirements identified for
version 1 Once version 1 is implemented,
work begins on version 2. Additional analysis is
performed on the basis of the previously
identified requirements and combined with new
ideas and issues that arose from users
experience with version 1. Version 2 then is
designed and implemented, and work immediately
begins on the next version. This process
continues until the system is complete Figure
3-17 illustrates this model.  
37
FIGURE 3-17 The phases development model.
38
Advantage Quickly getting a useful system
into the hands of users. Although it does not
perform all the functions the users need, it
helps them sooner to identify important
additional requirements Disadvantage The users
begin to work with systems that are incomplete.
It is critical to identify the most important and
useful features and include them in the first
version. 3.5.2 Prototyping Performs the
analysis, design and implementation phases
concurrently, and all three phases are performed
repeatedly in a cycle until the system is
completed. The basics of analysis and design
are performed, and work immediately begins on a
system prototype (i.e. a quick-and-dirty
program that provides a minimal amount of
features The first prototype is shown to the
users and the project sponsor, who provide
comments, which are used to reanalyze, redesign,
and re-implement a second prototype that provides
a few more features
39
This process continues in a cycle until the
analysts, users and sponsor agree that the
prototype provides enough functionality to be
installed and used. After that, refinement occurs
until it is accepted as the new system. (Figure
3-18)  
FIGURE 3-18 The Prototyping model.
The key advantage Very quickly provides a
system for users to interact with. It reassures
the users that the project team is working on the
system. The users can interact with the prototype
to better understanding what it can and cannot do
rather than attempting to understand a system
specification on paper.  
40
The major disadvantage Fast-paced system
releases challenge attempts to conduct careful,
methodical analysis. Often the prototype
undergoes such significant changes that many
initial design decisions become poor ones. This
can cause problems in the development of complex
systems because fundamental issues and problems
are not recognized until well into the
development process. 3.5.3 Throwaway
Prototyping Is similar to the prototyping model
in that it includes the development of
prototypes, however, they are done at a different
point in the SDLC Has a relatively thorough
analysis phase that is used to gather information
and to develop ideas for the system concept. Many
of the features suggested by the users may not be
well understood and many technical issues may not
be solved. Each of these issues are examined by
analyzing, designing and building a design
prototype (it is not a working system it only
represents a part of the system that needs
additional refinement and it contains only enough
details to enable users to understand the issues
under consideration) Typically, several
prototypes are used during analysis and design
phase. Each of them is used to minimize the risk
of missing of important issues before the real
system is built.
41
Once the issues are resolved, the project moves
into design and implementation. At this point,
the design prototypes are thrown away, what is a
principal difference between this model and
prototyping, in which the prototypes evolve into
the final system (see Figure 3-19)
FIGURE 3-19 The Trowaway Prototyping model.
The key advantages Balances the benefits of
well-through-out analysis and design phases with
the advantages of using prototypes to refine key
issues before a system is built. It may take
longer to deliver the final system as compared
with prototyping (as far as the prototypes do not
become the final system), but this model usually
produces more stable and reliable systems.
42
3.5 Selecting the Appropriate Method Choosing a
model of development is not simple, because no
one model is always best. Many organizations have
standards and policies to guide the choice of
model it might be one approved method or several
options. Figure 3-20 summarizes some important
selection criteria
FIGURE 3-20 Criteria for selecting a model of the
SDLC. Clarify of user requirements Sometimes the
user requirements are unclear or subject to
change. Prototyping and throwaway prototyping are
more appropriate models for such situations,
because they provide prototypes for user to
interact with at early stages of the SDLC.
43
Familiarity with Technology When the system will
use new technology, which is unfamiliar for the
analysts and programmers (e.g. the first
Web-based project with Java), it increases the
risks. Application of the new technology as early
as possible will improve the chance of success.
Throwaway prototyping is particularly appropriate
for this situation since it explicitly encourages
the developers to develop design prototypes for
areas with high risks. Phased model is good as
well because it creates opportunities to
investigate the technology in some depth before
the design is complete. System Complexity
Complex systems require careful and detailed
analysis and design. Throwaway prototyping is
particularly well suited to such situation, but
prototyping is not. The traditional structured
methodologies can handle complex systems, but
without the ability to get the system or
prototypes into users hands early on, some key
issues may be overlooked. Even though the phased
model enables users to interact with the system
early in the process. Short time schedules
Projects with short time schedules are well
suited for RAD models as far as they are designed
to increase the speed of development. Prototyping
and phases development are excellent choices
because they best enable the project team to
adjust the functionality in the system. If the
project schedule starts to slip, it can be
readjusted by removing functionality from the
version or prototype under development. The
waterfall model is the worst choice, because it
does not allow for easy schedule changes.
44
Schedule visibility One of the greatest
challenges in systems development is knowing
whether a project is on schedule. This is
particularly true of the structured methods
because design and implementation occur at the
end of the project. The RAD models move many of
the critical design decisions to an earlier point
in the project to help project managers to
recognize and address risk factors and keep
expectations in check. IV. Computer-Aided
System Engineering (CASE) Tools CASE tools are
software tools designed to help systems analyst
complete development tasks The CASE tool
contains a database of information called a
repository The repository stores information
about the system, including models, descriptions,
and references that link the various model
together. Information stored in repository can be
used in a variety of ways by the development
team. Every time a team member adds information
about the system, it is immediately available for
everyone else. Figure 3-21 shows CASE tools
capabilities that surround the repository.
45
FIGURE 3-21 A CASE tool repository contains all
information about the system.
46
CASE tools can check the models to make sure
they are complete and follow the correct
diagramming rules CASE tools can check one
model against another to make sure they are
consistent 4.1 Types of CASE tools Upper
CASE tools Provide support for the analyst
during the analysis and design phases, such as
creating and checking models and storing
information in the repository. Lower CASE
tools Provide support for implementation,
primarily generating programs and database
schemas based on specifications in the
repository Integrated CASE (ICASE)
tools Provide a combined support for the full
life cycle CASE tools may be general and
flexible allowing using any approach to
development desired. Others are designed for very
specific methodologies (like for information
engineering) 4.1 Examples of CASE tools
Information engineering CASE tools are
KnowledgeWare and Texas Instruments Information
Engineering Facility (IEF), combined later into
more flexible tool now called CoolTools
47
Flexible tools Visual Analyst helps to
create traditional models, like data flow
diagrams and entity-relationship diagrams and
supports object-oriented models, now called an
integrated application development tool (see
Figure 3-22)
FIGURE 3-22 The CASE tool Visual Analyst showing
a data flow diagram.
48
Rational Rose is a tool referred to as a visual
modeling tool that specifically supports the
object-oriented approach based on unified
modeling language (UML) standards. Provides
reverse-engineering and code-generating
capability and can be integrated with additional
tools to provide a complete development
environment. Figure 3-23 shows Rational Rose with
a variety of UML model.
FIGURE 3-23 The visual modeling tool Rational
Rose showing diagrams from the object-oriented
approach.
49
The most recent concept of round-trip
engineering allows synchronizing the graphical
models (such as class diagram) with generated
program code. If the program code is changed, the
class diagram is updated and contra versa, if the
class diagram is changed, the program code is
updated. Together J uses UML diagrams with the
Java programming language to provide round-trip
engineering support. Figure 3-24 shows Together J
with a class diagram and synchronized Java code.
FIGURE 3-24 The round-trip engineering tool
Together J showing a class diagram with
synchronized Java source code.
50
4.3 Background The case for CASE As software
systems get large and more complex they have
become prone to unpredictable behavior and bugs
Problem of systems that are not reliable, do
not meet requirements or that just plain dont
work! CASE tries to eliminate or reduce design
and development problems Ultimate goal of CASE
is to separate the application programs design
(and analysis) from the programs code
implementation - Generally, the more
detached the design process is from actual
coding, the better - Traditional software
development emphasized programming and debugging,
CASE focuses on good analysis and design 4.4
Causes of failure (and symptoms) in software
development Requirements Analysis No
written requirements Incompletely specified
requirements No user interface mock-up
No end user involvement
51
Design Lack of, or insufficient, design
documents Poorly specified data structures
and file formats Infrequent or no design
reviews Implementation Lack of, or
insufficient coding standards Infrequent or
no code reviews Poor in-line code
documentation Unit test and Integration
Insufficient module testing Lack of proper
or complete testing Lack of an independent
quality assurance group Beta Test Release
Complete lack of a beta test Insufficient
duration for beta test Insufficient number
of beta testers Wrong beta testers
selected Maintenance Too many bug reports
Fixing one bug introduces new bugs
52
4.5 What CASE can do to help Help to make
analysis and design process more rigorous and
complete, to reduce bugs later Examples of
functions in tools Provide support for
diagramming (for analysis and design)
Provide support for checking consistency of
design Provide graphing support to help
users visualize an existing or proposed
information system (e.g. Data flow diagrams)
Detail the processes of your system in a
hierarchical structure Produce executable
applications based on your data flow diagrams
(which can be made from point and click
placements of icons) Integrate specific
methodologies into windowing environments V.
Analysis and Design Phases in More
Detail Different system development
methodologies recommend different techniques for
completing activities. But the activities always
involve answering the same key questions.  
53
5.1 The Analysis Phase Involves definition in
great detail what the information system needs to
accomplish to provide the organization with the
desired benefits. There are six activities that
must be completed during the analysis (see Figure
3-25)
FIGURE 3-25 Analysis phase activities and key
questions.
54
These activities are often completed in
parallel. Analysis Phase Activities   Gather
Information Involves gathering lots of
information System analysts obtain
information from people who will be using the
system By interviewing them
By observing their work System analysts
obtain information by reviewing documents and
policy statements (e.g. at a bank) System
analyst really needs to become an expert in the
business area the system will support or should
even actually do some or part of the task to get
a feel for what is done (e.g. in order to
automate order-entry you may need to become an
expert on the task (knowing how orders are
processed)     The gathered information
involves Understanding the existing
system Identifying all current and
future users, locations, system interfaces
(inside and outside the organization)
Identifying possible software package solutions
that might be used
55
Define System Requirements Gathered information
represents system requirement. There are two sets
of system requirements Technical
Requirements( e.g. facts about needed system
performance, number of transactions)
Functional Requirements (what the system is
required to do - e.g. reduce fuel costs by
calculating where is best to fuel up) This
process involves modeling. It could be
Logical Model (any model that shows what the
system is required to do without committing to
any one technology requirements model is
logical) Physical Model (any model that
shows how the system will actually be
implemented) Models are often graphical in
nature Data flow diagrams (DFDs)
Entity-relationship diagrams (ERDs)
Prioritize Requirements Important to
establish which functional and technical
requirements are most critical Why? Since
resources are always limited and you want to
address the most important things Unless
evaluation priorities, system requirements tend
to expand as users make more suggestions (called
scope creep)
56
Prototype for Feasibility and Discovery If
system involves new technology, the team may need
to get experience working with it. Creating
prototypes can be very valuable Prototyping
helps to understand possibilities and limitations
of the technology Good idea for projects
where requirements are hard to define beforehand
By showing prototypes to end users can get
feedback into what is really needed
Prototypes help users (and analysts) to discover
requirements they might not thought about
otherwise, i.e. think creatively Generate and
Evaluate Alternatives Could include
considering more than one method to develop
system Could involve in-house development or
outsourcing to a consulting firm Might be
able to use off the shelf software package  
Each alternative has costs and benefits to be
considered Also must consider technical
feasibility Review Recommendations with
Management Usually done when all the above
are completed Must decide if project should
continue at all Must decide on which
alternative is best (if you are going ahead with
the project) NOTE at this point should
include CANCELLATION of the project as an option.
57
Possible reasons are May have found costs
were too high May have found benefits were
lower than thought Maybe the business
environment suddenly changed making the project
less important If the project is worthwhile, the
project team has detailed documentation on
System requirements Proposed design
solution 5.2 The Design Phase Involves
specifying in detail how system will work using
particular technology Some of the design
details are developed during systems analysis,
but much more detail is required Usually
activities of system design are done in parallel
(see Figure 3-26)
58
FIGURE 3-26 Design phase activities and key
questions.
59
Prototype for Design Details May be important
to continue to create and evaluate prototypes
Often associated with interface design, or to
confirm design choices about database, network
architecture or even programming environments,
etc Think of how to use prototypes to help
understand design decisions Prototypes are
important part of rapid application development
(RAD) that evolve into the finished
system.   Design the User Interfaces
































































Quality of the user
interface is a critical aspect of the information
system. To the user, the user interface is what
the IS is. Nature of user interface emerges
very early during design Specification of the
kind of tasks the users will complete conducted
to define the user interface Can involve
iterative development and refinement of user
interfaces (testing with end users) For most
cases, interfaces are graphical (with windows,
dialog boxes, etc), can include sound, video and
voice commands Sometimes specialists in user
interface design might be called (interface
designer, usability consultants, or human factors
engineers) The visual programming environments
now available make it easy for developers to
create graphical user interface but it is still a
very difficult task to make it friendly and
intuitive.
60
Design the System Interfaces No real system
exists in a vacuum. Many other ISs will be
affected by the new IS Will probably need to
interface with other systems and databases to
exchange information All systems should be
designed to work together from the beginning. The
component that enables systems to share
information is the system interface, and each
system interface needs to be designed in detail
Interfacing problems can be quite complex. In
some cases, the new system needs to interface
with a system outside the organization or with a
package application that the organization has
purchased and installed Design the Application
Architecture Involves specifying in detail how
all system activities will be carried out These
activities are specified during system analysis
in great detail as logical models, without
indicating what specific technology would be
used Once a specific design alternative is
selected, the physical models can be designed.
Physical models could include
Physical data flow diagrams
Structure charts
Object-interaction diagrams
61
Decision has to be made about automation
boundary (i.e. separate the manual work done by
people from the automated work done by computer)
Approach to application design and the design
models will vary depending on the technology
being used (e.g. client-server architecture
versus centralized architecture, object-oriented
technology versus COBOL-based programming)
Design and Integrate the Database    Designing
the database is another key design activity  
The data model (a logical model) created during
system analysis is used to create the physical
model of the database.    A database may be
A collection of traditional computer files
Relational database consisting of dozens
or even hundreds of tables (more often)      
Files and relational databases in the same
system       Object-oriented database
Important technical issues when designing the
database are         Response time       
Integration the new database with existing
databases
62
Design and Integrate the Network Sometimes a
new system is implemented along with a new
network (in this case, the network needs to be
designed)    More often, the network has been
established by network specialist based on an
overall strategic plan (the project team must
integrate the system into an existing network)
Important technical issues Reliability
Security Throughput May need to call
experts on networking Design and Integrate the
System Controls Involves ensuring that the
system has adequate safeguards to protect
organizational assets (i.e. system controls)
Must be considered in the context of all other
design activities User interfaces
System interfaces Application architecture
Database and network design
63
User-interface controls limit access to system
to authorized users only System interface
controls ensure that other systems cause no harm
to this system Application architecture
controls ensure that transactions recorded and
other work are done by the system correctly
Database controls ensure that data cannot be
accidentally (or maliciously) altered and are
protected from unauthorized access and from
accidental loss due to hardware failure
Network controls ensure communication through
network is protected All of those controls need
to be designed into the system based on specific
technology
64
Readings
Todays lecture Chapter 3 Approaches to
System Development For next lecture Chapter 4
Investigating System Requirements
Thank you !!!