Introduction to the Program Development Life Cycle (PDLC)
Source: Computers in your Future © 2002 by Bryan Pfaffenberger
At the dawn of the modern computer era, no notion of managing the software development process existed.
Programs were written for well-defined purposes, such as calculating missile trajectories. If the program didn’t
work, the programmer corrected it, so this approach came to be known as code-and-fix (or “cut-an-run,” as
detractors put it).
When businesses began using computers for more-complex purposes, problems appeared. Often, it turned
out that programmers didn’t really understand what managers wanted the program to do, and correcting problems
turned into an expensive, time-consuming nightmare. Other problems appeared, too: programmers didn’t document
their programs well (if at all), and some developed idiosyncratic programming styles so that they could assure their
continued employment, since no one else could figure out what their code did! These early programs were almost
impossible to debug and maintain (especially if the original programmer had left the company).
To address these, problems, the program development life cycle was introduced in the 1970s, and is still in
widespread use today.
Program Development Life Cycle (A part of SDLC’s implementation phase and provides an organized plan for
breaking down the task of program development into manageable chunks, each of which must be successfully
completed before moving on to the next phase).






Defining the problem (The system analyst defines the program specifications)
o Program Specifications
 The Input Data
 The processing that should occur
 What the output should look like
 How the user interface should look
Designing the program (Specifies the components that make the program work)
o Identify the Main Routine – the program’s major activity
o Break down the main routine various components into smaller subroutines (modules)
 Control Structures
 Sequence control structure
 Selection control structure
 Repetition control structure
o Developing the Algorithm
o Developing design tools
 Structure (hierarchy) charts
 Flowchart or pseudocode
Coding the program (Translating the algorithm into specific program language instructions)
Testing and debugging the program (Eliminating all errors – visible and hidden. Some errors, however,
will surface only when the system is put into use.)
Formalizing the solution (Documenting the program both internally and externally)
o Internal Documentation (usually through comments as part of the program)
o External Documentation
 Description of files that the program needs to work with
 Layouts of output that the program produces
 Algorithm Design Tools
 Instruction Manual
 Overview of the program’s functionality
 Tutorials for beginning users
 In-depth explanations of major program features
 Reference documentation of all program commands
 Thorough description of the error messages generated by the program.
Implementing and maintaining the program (The programming team fixes program errors that users
discover)
o Discovering program errors that weren’t caught in the testing phase
o Periodically evaluating by asking whether the program is fulfilling its objectives that may lead to
1



