The document presents a common model for integrating problem solving and program development. It reviews existing problem solving methodologies and synthesizes them into a 6-stage common model. The 6 stages are: 1) Formulating the problem, 2) Planning the solution, 3) Designing the solution, 4) Translating the solution, 5) Testing the solution, and 6) Delivering the solution. Each stage includes specific tasks and requires certain cognitive knowledge and skills. The model aims to make problem solving and programming closely integrated and provide students with a coherent framework to become effective problem solvers and programmers.

1. IEEE TRANSACTIONS ON EDUCATION, VOL. 42, NO. 4, NOVEMBER 1999 331
A Common Model for Problem Solving
and Program Development
Fadi P. Deek, Murray Turoff, Member, IEEE, and James A. McHugh
Abstract—We present a domain-specific problem solving model
to facilitate the study of programming. Specifically, we address
how problem solving and programming can be closely integrated
and taught to beginning students and what are the necessary
knowledge and skills to enhance students’ ability to become
effective problem solvers and programmers. To accomplish this,
we synthesized a common model for problem solving, based
on a review of existing methodologies, that integrates the tasks
of program development, and elaborates the required cognitive
knowledge and skills. The common model explicitly encourages
students to adhere to a well-specified six-stage process of formu-
lating the problem, planning, designing, translating, testing, and
delivering the solution.
Index Terms— Problem solving, program development, soft-
ware engineering.
I. INTRODUCTION
APRIMARY goal of curriculum reform efforts is to create
classrooms in which students are challenged to think
profoundly about the subjects by discovering, understanding,
analyzing, and applying skills and knowledge in new situ-
ations. Unfortunately, a substantial number of students enter
postsecondary education lacking requisite critical thinking and
problem solving skills. This is not surprising in view of the
recent TIMSS Report (NRC, 1997), which found that less than
20% of participating math teachers indicated that they focus
on conceptual thinking or problem solving in their classrooms.
While not minimizing the importance of syntactical issues,
research clearly indicates that the most fundamental obstacles
to learning programming are related to its problem solving
character [3], [4], [11], [16]. The introductory course in
computer science provides an opportunity to introduce students
to problem solving skills [1].
To expect effective and efficient solutions to be produced,
a considerable amount of important and creative work must
be done before the program can be written [24]. Forming a
solution to a problem can be done effectively with sound prob-
lem solving skills. To accomplish this it is necessary to create
a learning environment that facilitates students’ development
of problem solving and cognitive skills; enhances students’
acquisition of knowledge necessary for program development;
and encourages the retention and transfer of such skills,
knowledge and abilities to other situations. Problem definition,
planning and design skills should no longer be overlooked
Manuscript received December 11, 1997; revised August 16, 1999.
The authors are with the Computer and Information Science Department,
New Jersey Institute of Technology, Newark, NJ 07102 USA.
Publisher Item Identifier S 0018-9359(99)09164-5.
by the teaching methods. What is needed by students and
teachers is a coherent framework to use where the problem
solving process becomes a methodology connected to the
program development tasks. Students can learn programming
and develop problem solving skills by using the necessary
strategies to understand the problem, develop the solution
plan, and produce the design needed to implement and test
the solution. The programming language becomes a tool for
solving problems and the common focus on the syntax is
replaced by an emphasis on problem solving.
II. PROGRAM DEVELOPMENT TASKS
When learning problem solving and program development,
developing the skills to comprehend and define the problem
and its requirements, plan, design, implement, and test the
solution is one important part of the picture. Mastery of
program development tasks and methodologies is the other
important part.
A programming language has three aspects: syntactical,
semantic, and pragmatic. Syntactical knowledge refers to the
ability to construct grammatically correct instructions in order
to write a program. Semantic knowledge, in contrast, refers
to functional understanding of the programming language
and the meaning of its instructions. Pragmatic knowledge
refers to the practical understanding of the context and use
of language features. Programmers must develop such skills
as composing new and comprehending existing programs,
reusing and integrating existing code, debugging code, testing
programs, and documenting and modifying the programs they
write.
III. PROBLEM SOLVING METHODS
To synthesize a unified model for problem solving that
can be adapted to the particular requirements of program
development, one must first review the existing problem
solving methodologies to capture the essential features of these
approaches. Two of the earliest methods for problem solving
were given by [2] and [27], and represent opposite approaches.
Dewey’s approach essentially articulates the scientific method
for problem solving, while Wallas’ approach represents the
nonsystematic creative view of problem solving. This model
resembles the “sudden solution” or “Eureka” method described
by Hadamard [6] and the “creative method” of Poincare [17].
Subsequent models combined elements of both the scientific
and the creative approaches. Polya [18], [19], a prominent
mathematician, wrote a series of books on problem solving
0018–9359/99$10.00  1999 IEEE

