1 / 49

Chapter 21

Chapter 21. Blended Methodologies. SSADM = S tructured S ystems A nalysis and D esign M ethod. SSADM.

beggs
Télécharger la présentation

Chapter 21

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 21 Blended Methodologies

  2. SSADM = Structured Systems Analysis and Design Method SSADM 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 S A D M Feasibility Study Feasibility Requirement Analysis Analysis Requirement Specification Logical System Specification Design Physical Design Implementation Maintenance

  4. DFD symbols in SSADM

  5. SSADM entity life history constructs

  6. Student entity life history

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

  8. 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. • 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 http://www.macs.hw.ac.uk/~kdm1/infosys/Merise.doc

  9. Merise: Schema of decision-making process

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

  11. Merise by levels of data processing

  12. Merise flow diagram

  13. Conceptual data model (part)

  14. Conceptual processing model

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

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

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

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

  19. Four levels of IE

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

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

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

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

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

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

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

  27. Phase 4 – Construction and Cutover • Construction: •     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 

  28. IE – data, activity and interaction

  29. IE – divide and conquer approach

  30. Function / entity matrix type - example

  31. Bubble chart

  32. Three user views

  33. Synthises of views 1 and 2

  34. Synthises of all three views

  35. Dialogue flow example

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

  37. Planning Realization Preparation Productive 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 Welti ERP development -2 • 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

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

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

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

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

  42. End of Chapter 21 Thank You for Your Attention

More Related