System Analysis and Design

CSE 307 Sec 1

Instructor: Sabrina Alam

Lecture 01
Systems, Roles, and
Development Methodologies
Learning Objectives
 Understand the need for systems
analysis and design in organizations.
 Realize what the many roles of the
systems analyst are.
 Comprehend the fundamentals of
three development methodologies:
 SDLC
 The agile approach
 Object-oriented systems analysis and
design

1-2
Information—A Key Resource
 Fuels business and can be the
critical factor in determining the
success or failure of a business
 Needs to be managed correctly
 Managing computer-generated
information differs from handling
manually produced data

1-3
Major Topics
 Fundamentals of different kinds of
information systems
 Roles of systems analysts
 Phases in the systems development
life cycle as they relate to Human-
Computer Interaction (HCI) factors
 CASE tools
 Open Source Software

1-4
Need for Systems Analysis
and Design
 Installing a system without proper
planning leads to great user
dissatisfaction and frequently causes
the system to fall into disuse
 Lends structure to the analysis and
design of information systems
 A series of processes systematically
undertaken to improve a business
through the use of computerized
information systems
1-5
Roles of the Systems Analyst
 The analyst must be able to work
with people of all descriptions and
be experienced in working with
computers
 Three primary roles:
 Consultant
 Supporting expert
 Agent of change

1-6
Qualities of the Systems
Analyst
 Problem solver
 Communicator
 Strong personal and professional
ethics
 Self-disciplined and self-motivated

1-7
Systems Development Life
Cycle (SDLC)
 The systems development life cycle
is a phased approach to solving
business problems
 Developed through the use of a
specific cycle of analyst and user
activities
 Each phase has unique user
activities

1-8
The Seven Phases of the Systems
Development Life Cycle (Figure
1.1)

1-9
Incorporating Human-Computer
Interaction (HCI) Considerations

 The demand for analysts who are

capable of incorporating HCI into
the systems development process
keeps increasing, as companies
begin to realize that the quality of
systems and the quality of work life
can be improved by taking a
human-centered approach at the
outset of a project

1-10
Identifying Problems,
Opportunities, and Objectives
 Activity:
 Interviewing user management
 Summarizing the knowledge obtained

 Estimating the scope of the project

 Documenting the results

1-11
Identifying Problems,
Opportunities, and Objectives
 Output:
 Feasibilityreport containing problem
definition and objective summaries
from which management can make a
decision on whether to proceed with
the proposed project

1-12
Determining Human
Information Requirements
 Activity:
 Interviewing
 Sampling and investing hard data
 Questionnaires
 Observe the decision maker’s behavior
and environment
 Prototyping
 Learn the who, what, where, when,
how, and why of the current system

1-13
Determining Human
Information Requirements
 Output:
 The analyst understands how users
accomplish their work when interacting
with a computer
 Begin to know how to make the new
system more useful and usable
 Know the business functions
 Have complete information on the:
 People
 Goals
 Data
 Procedure involved

1-14
Analyzing System Needs
 Activity:
 Create data flow, activity, or sequence
diagrams
 Complete the data dictionary
 Analyze the structured decisions made
 Prepare and present the system
proposal
 Output:
 Recommendation on what, if anything,
should be done

1-15
System proposal
 Summarizes what has been found
• about users
• usability and usefulness of current
system
• provides cost/benefit analysis of
alternatives
• makes recommendations on what (if
anything) should be done

16
Designing the
Recommended System
 Activity:
 Design procedures for data entry
 Design the human-computer interface
 Design system controls
 Design database and/or files
 Design backup procedures
 Output
 Model of the actual system

1-17
Developing and
Documenting Software
 Activity:
 System analyst works with
programmers to develop any original
software
 Works with users to develop effective
documentation
 Programmers design, code, and remove
syntactical errors from computer
programs
 Document software with help files,
procedure manuals, and Web sites with
Frequently Asked Questions
1-18
Developing and
Documenting Software
 Output:
 Computer programs
 System documentation

1-19
Testing and Maintaining the
System
 Activity:
 Testthe information system
 System maintenance
 Maintenance documentation

 Output:
 Problems,if any
 Updated programs
 Documentation

1-20
Implementing and
Evaluating the System
 Activity:
 Train users
 Analyst plans smooth conversion from
old system to new system
 Review and evaluate system

 Output:
 Trained personnel
 Installed system

1-21
Some Researchers Estimate that the Amount of
Time Spent on Systems Maintenance May Be as
Much as 60 Percent of the Total Time Spent on
Systems Projects (Figure 1.2)

1-22
The Impact of Maintenance
 Maintenance is performed for two
reasons:
 Removing software errors
 Enhancing existing software

 Over time the cost of continued

maintenance will be greater than
that of creating an entirely new
system. At that point it becomes
more feasible to perform a new
systems study.
1-23
Resource Consumption over the
System Life (Figure 1.3)

1-24
Approaches to Structured Analysis and
Design and to the Systems
Development Life Cycle

 Traditionalsystems
development life cycle
 CASE systems development

life cycle
 Object-oriented systems

analysis and design