2. 332 IEEE TRANSACTIONS ON EDUCATION, VOL. 42, NO. 4, NOVEMBER 1999
Fig. 1. Summary of problem solving models.
that are considered an outstanding contribution to the study
of problem solving. In two of his works, How to Solve It and
Mathematical Discovery, he presented a general method and
applied it to solve many types of problems. Polya’s model
is among the most widely used and referenced framework
for a problem solving methodology. Johnson [9] presented
a variation on Wallas’ creative method. Kingsley and Garry
[10] presented a variation on the Dewey’s scientific method.
Osborn [14] presented a three-stage model, later revised by
Parnes [15]. Simon [22] offered a model encompassing a set
of skills comparable to the ones required in other methods,
such as those suggested by Dewey and Polya.
More recent methods were developed to provide mathemat-
ics, science and engineering students with an explicit method
for problem solving. Generally, these models divided the
problem solving process into a more finely specified process
than the earlier methods. Notable among these models is
the work of Rubinstein [20], who introduces an element of
reservation. One such reservation is at the problem under-
standing stage where he looks at possible solutions before
finalizing the problem statement; there is a similar withholding
of commitment at the final problem solution. Stepien et al.
[25] offered a by then familiar view of the methodology.
Etter [5] presented a model which was a close variation of
Polya’s, used by students to solve engineering and science
problems. Meier et al. [12] introduced a recent instance of
the standard model of problem solving also as a method for
teaching mathematics and science problem solving. Hartman
[7] describes an explicit model, similar to Polya’s, to help
students improve their thinking and problem solving skills.
An overview of these methods is provided in Fig. 1.
IV. A COMMON MODEL
While there are many models of problem solving, none was
explicitly developed for the domain of programming. Problem
solving and program development form an interdependent
process and, therefore, require an integrated methodology.
Relevant features of different problem solving methodologies
are synthesized here into a common model that is then
integrated with the program development tasks to meet the
specific needs of students learning how to program. Thus,

3. DEEK et al.: COMMON MODEL FOR PROBLEM SOLVING 333
Fig. 2. The common model for problem solving and program development.
their attention is on the entire problem solving and program
development process, of which syntax acquisition and the
writing of code are significant parts, not ultimate ends. The
cognitive knowledge and skills required to carry out the
various tasks of problem solving and program development
performed in each stage of this process are also identified.
This new common model is a domain-specific one. But more
importantly, the problem solving models reviewed in this paper
are implicit, focusing primarily on the steps of the process as
opposed to the details of the tasks, the skills, and knowledge
required for each task of the process. The common model
explicitly addresses these tasks, skills and knowledge. Fig. 2
provides a complete view of the common model.
A. Formulating the Problem
If we identify all the significant recommendations by the dif-
ferent methods regarding the problem definition/understanding
phase, then that stage includes the following: The key ingredi-
ent was captured by Polya: State the question, and identify
the goal, givens, unknowns, and relations. Kingsley–Garry
and Osborn–Parnes emphasize producing a representation of
the problem. Polya’s method accomplishes one such repre-
sentation, though others are possible. Simon highlights the
ability to recognize that there is a problem in the first place;
however, our emphasis tends to be on problems that are given.
Rubinstein’s exhortation to defer details is implicitly addressed
by any method, since a method, by definition, enforces caution
and clarification, constraining the impulse to charge blindly
ahead. Nonetheless, Rubinstein’s recommendation is a good
guideline to keep in mind throughout the whole process of
problem solving. Hartman recommends diagrammatic aids
and an initial search for relevant concepts. Stepien et al.
recommend collaboration, that is, discussing the problem with
others.
The common model approach, which refers to this stage
as formulating the problem, includes all these elements, be-
ginning with creating a problem description. This can be
refined using an inquisitive approach facilitating problem
understanding through verbalization, asking and answering
questions, gathering information, restating the problem, in-
troducing notations and drawing diagrams to visualize the
problem and possible solutions. The goal being to identify
the pertinent facts about the problem from a refined problem
description, ignoring inessentials. The initial problem state
produced in this way is a description of the problem and
an organized representation of all relevant information: the
goal, givens, unknowns, conditions and constraints. All of
this is subject to revision as problem understanding develops.
Domain knowledge, problem modeling, and communication
skills are required to perform these activities.
B. Planning the Solution
A review of the different methods for this stage reveals
two key recommendations: identify alternative solutions and
devise a plan. Almost all the methods explicitly emphasize the
necessity of generating alternative solutions, which are then

