PLC ve SCADA tabanlı enerji otomasyon projeleri yazılım ağırlıklı olmalarından dolayı oldukça zor projelerdir. Bu projelerin başarılı olup olmamalarını etkileyen çeşitli kriterler bulunmaktadır. Yazılım tarafından baktığımızda bunlardan ilk aklımıza gelenler yazılım ekibinin izlediği yazılım geliştirme süreci ve ekibin bilgi ve becerisi, iş kapsam ve tanımının tam olarak yapılıp yapılmadığı, seçilen yazılım geliştirme ortamının üretilmek istenen yazılım konusunda bir yetersizliğinin olmaması gibi kriterlerdir. Acaba bu tür projelerde yazılımda başarı nedir ?
Yazılımda Başarı
Yazılımda başarıyı, aşağıdaki üç konuda projenin beklenenleri sağlaması ya da daha iyi bir performans göstermesi diye düşünebiliriz:
– Zaman planı
– Maliyet
– Kalite
Zaman planı yazılımın çeşitli hedef noktalarına (milestone) belirlenen zamanda varılmasını ve hedefleri yerine getirmesini kapsar. Bir enerji otomasyon projesinde bulunması beklenen “analiz kapanış”, “tasarım kapanış”, “kod geliştirme kapanış” gibi hedeflere vaktinde ulaşılması buna örnek oluşturur.
Maliyet ise yine proje tamamlandığında öngörülen bütçe sınırları dahilinde bu hedefe varmaktır.
Enerji otomasyon projelerinde yazılım kalite beklentisi ise iki boyutludur. Bunlardan ilki tamamlanan yazılımın başlangıçta belirlenen gereksinimleri ne kadar sağladığıdır. İdeal durumda projelerin tüm gereksinimleri yerine getirmesi beklenmektedir. Ancak çoğu durumda yazılım kısmı “hata” dediğimiz problemler ile birlikte tamamlanır. Bu nedenle kalitede başarıyı aradığımız zaman, bunun istenenleri tamamıyla yapmak ve ortaya çıkan sonucun, projenin müşterisi ve kullanım alanının kabul edebileceği bir hata düzeyinde teslim etmek olduğunu görüyoruz. Örneğin enerji kesintisinin çok kritik olduğu büyük bir endüstriyel tesisin enerji dağıtım merkezini kontrol ve kumanda eden bir yazılımda bulunması kabul edilebilecek hata oranı, bir alışveriş merkezinde enerji analizörlerini izlemeye yönelik bir yazılımdan çok daha düşük olacaktır.
Yazılım endüstrisinde hataların sık sık dört kategoride sınıflandırıldığını görüyoruz:
– Kabul edilemez (Show stopper)
– Kritik önemli (Critical)
– Önemli (Important)
– Az önemli (Cosmetic)
Enerji otomasyon projelerinin kabul kriterleri sırasında özellikle yazılacak program büyüklüğüne bağlı olarak yukarıdaki hata sayıları ile ilgili kabul kriterleri belirtilebilir.
Yazılım geliştirme, genellikle yalnızca kod yazımından ibaret görülüyor. Oysa bu temelden yanlış bir yaklaşım. Tüm dünyada 365 bin üyesi bulunan ve 150 ülkede faaliyet gösteren meslek örgütü IEEE’nin bu konuda yön gösteren çalışmaları bulunuyor. IEEE’nin katkısıyla oluşturulan Yazılım Mühendisliği Bilgi Tanımı (Software Engineering Body of Knowledge – SWEBOK) on ayrı kategoriyi kapsıyor. Konfigürasyon yönetimi, üretim, tasarım, mühendislik altyapısı ve mühendislik yönetimini kapsayan bu kategorilerin tümü, ortaya sağlıklı bir yazılım çıkması açısından önem taşıyor. Kodlama ise bu kategorilerden birinin alt başlığı konumunda. Bu açıdan baktığımızda, yazılım yapan şirketlerin izlediği süreçlerin olgunluğu konusunda modellemelerle karşılaşmaktayız.
Yazılım Olgunluk Modeli
Yazılım olgunluk modeli (Humphrey, Kitson & Kasse 1989), yazılım yapan şirket ve organizasyonların izlediği süreç ve yöntemleri sınıflandıran bir modeldir. Bu modele göre yazılım geliştirme süreci 5 farklı olgunluk seviyesinde değerlendirilebilir. Seviye 1 en düşük dereceyi (risk fazla, verimlilik ve kalite az), Seviye 5 ise en yüksek dereceyi (risk az, verimlilik ve kalite fazla) ifade etmektedir.
Bu modele göre, diğer sektörlerde de olduğu gibi, enerji otomasyonu sektöründe yazılım faaliyeti gösteren her bir şirket bu seviyelerden birisi ile özdeşleştirilebilir. Bkz. Tablo-1
Yazılım Gelişmemişlik Modeli
Yazılım Gelişmemişlik Modeli (Finkelstein 1992) Yazılım Olgunluk Modeli Seviye 1’in de altındaki seviyeleri tanımlar. SEI (Software Engineering Institute – Yazılım Mühendisliği Enstitüsü) istatistiklerine göre dünya üzerinde yazılım yapan kuruluşların %70’i en alt seviye olan başlangıç seviyesindedir. Aslında bunların da çoğu kaotik yapının da altındadır ve Seviye 0, Seviye -1 ve Seviye -2 olarak tanımlanmalıdır.
Yazılım Olgunluk Modeli Seviye 1 şirket ve organizasyonların uyguladığı kaotik yöntemde, şahısların üstün gayretleri ile yazılım geliştirme yapılabilir. Seviye 0’dakiler bu gayreti engelleyici tutum içerisindedirler. Oluşturulan dökümanı ve tanımlanan yazılım özelliklerini önemsemezler, hatta kaybederler. Yazılmış programlarla ilgili olarak konfigürasyon yönetimini yapamaz ve yanlış versiyonları uygularlar.
Gelişmemiş şirket ve organizasyonlar, süreç yönetimlerinin oldukça çarpık olduğunun farkında değildirler. Teknik bir düzeltmenin sorunları ortadan kaldıracağına inançları tamdır. Bu tür kuruluşlar için yönetimsel meseleler “öncelikli konular listesi” içerisinde yer almamaktadır.
Seviye 0 kuruluşları öncelikli teknik problemin yazılımların tekrar kullanılması sırasında ortaya çıkacağına inanırlar. Bir yazılımın tekrar kullanılması sırasında önceki projede geliştirme sürecinde yaptıkları hatalardan daha büyük bir hata yapmayacaklarının garantide olduğuna inanırlar.
Seviye 0 kuruluşları ihmalkarlıkları sebebiyle etkili geliştirmenin önüne geçerler. Seviye -1 kuruluşları ise yazılım geliştirme düzenini bozucu yönde hareket etmektedirler. Bunlar karmaşık yapılarda ısrarcı davranmakta, standart dışı dökümantasyon yapmaktadırlar.
Seviye 0 kuruluşları için en önemli teknik kıstas yazılım geliştirme ortamları ve kaynaklarıdır. Uygun bir ortamda politikalarını ve prosesi sürekli geliştirebileceklerine inanmaktadırlar. Tüm dökümantasyonu oluşturmak ve kontrol etmek için kendi standartlarını geliştirebileceklerini, aynı zamanda bu tür bir ortamda karmaşık sorunlara çözüm getiren uygulamaları yapabileceklerini düşünmektedirler.
Seviye -1 organizasyonları benzer davranışlarla yazılım geliştirmeyi engellerken, aslında yardımcı olduklarını düşünmektedirler. Seviye -2 kuruluşları ise yazılım geliştirme süreçlerinin iyileştirilmesi konusuna oldukça küçümseyici yaklaşmaktadırlar. Zayıf yazılımlar yapmakta olduklarına aldırmazlar çünkü muhtemelen daha sonradan bakım ve servis hizmetleri ile ilk yaptıkları yazılımdan daha fazla para kazanacaklardır. Bu tür kuruluşlarda, yazılım geliştirme sürecini tarif eden döküman (eğer varsa tabi ki) uzun süre önce işten ayrılmış bir mühendis tarafından yıllar önce oluşturulmuştur. Bu dökümanı kimsenin okumamasıyla gurur duyarlar, zaten okumak isteyen çıksa da bu dökümanı bulamazlar. Bu tür organizasyonlar başarısızlığı hak etmektedirler. Bunların işe yarar yazılım üretmeleri mucizelere bağlıdır. Bkz. Tablo-2
Sonuç
Özellikle enerji kalitesi ve sürekliliğinin önem arzettiği tesislerdeki enerji otomasyon projelerinde, yazılım geliştirme önemle takip edilmesi gereken bir süreçtir. Bu tür projelerde kaotik ya da altındaki bir seviyede çalışan ekiplerden başarı beklemek, üstün performanslı birisinin mucizeler yaratarak projeyi kurtarmasını beklemekle ve projeyi gelecekte o kişiye bağımlı kılmakla eşanlamlıdır. Bu tür projelerde yer alan mühendislik ekiplerinin en az Seviye 3 yazılım geliştirme sürecini takip ediyor olması gerekliliği açıktır. Ancak ülkemizde Seviye 3 süreç yönetimini izleyen otomasyon mühendislik grubuna rastlamak bile sık karşılaşılan bir durum değildir.
Kaynaklar:
1- Finkelstein, A., SIGSOFT Yazılım Mühendisliği Notları, 1992
2- Erener, Ö., BTİnsan, 2003
