Top Banner
Methodologies in Methodologies in Systems Analysis Systems Analysis Irma Richardson Irma Richardson Mark Thornhill Mark Thornhill BA3810 BA3810 Feb. 4, 2008 Feb. 4, 2008
25
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: presentation

Methodologies in Systems Methodologies in Systems AnalysisAnalysisIrma RichardsonIrma RichardsonMark ThornhillMark Thornhill

BA3810BA3810Feb. 4, 2008Feb. 4, 2008

Page 2: presentation

DefinitionDefinition

Methodologies are comprehensive Methodologies are comprehensive multiple-step approaches to systems multiple-step approaches to systems development.development.

They range from very formalized and They range from very formalized and documented methods to very simple, or documented methods to very simple, or none at all.none at all.

Defined by Avison and Fitzgerald (1995) Defined by Avison and Fitzgerald (1995) as as a set of techniques underpinned by a a set of techniques underpinned by a philosophyphilosophy..

Page 3: presentation

Methodologies and ManagementMethodologies and Management

A methodology adopted by an A methodology adopted by an organization will be consistent with its organization will be consistent with its general management stylegeneral management style

The methodology chosen represents how The methodology chosen represents how well management agrees on aspects of well management agrees on aspects of decision makingdecision making

Page 4: presentation

TechniquesTechniques

Techniques are practical processes that Techniques are practical processes that analysts will follow as part of the methodology.analysts will follow as part of the methodology.

Ensure that the assignment is well thought out, Ensure that the assignment is well thought out, complete, and comprehensive.complete, and comprehensive.

Support a wide range of tasks, including:Support a wide range of tasks, including: InterviewsInterviews Planning and managingPlanning and managing DiagrammingDiagramming Designing reportsDesigning reports

Page 5: presentation

HistoryHistory

Early systems were developed in a Early systems were developed in a vacuum:vacuum: Limited user involvementLimited user involvement Inadequate requirements gatheringInadequate requirements gathering Ad hoc analysis and design techniquesAd hoc analysis and design techniques

Resulting systems often failed to meet Resulting systems often failed to meet requirementsrequirements Led to extensive maintenance requirementsLed to extensive maintenance requirements

http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html

Page 6: presentation

Why did early systems fail to meet Why did early systems fail to meet requirements?requirements?

Lack of ownership of and commitment to the Lack of ownership of and commitment to the system from users as a result of the low level of system from users as a result of the low level of involvementinvolvement

Business requirements may have changed Business requirements may have changed between inception and deliverybetween inception and delivery

Requirements may have been misunderstoodRequirements may have been misunderstood Inadequate analysis and design tools and Inadequate analysis and design tools and

techniques may have been usedtechniques may have been used ……or more likely a combination of these or more likely a combination of these

problemsproblems

http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html

Page 7: presentation

Early Systems AnalysisEarly Systems Analysis

No formal structureNo formal structure Resulting document often very long and difficult Resulting document often very long and difficult

for users to graspfor users to grasp Long narrative descriptionsLong narrative descriptions Record layoutsRecord layouts Report / display mock-upsReport / display mock-ups FlowchartsFlowcharts

Omissions, inconsistencies, and Omissions, inconsistencies, and misunderstandings difficult to detect, expensive misunderstandings difficult to detect, expensive to correct.to correct.

http://www.idinews.com/story.html Conrad Weisert, June 30, 2006

© Information Disciplines, Inc., Chicago

Page 8: presentation

Response to the problemResponse to the problem

The IS community responded to the The IS community responded to the problem by developing structured methods problem by developing structured methods of systems engineeringof systems engineering

``Structured Analysis and Systems ``Structured Analysis and Systems Specification'' by Tom De Marco (1978)Specification'' by Tom De Marco (1978)

““Structured Systems Analysis: Tools and Structured Systems Analysis: Tools and Techniques” by Chris Gane & Trish Techniques” by Chris Gane & Trish Sarson (1979)Sarson (1979)

Page 9: presentation

Criteria of “Structured” analysisCriteria of “Structured” analysis

A definite place to start, both for the analyst creating the A definite place to start, both for the analyst creating the specification and for anyone reading it.specification and for anyone reading it.

A definite and obvious place for every piece of relevant A definite and obvious place for every piece of relevant requirements information and clear relationships among requirements information and clear relationships among all components of the system specification.all components of the system specification.

