IB Computer Science IA Yazım Rehberi ve 20 Orijinal Araştırma Sorusu Önerisi

IB Computer Science Internal Assessment, yani IB Computer Science IA, programın en somut ürünlerinden biri. Kendi yazdığın gerçek bir yazılım, üstüne 2,000 kelimelik teknik bir rapor ve 35 saatlik planlı çalışma ile ortaya çıkan ciddi bir proje.

SL seviyesinde IA toplam notunun yaklaşık %30’unu, HL seviyesinde ise %20’sini oluşturuyor. Bu yüzden “küçük proje” değil, Grade Boundary farkı yaratabilecek kadar etkili bir bileşen. HL öğrencileri için maksimum 5 dakikalık zorunlu bir video demo var, SL için video şiddetle önerilen ama zorunlu olmayan bir bileşen.

Bu rehberin amacı, sana hem yapısal bir yazım stratejisi vermek hem de sonunda kullanabileceğin 20 özgün IA research question fikri sunmak. Yazıyı okuduğunda, hangi konuyu seçeceğine, raporu Criterion A’den E’ye nasıl yazacağına ve projeni nasıl test edip değerlendireceğine çok daha net karar verebileceksin.

IB Computer Science Internal Assessment Temel Kuralları ve Değerlendirme Kriterleri

IA’ye başlamadan önce oyunun kurallarını net bilmek gerekiyor. Aksi halde ortada fena olmayan bir kod olur ama not kıran küçük detaylar gözden kaçar.

Word limit, süre ve format: IA raporunun iskeletini anlamak

IB, IA raporunun maksimum 2,000 kelime olmasını istiyor. Bu sınıra, kodlar, appendix’teki ekran görüntüleri, test tabloları ve referanslar dahil değil; esas sayılan kısım açıklayıcı yazı.

Toplam 35 saatlik bir çalışma süresi öngörülüyor. Bunun içinde:

• Konu araştırması ve Planning,
• Design ve System overview,
• Coding ve Testing,
• Rapor yazımı ve video çekimi yer alıyor.

Teslim formatı genelde:

• Tek bir PDF rapor (Criterion A–E’yi içeren),
• Ayrı bir appendix PDF (source code, ek diagramlar, ek test çıktıları, uzun loglar) şeklinde oluyor.

Kodun tamamını ana rapora yapıştırmak kelimeyi şişirdiği için yanlış. Ana raporda sadece gerçekten açıklamak istediğin, algoritma ve data structure mantığını gösteren kısa parçaları kullanmak, tam kodu ise appendix’e koymak çok daha sağlıklı.

Test case ekran görüntüleri, uzun konsol çıktıları veya UI screenshot’ları da genelde appendix’te tutulmalı. Raporda sadece en kritik 1–2 örneği açıklayıcı metinle beraber göstermek, hem kelime sınırını hem de okumayı rahatlatır.

IA ile ilgili ayrıntılı resmi yönergeler, resmi Computer Science guide içinde yer alıyor; öğretmeninin paylaştığı güncel PDF mutlaka ilk referansın olsun.

Puanlama yapısı: Criterion A, B, C, D, E neye bakıyor?

IB, Internal Assessment’i 5 ana Criterion üzerinden değerlendiriyor. İsimler kılavuza göre hafifçe değişebilse de öz şu şekilde:

• Criterion A – Planning
  Problemi, bağlamı ve hedef kullanıcıyı ne kadar iyi tanımladığın, success criteria’ları ne kadar net yazdığın değerlendiriliyor. Güçlü bir A, projenin geri kalanı için sağlam bir temel demek.
• Criterion B – Solution overview (Problem decomposition & plan)
  Problemi küçük parçalara ayırma, abstraction ve stepwise refinement kullanma becerin ölçülüyor. Flowchart, UML class diagram, state diagram gibi gösterimler burada çok işe yarıyor. Ayrıca test plan’ın ilk hali de bu Criterion’da kendini gösteriyor.
