Systems Analysis

1
Systems Analysis Design

• Systems Analysis determining the requirements
  for a system
• What the system must do.
• Systems Design designing a system that meets the
  requirements
• How the system will do it.
• The phrase Systems Analysis and Design refers
  to an ordered process for the development of
  system.

2
Why do we need Systems Analysis Design?

• Large numbers of IS projects fail
• A study of well run organisations
• 10 of IS projects 100 over budget.
• A study of 600 companies
• 30-35 of IS projects are runaways
• A study by Yourdon (1992)
• 50 of IS projects at least 1 year late 100
  over budget.
• And worse
• Projects are frequently abandoned only when funds
  are nearly exhausted.

3
The Results

• Lost credibility
• Wasted funds
• Lost business opportunity
• Low morale
• Possible bankruptcy

4
Why do projects fail?

• Working without a clear set of specifications
• Premature coding Lack of planning
• Lack of user involvement/agreement
• Poor estimation of resources required
• Poor documentation of decisions
• Lack of quality assurance
• Staff turnover
• Over-manning in a crisis
• Inadequate knowledge of tools and or techniques

5
But also

• Requirements change throughout development
• (Scope Creep)
• Productivity levels vary widely
• Estimation techniques are poorly developed
• IS staff have distinct personality profiles (too
  optimistic)

6
Can We Improve?

• Building IS systems has a short history,
• Maybe we just need to learn how to do IT!

7
Successful Projects

• The success of a project is measured by its
  ability
• To meet the expressed requirements
• To meet the needs of the client/user
• To be completed on time and within budget.

8
How?

• Applying rigor to development projects
• Researching successes and failures
• Collecting statistics
• Applying sound System Analysis and Design
  Principles
• Use of Modeling Techniques
• Use of Methodologies

9
The System Development Process
10
The System Development Process is a set of
activities, methods, best practices,
deliverables, and automated tools that
stakeholders use to develop and maintain
information systems and software. A System Life
Cycle divides the life of an information system
into two stages, systems development and systems
operation and support.
11
(No Transcript)
12

• A system development life cycle (SDLC) is a
  logical process by which systems analysts,
  software engineers, programmers, and end-users
  build information systems and computer
  applications to solve business problems and
  needs.
• Also called an application development life cycle
  or systems development process

13
An example of a system development life
cycle Planning Analysis Design Build I
mplement Operate Here the phases provide
the input to the next phase and feedback to one
another. There are many other SDLCs.
14
Systems Development Methodologies A systems
development methodology is a very formal and
precise system development process that defines a
set of activities, methods, best practices,
deliverables, and automated tools that system
developers and project managers are to use to
develop and maintain information systems and
software.  
15
Principles of System Development       Get the
owners and users involved.       Use a
problem-solving approach.       Establish phases
and activities.       Establish
standards.       Justify systems as capital
investments.       Dont be afraid to cancel or
revise scope.       Divide and conquer.      
Design systems for growth and change.  
16
Systems Development Framework.

• A Systems Development Framework provides a
  generalised view of the systems development
  process.
• Identifies the necessary building blocks to
  successfully build systems.

17
(No Transcript)
18
What is a Methodology?

• The process used to develop information systems
  is called a methodology.
• Methodologies are derived from a logical system
  problem-solving process.
• Often referred to as
• System Development Life Cycle
• AND Systems Development Framework.

19

• Methodologies provide developers with
• Phases, activities or steps to assist with
  project management and timing of tasks
• Tools Techniques which provide methods of
  documenting and analysing requirements and
  designs
• Deliverables to identify what must be produced
  during each activity in the development process.
  Deliverables are completed at the end of each
  activity
• Individual and Group Roles for each Activity
• Quality Standards.

20

• Why Do Companies use Methodologies?
• Methodologies ensure that a consistent,
  reproducible approach is applied to all projects.
• Methodologies reduce the risk associated with
  shortcuts and mistakes.
