Learning Outcome 1:

Select the program logic design approach

Program Design: Logic Models
A logic model is a tool used to design and build the evaluation of programs. It uses a simple
visual to represent the relationship between the challenge or problem, the resources available, the
activities and the goals of the program. Logic models demonstrate the causal relationship
between what you put into a relationship and what you hope to get out of it.

We recommend using a logic model to help build all of your programs and services. Logic
models can help you identify your expectations and assumptions of your program by having you
outline your inputs, your activities, your outputs and your outcomes in one succinct form. Logic
models can help you guide your work throughout the implementation process and help you build
your evaluation framework to ensure you can demonstrate your impact.

Learning Objectives:

 To understand the purpose and value of using logic models in program design.
 To identify the major components of a logic model.
 To understand how to use logic models in your work.
 To understand how to identify program/project assumptions and potential weaknesses

UNDERSTANDING COMPUTER COMPONENTS AND OPERATIONS

Hardware and software are the two major components of any computer system. Hardware is the
equipment, or the devices, associated with a computer. For a computer to be useful, however, it
needs more than equipment; a computer needs to be given instructions. The instructions that tell
the computer what to do are called software, or programs, and are written by programmers. This
book focuses on the process of writing these instructions.
Software can be classified as application software or system software. Application software
comprises all the programs you apply to a task—word-processing programs, spreadsheets,
payroll and inventory programs, and even games. System software comprises the programs that
you use to manage your computer—operating systems, such as Windows, Linux, or UNIX. This
book focuses on the logic used to write application software programs, although many of the
concepts apply to both types of software.
Together, computer hardware and software accomplish four major operations:
1. Input
2. Processing
3. Output
4. Storage
Hardware devices that perform input include keyboards and mice. Through these devices, data,
or facts, enter the computer system. Processing data items may involve organizing them,
checking them for accuracy, or performing mathematical operations on them. The piece of
hardware that performs these sorts of tasks is the central processing unit, or CPU. After data
items have been processed, the resulting information is sent to a printer, monitor, or some other
output device so people can view, interpret, and use the results. Often, you also want to store the

1
output information on storage hardware, such as magnetic disks, tapes, compact discs, or flash
media. Computer software consists of all the instructions that control how and when the data
items are input, how they are processed, and the form in which they are output or stored.
Data includes all the text, numbers, and other information that are processed by a computer.
However, many computer professionals reserve the term “information” for data that has been
processed. For example, your name, Social Security number, and hourly pay rate are data items,
but your paycheck holds information.
Computer hardware by itself is useless without a programmer’s instructions, or software, just as
your stereo equipment doesn’t do much until you provide music on a CD or tape. You can buy
prewritten software that is stored on a disk or that you download from the Internet or you can
write your own software instructions. You can enter instructions into a computer system through
any of the hardware devices you use for data; most often, you type your instructions using a
keyboard and store them on a device such as a disk or CD.
You write computer instructions in a computer programming language, such as Visual Basic, C#,
C++, Java, or COBOL. Just as some people speak English and others speak Japanese,
programmers also write programs in different languages. Some programmers work exclusively in
one language, whereas others know several and use the one that seems most appropriate for the
task at hand.
No matter which programming language a computer programmer uses, the language has rules
governing its word usage and punctuation. These rules are called the language’s syntax. If you
ask, “How the get to store do I?” in English, most people can figure out what you probably
mean, even though you have not used proper English syntax. However, computers are not nearly
as smart as most people; with a computer, you might as well have asked, “Xpu mxv ot dodnm
Cadf B?” Unless the syntax is perfect, the computer cannot interpret the programming language
instruction at all.
Every computer operates on circuitry that consists of millions of on/off switches. Each
programming language uses a piece of software to translate the specific programming language
into the computer’s on/off circuitry language, or machine language. The language translation
software is called a compiler or interpreter, and it tells you if you have used a programming
language incorrectly. Therefore, syntax errors are relatively easy to locate and correct—the
compiler or interpreter you use highlights every syntax error. If you write a computer program
using a language such as C++ but spell one of its words incorrectly or reverse the proper order of
two words, the translator lets you know that it found a mistake by displaying an error message as
soon as you try to translate the program.

