IB Computer Science IA Evaluation Bölümünde Tam Puan Almak

IB Computer Science IA yazarken muhtemelen aklında hep kod var, algoritmalar var, belki biraz da GUI tasarımı var, değil mi? Fakat Grade Boundary çizgisini yukarı çeken şey her zaman sadece kod olmuyor, özellikle de Evaluation (Criterion E) kısmında.

IA yapısına kabaca baktığında, Problem specification, Planning, Development, Testing ve son olarak Evaluation gibi bir akış görüyorsun. Çoğu öğrenci ilk dört bölüme yoğunlaşıp, Evaluation bölümünü “kısa bir özet ve sonuç” gibi görüp geçiyor. Sonra da Internal Assessment sonucunda “Neden bu kadar düşük geldi?” diye düşünüyor.

2025 güncel kılavuzlarına göre Criterion E, sadece test sonuçlarını tekrar yazmanı istemiyor. Asıl amaç, reflection odaklı düşünmeni görmek; yani kendi product’ını, success criteria üzerinden, client geri bildirimiyle ve constraints bağlamında akıllıca sorgulaman bekleniyor. Bu yazı, seni adım adım götürüp Evaluation kısmını 6/6 (ya da seviyene göre tam puana yakın) yazabilmen için net, uygulanabilir bir yapı vermek için hazırlanmış bir rehber gibi düşünebilirsin.

IB Computer Science IA Evaluation (Criterion E) Tam Olarak Neyi Ölçüyor?

Criterion E, senin bir geliştirici olarak kendi çözümüne dışarıdan bakabilme yeteneğini ölçüyor. Examiner, sadece “program çalıştı mı” sorusuna değil, “öğrenci problem ve çözüme ne kadar bilinçli yaklaşıyor” sorusuna da cevap arıyor.

Burada odak noktası, final product’ın senin Planning kısmında belirlediğin success criteria ile ne kadar örtüştüğü. Yani Evaluation, Unit test sonuçlarını listelediğin bir Testing tekrarı değil, problem statement’ı, client ihtiyaçlarını ve aldığın tasarım kararlarını bir bütün olarak sorguladığın kısım. Kısacası, sadece ne yaptığını değil, ne kadar işe yaradığını ve nerede sınırlı kaldığını gösteriyorsun.

Criterion E kaç puan ve genel olarak ne bekleniyor?

2025 için güncel rehberlerde IB Computer Science IA Criterion E çoğu kaynakta 6 puanlık bir kriter olarak anlatılıyor, bazı yeni syllabus dokümanlarında ise 4 puanlık varyasyonlardan da söz ediliyor, fakat mantık aynı kalıyor. SL ya da HL olman beklentiyi kökten değiştirmiyor, sadece derinlik ve örnek sayısı biraz farklılaşabiliyor.

İyi yazılmış bir Evaluation, şu izlenimi bırakmalı: Öğrenci, success criteria’larını hatırlıyor, bunlara göre product’ını test etmiş, sonuçları yorumlamış, client ile etkileşime girmiş ve gelecekte yapılabilecek geliştirmeleri gerçekçi bir şekilde düşünmüş. Examiner, yazını okurken “Bu öğrenci kendi çözümünü teknik ve mantıklı bir dille eleştirebiliyor” dediği noktada, üst band puanlarına çok yaklaşmış oluyorsun.

Reflection odaklı düşünme: Sadece ürünü değil, süreci de değerlendirmek

Evaluation sadece “çalıştı mı, çalışmadı mı” kutucuklarını işaretlediğin bir rapor değil, aynı zamanda sürece baktığın küçük bir self review. Product’ın son halini değerlendirirken, aslında Development ve Testing aşamalarında aldığın kararları da yorumluyorsun.

Örneğin, belirli bir framework seçmen, farklı bir data structure kullanmaman, UI tasarımında minimalist kalman ya da sadece command-line interface tercih etmen birer “tesadüf” değil, hepsi bilinçli ya da yarı bilinçli trade-off kararları. Evaluation, bu tür seçimlerin sonuçlarını tarttığın, performansa, usability’ye, maintainability’ye olan etkilerini anlattığın yer olmalı. Böyle yazdığında, examiner senin sadece kod yazmadığını, problem çözen biri gibi düşündüğünü görür.

