SE Final Project Guidelines

Software Engineering 1
Software Engineering
Final Project Guidelines
====
1. Introduction
Real-world software development is different from the experience gained in most class programming projects.
The purpose of this software engineering final project is to help students 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
o Task distribution, communication and coordination
o Learn to break down tasks and define responsibilities
o Learn to use supporting tools for team collaboration.
• Apply problem definition techniques.
o Learn to elicit and specify requirements.
o Learn to use object-oriented analysis techniques.
• Create solution systematically.
o Learn to create design models.
o Develop implementation that is consistent with design.
• Gain experience with validation techniques.
o Learn to conduct formal reviews and inspections.
o Learn to plan tests early in the process.
o Learn to use simple automated testing tools.
2. Project Types
• Develop a small-scale system and/or application with community impact. The project may be the
development of information system, a website, and/or a mobile application.
• Each team should carry a project from problem statement to implementation of solutions. As an
exception, where implementation is not practical within the available time frame and resources in this
semester, you are allowed to use any templates or source code from any sources. However, you still need
to modify it to suit your system or application.
• The project concept itself does not have to be unique or original. Of course, original ideas and solutions
will attract higher evaluation. However, the system developed must have some identifiable aspect that is
innovative. It does not mean that the project must be something that has never been done before, but it
does mean that some aspects of the project must be innovative.
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. Each team should submit a weekly logs as the sources
of information for assessing individual contribution to the project.
Software Engineering 2
3.2. Team Roles

Each team must appoint:
1) Team leader (head honcho) - coordinate the distribution and assignment of work and serve as the
point of contact.
2) Scribe (record keeper) - record meeting notes.
3) Software Architect (idea person) - main designer/technical lead.
4) Quality assurance (bug catcher) - main testing lead.
5) Tech support (genius bar) - support and educate the team on the computing environment.
6) Software developer (code ninja) - participates in requirements, design, implementation and testing of
software.
One person can have multiple roles.
3.3. Some Useful Tips
While there is no magic formula for successful teamwork, here are some helpful tips from 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 weekly logs to track each person’s work
• 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 (preferably 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.
Percentage
Artifacts
(Tentative)
Problem Statement 5%
Requirements Specification Document 20%
Design Document 30%
Implementation (Source Code) 20%
Verification and Validation Document (Test plan,
15%
user stories, test criteria)
Teamwork Management Document (Project
10%
plan/schedule, weekly logs, work item assignments)

SE Final Project Guidelines

Uploaded by

Copyright:

Available Formats

SE Final Project Guidelines

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE Final Project Guidelines

Uploaded by

Copyright:

Available Formats

Software Engineering 1

3.2. Team Roles

4. Project Artifacts To Be Submitted

You might also like