Although there are differences in how compilers and interpreters work, their basic function is the
same—to translate your programming statements into code the computer can use.
When you use a compiler, an entire program is translated before it can execute; when you use an
interpreter, each instruction is translated just prior to execution. Usually, you do not choose
which type of translation to use—it depends on the programming language.
However, there are some languages for which both compilers and interpreters are available.
A program without syntax errors can be executed on a computer, but it might not produce correct
results. For a program to work properly, you must give the instructions to the computer in a
specific sequence, you must not leave any instructions out, and you must not add extraneous
instructions. By doing this, you are developing the logic of the computer program. Suppose you
instruct someone to make a cake as follows:

2
 Stir
Add two eggs
Add a gallon of gasoline
Bake at 350 degrees for 45 minutes
Add three cups of flour
Even though you have used the English language syntax correctly, the instructions are out of
sequence, some instructions are missing, and some instructions belong to procedures other than
baking a cake. If you follow these instructions, you are not going to end up with an edible cake,
and you may end up with a disaster. Logical errors are much more difficult to locate than syntax
errors; it is easier for you to determine whether “eggs” is spelled incorrectly in a recipe than it is
for you to tell if there are too many eggs or if they are added too soon.

Programmers often call logical errors semantic errors. For example, if you misspell a
programming language word, you commit a syntax error, but if you use an otherwise correct
word that does not make any sense in the current context, you commit a semantic error.
Just as baking directions can be given correctly in French, German, or Spanish, the same logic of
a program can be expressed in any number of programming languages. This note is almost
exclusively concerned with the logic development process. Because it is not concerned with any
specific language, the programming examples could have been written in Japanese, C++, or Java.
The logic is the same in any language. For convenience, we use English!
Once instructions have been input to the computer and translated into machine language, a
program can be run, or executed. You can write a program that takes a number (an input step),
doubles it (processing), and tells you the answer (output) in a programming language such as
Java or C++, but if you were to write it using English-like statements, it would look like this:
 Get input Number.
 Compute calculated Answer as input Number times 2.
 Print calculated Answer.
You will learn about the odd elimination of the space between words like “input” and
“Number” and “calculated” and “Answer” in the next few pages.
The instruction to get inputNumber is an example of an input operation. When the computer
interprets this instruction, it knows to look to an input device to obtain a number. Computers
often have several input devices, perhaps a keyboard, a mouse, a CD drive, and two or more disk
drives. When you learn a specific programming language, you learn how to tell the computer
which of those input devices to access for input. Logically, however, it doesn’t really matter
which hardware device is used, as long as the computer knows to look for a number. The logic of
the input operation that the computer must obtain a number for input, and that the computer must
obtain it before multiplying it by two—remains the same regardless of any specific input
hardware device. The same is true in your daily life. If you follow the instruction “Get eggs from
store,” it does not really matter if you are following a handwritten instruction from a list or a
voice-mail instruction left on your cell phone—the process of getting the eggs, and the result of
doing so, are the same.

Processing is the step that occurs when the arithmetic is performed to double the inputNumber;
the statement Compute calculatedAnswer as inputNumber times 2 represents processing.
Mathematical operations are not the only kind of processing, but they are very typical. After you

