CSC316: Systems

Analysis and Design

1
 Lecturer/Instructor

Dr. Ufuoma C. Ogude

Department of Computer Sciences
University of Lagos

Office: Rm016
Office Hours: Tues and Thurs. or by appointment
2
 Course Schedule
 Lecture Schedule:
 Tuesdays 1:00pm - 3:00pm

 Class Venue: E303

 Classes start October 31, 2023

 Please attend your lectures. Attendance is mandatory

3
 Learning Outcomes
Learning Outcomes
At the end of this course, students should be able to:
1. describe system requirements gathering techniques;
2. explain data modelling technique (entity relationship
modelling);
3. explain process modelling technique (data flow diagram);
4. describe system architectural design;
5. describe process and database design; and
6. explain user interface design.

4
 Course Overview
 System Analysis and Design is a three [3] credit unit course.

 It introduces the basic techniques and skills you need to

analyse a system and then design, develop and implement a
new one to meet the needs of users.

 The content of the course material is planned and written to

ensure that you acquire the proper knowledge and skills for
the appropriate situations.

5
 Course Overview
 The methods and methodologies used in analyzing and
designing various types of systems.

 Topics include project definition, CASE tools, data gathering,

structured analysis and design, human-machine interface,
database design, system controls, hardware selection and
system testing, implementation and operation.

6
 Course Overview
 Students are assigned to a project team involved in a system
study as part of the course.

 Real-life situations have been created to enable you identify

with and create some of your own.

 The essence is to get you to acquire the necessary knowledge

and competence, and by equipping you with the necessary
tools, we hope to have achieved that.

7
 Course Contents
System concepts: examples of systems; Systems Development Life
Cycle (SDLC);
Analysis–Fact gathering Techniques, Data delivery, Dataflow
diagrams, Process Description, Data Modeling;
System Design-structure charts, form designs, security, automated
tools for design; CASE; Implementation and Maintenance.

Introduction to the requirements design definition phase of

systems development.

Models, notations and processes for software requirement of

identification, representation, validation and analysis.
8
 Course Contents
Structured approach to analysis and design of information
systems for businesses.
Systems development life cycle. Structured top-down and
bottom-up design.
Dataflow diagramming. Entity relationship modelling.
Input and output, prototyping design and validation.
File and database design.
Design of user interfaces. Comparison of structured and object-
oriented design.

9
 Course Contents
An important component of the course is the use of
group projects with real-life case studies.

Lab work:
Practical exercises on systems development life cycle
(SDLC) activities with different case studies.
Use of different information systems case studies to
apply the knowledge of structured top-down and
bottom–up design, dataflow diagram and entity
relationship models. 10
 Outlines
This course provides a hands-on introduction to a number of Systems Analysis
and Design activities and concepts. It will include the following topics:
Week 1: Introduction to Systems Analysis and Design
Week 2: Systems Design Life Cycles (SDLC)
Week 3: Project Management
Week 4: Requirements Gathering
Week 5: Use Cases and Activity Diagrams
Week 6: Domain Modeling
Week 7: Data Modeling
Week 8: Data and Dataflow Modeling
Week 9: Database design and OO Design
Week 10: Architectural Design
Week 11: Deployment and Testing 11

Week 12, 13: Project time

Course Material
 Textbooks and References
 Recommended Text:
Systems Analysis & Design (5th Edition).
Alan Dennis, Barbara Haley Wixom and
Roberta M. Roth
 References
This course will make use of a number of
resources, including:
 book chapters
 online articles
 Use lecture notes/slides as study
guide
12
 Pre-Requisite
 CSC224 Introduction to Data
Structures

Knowledge of programming languages:

The earlier courses in this programme would have made you
familiar with basic computer hardware and software concepts
as well as with some of the programming languages.

13
Pre-Requisite

14
 Course Evaluation
 Final Examination: 60%
 Continuous Assessment: 40%

15
 Lecture 1:
Introduction

Introduction to Systems
Analysis and Design
16
 Introduction
 Systems are created to solve problems.

 One can think of the systems approach as an organized way of

dealing with a problem.

 In this dynamic world, the subject System Analysis and Design

(SAD), mainly deals with the software development activities.

17
 Why Study this Course
 Nowadays, most of the industries are affected by computers.

 Businesses are considering managing their information resource

to be equal in importance to managing their key resources:

property, facilities, equipment, employees and capital.

18
 Objectives
After going through this lesson, you should be able to
 define a system

 explain the different phases of system development life cycle

 enumerate the components of system analysis
19
 explain the components of system designing
 Define a System
 “System” is a set of components that interact to achieve a
common goal.
An organized set of doctrines usually intended to explain the
arrangements or working of a system whole

 The term is derived from a Greek word systema which means

an organized relationship among functioning units and
components.

 A collection of components that work together to realize some

objective forms a system.
 Define a System
 The word “system” is derived from Greek word Systema,
which means an organized relationship between any set of
components to achieve some common cause or objective.
A system is “an orderly grouping of interdependent
components linked together according to a plan to achieve a
specific goal.”

 The term “system” originates from the Greek term systēma,

which means to “place together”.
An integrated set of interoperable elements, each with
explicitly specified and bounded capabilities, working
synergistically to perform value-added processing to enable a
user to satisfy mission-oriented operational needs in a
prescribed operating environment with a specified outcome
and probability of success.
 Basic System Components
 Basically there are three major components in every
system, namely input, processing and output.
Basic System Entity Construct
Analytical System Entity Construct
 Constraints of a
System
 A system must have three basic constraints:
 A system must have some structure and behavior which is
designed to achieve a predefined objective.
 Interconnectivity and interdependence must exist among
the system components.
 The objectives of the organization have a higher
priority than the objectives of its subsystems.

 For example, traffic management system, payroll system,

automatic library system, human resources information system.
 Basic Implications of a System
 A system exists because it is designed to achieve one or more
objectives.
As we know that the system consists of small sub systems
where none of the sub systems is of much use as a single
independent system
 So there are three basic implications:
 A system must be designed to achieve predetermined objectives.
 Interrelationships and interdependencies must exist among the
components.
 The objectives of an organization must be given higher priority
than the objectives of the sub system.
Properties of a System
A system has the following properties −
Organization
 Organization implies structure and order.
 It is the arrangement of components that helps to achieve predetermined
