Training, Teaching and Learning Materials (TTLM)

ADMAS UNIVERSITY

The Ethiopian TVET-System

Database Administration
Level – III

Learning Guide
Unit of Competence: Design Program Logic
Module Title: Designing Program Logic
LG Code: EIS DBA3 050811
TTLM Code: EIS DBA3M 050811

1
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
 Training, Teaching and Learning Materials (TTLM)

Occupational Standard: Database Administration Level IV

Unit Title Design Program Logic
Unit Code EIS DBA3 05 0811
Unit This unit defines the competency required to describe the various processes
Descriptor in a program to ensure that there is understanding of user and design
requirements.

Elements Performance Criteria

1. Select the 1.1 Design documentation is obtained and the requirements for the
program logic programs are reviewed and clarified.
design 1.2 Design approach to be taken in coding and the modules and links
approach required is determined

2. Document the 2.1 Diagrams of program flow and modules are structured according to
program logic project standards
or design 2.2 Program scope and limits are documented according to project
standards
2.3 Special routines or procedures are documented or referenced
according to project standards
2.4 References for tables, files, inputs, outputs, and other program
functionalities are identified and revised according to program
requirements
2.5 Templates are used as applicable
3. Validate the 3.1 Program flow, states or conditions are checked for interfaces and
design compliance to design documentation requirements
3.2 Feedback/input is gained from appropriate person as needed

2
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
 Training, Teaching and Learning Materials (TTLM)

LO1 Select the program design approach

1.1 Obtaining design documentation and requirement for the program clarification
1.1.1 Pseudo code

 Example 1: Write an algorithm to determine a student’s final grade and indicate whether it is passing
or failing. The final grade is calculated as the average of four marks.

Input a set of 4 marks

Calculate their average by summing and dividing by 4
if average is below 50
Print “FAIL”
else
Print “PASS”

Pseudocode & Algorithm

 Detailed Algorithm
 Step 1: Input M1,M2,M3,M4
Step 2: GRADE ¬ (M1+M2+M3+M4)/4
Step 3: if (GRADE < 50) then
Print “FAIL”
else
Print “PASS”
endif

1.1.2 Flow charts

 (Dictionary) A schematic representation of a sequence of operations, as in a manufacturing process

or computer program.
 (Technical) A graphical representation of the sequence of operations in an information system or
program. Information system flowcharts show how data flows from source documents through the
computer to final distribution to users. Program flowcharts show the sequence of instructions in a
single program or subroutine. Different symbols are used to draw each type of flowchart.
A Flowchart
 shows logic of an algorithm
 emphasizes individual steps and their interconnections
 e.g. control flow from one action to the next

3
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
 Training, Teaching and Learning Materials (TTLM)

Flowchart Symbols
Basic

Example 1 STAR
T
Step 1: Input M1,M2,M3,M4 Input
Step 2: GRADE  Example 2
M1,M2,M3,
(M1+M2+M3+M4)/4 M4
Step 3: if (GRADE <50) then  Write an algorithm and draw a flowchart to
GRADE(M1+M2+M3+M
Print “FAIL” 4)/4 convert the length in feet to centimeter.
else Pseudocode:
Print “PASS” N  InputIS the length in Y
feet (Lft)
endif  Calculate
GRAD the length in cm (Lcm) by multiplying
LFT with 30 E<50
 Print length in cm (LCM) Flow chart
PRINT
“FAIL”
START
4
Date: September, 2017 Input
TLM Development Manual STOP
Compiled by: ICT Department Lft
 Lcm Lft x 30
Training, Teaching and Learning Materials (TTLM)
Print
Lcm
Algorithm
 Step 1: Input Lft
 Step 2: Lcm ¬ Lft x 30 STOP
 Step 3: Print Lcm

Example 3
Write an algorithm and draw a flowchart that will read the two sides of a rectangle and calculate its area.
Pseudocode
 Input the width (W) and Length (L) of a rectangle
 Calculate the area (A) by multiplying L with W
START
 Print A
Input
W, L
Algorithm
 Step 1: Input W,L
 Step 2: A¬L x W A LxW
 Step 3: Print A

Print
A

STOP
Example4
 Write an algorithm and draw a flowchart that will calculate the roots of a quadratic equation
ax
2
+bx + c=0

