ÇANKAYA ÜNİVERSİTESİ AKADEMİK YILI BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜMÜ LİSANS BİTİRME PROJELERİ UYGULAMA ESASLARI

Transkript

1 ÇANKAYA ÜNİVERSİTESİ AKADEMİK YILI BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜMÜ LİSANS BİTİRME PROJELERİ UYGULAMA ESASLARI Çankaya Üniversitesi Bilgisayar Mühendisliği Lisans programının şartlarına göre öğrencilerin ekip kurarak, akademik danışman gözetiminde iki dönemlik bir proje çalışması yapması gerekmektedir. Bu projelerin sanayi ile iş birliği içinde yürütülmesi öngörülmüş olup, öğrencilerden bu proje kapsamında bir şirketin projesi ya da sorununa yönelik bir gerçek hayat problemi çözmesi beklenmektedir. Bitirme projeleri normal şartlarda öğrencinin yedinci ve sekizinci döneminde kayıt olduğu her biri bir dönemlik ve birbirinin devamı niteliğinde olan iki dersten oluşur. Bu dersler aşağıda listelenmiştir: CENG Innovative System Design and Development I CENG Innovative System Design and Development II Bu derslerin sorunsuz yürütülebilmesi açısından projelerin derlenmesi, öğrencilere sunulması, gerekli plan ve yönergelerin hazırlanması, ders ile ilgili formların takip edilmesi ve ilgili toplantıların düzenlenmesi işlerinde Lisans bitirme projeleri koordinatörlüğü görev alır. Bunların yanı sıra, öğrencilerin ders hakkında bilgilendirilmesi ve gerekli duyuruların yapılması da bu koordinatörlüğün görevleri arasındadır. Öğrencilerin bu derslere kayıt olması hususunda şu kurallar uygulanır: 1. Her iki ders de Güz, Bahar ve Yaz dönemlerinde açılır. Normal şartlar altında öğrenciler CENG 407 dersine Güz döneminde, CENG 408 dersine ise Bahar döneminde kayıt olurlar. Yaz döneminde açılan derslerden mezun durumunda olan öğrenciler faydalanabilir. 2. CENG 408 dersinin ön koşulu olarak öğrencinin CENG 407 dersinde başarılı olması şartı aranır. 3. Öğrenci bu iki dersi ardışık iki dönemde alır. CENG 408 dersinin Yaz döneminde alınabilmesi için öğrencinin CENG 407 dersinden başarılı ve mezun durumunda olma şartı aranır. Öğrenci her iki derse aynı dönemde kayıt olamaz. 4. Bu dersleri sadece dördüncü sınıf öğrencileri alabilir. CENG 407 dersi şu esaslara göre yürütülür: 1. Projeler esas olarak derslerin başladığı tarihten bir hafta öncesine kadar bölüm elemanları tarafından bölümce uygun bulunan şirketlerle iletişim kurularak belirlenir. Bu süreçte problemin tanımını şirket belirler. Problemin tanımını ve detaylarını gösteren Proje

