Course Project

The goal of the course project is to provide you with hands-on software engineering experience, involving a team of 6-8 students. You will design and develop your product from the ground up in 10 weeks. The project is broken down into several milestones, listed on this page and on the course calendar.

In addition to submitting artifacts required for each milestone, you will be required to submit a weekly status report every Tuesday by 11pm (except for January 05 and March 08), and to attend weekly project meetings every Thursday during section (except for January 07 and March 10). We also strongly encourage you to hold weekly team meetings during Tuesday sections, and to work together as often as you can.

You have a great deal of latitude in choosing your own toolset. Your team is ultimately responsible for choosing and learning these tools. That said, the staff wants to help you as much as possible, so if you are stuck, please ask us! However, be aware that we don't know every tool that you might choose. Your whole team should work together to choose, understand, and use your tools—just like in the real world. You should be, or become, comfortable with reading documentation that is sometimes incomplete or confusing, and with installing and using new software. These are skills that will stand you in good stead, no matter where your career takes you.

Weekly Status Reports

Weekly status reports help to keep the executives, the customers, and yourselves informed about your progress. The team status update must fit on a single page, and it must specify the contributions of individual team members.

Each status update should have three sections. Each section is typically about the size of a paragraph, but it can be organized as bullet points or in some other clear way.

You may find it helpful to read the more detailed instructions for writing a research status report from which the CSE 403 guidelines have been adapted.

Your team status report will be submitted using the course dropbox.

Weekly Project Meetings

You will be required to have regular weekly meetings with the course staff, but you may schedule additional meetings if you like. A staff member will contact your team to set up a weekly 15-20 minute meeting during section hours (Thursdays, 9:30-10:20). Additional meetings may be scheduled during your TA's office hours.

The course staff serves as both customer and mentor. When you have a meeting with your TA, you are allowed to ask the TA to serve any of these roles, or even to switch roles during the meeting. As customer, the TA can help you to determine what a reasonable set of requirements are, and whether your documents and prototypes are compelling. As mentor, the TA can help you to resolve conflicts or give suggestions about designs, teamwork, and tools. Don't forget or underuse either of these roles.

It is a bad idea to try to hide information from your customer (or, for that matter, your TA). If things are going poorly or you are having trouble, be upfront. You may get good suggestions, and the customer won't feel blindsided if you are unable to resolve the problems on your own. It is a doubly bad idea to try to hide problems from your TA. Instead, use the TA as a resource to help solve your problems.

Weekly Team Meetings

You are strongly encouraged to meet as a team at least once a week and work together in the same location. We have reserved Tuesday sections (9:30-10:20) for this purpose. You can meet at any location you like or use EXED 110.

Software Tools

Integrated development hosting
We strongly recommend using a site that integrates the most important development tools: version control, issue tracking, and wiki. The wiki is a good place to host your development homepage. Examples include GitHub and Bitbucket.
Version control
We require that you use a distributed version control system, such as Git.
Web and database hosting
If you are developing a web application, you have a choice of hosting providers. Here are some of them, in the order of our recommendations.
  • Managed platforms (e.g. Google AppEngine, Heroku, Amazon EBS)
  • (Virtual) private servers (e.g., Amazon EC2, Linode, your own server)
Mailing list
We require that your team has a mailing list with archives. All CSE 403 staff members must have permission to post to your list and to read its archives, but they should not receive email from your list. You can create a team mailing list, with archives, through Mailman/C&C, Google Groups, and similar services.
Additional choices and requirements

If you need additional resources (a mobile phone, Amazon Web Services credit, etc.), please tell the staff as soon as possible. We will do our best to accommodate such requests, but cannot make any guarantees.

It is required that your team project can be installed, by a staff member, on a fresh CSE virtual machine image (or on other readily available resources such as attu, cubist, or Amazon Web Services). If you have written a mobile device app, it must run both on an emulator and on some mobile device, but it does not have to run on arbitrary mobile devices.

You may use any programming language you like. However, your project must obey professional standards of modularity and abstraction. Some languages make this very difficult to guarantee, and we strongly recommend against them.

More Tools

Diagramming

Here are tools you can use to draw UML diagrams.

Programming tools

The CSE lab machines have a full complement of development environments/tools, including most or all of the following.

IDEs
eclipse
Compilers and interpreters
C, C++, C#, Java, Python, PHP, Ruby(-on-rails), etc.
Unit test frameworks
Java: JUnit, TestNG, JUnitEE
JavaScript: JsUnit
C# and .NET: NUnit, csUnit
C: CUnit
PHP: PHPUnit, SimpleTest; CakePHP incorporates its own unit testing primitives
Ruby: Test::Unit, RSpec, ZenTest
Python: PyUnit
Other testing tools
Selenium for replay of user actions (e.g., clicks) in a browser
Code coverage
NoUnit, EMMA, Cobertura, Hansel, etc.

If you use Microsoft Windows on your personal computer, Cygwin might be helpful in interoperating with software hosted on CSE Unix machines (such as version control repositories).