(b −4 ac)
2

 Hint: d = sqrt , and the roots are: x1 = (–b + d)/2a and x2 = (–b – d)/2a
START
Pseudocode:
 Input the coefficients (a, b, c) of the quadratic equation Input
 Calculate d
a, b, c
 Calculate x1
 Calculate x2
 Print x1 and x2 d sqrt(b x b – 4 x a x c)

5 x1 (–b + d) / (2 x a)
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department X (–b – d) / (2 x a)
2
 Print
Training, Teaching and Learning Materials (TTLM) x1 ,x2

 Algorithm:
STOP
 Step 1: Input a, b, c
 Step 2: d ¬ sqrt( )
 Step 3: x1 ¬ (–b + d) / (2 x a)
 Step 4: x2 ¬ (–b – d) / (2 x a)
 Step 5: Print x1, x2

DECISION STRUCTURES
 The expression A>B is a logical expression
 it describes a condition we want to test
 if A>B is true (if A is greater than B) we take the action on left
 print the value of A
 if A>B is false (if A is not greater than B) we take the action on right
print the value of B

IF–THEN–ELSE STRUCTURE Y N
is
 The structure is as follows A>B
If condition then
true alternative
else
false alternative Print A Print B
endif

IF–THEN–ELSE STRUCTURE

 The algorithm for the flowchart is as follows:

If A>B then
print A
else Y N
print B is
endif A>B

Print Print
A B

Relational Operators
Operator Description
> Greater than
< Less than
= Equal to
>= Greater than or equal to
6
<=
TLM Development Less than orDate:
Manual equalSeptember,
to 2017
Compiled by: ICT Department
<> Not equal to
 Training, Teaching and Learning Materials (TTLM)

Example 5
 Write an algorithm that reads two values, determines the largest value and prints the largest value
with an identifying message.
ALGORITHM STA
Step 1: Input VALUE1, VALUE2 RT
Step 2: if (VALUE1 > VALUE2) then Input
MAX ¬ VALUE1
else
VALUE1,V
MAX ¬ VALUE2 ALUE2
endif Y is N
Step 3: Print “The largest value is”, MAX VALUE1>VALUE2

Example 6 MAX MAX

 Write an algorithm that reads three numbers and prints VALUE1 VALUE2
the value of the largest number.

Step 1: Input N1, N2, N3 Print

Step 2: if (N1>N2) then “The largest
if (N1>N3) then value is”, MAX
MAX ¬ N1 [N1>N2, N1>N3]
else STO
MAX ¬ N3 [N3>N1>N2] P
endif
else
if (N2>N3) then
MAX ¬ N2 [N2>N1, N2>N3]
else
MAX ¬ N3 [N3>N2>N1]
endif
endif
Step 3: Print “The largest number is”, MAX

 Flowchart: Draw the flowchart of the above Algorithm.

1.1.3 ERD

An entity-relationship diagram is a data modeling technique that creates a graphical representation of the

entities, and the relationships between entities, within an information system

The three main components of an ERD are:

The entity is a person, object, place or event for which data is collected. The entity is represented by a
rectangle and labelled with a singular noun.
The relationship is the interaction between the entities. A relationship may be represented by a diamond
shape, or more simply, by the line connecting the entities. In either case, verbs are used to label the
relationships.

7
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
 Training, Teaching and Learning Materials (TTLM)

The cardinality defines the relationship between the entities in terms of numbers.The three main cardinal
relationships are: one-to-one, expressed as 1:1; one-to-many, expressed as 1:M; and many-to-many,
expressed as M:N.
The steps involved in creating an ERD are:
 Identify the entities.
 Determine all significant interactions.
 Analyze the nature of the interactions.
 Draw the ERD.
Entity Relationship Diagram Notations

developed ERDs in 1976. Since then Charles Bachman and James Martin have added some sligh refinements to the basic ERD
principles.

Entity
An entity is an object or concept about which you want to store information.

Weak Entity
A weak entity is an entity that must defined by a foreign key relationship with another entity as it cannot be uniquely identified by
its own attributes alone.

Key attribute
A key attribute is the unique, distinguishing characteristic of the entity. For example, an employee's social security number might
be the employee's key attribute.

Multivalued attribute
A multivalued attribute can have more than one value. For example, an employee entity can have multiple skill values.

