CISC 475
Advanced Software Engineering
Fall 2012
Lecture: 205 Brown Lab, Tue/Thu 1700–1815
Lab: 109 Memorial Hall, Wed 1700–1815
|
Instructor:
Walt Leipold E-mail: leipold@udel.edu Office: 441 Smith Office hours: TR 1830–1930 Web: http://www.cis.udel.edu/~leipold |
Teaching Assistant: Jeremy Keffer E-mail: jkeffer@udel.edu Office: 103 Smith Office hours: TR 1530–1630, W 1545–1645 |
About the course
Schedule
Semester project
Final presentation
Final submission
Reading
Exams
Grading
Policies
This is the Web page for CISC475, “Advanced Software Engineering”. It contains announcements, policies, and other pertinent material for the course. The page will be updated frequently—plan on checking for new or updated material at least twice a week.
Announcements
2012-11-01: Due to lost class time caused by hurricane Sandy, the final exam has been rescheduled to 8 December (Saturday). The exam time remains unchanged (19:00–21:00).
About the course
CISC475 presents an introduction to software engineering concepts, methodologies and tools. It covers the analysis, specification, design, and implementation of software systems using object-oriented development processes including the Unified Process and UML. The course includes a semester-long team development project using the techniques discussed in class.
Class schedule
The following class schedule is preliminary—it will probably change as the semester progreses.
The schedule includes links to some of the PowerPoint slides and other materials from the lectures. Many topics covered in the lectures are not on the slides but will be on the exams.
Remember that lecture slides are not a substitute for either attending the lectures or reading the textbook—see this version of the Gettysburg Address, this Wired article by Edward Tufte, and this Robert Cringely article for some reasons why.
| Class | Date | Topics | Activities | Resources |
|---|---|---|---|---|
| 1 | 28 Aug | Intro | Slides | |
| 2 | 30 Aug | Software engineering | Slides | |
| 3 | 4 Sept | Requirements | Slides | |
| 4 | 6 Sept | UP artifacts | Presentation 0 (mini) | Slides |
| 5 | 11 Sept | Coding guidelines | Slides | |
| 6 | 13 Sept | Domain model | Slides | |
| 7 | 18 Sept | Software architecture Design class diagrams |
Slides | |
| 8 | 20 Sept | Operation contracts Interaction diagrams Software testing |
Submission 1 | Slides |
| 9 | 25 Sept | Honors risks presentation | ||
| 10 | 27 Sept | Presentation 1 | ||
| 11 | 2 Oct | Capability Maturity Model System Architecture Document Software maintenance |
Slides | |
| 12 | 4 Oct | Coupling & cohesion | Slides | |
| 13 | 9 Oct | Review for midterm | ||
| 14 | 11 Oct | Midterm exam | ||
| 15 | 16 Oct | Design patterns | Submission 2 | Slides |
| 16 | 18 Oct | Midterm post-mortem | Honors presentation | |
| 17 | 23 Oct | More design patterns | Slides | |
| 18 | 25 Oct | Honors risks presentation | ||
| 19 | 30 Oct |
CANCELLED (Hurricane Sandy) |
||
| 20 | 1 Nov | Presentation 2 | ||
| 21 | 6 Nov | No class (Election Day) | ||
| 22 | 8 Nov | Other UP artifacts Refactoring |
Submission 3 | Slides |
| 23 | 13 Nov | More software architecture Persistence |
Slides | |
| 24 | 15 Nov | Distributed architectures | Slides | |
| 25 | 20 Nov | Planning and estimating | Slides | |
| 26 | 26 Nov | Antipatterns | Honors risks presentation | Slides |
| 27 | 29 Nov | Review for final | ||
| 28 | 4 Dec | Final submission Final presentation (006 WHL) |
||
| 29 | 8 Dec |
RESCHEDULED! (Saturday) |
Final exam 1900–2100 in 205 BRL |
Semester project
A major part of this course consists of a semester-long team project. Each team will analyze, design, and build a significant software system using the Unified Process, and will deliver a complete set of UP artifacts (use cases, domain model, sequence diagrams, operation contracts, and so forth) along with the operating software.
Projects will be implemented in Java, and will target either cross-platform desktop development (Windows/MacOS/Linux) or the Android smartphone operating system.
Project topic: The project can be a productivity application, simulation, game, or whatever, as long as it is:
- Interesting
- Not something any team member has already developed
- Complicated enough to demonstrate the team's engineering skills
- Not too complicated to finish within one semester
- Not a chat server, card game, or other trivial application.
- Approved by the instructor
In general, an acceptable project is one that supports multiple business functions, ideally for multiple types or classes of users. Requirements analysis and design for such a project are more challenging than for a single-user, single function application (like a Solitaire game or an MP3 player).
Team member roles: Each team will consist of between four and seven students. Each student must have at least one well-defined role on the team. Part of each student's grade will be based on how well he carries out his declared role(s). Each team must have a team leader, but the other roles will depend on the team's task. Some typical roles might be:
- Team leader—coordinates activities, leads design and implementation efforts, interfaces with the customer
- Test engineer—designs, codes, and runs unit tests and integration tests.
- Configuration manager—documents the development process, develops deliverables with a consistent look and feel
- Lead developer—develops core classes, oversees work of other coders
- Coder—the "ground state" for team members; everybody should be doing some coding
- Database developer
Project tools: You must follow the Unified Process for this project, and deliver a number of UP artifacts. Your grade will be influenced by how well you adopt and use real software engineering tools, such as:
- Subversion for version control of both source code and artifacts.
- Ant to automate building, testing, and deployment.
- JUnit to unit test your code.
- Javadoc to document your classes.
- A punchlist/issue tracking system (such as Mantis or Trac) to track bugs, missing features, potential refactorings, and other issues.
- A Wiki for collaborative document editing.
Submissions: Each team will submit a set of UP artifacts at four milestones through the semester. For all four submissions, you will submit all of your UP artifacts on paper. This will allow the TA and instructor to mark up the submissions when grading. At the fourth milestone, you will also submit all UP artifacts, source code, build/test/install scripts, README files, installation instructions, and other documents on CD-ROM or other media (See below for details.) The organization and professionalism of these submissions, and the ease with which the instructor can get your code running from them, will affect your grade.
The following Unified Process artifacts must be included in each submission:
- Vision, Use Cases, Supplementary Specification, and Glossary.
- Domain Model and System Sequence Diagram(s)
- Specification and design documents: System Architecture Document, Operation Contracts, and Design Class Diagram
- Package Diagram, Deployment Diagram, project source code, .class files, javadoc files, installation scripts, installation instructions, help files, test scaffolding, etc.
Because the Unified Process is an iterative development process, artifacts will evolve throughout the project. Therefore, each submission must also include revised, updated versions of artifacts from all previous submissions.
3rd-party components: With the approval of the instructor, teams may use third-party libraries (for example, the Rhino JavaScript engine, the Hibernate object/relational persistence framework, the XStream XML serializer, the ANTLR parser generator, or the JFreeChart plotting package) as components in their projects. Except for such approved components, the code and documentation developed in this course must be the new, original work of the project team members.
Final presentation
Final project presentations will be held in WHL (Willard Hall Education Building) room 006 on Tuesday, 4 December, with the first presentation starting at 1700. The room will be available starting at 1645 to allow you to stage and test your equipment. Attendance at all presentations is mandatory for all students in all teams.
Each member of each team must introduce himself (not just be introduced by the team leader), and should make some part of the presentation. The instructor will take a photograph of each team.
Each presentation should take 45 minutes, including setup/teardown and question/answer. Do at least one dress rehearsal of your presentation to make sure that everyone knows his part and that it will take about that amount of time.
Here are some examples of the things a good presentation will cover:
- Overview: Describe what the system does, and why you think it's a good idea.
- Architecture: How is your system organized? What processes run, where do they run, and how do they communicate? Where is data stored, and how is it accessed?
- Infrastructure: Show off your source code, build scripts, Wiki, punchlist, and version control system.
- Functionality: Demonstrate all of the main Use Cases for your system.
- Error handling: Describe how you handle error conditions.
- Pattern usage: Describe which design patterns you used in your code, and why you used each.
- Refactoring: What parts of your system did you refactor, and why you did it. Did it help?
- Automated testing: This will be especially impressive.
- Lessons learned: What went wrong during the project, and how would you prevent it next time?
You can't cover all of these areas thoroughly in 45 minutes, so you'll have to choose the areas to emphasize that are most likely to impress the instructor, the TA, and faculty observers.
Final submission
Final project submissions are due at the beginning of class (5:00PM) on 4th December. The submission will consist of both printed and machine-readable versions.
The printed submission must contain all project artifacts plus a table of contents, arranged as a single document with sequential page numbers. Do not include source or Javadoc printouts. The submission should be stapled or bound together (no loose pages), should be printed single-sided, and should not contain any hand-drawn pictures.
The machine-readable version should be submitted on CD-ROM. It must contain:
- readme.txt (see below).
- An electronic version of the final printed submission, along with the raw files (e.g., Visio files) for all UP/UML artifacts.
- All your source code (including test and scaffolding code), Javadocs, and build and test scripts.
- All required 3rd-party libraries.
- A compiled version of the Javadocs, in their own directory. It should be possible to browse the Javadocs by double-clicking on index.html.
- Copies of all of your presentation materials from all three presentations (including the final presentation), in PowerPoint or OpenOffice format.
- Copies of your first three submissions. (If your electronic submissions were in PDF format, you must include the source documents (LaTex, Word, OpenOffice, etc.) as well.)
The readme.txt file should be at the root of the disk. It should describe the organization of the submission. It must contain instructions for building and running your system, including detailed instructions for downloading, installing, and configuring any 3rd-party components necessary.
Organize the files into a reasonable and functional directory hierarchy. The instructor should be able simply to copy the CD contents to hard disk, update CLASSPATH, and run Ant to build your application or run JUnit.
If the submission includes any Microsoft Office documents, they must be readable in Office 2003 or OpenOffice.org 2.0.
Reading
2012-09-04: I Won't Hire People Who Use Poor Grammar. Here's Why.
2012-09-11: "Painless Functional Specifications" parts 1, 2, 3, and 4.
2012-09-25: The CRUD pattern in Use Cases, and why it is evil.
2012-09-30: The Magical Number Seven, Plus or Minus Two.
2012-10-02: First four chapters of CMMI for Development, Version 1.3.
2012-11-05: If the comments are ugly, the code is ugly.
2012-11-05: Martin Fowler's master list of refactorings. (Learn at least three of the patterns that were not covered in class.)
Exams
The midterm exam will cover all lectures, all reading assignments, and anything else discussed in any class prior to the exam date. It will probably include an extra-credit problem.
The final examination will cover all lectures, all reading assignments, and anything else discussed in any class. It will probably include an extra-credit problem.
Grading
Grades for the semester will be based on:
| Midterm exam: | 20% of final grade | |
| Final exam: | 25% of final grade | |
| Semester project: | 50% of final grade | |
| Attendance and participation: | 5% of final grade |
Each student's project grade will be a combination of the group grade and an individual grade.
Policies
Exams: The course will include two exams, a midterm and a final. Exams will be closed-book.
Late assignments: There are no homework assignments (other than the project and an occasional reading assignment) in this course. There are four delivery milestones for components of the project, which must be met. No credit will be given for project materials turned in late.
Academic integrity: You will be expected to conform to the University's policy on academic integrity.
Grades by e-mail: The University has a strong policy on protecting PNPI (Personal Non-Public Information), and treats your grades as private, sensitive data. You may request that your grades for work in this class be sent to you via e-mail, but you are hereby warned that e-mail transmission is not secure and your grades may be visible to third parties.
Last modified: Thursday, 6 December 2012