ACCOUNTING INFORMATION SYSTEMS

ACFN 4121 CREDIT=3

B. A., Accounting and Finance, 4th Year
First Semester
CHAPTER-THREE
THE SYSTEM DEVELOPMENT PROCESS

PROF.DR.CHINNIAH ANBALAGAN
PROFESSOR OF ACCOUNITNG AND FINANCE
COLLEGE OF BUSINESS AND ECONOMICS
SAMARA UNIVERSITY, AFAR, ETHIOPIA EAST AFRICA
MAIL ID: DR.CHINLAKSHANBU@GMAIL.COM
System Development Process
 system initiation
 system analysis
 system design
 system implementation
 system support and continuous improvement
Basic Development Models
 sequential/waterfall
 iterative/incremental
Sequential Model

system
initiation

system
analysis

system
design

system information
implementation system
 Iterative/Incremental Model
system system system system
initiation analysis design implementation

increment
#1
system system system
analysis design implementation

increment
#2

system system system increment

analysis design implementation #3
 Methodologies
 provide alternative strategies to accommodate
different types of projects, technology goals
and development skills
 includes model descriptions, rules applicable to
the models, recommendations on good
practice and guidelines on the activities to be
followed
 methodologies

build or buy

predictive continuum adaptive

model-driven continuum product-driven

process- data-
prototype code
centric centric
moving
towards

object-
oriented
 Model-Driven Strategy
 system models facilitate communications
between users, analysts, designers and
builders
 typical models
 models that depict scope definition
 models that depict business and user
requirements
 architectural models
 physical models
 models to depict flow and procedure
 models to depict the redesigned business process
 Model-driven strategy
 model-driven techniques
 process modeling: reduce the communication gap
between technical and nontechnical stakeholders
 data modeling
 object modeling: attempts to eliminate the
separation between process and data
 The buy option
 determine prospective systems from existing
commercial application packages
 select a package and purchase
 install baseline commercial application
 redesign the business process
 conduct gap analysis
 customize the application to bridge the gap
between specific requirements and the current
features of the package
 1.System initiation

planning, preliminary investigation,

problem analysis
 System initiation
system development projects
 problems
 opportunities
 directives

problem-solving involves problem-solving,

exploiting opportunities and fulfilling directives
 System initiation
needs based on the PIECES framework
 need to improve performance
 need to improve information
 need to improve economics, control costs and
increase profit
 need to improve control or security
 need to improve efficiency of people and
processes
 need to improve service to customers,
suppliers, partners and employees
 System/project request
 may be a memo, letter, form
 evaluated according to urgency, visibility
benefits, priority, possible solutions
 factors that affect business decisions
 strategic plan
 top managers, IT department, users
 existing systems and data
 technology
 economy
 suppliers, customers, competitors, government
 System initiation
 preliminary investigation
 business profile and initial assessment
 define the problem
 is the problem worth it?
 establish initial scope
 problem analysis
 feasibility study (technical, operational, economic,
schedule)
 recommend course of action
 cancel, continue or reduce/expand scope
 Feasibility study
 assess worthiness based on operational,
economic, technical and schedule feasibility
 business case: justification for a request
 done by a committee or an individual
 an ongoing task that must be performed
throughout the systems development process
 Feasibility study
 possible questions raised
 will the proposed system reduce costs? increase
revenue? where? when? how? how much?
 will the system result in more information or
produce better results? how? are the results
measurable?
 will the system serve customers better?
 will the system serve the organization better?
 can the project be implemented in a reasonable
time period? how long will the results last?
 are the necessary financial, human, and technical
resources available?
 Scope definition
 problem definition and understanding
 determine cause and effect
 understand the problem domain
 establish baseline scope in terms of data,
business processes and system interfaces
 develop baseline schedule and budget
 identify constraints
 models used
 fishbone diagram (Ishikawa diagram)
 Pareto chart
 context diagram
 present results to management
 Steps in planning the
