1. Blended Methodologies
Chapter 21
Blended
Methodologies

2. 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.

3. 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

11. DFD symbols in SSADM

12. SSADM entity life history constructs

13. Student entity life history

14. 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.

15. 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

16. Merise: Schema of decision-making process

17. 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

18. Merise by levels of data processing

19. Merise flow diagram

20. Conceptual data model (part)

21. Conceptual processing model

22. Rules of mapping conceptual processing model to normalised rational model

23. 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.     

24. 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

25. 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

26. Four levels of IE

27. 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.

28. 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)

29. 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

30. 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

31. 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 

32. 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.

33. 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

34. 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 

35. IE – data, activity and interaction

36. IE – divide and conquer approach

37. Function / entity matrix type - example

38. Bubble chart

39. Three user views

40. Synthises of views 1 and 2

41. Synthises of all three views

42. Dialogue flow example

43. 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)

44. 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

45. 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)

46. Project lifecycle – ERP development (Weiti, 1999)

47. 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.

48. 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)

49. End of Chapter 21
Thank
You for Your
Attention