3
write a program, the program can be used on computers of different brand names, sizes, and
speeds. Whether you use an IBM, Macintosh, Linux, or UNIX operating system, and whether
you use a personal computer that sits on your desk or a mainframe that costs hundreds of
thousands of dollars and resides in a special building in a university, multiplying by 2 is the same
process. The hardware is not important; the processing will be the same.
In the number-doubling program, the Print calculatedAnswer statement represents output. Within
a particular program, this statement could cause the output to appear on the monitor (which
might be a flat panel screen or a cathode-ray tube), or the output could go to a printer (which
could be laser or ink-jet), or the output could be written to a disk or CD. The logic of the process
called “Print” is the same no matter what hardware device you use.
Besides input, processing, and output, the fourth operation in any computer system is storage.
When computers produce output, it is for human consumption. For example, output might be
displayed on a monitor or sent to a printer.
Storage, on the other hand, is meant for future computer use (for example, when data items are
saved on a disk).
Computer storage comes in two broad categories. All computers have internal storage, often
referred to as memory, main memory, primary memory, or random access memory (RAM). This
storage is located inside the system unit of the machine. (For example, if you own a
microcomputer, the system unit is the large case that holds your CD or other disk drives. On a
laptop computer, the system unit is located beneath the keyboard.) Internal storage is the type of
storage most often discussed before.
Computers also use external storage, which is persistent (relatively permanent) storage on a
device such as a floppy disk, hard disk, flash media, or magnetic tape. In other words, external
storage is outside the main memory, not necessarily outside the computer. Both programs and
data sometimes are stored on each of these kinds of media.
To use computer programs, you must first load them into memory. You might type a program
into memory from the keyboard, or you might use a program that has already been written and
stored on a disk. Either way, a copy of the instructions must be placed in memory before the
program can be run.
A computer system needs both internal memory and external storage. Internal memory is needed
to run the programs, but internal memory is volatile—that is, its contents are lost every time the
computer loses power. Therefore, if you are going to use a program more than once, you must
store it, or save it, on some nonvolatile medium. Otherwise, the program in main memory is lost
forever when the computer is turned off. External storage (usually disks or tape) provides a
nonvolatile (or persistent) medium.

Once you have a copy of a program in main memory, you want to execute, or run, the program.
To do so, you must also place any data that the program requires into memory. For example,
after you place the following program into memory and start to run it, you need to provide an
actual inputNumber—for example, 8 that you also place in main memory.
 Get inputNumber.
 Compute calculatedAnswer as inputNumber times 2.
 Print calculatedAnswer.
 The inputNumber is placed in memory at a specific memory location that the program
will call inputNumber.
Then, and only then, can the calculatedAnswer, in this case 16, be calculated and printed.

4
Definition of Project logical model

What is a logic model?

A logic model presents a picture of how your effort or initiative is supposed to work. It explains
why your strategy is a good solution to the problem at hand. Effective logic models make an
explicit, often visual, statement of the activities that will bring about change and the results you
expect to see for the community and its people. A logic model keeps participants in the effort
moving in the same direction by providing a common language and point of reference.

More than an observer's tool, logic models become part of the work itself. They energize and
rally support for an initiative by declaring precisely what you're trying to accomplish and how.

In this section, the term logic model is used as a generic label for the many ways of displaying
how change unfolds.

Some other names include:

 road map, conceptual map, or pathways map

 mental model
 blueprint for change
 framework for action or program framework
 program theory or program hypothesis
 theoretical underpinning or rationale
 causal chain or chain of causation
 theory of change or model of change

Each mapping or modeling technique uses a slightly different approach, but they all rest on a
foundation of logic - specifically, the logic of how change happens. By whatever name you call
it, a logic model supports the work of health promotion and community development by charting
the course of community transformation as it evolves.

Program logic

Program logic also goes under several other names: program theory, logic modelling, program
logic models, theory of action, and theory-based evaluation. If you're searching for information
about it on the Web, you'll need to look under all those names. The "programs" here are
programs of planned action in general - usually not computer programs, radio programs, or TV
programs. Program logic models, on which this page is focusing, are produced in a wide variety
of different forms, with this common basis:

 A program is defined as a sequence of objectives.

 Usually the designers begin with an desired social impact in mind, and work back from
that goal to determine what must be done to accomplish it.
 To achieve that impact, some intermediate goals (outcomes) must first be reached.
 To attain those outcomes, the program must produce some outputs.

5
  To produce the outputs, activities are required.
 And in order to do the activities, inputs or resources are needed.

A simplified form of the sequence can be shown thus:

