CTP 210 Term Project
Course Description
Specification, analysis, design, implementation, documentation and presentation of a medium-sized
software system using by small teams under close supervision of a faculty advisor for each team.
Teams will develop a software system, utilizing tools and techniques that they already know from
previous courses and new ones that they will independently choose and learn during project
development.
Project Phases and Deadlines
1. Planning and Analysis (10%)
Project planning and analysis is central to conducting a methodological software
development effort. The students are required to develop documents on what they are to
produce and how to manage the production effort. IEEE standards are taken as a baseline but
are reduced to comply with the size of the projects. The deliverables and/or action items
under this phase and some useful documents for each are listed below.
Project Plan (PP) (%2.5): The project plan does give a short problem
description list of activities, with individual responsibilities, dependencies,
deadlines and the plan B (risk mitigation) in a compact document. The project
plan has to prepared early in the project and updated if necessary.
(guide) (reduced project plan template) (IEEE PMP standard).
Analysis Report (AR) (%7.5): The analysis report systematically defines in
detail the requirements of the software modules to be produced, from
different perpectives.
(guide) (reduced SRS template with UML and/or DFD) (IEEE SRS standard)
2. Design (15%)
A systems design is essential to develop software in a coordinated fashion. Unless design
entities are previously specified with their interfaces and behavioral models, integrating
individual software components is very hard if not impossible.
Design Report (DR) (10%): The design report decomposes the proposed
solution into independent design entities (modules or components) with
assigned names, goals and functionalities. Each design entity will be
documented appropriate to its characteristics. Use of tables, figures, standards
compliant UML and ER diagrams are necessary to communicate not only
data models but also relationships and flow of events.
(guide) (reduced SDD template with UML and ER diagrams) (IEEE SDD
standard)
Design Presentation (DP) (5%): The design presentation will summarize the
problem statement, and the proposed solution to department faculty and
guests from industry. The tools and techniques to be used will also be
discussed. The presentation should also feture standards compliant UML and
ER diagrams, and if possible a working prototype of the proposed system.
(guide) (sample DPs from previous semester / not necessarily perfects)
3. Implementation (40%)
The implementation phase of the project is the one with the longest duration. Therefore most
efforts are spent during this time. In order to facilitate an almost linear distribution of efforts
over weeks and a fair workload distribution among team members, many small milestones
should be defined and many seperate deliverables will be required.
Prototype Presentation (PP) (5%) : During the middle of the
implementation phase, every team will have to demonstrate a running
prototype of the system. The prototype should solidly demonstrate progress
since the design presentation.
(sample PPs from previous semester – not necessarily perfect)
Final Presentation (IP) (5%): At the end of the semester every team will
demonstrate the application to department faculty and guests from industry.
This presentation should also include a checklist based requirements
validation. Even though presentation grading is not on the quality of software
deliverables but on the quality of the presentation, software deliverables are a
pre-requisite for the presentation. A presentation with no actual software
deliverable will be graded zero.
(guide) (sample IP)
Implementation Report (IR) (10%) : The implemantation report should
assist users who will actually make use of the software. The user
documentation should define the need and scope of the system and
demonstrate use of all features of the system. To ensure consistency within
user documentation, an ISO standard is used. The standard does not dictate
how the documentation should be structures, all it does is to enable
documentation developers to use a common set of formatting and similart
criteria.
(guide) (user manual template) (ISO user manual standard)
Coding Quality (CQ) (15%) : The coding quality, that can either be
manually observed or evaluted using software engineering tools and
techniques show how good a software is structured with respect to aspects
such as understandability and maintainability. Very small effort such as using
a common coding style and commenting complicated algorithms can
contribute vastly towards overall quality.
(coding style guide) (testing guide)
(list of tools for improving coding quality)
(list of tools for documentation)
Individual Performance (InP) (5%): Even though teams collaborate, some
team members are over-performers, or some do stay behind even when hey
contribute alot. There may be also similar reasons for under-performance
These are based on behavioral preferences and can not be judged easily by
looking at code deliverables. The supervisor is responsible for observing and
improving the performance of individual team members, possibly through off
the record performance improvement plans and action items. At the end of the
semester, each team member is individually evaluated for personal attitude
towards the project and personal performance improvement.
4. Weekly Progress (30%)
Team members are required to report in to their supervisor at least once every week on a
pre-scheduled basis. These scheduled meeting are integral to keeping the pace of the project
and to early detect problems. At the end of each week, the supervisor evaluates the results
and weekly progress of the team on individual basis. Contribution to some smaller project
activities such as establishing a project group web site, using Moodle or email lists to notify
others on updates will also be evaluated on this basis.
Weekly Progress Reports (WPR) (30%): There will be a number of weekly
progress reports prepared by the supervisor. The average of the individual
scores for each team member will be used for the overall grading of that
person at the end of the semester.
(guide for attending meetings)
5. Attendance (5%)
The weekly lectures aim at delivering both theory and practical insight into problems related
to software project management. Thus attending to and participating in the weekly lectures
is crucial.
An important note on individual grading: Although the projects are assigned to teams, grading is
done individually. In the past, there were letter grade differences in members of the same team,
mostly due to individual performance observed in weekly meetings. This semester the individuality
of grades is made more visible to the student.
40% of the total grading (weekly progress, individual performance, attendance) is directly
individual and 15% of the grading (three presentations) is partially individual.
Practically a team with very good project result could have a number of A's and a number of
F's based on contribution to project objectives and team work.