Programming NC IV

1
Program Development Life Cycle

Program Development Life Cycle (PDLC)

This module covers the different phases of a program development life cycle
– defining the problem and its requirements, designing the program, actual
coding of the program, testing and debugging, formalizing the solution and
proper documentation. Algorithms, pseudocode and flowcharts will also be
discussed.
After completing this module, students are expected to:
1. enumerate and explain the phases of a program development life cycle;
2. write simple and technical pseudocode; and
3. construct simple flowcharts.

Program Development Life Cycle

Just like every other process, programming also follows a cycle – PDLC or
program development life cycle. PDLC is a set of steps and phases that a
programmer or developer follows to define, conceptualize, design, develop
and maintain a computer program. Usually, the cycle consists of the phases
illustrated in Figure 1.

Figure 1. Program Development Life Cycle

Course Module
Analyze the Problem
Before anything else, the program requirements should be clearly defined.
What is the program for? What does it do? Who are the end users? What are
the functions? What are the scope and limitations?
Just like what you do every time you cook (or your mom or dad or auntie).
Decide first what you are going to cook before gathering the necessary
ingredients and cooking tools.
Look at the sample simplified requirements document below. Let’s
say XYZ Bakery is now open and surprisingly, customers are asking if
they could order online and have their cakes delivered. The owner of
the bakery decided to try implementing this process and arrived with
the document below.
Requirements Document
Application Title Place Order Online
Purpose This website feature will allow new and old
customers to place their orders online and
wait for the delivery of the product.
Program Procedures Customers should be able to order bread and
pastries from XYZ bakery through the
website.
Algorithms, 1. The customer must be able to view all
Processing and products of XYZ including its name, main
Condition ingredients and price.
2. The user should also be able to view items
on sale or promo.
3. Once the user has decided which product
to buy, he will click on the picture and it
goes to checkout page.
4. The user will identify how many pieces or
boxes will he order in the checkout page.
5. He should also be asked for the complete
address and contact number.
6. Once the customer clicks “Place Order”, a
confirmation message should appear.
7. The user should receive an SMS when his
order is confirmed. This feature is
important to inform customers whether
the product ordered is available or not.
Notes and 1. Minimum order should be worth P100.00.
Restrictions 2. Customer’s address should not be a PO
Box.
3. Online payment is not yet accepted. At the
moment, cash-on-delivery is the only way
to pay.
4. Online orders can only be done from 6AM
– 5PM, business hours of XYZ Bakery.
Comments Pictures of the products to be used should be
updated.
 Programming NC IV
3
Program Development Life Cycle

Determining requirements can be broken down into four processes:

1. Requirements gathering - The programmers, or sometimes business
analysts, meet and converse with the client and end users to learn about
their expectations from the program / software to be developed.
2. Organizing requirements – The requirements are arranged in order of
importance, urgency and convenience.
3. Negotiation & discussion - If there are confusing or vague requirements, a
negotiation is conducted and discussed with the stakeholders.
4. Documentation – Formal, informal, functional and non-functional
requirements must be documented properly for the next phase of the
program development life cycle.

Design the Program

Now that the requirements have been identified, the next phase is designing
the program. How do you actually design a program?
Tools such as flowchart and pseudocode, which will be discussed in detail in
the later part of this module, are used in conceptualizing and designing a
program.
Why is this phase important? Can’t we just go ahead and write the code?
Imagine constructing and building a house without a blueprint. The workers
do not have an idea on how the house should look like. It’s the same with
flowcharts. Flowcharts give the programmers an idea on the flow of the
program and its scope.
The figure below is an example of a simple flowchart which shows menu
options – Introduction, Parts, Types, Processes, Evaluation and Quit.

Figure 2. Computer Peripherals

Course Module
Coding and Execution
Once the program design has been accomplished, programmers will now
proceed with the actual coding – using a programming language like Java to
write the lines of code. The image below is a sample block of Java code.

Figure 3. Computer Peripherals

Testing and Debugging

Testing and debugging comes after coding the program. This is done to
ensure that the program works, produces the correct and intended result,
and displays it appropriately.
“Debugging” actually means finding and removing “bugs” or errors for the
program to function properly and meet its requirements. Programmers are
responsible for debugging their programs.
The screenshot below shows a sample program with a bug.
 Programming NC IV
5
Program Development Life Cycle

Figure 4. Sample Program Bugs

Formalize the Solution

In this phase, the program is run to check for syntax and grammatical errors
which could have been overlooked during the coding phase.
Documentation
Documentation comes last. In this phase, the programmers write down
instructions for the end users (the ones who are going to use the system), the
purpose of the program, how it performs its functions, the input needed and
the output expected.
Internal documentations are done by programmers through comments (this
will be discussed in a later module). These comments explain what a function
does and why it was created.
At a later section of this module, we will discuss documentation standards
and acceptable practices for programmers.

Course Module
Algorithm, Pseudocode and Flowchart
This section covers the fundamental concepts of an algorithm, pseudocode
and flowchart. Some standards and protocols in proper programming
documentation are also discussed.