objectives.
Interaction
 It is defined by the manner in which the components operate with each
other.
 For example, in an organization, purchasing department must interact with
production department and payroll with personnel department.
Interdependence
 Interdependence means how the components of a system depend on one
another.
 For proper functioning, the components are coordinated and linked
together according to a specified plan.
 The output of one subsystem is the required by other subsystem as input.
Properties of a System
Integration
 Integration is concerned with how a system components are
connected together.
 It means that the parts of the system work together within the
system even if each part performs a unique function.

Central Objective
 The objective of system must be central.
 It may be real or stated.
 It is not uncommon for an organization to state an objective and
operate to achieve another.
 The users must know the main objective of a computer application
early in the analysis for a successful design and conversion.
 Elements of a System
The following diagram shows the elements of a system:
 Elements of a System
Outputs and Inputs
 The main aim of a system is to produce an output which is useful for its
user.
 Inputs are the information that enters into the system for processing.
 Output is the outcome of processing.

Processor(s)
 The processor is the element of a system that involves the actual
transformation of input into output.
 It is the operational component of a system. Processors may modify the
input either totally or partially, depending on the output specification.
 As the output specifications change, so does the processing. In some
cases, input is also modified to enable the processor for handling the
transformation.
 Elements of a System
Control
 The control element guides the system.
 It is the decision–making subsystem that controls the pattern of
activities governing input, processing, and output.
 The behavior of a computer System is controlled by the Operating
System and software. In order to keep system in balance, what and how
much input is needed is determined by Output Specifications.

Feedback
 Feedback provides the control in a dynamic system.
 Positive feedback is routine in nature that encourages the performance
of the system.
 Negative feedback is informational in nature that provides the
controller with information for action.
 Elements of a System
Environment
 The environment is the “supersystem” within which an organization operates.
 It is the source of external elements that strike on the system.
 It determines how a system must function.
For example, vendors and competitors of organization’s environment, may
provide constraints that affect the actual performance of the business.

Boundaries and Interface

 A system should be defined by its boundaries.
 Boundaries are the limits that identify its components, processes, and
interrelationship when it interfaces with another system.
 Each system has boundaries that determine its sphere of influence and
control.
 The knowledge of the boundaries of a given system is crucial in determining
the nature of its interface with other systems for successful design.
 Stakeholders
 System Owners: are the system's sponsors and chief advocates. They
are usually responsible for funding the project to develop, operate, and
maintain the information system.

 System Users: are the people who use or are affected by the system
on a regular basis–capturing, validating, entering, responding to, storing,
and exchanging data and information. A common synonym is client.

 System Designers: translate system users' business requirements and

constraints into technical solutions.

They design the computer files, databases, inputs, outputs, screens,

networks and programs that will meet the system users' requirements.
 Stakeholders
 System Builders: construct the system components based on the design
specifications from the system designer. In many cases, the system
designer and builder for a component are one and the same.

 Systems Analyst: facilitates the development of systems and computer

applications.

A systems analyst studies the problems and needs of an organization

to determine how people, data, processes, communications, and
information technology can best accomplish improvements for the
business.

 Business Analyst: is a systems analyst that specializes in business

problem analysis and technology-independent requirements analysis.
 Role of System Analyst
 The system analyst is a person who is thoroughly aware of the

system and guides the system development project by giving

proper directions.

 He is an expert having technical and interpersonal skills to carry

out development tasks required at each phase.

 He pursues to match the objectives of information system with

the organization goal.

 Role of System Analyst
Main Roles
 Defining and understanding the requirement of user through various
Fact finding techniques.
 Prioritizing the requirements by obtaining user consensus.
 Gathering the facts or information and acquires the opinions of
users.
 Maintains analysis and evaluation to arrive at appropriate system
which is more user friendly.
 Suggests many flexible alternative solutions, pick the best solution,
and quantify cost and benefits.
 Draw certain specifications which are easily understood by users and
programmer in precise and detailed form.
 Implemented the logical design of system which must be modular.
 Plan the periodicity for evaluation after it has been used for some
time, and modify the system as needed.
 The Systems Analyst as a
Facilitator
Steering committee

User 1 Information
technology
vendors

User 2

Systems Applications
analyst programmers

User N

Network
administrator

Management/ system Database Interface

owner administrator design expert
Systems Analyst
 What Does a Systems Analyst Do?

1. Identify the problem.

2. Analyze and understand the problem.

3. Identify solution requirements or expectations.

4. Identify alternative solutions and decide a course of action.

5. Design and implement the “best” solution.

6. Evaluate the results. If the problem is not solved, return to

Step 1 or 2 as appropriate.
 Ten Commandments
 The Ten Commandments of Computer Ethics
 Thou shalt not use a computer to harm other people.
 Thou shalt not interfere with other people's computer
work.
 Thou shalt not snoop around in other people's computer
files.
 Thou shalt not use a computer to steal.
 Thou shalt not use a computer to bear false witness.
 Thou shalt not copy or use proprietary software for
which you have not paid.
Ten Commandments
 Thou shalt not use other people's computer resources
without authorization or proper compensation.
 Thou shalt not appropriate other people's intellectual
output.
 Thou shalt think about the social consequences of the
program you are writing or the system you are designing.
 Thou shalt always use a computer in ways that insure
consideration and respect for your fellow humans.
 Attributes of a Systems
Analyst
 The following figure shows the attributes a systems analyst
should possess −
 Skills of the Systems Analyst
 Systems analysts need a great variety of special skills,

like:

 Technical knowledge and skills.

 Business knowledge and skills.

 People knowledge and skills.

 Integrity skills and ethics.

 Technical Knowledge and Skills
 A systems analyst should understand the fundamentals about:
 Computers and how they work.
 Devices that interact with computers, including input devices,
storage devices and output devices.
 Communications networks that connect computers.
 Databases and database management systems.
 Programming languages.
 Operating systems and utilities.
 Technical Knowledge and Skills
 A systems analyst also need to know a lot about tools and techniques
for developing systems, like:
 Software packages such as Microsoft Access and LibreOffice Base that
can be used to develop systems.
 Integrated development environments (IDEs) for specific programming
languages, such as Netbeans, Eclipse and MS Visual Studio .NET.
 Computer-aided system engineering (CASE) tools that store information
about system specifications created by analysts and sometimes
generate program code, such as GNU Ferret.
 Program code generators, testing tools, configuration management tools,