2 Seçim Formu nun (EK1 - Project Selection Form) ilgili yerleri şirket tarafından doldurulur ve öğrencilere daha sonra sunulması için havuzda bekletilir. 2. Öğrencilerin kendilerinin şirketler ile iletişime geçerek getirdiği projeler var ise bu projelerin bölüm tarafından uygun bulunması koşuluyla havuza eklenmesi sağlanır. 3. Dönemin ilk üç haftasında derse kayıtlı olan öğrencilerle ortak toplantılar yapılır. Bu toplantıda proje koordinatörlüğü tarafından öğrencilere dersin yürütülmesi, yazılım geliştirme süreçleri hakkında bilgiler verilir. Öğrencilerin ekip kurması ve bir proje seçmesi ya da bir projeye dahil olması sağlanır. Bu toplantılara katılım zorunludur. 4. Proje ekipleri zorunlu haller dışında üç kişiden oluşur. 5. Proje ekibi havuzdan uygun bulduğu bir proje seçer. Proje Seçim Formu nu doldurur ve bu formun dört kopyasını ilgili şirkette imzalatıp, onaylattırır. Formun iki kopyası şirket ile ekipte kalır. Diğer kopyalar ise proje ekibi tarafından proje koordinatörüne ve proje danışmanına dağıtılır. 6. Öğrenciler tarafından alınan projeler, bölüm elemanları tarafından seçilir. Böylece her projeye bir proje danışmanı atanmış olur. Gerektiğinde projeye bir yardımcı danışman da atanabilir. Öğrenciler tarafından seçilmeyen projeler, daha sonraki dönemlerde değerlendirilmek üzere havuzda kalır. 7. Proje ekibi dönem sonunda kadar her hafta proje danışmanıyla birlikte düzenli olarak toplanır. Bu toplantılar Proje Takip Formu (EK2 - Project Tracking Form) ile kayıt altına alınır. Bu form öğrenci başına iki kopya halinde tutulur. Bir kopya proje danışmanı tarafından, diğer kopya ise öğrenci tarafından saklanır. Öğrenci, ortak yapılan toplantılar dahil en az proje toplantısına katılmak zorundadır. Aksi takdirde, öğrenciye dönem sonunda NA notu verilir. 8. Proje ekipleri dönem sonuna kadar proje detaylarını içeren bir proje raporu ve SRS (System Requirements Specification) ile SDD (System Design Description) dökümanlarını hazırlar ve bölüme teslim eder. 9. Dönem sonunda proje ekipleri o dönem boyunca yaptıkları çalışmayı özetleyen bir sunum yapar. CENG 408 dersi şu esaslara göre yürütülür: 1. Öğrenciler bu derste, CENG 407 dersinden başarılı olmaları koşuluyla aynı ekip üyeleri ile projelerine devam ederler. 2. Dönemin ilk iki haftasında derse kayıtlı öğrencilerle ortak toplantılar yapılır. Bu toplantıda proje koordinatörlüğü tarafından öğrencilere dersin yürütülmesi hakkında bilgiler verilir. Gerekiyorsa ekip üyelerinin yeniden düzenlenmesi sağlanır. Bu toplantılara katılım zorunludur. 3. Proje ekipleri, CENG 407 dersinde olduğu gibi bu derste de proje danışmanları ile haftalık düzenli toplantılar yaparlar. Toplantılara katılım zorunlu olup, bu konuda CENG 407 dersi ile aynı esaslar uygulanır.

3 4. Bu derste proje ekiplerinden, bir önceki dönemde hazırlamış olduğu SDD dökümanı uyarınca projesini geliştirmesi beklenir. Geliştirilen projeye ait olan kaynak kod ve uygulama dosyaları ekip tarafından bölüme teslim edilir. Ayrıca, proje ekibi geliştirdikleri uygulamaya bağlı olarak kullanıcı/yönetici kılavuzlarını hazırlar. Bu dökümanları da proje ile birlikte bölüme teslim eder. 5. Geliştirilen uygulama proje ekibi tarafından SRS dökümanında belirtilen gereksinimlere göre son testleri yapılır. Bitirilen proje ve hazırlanan kılavuzlar proje alınan şirkete teslim edilir. Şirket projeyi onaylarsa Proje Kabul Formu nu (EK3 - Project Acceptance Form) imzalar. Bu formun tamamlanmış ve imzalanmış hali proje danışmanına teslim edilir. 6. Proje ekibi, tüm projeyi detaylı açıklayan bir proje raporu hazırlar. Bu raporu SRS ve SDD dökümanlarının son halleriyle birlikte bölüme teslim eder. Projenin bölümde tanıtılması için ders sayfasında açıklanan kurallar uyarınca bir poster hazırlamak ve bölüme teslim etmek zorundadır. 7. Ekipler, dönem sonunda projelerini özetleyen bir sunum ve demo yaparlar. Sunum dökümanları da bölüme teslim edilir. CENG 407 ve CENG 408 derslerinin değerlendirilmesi proje danışmanı ve bölüm elemanlarından oluşan bir juri tarafından, bu dersler için özel hazırlanmış Öğrenci Değerlendirme Formu nda (EK 4-5: Student Evaluation Form) belirtilmiş kriterlere göre yapılır. Proje danışmanı genel olarak, projenin dökümantasyonuna, proje raporuna ve öğrencinin ekibe olan katkısına göre değerlendirme yapar. Dökümantasyonların değerlendirilmesi EK6 da verilen rubrik (Grading Rubric) doğrultusunda yapılır. Juri ise son ürünün durumuna, yapılan sunuma ve proje alınan şirketin beğenisine göre değerlendirir. Belirtilen her kriter öğrencinin notuna belirli oranda katkı yapar. Bu notlar toplanarak öğrencinin alacağı not belirlenmiş olur.