4. 334 IEEE TRANSACTIONS ON EDUCATION, VOL. 42, NO. 4, NOVEMBER 1999
evaluated, and from which one is selected. Polya, in contrast,
recommends examining similar and/or simpler problems and
restating the problem. Though apparently different, this is in
fact a fundamental recommendation for “finding an alternative
solution,” because it provides an actual strategy for developing
solutions by examining simpler or alternative problems, which
one may be able to solve, and whose solutions can then be
adapted to the current problem. This provides a technique, for
example, for accomplishing what Wallas only recommends:
gain insight into the problem and discover solution, or into Ru-
binstein’s recommendation to: change the frame of reference
and search for solution patterns. Once a solution is selected,
Polya again provides the most inclusive recommendation;
namely, devise a plan, by outlining a potential solution and
breaking the problem into parts. The outline or plan for a
solution is just a high level view of the solution. This high level
view serves several purposes. It helps ensure the coherence of
the implemented solution and its fidelity to the objective of
the original problem, by deferring premature and distracting
immersion in the details of implementation. Once such a high-
level view is defined, the next logical step is to refine the plan
by breaking the plan/problem/solution into parts.
The common model approach includes all these elements
beginning with developing a solution strategy by assessing
possible alternatives and devising a plan for solving the
problem. The solution is more manageable when the problem
is reformulated into a set of smaller components. Therefore,
the goal is refined into subgoals that are more easily achieved
and the tasks to accomplish each subgoal are defined. Finally,
the givens and unknowns are related to the various problem
subgoals. Although the different problem solving models do
not explicitly state this, it is important to do so as we begin
to adapt the common model to fit the needs of programming.
Domain and problem-specific knowledge as well as strategic
skills are required to perform these activities.
C. Designing the Solution
If we identify all the significant recommendations by the
different methods regarding the implementation of the so-
lution, then that stage includes the following. Most of the
methods explicitly emphasize the necessity to select a solu-
tion from generated alternatives, which is then refined and
implemented. The essential tasks were clearly stated by Polya
in his carry-out-plan stage: Refine and transform the plan
into a solution, and decompose tasks. Others also call for
refinements, transformations, and decomposition. For example,
Kingsley–Garry and Osborn–Parnes emphasize refining the
solution, Rubinstein calls for transformations to simplify the
process and Hartman recommends breaking the problem into
parts.
The common model approach, which refers to this stage
as designing the solution, includes all these elements for
refining and transforming the plan into a design to solve
the problem. The plan devised in the earlier stage must
be implemented in order to produce the desired outcome.
First, a transformation from a high-level solution outline to
a carefully specified solution may require further refinement.
Existing subgoals, representing various solution components,
are examined to determine whether additional decomposition
is needed. Next, the relationships among solution components
are established, creating a hierarchical solution organization.
The different models for problem solving conclude the solution
implementation at this stage. However, since this common
model is being adapted for the programming domain, the final
implementation does not take place until the code is written,
and thus an additional step is added here to prepare for the
syntax translation. This requires that the subcomponents be
transformed into modules whose functions are specified, the
data associated with these modules are formally represented,
and an explicitly stated algorithm is created. As with planning
the solution, domain and problem-specific knowledge as well
as strategic skills are required to perform these activities.
D. Translating the Solution
This is a syntax-specific stage and the different methods
reviewed do not provide any explicit recommendations for the
programming domain. Translating an algorithmic solution into
programming language code requires extensive knowledge of
programming. The essential tasks here include: understanding
the language, the ability to compose programs consistent with
solution specification and to comprehend existing programs
that may be reused and integrated in a certain situation.
Also debugging programs is an important task here requiring
diagnostic analysis of coding errors.
The common model approach, which refers to this stage
as solution translating, regard translation as the first pro-
gram development stage, where a transition into programming
language mode is required to produce a program that runs
on the computer. Program translation is normally carried
out in parallel with the next stage of testing. The work
performed in planning and design is used as the basis for
program implementation. Mapping the algorithmic logic and
modules’ specifications into correct programming language
code requires various program development tasks. Program
composition is the first of which, requiring close attention to
syntax details in order to translate design specifications into
instructions suitable for machine execution. Comprehending
existing programs is also relevant for solution translation
and essential for reusing and integrating existing code. This
involves understanding the code from data/control structure
and design views, the purpose of individual instructions and
subprogram references, and the collective function of the
program as a whole. Debugging programs is another relevant
program development task, involving considerable logical and
deductive efforts in order to diagnose and correct syntax
error to assure that the programs will run. In addition to all
of the knowledge and skills required in the earlier solution
design stage, this stage also requires syntactical, semantic, and
pragmatic skills to perform the translation activities.
E. Testing the Solution
This is typically the last stage of the traditional problem
solving process, and is the most similar among all reviewed
methods. The standard recommendation of the different meth-

