1 of 49

Structured Analysis

by Ronni Kahalani, Copenhagen School of Design & Technology.

With inspiration from the book Software Engineering - A Practitioner's Approach.

Zoom in/out based Context- and Data Flow diagrams,

which complexity is measured in function points.

2 of 49

Who am I?

Thank you for stopping by.

I’m Ronni. I hope you’re well and wish you a safe and worthy journey.

This presentation is part of the Software Engineering Series, from my lectures at Copenhagen School of Design & Technology.

You can view the Introducing Myself, if you want to know a little more about who I am.

All my presentations and materials are free and available at my blog post: Software Engineering.

Don’t let me uphold you,

continue your journey, go to next slide.

2

3 of 49

Agenda

  • Overview
  • The Flow Model
  • Data Flow Modeling Notation
  • External Entity
  • Process
  • Data Flow
  • Data Stores
  • The Data Flow Hierarchy
  • Find 3 errors
  • Find 3 errors, again
  • Function Point Analysis

4 of 49

Overview

  • We’re in the elicitation phase, exploring the user- and business needs.
  • Together with the customer/user, we explore what we are to produce.
  • We analyze
    • the people that are supposed to use the system and their interactions.
    • data, rules, constraints, and scenarios that drive user behavior and needs.
    • others that might be impacted.
  • Our focus is on building a system that satisfy the user’s needs.

5 of 49

Flow-Oriented Modeling

Represents how data objects are transformed as they move through the system

  • Data flow diagrams (DFDs) are the diagrammatic format used.
  • Structured Systems Analysis and Design (SSADM) is a waterfall method which techniques are centered on the use of DFDs.
  • DFDs are considered by many to be an “old school” approach but continues to provide a view of the system that is unique—it should be used to supplement other analysis model elements.

6 of 49

The Flow Model

Every computer-based system is an information transformer ....

Input

Computer based system

output

7 of 49

Data Flow Modeling Notation

External Entity

Process

Data store

Data flow

8 of 49

External Entity

Data must always originate from somewhere (source) and must always be sent to something (sink).

External Entity

A producer or consumer of data.

Ex.: A person, a device, a department.

9 of 49

Process

Data must always be processed in some way to achieve system function.

Process

A data transformer (changes input to output).

Ex.: compute taxes, determines data, formats, reports, display graphs….

10 of 49

Data Flow

Data flows through a system, beginning as input and transformed into output.

Compute triangle area

base

height

area

11 of 49

Data Stores

Data is often stored for later use.

Lookup sensor data

sensor #

report required

sensor, location, age

Data store

sensor data

sensor #

type, location, age

12 of 49

The Data Flow Hierarchy

Refinement continue until each bubble performs a simple function.

Entity

X

Entity

Y

P

a

b

P1

P2

P3

P4

P5

a

b

c

d

e

f

g

13 of 49

Data Flow Diagramming: Guidelines

  • All icons must be labeled with meaningful names.
  • Always begin with a context level diagram.
  • Always show external entities at level 0 (context diagram).
  • Always label data flow arrows.
  • Do not represent procedural logic.

14 of 49

Two notation systems

15 of 49

Flow Modeling Notes

  • Each bubble is refined until it does just one thing.
  • One bubble at a time should be refined.
  • Only external entities at level 0.
  • Information flow continuity must be maintained from level to level. That is input and output at one level must be the same as input and output at refined levels.
  • Most systems require between 3 and 7 levels for an adequate flow model.

16 of 49

Constructing a DFD

  • First create a context diagram
    • Determine external entities (producers and consumers of data).
  • Then refine level 0 DFD
    • review use cases and/or the data model and use agrammatical parse to determine
      • Process = verbs.
      • External entities, data or data stores = nouns.
  • Then refine level 1 DFD

17 of 49

A Context Diagram

An overview of an organizational system that shows the system boundary, sources/ sinks that interact with the system, and the major information flows between the entities and the system.

A Context Diagram addresses only one process.

18 of 49

Example Context Diagram for a Fast-Food IS

19 of 49

Decomposition Overview (Balancing principle)

20 of 49

A decomposed Context Diagram (level 1)

21 of 49

A decomposed Context Diagram (level 2)

22 of 49

Unbalanced DFD

23 of 49

Rules for Processes

Processes can’t

  • have only outputs (a miracle).
  • have only inputs (a black hole).
  • produce outputs with insufficient inputs (a gray hole).

24 of 49

Find 3 errors

?

25 of 49

Identify Errors in This Diagram

Bank statement

Employee status

Employee address

Existing account

Account status

Accounts Receivable Department

Employee

Membership

application

3.1.3

Freeze Member Account

3.1.2

Create Member Account

3.1.1

Generate Bank Statement

Member Accounts

Frozen account

notification

Employees

26 of 49

Processes in a DFD

27 of 49

Data Flows in a DFD

28 of 49

Data Flow Packet Concept

Data that travel together should be shown as a single data flow.

Itemized calls, invoice

Pay Phone Bill

Itemized calls

Invoice

Telephone Service Provider

29 of 49

Naming Rules for Data Flows

  • Use a singular noun phrase for each data flow
    • Ex: customer data, shipping report, ..., etc.
  • Carry logical meaning only, i.e., no implication on data form or data structure.
  • Minimum flow (avoid data flooding).
  • Should never be “Unnamed”.

30 of 49

Naming other DFD Components

  • Process - Use an Action Verb Phrase
    • Ex: Create Member Order, Generate Bank Statement, etc.
  • External Entity (Sink/Source) - Use a Singular Descriptive Noun
    • Ex: Student, Customer, etc.
  • Data Store - Use a plural descriptive noun
    • Ex: Members, Customers, etc.
    • Decide whether to specify the underlying format in the naming (e.g. member file, -database, -service or ….), because it may change over time technology-wise.