Planlama Aşamasındaki Success Criteria’yı Evaluation Bölümünde Nasıl Kullanmalısın?

Planning kısmında yazdığın success criteria listen, Criterion E için altın değerinde. Birçok öğrenci bu listeyi yazıyor, sonra Evaluation bölümünde tamamen unutuyor. Oysa tam puana oynamak istiyorsan, success criteria senin Evaluation iskeletin olmalı.

Pratik olarak şöyle düşünebilirsin: Planning’te oluşturduğun success criteria tablosu, Evaluation’da tek tek geri döneceğin checklist görevi görüyor. Examiner, bu köprüyü gördüğünde, IA’ni bütünsel bir çalışma olarak algılıyor; Problem specification, Planning, Testing ve Evaluation arasında net bir tutarlılık hissediyor.

Her bir success criterion için net ve dürüst bir değerlendirme yap

Evaluation yazarken, success criteria listesini önüne alıp her birini ayrı ayrı değerlendirmek en sağlam yöntem. Her criterion için önce kısa bir yargı verip, ardından bir iki cümleyle bunu destekleyebilirsin.

Örneğin şu kalıplar işini çok kolaylaştırır:

• “This success criterion was fully achieved because …”
• “This success criterion was partially achieved due to …”
• “This success criterion was not achieved, mainly because …”

Burada önemli nokta, bu ifadeleri kuru bir label olarak bırakmamak. “Fully achieved” diyorsan, hangi test case’lerin geçtiğini, client’ın ne söylediğini veya gözlemlediğin kullanım senaryosunu kısaca açıklamalısın. “Partially achieved” diyorsan, hangi kısım çalışıyor, hangi kısım beklediğin kadar iyi değil, bunu netleştirmen gerekiyor. Examiner, senin kendi işini eleştirebildiğini görmeyi seviyor.

Test sonuçlarını Evaluation kısmına akıllıca bağlamak

Testing bölümünde muhtemelen test plan, test cases ve screen recording gibi kanıtlar sundun. Evaluation’da bu tabloyu tekrar yapıştırman gerekmiyor, hatta yapmaman daha iyi olur, çünkü burada amaç, testlerin ne söylediğini yorumlamak.

Örneğin, “All test cases passed” gibi genel bir ifade yerine, şu tarz bir cümle daha puan getirir: “All boundary-value test cases for the input validation passed, which shows that the product reliably prevents invalid data from being stored in the database.” Aynı şekilde, başarısız testler için de, neden başarısız olduklarını ve gerçek kullanımda ne kadar problem çıkarabileceklerini anlatman gerekiyor.

Testing ile Evaluation arasındaki köprüyü kurmanın iyi yolu, en kritik 3–5 test sonucunu seçip, bunların product’ın problem çözme gücüne ne anlattığını açıklamak. Böylece examiner, sadece “test yaptım” demediğini, test verisini anlamlı şekilde yorumladığını görür.

Güçlü Yönler, Zayıf Yönler ve Sınırlamalar Üzerinden Maksimum Puan Toplamak

Evaluation bölümünün kalbi, strengths, weaknesses ve constraints kısmı. Burada sihirli nokta, ürünü göklere çıkarırken aynı zamanda eksiklerini teknik bir dille kabul etmek. Aşırı “her şey mükemmel” tonu, genellikle yüzeysel görünür; aşırı öz-eleştiri ise product’ın değerini küçültür. Denge kurduğunda, hem olgunluk hem teknik farkındalık göstermiş olursun.

Strengths: Ürünün gerçekten iyi yaptığı işleri açık ve somut anlat

“Everything works perfectly” tarzı cümleler examiner için hiçbir şey ifade etmiyor. Güçlü yönleri yazarken, mutlaka success criteria ve client ihtiyaçları ile bağlantı kurmalısın. Mesela:

• Performance: “The product responds within one second for all typical user actions, which matches the client’s need for quick daily data entry.”
• Usability: “The navigation bar groups the three most frequent actions on a single screen, which reduced the client’s training time to less than ten minutes.”
• Data validation: “Invalid dates and negative quantities are rejected with clear error messages, so the client no longer needs to correct data manually.”
• Error handling: “If the database connection fails, the system shows a warning and logs the error, which prevents silent data loss.”

Her strength için küçük bir kanıt eklemek, mesela tek bir test sonucu, kısa bir client feedback alıntısı veya kendi gözlemin, Criterion E puanlarını belirgin şekilde yukarı çeker.