Derived attribute
A derived attribute is based on another attribute. For example, an employee's monthly salary is based on the employee's annual
salary.

8
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
 Training, Teaching and Learning Materials (TTLM)

Relationships
Relationships illustrate how two entities share information in the database structure.

Cardinality
Cardinality specifies how many instances of an entity relate to one instance of another entity.

Ordinality is also closely linked to cardinality. While cardinality specifies the occurences of a relationship, ordinality describes the
relationship as either mandatory or optional. In other words, cardinality specifies the maximum number of relationships and
ordinality specifies the absolute minimum number of relationships.

Recursive relationship
In some cases, entities can be self-linked. For example, employees can supervise other employees.

9
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
 Training, Teaching and Learning Materials (TTLM)

1.1.4 DFD

Data Flow Diagram Notations

You can use two different types of notations on your data flow diagrams:Yourdon & Coad or Gane & Sarson.
Process Notations

10
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
 Training, Teaching and Learning Materials (TTLM)

Process
A process transforms incoming data flow into outgoing data flow.

Yourdon and Coad Process Notations

Gane and Sarson Process Notation

Datastore Notations

DataStore
Datastores are repositories of data in the system. They are sometimes also referred to as files.

Yourdon and Coad Datastore Notations

Gane and Sarson Datastore Notations

Dataflow Notations

Dataflow
Dataflows are pipelines through which packets of information flow. Label the arrows with the name of the data that moves through
it.

11
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
 Training, Teaching and Learning Materials (TTLM)

External Entity Notations

External Entity
External entities are objects outside the system, with which the system communicates. External entities are sources and
destinations of the system's inputs and outputs.

DFD levels
The first level DFD shows the main processes within the system. Each of these processes can be broken into further processes until
you reach pseudocode.

1.1.5 HIPO Charts

The HIPO (Hierarchy plus Input-Process-Output) technique is a tool for planning and/or
documenting a computer program. A HIPO model consists of a hierarchy chart that
graphically represents the program’s control structure and a set of IPO (Input-Process-
Output) charts that describe the inputs to, the outputs from, and the functions (or processes)
performed by each module on the hierarchy chart.

A completed HIPO package has two parts. A hierarchy chart is used to represent the top-down
structure of the program. For each module depicted on the hierarchy chart, an IPO (Input-
Process-Output) chart is used to describe the inputs to, the outputs from, and the process
performed by the module.

12
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
 Training, Teaching and Learning Materials (TTLM)

1.0  Manage inventory
2.0  Update stock
2.1  Process sale
2.2  Process return
2.3  Process shipment
3.0  Generate report
3.1  Respond to query
3.2  Display status report
4.0  Maintain inventory data
4.1  Modify record
4.2  Add record
4.3  Delete record

1.1.6 Data Structure

In computer science, a data structure is a particular way of storing and organizing data in a computer so that it can be
used efficiently.
Data structures provide a means to manage large amounts of data efficiently, such as large databases and
internet indexing services. Usually, efficient data structures are a key to designing efficient algorithms.
Some formal design methods and programming languages emphasize data structures, rather than algorithms,
as the key organizing factor in software design. Storing and retrieving can be carried out on data stored in
both main memory and in secondary memory.
 An array data structure stores a number of elements in a specific order. They are accessed using an
integer to specify which element is required (although the elements may be of almost any type).
Arrays may be fixed-length or expandable.
 Record (also called tuple or struct) Records are among the simplest data structures. A record is a
value that contains other values, typically in fixed number and sequence and typically indexed by
names. The elements of records are usually called fields or members.

13
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
 Training, Teaching and Learning Materials (TTLM)

 A hash or dictionary or map is a more flexible variation on a record, in which name-value pairs can
be added and deleted freely.
 Union. A union type definition will specify which of a number of permitted primitive types may be
stored in its instances, e.g. "float or long integer". Contrast with a record, which could be defined to
contain a float and an integer; whereas, in a union, there is only one value at a time.
 A tagged union (also called a variant, variant record, discriminated union, or disjoint union) contains
an additional field indicating its current type, for enhanced type safety.
 A set is an abstract data structure that can store specific values, without any particular order, and no
