SWEspr09
Assignments Discussion Group Theater Apps Course Advertisement
Lecture Blog Design Patterns SVN Server Flex Links Student Wikis Bug Tracker
Concept Presentations
Accessible Games
See students' accessible video games!
91.411 Software Engineering I
Spring 2009
Prof. Fred Martin | TA: tbd |
⚠ (:html:)<a href="http://mailhide.recaptcha.net/d?k=01COSqrfJ-58cc94fQb2pI1A==&c=iZBP8kCznrjdnfw8QFFKADFtsIimnLdVHk581djoISQ=" onclick="window.open('http://mailhide.recaptcha.net/d?k=01COSqrfJ-58cc94fQb2pI1A==&c=iZBP8kCznrjdnfw8QFFKADFtsIimnLdVHk581djoISQ=','', 'toolbar=0,scrollbars=0,location=0,statusbar=0, menubar=0,resizable=0,width=500,height=300'); return false;" title="Reveal this e-mail address">fr...@...uml.edu</a>(:htmlend:) |
MWF, 11:30 am - 12:20 pm
Olsen 403
Theater Software Projects
In collaboration with Prof. Justin Rowland's Theater Design class, we conceived of software that would allow users interactively manipulate four types of media objects: sets, costumes, props, and sounds. Each of the software demonstrations below in an original software product that is a variation on this theme. The projects include imagery and/or sounds provided by students from the Theater Design class. Many of them also allow new media objects (images; sounds) to be uploaded.
Our objective was to make software that would allow the Theater Design students use a new software tool to interactively think and play with the results from their initial research plans.
- Scene Maker by Steve Gadman (with Byron McNeal's design elements)
- Set Designer by Brian Mello (with Sarah D.'s design elements)
- Theater Designer by Steven Zukowski (with Michelle T.'s design elements)
- TheaterStudio 1.0 - Soliloquy by Eric Krupink (with Daniela Nedbalek's design elements)
- Theater App by Jim Ebert (with Michelle T.'s design elements)
- Awesome Theater App by Tom Kiley (With Chris Bradley's design elements)
- Even More Awesome Theater App by Chris Corcoran
- TheaterApp by Anthony White
- Theater App by John Fertitta
- Set Creator by Peter Psehoyas Jr
Overview
In this course, we will learn about software engineering by creating two significant pieces of softwarean interactive software "toy" for theatre design students, and video games that are playable and enjoyable for children with multiple disabilities. We will learn how to design software by reading case studies of large software design projects, considering theory of well-designed software (in particular, the IEEE Software Engineering Body of Knowledge), and reflecting on the design process as our own projects are underway.
To help in framing the challenge of creating software for children with multiple disabilities, we will be visited by Bonnie Paulino, Principal at the Kennedy Day School at the St. Franciscan's Hospital in Brighton, MA. Bonnie has been using computer technology with disabled children for more than 25 years and is a caring expert in the field. Your videogame programs will be used by students at her school.
From a technical perspective, we will:
- Discuss requirements elicitation, agile design, the role of documentation, design patterns, test-driven development, the second-system effect, and the role of community / peer-pressure in software design.
- Use the Adobe Flex 3.0 release and create game applets that can be played by anyone with a web browser and internet connection
- Work with source code control and unit testing frameworks.
A Bit More...
To generalize, there are two types of software engineering classes: one in which everyone builds the same thing, and one in which everyone builds something different. The former is good because it lets instructors focus in on specific and particular theoretical material. Instructors know exactly what problems you will be encountering as you write code, because they have created the design challenges expressly to expose certain ideas! A great example of this type of class is MIT's course 6.170, Laboratory in Software Engineering.
On the other hand you have courses that are more representative of life in the unstructured real-world, where every project is indeed different. As described by Diane Pozefsky in her Software Engineering Laboratory at UNC, this course is a faculty-coached team project. Student teams in this type of class might each have a different client and be working with wholly different software technologies.
Here, we will take a middle ground. Primarily, we will have project implementation as the heart of the class. But we will all be working on the same sort of project (videogames for children with multiple disabilities), and we will all be using the same technologies.
Required Books
We will use one required book:
Please make sure to get the 20th Anniversary Edition (aka 2nd edition, 1995). Here is an Amazon link; used copies are available around $18. Please order right away; if you pay for expedited shipping (about $7), you'll get it pretty quickly.
There will be other readings, including essays published on the web and material photocopied from out-of-print books. The latter will be handed out in class. The current reading assignment is always here.
Deliverables
This is a project-driven course with a reading component. Discussion, writings, and other reflections on the readings will illuminate your design process as you are engaged in your own software development.
Therefore the projects themselves and the readings/reflections are both important.
The specific deliverables you will be responsible for are:
- Reading reflections. For each assigned reading, you will be responsible for a reading summary and reflection.
- Project 1 (Theatre Design software toy) software product. This is a 4-week project at the beginning of the semester. Theatre Design students will provide media elements for you to incorporate into your project.
- Accessible game concept video presentation. This is a 3- to 5-minute long movie (e.g., Quicktime, MPG, or DVD video) that demonstrates your game concept. The main purpose of this video is to present the concept to the faculty and staff at the Kennedy Day School for feedback before you go off and implement the game. 2 weeks.
- Prototype implementation of your game. This is a partial implementation of your game in which you will make sure core functionality is operational. This release will be reviewed by teachers at the Kennedy Day School while you work on a final version. This deliverable requires that you make choices about what's most important, and provides an opportunity to have user feedback to help focus the final work.
- Final implementation of your game. This implementation will be due during finals week. This is an opportunity to refactor your code using design patterns you have learned in class. We will also do in-class reviews of code and UML block diagrams of your internal designs. You will personally visit the Kennedy Day school and see students using your game.
- Game documentation. This includes having your code on the course source code control server, and turning in specific documentation on the game's design. Each are due 1 week before each release.
- Mid-term. Precise placement in semester TBD.
SWEBOK Knowledge Areas
The IEEE Software Engineering Body of Knowledge project defines eleven Knowledge Areas, or KAs. These are:
- Software requirements
- Software design
- Software construction
- Software testing
- Software maintenance
- Software configuration management
- Software engineering management
- Software engineering process
- Software engineering tools and methods
- Software quality
- Related Disciplines
The areas and their subareas are illustrated in the diagram below, from the SWEBOK 2004 document:


Build Technology
Adobe Flex ships with Eclipse, so we will likely use that. People are free to drive the flex compiler around from the Unix shell, if you like.
There is an SVN server set up for course use. Each student will have 3 SVN repositories: one of playing around, one for project 1, and one for project 2. Instructions on using this will be made available. By the 3rd week all code should live on the server.
Collaboration
Some work will be done individually and other work will be done in pairs.
For project work, teams will be responsible for conceiving work in such a fashion that each person is responsible for a separable portion of the project. A clear division of work, with an API between each person's portion, will be spec'ed out before substantial implementation is undertaken. Students will be responsible for implementing their portion of work as originally agreed. If the design changes dramatically, so that the original definition is no longer applicable, this should be documented and reported as soon as it become apparent.
We will use a course Wiki for each team to post its game releases.
Discussion Group / E-Mail List
We will use Google Groups for class conversation and announcements. Please join this group.
⚠ (:html:)
<table style="border:1px solid #aa0033; font-size:small" align=center>
<tr>
<td rowspan=3>
<img src="http://groups.google.com/groups/img/groups_medium.gif" height=58 width=150 alt="Google Groups">
</td>
<td colspan=2 align=center><b>Subscribe to 91411-s09</b></td>
</tr>
<form action="http://groups.google.com/group/91411-s09/boxsubscribe">
<tr>
<td>Email: <input type=text name=email></td>
<td>
<table
style="background-color:#ffcc33;padding:2px;border:2px outset #ffcc33;">
<tr>
<td>
<input type=submit name="sub" value="Request">
</td>
</tr>
</table>
</td>
</tr>
</form>
<tr><td colspan=2 align=center>
<a href="http://groups.google.com/group/91411-s09">Browse Archives</a>
</td></tr>
</table>
(:htmlend:)
Please choose Edit my membership and select Email, to have each group message sent to you directly.
The group address is 91411-s09@googlegroups.com. You have to be a member to send to the list.
Grading
The following schedule will be used in determining course grades:
20% | Theatre design software toy implementation + associated documentation |
20% | Accessible game concept presentation |
20% | Accessible game implementation + associated documentation |
20% | Reading reflections + class participation |
20% | Midterm examination |