Avoidance of repetition.Avoidance of repetition. Consistency among all components of the system Consistency among all components of the system

specification.specification. Avoidance of vagueness and ambiguity at all levels.Avoidance of vagueness and ambiguity at all levels. A definite end, with assurance that the specification is A definite end, with assurance that the specification is

complete, with respect to known requirements. complete, with respect to known requirements.

© Information Disciplines, Inc., Chicago

Page 10: presentation

Systems Development Life Cycle Systems Development Life Cycle (SDLC)(SDLC)

A.k.a. Waterfall A.k.a. Waterfall ModelModel

Inherent Inherent problem is that problem is that all requirements all requirements are rarely are rarely discovered at discovered at the beginningthe beginning

Page 11: presentation

Rapid Application Development Rapid Application Development (RAD)(RAD)

RAD is a methodology RAD is a methodology for compressing the for compressing the analysis, design, build, analysis, design, build, and test phases into a and test phases into a series of short, iterative series of short, iterative development cycles. development cycles.

Iteration allows for Iteration allows for effectiveness and self-effectiveness and self-correction. People are correction. People are good at making an good at making an adequate beginning and adequate beginning and then making many small then making many small refinements and refinements and improvements. improvements.

Intended to overcome Intended to overcome inherent problem of inherent problem of Waterfall.Waterfall.

http://www.credata.com/research/rad.html

Page 12: presentation

Joint Application Development Joint Application Development (JAD)(JAD)

Brings together business area people (users) Brings together business area people (users) and IT (Information Technology) professionals in and IT (Information Technology) professionals in a highly focused workshop. a highly focused workshop.

Advantages include a dramatic shortening of the Advantages include a dramatic shortening of the time it takes to complete a project. time it takes to complete a project.

Also improves the quality of the final product by Also improves the quality of the final product by focusing on the up-front portion of the focusing on the up-front portion of the development lifecycle, thus reducing the development lifecycle, thus reducing the likelihood of errors that are expensive to correct likelihood of errors that are expensive to correct later on.later on.

Developed by Chuck Morris of IBM Raleigh and Developed by Chuck Morris of IBM Raleigh and Tony Crawford of IBM Toronto around 1980. Tony Crawford of IBM Toronto around 1980.

http://www.credata.com/research/jad.html

Page 13: presentation

Gane & Sarson Data Flow Diagram Gane & Sarson Data Flow Diagram (DFD) (DFD)

The Gane & The Gane & Sarson style Sarson style DFD is typically DFD is typically used for used for information information systems. Here is systems. Here is shown the flow of shown the flow of information in a information in a small software small software company. company.

http://www.excelsoftware.com/processmodel.html

Page 14: presentation

Hatley/PirbhaiHatley/Pirbhai Extension of the concept Extension of the concept

that every computer that every computer system can be modeled system can be modeled through the usage of an through the usage of an input-processing-output input-processing-output model by including the model by including the two addition features of two addition features of user interface process user interface process and maintenance/self and maintenance/self testing.testing.

The template The template components are: User components are: User Interface, Input, System Interface, Input, System Function and Control, Function and Control, Output and Output and Maintenance/Self Test.Maintenance/Self Test. http://en.wikipedia.org/wiki/Hatley-

Pirbhai_modeling

Page 15: presentation

Yourdon/DeMarco DFD Yourdon/DeMarco DFD

It includes both It includes both data and control data and control flow as required flow as required in the in the Hatley/Pirbhai Hatley/Pirbhai method typically method typically used in real-time used in real-time system analysis system analysis and design. and design.

http://www.excelsoftware.com/processmodel.html

Page 16: presentation

Object Oriented Analysis (OOA)Object Oriented Analysis (OOA)

Built around objects – combinations of data and Built around objects – combinations of data and processes.processes.

Objects correspond to real things, such as Objects correspond to real things, such as customers, suppliers, contractscustomers, suppliers, contracts

Goal is to make systems elements more Goal is to make systems elements more reusablereusable

Organized into object classes – groups of Organized into object classes – groups of objects sharing structural and behavioral objects sharing structural and behavioral characteristicscharacteristics

Uses inheritance principleUses inheritance principle Uses Use Cases and UMLUses Use Cases and UML