4 FORM CENG- 01 ÇANKAYA UNIVERSITY Computer Engineering Department CENG Project Selection Form This form should be used for CENG Project Selection. Three copies of this form should be signed, one for the student, one for the supervisor, and one for the department files. Part I. Project Member(s). To be completed by the Student(s). Mobile Mobile Mobile Part II. Project Information. To be completed by the Student and the Supervisor. Starting Term / Fall Spring Title of the Project Project Description Part III. Company Information and Approval. Company Name Address City Contact Name Web Page Phone Seal and Date Part IV. Supervisor(s) Approval. Supervisor Name Department Co-supervisor Name Department Date Date Version: September 2012

5 FORM CENG-03 ÇANKAYA UNIVERSITY Computer Engineering Department CENG Project Tracking Form This form should be used for CENG by each student to track the project progress throughout the semester. The final signed version should be added to the semester-end report. Part I. Project Member. To be completed by the Student Mobile Part II. Project Information. To be completed by the Student and the Supervisor Starting Term / Fall Spring Project Number Project Title Part III. Weekly Accomplishments Meeting No Date and Time Work Item Completed of Student of Part IV. Remarks While developing a project, the following work items must be completed: 1. Problem Definition: A clear definition of your project should be developed first. Project members should discuss in detail the scope of the project with their advisors and the company or institution sponsoring the project. 2. Literature Search: At least three similar projects/tools/applications/etc should be investigated and analyzed. A comparison should be stated. How the selected project will differ from and/or improve the existing projects/tools/applications/etc. 3. Outline and Schedule: An outline of the project and a weekly schedule should be developed. 4. Requirements: A document describing the requirements of the project should be written. This document will describe in detail what the project will do. 5. Design: A document describing design of the project should be written. This document will describe in detail how the project will be implemented. (Architecture, Model, DB Design, UI Design, etc.) 6. Implementation: In this work item, the project will be built. Source code and manuals (user, admin, etc.) should be available. 7. Validation: In this work item, the project should be tested by the project members. The tested product should be delivered to the company or institution sponsoring the project for acceptance. Note 1: For projects which span two semesters (CENG 407 and CENG 408), the first 5 items should be completed during the first semester. Note 2: If a project does not fit the development model described above, similar work items should be developed and completed. Note 3: In order to pass the course, each project member should attend at least meetings each semester.

6 FORM CENG- 02 ÇANKAYA UNIVERSITY Computer Engineering Department CENG Project Acceptance Form This form should be used for CENG Project Acceptance by the sponsoring company. Part I. Project Member(s). To be completed by the Student(s). Mobile Mobile Mobile Part II. Project Information. To be completed by the Student Starting Term / Fall Spring Title of the Project Project Description Part III. Company Information and Statement of Acceptance (To be completed by the sponsoring company) Company Name Address City Contact Name Internet Address Phone Seal and Date Please indicate below whether the finished product is accepted in terms of its fitness to your needs (functionality), completeness, and quality. Statement of Acceptance Version: September 2012