modifications to update the program,
add features for the user, or
a decision to abandon the current system and develop a new one.
Program Development Life Cycle (An outline of each of the steps used to build software applications.)
Source: Visual Basic 6 Introductory Concepts and Techniques by Shelly, Cashman, Repede & Mick
1. Analyze the problem.
a. Precisely define the problem to be solved
b. Write the program specifications – descriptions of the program’s inputs, processing, outputs, and user
interface.
2. Design the program.
a. Develop a detailed logic plan using a tool such as pseudocode, flowcharts, object structure diagrams, or
event diagrams to group the program’s activities into modules.
b. Devise a method of solution or algorithm for each module.
c. Test the solution algorithms.
3. Code the program.
a. Translate the design into an application using a programming language or application development tool
by creating a user interface and writing code
b. Include internal documentation – comments and remarks within the code that explain the purpose of
code statements.
4. Test and debug the program.
a. Test the program, finding and correcting errors (debugging) until it is error free and contains enough
safeguards to ensure desired results.
5. Formalize the solution.
a. Review and, if necessary, revise internal documentation
b. Formalize and complete end-user (external) documentation
6. Maintain the program.
a. Provide education and support to end users
b. Correct any unanticipated errors that emerge and identify user-requested modifications(enhancements)
c. Once errors or enhancement are identified, the program development life cycle begins again in Step 1.
Program Development Cycle
Source: An Introduction to Programming Using VB 6.0 Update 4 th Edition © 2004, by David I Scheider
1. Analyze: Define the problem.
Be sure you understand what the program should do – that is, what the output should be. Have a clear idea
of what data (or input) are given and the relationship between the input and the desired output.
2. Design: Plan the solution to the problem.
Develop the algorithm (a logical sequence of precise steps that solve the problem). Every detail, including
obvious steps, should appear in the algorithm. Translate the algorithm into a logic plan using any of the
popular methods – flowcharts, pseudocode, top-down charts. These design tools help the programmer break
a problem into a sequence of small tasks the computer can perform to solve the problem. Planning also
involves using representative data to test the logic of the algorithm by hand to ensure that it is correct.
3. Choose the interface: Select the objects (text boxes, command buttons etc.)
Determine how the input will be obtained and how the output will be displayed. Then create objects to
receive the input and display the output. Also, create appropriate command buttons and menus to allow the
user to control the program.
4. Code: Translate the algorithm/flowchart/pseudocode into a programming language.
During this stage, the program is written in a particular language (e.g., Visual Basic) and entered into the
computer. The programmer/coder uses the algorithm/flowchart/pseudocode devised in Step 2 along with a
knowledge of the programming language, say, Visual Basic.
5. Test and debug. Locate and remove any errors in the program.
As the program is typed, Visual Basic points out certain types of program errors. Other types will detected
by Visual Basic when the program is executed; however, many errors due to typing mistakes, flaws in the
algorithm, or incorrect usages of the Visual Basic language rules can be uncovered and corrected only by
careful detective work. An example of such an error would be using addition when multiplication was the
proper operation.
6. Complete the documentation: Organize all the material that describes the program.
2
Documentation is intended to allow another person, or the programmer at a later date, to understand the
program. Internal documentation consists of statements in the program that are not executed, but point out
the purposes of various parts of the program. Documentation might also consist of a detailed description of
what the program does and how to use the program (for instance, what type of input is expected). For
commercial programs, documentation includes an instruction manual and on-line help. Other types of
documentation are the flowchart, pseudocode, and top-down chart that were used to construct the program.
Although documentation is listed as the last step in the program development cycle, it should take place as
the program is being coded.
Program Development Cycle
I.
Identify, specify, or determine the Problem.
II.
Analyze the Problem.
1.
Determine the data/info to be produced (output) as a solution of the problem. Variables required to
represent the output should also be defined as part of this step.
2.
Determine the data (called inputs) necessary to produce the outputs. As in Step a, variables required to
represent the input should be defined.
3.
Develop an algorithm for obtaining the outputs from the inputs in a finite number of steps.
Algorithm. An organized sequence of operations for solving a problem in a finite number of
steps. In the case of numerical problems, the algorithm consists of the sequence of
calculations necessary to obtain the desired outputs, but in the case of non-numerical
problems, the algorithm may include various text and graphics manipulation
operations along with numerical operations.
The main purpose of this step (Step II) is to make sure that you thoroughly understand the problem.
Remember: Any misconceptions in your problem analysis will be carried over into your
program. You can't expect a computer to make up for muddled analysis. As the old saying
goes: Garbage In = Garbage Out (GIGO)
III.
Outline the Program
Formulate the pseudocode, flowchart, structure chart, or other designing tools based on the algorithm.
Pseudocode. A collection of instructions, normally, a mixture of a natural language (usu., English) and a
computer programming language (e.g., C Language) that reveal or detail what the program is to be
doing.
Flowchart. A chart that shows the path or flow of data through a program or an info-handling system and the
operations on the data at significant points along the path.
Structure Chart. A chart that exhibits/expresses the modules or smaller problems and how they are related to
each other. Or, simply the vertical slice through the entire problem or system.
IV.
Implement the Program
1. Code the Program. Write the source code of the program by translating the design tool (e.g., pseudocode)
developed in the preceding step (Step III) into the equivalent statements of the language (e.g., C Language)
to be used.
2. Test and debug the Program. Test the operation of the program to track down programming errors (bugs).
3. Document the Program. Include comments which describe the various sections of the program - that is,
aside from the External Documentation.
Documentation. A set of instructions shipped with a program or a piece of hardware. It serves as supporting
papers on the use, operations, layout or diagram, and requirements of the program or a piece of
hardware.
 Technical Documentation - used by programmers and systems analysts to update or modify the
program.
♠ Internal Documentation - accomplished by using program comments.
3
♠ External Documentation - includes flowcharts, decision table, pseudocode, and
structure/layout chart that depict input and output program descriptions, and other
materials that describe the functions and operations of the program.
 User Documentation describes how to use the program in non-technical terms. It is like an owner's
manual for a car or an appliance.
Basic Control Structures (logical constructs that specify how instructions in a program are to be executed)
 Sequence – instructions are designed to be executed (performed by the computer) in the order they are