• Methodologies produce complete and consistent
  documentation from one project to the next.

21
Software Development Methods

• Various commercial methods are available for
  systems development
• BSP Business Systems Planning
• SADT Structured Analysis and Design Technique
• SSADM Structured Analysis And Design Method
• SALD Structured Analysis and Logical Design
• JSD Jackson System Development
• IE Information Engineering
• SSM Soft Systems Methodology - Lancaster
• RAD Rapid Applications Development
• OOA Object Oriented Analysis
• And many others

22
Some Limitations?

• Some methods may not cover all phases of the
  Systems Development Process.
• For example
• SADT
• analysis and design.
• SSADM
• analysis, design and implementation.
• IE
• planning, analysis, design and implementation.

23
The Good News!

• Most methods are suitable for small, medium and
  large projects.

24

• Models
• Are a representation of reality
• Analysts describe information system requirements
  using a collection of models
• Complex systems require more than one type of
  model
• Models represent some aspect of the system being
  built

25
Reasons for ModelingFigure 5-2
Systems Analysis and Design in a Changing World,
2nd Edition, Satzinger, Jackson, Burd
26

• Types of Models
• Different types of models are used in information
  systems development
• Mathematical - formulas that describe technical
  aspects of the system
• Descriptive - narrative memos, reports, or lists
  that describe aspects of the system
• Graphical - diagrams and schematic
  representations of some aspect of the system

27

• Logical models show what a system does.
• Independent of implementation
• Referred to as essential models, conceptual
  models or business models.
• Mainly used in requirements definition
• (Models used in this subject will mostly be
  logical models)

28

• Physical models show how ( what) a system does.
• Implementation dependant
• Referred to as implementation models or technical
  models.
• Mainly used in the design phase

29
Types of methodologies         Model-Driven
Development (MDD)       Rapid Application
Development (RAD)       Commercial Off-the-Shelf
Software (COTS)       or hybrids of the above
30
Whitten, J. Bentley, L. Dittman, K. Systems
Analysis and Design Methods, Fifth Edition,
McGraw Hill 2000
31
   Modelling is the act of drawing one or more
graphical representations (or pictures) of a
system. Modelling is a communication technique
based upon the old saying, a picture is worth a
thousand words.      Model-driven development
techniques emphasize the drawing of models to
help visualize and analyse problems, define
business requirements, and design information
systems.
32
Examples of Model-driven development Structured
systems analysis and design process-centered Inf
ormation engineering (IE) data-centered Object-o
riented analysis and design (OOAD)
object-centered (integration of data and process)
33
Whitten, J. Bentley, L. Dittman, K. Systems
Analysis and Design Methods, Fifth Edition,
McGraw Hill 2000
34

• Rapid Application Development Route
• Rapid application development (RAD) techniques
  emphasize extensive user involvement in the rapid
  and evolutionary construction of working
  prototypes of a system to accelerate the system
  development process.
• RAD is based on building prototypes that evolve
  into finished systems (often using time boxing)
• A prototype is a smaller-scale, representative or
  working model of the users requirements or a
  proposed design for an information system.
• A time box is a nonextendable period of time,
  usually 60-120 days, by which a candidate system
  must be placed into operation.

35
Whitten, J. Bentley, L. Dittman, K. Systems
Analysis and Design Methods, Fifth Edition,
McGraw Hill 2000
36
Commercial off-the-shelf (COTS) software is a
software package or solution that is purchased to
support one or more business functions and
information systems.
37
Whitten, J. Bentley, L. Dittman, K. Systems
Analysis and Design Methods, Fifth Edition,
McGraw Hill 2000
38
Whitten, J. Bentley, L. Dittman, K. Systems
Analysis and Design Methods, Fifth Edition,
McGraw Hill 2000
39
The People The Organisation

• Identifying requirements What do they need and
  where do you get the information

