Slides week 3


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Slides week 3

  1. 1. <ul><li>Structured Systems Analysis and Design Method (SSADM); </li></ul><ul><li>Information Engineering </li></ul><ul><li> </li></ul><ul><li> </li></ul>IMS5006 - Information Systems Development Practices
  2. 2. Structured Systems Analysis and Design Method (SSADM) <ul><li>A comprehensive and structured approach to systems development </li></ul><ul><li>A “baseline” for comparison and evaluation of other methodologies and for themes in systems development </li></ul><ul><li>The true successor to the traditional SDLC approach with new techniques and tools developed since the 1970s </li></ul>
  3. 3. <ul><li>assumptions about information systems: </li></ul><ul><ul><li>relatively stable </li></ul></ul><ul><ul><li>routine processing, well-defined interaction </li></ul></ul><ul><ul><li>free-standing, developed from &quot;scratch&quot; </li></ul></ul><ul><ul><li>globally defined data, processes </li></ul></ul><ul><ul><li>complete and objectively definable </li></ul></ul><ul><ul><li>information is well-structured </li></ul></ul>Structured Systems Analysis and Design Method (SSADM)
  4. 4. <ul><li>assumptions about information systems development: </li></ul><ul><ul><li>essentially a linear process </li></ul></ul><ul><ul><li>users know their current and future needs </li></ul></ul><ul><ul><li>conceptual descriptions can be complete </li></ul></ul><ul><ul><li>in the early lifecycle stages, system structure is more important than system behaviour </li></ul></ul><ul><ul><li>specification techniques should be simple and graphical for users to understand easily </li></ul></ul>Structured Systems Analysis and Design Method (SSADM)
  5. 5. <ul><li>assumptions about information systems, systems development and the system developer’s roles: </li></ul><ul><ul><li>system developer is the “expert” who has the technical knowledge to provide a solution </li></ul></ul><ul><ul><li>system developer “owns” the methodology and controls the development process </li></ul></ul><ul><ul><li>users have the business knowledge and must work with/support system developers as necessary to ensure requirements are met </li></ul></ul><ul><ul><li>users will own the system, must sign off </li></ul></ul>Structured Systems Analysis and Design Method (SSADM)
  6. 6. SSADM <ul><li>developed by LBMS and Central Computing and Telecommunications Agency (CCTA) in the UK </li></ul><ul><li>accepted by CCTA in January 1981 as the standard approach within the UK civil service </li></ul><ul><li>requirements: documentation </li></ul><ul><ul><ul><li>self-checking </li></ul></ul></ul><ul><ul><ul><li>tried and tested techniques </li></ul></ul></ul><ul><li>tailorable </li></ul><ul><li>teachable </li></ul>
  7. 7. SSADM <ul><li>mature, widely used in UK in particular </li></ul><ul><li>typically medium to large projects </li></ul><ul><li>“ data-driven” due to emphasis originally on data modelling and database technology </li></ul><ul><li>later versions are more balanced: </li></ul><ul><li>role of users emphasised </li></ul><ul><li>importance of processes and functions </li></ul><ul><li>version 4 in 1990 </li></ul><ul><li>earlier version has 6 stages (Downs, Clare and Coe 1988) </li></ul><ul><li>version 4 has 7 stages (Avison and Fitzgerald 2003) </li></ul>
  8. 8. SSADM <ul><li>highly structured </li></ul><ul><li>facilitates project management </li></ul><ul><li>documentation “pervades” SSADM </li></ul><ul><li>e.g. completion of preprinted forms </li></ul><ul><li>stages and their activities are precisely defined as are their associated deliverables </li></ul>
  9. 9. SSADM <ul><li>prescriptive </li></ul><ul><li>reductionist </li></ul><ul><li>comprehensive </li></ul><ul><li>has evolved with use: versions, CASE tool </li></ul><ul><li>templates e.g. micro SSADM, maintenance SSADM </li></ul><ul><li>SDLC phases: feasibility, systems analysis, system design </li></ul><ul><li>focus on functional and technical aspects </li></ul>
  10. 10. SSADM phases <ul><li>earlier version - Downs, Clare and Coe 1988: three phases </li></ul><ul><li>1. feasibility study </li></ul><ul><li>examine the business and technical feasibility of the project </li></ul><ul><li>2. systems analysis </li></ul><ul><li>analyse the current system and problems, identify new requirements and technical options </li></ul><ul><li>3. systems design </li></ul><ul><li>logical data and process design, physical design </li></ul>
  11. 11. SSADM phases and stages <ul><li>1. feasibility study </li></ul><ul><li>stage 01: problem definition </li></ul><ul><li>stage 02: project identification </li></ul><ul><li>2. systems analysis </li></ul><ul><li>stage 1: analysis of systems operations & current problems </li></ul><ul><li>stage 2: specification of requirements </li></ul><ul><li>stage 3: selection of technical options </li></ul><ul><li>3. systems design </li></ul><ul><li>stage 4: data design </li></ul><ul><li>stage 5: process design </li></ul><ul><li>stage 6: physical design (Downs et al 1988) </li></ul>
  12. 12. SSADM <ul><li>characteristics Downs, Clare and Coe 1998 </li></ul><ul><li>hierarchical structure: </li></ul><ul><li>phases, stages, steps, tasks, techniques </li></ul><ul><li>data driven design </li></ul><ul><li>cross-checking </li></ul><ul><li>separation of logical and physical </li></ul><ul><li>tailorable </li></ul><ul><li>user communication </li></ul><ul><li>quality assurance </li></ul><ul><li>documentation standards </li></ul>
  13. 13. SSADM techniques <ul><li>Downs, Clare and Coe 1988 </li></ul><ul><li>data flow diagrams </li></ul><ul><li>logical data structuring (LDST) </li></ul><ul><li>entity life histories </li></ul><ul><li>dialogue design </li></ul><ul><li>relational data analysis (RDA) </li></ul><ul><li>composite logical data design (CLDD) </li></ul><ul><li>process outlines </li></ul><ul><li>system flow charts </li></ul>
  14. 14. SSADM: other SDLC phases <ul><li>construction and implementation: </li></ul><ul><li>output of physical design can interface with </li></ul><ul><li>1. traditional programming (JSP) </li></ul><ul><li>2. application generators </li></ul><ul><li>3. application packages </li></ul><ul><li>prototyping can be used in design and construction </li></ul><ul><li>automated support tools are available </li></ul><ul><li>a project management methodology can be used </li></ul><ul><li>organisational IT/ IS planning: </li></ul><ul><li>use a planning methodology </li></ul><ul><li>e.g. LEAP developed by LBMS </li></ul>
  15. 15. SSADM: later versions <ul><li>version 4 - Avison and Fitzgerald 2003: five phases, seven stages </li></ul><ul><li>feasibility study </li></ul><ul><li>0 Feasibility </li></ul><ul><li>requirements analysis </li></ul><ul><li>1 Investigation of current environment </li></ul><ul><li>2 Business system options </li></ul><ul><li>requirements specification </li></ul><ul><li>3 Definition of requirements </li></ul><ul><li>logical system specification </li></ul><ul><li>4 Technical system options </li></ul><ul><li>5 Logical design </li></ul><ul><li>physical design </li></ul><ul><li>6 Physical design </li></ul>
  16. 16. SSADM version 4: Feasibility Study <ul><li>ensure the project identified in planning phase is feasible </li></ul><ul><li>(= technically possible) and benefits > costs </li></ul><ul><li>prepare for the study (assess the scope) </li></ul><ul><li>define the problem (compare requirements with current situation) </li></ul><ul><li>identify and select feasibility option (consider broad alternatives in terms of business requirements and technical options) </li></ul><ul><li>produce feasibility report </li></ul><ul><li>techniques: interviewing, document review etc., broad DFDs and ER model </li></ul>
  17. 17. SSADM version 4: Requirements Analysis <ul><li>1 Investigation of current environment </li></ul><ul><li>detailed physical DFDs and ER model of current processing and data, </li></ul><ul><li>logical DFDs, functional and non-functional “requirements catalogue”, </li></ul><ul><li>scope and feasibility study results re-examined </li></ul><ul><li>2 Business system options </li></ul><ul><li>cost-justified requirements only, determine and agree on functionality, </li></ul><ul><li>business options meeting minimum requirements: cost, technical constraints, development schedule, benefits and impact, training, etc. </li></ul>
  18. 18. SSADM version 4: Requirements Specification <ul><li>3 Definition of requirements </li></ul><ul><li>logical data model (ER) extended, </li></ul><ul><li>attribute collection and normalisation, </li></ul><ul><li>DFDs extended, </li></ul><ul><li>full documentation of all data, processes and events, </li></ul><ul><li>entity life history diagrams, </li></ul><ul><li>prototyping can be used for important dialogues and menu structures </li></ul>
  19. 19. SSADM version 4: Logical System Specification <ul><li>These stages occur in parallel: </li></ul><ul><li>4 Technical system options </li></ul><ul><li>environment in which system will operate - hardware, software, contraints (e.g. performance, security, service levels) </li></ul><ul><li>5 Logical design </li></ul><ul><li>design what the system is required to do </li></ul><ul><li>user involvement, refer to any prototypes, define dialogues and menu structures for specific user roles, ELHs used to define update and enquiry processing, data validation rules etc. </li></ul>
  20. 20. SSADM version 4: Physical Design <ul><li>map the logical design onto a specific physical environment: functional component implementation map (FCIM) </li></ul><ul><li>6 Physical design </li></ul><ul><li>roles of the technologists stressed </li></ul><ul><li>users and analysts verify final design satisfies user requirements, </li></ul><ul><li>convert data model, specify programs, procedures etc. </li></ul><ul><li>specific activities depend on specific environment (system type, size, technical platform etc. </li></ul><ul><li>SSADM ends: subsequent activities build, test and install the system </li></ul>
  21. 21. SSADM <ul><li>a structured approach: well-defined structure for its use, for training, and for managing projects </li></ul><ul><li>supported by CASE tools </li></ul><ul><li>clearly defined deliverables and quality review checkpoints </li></ul><ul><li>relies on availability of skilled personnel </li></ul><ul><li>systems development is about providing technical solutions to business problems </li></ul>
  22. 22. Information Engineering <ul><li>Martin and Finkelstein (1981), Martin (1989), several versions </li></ul><ul><li>data oriented methodology </li></ul><ul><li>full lifecycle coverage </li></ul><ul><li>organisation-wide perspective on planning of information technology and information systems </li></ul><ul><li>top-down analysis and development of organisation’s applications </li></ul><ul><li>focus on data and activities </li></ul><ul><li>well-supported by CASE tools e.g. IEW, IEF </li></ul><ul><li>has evolved </li></ul><ul><li>widely used </li></ul>
  23. 23. <ul><li>evolution </li></ul><ul><li>data base technology </li></ul><ul><li>data analysis and data management </li></ul><ul><li>strategic data models, procedure formation </li></ul><ul><li>4GLs and “productivity tools”, e.g. code generators </li></ul><ul><li>alignment of information systems planning with strategic business planning </li></ul><ul><li>process modelling techniques </li></ul><ul><li>CASE technology, “encyclopedia”, knowledge coordinator </li></ul><ul><li>RAD (Rapid Application Development) </li></ul><ul><li>object-oriented concepts </li></ul>Information Engineering
  24. 24. <ul><li>data centred: </li></ul><ul><li>model data requirements first, processes later </li></ul><ul><li>(data is more stable) </li></ul><ul><li>applications will be integrated by a common data framework </li></ul><ul><li>information engineering: </li></ul><ul><li>“ an interlocking set of formal techniques in which enterprise models, data models and process models are built... and are used to create and maintain data processing systems” </li></ul><ul><li> James Martin (1986) </li></ul><ul><li>use of diagrams as a communication and representation tool </li></ul>Information Engineering
  25. 25. <ul><li>information strategy planning </li></ul><ul><li>to build an information and technology architecture to support business strategy and objectives </li></ul><ul><li>business area analysis </li></ul><ul><li>to identify data and function requirements of each business area </li></ul><ul><li>individual systems planning </li></ul><ul><li>systems design </li></ul><ul><li>to complete logical specifications for a system and convert these into physical design specifications </li></ul><ul><li>construction </li></ul><ul><li>to generate code, test, and install the system </li></ul><ul><li>cutover </li></ul>Major phases of Information Engineering
  26. 26. Phase 1 - information strategy planning: <ul><li>corporate management and planners assess the organisation: </li></ul><ul><li>business mission, objectives, CSFs, performance measurements, organisation structure, current situation </li></ul><ul><li>construct corporate data model </li></ul><ul><li>determine major business functions </li></ul><ul><li>identify business areas, including goals and CSFs </li></ul><ul><li>determine: </li></ul><ul><li>information architecture (global entities and business areas) </li></ul><ul><li>information systems architecture (business sytems) </li></ul><ul><li>technical architecture (technology: hw/sw/comms) </li></ul><ul><li>information strategy plan (priorities) </li></ul>
  27. 27. Phase 2 - business area analysis: <ul><li>identify and model in detail the fundamental data and activities required to support a business area </li></ul><ul><li>ensure that requirements are independent of technology </li></ul><ul><li>ensure that requirements are independent of current systems and procedures </li></ul><ul><li>ensure that requirements enable business area’s goals and CSFs to be supported </li></ul><ul><li>ensure that requirements are independent of the current organisational structure </li></ul><ul><li>a high-level executive sponsor is necessary </li></ul>
  28. 28. Business area analysis: steps <ul><li>extract the relevant entity relationship model and business-function decomposition models </li></ul><ul><li>identify relevant departments, locations, business goals, CSFs </li></ul><ul><li>create a preliminary data model: identify events, entity life cycles, initial attributes </li></ul><ul><li>create a preliminary process model: decompose the functions into processes </li></ul><ul><li>model data and processes of existing systems for comparison </li></ul><ul><li>involve all affected end-users in iteratively building: </li></ul><ul><li>a detailed data model, a detailed process model, entity / process matrices </li></ul><ul><li>identify and prioritise system development projects </li></ul>
  29. 29. Business area analysis: techniques <ul><li>data model </li></ul><ul><li>entity relationship modelling </li></ul><ul><li>attribute collection </li></ul><ul><li>normalisation </li></ul><ul><li>canonical synthesis </li></ul><ul><li>process model </li></ul><ul><li>process decomposition models </li></ul><ul><li>process dependency diagrams </li></ul><ul><li>data and activity interaction </li></ul><ul><li>entity lifecycles </li></ul><ul><li>process / entity matrix </li></ul>
  30. 30. Information engineering: phases 3 and 4 <ul><li>Phase 3 - individual systems planning </li></ul><ul><li>use JRP for individual systems planning </li></ul><ul><li>Phase 4 - system design: </li></ul><ul><li>concerned with how selected processes in the business are implemented in procedures and how these procedures work </li></ul><ul><li>use the logical data and process models to design the external representations of the system </li></ul><ul><li>direct end-user involvement is essential </li></ul><ul><li>identify reusable procedures </li></ul><ul><li>use prototyping </li></ul><ul><li>use JAD </li></ul>
  31. 31. System design techniques <ul><li>prototyping </li></ul><ul><li>detailed process models: procedure design using access path and volumes analysis, dialogue flows and menu structures, </li></ul><ul><li>physical database design, file design, </li></ul><ul><li>screen displays </li></ul><ul><li>menu flows </li></ul><ul><li>report layouts </li></ul><ul><li>on-line procedures and software </li></ul><ul><li>batch procedures and software </li></ul><ul><li>design verification and testing </li></ul>
  32. 32. <ul><li>Phase 5 - construction: </li></ul><ul><li>technical design, create physical databases </li></ul><ul><li>create modules and programs, unit testing </li></ul><ul><li>system testing, documentation </li></ul><ul><li>Phase 6 - cutover: </li></ul><ul><li>conversion </li></ul><ul><li>final testing </li></ul><ul><li>conduct training </li></ul><ul><li>install the system, review implementation </li></ul>Information engineering: phases 5 and 6
  33. 33. Information Engineering <ul><li>features: </li></ul><ul><li>organisation-wide perspective aligned with strategic business planning </li></ul><ul><li>comprehensive </li></ul><ul><li>emphasis on user involvement e.g. JAD, JRP </li></ul><ul><li>evolves by incorporating new techniques, concepts, technologies e.g. RAD, object-oriented concepts </li></ul><ul><li>evolves from practice e.g. shortened ISP phase </li></ul><ul><li>emphasis on automation e.g. 4GLs, I-CASE, prototypes </li></ul><ul><li>primarily for database transaction processing systems </li></ul><ul><li>little event or behaviour modelling </li></ul>
  34. 34. <ul><li>features: </li></ul><ul><li>after ISP phase, activities can proceed in parallel </li></ul><ul><li>high level data and process model (co-ordinating model) enables this by highlighting interfaces and dependencies between systems etc. </li></ul><ul><li>flexible paths through the methodology </li></ul><ul><li>e.g. reverse engineering and re-engineering </li></ul>Information Engineering
  35. 35. References <ul><li>Prescribed text: </li></ul><ul><li>Avison, D.E. & Fitzgerald, G. (2003). </li></ul><ul><li>Information Systems Development: </li></ul><ul><li>Methodologies, Techniques and Tools. (3rd ed), McGraw-Hill, London. </li></ul><ul><li>Chapters 20.1, 20.3 </li></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.