Before you get started
This class requires you to do a LOT of work between homeworks (3 or 4), reading assignments,
reading the textbooks, a pretty large project, and two exams.
Grading is quite strict as well, in that failure to get a passing grade in, say, the project will earn
you a failing grade in this class. Put it another way, you cannot get around work by skipping assignments
and hoping to pass based on a good class average.
^ Top ^
Late Work
All work that you turn in must be submitted on the Blackboard before
midnight (Central Time) the day the work is due.
I understand that from time to time you'll get overwhelmed with work, or that you may have personal problems
that will make you less productive than you'd like. That's why each student in this class has a credit of
two (2) days for late work.
You can use this credit as you see fit, for good reason or no reason at all, all at once
or in pieces -- though there is no fractional credit. The only thing we ask for is that,
in your Blackboard submission (in the COMMENT field) you indicate how much of your
credit you want to use.
Once you've used late credit you may not go back and ask us to apply it for something else; once you
use it it's gone.
After you've used your "late work credit", or if you don't want to use it, there is
a 5% per calendar day penalty for late work.
^ Top ^
Academic Honesty
All the work you submit must be individual, including, but not limited to, those cases
when your instructor has approved pair-programming for you; in these cases the only thing that
may be identical with somebody else's is code.
Academic dishonesty will not be tolerated. IIT has a strict academic honesty policy; here
are the top points:
-
The misrepresentation of any work submitted for credit as the product
of a student’s sole independent effort, such as using the ideas of others
without attribution and other forms of plagiarism.
-
The use of any unauthorized assistance in taking quizzes, tests or
examinations.
-
The acquisition, without permission, of tests, answer sheets, problem
solutions or other academic material when such material has been withheld from
distribution by the instructor.
-
Deliberate harmful obstruction of the studies, research or academic work of
any member of the IIT community.
-
Making material misrepresentation in any submission to or through any office
of the university to a potential employer, professional society, meeting or organization.
-
The intentional assistance of others in the violation of the standards for academic honest.
You can read IIT's Code of Academic Honesty
here. You should read it until you fully understand it.
A good way to test whether you understand it is to try to explain it to somebody else.
^ Top ^
Programming Language(s)
For any of the assignments in this class, including the project, please feel
free to use any of the free and/or
open-source (FOSS)
object-oriented programming languages in the set { Java, Ruby, JavaScript, Python, C++ }.
You may even use Smalltalk if you want to, however this will make testing
somewhat more difficult for us. Before you start, please check with your
instructor to make sure he's ok with it.
Work done using languages other than specified above, as well as the linking
of free and open-source software with proprietary 3rd party libraries will not
be accepted.
To learn more about free software check out the
Free Software Foundation.
You should also know that free software is not the same thing as open-source software,
this article from the
GNU foundation clarifies the matter for you.
^ Top ^
Test Environment
All programming work you do for this class will be tested on *our* computer(s)
running a fresh instalation of
Ubuntu 16.04 LTS (Xenial Xerus).
I'm sorry, but the fact that your code runs on your computer and not on ours is not
enough to earn you credit for your work.
If you've been using Linux, then this requirement is very easy to satisfy.
If you're new to Linux, then you'll have some learning to do, which is a very
good and valuable thing.
Let me repeat, we're not going to test under any version of Windows, nor are we going
to do it under any other Unix variant other than the one described above.
Moreover, we are not going to test your project inside Eclipse or other IDE; we
need to have clear instructions for how to get the code, build executable, deploy.
If we ask you to demo your project, then you'll have to do it in the test
environment specified above. A full demo will require you to do the following:
- Check out your code from the repository
- Build the executable
-
Run the script that calculates unit-test coverage and prove that it meets
the project requirements
- Deploy the executable
- Prove that your project does what the requirements call for
You typically have 30' for the demo.
If your application requires things (e.g. libraries, plug-ins, gems, etc.) that
don't come with the standard Linux distribution, then you should tell us, in
the README file you provide with your other deliverables, how to install required
dependencies. Better yet, your build script will install all that's needed
for a successful demo.
^ Top ^
Unit Testing
We're all tired of bad software, whether because it crashes when we least expect it
or because of security holes that allow the bad guys to take over our systems and identities.
We all pretty much despise software maintenance, in particular when we're asked to modify code
that we never touched, don't really understand, and have no way of making sure our changes
don't damage existing functionality.
The good news is that we can do something about it: creating automated unit tests for all
your code is a very good start. Doing it in Test-Driven Development (TDD) fashion is even better.
You cannot possibly get full credit for your work unless each and every method in your
classes has good unit testing. By good I mean meaningful and sufficient:
- A unit-test that just asserts true is not meaningful.
- Providing only one unit test for a method that requires multiple tests is not sufficient.
You will be required to measure and include with your deliverables the unit
test coverage as measured by the tool of choice in your chosen programming language, e.g.
jCoverage for Java, Rcov for Ruby, etc.
As a general rule automated unit testing will account for 50% of your mark in any assignment,
of which 3/5 is assigned to unit test coverage, and the other 2/5 will be awarded based
on how good your tests are.
If you fail to submit unit testing, then you cannot expect to get more than 50% in the assignment.
Unit test coverage above 80% is required for full credit. Unit test coverage below 50%
doesn't earn you any credit. For anything in between, you get one percentage point of credit
for each percentage point of unit test coverage. For example, if your test coverage is 73%,
then the most credit you can get for unit testing is 30-(80-73)=23. In another
example, if the unit test coverage is 51%, then the most credit you can get is 30-(80-51)=1.
Unit tests that are useless will be removed and the coverage will be measured again
before a mark is assigned for your work.
The other 20 percentage points for unit test coverage will be equally spread between
the methods of your code. If you fail to write any unit test for a method, then you
lose the corresponding percentage points; we will have discretion to give you less than
full credit if you haven't written enough unit-tests for a method. For example, if your code
has 10 methods across three (3) classes, then you get 20/10=2 percentage points of credit
for unit tests written per each method. Another way to look at this is to say that you lose
two (2) percentage points for each method that doesn't have any unit test.
^ Top ^
Project
The purpose of the project is to give you the opportunity to practice the
concepts discussed in this class. The requirements are purposely somewhat
vague such that you can interact with the client (that's your instructor) to
figure out the detailed requirements.
In addition to various deliverables you have to produce throughout the semester
and a working product on the due date of the project,
you are expected to develop a lot of automated unit tests as you work on this
project.
You'll be required to review the project of a peer, comment on it and make
critical recommendations for its improvement. 10% of your "Project"
mark will be tied to how well you grade your peer's project. Another 10% will
be the mark given to your project by the student reviewing it. Please note
that if you submit your project late, then your grade will be determined
entirely by your instructor.
We'll want to see constant progress in your project work; just getting started
a day or two before the due date is not going to cut it. That's why you're
required to give access to your software repository to both your instructor
and your TA by the end of 9/4/17. If you already have a GitHub account, then
you can share it with us. If this is the first time you have to do it, then
you may want to look at Github,
Bitbucket, Pivotal Tracker, etc.
^ Top ^