7 FORM CENG- 05 ÇANKAYA UNIVERSITY Computer Engineering Department CENG 407 Student Evaluation Form This form should be used for CENG 407 for each student by the advisor, co-advisor, and the members of the jury to determine the student s final grade. Part I. Project Member. To be completed by the Student Part II. Project Information. To be completed by the Student and the Supervisor Starting Term / Fall Spring Project Number Project Title Part III. Grading No Grading Component Comments Out of Evaluation Attendance and progress* o Weekly meetings with advisor, Adherence to project schedule Wks Grade U S Report o Meets report requirements (posted on the web) Eval Very Bad Bad Ave Good Very Good Grade Requirements (SRS) o IEEE 830 standard Eval Very Bad Bad Ave Good Very Good Grade Design (SDD) o High Level Design, GUI, DB, Module Eval Very Bad Bad Ave Good Very Good Grade Ethical and Social Responsibility o IEEE code of ethics, Information Privacy, Intellectual Property Rights Eval None Low Medium High Very High Grade Contribution o Teamwork, Individual Load, Individual Contribution Eval None Low Medium High Very High Grade Presentation o Flow, Language, Time, Quality Eval Very Bad Bad Ave Good Very Good Grade Note: Letter grades will be assigned using the scale below 90 and above AA CB DD BA CC FD BB DC 39 and below FF Jury Name Date U or S TOTAL 0 Evaluator (*) The student must attend at least meetings with project coordinator and advisor. Otherwise, the course is graded as N/A. Version 3 / September 2013

8 FORM CENG- 04 ÇANKAYA UNIVERSITY Computer Engineering Department CENG 408 Student Evaluation Form This form should be used for CENG 408 for each student by the advisor, co-advisor, and the members of the jury to determine the student s final grade. Part I. Project Member. To be completed by the Student Part II. Project Information. To be completed by the Student and the Supervisor Starting Term / Fall Spring Project Number Project Title Part III. Grading No Grading Component Comments Out of Evaluation Attendance and progress* o Weekly meetings with advisor, Adherence to project schedule Wks Grade U S Contribution o Teamwork, Individual Load, Individual Contribution Eval None Low Medium High Very High Grade Ethical and Social Responsibility o IEEE code of ethics, Information Privacy, Intellectual Property Rights Eval None Low Medium High Very High Grade Outputs o Updated project report, Updated Requirements (SRS), Updated Design Document (SDD), User Documentation, Implementation Environment Eval Very Bad Bad Ave Good Very Good Grade End Product o Availability of fully functional product o Successful Demo o Customer Acceptance Eval Very Bad Bad Ave Good Very Good Grade Presentation o Flow, Language, Time, Quality Eval Very Bad Bad Ave Good Very Good Grade Note: Letter grades will be assigned using the scale below 90 and above AA CB DD BA CC FD BB DC 39 and below FF Name Jury Jury Date U or S TOTAL 0 Evaluator (*) The student must attend at least meetings with project coordinator and advisor. Otherwise, the course is graded as N/A. Version 3 / September 2013

9 Grading Rubric for CENG 407 and CENG 408

10 Grading Rubric Project Report This is the rubric outline the grading criteria for project report. Achievement Minimal Limited Satisfactory Exemplary Grade Section(s) missing, not Serious omissions or Some problems with Provides all relevant Content 5 useful, inconsistent, or problems with content (2) completeness or details of information correctly and wrong. (1) content (4) with appropriate detail (5) Introduction Problem Definition Description of the System Grammar and Spelling Expression Tone Organization Poor introduction (2) Problem not defined at all (3) Very weak description of the system designed (8) Many serious mistakes in grammar or spelling (2) Very difficult to understand (1) Tone not appropriate for technical writing (1) Very hard to find information (1) Brief introduction, company not introduced (4) Insufficient detail on problem definition (6) Description of the system designed with no detail (16) Several large issues or many smaller ones (4) Hard to follow or poor word choices (2) Tone somewhat unprofessional (2) Information difficult to locate (2) Sufficient introduction of overall project process and company (8) Problem is defined but some inadequacy (12) Almost complete description but some minor drawbacks (32) Some small grammar or spelling issues (8) Mostly easy to read and understand (4) Mostly professional tone (4) Can find information with slight effort (4) Full introduction of overall project process and company () Well defined problem in every detail (15) Full description with all details including charts, figures (40) Grammar, punctuation, and spelling all correct () Clear and concise. A pleasure to read (5) Tone is consistently professional (5) All information is easy to find and important points stand out (5) Layout is attractive, consistent, and helps guide the reader (5) Layout Layout makes it harder to understand and use the document (1) Layout is inconsistent or not visually appealing or supportive (2) Layout is reasonable, consistent and generally helpful (4) Total 0 (Total:20) (Total:40) (Total:80) (Total:0)

