Course standards
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.
Except for exams, the prontuario is the only piece of paper to be passed out in class. I won’t even accept a paper or CD copy; email is the only way.
All other material will be distributed through my web page http://ece.uprm.edu/~noack. You are responsible for checking this page at least once per week, and when changes are announced in class
Similarly, homework and projects are to be handed in as email enclosures and not hardcopy. A minor detail, when you hand in a group assignment, copy the other partners. That allows me to return the graded copy and the grade itself to all the group members. If your mailbox gets too full, consider detaching the attachment and keeping the message.
Assignments, office hours and other information
Office hours (Fall 2009):
Tuesday, Thursday 1:45 pm – 5:00 pm
Also I am often available in the universal hour Tuesday and Thursday 10:30 am –
12:30 pm
I am easily available by email, even at
odd times such as evenings and weekends, and for many purposes I prefer
it. It allows you to attach programs and
other data or output, and saves much time when your questions are short or specific.
(for in-office consultation I suggest calling on X3652 or emailing and will normally see you any time I am in the office). I will answer questions after class or between classes in the classroom, but not when it interferes with the next class given by another professor.
Team programming on short assignments
For most short assignments I am requiring team programming rather than individual work. This has several advantages to wit:
· You teach each other – often one person hangs up on an isolated point or undocumented feature – the other often finds the key to the problem.
· You often find quality problems or technique improvements
· I have less reports to grade
When a happy hour is given, only one participant (randomly chosen by me) is expected to demonstrate or answer questions. If that person has been a spectator or absentee, the result is predictable and disastrous.
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
· Security-related projects
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. Normally I bring my own laptop; if you plan to use it, remember to make your presentation readable in Office XP rather than 2007. Also, you can use your own, but make sure it works with our projector.
Remember to make diagrams readable – you should preview them with a projector, or failing that, sit six or more feet from your display. If you can’t read them at that distance your audience can’t read them in the normal classroom setting. The usual weakness is too small type in the labels and captions and delicate boxes and arrows. Also, check the colors for reasonable contrast.
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. This should be emailed to me the day (or at least evening) before the presentation.
The topics to be covered in each report are:
Requirements and Definition – Briefly, what are you going to do
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 – Briefly, how are you going to do it
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, so you can put them together readily when integrating the project.
Implementation – Briefly, did you do it, how, and how well
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.
Final report – this should be a stand-alone report completely describing the project. It is the first item I read at happy hour, so a little effort will pay you well. A typical length is 10 pages – not including your code; that should be in the source files themselves. Try to use readable diagrams – they are usually more significant and memorable than prose. The more important qualities are organization, completeness, and readability, not length.
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, but you or I can generate it with a simple style change. BTW, Microsoft Word allows making comments on the document in many different ways.
· 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, definitely not proyectofinal.zip. Also, please virus check everything, especially if of internet or Microsoft Office 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. Electronic form is preferable rather than CD/DVD. The size limit for email to ece is 10MB – most portfolios are somewhat smaller.
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 usual 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 duration 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-second 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.
Grading notation
For several reasons, mostly because I am too generous in giving partial credit, but also to speed up grading and to be more consistent, I have started using a somewhat odd notation in grading, shown in the following table
|
Symbol |
Value |
Meaning |
|
a |
OK |
Essentially correct |
|
- |
1/3 off |
Minor errors |
|
-- |
2/3 off |
Major errors, but some truth |
|
X |
No credit |
Missing, SciFi, or RADQ |
For programming problems, I sometimes show the grade (in points off) numerically, but for most other questions the credit for the problem will be a multiple of three.
Exam answers and review material on the webpage.
Almost always I place the answers for exams on the webpage immediately after the exam, I leave them there until the next exam in the series is given. This allows you to get an idea of the type and length of answer I expect, and the type of questions I ask. The answer shown is not necessarily the only correct answer. In particular, if I see an unusual but significant answer I check it rather carefully to see if it is a correct answer to a possibly different but reasonable interpretation of the question as it appears on the exam. Such answers receive full credit.
Why I use an open webpage rather than using WebCT or other information concealment techniques
Confidentiality – the only part of the course and associated material I keep confidential is the grades of individual students. Making a copy of the grade book with the student identity obliterated allow you to see how your grade compares with other students in the class, to assure you that I am avoiding bias in grading, and to make evident what the grading policy is. It also means that errors can be detected and corrected (other than on final exams, there just isn’t time or occasion for handing these back before grades are due).
Information sharing – This is an important and now neglected part of curriculum and course development. For people teaching later courses, such as OS, it is important to know what is currently being done in earlier courses, for example what languages and programming environments are used, and what level of mathematical and algorithmic knowledge to expect. Also, open pages are a help in keeping various sections of the course consistent, this also helps in meeting the needs of the next course in sequence, for example, Operating Systems and Micro II, based on the knowledge from Micro I. In this connection it should be noted that the ABET-mandated mechanism of formal outcomes designation and assessment is much more hindrance than help.
Technique sharing – In the past I have learned much from other faculty members’ webpages, both regarding webpage organization and presentation techniques. An example is some of the tutorial material developed by Dr. Sandra Cruz Pol, a past example is the elaborate PowerPoint methodology of Dr. Jorge Cruz Emeric. I don’t always agree with the specifics, but I have found useful methods. Since I have no plans to develop revenue-producing distance-learning courses, I have no need to restrict access.