• Criterion C – Development
  Çözümü nasıl geliştirdiğini, hangi algorithm ve data structure’ları neden seçtiğini, hangi programming techniques’i kullandığını anlattığın bölüm. Sadece “şu kodu yazdım” demek değil, kendi teknik kararlarını gerekçelendirdiğin yer.
• Criterion D – Functionality (veya raporda Development ile iç içe anılabilir)
  Ürünün gerçekten çalıştığını, success criteria’ları karşıladığını, hatasız veya kabul edilebilir hata seviyesinde olduğunu kanıtlayan testler ve video gösterimi. HL için zorunlu video bu Criterion’la çok yakından ilişkili.
• Criterion E – Evaluation
  Çözümün ne kadar başarılı olduğunu analitik biçimde tartıştığın, limitations ve future improvements yazdığın kısım. “Her şey süper çalışıyor” demek yerine, dürüst ve ölçülebilir bir değerlendirme bekleniyor.

Grade Boundary mantığı basit: IA’den alacağın puan, yazılı sınavlarla birleşip toplam Computer Science puanını oluşturuyor. 7 almak için genelde ortalama olarak oldukça yüksek bir toplam gerektiğinden, IA’de birkaç puan bile fark yaratabiliyor.

IB kurallarında son yıllarda neler değişti? Client zorunluluğu ve video

Eski kılavuzlarda “client” bulmak zorunlu iken, yeni formatta gerçek bir client zorunluluğu kaldırıldı. Artık kendi hayatından, okulundan, hobilerinden bir problem seçip, onu kendin için veya hedeflediğin kullanıcı grubu için çözebilirsin.

Diğer önemli değişiklik, video:

• HL öğrencileri için maksimum 5 dakikalık, ürünü ve bazı testleri gösteren zorunlu bir video şart.
• SL öğrencileri için aynı tarz bir video şiddetle öneriliyor. Bazı öğretmenler “faktik olarak şart gibi düşün” bile diyor.

Bu değişim, proje seçimini de etkiliyor. Artık çok karmaşık ama test etmesi zor, göstermek için uzun video gerektiren konular yerine, 5 dakikada rahatça demonstre edilebilecek, net input-output örnekleri olan çözümler daha mantıklı hale geliyor.

Mükemmel Bir IB Computer Science IA Konusu Nasıl Seçilir?

Konuyu doğru seçmek, hem kodlamayı hem de raporu kolaylaştırıyor. Çok geniş bir fikir, 35 saatte yetişmiyor; çok basit bir fikir de düşük puan riski yaratıyor.

İyi bir IA konusu için 5 temel kriter

1. İlgi
Gerçekten ilgilendiğin bir alan seçmek işini ciddi şekilde kolaylaştırır. Örneğin okul kulübün için attendance app yazmak, bilmediğin bir sektör için generic inventory system yazmaktan daha motive edici olur.

2. Uygulanabilirlik (35 saat)
35 saat içinde planlama, coding, testing ve rapor yazımını bitirebileceğin bir fikir olsun. Örneğin “küçük bir timetable scheduler” makulken, “tüm okul için tam entegre SIS sistemi” gerçekçi olmaz.

3. Karmaşıklık (algorithm ve data structure içeriği)
IA’de seni öne çıkaran, kullandığın algorithm ve data structure seviyen. Basit bir CRUD uygulaması yerine, conflict-checking, sort, search, basic optimization gibi mantık içeren çözümler tercih edilmeli. Örneğin, exam revision planner’da akıllı bir scheduling algorithm kullanmak iyi bir örnek.

4. Veri ve input’a erişim
Projeni besleyecek veriye ulaşabiliyor olmalısın. Okul kulübü üyeleri, timetable verileri, geçmiş quiz sonuçları gibi kaynaklar, test case üretmeyi kolaylaştırır.

5. Test edilebilirlik
Başarının measurable olması çok önemli. Önceden tanımlanmış net test cases yoksa, Evaluation zayıf kalır. Örneğin “haftalık programda time conflict olmaması” gibi açık kriterler, test etmeyi kolaylaştırır.

Çok geniş veya çok basit IA fikirlerinden nasıl kaçınılır?

