This document is subject to change, especially now that we are online. As I adjust my teaching methods, I may update grade percentages, dates, etc. Check it for updates at least
weekly during the semester.
Instructors: Terry Harvey (Sections 10,11) Matt Bonham (Section 12)
Office: Online! See table in Canvas. If you can't make office hours, email me for an appt.
Email: tharvey or mbonham at udel.edu
Phone: don't phone, Discord or email!
Useful Links
Text: We'll be using multiple online resources; links will be
provided throughout the semester. Check Canvas first for files and other resources.
Important Project dates, subject to change:
|
Mar 3-4 |
First customer visit |
Mar 17-18 |
Storyboard
presentations to customer |
Mar 24-25 |
UML use cases,
class and sequence diagrams |
3/31 - 4/1 |
First code review:
UML classes and stubs, compiles |
Apr 7-8 |
Alpha code
review: demo simple
use case w/GUI, JUnit tests |
Apr 7-8 |
Alpha presentations |
|
Code review: demo multiple use cases w/GUI, JUnit tests, graphics (some image placeholders ok) |
4/28-29 |
Beta presentations |
|
Inter-team testing |
5/11-12 |
Rehearsal Presentations |
5/12-13 |
Presentations to
Client and Faculty |
5/14-18 |
Project final
code review, all JUnit tests, all functionality |
|
No Final Exam |
|
|
Course Modifications
This semester we will be learning online.
The most important piece of this course has always been the team-based project. We will work together to develop effective online teams, which, while not ideal from many perpectives, 1) is an excellent skill to learn, 2) is the way many software engineers are now practicing, and 3) is the way most open source projects are developed (e.g. Apache, Mozilla, Linux).
Instead of exercises in class with explanations and exams, we will work together online through exercises and project development. Assessment will be through assignment submissions, meetings about assignments and the project with the professor and TA, the project itself, and your team's internal assessments. Please watch this document, but more importantly, watch Discord, email, and Canvas for announcements about assignments, project, and meetings.
Classes will take place, online during regular class times. They will not be monolithic blocks of virtual class. We will break out to work on exercises, check out resources, etc., then return to shared space for analysis. I will not take attendance because I do not know your limitations. If you miss a "class" you can watch it online - the links will post in Canvas. One way or another, you will be responsible for learning the material covered. While the class sessions will be ideal for discussing material, we will also be able to discuss in lab or in virtual office hours and appointments.
Course Objectives
This course is designed to introduce students to a variety of tools and ways of thinking about software and software development. Topics to be introduced include
- Learning from online resources (e.g. Java documentation)
- Working in teams
- Working with non-technical team members
- Making presentations
- Communicating about software
- Working with customers
- GUI/event-driven programming
- UML diagrams
- Object-oriented style
- Modular design
- Method-level specification
- Automated testing
- simple Design Patterns
- Agile development methodology
- simple version control (git)
- using an IDE
- Evaluation of code for
At the conclusion of this course students should be more comfortable with the design and implementation of software projects requiring multiple authors, and should be well-positioned to tackle advanced versions of these same topics in Software Engineering II, CISC475.
Lecture
We will cover a wide variety material in this
course, most of which is not in the textbook. Attending lecture is helpful to
learn the material and to interact with class
members, teammates, and the professor. If you are not able to attend, watch later and do the exercises. Material that is delivered during lecture is sometimes in conflict with information you can find on the web; in such cases the lecture material is to be considered correct for purposes of assignments. All material is examined and discussed, so be sure to use class and office hours to clarify your understandings.
Lab
Labs will sometimes be due the day of lab,
and sometimes due later. Some labs will not
have a component that gets turned in, but
completion of the exercise is required regardless.
Labs that do not have a gradeable
component will be marked pass/fail at
the discretion of the TA.
After you submit a lab, I may give detailed answers to questions about the lab. For this reason, it is important that you submit on time. Also, staggered submissions make fair and timely grading more difficult for the TA. Please work on your assignments early and often.
Labs may be done alone, in pairs,
or in groups. We will specify which
for each lab. If you work in a team,
1) put all the names on the
assignment and in every code file to
avoid losing points; 2) every team
member must submit the lab
electronically unless otherwise specified; 3)
only submit one paper copy (if
any - ask your TA).
Participation
There will be many opportunities to
participate in class. Participation
includes asking questions, answering
instructor questions, and being an
active and constructive party when
asked to work with other students in
class. Speak up and join in! It's five percent of
your grade. If you have remarkable
difficulty contributing in class, see me
during the first week of class to
discuss alternative assignments.
Your project grade will be scaled by a factor determined by
several team peer evaluations. Honesty
about yourself and others is critical
to this process, which we will discuss more in class. The professor
reserves the right to make adjustments
to this factor if he deems it
necessary, but be aware that no
previous student has benefited from
such adjustment.
Up to 20 percent of your project grade will be based on your presentations of material in class. When you are part of a team, be sure that you present material every time the team does. Know the material well enough that you are not reading. We'll go over lots of other presentation points.
Grading
See pre-test policy link above
56% Project(s) (includes all phases and presentations)
20% Lab assignments
20% Classroom (or online classroom) exercises
1% Peak participation assignments
3% Class participation
At the end of the semester, all
grades will be taken into account by
the instructor in determining whether
or not to apply a curve of some
kind. Historically, there is little or
no curve. Under no circumstance will
grades be curved "down", but
there is no guarantee that grades will
be curved up.
Grade Scale
Number
|
100-93
|
93-90
|
90-87
|
87-83
|
83-80
|
80-77
|
77-73
|
73-70
|
70-67
|
67-63
|
63-60
|
<60
|
Letter
|
A
|
A-
|
B+
|
B
|
B-
|
C+
|
C
|
C-
|
D+
|
D
|
D-
|
F
|
Project
This semester's project will
involve working in a team composed of
students from your 275 lecture section. It is crucial that teams be able to meet online. Teams will
design and implement software for a
client of the professor's choosing. The project grade will be
composed of a number of parts,
including multiple presentations, all
parts of the software engineering
cycle, quality of teamwork and team evaluations, and final
presentation. Projects which pass the
final presentation may present their
work to faculty, administration, and
adoring fans. Client may select any or all
software to use in presentations and
distribute from their website.
Assignments
Typically, labs and projects will be graded by the TA, exams by the instructor. Once an assignment is returned, you have one week to request that your grade on the assignment be re-examined. Submit the assignment to the person who graded it along with a cover sheet explaining where you think you should be credited with additional points and why. If you submit for re-grading to the TA and are not satisfied with the result, you may re-submit to the instructor, but be forewarned that historically this option has not met with much success.
See the separate document on Assignment
Standards.
Academic Honesty
I expect my students to uphold the
highest standards of academic honesty,
as described in the University Code of
Conduct at Http://www.udel.edu/stuguide/20-21/code.html
Any violations will be referred to
the Office of Academic Conduct.
NOTES:
Quizzes and peak participation exercises are not team activities, and must be written solely by you without assistance of any kind. Plagiarism in any writing, including code, will be considered a violation of Academic Honesty policy.
Teams must work independently of other teams. Do not share work or code between teams; this is a violation of the Academic Honesty policy.
If you are ever in doubt about whether some activity is permitted, do not do it until you have asked the professor and received clarification.