Week 02 Structured Methodologies PDF

System Development Methods CT00046-3-2 Structured Methodologies  SDLC Versus SDM  System Development Life Cycle (SDLC) is a basis of System Development Methodology (SDM).  There are many options of SDM....

System Development Methods CT00046-3-2 Structured Methodologies  SDLC Versus SDM  System Development Life Cycle (SDLC) is a basis of System Development Methodology (SDM).  There are many options of SDM. SDLC SDM People- Structure Agile SDM Oriented d SDM SDM Many Water SSAD V- SCRU WISD XP RAD more. SSM -fall M Model M M. Module Code & Module Title Slide Title SLIDE 2 Slide 2  Topic & Structure of the Lesson 1. Principles of structured methodologies. 2. Phases in Waterfall methodology, Structured Systems Analysis and Design Methodology (SSADM), and V-Model. 3. Strengths and weaknesses of structured methodologies. Module Code & Module Title Slide Title SLIDE 3 Slide 3  Slide 3 (of 17) Learning Outcomes By the end of this lecture, you should be able to : 1. Explain the underlying principles of Structured Methodologies. 2. Describe the phases in Waterfall, Structured Systems Analysis and Design Methodology (SSADM), and V-Model. 3. Identify the strengths and weaknesses of Structured Methodologies. Module Code & Module Title Slide Title SLIDE 4 Slide 4  Slide 4 (of 17) Key Terms you must be able to use If you have mastered this topic, you should be able to use the following terms correctly in your assignment and exam:  Structured Methodologies  Waterfall Methodology  SSADM  V-Model Module Code & Module Title Slide Title SLIDE 5 Slide 5 Slide 5 (of 19) Traditional / Structured Methodologies System development is organized into phases, with deliverables and milestones to measure progress. Developed in the 70’s. Also known as Traditional Methodologies Very detailed steps explained.  The formulation for beginners to develop a system. Requirements need to be clear and fixed. Focus on error free product Rigid and strict rules. Emphasis on full documentation. Example methodologies: Waterfall Model, Structured Systems Analysis and Design Methodology (SSADM), V-Model. Module Code & Module Title Slide Title SLIDE 6 Slide 6  Waterfall Methodology Introduced in the 1970s by Dr. Winston W. Royce. Close to SDLC phases Can be used for almost all types of projects Highly structured and rigid - sequential development process.  One should move to the next phase only when its preceding phase is completed and perfected. Promotes quality control of process and product. Emphasis on good documentation Module Code & Module Title Slide Title SLIDE 7 Slide 7  Waterfall Methodology Phases Requirements Design Implementation Integration & Testing Deployment Maintenance Module Code & Module Title Slide Title SLIDE 8 Slide 8  Waterfall Methodology Phases.. cont.  Requirement Gathering and Analysis – All possible requirements of the system to be developed are captured and documented into System Requirement Specification (SRS) document.  System Design – The SRS is studied, and system design is prepared. – System Design helps in specifying hardware and system requirements and helps in defining overall system architecture.  Implementation – With inputs from system design, the system is first developed in small programs called units, which are integrated into the next phase. – Each unit is developed and tested for its functionality which is referred to as Unit Testing. Module Code & Module Title Slide Title SLIDE 9 Slide 9  Waterfall Methodology Phases.. cont. Integration and Testing – All the units developed in the implementation phase are integrated into a system after testing each unit. – Post integration the entire system is tested for any faults and failures. Deployment −Once the functional and nonfunctional testing is done, the product is deployed in the customer environment or released into the market. Maintenance – Aimed to fix some issues which come up in the client environment. – Also, to enhance the product some better versions are released. Module Code & Module Title Slide Title SLIDE 10 Slide 10  Structured Systems Analysis and Design Methodology (SSADM) Popular methodology used in the late 80s Rigid and document-led approach to system design Good for projects with complex database design. Has strategies to align business needs with system development. Module Code & Module Title Slide Title SLIDE 11 Slide 11  SSADM Phases Decide how viable the project really is. Investigation of current system and provides users with options that meet their requirements. Refine the requirements based on the selected business system option. Evaluation of the best technical products and provides detailed specification. Covers everything needed for construction and Slide Title implementation. Module Code & Module Title SLIDE 12 Slide 12  Project Definition Before a project can begin, we must establish the objectives and the areas of the business which are involved. The need to begin a new project may arise from a variety of causes. For example: – It may be that the existing manual system has proved inadequate to handle a particular set of circumstances, – It may be that the requirements of an entirely new company or department need to be defined and subsequently satisfied. Module Code & Module Title Slide Title SLIDE 13 Slide 13  Project Definition (Cont.) The starting point for a project should be a Project Initiation Document that includes 'terms of reference’. In systems analysis, the terms of reference are usually produced jointly by the client (or user) and the analyst and define: – The objectives and scope of the investigation or project. – The resources available or required and the timescales involved. – Any limitations or constraints Module Code & Module Title Slide Title SLIDE 14 Slide 14  Feasibility Study Once the terms of reference have been defined, it may be necessary to carry out a feasibility study in order to decide how viable the project really is before too many resources are committed. Within a feasibility study, a preliminary investigation, analysis and design are carried out with the aim of: – understanding the operation of the present system and its problems – identifying the requirements for the new system – identifying a range of viable solutions to the problem – identifying the cost/benefit implications involved Module Code & Module Title Slide Title SLIDE 15 Slide 15  Feasibility Study (Cont.) More specifically, the study should embrace the following Overview of the current system (if appropriate) − objectives − outline description of processing − -outline description of input and output data requirements − operational constraints, e.g., volumes of data, timescales for processing, etc. − problems, shortcomings, costs Requirements for the new system − objectives − overview of output, input, processing and data Module Code & Module Title Slide Title SLIDE 16 Slide 16  Feasibility Study (Cont.) Overview of a range of alternative solutions comprising, for each solution: − technical feasibility, i.e., will the proposed hardware and/ /or software be able to solve the problem? − are suitably qualified personnel available to develop the system? − economic feasibility, i.e., how much will the solution cost (hardware, software, staff, training, etc.)? − what are the benefits? can they be quantified (reduction in staff)? − what are the risks of implementing the system (e.g., financial loss)? − what is the cost of not implementing the system? (e.g., loss of competitive edge) − operational feasibility: can the system be developed and implemented within the given timescales? Module Code & Module Title Slide Title SLIDE 17 Slide 17  Feasibility Study (Cont.) Overall recommendation. −other implications. For example, if the system is to hold personal data, is the company registered under the Data Protection Act? or software be able to solve the problem? Module Code & Module Title Slide Title SLIDE 18 Slide 18  Investigation of Current Environment Investigation of the current environment documents the current system (if it exists) and production of a Requirements Catalogue, data model and process model. – Requirements generally consist of a collection of problems which have been identified in the current system, together with a set of requirements for the new system. – As there may be millions of items of data within a small system, it is necessary to simplify the analysis procedure by grouping data relating to the same or similar objects and treating it as a single entity. An entity is an object of the real world about which information is held in a particular system. – Data is moved around the system by processes. These processes may be triggered in several ways ; for example, time, input of data from outside or from another part of the system. Module Code & Module Title Slide Title SLIDE 19 Slide 19  Business System Options Provides User Management with prepared options (Business System Options/BSO) describing the scope and functionality of alternative ways of developing a system to meet their requirements , user and task identification. Describe 'what the system should do' rather than 'how it will do it’. The set of options should be designed to give the user the opportunity to decide what approach should be taken to solve the problems of this part of his business. It is normal for the analyst to produce several options for discussion with the user. The proposed options are chosen, this choice then enables the analyst to proceed with the detailed logical design of the proposed system. Module Code & Module Title Slide Title SLIDE 20 Slide 20  Definition of Requirements Definition of Requirements take the selected Business System Option and refines the requirements catalogue, data and process models expanding the detail into function descriptions and Input/Output structures. The following tasks are carried out and documentation is amended or created to support the development of the required system model. – Defining Required System Processing – Development of Required Data Model – Derive System Functions – Structure Diagrams – Specification Prototypes Module Code & Module Title Slide Title SLIDE 21 Slide 21  Technical System Options Technical system option is the evaluation of the best technical products to meet the requirements specification. This is carried out in parallel with the next phase Logical Design). The options are normally produced in outline from a 'brainstorming' session and consider some aspects, for example: – Will we need processing to be available at more than one point, in which case what levels of processing are needed and where are the processor(s) and terminals going to be located? – Does data need to be passed between sites and, if so, what do we need? – What software will need to be bought and/or developed? the software was able to support adequate response times at peak loading. – What if the production of invoices were not held up due to insufficient printers (or to the lack of a sufficiently large buffer in the printer or printers). Module Code & Module Title Slide Title SLIDE 22 Slide 22  Logical Design Logical Design, (i.e., what the new system will do) providing the detailed specification of processing structures, data and Human Computer Interfaces in the form of dialogues. The three parts of this stage can be carried out in sequence or in parallel, this will depend on the skills and size of the project team. – Dialogue Design: This area of design is important to users as often they see their interaction with the system as synonymous with the functionality of the system. – Define Update Processing: This step completes the specification of the update processing and the associated error handling. – Define Enquiry Process: This step completes the Slide Title Module Code & Module Title SLIDE 23 Slide 23  Physical Design Physical design (i.e., how the new system will work) specifies the physical data, processes, inputs and outputs. It covers everything needed to decide an application's construction and implementation methods. The stage requires expertise in the form of designers, programmers and other specialists. Analysts can specify function components, but experienced designers are required to decide how those components can be implemented. Module Code & Module Title Slide Title SLIDE 24 Slide 24  Physical Design Some tasks in this stage including: – Create Physical Design Strategy: include Processing System Classification, DBMS Data Storage Classification, DBMS Performance Classification. – Overview of Physical Data and Process Design. – Space and Performance: If the previous activities have been completed, the design may need to be modified to meet the required storage and performance objectives. – Physical Process Specification: the logical design products are converted into programs, physical I/O formats and physical dialogue designs that will work in the selected physical environment. Module Code & Module Title Slide Title SLIDE 25 Slide 25  SSADM Design Techniques Logical Data Modeling – To determine the high-level requirement for the system – System components, entities, main process, etc. Data Flow Modeling – To determine the ‘movement’ of data within the system – Data transformation, storage, data flow, etc. Entity Event Modeling – To determine the processes and operations Module Code & Module Title Slide Title SLIDE 26 Slide 26  V-Model Derived and modified from Waterfall Model. After the implementation phase, the phases in the V- Model bent upwards to form the ‘V’ shape. This represents the association between each phase with its testing phase. The horizontal dimension of the V-Model denotes the project completeness (project time). The vertical dimension of the V-Model denotes the multiple levels of the system of interest. The topmost level represents the system context in which the system operates. The bottommost level represents the parts that can be obtained and hence suffice to be defined in a black-box-view. Module Code & Module Title Slide Title SLIDE 27 Slide 27  V-Model Phases Module Code & Module Title Slide Title SLIDE 28 Slide 28  V-Model Phases (Cont.) Concept of Operations Identify goals and objectives of the proposed system, study business strategies and policies to determine system constraints. Study organizations entities, stakeholders, activities, etc. Produce a checklist that contains:  Clear reasons to develop a new system or upgrade the existing system.  Stakeholders and their roles.  Identified internal, external, support, physical and operational environments of the proposed system., etc. Module Code & Module Title Slide Title SLIDE 29 Slide 29  V-Model Phases (Cont.)  Requirements Analysis and Architecture Requirements Analysis: User requirements are collected using requirement engineering techniques i.e., interview, survey, observation, etc. Requirements the documented in a System Requirements Specification (SRS) describing functional and non-functional requirements. System Design: Study the SRS, figure out possibilities and techniques to implement the defined requirements. If any unfeasible requirements, user is informed to discuss the alternative replacements. The software specification document is produced that contains structure of system menu, structure of data, data dictionary, list of business scenarios, test plans, etc. Architecture Design/Physical Design: Includes software architecture, database tables, interface relationships, Module Code & Module Title Slide Title SLIDE 30 Slide 30  V-Model Phases (Cont.)  Detailed/Module Design The proposed system has broken down into smaller and manageable units/modules, then each unit is explained in detail. The detailed design includes database tables with type, size, and constraints, detail interfaces, detail input and output for each module, etc.  Verification and Validation Unit testing: each unit is tested to discover and resolve any defects and bugs. Integration testing: some integrated units will be tested together to discover and resolve any issues in the interfaces and interaction. System testing: aimed to check the overall system meets the specified requirements. User acceptance testing: used by the users to verify the system, to determine whether a system satisfies their Module Code & Module Title Slide Title SLIDE 31 Slide 31  V-Model Phases (Cont.) Operation and Maintenance  Identify best practices for system operations, problem management and support/help desk best practices, release management and quality assurance in system operations, characteristics and best practices for IT asset management, hardware maintenance and hardware monitoring, capacity planning and monitoring activities, maintenance, and service management activities within an organization, etc. Module Code & Module Title Slide Title SLIDE 32 Slide 32  V-Model Techniques Takes the ‘top-down’ development approach – Concept, Architecture Design, high-level design, etc. Verification and Validation at end of each phase / process which can include: 1. Validation of stakeholder requirements 2. Validation of allocated requirements 3. Validation of system element definitions 4. Validation of the virtually integrated system 5. Validation of the operational system deployed into its environment 6. Validation of the in-service system. Use various testing techniques for product – Unit, integration, system, user acceptance, etc. Module Code & Module Title Slide Title SLIDE 33 Slide 33  Strengths with Structured Methodologies (in general) A hierarchical approach tends to generate well- organized systems. Its step-by-step approach (parallel to the system development life cycle). Simplifies project management, risk management, and resource management. Module Code & Module Title Slide Title SLIDE 34 Slide 34  Problems with Structured Methodologies (in general) Rigid phases, discourage skipping of unimportant steps. Emphasize of process and product quality rather than customer satisfaction Requirement need to be defined at the beginning of the project and not encouraged to change towards the end. Too many ‘red-tapes’, wasting time and resources Module Code & Module Title Slide Title SLIDE 35 Slide 35  Summary  Traditional/Structured Methodologies contains detailed steps explained, requirements that need to be clear and fixed, focus on error-free product, rigid and strict rules, and emphasis on full documentation.  The Waterfall methodology can be used for almost all types of projects, is highly structured, and use a sequential development process - one should move to the next phase only when its preceding phase is completed and perfected.  The SSADM is suitable for projects with complex database design, has strategies to align business needs with system development, and ends at the design stage.  The V-Model contains the horizontal dimension that denotes the project completeness (project time) and the vertical dimension that denotes the multiple levels of the system of interest. Besides, verification and validation can be Module Code & Module Title Slide Title SLIDE 36 Slide 36  Question & Answer Module Code & Module Title Slide Title SLIDE 37 Slide 37  Next Session Agile Methods Module Code & Module Title Slide Title SLIDE 38 Slide 38  References Tilley, S. (2019). Systems Analysis and Design 12th Edition. Cengage Learning. ISBN-13: 978- 0357117811. ISBN-10: 0357117816 Pressman, R., & Maxim, B. (2019). Software Engineering: A Practitioner's Approach 9th Edition. McGraw Hill. ISBN-13: 978-1259872976. ISBN-10: 1259872971 Dennis, A., Wixom, B,. & Roth, R.M. (2021). Systems Analysis and Design 8th Edition. Wiley. ISBN: 978-1-119-80378-2 Module Code & Module Title Slide Title SLIDE 39 Slide 39