software library management tools, documentation support tools,
project management tools and so on.
Business Knowledge and Skills
 What business functions do organizations perform?

 How are organizations structured?

 How are organizations managed?

 What type of work goes on in organizations, for example,

finance, manufacturing, marketing, customer service and so

on?
 People Knowledge and Skills
 Because analysts usually work on development teams with
other employees, systems analysts need to understand a lot
about people skills.
 It is critical that the analyst understand how people:
 Think.
 Learn.
 React to change.
 Communicate.
 Work (in a variety of jobs and levels).
Integrity Skills and Ethics
 A systems analyst is asked to look into problems that involve
information in many different parts of organization.
 The analyst must have the integrity to keep private
information's, such as health, salary and job performance.
 They are expected to uphold the highest ethical standards
when it comes to private proprietary information they might
encounter on the job.
 Any appearance of impropriety can destroy an analyst's career.
 Lecture 2 - 3:

System Development
Life Cycle
(SDLC)
48
 Key Ideas
 Many failed systems were abandoned because analysts tried to

build wonderful systems without understanding the organization.

 The primarily goal is to create value for the organization.

 Quality is satisfaction of requirements, not ‘goodness’

 Key Ideas
 The systems analyst is a key person analyzing the business,

identifying opportunities for improvement, and designing

information systems to implement these ideas.

 It is important to understand and develop through practice the

skills needed to successfully design and implement new

information systems.
 Objectives
 Understand the fundamental systems development life cycle

and its four phases.

 Understand the evolution of systems development

methodologies.

 Be familiar with the Unified Process and its extensions.

 Be familiar with the different roles on the project team.

Major Attributes of the life cycle
 The project
 Moves systematically through phases where each phase has a
standard set of outputs
 Produces project deliverables
 Uses deliverables in implementation
 Results in actual information system
 Uses gradual refinement
System Development Life Cycle
(SDLC)
 System life cycle is an organizational process of developing
and maintaining systems.
It helps in establishing a system project plan, because it gives
overall list of processes and sub-processes required for
developing a system.

 SDLC means combination of various activities.

 In other words we can say that various activities put
together are referred as system development life cycle.
 In the System Analysis and Design terminology, the
system development life cycle means software
development life cycle.
 System Development Life Cycle
(SDLC)
 SDLC is a method of system development.

 An effective SDLC should result in a high quality system that

meets customer expectations, reaches completion within time
and cost evaluations, and works effectively and efficiently.

 SDLC is a conceptual model which includes policies and

procedures for developing or altering systems throughout
their life cycles.
 System Development Life Cycle
(SDLC)
 Following are the different
 SDLC is used by analysts to
phases of software development
develop a system. SDLC cycle:
 System study
includes the following
 Feasibility study
activities:  System analysis
 requirements
 System design
 design
 Coding
 implementation
 Testing
 testing
 Implementation
 deployment
 Maintenance
 operations
 The different phases of
 maintenance
software development life cycle
Phases of Software development
Life Cycle
The System Study And
Design Model
 Phases of SDLC
 Systems Development Life Cycle is a systematic approach which
explicitly breaks down the work into phases that are required to
implement either new or modified System.
Phases of SDLC
Phases of SDLC
 Phases of SDLC:
 Planning phase: the initial phase of the SDLC whose
objective is to identify the scope of the new system and
plan project.
 Analysis phase: one phase of the SDLC whose objective is
to understand user needs and develop requirements.
 Design phase: the phase of the SDLC where the system
and programs are designed.
 Implementation phase: the phase of the SDLC where the
new system is programmed and installed.
 Support phase (Maintenance phase): the phase of the
SDLC that occurs after the system is installed.
Systems Development Life
Cycle
Systems Development Life
Cycle
Planning

Implementation Analysis

Design
4 Main Project Phases
 Planning
 Why build the system?
 Analysis
 What, when, where will the system be?
 Design
 How will the system work?
 Implementation
 System construction & delivery
 SDLC: Planning
1. Project Initiation
 Develop a system request
 Conduct a feasibility
analysis
2. Project Management
 Develop work plan
 Staff the project
 Control and direct the
project
Why should we build this system?
 Identifying business value
(is it worth doing?)
 Analyze feasibility (is it
possible?)
 Develop work plan (when?)
 Staff the project (who?)
 Control and direct project
 SDLC: Analysis
1. Develop analysis strategy  Analysis (what do we
2. Gather requirements want? Who will use the

3. Develop a system proposal system?)

 Systems Analysis: understanding  Information gathering
and specifying in detail what a
 Process modelling (what
system should do
 System Analysis is the study of a happens?)
business problem domain to  Data modelling (… and to
recommend improvements and
specify the business requirements what?)
for the solution.

What should the system do for us?

Where and when will it be used?
 SDLC: Design
1. Develop a design strategy  Design strategy
2. Design architecture and interfaces
3. Develop databases and file  Architectural design
specifications  Interface design (HCI)
4. Develop the program design
 Database and file
 System Design: specifying in detail
how the parts of a system should design
be implemented
 Program design (what
 System Design is the
specification or construction of a will the programs do?)
technical, computer-based
solution for the business
requirements identified in a system
analysis.

How will we build the system?

 SDLC: Implementation
1. Construct system  Construction (Programming,
2. Install system testing, validation etc)
 Implement a training plan  Installation (including
for the users migration, change
3. Establish a support plan management)

Build the system!

 Putting the SDLC Together
 Each phase consists of steps that lead to specific
deliverables
 The system evolves through gradual refinement
 Once the system is implemented, it may go back into a
planning phase for its next revision, a follow-on system,
or maintenance releases
Processes and Deliverables
Process Product
Planning Project Plan

Analysis System Proposal

Design System
Specification

Implementation New System and

Maintenance Plan
SYSTEMS DEVELOPMENT
Methodologies
 Methodologies
 What Is a Methodology?
 A formalized approach or series of steps
 Writing code without a well-thought-out system request
may work for small programs, but rarely works for large
ones.
 Systems Development
Methodologies
 A methodology is a formalized 1. Structured Design
approach to implementing the
2. Rapid Application
SDLC
Development
 Well-known methodologies include:
3. Agile Development
 Waterfall development
 Parallel development
 V-model
 Rapid application development
 Agile development