Weaknesses ve limitations: Hataları saklamak yerine, olgun bir şekilde sahiplen

Weaknesses ve limitations yazarken, “Bunu yazarsam puan kaybederim” kaygısı çok yaygın, ama gerçekte tam tersi oluyor. Examiner, gerçekçi zayıflıkları fark ettiğini ve bunların impact’ini yorumlayabildiğini görünce seni daha olgun bir developer olarak değerlendiriyor.

Örneğin:

• Time constraint: “Due to time constraints, the reporting feature only exports to CSV, which limits usability for the client who usually works in PDF.”
• Lack of experience with framework: “My limited experience with the GUI framework caused a simple layout, which affects the visual appeal of the product.”
• Limited hardware resources: “The client’s old hardware required me to avoid heavy animations, so the interface looks less modern but responds more quickly.”

Her weakness için iki kısa parça yazman iyi olur: impact ve possible improvement. Yani hem “Bu sorun product’ı nasıl etkiliyor?” sorusuna hem de “İleride bu nasıl geliştirilebilir?” sorusuna kısaca değinmelisin.

Constraints: Zaman, teknoloji ve bilgi sınırlarının projeye etkisini açıklamak

Constraints, aslında bahaneden çok, ortam şartlarının teknik analizi. Zaman kısıtı, okulun network altyapısı, seçtiğin programming language, kullandığın library’lerin limitleri gibi unsurlar bu başlık altında toplanabilir.

Örneğin, Java seçtiğin için mobile-native bir uygulama yapmak yerine desktop solution yazmış olabilirsin. Ya da okulun internet güvenlik politikaları yüzünden cloud database kullanamamış olabilirsin. These constraints altında yaptığın mantıklı tercihleri göstermek, senin tasarım kararlarının arkasında rasyonel bir düşünce olduğunu gösterir.

Evaluation’da constraints yazarken, “Bu yüzden yapamadım” tonundan çok, “Bu koşullar altında en mantıklı yol buydu” tonunu yakalamaya çalışmak işe yarar. Böylece, problem çözen biri gibi görünürsün.

Client Feedback ve Gelecek Geliştirmelerle Rubrikteki Son Puanları Kapatmak

Criterion E içinde client feedback ve future improvements kısmı genellikle puan kazandıran ama öğrencilerin hafife aldığı bir alan. IB, Computer Science IA’yı gerçek bir client için yazılmış gerçek bir solution olarak görmek istiyor; bu da client ile etkileşim kurmanı ve bunu yazında göstermen gerektiği anlamına geliyor.

Client feedback: Sadece “client was happy” yazmak neden yetmez?

“Client was happy with the product” gibi tek cümlelik ifadeler, Criterion E açısından oldukça zayıf. Examiner, gerçekten client ile konuştun mu yoksa bunu uydurdun mu, anlamak ister. Bu yüzden kısa ama net feedback kanıtları işini çok güçlendirir.

Örneğin:

• “During a short interview, the client said, ‘I can now complete the weekly report in about 10 minutes instead of 40.’”
• “In a questionnaire with five questions, the client rated the usability of the interface as 4 out of 5.”

Feedback’in içeriğinde UX, learning curve, speed, accuracy gibi alanlara değinmek çok iyi görünür. Ayrıca, feedback toplama yöntemine kısaca değinmek de faydalı: interview, questionnaire, observation gibi terimleri bir cümle ile geçirmek yeterli olur.

Realistic improvements ve future extensions nasıl yazılmalı?

Future improvements kısmı, öğrencilerin “add AI”, “create mobile app”, “add cloud support” gibi çok genel ve çoğu zaman gerçekçi olmayan maddeler yazdığı yer. Examiner, burayı hayal listesi gibi değil, mevcut codebase ve constraints göz önünde bulundurularak oluşturulmuş uygulanabilir geliştirme planı gibi görmek ister.

Daha sağlam örnekler şöyle olabilir:

• Security: “Implementing hashed passwords instead of plain-text storage would protect the client’s user accounts with minimal changes to the current database schema.”
• Scalability: “Refactoring the data access layer into separate modules would make it easier to support multiple branches in the future.”
• UI/UX: “Adding a search bar to the main list view would reduce scrolling time for the client, and it only requires a small change in the filtering function.”
• Data validation: “Introducing server-side validation in addition to client-side checks would prevent malformed data from being saved if JavaScript is disabled.”

