CO6031 Systems Analysis for Health Informatics An Introduction to Methodologies

Concepts used for Analysis and Design Methodologies provide guidelines to follow for completing every activity in SDLC Models, whether physical, graphical or mathematical, are used to represent some aspect of the real world e.g DFDs and Gantt charts Tools - usually software support to help create models Techniques - a collection of procedures & guidelines to help analysts complete a systems development activity or task

What is a Methodology? A methodology is a collection of procedures, techniques, tools and documentation aids, supported by a philosophy, which all help the systems developers in their efforts to implement an information system. (Avison & Fitzgerald, 1988) A methodology provides an integrated approach to systems development

Methodology Tools Techniques Models User interviewing techniques CASE tools Project Management applications Word Processors User interviewing techniques Data Modelling techniques Tools Techniques Models Data Flow Diagrams Entity-relationship diagrams Use case diagrams

Systems Development Methodologies A methodology comprises the following. Phases & Sub-phases Techniques & Tools Guidance on how to use the techniques & tools at each stage within a phase or sub-phase Specified deliverables Project Management An all encompassing philosophy

Methodologies Vary widely in: Philosophy Completeness of definition or documentation Coverage of the systems life cycle Type of application to which they are best suited

Why the need for a Methodology? (1) Aspects of early Information Systems In applications development there was a far greater emphasis on programming than on understanding requirements Poor communications between developers and end users Users’ needs were often not properly established  systems developed tended to be inappropriate Projects were generally ill-managed estimated completion dates (if any) were not met

Why the need for a Methodology? (2) Systems were unreliable small changes to one part of the system could cause undesirable effects in other parts of the system Often people who maintained the systems were not those who had developed it Systems were not coherent; different applications did not interact since they were developed independently  redundancy and inconsistency in data Systems might satisfy the needs of individual departments but not the needs of the organisation as a whole

Systems Development Methodologies – Examples (1) SSADM (Structured Systems Analysis and Design Methodology) (IE) Information Engineering STRADIS(Structured Analysis, Design and Implementation of Information Systems) OMT (Object Modelling Technique)

Examples (2) (SSM) Soft Systems Methodology (JSD) Jackson Systems Development ETHICS (Effective Technical and Human Implementation of Computer-based Systems) (YSM) Yourdon Systems Method Merise Euromethod

Systems Development Methodologies The following are not methodologies: UML (Unified Modelling Language) OO (This a software development approach or paradigm) Formal Methods (the use of mathematical precision in specification and design)

Methodology: Advantages The use of methodology helps to: Produce a better quality product (documentation standards, acceptability to the user, maintainability and consistency) Ensure that user requirements are met completely Give the project manager a better control of the project execution and a reduction in overall development costs Promote better communication between project participants Encourage the transmission of know-how throughout the organisation

Methodology: Disadvantages (depending on the Methodology) can be: too restrictive, bureaucratic followed like a cookbook (with potentially disastrous results) too slow to deliver

Evolution of Methodologies Pre-methodology era (-1970s) Early-methodology era (1970s-1980s) SDLC Methodology era methodologies emerged Developed from practice - industry Developed from theory – academia

Background to Methodologies (1) >1000 brand-named methodologies exist world-wide Often Practice-based & developed An organisation practice  commercial product Sometimes theory-based & developed Developed in universities and research centres {commercial product} Most early methodologies relied on one technique or closely related techniques (e.g. entity modelling, DFD)

Background to Methodologies (2) Most methodologies developed into products were : Written up Made consistent Made comprehensive Made marketable Updated as needed Maintained Researched and developed Evolved into training packages Provided with supporting software

Adopting a Methodology Can range from a fully-fledged product to being a vague outline of the basic principles Can cover widely differing areas of the development process, from high level strategic and organisational problem-solving, to the detail of implementing a small information system Can cover just conceptual issues, or physical design procedures, or the whole range of intermediate stages

Adopting a Methodology (2) A methodology also : Can range from being designed to be applicable to specific types of problems in certain types of environments or industries, to being an all-encompassing general-purpose methodology May be potentially usable by anybody, or only by highly trained specialists, (sometimes licensed practitioners) or be designed for users to develop their own applications and systems May require an army of people to perform all the specified tasks, or may not even have any specified tasks May or may not include CASE tools

Factors affecting the suitability of a Methodology Project type (large, small, routine or mission-critical) Control systems, or Information Systems? Application domain (real-time, safety-critical, user-centred, highly interactive, distributed or batch-mode) Nature and level of “maturity” of the IS development organisation: Initial, repeatable, defined, managed, optimised