preliminary investigation

 1. understand the problem or opportunity

 2. define the project scope and constraints.
 3. Perform a fact-finding
 4. analyze project usability, cost , benefits,
and schedule data.
 5. Evaluate feasibility
 6. Present results to and recommendations to
management.
 Understand the problem or
opportunity
 Ishikawa diagrams (also called fishbone
diagrams, or herringbone diagrams ,
cause-and-effect diagrams, or Fishikawa)
are diagrams that show the causes of a certain
event –
 created by Kaoru Ishikawa (1990).
 Common uses of the Ishikawa diagram are
product design and quality defect prevention,
to identify potential factors causing an overall
effect.
 Causes are usually grouped into major
categories to identify these sources of
variation. The categories typically include:
 People
 Methods
 Machines
 Materials
 Measurements
 Environments
 People: Anyone involved with the process
 Methods: How the process is performed and
the specific requirements for doing it, such as
policies, procedures, rules, regulations and
laws
 Machines: Any equipment, computers, tools
etc. required to accomplish the job
 Materials: Raw materials, parts, pens, paper,
etc. used to produce the final product
Fishbone diagram
Pareto chart
Example: Context Diagram

0 GRADED
CLASS LIST WORK
STUDENT
RECORDS GRADING STUDENT
SYSTEM FINAL GRADE
SYSTEM SUBMITTED
WORK

GRADE REPORT GRADE PARAMETERS

INSTRUCTOR
 Define the project scope
and constraints
 Project scope – defining the specific
boundaries, or extent, of the project.
 Project creep – the process by which projects
with general scope definitions expand gradually,
without the specific authorization.
 Constraint – is a requirement or condition that
the system must satisfy or an outcome that
the system must achieve.
 Can involve HW,SW,time,policy,law,or cost.
 Perform fact finding
 Analyze organization charts
 Conduct initial interview
 Review documentation
 Observe operations
 Conduct survey
 Analyze Project Usability,
cost, benefits, and Schedule
 Projects prediction
 Project schedule
 Gantt Chart - is a type of bar chart that illustrates
a project schedule. Gantt charts illustrate the
start and finish dates of the terminal elements
and summary elements of a project.
 Evaluate Feasibility
 Operational
 Technical
 Economic
 schedule
 Present Results and
recommendations to management

 The final task in preliminary investigation is to

prepare a report to management, and possibly
deliver a presentation.
 2. System analysis

requirements discovery, analysis,

modeling and documentation
 definition of terms
 systems analysis
 problem-solving technique that decomposes a
system into its component parts for the purpose
of studying how well those component parts work
and interact to accomplish their purpose; aims to
build a solid foundation for system development
 model
 representation of either reality or vision
 requirements discovery
 process of identifying or extracting system
problems and solution requirements from the
user community
 System analysis
 requirements analysis
 what capabilities must the system provide?
 what data must be captured and stored?
 what information must be generated?
 what performance level is expected?
 requirements documentation
 logical modeling
 translate requirements into logical models
 technology-independent
 methodology-dependent
 Requirements analysis
 determine what users need and want from the
system
 express user requirements
 functional - description of activities and services
that a system must provide, expressed in terms
of inputs, processes, outputs, stored data that
are needed to satisfy the system improvement
objectives
 non-functional - description of other features,
characteristics and constraints that define a
satisfactory system, include performance, ease of
learning, timetables, doc and training needs,
standards, quality management, security
 Requirements analysis
 prioritize requirements
 mandatory vs. desirable
 rank desirables
 model requirements
 analyze alternative solutions and make a
decision
 document requirements
 validate requirements
 Requirements definition
 define system requirements
 Is a characteristics or feature that must be
included in an information system to satisfy
business requirements and be acceptable to
users.
 General categories: inputs, outputs, processes,
performance, security/control
 sample requirements
 the web site must report online volume statistics
