Software Engineering Term Project Guidelines

1. Introduction

Real-world software development is different from the experience gained in most class programming projects. Requirements are often unclear and complex. No one can accomplish a fairly complex project singlehandedly. Systematic testing is vital. In the real world, one must work with the realization that the software produced will be used by, and maintained by, other people, hence usability and maintainability are important qualities. The purpose of the software engineering term project is to help you get a feel for real-world software development. Students will work together in teams of 4-6 members. Students will be taking this project from problem definition to system test, applying basic software engineering processes.

You should understand that the project will require a significant commitment of your time from the beginning of the semester to the end.

1.1 Overall Objectives

• Learn teamwork.
  • Task distribution, communication and coordination.
  • Learn to break down tasks and define responsibilities.
  • Learn to use supporting tools for team collaboration.
• Apply problem definition techniques.
  • Learn to elicit and specify requirements.
  • Learn to use object-oriented analysis techniques.
• Create solution systematically.
  • Learn to create design models.
  • Develop implementation that is consistent with design.
  • Employ a version control system.
• Gain experience with validation techniques.
  • Learn to conduct formal reviews and inspections.
  • Learn to plan tests early in the process.
  • Learn to use simple automated testing tools.

2. Project Proposals

• Develop an application with community impact.
• The project must use modern toolsets (version control, project tracking, automated testing, modeling, and build and integration).
• The project must use object-oriented programming technology.
• If developing a web application, it must make use of modern platforms (web framework, view templates, and persistence framework). 

The project proposal is to be written up as a problem statement. This statement will be reviewed and the proposal may be modified in order to fit within the time constraints.

3. Working Together

Students will be asked to self-organize into teams consisting of 4-6 members.

3.1 Grading Policy

Each member of the team is expected to contribute equally to the project. Note that project grades will be given on an individual basis. In other words, if one person does not contribute substantially to the project, his/her grade will be significantly reduced. Weekly logs (see Section 4.4), project tracking data (see Section 4.3), code commit data (see Section 4.1), and peer evaluations will be the primary sources of information for assessing individual contributions to the project. If there is a clear discrepancy in individual contributions, individual project grades will be adjusted accordingly.

3.2 Team Roles

Each team must appoint:

1. project manager - coordinate the distribution and assignment of work and serve as the point of contact.
2. scribe - record meeting notes.
3. architect - main designer/technical lead.
4. quality assurance - main testing lead.
5. tech support - support and educate the team on the computing environment.
6. software developer - participates in requirements, design, implementation and testing of software.

One person can have multiple roles.

3.3 Project Tracking Tools

Our experience has shown that some CSCI 4830 projects fail because the teams were unable to make progress due to teamwork issues (unable to find common meeting time, unable to agree on ways of communicating decisions and tasks, etc.). To mitigate this, you are required to make use of tools for tracking project activities. Some commonly used tools:

• Integrated with version control:
  • Github
  • Bitbucket
  • Assembla
  • Team Foundation Server
• Tracking only
  • Trello
  • Pivotal Tracker
  • Taiga

3.4 Tips

While there is no magic formula for successful teamwork, the following are helpful tips from my observations of successful teams in the past.

• Set up a regular team meeting. Take notes during the team meeting and post them. At the end of the meeting, make sure that each member is clear about his or her work items.
• Assign work items to individuals. Work items that are assigned to two or more members usually end up being completed by one person, or worse, not done at all.
• Record work items in a project tracking system. In this way, it should be possible for me to get an idea of each person's to-do list at any given time.
• In the meeting notes, record who were in attendance and who were not. A few absences can be tolerated, especially if there is some excuse (preferrably given ahead of time).
• Nonresponsive teammates disrupt the smooth functioning of the team and can wreak havoc on the morale of the team. Refer nonresponsive teammates to me. These include but are not limited to, (a) those chronically absent (3 or more times) with no excuse, (b) those who repeatedly fail to respond to queries, (c) those who continually neglect their work items.
• It is helpful to sit together in class so you can use the times before and after class for quick discussions.

4. Project Artifacts To Be Submitted

These are the artifacts that should be submitted. Examples and templates will be provided later.

4.1 Notes on Version Control Repository

Source code for the project must be version-controlled, i.e., modifications should be saved using a version control repository such as Git throughout code development.

4.2 Notes on Source Code

Source code is expected to make use of sound programming principles. It is also expected that code should be commented in such a way as to facilitate automatic document generation using tools such as Javadoc, Doxygen, etc.

4.3 Notes on Project Tracker

Use a project tracking tool as discussed in Section 3.3. Individual assignments must be updated weekly.

4.4 Notes on Weekly Logs

Each team member must record every week a log of his/her activities contributing towards the project. The tasks should be brief and specific. Examples:

• Wrote use cases for the requirement querying functionality.
• Working on object model: (list of objects)
• Updated issues list.
• Modified file.c and checked into Subversion.
• Met with team. See posted meeting notes.
• Could not make progress because of ...

Fill out the weekly log here: http://cs2.ist.unomaha.edu/~hsiy/SElogs.

5. Major Deadlines

Notes

• These are basic deadlines for every team. Teams will be expected to work out a set of internal tasks that are consistent with these deadlines and include it in their Project Plan.
• Aside from the initial deliverable which is submitted via email, submit everything else by uploading to your team's shared drive.
• An acceptable version of each project artifact must be submitted by the deadlines above. Late or incomplete submissions will get a 1-point per day deduction from the final grade.
• If you are unsure whether your submission would be acceptable or not, please come and talk to me, before the deadline.
• When I provide feedback on a submitted deliverable, it is expected that the feedback should be incorporated into a revised version of the deliverable and resubmitted for re-review. Expect to make multiple revisions, especially for the requirements and design documents.
• When resubmitting a deliverable, include a brief item-by-item explanation how each of my comments were addressed.