repeated values. Values themselves are not retrieved from sets, rather one test a value for
membership to obtain a boolean "in" or "not in".
 An object contains a number of data fields, like a record, and also a number of program code
fragments for accessing or modifying them. Data structures not containing code, like those above,
are called plain old data structure.

Basic principles
 Data structures are generally based on the ability of a computer to fetch and store data at any place in its
memory, specified by an address—a bit string that can be itself stored in memory and manipulated by
the program. Thus the record and array data structures are based on computing the addresses of data
items with arithmetic operations; while the linked data structures are based on storing addresses of data
items within the structure itself.
 The implementation of a data structure usually requires writing a set of procedures that create and
manipulate instances of that structure. The efficiency of a data structure cannot be analyzed separately
from those operations. This observation motivates the theoretical concept of an abstract data type, a data
structure that is defined indirectly by the operations that may be performed on it, and the mathematical
properties of those operations (including their space and time cost).

1.1.7 RAD

Rapid application development (RAD) is a software development methodology that uses minimal planning in favor
of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself.
The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change
requirements.
Rapid application development (RAD) is a software development methodology that uses minimal planning
in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing
the software itself. The lack of extensive pre-planning generally allows software to be written much faster,
and makes it easier to change requirements. RAD is not appropriate when technical risks are high.
Phases of RAD
1. Requirements Planning phase – combines elements of the system planning and systems analysis
phases of the Systems Development Life Cycle (SDLC). Users, managers, and IT staff members
discuss and agree on business needs, project scope, constraints, and system requirements. It ends
when the team agrees on the key issues and obtains management authorization to continue.
2. User design phase – during this phase, users interact with systems analysts and develop models and
prototypes that represent all system processes, inputs, and outputs. The RAD groups or subgroups
typically use a combination of Joint Application Development (JAD) techniques and CASE tools to
translate user needs into working models. User Design is a continuous interactive process that allows
users to understand, modify, and eventually approve a working model of the system that meets their
needs.
3. Construction phase – focuses on program and application development task similar to the SDLC. In
RAD, however, users continue to participate and can still suggest changes or improvements as actual
screens or reports are developed. Its tasks are programming and application development, coding,
unit-integration and system testing.
4. Cutover phase – resembles the final tasks in the SDLC implementation phase, including data
conversion, testing, changeover to the new system, and user training. Compared with traditional

14
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
 Training, Teaching and Learning Materials (TTLM)

methods, the entire process is compressed. As a result, the new system is built, delivered, and placed
in operation much sooner.

Practical implications
When organizations adopt rapid development methodologies, care must be taken to avoid role and
responsibility confusion and communication breakdown within a development team, and between team and
client. In addition, especially in cases where the client is absent or not able to participate with authority in
the development process, the system analyst should be endowed with this authority on behalf of the client to
ensure appropriate prioritization of non-functional requirements. Furthermore, no increment of the system
should be developed without a thorough and formally documented design phase.

1.1.8 CASE Tools

CASE (computer-aided software engineering)

 E-Mail
 Print
 A
 AA
 AAA
 inShare
 Facebook
 Twitter
 Share This
 RSS

15
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
 Training, Teaching and Learning Materials (TTLM)

 Reprints
CASE (computer-aided software engineering) is the use of a computer-assisted method to organize and
control the development of software, especially on large, complex projects involving many software
components and people. Using CASE allows designers, code writers, testers, planners, and managers to
share a common view of where a project stands at each stage of development. CASE helps ensure a
disciplined, check-pointed process. A CASE tool may portray progress (or lack of it) graphically. It may also
serve as a repository for or be linked to document and program libraries containing the project's business
plans, design requirements, design specifications, detailed code specifications, the code units, test cases
and results, and marketing and service plans.

Computer-aided software engineering (CASE) is the scientific application of a set of tools and methods to a
software system with the desired end result of high-quality, defect-free, and maintainable software products.
It also refers to methods for the development of information systems together with automated tools that can
be used in the software development process

Components
1. Diagrammatic Tools
2. Information Repository
3. Interface Generators
4. Management Tools