5. DEEK et al.: COMMON MODEL FOR PROBLEM SOLVING 335
ods is verify the solution. This verification procedure in-
cludes effectiveness of solution and accuracy of results. Many
of the methods also emphasize the evaluation of solution
suitability for other problems and, naturally, sharing and
reporting results. This problem-solving task is analogous to
testing programs, a fundamental program development task,
making this stage also a syntax-specific one. Students perform
code testing by developing and using test data to verify
program correctness. Modifying programs, another program
development task usually takes place as a result of code testing.
Of course, programs can be modified for other reasons also,
such as enhancing functionality and for reuse purposes.
The common model approach considers the main purpose of
this stage is to verify that the solution specification and results
are consistent with the problem requirements. This is done by
developing test data, testing the program using this data, and
examining the results for accuracy. While testing programs
for correctness can take place at various stages of their
development, a comprehensive posttranslation verification is
a must. Students should learn to develop test data suitable
for verifying program correctness, perform code testing, and
correct identified errors. The evaluation of test results requires
not just test for correctness and completeness, but also per-
formance oriented criteria such as efficiency, reliability, and
readability. Modification to the implementation, design or even
planning may be required on the basis of this verification.
Modifying programs entail changes to a program that may
affect its logic, language constructs, or data representations.
Programmers must also be able to modify programs in order
to alter their functionality or adapt previously written code
to solve new problems. The ability to modify a program,
especially after deployment, depends on the availability of
documentation, as well as the program comprehension and
composition skills of the programmer doing the modification.
An equally important purpose of this stage is to look back and
learn from the problem solving experience itself, acquiring
knowledge and skills that can be transferred to other problem
solving situations. This stage requires the same skills as
translation to perform these activities.
F. Delivering the Solution
The common model ends with solution delivery. The cog-
nitive activities of problem solving and program development
have been completed by this stage so no further problem
transformations are involved. However, the work produced
during the previous stages has to be documented and presented
in a readable and organized manner. Documenting programs,
solution strategy, and test results is essential for both com-
prehension and modification of code. In addition to internal
documentation, in the form of comments and explanations
embedded in the code describing the approach and tech-
niques used in solving the problem, external documentation
is also required. This includes documentation developed prior
to writing the code, such as problem description, solution
planning, specifications and algorithms, charts, as well as end-
user documentation. Communication skills are essential to
compile and organize the work of this stage.
V. CONCLUSION
Problem solving skills are not often emphasized by current
educational methods. Such skills form the foundation for
further learning; are necessary for scientists, engineers, and
managers, and must be treated as essential competencies for
all students [8], [23], [26]. General principles and methods of
problem solving, thinking, reasoning, and learning skills must
have a place in an academic curriculum [13], [18], [19], [21],
and should be taught within the context of a subject matter
[23]. Since forming a solution to a problem cannot be done
effectively without the requisite problem solving techniques,
the first course on programming seems both a useful and
appropriate place to introduce and enhance such skills. The
common model for problem solving and program development
presented in this paper can serve such purpose.
The issues regarding the choice of programming language
and methodology for the first course on problem solving and
programming are also important. However, there are various
competing design/program development methodologies that
are used in this first. Top–down design being the traditional
methodology, but with object-oriented growing rapidly. Also,
there still is a debate, and will always be one, on the most
suited programming language for this course. Again, with
C/C++ being among the more popular, but with Java and
others gaining grounds. Precisely because of these reasons
we are going back, in our courses, to the basic heuristics
of problem solving and thinking skills. For example, in the
common model, breaking down the problem is described
as a goal decomposition activity (goal decomposition is a
problem solving heuristic that is useful in both top–down and
object oriented methodologies). By focusing on the problem
solving heuristics that the common model promotes, the skills
and knowledge students gain can be easily transferred and
applied to the changing methodologies/languages as well as
to other subject areas. Finally, we are now in the process
of evaluating the impact of the methodology presented here
(currently used in all freshman-level computing courses at
the New Jersey Institute of Technology). Initial results, as
compared to earlier semesters as well as the study’s experiment
versus control sections, show a positive impact on students’
achievement. Also, instructors and course evaluation indicate
greater students’ satisfaction with the course, its content and
the methodology.
REFERENCES
[1] F. P. Deek, H. Kimmel, and J. A. McHugh, “Pedagogical changes in the
delivery of the first course in computer science: Problem solving then
programming,” J. Eng. Educ., vol. 87, no. 3, pp. 313–320, 1998.
[2] J. Dewey, How We Think. Boston, MA: Heath, 1910.
[3] A. Ebrahimi, “Novice programmer error: Language constructs and plan
composition,” Int. J. Human-Computer Studies, vol. 41, pp. 457–480.
[4] D. Ennis, “Combining problem solving and programming instruction to
increase the problem solving abilities in high school students,” J. Res.
Computing Educ., vol. 26, no. 4, pp. 488–496, 1994.
[5] D. M. Etter, Engineering Problem Solving with ANSI C: Fundamental
Concepts. Englewood Cliffs, NJ: Prentice-Hall, 1995.
[6] J. Hadamard, The Psychology of Invention in the Mathematical Field.
Princeton, NJ: Princeton Univ. Press, 1945.
[7] H. Hartman, Intelligent Tutoring. Clearwater, FL: H&H, 1996.
[8] J. R. Hayes, “Teaching problem solving mechanism,” in Problem Solving
and Education: Issues in Teaching and Research, D. T. Tuma and F. Reif