Her improvement için kısaca “neden önemli” ve “nasıl uygulanabilir” hattını göstermeye çalıştığında, Evaluation kısmın, sanki küçük bir proje yol haritası gibi görünür. Bu da reflection seviyeni çok net ortaya koyar.

Evaluation Bölümünü Yazarken Sık Yapılan Hatalar ve Tam Puan İçin Mini Kontrol Listesi

Son bölüme geldiğinde, artık Criterion E için neler yazman gerektiği kafanda şekillenmiş olmalı. Şimdi, sık yapılan hatalara ve bunlardan kaçınmak için kullanabileceğin küçük bir checklist’e bakmak faydalı olur.

Sık yapılan hatalar: Test bölümünü kopyalamak, genellemeler yapmak, kanıt sunmamak

En yaygın hatalardan biri, Testing bölümündeki tabloyu veya açıklamaları neredeyse aynen Evaluation’a taşımak. Bu durumda examiner, yeni bir analiz görmediği için puanları kıstığı gibi, reflection seviyesi de düşük görünür. Bir başka sık hata, success criteria’ya hiç geri dönmeden sadece “Program çalıştı, client mutlu oldu” tarzı genel ifadeler kullanmak; bu da rubrikte açıkça beklenen “evaluation against success criteria” kısmını boşa çıkarır.

Bazı öğrenciler sadece olumlu yanları yazıyor, weaknesses, limitations ve constraints’i yok sayıyor. Bu tür tek taraflı anlatımlar, yüzeysel bulunuyor. Bir diğer problem de client feedback’i tek cümleyle geçiştirmek ve hiçbir alıntı, hiçbir küçük veri sunmamak. Son olarak, Evaluation bölümünü aşırı kısa tutmak, örneğin sadece 2–3 cümleyle bitirmek, reflection derinliğini çok zayıflatıyor ve üst band puanları neredeyse imkansız hale getiriyor.

6/6 için hızlı kontrol listesi: Evaluation bölümünü teslim etmeden önce neye bakmalısın?

Evaluation taslağını bitirdiğinde, kendine şu soruları sorman iyi olur:

• Planning kısmında yazdığım her success criterion için açık bir değerlendirme yaptım mı?
• Test results ile yazdığım yorumlar arasında net bir bağlantı kurdum mu?
• En az iki strength ve en az iki weakness/limitation’ı somut örneklerle anlattım mı?
• Zaman, teknoloji veya bilgi kaynaklı en az bir iki constraint’ten ve bunların etkisinden bahsettim mi?
• Client feedback için, gerçek bir interview, questionnaire veya observation’dan en az bir somut kanıt yazdım mı?
• Future improvements kısmında, mevcut codebase ile uyumlu, gerçekten uygulanabilir geliştirme fikirleri sundum mu?
• Sadece “ne olduğunu” değil, her önemli noktanın “neden önemli” olduğunu da kısaca açıkladım mı?

Bu sorulara dürüstçe “evet” diyebiliyorsan, Criterion E bölümün muhtemelen üst seviye puan bandına oldukça yakın demektir.

Sonuç: Evaluation Bölümünü Stratejik Bir Fırsata Dönüştür

Evaluation, zorunlu bir “son söz” parçasından çok, tüm IA’ni parlatan stratejik bir fırsat gibi görüldüğünde anlam kazanıyor. Zaten iyi bir Planning ve Testing yaptıysan, success criteria’ya geri dönerek, strengths ve limitations dengesini kurarak, gerçek client feedback kullanarak ve gerçekçi future improvements yazarak Criterion E’de tam puana oldukça yaklaşabilirsin.

Unutmamak gerekiyor ki IB, sadece kod yazan değil, kendi çözümünü eleştirebilen ve geliştirebilen bir öğrenci profili görmek istiyor; bu profilin en net göründüğü yer de Evaluation. Yazını tamamladıktan sonra, taslağını birkaç kez yüksek sesle okuyup, gerekirse öğretmeninden veya güvendiğin bir arkadaştan geri bildirim istemen büyük fark yaratır. Kısa bir reflection bölümü bile, doğru kurgulandığında, tüm Internal Assessment çalışmanı bir üst seviyeye taşıyabilir.