cs487 - Software Engineering I - Fall 2016

Before you get started

This class requires you to do a LOT of work between reading assignments, a pretty large project, and a final exam.

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.

Hours

Books

Textbook(s)

Software Engineering (9th Edition), Ian Sommerville, Addison Wesley, ISBN-13: 978-0137035151

Other books

I highly encourage you to read these books, you'll discover that you'll keep them around you for your entire career as a professional Software Engineer.

• The Pragmatic Programmer: From Journeyman to Master, Andrew Hunt and David Thomas, Addison Wesley, ISBN-10: 020161622X, ISBN-13: 978-0201616224
• Surviving Object-Oriented Projects, Alistair Cockburn, Addison Wesley, ISBN-10: 0201498340
• Code Complete: A Practical Handbook of Software Construction, Steve McConnell, 2nd edition, Microsoft Press, ISBN-10: 0735619670, ISBN-13: 978-0735619678
• The Mythical Man-Month: Essays on Software Engineering, Frederick P. Brooks, Addison Wesley, ISBN-10: 0201835959, ISBN-13: 978-0201835953
• Peopleware: Productive Projects and Teams, 2nd edition, Tom DeMarco, Timothy Lister, Dorset House, ISBN-10: 0932633439, ISBN-13: 978-0932633439
• Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison Wesley, ISBN-10: 0201485672
• Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, Prentice Hall, ISBN-10: 0132350882, ISBN-13: 978-0132350884
• Patterns of Enterprise Application Architecture, Martin Fowler, Addison Wesley, ISBN-13: 978-0321127426

Grading

• Final: 60%
• Project: 40%

The following grading scale will be used to determine your grade in this class:

• A: [90, 100+)
• B: [80, 90)
• C: [70, 80)
• D: [60, 69) ... this grade may not be assigned to graduate students, instead an E will be assigned.
• E: [0, 59) This is a failing grade!

Class participation will help settle borderline grades. While class attendance is not taken, your instructor believes that regular class attendance is important and expects students to actively participate in class. Questions and comments are always welcome.

Late Work

Exceptional circumstances

Your teacher will try to accommodate you in those cases that are beyond your control, such as medical and personal emergencies. Please note that, based on circumstances, the teacher may decide to assign you an incomplete grade, "I", or otherwise ask you to drop the class.

Incomplete ("I") Grades

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:

1. 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.
2. The use of any unauthorized assistance in taking quizzes, tests or examinations.
3. 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.
4. Deliberate harmful obstruction of the studies, research or academic work of any member of the IIT community.
5. Making material misrepresentation in any submission to or through any office of the university to a potential employer, professional society, meeting or organization.
6. The intentional assistance of others in the violation of the standards for academic honest.

Extra Credit

There are multiple ways you can receive extra credit in this class, here are some:

• Take class notes: scan them and return them to your instructor after each class in PDF format. If you take notes electronically, then turn in to your instructor a copy of your notes, .txt, .odf, .doc, .pdf formats ok.
  • Maximum extra credit: 5 points that will be added to the average class score (scale from one to 100)
  • If you want to get this extra credit, then you'll have to commit to turning in notes for each class.
  • In addition, your instructor will have to confirm upfront that you are eligible for this extra credit since only one student in class can get it.
• Identify errors in the project definition, e.g. typos, wrong commands, conflicting statements, etc, and submit a suggestion for how it should be corrected. Extra credit depends on how significant your find is.
• Recommend new projects or homeworks for this class. Your recommendation should be original and non-trivial. If you're not sure what original and non-trivial mean, then talk to your instructor.
• Extra credit: 5 points per accepted recommendation. All extra credit will be added to your average class score (scale from one to 100).
• Recommend problems to be included in the midterm or final. You'll get credit for submitting a good problem. Your submission should be original and non-trivial.
• Extra credit: 4 points per accepted recommendation. All points you earn for your recommendations will be added to your average class score (scale from one to 100).
• The credit will be doubled for each problem that's included in the exam.