Categories of Methodologies
 Structured Design
 Waterfall Development
 Parallel Development
 Rapid Application Development
 Phased
 Prototyping
 Throwaway Prototyping
 Agile Development
 eXtreme Programming
Structured Design
 Projects move methodically from one to the next
step
 Generally, a step is finished before the next one
begins
Waterfall Development
Method
Waterfall Development
Method
 Waterfall Development
Method
 The Waterfall Model works well when:

...Problem and solution method are well understood, requiring

no large-loop corrections to development problems

Pros and Cons of the Waterfall
Method
Pros Cons

Identifies systems Design must be

requirements long specified on paper
before programming before programming
begins begins

Long time between

system proposal and
delivery of new
system
Parallel Development

Slide 79
Rapid Application Development
(RAD)
 Critical elements

 CASE tools

 JAD sessions

 Fourth generation/visualization programming

languages

 Code generators
Rapid Application Development
Categories
 Phased development
a series of versions, later combined
 Prototyping
 System prototyping
 Throw-away prototyping
 Design prototyping
Phased Development

Slide 82
How Prototyping Works
Throwaway Prototyping
Agile Development
 Simple iterative application development

 Extreme programming (XP)

Extreme Programming (XP)
 Key principles
 Continuous testing
 Simple coding by pairs of developers
 Close interactions with end users
 Testing & Efficient Coding Practices
 Integrative testing environment
 Requires…
 Stable and experienced teams
 Small groups of developers (<=10)
Extreme Programming (XP)
Selecting the Appropriate
Methodology
 Clarity of User Requirements
 Familiarity with the Technology
 System Complexity
 System Reliability
 Length of Time Schedules
 Time Schedule Visibility
 Selecting the Right
Methodology
Usefulness for Waterfall Parallel Phased Prototyping Throwaway Extreme
Prototyping Programming

Unclear user Poor Poor Good Excellent Excellent Excellent

requirements

Unfamiliar Poor Poor Good Poor Excellent Poor

technology

Complex systems Good Good Good Poor Excellent Poor

Reliable systems Good Good Good Poor Excellent Good

Short time Poor Good Excellent Excellent Good Excellent

schedule

Schedule Poor Poor Excellent Excellent Good Good

visibility
Criteria for Selecting a
Methodology

Slide 90
 Object-Oriented Analysis &
Design
 Attempt to balance emphasis on data and process
 Uses Unified Modeling Language (UML)
 Characteristics of OOAD:
 Use-case Driven
 Architecture Centric
 Iterative and Incremental
The Unified Process
 A specific methodology that maps out
when and how to use the various UML
techniques for object-oriented analysis
and design
 A two-dimensional process consisting of
phases and flows
 Phases describe how the system evolves over
time
 Workflows are collections of tasks that occur
throughout the lifecycle, but vary in intensity
The Unified Process
Unified Process Phases
 Inception
 Elaboration
 Construction
 Transition
Engineering Workflows
 Business modeling
 Requirements
 Analysis
 Design
 Implementation
 Testing
 Deployment
 Supporting
Workflows
 Project management
 Configuration and change management
 Environment
 Operations and support*
 Infrastructure management*

* Part of the enhanced unified process

 The Unified Modeling
Language
 Provides a common vocabulary of object-
oriented terms and diagramming
techniques rich enough to model any
systems development project from
analysis through implementation
 Version 2.0 has 14 diagrams in 2major
groups:
 Structure diagrams
 Behavior diagrams
UML Structure Diagrams
 Represent the data and static relationships
in an information system
 Class
 Object
 Package
 Deployment
 Component
 Composite structure
 UML Behavior Diagrams
 Depict the dynamic relationships among the instances
or objects that represent the business information
system
 Activity
 Sequence  Behavior state machine
 Communication  Protocol state machine,
 Interaction overview  Use-case diagrams
 Timing
 Outlines
This course provides a hands-on introduction to a number of Systems Analysis
and Design activities and concepts. It will include the following topics:
Week 1: Introduction to Systems Analysis and Design
Week 2: Systems Design Life Cycles (SDLC)
Week 3: Project Management
Week 4: Requirements Gathering
Week 5: Use Cases and Activity Diagrams
Week 6: Domain Modeling
Week 7: Data Modeling
Week 8: Data and Dataflow Modeling
Week 9: Database design and OO Design
Week 10: Architectural Design
Week 11: Deployment and Testing 100

Week 12, 13: Project time

PROJECT TEAM ROLES
AND SKILLS
 Five Functions of
Management
Planning

Directing Staffing

Controlling
Organizing
102
Critical Areas
 Communications

 Databases

 Programming

 Hardware

 Industry Standards

103
Management Hierarchy
 Strategic
Systems
 Middle
Needs
 Operational

104
 Project Management

Analysis
and • Resources
Design • Time
Activities

105
Project Fundamentals

 Project Initiation
 Determining Feasibility
 Scheduling
 Managing Activities and
Personnel

106
Project Management
 Management: is getting things done through other people.
 Project: a planned undertaking that has a beginning and
an end that produces a predetermined result or product.
 Project management is a special type of management.
 Project Management: is organizing and directing other
people to achieve a planned result within a predetermined
schedule and budget.
Project Team Skills
 Project team members are change agents who find ways
to improve their organization
 A broad range of skills is required, including
 Technical
 Business
 Analytical
 Interpersonal
 Management
 ethical
 Project Team Roles
Role Responsibilities
Business Analyst Analyzing the key business aspects of the system
Identifying how the system will provide business value
Designing the new business processes and policies
Systems Analyst Identifying how technology can improve business
processes
Designing the new business processes
Designing the information system
Ensuring the system conforms to IS standards
Infrastructure Ensuring the system conforms to infrastructure
Analyst standards
Identifying infrastructure changes required by the
system
Change Developing and executing a change management plan
Management Developing and executing a user training plan
Analyst
Project Manager Managing the team
Developing and monitoring the project plan
Assigning resources
Serving as the primary point of contact for the project
 Project Team Roles
 Business analyst (business value)
 Systems analyst (IS issues)
 Infrastructure analyst (technical issues – how the system will
interact with the organization’s hardware, software,
networks, databases)
 Change management analyst (people and management issues)
 Project manager (budget, time, planning, managing)

Slide 110
 Summary
 The Systems Development Life Cycle (SDLC) consists of
