Department: Information and Telecommunication Technology Sector_

TVET –Program Title: Database Administration _ Level:III Year: 2

Course /Module Title: Designing Program Logic

Ac. Year: 2013 E.C

Nominal Duration: 30 hrs Hours: Periods / Week: Semester:

Course / Module Code: EIS DBA3 M06 0517 Program: (Reg/Ext) Regular

Name of the Trainer:

Course / Module Description

This module defines the competency required to describe the various processes in a program to ensure that
there is understanding of user and design requirements.

Leaning Outcomes (Objectives):

At the end of the course / Module, the trainee will able to:

Lo1. Select the program logic design approach

Lo2. Document the program logic or design
Lo3. Validate the design
Duty (Chapter)

I.

1.

2.

II

1.

2.

Course / Module Assessment Methods:

References:

1. www.google.com

2.

Designing Program Logic

LO1 Select the Program Design Approach
1.1 Obtaining Design Documentation and Requirement for the Program Clarification
A program is a logical description of your problem from which a solution is logically derivable.
Logic programming is a type of programming paradigm which is largely based on formal logic. Any
program written in a logic programming language is a set of sentences in logical form, expressing
facts and rules about some problem domain.

What is Program Design?

Program design is the process of converting a set of requirements into a collection of commands or a
program that can be executed on a computer system. A program is a series of instructions that the
computer executes in order to perform some meaningful work. For example, the developers at
Microsoft created a program called Word that performs word processing activities for a user.
Program design is an integral part of software development and depending on the methodology used
can be a significant step in the process. Generally, it consists of:
• Translating requirements into general operations or commands.
• Identifying important attributes and characteristics of the commands and grouping them.
• Establishing an order and relationships between the groups.
The result is a framework that the program can use to deliver the required functionality.

1.1.1 Pseudo code

Pseudo code is an informal high-level description of the operating principle of a computer program
or other algorithm.
Pseudo code
• English-like representation of a program
• It could be viewed as the outline of a program
• It can‟t be compiled or executed.
• The focus is on solving the problem, not worrying about the specifics of a programming
language.
It uses the structural conventions of a programming language, but is intended for human reading
rather than machine reading. Pseudo code typically omits details that are not essential for human
understanding of the algorithm, such as variable declarations, system-specific code and some
subroutines. The programming language is augmented with natural language description details,
where convenient, or with compact mathematical notation. The purpose of using pseudo code is that
it is easier for people to understand than conventional programming language code, and that it is
an efficient and environment-independent description of the key principles of an algorithm. It is
commonly used in textbooks and scientific publications that are documenting various algorithms, and
also in planning of computer program development, for sketching out the structure of the program
before the actual coding takes place.

Designing Program Logic Page | 1

Pseudo-code is an English-like representation of the same thing. Pseudo is a prefix that means
“false,” and to code a program means to put it in a programming language; therefore, pseudo-code
simply means “false code,” or sentences that appear to have been written in a computer programming
language but don‟t necessarily follow all the syntax rules of any specific language. You have already
seen examples of statements that represent pseudo-code earlier in this chapter, and there is nothing
mysterious about them.
Pseudo code Structure
 Input: READ, OBTAIN, GET and PROMPT
 Output: PRINT, DISPLAY and show
 Compute: COMPUTE, CALCULATE and DETERMINE
 Initialize: SET and INITIALIZE
 Add one: INCREAMENT
Example: The following five statements constitute a pseudo-code representation of a number-
doubling problem:
 start
 get inputNumber
 compute calculatedAnswer as inputNumber times 2
 print calculatedAnswer
 stop
Example: Write a program that obtains two integer numbers from the user. It will print out the sum of
those numbers.
 Prompt the user to enter the first integer
 Prompt the user to enter a second integer
 Compute the sum of the two user inputs
 Display an output prompt that explains the answer as the sum
 Display the result.
Pseudo Code with SEQUENCE
When we write programs, we assume that the computer executes the program starting at the
beginning and working its way to the end.
We call this sequence
SEQUENCE is a linear progression where one task is performed sequentially after another.
In pseudo code it look like this

