Page:of 11
Automatic Zoom
1
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 wel
l
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 mor
e
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: programm
ers 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
impossib
le 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 par
t 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 an
alyst 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 th
e 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 hidd
en. 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 need
s
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 fe
atures

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
2

modifications to update the program,

add features for the user
, or

a decision to abandon the current system and dev
elop 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.
W
rite 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 applicatio
n 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.
Prov
ide 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 Devel
opment 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 d
ata (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, sho
uld 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 perfor
m 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 ob
tained 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 in
to 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/pse
u
docode devised in Step 2 along with a
knowledge of the p
rogramming 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; h
owever, 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
multiplicatio
n was the
proper operation.
6.
Complete the documentation
: Organize all the material that describes the program.
3
Documentation is intended to allow another person, or the programmer at a
later date, to understand the
program. Internal documentation consists o
f 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 a
s 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 d
efined.
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 con
sists 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 thi
s 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:
G
arbage
I
n
=
G
arbage
O
ut (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., Eng
lish) 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 signi
ficant 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 t
he 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 shi
pped 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 o
r modify the
program.
♠ Internal Documentation
accomplished by using program comments.
5
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 avail
able.
Decision
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.
Connector
Used to join different flowlines.
Or, represents any entry from,
or exit to, another part of the flow
chart.
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 operat
ions 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.
Prob
lem Analysis
a.
Output Requirements
Description
Variable to be Used
Data Type
Number of
Stamps
Stamps
Integer
b.
Input Requirements
Description
Variable to be Used
Data Type
Number of Sheets of Paper
Sheets
Integer
c.
Processing Requirements
Com
pute
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 t
o the next highest whole number.
(processing)
d.
Display the number of stamps. (output)
6
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
Hierarchy Chart
Input
Sheets
Compute
Stamps
Round up
Stamps
Display
Stamps
Start
Stop
Postage Stamp
Program
Calculate Stamps
Read Sheets
Display Stamps
Set Stamps =
Sheets / 5
Round up Stamps
7
3.
Choosing the Interface
Form Layout
Properties Table
Object
Properties
Setting
Form
Name
frmS
tamps
Caption/Text
Postage Stamps
BackColor
(Choose your own)
Frame
/GroupBox
Name
fraSheetsStamps
Caption/Text
Sheets and Stamps
Enabled
False
Label
Name
lblSheets
Caption/Text
Number of Sheets
TextBox
Nam
e
txtSheets
Text
(Blank)
Alignment
Right Justify
Label
Name
lblStamps
Caption/Text
Number of Stamps
Alignment
Right Justify
TextBox
Name
txtSheets
Text
(Blank)
Alignment
Right Justify
Locked
True
CommandButton/Button
Name
cmdOn (or btnOn)
Caption
&On
CommandButton/Button
Name
cmdCompute (or btnCompute)
Caption/Text
&Compute
Enabled
False
CommandButton/Button
Name
cmdClear (or btnClear)
Caption/Text
C&lear
Enabled
False
CommandButton/Button
Name
cmdQuit(or btnQuit)
Caption
&Quit
8
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 c
mdClear_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(txtSheet
s.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
*/
9
/* 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.p
rintln("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;
}
10
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
–
no
t 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 d
evelop 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 out
put.
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 sho
uld 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, th
ere 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 re
presented 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 fl
owchart 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
standa
rd
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 Dev
elopment. 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 versio
n 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 omit
s, 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 subdivid
ed 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.
11

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 tel
ls 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 m
ost 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. Specif
ically, 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 som
e 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 “di
vide
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 conf
using 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 bubble
s.

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.