11 Grading Rubric - Software Requirements Specification (SRS) Grade Criteria (5 pts) 1. Introduction - Title Page - Document Control - Table of Contents - Purpose and Intended Audience - Scope - Definitions - References All items are complete and accurate; TOC reflects document; definitions are accurate and necessary; references are in correct format; 5 points (15 pts) 2. General Description - Product Perspective - Features - User Characteristics - General Constraints - Assumptions and Dependencies Most items are complete and accurate; some definitions missing or unnecessary; 3 points Several items are missing or incomplete; Use Cases: points Diagram is syntactically correct; use cases and actor descriptions match diagram; use cases and scenarios have pre/post conditions and triggers; useful alternate flows are described; scenarios capture system and actor interactions; points Diagram is syntactically correct; most use cases and actors match diagrams; most use cases and scenarios have pre/post conditions and triggers; alternate flows are described; scenarios capture system and actor interactions; 5 points Diagram syntax is incorrect (e.g., arrows on associations, mismatches between use case/actor descriptions and diagram, incorrect use of stereotypes); scenario flows do not capture system/actor interactions; alternate flows missing; pre/post conditions missing;

12 Perspective, constraints, assumptions: 5 points Perspective is complete Perspective is accurate, and accurate, describes describes needed existing system and changes; Gives constraints needed changes; Gives and assumptions. Does constraints and not list requirements in assumptions. Does not list the constraints and requirements in the assumptions. constraints and assumptions. 3 points 5 points (15 pts) 3. External Interface Requirements Perspective is incomplete; lists requirements in the constraints and assumptions. - User Interface - Hardware Interface - Software Interface - Communications Interface User interface, if needed, is described. System behavior (e.g., stimulus/response) is not described. User interface requirements are traceable (not fabricated); Graphical interfaces are described using images as well as words. All interfaces are identified and requirements specified. 15 points Most interface requirements are traceable (not fabricated); Most requirements are unambiguous; Most requirements are present. 8 points Interfaces are not all identified or described. System behavior (from section 4) is present;

13 (20 pts) 4. Behavioral Requirements - Same class of user - Real world objects - Stimulus - Related features - Functional All requirements are complete, accurate, not repeated, and placed in the appropriate section. Subsections, where useful, have been defined and included in the TOC; Requirements are traceable, consistent, clear, unambiguous, and precise. Cross-references, where needed, are present and accurate. Requirements are testable. 2 Most requirements are complete, accurate, not repeated, and placed in the appropriate section. Most requirements are traceable, consistent, clear, unambiguous, and precise. Document reflects a substantial understanding of the project. Most requirements are testable. points Requirements are incomplete, inaccurate, repeated, or placed in the wrong section. No subsections have been defined; Requirements are fabricated; requirements are inconsistent or ambiguous. Requirements are not testable. The document does not reflect substantial understanding of the project. ( pts) 5. Non-Behavioral Requirements - Performance - Security - Qualitative (Same criteria as item 4) ( pts) 6. Other Requirements - Database - Operations - Site Adaptation (Same criteria as item 4)