Aşırı geniş örnekler:

• Tam kapsamlı bir “social media platform”
• Ödeme entegrasyonu olan “full e-commerce site”

Bu tür projeler, güvenlik, authentication, payment gateway, massive data gibi konulara girdiği için hem gerçekçi değil hem de raporun odak noktasını dağıtır. Bunların yerine, örneğin sadece okul kulübü üyeleri için “announcement ve event tracking tool” geliştirmek çok daha makul.

Aşırı basit örnekler:

• Dört işlem yapan basic calculator
• Sadece sabit sorulardan oluşan static quiz app

Bu fikirler, yeterince algorithmic complexity taşımadığı için Criterion C ve D’de zayıf kalır. Aynı fikri yükseltmek için, örneğin quiz app’e adaptive difficulty, performance tracking ve basic statistics ekleyebilirsin.

Research question ve problem statement arasındaki fark

Problem statement, bağlamı ve ihtiyacı anlatan, genelde paragraf formunda bir açıklamadır.
Research question ise, çözümün odaklandığı soruyu daha net ve genellikle İngilizce, soru cümlesi şeklinde ifade eder.

Örneğin:

• Research question:
  “How can I design a scheduling algorithm to reduce conflicts in our school’s club meetings?”
• Problem statement (özet):
  “Okuldaki kulüp toplantıları sık sık çakışıyor ve öğrenciler aynı anda iki kulübe katılamıyor. Haftalık kulüp programını, öğrencilerin tercih ve uygunluklarına göre daha az conflict içerecek şekilde organize edecek bir yazılıma ihtiyaç var.”

IA raporunda ikisini de kullanmak, hem Planning bölümünü güçlendirir hem de projeni öğretmen ve moderatör için çok daha anlaşılır kılar.

IB Computer Science IA Yapısı: Criterion A’den E’ye Yazım Rehberi

Şimdi asıl işe, raporun Criterion A’den E’ye nasıl yazılacağına bakalım.

Criterion A: Planning bölümünü güçlü yazmak için adım adım rehber

Planning bölümünde üç ana bileşen var: context, problem description ve success criteria.

• Context:
  Kısa ama net biçimde ortamı tanımla. Okul mu, kulüp mü, küçük bir işletme mi, yoksa kişisel kullanımın mı?
• Problem description:
  Şu soruları yanıtla: Hangi sorunu çözmeye çalışıyorsun, bu sorun neden önemli, şu anki çözüm neden yeterli değil?
• Success criteria:
  Tipik olarak 3 ila 5 arası, ölçülebilir kriter yaz. Her biri, daha sonra Testing ve Evaluation’da referans alacağın cümleler olsun. Örneğin:
  • “The system should generate a weekly schedule without time conflicts.”
  • “The system should allow the user to edit and save schedules within 3 clicks.”
  • “The application should store at least 100 events without performance issues.”

Planning’i yazarken, ileride yazacağın her Criterion’u besleyen bir temel kurduğunu unutma.

Criterion B: Problem decomposition ve plan için diagram ve test planı kullanmak

Criterion B, problemin nasıl parçalara ayrıldığını ve çözümü nasıl planladığını gösterdiğin kısım.

• Problem decomposition:
  Büyük problemi küçük fonksiyonlara, modüllere ve görev listelerine böl. Örneğin bir attendance app için: user login, event creation, attendance marking, report generation gibi alt başlıklar.
• Abstraction ve stepwise refinement:
  Önce high-level adımları yaz, sonra gerektiği yerde bunları daha detaylı parçalara böl. Bu yaklaşım raporu okuyan kişiye mantığını gösterir.
• Diagramlar:
  • Flowchart, bir algoritmanın adım adım akışını göstermek için,
  • UML class diagram, class’lar ve aralarındaki ilişkiyi göstermek için,
  • State diagram, özellikle oyun veya çok aşamalı form süreçleri için oldukça kullanışlı.
