AiOLoS: Yazılım Geliştiren Organizasyonlarda Örgütsel Öğrenmeyi Değerlendirme Modeli

Abstract

Özet. Teknolojinin çok hızla geliştiği bir endüstride, yazılım geliştiren organizasyonlar (YGO) ve bilgi teknolojileri alanında çalışan kuruluşların (BTK), sürekli artan rekabete ayak uydurmak ve rekabetçi avantaj elde etmek için doğru bilgiyi elde etmeleri, bu bilgiyi etkin kullanmaları ve bilginin uygun şekilde evrim geçirmesini sağlayarak takip eden projelere taşımaları gerekmektedir. Bu bildiride YGO ve BTK'lerin örgütsel öğrenimini (ÖÖ) değerlendirmek amacıyla özgün bir model olarak önerilen AiOLoS tanıtılmakta ve gerçekleştirilen farklı uygulamaları özetleyerek genel bir değerlendirme sunulmaktadır. AiOLoS modeli, (a) Öğrenen kuruluşun, örgütsel öğrenme süreci kapsamında takip ettiği ana süreç alanlarını ve temel süreçleri tanımlamakta (b) Kuruluşun örgütsel öğrenme özelliklerini değerlendirmek için gerekli olan ölçüleri ve bunlarla ilgili tanım/yorumları sunmaktadır. Çalışma, AiOLoS'un YGO ve BTK'lerde örgütsel öğrenmeyi değerlendirmek için bir araç olarak uygulanabilirliğini ve yazılımın süreç iyileştirmeye (YSİ) bir çıkış noktası olup olamayacağını göstermek amacı ile geliştirilmiş olan dört farklı durum çalışması ile desteklenmektedir. Sonuçlar, AiOLoS ölçülerinin YGO ve BTK'lerde uygulanabilir olduğunu ve büyük ölçüde organizasyon içinde gerçekleşen ÖÖ'yi ölçebildiklerini göstermektedir. Ayrıca, durum çalışmalarından bir tanesi akademik ortamda geliştirilmiş olup, ÖÖ'nin ölçülmesi haricinde sınıf içi yazılım projelerinde ve yazılım mühendisliği eğitiminde eleştirel düşünmenin uygulanabilirliğini de ortaya koymaktadır. Anahtar Kelimeler. AiOLoS, Örgütsel öğrenme, Öğrenen kuruluşlar, Yazılım mühendisliği eğitiminde eleştirel düşünce

Giriş

Yazılım mühendisliğinin temel amaçlarından biri, hem son ürüne hem de geliştirme sürecine odaklanarak, yazılım geliştiren organizasyonların (YGO) yüksek kalitede yazılım ürünleri geliştirmesine yardımcı olmaktır. Başta CMMI ve SPICE (ISO/IEC 15504) olmak üzere yazılım ürünlerinin ve geliştirme sürecinin kalitesini değerlendirmek için farklı modeller bulunmaktadır. Bunlar, nihai ürünün kalitesinin büyük ölçüde geliştirme ve bakım süreçlerinin kalitesi tarafından belirlendiğini kabul etmektedirler [ 1 ]. Fakat bu modellerden hiç biri YGO’lardaki birey ve takımların örgütsel öğrenmesine (ÖÖ) odaklanmamaktadır.

ÖÖ, organizasyonların devamlılığı için temel bir önkoşul olup [ 2 ], daha sonraki çalışmalarında sürekli bir rekabetçi avantaj elde edebilmeleri için organizasyonlara ihtiyaç duydukları bilgi varlıklarını elde etmeleri için imkân tanımaktadır [ 3, 4 ]. Öğrenme, bilgi ve olgunluğun önkoşulu olup, bu üç kavram birbirleri ile ilişkilidir [ 5 ]. Diğer yandan bilgi, YGO’ların en değerli varlıklarından biri olup iş başarısını doğrudan etkilemektedir [ 6 ]. Teknolojik ilerlemenin çok hızlı olduğu yazılım geliştirme sektöründe YGO’ların doğru bilgiyi elde etmeleri, bu bilgiyi etkin kullanmaları ve sonraki projelere taşımaları önem kazanmaktadır [ 5 ]. Bu üç aşama, Bilgi Yönetiminin (BY) ana süreç alanlarını oluşturduğundan, literatürde farklı kaynaklarda ([ 7-10 ]) BY’nin YGO’lar için öneminden bahsedilmektedir. Her ne kadar öğrenen organizasyon ve öğrenen YGO [ 11 ] terimleri tanımlı olsa da, YGO’ların tüm süreç alanlarındaki ÖÖ kabiliyetlerini ve BY aktivitelerini değerlendirecek, bu kapsamda iyileştirme isteyen alanları ortaya çıkaracak ve bu alanlardaki gelişmeyi izlemeye olanak sağlayacak bir modele ihtiyaç duyulmaktadır [ 12 ]. Bu doğrultuda, yazılım projelerinde ÖÖ’ye olanak tanıyan etkinlikler van Solingen vd. [ 6 ] tarafından listelenmekte olup, Ruhe ve Bomarius da [ 13 ] YGO’larda ÖÖ kabiliyetlerini ölçmek için araçlar geliştirmenin şirketin var olması, yenilenmesi ve büyümesi, üst yönetimin bilgilendirilmesi ve performans kontrolü için öneminin altını çizmektedirler.

Çalışmamızın temelinde şu araştırma soruları yatmaktadır: YGO’ların ÖÖ kabiliyetlerini nasıl modelleyebilir ve değerleyebiliriz? YGO’larda ÖÖ’nin ana süreç alanları nedir? ÖÖ temel süreçleri nasıl ölçülebilir? Bu ölçüm sonuçları yazılım süreç iyileştirme (YSİ) için nasıl kullanılabilir? Yunan mitolojisindeki rüzgâr tanrısından esinlenilerek isimlendirilen AiOLoS (YGO’larda ÖÖ’yi Değerlendirme – Assessing Organizational Learning in Software Development Organizations) modelinin ayrıntılı tanımı, ilgili ÖÖ, BY ve öğrenen organizasyonlar literatürü ile ilişkilendirilmesi ve üç durum çalışması [ 5 ]’te sunulmuştur. Bu durum çalışmalarından birincisi akademik bir ortamda geliştirilmiş olup sonuçları [ 14 ]’de, aynı durum çalışmasına dayanan ve yazılım mühendisliği eğitiminde eleştirel düşüncenin uygulanmasını inceleyen çalışmanın sonuçları ise [ 15 ]’te verilmektedir. Son olarak [ 16 ]’da AiOLoS’un bilgi teknoloji kuruluşlarında (BTK) uygulanabilirliği sınanmakta ve elde edilen sonuçlar tartışılmaktadır.

