The reports and projects must be completed in order to pass the course. This includes the in-class reports.
Exam attendance is required unless you have a medical excuse or equivalent documentable emergency.
Class attendance is also required. You are allowed three unexcused absences with no questions asked, beyond this number your grade will be reduced.
Dishonest behavior, as commonly understood, which includes exam cheating or plagiarism, failing to do your part of a project, and presenting a project that is not your own work, will result in at least a zero for the exam or project, and for an aggravated incident, failure in the course and initiation of University disciplinary action. In research, you expect to build on others’ work, but it should be very clear what is yours and what is theirs, clearly referenced or acknowledged.
Projects - General
Normally, I require group projects in all software courses except ICOM 4015. The intent is to give you a chance to experience various aspects of working in industry while you can still make mistakes without career damage. Working in groups of three or four people allows you to learn about the techniques and problems of group organization and interaction.
If you do not make the oral reports, do not expect a passing grade for the project. A project that appears on the last day of the semester, without previous reviews, is rarely responsive and will not be accepted. Also, a completed project is a required part of the course.
Projects - ICOM 5007 specifics
Acceptable projects include
· Operating system utilities
· Significant kernel modifications
· Device drivers or modules
· Significant utilities for working with handheld devices of various types – palmpilots and similar devices – windows CE applications are also possible
Three in-class reports are required - Requirements and Definition, Design, and Implementation. These are short in-class reports, normally using overhead transparencies; and the primary intent is to allow you to see how your work compares with other groups and to share ideas about giving reports and handling the problems of projects. It also lets me see whether your group is functioning well or if it needs some redirection.
There are three required components of an in-class report:
A well-rehearsed oral presentation.
Transparencies to support the oral report. I recommend using Power Point or other equivalent presentation software and considering the human factors – for example, an audience can’t read a type size much smaller than 14 points, or understand complex diagrams with unreadable labels. Data displays are available in the department if reserved in time.
A short (two pages or so) content-intensive report. This is not merely a copy of the transparencies; it is a serious, factual, and concise-but-thorough report of the specifics of this phase of your project.
The topics to be covered in each report are:
Requirements and Definition - Requirements means what you need to do and what you need to have in order to do it. Definition is the statement of what you actually plan to do (beyond the bare requirements); it is your statement of what the program or product should do, but not the internal details of how you will implement it. Also, you need to describe your division of labor, stating what are the major parts of the project. For each part of the project, you need to state who develops that part and who verifies it (a different person).
Design – This report states how you will do the project and what changes you might have made to the definition. If you are doing object-oriented design, it means the major objects and their interrelationships. At the conclusion of the design phase, you should be able to implement the parts of the project independently and in parallel.
Implementation – In this report you should state:
What you accomplished and how well it performed
How you verified its functioning and performance
A brief statement of how to use it.
The project portfolio is intended to provide me (and you) with a permanent record of your project. It should contain everything you did for your project, including:
· All source code
· All documentation for the project (this may be text, word, or html, and may even be mixed (for example if you did man pages, although these should also have pdf versions)
· The executables
· The final report and all your in-class presentations.
o In-class presentations include both the slides and the short reports. Slides should be in Power Point or its equivalent.
o The final report should be well-formatted in some variety of word processor, and should not be double-spaced. Many people like double-spaced text – I prefer single-spaced so I can see the big picture; double-spaced is useful when copy is to be hand-marked.
· A readme file. This should describe your portfolio. Both it and all your reports should contain all the authors’ names and email addresses, if you usually use an outside mail address, show your Amadeus address also. If you prefer to use an outside ISP, I would recommend using a .forward file in Amadeus. This should be in the root directory of your zip file.
· The original of any code or other information you reuse must be in a separate directory and its origin (especially if from the internet) must be clearly identified. If it is from a book reference, the book must be available at the happy hour. Note that your English (or mine) looks nothing like formal textbook or journal article writing.
I am not picky about the structure of your portfolio. You may, but don’t have to, use the format of Dr. Javier Arroyo. The important thing is to organize it intelligently (separate directories for each of the four categories above). A zip or tar file is a good way to hand in the portfolio, but it must have a unique name, I suggest os_your_Amadeus_login.zip – I need this so I don’t store your file on top of another report. Since your Amadeus name is unique and your hotmail name may not be, please use one of your groups login names from Amadeus. Also, please virus check everything, especially if of internet or MSWindows origin. I will not forgive you for any such contagion. Please make sure your zip file is expandable with Winzip – some Linux gzips are not readable except with gunzip. The man page for gzip explains this, cryptically.
Please note that I will not conduct your happy hour unless this file is available and complete.
Happy Hours
The happy hour is intended as a working review of your project, not a formal presentation. Thus it is conducted in the laboratory rather than a presentation room and in normal student/faculty attire. My normal procedure is to
· Read the report - I do this on the spot so I won't confuse your ideas with others.
· Have you demonstrate the program and try it myself.
· Examine parts of the code or other implementation details. During this process I may ask questions of either the developer or the tester.
· Examine how you verified that the product worked correctly and efficiently.
· Ask your rationale for your engineering decisions and how you might make a specific improvement. This often reveals your understanding of the project.
A happy hour is not intended as a harassment; it is a serious review of what you did, conducted as it would be in a professional environment. It is definitely not a stress interview, and if you feel so, you should say something - I will definitely try to mellow the atmosphere. Its duratio<, depends on the grade; A projects take longer because I am interested, C and below take longer so that you reach understanding of the problems with your product. The shortest happy hours are those resulting in B's.
Comments on Oral Presentations
Short presentations are more difficult than long ones; they have to be rehearsed with an audience and with their visual aids in order to detect illogical or incomplete explanations or unreadable slides. Advertising people know this; the thirty-minute spot that annoys you has been redone and reviewed many times more than the show it interrupts.
The first commandment for doing oral presentations is to work with your audience. If you are in contact, facing and observing audience response, you will discover most of your other problems. You will find out if you are blocking the audience’s view of your slides, if they can’t hear you, if they are bored or confused, and only if you face your listeners can they hear you. If you stare at the screen in amazement as though you have never seen the slides before, your audience will believe you haven’t, and they won’t be able to hear you anyway. If you have rehearsed, your rehearsal audience can tell you whether you can be heard, and whether your presentation is logical and in sequence, and whether your slides are readable, logically arranged, and have a good appearance.
Slides should have professional content and design. This means more than just bare readability, but near-instant understandability. Complete sentences are rarely needed – phrases, and short lists make more sense. Complex diagrams should be broken apart, first an overall diagram, and then separate diagrams of each part. Highly colorful designs are often distracting, and clip art is usually trite and irrelevant, especially the little stick figure pulling out his last hair and asking “Any questions?” Again, you will discover these problems during rehearsal. The secret is to really learn the tools (Power Point and how to include any imported data such as images, diagrams, and code, also templates and slide masters). This takes practice and study of other presentations, the samples provided with the software are usually sales presentations and not of much use.
Finally, unless you have checked your visual aids beforehand, Murphy will surely visit. Examples – burned out bulbs or data displays, wrong settings such as data display resolution, missing signals at the laptop output, dim images (you can sometimes fix this by changing your slide master to a different color scheme or going black&white), even missing electrical outlets or cords that won’t reach.
Exam Policy and Methods 
For several reasons I give open book exams and make previous exams available. The open book exam fits the way software is actually done, relying on memory rather than using the documentation is a sure way to introduce errors and learn debugging techniques. In this context you should be learning capabilities and how to find the details when needed. Also, I seldom give problems that are just simple arithmetic solutions to already familiar problems; my preference is either open-ended design questions or reasoning questions that require some synthesis based on information from various contexts to arrive at an answer. The abbreviation RADQ (right answer to a different question) means that your answer doesn’t appear to be a logical answer to this question.
Also, memorization is the lowest level of
learning; reasoning and application come higher on the intellectual scale.
Descriptions are a necessary part of
programs; they help you to develop a good program and help me to grade it
fairly. For this reason they normally are half the grade for the problem and
are required before I will grade the other half. In various situations the
question may call for any of these possibilities, in decreasing order of
complexity:
· Complete program - This includes the global area, includes and all functions, including main.
· Function - The header and body must be included.
· Code segment with declarations - Only the variable declarations and necessary code for the specified task are required.
· Code segment without declarations - The variable declarations will usually be given; you get to write the code to accomplish the specified task.