Tools
CASE tools are a class of software that automates many of the activities involved in various life cycle
phases. For example, when establishing the functional requirements of a proposed application, prototyping
tools can be used to develop graphic models of application screens to assist end users to visualize how an
application will look after development. Subsequently, system designers can use automated design tools to
transform the prototyped functional requirements into detailed design documents. Programmers can then use
automated code generators to convert the design documents into code. Automated tools can be used
collectively, as mentioned, or individually. For example, prototyping tools could be used to define
application requirements that get passed to design technicians who convert the requirements into detailed
designs in a traditional manner using flowcharts and narrative documents, without the assistance of
automated design software.

Types of tools are:

 Business process engineering tools.  Analysis and design tools
 Process modeling and management tool  Interface design and development tools
 Project planning tools.  Prototyping tools
 Risk analysis tools  Programming tools
 Project management tools  Web development tools
 Requirement tracing tools  Integration and testing tools
 Metrics management tools  Static analysis tools
 Documentation tools  Dynamic analysis tools
 System software tools  Test management tools
 Quality assurance tools  Client/Server testing tools
 Database management tools  Re-engineering tools
 Software configuration management tools

16
Date: September, 2017
TLM Development Manual
Compiled by: ICT Department
MODULE TITLE: Designing Program Logic

Existing CASE tools can be classified along 4 different dimensions:

1. Life-cycle support
2. Integration dimension
3. Construction dimension
4. Knowledge-based CASE dimension

Life-Cycle Based CASE Tools

 This dimension classifies CASE Tools on the basis of the activities they support in the information systems
life cycle. They can be classified as Upper or Lower CASE tools.
 Upper CASE Tools support strategic planning and construction of concept-level products and ignore
the design aspect. They support traditional diagrammatic languages such as ER diagrams, Data flow
diagram, Structure charts, Decision Trees, Decision tables, etc.,,
 Lower CASE Tools concentrate on the back end activities of the software life cycle, such as physical
design, debugging, construction, testing, component integration, maintenance, re engineering and
reverse engineering.

Integration dimension
 Three main CASE Integration dimensions have been proposed CASE Framework
1. ICASE Tools
2. Integrated Project Support Environment(IPSE)

Applications
 All aspects of the software development life cycle can be supported by software tools, and so the use of
tools from across the spectrum can, arguably, be described as CASE; from project management software
through tools for business and functional analysis, system design, code storage, compilers, translation tools,
test software, and so on.
 However, tools that are concerned with analysis and design, and with using design information to create
parts (or all) of the software product, are most frequently thought of as CASE tools. CASE applied, for
instance, to a database software product, might normally involve:
 Modeling business / real-world processes and data flow
 Development of data models in the form of entity-relationship diagrams
 Development of process and function descriptions

17
MODULE TITLE: Designing Program Logic

1.1.9 Prototyping

Software prototyping, refers to the activity of creating prototypes of software applications, i.e., incomplete versions of
the software program being developed. It is an activity that can occur in software development and is comparable
to prototyping as known from other fields, such as mechanical engineering or manufacturing.

A prototype typically simulates only a few aspects of, and may be completely different from, the final product.

Prototyping has several benefits: The software designer and implementer can get valuable feedback from the users early in the
project. The client and the contractor can compare if the software made matches the software specification, according to which
the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and
whether the deadlines and milestones proposed can be successfully met.

A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or
learned from. It is a term used in a variety of contexts, including semantics, design, electronics, and software
programming. A prototype is designed to test and trial a new design to enhance precision by system analysts
and users.

Basic prototype categories

Here is no general agreement on what constitutes a "prototype" and the word is often used interchangeably
with the word "model" which can cause confusion. In general, "prototypes" fall into five basic categories:-
1. Proof-of-Principle Prototype (Model) (in electronics sometimes built on a breadboard). A Proof of
concept prototype is used to test some aspect of the intended design without attempting to exactly
simulate the visual appearance, choice of materials or intended manufacturing process. Such prototypes
can be used to "prove" out a potential design approach such as range of motion, mechanics, sensors,
architecture, etc. These types of models are often used to identify which design options will not work, or
where further development and testing is necessary.
2. Form Study Prototype (Model). This type of prototype will allow designers to explore the basic size,
look and feel of a product without simulating the actual function or exact visual appearance of the
product. Form Study Prototypes are often hand-carved or machined models from easily sculpted,
inexpensive materials (e.g., urethane foam), without representing the intended color, finish, or texture.
Due to the materials used, these models are intended for internal decision making.
3. User Experience Prototype (Model). A User Experience Model invites active human interaction and is
primarily used to support user focused research. While intentionally not addressing possible aesthetic
treatments, this type of model does more accurately represent the overall size, proportions, interfaces, and
articulation of a promising concept. This type of model allows early assessment of how a potential user
interacts with various elements, motions, and actions of a concept which define the initial use scenario
and overall user experience. As these models are fully intended to be used and handled, more robust
construction is key. Materials typically include plywood, REN shape, RP processes and CNC machined
components. Construction of user experience models is typically driven by preliminary CAID/CAD
which may be constructed from scratch.
4. Visual Prototype (Model) will capture the intended design aesthetic and simulate the appearance, color
and surface textures of the intended product but will not actually embody the function(s) of the final
product. These models will be suitable for use in market research, executive reviews and approval,
packaging mock-ups, and photo shoots for sales literature.