written (i.e., one after another). This control structure provides the building block for computer programs. It
is used to show a single action or one action followed in order (sequentially) by another. Actions can
inputs, processes, or outputs.
o Example
 Go to the phone
 Dial the pizza place
 Order the pizza
 Hang up
 Selection (conditional, branch, or decision) – the program branches off to different instructions depending
on whether a condition is met; or, one of several blocks of program code is executed based on a test for
some condition. It is used to tell the program which action to take, based on a certain condition. When a
condition is evaluated, its result is either true or false. If the result is true, one action is performed; if the
result is false, a different action is performed.
o Example
 Open your wallet
 If you have enough money,
 THEN Go to the phone.
o Dial the pizza place.
o Order the pizza.
o Hang up.
 ELSE Forget the whole thing.
 Repetition (looping or iteration) – the program repeats the same instructions over and over. It is used when
a set of actions is to be performed repeatedly.
o Example
 DO gobble down pizza
 WHILE there is still pizza.
Or
 DO gobble down pizza
 UNTIL none remains.
 Unconditional Branch – the programs jumps from one place to another. Structured programming forbids
this structure.
Some Program Flowcharting Symbols
Symbol
Name
Meaning
Flowline
Used to connect symbols and indicate the flow of logic.
Terminal
Used to represent the beginning (Start), the end (End), or a point of
interruption or delay in a program.
Used for input and output operations, such as reading and printing. Or,
represents I/O function, which makes data available for processing (input)
or displaying (output) of processed information. The data to be read or
printed are described inside.
Input/Output
Processing
Used for arithmetic and data-manipulation operations. The instructions are
listed inside the symbol. Or, represents the process of executing a defined
4
Decision
Connector
operation or group of operations that results in a change in value, form, or
location of information. Also functions as the default symbol when no
other symbol is available.
Used for any logic or comparison operations. Unlike the input/output and
processing symbols, which have one entry and one exit flowline, the
decision symbol has one entry and two exit paths. The path chosen
depends on whether the answer to a question is “yes” or “no.” Or,
represents a decision that determines which of a number of alternative
paths is to be followed.
Used to join different flowlines. Or, represents any entry from,
or exit to, another part of the flowchart.
Off-page Connector
Used to indicate that the flowchart continues to a second/next page.
Pre-defined Process
Used to represent a group of statements that perform one processing task.
Or, represents a named process consisting of one or more operations or
program steps that are specified elsewhere.
-----
Annotation
Used to provide additional info about another flowchart symbol.
Or, represents the addition of descriptive info, comments, or
explanatory notes as clarification. The vertical line land broken
line may be placed on the left, or on the right.
Example Problem:
Suppose you are asked to determine the number of stamps to place on an envelop with the rule or policy
that one stamp will be used for every five sheets of paper.
1. Problem Analysis
a. Output Requirements
Description
Number of Stamps
Variable to be Used
Stamps
Data Type
Integer
Variable to be Used
Sheets
Data Type
Integer
b. Input Requirements
Description
Number of Sheets of Paper
c. Processing Requirements
Compute Stamps = Sheets / 5
Determine the rounded up value of Stamps.
2. Program Design
Algorithm
a. Request or enter number of sheets of paper. (input)
b. Compute number of stamps by dividing the number of sheets by 5. (processing)
c. Round the numbers of stamps up to the next highest whole number. (processing)
d. Display the number of stamps. (output)
5
Pseudocode
Program: Determine the number of stamps for a letter
Read or Input Sheets
Set the Stamps to Sheets / 5 ( or Compute Stamps = Sheets/5)
Round Stamps up to the next whole number
Display or print Stamps
Program Flowchart
Start
Input
Sheets
Compute
Stamps
Round up
Stamps
Display
Stamps
Stop
Hierarchy Chart
Postage Stamp
Program
Read Sheets
Calculate Stamps
Set Stamps =
Sheets / 5
Display Stamps
Round up Stamps
6
3. Choosing the Interface
Form Layout
Properties Table
Object
Form
Frame/GroupBox
Label
TextBox
Label
TextBox
CommandButton/Button
CommandButton/Button
CommandButton/Button
CommandButton/Button
Properties
Name
Caption/Text
BackColor
Name
Caption/Text
Enabled
Name
Caption/Text
Name
Text
Alignment
Name
Caption/Text
Alignment
Name
Text
Alignment
Locked
Name
Caption
Name
Caption/Text
Enabled
Name
Caption/Text
Enabled
Name
Caption
Setting
frmStamps
Postage Stamps
(Choose your own)
fraSheetsStamps
Sheets and Stamps
False
lblSheets
Number of Sheets
txtSheets
(Blank)
Right Justify
lblStamps
Number of Stamps
Right Justify
txtSheets
(Blank)
Right Justify
True
cmdOn (or btnOn)
&On
cmdCompute (or btnCompute)
&Compute
False
cmdClear (or btnClear)
C&lear
False
cmdQuit(or btnQuit)
&Quit
7
4. Coding the Program
Code 1: In Visual Basic 6.0
Private Sub cmdOn_Click()
If UCase(cmdOn.Caption) = "&ON" Then
fraSheetsAndStamps.Enabled = True
cmdOn.Caption = "&Off"
cmdClear.Enabled = True
Else
fraSheetsAndStamps.Enabled = True
cmdOn.Caption = "&On"
cmdClear.Enabled = False
cmdCompute.Enabled = False
End If
End Sub
Private Sub cmdClear_Click()
txtSheets.Text = Empty
txtStamps.Text = Empty
End Sub
Private Sub cmdCompute_Click()
If Val(txtSheets.Text) Mod 5 > 0 Then
txtStamps.Text = Fix(Val(txtSheets.Text) / 5) + 1
Else
txtStamps.Text = Val(txtSheets.Text) / 5
End If
End Sub
Private Sub cmdQuit_Click()
MsgBox "Hasta que me vuelva a ejecutar...", vbInformation, "Gracias!"
End
End Sub
Private Sub txtSheets_LostFocus()
If Val(txtSheets.Text) <= 0 Then
MsgBox "Ooops! Not a valid value. Try again...", vbCritical, "Invalid Entry"
txtSheets.Text = Empty
txtSheets.SetFocus
Else
cmdCompute.Enabled = True
End If
End Sub
Code 2: In Java
/**
* @(#)Stamps.java
*
* Stamps application
*
* @author
* @version 1.00 2011/1/15
*/
8
/* Note: Before you compile this program, copy Input.class
* in the same location where you saved this program
*/
public class Stamps {
public static void main(String[] args) {
// TODO, add your application code
int
Sheets, No_of_Stamps;
Input Ask = new Input();
System.out.println("Stamps on an Envelope\n");
System.out.print("Number of Sheets : ");
Sheets = Ask.iinteger();
No_of_Stamps = (int) Math.ceil(Sheets/5.0);
System.out.println("Number of Stamps : "+No_of_Stamps);
}
}
Code 3: In C/C++
#include <stdio.h>
#include <math.h>
main(void)
{
unsigned int Sheets, Stamps;
clrscr();
printf("Postage Stamps\n\n");
printf("Number of Sheets : ");
scanf("%u",&Sheets);
Stamps = ceil(Sheets/5.0);
printf("Number of Stamps : %u",Stamps);
getche();
return 0;
}
9
Guidelines for Developing Flowcharts (Programming in BASIC by Ralph M. Stair, Jr.)
1. The overall purpose of a flowchart is to reveal the logic and layout of the problem – not specific programming
statements or rules.
2. Flowcharts are used as a design tool. Thus, they should be done before the program is developed.
3. Just as there are many way s to solve a problem, there are many ways to develop a flowchart. You should strive
to develop a good flowchart, not the one best flowchart. This can be done by using common sense and following
these rules.
a. Flowcharts should be relatively independent of a particular programming language. In other words, the
same flowchart can be used to write a program in C/C++, Java, Pascal, BASIC, or any other programming
language.
b. A flowcharting template should be used. Each symbol should only be used for its specified purpose. In other
words, the rectangle should not be used a decision or for input and output.
c. Flowcharts should be simple and straightforward. Unnecessary loops and branches should be avoided. Using
a large number of connectors between different segments of the program and between different pages
should also be avoided.
d. The flowchart lines should be either vertical or horizontal. Flowcharting lines that curve or lines that are at
angles should be avoided. In addition, flowcharting lines should never cross, and each flowcharting line
should be attached to a flowcharting symbol. When possible, there should only be one flowcharting line
drawn to each symbol.
e. Only executable statements should be included in flowcharts. Furthermore, text or written in a flowcharting
symbol should be short or kept to a minimum.
f. Several programming statements can be represented using one flowchart symbol. Furthermore, it is
unnecessary to use formal programming words.
g. Flowcharts should be written from top to bottom and from left to right. There should be straightforward flow
from one flowcharting symbol to another.
h. A flowchart is also a documentation tool. If you decide to change a program, first design these changes by
redoing the flowchart. The flowchart should always reflect the current program.
Some Important Terms:
 Desk Checking (@ the Flowchart Stage). The use of different data as input to check the output. Or, a
