Almanya - Karlsruhe UIR Hava Trafik Kontrolü MerkezindeYazılım Yaşam Döngüsü Standartlarının Uygulanışı

The Application of Software Lifecycle Standards at Karlsruhe UIR ATC Center - Germany

Ali Rıza, Saral
SPD İletişim AŞ, Istanbul

Özet
Bu makale, Almanya – Karlsruhe UIR (Üst Hava Sahası) Hava Trafik Kontrolü Merkezinde [1] yazılım yaşam döngüsü standartlarının uygulanış şeklini ve buna ilişkin geçiş döneminde EUROCONTROL – STK (Avrupa Hava Seyrüsefer Güvenliği Kuruluşu – Karlsruhe Yazılım Ekibi) tarafından uygulanan yaklaşımı ele almaktadır.

Abstract
This article studies the application of software lifecycle standards by the EUROCONTROL – STK (European Organisation for the Safety of Air Navigation – Software Team Karlsruhe) at Karlsruhe UIR (Upper Information Region) ATC (Air Trafic Control) Center and its approach during the transition period.

1. Giriş
Karlsruhe UIR ATC Merkezinin geçmişi 2. Dünya savaşı sonrasına kadar uzansa da bugünkü hali ile aslen EUROCONTROL tarafından kurulmuştur. Şu anda Alman ATC kuruluşu DFS (Deutsche Flug Zicherung)’un kontrolündedir. EUROCONTROL ise yazılım ekibi ile sistemin bakım ve genişletilişini yapmaktadır. Sistem gelişimi 1980’lerden geç 1990’lara kadar sürmüştür. Şu anda yalnız bakım ve zorunlu genişletişler yapılmaktadır.

Bu yazının ele aldığı, yazılım hayat döngüsü standartları uygulanışına geçiş 1990 – 1997 dönemini kapsamaktadır. Söz konusu dönemde günde 1500 uçak olan trafik yükü bu gün 3500 (tepe noktası) civarındadır.
Sistemin başarısı her gün yüzbinlerce kişinin can ve mal güvenliğini doğrudan etkilemektedir. Sistem 7/24 esasına göre ve yüksek güvenilebilirlik hedefleri ile çalışmaktadır.

2. Yaşam Döngüsü Standartlarının Uygulanışı
1992 yılında, EUROCONTROL-STK’in çalışmaları yer yer tıkanış aşamasına gelmişti. 30 kişilik bir yazılım ekibi paralel olarak aynı zamanda sistemin bakım ve geliştirişini yapıyor, bunun yanında Amerikan Hughes firması ve diğer firmalardan sözleşmeli personel ile radar konsol ve diğer özel ayrık projeler yapılmağa çalışılıyordu.
2.1. Eleman profili ve eğitim çalışmaları
Ekip 1980’lerde toplanmış, bir süre Paris’te çalışılmış. Daha sonra Karlsruhe’ye gelinmiş. Bu grup en yaşlı nesili oluşturuyor. Yaşları 50 – 60 arasında 1992 – 1997 dönemi itibarı ile. Az sayıda sonradan alınmış 40 – 50 yaş grubu ve yine az sayıda genç 30 – 40 yaş grubu var. Yaşlı gruplar arasında Matematik, Fizik doktorası sahibi olan ve teknik yöneticilik yapanlar var. STK müdürü eski bir hava trafik kontrolcüsü.

Standartların uygulanışına geçiş açısından yazılım mühendisliği eğitimi almamış bir kadro önemli bir dezavantaj. Her gün yoğun operasyonel yük altında zorlanan ekipteki direnişi kırmak amacı ile object oriented programming concepts, analysis ve design, üç ayrı birer haftalık kurs, yakında fakat başka bir kurumun çatısı altında düzenlendi. Faydalı da oldu.

2.2. İşe yaramayan ve Kullanılmayan Dökümanlar
STK içinde EUROCONTROL merkezi yönetiminin teşviki ile çok sayıda hiçbir işe yaramayan doküman yaratıldı [4].

Harici olarak başka kurum ve kuruluşların yaratmış olduğu, ESA Software Engineering, Alman V-Model ve çeşitli EUROCONTROL, “IEEE 1074 Standard for Developing Life Cycle Processes” gibi dökümanlar STK içinde çeşitli zamanlarda dolaşıma sokuldu ve kişisel olarak tartışıldı. Yönetimin IEEE 1074 üzerinde yoğunlaştığı gözlendi.

2.3. Örgütlenme Yaklaşımları
Bu süreç içinde yönetim bir Kalite Yöneticisini işe aldı ve görevlendirdi. Kalite yöneticisi havacılık dışı bir alandan geldiği için Hava Trafik Kontrolü konularına hakim değildi ve 1-2 ay gibi çok çok kısa süre içinde istenenleri başaramadı.