18
MODULE TITLE: Designing Program Logic

5. Functional Prototype (Model) (also called a working prototype) will, to the greatest extent practical,
attempt to simulate the final design, aesthetics, materials and functionality of the intended design. The
functional prototype may be reduced in size (scaled down) in order to reduce costs. The construction of a
fully working full-scale prototype and the ultimate test of concept is the engineers' final check for design
flaws and allow last-minute improvements to be made before larger production runs are ordered.

1.1.10 Modular programming

"Modular Programming" is the act of designing and writing programs as interactions among
functions that each perform a single well-defined function, and which have minimal side-effect
interaction between them. 
Modular programming is the process of subdividing a computer program into separate sub-programs.

A module is a separate software component. It can often be used in a variety of applications and functions with
other components of the system. Similar functions are grouped in the same unit of programming code and separate
functions are developed as separate units of code so that the code can be reused by other applications.
19
MODULE TITLE: Designing Program Logic

Object-oriented programming (OOP) is compatible with the modular programming concept to a large extent.
Modular programming enables multiple programmers to divide up the work and debug pieces of the program
independently.
The benefits of using modular programming include:

 Less code has to be written.

 A single procedure can be developed for reuse, eliminating the need to retype the code many times.
 Programs can be designed more easily because a small team deals with only a small part of the entire code.
 Modular programming allows many programmers to collaborate on the same application.
 The code is stored across multiple files.
 Code is short, simple and easy to understand.
 Errors can easily be identified, as they are localized to a subroutine or function.
 The same code can be used in many applications.
 The scoping of variables can easily be controlled.

1.2 Taking design approach in coding the modules

LO2 Document the program logic or design

2.1 Structuring diagrams of flow and modules
2.1.1 Visio

2.1.2 Smart Draw

2.2 Documenting program scope and limits

The Scope Statement is an essential element of any project. Project managers use the Scope Statement as a written confirmation of
the results your project will produce and the constraints and assumptions under which you will work. Both the people who requested
the project and the project team should agree to all terms in the Scope Statement before actual project work begins.

A good Scope Statement includes the following information:

 Justification: A brief statement regarding the business need your project addresses. (A more detailed discussion of the
justification for the project appears in the project charter.)
 Product scope description: The characteristics of the products, services, and/or results your project will produce.
 Acceptance criteria: The conditions that must be met before project deliverables are accepted.
 Deliverables: The products, services, and/or results your project will produce (also referred to as objectives).
 Project Exclusions: Statements about what the project will not accomplish or produce.
 Constraints: Restrictions that limit what you can achieve, how and when you can achieve it, and how much achieving it can
cost.
 Assumptions: Statements about how you will address uncertain information as you conceive, plan, and perform your project.

2.3 Documenting special routines or procedures

20
MODULE TITLE: Designing Program Logic

2.4 Identifying and revising references for tables, inputs, outputs other programs

2.1 Applying Templates

Template metaprogramming (TMP) is a metaprogramming technique in which templates are used by a compiler to

generate temporary source code, which is merged by the compiler with the rest of the source code and then compiled.
The output of these templates include compile-time constants, data structures, and complete functions. The use of
templates can be thought of ascompile-time execution. 
LO3 Validate the design

3.1 Checking program flow, states or conditions

3.1.1 Interfaces and compliance to design documentation requirement

Gaining feedback or input from appropriate person

21