Algorithm
Algorithm is used to describe how you do simple daily tasks or actions. In
computer science, algorithm is defined as a procedure or formula which
consists of a set of steps to accomplish a specific task. In the next section, we
will discuss the different tools to present an algorithm.
Before that, here are some real life situations where you use an algorithm:
How do you look for an item in the supermarket?
1. Look for the right aisle.
2. Scan the items from right to left, top to bottom.
3. Stop when you find the product you’re looking for.
How do you cook a sunny-side up egg?
1. Prepare the ingredients and the kitchen tools.
2. Heat the pan.
3. Pour enough amount of cooking oil.
4. Wait until oil is hot.
5. Crack an egg into the pan.
6. Once cooked, take it out of the pan.
How do you go to school?
1. Walk to loading area.
2. Ride a jeep, bus or FX.
3. Get off the unloading area nearest the school.
4. Walk to the school.
The examples above are simple series of steps needed to be done to
accomplish the task given. Now how do we present computer algorithms?
Interested? Read on.

Pseudocode
Pseudocode, or program design language, describes the steps of an algorithm
using everyday language. These statements describe an action and focuses on
the logic of the program’s algorithm. Steps should be numbered and should
be clear enough so that the desired programming code can be generated
using these statements.
Here are the general rules in writing pseudocode:
1. These symbols are used for arithmetic operations +, -, *, /, etc.
2. Keywords such as PRINT, READ, WRITE, etc. can be used.
3. Symbolic names can be used to identify processed quantities.
4. Proper indentation should be used for branches of instruction or
repeating / looping statements.
 Programming NC IV
7
Program Development Life Cycle

Pseudocode, as another way to interpret an algorithm, has its own set of

benefits:
1. Pseudocode provides a simple means of presenting program logic
through the use of everyday language.
2. It is language independent.
3. It is easier to write codes from a pseudocode than a flowchart (refer to
the next section).
4. Pseudocode is compact and requires less pages.
5. It allows programmers to work in different computer languages.

Flowchart
A flowchart is a graphical representation of an algorithm using shapes and
symbols to illustrate the steps or procedure. It flows from top to bottom and
it has a beginning and an end.
Flowcharts are prepared for the following reasons:
1. It makes the logic clear and understandable.
2. For communication purposes.
3. It is used for effective analysis.
4. It is useful during the coding phase.
5. Flowcharts are used for testing and debugging.
6. Flowcharts are part of the documentation.
The following are the common flowchart symbols.
Symbol Name Function
This symbol indicates an operation,
Process data transformation, logical
operation, etc.
This shape means the program is
Input / Output expecting an input or displaying an
output.
The diamond shape refers to
evaluation of a condition. It branches
Decision
out depending on whether the
condition is met or not.

This symbol connects sections of the

Connector
flowchart for smooth and linear flow.

This shape indicates the start and end

Terminal
of the program.

These arrows indicate the direction

Flow Lines
of the program flow.
Course Module
Take note of the general rules when constructing a flowchart:
1. All symbols used in the flowchart must be connected by flow lines.
2. Flow lines enter from the top of the symbol and exits at the bottom of the
symbol; except for the decision which can be connected by the flow lines
at the bottom or side.
3. Flowcharts are drawn in a way that it logically flows from top to bottom.
4. The beginning and end of a flowchart are indicated by terminals.
5. In case the program is too complicated, use connectors.

Now using both Pseudocode and Flowchart, present this algorithm:

A student takes 3 tests. Get his / her average and decide whether he / she
will pass or fail. (Average should be greater than 75.) Inform the student of
the result.

Pseudocode:
1. A student takes tests.
2. Get the three scores.
3. Compute for the average by adding up the scores and dividing the sum by
three.
4. If average is above 75,
Print “Yey! You passed!”
Else
Print “Oh, no! Failed.”

Now take a look at how we convert it into a flowchart.

 Programming NC IV
9
Program Development Life Cycle

Flowchart:

Figure 5. Flowchart

Now let’s make a subtle change. If the student fails, he / she should take the
test again. If he / she pass, the program ends.

Pseudocode:
1. A student takes tests.
2. Get the three scores.
3. Compute for the average by adding up the scores and dividing the sum by
three.
4. If average is above 75
Print “Yey! You passed!”
Else
Go back to 1.

Course Module
Flowchart:

Figure 6. Flowchart

Notice that both flowcharts used the decision shape (diamond) and it
branched out to two directions – one if the condition is met and the other, if
not.
How about connectors? Let’s revisit the example given in the PDLC as
illustrated in Figure 3. You’ll notice that the main flowchart has connectors
labeled as A, B, C, D, E and X.
A and B connectors are shown below the main flowchart. They have a
separate function which if we try to connect to the main flowchart, will make
it hard to read. Remember that connectors are used to make it clearer and
easier to read.
As you’ll notice, the X connector goes back to the point after the Start. It
means that every time A, B, C, D or E are closed, it goes back to the menu
where you can choose to load Introduction, Parts, Types, Process, Evaluation
or Quit. By the way, this flowchart is made for an eLearning app about
succulent plants.
 Programming NC IV