Designing Program Logic Page | 2

Statement 1; For example, for making a cup of tea:
Statement 2; Organize everything together;
Statement 3; Plug in kettle;
Statement 4; Put teabag in cup;
Statement 5; Put water into kettle;
Wait for bottle to boil;
Add water to cup;
Remove teabag with spoon/fork/;
Add milk and /or sugar;
Serve;
Pseudo Code with LOOP
What if we need to tell the computer to keep doing something until some condition occurs?
Let‟s say we wish to indicate that you need to keep filling the kettle with water until it is full.
We call this a loop.
WHILE is a loop (repetition) with a simple conditional test at its beginning
Or, in general
While (<condition>) Put teabag in cup;
Do <Statements>; While (Kettle is not full)
Endwhile; Do keep filling Kettle;
As we could state this as: EndWhile;
While (Kettle is not full) Wait for bottle to boil;
Do keep filling Kettle; Add water to cup;
EndWhile; Remove teabag with spoon/fork/;
Example, above Add milk and /or sugar;
Organize everything together; Serve;
Plug in kettle;
Pseudo Code with SELECTION
What if we want to make a choice, for example, do we want add sugar or not to the tea?
We call this selection.
Designing Program Logic Page | 3
IF-THEN-ELSE is a decision (selection) in which a choice is made between two alternative courses
of action.
Or, in general:
If (<condition>) While (Kettle is not full)
Then <Statement>; Do keep filling Kettle;
Else <Statement>; EndWhile;
EndIf; Wait for bottle to boil;
So, we could state this as: Add water to cup;
If (Sugar is required) Remove teabag with spoon/fork/;
Then add Sugar; Add milk;
Else don’t add sugar; If (Sugar is required)
EndIf; Then add Sugar;
Example, Above: Else do nothing;
Organize everything together; EndIf;
Plug in kettle; Serve;
Put teabag in cup;
1.1.2 Flowcharts
A flow chart is a graphical or symbolic representation of a process. Each step in the process is
represented by a different symbol and contains a short description of the process step. The flow
chart symbols are linked together with arrows showing the process flow direction.
• Pictorial representation of a program
• Can be created with pencil and paper, Microsoft Word, PowerPoint, Visio (a copy of this is
in the back of the Farrell book), etc.
• For this class, all flowcharts must be done in Visio

Six basic flowchart shapes

Lozenge/terminal symbol -Indicates the beginning or end of a program

Input/output symbol- Represents information coming into a program or going out of

a program

Processing symbol- Shows calculations that a program must do

Designing Program Logic Page | 4
 Diamond symbol represents decision- that a program must make

The circle is for connecting parts of the flowchart to other parts. This is especially useful
if the flowchart covers more than one page

Flow lines connect the shapes within a flowchart

The three basic control structures
1. Sequence 2. Selection

Selection (2) 3. Repetition

Example 1 Add three numbers

A program is required to read three numbers, add them together and print their total.
Pseudo code
Add_three_numbers
Read number1, number2, number3

Designing Program Logic Page | 5

Total = number1 + number2 + number3
Print total
END
Defining diagram
Input Processing Output
Number1 Read three numbers total
Number2 Add number together
Number3 Print total number

Example 2 Getting out of bed in the morning

The following flow chart example presents a very simple flow chart for the process of getting out of
bed in the morning.

Designing Program Logic Page | 6

Example:- Find average temperature
A program is required to prompt the terminal operator for the maximum and minimum temperature
readings on a particular day, accept those readings as integers, and calculate and display to the
screen the average temperature, calculated by (maximum temperature + minimum temperature)/2.
Defining diagram
Input Processing Output
Max_temp Prompt for temperatures Avg_temp
Min_temp Get temperatures
Calculate average temperature
Display average temperature

Pseudo code
Flow Chart Start
Find average_temperature
Prompt operator for max_temp, min_temp
Get max_temp, min_temp
Avg_temp= (max_Temp + min_temp)/2
Output avg_temp to the screen
END Get max_temp,
min_temp

Calculate Average
Temprature

Print Average
Temprature.

End