The diagram is very abstract, so let's create an example to show how the model can work: a radio
program designed to educate people about how to prevent malaria. (This is a very simple
example, with only a single chain. Real examples are a lot more complex.)

 The inputs are the money, labour, and facilities needed to produce the program.
 The activity is producing and broadcasting the program.
 The output is that some people hear the program.
 The outcome is that some of those listeners act on the program's advice.
 The impact is that malaria in that area is reduced.

The power of logic modelling is that each step in the chain can be evaluated in a way that's most
appropriate at that point.

 Did the inputs (money etc.) really produce the activities (the broadcast)? That question
can be answered by auditing.
 And did the activities produce the output (an informed audience)? An audience survey
could answer that question.
 Did the output produce the outcome (how many listeners acted on the advice)? The
audience survey could answer that, too.
 To measure the impacts, public health statistics could be used, perhaps comparing the
area where the program was broadcast with a matching area where it was not.

As you move to the right along the causal chain, it gets more difficult to provide clear answers -
e.g. if malaria really was reduced, was it because of that radio program, or for various other
reasons?

But the principle is that you specify what you hope will happen, in the form of a chain, and then
test each link in the chain to work out what really did happen. That's program logic modelling in
a nutshell. At first it seems like a ridiculously cumbersome way of stating the obvious, but its
value in practice lies in that step-by-step testing. If the program didn't work as intended, you can
detect the weak links in the logic chain.

The above diagram is represented as a chain, implying that no stage can occur until all previous
stages are complete. In that sense, it resembles a chain scenario (or sequence of possible future
events): the main difference is that program logic embodies one overriding intention, while a
scenario does not. The problem with this type of thinking is that (though its truth seems obvious)
the world doesn't always work like that. This "hierarchy of effects" approach, as it's sometimes
called, just doesn't correspond with reality. For example, there's the famous AIDA model of

6
marketing. This means that A (awareness) happens first - people become aware of a product.
Then It happens: they're interested in it. Then it's D: they Desire it. Finally, they Acquire it.

Program Design Logic

Program Design Logic (or PDL, for short) is a method for designing and documenting methods
and procedures in software. It is related to pseudocode, but unlike pseudocode, it is written in
plain language without any terms that could suggest the use of any programming language or
library.
PDL was originally developed by the company Caine, Farber & Gordon and has been modified
substantially since they published their initial paper on it in 1975. It has been described in some
detail by Steve McConnell in his book Code Complete.
Programming paradigm
A programming paradigm is a fundamental style of computer programming, which is not
generally dictated by the project management methodology (such as waterfall or agile).
Paradigms differ in the concepts and abstractions used to represent the elements of a program
(such as objects, functions, variables, constraints) and the steps that comprise a computation
(such as assignations, evaluation, continuations, data flows). Sometimes the concepts asserted by
the paradigm are utilized cooperatively in high-level system architecture design; in other cases,
the programming paradigm's scope is limited to the internal structure of a particular program or
module.
A programming language can support multiple paradigms. For example, programs written in
C++ or Object Pascal can be purely procedural, or purely object-oriented, or contain elements of
both paradigms. Software designers and programmers decide how to use those paradigm
elements. In object-oriented programming, programmers can think of a program as a collection
of interacting objects, while in functional programming a program can be thought of as a
sequence of stateless function evaluations. When programming computers or systems with many
processors, process-oriented programming allows programmers to think about applications as
sets of concurrent processes acting upon logically shared data structures.
Just as different groups in software engineering advocate different methodologies, different
programming languages advocate different programming paradigms. Some languages are
designed to support one paradigm (Smalltalk supports object-oriented programming, Haskell
supports functional programming), while other programming languages support multiple
paradigms (such as Object Pascal, C++, C#, Visual Basic, Common Lisp, Scheme, Python,
Ruby, and Oz).
Many programming paradigms are as well known for what methods they forbid as for what they
enable. For instance, pure functional programming forbids using side-effects; structured
programming forbids using goto statements. Partly for this reason, new paradigms are often
regarded as doctrinaire or overly rigid by those accustomed to earlier styles. Avoiding certain

7
methods can make it easier to prove theorems about a program's correctness, or simply to
understand its behavior.

