CS 491
Senior Design Project I

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

Details for the Current Academic Year

General

All senior students are required to undertake a capstone and innovative design project during their final year. Innovation is considered as the creation of better or more effective products, systems, services, or technologies that have the potential to be accepted by markets, governments, and society.

CS491-492 projects are directed towards an innovative solution of a real and substantial problem. These projects are conducted within a team of 3 to 5 students. Students must show the ability to identify, formulate and find innovative solutions to practical and theoretical problems as part of the project. Students have to be able to communicate the results of their work in both written and oral form within their group as well as to others. These projects provide a unique opportunity for the students to develop and demonstrate powers of initiative and collaborative work.

Each project is undertaken by the supervision of a faculty member of the Computer Engineering Department. Each team will propose a project to one of the faculty members as their candidate supervisor. The proposed project must be identified and formulated by the team. If the faculty member accepts to supervise the proposed project, he/she will determine two jury members and one innovation expert from the list of Innovation Experts. 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 Department Secretary by Monday of the 4th week of the semester.

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 4th week of the semester:

Project Specifications: {Due: 5pm, Monday, 4th week of the 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. Copies of the Project Specification Report must be returned to the project supervisor and the jury members.

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
Helpful material:
[1] ACM Code of Ethics and Professional Conduct
[2] The Software Engineering Code of Ethics, IEEE Computer Society
[3] IEEE Code of Ethics
[4] Computer and Information Ethics, Stanford Encyclopedia of Philosphy

Analysis Report: {Due: 5pm, Monday, 8th week of the 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
Reference: Object-Oriented Software Engineering, Using UML, Patterns, and Java, 2nd Edition, by Bernd Bruegge and Allen H. Dutoit, Prentice-Hall, 2004, ISBN: 0-13-047110-0.

High-Level Design Report: {Due: 5pm, Last day of the 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
Reference: Object-Oriented Software Engineering, Using UML, Patterns, and Java, 2nd Edition, by Bernd Bruegge and Allen H. Dutoit, Prentice-Hall, 2004, ISBN: 0-13-047110-0.

Grading
Total grade has three components:

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

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

Project Evaluation Form: PDF file.