four stages: Planning, Analysis, Design, and
Implementation
 The Major Development Methodologies:
 Structured Design
 Waterfall Method
 Parallel Development
 Rapid Application Development (RAD)
 Phased Development
 Prototyping (system prototyping)
 Throwaway Prototyping (design prototyping)
 Agile development
 eXtreme Programming
 Project Team Roles
 Summary
 There are five major team  Project team members are
roles: change agents who find ways
 business analyst to improve their organization
 systems analyst  A broad range of skills is
 infrastructure analyst required, including
 change management  Technical
analyst  Business
 project manager.  Analytical
 Interpersonal
 Management
 ethical
Further Reading
Project Success
Factors
Project Success Factors
 In 1995, the Standish Group published results of a study
on system development project success:
 The results indicated that:
 ≈32% of all development projects are canceled
before they are finished.
 More than half of computer system projects cost
almost double the original budget.
 ≈42% have the same scope and functionality as
originally proposed.
Project Success Factors
 In fact, many systems are implemented with only a
portion of the requirements satisfied.
 Depending on the company size, completely successful
projects (on time, on budget, with full functionality)
range from only 9% to 16%.
 System development is a difficult activity requiring very
careful planning, control and execution.
 Q and A
Project Success Factors
 The primary reasons of not fulfilling the desired objectives:
 Incomplete or changing system requirements.
 Limited user involvement.
 Lack of executive support.
 Lack of technical support.
 Poor project planning.
 Unclear objectives.
 Lack of required resources.
 Q and A
Project Success Factors
 Most of these problems could be corrected with strong
project management.
 Some reasons for success are the following:
 Clear system requirement definitions.
 Substantial user involvement.
 Support from upper management.
 Thorough and detailed project plans.
 Realistic work schedules and milestones.
 Summary
 All systems development projects follow essentially the same process,
called the system development life cycle (SDLC)
 System development methodologies are formalized approaches to
implementing SDLCs
 Object-Oriented Systems Analysis and Design (OOSAD) uses a use-
case-driven, architecture-centric, iterative, and incremental
information systems development approach
 The Unified Process is a two-dimensional systems development process
described with a set of phases and workflows
 The Unified Modeling Language, or UML, is a standard set of
diagramming techniques
 The project team needs a variety of skills
Context Diagram for Airline
Reservation System
Level One Data Flow Diagram for
Reservation Process
 Course Summary
 Introduction to Systematic Approach to:
 Define Needs
 Create Specifications
 Design Information Systems
 Hands-on Case Studies
 Systems Analysis & Design Techniques
 Project Management

121
 Course Learning Objectives
 Analyze/design using SDLC Waterfall and Agile Methodologies
 Project Management software for tracking and reporting tasks,
costs, resources and timelines
 Analyze acquisition, implementation, testing, maintenance, risk
management, and best practices
 ID and analyze SDLC project professionalism and ethics
 ID system risk/issues and mitigation
 Analyze and discuss governance, security, and privacy
 Differentiate various IT, PM, and management roles in system
development
 Analyze business environment and how IT supports the organization
achieve business objectives
 ID and analyze standard and best practices for IT governance and
management
 ID and analyze industry relevant IT career paths, certifications, 122
currency
Course Topics
 Systems Development Life Cycle (SDLC)
 Agile and other development methodologies
 Project Management
 Professionalism and Ethics
 Security & Privacy standards and regulations
 Information Technology management
 Information Technology Standards and best practices
 Computer Careers and Certifications

123
Course References
 CAHIMS 3.5 – Project Management
 CAHIMS 4.2 – Systems Acquisition
 CAHIMS 4.3 – Interoperability Standards & Certification
 CAHIMS 5.1 – Systems Implementation
 CAHIMS 5.3 – Systems Monitoring and Maintenance
 CAHIMS 7.2 – Security Risk Assessment & Audit
 CAHIMS 8.2 – Quality Standards
 CAHIMS 8.3 – Strategic Planning
 Systems Analysis and Design, 3rd Ed, Kendall & Kendall,
Prentice Hall, New Jersey, 1995
 Systems Analysis and Design, 6th Ed, Shelly, Cashman,
Rosenblatt, Course Technology, Massachusetts, 2006

124
 Module 1
Systems Development Life
Cycle

125
Failure of IT Projects
Gartner 2012 Survey reports that:
 “Runaway budget costs are behind one-quarter
of project failures for projects with budgets
greater than $350,000.
 Small is beautiful — or at least small projects
are easier to manage and execute. The failure
rate of large IT projects with budgets
exceeding $1 million was found to be almost
50% higher than for projects with budgets
below $350,000.”
http://thisiswhatgoodlookslike.com/2012/06/10/gartner-survey-shows-why-projects-fail/, 02/12/14

126
IT Projects
Every year, Gartner performs a global
analysis of IT spending trends. Key findings
from this year's Gartner IT Key Metrics
report are:
 56% of global IT budgets are spent on
infrastructure and operations
 34% of global IT budgets are spent on
applications
 10% of global IT budgets are spent on IT
overhead
http://www.gartner.com/technology/metrics/, 02/12/14

127
 Sound Health, LLC
 Local health care cooperative
 General out-patient care
 Limited specialty care
 Health care providers have working
relationships with local hospitals
 Need to update their I-T support

128
Information

A Critical
Organizational
Resource

129
Organizations
as
Systems

130
Characteristics of Organizations

 Structure
 Goals/
Objectives
 Functions
 Sub-Systems
 Communication

131
Management Information
Systems

132
Systems Development Life Cycle
 Identifying problems,
opportunities, and objectives
 Determining information
requirements
 Analyzing system needs
 Designing the recommended
system
 Developing and documenting
software
 Testing and maintaining the system
133
 Implementing and evaluating the
System Life Cycle
 Phase I – Preliminary Investigation
 Phase II – Systems Analysis
 Phase III – Systems Design
 Phase IV – Systems Implementation
 Phase V – System Operation and Support

134
System Lifecycle
A Continuous Process
“Next”
System
Implementation
Design
Investigation

Operation “Current”
System Analysis
Operation
Implementation Design
Analysis

Investigation

135
The Systems Analyst
 Investigates, analyzes, designs,
develops, installs, evaluates,
maintains
 Technical and communication skills
essential
 Primary roles: consultant,
supporting expert, change agent