method of discovering logical error by tracing the values of variables on paper by writing down their
expected value after “mentally executing” each line in the program. The test should include non-standard
data as well as typical data. This method is rudimentary and highly impractical except for small programs.
 Algorithm. A logical sequence of precise steps that solve the problem. Or, a step-by-step description of
how to arrive at a solution.
 Program Development. The progression from understanding a problem specification to achieving a
working computer-based solution.
 Program Development Cycle. A sequence of steps programmers used to plan their programs.
 Testing. The process of finding errors in a program.
 Debugging. The process of correcting errors found in a program.
 Bug. An error in a program.
 Coding. The technical word for writing the program.
 Flowcharts. A diagram consisting of geometric symbols connected by arrows that graphically depicts the
logical steps to carry out a task and show how the steps relate to each other. Or, a diagram that shows the
logic of a program. The flowlines (the arrows connecting the symbols) show the progression in which the
steps take place.
 Pseudocode. An abbreviated version of actual computer code. Created in 1970s as an alternative to
flowcharts, it is a stylized form of writing used to describe the logic of a program. It uses English-like
phrases with some programming keywords/statements to outline the task. It allows the programmer to focus
on the steps required to solve the problem rather than on how to use the computer language.
 Hierarchy Charts. A chart that shows the overall program structure. It shows how the different parts of a