11
Program Development Life Cycle

Figure 7. Flowchart with Connectors

Documentation Standards
An effective programmer does not only write codes and programs that work
without errors and bugs. You also have to follow coding techniques,
programming practices and documentation protocols in case new features
will be added to the program: change its features, fix bugs and improve
performance. Your codes should be readable enough so that other
programmers can comprehend them very well.
Course Module
Names
Naming the different elements of a program aids programmers to
understand the program flow. A name should tell “what” it does rather than
“how” it does a function.
Use simple words that can be understood by others. For example, use
GetNextStudent() instead of GetNextString().
There are different rules for different program elements:

Naming Routines:
1. In object-oriented programming, avoid repeating the name of the class in
naming class properties. Instead of Book.BookTitle, use Book.Title.
2. Use both a verb and a noun to describe operations and functions, for
example CalculateAverageScore().
3. In programming languages that allow function overloading, all overloads
should perform the same functions.

Naming Variables:
1. Attach computation qualifiers such as Sum, Avg (Average), Min
(Minimum), Max (Maximum) to the ending of a variable name, if
applicable.
2. Use traditional opposite pairs such as begin/end, open/close and
min/max in variable names.
3. Capitalize each word when naming routines or functions like
CalculateTotalScore().
4. Capitalize each word, except the first word, in naming variables like
totalScore.
5. Boolean variable names should contain Is which imply Yes/No,
True/False values like recordIsFound.
6. Use meaningful variable names even for variables which will only be used
a few times in the program.
7. Constant variables should be in uppercase separated by underscore like
NUM_WEEKS_IN_MONTH or EXAM_PASSING_SCORE.

Naming Tables in a Database:

1. Use singular forms in naming tables, use Student instead of Students.
2. In naming columns, do not repeat the name of the table, use LastName
instead of StudentLastName in the Student table.
3. Do not include data type in the name of the column, use Age instead of
IntAge (which means that age is set to integer).
 Programming NC IV
13
Program Development Life Cycle

Other tips:
1. Lessen the use of abbreviations. If abbreviations are used, be consistent.
For example, if min is used for minimum, avoid using min for minutes in
the future.
2. In naming functions, describe the value being returned like
GetHostName().
3. Name files and folders appropriately as well. Make sure they describe
their contents.
4. Avoid recycling and reusing names for different elements.
5. Refrain from using homonyms to avoid confusion such as write and right.
6. Check your spelling. Do not use misspelled words.
7. Avoid typographical errors as well.

Comments
Comments have two types – internal and external documentation. Internal
comments can be found in the program itself while external is the opposite.
External documentation includes help files, specifications and design
documents.
The following are recommended techniques by Microsoft in writing your
comments:
1. If you update a block of code, make sure to update the related comment
as well.
2. Begin every routine with a standard, boilerplate comment which
describes what the routine does.
3. Do not add comments at the end of a line of code – it makes reading the
program difficult.
4. Refrain from adding typographical frame around a block of code. It might
look attractive but it is hard to maintain.
5. Write complete sentences in a comment.
6. Write comments as you write the codes.
7. Refrain from including inappropriate comments like humorous side
comments.
8. Use comments to explain, not to translate, the code.
9. Comment on anything that is not obvious.
10. Use a uniform style throughout the whole program.

Course Module
 Format
A proper programming format makes the program’s logical flow stand out.
Take time to make sure that the program is formatted in a consistent way.
The following are formatting techniques you can apply in writing your
program:
1. Use a consistent size for indent - like four spaces. Align codes using the
prescribed indentation.
2. In printing a hard copy of the source code, use monospace font.
3. Use mixed case instead of underscore in naming, except for constants.
4. Align open and close pair of braces vertically.
5. Establish a maximum length of comments per line.
6. Use spaces before and after operators.
7. Put a space after each comma in lists such as array values and arguments.
8. If a line of code is broken in several lines, make it obvious that it is a
single line of code.
9. Avoid placing more than one line of statement per line.
10. In writing SQL statements, use uppercase for keywords and mixed case
for database elements like tables and columns.

Glossary
Boolean (n.) – a type of variable which can only have two possible values –
true or false, yes or no
Data Type (n.) – a characteristic of a value which tells what kind of data it can
have
Object Oriented Programming (n.) – a programming language model focused
on objects instead of actions
Variable (n.) – an element which value can change; in programming, a
variable is associated with data storage locations

References
Caron, R. (2000). Coding Techniques and Programming Practices. Microsoft
Corporation. Available at: https://msdn.microsoft.com/en-
us/library/aa260844(v=vs.60).aspx
Webber, L. Study.com. Business 104: Information Systems and Computer
Applications. Available at: http://bit.ly/2fU8Qiu