136
BABOK® Guide - Workplace
Competencies

 Analytical Thinking and Problem Solving

 Behavioral Characteristics
 Business Knowledge
 Communication Skills
 Interaction Skills
 Software Applications

137
Sampling and Investigating
Hard Data

138
Sampling

 What is it?
 Why do we need it?
 How do we design it?
 How much do we
sample?

139
What Kind of Information?

Quantitative
Qualitative

140
Marketing 101
Perceptions are Reality

Your biases, education, intellect, upbringing,

ethnicity, beliefs, emotions . . . filter your
perceptions - everything you hear and see . . .
and how you interact with people, including
interviews.

141
Sound Health, LLC
 13 Physicians
 2 Physician’s Assistants (PAs)
 2 Nurse Practitioners (NPs)
 5 Registered Nurses (RNs)
 6 Licensed Practical Nurses (LPNs)
 14 Support staff
 2 I-T staff

142
What is the purpose
of an interview?

143
Gather Information
Goals
Feelings
Informal
Opinions Procedures

144
Interview Planning

 Background material
 Objectives
 Who to interview
 Prepare the interviewee
 Questions

145
Conducting the
Interview

146
Alternatives
to
One-on-One
Interviews

147
Questionnaires:
Interview Alternative

148
Gather Information
Beliefs Behaviors

Attitude Characteristics

Questions:
- Closed
- Open-Ended

149
Effective Questionnaires

cy
 What is the  Scaling

ct den
purpose? « Nominal

ef en
Ha ntr ncy
lo a l t
« Ordinal

Ce nie

fe
 Conditions for Interval

Le
«
Use? « Ratio
 Questions  White Space
« Remember, no
interaction
« Choose words
carefully
« Validity and reliability

150
Analyst Observations:
Elementary, My Dear Watson, Elementary

151
Why Observe?
Relationships

Messages
Activities
Gain Insight
Influence
Confirm, Negate, Reverse
Structured & Systematic

152
How to Observe
 Structured and systematic
 What will be observed
 Determine level of correctness
 Categorize key actions
 Collection materials - forms, scales,
etc
 When
 Time and event samples

153
What to Observe

 Decision-maker Activities
 Body Language
 Physical Environment

154
 Module 2
Development Methodologies
CAHIMS 4.2

155
Traditional
TheSystems Analysis
“Waterfall” & Design
Approach
Phase 1 - Preliminary Investigation

Phase 2 - Systems Analysis

Process
Could Take Phase 3 - Systems Design
Years to
Complete
Phase 4 - Acquisition &
Implementation

Phase 5 - Maintenance

156
http://www.docstoc.com/docs/41002042/Traditional-systems-development-phases-The-Waterfall-Method

157
SDLC Alternatives

 Prototyping
 Incremental Development
 Agile
 Scrum

158
http://www.sdlc.ws/agile-vs-waterfall/

159
 Draw a Picture

Dataflow Diagrams Entity-Relationships

Preferences and Emplooyee Primary Travel
Available Flights Travel Destination
Passenger Agent Entity

1 1

0
Travel Ticketing Assigned to Can be
Request Airline Information Relationships Booked by
Reservation
System

Data
Passenger Process
Entities Flow Reservation 1 M

Secondary
Phone Passenger
Extensiion Entity

Airline

160
Modeling the System

A Picture’s Worth 1,000 Words

161
Data Flow Diagrams
 Picture of system centered on business
activities
 Based on business events not a
particular technology, therefore more
stable
 Communication with users
 Analysts’ business understanding
 Present and proposed system
 Basis for physical DFD

162
DFD vs Narrative Descriptions
Advantages

 Prevents premature technical

system implementation
 Enhances system/subsystem
interrelatedness understanding
 Communicates analysts’ system
understanding to users
 Analysis of proposed system -
necessary data/processes defined

163
Symbology and Conventions

Entity Flow of Data Process Data Store

(Noun) (Noun) (Name of Whole System (Noun)
Name of Subsystem
Verb-Adjective-Noun)

164
General to Specific
Exploding Diagrams

 Context Level
(Environmental)
 Diagram 0
 Child Diagrams (Parent
Process Exploded)

165
Context Level DFD
(Environmental Model)
 Entities - Process - Data Flow
 How do you buy a tent from REI?
Item Availability
Sales
Assoc.
0
Item Request Sales Info
Customer Sales
System
Customer
Order

Supplier

166
Diagram 0
Context Level

External
Entity Input A
0 External
1 Output C Entity
System 3
Input B Name

External
Entity
2

1 2
External Input A Data Flow B Output C
Entity General General External
1 Process Process Entity
AAA BBB 3
Data Flow C
Diagram 0

Record A
Record E

D1 Data Store 1 D2 Data Store 2

Record A
Record E

3 4
External Input B General Data Flow D General
Entity Process Process
2 CCC DDD

167
Sound Health Context Level DFD
Ins
Companies Pharmacies

Pmt
Report Invoices Rpts
Correction
Prescription Order
0
Appointment
SH
Patients
Patient MIS Appt Rqst
Records Patient
Co-Payments
Reports
Bank Deposit
Bank
Hospitals Statements

Bank

168
DFD Errors
 Data Flows - Omitted/Wrong
Direction
 Data Flows and External Entities
Connected
 Incorrect Labels - Processes/Data
Flows
 Too Many Processes - Limit 9
 Unbalanced Decomposition - Child
Diagrams
169
 Entity-Relationship Diagrams

 Review from CIS260 “Database

Management Systems”
 Graphic depiction of system components
 Provides means for clarity

170
The Entity Relationship(ER)
Model
 The ER model shows information to be
collected in the database (entity) and its
relationship with other information
collected.

 Peter Chen, 1976, originator of the entity

relationship model
Identify the “Entities”

Identify the “entities” – the nouns – the title of the information

being collected (patient, appointment, prescription, physician, etc.).

1. Draw a box for each entity and label with the entity name.
2. Label using the singular spelling of the noun and capitalize the
noun.*

Figure 1: The design of the "box" will depend on the

software used to create it.
Identify the “Relationships”
Identify the “relationships” – the verbs; how one piece of
data or information interacts/relates with another piece of
information Draw a line between entities to show
relationship.
1.Label the line with verbs that describe the relationship.
2.The first verb is for reading left to right; the second
verb is for reading right to left.