1.1.4 DFD’s
Data Flow Diagram (DFD)
The Data Flow Diagram (DFD) is a graphical representation of the flow of data through an
information system.
A structured analysis technique that employs a set of visual representations of the data that moves
through the organization, the paths through which the data moves, and the processes that produce,
use, and transform data. It enables you to represent the processes in your information system from
Designing Program Logic Page | 7
the viewpoint of data. The DFD lets you visualize how the system operates, what the system
accomplishes and how it will be implemented, when it is refined with further specification.

Data flow diagrams are used by systems analysts to design information-processing systems but also
as a way to model whole organizations.
Why Data Flow Diagrams?
• Can diagram the organization or the system
• Can diagram the current or proposed situation
• Can facilitate analysis or design
• Provides a good bridge from analysis to design
• Facilitates communication with the user at all stages
Types of DFDs
• Current - how data flows now
• Proposed - how we‟d like it to flow
• Logical - the “essence” of a process (i.e. implementation-independent and describe the
system, rather than how activities are accomplished.)
• Physical - the implementation of a process (i.e. are implementation-dependent and describe
the actual entities (devices, department, people, etc.) involved in the current system.)
• Partitioned physical - system architecture or high-level design

Levels of Details
Context Diagram- Shows just the inputs and outputs of the system
Level 0 Diagram- Decomposes the process into the major subprocesses and identifies what data
flows between them

Child diagrams- Increasing levels of detail (i.e. Level 1, Level 2 etc)

Primitive diagrams- Lowest level of decomposition

Four Basic Symbols

Designing Program Logic Page | 8

Process:

1.0
Grade Detail Produce Grade Report
Grade
Report

Work or actions performed on data (inside the system)


Labels should be verb phrases
Receives input data and produces output
Rule 1: Process
 Can have more than one outgoing data flow or more than one incoming data flow

1.0 Graded Work

Submitted work Grade Student Grade
Student

3.0
Hours Worked Calculated Gross Pay
Pay Rate Gross
Pay

Designing Program Logic Page | 9

Rule 2: Process
 Can connect to any other symbol (including another process symbol)

2.0 Inventory Change

1.0
Order Accepted Order
Verify Assemble
Order Order

Data Flow Deposit

 Is a path for data to move from one part to another
 Arrows depicting movement of data
 Can represent flow between process and data store by two separate arrows

Data Store
D1 Students

 Is used in a DFD to represent data that the system stores

 Labels should be noun phrases
Rule: Data Store
 Must have at least one incoming and one outgoing data flow

Customer Payment

Daily Payment

Designing Program Logic Page | 10

Source/Sink (External Entity)
1.0
Order

CUSTOMER Invoice
Verify
Order
 External entity that is origin or destination of data (outside the system)
 Labels should be noun phrases
 Source –Entity that supplies data to the system
 Sink –Entity that receives data from the system

Context Level Diagram

• Just one process
• All sources and sinks that provide data to or receive data from the process
• Major data flows between the process and all sources/sinks
• Shows all the outside entities that receive information from or contribute information to the
system
• No data stores
Example: - Course Registration: Context level Diagram

Level 0 Diagram
• Process is “exploded”
• Sources, sinks, and data flows repeated from context diagram
• Process broken down into sub processes, numbered sequentially
• Lower-level data flows and data stores added

Designing Program Logic Page | 11

1.1.5 Hierarchy Input Process Output Diagram (HIPO)
• It is a hierarchy chart that graphically represents the program‟s control the s functions (or
processes) performed by each module on the system.

Designing Program Logic Page | 12

Hierarchy Input Process Output Diagram (HIPO)

1.1.6 Data Structure

Data structure diagram (DSD) is intended for description of conceptual models of data (concepts
and connections between them) in the graphic format for more obviousness. Data structure diagram
includes entities description, connections between them and obligatory conditions and requirements
which connect them.

Data structure diagram is a subspecies of the “entity-relationship” diagram type (ERD).