31 of 49

Process Logic

  • Data Flow Diagrams are good for identifying and describing processes.
  • Not good at showing logic inside processes.
  • Need to specify detailed instructions for the lowest level of process decomposition.

32 of 49

Process Specification (PSPEC)

  • A description of a process at the lowest level of decomposition.
  • For each leaf process define
    • Text description.
    • Pseudo code.
    • Equations.
    • Decision tables.
    • Diagrams/charts.

33 of 49

Decision tables

34 of 49

DFDs: A Look Ahead

35 of 49

Advantages of DFDs

  • Simple but powerful graphic technique which is easily understood.
  • Represents a system from a data flow viewpoint, with inputs and outputs, people can relate to.
  • Ability to represent the system at different levels of detail.
  • Helps define the boundaries of a system.
  • Identifies information services the users requires.
  • Useful tool during interviews.

36 of 49

Find 3 errors, again

?

37 of 49

Identify Errors in This Diagram

38 of 49

Function Point Analysis

Primary purpose is to measure and provide the software application functional size/complexity, in units called function points.

39 of 49

Function Point Analysis

  • Developed, in 1979, at IBM and has been further modified by the International Function Point Users Group (IFPUG).
  • Primary purpose of the functional point analysis is to measure and provide the software application functional size to the client, customer, and the stakeholder on their request.
  • Further, it is used to measure the software project development along with its maintenance, consistently throughout the project irrespective of the tools and the technologies.
  • FPs (function points) characterizes the complexity of the software system and hence can be used to depict the project time and the manpower requirement.

40 of 49

Function Point - Types of Attributes

  • Function Points are identified by counting the number and types of functions used in an app. Various functions used in an app can be put under five types, as shown below.

Measurements Parameters

Examples

#EI - Number of External Inputs

Input screen and tables

#EO - Number of External Output

Output screens and reports

#EQ - Number of External Inquiries

Prompts and interrupts.

#ILF - Number of Internal Files

Databases and directories

#EIF - Number of External Interfaces

Shared databases and shared routines.

41 of 49

FP - Functional Units System

  • These parameters are then individually assessed for complexity.
  • The FPA functional units are shown in Fig:

42 of 49

Function Point - General info

Characterizes the complexity of the software system and hence can be used to depict the project time and manpower requirement.

  • Express the effort required to develop the project.
  • Are programming language independent.
  • The FP Analysis method is used for data processing-, business- and information systems.
  • Also known as information domain characteristics.

43 of 49

Weights of 5-FP Attributes

All the parameters mentioned, are assigned weights that have been experimentally determined.

The functional complexities (Count columns) are multiplied with the corresponding weights against each function, and the values are added up to determine the UFP (Unadjusted Function Point) of the subsystem.

Measurement Parameter

Count

Simple

Average

Complex

UFP

Number of External Inputs (EI)

2

*

3

4

6

=

0

Number of External Outputs (EO)

3

*

4

5

7

=

0

Number of External Inquiries (EQ)

5

*

3

5

6

=

0

Number of Internal Files (ILF)

2

*

7

10

15

=

0

Number of External Interfaces (EIF)

3

*

5

7

10

=

0

Complexity Factor

Total Unadjusted Function Points (UFP)

0

44 of 49

FP - Computing Function Points

Here that weighing factor will be simple, average, or complex for a measurement parameter type.

Total Unadjusted Function Points (UFP)

Measurement Parameter

Count

Simple

Average

Complex

UFP

Number of External Inputs (EI)

2

*

3

4

6

=

6

Number of External Outputs (EO)

3

*

4

5

7

=

15

Number of External Inquiries (EQ)

5

*

3

5

6

=

30

Number of Internal Files (ILF)

2

*

7

10

15

=

14

Number of External Interfaces (EIF)

3

*

5

7

10

=

21

86

Complexity Factor

45 of 49

Computing Function Points

Unadjusted Function Points (FP) are adjusted for general system influence.

  • UFP (Unadjusted FP) = 86, taken from the previous slide.�
  • DI (Degree of Influence) = 36
    • Sum of influences, F1 - F14 from the GSCs sheet table, on your right.
    • ∑(2,3,3….3,2,2) = 36�
  • CAF (Complexity Adjustment Factor) = 0.65 + (0.01 * DI) = 1.01
    • 0.65 + (0.01 * 36) = 0.65 + 0.36 = 1.01
    • Also called Technical Complexity Factor (TCF).�
  • FP (Function Points) = UFP * CAF = 86.86
    • 86 * 1.01 = 86.86

Final adjusted FP value:

86.86

System

Influence

F1

Data communications

2

F2

Distributed data processing

3

F3

Performance

3

F4

Heavily used configuration

2

F5

Transaction rate

3

F6

Online data entry

3

F7

End-user efficiency

3

F8

Online update

3

F9

Complex processing

2

F10

Reusability

3

F11

Installation ease

2

F12

Operational ease

3

F13

Multiple sites

2

F14

Facilitate change

2

Total GSC score

36

GSC Influence values

0 = Not present, or no influence

1 = Incidental influence

2 = Moderate influence

3 = Average influence

4 = Significant influence

5 = Strong influence throughout

46 of 49

Online Function Point Calculator

47 of 49

Function Point Descriptions

Software Engineering | Functional Point (FP) Analysis - javatpoint

Function Point Analysis Fundamentals

Review of Function Points Analysis

48 of 49

Questions?

Anything? What’s on your mind? Come on ask me anything…

49 of 49

Feedback?

Thank you for your precious time.

I hope it was worth it and would love to get your feedback.

Please share your feedback here