Computer Science 507
Software Engineering
Spring 2014, The College of Saint Rose
Groups will be formed and assigned to projects early in the semester. You will have a chance to voice your preferences, but the instructor has the final say on the formation of groups and matching of groups with projects.
Overview
The goal of the project is to give you experience working in a team on to produce a software system for a client. You will progress through the entire development lifecycle from requirements, through design, implementation, testing, and delivery. Ideally, we would also have time to get additional client feedback after delivery to produce a "version 1.1", but most likely your project will end with the initial product delivery.
The programming language(s) and target platform(s) will vary from project to project. In some cases, the client may require that the product works on a specific platform or platforms, while in other cases, you will be free to choose, in consultation with your client, an appropriate platform.
One important requirement that applies to all projects is that your project's code and documentation must be made freely available. We will set up a web repository at the end of the semester where all projects will be available to the general public.
Possible Projects
The following are some potential projects:
Other project ideas may be suggested as long as there is an external client. Any such ideas should be sent by email to terescoj AT strose.edu as soon as possible, and no later than 11:59 PM, Friday, January 17, 2014.
Group Formation and Project Assignment
Groups will be formed and projects assigned as soon as possible. To facilitate this process, please send an email to terescoj AT strose.edu no later than 11:59 PM, Wednesday, January 22, 2014 which includes the following:
Many factors will be considered when forming teams. Unfortunately, not everyone will be able to get their first choice of project and teammates.
Coordination and Tracking Progress
Each group should create and maintain a document to track your progress and to communicate among group members. The suggested mechanism is to create a document in Google Drive that is shared among all group members and with the instructor (please share with both terescoj AT strose.edu and terescoj AT gmail.com).
One section of this document must be called "Activity Log" and should log all of your group's activities for the project. Entry types will include group meeting and discussions, individual or group efforts on deliverable or internal group documents or software items, and any interactions with clients. Example entries might include:
2014-01-18, group organizational meeting. 4:30-5:30 PM. All group members in attendance. 2014-01-19, Alice and Bob met with client, emailed summary to all group members. ... 2014-03-04, Carol and Dilbert worked on GUI code, 8-10 PM.
You should create other sections as needed as you work on the requirements, design, implementation, and testing of your project.
While this document will not be a client deliverable, it will be considered as part of the project grade. It will also be used as a mechanism to provide instructor feedback.
Client Meetings and Requirements Documents
The first phase of your project is to gather information from your client(s) and produce formal requirements specification documents. The user requirements document should be a specific but perhaps not precise description of the project's goals, to be shared with an accepted by your client. The system requirements document will contain much more precise information at a level of detail important primarily to the development team. These documents should be submitted by email to terescoj AT strose.edu by 11:59 PM, Monday, February 10, 2014. Please use the document /home/cs507/RequirementsTemplate.doc on mogul as your template for the system requirements document. Be sure to update your activity log to document all group meetings, client meetings, and other efforts to produce these documents.
Also, each group should begin to think about the strengths and weaknesses of its members in planning for the design, implementation, testing, and documentation tasks upcoming. Each team member should be able to play to his or her strengths but also to take on some work in an area where he or she might not be as comfortable to enhance and develop new skills.
Finally, come up with a clever name for your group to use to present yourself to your client.
Software Plan and Design
The second major phase is the construction of your software plan and design. In this phase, you will choose your software process model and plan your implementation. These are the items in Chapters 4-6 of Sommerville.
A document outlining your software plan should be submitted by email to terescoj AT strose.edu by 6:00 PM, Monday, February 24, 2014. Each group will also give a formal 15-20 minute presentation (prepare slides) of their software plan and preliminary design to the class during our meeting on that date.
The specifics of the software plan and design depend on the project and the software process model you are planning to use. Items that are likely to be relevant to most projects include:
In the process of developing your software plan and design, you may find that updates are necessary on your requirements specification document. You need not submit an updated requirements specification at this time, but you are welcome to do so if you believe it is necessary to have the updated document in order to understand your software plan and design.
Documentation Guidelines
An essential part of any successful software project is the deliverable documentation. The documentation for most projects should include each the following categories:
Bug Bash
During our meeting on 6:00 PM, Monday, April 14, 2014, we will hold a "bug bash", where the entire class will compete to find as many bugs in the projects as possible. Each group's goal leading up to this is to have a complete, working implementation of your software. You will demonstrate its use, and allow classmates to interact with your software, as appropriate. Everyone else's goal will be to find as many bugs and to make as many constructive suggestions as possible. This sounds adversarial, but the intent is to provide a friendly forum where you can discover potential problems with your software before the final submission and delivery to your client. Overall, our goal is to improve all of the projects before they are presented and delivered.
Complete Project Presentations
During our last regular class meeting on Monday, April 28, 2014, each group will present their work to the class. All group members should participate in the presentation in some significant way. You should take the class through the project from a description of its purpose, through your design and implementation process, up to a description (and if appropriate, a demonstration) of what you have delivered or will be delivering to your client. Show samples of code and documentation, including both comments and external documentation. Include your thoughts on how well your group's actual efforts matched the software process model you were using, and whether you think the choice of model was appropriate, in retrospect.
Each of your presentations will be evaulated by the instructor and each of you will comment on each others' presentations. The evaluations will include the following criteria: the clarity of the introduction and project motivation, the clarity and completeness of background information about the project, the description of project's goals, methodology, and accomplishments, and whether the conclusion emphasizes and summarizes major points of the project. We will also comment on presentation style (eye contact, pace, etc), preparation of slides or other visual materials, the demonstration of subject knowledge, the length of the talk, and the presenter(s) ability to answer questions appropriately. You may also provide any other comments about each talk that you feel would be useful to the presenter to improve his or her presentation skills.
Each group should plan to present for 30-40 minutes, with about 10 minutes reserved for questions and answers for each group.
The evaluation form is available here.
Grading
Your grade for the project will be based on your work at all steps of the project. The following breakdown may be changed somewhat, but serves as a general guideline.
|
Grading Breakdown | |
| Preferences email | 1% |
| Activity log completeness | 5% |
| Requirements document | 10% |
| Software plan | 10% |
| Design presentation/evaluations | 8%/2% |
| Bug bash participation | 5% |
| Final presentation/evaluations | 12%/2% |
| Developer/administrator documentation | 10% |
| End user documentation | 10% |
| Delivered product | 25% |
Academic Honesty Guidelines
Collaboration within a group is unrestricted. Since each group is working on a different project, you are free to discuss your projects with each other. If you wish to use or refer to any software libraries or outside source code beyond those that come standard with your development environment, check with me first and cite their usage appropriately. All sources must be cited properly. If in doubt about anything related to academic honesty, ask now and avoid problems later!