Entities in data structure diagrams are presented in the form of rectangles or rounded rectangles, and
connections between them in the form of arrows. The description of an entity is usually placed
inside the rectangle, which denotes the entity. The text description of the entity requirements
connecting entities is placed near the line which denotes the connection between entities. The
description of connection types between entities (one-to-one, one-to-many, etc.) can be different in
different notations and differs with the arrow type on the line of connection between entities. The
most famous are notations of DeMarco, Jackson and Yourdon.

Designing Program Logic Page | 13

DSD also used for hierarchical presentation of the complicated entity. Such data structure diagram
is usually created in the result of entity decomposition to the set level of detailed elaboration and
presented as a tree.

The difference of the data structure diagram from the “entity- relationship” diagram is that DSD
more completely defines connections and relations between elements of entities whereas ERD
defines connections between entities.

Designing Program Logic Page | 14

1.1.7 RAD
What is RAD model- advantages, disadvantages and when to use it?
RAD model is Rapid Application Development model. It is a type of incremental model. In RAD
model the components or functions are developed in parallel as if they were mini projects. The
developments are time boxed, delivered and then assembled into a working prototype. This can
quickly give the customer something to see and use and to provide feedback regarding the delivery
and their requirements.
Diagram of RAD-Model:

The phases in the rapid application development (RAD) model are:

Business modeling: The information flow is identified between various business functions.
Data modeling: Information gathered from business modeling is used to define data objects that are
needed for the business.
Process modeling: Data objects defined in data modeling are converted to achieve the business
information flow to achieve some specific business objective. Description are identified and created
for CRUD of data objects.

Designing Program Logic Page | 15

Application generation: Automated tools are used to convert process models into code and the
actual system.
Testing and turnover: Test new components and all the interfaces.
Advantages of the RAD model:
• Reduced development time.
• Increases reusability of components
• Greater customer satisfaction
• Encourages customer feedback
• Faster delivery time
• simple and better quality
Disadvantages of RAD model:
• Depends on strong team and individual performances for identifying business requirements.
• Only system that can be modularized can be built using RAD
• Requires highly skilled developers/designers.
• It is not appropriate when technical risk is high
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling and automated code generation is very
high.
When to use RAD model:
• RAD should be used when there is a need to create a system that can be modularized in 2-3
months of time.
• It should be used if there‟s high availability of designers for modeling and the budget is high
enough to afford their cost along with the cost of automated code generating tools.
• RAD SDLC model should be chosen only if resources with high business knowledge are
available and there is a need to produce the system in a short span of time (2-3 months).

1.1.8 Prototyping
What is Prototype model- advantages, disadvantages and when to use it?
This prototype is developed based on the currently known requirements. By using this prototype, the
client can get an “actual feel” of the system, since the interactions with prototype can enable the
client to better understand the requirements of the desired system. Prototyping is an attractive idea
for complicated and large systems for which there is no manual process or existing system to help
determining the requirements. The prototypes are usually not complete systems and many of the
details are not built in the prototype. The goal is to provide a system with overall functionality.

Designing Program Logic Page | 16

Diagram of Prototype model:

Advantages of Prototype model:

• Users are actively involved in the development
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily
• Confusing or difficult functions can be identified
Disadvantages of Prototype model:
• It‟s a slow in process
• It‟s not complete model
• It is time consuming model
• It should be developed or built on company‟s cost
When to use Prototype model:
• Prototype model should be used when the desired system needs to have a lot of interaction
with the end users.
• Typically, online systems, web interfaces have a very high amount of interaction with end
users, are best suited for Prototype model. It might take a while for a system to be built that
allows ease of use and needs minimal training for the end user.
• Prototyping ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system. They are
excellent for designing good human computer interface systems.

1.1.9 Case Tools

CASE (computer-aided software engineering) tools have been widely in use since the 1990's. They
are specialized, computerized tools that aid in the design, development and maintenance of
software. The term CASE was originally coined by software company, Nastec Corporation of
Southfield, Michigan in 1982 with their original integrated graphics and text editor GraphiText.

Many different definitions of CASE tools exist, below are just a few of those:
Galin - CASE tools are computerized software development tools that support the developer when
performing one or more phases of the software life cycle and/or support software maintenance.

