# Bilişsel Sistemler Mühendisliği: İnsan Faktörleri, Durumsal Farkındalık ve Karar Desteği > Bilişsel görev analizi, bilişsel iş analizi, doğal çalışma ortamında karar verme, durumsal farkındalık, ekolojik arayüz tasarımı ve dayanıklılık mühendisliğini karmaşık insan-makine sistemleri bağlamında birleştiren ders notu. - Author: Muhammet Ali Köker - Language: tr - Canonical: https://alikoker.com.tr/bilissel-sistemler-muhendisligi - Translation: https://alikoker.com.tr/en/cognitive-systems-engineering - Published: 2026-09-23T18:17:10+03:00 - Modified: 2026-09-23T18:17:10+03:00 - Verified: 2026-09-23T18:17:10+03:00 - Type: article Bilişsel sistemler mühendisliği, insanı teknik sistemin dışında kalan bir kullanıcı olarak değil; bilgi, otomasyon, prosedür, ekip, zaman baskısı ve fiziksel çevreyle birlikte çalışan sosyoteknik sistemin etkin bir bileşeni olarak ele alır. Bu bakış açısında temel soru yalnızca “arayüz kullanılabilir mi?” değildir. Daha önemli sorular; çalışanın hangi ipuçlarını kullandığı, neyi anlamaya çalıştığı, belirsizliği nasıl yönettiği, hangi kararları hangi zaman baskısı altında verdiği, otomasyonun hangi bilişsel işi devraldığı ve sistem beklenmeyen bir koşula girdiğinde insan ile teknik bileşenlerin birlikte nasıl uyum sağladığıdır. Bu ders, bilişsel görev analizi, bilişsel iş analizi, doğal çalışma ortamında karar verme, durumsal farkındalık, ekolojik arayüz tasarımı ve dayanıklılık mühendisliğini tek bir mühendislik omurgasında birleştirir. Amaç insan davranışını soyut psikoloji kavramlarıyla açıklamak değil; karmaşık ve kritik sistemlerin gereksinim, mimari, arayüz, otomasyon, doğrulama ve işletim kararlarına dönüştürülebilen analiz yöntemleri geliştirmektir. İnsan-makine etkileşiminin görsel ve etkileşimsel boyutu [Web Uygulamalarında UI/UX Mühendisliği](/web-uygulamalarinda-ui-ux-muhendisligi) dersinde daha ayrıntılı ele alınır. Sistem yaşam döngüsü, gereksinim, tasarım ve kalite bağlantısı için [Yazılım Mühendisliği](/yazilim-muhendisligi-surec-gereksinim-tasarim-kalite), doğrulama ve geçerleme için [Yazılım Test Mühendisliği](/yazilim-test-muhendisligi-uygulamali-dogrulama-gecerleme), güvenlik-kritik insan-makine bağlamı için [Aviyonik Sistemler ve İnsansız Hava Araçları](/aviyonik-sistemler-ve-insansiz-hava-araclari), üretken yapay zekâda kanıt ve türetilmiş çıktı ayrımı için [Bilgi Erişimi Destekli Üretim](/rag) tamamlayıcıdır. ## Ünite 1: Bilişsel Sistemler Mühendisliğinin Kapsamı ### Kullanıcıdan ortak bilişsel sisteme Klasik etkileşim tasarımında kullanıcı çoğu zaman sistemden hizmet alan taraf olarak modellenir. Kritik veya yüksek tempolu işlerde bu model eksik kalır. Operatör, yazılım, sensörler, veri tabanı, otomasyon, prosedürler ve ekip üyeleri aynı amaca yönelen **ortak bilişsel sistem** oluşturabilir. Bilginin bir bölümünü makine toplar, bir bölümünü insan yorumlar; bazı kararlar otomatik kurallarla, bazıları uzman muhakemesiyle verilir. ```text çevre / olaylar ↓ sensörler ve veri kaynakları ↓ teknik sistem ── otomasyon ↓ │ bilgi temsili │ ↓ │ insan / ekip ←───────┘ ↓ karar ve eylem ↓ çevrede yeni durum ``` Bu döngüde başarım, yalnız yazılımın doğru hesap yapmasına bağlı değildir. Doğru bilginin doğru zamanda görünür olması, güncelliğini yitirmiş (stale) verinin anlaşılması, alarm yoğunluğunun yönetilmesi, operatörün sistem durumunu doğru yorumlaması ve otomasyonun sınırlarının bilinmesi de sistem davranışının parçasıdır. ### İnsan hatası tek başına açıklama değildir Bir olayın “operatör hatası” olarak etiketlenmesi çoğu kez neden analizi için başlangıç değil, sonlandırıcı bir etikettir. Bilişsel sistemler mühendisliği; hangi bilginin erişilebilir olduğunu, hangi hedeflerin çatıştığını, zaman ve kaynak kısıtlarını, otomasyonun davranışını, prosedürün gerçek iş akışıyla uyumunu ve karar anındaki belirsizliği inceler. Bu yaklaşım insanın yanılmaz olduğunu varsaymaz. Tam tersine, hata olasılığını sistem bağlamı içinde açıklamaya çalışır. Aynı kişi farklı bilgi düzeni, iş yükü veya zaman baskısında farklı davranabilir. Bu nedenle güvenilirlik, yalnız eğitim veya disiplin sorunu değil, sistem tasarımı problemidir. ### Karmaşıklık ile zorluk ayrımı Bir sistem teknik olarak karmaşık olabilir fakat operatör için anlaşılır davranabilir. Tersi de mümkündür: teknik olarak basit bir iş, dağınık bilgi kaynakları ve belirsiz sorumluluklarla bilişsel olarak zorlaşabilir. Bilişsel mühendislik, bileşen sayısını değil, çalışanın hedefe ulaşmak için kurmak zorunda olduğu zihinsel modeli ve koordinasyon yükünü inceler. ## Ünite 2: Karmaşık İşte İnsan Bilişi ve Uzmanlık ### Dikkat sınırlıdır Operasyonel sistemler aynı anda çok sayıda sinyal üretebilir. İnsan dikkatinin sınırlı olması, arayüzde görünen her bilginin fiilen algılanacağı anlamına gelmediğini gösterir. Kritik bilgi görsel olarak mevcut olsa bile yanlış bölgede, yanlış zamanda veya yüksek gürültü içinde kalabilir. Bu nedenle bilgi görünürlüğü ile bilgi edinimi farklıdır: ```text gösterildi ≠ fark edildi fark edildi ≠ doğru yorumlandı yorumlandı ≠ doğru öngörü üretildi öngörüldü ≠ uygun eylem seçildi ``` ### Çalışma belleği ve dışsallaştırma Çalışma belleğinin sınırlı kapasitesi, uzun işlem zincirlerini zihinde tutmayı kırılgan hale getirir. İyi tasarlanmış sistemler ara durumu dışsallaştırır: seçili nesneyi, önceki adımı, zaman damgasını, veri kaynağını, belirsizliği ve işlem sonucunu görünür tutar. Böylece operatör bilişsel kapasitesini arayüz durumunu hatırlamaya değil, probleme ayırabilir. ### Zihinsel modeller Operatör yalnız değerleri okumaz; sistemin nasıl çalıştığına ilişkin bir **zihinsel model** kurar. Bir metriğin yükselmesi, başka bir bileşenin gecikmesi veya belirli bir alarm dizisi bu model içinde anlam kazanır. Arayüz yalnız yüzey değerlerini gösteriyor, fakat sistemdeki nedensel veya işlevsel ilişkileri görünür kılmıyorsa kullanıcı ezberlenmiş prosedürlere aşırı bağımlı hale gelebilir. ### Uzmanlık ve örüntü tanıma Uzman ile acemi arasındaki fark yalnız daha çok bilgi bilmek değildir. Uzmanlar çoğu zaman anlamlı ipuçlarını daha hızlı seçer, olayları daha iyi kümeler, tipik olmayan örüntüleri daha erken fark eder ve olası sonuçları daha etkili canlandırır. Bu örtük bilgi klasik gereksinim görüşmesinde kolayca ortaya çıkmaz; çünkü uzman yaptığı ayrımı günlük işinin doğal parçası olarak görür. ## Ünite 3: Bilişsel Görev Analizi **Bilişsel Görev Analizi (Cognitive Task Analysis, CTA)**, bir işi yalnız gözlenebilir adımlara bölmek yerine, başarılı performans için gerekli algılama, bilgi, karar, muhakeme ve problem çözme süreçlerini ortaya çıkarmaya çalışır. ### Geleneksel görev analizi ile fark Klasik görev analizi şu akışı verebilir: ```text kaydı aç → alanları kontrol et → karşılaştır → karar ver → sonucu kaydet ``` CTA ise özellikle “karşılaştır” ve “karar ver” adımlarının içinde ne olduğunu araştırır: - Hangi ipuçları önemlidir? - Hangi ipucu yanıltıcı olabilir? - Uzman hangi anormalliği diğerlerinden önce fark eder? - Zor vakada hangi ek bilgi aranır? - Hangi durumda prosedürden sapmak gerekir? - Hangi belirsizlik kabul edilebilir, hangisi değildir? - Karar verildikten sonra hangi işaretler yeniden kontrol edilir? ### CTA'nın çıktısı CTA'nın amacı bir psikolojik profil üretmek değildir. Mühendislik açısından yararlı çıktı; bilişsel gereksinim, kritik ipucu, karar noktası, hata tuzağı, bilgi gereksinimi ve eğitim gereksinimi gibi tasarıma dönüştürülebilir bulgulardır. Örneğin “uzman kullanıcı deneyimlidir” düşük değerli bir bulgudur. Buna karşılık “uzman, iki veri kaynağındaki zaman uyumsuzluğunu önce zaman damgası ve kaynak gecikmesi üzerinden kontrol ediyor; bu bilgi tek ekranda görünmediğinde iki ayrı görünüm arasında geçiş yapıyor” doğrudan tasarım girdisidir. ### Hazırlık ve çerçeveleme CTA çalışması başlamadan önce amaç daraltılmalıdır. Tüm işi açıklamaya çalışmak yerine bilişsel olarak zor, hata maliyeti yüksek veya uzmanlık farkının belirgin olduğu bölümler seçilir. Katılımcı seçimi de önemlidir: yalnız en deneyimli çalışanlar değil, orta düzey ve yeni çalışanlar arasındaki farklar da hangi bilginin deneyimle oluştuğunu gösterir. ### Kavram haritaları Kavram haritası, uzmanın alan bilgisindeki ilişki yapısını dışsallaştırabilir. Ancak amaç güzel bir şema çizmek değil, kavramların hangi koşullarda bağlandığını ve hangi ayrımların operasyonel önem taşıdığını bulmaktır. ### Olay tabanlı görüşme Genel “işinizi nasıl yapıyorsunuz?” sorusu çoğu zaman idealize edilmiş prosedürü üretir. Zor veya sıra dışı gerçek olayların ayrıntılı yeniden kurulması daha yüksek bilişsel verim sağlayabilir. Olayın zaman çizelgesi çıkarılır; karar noktaları, fark edilen ipuçları, beklenen sonuçlar ve alternatif eylemler sorgulanır. ### Kritik Karar Yöntemi **Critical Decision Method (CDM)**, zorlu olayları ayrıntılı biçimde incelemek için kullanılan olay tabanlı CTA yöntemlerinden biridir. Mühendislik kullanımında yöntem; olayın kronolojisini çıkarmak, kritik karar noktalarını belirlemek ve her noktada ipuçları, amaçlar, beklentiler, seçenekler ve deneyim etkisini araştırmak için kullanılabilir. CDM'yi sıradan bir kullanıcı görüşmesine dönüştürmemek gerekir. “Neden bunu yaptınız?” sorusu tek başına yetersizdir. Daha üretken sorular şunlardır: - O anda ilk fark ettiğiniz değişiklik neydi? - Bu durumun olağandan farklı olduğunu nasıl anladınız? - Hangi bilgiyi görmeseydiniz kararınız değişebilirdi? - Daha az deneyimli biri burada neyi kaçırabilirdi? - Başka hangi eylemi düşündünüz? - Sonucun doğru gittiğini hangi işaretten anladınız? ### Knowledge Audit **Knowledge Audit**, uzmanlık gerektiren bilişsel boyutları sistematik biçimde aramaya yardım eder. Örüntü tanıma, anormallik sezme, geçmiş vakalarla benzerlik kurma, zihinsel kestirme, fırsat fark etme veya gelecek durumu öngörme gibi boyutlar farklı işlerde farklı ağırlık taşır. CTA'nın en önemli mühendislik sonucu, gereksinim dokümanında daha önce bulunmayan bilişsel gereksinimleri görünür hale getirmesidir. ## Ünite 4: Bilişsel İş Analizi ### CTA ile CWA aynı analiz değildir CTA ve CWA çoğu projede birbirini tamamlar, fakat aynı soruya cevap vermez. CTA belirli bir işte uzman performansının bilişsel içeriğini açığa çıkarmaya çalışırken CWA, işin kişiden ve mevcut arayüzden daha kalıcı olan kısıtlarını modeller. Bu ayrım özellikle mevcut uygulamanın yeniden tasarlandığı projelerde önemlidir. Yalnız CTA ile ilerlemek, bugünkü uzmanların bugünkü aracın sınırlarına uyum sağlamak için geliştirdiği çalışma biçimini istemeden yeni tasarıma dondurabilir. Yalnız CWA ile ilerlemek ise gerçek kullanıcıların kritik ipuçlarını, kestirmelerini ve koordinasyon sorunlarını yeterince görünür kılmayabilir. Pratikte iki analiz arasında şu ilişki kurulabilir: ```text CTA → uzman bugün zor işi nasıl başarıyor? CWA → iş alanında hangi amaçlar ve kısıtlar kalıcı? ↓ ortak tasarım gereksinimleri ``` Bu nedenle yöntem seçimi “hangi teknik daha gelişmiş?” sorusuyla değil, hangi belirsizliğin giderilmesi gerektiğiyle yapılmalıdır. ### Kısıt temelli düşünmenin tasarım değeri Prosedürler belirli bir çalışma yolunu tarif eder. Kısıtlar ise kabul edilebilir davranış uzayının sınırlarını tarif eder. Beklenmeyen koşullarda önceden yazılmış prosedür bulunmayabilir; ancak fiziksel, işlevsel, güvenlik veya organizasyonel kısıtlar geçerliliğini koruyabilir. CWA'nın tasarım açısından güçlü yönü, kullanıcıya yalnız “sonraki adımı” söylemek yerine bu sınırları anlayabileceği temsil biçimleri üretmeye çalışmasıdır. Bir sistemde örneğin kapasite sınırı, minimum veri tazeliği, görev ayrılığı, yetki eşiği veya kaynak bağımlılığı varsa bunlar yalnız arka uç doğrulaması olarak saklanmamalıdır. Operatörün kararını etkiliyorlarsa uygun soyutlama düzeyinde görünür hale getirilmeleri gerekir. **Bilişsel İş Analizi (Cognitive Work Analysis, CWA)**, belirli bir kullanıcının mevcut prosedürü nasıl uyguladığından daha genel bir soruya odaklanır: İş alanında hangi amaçlar, işlevler, kısıtlar ve olanaklar vardır ve sistem farklı koşullarda hangi davranışlara izin vermelidir? Bu nedenle CWA özellikle beklenmeyen durumların önemli olduğu karmaşık sosyoteknik sistemlerde değerlidir. Mevcut prosedürü birebir otomatikleştirmek yerine, değişmeyen iş kısıtlarını ve olası çalışma stratejilerini görünür kılmayı amaçlar. ### Beş analiz boyutu CWA genellikle beş tamamlayıcı boyutla ele alınır: 1. **İş alanı analizi (Work Domain Analysis)** 2. **Kontrol görevi analizi (Control Task Analysis)** 3. **Strateji analizi (Strategies Analysis)** 4. **Sosyal örgütlenme ve iş birliği analizi (Social Organization and Cooperation Analysis)** 5. **Çalışan yetkinlikleri analizi (Worker Competencies Analysis)** Bu boyutlar doğrusal bir yazılım geliştirme yaşam döngüsü değildir. Aynı sistemi farklı kısıt düzeylerinden inceleyen modellerdir. ### Neden görev listesinden daha güçlü olabilir? Görev listesi bugünkü prosedürü yakalar. Ancak prosedür teknoloji, mevzuat veya organizasyon değişince eskimeye başlayabilir. İş alanı kısıtları daha kalıcı olabilir. Örneğin bir kontrol sisteminde enerjinin korunumu, kapasite sınırı, güvenli çalışma aralığı veya yetki ayrımı; belirli ekran düzeninden daha temel tasarım gerçekleridir. ## Ünite 5: İş Alanı Analizi ve Soyutlama Hiyerarşisi ### Soyutlama ile ayrıştırma farklı eksenlerdir Soyutlama hiyerarşisi “neden–ne–nasıl” ilişkisini açıklarken, sistemin hangi bölümünden söz edildiği ayrı bir ayrıştırma eksenidir. Aynı işlevsel amaç tüm sistem düzeyinde ele alınabileceği gibi bir alt sistem veya tek bileşen düzeyinde de incelenebilir. Bu iki ekseni karıştırmamak, büyük sistemlerde tek bir dev şema üretme eğilimini azaltır. ```text ayrıştırma sistem → alt sistem → bileşen soyutlama amaç ↓ değerler işlevler süreçler fiziksel kaynaklar ``` Bu yapı bir envanter değildir. Her hücreyi doldurmak zorunlu olmadığı gibi, modelin değeri kutu sayısından değil seviyeler arasındaki araç–amaç bağlantılarının tasarım kararlarını açıklayabilmesinden gelir. ### Modelin doğrulanması İş alanı modeli yalnız analistin masa başında oluşturduğu kavramsal şema olarak bırakılmamalıdır. Alan uzmanlarıyla şu sorular üzerinden sınanabilir: Üst düzey amaçlardan biri çıkarıldığında alt işlevlerin gerekçesi hâlâ açıklanabiliyor mu? Bir fiziksel kaynak kaybolduğunda hangi işlevlerin etkileneceği modelden izlenebiliyor mu? Aynı amaca ulaşan alternatif yollar görünür mü? Normal çalışma ile bozulmuş çalışma arasındaki fark model içinde ifade edilebiliyor mu? Model bu sorulara cevap veremiyorsa daha fazla ayrıntı eklemekten önce yanlış soyutlama veya eksik ilişki olasılığı araştırılmalıdır. ### İş alanı analizi İş alanı analizi, sistemin amaçlarını, değerlerini, işlevlerini, fiziksel süreçlerini ve kaynaklarını birbirine bağlar. Amaç prosedür yazmak değil, sistemin **neden var olduğunu**, **hangi ölçütlerle başarılı sayıldığını**, **hangi işlevlerle çalıştığını** ve **hangi fiziksel/teknik kaynaklara dayandığını** modellemektir. ### Soyutlama hiyerarşisi Yaygın temsil biçimlerinden biri **soyutlama hiyerarşisi (abstraction hierarchy)** yaklaşımıdır. Alanın niteliğine göre adlar değişebilse de tipik düşünce şudur: ```text işlevsel amaçlar ↓ değerler ve öncelik ölçütleri ↓ amaçtan bağımsız işlevler ↓ nesneye bağlı süreçler / işlevler ↓ fiziksel nesneler ve kaynaklar ``` Üst katman “neden?”, alt katman “nasıl?” sorusuna yaklaşır. Bir operatör belirli sensör değerini yalnız fiziksel sayı olarak değil, daha üst düzey işlev ve amaçlarla ilişkili olarak değerlendirebilir. ### Araç-amaç bağlantıları Hiyerarşide dikey ilişki, bir alt düzey öğesinin üst düzey amacı nasıl desteklediğini ve üst düzey amacın hangi alt araçlarla gerçekleştirilebildiğini gösterir. Bu ilişki, arayüz tasarımında yalnız değerleri değil işlevsel bağı görünür kılmak için önemlidir. ### Örnek: genel bir veri işleme hizmeti ```text Amaç Güvenilir ve zamanında sonuç üretmek ↓ Ölçütler Doğruluk / gecikme / kapasite / izlenebilirlik ↓ İşlevler Kabul / doğrulama / işleme / saklama / sunma ↓ Teknik süreçler Kuyruk / çıkarım / veritabanı / önbellek / ağ ↓ Kaynaklar Sunucular / depolama / bağlantılar / süreçler ``` Bu görünüm, “CPU %80” değerini tek başına değerlendirmek yerine yük, kuyruk, işleme kapasitesi ve hizmet amacıyla bağlamaya izin verir. ## Ünite 6: Kontrol Görevleri, Karar Merdiveni ve Stratejiler ### Karar merdiveni bir kullanıcı akış şeması değildir Karar merdiveni, bilişsel etkinliği sabit bir ekran akışına dönüştürmek için kullanılmamalıdır. Deneyimli çalışan her olayda tüm basamakları tek tek geçmez. Tanıdık bir durumda gözlenen ipucu doğrudan bilinen bir eylem kuralını tetikleyebilir; yeni veya belirsiz durumda ise hedef belirleme, seçenek üretme ve değerlendirme gibi daha fazla bilişsel etkinlik gerekebilir. Tasarımın amacı insanı merdivenin her basamağından zorla geçirmek değil, gerekli olduğunda atlanan bilişsel bağlantıyı destekleyecek bilgiyi erişilebilir tutmaktır. ### Bilgi gereksiniminden arayüz gereksinimine Bir karar noktasında “kullanıcı durumu anlayabilmelidir” demek doğrulanabilir değildir. Bunun yerine hangi değişkenlerin, ilişkilerin ve zaman ufkunun gerekli olduğu yazılabilir. Örneğin bir kaynak baskısını değerlendirmek için yalnız anlık kullanım değil; eğilim, kapasite sınırı, kuyruk büyüme hızı ve son yapılandırma değişikliği gerekebilir. Böylece bilişsel analiz soyut bir insan faktörleri raporundan ölçülebilir sistem gereksinimine dönüşür. ### Strateji değişimi ve maliyet Aynı hedef için hızlı fakat yaklaşık bir strateji ile yavaş fakat daha güvenilir bir strateji bulunabilir. Strateji seçimi zaman baskısı, veri kalitesi, iş yükü ve karar maliyetine göre değişebilir. Sistem yalnız tek “doğru” yolu desteklerse gerçek çalışma sırasında kullanıcılar arayüz dışı notlar, paralel araçlar veya kestirmeler geliştirebilir. Bu davranış her zaman kötü uygulama değildir; bazen tasarımın strateji çeşitliliğini yeterince desteklemediğinin işaretidir. ### Kontrol görevi analizi İş alanı “hangi kısıtlar içinde çalışıyoruz?” sorusunu açıklarken, kontrol görevi analizi belirli durum sınıflarında hangi karar ve kontrol etkinliklerinin gerektiğini inceler. Normal işletim, sıra dışı yük, veri kaybı, bileşen arızası veya belirsiz durum farklı bilgi gereksinimleri doğurabilir. ### Karar merdiveni **Decision ladder** yaklaşımı, algıdan eyleme giden bilişsel aşamaları ve bu aşamalar arasındaki olası kısa yolları modellemek için kullanılabilir. Deneyimli kullanıcı her durumda bütün aşamaları tek tek yürütmez; tanıdığı örüntüde daha doğrudan bir kural veya eyleme geçebilir. Yeni veya alışılmadık durumda ise daha analitik bir yol izleyebilir. ```text olayı fark et ↓ bilgiyi tanımla ↓ durumu yorumla ↓ amaç / hedef belirle ↓ seçenek üret ↓ prosedür / eylem seç ↓ uygula ``` Bu modelin değeri insan davranışını mekanik sıraya zorlamak değildir; hangi aşamada hangi bilginin gerektiğini ve arayüzün nerede bilişsel köprü kurması gerektiğini göstermektir. ### Strateji analizi Aynı hedefe birden fazla stratejiyle ulaşılabilir. Bir uzman hızlı, örüntü temelli yol kullanırken başka bir kullanıcı sistematik karşılaştırma yapabilir. Ağ kısıtlı olduğunda yerel veriyle, normal koşulda merkezi servisle çalışmak da teknik strateji farkıdır. Sistem yalnız tek ideal stratejiyi desteklerse değişen koşullara karşı kırılganlaşabilir. Strateji analizi, güvenli alternatif yolları ve bu yolların bilgi gereksinimlerini belirlemeye yardım eder. ## Ünite 7: Sosyal Örgütlenme, İş Birliği ve Yetkinlikler ### Dağıtık biliş ve ortak durum resmi Karmaşık işte gerekli bilginin tamamı tek kişinin zihninde bulunmaz. Bir ekip üyesi teknik durumu, diğeri operasyonel önceliği, başka biri geçmiş bağlamı biliyor olabilir. Bu nedenle ekip başarımı yalnız bireysel yetkinliklerin toplamı değildir; bilginin kimde bulunduğunun bilinmesi, doğru anda paylaşılması ve ortak kavramların tutarlı olması gerekir. “Ortak durum resmi” herkesin aynı ekranı görmesi anlamına gelmez. Roller farklıysa ayrıntı gereksinimleri de farklı olabilir. Kritik olan, roller arası bağımlılıkların ve karar için gerekli ortak değişkenlerin çelişkili biçimde temsil edilmemesidir. ### Yetki, sorumluluk ve geri bildirim Bir kişiye eylem yetkisi vermek, o kişinin eylemin etkisini gözleyebileceği anlamına gelmez. Tasarımda yetki ile gözlenebilirlik birlikte incelenmelidir. Kullanıcı bir değişiklik yapabiliyor ancak sonucu başka ekip veya ekranda görünüyorsa kapalı bir kontrol döngüsü oluşmaz. Benzer biçimde, bir rol sonucu izlemekten sorumlu fakat müdahale yetkisine sahip değilse eskalasyon yolu açık olmalıdır. ### Beceri–kural–bilgi düzeyleri Çalışan yetkinlikleri analizinde kullanılan beceri, kural ve bilgi temelli davranış ayrımı, aynı görevin farklı koşullarda farklı bilişsel kontrol biçimleri gerektirebileceğini hatırlatır. İyi öğrenilmiş bir eylem düşük bilinçli çabayla yürürken tanıdık bir anormallik kural uygulamasını, tamamen yeni bir durum ise daha analitik bilgi temelli muhakemeyi gerektirebilir. Arayüz normal akışta hızlı kullanımı desteklerken sıra dışı durumda açıklayıcı bağlama geçiş olanağı sunmalıdır. ### Bilişsel iş ekip içinde dağılır Karmaşık sistemlerde bilgi tek kişide bulunmaz. Bir rol teknik durumu, başka rol operasyonel önceliği, başka rol yetki veya güvenlik kısıtını bilir. Bu nedenle ortak kararın kalitesi yalnız bireysel uzmanlığa değil, bilginin ekip içinde doğru dağılımına ve aktarımına bağlıdır. ### Yetki ile bilgi aynı yerde olmayabilir Kararı verme yetkisi ile gerekli bilginin bulunduğu rol farklı olabilir. Sistem tasarımı, doğru kişiye doğru ayrıntı düzeyini ulaştırmalı; fakat gereksiz bilgi yayılımı ve yetki ihlalinden kaçınmalıdır. Bu, hem arayüz hem erişim denetimi hem de iş akışı problemidir. ### Çalışan Yetkinlikleri Analizi Çalışan yetkinlikleri analizi; belirli bir işin beceri, kural ve bilgi tabanlı davranış bakımından ne gerektirdiğini inceler. Amaç kişiyi puanlamak değil, sistemin hangi davranış türünü desteklemesi gerektiğini anlamaktır. - **Beceri tabanlı davranış** hızlı ve akıcıdır; gereksiz diyaloglar akışı bozabilir. - **Kural tabanlı davranış** tanınan koşul ile bilinen prosedürü eşler. - **Bilgi tabanlı davranış** yeni durumda problem çözme ve nedensel muhakeme gerektirir. Beklenmeyen durumlarda yalnız kural listesi sunmak yetersiz kalabilir; sistem iş alanının ilişkilerini görünür hale getirerek bilgi tabanlı muhakemeyi desteklemelidir. ## Ünite 8: Doğal Çalışma Ortamında Karar Verme ### Tanıma, değerlendirme ve zihinsel simülasyon RPD yaklaşımında uzman karar verici her zaman geniş bir seçenek listesi üretip puanlamaz. Durumu tanıdık bir örüntü olarak sınıflandırabilir; bu örüntü tipik hedefleri, beklenen gelişmeleri, önemli ipuçlarını ve uygulanabilir ilk eylemi birlikte çağırır. Ardından eylemin yakın gelecekte ne doğuracağını zihinsel olarak sınar. Ciddi bir sorun görülmüyorsa ilk uygulanabilir seçenek seçilebilir; sorun varsa değiştirilir veya sonraki seçenek düşünülür. Bu süreç “uzman ilk aklına geleni yapar” biçiminde basitleştirilmemelidir. Tanıma kalitesi deneyime, geri bildirim döngülerine ve ortamın düzenliliğine bağlıdır. Zihinsel simülasyon da özellikle sonuçların gecikmeli veya geri dönüşü zor olduğu işlerde önem kazanır. ### Zaman baskısında seçenek üretme maliyeti Klasik karar destek sistemleri bazen olabildiğince çok seçenek üretmeyi fayda olarak görür. Oysa zaman baskısında fazla seçenek karşılaştırma maliyetini yükseltebilir. Karar desteğinin amacı seçenek sayısını maksimize etmek değil; kritik ayrımları görünür kılmak, uygulanamaz seçenekleri erken elemek ve kullanıcının eylem sonucunu öngörmesini desteklemektir. ### Uzmanlık için geri bildirim şartı Deneyim tek başına güvenilir sezgi üretmez. Bir kararın sonucu geç, belirsiz veya yanlış geri bildirimle dönüyorsa kişi çok sayıda vaka görse bile hatalı örüntüler öğrenebilir. Bu nedenle sistem tasarımında yalnız karar anı değil, karar sonrası geri bildirim kalitesi de uzmanlık gelişiminin parçasıdır. **Naturalistic Decision Making (NDM)** araştırma geleneği, insanların yüksek risk, zaman baskısı, eksik bilgi, değişen hedefler ve gerçek iş bağlamı altında nasıl karar verdiğini inceler. Bu yaklaşım, her kararın önce bütün seçeneklerin çıkarıldığı, sonra puanlandığı ve en yüksek puanın seçildiği varsayımına karşı önemli bir tamamlayıcıdır. ### Analitik seçim her zaman gerçekleşmez Bazı kararlar için karşılaştırmalı analiz uygundur. Ancak deneyimli çalışanların zaman baskılı durumlarda yaptığı şey çoğu kez şöyledir: ```text durumu tanı → tipik eylemi hatırla → zihinsel olarak sonucu canlandır → uygunsa uygula → uygun değilse sıradaki uygulanabilir seçeneğe geç ``` Bu davranış rastgele sezgi değildir. Uzmanlığın oluşturduğu örüntüler, beklentiler ve deneyim tabanlı zihinsel modeller önemlidir. ### Tanımaya Dayalı Karar modeli **Recognition-Primed Decision (RPD)** modeli, deneyimli karar vericinin durumu tanıması ile eylem değerlendirmesini birleştirir. Durum tipik bir örüntüye uyduğunda tek bir uygulanabilir eylem ilk aday olabilir. Karar verici eylemin sonucunu zihinsel olarak canlandırır; sorun görmezse seçenekleri karşılaştırmadan uygulayabilir. Bu model “ilk akla gelen her zaman doğrudur” demez. Tanımanın güvenilirliği alan deneyimine, geri bildirim kalitesine ve çevrenin düzenliliğine bağlıdır. Ayrıca yeni, aldatıcı veya hızlı değişen durumlarda analitik değerlendirme gerekebilir. ### Uzman sezgisinin sınırı Sistem tasarımı uzmanın sezgisini körlemesine otomatikleştirmemelidir. Verinin değiştiği, geçmiş örüntülerin geçersizleştiği veya yapay zekânın yeni bir bilgi kaynağı eklediği ortamda eski sezgiler yanlış güven üretebilir. İyi karar desteği, uzmanlığa alan açarken dayanak ve karşı kanıtı görünür tutar. ## Ünite 9: Durumsal Farkındalık **Durumsal farkındalık (situation awareness)**, dinamik sistemlerde karar vermeden önce çevredeki ilgili öğelerin algılanması, mevcut durumun anlamlandırılması ve yakın gelecekteki durumun öngörülmesiyle ilişkilidir. ### Üç düzeyli model Endsley'nin yaygın modelinde üç düzey ayırt edilir: ```text Düzey 1: Algılama Ne oluyor? ↓ Düzey 2: Anlama Bu ne anlama geliyor? ↓ Düzey 3: Öngörü Bu eğilim sürerse sonra ne olabilir? ``` Bu düzeyler katı bir yazılım boru hattı değildir. Operatörün hedefleri, zihinsel modeli ve beklentileri algılanan bilginin seçimini etkiler. ### Veri zenginliği farkındalık değildir Daha çok gösterge, daha iyi durumsal farkındalık anlamına gelmez. Yüzlerce bağımsız metriği göstermek kullanıcının işini artırabilir. İhtiyaç; ilişkileri, öncelikleri, eğilimleri ve sınırları anlaşılır biçimde göstermektir. Örneğin: ```text CPU: %82 Kuyruk: 14 200 Giriş: 480/s Çıkış: 450/s ``` ham veridir. Kullanıcının asıl sorusu “sistem kapasite kaybediyor mu, kuyruk büyümeye devam edecek mi ve müdahale için ne kadar zaman var?” olabilir. Durum gösterimi bu ilişkiyi görünür hale getirmelidir. ### Zaman ve veri tazeliği Durumsal farkındalıkta zaman damgası kritik olabilir. İki değer aynı ekranda bulunsa da biri 100 ms, diğeri 30 saniye eskiyse birlikte yorumlanmaları yanıltıcı olabilir. Bu nedenle veri tazeliği, örnekleme aralığı ve gecikme yalnız altyapı metriği değil, insan-makine karar kalitesinin parçasıdır. ### Otomasyon ve farkındalık Otomasyon iş yükünü azaltabilir ancak kullanıcıyı süreçten koparabilir. Sistem uzun süre otomatik çalıştıktan sonra insanın yalnız istisna anında devreye girmesi gerekiyorsa, operatörün gerekli zihinsel modeli koruması zorlaşabilir. Bu nedenle otomasyon tasarımı “kaç adımı kaldırabiliriz?” kadar “insanın gerektiğinde doğru duruma geri girebilmesi için neyi görünür tutmalıyız?” sorusunu da yanıtlamalıdır. ## Ünite 10: Durumsal Farkındalığın Ölçülmesi ### Ölçüm hedefi önce tanımlanmalıdır Durumsal farkındalık tek bir genel puana indirgenmeden önce hangi kararlar için hangi durum bilgisinin gerekli olduğu belirlenmelidir. Bir operatörün yüzlerce değeri hatırlaması yüksek farkındalık anlamına gelmez; önemli olan görev açısından gerekli değişkenleri, ilişkileri ve gelecek eğilimlerini doğru temsil edebilmesidir. Bu nedenle ölçüm maddeleri doğrudan görev ve karar gereksinimlerinden türetilmelidir. ### SAGAT'ın mühendislik kullanımı ve sınırları SAGAT benzeri dondurma tekniklerinde senaryo belirli anlarda kesilir, normal göstergeler gizlenir ve katılımcının mevcut duruma ilişkin bilgisi sorgulanır. Yöntemin gücü, öznel “durumu ne kadar iyi anladınız?” sorusu yerine gerçek durumla karşılaştırılabilir yanıtlar üretmesidir. Ancak dondurma noktaları öngörülebilir olursa katılımcı ölçüme göre dikkat stratejisi geliştirebilir. Sorular da yalnız kolay ölçülen düşük düzey değerlerden oluşursa kavrama ve öngörü boyutları temsil edilemez. ### SART ve öznel ölçümlerin yeri SART gibi öznel yöntemler operatörün dikkat talebi, dikkat kaynağı ve durum anlayışına ilişkin kendi değerlendirmesini yakalayabilir. Bu veri değersiz değildir; fakat objektif doğrulukla aynı değişkeni ölçtüğü varsayılmamalıdır. Bir kişi kendini oldukça farkında hissederken kritik bir ilişkiyi yanlış anlayabilir veya tersine yüksek belirsizlik hissedip doğru karar verebilir. ### Ölçüt üçgenleme Güçlü değerlendirme çoğu zaman tek metrik yerine farklı kanıt türlerini birleştirir: ```text durum sorguları + öznel değerlendirme + görev performansı + gözlem / olay analizi ↓ daha güçlü yorum ``` Bu kanıtlar birbirinin yerine geçmez. İyi görev performansı bazen düşük sistem desteğine rağmen uzman telafisiyle elde edilebilir; kötü performans ise doğru durum anlayışına rağmen yetersiz yetki veya kaynak nedeniyle oluşabilir. Durumsal farkındalığı ölçmeden “arayüz farkındalığı artırdı” demek zayıf bir iddiadır. Ancak tek bir ölçüm yöntemi de bütün boyutları kusursuz açıklamaz. ### SAGAT **Situation Awareness Global Assessment Technique (SAGAT)**, kontrollü simülasyonlarda görevi belirli anlarda dondurup ekran bilgisini gizleyerek katılımcıya mevcut durum hakkında sorular yöneltmeye dayalı doğrudan ölçüm yaklaşımıdır. Sorular sistemin gerçekten gerekli durum bilgisine bağlanmalıdır. Avantajı, performans sonucundan ayrı olarak kullanıcının o anda ne bildiğini sorgulayabilmesidir. Sınırlılığı ise görevi dondurmanın doğal akışı bozabilmesi ve gerçek üretim ortamında her zaman uygulanamamasıdır. ### SART **Situation Awareness Rating Technique (SART)**, görevin ardından öznel değerlendirme toplar. Uygulaması daha kolaydır fakat kişinin kendi farkındalığını değerlendirmesi ile gerçek durum bilgisinin doğruluğu aynı şey değildir. Öznel güven yüksek, gerçek bilgi düşük olabilir. ### Performans ölçütleri Görev başarısı, hata oranı ve tepki süresi değerlidir fakat tek başına durumsal farkındalık ölçüsü değildir. Kullanıcı doğru sonucu şansla üretebilir veya yüksek farkındalığa rağmen sistem kısıtı nedeniyle görevi tamamlayamayabilir. ### Çoklu ölçüm yaklaşımı Daha güvenilir değerlendirme için yöntemler birlikte kullanılabilir: ```text doğrudan SA sorguları + görev performansı + davranış gözlemi + hata / olay analizi + öznel iş yükü ve güven ölçümleri ``` Burada amaç tek bir “SA puanı” üretmekten çok, tasarım değişikliğinin hangi bilişsel mekanizmayı etkilediğini anlamaktır. ## Ünite 11: Ekolojik Arayüz Tasarımı ### Algısal biçim ile iş alanı kısıtı eşleşmelidir Ekolojik arayüz tasarımında görselleştirme yalnız estetik bir özet değildir. Temsilin geometrisi veya düzeni, iş alanındaki anlamlı ilişkiyi doğrudan algılanabilir kılmalıdır. İki değişken arasındaki güvenli oran önemliyse kullanıcı bu oranı zihinsel olarak hesaplamak zorunda kalmamalıdır; mümkün olduğunda sınır ve mevcut durum aynı algısal yapıda gösterilebilir. Bununla birlikte her ilişkiden gösterge üretmek doğru değildir. EID'nin amacı bilgi yoğunluğunu artırmak değil, karar için gerekli kısıtları uygun algısal biçime dönüştürmektir. Gereksiz ilişki görselleştirmesi yeni bir gürültü katmanı yaratır. ### Beceri, kural ve bilgi temelli davranışı birlikte desteklemek Normal çalışma sırasında deneyimli kullanıcı hızlı algısal eşleşmelerle hareket edebilir. Daha az tanıdık durumda kurallar ve prosedürler devreye girer; beklenmeyen durumda ise sistemin amaç ve kısıtlarını anlayarak yeni bir çözüm oluşturmak gerekir. İyi bir ekolojik temsil bu düzeylerden yalnız birine göre optimize edilmez. Hızlı kullanım için doğrudan algılanabilir yapı sunarken derin inceleme için neden-sonuç ve araç-amaç bağlarını kaybetmez. **Ekolojik Arayüz Tasarımı (Ecological Interface Design, EID)**, karmaşık sistemlerde arayüzün yalnız mevcut durum değerlerini değil, iş alanındaki kısıtları ve işlevsel ilişkileri de algılanabilir kılmasını hedefler. Temel fikir, kullanıcıyı gereksiz yere daha yüksek bilişsel işlem düzeyine zorlamadan beceri-, kural- ve bilgi-tabanlı davranışı desteklemektir. ### Değer göstermek ile kısıt göstermek Klasik gösterim: ```text Giriş hızı: 420/s İşleme hızı: 400/s Kuyruk: 12 000 ``` İlişkiyi görünür kılan gösterim: ```text kapasite sınırı │ giriş 420/s ───────┼─────┐ │ +20/s birikim çıkış 400/s ─────────────┘ mevcut kuyruk: 12 000 aynı fark sürerse kuyruk büyür ``` İkinci temsil operatörün hesap yapma yükünü azaltabilir; çünkü sistem davranışındaki kısıt ve eğilim doğrudan görünür hale gelir. ### EID dekoratif görselleştirme değildir EID, grafik ekranı daha “teknik” göstermek değildir. İş alanı analizi olmadan çizilen karmaşık göstergeler, yalnız bilgi yoğunluğunu artırabilir. Arayüzde gösterilecek ilişki gerçekten sistemin fiziksel, işlevsel veya güvenlik kısıtına dayanmalıdır. ### Beklenmeyen duruma destek Prosedür tabanlı arayüz bilinen arızalarda etkili olabilir. Beklenmeyen durumda operatörün sistemin daha temel ilişkilerini kullanarak yeni çözüm üretmesi gerekir. EID'nin güçlü olduğu nokta, bu bilgi tabanlı davranışı destekleyecek kısıtları görünür kılmaktır. ## Ünite 12: Karar Desteği Tasarımı Karar destek sistemi, kullanıcı adına karar vermek zorunda değildir. Daha değerli hedef çoğu zaman; doğru ipuçlarını öne çıkarmak, ilgili bağlamı birleştirmek, alternatif açıklamaları görünür tutmak ve sonuçların dayanağını izlenebilir kılmaktır. ### Veri, bilgi, durum ve karar desteği ayrımı ```text veri ↓ bağlamlandırılmış bilgi ↓ durum modeli ↓ olası sonuçlar / seçenekler ↓ insan kararı ``` Bir sayı göstermek veri sunumudur. Sayıyı doğru hedef ve zamanla eşlemek bilgi sunumudur. Birden fazla kaynaktan gelen verinin ortak anlamını açıklamak durum modelidir. Kullanıcının hedefi açısından olası sonuçları ve kanıtı görünür kılmak karar desteğidir. ### Açıklanabilirlik yerine eyleme dönük izlenebilirlik Özellikle yapay zekâ içeren sistemlerde uzun bir doğal dil açıklaması tek başına yeterli değildir. Kullanıcı şu sorulara yanıt bulabilmelidir: - Bu sonuç hangi kayıtlara dayanıyor? - Kaynakların zamanı ve güvenilirliği nedir? - Hangi bilgi doğrudan gözlem, hangisi türetilmiş sonuçtur? - Çıkarım hangi belirsizlikleri içeriyor? - Kaynak değişirse sonuç yeniden üretilebilir mi? Bu yaklaşım [Bilgi Erişimi Destekli Üretim](/rag) dersindeki erişim, veri kökeni ve izlenebilirliği (provenance) ile kanıt temellendirme ilkeleriyle doğrudan ilişkilidir. ## Ünite 13: Dayanıklılık Mühendisliği ### Başarı ve başarısızlığın ortak değişkenliği Günlük çalışma tamamen prosedür kopyası değildir. İnsanlar ve teknik bileşenler zaman, kaynak ve bilgi koşullarına göre sürekli küçük ayarlamalar yapar. Aynı ayarlama çoğu gün verimlilik sağlarken farklı bağımlılıkların aynı anda değiştiği bir günde kırılganlık yaratabilir. Bu nedenle yalnız başarısız olaylara bakmak, sistemin her gün hangi uyarlamalar sayesinde çalıştığını görünmez bırakır. ### İşlevsel rezonans ve bağımlı değişkenlik Bir işlevdeki küçük zamanlama veya doğruluk değişkenliği tek başına sorun olmayabilir. Ancak birden fazla işlevin değişkenliği aynı anda ve uyumsuz yönde birleştiğinde beklenmeyen sonuç oluşabilir. “Tek kök neden” arayışı bu tür örüntülerde yetersiz kalabilir. Analiz, bileşen hatasının yanında işlevler arası zamanlama, kaynak ve kontrol bağımlılıklarını da incelemelidir. ### Öncü ve gecikmeli gösterge ayrımı Olay sayısı, hata sayısı veya kesinti süresi çoğunlukla gerçekleşmiş sonucu ölçer. Dayanıklılık açısından yalnız bu gecikmeli göstergeler yeterli değildir. Kuyruk eğimi, kapasite marjı, alarm bastırma sıklığı, manuel telafi miktarı, görev devri yoğunluğu veya belirli bir kaynağa bağımlılık gibi öncü göstergeler kırılganlığın olaya dönüşmeden önce fark edilmesine yardım edebilir. ### Öğrenme yalnız postmortem değildir Öğrenme, büyük olaylardan sonra rapor yazmakla sınırlı olmamalıdır. Başarılı fakat zor vardiyalar, near miss durumları, manuel telafiler ve beklenmeyen şekilde iyi çalışan adaptasyonlar da incelenebilir. Amaç kişiyi değerlendirmek değil, sistemin nerede marj kullandığını ve hangi koşullarda bu marjın tükenebileceğini anlamaktır. **Dayanıklılık mühendisliği (resilience engineering)**, yalnız arızaları önlemeye değil, sistemin değişen ve kısmen öngörülemez koşullarda gerekli işlevini sürdürebilme ve uyum sağlayabilme kapasitesine odaklanır. Başarı ile başarısızlığı bütünüyle ayrı süreçler olarak görmek yerine, günlük işte yapılan uyarlamaların farklı koşullarda farklı sonuçlar doğurabileceğini inceler. ### Tasarlanan iş ve yapılan iş Prosedürler işi ideal koşullar altında tanımlar. Gerçek işte zaman, personel, araç, veri ve çevre koşulları değişir. Çalışanlar görevi tamamlamak için sürekli küçük uyarlamalar yapar. Bu uyarlamalar çoğu zaman sistemin çalışmasını sağlar; ancak bazı kombinasyonlar risk oluşturabilir. Bu nedenle olay sonrası yalnız “prosedüre uyulmadı” demek, uyarlamanın neden gerekli hale geldiğini kaçırabilir. ### Dört dayanıklılık kapasitesi Resilience engineering literatüründe yaygın dört yetenek şunlardır: - **Müdahale edebilme (respond):** gerçekleşen duruma etkili tepki verebilmek. - **İzleyebilme (monitor):** yaklaşan değişimi gösterecek kritik göstergeleri takip etmek. - **Öngörebilme (anticipate):** gelecekteki tehdit ve fırsatları düşünmek. - **Öğrenebilme (learn):** geçmiş başarı ve başarısızlıklardan uygulanabilir ders çıkarmak. Bu dört yetenek operasyonel tasarıma çevrilebilir. Örneğin izleme için doğru öncü gösterge, müdahale için yetkili ve geri alınabilir eylem, öngörü için kapasite eğilimi, öğrenme için olay sonrası güvenilir kayıt gerekir. ### Kademeli hizmet kaybı Kritik sistem her bileşen arızasında tamamen durmak zorunda değildir. Güvenli olan işlevler korunup ikincil işlevler sınırlandırılabilir. Bu **kademeli hizmet kaybı (graceful degradation)** yaklaşımı, sistemin hangi minimum yeteneklerle güvenli değer üretmeye devam edebileceğinin önceden belirlenmesini gerektirir. ```text normal kip ↓ kaynak baskısı ↓ ikincil işlevleri sınırla ↓ çekirdek hizmeti koru ↓ geri kazanım ``` ### Marj ve adaptif kapasite Kapasite yalnız ortalama kullanım değildir. Sistem ne kadar ek yük, hata veya koordinasyon zorluğu emebilir? Teknik tarafta CPU, kuyruk ve bağlantı marjı; insan tarafında dikkat, ekip kapasitesi ve vardiya yükü benzer sınırlar yaratabilir. Marj görünmezse sistem nominal olarak çalışırken kırılganlığa yaklaşabilir. ## Ünite 14: Otomasyon, Yapay Zekâ ve İnsan Denetimi ### Otomasyon düzeyi değil işlev dağılımı önemlidir “Daha fazla otomasyon” tek boyutlu bir hedef değildir. Bilgi edinme, bilgi analizi, seçenek üretme ve eylem uygulama farklı derecelerde otomatikleştirilebilir. Bir sistem veriyi otomatik toplayıp kararı insana bırakabilir; başka bir sistem seçenek önerip uygulama yetkisini insanda tutabilir. Tasarım değerlendirmesi hangi bilişsel işlevin neden otomasyona verildiğini ve bunun insanın kalan görevini nasıl değiştirdiğini açıkça göstermelidir. ### Kip farkındalığı ve otomasyon sürprizi Kullanıcı sistemin hangi otomasyon kipinde olduğunu, bu kipin neden değiştiğini ve hangi yetkilerin otomasyonda kaldığını anlayamazsa beklenmedik davranış “otomasyon sürprizi” olarak ortaya çıkabilir. Kip değişimi yalnız küçük bir etiketle bildirilmemeli; davranışsal sonucu karar açısından önemliyse eylem sınırları da anlaşılır olmalıdır. ### Belirsizlik sunumu Bir model çıktısının sayısal güven değeri tek başına yeterli değildir. Bu değerin kalibrasyonu, hangi veri dağılımında üretildiği ve kullanıcının hangi kararı vereceği önemlidir. Belirsizlik sunumu kullanıcıyı matematiksel ayrıntıyla boğmadan şu ayrımları korumalıdır: ölçülen gerçek, deterministik türetim, istatistiksel tahmin ve üretken yorum. ### Devir teslim tasarımı Otomasyon başarısız olduğunda “manuel moda geç” komutu kullanıcıya bağlam kazandırmaz. Etkili devir teslim; mevcut durum, son otomatik eylemler, bekleyen işlemler, kritik sınırlar ve insanın ilk kontrol etmesi gereken değişkenleri birlikte sunmalıdır. Devir teslim süresi de bir performans gereksinimidir; kullanıcının bağlamı yeniden kurmasının ne kadar sürdüğü test edilebilir. ### Otomasyonun paradoksu Otomasyon normal durumda insan iş yükünü azaltabilir, fakat istisna anında kullanıcıdan daha yüksek bilişsel performans bekleyebilir. Sistem uzun süre otomatik çalıştığında operatörün pratik, sistem durumu ve nedensel model üzerindeki hakimiyeti azalabilir. Bu nedenle kritik otomasyon tasarımında devir teslim anı başlı başına gereksinimdir. ### Otomasyon yanlılığı Kullanıcı otomatik öneriyi gereğinden fazla güvenilir kabul edebilir; buna **otomasyon yanlılığı (automation bias)** denir. Tersi de mümkündür: sık yanlış alarm veya düşük kaliteli öneri, kullanıcıda kalıcı güvensizlik oluşturabilir. Hedef “maksimum güven” değil, sistemin gerçek yetenek ve sınırlılıklarıyla uyumlu **kalibre edilmiş güven** olmalıdır. ### Kanonik kanıt ve türetilmiş yorum AI destekli kritik bir sistemde şu katmanların ayrılması yararlıdır: ```text kanonik kayıt / ölçüm ↓ deterministik türetim ↓ istatistiksel model çıktısı ↓ üretken model yorumu ↓ insan değerlendirmesi ve karar ``` Üst katmandaki yorum alt katmandaki kanıtın yerine geçmemelidir. Model çıktısının saklanması gerekiyorsa sürüm, zaman, giriş, kullanılan kaynaklar ve belirsizlik gibi veri kökeni ve izlenebilirlik bilgileri korunmalıdır. ### İnsan denetimi yalnız onay düğmesi değildir “İnsanın karar döngüsünde tutulması (human-in-the-loop)” terimi bazen yalnız son ekranda bir onay düğmesi bulunması anlamında kullanılır. Gerçek insan denetimi için kullanıcının karar vermeye yetecek bilgiye, zamanı yönetebilecek iş akışına, öneriyi reddetme yetkisine ve sonucun kaynağını denetleme olanağına sahip olması gerekir. ## Ünite 15: Bilişsel Sistem Mühendisliğini Uygulama ### Analiz çıktılarının izlenebilirliği Bilişsel analiz raporda kalırsa geliştirme sürecine etkisi sınırlı olur. Kritik bulgular gereksinim, tasarım kararı ve doğrulama kanıtına bağlanmalıdır: ```text zor olay / uzman ipucu ↓ bilişsel gereksinim ↓ arayüz / otomasyon kararı ↓ test senaryosu ↓ ölçüm ve kabul ölçütü ``` Bu zincir, “insan faktörleri değerlendirildi” gibi doğrulanamaz bir ifadeyi somut mühendislik kanıtına dönüştürür. ### Minimum uygulanabilir bilişsel analiz Her proje tam ölçekli CTA ve CWA çalışması yürütemez. Kaynak sınırlıysa yüksek riskli kararların seçildiği dar bir çalışma yapılabilir: birkaç uzmanla zor olay görüşmeleri, temel iş alanı kısıt modeli, karar gereksinimi matrisi ve bir veya iki kritik senaryonun simülasyon temelli doğrulaması. Küçük çalışma dahi yalnız genel kullanılabilirlik testinden daha güçlü tasarım girdisi üretebilir. ### Değişiklik yönetimi Bilişsel gereksinimler sabit değildir. Yeni otomasyon, organizasyon değişikliği, daha hızlı veri akışı veya farklı kullanıcı profili eski uzmanlık dağılımını değiştirebilir. Bu nedenle büyük sürüm değişikliklerinde yalnız fonksiyonel regresyon değil, bilişsel regresyon da sorulmalıdır: Kullanıcı daha önce görünür olan hangi ilişkiyi artık zihninde kurmak zorunda kalıyor? Hangi yeni otomasyon eski geri bildirim döngüsünü kapattı? Hangi hızlı yol istisna anında gerekli bağlamı gizledi? ### Başarı ölçütü Bilişsel sistem mühendisliğinin başarısı “kullanıcı arayüzü beğendi” sonucu değildir. Daha anlamlı ölçütler; kritik durumu daha erken fark etme, yanlış zihinsel model oranının azalması, bağlam geri kazanım süresinin kısalması, bozulmuş kipte çekirdek görevin korunması, gereksiz koordinasyon adımlarının azalması ve karar sonrası geri bildirimin kapanmasıdır. Ölçütler alanın gerçek riskiyle ilişkilendirilmelidir. ### Analiz akışı Karmaşık bir operasyonel sistemi geliştirirken aşağıdaki sıra yararlı bir başlangıçtır: ```text 1. İş hedeflerini ve değişmeyen kısıtları belirle 2. Bilişsel olarak zor kararları seç 3. Uzmanlık ve kritik olay verisini CTA ile çıkar 4. İş alanını CWA ile modelle 5. Bilgi ve karar gereksinimlerini tanımla 6. Durumsal farkındalık hedeflerini yaz 7. Arayüz ve otomasyonu bu gereksinimlere göre tasarla 8. Normal ve bozulmuş kipleri doğrula 9. İnsan performansı ile sistem performansını birlikte ölç 10. Gerçek olaylardan yeni gereksinim üret ``` ### Bilişsel gereksinim örneği Zayıf gereksinim: ```text Sistem alarm gösterecektir. ``` Daha güçlü gereksinim: ```text Operatör, bir alarmın hangi varlıkta oluştuğunu, ne zaman başladığını, halen etkin olup olmadığını, hangi üst düzey hizmet hedefini etkilediğini ve alarmın doğrulanması için gereken iki temel sinyali aynı çalışma bağlamında görebilmelidir. ``` İkinci ifade arayüz tasarımını daha fazla kısıtlar fakat doğrulanabilir bir bilişsel hedef üretir. ### Karar gereksinimi matrisi Bir işlev için şu sorular birlikte yazılabilir: ```text Karar : Kullanıcı neyi seçiyor veya değerlendiriyor? İpucu : Hangi sinyal ve ilişkiler anlamlı? Bağlam : Hangi geçmiş veya eşzamanlı bilgi gerekli? Belirsizlik : Ne bilinmiyor, ne yaklaşık? Zaman : Bilginin yaşı ve karar süresi nedir? Sonuç : Yanlış kararın maliyeti nedir? Eylem : Karar sonrası hangi yetkili işlem yapılabilir? Geri bildirim: Eylemin sonucunun doğru olduğu nasıl anlaşılır? ``` Bu matris, klasik fonksiyonel gereksinimlerin yerini almaz; onları bilişsel çalışma açısından tamamlar. ### Tasarım gözden geçirmesinde sorulacak sorular - Ekran mevcut durumu mu gösteriyor, yoksa iş alanındaki ilişkileri de görünür kılıyor mu? - Kullanıcı kritik bir değerin ne kadar eski olduğunu anlayabiliyor mu? - Normal akış hızlıyken beklenmeyen durumda ayrıntıya inmek mümkün mü? - Otomasyon devre dışı kaldığında insan gerekli zihinsel modele sahip mi? - Bir model önerisi ile doğrulanmış kayıt görsel ve anlamsal olarak ayrılıyor mu? - Kullanıcı kesinti sonrası hangi kayıtta, hangi adımda ve hangi bağlamda kaldığını anlayabiliyor mu? - Alarm sayısı değil, karar için gerekli alarm ilişkisi gösteriliyor mu? - Sistemin kapasite veya güvenlik sınırına yaklaşması yalnız teknik loglarda mı görülebiliyor? ### Doğrulama yaklaşımı Bilişsel gereksinimler yalnız kullanıcı memnuniyeti anketiyle doğrulanmamalıdır. CTA sonrası görev senaryoları, kontrollü simülasyonlar, durumsal farkındalık ölçümleri, hata enjeksiyonu, bozulmuş kip testleri ve gerçek olay incelemeleri birlikte kullanılabilir. Yazılım testinin bu boyutu [Yazılım Test Mühendisliği](/yazilim-test-muhendisligi-uygulamali-dogrulama-gecerleme) dersindeki model, özellik ve dayanıklılık temelli doğrulama yöntemleriyle tamamlanır. ## Sonuç Bilişsel sistemler mühendisliği, insan faktörlerini geliştirme sürecinin sonunda yapılan kullanılabilirlik kontrolüne indirgemez. İnsan davranışı, otomasyon, bilgi akışı, organizasyon ve teknik altyapı daha ilk gereksinim aşamasından itibaren aynı sistemin parçaları olarak ele alınır. Bilişsel görev analizi uzmanlığın ve zor kararların içeriğini görünür kılar. Bilişsel iş analizi, mevcut prosedürün ötesindeki iş alanı kısıtlarını ve alternatif stratejileri modeller. Doğal çalışma ortamında karar verme araştırmaları, uzmanların zaman baskısı ve belirsizlik altında seçenekleri nasıl kullandığını açıklar. Durumsal farkındalık, arayüzün yalnız veri göstermesi yerine anlam ve öngörü üretmesini gerektirir. Ekolojik arayüz tasarımı sistem kısıtlarını algılanabilir hale getirmeye çalışır. Dayanıklılık mühendisliği ise beklenmeyen durumda uyarlanabilir kapasitenin korunmasını merkeze alır. Bu yaklaşımlar birlikte kullanıldığında hedef, insanı sistemdeki zayıf halka olarak görmek değil; insan ve teknolojinin birlikte daha anlaşılır, denetlenebilir, uyarlanabilir ve güvenilir davranacağı bir çalışma sistemi tasarlamaktır. ## Kaynakça - Beth Crandall; Gary Klein; Robert R. Hoffman. *Working Minds: A Practitioner's Guide to Cognitive Task Analysis*. MIT Press, 2006. https://mitpress.mit.edu/9780262033510/working-minds/ - Caroline E. Zsambok; Gary Klein (eds.). *Naturalistic Decision Making*. Lawrence Erlbaum Associates, 1997. - Erik Hollnagel; Jean Pariès; David D. Woods; John Wreathall (eds.). *Resilience Engineering in Practice: A Guidebook*. Ashgate, 2011. https://www.routledge.com/Resilience-Engineering-in-Practice-A-Guidebook/Hollnagel-Paris-Wreathall/p/book/9781472420749 - Gary Klein. *Sources of Power: How People Make Decisions*. 20th Anniversary Edition. MIT Press, 2017. https://mitpress.mit.edu/9780262534291/sources-of-power/ - Jens Rasmussen; Annelise Mark Pejtersen; L. P. Goodstein. *Cognitive Systems Engineering*. Wiley, 1994. https://www.wiley-vch.de/en/areas-interest/engineering/cognitive-systems-engineering-978-0-471-01198-9 - Kim J. Vicente. *Cognitive Work Analysis: Toward Safe, Productive, and Healthy Computer-Based Work*. Lawrence Erlbaum Associates, 1999. https://www.routledge.com/Cognitive-Work-Analysis-Toward-Safe-Productive-and-Healthy-Computer-Based/Vicente/p/book/9780805823974 - Kim J. Vicente; Jens Rasmussen. “Ecological Interface Design: Theoretical Foundations.” *IEEE Transactions on Systems, Man, and Cybernetics*, 22(4), 589–606, 1992. DOI: https://doi.org/10.1109/21.156574 - Mica R. Endsley. “Toward a Theory of Situation Awareness in Dynamic Systems.” *Human Factors*, 37(1), 32–64, 1995. DOI: https://doi.org/10.1518/001872095779049543 - Mica R. Endsley; Daniel J. Garland (eds.). *Situation Awareness Analysis and Measurement*. Lawrence Erlbaum Associates, 2000. https://www.routledge.com/Situation-Awareness-Analysis-and-Measurement/Endsley-Garland/p/book/9780805821345 - Nancy G. Leveson. *Engineering a Safer World: Systems Thinking Applied to Safety*. MIT Press, 2012. https://mitpress.mit.edu/9780262016629/engineering-a-safer-world/ ## Bu Çalışmaya Atıf Köker, M. A. (2026). Bilişsel Sistemler Mühendisliği: İnsan Faktörleri, Durumsal Farkındalık ve Karar Desteği. alikoker.com.tr. https://alikoker.com.tr/bilissel-sistemler-muhendisligi - BibTeX: https://alikoker.com.tr/bilissel-sistemler-muhendisligi.bib - RIS: https://alikoker.com.tr/bilissel-sistemler-muhendisligi.ris - CSL-JSON: https://alikoker.com.tr/bilissel-sistemler-muhendisligi.csl.json