Software design
Software development is the process of conceiving, specifying, designing, programming,
documenting, testing, and bug fixing involved in creating and maintaining applications,
frameworks, or other software components. Software development is a process of writing and
maintaining the source code, but in a broader sense, it includes all that is involved between the
conception of the desired software through to the final manifestation of the software, sometimes
in a planned and structured process. Therefore, software development may include research, new
development, prototyping, modification, reuse, re-engineering, maintenance, or any other
activities that result in software products.
Software can be developed for a variety of purposes, the three most common being to meet
specific needs of a specific client/business (the case with custom software), to meet a perceived
need of some set of potential users (the case with commercial and open source software), or for
personal use (e.g. a scientist may write software to automate a mundane task). Embedded
software development, that is, the development of embedded software, such as used for
controlling consumer products, requires the development process to be integrated with the
development of the controlled physical product. System software underlies applications and the
programming process itself, and is often developed separately.
The need for better quality control of the software development process has given rise to the
discipline of software engineering, which aims to apply the systematic approach exemplified in
the engineering paradigm to the process of software development.

Core activities of software development includes

A software development process (also known as a software development methodology, model, or
life cycle) is a framework that is used to structure, plan, and control the process of developing
information systems. A wide variety of such frameworks has evolved over the years, each with
its own recognized strengths and weaknesses. There are several different approaches to software
development: some take a more structured, engineering-based approach to developing business
solutions, whereas others may take a more incremental approach, where software evolves as it is
developed piece-by-piece. One system development methodology is not necessarily suitable for
use by all projects. Each of the available methodologies is best suited to specific kinds of
projects, based on various technical, organizational, project and team considerations.
Most methodologies share some combination of the following stages of software development:
 Analyzing the problem
 Market research
 Gathering requirements for the proposed business solution
 Devising a plan or design for the software-based solution
 Implementation (coding) of the software

8
  Testing the software
 Deployment
 Maintenance and bug fixing
These stages are often referred to collectively as the software development lifecycle, or SDLC.
Different approaches to software development may carry out these stages in different orders, or
devote more or less time to different stages. The level of detail of the documentation produced at
each stage of software development may also vary. These stages may also be carried out in turn
(a “waterfall” based approach), or they may be repeated over various cycles or iterations (a more
"extreme" approach). The more extreme approach usually involves less time spent on planning
and documentation, and more time spent on coding and development of automated tests. More
“extreme” approaches also promote continuous testing throughout the development lifecycle, as
well as having a working (or bug-free) product at all times. More structured or “waterfall” based
approaches attempt to assess the majority of risks and develop a detailed plan for the software
before implementation (coding) begins, and avoid significant design changes and re-coding in
later stages of the software development lifecycle planning.
There are significant advantages and disadvantages to the various methodologies, and the best
approach to solving a problem using software will often depend on the type of problem. If the
problem is well understood and a solution can be effectively planned out ahead of time, the more
"waterfall" based approach may work the best. If, on the other hand, the problem is unique (at
least to the development team) and the structure of the software solution cannot be easily
envisioned, then a more "extreme" incremental approach may work best.
Identification of need (Analyzing the problem)
The sources of ideas for software products are plenteous. These ideas can come from market
research including the demographics of potential new customers, existing customers, sales
prospects who rejected the product, other internal software development staff, or a creative third
party. Ideas for software products are usually first evaluated by marketing personnel for
economic feasibility, for fit with existing channels distribution, for possible effects on existing
product lines, required features, and for fit with the company's marketing objectives. In a
marketing evaluation phase, the cost and time assumptions become evaluated. A decision is
reached early in the first phase as to whether, based on the more detailed information generated
by the marketing and development staff, the project should be pursued further.
Students of engineering learn engineering and are rarely exposed to finance or marketing.
Students of marketing learn marketing and are rarely exposed to finance or engineering. Most of
us become specialists in just one area. To complicate matters, few of us meet interdisciplinary
people in the workforce, so there are few roles to mimic. Yet, software product planning is
critical to the development success and absolutely requires knowledge of multiple disciplines.
Because software development may involve compromising or going beyond what is required by
the client, a software development project may stray into less technical concerns such as human
resources, risk management, intellectual property, budgeting, crisis management, etc. These

