• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Alternative Methodologies for Systems Development
 

Alternative Methodologies for Systems Development

on

  • 866 views

Exploring systems development methodologies: the alternatives.

Exploring systems development methodologies: the alternatives.

Statistics

Views

Total Views
866
Views on SlideShare
866
Embed Views
0

Actions

Likes
0
Downloads
12
Comments
0

0 Embeds 0

No embeds

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

    Alternative Methodologies for Systems Development Alternative Methodologies for Systems Development Presentation Transcript

    • Alternative Methodologies For Systems Development
    • Visualising Systems Paradigms Models vary but there are similarities. These similarities fall into 3 specific areas: • Methods – the techniques used • Tools - both automated and semi automated • Procedures - how the process is managed
    • Structured Systems Analysis and Design Methodology (SSADM) • The most frequently used structured analysis methodology used in the UK and it will be used during this course. • Structured analysis focuses on what the system does rather than how it does it. • This means the emphasis is on the logical rather than the physical, in other words it addresses what the system is meant to accomplish. • It is based on the assumption that the procedures of an organisation are stable, that is they rarely vary, and that the data is stored and used in a way that simply supports those procedures. • The main characteristic of structured analysis is the top down, functional decomposition of the system.
    • Systems Development Life Cycle (SDLC) • This approach is most appropriate to situations where there are predictable Information Systems (IS) requirements. • This includes systems involving the entry of data from input documents, often with high transaction and processing volumes requiring validation of data input. • The SDLC stages can be clearly identified, scheduled, monitored and controlled.
    • The Waterfall Model This approach demands a systemic, sequential approach to software development that begins at system level and progresses through analysis, design, coding, testing and maintenance.
    • Problems with the Waterfall Model 1. Real projects rarely follow the sequential flow that the model suggests; iteration always occurs and this creates problems in the application of this method as it does not allow any steps to be retraced, i.e. the designer can’t go back to the analysis. 2. It is often difficult for the customer/user to state all their requirements explicitly at the start of a project; the waterfall model requires this and has difficulty allowing for the uncertainty that exists at the beginning of many projects. 3. The customer must have patience because a working version of the program will not appear until late in the project.
    • Data Centred Approach (Information Engineering) • This approach takes the view that the structured analysis approach produces a computer system that is rooted in the past. • In this approach data is regarded as a separate resource within an organisation and processes become merely a means of transforming it. • The main problem with this approach is that it can often incur a heavy front end loading, in terms of cost and time, before results are produced. • It’s adherents claim that once the front-end investment has been made systems can be developed more rapidly than with the structured approach.
    • Object-Oriented Approach (O-O) • This methodology in some ways is similar to the data centred approach in that it focuses on the data, however, it is also like the structured analysis approach as it is also concerned with what happens to the data. • The main building block of the O-O approach is the object. An object, in terms of the computer system development, is something from the ‘real world’. • Such objects also have properties, or attributes, that are of interest to the developer of the system. These properties relate to the data found in other approaches. • An object is defined in programming terms as a unit that packages together a set of data items and the knowledge of how to manipulate that data.
    • Unified Modelling Language Car The “class” for this object Engine size Fuel capacity No of passengers Some of the attributes of this object Start () Stop () Forward () Reverse () Some of the operations that this object can perform
    • Benefits of the O-O Approach • More maintainable because the software is not based on the existing functionality of the organisation. • More reliable in terms of being able to re-use tested and proven objects over and over again based on the fact that, with only minor differences, a ‘car’ object in one system will be the same as a ‘car; object in another system. • More able to deal with the increasingly complex systems required now and in the future; complex in terms of size and in the new data types required, especially for Web based applications where the traditional data types are unable to cope with music and video images.
    • Prototyping The “quick and dirty” approach, the method used when no method is used! It is often overlooked as an ‘approach’ as such, being considered to be a ‘poor relation’ to the accepted methodologies. However, it has some undoubted strengths and can be considered as the Human Computer Interface (HCI) version of development. Start Stop Requirements gathering & refining Engineer product Quick design Refine prototype Build prototype Customer evaluation of prototype
    • Soft Systems Methodology (SSM) • The term ‘soft systems’ is used to distinguish this method from the so-called ‘hard systems’ techniques that are used to solve well defined technical problems. In simple terms, a ‘soft’ approach addresses the ‘what’ aspects of system analysis and design while the ‘hard’ approach addresses the ‘how’ aspects of the problem. • The strength of the SSM approach is that it focuses on some real world situation perceived as problematic, such as where the problem situation is unstructured, which is often the case with large and complex organisations, or where user requirements are unclear.
    • Systems Thinking & The Real World
    • CATWOE? • C = Customers Who is on the receiving end? • A = Actors Who are the actors who will 'do the doing', carrying out your solution? • T = Transformation process What is the process for transforming inputs into outputs? • W = World View What is the bigger picture into which the situation fits? • O = Owner Who is the real owner or owners of the process or situation you are changing? • E = Environmental constraints What are the broader constraints that act on the situation and your ideas?
    • Rich Picture