• Test plan:
  Basit bir tablo tasarlayabilirsin; sütunlar genelde Test case, Input, Expected output, Actual result, Pass/Fail şeklinde olur. Bu planı Criterion D ve E’de kullanacağın gerçek test sonuçlarına dönüştüreceksin.

Criterion C: System overview ile algoritma ve system design’i anlatmak

System overview, “kodu baştan sona anlatmak” değil, sistemin mimarisi ve mantığını açıklamak için var. Genelde şu başlıklar işini görür:

• Overall architecture (örneğin client-server mi, tek desktop app mi),
• Key classes or modules,
• Kullanılan data structures (list, dictionary, tree, queue vb.),
• Main algorithms (örneğin scheduling algorithm, search algorithm, path finding),
• User interface flow (kullanıcının ekranda izlediği yol).

Burada gerçek kod yerine kısa pseudo-code örnekleri kullanabilirsin. Örneğin bir timetable conflict checker için:

for each event in events:   if event.time overlaps with any other event for same user:     mark conflict

Bu, moderatörün senin algorithm mantığını anlamasını sağlar, satır satır syntax ile uğraşmak zorunda kalmaz.

Criterion D: Development bölümünde kodun en güçlü kısımlarını vurgulamak

Development, “günlük gibi ne yaptığını sıraladığın” değil, önemli teknik kararlarını anlattığın yerdir.

Burada:

• Önemli coding decisions (örneğin neden belirli bir framework veya library kullandın),
• Error handling ve data validation yaklaşımların,
• Performance veya efficiency için yaptığın iyileştirmeler,
• Seçtiğin algorithm ve data structures’ın neden uygun olduğu

gibi konulara odaklanmalısın.

Raporun içine sadece, mantık içeren ve senin teknik seviyeni gösteren code fragments al. UI layout kodları, basit getter-setter’lar veya otomatik üretilmiş kodlar appendix’te kalabilir.

HL için zorunlu, SL için önerilen video demonstration da burada dolaylı olarak etkili. Videoda gösterdiğin önemli features ve test cases, Development ve Functionality algısını güçlendirir.

Criterion E: Evaluation bölümünde dürüst ve analitik bir değerlendirme yapmak

Evaluation bölümünde her bir success criterion üzerinden tek tek gitmek iyi bir yöntemdir. Örneğin:

1. Criterion 1 için sistem ne kadar başarılı oldu, hangi testler bunu gösterdi?
2. Criterion 2’de beklenmeyen sınırlamalar çıktı mı?
3. Performans, usability veya reliability ile ilgili gözlemlerin neler?

Ek olarak şu alt başlıklar okunurluğu artırır:

• Limitations,
• Possible future improvements,
• Scalability (sistemin büyüyen veri ile nasıl başa çıkacağı),
• Usability feedback (mümkünse gerçek kullanıcı yorumları).

En önemli nokta, “everything works perfectly” dememek. Küçük bir hatayı bile fark edip dürüstçe açıklaman, teknik olgunluk göstergesidir.

IB Computer Science IA İçin 20 Özgün Araştırma Sorusu ve Proje Fikri

Aşağıdaki fikirler, doğrudan kullanabileceğin veya kendi ilgi alanına göre uyarlayabileceğin, gerçekçi IA seviyesinde araştırma soruları.

Okul ve ders hayatına yönelik 5 IA araştırma sorusu önerisi

1. “How can I design a timetable optimizer to minimize clashes between students’ elective subjects?”
   Okulun ders programı verilerini kullanarak öğrenci seçimlerine göre çatışma sayısını azaltan bir scheduling tool geliştirme fikri.
2. “How can a smart assignment deadline tracker help students prioritize tasks based on urgency and importance?”
   Deadline, ağırlık ve tahmini süreye göre önceliklendiren, basic prioritization algorithm kullanan bir görev yöneticisi.
3. “How can I build an exam revision planner that adapts study sessions based on past quiz results?”
   Öğrencinin zayıf olduğu konulara daha fazla süre ayıran, basit rule-based adaptation içeren bir çalışma planlayıcısı.