Bildirinin ikinci bölümünde AiOLoS modelinin genel yapısı, ana süreç alanları ve temel süreçler ile bunlarla ilişkili önerilen ölçüler kısaca verilmektedir. Üçüncü bölümde sırasıyla dört durum çalışması tanıtılmakta ve sonuçları özetlenmektedir. Son bölümde bu durum çalışmalarından elde edilmiş sonuçlar değerlendirilmekte ve sonraki dönemde yapılacak çalışmalar gözden geçirilmektedir. 2

AiOLoS Modeli

AiOLoS modelinin temel amacı YGO’lar arasında ÖÖ kabiliyetleri doğrultusunda bir karşılaştırma çerçevesi sunmak ve nihayetinde YSİ’ye başlangıç noktası olacak şekilde YGO’ların ÖÖ kapsamında eksiklerini saptayıp bu alanda yapacakları ÖÖ iyileştirmelerini izleyebilecekleri ölçüleri tanımlamaktır. AiOLoS, Şekil 1’de göster ildiği üzere üç ana süreç alanından ve 12 temel süreçten oluşmaktadır. Üç ana süreç alanı öğrenme sürecinin devamlılığını göstermek amacıyla literatürde [ 17, 18 ] önerildiği üzere birbirleri ile döngüsel bir şekilde ilişkilendirilmiştir. AiOLoS’u oluşturan ana süreç alanları ve temel süreçlerin tamamı mevcut BY, ÖÖ ve öğrenen YGO liter atüründen, YGO’ların karakteristiklerine olan uygunlukları incelenerek ampirik yöntemlerle seçilmişlerdir. AiOLoS’un literatür ile bağı ve her bir ana süreç alanının ve temel sürecin tanımı [ 5 ]’te ve daha ayrıntılı olarak da [ 19 ]’da verilmektedir. 2.1

AiOLoS Ölçüleri

Chouseinoglou vd.’nin [ 5 ] belirttiği üzere, başta Software Measurement Guidebook ve Goal-Driven Measurement Guidebook olmak üzere yazılım mühendisliği alanında ölçümlerin gerçekleşmesi için takip edilecek yaklaşımların anlatıldığı birçok farklı yöntem mevcut olup, yazarlar [ 5 ] alanda ölçüm yapmanın öneminin altını çizmektedirler. Ayrıca BY sürecinin ölçümü [ 20-22 ] ve ölçüm için seçilecek ölçülerin doğru belirlenmesi [ 23 ] de büyük önem taşımaktadır. Öğrenen YGO’larda ölçüm yapmak için yöntemler Ruhe ve Bomarius [ 13 ] tarafından sunulmaktadır. Bununla beraber, ölçülmeye çalışılan olgular ve kullanılan ölçüm yaklaşımları yeni ise, söz konusu ölçümlerde kullanılacak olan ölçülerin seçilme süreci zor bir girişim olmaktadır [ 17 ]. Bu nedenlerden dolayı literatürde mevcut olan ÖÖ’yi ölçme yöntemleri incelenmiş ve bunların YGO’lara olan uygunluğu değerlendirilmiştir. Bu kapsamda mevcut olan yöntem ve ölçülerin çoğunlukla sübjektif olduğu, bunun da yapılan ölçümün geçerliliğini etkilediği görülmüştür.

Tüm bunlar göz önüne alınarak, AiOLoS’un ölçüleri mevcut literatürdeki öneriler ve yaklaşımlar dikkatle incelenerek oluşturulmuştur. AiOLoS’un 12 temel sürecine yönelik ölçülerin belirlenmesi için hedefe-yönelik bir yöntem olan Goal/Question/Metric (GQM)’in [ 24, 25 ] ve bunun bir türevi olan V-GQM’in [ 26 ] özelleştirilmiş bir şekli kullanılmıştır. GQM’un hedef tanımları için YGO’ların yazılım geliştirme sürecinde kullandıkları aktivitelerden yararlanılmıştır. Bunlar; ─ Kurum içi ve dışı alınan ve verilen eğitimler ─ Toplantılar ─ Yazılım dokümantasyonu geliştirme ─ Yazılım geliştirme ─ Hata düzeltme ─ İletişim ve mesaj gönderimi ve alımı ─ BY araçları ve örgütsel bilgi saklama ve arama araçları ─ Rekabetçi karşılaştırma olarak sıralanabilir.

GQM sürecinin sonucunda AiOLoS için 82 alt ölçev (metric) tanımlanmış olup bunlar daha sonra 39 ölçevde birleştirilmiştir. Tüm GQM süreci, elde edilen ölçevler, ölçev tanımlarının ayrıntıları, önerilen ölçüm formülleri ve her bir ölçevin ÖÖ, BY ve öğrenen YGO literatürü ile ilişkilendirilmeleri [ 5 ] ve [ 19 ]’da verilmektedir. Söz konusu 39 ölçev (ve Durum Çalışması D’de önerilmiş olan KOrg3 ölçevi) kısa bir tanım ve hangi durum çalışmalarında uygulandıkları bilgisi ile beraber Tablo 1’de gösterilmiştir.

Tablo 1. AiOLoS Ölçüleri ve Uygulandıkları Durum Çalışmaları Temel Süreç

Ölçü Bilgi Tanılama

Bilgi Alımı Değerlendirilmiş Harici Dokümanlar KAcq4 Harici Eğitim Yayılımı KAcq5

Yaratıcı Fikir Geliştirme KDev1 Bilgi Geliştirme Yaratıcı Fikir Değerlendirme KDev2

Yatay Doküman İlişkilendirme KOrg1 ÖrgüBtillegnimesi Dikey Doküman İlişkilendirme KOrg2

Doküman İlişkilendirme1 KOrg3 Yönetimden Bilgi Mesajları KDis1

Toplantı Sayısı KDis2 Bilgi Yayılımı Toplantı Süreleri KDis3