9
processes may also cause the role of business development to overlap with software
development.
Planning
Planning is an objective of each and every activity, where we want to discover things that belong
to the project. An important task in creating a software program is extracting the requirements or
requirements analysis. Customers typically have an abstract idea of what they want as an end
result but do not know what software should do. Skilled and experienced software engineers
recognize incomplete, ambiguous, or even contradictory requirements at this point. Frequently
demonstrating live code may help reduce the risk that the requirements are incorrect.
"Although much effort is put in the requirements phase to ensure that requirements are complete
and consistent, rarely that is the case; leaving the software design phase as the most influential
one when it comes to minimizing the effects of new or changing requirements. Requirements
volatility is challenging because they impact future or already going development efforts."
Once the general requirements are gathered from the client, an analysis of the scope of the
development should be determined and clearly stated. This is often called a scope document.
Designing
Once the requirements are established, the design of the software can be established in a software
design document. This involves a preliminary or high-level design of the main modules with an
overall picture (such as a block diagram) of how the parts fit together. The language, operating
system, and hardware components should all be known at this time. Then a detailed or low-level
design is created, perhaps with prototyping as proof-of-concept or to firm up requirements.
Implementation, testing and documenting
Implementation is the part of the process where software engineers actually program the code for
the project.
Software testing is an integral and important phase of the software development process. This
part of the process ensures that defects are recognized as soon as possible. In some processes,
generally known as test-driven development, tests may be developed just before implementation
and serve as a guide for the implementation's correctness.
Documenting the internal design of software for the purpose of future maintenance and
enhancement is done throughout development. This may also include the writing of an API, be it
external or internal. The software engineering process chosen by the developing team will
determine how much internal documentation (if any) is necessary. Plan-driven models (e.g.,
Waterfall) generally produce more documentation than Agile models.
Deployment and maintenance
Deployment starts directly after the code is appropriately tested, approved for release, and sold
or otherwise distributed into a production environment. This may involve installation,