Page 17: presentation

Use CasesUse Cases

Depiction of a system’s Depiction of a system’s behavior or functionality behavior or functionality under various conditions under various conditions as the system responds as the system responds to requests from users.to requests from users.

Components:Components: ActorsActors Use casesUse cases System boundarySystem boundary ConnectionsConnections Extend relationshipExtend relationship Include relationshipInclude relationship

http://www.alistapart.com/articles/tamingscope

Page 18: presentation

Unified Modeling Language (UML)Unified Modeling Language (UML)

Standardized specification language for object modeling. Standardized specification language for object modeling. General-purpose modeling language that includes a General-purpose modeling language that includes a

graphical notation used to create an abstract model of a graphical notation used to create an abstract model of a system, referred to as a UML model.system, referred to as a UML model.

Helps assure that business functionality is complete and Helps assure that business functionality is complete and correct, end-user needs are met, and program design correct, end-user needs are met, and program design supports requirements for scalability, robustness, supports requirements for scalability, robustness, security, extendibility, and other characteristics, before security, extendibility, and other characteristics, before implementation in code. implementation in code.

Tools are available to generate program code from UML Tools are available to generate program code from UML models.models.

Can be used to model not only software systems, but Can be used to model not only software systems, but business systems and other non-software systems.business systems and other non-software systems.

http://www.omg.org/gettingstarted/what_is_uml.htm

Page 19: presentation

Example of OO UML ModelExample of OO UML Model

Simplified banking systemSimplified banking system

http://www.ratio.co.uk/W1.html

Page 20: presentation

Agile MethodologiesAgile Methodologies

Argues that software development methodologies Argues that software development methodologies adapted from engineering generally do not fit adapted from engineering generally do not fit with real-world software development. with real-world software development. Requirements are much more fluid for software Requirements are much more fluid for software than typical engineering projects.than typical engineering projects.

Share three key principles:Share three key principles:1.1. Focus on adaptive rather than predictive Focus on adaptive rather than predictive

methodologiesmethodologies2.2. Focus on people rather than rolesFocus on people rather than roles3.3. Focus on self-adaptive processesFocus on self-adaptive processes

Page 21: presentation

Soft Systems Methodologies (SSM)Soft Systems Methodologies (SSM)

Blend of conventional data collection and analysis Blend of conventional data collection and analysis techniques together with creative thinking tools (e.g. techniques together with creative thinking tools (e.g. cognitive mapping) used to characterize business cognitive mapping) used to characterize business problems (with significant social/political content) and problems (with significant social/political content) and hopefully suggest ways in which they can be resolved.hopefully suggest ways in which they can be resolved.

Peter Checkland noted the limitations of applying Peter Checkland noted the limitations of applying traditional systems approaches (i.e. Input > traditional systems approaches (i.e. Input > Process>Output etc.) He concluded that this was Process>Output etc.) He concluded that this was because typical business problems were often because typical business problems were often deceptively complex, with many competing influences, deceptively complex, with many competing influences, and sometimes no obvious right answers.and sometimes no obvious right answers.

Five distinct stages: Rich Pictures, Root Definitions, Five distinct stages: Rich Pictures, Root Definitions, Conceptual Models, Real World Comparisons and Conceptual Models, Real World Comparisons and Solution Development.Solution Development.

http://www.managers-net.com/ssm1.html

Page 22: presentation

Five Stages of SSMFive Stages of SSM Rich Pictures Rich Pictures

Finding out about the problem situation and expressing it through cartoon-like diagrams showing Finding out about the problem situation and expressing it through cartoon-like diagrams showing boundaries, structure, information/communication channels (e.g. documents, e-mails, media etc), boundaries, structure, information/communication channels (e.g. documents, e-mails, media etc), participants, monitoring activities (usu. shown as eyeballs), areas of conflict (usu. shown as crossed participants, monitoring activities (usu. shown as eyeballs), areas of conflict (usu. shown as crossed swords), emotions displayed, barriers to communication etc. The mix of the formal and informal generates swords), emotions displayed, barriers to communication etc. The mix of the formal and informal generates the richness. the richness.

Root Definitions Root Definitions Identifying the perspective/motivation of each group of stakeholders in the rich picture. Checkland Identifying the perspective/motivation of each group of stakeholders in the rich picture. Checkland

