Program Development Life Cycle

Module Overview
This module covers the different phases of a program
development life cycle, algorithms, pseudocode and flowcharts.
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 at the right.
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?
Analyze the Problem (cont.)
• Look at the sample simplified
requirements document at the right.
• 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.
Analyze the Problem (cont.)
• 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.
Analyze the Problem (cont.)
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.
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 at the right is a sample
block of Java code.
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.
Testing and Debugging (cont.)
• The screenshot at the
right shows a sample
program with a bug.
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
• 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.
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.
Algorithm (cont.)
• 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 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.
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.
Pseudocode (cont.)
• 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.
Pseudocode (cont.)
• 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.
Pseudocode (cont.)
• 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.”
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.
Flowchart (cont.)
• 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.
Flowchart (cont.)
Flowchart (cont.)
Flowchart (cont.)
• 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.
Flowchart (cont.)
• 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.
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.
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().
Names (cont.)
• 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.
Names (cont.)
• 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.
Names (cont.)
• 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).
Names (cont.)
• 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.
Comments (cont.)
• 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.
Comments (cont.)
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.
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.
Format (cont.)
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.
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