Figure 2:
The Patient has an Appointment. The
Appointment is for a Patient.
Identify the “Cardinality”
Identify the “cardinality” – the number of entities allowed
in the relationship.

1.A single line touching an entity means “ONE”.

2.A line ending with three small lines, referred to as
“crow’s feet”, means “Zero or more”. Once created, this
can be set to a different minimum such as “One or
more” or “Three or more”.

Figure 3: Single point at line end means "ONE";

crow’s feet, means "many" or "one or more".
Identify the “Optional/Optionality”
Identify “optional/optionality” – whether the relationship is required or
not.
1. Microsoft VISIO uses the “O” to show “optional” as seen by
the entity Appointment.
2. The “||” means one required.

Figure 4: The Patient may have "one or more“

Appointments; the Appointment must have one Patient.
Add the “Attributes”
Add the “attributes” – descriptors of the entity.
1. Label the attributes as singular tense.
2. Don’t put spaces or symbols between words if more than one is
needed for clarity.
3. Type or write as “camel case” – first letter of each word is upper
case, all other letters are lower case.

Figure 5: We identify the Patient by his/her name;

we identify the Appointment by the date, time and Physician .
Add “Primary Key (PK)” and
“Foreign Key (FK)”
Add “primary key (PK)” – use an attribute of the entity,
or create a new attribute, that uniquely identifies the entity.
1. A new attribute, primary key ID, is usually created for
most entities because none of the attributes identified
are guaranteed to always be “unique”.
2. Add “foreign key(FK)” –this is the Primary key of the
parent table in a relationship. The PK of the parent (in
this case “Patient”) is added to the child table (in this
case “Appointment”) thereby becoming the FK.

Figure 6:
 Unique Identifiers (UID)
 A unique identifier/unique ID/UID is a number or
combination of numbers and letters that when used
will only identify one entity or record.
 Examples of ID’s we think uniquely identify us:
 Driver’s license
 Social Security Number
 Telephone number
 Why they might not be unique:
 http://www.idanalytics.com/news-and-events/news-
releases/2010/8-11-2010.php
 CustomerID, or PatientID, or AccountNumber are
examples of new identifiers created for the purpose
of keeping the information unique.
Read the Data Models
Practice reading the diagrams.
1. Keep nouns singular when starting each sentence.
2. Read from left to right, then from right to left. The sentences must make sense
in both directions.

Noun A may/ have with some of Noun B.

must relationship(s number
)

** Bike must be sold with one or more Wheel(s)

*** A Wheel May Be sold with A Bike

Bike Wheel

is sold with / is part of

Creating Mr. Webster
a Dictionary for your Data

180
The Data Dictionary
 Component of the Data Repository
 Reference work of data about data
 Compiled by Systems Analysts - Special
Forms
 Consistent standard for for data elements
 Collects, coordinates, and confirms what a
specific data term means to different people
in an organization
 Used to validate DFD accuracy and
completeness
 Provides starting point for screen/report
development
 Determine contents of data stored in files
 Develop logic for DFD processes
 4 categories: flows, structures, elements,
stores 181
Defining and Describing Data
 Data flow definition: ID #, name, gen
description, source, destination, etc.
 Data structures: algebraic notation - “=”,
“+”, “{ }”, “[ ]”, “( )”
 Data elements
 Data stores: base and derived

182
Special Forms
 Data Flow  Element
Description Description
 ID  ID
 Name  Name
 Description  Aliases
 Source/destination  Description
 Type of data flow  Characteristics
 Volume/time  Validation Criteria

183
Transforming
Processes
Documenting and Analyzing
Decisions and Logic Requires
Good Analysis

184
Why Develop Process Specs?
 Reduce ambiguity
 Precise description of what is to be
accomplished
 Validate system design

Note: Some processes do not require specs

185
Documenting Process
Specifications

What to capture?

186
Structured Decisions

 How do you make

them?
 What do you need?
 how do you document?

187
How To Portray Processes
3 Techniques

 Structured English
 Decision Tables
 Decision Trees

188
 Process Specs
 Process Description documents details of
functional primitive
 Modular Design
 Sequence
 Selection
 Iteration

189
Process Specs
 Structured English
 Like Pseudocode
 Use Keywords
 Decision Table
 4 Quadrants – Conditions, Alternatives,
Actions, Rules
 Decision Tree – Graphic Decision Table

190
 Structured English
 Process involves formulas or iteration
 Use to clearly describe logical processes
 Sequence, selection, iteration
 Limit vocabulary, standard terms
 Indent for readability

191
New Patient Billing
 When calculating billing for medical services, if a new
patient, ask if they have insurance. If married, ask if
their spouse has separate insurance. If there are two
insurance policies check for birthdates of patient and
spouse to determine which policy is primary and which
is secondary. Check to determine if one or the other
policy has stipulations preventing being secondary
payer. If both insurance companies can be billed in this
situation with one as primary and the other as
secondary, calculate patient co-pay/deductible (if any)
for services and invoice insurance companies.
 If the patient is not married or only one insurance
policy is available, calculate co-pay/deductible (if any)
for services and invoice insurance company. If patient
does not have insurance, then invoice patient for
services. 192
 New Patient Billing Process
If patient has insurance
Then If patient has spouse with separate insurance
Then If separate policies allow primary/secondary status based on birthdates
Then Calculate co-pay/deductible for patient and invoice both
insurance companies
Else calculate co-pay/deductible for patient based on primary
insurance company
End If
Else Calculate co-pay/deductible for patient and invoice insurance company
End If
Else invoice patient for services
End IF

193
 Decision Tables
 Multiple conditions
 Multiple actions
 Depicts all possible combinations
 Provides means to simplify logic

194
 Decision Table Rules
 Determine Number of Conditions
 Determine Number of Possible Actions
 Determine Number of Condition
Alternatives
 Calculate the Max Columns
 Fill in Condition Alternatives
 Complete Table with “X’s” in Rules as
Appropriate
 Combine Rules
 Check for Impossible and Redundant
 Rearrange Conditions and Actions for
Readability
195
 Decision Table
Construct a decision table to determine the
logic for automating awarding bonus airline
frequent flyer miles using the following
criteria. Reservation must be made online
and either the ticket paid using the airline
branded credit card or departure and return
flights do not span a weekend (i.e. travel is
sometime from Monday through Friday).