every four hours. (o)
 employees must swipe their ID cards into online
data collection terminals (i)
 Requirements definition
 sample requirements
 the student records system must calculate the
GPA at the end of each semester (pro)
 system must support 25 users online
simultaneously (per)
 response time must not exceed four seconds
(per)
 The system must provide log-on security (s)
 Requirements modelling
 the use of pictorial system models to visualize,
describe and validate existing or proposed
systems
 tools and techniques
 Prototype
 CASE tools
 structure chart
 data flow diagram
 unified modeling language (UML)
 E-R diagram
 many others…
 Tools and techniques
 prototyping
 prototype: concrete model that depicts how a
system will appear or behave
 CASE
 repository: database of models, descriptive
information, specifications, etc.
 facilities: tools for diagramming, dictionary,
design, code generation, quality management,
testing
 project management tools
 Tools and techniques
 application development environment
 programming language
 debuggers
 interface construction
 middleware
 testing tools
 version control
 help authoring
 repository links
Tools and techniques: benefits

 improved productivity
 improved quality
 more consistent documentation
 reduced maintenance
 enforcement of the methodology
 CASE TOOLS
 refer to the software used for the automated
development of systems software, i.e.,
computer code.
 The CASE functions include analysis, design,
and programming.
 Modeling tools – MS visio, analyst visibility
 Documentation tools – Case repository tools
 Engineering tools – systems architect
 Construction tools – code generator tools
 Structured Charts
 Functional Decomposition Diagrams
(structured charts) – is a top-down
representation of a function or process.
 Data flow diagrams
 shows how data moves through an
information system but does not show
program logic or processing steps
 DFD notation

EXTERNAL EXTERNAL
ENTITY ENTITY

DATA FLOW DATA FLOW

Gane &
PROCESS PROCESS Yourdon
Sarson

DATA FLOW DATA FLOW

DATA STORE
DATA STORE
Example: Context Diagram

0 GRADED
CLASS LIST WORK
STUDENT
RECORDS GRADING STUDENT
SYSTEM FINAL GRADE
SYSTEM SUBMITTED
WORK

GRADE REPORT GRADE PARAMETERS

INSTRUCTOR
 UML
 Unified Modeling Language – is a widely used
method of visualizing and documenting
software systems design.
 - UML uses object-oriented design concepts.
 UML provides various graphical tools such as
use case diagrams.
 Cross life-cycle activities
 fact-finding
 documentation (with repository)
 presentation
 feasibility analysis
 process and project management
Fact-finding
 Fact-finding
 a key activity during the system initiation and
system analysis phases
 requires that the information needed is
identified first
 fact-finding activities must be planned
 fact-finding results must be documented and
organized to facilitate readability and analysis
fact-finding techniques
 document review
 research
 questionnaires and surveys
 observation
 interviews
 prototyping
Zachman Framework
 John Zachman
 The zachman framework for Enterprise
Architecture, is a model that asks the
traditional fact-finding questions in a systems
development context.
 who,what, where, when, and how questions.
 Who? Who performs each of the procedures
within the system?
 What? What is being done?
 Where? Where are operations being
performed?
 When? When is a procedure performed?
 How? How is a procedure performed?
document review
 review existing documentation, reports, forms,
files, databases, memos
 organizational charts
 mission, vision statement
 formal objectives of the concerned subunit
 policy manuals, SOPs, job outlines
 completed forms
 manual and computerized databases, screens and
reports
 documentations of previous systems
document review
 facts that may be obtained
 symptoms and causes of problems
 personnel who have knowledge and
understanding of the problems
 business functions
 data that have to be collected and generated by
the system
 things that are not understood that can be
covered in interviews
research
 relevant literature provide additional
background information on the organization as
well as trends in business and technology
 sources
 magazines and books to obtain background
information
 professional meetings and seminars
 Internet
 site visits
