IMS3230 - Information Systems Development Practices

1. IMS3230 - Information Systems Development Practices The traditional SDLC and structured approaches: Structured Analysis

2. The traditional SDLC • Traditional SDLC: basis for many systems development approaches since the 1970s e.g. NCC in the UK proposed a methodology based on the SDLC in the late 1960s • A linear “waterfall” model: Feasibility study System investigation Systems analysis Systems design Implementation Review and maintenance See Avison & Fitzgerald (2003) chap 3

3. The traditional SDLC • Methodologies based on the SDLC have: • A series of phases, subphases, activities etc., defined deliverables • Techniques used in particular phases • Standards for techniques, documentation etc. • Software tools to assist developers e.g. project management, data dictionary, report generators, CASE tools • Training schemes • A philosophy – implied but not stated

4. The traditional SDLC • Techniques: Early: flow charts, organisation charts, grid charts etc. Later: data flow diagramming, ER modelling, normalisation, etc. • Concepts and philosophy of the traditional SDLC approaches influenced and/or evolved into the later approaches such as Structured Analysis, SSADM, Information Engineering, Object-oriented development approaches etc.

5. Traditional SDLC Strengths of the SDLC: • well-tried and tested • provides a base guideline for systems development which can be modified to suit specific requirements • emphasis on project control, documentation, standards, and quality control • useful for building large transaction processing systems and management information systems where requirements are highly structured and well-defined • building complex systems which need rigorous and formal requirements analysis, predefined specifications, and tight control of the system development process

6. Traditional SDLC Limitations of the SDLC: • is resource intensive • a large amount of time spent gathering information and preparing detailed specifications and sign-off documents • could take years to develop a system .. requirements change before the system is operational • is inflexible and inhibits change • output-driven: the time and cost required to repeat activities encourages freezing of specifications early in the development and locks users into something that may no longer be appropriate • top-down, step-by-step approach discourages iteration and evolution of understanding and ideas

7. Traditional SDLC Limitations: • hard to visualize final system • users sign off specification documents without fully understanding their contents or implications • management and strategic needs ignored • decision-making is often unstructured, there are no well-defined models or procedures • routine, low-level processing instead of meeting strategic and corporate objectives

8. Traditional SDLC Limitations: • not well suited to most of the small desktop systems that are common • does not encourage user participation • models based on processes are unstable • focus on technical aspects of problemsituations BUT • SDLC is still being used successfully • Alternative methodologies/approaches do not solve all of these problems • Many systems developed use no methodology (the implications of this????)

9. Structured Analysis • De Marco (1978): Structured Analysis and System Specification • Gane and Sarson (1979): Structured Systems Analysis: Tools and Techniques • STRADIS (Structured Analysis, Design and Implementation of Information Systems) (see Avison and Fitzgerald (2003) Chap 19.1) • Yourdon (1989): Modern Structured Analysis YSM (Yourdon Systems Method) (see Avison and Fitzgerald (2003) Chap 19.2)

10. Structured Analysis • apply the concepts of structured design to systems analysis • process-oriented • functional decomposition to structure the system definition • data flow diagrams (DFDs) to represent system requirements • individual, routine, operational level applications • influential, widely practised • has evolved • emphasis on communication with the users

11. The Structured lifecycle • See DeMarco (1979) for his version • The STRADIS lifecycle: 1. initial study overview DFD of existing system, estimates of time, costs and benefits, report to determine if proceed to next stage 2. detailed study detailed investigation of existing system, current logical DFDs, statement of costs/benefits, impact on staff/procedures

12. The Structured lifecycle • The STRADIS lifecycle continued: 3. defining and designing alternative solutions system objectives, new logical DFDs, alternative design options 4. physical design transform/transaction analysis, normalisation, physical file/DB design, design details of error handling, report and screen formats etc. • implementation not specifically addressed

13. Structured Analysis • the “structured specification” (DeMarco): - a set of fully levelled data flow diagrams - data dictionary - transform descriptions (mini-specs) • characteristics - graphic - non-redundant - maintainable - partitioned - separation of logical and physical - the viewpoint of the data • emphasis on the importance of systems analysis

14. Structured Analysis • the system is a network of processes with data flowing into and out of the processes • levelling of the system's processes: a static view of the system's functional decomposition • top down modelling • postpone consideration of physical implementation details: - man / machine boundary - error routines - initialisation and termination procedures - design of major inputs and outputs - performance targets • transition to design

15. Structured Analysis DeMarco (1979): “classic” structured analysis four stage modelling process: • build a set of current system physical data flow diagrams: (current physical model) • derive a logical equivalent: (current logical model) • incorporate new system requirements identified in the feasibility report: (new logical model) • add physical implementation details to reflect the selected implementation option (new physical model)

16. “classic” Structured Analysis See subphases of structured analysis - DeMarco (1979) • current physical model: a detailed investigation of the current system's operations - determine scope and users affected - interview users - collect sample data types, forms, files, transactions - produce levelled, physical DFDs of current system and data dictionary - user walkthroughs to verify DFDs - publish documentation for user acceptance

17. “classic” Structured Analysis • current logical model - “logicalise” the physical DFDs by removing current implementation details - user walkthroughs to verify the model • new logical model - use the “charter for change” and current logical model - identify the domain of change on bottom-level DFDs - repartition the domain of change - walkthrough with users to verify

18. “classic” Structured Analysis • new physical model: - establish different options for the man/machine boundary - prepare cost / benefit statements for each - users select their preferred option - convert the new logical model into a physical model which reflects the selected implementation option • transition to system design phase where structured design techniques are used

19. “classic” Structured Analysis • emphasis on detailed modelling of the existing system: - “analysis paralysis” - inhibits creative redesign • limited data modelling • no modelling of system behaviour • level of individual applications • for routine, highly structured systems

20. Evolution of structured analysis • Ward and Mellor (1985): Structured Development for Real-Time Systems Yourdon (1986): “Whatever happened to structured analysis?” Yourdon (1989): Modern Structured Analysis • model the “essential” system: - logical model of the new system - no modelling of the current system • model stored data: entity relationship models • model system behaviour: - control flows and control processes - state transition diagrams

21. Modern structured analysis the essential model 1. the environmental model: - context diagram - statement of system's purpose - event list 2. the behavioural model: - event-driven, “middle out” partitioning of processes - entity relationship model - state transitions diagrams (for real time systems) - balance all models - data dictionary (with mini-specs)

22. Modern structured analysis 3. the user implementation model bridge the gap between specification and system design: - document on DFDs the computerisation boundary - allocate subsystems and processes to particular software and hardware environments - design key human/computer interfaces and key error processing routines - consider key physical data design decisions e.g. DBMS - design critical manual procedures transition into systems design

23. References • Prescribed text: Avison, D.E. & Fitzgerald, G. (2003). Information Systems Development: Methodologies, Techniques and Tools. (3rd ed), McGraw-Hill, London. Chapters 3, 19 Refer to additional references in the readings at the unit web page and in the prescribed text