Information and Communication Technology ICT Structured Systems Analysis

Information and Communication Technology (ICT)

Structured Systems Analysis And Design Method (SSADM)

Structured Systems Analysis And Design Method (SSADM) Structured systems analysis and design methodology (SSADM) is a set of standards for systems analysis and application design. It uses a formal methodical approach to the analysis and design of information systems. The SSADM is an open methodology based on the waterfall model. It has been used by many commercial businesses, consultants, educational establishments and CASE tool developers.

Structured Systems Analysis And Design Method (SSADM) SSADM follows the waterfall life cycle model starting from the feasibility study to the physical design stage of development. One of the main features of SSADM is the intensive user involvement in the requirements analysis stage. The techniques used in SSADM are logical data modeling, data flow modeling

Structured Systems Analysis And Design Method (SSADM)

Analytical Tools �Business Activity Modeling �Business activity model �Data Flow Modeling (DFM) �Data Flow Diagrams (DFD) �Elementary Process Descriptions (EPD) �Logical Data Modeling (LDM) �Logical Data Structure (LDS) Business System Options (BSO)

Analytical Tools Business Activity Modeling A start-off technique for understanding what’s going on in the system under investigation. It is used to show the business activities that the actors in the system’s environment do and their associations.

Business System Options (BSO) BSO describes what the system will do. Each BSO must satisfy the minimum system requirements and consists of a functional description, a high-level technical description, major benefits to the business, approximate cost estimate, development time scale and impact on organization and other existing systems.

Logical vs Physical Data Flow Diagrams Data flow diagrams (DFDs) are categorized as either logical or physical. A logical DFD focuses on the business and how the business operates. It describes the business events that take place and the data required and produced by each event. On the other hand, a physical DFD shows how the system will be implemented.

Logical vs Physical Data Flow Diagrams Logical DFD (Logical Data Flow Modeling (Logical DFM) • Logical DFD depicts how the business operates. • The processes represent the business activities. • The data stores represent the collection of data regardless of how the data are stored. • It s how business controls.

Physical DFD (Physical Data Flow Modeling /PDM) • Physical DFD depicts how the system will be implemented (or how the current system operates). • The processes represent the programs, program modules, and manual procedures. • The data stores represent the physical files and databases, manual files. • It show controls for validating input data, for obtaining a record, for ensuring successful completion of a process, and for system security.

Logical DFM of the proposed system • Starts from elementary processes • As location of a process only indicates a physical constraint, removes it from all processes • As the person who actually did a process in physical DFM now feeds inputs to the corresponding process in the logical DFM, transforms the location into an external entity • Removes any purely human activity and replaces it with an external entity • Adds new processes required to support any new functionalities of the proposed system • Reconstructs the hierarchy by regrouping logical processes based on their functionality • Describes the functionality of elementary processes in pseudo code and write EPD

Physical Design of Database Maps logical schema to relational schema • normalizes all the relations in relational schema to 3 NF • tabulates a Table Specification and a Record Specification for each relation in the normalized relational schema • provides physical design for the construction of the database

Object-Oriented Methodology The main difference between object-oriented analysis and other forms of analysis is that in object-oriented approach, requirements are organized around objects, which integrate both data and functions. They are modelled after real-world objects that the system interacts with. In traditional analysis methodologies, the two aspects - functions and data - are considered separately.

Object-Oriented Methodology The primary tasks in object-oriented analysis (OOA) are Identifying objects Organizing the objects by creating object model diagram Defining the internals of the objects, or object attributes Defining the behavior of the objects, i. e. , object actions Describing how the objects interact

Data Dictionary • Is an integral part of database • • Holds information about the database and the data that it stores (data about data - metadata) • Contains the actual database descriptions used by the Database Management System (DBMS)

Data Dictionary E. g

Software Testing Involves executing an implementation of the software with test data examine the output of the software and its operational behavior to check that is performing as required. Testing is a dynamic technique because it works with an executable section of the system.

What is a test case? • A test case is a set of actions executed to verify a particular feature or functionality of a software application. • Test cases are documented by the Quality Assurance team while the software development is going on.

Software testing techniques White box testing Black box testing Unit Testing Integrated testing System testing Acceptance testing

White box testing Takes internal implementation of a software to derive test cases to test the software Performed in the early stages of the testing process Usually applied for testing relatively small program units Analysis of the program code determines how many test cases are required to exercise all the internal components of the software (statements, branches, paths) adequately

White box testing Using white box testing methods, the software engineer can derive test cases that: All independent paths within the module is tested All logical paths are driven on true and false sides All loops tested at their boundaries All internal data structures are tested for validity.

Black box Testing • software to be tested is treated as a black box and its behavior is examined by studying the inputs and outputs • knowing the intended functionalities of a software, tests are conducted to see whether the software can deliver them • test cases are derived from the requirement specification of the software to be tested

Black box Testing Black box is not an alternative to white box testing , it is a complementary approach that uncovers a different class or errors. Incorrect or missing functions Interface errors Errors in data structures or external database access Behavior of performance errors Initialization and termination errors

Quizz

Please write down this note and complete the writing book (ICT book)