Gençlerden oluşturulan bir Yazılım Kalitesi grubu da operasyonel bilgi ve tecrübe eksikliğinden yaşlı grupla mücadele edemedi. Uluslararası bir ortamda bu tür süreçlerin bir dezavantajı da iletişimde yaşanan güçlük, ilgililerin İngilizce hakimiyetinin karışık politik ve teknik konularda amaçlarına ulaşmalarını mümkün kılacak bir düzeyde olmamasıdır.

2.4. Harici firmalara Yaptırılan İşler
Aşırı operasyonel sorumluluk ve yükten kaynaklanan isteksizlik nedeni ile sistem dökümantasyonu harici bir firmaya 10 milyon Mark mertebesinde ödeme ile yaptırıldı. Dökümantasyon fonksiyonlar seviyesinde DDD içerir ve hala bakım – geliştiriş çalışmalarında vaz geçilmez bir kaynak olabilir.

Şimdiki sistemin yerini alacak yeni sistem için şartname de harici bir şirkete yaptırıldı. Sistem dökümantasyonuna benzer şekilde çok kaliteli, izlenebilirlik (traceability) referanslarına kadar detaylı ve güzel bir çalışma yapıldı.

2.5. EUROCONTROL’ün Merkezi Çabaları
EUROCONTROL’ün merkezi yönetimi tüm Avrupa’da Hava Trafik Kontrolünün uyumu için EATCHIP (European ATC Harmonization and Implementation Program) faaliyetlerini başlattı. Buna bağlı olarak geliştirim ve bakım için kullanılan workstation’lar değişti, radar pozisyonlarında kullanılan sistemler değişti. Bu çalışmalarda ortaya çıkan sorun, faaliyetlerin acil operasyonel sıkıntılara çözüm olmaması ve kısa dönem ihtiyaçlara yanıt verememesi idi. Sonuçların operasyonel gerçeklik boyutunda görünür hale gelememesi günümüzde EUROCONTROL’ü küçülerek bedel ödemeğe zorlamakta[3].

2.6. Çalışma Felsefesi
EUROCONTROL – STK’in sistem geliştirirken, yöntem, süreç ve araçları ne kadar kullandığı ve standartları uyup uymadığı ya da hangi standartlara uyduğu ile ilgili Alman DFS kuruluşu tarafından bağımsız bir kuruluşa denetim yaptırılmıştır[2].

Sistem geliştirişin dört ana süreci; Yazılım-Geliştiriş, Proje, Kalite Kontrol ve Kurulum Yapısı(Configuration) yönetiminden en sonuncusunun en iyi belgelenmiş ve araçlarla desteklenmiş olduğu gözlenmiştir.

Yazılım-geliştiriş sürecinin belgelenmediği ve hiçbir standarda uymadığı gözlenmiştir. PL1 ve Assembler için 1973 yılından kalmış bir standart vardır fakat analiz, tasarım ve testte sorumluluk tamamen yazılımcı ve onun müdürüne aittir. Ne kadar sürede iş yapılacağı, uzmanlık alanı sınırları, hangi mihenglerin sağlanacağı, sorunların ne kadar kökten halledileceği tamamen onların kişisel vicdanlarına[5 - 12] kalmıştır.

Kalite Güvencesi Süreci acil durumlar nedeni ile sürüm kontrolü ve sistem inşası çalışmaları Kalite Güvencesi çalışmalarından bağımsız ve belirli bir sürece bağlı olmadan yürütülmekte. Tümleşik ve diğer testlerde eski savaş pilotu ve hava trafik kontrolörlerinden kaynaklanan kişisel uzmanlık ve vicdani duyarlık dikkat çekici.

Proje yönetimi süreci KADS vb. bazı projelerde görüldüğü gibi, uzun oluşu ve çok kağıt üretişi nedeni ile esasen yürütülmemekte.

2.7. Çözüm
STK bir yandan üstündeki operasyonel sorumluluğun gereklerini yerine getirmek, öte yandan giderek tıkanış noktasına gelmiş, faaliyetlerinin önünü açmak amacı ile
IEEE 1074 çerçevesinde, IBM’in Software Configuration Library Management(SCLM) ürününü kullanıma soktu.

SCLM ile yapılan release’ler başlangıçta 12 saatin üzerinde bir süre ile inşa ediliyordu. Bu durum şiddetli tartışmalara ve sorunlara neden olsa da STK yönetimi seçiminde ısrar ederek takıma başarı ile liderlik etti.

Yazılım kurulum yönetimi (SCM), version control, release managment, Operational Deficiency (OD) yönetimi adı altında problem ve incident management unsurları giderek sistemli şekilde uygulandı. Henüz operasyonel olmayan, Radar konsolu gibi ayrık projelerde ise software lifecycle’ın tüm unsurları ile uygulanmağa çalışılması zaman ve emek kaybına neden oldu.