introduced the mnemonic CATWOE to describe the six elements that need to be covered: introduced the mnemonic CATWOE to describe the six elements that need to be covered: Customer: the beneficiaries of the system. Customer: the beneficiaries of the system. Actor: the people who perform the tasks in the system. Actor: the people who perform the tasks in the system. Transformation: the core activity of the system, or primary change brought about. Transformation: the core activity of the system, or primary change brought about. Weltanschauung (or worldview): the underlying beliefs & objectives of the system. Weltanschauung (or worldview): the underlying beliefs & objectives of the system. Owner: the person or body that has the power to approve/cancel the system. Owner: the person or body that has the power to approve/cancel the system. Environment: external constraints (e.g. legal, commercial, environmental etc.) Environment: external constraints (e.g. legal, commercial, environmental etc.)

Conceptual Models Conceptual Models A simplified diagram (typically 5-10 stage) showing how each stakeholder would ideally see the system A simplified diagram (typically 5-10 stage) showing how each stakeholder would ideally see the system

operating to achieve each Root Definition. More detailed second-level diagrams can be produced where operating to achieve each Root Definition. More detailed second-level diagrams can be produced where necessary. necessary.

Real World Comparisons Real World Comparisons The conceptual models are compared with the real world activities to see whether or not the perspectives The conceptual models are compared with the real world activities to see whether or not the perspectives

are being met, and where there are discrepancies. This comparison can be carried out in many ways, e.g.: are being met, and where there are discrepancies. This comparison can be carried out in many ways, e.g.: documenting the current practices, interviewing or benchmarking. documenting the current practices, interviewing or benchmarking.

Solution Development Solution Development After the discrepancies have been identified, possible solutions are explored, and their feasibility evaluated. After the discrepancies have been identified, possible solutions are explored, and their feasibility evaluated.

http://www.managers-net.com/ssm1.html

Page 23: presentation

Method Chunk FederationMethod Chunk Federation

Seeks to break down project-specific Seeks to break down project-specific methodologies into more generic “chunks” that methodologies into more generic “chunks” that can be located, retrieved, and reused by other can be located, retrieved, and reused by other projects.projects.

Recognizes the need for customization, and the Recognizes the need for customization, and the perceived rigidity of conventional methodologies.perceived rigidity of conventional methodologies.

Focuses on reuse to take advantage of existing Focuses on reuse to take advantage of existing developments, to the extent possible.developments, to the extent possible.

http://www.via-nova-architectura.org/files/EMMSAD2006/Mirbel.pdf

Page 24: presentation

Actual Methodology for Actual Methodology for Implementing SAPImplementing SAP

L4 Analysis & Localized

Design

Development & Functional Unit

Test(GLOBE, H/L)

Streams analyze the GLOBE Template (Level 3-5 and E2E Processes) and determine the desired design for NPPC.

L4 Scoping Process

[Complete]

Determine the number of L4's that are in scope by Stream. Performed during Solution Preparation.

Cycle 1-A Configuration

Buckets

BBP1 Workshop (SAP

Organization Hierarchy)

Cycle 1Testing

(Configuration Testing)

Determine the Data Objects that are in Scope for the Market

Scope & ClusteringWorkshops[Complete]

Gap Documentation & Market, GC, BTC

Approval. Functional

Specifications

Fit & Downstream Activities (incl.

Cycle 1-B Config)

L4 Out of Scope& Downstream

Activities Cycle 2 Configuration

Buckets

Market Integration Test 1

(End-to-End Process Testing)

Note: If errors / corrections found during this process, a formal Rework / Change Process must be followed. This process is not depicted above.

Cycle 2 Testing(Configuration

Testing)Market

Integration Test 2(End-to-End

Process Testing)

Market Acceptance Test

(Full System Testing)

Cluster Go-Live

Data Object Scope List

Cutover Simulation 1

Testing

MIG does not have CS1 feed into MIT1. NPPC investigating having CS1 data feed into MIT1.

Cutover Simulation 2

Testing

End-To-End Localization

End User Learning & Training,

Communication

Production Data Load

Define, Construct & Functional Unit Test of Data Load

(GLOBE, H/L)

Roles, Change Impacts, Learning

& Training Localization

Major MIG Activites- High Level Process Flow

Page 25: presentation

Questions?Questions?