Toplantı Tartışma Etkinliği KDis4 Toplantı Yayılım Ölçevi KDis5

Dâhili Dağıtılan Yönergeler KPub1 Bilgi Yayını Harici Dağıtılan Yönergeler KPub2

Akademik Yayınlar KPub3

Yaratıcı Fikir Uygulama KUse1 Bilgi Uygulayımı Çıktı Kalitesi KUse2

Toplantı Fonksiyonel Etkinliği KUse3

Fazlar Arası İşlerin Değişimi KInt1 BütBünillgeişimi Fazlar Arası Çıktıların Değişimi KInt2 Çıktı Düzeltme KInt3 Bilgi Değerlendirme ve Değerlendirme KPD1

Yönergelerden Farklı İşler KPD2 Bilgi Saklama ve Silme Şablonlardan Farklı Çıktılar KPD3

Bilgi Saklama Aracı Kullanımı KPD4

Bilgi Saklama Aracı Etkinliği KPD5 Bilgi Değerlendirme Değerlenmiş Öğeler KEval1

Paylaşılan Dokümanlar KSel1 Bilgi Satışı Paylaşılan İşler KSel2

Verilen Eğitimler KSel3

Projeler Arası Yönerge Evrimi KEvol1 Bilgi Evrimi Projeler Arası İş Evrimi KEvol2

Projeler Arası Çıktı Evrimi KEvol3 √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

√ √ √ √ √ √ √ √ √ √ √

√ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

√ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

√ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √

√ √ √ √ √ √ √ √ 2.2

AiOLoS’un ve AiOLoS Ölçülerinin Uygulanması

AiOLoS YGO’larda farklı oluşumlarda, başlıca yazılım grupları, takımları veya organizasyonun tamamında uygulanabilecek şekilde tasarlanmıştır. Bu kapsamda dört farklı AiOLoS uygulama yaklaşımı mevcuttur: ─ Yatay Değerlendirme: Bir oluşumun ÖÖ kabiliyetleri, takip ettiği yazılım geliştirme süreci içindeki farklı fazlar bazında karşılaştırılmakta (Durum Çalışması B). ─ Dikey Değerlendirme: Farklı oluşumların ÖÖ kabiliyetleri birbirleri ile karşılaştırılmakta (Durum Çalışmaları C ve D) ─ Melez Değerlendirme: farklı oluşumların ÖÖ kabiliyetleri, bu oluşumların her birinin takip ettiği yazılım geliştirme süreci içindeki farklı fazlarla karşılıklı olarak karşılaştırılmakta (Durum Çalışması A) 1 KOrg3 Doküman İlişkilendirme orijinal AiOLoS modelinde [ 5 ] önerilmemiş olup, Durum Çalışması D’de yazarlar tarafından [ 16 ] AiOLoS modelinde verilmiş olan yönteme [ 5 ] dayanılarak yeni oluşturulmuştur. ─ En İyi Uygulamaya Karşı Değerlendirme: bir oluşumun ÖÖ kabiliyetleri, organizasyon tarafından hedef olarak belirlenen veya üçüncü partilerden alınan kriterler ile karşılaştırılmakta.

Her ne kadar AiOLoS ölçevleri YGO’ların takip ettiği ortak ve genel süreçler göz önüne alınarak geliştirilmiş olsa da, önerilen tüm ölçevler her YDO’da uygulanamayabilir. Belli süreçlerin takip edilmemesi, süreçler hakkında veri takibinin ve kaydının yapılmaması veya kaydın kısmi/yetersiz olması, elde edilen verilerin karşılaştırılamaması bu uygulama sorunu için başlıca nedenlerdir. AiOLoS’u uygulamak isteyen YGO’lar sorunlu ölçevler için üç farklı yaklaşımdan birini benimseyebilirler: ─ Ölçevi değerlendirme sürecinden çıkarabilir. ─ Ölçevi ellerinde bulunan mevcut veriye uyacak şekilde uyarlayabilir. ─ Ellerinde bulunan mevcut veri kapsamında yeni ölçevler önerebilir. Chouseinoglou vd. [ 5 ], AiOLoS’u uygulamak isteyen YGO’ların takip ve kayıt etmeleri gereken verileri, elde ettikleri verileri ve özelliklerini değerlendirerek mevcut AiOLoS ölçevlerini nasıl uygulamaları gerektiğini ve takip etmeleri gereken değerlendirme aşamalarını ayrıntılı biçimde açıklamaktadır. 3

Durum Çalışmaları

AiOLoS modelinin uygulanabilirliğini ve önerilen ölçevlerin bir YGO’da ÖÖ kabiliyetlerini ne derecede ölçebildiğini sınamak için ampirik durum çalışmaları tasarlanmıştır. Söz konusu çalışma kapsamında biri akademik ortamda (A), biri kamu kuruluşunda (B) ve biri de özel bir YGO’da (C) olmak üzere üç durum çalışması yapılmıştır. AiOLoS’un BTK’larda uygulanabilirliğini sınamak için de ayrı bir durum çalışması (D) Özen vd. [ 16 ] tarafından gerçekleştirilmiştir. Durum çalışmalarının de tayları Tablo 2’de, önerilen ölçevlerinden hangilerinin hangi durum çalışmasında kullanıldığı bilgisi Tablo 1’de sunulmuştur. Durum çalışmaları ile ilgili geçerlilik tehditleri ve durum çalışmalarının genellenebilirliği [ 5, 14, 15, 16 ]’da tartışılmıştır. 3.1

Durum Çalışması A – Sınıf Örneği

