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 do these each week:
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 help to keep the staff 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.
Your team status report will be submitted using the course dropbox.
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 Thursday section hours. 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.
You are required to meet as a team at least once a week. We have reserved Tuesday sections for this purpose. You can meet at any location you like or use the Tuesday section location. We strongly encourage you to also work together in the same location at least once a week.
We also require that you use Git for distributed version control. If you are unfamiliar with Git, the following resources will help you get started:
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.
The CSE lab machines have a full complement of development environments and tools. You may use any programming language you like. However, your project must obey professional standards of modularity and abstraction.
Here are tools you can use to draw UML diagrams.
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 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.