14 (5 pts) 7. Functional Model Diagram is syntactically correct (data on arcs, processes in nodes). Processes have appropriate inputs and outputs. All processes are present. All data sources are identified. Each level has a consistent level of abstraction. All diagrams are consistent between levels. Process and data names are appropriate and meaningful. Diagram is syntactically correct.most processes have appropriate inputs and outputs. Most processes are present. Data sources are identified. All diagrams are consistent between levels. Most process and data names are appropriate and meaningful. Diagram syntax is incorrect (e.g., processes and data not clearly defined or mislabeled), control flow is expressed. Processes are missing. Data sources are not identified. Diagrams are inconsistent between levels. Names are not meaningful or appropriate. 5 points (5 pts) 8. Dynamic Model Diagram is syntactically correct (event [condition]/action on arcs, states in nodes). Initial and final states are clear. Transitions into and from composite states are clear and accurate. State names imply persistence and are appropriate and meaningful. 3 points Diagram is syntactically correct. Initial and final states for system are identified. Most transitions are clear and deterministic. Most names are appropriate and meaningful. Diagram syntax is incorrect States are missing. Transitions are not labeled. Names are not meaningful or appropriate. 5 points 3 points

15 (5 pts) 9. Static Model Diagram is syntactically correct (entities and relationships); entities have attributes; multiplicities are indicated. Diagram models the data elements, objects, and entities controlled by the system (and not the implementation of the system itself). Names are appropriate and meaningful. Diagram is syntactically correct. Most entities or classes have appropriate attributes. Most names are appropriate and meaningful. Diagram syntax is incorrect. Diagram models implementation, but not elements controlled by the system. Many entities or classes are missing. Names are not meaningful or appropriate. 5 points ( pts). Presentation 3 points TOTAL: (0 pts) All numbered requirements use shall ; grammar is correct. Complete sentences are used; Formatting assists readability. points Total Grade: Most items are grammatically correct. Most of the formatting is consistent and aids readability. 5 points Many major grammatic errors are present; numbered requirements do not use shall ; document is difficult to read.

16 Grading Rubric - Software Design Description (SDD) Achievement Minimal Limited Satisfactory Exemplary Grade Some problems with Provides all relevant information Content Section(s) missing, not useful, Serious omissions or problems 5 completeness or details of correctly and with appropriate inconsistent, or wrong. (1) with content. (2) content (4) detail (5) Introduction Architectural Description Interface Description Detailed Design 35 Grammar and Spelling Expression Tone Organization Layout Minimal details See criteria in exemplary (2) Minimal details See criteria in exemplary (2) Insufficient interface description, no details (2) Very poor design, mostly irrelevant with SRS (7) Many serious mistakes in grammar or spelling (2) Very difficult to understand (1) Tone not appropriate for technical writing (1) Very hard to find information (1) Layout makes it harder to understand and use the document (1) Limited details See criteria in exemplary (4) Limited details See criteria in exemplary (4) Limited interface description, not supported by figures, screenshots, etc. (4) Deficient design not satisfying most requirements in SRS (14) Several large issues or many smaller ones (4) Hard to follow or poor word choices (2) Tone somewhat unprofessional (2) Information difficult to locate (2) Layout is inconsistent or not visually appealing or supportive (2) Satisfactory details See criteria in exemplary (8) Satisfactory details See criteria in exemplary (8) Minor deficiencies in interface description (8) Partially satisfies SRS, minor problems with design (28) Some small grammar or spelling issues (8) Mostly easy to read and understand (4) Mostly professional tone (4) Can find information with slight effort (4) Layout is reasonable, consistent and generally helpful (4) All details (scope of product, references, definitions, acronyms, abbreviations) are given () Good architectural design (superclasses/sub-classes, attributes and correct notation) () All interfaces are well-described and supported by figures, screenshots etc. () Meets all requirements aforementioned in SRS (35) Grammar, punctuation, and spelling all correct () Clear and concise. A pleasure to read (5) Tone is consistently professional (5) All information is easy to find and important points stand out (5) Layout is attractive, consistent, and helps guide the reader (5) Total 0 (Total:20) (Total:40) (Total:80) (Total:0)