Bill Pringle - Bill@BillPringle
| Home | News | Downloads | LDS | Talks | Famly History | Facebook | Games | Mobile | About Me |
Many of my classes involve a group programming project. It is important to remember that the goal of the project is not to write a program. The goal is to demonstrate your understanding and (hopefully) mastery of the subject matter. For example, if the course is about Data Structures and Algorithms, then you want to write a program that uses a lot of Data Structures and Algorithms. If the course is Programming Concepts, then you want to write a program that uses a lot of programming concepts.
The type of project your group decides on can affect your grade. If the project doesn't demonstrate the objectives of the course, then it will be harder to get a good grade. You can get a better grade doing a decent job on an appropriate project than doing a great job on an inappropriate project. That is because the goal is not to write a great program, but to demonstrate your understanding of the course topic.
You are free to form your own groups. There may be restrictions, depending on the course. For the Graduate School, each group should contain at least one full time programmer. For Continuing Education, each group should contain at least one person who has done some programming or extensive computer usage. Avoid groups where most members have very little or no programming experience.
Each team should have a name and a group leader. The duties of the group leader is to make decisions based on input from everyone in the group. This doesn't have to be the most experienced person. Often, it is better if they are the least experienced person. The team leader also provides me with regular Status Reports and is usually the person to contact me for advice or help with the project. (Anyone should feel free to contact me for help with the course, this is for help with the project).
Everyone in the group should do some programming. It doesn't have to be a lot, but it has to be something. They can get help from other members of the team if necessary, but the majority of the work should be theirs. This will be very important in determining your final grade, so make sure that you participate in the project.
Your group is free to choose any type of program for your project. I usually give some suggestions, but they are only suggestions. The suggestions, however, are usually good choices for the course. This is because the programs will afford you plenty of changes to demonstrate your knowledge and (hopefully) mastery of the course subject matter. If you want to pick a different program, that is fine. Just make sure that the program will give you lots of opportunities to exercise the principles you will be learning in class. Check with me to make sure that it is appropriate. I might offer some modifications to the scope that will help you learn more from the project.
You will probably do better if at least one person in your group is familiar with the subject matter of the project. Remember to start out small and then add things once you get the basic program working. It is much easier to keep building onto a working program until it is quite large, than trying to get a large program working from "scratch".
The purpose of the papers are to demonstrate to me that you understand (and hopefully master) the course subject matter. The paper should reflect how the project has helped you learn the subject matter and/or how you used your prior knowledge and experience on the project. The best papers are those that can use the project as an example of good (or bad) practices relative to the course material. This is why it is so important to pick a good project from the start. If you pick a project that provides lots of experience relative to the course topic, then you will have more to write about.
And remember, the goal of the project is to demonstrate your understanding of the course topic, not write a program. The program is the means to the end, not the end itself. You will get a better grade by adding features relative to the course, rather than making the program flashier.
I will usually require weekly status reports on your project. These should be submitted by the team leader. I prefer to receive e-mail, but will accept paper reports if you insist. It should contain specifics relevant to the course. Once again, for Data Structures and Algorithms, I would expect a report outlining the Data Structures and Algorithms being used. It should also contain how well the program is coming together, but always keep in mind the goal is not to write a program.
Each team will submit a final project on the last day of class. Frequently each team will have the opportunity to demonstrate their project on that day. Teams will submit a binder containing a group section and an individual section. All papers (group and individual) and source code should be submitted in both paper and electronic form. Programs downloaded from my web site do not have to be included, but mention should be made that they were used.
The group section should contain the following information:
Please organize what you hand in so that it is easy to find things. Index tabs or colored paper to mark the beginning of each section work fine.
The paper should include an evaluation of the project from the student's
perspective. (This may or may not agree with the group evaluation.)
See note below.
This section may also include a discussion of what was learned in the course. This should not be a rehash of the lecture notes or the text book. (i.e., not something you could have purchased or someone else could have written for you). It should contain what insights you gained from the course, especially pertaining to the group project or real-life experiences. It should not be a list of facts that you learned, but how it helped you with your project, your job, etc. How could what you learned help you to do the project better if you were to do it over again?
If you ever tend to cut corners, read the section on cheating
Remember, the goal of the project is not to write a program. It is to demonstrate your understanding and mastery of the subject matter. Grading will be based on how well you achieve this objective.
Think of this as similar to writing a book report. Suppose I told you to write a book report on any text book that dealt with the course topic. You are to be graded on the book report, not on the book. You can increase your chances of getting a better grade by picking a good book that deals with the course topic. You can also increase your chances if you read the book well. You are asked to write a paper on your programming project. You are not being graded on the project, but on the paper. By picking a good project, you can increase your chances of getting a better grade. You can also increase them by doing a good job on whatever project you choose.
The group section is graded based on how well the paper demonstrates an understanding of the subject matter. If you didn't get something working, that isn't necessarily bad. If you can demonstrate that you understand what you wanted to do, and how you wanted to do it, that will help. (Of course, you probably should have asked me for help on how to do something that isn't working, but that is another matter.) Everyone shares in the group portion of the grade.
The individual section is graded based on how well the individual demonstrates their understanding of the subject matter. There are two ways you can do this: (1) you wrote a significant portion of the actual project and/or paper, or (2) you explain how what you learned in class were done and/or could have been done on your project.
Please remember that you should not spend a lot of time on what you did or learned. You should spend much more time on what decisions you made, and why you made them. You should discuss how you applied (or would have applied, if you had time) the principles you learned in class to the project. Remember, you are not being graded on what you accomplish, but rather on what you understand. Write a short sentence about something you did, and then the next few paragraphs on what other options you considered, the pros and cons of each option, why you decided to do it the way you did. Then, based on your experience and what you know now, explain why you think you made the right (or wrong) decision.
Don't just list facts, explain what they mean and why it matters. (I'm not asking for lots of definitions, but explain real differences, not just different terminology.) For example, when creating GUIs, Java uses a text field, and VB uses a text box. So what? Is there any difference between the two, or is it just different names? Is there an advantage of one over the other? Does one make it easier or harder to do something than the other?
Don't spend a lot of time quoting others. If you include a quote, explain why you are including it. Discuss your understanding of the quote. Explain why you agree or disagree with it, or what insight it gave you. I can't say it enough: spend more time explaining why, not what.
Discuss how what you learned can help you in your career. For example, if you are a programmer, what did you learn that you can use to become a better programmer. If you are in the MIS program, how would you use what you learned to make decisions as an IT manager? Being able to recite a bunch of facts doesn't necessarily help you make a decision. You have to know what to do with those facts, and how to balance the pros and cons of various solutions to pick the optimal one.
Try to integrate your group paper. Avoid having a bunch of separate sections, each written by a different student, and each reading like you didn't read any of the other sections. That's what the individual papers are for. Your paper (and grade) would be greatly improved if you had one section that talked intelligently about the various aspects of the topic. It should compare the different aspects, weigh them, discuss the strengths and weaknesses of each. The group paper is supposed to be a group consensus. That means you have met, discussed the issues, and arrived at a conclusion.
Don't depend on a list or table of features and scores. While it is good to present a summary, and tables are a very good way to do that, you shouldn't stop at that. You should spend a lot of time discussing the various features, and explaining why the various scores were assigned.
Provide specific examples. Don't just state facts, illustrate that you understand what you just said (or quoted) by citing examples that illustrate this point.
Make sure you keep refering to how things relate to your project. For example, you can state that the advantage of a double linked list is that you can travel both directions in a list. That is correct, but it doesn't help you unless you can explain why you needed to travel both directions in a linked list within your project. Quoting a bunch of facts from some book doesn't help you unless you can relate them to your project. That's how I can tell that you actually understand what you just quoted.
Be honest in your evaluations. You don't get extra points by claiming that
your project was a success. The paper that starts with "I think I made every
possible mistake" has a better chance to get an 'A' than one that starts with
"I am quite pleased with the way the program turned out." It is extremely
unlikely that you did everything correctly. I know that I never do, so I
don't expect you to, either. What I do expect, however, is that you will
recognize your mistakes, identify what areas didn't go as smoothly as
planned, and decide what you would do differently if you had to do it over
again.
See note below.
When describing what you considered, or what you would do differently, explain your reasons. Saying "I would do X, Y, or Z" doesn't help much. For all I know, X, Y, and Z were randomly picked out of the lecture notes. Explain why you would do X, Y, or Z. Also, explain why you didn't consider A, B, or C.
I have never finished a project and said to myself, "That was great! If I had to do it over, I would do exactly the same thing!". If you try to say that, I get very suspicious. (BTW on those rare times when I was able to do it over, I often find out that my "better idea" wasn't as great as I thought.)
Don't just list a bunch of facts. Explain why something was good (or bad), what alternatives there were, and why you made the decisions you did. If you think you made the right decision, explain why. If you think you made the wrong decision, explain why, then explain what you think the right decision was, and why.
One final note. The evaluation should be critical, but also honest. Don't sugar coat how things went. Trying to convince me that your group did great when I can see all kinds of problems in your approach won't help your grade. Pointing out a problem that I didn't notice won't hurt you, either (in fact, it might help because it means you were aware of a problem that wasn't overly obvious.) Also, trying to convince me that your team mates are a bunch of idiots, and that you were the only one that knew what they were doing won't help your grade. If you know a lot more than the rest of your group, then try to help them learn more and do better. You can only help your own grade in the process.
The Group and Individual evaluations are from completely different perspectives. For example, the group might have decided to do something that was a really good idea. In the group section, you would state that it was a good idea, why it was a good idea, what other options were considered, and why you chose the one you did. However, maybe you were supposed to implement this good idea, but ran into trouble because you misunderstood what was expected. In your individual section, you admit what went wrong, explain why it went wrong, and what could have been done to prevent such a thing from happening again. That can count just as much as if you had done what had been expected. In fact, if you just lucked into doing the right thing, you probably haven't learned as much as the other situations.
If you agree with the group's decision, that is fine, but not required. In addition to personal experiences, I would also expect the individual sections to contain more detail and possibly different reasoning behind group decisions when they were involved. I would especially expect the "what would you do different if you had more time" question to be answered differently. If you say the exact same thing in the individual section that was said in the group section, then I have to wonder if you had any thoughts of your own on the topic. (If you are the one who wrote the group section, say so. :^)
Don't Cheat
The University has a strong position on Academic Integrity. If you are suspected of cheating, you can be charged and, if proven guilty, receive a grade of FX. This is a special grade that indicates you flunked the course because you cheated. It will never be removed from your record.
Besides being wrong, it is stupid. You are taking a big risk. And, for my classes, it won't do you any good, even if you get away with it. The papers you are to hand in are to contain personal experiences. Generic papers, such as you can get off the internet, will get you the lowest possible grade from me. If you luck out and pick a really good paper to hand in, (and I don't notice that you cheated), it will score less than somebody who wrote a really terrible paper, but included lots of personal experiences. If you pick a poorly written paper, you might end up with a failing grade.
There are two ways to cheat: hand in a paper entirely written by somebody else, or cut and paste several papers into yours. Both are bad ideas. If you copy an entire paper, there is no way you can cover all the topics that I outline. And, of course, you will have a really hard time trying to insert your personal experiences into the paper, because the points that the paper raises won't necessarily match what you have experience with. That raises a red flag for me. If you copy and paste several papers into yours, you are taking even more of a risk. The chances are really high that you will include papers with different opinions, which will result in you making contradictory statements. Another red flag.
If I suspect that you have cheated, I will do a search on the web. Remember: if you can find it on the web, so can I. Even if you paraphrase somebody's paper, there is a good chance I will find it. If I can't find your material on the web, then there are sites where instructors can submit electronic versions of student papers. These sites analyze the papers sentence by sentence, and report on any duplications, citing the references. If you are lucky enough to be the first person to use your source, you might get away with it; otherwise, you will be caught.
And if I think you have cheated, I will give you a grade of DF (deferred grade), and give you the opportunity to either admit what you have done, or contest it. If you admit to cheating, you will have to take the course over again, and the best grade you can hope for will be a C. If you contest it, and are proven guilty, you will receive a grade of FX (failure due to cheating), which goes into your permanent transcript and is never removed. If you are proven not guilty, then the charges are dropped, and then I grade you on the paper you handed in. (Please review what I said above about what kind of grades generic papers are likely to get.)
The bottom line is, Don't Cheat!
Here are some guidelines about how to write an honest paper
© 1999-2014 Bill Pringle. Hosting courtesy of CHCS Consulting. This site best viewed with FireFox.