6. 336 IEEE TRANSACTIONS ON EDUCATION, VOL. 42, NO. 4, NOVEMBER 1999
Eds. Hillsdale, NJ: Lawrence Erlbaum, pp. 141–147.
[9] D. M. Johnson, The Psychology of Thought and Judgment. NY: Harper,
1955.
[10] H. L. Kingsley and R. Garry, The Nature and Conditions of Learning.
Englewood Cliffs, NJ: Prentice-Hall, 1957.
[11] R. E. Mayer, “The psychology of how novices learn computer pro-
gramming,” ACM Computing Surveys, vol. 3, no. 1, pp. 121–141, Mar.
1981.
[12] S. L. Meier, R. L. Hovde, and R. L. Meier, “Problem solving: Teachers’
perception, content area models, and interdisciplinary connections,” J.
School Sci. Math., vol. 96, no. 5, pp. 230–237.
[13] D. A. Norman, “Cognitive engineering and education,” in Problem
Solving and Education: Issues in Teaching and Research, D. T. Tuma
and F. Reif, Eds. Hillsdale, NJ: Lawrence Erlbaum, 1980, pp. 97–107.
[14] A. Osborn, Applied Imagination. New York: Scribner’s Sons, 1953.
[15] M. Page-Jones, The Practical Guide to Structured Systems Design, 2nd
ed. Englewood Cliffs, NJ: Prentice-Hall, 1988.
[16] S. J. Parnes, Creative Behavior Guidebook. New York: Scribner’s
Sons, 1967.
[17] D. N. Perkins and F. Martin, “Fragile knowledge and neglected strategies
in novice programmers,” in Empirical Studies of Programmers, E.
Soloway and S. Iyengar Eds. Norwood, NJ: Ablex, 1986, pp. 213–229.
[18] H. Poincare, The Foundations of Science. New York: Science, 1913.
[19] G. Polya, How to Solve It. Princeton, NJ: Princeton Univ. Press, 1945.
[20] , Mathematical Discovery: On Understanding, Learning and
Teaching problem Solving. New York: Wiley, 1962.
[21] M. Rubinstein, Patterns of Problem Solving. Englewood Cliffs, NJ:
Prentice-Hall, 1975.
[22] A. H. Schoenfeld, “Learning to think mathematically: Problem solving,
metacognition, and sence making in mathematics,” in Handbook for
Research on Mathematics Teaching and Learning, D. Grouws, Ed.
New York: Macmillan, 1992.
[23] H. A. Simon, The New Science of Management. New York: Harper
and Row, 1960.
[24] , “Problem solving and education,” in Problem Solving and
Education: Issues in Teaching and Research, D. T. Tuma and F. Reif,
Eds. Hillsdale, NJ: Lawrence Erlbaum, 1980, pp. 81–96.
[25] E. Soloway, J. Spohrer, and D. Littman, “E unum pluribus: Generating
alternative design,” in Teaching and Learning Computer Programming.
R. E. Mayer Ed. Hillsdale, NJ: Lawrence Erlbaum, 1988, pp. 137–152.
[26] W. J. Stepien, S. A. Gallagher, and D. Workman, “Problem-based learn-
ing for traditional and interdisciplinary classrooms,” J. Educ. Gifted, vol.
16, no. 4, pp. 338–357, 1993.
[27] D. T. Tuma and F. Reif, Eds., Problem Solving and Education: Issues in
Teaching and Research. Hillsdale, NJ: Lawrence Erlbaum, 1980, pp.
141–147.
[28] G. Wallas, The Art of Thought. New York: Harcourt Brace Jovanovich,
1926.
Fadi P. Deek received the B.S., the M.S. and the Ph.D. degrees in computer
science in 1985, 1986, and 1997, respectively, all from the New Jersey Institute
of Technology (NJIT), Newark.
He is Vice Chairperson and Associate Professor of Computer and Infor-
mation Science at NJIT. He has been teaching the introductory computer
science course for the past 15 years and has developed methods and tools
to support beginning students learning problem solving and programming.
His current research includes computer science education, programming
environments, problem solving/cognition/learning theory. He is the Director
of the Computing Education, Cognition, and Learning Laboratory at NJIT, an
applied research laboratory dedicated to the improvement of K–16 education.
Dr. Deek is the recipient of five different NJIT teaching awards and the
university’s Board of Overseer’s Public and Institute Service Award.
Murray Turoff (M’72) received the B.AS. degree in mathematics and physics
from the University of California, Berkeley, in 1958, and the Ph.D. degree in
physics from Brandeis University, Waltham, MA, in 1965.
He is a Distinguished Professor of computer and information science at
the New Jersey Institute of Technology (NJIT), Newark. He currently directs
the graduate degree programs in information systems at NJIT. He has been a
leader in the design and development of computer mediated communications
systems since the late 1960’s. He is the coauthor of the award-winning
book, The Network Nation. Recent work has been associated with the use
of computer mediated communications for improving the delivery of college-
level education and the support of project management and decision analysis.
James A. McHugh received the B.S. degree in mathematics from Fordham
College, NY, in 1965 and the Ph.D. degree in applied mathematics from the
Courant Institute of Mathematical Sciences in 1970.
He is currently an Associate Chair for Graduate Studies in the Department of
Computer and Information Science at the New Jersey Institute of Technology,
Newark. His research interests are algorithmic graph theory and visualization,
bin packing, and the application of problem solving methodology in computer
science.