AiOLoS modelinin genel yapısının ve önerilen ölçülerin uygulanabilirliğini sınamak için Başkent Üniversitesi, İstatistik ve Bilgisayar Bilimleri Bölümü’nde verilmekte olan ve bir dönemlik yazılım mühendisliği proje dersi olarak tasarlanmış olan İST478 dersi Durum Çalışması A olarak kullanılmıştır. Dersin genel yapısı Southern California Üniversitesi’nde 1996 yılından bu yana verilmekte olan ve farklı doktora tezi çalışmalarında test ortamı olarak kullanılan CSCI577ab dersinden [ 27, 28 ], ilgili öğre tim elemanlarının izni alınarak, birebir kullanılmıştır. İST478 dersi, mümkün olduğunca gerçeğe yakın bir müşteri ve müşteri gereksinimleri tanımlanarak tasarlan mış olup, içinde ders anlatma (lecturing) bulunan uygulamalı bir proje dersi (practicum) [29, 30] olarak tanımlanabilir. İST478 dersinde ICSM yazılım geliştirme sürecinin aşamaları takip edilmiş olup, ICSM-EPG’de [31] tanımlanan görevler ve çıktılar/teslimatlar proje grupları tarafından önceden belirtilmiş olan aralıklarda hazırlanarak teslim edilmiştir. Dönem başında lisans (15) ve lisansüstü (4) öğrencilerden oluşan dört proje grubu oluşturulmuş, bu gruplardan sadece üçü ders izlencesine uy gun çıktılar teslim etmişlerdir. Projeler kapsamında takip edilen ICSM’in beş fazında elde edilmiş olan AiOLoS ölçülerinin değerleri ayak izi grafikleri olarak Şekil 2’de gösterilmiştir. Durum çalışmasının detayları, dersin işlenişi, takip edilen aşamalar, öğrenci ve AiOLoS değerlendirmesini yapan öğretim elemanının işgücü analizleri Chouseinoglou ve Bilgen tarafından [ 14 ]’te verilmektedir.

Tablo 2. Durum Çalışmalarının Detayları

Durum Çalışması A Empoze edildi Kurgu Gayrı resmi - Keşifçi - Eylem Araştırması 15 lisans ve 4 lisansüstü öğrenci Çıkış Yetki Bağlam Biçim Araştırma Metodu Veri Toplama Yarı-yapılı 7 Görüşmeler Anket 8 Geçmiş Veriler Yok Araştırma Süresi 4 ay Görüşmelere Alınan 19 Kişi Durum Çalışması Bağlam Bilgileri Takım Sayısı 4 Takım Üye Sayıları 4-6 Eğitim Seviyesi Orta Alan Uzmanlığı Düşük Proje Yöneticilerin Orta Uzmanlığı

Durum Çalışması B İşbirliği ile İş sahibi Araştırmacı  Kurum Resmi - Betimleyici - İyileştirme modu - Sörvey Kamu YGO 8 1 Var – Doğrudan alındı 1 ay 7 1 46 Yüksek Yüksek Yüksek

Durum Çalışması C İşbirliği ile İş sahibi Resmi - Betimleyici - İyileştirme modu - Sörvey Özel YGO

Durum Çalışması D İşbirliği ile İş sahibi Araştırmacı  Kurum Resmi - Betimleyici - İyileştirme modu - Sörvey Özel BTK 2 3 Yok 1 ay 4 3 3-20 Yüksek Yüksek Yüksek 2 1 Kısmen 15 gün 5 4 5-13 Yüksek Yüksek Yüksek

Yazılım mühendisliği eğitiminin günün hızla değişen ihtiyaç ve koşullarına cevap verebilecek, çözümler üretebilecek öğrenciler mezun etmesi gerektiği, ama klasik yazılım mühendisliği eğitiminin buna cevap veremeyeceği açıktır. Chouseinoglou ve Bilgen [ 15 ], eleştirel düşünce becerilerinin yazılım mühendisliği proje derslerinde öğrencilere kazandırılabileceğini ve öğrencilerin problem çözme becerilerine katkı sağlayabileceğini sınamak amacı ile AiOLoS kapsamında gerçekleştirilen Durum Çalışması A’da ayrıca bu konuya da değinmektedirler. Edebiyat, sanat ve benzeri sosyal ve okumaya dayalı alanlarda eleştirel düşünme becerilerini artırmak için uygu lanan bir yöntem olan SQ4R [32, 33] (Gözle, Sor, Oku, Yansıt, Cevapla, Yeniden gözden geçir) bu durum çalışması içinde dört gruptan ikisi tarafından uygulanmış olup, bu uygulamanın sonuçları [ 15 ]’te tartışılmıştır. Durum Çalışması A sürecinde, SQ4R uygulayan gruplar, proje kapsamında üretmeleri gereken temel çıktılar öncesinde söz konusu çıktı hakkında bir araştırma yapıp devamında buldukları bil gilere dayanarak söz konusu çıktının önemini kısa bir yansıma makalesi yazarak Soru S1) SQ4R’ın ders konularını daha iyi öğrenmenize yardımcı olduğunu düşünüyor musunuz? S2) SQ4R’ın ders konularını projenize uygulamanızda yardımcı olduğunu düşünüyor musunuz? S3) Sizce SQ4R projenizi geliştirmenizde size bir avantaj sağladı mı? S4) Sizce SQ4R’ı gerçekleştirmek için sarf ettiğiniz ek işgücüne/zamana değer miydi? S5) Sizce elde ettiğiniz bilgileri daha sonraki profesyonel yaşamınıza taşımada SQ4R yaklaşımının katkısı olacak mı? 2 3 1 4 8 6 9 6 6 sorgulamışlardır. Devamında ders sorumlusu tarafından çıktı ve ilgili süreçler hakkında dokümantasyon ve kılavuzlar dağıtılarak bunlar öğrenciler tarafından okunup, sınıf içinde yapılan yansıtma toplantıları ile neler anladıkları ders sorumlusu nun koordinasyonunda sınıfla paylaşılmıştır. Çıktı ve ilgili süreçler bu bilgilere dayanılarak geliştirilip öğrenciler sınıf içinde bir tartışma toplantısı yaparak ders so rumlusunun sorularına cevap verdikten sonra, söz konusu çıktı ile ilgili süreçler hakkında ve projedeki yeri ile ilgili bir yeniden gözden geçirme raporu hazırlayıp sun muşlardır. Takip edilen SQ4R sürecinin kısa bir anlatımı Şekil 3’te verilmektedir.

Buna benzer bir yöntem ile daha önce çalışmamış olan öğrenciler ders sonunda SQ4R’ın öğrenme süreçlerine yaptığı katkıyı tanımlamak için bir anket doldurmuş olup, öğrenci görüşlerinin yansıtıldığı anketin sonuçları Tablo 3’de verilmektedir.

Tablo 3. SQ4R ile İlgili Öğrenci Görüşleri