3. Tartışma
2. dünya savaşından bu yana Almanya’da büyük yolcu uçağı kazası olmamıştır. EUROCONTROL-STK’in seçtiği ekonomik yaklaşım başarılı olmuştur. Malesef, güncel ihtiyaçlara aşırı önem veren bu yaklaşım, şu andaki sistemin yerini alacak yeni sistem ve yöntemlerin geliştirilişinde başarısız olmuştur.

EUROCONTROL-STK’in, proje büyüklüğünün insan hayat süresinden büyük oluşundan da kaynaklanan, bu başarısızlığı, maalesef, birleşik Avrupa anlayışının bir kez daha başarısızlığına neden olmuş, bir Avrupa projesi olarak başlayan Karlsruhe ve Maastricht ATC merkezleri, özelleştirme bahanesi ile Alman devletinin DFS özel şirketi yönetimine girmiştir.

Bu üstü kapalı millileştiriş çabaları, öte yandan, teknik ve operasyonel dar boğazlarla karşılaşmış, tüm Avrupa’dan toplanmış bir takımın tecrübe ve entelektüel zenginliğinin yerini akmakta başarısız olmuştur. Planlanan tarihleri 1-2 yıl geçtiği halde, Karlsruhe’de halen EUROCONTROL-STK’in geliştirmiş olduğu eski sistem operasyoneldir.

Eğer dikkat edilirse EUROCONTROL-STK’in yaklaşımının bir çeşit agile-çevik çözüm olduğu gözlenebilir.

Alman DFS yönetim anlayışının ağır başlı ve yatırımlarına sahip çıkan tutumu örnek gösterilebilir. Yapılan yatırımlar 10 yıllarca kullanılmakta, ekonomik ömrü dolmadan değiştirilmemektedir.

4. Sonuç
Emniyet unsuru içeren büyük sistemlerde, standartların gerektirdiği sınırlar içinde uygulanışı adım adım ilerleyen bir süreç olmalıdır. Operasyonel gerçekliğe uygun olarak, standartları gerektiği yerde ve zamanda gerektiği kadar uygulamak gerekir.

5. Teşekkür
Farklı inançta insanların uçaklarla gökdelenler yıktıkları ve bu inançların çeşitli türde savaşlar çıkmasına neden olduğu günümüzde, 1992 – 1997 tarihleri arasında, günde yüz bin üzerinde kişinin can güvenliğini etkileyen, Frankfurt üst bölgesini de içeren Alman Karslruhe UIR hava sahasında, 23 tane Operasyonel Yetersizliği düzeltmem için bana görev ve kişisel sorumluluk veren Rolf MÜHLSTROH (rahmetli), John MEREDITH, Wolfgang PETER, Roy PERRY’ye minnetle teşekkür ederim. Bana güven duymaktaki cesaretleri önümüzdeki yüzyıl Avrupası’na örnek olabilecek güç ve aydınlıktadır.

6. Kaynaklar
[1] Siemens Plessey Systems Ltd., KARLDAP – The Karlsuhe Automated Data Processing System, Jul 1993.
[2] IABG, AUDIT ESTK – END BERICHT, Deutsche Flug Sicherung, 1995.
[3] P-E Internatonal, Report of a Review Conducted in the Directories of Operations and Engineering, EUROCONTROL , 1992
[4] Oberle, T., KARLDAP Change Management Process, SDK.COS.CMPRO.V01.01, 1995.
[5] Murray, S., “Assessing the Impact of Program Maintenance”, Technical Support, Aug., 1992, p 38.
[6] Ward, W.T., “Software Defect Prevention Using McCabe’s Complexity Metric”, Hewlett-Packard Journal, Apr. 1989, p 64.
[7] IEEE, IEEE Standard for Software Maintenance, IEEE Std 1219-1993.
[8] McCabes, et all., “Tips on Re-engineerin Redundant Software”, Datamation, Apr., 1992.
[9] Tsai, J.P., et all, “A Hybrid Knowledge Representation as a Basis of Requirement Specification and Specification Analysis”, IEEE Transactions on Software Eng., Vol 18 No 12, Dec 1992, p 1076.
[10] Kozaczynski, W., et all., “Program Concept Recognition and Transformation”, ”, IEEE Transactions on Software Eng., Vol 18 No 12, Dec 1992, p 1065.
[11] Yu-Chi-Ho, “Performance Analysis and Perturbation Analysis of Discrete Event Dynamic Systems”, IEEE Trans. On Automatic Control, Vol. AC-32, No. 7, Jul 1987.
[12] Dalal, S.R., et all., "When to Stop Testing for Large Software Systems with Changing Code", IEEE Transactions on Software Engineering, Vol. 20, 1994, p 318.