40
The Stakeholders   A stakeholder is any person
who has an interest in an existing or new
information system. Stakeholders can be technical
or non-technical workers.   For information
systems, the stakeholders can be classified
as   System owners  System users  Systems
analysts System designers System builders IT
vendors and consultants
41
Systems Owners Users   Anyone who may use the
system   Top Level Management   Middle
Management. Operational Management   Operati
onal Staff.
42
System Owners Top Level Strategic
Management   The systems sponsors and chief
advocates.   Their involvement is essential
They pay for the project and give final
approval.   Responsible for funding the project
to develop, operate, and maintain the information
system. Involvement in Information Systems
Projects   Concerned with policies and
plans Long term perspective See only achievement
and costs. See project in business
terms. Responsible for strategic or tactical
goals/plans. See project as an investment. Allow
access to necessary resources.
43
System users The people who use or are affected
by the information system on a regular
basis. They use the system to capture, validate,
enter, respond to, store, and exchange data and
information. Types include Internal
users Clerical and service workers Technical and
professional staff Supervisors, middle managers,
and executive managers Remote and mobile users
(internal but disconnected) External users A
common synonym is client.
44
Organisational Needs Information Systems
45
Strategic management   Determine long term
direction of the organisation.   Systems designed
to support their work   ESS/ DSS and MIS
relevant   These systems assist with
unstructured one-off decisions that require
judgement
46
Middle Management or Tactical Management Determin
e tactics to implement strategy   Set operational
goals/plans.   Systems must collect data to
evaluate operational goals. Systems designed to
support their work MIS and DSS are
important   MIS assists monitoring and control in
Department or Organisational Units   DSS support
unstructured decisions
47
Operational Management   Are responsible to
implement the tactics determined by middle
management. Set timetables Assign
personnel Largely concerned with regular
monitoring and reporting Problems are
recurrent  Monitor day to day operations Short
term perspective       Systems designed to
support their work MIS and DPS
48
Operational Personnel   The non managerial
layers, perform day to day tasks   Work is
usually consists of performing transactions   Syst
ems designed to support their work   DPS
49
User Responsibilities.   Supply necessary
resources.   Specify requirements.   Supply
necessary information required for
development.   Provide access to relevant
documents, equipment, staff, facilities.   Note
One may not assume that a client is aware of
these responsibilities. The responsibilities of
the client/user must be defined prior to
initiating a study and should be mentioned in the
terms of reference.
50

• Information Gathering
• Where does one get the information needed to
  identify requirements?
•  
• System Owners/Users
•  
• Major source of information source
• Responsible to supply information needed by
  analyst and designer
• Able to describe the system
• Identify problems, opportunities and deficiencies
• Articulate new system requirements
• Suggest other information sources

51
Company Documents Forms/reports/memos obtain list
from users Current system documentation   Computer
Programs and system documentation   Policy and
Procedure Manuals Organisational charts, mission
and objectives Job descriptions, Polices and
procedures   Other Sources Annual reports Trade
journals Vendors Training manuals and courseware
52
Measuring Development Capabilities

• The Capability Maturity Model (CMM)

53
The Capability Maturity Model (CMM)   A
framework to assess the maturity level of an
organizations information system development and
management processes and products.   Consists
of five levels of maturity measured by a set of
guidelines called the key process areas.
54

• Key Process Areas
• Level 1Initial
• Level 2Repeatable 
• Level 3Defined
• Level 4Managed
• Level 5Optimizing

55
Level 1Initial System development projects
follow no prescribed process.   Level
2Repeatable Project management processes and
practices are established to track project costs,
schedules, and functionality.   Level 3Defined
A standard system development process (sometimes
called a methodology) is purchased or
developed, and integrated throughout the
information systems/services unit of the
organization.   Level 4Managed Measurable
goals for quality and productivity are
established.   Level 5Optimizing The
standardized system development process is
continuously monitored and improved based on
measures and data analysis established in Level
4.
56
(No Transcript)
57

• This subject will focus on
• Systems Analysis
• System Design
• The Analysis-Design interface
• Methodology concepts.