10
customization (such as by setting parameters to the customer's values), testing, and possibly an
extended period of evaluation.
Software training and support is important, as software is only effective if it is used correctly.
Maintaining and enhancing software to cope with newly discovered faults or requirements can
take substantial time and effort, as missed requirements may force redesign of the software.
There are many approaches to software project management, known as software development
life cycle models, methodologies, processes, or models. The waterfall model is a traditional
version, contrasted with the more recent innovation of agile software development.

Design Concepts
The design concepts provide the software designer with a foundation from which more
sophisticated methods can be applied. A set of fundamental design concepts has evolved. They
are as follows:
Abstraction - Abstraction is the process or result of generalization by reducing the information
content of a concept or an observable phenomenon, typically in order to retain only information
which is relevant for a particular purpose. It is an act of representing essential features without
including the background details or explanations.
Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a
macroscopic statement of function in a step-wise fashion until programming language statements
are reached. In each step, one or several instructions of a given program are decomposed into
more detailed instructions. Abstraction and Refinement are complementary concepts.
Modularity - Software architecture is divided into components called modules.
Software Architecture - It refers to the overall structure of the software and the ways in which
that structure provides conceptual integrity for a system. Good software architecture will yield a
good return on investment with respect to the desired outcome of the project, e.g. in terms of
performance, quality, schedule and cost.
Control Hierarchy - A program structure that represents the organization of a program
component and implies a hierarchy of control.
Structural Partitioning - The program structure can be divided both horizontally and vertically.
Horizontal partitions define separate branches of modular hierarchy for each major program
function. Vertical partitioning suggests that control and work should be distributed top down in
the program structure.
Data Structure - It is a representation of the logical relationship among individual elements of
data.
Software Procedure - It focuses on the processing of each module individually.

11
Information Hiding - Modules should be specified and designed so that information contained
within a module is inaccessible to other modules that have no need for such information.
In his object model, Grady Booch mentions Abstraction, Encapsulation, Modularization, and
Hierarchy as fundamental software design principles. The acronym PHAME (Principles of
Hierarchy, Abstraction, Modularization, and Encapsulation) is sometimes used to refer to these
four fundamental principles.

Design considerations
There are many aspects to consider in the design of a piece of software. The importance of each
consideration should reflect the goals and expectations that the software is being created to meet.
Some of these aspects are:
Compatibility - The software is able to operate with other products that are designed for
interoperability with another product. For example, a piece of software may be backward-
compatible with an older version of itself.
Extensibility - New capabilities can be added to the software without major changes to the
underlying architecture.
Modularity - the resulting software comprises well defined and independent components which
lead to better maintainability. The components could be then implemented and tested in isolation
before being integrated to form a desired software system. This allows division of work in a
software development project.
Fault-tolerance - The software is resistant to and able to recover from component failure.
Maintainability - A measure of how easily bug fixes or functional modifications can be
accomplished. High maintainability can be the product of modularity and extensibility.
Reliability (Software durability) - The software is able to perform a required function under
stated conditions for a specified period of time.
Reusability - The ability to use some or all of the aspects of the preexisting software in other
projects with little to no modification.
Robustness - The software is able to operate under stress or tolerate unpredictable or invalid
input. For example, it can be designed with resilience to low memory conditions.
Security - The software is able to withstand and resist hostile acts and influences.
Usability - The software user interface must be usable for its target user/audience. Default values
for the parameters must be chosen so that they are a good choice for the majority of the users.
Performance - The software performs its tasks within a time-frame that is acceptable for the user,
and does not require too much memory.
Portability - The software should be usable across a number of different conditions and
environments.

12
Scalability - The software adapts well to increasing data or number of users.

Software Design Approaches

Here are two generic approaches for software designing: Top-down and bottom-up design

Top-down and bottom-up are both strategies of information processing and knowledge ordering,
used in a variety of fields including software, humanistic and scientific theories and management
and organization. In practice, they can be seen as a style of thinking, teaching, or leadership.
A top-down approach (also known as stepwise design and in some cases used as a synonym of
decomposition) is essentially the breaking down of a system to gain insight into its compositional
sub-systems in a reverse engineering fashion. In a top-down approach an overview of the system
is formulated, specifying, but not detailing, any first-level subsystems. Each subsystem is then
refined in yet greater detail, sometimes in many additional subsystem levels, until the entire
specification is reduced to base elements. A top-down model is often specified with the
assistance of "black boxes", which makes it easier to manipulate. However, black boxes may fail
to clarify elementary mechanisms or be detailed enough to realistically validate the model. Top
down approach starts with the big picture. It breaks down from there into smaller segments.
A bottom-up approach is the piecing together of systems to give rise to more complex systems,
thus making the original systems sub-systems of the emergent system. Bottom-up processing is a
type of information processing based on incoming data from the environment to form a
perception. From a cognitive psychology perspective, information enters the eyes in one
direction (sensory input, or the "bottom"), and is then turned into an image by the brain that can
be interpreted and recognized as a perception (output that is "built up" from processing to final
cognition). In a bottom-up approach the individual base elements of the system are first specified
in great detail. These elements are then linked together to form larger subsystems, which then in
turn are linked, sometimes in many levels, until a complete top-level system is formed. This
strategy often resembles a "seed" model, by which the beginnings are small but eventually grow
in complexity and completeness. However, "organic strategies" may result in a tangle of
elements and subsystems, developed in isolation and subject to local optimization as opposed to
meeting a global purpose.

What is a Prototype? - Definition, Function & Theory

In the product development process, one of the key steps is creating a sample of the product
before it is manufactured. This lesson will explain what a prototype is and the benefits of using
one in your business.

What Is a Prototype?

You have a great idea for a new product. You can imagine in your mind how it will work and
how cool it will be when it's done. You can see in your mind how each of the pieces work
together and how much easier it makes your life. But putting that into words is a little

13
challenging. You go to work to make something physical that resembles the picture in your
mind. You create a rough mock-up of what the final product will look like.

You have just created a prototype. A prototype is an initial creation of a product that shows the
basics of what a product will look like, what the product will do, and how the product operates.
A prototype is not meant to be the final version; it's the rough draft form of the product. It will
often have elements that demonstrate how the product will work, even though the prototype may
not have the functionality that the final product will have after it is professionally manufactured.
The prototype helps you to get a solid idea of what the product will be and make alterations
while the item is still in concept mode.

Benefit of a Prototype

A prototype is a valuable tool in the product development process. It gives the inventor or the
creator a chance to see their idea come to life. By creating an initial example of your idea, you
have a chance to make changes to the design, work out problems in design, and make alterations
to make the product look nice. The prototype is essentially a rough draft of the product. Once the
prototype is created, steps can be taken to refine the product, both in design and function.

Prototypes may be used to demonstrate a potential product and can also be used as a tool to gain
financing or investments. When a potential investor can see what the item is you want to create,
they can get a better vision of what you want to produce and may be more interested in putting
their money towards the project.

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:

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

1. Business Modelling:

The core business models are decided and their priority of achievement is determined. The type
and flow of information are decided between different business models. What information will
be needed to decide the type of data structures and how will communication bridges between
different business services be established is determined during this process.

2. Data Modelling:

The next phase involves review and analysis of data objects in relation to the business model.
The attributes of these data sets are defined and their relevance to the business is clearly mapped
out.

3. Process Modelling:

The data sets and business models are aligned to create a flow of information for different
models. The process for development and change both are specified. In this stage, the process
structure for adding, deleting, modifying or retrieving a data set are set in place.

4. Testing & Turnover:

The very reason for the popularity of RAD is because it focuses more on testing and turnover.
Each prototype is tested by the user and feedback is collected. This feedback is used to modify
the existing project structure and implement changes in accordance with the user interaction with
the prototype. The test process is iterated for each prototype leading to fewer bugs in the final
application.

15
Advantages and Disadvantages of SDLC RAD Model

Advantages Disadvantages
 Flexible and adaptable to changes  It can't be used for smaller projects

 It is useful when you have to  Not all application is compatible with RAD
reduce the overall project risk
 It is adaptable and flexible to  When technical risk is high, it is not suitable
changes
 It is easier to transfer deliverables  If developers are not committed to delivering
as scripts, high-level abstractions software on time, RAD projects can fail
and intermediate codes are used
 Due to code generators and code  Reduced features due to time boxing, where
reuse, there is a reduction of features are pushed to a later version to finish a
manual coding release in short period

 Due to prototyping in nature, there  Reduced scalability occurs because a RAD

is a possibility of lesser defects developed application begins as a prototype
and evolves into a finished application

 Each phase in RAD delivers  Progress and problems accustomed are hard to
highest priority functionality to track as such there is no documentation to
client demonstrate what has been done

 With less people, productivity can  Requires highly skilled designers or developers
be increased in short time

When to use RAD Methodology?

 When a system needs to be produced in a short span of time (2-3 months)
 When the requirements are known
 When the user will be involved all through the life cycle
 When technical risk is less
 When there is a necessity to create a system that can be modularized in 2-3 months of
time
 When a budget is high enough to afford designers for modeling along with the cost of
automated tools for code generation

Few RADical Steps

Getting started with rapid application development generally follows a cyclical process that
includes four basic steps:

16
1. Planning Requirements: During this initial stage designers, developers, and users come to
a rough agreement on project scope and application requirements, so that future stages
with prototyping can begin.
2. User Design: User feedback is gathered with heavy emphasis on determining the system
architecture. This allows initial modeling and prototypes to be created. This step is
repeated as often as necessary as the project evolves.
3. Rapid Construction: Once basic user and system design has begun, the construction phase
is where most of the actual application coding, testing, and integration takes place. Along
with User Design, the Rapid Construction phase is repeated as often as necessary, as new
components are required or alterations are made to meet the needs of the project.
4. Cutover: The final Cutover (or Transition) stage allows the development team time to
move components to a live production environment, where any necessary full-scale
testing or team training can take place.

17