program relate to each other. It omits, however, the specific processing logic. Hierarchy charts describe
what each part, or module, of the program does and they show how the modules relate to each other. The
chart is read from top to bottom and from left to right. Each module may be subdivided into a succession of
sub-modules that branch out under it. The main benefit of hierarchy charts is in the initial planning of a
program. We break down the major parts of a program so we can see what must be done in general. From
this point, we can then refine each module into more details plans using flowcharts or pseudocode. This
process is called the divide-and-conquer method. Hierarchy charts are also called structure charts, HIPO
(Hierarchy plus Input-Process-Output) charts, top-down charts, or VTOC (Visual Table of Contents) charts.
10
















Top-Down Program Design. The design that focuses on the main goal that the program is trying to achieve
and then breaks the program into manageable components contributing to this goal.
Programming Language. An artificial language consisting of a vocabulary and a set of rules
Syntax Errors. Grammatical errors, such as misspellings, omissions, or incorrect punctuations.
Run-time Errors. Errors that occur while a program is running and usually caused by the inability of the
computer to carry out the intended task.
Logical Errors. Errors that occur when a program does not perform the way it was intended.
Driver. A dummy program set up to test the reliability of a procedure.
Computer Program. A sequence of instructions that tells a computer what to do and how to do it. Or, a
series of (logically-coded) instructions that a computer can interpret and execute. It has three constituent
parts: input, process, and output. Input and output are important to make the program useful but most of the
work gets done in process. Process is the heart of programming and does not include user interface;
therefore, it does not include GUI. A source code program comprises all statements and files necessary for
complete interpretation or compilation. An executable program can be loaded into a given environment and
executed independently of other programs.
Programming. The art, science, and discipline of designing, writing, debugging, and/or maintaining
computer programs. It is problem solving. Specifically, problems are solved by creating solutions that run
on a computer. In order to create a solution, a programmer must understand the problem , determine what
information is available with which to solve the problem, and design a solution that uses some or all
available information. The solution includes designing and writing a computer program.
Stub Programming. A programming technique where key event procedures and perhaps some of the
smaller procedures are coded first while dummy procedures (or stubs) are written for the remaining
procedures. Initially, a stub procedure might consist of a Print method to indicate that the procedure has
been called, and thereby confirm that it is called at the right time.
Stepwise Refinement. The repeated use of a “divide-and-conquer” approach to break up a large problem
into smaller subproblems.
Spaghetti Code. A program composed of a convoluted (too complex or intricate to understand easily;
having many twists, coils, or whorls) tangle of branching that produces confusing code.
Flag. A Boolean variable, used to indicate whether a certain event has occurred.
Quick Info. A feature of IntelliSense that causes the editor to display a line containing the general form of a
statement or function.
ToolTips. Pop-up help bubbles.
User Interface. The way that a program accepts instructions from the user and presents results.
Graphical User Interface (GUI). An user interface that provides visual clues such as small pictures, or
icons, to help the end user give instructions to the computer.
11