Chapter 1: Quick Revision of System/Software Analysis and Design Tools

Chapter 1: Quick Revision of System/Software Analysis and Design Tools
Modern Systems Analysis and Design Chapter 1: Quick Revision of System/Software Analysis and Design Tools

System/Software Analysis and Design Tools

Software Analysis and Design Tools
Software analysis and design includes all activities, which help the transformation of requirement specification into implementation. Requirement specifications specify all functional and non-functional expectations from the software. These requirement specifications come in the shape of human readable and understandable documents. Software analysis and design is the intermediate stage, which helps human-readable requirements to be transformed into actual code.

1- Data Flow Diagram (DFD)

1- DFD Data flow diagram is graphical representation of flow of data in an information system. It is capable of depicting incoming data flow, outgoing data flow and stored data. There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of control in program modules. DFDs depict flow of data in the system at various levels.

1- DFD Types of DFD Logical DFD - This type of DFD concentrates on the system process, and flow of data in the system. For example in a Banking software system, how data is moved between different entities. Physical DFD - This type of DFD shows how the data flow is actually implemented in the system. It is more specific and close to the implementation.

1- DFD DFD Components DFD can represent Source, destination, storage and flow of data using the following set of components - Entities - Entities are source and destination of information data. Entities are represented by a rectangles with their respective names. Process - Activities and action taken on the data are represented by Circle or Round-edged rectangles.

1- DFD DFD Components DFD can represent Source, destination, storage and flow of data using the following set of components - Data Storage - There are two variants of data storage - it can either be represented as a rectangle with absence of both smaller sides or as an open-sided rectangle with only one side missing. Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from the base of arrow as its source towards head of the arrow as destination.

1- DFD Levels of DFD Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire information system as one diagram concealing all the underlying details. Level 0 DFDs are also known as context level DFDs.

1- DFD Levels of DFD Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1 DFD depicts basic modules in the system and flow of data among various modules. Level 1 DFD also mentions basic processes and sources of information.

1- DFD Levels of DFD Level 2 - At this level, DFD shows how data flows inside the modules mentioned in Level 1. Higher level DFDs can be transformed into more specific lower level DFDs with deeper level of understanding unless the desired level of specification is achieved.

2- Structure Charts

2- Structure Charts Structure chart is a chart derived from Data Flow Diagram. It represents the system in more detail than DFD.

2- Structure Charts It breaks down the entire system into lowest functional modules, describes functions and sub-functions of each module of the system to a greater detail than DFD.

2- Structure Charts Structure chart represents hierarchical structure of modules. At each layer a specific task is performed.

2- Structure Charts Module - It represents process or subroutine or task. A control module branches to more than one sub-module. Library Modules are re-usable and invokable from any module.

2- Structure Charts Condition - It is represented by small diamond at the base of module. It depicts that control module can select any of sub-routine based on some condition.

2- Structure Charts Jump - An arrow is shown pointing inside the module to depict that the control will jump in the middle of the sub-module.

2- Structure Charts Loop - A curved arrow represents loop in the module. All sub-modules covered by loop repeat execution of module.

2- Structure Charts Data flow - A directed arrow with empty circle at the end represents data flow.

3- HIPO Diagram

3- HIPO Diagram Hierarchical Input Process Output It is a diagram It is a combination of two methods / parts Hierarchical (H) part and IPO part HIPO model was developed by IBM in year 1970.

3- HIPO Diagram HIPO diagrams are good for documentation purpose. Their graphical representation makes it easier for designers and managers to get the pictorial idea of the system structure.

Hierarchical Part 3- HIPO Diagram

IPO Part 3- HIPO Diagram

3- HIPO Diagram Both parts of HIPO diagram, Hierarchical presentation and IPO Chart are used for structure design of software program as well as documentation of the same.

4- Structured English

4- Structured English Graphs or diagrams, may are sometimes interpreted differently by different people. Hence, analysts and designers of the software come up with tools such as Structured English. It is nothing but the description of what is required to code and how to code it.

4- Structured English Structured English helps the programmer to write error-free code. It uses plain English words. It is not the ultimate code but a kind of description what is required to code and how to code it.

4- Structured English Example Customer Authentication in the online shopping environment:

4- Structured English The code written in Structured English is more like day-to-day spoken English. It can not be implemented directly as a code of software. Structured English is independent of programming language.

5- Pseudo Code

5- Pseudo Code Pseudo code is written more close to programming language. It may be considered as augmented programming language, full of comments and descriptions.

5- Pseudo Code It is written using some actual programming language’s constructs, like Jave, C, Fortran, etc. Pseudo code contains more programming details than Structured English. It provides a method to perform the task, as if a computer is executing the code.

5- Pseudo Code

6- Decision Tables

6- Decision Tables A Decision table represents conditions and the respective actions to be taken to address them, in a structured tabular format. It is a powerful tool to debug and prevent errors. It helps group similar information into a single table