1-25
Case Tools
 CASE tools are productivity
tools for systems analysts
that have been created
explicitly to improve their
routine work through the use
of automated support

1-26
Reasons for Using Case Tools
 Reasons for using CASE tools
 Increasing analyst productivity
 Improving analyst-user communication

 Integrating life cycle activities

1-27
Reasons for Using Case Tools
cont..
 Increasing analyst productivity:
• Automates the drawing and modifying of
diagrams
• Automates the sharing of work thus
reducing the time to collaborate with
group members
• Facilitates interaction among team
members by making diagramming a
dynamic, interactive process

28
Reasons for Using Case Tools
cont..
 Improving analyst-user communication:
CASE tools foster greater, more meaningful
communication among users and analysts.
 Integrating life cycle activities: Integration
of activities through the underlying use of
technologies makes it easier for users to
understand how all the life cycle phases are
interrelated and interdependent.
 Accurately assessing maintenance changes:
Enable users to analyze and assess the
impact of maintenance changes.

29
1-30
The Agile Approach
 Based on:
 Values

 Principles
 Core practices

1-31
Agile Values
 Communication
 Simplicity
 Feedback
 Courage

1-32
Four Agile Resources
 Resources are adjusted to ensure
successful project completion
 Time

 Cost
 Quality

 Scope

1-33
Five Stages of Agile
Development
 Exploration
 Planning
 Iterations to the first release
 Productionizing
 Maintenance

1-34
 Agile Project Development Process
(Figure 1.5)

1-35
Object-Oriented (O-O) Systems
Analysis and Design
 Alternate approach to the structured approach
of the SDLC that is intended to facilitate the
development of systems that change rapidly in
response to dynamic business environments
 Analysis is performed on a small part of the
system followed by design and implementation
 Generally, works well in situations where
complicated information systems are
undergoing continuous maintenance,
adaptation, and redesign.

1-36
Object-Oriented (O-O) Systems
Analysis and Design
 The cycle repeats with
analysis, design, and
implementation of the next
part and this repeats until the
project is complete
 Examines the objects of a

system

1-37
Unified Modeling Language
(UML) Phases
 Define the use case model:
 Use case diagram
 Use case scenarios

 Create UML diagrams

 Develop class diagrams
 Draw statechart diagrams
 Modify the UML diagrams
 Develop and document the system

1-38
1-39
Choosing a Method
 Choose either:
 SDLC

 Agile
 Object-oriented methodologies

1-40
When to Use SDLC
 Systems have been developed and
documented using SLDC
 It is important to document each step
 Upper level management feels more
comfortable or safe using SDLC
 There are adequate resources and
time to complete the full SDLC
 Communication of how new systems
work is important

1-41
When to Use Agile
 There is a project champion of agile
methods in the organization
 Applications need to be developed quickly
in response to a dynamic environment
 A rescue takes place (the system failed and
there is no time to figure out what went
wrong)
 The customer is satisfied with incremental
improvements
 Executives and analysts agree with the
principles of agile methodologies

1-42
When to Use Object-Oriented
 The problems modeled lend
themselves to classes
 An organization supports the UML
learning
 Systems can be added gradually, one
subsystem at a time
 Reuse of previously written software
is a possibility
 It is acceptable to tackle the difficult
problems first
1-43
Open Source Software
 An alternative of traditional software
development where proprietary code
is hidden from the users
 Open source software is free to
distribute, share, and modify
 Characterized as a philosophy rather
than simply the process of creating
new software
 Examples: Linux Operating System,
Apache Web Server, Mozilla Firefox

1-44
Four Types of Open Source
Communities:

 Ad hoc
 Standardized
 Organized
 Commercial

1-45
Six Key Dimensions that
Differentiate Open Source
Communities

 General structure
 Environment
 Goals
 Methods
 User community
 Licensing

1-46
Reasons for Participating in
Open Source Communities
 Rapidity with which new software
can be developed and tested
 Faster to have a committed group of
experts develop, test, and debug
code
 This fosters creativity
 Have many good minds work with
innovative applications

1-47
Reasons for Participating in
Open Source Communities
 Potential to reduce development
costs
 Bolster their self-image
 Contribute something worthwhile to
the software development
community

1-48
Open Source Contribution
and Differentiation
 Contributions to the open
community and differentiation from
the open community are for the
following reasons:
 Cost
 Managing resources
 Time it takes to bring a new product to
the market

1-49
Reasons for Analyst Participation
in the Open Source Community

 Curiosity about software benefits

 Achieve collective design
 Incorporate open source software
design into:
 Proprietary products
 Processes

 Knowledge

 IT artifacts

1-50
Collective Design
 Through a process of collective
design the IT artifact is imbued with
 Community and organizational
structures
 Knowledge

 Practices

1-51
Summary
 Information is a key resource
 Integration of traditional systems with
new technologies
 Roles and qualities of the systems
analyst
 The systems development life cycle
 CASE tools
 Agile systems development
 Object-oriented systems development
 Open source systems

1-52
Copyright © 2014 Pearson Education, Inc.
Publishing as Prentice Hall

1-53
 END OF
Lecture 01