presentation
Upcoming SlideShare
Loading in...5
×
 

presentation

on

  • 1,036 views

 

Statistics

Views

Total Views
1,036
Slideshare-icon Views on SlideShare
709
Embed Views
327

Actions

Likes
0
Downloads
16
Comments
0

3 Embeds 327

http://mycourse.solent.ac.uk 322
http://mycourse-archive.solent.ac.uk 4
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    presentation presentation Presentation Transcript

    • Methodologies in Systems Analysis Irma Richardson Mark Thornhill BA3810 Feb. 4, 2008
    • Definition
      • Methodologies are comprehensive multiple-step approaches to systems development.
      • They range from very formalized and documented methods to very simple, or none at all.
      • Defined by Avison and Fitzgerald (1995) as a set of techniques underpinned by a philosophy .
    • Methodologies and Management
      • A methodology adopted by an organization will be consistent with its general management style
      • The methodology chosen represents how well management agrees on aspects of decision making
    • Techniques
      • Techniques are practical processes that analysts will follow as part of the methodology.
      • Ensure that the assignment is well thought out, complete, and comprehensive.
      • Support a wide range of tasks, including:
        • Interviews
        • Planning and managing
        • Diagramming
        • Designing reports
    • History
      • Early systems were developed in a vacuum:
        • Limited user involvement
        • Inadequate requirements gathering
        • Ad hoc analysis and design techniques
      • Resulting systems often failed to meet requirements
        • Led to extensive maintenance requirements
      http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html
    • Why did early systems fail to meet requirements?
      • Lack of ownership of and commitment to the system from users as a result of the low level of involvement
      • Business requirements may have changed between inception and delivery
      • Requirements may have been misunderstood
      • Inadequate analysis and design tools and techniques may have been used
      • … or more likely a combination of these problems
      http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html
    • Early Systems Analysis
      • No formal structure
      • Resulting document often very long and difficult for users to grasp
        • Long narrative descriptions
        • Record layouts
        • Report / display mock-ups
        • Flowcharts
      • Omissions, inconsistencies, and misunderstandings difficult to detect, expensive to correct.
      http://www.idinews.com/story.html Conrad Weisert, June 30, 2006 © Information Disciplines, Inc., Chicago
    • Response to the problem
      • The IS community responded to the problem by developing structured methods of systems engineering
      • ``Structured Analysis and Systems Specification'' by Tom De Marco (1978)
      • “ Structured Systems Analysis: Tools and Techniques” by Chris Gane & Trish Sarson (1979)
    • Criteria of “Structured” analysis
      • A definite place to start, both for the analyst creating the specification and for anyone reading it.
      • A definite and obvious place for every piece of relevant requirements information and clear relationships among all components of the system specification.
      • Avoidance of repetition.
      • Consistency among all components of the system specification.
      • Avoidance of vagueness and ambiguity at all levels.
      • A definite end, with assurance that the specification is complete, with respect to known requirements.
      © Information Disciplines, Inc., Chicago
    • Systems Development Life Cycle (SDLC)
      • A.k.a. Waterfall Model
      • Inherent problem is that all requirements are rarely discovered at the beginning
    • Rapid Application Development (RAD)
      • RAD is a methodology for compressing the analysis, design, build, and test phases into a series of short, iterative development cycles.
      • Iteration allows for effectiveness and self-correction. People are good at making an adequate beginning and then making many small refinements and improvements.
      • Intended to overcome inherent problem of Waterfall.
      http://www.credata.com/research/rad.html
    • Joint Application Development (JAD)
      • Brings together business area people (users) and IT (Information Technology) professionals in a highly focused workshop.
      • Advantages include a dramatic shortening of the time it takes to complete a project.
      • Also improves the quality of the final product by focusing on the up-front portion of the development lifecycle, thus reducing the likelihood of errors that are expensive to correct later on.
      • Developed by Chuck Morris of IBM Raleigh and Tony Crawford of IBM Toronto around 1980.
      http://www.credata.com/research/jad.html
    • Gane & Sarson Data Flow Diagram (DFD)
      • The Gane & Sarson style DFD is typically used for information systems. Here is shown the flow of information in a small software company.
      http://www.excelsoftware.com/processmodel.html
    • Hatley/Pirbhai
      • Extension of the concept that every computer system can be modeled through the usage of an input-processing-output model by including the two addition features of user interface process and maintenance/self testing.
      • The template components are: User Interface, Input, System Function and Control, Output and Maintenance/Self Test.
      http://en.wikipedia.org/wiki/Hatley-Pirbhai_modeling
    • Yourdon/DeMarco DFD
      • It includes both data and control flow as required in the Hatley/Pirbhai method typically used in real-time system analysis and design.
      http://www.excelsoftware.com/processmodel.html
    • Object Oriented Analysis (OOA)
      • Built around objects – combinations of data and processes.
      • Objects correspond to real things, such as customers, suppliers, contracts
      • Goal is to make systems elements more reusable
      • Organized into object classes – groups of objects sharing structural and behavioral characteristics
      • Uses inheritance principle
      • Uses Use Cases and UML
    • Use Cases
      • Depiction of a system’s behavior or functionality under various conditions as the system responds to requests from users.
      • Components:
        • Actors
        • Use cases
        • System boundary
        • Connections
        • Extend relationship
        • Include relationship
      http://www.alistapart.com/articles/tamingscope
    • Unified Modeling Language (UML)
      • Standardized specification language for object modeling.
      • General-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model.
      • Helps assure that business functionality is complete and correct, end-user needs are met, and program design supports requirements for scalability, robustness, security, extendibility, and other characteristics, before implementation in code.
      • Tools are available to generate program code from UML models.
      • Can be used to model not only software systems, but business systems and other non-software systems.
      http://www.omg.org/gettingstarted/what_is_uml.htm
    • Example of OO UML Model
      • Simplified banking system
      http://www.ratio.co.uk/W1.html
    • Agile Methodologies
      • Argues that software development methodologies adapted from engineering generally do not fit with real-world software development. Requirements are much more fluid for software than typical engineering projects.
      • Share three key principles:
      • Focus on adaptive rather than predictive methodologies
      • Focus on people rather than roles
      • Focus on self-adaptive processes
    • Soft Systems Methodologies (SSM)
      • Blend of conventional data collection and analysis techniques together with creative thinking tools (e.g. cognitive mapping) used to characterize business problems (with significant social/political content) and hopefully suggest ways in which they can be resolved.
      • Peter Checkland noted the limitations of applying traditional systems approaches (i.e. Input > Process>Output etc.) He concluded that this was because typical business problems were often deceptively complex, with many competing influences, and sometimes no obvious right answers.
      • Five distinct stages: Rich Pictures, Root Definitions, Conceptual Models, Real World Comparisons and Solution Development.
      http://www.managers-net.com/ssm1.html
    • Five Stages of SSM
      • Rich Pictures
        • 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), 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 the richness.
      • Root Definitions
        • 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:
        • Customer: the beneficiaries of the system.
        • Actor: the people who perform the tasks in the system.
        • Transformation: the core activity of the system, or primary change brought about.
        • Weltanschauung (or worldview): the underlying beliefs & objectives of 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.)
      • Conceptual Models
        • 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 necessary.
      • Real World Comparisons
        • 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.: documenting the current practices, interviewing or benchmarking.
      • Solution Development
        • After the discrepancies have been identified, possible solutions are explored, and their feasibility evaluated.
      http://www.managers-net.com/ssm1.html
    • Method Chunk Federation
      • Seeks to break down project-specific methodologies into more generic “chunks” that can be located, retrieved, and reused by other projects.
      • Recognizes the need for customization, and the perceived rigidity of conventional methodologies.
      • Focuses on reuse to take advantage of existing developments, to the extent possible.
      http://www.via-nova-architectura.org/files/EMMSAD2006/Mirbel.pdf
    • Actual Methodology for Implementing SAP
    • Questions?