Wikipedia - The scientific application of a set of tools and methods to a piece of software which
results in high-quality, defect free and maintainable software products.

Carnegie-Mellon - The use of computer-based support in the software development process.

Designing Program Logic Page | 17

Types of CASE tools
Classic CASE tools - established software development support tools (e.g. interactive debuggers,
compilers, etc.)
Real CASE tools - can be separated into three different categories, depending on where in the
development process they are most involved in:
• Upper - support analysis and design phases
• Lower - support coding phase
• Integrated - also known as I-CASE support analysis, design and coding phases
Upper and lower CASE tools are named as such because of where the phases they support are in the
Waterfall Model (see below)

Why use CASE tools?

CASE tools offer:
• Savings in resources required for software development - with less
• Quicker development phase (i.e. shorter time to market)
• Reduction of generation of defects
• Easier identification of defects during development
• Savings in maintenance resources required
• Greater standardization of software systems and therefore increased reuse possibilities
• Reduction of effort needed on development

Designing Program Logic Page | 18

1.1.10Modular programming
It is a software design technique that emphasizes separating the functionality of a program into
independent, interchangeable modules, such that each contains everything necessary to execute only
one aspect of the desired functionality.

Need for Modular Programming

 When a program become very large and complex, it becomes very difficult task for the
programmers to design, test and debug such a program.
 Therefore, a long program can be divided into a smaller program called modules as the
modules can be designed, tested and debugged separately, the task of programmer becomes
easy and convenient.
 It makes your program easy to understand.

Why Modular Programming?

 Helps manage complexity
o Smaller blocks of code and easier to read.
 Encourages re-use of code within a particular program or across different programs
 Allows independent development

Modularity:
 How do you solve a big/complex problem?
 Divide it into small tasks and solve each task. Then combine these solutions.

 In C we use function also referred to as modules to perform specific tasks that we

determined in our solution.
 This strategy is essentially based on the divide-and –conquers approach to problem solving
and has many advantages over developing a program for the entire problem.
 We will assign a name to each module and combine the name modules in a program
structure under the control of a main program.
 Such a program structure consists of a set of modules and an order of execution.

Elements of Modular Programming

 C requires that function names be unique in a source program file.
 Program execution always begins and eventually terminates in the main function.
 Additional function are called or invoked when the program encounter function names.
 Functions could be:
o Pre-defined library functions (e.g., printf, sin, tan) OR
o Programmer-defined functions (e.g., my_printf, Area)

Designing Program Logic Page | 19

  Functions perform a specific task
 Arguments with no return type
Void fun (int x, int y)
{
//statement
}

 Arguments with return type

Void fun (int x, int y)
{
//statement
Return 0;
}

 No arguments with no return type

Void fun ()
{
// statement
}

 No arguments with return type

Void fun ()
{
// statement
Return 0;
}

These functions require three elements

1. Function Declaration:
In this only the name and the syntax of the function will written.
2. Function Calls:
In this program will call the function.
3. Function Definition:
In this program will define that how the function will perform their task.
A function definition consists of:
 A function type
 A function name
 An optional list of formal parameters enclosed in parentheses
 A compound statement.
EX: Void start ( int a)
{
….. Statement …..
}

Designing Program Logic Page | 20

Modular Programming Example
# include < Studio.h>
Int max (int num1, int num2);
Int main ()
{
Int a=100;
Int b= 200;
Int ret;
Ret= max (a, b);
Printf (“Max value is : %d\n”, ret);
Return 0;
}
Int max (int num1, int num2)
{
Int result;
If (num1> num2)
Result =num1;
Else
Result =num2
}

Output
Max value is : 200

Advantage of Using Modules

 Modules can be written and tested separately
 Modules can be reused
 Large projects can be developed in parallel
 Reduces length of program, making it more readable
 Promotes the concept of abstraction
 A module hides details of a task
 We just need to know what this module does
 We don‟t need to know how it does it
Disadvantage of Using Modules
 Means of documentation of modules must be systematic
 Can lead to problems when modules are linked because link must thoroughly tested.
 Since separate modules map repeat certain functions, the modular programming often need
extra time and memory.