4. “How can a school library recommendation tool suggest books based on borrowing history and genre preferences?”
   Basit recommendation logic ile, library verilerini kullanıp öğrencilere yeni kitaplar önerebilen bir sistem.
5. “How can I design a catch-up manager to help absent students access missed lessons and materials efficiently?”
   Devamsız öğrenciler için kaçırılan ders ve materyalleri otomatik listeleyen, link ve notları organize eden bir uygulama.

Oyun, spor ve hobi alanında 5 IA araştırma sorusu önerisi

6. “How can I create a puzzle game with adaptive difficulty based on player performance?”
   Oyuncunun başarı oranına göre seviye zorluk parametrelerini ayarlayan basit bir difficulty adjustment algorithm içeren oyun.
7. “How can a football training statistics tracker help players monitor progress over a season?”
   Maç ve antrenman verilerini toplayıp temel grafikler ve performans metrikleri üreten bir tracking tool.
8. “How can I design a music practice scheduler that balances pieces, scales, and technical exercises over a week?”
   Farklı çalışma türlerini haftaya eşit ve mantıklı dağıtan, küçük bir scheduling logic kullanan uygulama.
9. “How can a habit tracking app use streak-based feedback to motivate users to reach their goals?”
   Günlük alışkanlık verilerini tutup streak mantığıyla motivasyon sağlayan, basit analytics içeren bir mobil veya web app.
10. “How can I build a digital board game matchmaker that pairs players with similar experience levels?”
    Oyuncu istatistiklerine bakarak, benzer seviyedeki oyuncuları eşleştiren basic matchmaking algorithm barındıran bir sistem.

Veri analizi, görselleştirme ve küçük ölçekli AI içeren 5 IA araştırma sorusu

11. “How can I implement a simple recommendation system to suggest study resources based on students’ subject choices?”
    Subject seçimi ve geçmiş kullanım verisine göre resource öneren, rule-based veya basic similarity hesaplayan bir sistem.
12. “How can a basic classifier predict students’ preferred school clubs using survey data?”
    Çok basit bir classification algorithm (örneğin rule-based veya k-NN seviyesinde) ile kulüp tercih tahmini yapan bir uygulama.
13. “How can I visualize school energy usage data to help identify peak consumption periods?”
    Gerçek veya örnek enerji verilerini zaman bazlı grafiklerle gösterip peak dönemleri vurgulayan bir data visualization projesi.
14. “How can a study pattern analyzer use log data to provide feedback on students’ digital study habits?”
    Çalışma süresi, kırılmalar ve konu dağılımını log’lardan okuyup temel pattern analizi yapan bir tool.
15. “How can I design a simple route optimization tool for school buses to reduce total travel time?”
    Küçük sayıda durak için basit heuristic algoritmalarla güzergâh süresini azaltmaya çalışan bir optimization uygulaması.

Toplumsal fayda ve sürdürülebilirlik odaklı 5 IA araştırma sorusu

16. “How can I build a food waste tracking system for the school cafeteria to reduce leftovers?”
    Günlük üretim, tüketim ve atık miktarını kaydedip haftalık rapor ve simple trend analizi sunan bir sistem.
17. “How can a water usage monitor help students understand and reduce their daily water consumption?”
    Kullanıcı girişleri veya sensör verilerine dayalı basit dashboard ile su tüketimini gösteren ve hedef belirleten bir uygulama.
18. “How can I design a community event organizer that helps students find and register for local volunteering opportunities?”
    Etkinlik listesi, filtreleme ve basit registration takibi yapan, özellikle gönüllülük odaklı bir event management tool.
19. “How can a local recycling reminder app increase correct recycling behavior among households?”
    Konuma ve takvime göre hatırlatmalar gönderen, doğru geri dönüşüm talimatlarını gösteren bir notification tabanlı uygulama.
20. “How can I build a small NGO donation tracker that provides transparent reports to donors?”
    Bağışları kategorilere ayırıp, basit grafik ve raporlarla şeffaflık sağlayan bir tracking and reporting sistemi.

IB Computer Science IA Yazarken Sık Yapılan Hatalar ve Kaçınma Stratejileri