Tam Çoğunlukla Durum Çalışması B, ODTÜ Bilgi İşlem bünyesinde gerçekleştirilmekte olan Bütün leşik Bilgi Sistemi (BBS) proje ekibi ile 01.01.2009 ile 31.07.2012 tarihleri arasında AiOLoS’un Yatay Değerlendirme Yöntemi kullanılarak ve projenin dört fazından elde edilen geçmiş veriler kullanılarak uygulandı. BBS program yöneticisinin AiOLoS denetçisine sağladığı destek ile proje kapsamında oluşturulan dokümanlar, içerikler, toplantı tutanakları, eğitim kayıtları vb. incelenmiş olup, ilgili tüm veriler AiOLoS ölçevlerine girdi olarak kullanılmıştır. AiOLoS’a girdi sağlamış olan maddeler ve bunların işlenmesi için harcanan işgücü Tablo 4’te verilmektedir. BBS projesi kapsamında takip edilen dört fazdan elde edilmiş olan AiOLoS ölçevlerinin değerleri ayak izi grafiği olarak Şekil 4’te gösterilmiştir. 2 2 1 Şekil 2. Durum Çalışması A – ÖÖ Ayak İzi Grafikleri

Şekil 3. İST478’te Uygulanan SQ4R Yaklaşımı

AiOLoS değerlendirmesinden elde edilmiş olan sonuçlar BBS üst yönetimi ile görüşülmüş olup, üst yönetim bunların doğruluğunu ve geçerliliğini onaylamıştır. Bu görüşmelerin sonucunda varılan çıkarımlar aşağıda özetlenmektedir: ─ BBS ekibi, Bilgiyi Edinme ana süreç alanında yüksek puanlar elde etmekte, bunun temel nedeni BBS projesinin ODTÜ Bilgi İşlem çalışanlarına çok yabancı olması olarak görülmekte. Her ne kadar eğitim puanları yüksek olsa da, ekip içinde sürekli aynı kişilerin eğitim almasından dolayı Harici Eğitim Yayılımı (KAcq5) çok düşük sonuç vermekte. ─ Geliştirilen dokümanlar arasındaki ilişkilendirmelerin ve bağıntıların eksik ve yetersiz olmasından dolayı Bilgi Örgütlenmesi değerleri düşük çıkmakta. ─ BBS takımı düzenli ve sık toplantılar gerçekleştirdiği için Bilgi Yayılımı değerleri yüksek hesaplanmakta. Fakat bu alan ile ilgili ölçülerin (KDis2, KDis3, KDis4, KDis5) girdilerini toplarken tecrübe edilen sorunlar üst yönetime muhtemel iyileştirme alanı olarak iletilmiştir: a) Her toplantının tutanakları tutulmamakta (örneğin Faz 3’te 154 toplantının sadece 25’inin tutanağı tutulmuş) ve dolayısıyla önemli bilgiler kaybolmakta b) Tutanakları yazma ve saklama ile ilgili mevcut yöntemler etkisiz kalmakta c) Toplantılarda öne sürülen fikirler kayıt altına alınmamakta. ─ Toplantı tutanaklarında saklanmakta olan bilgi parçacıklarının eksik olmasından dolayı BBS takımı, Bilgi Uygulayımı temel sürecinde gerçekleşenden daha yüksek puanlar elde etmekte. ─ Fazlar arası işler ve dokümanlar tekrar etmediği için Bilgi Bütünleşimi temel sürecinde BBS takımı düşük puanlar elde etmekte. ─ BBS takımı bilgi arşivleme ve saklama ile ilgili birçok farklı aracı etkin bir şekilde kullandığı için Bilgi Saklama ve Silme temel sürecinde yüksek puan elde etmekte. ─ BBS takımı çalışanları, BBS proje yöneticileri tarafından belirlenmiş olan ve proje süresince çalışanların elde etmesi beklenen 69 farklı öğrenme çıktısını KEval1 ölçüsü için değerlediler. Fazlar arası KEval1 değerinin sürekli azaldığı görülmekte. Bunun temel nedeni projenin ilerlemesi ile iş ve görevlerin farklılaşması ve son fazlarda öğrenim çıktılarının artması olarak tespit edildi. ─ BBS projesi tamamlanmaya uzak olduğu için BBS takımının Bilgiyi Aktarma ana süreç alanında düşük puanlar elde etmesi anlamlı kabul edilmekte.

Tablo 4. Durum Çalışması B –AiOLoS’u Uygulama İşgücü İncelenen madde sayısı

Toplam inceleme süresi (kişi/saat olarak) Durum Çalışması C, özel sektöre ait bir YGO’da gerçekleştirilmiştir. Kurumun adının açıklanmasını istememesinden dolayı bu bildiride YGO X olarak isimlendirilmiştir. YGO X’nin bünyesinde bulunan üç yazılım takımı AiOLoS değerlendirmesinde yer almış olup her bir takımın özellikleri Tablo 5’te verilmektedir. Takımların gerçek leştirdikleri projeler aynı fazları takip etmediği için bu durum çalışmasında AiOLoS’un Dikey Değerlendirme Yöntemi kullanılmıştır. AiOLoS ölçülerine girdiler, geçmiş veriler yerine proje yöneticilerine ve takım üyelerine dağıtılan anketler ve onlarla yapılan görüşmeler aracılığı ile toplanmıştır. Üç yazılım takımından elde edilmiş olan AiOLoS ölçülerinin ayak izi grafikleri Şekil 5’te gösterilmiştir.

Tablo 5. Durum Çalışması C – Değerlenen Proje ve Takımlar Takım No

Değerlendirme

Süresi 1