Designing Program Logic Page | 21

SELF-CHECK FOR LO1

NAME _______________________________ ID. No. __________ DATE ___/___/_____

Directions: Answer all the questions listed below. If you have some clarifications, feel free to ask
your trainer (2pts each).

1. What is program logic?

2. What is pseudo-code?
3. What is the purpose of using pseudo-code?
4. What is flow chart? List the six basic flow chart shapes and identify what it represents?
5. What is DFD? List the four basic symbols of DFD and identify what it represents?
6. Write pseudo-code and draw the flow chart to find the Sum of Two Numbers Entered.
7. Write pseudo-code and draw a flow chart that reads three numbers and prints the value of
the largest number.
8. Write pseudo-code and draw the flow chart to calculate the Sum of the First 50 Numbers.
9. Write pseudo-code and the corresponding flowchart for finding the sum of n numbers.
10. Write pseudo-code and the corresponding flowchart for finding the sum of the numbers 2,
4, 6, 8, …, n.
11. Write pseudo code and draw the flow chart that performs the following: Ask a user to enter
a number. If the number is between 0 and 10, write the word blue. If the number is
between 10 and 20, write the word red. If the number is between 20 and 30, write the
word green. If it is any other number, write that it is not a correct color option.
12. Write pseudo code and draw its flow chart to print all multiples of 5 between 1 and 100
(including both 1 and 100).
13. Write a pseudo-code and draw a flow chart solution which will take in an integer value and
determine whether that value is odd or even.

Designing Program Logic Page | 22

LO2 Document the Program Logic or Design
2.1 Documenting Program Scope and Limits
The larger the project, the more important it becomes to use CASE tools in the software's
development. The standardization provided by using CASE tools allows many developers to work
on one project without spending time working out what certain sections of code does, it also enables
easier debugging which becomes more important with a project that involves a large amount or
complex coding as software such as this is more likely to have errors.

The purpose of a scope and limitations statement is to provide an outline of what your project
will address and what it won’t address. What you turn in will include the following:

 a description of the project (what technology you are addressing and the rationale for choosing
that technology),
 an explanation of what kind of data you will collect, the methods you will use (interviews,
library research, observation, etc.), and how much of each kind of data you will collect,
 an explanation of how you are approaching the challenge of making something „better‟ (making
it less expensive, easier to use, available to a more diverse population, more environmentally
friendly, etc.),
 A proposal about how you will test your initial design suggestions. Remember the design
guidelines provided during Unit 1, and address these as you outline your approach, and
 A timeline with major tasks to be accomplished for the project and which team member will
take a leadership role and responsibility for the task.

While the actual write-up you hand in may be as short as one page, I expect a significant level of
detail in your descriptions of your approach, and I also expect that the paper will reflect a
considerable amount of thought and the contributions of each group member. Keep in mind that my
expectation is that three or four people will be contributing content to this statement, and the work
should reflect that level of collective effort.

2.2 Program Design Logic Document Contents

Designing Program Logic Page | 23
TABLEOFCONTENTS

1. INTRODUCTION 2
11. Purpose 2
12. Scope 2
13. Overview 2
14. ReferencMaterial 2
15. DefinitionsandAcronyms 2

2. SYSTEMOVERVIEW 2

3. SYSTEMARCHITECTURE 2
31. ArchitecturalDesign 2
32. DecompositionDescription 3
33. DesignRationale 3

4. DATADESIGN 3
41. DataDescripton 3
42. DataDictionary 3

5. COMPONENTDESIGN 3

6. HUMANINTERFACEDESIGN 4
61. OverviewofUserInterface 4
62. ScreenImages 4
63. ScreenObjectsandActions 4

7. REQUIREMENTSMATRIX 4

8. APPENDICES 4

1. INTRODUCTION

Designing Program Logic Page | 24

1.1 Purpose
Identify the purpose of this SDD and its intended audience. (e.g. “This software design document
describes the architecture and system design of XX. ….”).

1.2 Scope
Provide a description and scope of the software and explain the goals, objectives and benefits of
your project. This will provide the basis for the brief description of your product.

