IB Computer Science dersi için yaptığın Internal Assessment (IA), toplam notunun önemli bir parçası, SL için yaklaşık %30, HL için yaklaşık %20 ağırlığa sahip ve 34 puan üzerinden değerlendiriliyor. Kısaca, gerçek bir client için çalışan bir yazılım çözümü geliştiriyorsun, ardından en fazla 2.000 kelimelik bir raporla (code hariç) bu çözümü anlatıyorsun.
IA, beş ana kısım üzerinden puanlanıyor: Criterion A (Planning), B (Solution Overview), C (Development), D (Functionality) ve E (Evaluation). Yani sadece koduna değil, planlama, tasarım, açıklama, test ve değerlendirme sürecine bakılıyor.
İyi proje örneklerine bakmak, kopyalamak için değil, seviyeyi ve beklenen scope ile complexity düzeyini anlamak için çok işe yarıyor. “Ne kadar ileri gitmem gerekiyor?”, “Bu fikir IA için fazla mı basit?” gibi sorulara daha net cevap verebiliyorsun.
Bu yazının amacı, yüksek puan almış ya da yüksek puan potansiyeli taşıyan IB Computer Science IA proje türlerini, somut ve anlaşılabilir örneklerle göstermek. Okurken, “Bu fikirleri birebir yapmalıyım” yerine “Bunu kendi hayatıma uyarlayabilirim” hissini yaşaman hedefleniyor. Çünkü iyi haber şu: Planlı gidersen, sen de gayet güçlü bir IA yazabilirsin.
Güçlü bir IA projesi, sadece “güzel kod yazdım” demek değildir; her Criterion için net, görünür kanıt sunan bir yapı kurmaktır. Aşağıdaki tablo genel resmi basitçe özetliyor:
| Criterion | Odak | Yaklaşık Puan Rolü |
|---|---|---|
| A | Planning | Client, problem, success criteria |
| B | Solution Overview | Design, UML diagram, test plan |
| C | Development | Code açıklaması, Algorithm, teknikler |
| D | Functionality | Çözümün gerçekten çalışması |
| E | Evaluation | Değerlendirme, limits, improvements |
Bu resmi aklında tutarak, iyi proje için temel yapı taşlarını basit bir dille açalım.
En yüksek puanlı IA’lerin büyük kısmında, gerçek bir client vardır; bu client bazen bir öğretmen, bazen bir aile üyesi, bazen de küçük bir işletme olur. Criterion A burada, “Gerçek bir probleme mi çözüm üretiyor?” sorusuna cevap arar.
Client ile en az bir kısa interview yapmak, ekran görüntüsü, email konuşması ya da konuşma notlarını rapora eklemek ciddi fark yaratır. Bu görüşmede, client’in yaşadığı sıkıntıyı, mevcut çözümlerin niçin yeterli olmadığını, neyi otomatikleştirmek ya da kolaylaştırmak istediğini netleştirirsin.
Sonrasında, problem definition, ölçülebilir success criteria ve mantıklı bir scope yazarsın. Örneğin: “Sistem, ayrı ayrı aylar için toplam harcamayı hesaplayabilmeli” gibi, sonradan test edilebilir maddeler. Ne kadar net ve ölçülebilir yazarsan, Criterion A puanın o kadar güçlenir.
Öğrencilerin en çok zorlandığı kısım, “Bu proje yeterince complex mi?” sorusu olur. Sadece dört butonlu bir hesap makinesi, genelde IA için fazla basit kalır; buna karşılık gerçek bir sosyal medya platformu, çok kullanıcılı tam bir e-ticaret sitesi gibi fikirler de scope açısından gereksiz derecede büyük olur.
Tatlı nokta, belirgin Algorithm ve anlamlı Data Structure kullanımına izin veren, ama tek başına 10 kişilik developer ekibi gerektirmeyen projelerdir. Örneğin:
Bu tür özellikler, Criterion C’de complexity açısından sana avantaj sağlar ve raporda açıklayabileceğin somut teknik malzeme üretir.
IA sadece backend değildir, kullanıcıyla etkileşim kuran User Interface (UI) kısmı da önemlidir. Karışık menüler, anlamsız buton isimleri, hiçbir uyarı içermeyen hata ekranları, projeyi zayıf gösterir.
Basit, anlaşılır menüler, tutarlı renk ve font kullanımı, açıklayıcı buton isimleri, net error message’lar ve input validation (örneğin boş formu kabul etmeme) gibi küçük görünen detaylar, hem Functionality hem de Evaluation bölümünü güçlendirir.
UI konusunda temel prensipleri görmek için Columbia University’nin hazırladığı usability heuristic listesini incelemek, “iyi arayüz” ile “kafa karıştıran arayüz” farkını anlamana yardım edebilir. Ayrıca, UCSD’nin UI ve UX design principles üzerine yazdığı kısa rehber, sade örneklerle tasarım kararlarını geliştirmeni sağlayabilir.
Birçok öğrenci kod tarafına odaklanıp documentation kısmını sona bırakır, bu da genelde puana mal olur. Oysa iyi IA projeleri, iyi raporlarla birlikte yürür.
Bunlar Extended Essay gibi araştırma odaklı bir yapı değildir; IA çok daha uygulamalı, ürün ve süreç odaklıdır. Yani kod ve documentation birbirini tamamlayan iki parça gibi düşünülmelidir.
Şimdi, teori yerine somut fikirler üzerinden gitmek daha kolay. Aşağıdaki proje örnekleri, 2025’te hâlâ mantıklı, uygulanabilir ve IB scope’una uygun fikirlerdir. Her biri için küçük bir senaryo, client fikri, olası teknoloji seti ve neden iyi bir IA adayı olduğu üzerine basit açıklamalar bulacaksın.
Bu fikirleri birebir kopyalamak yerine, kendi okuluna, ailene veya çevrene uyarlaman en sağlıklı yol olur.
Bu projeyi, basit bir web app ya da desktop uygulaması olarak düşünebilirsin. Kullanıcı, ülke veya bölge seçip farklı tarihlerdeki COVID-19 vaka sayılarını, ölüm sayılarını ya da toparlanan hasta sayılarını line chart veya bar chart ile görebilir.
Veriyi bir API üzerinden çekmek, Criterion C için iyi bir teknik avantaj sağlar; ancak API yönetimi seni zorluyorsa, hazır CSV dosyaları ile sınırlı bir dataset kullanmak da gayet geçerlidir. Önemli olan, veriyi içeri alıp filtrelemen, sort etmen, belki belirli tarih aralıklarına göre analiz yapman ve bunu görsel olarak sunmandır.
Bu tür bir proje, Criterion B’deki design kısmında data flow diagram, UI wireframe ve test plan için güzel malzeme üretir; Criterion C’de ise data processing ve graphical representation sayesinde güçlü complexity gösterir. Scope’u küçük tutup sadece birkaç ülke veya sınırlı tarih aralığı ile çalışmak, IA’yi çok daha yönetilebilir kılar.
Bu fikir, hem aile bütçesi hem de küçük bir işletme için son derece gerçekçi bir senaryo sunar. Client, harcamalarını kategoriye göre takip etmekte zorlanan bir ebeveyn ya da kasasını Excel ile zor yöneten küçük bir kafe sahibi olabilir.
Sistem, gelir ve giderleri kategori (yemek, ulaşım, eğitim, kira vb.) üzerinden kaydeder, ardından bu verileri aylık toplamlar, pie chart veya bar chart gibi görsellerle sunar. Veri tarafında lists ve dictionaries kullanabilir, istersen basit bir SQL database ile kalıcı kayıt tutabilirsin.
Success criteria örnekleri olarak, “kullanıcı belirli bir ay için toplam harcamasını görebilmeli”, “sistem en çok harcama yapılan ilk üç kategoriyi gösterebilmeli” gibi maddeler yazılabilir. Bu proje, hem Algorithm hem de User Interface açısından dengeli bir complexity sağlar.
Dil öğrenen bir öğrenci için tasarlanan bu proje, hem pedagojik hem de teknik açıdan doyurucu olabilir. Kullanıcı yeni kelimeleri ekler, uygulama bunları flashcard olarak gösterir ve kullanıcının verdiği cevaba göre kelimeyi “easy”, “medium” veya “hard” şeklinde etiketler.
Basitleştirilmiş bir spaced repetition algorithm kullanarak, örneğin “hard” kelimeleri daha sık, “easy” kelimeleri daha seyrek gösteren bir sistem kurabilirsin. Bu döngüyü raporda pseudocode ile anlattığında, Criterion C’de Algorithm açıklaması için çok temiz bir örnek oluşur.
Ayrıca, kullanıcı istatistikleri (kaç kelime öğrenildi, hangi kategoride zorlanıyor) gösteren küçük bir dashboard eklemek, Data Structure kullanımını ve evaluation kısmını da güçlendirir.
Burada client, genelde bir matematik öğretmeni olur ve öğrencilerin belirli konularda pratik yapmasını kolaylaştırmak ister. Sistem, seçilen zorluk seviyesine göre random math soruları üretir, öğrencinin cevaplarını kaydeder ve zaman içindeki ilerlemeyi grafik veya temel istatistiklerle gösterir.
Randomization için basit number generation kullanabilir, soruları topic veya difficulty level alanlarıyla saklayabilirsin. Skor hesaplama, doğru cevap yüzdesi, son 10 sorudaki başarı oranı gibi basit statistics hesapları da eklenebilir.
Bu senaryo, Criterion A için oldukça güçlüdür; çünkü gerçek bir öğretmenle yapılan interview, problem tanımını ve success criteria listesini çok net hale getirir. Aynı zamanda Algorithm, data storage ve UI tarafı dengeli bir complexity sunar.
Machine learning her zaman ilgi çeker, fakat IA’de scope’u küçük tutmak çok önemlidir. Spam Email Detector fikri, bu dengeyi yakalamak için güzel bir örnek sayılır. Hazır bir email dataset’i, örneğin UCI Machine Learning Repository’deki Spambase dataset, başlangıç için oldukça uygundur.
Proje, email içeriklerinden basit features çıkarmayı (belirli kelimelerin sayısı, mesaj uzunluğu gibi) ve ardından Naive Bayes gibi temel bir classification modelini kullanmayı içerebilir. Modelin arkasındaki ağır matematiğe girmek zorunda değilsin; daha çok training süreci, test split ve accuracy karşılaştırması üzerine odaklanabilirsin.
Bu tip bir proje, Criterion C’de yüksek complexity gösterebilir, çünkü data preprocessing, model training ve evaluation adımlarını açıkça anlatırsın. Aynı zamanda Criterion E’de de, modelin limits kısmını (örneğin küçük dataset, belirli dil yapıları) tartışmak için iyi bir zemin sağlar.
Film izlemeyi seven bir arkadaş grubu veya küçük bir sinema kulübü, bu proje için ideal client olabilir. Sistem, kullanıcıların daha önce izlediği filmlere verdiği puanlara göre yeni filmler önerir.
Basit bir content-based recommendation yaklaşımıyla, film türü (action, drama), yıl veya director bilgisine göre benzer filmleri skorlayabilirsin. Alternatif olarak, çok küçük bir kullanıcı grubunda user-based yaklaşım taklidi yapıp, “benzer zevke sahip kullanıcıların sevdiği filmleri önermek” fikrini sade bir Algorithm ile kurabilirsin.
Dataset’i birkaç düzine filmle sınırlı tutmak, IA için hem yeterli hem de yönetilebilir olur. Data structures, filtering ve scoring hesapları sayesinde Criterion C tarafında yeterli algorithmic complexity yakalanır.
Bu başlık altında iki benzer scope’lu fikir var. Birincisi, aile üyeleri arasında görevleri paylaştıran bir Chore Management App; ikincisi, sınavlara ve ödevlere hazırlık sürecini planlayan bir Study Planner.
Her iki projede de, kullanıcı yeni task ekler, due date girer, priority belirler ve sistem bu görevleri liste, calendar view veya simple notification sistemi ile yönetir. Client olarak, evde çocuklarına görev dağıtmak isteyen bir ebeveyn ya da sınav döneminde zamanı iyi kullanmak isteyen bir arkadaş grubunu seçebilirsin.
Bu tür projeler ilk bakışta basit görünse de, iyi düşünülmüş User Interface, mantıklı Data Structure seçimi ve kapsamlı testing ile oldukça yüksek puan verebilecek seviyeye çıkabilir. Özellikle success criteria ile test cases’i bire bir eşleştirdiğinde, Criterion D ve E bölümleri çok daha sağlam olur.
Artık bazı proje türlerini gördün; şimdi önemli olan, bunları kendi hayatına uyarlayıp sıfırdan özgün bir Internal Assessment süreci kurmak. Grade Boundary hedefin ne olursa olsun, planlı hareket ettiğinde hem kodu hem de raporu kontrol altında tutabilirsin.
Bu yazıdaki fikirler, “copy paste” için değil, pattern görmek için var. Örneğin, Personal Finance Dashboard fikrini alıp, okul kulübünün bütçe takibini yapan bir sistem haline getirebilirsin; böylece client’in kulüp başkanı olur, success criteria da kulüp masraflarına göre şekillenir.
Benzer şekilde, Math Quiz Generator fikrini sadece matematikle sınırlamaz, kimya formülleri, tarih bilgisi veya dil bilgisi üzerine soru üreten bir quiz system olarak tekrar kurgulayabilirsin. Chore Management App fikrini ise, sınıf içi görev paylaşımı ya da robotics club içindeki task management için uyarlaman mümkün.
Bu tür adaptasyonlar, hem gerçek hayata çok daha yakındır, hem de Academic Honesty kurallarına uyum açısından güvenlidir. IB, orijinal koddan çok, senin problemi anlama, tasarlama, açıklama ve değerlendirme becerine bakar; bu yüzden başkasının IA’sını kopyalamak yerine, kendi bağlamına uyan özgün bir solution geliştirmek her zaman daha akıllıca olur.
Birçok öğrenci, kodu yazdıktan sonra “raporu bir haftada yazarım” der; sonra Criterion A’dan E’ye kadar olan detayları toparlayamadığı için puan kaybeder. Aslında documentation, proje boyunca küçük adımlarla toplanırsa çok daha rahat ilerler.
En başta, client interview kayıtlarını veya notlarını saklamak, problem definition ve success criteria taslağını erken yazmak iyi bir başlangıç sağlar. Design aşamasında hızlı UML diagram, UI sketch ve basic flowchart çizmek, sonradan rapora direkt eklenebilecek materyal üretir.
Development sırasında, önemli Algorithm kararlarını kısa notlar halinde yazmak, hangi Data Structure’ı neden seçtiğini bir cümleyle bile olsa kaydetmek, Criterion C metnini yazarken sana büyük zaman kazandırır. Prototyping sürecinde aldığın screenshot’ları, testing aşamasında topladığın kanıtları da klasörleyip sakladığında, son hafta neredeyse sadece düzenleme ve açıklama yapman yeterli olur.
Testing kısmı, sadece “programı çalıştırdım, ekran görüntüsü aldım” demek değildir. Güçlü bir IA’de, farklı test case türleri görünür olur: normal cases (beklenen girişler), extreme cases (çok büyük ya da çok küçük değerler) ve invalid input (boş alan, yanlış format gibi) senaryoları.
Her test için, kullanılan input, beklenen output ve actual result bilgilerini tabloya yazmak, Criterion D’yi destekler. Üstüne, birkaç gerçek kullanıcıdan kısa user feedback almak, Evaluation bölümünü çok zenginleştirir. Örneğin, Study Planner kullanan bir arkadaşın, “Daha görsel bir calendar view olsa, haftalık planı bir bakışta görebilirdim” dediğinde, bu yorum doğrudan future improvements kısmına taşınabilir.
Evaluation bölümünde, hem success criteria’ya ne kadar ulaştığını dürüstçe tartışmak, hem de kullanıcı geri bildirimlerini kullanarak mantıklı geliştirme fikirleri önermek, puanı bariz şekilde yükseltir. Bu yaklaşım, Human-Computer Interaction bakış açısına da yakındır; merak edersen Georgia Tech’in Human-Computer Interaction I: Fundamentals and Design Principles sayfası, kullanıcı odaklı tasarım fikrini daha geniş bir çerçevede görmeni sağlayabilir.
Buradaki proje örnekleri, aslında sadece bir başlangıç noktası; asıl önemli olan, kendi hayatına, okuluna veya topluluğuna uygun, gerçek bir problem bulman ve bunu makul bir scope içinde çözmen. Dashboard, quiz system, recommendation system, ML classifier, chatbot veya planner gibi türler, yalnızca üzerinde oynayabileceğin hazır kalıplar gibi düşünülebilir.
İlk adım olarak, bu hafta içinde en az iki olası client ile kısa bir görüşme yapmayı deneyebilirsin; sorunlarını not al, her sorun için birer kaba solution idea çiz ve sonra IA için en mantıklı olanı seç. Sonrasında, planlama, design, development, testing ve evaluation adımlarını bilinçli şekilde zamanlayarak Grade Boundary hedeflerine adım adım yaklaşabilirsin.
Sabırlı ve düzenli çalıştığında, IB Computer Science IA gözünde büyüyen dev bir projeden çıkıp, kontrollü ve yönetilebilir bir yazılım projesine dönüşür. En önemlisi, “Bunu ben de yapabilirim” hissini kaybetme; iyi seçilmiş bir problem ve net bir raporla, güçlü bir IA kesinlikle ulaşılabilir.
Bir ormanın kesilmesine “evet” ya da “hayır” demek kolay görünebilir, ama IB Environmental Systems and Societies (ESS) içinde önemli olan kararın kendisi değil, neden o
Bir nehri kirleten fabrikanın bacası sadece duman mı çıkarır, yoksa görünmeyen bir fatura da mı üretir? IB ESS’de environmental economics, tam olarak bu görünmeyen faturayı
Bir nehre atılan atık, bir gecede balıkları öldürebilir, ama o atığın durması çoğu zaman aylar, hatta yıllar alır. Çünkü çevre sorunları sadece “bilim” sorusu değil,
Şehirde yürürken burnuna egzoz kokusu geliyor, ufuk çizgisi gri bir perdeyle kapanıyor, bazen de gözlerin yanıyor; bunların hepsi urban air pollution dediğimiz konunun günlük hayattaki
Şehir dediğimiz yer, sadece binalar ve yollardan ibaret değil, büyük bir canlı organizma gibi sürekli besleniyor, büyüyor, ısınıyor, kirleniyor, bazen de kendini onarmaya çalışıyor. IB
IB ESS Topic 8.1 Human populations, insan nüfusunun nasıl değiştiğini, bu değişimin nedenlerini ve çevre üzerindeki etkilerini net bir sistem mantığıyla açıklar. Nüfusu bir “depo”
Bir gün marketten eve dönüyorsun, mutfak tezgahına koyduğun paketli ürünlerin çoğu, aslında üründen çok ambalaj gibi görünüyor. Üstüne bir de dolabın arkasında unutulan yoğurt, birkaç
Evde ışığı açtığında, kışın kombiyi çalıştırdığında ya da otobüse bindiğinde aslında aynı soruyla karşılaşıyorsun, bu enerjiyi hangi kaynaktan üretiyoruz ve bunun bedelini kim ödüyor? IB
Bir musluğu açtığında akan su, markette aldığın ekmek, kışın ısınmak için yaktığın yakıt, hatta telefonunun içindeki metal parçalar; hepsi natural resources (doğal kaynaklar) denen büyük
Gökyüzüne baktığında tek bir “hava” var gibi görünür, ama aslında atmosfer kat kat bir yapı gibidir ve her katın görevi farklıdır. IB Environmental Systems and