AiOLoS değerlendirmesinden elde edilen sonuçlar takım liderleri ve proje yöneti cileri ile birlikte incelendiğinde aşağıdaki çıkarımlara ulaşılmıştır: ─ Takım 1’in az sayıda üyeden oluşması; bilgiyi elde etme, kullanma ve taşımada diğer takımlara göre çoğunlukla daha avantajlı olduğunu göstermiştir. ─ Takım 1, gerçekleştirdikleri proje hakkında ön bilgiye sahip olan ve sayıca daha az elamandan oluştuğu için Bilgiyi Edinme ana sürecinde diğer takımlara göre daha yüksek puanlar elde etmekte. Takım 1’in gerçekleştirdiği proje iyi tanımlı bilgi parçacıklarının kullanımına ve uluslararası standartların uygulanmasına dayandığı için Bilgi Alımı temel sürecinde de yüksek puanlar elde etmekte. ─ Değerlendirme sonucunda Takım 2’nin yürüttüğü projenin özelliklerinden dolayı üst yönetimden aldığı bilgi içerikli mesaj sayısının çok fazla olduğu ortaya çıkmıştır. Takım 1 toplantılarda daha çok sorun çözebilirken, Takım 3’ün toplantı sürelerinin göreli olarak daha uzun olduğu görülmüştür. ─ Takım 1’in yürüttüğü proje kapsamında ürettiği dokümanlar organizasyon genelinde dağıtıldığı için Bilgi Yayını temel sürecinde çok yüksek puanlar elde etmekte. ─ Üç takım da Çıktı Düzeltme (KInt3) ölçüsünde yüksek puanlar elde etmekte.

Takım 1’in yaptığı işler standartlara uyulduğu ve değişmediği için KInt1 ve KInt2 sıfır olarak değerlenmekte. Takım 2 ve 3’ün de düşük puan almasının nedeni işleri ve görevleri zaman içinde çok yavaş değiştirmeyi tercih ettikleri şeklinde açıklanmakta. Aynı nedenlerden dolayı KPD2 ve KPD3’te düşük puanlar elde edilmekte. ─ Bilgi saklama araçları kullanım oranlarının üç takım için de yüksek olduğu görülmüştür, bunun nedeni takımların söz konusu araçları büyük bir özen ve dikkatle kullanmaları olarak açıklanmakta. Takım 3’ün KPD5 puanının düşük olmasının nedeni, proje ile ilgili birçok bilgi parçacığının sadece toplantı tutanaklarında saklanıyor olması. ─ Projelerin doğasından dolayı üç takım da Bilgi Satışı temel sürecinde, Verilen Harici Eğitimler dışında, düşük puanlar elde etmekte. Projelerin sonlanmasına yaklaştıkça verilen eğitim sayısının arttığı gözlemlenmekte. ─ Takım 1 uluslararası standartlara dayanarak proje geliştirdiği için Bilgiyi Aktarma ana süreç alanındaki ölçülerin uygulanılamayacağını belirtmiştir. Takım 2 ve 3’ün proje yöneticileri bir sonraki projelerde doküman şablonlarını olduğu gibi ve çıktıları da sadece %10 değişiklik ile kullanabileceklerini belirttiler.

Elde edilen tüm bulgular üç proje yöneticisi tarafından doğrulanmıştır.

Şekil 5. Durum Çalışması C – ÖÖ Ayak İzi Grafikleri 3.4

Durum Çalışması D – BTK Takımları

Özen vd. [34] özellikle ITIL ve benzeri servis yönetim metodolojileri kullanan BTK’lerde ÖÖ’nin ve BY’nin öneminden bahsetmekte, BTK ve YGO’lar arasındaki ÖÖ perspektifinde benzerliklerin altını çizmektedirler. Yazarların [34] bu ihtiyaç ve benzerliklerden yola çıkarak gerçekleştirdikleri çalışmada AiOLoS’un temel süreçleri ve özelleştirilmiş ölçüleri ile bir ÖÖ kabiliyet değerlendirmesi, Türkiye’nin önde ge len BTK’larından birinde uygulanmıştır. Organizasyon adının açıklanmasını istemediği için bu bildiride BTK X şeklinde isimlendirilmiştir.

Durum Çalışması D, AiOLoS ile ilgili birkaç önemli noktaya katkı sağlamıştır. Bunlardan ilkinin, AiOLoS’un YGO haricinde başka organizasyonlarda da (özellikle bilgi yoğun iş yapan organizasyonlar) kullanılabilir olduğu gözlemlenmiştir. Ayrıca Chouseinoglou vd.’nin [ 5 ] önermekte olduğu ölçülerin uygulanmadan önce kontrol edilmesi ve değerlenmesi sürecinin de çalıştığı, ayrıca ölçülerin başarılı bir şekilde ihtiyaçlar doğrultusunda özelleştirilebildiği ortaya çıkmıştır.

Dört BT takımından elde edilmiş olan AiOLoS ölçülerinin ayak izi grafikleri Şekil 6’da gösterilmiştir. AiOLoS değerlendirmesinden elde edilen sonuçlar takım liderleri ve proje yöneticileri ile incelendiğinde aşağıdaki çıkarımlara ulaşılmıştır: ─ Takım 1’in çoğu ana süreç alanında yüksek puanlar almasının temel nedeni takımiçi ve takım-dışı iletişim becerilerinin yüksek olması olarak açıklanmıştır. Müşteriye ürün teslimatında bulundukları için eğitim dokümantasyonları hazırlamaları ve değerlendirme süresi içinde takıma iki yeni üyenin katılmasından dolayı da takım içi eğitimlerin verilmesi Takım 1’in ÖÖ değerlerini yükseltmiştir. ─ Takım 2’nin eğitim programlarına dâhil olmak yerine “iş yaparak öğrenme yöntemini” seçtiği ve iş yüklerinin yüksek olmasından dolayı dokümantasyon üretemediği ortaya çıkmıştır. ─ Takım 3 sınırlı sayıda personel ile kritik işlemler gerçekleştirdiği için dokümantasyon hazırlama ve harici eğitimlere zaman ayıramadığı anlaşılmıştır. ─ Takım 4, diğer takımlara göre daha fazla üyeden oluştuğu için toplantılara daha fazla süre ve işgücü ayırmakta olup, bu ölçülerde daha yüksek değerler elde etmektedir. Ayrıca, sağladıkları hizmetler kapsamında müşterilere talimatlar ve benzeri dokümanlar hazırladıkları için bu alanda da yüksek değerler elde etmektedirler. 3.5

Uzman Görüşleri