1.3 Overview
Provide an overview of this document and its organization.

1.4 Reference Material

This section is optional.
List any documents, if any, which were used as sources of information for the test plan.

1.5 Definitions and Acronyms

This section is optional.
Provide definitions of all terms, acronyms, and abbreviations that might exist to properly interpret
the SDD. These definitions should be items used in the SDD that are most likely not known to the
audience.

2. SYSTEM OVERVIEW
Give a general description of the functionality, context and design of your project. Provide any
background information if necessary.

3. SYSTEM ARCHITECTURE
3.1 Architectural Design
Develop a modular program structure and explain the relationships between the modules to achieve
the complete functionality of the system. This is a high level overview of how responsibilities of the
system were partitioned and then assigned to subsystems. Identify each high level subsystem and
the roles or responsibilities assigned to it. Describe how these subsystems collaborate with each
other in order to achieve the desired functionality. Don‟t go into too much detail about the
individual subsystems. The main purpose is to gain a general understanding of how and why the
system was decomposed, and how the individual parts work together. Provide a diagram showing
the major subsystems and data repositories and their interconnections. Describe the diagram if
required.

3.2 Decomposition Description

Provide a decomposition of the subsystems in the architectural design. Supplement with text as
needed. You may choose to give a functional description or an object oriented description. For a
functional description, put top level data flow diagram (DFD) and structural decomposition
diagrams. For an OO description, put subsystem model, object diagrams, generalization hierarchy
diagram(s) (if any), aggregation hierarchy diagram(s) (if any), interface specifications, and sequence
diagrams here.

3.3 Design Rationale

Designing Program Logic Page | 25

Discuss the rationales for selecting the architecture described in 3.1 including critical issues and
trade/offs that were considered. You may discuss other architectures that were considered, provided
that you explain why you didn‟t choose them.

4. DATA DESIGN
4.1 Data Description
Explain how the information domain of your system is transformed into data structures. Describe
how the major data or system entities are stored, processed and organized. List any databases or data
storage items.

4.2 Data Dictionary

Alphabetically list the system entities or major data along with their types and descriptions. If you
provided a functional description in Section 3.2, list all the functions and function parameters. If you
provided an OO description, list the objects and its attributes, methods and method parameters.

5. COMPONENT DESIGN
In this section, we take a closer look at what each component does in a more systematic way. If you
provide a function listed in 3.2 in procedural description language (PDL) or pseudocode. If you
gave an
OO description, summarize each object member function for all the objects listed in 3.2 in PDL or
pseudocode. Describe any local data when necessary.

6. HUMAN INTERFACE DESIGN

6.1 Overview of User Interface
Describe the functionality of the system from the user‟s perspective. Explain how the user will be
able to use your system to complete all the expected features and the feedback information that will
be displayed for the user.

6.2 Screen Images

Display screenshots showing the interface from the user‟s perspective. These can be hand drawn or
you can use an automated drawing tool. Just make them as accurate as possible. (Graph paper works
well.)

6.3 Screen Objects and Actions

A discussion of screen objects and actions associated with those objects.

7. REQUIREMENTS MATRIX
Provide a cross reference that traces components and data structures to the requirements in your
SRS document. Use a tabular format to show which system components satisfy each of the
functional requirements from the SRS. Refer to the functional requirements by the numbers/codes
that you gave them in the SRS.

8. APPENDICES
This section is optional.
Appendices may be included, either directly or by reference, to provide supporting details that could
aid in the understanding of the Software Design Document.

Designing Program Logic Page | 26

LO3 Validate the design
3.1 Checking Program Flow, States or Conditions
Verification and Validation
Software verification provides objective evidence that the design outputs of a particular phase of the
software development life cycle meet all of the specified requirements for that phase. Software
verification looks for consistency, completeness, and correctness of the software and its supporting
documentation, as it is being developed, and provides support for a subsequent conclusion that
software is validated. Software testing is one of many verification activities intended to confirm that
software development output meets its input requirements. Other verification activities include
various static and dynamic analyses, code and document inspections, walkthroughs, and other
techniques.

