CSCI 306: Software Engineering
Course Information (Spring 2016)
Where and When:
T/Th, 11:00-12:15, MZ 26
T/Th, 3:30-4:45, BB 316B
Office Hours: T/Th, 8-9:15, also by appointment!
This course is intended to make you a better software programmer by providing an introduction to the processes and considerations of Software Engineering. You will learn to plan and execute iterative programming projects in groups, critique (and improve) existing code, and learn the basics of widely used software engineering processes and techniques (including Agile Development and UML). Assignments will not be restricted to coding, and should encourage students to think as software engineers, rather than individual programmers.
- Agile Software Development, Principles, Patterns and Practices, by Robert C Martin, Prentice Hall, ISBN 0-13-597444-5 (recommended)
- Big Java, Third Edition, by Cay Horstmann, Wiley and Sons, 2008, ISBN 0-471-10554-2 OR Java Concepts, by Cay Horstmann, Wiley and Sons, 2008, ISBN 978-0-470-10555-9 (optional)
|Labs, exercises, projects||Class participation (includes piazza)||Exams|
Course grading will be done on a plus/minus scale, with 93 to 100 as A, 90 to 92.9 as A-, 87 to 89.9 as B+, etc. I typically do not curve course grades.
All assignments are due at 11:59 pm on the date listed on the schedule, unless otherwise noted.
Late work is strongly discouraged. Late assignments will be penalized 10% per day. For small assignments (less than 10 points), the late penalty is 1 point per day. No assignments will be accepted more than 2 days late.
Incorrect assignments (e.g., submitting the wrong file, forgetting to include your partner's name, etc.) will also be assessed a penalty of 10%.
Programs that do not compile or do not execute will not get full credit. Deduction may be from 10-20% (in addition to points deducted for items on the rubric which are not satisfied). In other words, if you have a working program, then add some code that doesn't compile, it is better to remove or comment out that code.
Since most of the work for this class will be done in pairs or teams, class attendance is very important, especially on days when we are completing assignments that we have already begun. If you donít show up then your partner(s) must complete the assignment on their own. To encourage participation and attendance, I will pass around an attendance sheet each day.
To get full credit for participation, you must also do at least one post on piazza.
Our goal is to develop effective software engineering skills, which includes the ability to use online help forums. Please try to post a question on piazza rather than contacting me directly. If you email a question to me which I think will be of interest to others, I will post it on piazza and remind you of this policy. Once we begin using git, to get help on a program you should send your git url, not a file (and never a partial file).
Piazza "Rules of Engagement" (thanks Randy B.)
Online forums can be quite intimidating. I'd like to suggest these guidelines:
- Be polite. This also applies to assignment clarifications (e.g., writing "This requirement makes no sense" may not be the best phrasing. Try something like: "I'm not clear what requirement X means. Should I do [x] or [y]?")
- A Piazza post is not a text message; use complete sentences and correct spelling, punctuation, and grammar.
- When asking a question, do not post large blocks of code. A couple lines of code, to clarify your question, may be appropriate. Before posting, ask yourself: would this be giving most of the answer to another student? Thinking about how to phrase the question may help you solve the problem.
- When answering a question, do not post the exact code
from your homework solution. Possible exception would be something
that takes one line and is primarily a syntax question.
E.g., to a question like "How do I set the
color of my rectangle" you might answer with something like
"You need to set the color before drawing. If
gis a Graphics object, you can do g.setColor(Color.CYAN);"
- Using pseudocode is an excellent way to answer questions.
Collaboration Policy for Programming Projects in CS Courses
The following policy exists for all CS courses in the EECS department. This policy is a minimum standard; your instructor may decide to augment this policy.
- If the project is an individual effort project, you are not allowed to give code you have developed to another student or use code provided by another student. If the project is a group project, you are only allowed to share code with your group members.
- You are encouraged to discuss programming projects with other students in the class, as long as the following rules are followed:
- You view another student's code only for the purpose of offering/receiving debugging assistance. Students can only give advice on what problems to look for; they cannot debug your code for you. All changes to your code must be made by you.
- Your discussion is subject to the empty hands policy, which means you leave the discussion without any record [electronic, mechanical or otherwise] of the discussion. For CSCI 306: you may write notes that describe design ideas.
Info on this page is also available on this syllabus, in case you prefer to print a copy.