Durum çalışmalarının tamamlanmasından sonra, üst yönetim sorumluları ile takım ve proje liderleri AiOLoS modeli ve her bir durum çalışmasında elde edilmiş sonuçlar hakkında bilgilendirildiler. Takım ve proje liderleri, kendi takım ve projelerinde elde edilmiş olan değerlendirme sonuçları ve kendi bilgileri dâhilinde olan gerçek ÖÖ’yi karşılaştırarak, AiOLoS’un YGO’larda ÖÖ’yi ne kadar iyi ölçtüğünü (Tablo 6) ve BTK’larda uygulanıp uygulanamayacağını (Tablo 7) dört soruya Likert ölçeğinde cevaplar vererek değerlendirmeleri istenmiştir. AiOLoS kapsamında gerçekleştirilmiş olan durum çalışmaları niteliksel çalışmalar olduğu için genel geçer bir kuram ortaya konulması söz konusu değildir. Bu nedenden dolayı ancak “olgun hipotezler”in oluşturulması hedeflenmiş, bu çerçevede, yapılan örnek durum çalışmalarının yeterli değerlendirme sağladığı görülmüştür.

Şekil 6. Durum Çalışması D – ÖÖ Ayak İzi Grafikleri Tablo 6. Durum Çalışması A, B, C – Uzman Görüşleri2

Tam S1) AiOLoS BTK’ların ÖÖ kabiliyetlerini ölçmekte midir? S2) Değerlenmiş olan ÖÖ kabiliyetleri BTK’ya rekabetçi avantaj sağladığını düşünüyor musunuz? S3) Yapılmış olan ölçümler ve elde edilmiş olan ayak izleri takımların ÖÖ kabiliyetlerini ölçmekte midir? S4) AiOLoS ile değerlenen ÖÖ kabiliyeti süreç iyileştirme için kullanılabilir mi? 4

Sonuç ve Öneriler

AiOLoS modelinin ana süreçleri, mevcut ÖÖ, BY ve öğrenen organizasyon literatür leri incelenerek, bunların YGO’lara olan uygulanabilirliği değerlendirilerek ve ihtiyaç duyulan detay seviyesinde temel süreç alanları oluşturularak hazırlanmıştır. AiO LoS’un ana ve temel süreçleri söz konusu ilgili literatürlerden elde edilmiş olup daire sel yapısı ÖÖ’nin sürekliliğini göstermektedir. Mevcut olan diğer ÖÖ yaklaşımlarına göre AiOLoS daha nesnel ve YGO’ların ihtiyaçlarına yönelik ölçevler kullanmaktadır. Bilgi Değerlendirme temel süreci haricinde tüm temel süreçlerin birden fazla ölçev ile ölçülebileceği önerilmekte, gerektiğinde yeni ölçevlerin önerilmesi veya mevcut ölçevlerin değiştirilmesi için mekanizmalar sunulmaktadır. Ölçümlerin gerçek ÖÖ’yi değerleyebildiği ve YSİ için bir çıkış noktası oluşturabileceği üç farklı durum çalışması ve uzman görüşleri ile ortaya çıkmaktadır. Bu noktada AiOLoS’un YSİ için çıkış noktası olabilmesi için YSİ ile bağlarının oluşturulması ve bunların formal olarak tanımlanması bir sonraki çalışma olarak hedeflenmektedir. Ayrıca AiOLoS’un mevcut yazılım olgunluk modelleri ile ilişkilendirilmesinin yapılması ve farklı seviyelerdeki YGO’ların ÖÖ kabiliyetlerinin nasıl değiştiğinin incelenmesi de önemli bir araştırma konusu olarak durmaktadır. Bunun haricinde, YGO’larda büyük oranda gayri resmi yollardan gerçekleşen ÖÖ’yi de ölçebilecek yeni ölçevlerin geliştirilmesi de ayrıca önem arz etmektedir.

Durum Çalışması A’da uygulanmış olan eleştirel düşünce yaklaşımından tecrübe edildiği üzere, her ne kadar çalışma istatistiksel anlamlı sonuçlar üretmemiş olsa da, proje ve ders anlatım tabanlı yazılım mühendisliği derslerine eleştirel düşünce yön

Üstsimgeler ilgili durum çalışmasını ifade etmektedir teminin uygulanmasının öğrenme ortamına katkı sağladığı görülmüştür. Bu kapsamda, daha fazla yazılım mühendisliği proje dersi üstünde eleştirel düşünce yaklaşımlarının uygulanması gelecek çalışma olarak hedeflenmektedir.

Yapılan dördüncü bir durum çalışması ile AiOLoS’un YGO’lar haricinde BTK gibi teknoloji tabanlı başka organizasyonlarda da uygulanabildiği ve gerçekleşen ÖÖ’yi büyük oranda ölçebildiği gözlemlenmiştir. Bu çalışma ayrıca AiOLoS’un farklı organizasyon yapılarında hızlı ve kolay bir şekilde uygulanabildiğini, elde edilen sonuçların BTK’larda süreç iyileştirme için kullanılabileceğini göstermiştir. BTK’lar ile ilgili olan çalışmaların sayısının artırılması, elde edilen sonuçlar doğrultusunda AiOLoS’un mevcut BTK olgunluk ve servis yönetim modelleri ile ilişkilendirilmesi gelecekteki çalışmalar olarak planlanmıştır.

Kaynaklar

28. S. Koolmanojwong ve B. Boehm, "Using Software Project Courses to Integrate Education and Research: An Experience Report", Proceedings of the 22nd Conference on Software Engineering Education and Training (CSEET 09), Hyderabad, India, 2009. 29. E. P. Katz, "Software engineering practicum course experience", 23rd IEEE

Conference on Software Engineering Education and Training (CSEE&T), IEEE, 2010. 30. R. Bareiss ve E. Katz, "An exploration of knowledge and skills transfer from a formal software engineering curriculum to a capstone practicum project", 24th IEEE-CS Conference on Software Engineering Education and Training (CSEE&T), IEEE, 2011. 31. USC-CSSE, "Instructional Commitment Spiral Model - Software Electronic Process Guide", USC Viterbi School of Engineering, 2008. Çevrimiçi, 30.6.2012 tarihinde erişilmiştir. Erişim adresi: http://greenbay.usc.edu/IICMSw/index.htm 32. E. L. Thomas ve A. H. Robinson, Improving Reading in Every Class: A Sourcebook for Teachers, Boston: Allyn & Bacon, 1982. 33. S. M. Glynn ve D. K. Muth, "Reading and writing to learn science: achieving scientific literacy", Journal of Research in Science Teaching, cilt 31, sayı 9, s.10571073, 1994. 34. G. Özen, "A Study to Assess Learning Capabilities of IT Organizations by Using AiOLoS Model," Teknik Rapor: METU/II-TR-2013-03, Enformatik Enstitüsü, Orta Doğu Teknik Üniversitesi, Ankara, Türkiye, 2013.