Software validation is a part of the design validation for a finished device, but is not separately
defined in the Quality System regulation. For purposes of this guidance, FDA considers software
validation to be "confirmation by examination and provision of objective evidence that software
specifications conform to user needs and intended uses, and that the particular requirements
implemented through software can be consistently fulfilled." In practice, software validation
activities may occur both during, as well as at the end of the software development life cycle to
ensure that all requirements have been fulfilled. Since software is usually part of a larger hardware
system, the validation of software typically include evidences that all software requirements have
been implemented correctly and completely and are traceable to system requirements. A conclusion
that software is validated is highly dependent upon comprehensive software testing, inspections,
analyses, and other verification tasks performed at each stage of the software development life
cycle. Testing of device software functionality in a simulated use environment, and user site testing
are typically included as components of an overall design validation program for a software
automated device.

Software verification and validation are difficult because a developer cannot test forever, and it is
hard to know how much evidence is enough. In large measure, software validation is a matter of
developing a "level of confidence" that the device meets all requirements and user expectations for
the software automated functions and features of the device. Measures such as defects found in
specifications documents, estimates of defects remaining, testing coverage, and other techniques are
all used to develop an acceptable level of confidence before shipping the product. The level of
confidence, and therefore the level of software validation, verification, and testing effort needed, will
vary depending upon the safety risk (hazard) posed by the automated functions of the device.

3.2 Gaining Feedback or Input

The great leadership guru Ken Blanchard likes to say that “Feedback is the breakfast of champions.”
He is right; getting high-quality feedback from customers can make a phenomenal difference to a
company‟s bottom line. Yet so, few business owners actually seek feedback on their performance.
Maybe it is because they are too busy serving their customers, or perhaps it is because they are scared
of what their clients might say when asked. Regardless, not asking for feedback is a crazy mistake.
Good customer feedback can help to do a number of things, including:
• Improve products.
• Alter pricing structure.
• Retain customers for longer.
• Increase referrals
Designing Program Logic Page | 27
• Identify high- and low-achieving staff.
1. Ask new customers why they chose your service brand. This can be hard to do as many
customers will feel uncomfortable speaking with a company representative directly. For this reason, it
is important to establish a comfortable rapport so that customers feel they may speak openly and
honestly. An alternative is to hire a consultant to perform this survey as a third party may uncover
sensitive information more readily.

2. Ask current and past customers what differentiates your service brand from others. Another
approach is to ask a customer what thought or image first comes to mind when they consider your
company. Then the first thought or image when considering a competitor‟s brand. There is no right or
wrong answers. Take each answer at face value and recognize that the stated differences will be very
instructive in terms of how your brand is being perceived by your target audience. Any
misalignments uncovered with regard to your branding message and audience perception can then be
readily addressed.

3. Who are your repeat customers? Look for areas of commonality among your repeat customers.
This is an important clue to how your brand is perceived in the marketplace. For example, do your
customers seem to fall within a certain age or demographic group? Contact these repeat patrons to
understand what drives their customer loyalty.
4. Is your business obtaining referrals? If your brand is perceived accurately by customers, then
word-of-mouth is a great source of new business. What customers say about your company‟s brand
speaks louder than any promotional message.

5. Contact customers who chose a competitor. Assume a friendly tone and stress that your call is
not sales-oriented. You simply wish to follow up on why they didn‟t choose your firm. Again, a
consultant performing this survey may obtain more detailed information during a conversation with a
company employee.

6. Is your brand an integral part of your core values? Both Starbucks and Union Square align
their service branding strategy with company values. Company core values are just that: they are the
rock upon which your firm is built and, as such, unchanging. Building your service brand on core
values ensures message consistency and facilitates the development strong and attractive of a brand
image in the minds of your audience.
Spending time understanding the perception of your service brand is a highly valuable exercise. It
ensures that your firm is reaching its intended audience and aligning customer expectations with
service delivery.

Continually seeking feedback through a variety of sources can help you identify trends, gain
competitive advantages, and cut costs. Failure to seek feedback can cost you customers. And
remember, you can't make a profit if you're not satisfying your customers

Designing Program Logic Page | 28