| Required? | Title | Author | Publication information |
| Yes | Problem Based Learning:How to Gain the Most From PBL | Donald Reasons | Available from Instructor |
| date | weight | |
| Midterm | 11 November | 10% |
| Final (take-home) | ***TBA*** | 15% |
| Requirements Specification | October 28 | 20% |
| Design Documentation | November 18 | 20% |
| Design Presentations | November 18 | 5% |
| Prototype /Demo Due | December 9 | 10% |
| Prototype Documentation | December 9 | 10% |
| Final Presentation | December 9 and 11 | 10% |
| Date | Topic | Reading | Project | Homework | Handout | |||
| 1 | 10/10 | Introduction | PBL Steps | |||||
| 2 | 10/14 | Group Assignments | Pretest | |||||
| 3 | 10/16 | PBL Demo -- The Chair! | Educational Prescription | |||||
| 4 | 10/21 | Group Meetings | ||||||
| 5 | 10/23 | Group 1 presentation | ||||||
| 6 | 10/28 | Group Meetings | ||||||
| 7 | 10/30 | Requirements Doc Due | ||||||
| 8 | 11/4 | |||||||
| 9 | 11/6 | |||||||
| 10 | 11/11 | Midterm Exam | ||||||
| 11 | 11/13 | |||||||
| 12 | 11/18 | Design Presentations | ||||||
| 13 | 11/20 | |||||||
| 14 | 11/26 | |||||||
| 15 | 12/3 | |||||||
| 16 | 12/5 | |||||||
| 17 | 12/10 | |||||||
| 18 | 12/12 | |||||||
| 19 | 12/16 | |||||||
| 12/18 |
W. Michael McCracken
October 9, 1996
Design of software systems is often related to a category of problems called ill-structured problems. Ill structured problems exhibit characteristics of not being well defined, being able to be solved with multiple strategies as well as having multiple acceptable solutions. Information systems design is typically taught using combinations of techniques including problem solving method focused lectures, exercises and projects. The intent of instruction in these types of classes is to familiarize students with the process of design. Quite often the result is that students become quite familiar with tools and techniques but gain little practical experience in actually creating design solutions to problems. That is, they can draw great boxes and arrows, but they can't design.
A new approach to problem solving education has been developed in the field of medicine. This approach, called Problem Based Learning (PBL) has replaced the standard medical curriculum at several universities. The classical medical curriculum contained two years of science followed by two years of clinical practice. The PBL approach integrates the four years into a continuous problem solving model that increases with complexity over the period. Though explicit measures of success are just becoming available, the notion of eliminating formal lecture sequences followed by practice is compelling. The goals of PBL are: 1) developing scientific understanding through the use of realistic problems, 2) developing applied reasoning strategies and 3) developing self-directed learning strategies. In PBL, an authentic problem that requires solution is presented to a small group of students. The students discuss and refine their understanding of the problems and propose tentative solutions. As students discuss the problem, they raise issues that can be used as learning goals for later independent, self-directed learning. The results of this independent learning are brought back to the group to further elaborate and discuss the problem.
Problem Based Learning (PBL), as previously mentioned, uses realistic problems as a mechanism for learning. The three goals, develop scientific understanding, applied reasoning strategies, and self-directed learning strategies via immersion in authentic problems is difficult in its implementation. The approach relies on a student's ability to reason about problems, develop lists of open items that need to be investigated, and make decisions relative to the allocation of resources. In addition, it relies on the instructor being able to guide the students without constructing solution models or providing answers to the students. That is, instructors have to be mainly seen and not heard.
The methodology for PBL follows a general problem solving approach using groups of students, rather than individuals. A problem is posed to the group. The group must first understand the problem, develop potential solutions, create lists of items that need further investigation, recast the solutions as a result of the investigations (that is, iterate), and develop validation criteria so that they may decide when they have a solution. In addition, students must develop skills in interpersonal interaction (since it is a group project) and skills in decision making.
As a part of developing a set of problems for CS 4351, we developed the learning outcomes for the course. These were used by the instructors to ensure that the problems we select adequately cover the outcomes. The learning outcomes are:
1.) Develop skills in designing information systems using a subset of the available techniques and methods currently in practice, including the ability to select the appropriate technique/method for a particular application type.
2.) Develop group interaction skills including effective communication skills.
3.) Develop project planning and management skills at the level of managing a small group project.
4.) Develop general software engineering skills at the level of producing correct and complete artifacts for a small project.
A list of the criteria for student evaluation follows. Appendix A contains the course syllabus and the allocation of grading for the course:
• Project Reports : Three project reports are required to be produced for the project. The project reports are the main basis of evaluation of the projects. The reports cover requirements, design, and a description of the prototype. The students have to describe the process that they apply in each phase of their project assignment as well as the actual product of that phase.
• Presentations : A formal presentation at the midpoint and completion of the project will be given by each group and graded by the instructors. The grade given on the presentation will be based on the ability to effectively convey the results obtained from their work and on the content of the presentation itself.
• Student evaluation by team members : Individual students are asked to evaluate the contributions of their team mates at the completion of each project phase. The evaluation is used to adjust the individual grades of a student who is not contributing to the project.
• Examinations : Two examinations will be held over the quarter; the midterm counts as 10% of the grade and a comprehensive final exam counts as 15% of the course grade.
The grading criteria, appearing in Appendix B, has been established by the instructors for each milestone. The criteria is used to establish the minimum requirements for the project document for each phase of the project. The graded documents will be returned to the students at the next class meeting.
The document that the team turns in is required to include refinements made to the previous part of the project, and the team is expected to correct any errors noted by the instructors. Although not much credit is specifically assigned to this refinement, ignoring the corrections is penalized heavily due to the project's nature of building on previous work.
The examinations test the students on concepts and understanding of fundamental principles rather than regurgitation of facts given in the text book. The exams are open book and open-notes, as the emphasis is on analysis of a problem and less on the student's retention. The questions are designed so that a student who has done a fair share of work in the project and has understood the process will do well on the examination. A typical question on the exam describes a problem scenario and asks the student to present and validate a possible solution. While the questions are not classified as either simple or difficult, they are definitely intended to be thought-provoking.
This course covers the "state of the art" of Information System technologies and the methodologies for developing those systems.
You should note that this course is being taught by the problem based learning technique. What that means is that there are few if any lectures by me. Your job is to explore the various methods, techniques and tools available to an information systems designer, under my guidance, and come up with solutions to problems I pose to you. The problems are as realistic as I can make them, within the confines of the academic quarter. You will likely be frustrated, and get mad at me at various times in this course. Believe me, my intentions are not to cause these disturbances, but nevertheless at times you will feel that I am hiding information from you, not being very cooperative and being downright critical of what you do. The point of problem based learning is that more effective learning occurs when the student explores the space of solutions on their own, tries various approaches to the solution of problems, and most importantly reflects on the results of their efforts (both good and bad). This is not an experiment, it is a technique that is in place in many different forms throughout the world, though I am the first to be actively using it in the College of Computing.
You should be forewarned, if you are a plug and chugger, or expect to be spoon fed information to be repeated on command, you will not survive the course. If you feel that this approach will result in the course becoming a snap, you are also wrong. In fact, this course will require more work than most courses, but I expect when it is all over you will know how to approach problems of building information systems in ways and with a depth of knowledge that you may never gain in classical didactic teaching approaches. If you have concerns about this, see me.
Please note, if you are a person who would rather sit alone and hack, this course is not for you, nor is a job in the IS field one you should consider. Though, we will stress technical aspects of information system design, you will be performing these activities in a social context with your colleagues and customers. If you are unable to interact effectively with these people you will not survive this course.
The course assessment will be based upon:
(10%) A mid-term exam, that will cover the first half of the course
(15%) A final exam, that will cover the total course.
(75%) The project. This evaluation will include your contributions to the projects, your knowledge gained through the projects, and your ability to convey those results and knowledge
The project will be announced during class. The class will be divided into groups for the projects.
W. Michael McCracken (mike@cc.gatech.edu), Room 265 AECAL, x6172,Office Hours: Will be posted on my door.
Two interesting topics we need to talk about. This course is based on reality, that is, I will try to help you understand the real world aspects of Information Systems. What that means is that we will relate the theoretical basis and the uses of information in organizations, and then relate that to the practical usage of information within organizations. The project is as real as we can make it, and it is the vehicle we will use to exemplify everything. Outside reading and discussions with your classmates is expected. I expect that you are Seniors and have taken such things as Data Bases, Operating Systems, Software Engineering and you have an understanding of how to analyze a computer system. If not, you may have to do some extra work to keep up.
As far as discussions with your classmates, you all have e-mail accounts. You should set up group aliases and include the TA and myself in the conversations when you need our help.
If you're smart you've found somebody who has taken this course previously from me. Though the teaching and evaluation methods will be different, you will find out that I grade the project write-ups very carefully. What that translates to is that I expect outstanding work on them and no less.
Because we don't have a bunch of boring lectures in class doesn't mean you can punt class and make it through this course. What we will primarily do in class is discuss your projects, with my offering criticisms and guidance. What you will gain from listening to the discourses with other students is significant. If you only listen to the critiques of your work, you will miss most of the concepts and ideas behind building information systems. Since everyone will be working on the same project, you will learn how to evaluate and critique the decisions that go into making a correct solution to the problems. Remember, there is no one solution to any of these problems, but there are definitely more bad than good solutions.
Unexcused absences from the mid-term, or final, and not showing up for the project presentations will result in an F for the course.
The other rule is have a good time. If you aren't having a good time with this class, I suggest you look for another career.
Requirements document
Methodological (30)
____/ 10 Elicitation methods and techniques
____/ 10 Validation
____/ 10 Methodology associated with representation
Representational (30)
____/ 10 Formality
____/ 10 Criteria for Selection
____/ 10 Representation Correctness
Acceptance Criteria (15)
____/ 5 Completeness
____/ 5 Conciseness
____/ 5 Correctness
Other (25)
____/ 5 Usability Requirements
____/ 5 Other Non-functional Requirements
____/ 5 Validation/ Verification
____/ 10 Understanding/ Depth of Problem
Design Document
Requirements (0)
____ Revision
Overall Description (10)
____/ 5 System Architecture
___/ 5 Functional Allocation
Decomposition (30)
____/ 10 Components
____/ 10 Definitions
____/ 10 Quality Measures (Completeness, conciseness, correctness)
Human Interface Design (30)
____/ 15 Screen Layout
____/ 5 Semantic Properties
____/ 10 Quality Measures (Completeness, conciseness, correctness)
Other (30)
____/ 10 Traceability
____/ 15 Testing
____/ 5 "Bonus" points