Blended Methodologies Chapter 21 Blended Methodologies

SSADM SSADM = Structured Systems Analysis and Design Method SSADM (Structured Systems Analysis and Design Methodology) – Highly structured, documented methodology traditionally aimed at well-defined, large-scale systems developments typical of large bureaucracies. While traditionally data driven with an emphasis on data modelling, this has been more recently balanced by greater emphasis on the role of the user. SSADM follows a familiar hard systems approach focused on system feasibility, requirements analysis, requirements specification, logical (functional) design and physical design. The methodology has evolved to become more suited to an ‘integrating’ approach that can accommodate, for example, a SSM front-end. Standard information system development methodology for UK government projects It follows a waterfall approach to information systems development. It is comprehensive and well-tried.

SSADM stages Strategy Planning S Feasibility A D M Analysis Design Feasibility Study Requirement Analysis Analysis Requirement Specification Logical System Specification Design Physical Design Implementation Maintenance

DFD symbols in SSADM

SSADM entity life history constructs

Student entity life history

Merise Merise – A French methodology for used widely for Information System development. Unlike many of the competing methodologies, Merise gives equal weighting to both data and process aspects of systems analysis and design.

Merise Decision cycle Life cycle Abstraction cycle Technical choices regarding hardware and software; Processing choices such as real time or batch; User-oriented choices relating to the user interface; Identification decisions regarding the major actors of the information system and the organization Financial decisions relating to cost and benefit; Management decisions concerning he functionality of the information systems. Merise Decision cycle Life cycle Abstraction cycle Strategic Planning – provides a framework for analyzing and planning the organizations needs; Preliminary Study – describes the proposed information system in terms of impact, cost, benefit and strategy; Detailed Study – detailed functional specification and the functional design; Schedules and other documents – for maintenance, development and implementation LEVEL CONCERN DATA PROCESSING Conceptual What do you want to do? Conceptual data model Conceptual processing model Logical or Organizational Who does what, when, where, how? Logical data model Logical or organizational data model? Physical or Operational By what means? Physical data model Operational processing model http://www.macs.hw.ac.uk/~kdm1/infosys/Merise.doc

Merise: Schema of decision-making process

Merise life cycle Strategic planning (at the corporate level) Preliminary study (for the domain of interest) Detailed study (for a particular project) Schedules and other documentation

Merise by levels of data processing

Merise flow diagram

Conceptual data model (part)

Conceptual processing model

Rules of mapping conceptual processing model to normalised rational model

Information Engineering (IE) IE (Information Engineering) – A data modelling methodology focused on the data-oriented entity-relationship concept. IE has a Rapid Application Development (RAD) version and an Object-Oriented version. IE defines a framework within which a range of techniques is used (typically the best that are currently available for a given task). The methodology places an emphasis on the use of diagrams as a communication and representation tool.     

Information Engineering (IE) Background Martin and Finkelstein (1981), Martin (1989), several versions Data oriented methodology full lifecycle coverage organization-wide perspective on planning of information technology and information systems top-down analysis and development of organization’s applications focus on data and activities well-supported by CASE tools e.g. IEW, IEF has evolved widely used model data requirements first, processes later            (data is more stable)    applications will be integrated by a common data framework

Evolution of IE Data base technology Data analysis and data management Strategic data  models, procedure formation 4GLs and “productivity tools”, e.g. code generators Alignment of information systems planning with strategic business planning Process modelling techniques CASE technology, “encyclopedia”, knowledge coordinator RAD (Rapid Application Development) Object-oriented concepts

Four levels of IE

Information Engineering (IE) Information strategy planning. The objective here is to construct an information architecture and a strategy which supports the overall objectives and needs of the organization. This is conducted at the enterprise level. One part of this planning is the identification of relevant business areas. Business area analysis. The objective here is to understand the individual business areas and determine their system requirements. System planning and design. The objective here is to establish the behaviour of the systems in a way that the user wants and that is achievable using technology. Construction and cutover. The objective here is to build and implement the systems as required by the three previous levels.