196
Decision Table
Conditions Condition Alternatives
1 2 3 4 5 6 7 8
1. Reservation Made Online Y Y Y Y N N N N
2. Airline Branded Credit
Y Y N N Y Y N N
Card
3. Monday – Friday Travel Y N Y N Y N Y N
Actions Action Entries (Rules)
1. Award Bonus Miles X X X
2. Do Not Award Bonus
X X X X X
Miles

197
 Decision Tree
 Graphic depiction of a decision table
 Linear progression of conditions
 Branches indicate true/false; yes/no
 Use the Decision Table information and
create a Decision Tree

198
 Decision Trees

Bonus Miles
Yes
Airline CC
Yes Bonus Miles
Reservation Online Yes
No M-F Travel

No No Bonus Miles No Bonus Miles

No

Think of a circle signifying IF while the square means THEN.

199
Decisions, Decisions
Supporting the
Decisionmaker
The Role of the DSS

200
When to Use . . .
 Structured English
 Many Repetitious Actions, or
 Communications to End Users Important
 Decision Tables
 Complex Combinations of Conditions,
Actions, and Rules
 Effectively Avoids Impossible Situations,
Redundancies, and Contradictions
 Decision Trees
 Sequence of Conditions and Actions Critical
 Not Every Condition is Relevant to Every
Action
201
Decisions
 Style - Analytic or Heuristic

 Phases - Intelligence, Design, Choice

 Involves risk and uncertainty

202
Decision Support Systems
 Organize information
 Interaction with decisionmaker
 Add structure
 Uses decision-making database
 Does not replace decisionmaker
 Does not make decision
 Supports routine or one-time
decisions

203
Creating the DSS

 DSS generator (DSSG) s/w pkg

 Build from scratch

204
Making Decisions

Uncertainty Certainty

Risk
Somewhat Knowledgeable:
- About alternatives (controllable variables)
- What we cannot control, must estimate (environmental variables)
- What the outcomes will be (dependent variables)

Certainty Increases with Information and Experience

205
Decisions

Structured Unstructured

“Totally Programmed” Intuition

- Structured English and
- Decision Tables Judgment
- Decision Trees

Semi-structured

206
 Preparing the
Systems Proposal

207
Analysts’ Synthesis of Information

 Systematically project future

needs

 Weigh hardware and software

alternatives

208
Hardware and Software Needs
 Accurate inventory
 Workload
 New equipment
 Vendor support
 Software evaluation

209
Cost/Benefit Analysis
 “What If?”
 Trend analysis
 Graphics
 Moving averages
 Tangible/intangible benefits
 Break-even analysis
 Payback
 Cash-flow analysis

210
Writing and Presenting the
Systems Proposal

211
The Systems Proposal
 Cover letter  Systems study
 Title page details
 Contents  Alternatives

 Executive  Recommendation

summary s
 Systems study  Summary

outline  Appendicies

212
Writing Style
 Understandable but not
condescending
 Organizational preference
 Active vs. passive voice
 That, which, and there
 Make the bottom line the top
line

213
Tables and Graphs
 Tables - one per page, clearly titled,
labeled, and outlined

 Graphs - appropriate to data, e.g.

pie chart to show % of whole

214
Presenting the Proposal
 Objective: info or decision
 Key points and issues
 Attention grabber
 Visual aids
 Paper charts, overheads,

35mm, computer driven

 It’s the delivery

215
Designing Effective
Output

216
Design Objectives
 Forms of output
 6 objectives for output
 Designed to serve a
purpose
 Fit the user
 Appropriate quantity
 Assure output where
needed
 Timely
 Correct output method
 Keep it simple (KISS) 217
Designing Effective
Input

Paper Forms and Video

Screens

218
Form Design:
Flow and Structure
 Heading
 ID and Access • Captioning
• Check-Off
 Instructions
 Body
 Signature and Verification
 Totals
 Comments

219
Input Forms/Screens Should Be:
 Effective
 Accurate
 Easy to use
 Consistent
 Simple
 Attractive

220
The User Interface

221
Interface Objectives
 Effectiveness
 Appropriate Access
 Efficiency
 Increased Speed w/Reduced
Errors
 User Consideration
 Feedback
 Productivity
 Ergonomic Design
222
Types of Interfaces
 Two Components
 Presentation Language -- Computer-to-
Human
 Action Language -- Human-to-Computer
 Natural Languages
 Q&A
 Menus
 Command Language
 GUI

223
Interface Examples

Organization Information Support System

Select a letter and press ‘Enter’

A. Word Processing
B. Accounting
C. Presentation Graphics
D. Organization Data
E. E-Mail
F. Calendar
F. Internet

.SELECT NAMES FROM PHONE WHERE ZIP = “22032” C:\>_

Command Language Menu

224
Interface Examples

Q&A GUI

225
Implementing the
System
CAHIMS 5.1, 5.3

226
Implementation
The process of assuring the information
system is operational
 allowing users to take over operation and
use
 continue feedback and evaluation

227
Implementation Components
Putting the System Into Operation

 Enabling users with an information

center
 Enabling users with appropriate
training
 Which Conversion Strategy?
 System Evaluation - How well does
it work?

228
Information Center
 Primary Objective: Support internal
organization users in accessing data so
that they are empowered to formulate,
analyze, and sole their own business
problems or questions through the use of
computers.

229
Training Users

 Who to train?
 Who provides training?

230
Conversion

• Direct Old System New System

• Pilot Old System New System

• Phased Old System

New System

• Parallel Old System

New System

231
Evaluation

 User involvement
 System utility
 Matrix
 Information system functions
 Modules - Forms, Times, Places,
Etc.

232
 Module 3
Project Management
CAHIMS 3.5

233
Management Tools
 Gantt charts
 Task Listing
 Task duration - length of bar
 PERT diagrams
 Shows relationships
 Critical path
 Computer-based

234
Project Management Software
 Identifying tasks
 Identifying task relationships
 Estimating task duration
 Resourcing tasks
 Resource costs
 Project and task reports

235
Using MS Project
 Adding tasks
 Creating task relationships
 The Gantt chart
 Establishing baseline
 Tracking Gantt chart
 Resources
 Sharing resources
 Reports

236
 Module 4
Security and Privacy
CAHIMS 7.2

237
 Security
 Access to hardware
 Access to software
 Access to data and information

238
 Privacy
 Federal laws govern privacy issues
 Health information privacy laws
 Physical procedures

239