References

1. M. C. Paulk , C. V. Weber , B. Curtis ve M. B. Chrissis , The Capability Maturity Model: Guidelines for Improving the Software Process , Boston: Addison-Wesley, 1995 .

2. D. H. Kim , "The Link between Individual and Organizational Learning" , Sloan Management Review, cilt 35, sayı 1, s.37-50 , 1993 .

3. K. Chang Lee , S. Lee ve I. W. Kang , "KMPI: Measuring Knowledge Management Performance" , Information & Management, cilt 42 , sayı 1, s. 469 - 482 , 2005 .

4. J. M. Sinkula , W. E. Baker ve T. Noordewier , "A Framework for Market-based Organizational Learning: Linking Values, Knowledge, and Behavior" , Journal of the Academy of Marketing Science, cilt 25, sayı 4, s.305-318 , 1997 .

5. O. Chouseinoglou , D. İren , N. A. Karagöz and S. Bilgen , "AiOLoS: A Model for Assessing Organizational Learning in Software Development Organizations" , Information and Software Technology , 2013 doi: 10.1016/j.infsof. 2013 . 05 .004.

6. R. van Solingen, E. Berghout , R. J. Kusters ve J. Trienekens , "From process improvement to people improvement: enabling learning in software development" , Information and Software Technology, cilt 42, sayı 14, s.965-971 , 2000 .

7. L. Mathiassen , J. Pries-Heje ve O. Ngwenyama , Improving Software Organizations: From Principles to Practice, Redwood City, CA: Addison Wesley Longman Publishing Co., 2001 .

8. J. García , A. Amescua , M.-I. Sánchez ve L. Bermón , "Design guidelines for software processes knowledge repository development" , Information and Software Technology, cilt 53, sayı 8, s.834-850 , 2011 .

9. T. Dingsøyr ve R. Conradi , "A Survey of Case Studies of the Use of Knowledge Management in Software Engineering" , International Journal of Software Engineering and Knowledge Engineering , cilt 12 , sayı 4, s. 391 - 414 , 2002 .

10. A. Aurum , F. Daneshgar ve J. Ward , "Investigating Knowledge Management practices in software development organisations - An Australian experience" , Information and Software Technology, cilt 50, sayı 6, s.511-533 , 2008 .

11. G. Ruhe, "Learning Software Organisations", Handbook of Software Engineering and Knowledge Engineering, cilt 1 , S. K. Chang , Dü., World Scientific Publishing 2001 , 2001 , s. 663 - 678 .

12. G. Ruhe, "Software Engineering Decision Support - A New Paradigm for Learning Software Organizations" , Advances in Learning Software Organizations (4th International Workshop , LSO 2002), Chicago, IL, USA, 2003 .

13. G. Ruhe ve F. Bomarius , "Overview" Learning Software Organizations Methodology and Applications (11th International Conference on Software Engineering and and Knowledge Engineering, SEKE'99), Kaiserslautern, Germany, 1999 .

14. O. Chouseinoglou ve S. Bilgen, "A Model for Assessing Organizational Learning in Software Development Organizations" , 4th International Conference on HumanCentred Software Engineering (HCSE 2012 ), Toulouse. Lecture Notes in Computer Science 7623, s. 251 - 258 , 2012 .

15. O. Chouseinoglou ve S. Bilgen, "Introducing Critical Thinking to Software Engineering Education" , 11th International Conference on Software Engineering Research, Management and Applications (SERA 2013 ) Prague, 2013 . Studies in Computational Intelligence, cilt 496 , s. 55 - 72 , 2014 .

16. G. Özen, N. A. Karagöz , O. Chouseinoglou ve S. Bilgen, "Assessing organizational learning in IT organizations: an experience report from industry" , MENSURA 2013 ' e sunum için kabul edilmiştir .

17. S. Lähteenmäki , J. Toivonen ve M. Mattila , "Critical Aspects of Organizational Learning Research and Proposals for Its Measurement" , British Journal of Management , cilt 12 , sayı 2, s. 113 - 129 , 2001 .

18. R. Maier , Knowledge Management Systems: Information and Communication Technologies for Knowledge Management , New York: Springer-Verlag, 2004 .

19. O. Chouseinoglou ve S. Bilgen, "Organizational Learning Assessment in Software Development Organizations", Teknik Rapor: METU/II-TR- 2012 -02, Enformatik Enstitüsü , Orta Doğu Teknik Üniversitesi, Ankara, Türkiye, 2012 .

20. M. Demarest , "Understanding Knowledge Management" , Journal of Long Range Planning, cilt 30, sayı 3, s.374-384 , 1997 .

21. P. K. Ahmed , K. K. Lim ve M. Zairi , "Measurement Practice for Knowledge Management" , Journal of Workplace Learning, cilt 11, sayı 8, s.304-311 , 1999 .

22. C. Armistead , "Knowledge Management and Process Performance" , Journal of Knowledge Management, cilt 3, sayı 2, s.143-157 , 1999 .

23. M. Oliveira ve V. Goldoni , "Metrics for Knowledge Management Process" , IAMOT 2006 15th International Conference on Management of Technology , Beijing, 2006 .

24. V. R. Basili , G. Caldiera ve D. H. Rombach , "Goal Question Metric Paradigm" , Encyclopedia of Software Engineering, J. J. Marciniak , Dü., New York, John Wiley & Sons, 1994 , s. 528 - 532 .

25. R. van Solingen ve E. Berghout , The Goal/Question/Metric Method: A Practical Guide for Quality Improvement of Software Development , London: McGraw-Hill Publishing , 1999 .

26. T. Olsson ve P. Runeson , "V-GQM: A Feed-Back approach to validation of a GQM study" , Proceedings of Seventh International Software Metrics Symposium, METRICS 2001 , 2001 .

27. B. Boehm ve S. Koolmanojwong, " Software Engineering I - Fall 2011 ", USC Viterbi School of Engineering, Çevrimiçi, 30 . 6 .2012 tarihinde erişilmiştir . Erişim adresi: http://greenbay.usc.edu/csci577/fall2011/index.php