Phase 1 - Information Strategy Planning corporate management and planners assess the organization:     business mission, objectives, CSFs, performance measurements, organization structure, current situation construct corporate data model determine major business functions identify business areas, including goals and CSFs determine:  information architecture (global entities and business areas) information systems architecture (business sytems) technical architecture (technology: hw/sw/comms) information strategy plan (priorities)

Phase 2 - Business Area Analysis identify and model in detail the fundamental data and activities required to support a business area ensure that requirements are independent of technology ensure that requirements are independent of current systems and procedures ensure that requirements enable business area’s goals and CSFs to be supported ensure that requirements are independent of the current organisational structure a high-level executive sponsor is necessary

Business area analysis: steps extract the relevant entity relationship model and business-function decomposition models identify relevant departments, locations, business goals, CSFs create a preliminary data model: identify events, entity life cycles, initial attributes create a preliminary process model: decompose the functions into processes model data and processes of existing systems for comparison involve all affected end-users in iteratively building: a detailed data model, a detailed process model, entity / process matrices identify and prioritize system development projects

Business area analysis: techniques Data model         entity relationship modelling        attribute collection         normalisation         canonical synthesis Process model       process decomposition models       process dependency diagrams Data and activity interaction           entity lifecycles            process / entity matrix   

Phase 3 - System Planning and Design Business System Design The purpose of a Business System Design project is to specify all aspects of a system that are relevant to its users, in preparation for the technical design, construction, and installation of one or more closely related databases and systems. The key tasks are therefore structured to produce unambiguous consistent specifications, with the volume of detail necessary to make planning and technical design decisions. Technical Design A Technical Design project prepares an implementation area for construction and installation. The key tasks are structured to produce a system and database that meet the user's acceptance criteria and are technically sound.

System design techniques prototyping detailed process models: procedure design using access path and volumes analysis, dialogue flows and menu structures, physical database design, file design, screen displays menu flows report layouts on-line procedures and software batch procedures and software design verification and testing

Phase 4 – Construction and Cutover     technical design, create physical databases     create modules and programs, unit testing     system testing, documentation  Cutover:     conversion     final testing     conduct training     install the system, review implementation 

IE – data, activity and interaction

IE – divide and conquer approach

Function / entity matrix type - example

Bubble chart

Three user views

Synthises of views 1 and 2

Synthises of all three views

Dialogue flow example

Welti ERP development - 1 As mentioned earlier, there is a trend to buy package software Enterprise Resource Planning (ERP) systems are quite popular (e.g. SAP) Norbert Welti proposed approach for developing ERP projects in 1999 Could be considered an organizational model (more later)

Welti ERP development -2 Planning Decide if organization is prepared to take this step Define scope of project (including locations and departments involved) Allocate resources (staff and external consultants, hard-and software) Suggest objectives and targets (response time, reliability, etc.) Plan detailed activities Set up technical environment Planning Realization Preparation Productive Realization Develop a prototype (reflecting the organization’s processes in the ERP system’s structures) Customize the system Create reports and forms Convert data from legacy systems, prepare interfaces

Welti ERP development - 3 Preparation Develop the final system Do final customizing Integrate modules Perform quality tests Document the system Migrate the data Prepare for changeover Productive Optimize/fine-tune the system Business process re-engineering (BPR)

Project lifecycle – ERP development (Weiti, 1999)

Accelerated SAP Project preparation. This phase sets up the project team and planning for the project. Design business blueprint. This is an outline of the expected SAP system to be implemented. Simulation. In this phase the design and configuration of the ERP system are completed in detail and agreed. Validation. In this phase the planned system is implemented and tested fully. Final preparation. In this phase the interfaces between the ERP modules are written and the system becomes operational. Support. This refers to the ongoing maintenance and upgrading, where necessary, of the ERP system.

References Structured Systems Analysis and Design Method (SSADM) (Downs et al., 1988; Weaver, 1993; Eva, 1994) Merise (Quang and Chartier-Kastler, 1991) Information Engineering (IE) (Martin and Finkelstein, 1981; Martin, 1989) Welti ERP Development (Welti, 1999)

End of Chapter 21 Thank You for Your Attention