IA sürecinde çoğu öğrenci aynı tuzaklara düşüyor. Bunları bilmek, baştan önlem almanı sağlayacak.

Yetersiz planlama ve test: Sadece çalışan kodun IA için yeterli olmaması

Sadece “çalışan code” yüksek not getirmez. Planning, System overview ve Testing bölümleri zayıfsa, iyi yazılmış bir program bile beklediğin puanı vermez.

Basit bir strateji:

• İlk haftada konu seçimi ve Planning taslağını bitir,
• İkinci ve üçüncü haftalarda temel features’ı geliştirirken paralel olarak test plan’ını doldur,
• Son haftalarda refinements, ek testler ve raporun son haline odaklan.

Test plan’ı en baştan kurmak, hem Development sürecini yönlendirir hem de Evaluation’ı çok daha kolay yazar hale getirir.

Hazır kod kullanımı, AI araçları ve akademik dürüstlük

Stack Overflow, GitHub repository’leri veya AI coding assistant araçları gerçek hayatta sık kullanılıyor, ama IB bağlamında Academic Honesty kuralları çok net.

• Anlamadığın kodu doğrudan kopyalarsan, hem plagiarism riski doğar hem de viva voce tarzı sorularda zor durumda kalırsın.
• Harici kaynaklardan aldığın fikir, snippet veya algorithm için mutlaka uygun citation yapman gerekir.
• Extended Essay’de olduğu gibi, Internal Assessment’te de orijinallik ve kişisel katkı esas alınır.

Kısaca, ilham almak normal, ama nihai çözüm senin anlayabildiğin, açıklayabildiğin ve savunabildiğin bir ürün olmalı.

Dokümantasyonu en sona bırakmak ve kelime sınırını yanlış yönetmek

En yaygın hatalardan biri, önce tüm kodu yazıp, raporu deadline’dan hemen önce aceleyle yazmaya çalışmak. Bu, hem kelime sınırını aşmana hem de Criterion A ve B’nin yüzeysel kalmasına yol açar.

Daha iyi bir yaklaşım:

• Önce raporun ana başlıklarını ve kısa bullet point’lerini yaz (outline),
• Geliştirme sırasında önemli kararları not al,
• En sonda sadece bu notları düzenleyip, kelime sınırını kontrol ederek temiz bir versiyon çıkar.

Gereksiz ekran görüntülerinden, UI detaylarını uzun uzun anlatmaktan kaçın. Odak, algorithm mantığı, design kararları ve test sonuçları üzerinde olmalı.

Sonuç: IB Computer Science IA İçin Uygulanabilir Mini Checklist

Yazıyı bitirirken, elinde kullanabileceğin kısa bir IA checklist olsun:

• Konun, seni gerçekten ilgilendiriyor mu ve 35 saatte yapılabilir mi?
• Research question ve problem statement net, bağlamı iyi açıklıyor mu?
• Criterion A için en az 3, tercihen 3–5 ölçülebilir success criteria yazdın mı?
• Criterion B’de problem decomposition, diagramlar ve başlangıç test planı açık mı?
• Criterion C ve D’de, en güçlü algorithm ve data structure kararlarını açıkça anlattın mı?
• Criterion E’de her success criterion için ayrı ayrı değerlendirme yaptın mı?
• Test plan’ın dolu, gerçek input ve expected output ile desteklenmiş mi?
• HL isen 5 dakikalık video demo hazır mı, SL isen video kaydını düşünerek testlerini planladın mı?
• Raporun 2,000 kelime sınırının içinde, ama içerik olarak dolu mu?

Unutma, IA sadece bir not değil; aynı zamanda gelecekte portfolyo’na koyabileceğin, üniversite başvurularında gösterebileceğin somut bir Computer Science projesi. Detaylı kriter açıklamaları ve en güncel kurallar için mutlaka öğretmeninin paylaştığı resmi IB Computer Science guide ve Internal Assessment bölümünü incele, sonra bu rehberi elinin altında tutarak adım adım ilerle.