Introduction to the Program Development Life
Cycle (PDLC)
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.
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 PDLC’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
§
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.)
- 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.
- 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.
- 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.
- 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.
- Formalize the solution.
a.
Review
and, if necessary, revise internal documentation
b.
Formalize
and complete end-user (external) documentation
- 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
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.
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.
The C language was developed in 1972 by Dennis Ritchie at Bell Telephone laboratories, primarily as a systems programming language. That is, a language to write operating systems with. Richie’s primary goals were to produce a minimalistic language that was easy to compile, allowed efficient access to memory, produced efficient code, and did not need extensive run-time support. Thus, for a high-level language, it was designed to be fairly low-level, while still encouraging platform-independent programming.
C ended up being so efficient and flexible that in 1973, Ritchie and Ken Thompson rewrote most of the UNIX operating system using C. Many previous operating systems had been written in assembly. Unlike assembly, which ties a program to a specific CPU, C’s excellent portability allowed UNIX to be recompiled on many different types of computers, speeding its adoption. C and Unix had their fortunes tied together, and C’s popularity was in part tied to the success of UNIX as an operating system.
In 1978, Brian Kernighan and Dennis Ritchie published a book called “The C Programming Language”. This book, which was commonly known as K&R (after the author’s last names), provided an informal specification for the language and became a de facto standard. When maximum portability was needed, programmers would stick to the recommendations in K&R, because most compilers at the time were implemented to K&R standards.
In 1983, the American National Standards Institute (ANSI) formed a committee to establish a formal standard for C. In 1989 (committees take forever to do anything), they finished, and released the C89 standard, more commonly known as ANSI C. In 1990 the International Organization for Standardization adopted ANSI C (with a few minor modifications). This version of C became known as C90. Compilers eventually became ANSI C/C90 compliant, and programs desiring maximum portability were coded to this standard.
In 1999, the ANSI committee released a new version of C called C99. It adopted many features which had already made their way into compilers as extensions, or had been implemented in C++.
C++
C++ (pronounced see plus plus) was developed by Bjarne Stroustrup at Bell Labs as an extension to C, starting in 1979. C++ adds many new features to the C language, and is perhaps best thought of as a superset of C, though this is not strictly true as C99 introduced a few features that do not exist in C++. C++’s claim to fame results primarily from the fact that it is an object-oriented language. As for what an object is and how it differs from traditional programming method
Introduction to Programming
A program is a set of instructions that tell the computer to do various things; sometimes the instruction it has to perform depends on what happened when it performed a previous instruction. This section gives an overview of the two main ways in which you can give these instructions, or “commands” as they are usually called. One way uses an interpreter, the other acompiler. As human languages are too difficult for a computer to understand in an unambiguous way, commands are usually written in one or other languages specially designed for the purpose.
With an interpreter, the language comes as an environment, where you type in commands at a prompt and the environment executes them for you. For more complicated programs, you can type the commands into a file and get the interpreter to load the file and execute the commands in it. If anything goes wrong, many interpreters will drop you into a debugger to help you track down the problem.
The advantage of this is that you can see the results of your commands immediately, and mistakes can be corrected readily. The biggest disadvantage comes when you want to share your programs with someone. They must have the same interpreter, or you must have some way of giving it to them, and they need to understand how to use it. Also users may not appreciate being thrown into a debugger if they press the wrong key! From a performance point of view, interpreters can use up a lot of memory, and generally do not generate code as efficiently as compilers.
In my opinion, interpreted languages are the best way to start if you have not done any programming before. This kind of environment is typically found with languages like Lisp, Smalltalk, Perl and Basic. It could also be argued that the UNIX® shell (
The advantage of this is that you can see the results of your commands immediately, and mistakes can be corrected readily. The biggest disadvantage comes when you want to share your programs with someone. They must have the same interpreter, or you must have some way of giving it to them, and they need to understand how to use it. Also users may not appreciate being thrown into a debugger if they press the wrong key! From a performance point of view, interpreters can use up a lot of memory, and generally do not generate code as efficiently as compilers.
In my opinion, interpreted languages are the best way to start if you have not done any programming before. This kind of environment is typically found with languages like Lisp, Smalltalk, Perl and Basic. It could also be argued that the UNIX® shell (
sh, csh) is itself an interpreter, and many people do in fact write shell “scripts” to help with various “housekeeping” tasks on their machine. Indeed, part of the original UNIX® philosophy was to provide lots of small utility programs that could be linked together in shell scripts to perform useful tasks.
Here is a list of interpreters that are available from the FreeBSD Ports Collection, with a brief discussion of some of the more popular interpreted languages.
Instructions on how to get and install applications from the Ports Collection can be found in the Ports section of the handbook.
Instructions on how to get and install applications from the Ports Collection can be found in the Ports section of the handbook.
- BASIC
- Short for Beginner's All-purpose Symbolic Instruction Code. Developed in the 1950s for teaching University students to program and provided with every self-respecting personal computer in the 1980s, BASIC has been the first programming language for many programmers. It is also the foundation for Visual Basic.
The Bywater Basic Interpreter can be found in the Ports Collection as lang/bwbasic and the Phil Cockroft's Basic Interpreter (formerly Rabbit Basic) is available as lang/pbasic. - Lisp
- A language that was developed in the late 1950s as an alternative to the “number-crunching” languages that were popular at the time. Instead of being based on numbers, Lisp is based on lists; in fact the name is short for “List Processing”. Very popular in AI (Artificial Intelligence) circles.
Lisp is an extremely powerful and sophisticated language, but can be rather large and unwieldy.
Various implementations of Lisp that can run on UNIX® systems are available in the Ports Collection for FreeBSD. GNU Common Lisp can be found as lang/gcl. CLISP by Bruno Haible and Michael Stoll is available as lang/clisp. For CMUCL, which includes a highly-optimizing compiler too, or simpler Lisp implementations like SLisp, which implements most of the Common Lisp constructs in a few hundred lines of C code, lang/cmucl and lang/slisp are available respectively. - Perl
- Very popular with system administrators for writing scripts; also often used on World Wide Web servers for writing CGIscripts.
Perl is available in the Ports Collection as lang/perl5.16 for all FreeBSD releases. - Scheme
- A dialect of Lisp that is rather more compact and cleaner than Common Lisp. Popular in Universities as it is simple enough to teach to undergraduates as a first language, while it has a high enough level of abstraction to be used in research work.
Scheme is available from the Ports Collection as lang/elk for the Elk Scheme Interpreter. The MIT Scheme Interpreter can be found in lang/mit-scheme and the SCM Scheme Interpreter in lang/scm. - Icon
- Icon is a high-level language with extensive facilities for processing strings and structures. The version of Icon for FreeBSD can be found in the Ports Collection as lang/icon.
- Logo
- Logo is a language that is easy to learn, and has been used as an introductory programming language in various courses. It is an excellent tool to work with when teaching programming to smaller age groups, as it makes creation of elaborate geometric shapes an easy task.
The latest version of Logo for FreeBSD is available from the Ports Collection in lang/logo. - Python
- Python is an Object-Oriented, interpreted language. Its advocates argue that it is one of the best languages to start programming with, since it is relatively easy to start with, but is not limited in comparison to other popular interpreted languages that are used for the development of large, complex applications (Perl and Tcl are two other languages that are popular for such tasks).
The latest version of Python is available from the Ports Collection in lang/python. - Ruby
- Ruby is an interpreter, pure object-oriented programming language. It has become widely popular because of its easy to understand syntax, flexibility when writing code, and the ability to easily develop and maintain large, complex programs.
Ruby is available from the Ports Collection as lang/ruby18. - Tcl and Tk
- Tcl is an embeddable, interpreted language, that has become widely used and became popular mostly because of its portability to many platforms. It can be used both for quickly writing small, prototype applications, or (when combined with Tk, a GUI toolkit) fully-fledged, featureful programs.
Various versions of Tcl are available as ports for FreeBSD. The latest version, Tcl 8.5, can be found in lang/tcl85.
Compilers are rather different. First of all, you write your code in a file (or files) using an editor. You then run the compiler and see if it accepts your program. If it did not compile, grit your teeth and go back to the editor; if it did compile and gave you a program, you can run it either at a shell command prompt or in a debugger to see if it works properly. [1]
Obviously, this is not quite as direct as using an interpreter. However it allows you to do a lot of things which are very difficult or even impossible with an interpreter, such as writing code which interacts closely with the operating system—or even writing your own operating system! It is also useful if you need to write very efficient code, as the compiler can take its time and optimize the code, which would not be acceptable in an interpreter. Moreover, distributing a program written for a compiler is usually more straightforward than one written for an interpreter—you can just give them a copy of the executable, assuming they have the same operating system as you.
As the edit-compile-run-debug cycle is rather tedious when using separate programs, many commercial compiler makers have produced Integrated Development Environments (IDEs for short). FreeBSD does not include an IDE in the base system, but devel/kdevelop is available in the Ports Collection and many use Emacs for this purpose.
Obviously, this is not quite as direct as using an interpreter. However it allows you to do a lot of things which are very difficult or even impossible with an interpreter, such as writing code which interacts closely with the operating system—or even writing your own operating system! It is also useful if you need to write very efficient code, as the compiler can take its time and optimize the code, which would not be acceptable in an interpreter. Moreover, distributing a program written for a compiler is usually more straightforward than one written for an interpreter—you can just give them a copy of the executable, assuming they have the same operating system as you.
As the edit-compile-run-debug cycle is rather tedious when using separate programs, many commercial compiler makers have produced Integrated Development Environments (IDEs for short). FreeBSD does not include an IDE in the base system, but devel/kdevelop is available in the Ports Collection and many use Emacs for this purpose.
This comment has been removed by the author.
ReplyDeletetq ,,itss good to reference
ReplyDelete