Information Technology Reference
In-Depth Information
Leffingwell & Widrig, 2000; Brown & Dobbie, 1998) to be experienced by our PBL students
within their curriculum activities:
•
Analyzing the problem
: This includes a set of skills to understand the problem to be
solved before application development begins. It is the process of understanding real-
world problems and user needs and proposing solutions to meet those needs. We
consider a problem as the difference between things as perceived and things as derived
(Gause & Weinberg, 1989). Accordingly, if the user perceives something as a problem,
it is a real problem, and it is worthy of addressing. Typical techniques include gaining
agreement on the problem definition, understanding the root causes to induce the
problem, and identifying the stakeholders and the users, with the former being anyone
who could be materially affected by the implementation of the new application.
•
Understanding user needs
: This introduces a variety of techniques to elicit require-
ments from the system users and the stakeholders. Software teams are rarely given
effective requirements specifications for the systems they are going to build. Often,
they have to go out and get the information they need to be successful. Typical
methods include interviewing and questionnaires, requirements workshop, brain-
storming and idea reduction, storyboarding, use cases derivation, role playing, and
prototyping. Each represents a proactive means of pushing knowledge of user needs
forward and thereby converting fuzzy requirements to those that are better known.
•
Defining the system
: This describes the initial process, by which the team converts an
understanding of the problem and the users' needs to the initial definition of a system
or application that will address those needs. Our PBL teams should learn that complex
systems require comprehensive strategies to organize information for requirements.
This information could be expressed in terms of a hierarchy, starting with user needs,
transitioning through feature sets, then into the more detailed software requirements.
The latter could be expressed in use cases or traditional forms of requirements
documents, say, the vision document defining at a high level of abstraction, both the
problem space and the solution space.
•
Managing the project scope
: This reminds our teams that they should be aware not
to initiate projects with too large a scope to be accomplished. Project scope is presented
as a combination of the functionality to be delivered to meet users' needs, the resources
available for the project, and the time allowed in which to achieve the implementation.
The purpose of scope management is to establish a high-level requirements baseline
for the project. The team has to establish the rough level of effort required for each
feature of the baseline, including risk estimation on whether implementing it will cause
an adverse impact on the schedule. Also, each team has to actively engage its
customers in helping solve the scope management problem to ensure the quality and
the timeliness of the software outcomes.
THE CRITERIA FOR PBL EVALUATION
Throughout our students' study period, we have borne in mind that our instructional
method should be evaluated in part by its ability to explain practice. The following explicit
criteria (Greening, 1998; Ryan, 1993; Savery & Duffy, 1995) have been found useful in order
to later judge the learning outcome with respect to the process of problem diagnosis, action
intervention, and reflective learning:
