CS 491
Senior Design Project I

Description: A technical and innovative group project emphasizing engineering design principles on a specific topic in any field of computer science or engineering. Documentation on specifications, analysis and the high level design of the project are required. Credit units: 3 ECTS Credit units: 6, Prerequisite: CS 202 and CS 319.

General

Projects are undertaken in cooperation with a faculty member and an innovation expert. Each team will propose a project to one of the faculty members. If the faculty member accepts to supervise the proposed project, he/she will determine two jury members and one innovation expert from the list. The team will present their project to the innovation expert for his/her assessment of the innovativeness of the project. The innovation expert completes the Assessment of Innovativeness form, which is to be returned to the project. The team and the innovation expert may prepare and sign a Memorandum Of Understanding (MOU) or a Non-Disclosure Agreement (NDA) to protect the intellectual property.

Each group must prepare a web page for their project and make their reports available on this page. Each report should be typed in accordance with the guidelines and must be spell checked (!) and adopt the department's standard layout (here is a Word template you may use). Three hard copies of each report is required. The hard copies of the reports must be handed in to the supervisor and the jury members by their respective due dates.

The team must email the following to the department secretary at sekreter@cs.bilkent.edu.tr by the end of the third week of the Fall semester:

• Name of the project
• The URL of the project web page
• Names of the team members
• Names of the supervisor, innovation expert and jury members
• One paragraph description of the project

Project Specifications: {Due: 5pm, Monday, 4^th week of Fall semester}
The project specifications report gives a title to and brief description of the proposed project. The initial project requirements are also identified. This document must also contain a section that discusses the project constraints such as economic, environmental, social, political, ethical, health and safety, manufacturability, and sustainability. In addition, discussion of the professional and ethical responsibilities relevant to the project must also be included in a separate section. The Assessment of Innovativeness form must be returned to the project supervisor and the jury members, along with the Project Specifications report.

Jury members are determined by the project supervisor.

One example organization of this report is as follows:

1. Introduction
1.1 Description
1.2 Constraints
1.3 Professional and Ethical Issues
2. Requirements
3. References

Analysis Report: {Due: 5pm, Monday, 8^th week of Fall semester}
The analysis report contains a detailed analysis of the problem. It should address all relevant issues. The analysis report must be available on the web page of the project.

Analysis Document of a project is produced as a result of the analysis of the system to be developed. The requirements specifications provided by the customer are analyzed carefully and this document is produced as a result of a thorough analysis of the system at hand. In a sense, this document is a contract between the developer ("you") and the user/customer ("us" in this case). Analysis results in a model of the system that aims to be correct, complete, consistent and verifiable. Developers formalize the system specification produced during requirements elicitation and examine in more detail boundary conditions and exceptional cases. Developers correct and clarify the system specification if any errors or ambiguities are found. The client and the user are usually involved in this activity, especially when the system specification needs to be changed and when additional information needs to be gathered.

For example, in object-oriented analysis, developers build a model describing the application domain. The analysis model is then extended to describe how the actors and the system interact to manipulate the application domain model. Developers use the analysis model, together with nonfunctional requirements, to prepare for the architecture of the system developed during high-level design.

There can be many different ways in which to organize an analysis document; the key point is being able to convey the model produced as a result of the analysis as clearly and completely as possible. One example organization for an object-oriented software system is as follows:

1. Introduction
2. Current system (if any)
3. Proposed system
3.1 Overview
3.2 Functional Requirements
3.3 Nonfunctional Requirements
3.4 Pseudo requirements
3.5 System models
3.5.1 Scenarios
3.5.2 Use case model
3.5.3 Object and class model
3.5.4 Dynamic models
3.5.5 User interface - navigational paths and screen mock-ups
4. Glossary
5. References

High-Level Design Report: {Due: 5pm, Last day of Fall semester}
High-level or system design is the transportation of the analysis model into a system design model. The high-level design report must be available on the web page of the project.

During system design, developers define design goals of the project, and decompose the system into smaller subsystems that can be realized by individual teams (subgroups). In the case of a software-intensive project, developers also select strategies for building the system, such as the hardware/software platform on which the system will run, the persistent data management strategy, the global control flow, the access control policy, and the handling of boundary conditions.

Extent and validity of the design principles that were used to carry out the project must be explained in detail. Creativity, that is the extent to which the team developed a novel solution to the design problem while still achieving a functional design, must be clear.

The following applies to object-oriented software-oriented projects for the most part; for other types of projects, the tasks are somewhat different, and the contents of the report must be decided in consultation with the project advisor.

The result of system design is a model that includes a clear description of each of these strategies, a subsystem decomposition, and a (UML) deployment diagram representing the hardware/software mapping of the system. Again there is no single way to organize such a report; a sample for an object-oriented software system would be as follows:

 
1. Introduction
1.1 Purpose of the system
1.2 Design goals
1.3 Definitions, acronyms, and abbreviations
1.4 Overview
2. Current software architecture (if any)
3. Proposed software architecture
3.1 Overview
3.2 Subsystem decomposition
3.3 Hardware/software mapping
3.4 Persistent data management
3.5 Access control and security
3.6 Global software control
3.7 Boundary conditions
4. Subsystem services
5. Glossary
6. References

Grading
Total grade has three components:

• 75%: Group grade. It is the average of grades given by the supervisor and jury members for the performance of the group through out the semester.
• 20%: Participation in the project. It is determined by the supervisor separately for each group member.
• 5%: Peer grade. It is the average of the grades given by the other team members. Each team member is asked to evaluate the contribution of every other member of their team. It is the responsibility of the project supervisor to get the grades of each team member for every other member of the team.

The letter grades will be assigned according to the following table:

Range	Grade
90-100	A
85-89	A-
80-84	B+
75-79	B
70-74	B-
65-69	C+
60-64	C
55-59	C-
50-54	D+
45-49	D
0-44	F

Project Evaluation Form: PDF file.