Exams

Exams are open-book(s), open-notes and comprehensive. You may bring with you any notes you want, however you may not share them with anybody else during the exam.

During the exam the use of communication devices such as phones and computers is not allowed. You may bring with you a calculator if you think you need one.

Programming Language(s)

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.

If you're building a mobile application, then we'll use the simulator/emulator that comes with iOS or Android.

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.

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.

Communications

Typically the first person you should contact for any questions related to assignments is your TA.

Please be descriptive in the subject line when you email your instructor such that processing doesn't get delayed. At the very minimum you should indicate the class and the term, followed by a brief description of what is it that you want to communicate.

Examples of good subject lines for your email:

• cs487, Fall 2016 - Hw1, part (i)
• cs487, Fall 2016 - When will the grades be posted on the Blackboard?
• cs487, Fall 2016 - Question about project

Assignment Submission

You are required to submit your work online, using the Blackboard. Late work will be accepted, however it is subject to the late penalties described in this syllabus.

Here are the requirements:

Project

The true measure of good Software Engineering is working software delivered on time--not much of a choice here since the delivery date is fixed--and that satisfies the customer expectations. Your budget is fixed too since you cannot add new members to the team.

Agile

The only way you can complete the project by the end of this semester is if you work using an agile methodology. Each iteration is one week long.

Team

If you are in section #1 (live, Main Campus), then you'll do the project as part of a team of 4-5. Students in all the other sections will work on individual projects.

You should work on creating a team or becoming part of a team. Your instructor doesn't like assigning students to teams.

Topic

If you have an idea, then pitch it to your peers and get them to join your team. In this case you are the customer and the delivery team which makes for some interesting challenges: you're more like an entrepreneur than a small company that delivers software on to paying customers.

If you are part of a team that works on a sponsored project, then your instructor is your customer; he will provide the high-level requirements for the project, answer your questions, etc.

If you are not in the live section (aka Main Campus), then you'll have to work on a project on your own. Choose a topic and run it by your instructor to make sure it's reasonably simple but not too much so.

Your instructor will assign you a project topic only if all else has failed.

FOSS

All work you do is FOSS. Your instructor prefers GNU's GPL, however for purposes of this class you may use any of the open-source licenses that are popular, e.g. Apache, MIT, FreeBSD.

Weekly Updates

Each team and each student who does an individual project will need to submit a weekly status on the Blackboard. Teams will need to deliver their status live - in front of the class - as well.

Here's what needs to be in the weekly status:

• Team name (student name for individual projects).
• Team members. Not required for individual projects.
• Work done during the previous iteration (last week)
• What you plan to accomplish during this iteration (this week).
• Issues you're facing, whether technical, team, etc.
• Number of story points completed in the previous iteration and the number of story points left to completion. This will make sense as soon as you have created user stories, decided on a Minimum Viable Product, and have estimated the stories that deliver the MVP.
• Unit test coverage.
• If you're a team then show (demo) the class what's new even if you don't think it's much. If you're doing an individual project, then include a link to the new functionality.

NOTE: You have to deliver a status even on those weeks when we don't have class.

House Keeping

Project Management and Collaboration

Class Schedule

Important Events

Americans with Disabilities Act (ADA)

Reasonable accommodations will be made for students with documented disabilities. In order to receive accommodations, students must obtain a letter of accommodation from the Center for Disability Resources. The Center for Disability Resources (CDR) is located in 3424 S. State St., room 1C3-2 (on the first floor).

Varia

Unless otherwise stated all papers you turn in will be TYPED. No handwritten work is accepted.

Each page will have a header as follows:

• The left side: your name
• Middle: page number and the total number of pages (ex. 2/5 indicates this is page 2 out of a total of 5)
• Right hand side: name of the assignment (ex. Homework #2)

Each page will also have a footer:

• The left hand side will contain the following text: cs487-section: Fall 2016 where section stands for the section you are in
• The right hand side will contain the following text: Illinois Institute of Technology - Computer Science