observation
 observe the people at work
 one may also “live” the system
 timing
 during regular workloads
 peak periods
 obtain sample forms for the tasks being
observed
 although it provides additional perspective,
beware of the Hawthorne effect
questionnaires and surveys
 suitable for getting data from a large number
of people
 free-format vs. fixed-format
 ensure that questions collect the correct data
 impersonal nature gives people more freedom
to provide input and suggestions
interviews
 primary means of fact-finding
 Dialogue with user or manager to obtain their
requirements

 Two forms:
 Open-ended: conversational, questions with no
specific answers in mind
 Closed-ended: structured, questions with limited
range of possible answers
Individual Interview
 Interview one person at a time

 Advantages
 Easier to schedule than group interviews
 Disadvantages
 Contradictions and inconsistencies between
interviewees
 Follow-up discussions are time consuming
Group Interview
 Interview several key people together
 Advantages
 More effective use of time
 Can hear agreements and disagreements at once
 Opportunity for synergies
 Disadvantages
 More difficult to schedule than individual interviews
 steps
1. determine the people to interview
 organizational chart
 informal structures
 group interview
2. establish objectives for the interview
 general areas to be discussed
 information that is to be gathered
 topics are initially general but become more
detailed in the course of analysis
interviews
 steps
3. develop interview questions
 beware of leading questions that favor a particular
reply
 use different types of questions appropriately
(close-ended, open-ended, range-of-response)
4. prepare for the interview
 schedule (time, venue, length of interview)
 communicate the agenda beforehand
 request for documents related to interview topics
interviews
 steps
5. conduct the interview
 interview guidelines
 observance of engaged listening
 use of appropriate questions and language
 correct posture and proper gestures
 use of acceptance cues
 taking of notes
 neutrality
 appropriate use of restatement
 open and close the interview properly
interviews
 steps
6. document the interview
7. evaluate the interview
communication strategies
 know WHY you are communicating, and what
you want to accomplish
 know WHO your targets are
 know WHAT is expected of you and when to
go into detail
 know WHEN to speak and when to remain
silent
 know HOW to communicate effectively
 know your subject
written communication
 guidelines
 know your audience
 be concise and well-organized
 use an appropriate style
 use words that are easy to understand
 check grammar and spelling
 proof-read
written communication
 types
 e-mail
 primary form of communication
 decrease in formality does not imply diminished
attention to clear writing and good grammar
 follow netiquette
 memos and letters
 company letterhead
 templates
 reports
presentations
 typical goals
 communicate project status
 describe initial findings
 explain solutions and alternatives
 justify decisions related to the project
 present system development work products
 consist of the introduction, the information
and the summary
presentations
 guidelines
 know your audience
 be specific, coherent and organized
 know when technical terms are appropriate
 use appropriate visual aids
 practice, practice, practice
 be credible
 use effective speaking techniques
 turn your nervousness into an advantage
presentations
 guidelines
 avoid meaningless words or phrases
 control the presentation
 review main points in the summary and ask for
questions
 answer questions appropriately
system design
 create a blueprint based on the requirements
 determine the application architecture
 technical implementation of the logical design
 user interface (prototype) and data design
 redesign business processes
 design specification documentation
 address system integration issues
system implementation
 build and test the system according to
requirements and the design specification
 write code
 implement the interfaces of the system with
existing ones
 purchased software are installed and
configured
 aims to deliver a functional and documented
information system
system implementation
 install the system
 provide a smooth transition
 user training
 assist users with normal start-up problems
 data initialization or conversion
 evaluate the system (post-audit/post-mortem)
system operation and support
 ensure that system is operational
 maintain the system
 correct errors
 adapt to changes in the environment
 enhance with new features and benefits
 protect the system
system maintenance
 smaller-scale version of the system life cycle
 triggered by some combination of user and
technical feedback
 program errors
 design flaws
 business process issues
 new technical requirements
 new business requirements
 result should be an updated, improved system