6- Decision Tables Creating Decision Table To create the decision table, the developer must follow basic four steps: Identify all possible conditions to be addressed Determine actions for all identified conditions Create Maximum possible rules Define action for each rule

6- Decision Tables Example: “Withdrawal (from ATM) is granted if requested amount is covered by the balance OR if the customer is granted credit to cover the withdrawal amount”. Two conditions: “withdrawal amount ≤ balance” and “credit granted” One Action: “Withdrawal is granted” Ref:

6- Decision Tables Example: Step 1 – Analyze the requirement and create the first column Ref:

6- Decision Tables Example: If there are two conditions and each condition can be either true or false, you need 4 columns. If there are three conditions there will be 8 columns and so on. Mathematically, the number of columns is 2 conditions. In this case 22 = 4 columns. Step 2 – Add Columns Ref:

6- Decision Tables Example: Now fill in the T and F for the conditions. How? Row 1: TF, Row 2: TTFF, Row 3: TTTTFFFF For each row, there is twice as many T and F as the previous line. Repeat the pattern above from left to right for the entire row. In other words, for a table with 8 columns, the first row will read TFTFTFTF, the second row will read TTFFTTFF and the third row will read TTTTFFFF. Step 2 – Add Columns

6- Decision Tables Example: Step 2 – Add Columns

6- Decision Tables Example: Mark insignificant values with “-”. If the requested amount is less than or equal to the account balance it does not matter if credit is granted. Step 3 – Reduce the Table

6- Decision Tables Example: Remove duplicate columns. In this case, the 1st and 3rd column are equal, therefore one of them is removed. Step 3 – Reduce the Table

6- Decision Tables Example: Enter actions for each column in the table. Name the columns (the rules). They may be named R1/Rule 1, R2/Rule 2 and so on, but you can also give them more descriptive names. Step 4 – Determine Actions

6- Decision Tables Example: Test case for R1: balance = 200, requested withdrawal = 200. Expected result: withdrawal granted. Test case for R2: balance = 100, requested withdrawal = 200, credit granted. Expected result: withdrawal granted. Test case for R3: balance = 100, requested withdrawal = 200, no credit. Expected Result: withdrawal denied. Step 5 – Write Test Cases

7- Entity Relationship Model

7- Entity Relationship Model It is a type of database model based on the notion of real world entities and relationship among them. We can map real world scenario onto ER model. ER Model is best used for the conceptual design of database.

7- Entity Relationship Model ER Model creates a set of entities with their attributes, a set of constraints and relation among them. ER Model can be represented as follows:

7- Entity Relationship Model Entity - An entity in ER Model is a real world being, which has some properties called attributes. For example, Consider a school database. Here, a student is an entity. Student has various attributes like name, id, age and class etc.

7- Entity Relationship Model Relationship - The logical association among entities is called relationship. Relationships are mapped with entities in various ways. Mapping cardinalities define the number of associations between two entities.

7- Entity Relationship Model Mapping cardinalities: one to one one to many many to one many to many

8- Data Dictionary

8- Data Dictionary Data dictionary is the centralized collection of information about data. It stores meaning and origin of data, its relationship with other data, data format for usage etc. Data dictionary is often referenced as meta-data (data about data) repository. * A data dictionary is a table providing a comprehensive description of each field in the database. * (same ref for next slides)

8- Data Dictionary Data dictionaries describe the characteristics of data including: field name: the name of the field as it appears in the database. data type: includes text, number, date, currency, yes/no (Boolean). data format: any special formatting applied to the field; e.g. number of decimal places in number fields, short, medium and long date and time formats. field size: the number of characters allowed for a given field. description: a simple description of field contents.

8- Data Dictionary

9- Storyboards

9- Storyboards It describes various interfaces (screens) present in a system as well as the links between them. The representation of each interface should be detailed enough for the reader to identify the purpose, contents and design elements. Areas used for input, output and navigation should be clearly identified and labeled.

9- Storyboards Any links shown between interfaces should originate from the navigational element that triggers the link. Storyboards can be used in a variety of contexts. They can show the relationship between data entry screens in a database, or slides in a presentation, or pages in a website.

Storyboards

Difference between: “Wireframe, Storyboard and Prototype”

Wireframe: a blueprint
of a single page

Storyboards: A series of wireframes next to each other.

Prototype: Representation of all or part of a product or system that, although limited in some way, can be used for Evaluation (ISO 9241 part 210)

Difference between: “Wireframe, Storyboard and Prototype” So in this sense a wireframe and a storyboard both can be prototypes, because you can use both for evaluation (testing with users to get feedback).

Difference between: “Wireframe, Storyboard and Prototype”

References

Chapter 1: Quick Revision of System/Software Analysis and Design Tools

Similar presentations

Presentation on theme: "Chapter 1: Quick Revision of System/Software Analysis and Design Tools"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Chapter 1: Quick Revision of System/Software Analysis and Design Tools

Similar presentations

Presentation on theme: "Chapter 1: Quick Revision of System/Software Analysis and Design Tools"— Presentation transcript:

Similar presentations

About project

Feedback