Otomatik Kontrol Ulusal Toplantısı, TOK 2017, Eylül, Yıldız Teknik Üniversitesi, İstanbul

Transkript

1 Otomatik Kontrol Ulusal Toplantısı, TOK 217, Eylül, Yıldız Teknik Üniversitesi, İstanbul Robot Geliştirme Yazılım Altyapılarının Yazılım Ürün Kalitesinin İncelenmesi Evaluation of Software Product Quality of Robot Development Software Frameworks Savaş Öztürk 1 1 TÜBİTAK BİLGEM TDBY Yazılım Test ve Değerlendirme Lab. Gebze, KOCAELİ Savas.ozturk@tubitak.gov.tr Özetçe Teknolojinin gelişimi ile birlikte robotlar ve otonom araçlar günlük hayatımızda daha çok yer almakta, bunları çalıştıran yazılımların boyutları ve önemi artmaktadır. Endüstride yaşanan hızlı gelişim, her şeyi en baştan geliştirmek yerine var olan parçaları tümleştirerek ilerlemeyi gerekli kılmaktadır. Yazılım açısından bu yönelim, açık kaynak kodlu yazılım ürünlerinin yaygınlaşmasını hızlandırmış ve açık kaynak kodu kullanan emniyet-kritik sistemlerde güvenliğin, güvenilirliğin, kullanılabilirliğin ve bakım yapılabilirliğin nasıl sağlanacağı soru işareti olmuştur. Bu çalışmada en yaygın kullanılan 9 açık kaynak kodlu robot geliştirme platformunun yazılımlarının ürün kalitesi incelenmiştir. Yazılımların bakım yapılabilirliği SIG Bakım Yapılabilirlik kriterine göre derecelendirilmiş ve Rome Lab. modeline göre de hata yoğunluğu öngörümleri gerçekleştirilmiştir. Metot seviyesinde ve sınıf seviyesinde yapılan ölçüt değerlendirmelerinde, incelemeye tabi yazılımların büyük kalite sorunları içerdikleri ve üzerinde geliştirilecek yazılımların da bu hataları devralarak ilerlediği gözlenmiştir. Abstract With the development of technology, robots and autonomous vehicles take place more than before, hence the software products inside of them get greater in size and importance. Fast development of the industry requires integration of instant parts instead of developing them from scratch. Such kind of trend has fastened the utilization of open source software, and how to handle reliability, security and maintainability has become an important question. Software product quality of selected most used open source robot development frameworks is investigated in this study. SIG Maintainability Model is used for grading and Rome Lab. Reliability Prediction Model is used for predicting initial fault density. Evaluations held on method level, class level and project level has shown that all the software products have been deployed with quality problems and new developers inherit defects from them. 1. Giriş Son yıllarda teknoloji her alanda büyük bir ivme ile gelişmektedir. Uzaya gönderilen roketin işini tamamlayınca dönmesi bir rutin haline gelmiş, bilim kurgu filmlerindeki otonom arabalar sokaklarda gezmeye başlamış, insansız orduların ayak sesleri duyulmaya başlanmıştır. Kuşkusuz bu gelişmelerde başat aktör yazılım ve donanımlarda gerçekleşen devrimsel gelişimlerdir. 3 yıl önceki donanımlarla fazla yol alınamayan yapay zekâ öğrenme algoritmaları, grafik kartlarına özel olarak geliştirilen işlemci teknolojisi sayesinde yeniden gündeme gelmiştir. Henüz 1 yıllık bir geçmişi olmayan Tesla otomobili, 1 yıllık otomotiv şirketlerinin tahtını, Windows geliştirme platformundan daha çok yazılımı çalıştırarak sarsmaktadır. Tesla bunu, bir geliştirmeci ordusu kullanmadan ve onlarca yıllık tecrübeye sahip olmadan, açık kaynak kodlu yazılımları etkin bir şekilde kullanarak başarmıştır. Artık şirketler sıfırdan yazılım üretmek yerine uygun yazılımları birleştirerek geliştirmeyi tercih etmektedir. Yazılımın yoğun ve etkin olarak kullanıldığı günümüzün kontrol sistemlerinde yazılımsal hatalar can kaybına kadar giden arızalara yol açabilir. Otonom otomobillerde direksiyon, gaz ve fren gibi bütün hayati kontroller, yazılımın sensörlerden aldığı bilgiyi çok hızlı bir şekilde işleyerek karar vermesi sonucunda gerçekleştirilir ve en küçük bir hatanın telafisi olamayabilir. Bu nedenle bu yazılımların ve temel teşkil eden açık kaynak kodlu yazılımların, kontrollü bir şekilde geliştirilmesi ve/veya çok iyi test edilmesi gerekir. Endüstri, bu gerçeğin farkındadır ve robot yazılımlarının kaliteli olması için Avrupa'da H22 projesi başlatılmıştır [1]. Açık kaynak kodun sıkça kullanıldığı yerlerden birisi de robot geliştirme platformlarının yazılımları olmuştur. Otonom sistemlere temel olacak bu yazılımların beklenen işlevleri yerine getirmesinin yanı sıra kalite faktörlerinden güvenilir (can, mal ve itibar kaybına sebep olmadan aralıksız çalışabilmesi), güvenli (dışarıdan kötü niyetli müdahalelere fırsat vermemesi), bakım yapılabilir (kodun anlaşılabilir ve kolay düzeltilebilir olması) olması da ön plana çıkmaktadır. Açık kaynak kodlu yazılımlarda süreç kalitesinin yani yazılımın nasıl geliştirildiğinin, belgelendirildiğinin ve test edildiğinin izlenmesi, farklı konumlarda farklı kültürel kimliğe sahip ekiplerin süreç kalitesini sağlamak için ayrı bir iş gücü tahsis etmesi zor olabilir. ABD Hava Kuvvetleri Rome Lab. 368

2 Otomatik Kontrol Ulusal Toplantısı, TOK 217, Eylül, Yıldız Teknik Üniversitesi, İstanbul güvenilirlik öngörümü çalışmasında, yazılımda en çok hatanın kodlama aşamasında eklendiği iddia edilmektedir [2]. Yani süreç ne kadar kaliteli işletilirse işletilsin, kodlama hataları yazılımın kalitesini yerle bir edebilir. Kodlar ve hata veritabanı gibi somut veriler üzerinden ürün kalitesini geliştirme ekibinden bağımsız olarak değerlendirmek mümkündür. Japonya'daki robot yarışmasında yarışmacı robotların yazılım kalitesi üzerinden değerlendirilmesi üzerinde çalışılmış, ancak UML tasarımlarına bakılarak yapılan değerlendirme hakemlerin değerlendirmesi ile uyumlu çıkmamıştır [3]. Bunun nedeni olarak tasarımın koda aynen geçirilmemesi olarak açıklanmıştır. Sadece kod üzerinde yapılan statik kod analizlerinin yazılımda mevcut hataların %6'ına yakınını daha test süreci başlamadan tespit ettiği ortaya çıkarılmıştır [3]. Dolayısıyla sadece koda bakarak kalite değerlendirmesi, önemli bir gösterge sağlar. Bu çalışmada en yaygın açık kaynak kodlu robot geliştirme yazılımlarının kod kalite incelemesi gerçekleştirilmiştir. Seçilen yazılımlara ait çevrimsel karmaşıklık (cyclomatic complexity), esas karmaşıklık (essential complexity), büyüklük (satır sayısı, yorum sayısı vb.) ve nesne yönelimli ölçütler (Chidamber & Kemerer metrik seti) kullanılarak bakım yapılabilirlik derecelendirmesi ve güvenilirlik öngörümleri gerçekleştirilmiştir. Bakım yapılabilirlik derecelendirmesi için SIG (Software Improvement Group) modeli ve hata yoğunluğu öngörümü için ise Rome Lab. modelinden esinlenilmiştir [5]. İncelemeye tabi yazılımların C/C++, C#, Java, Python, Ruby, PHP, Eagle gibi geniş yelpazede bir dil kümesi kullanılarak geliştirildiği gözlenmiş ve bu nedenle ölçümler için kapsamlı bir dil desteği sunan SciTools Understand aracı kullanılmıştır. Bakım yapılabilirlik ve güvenilirlik hesaplamaları ise laboratuvarımızda geliştirdiğimiz yazılımlar ile gerçekleştirilmiştir [6]. İnceleme sonucunda, yazılımların büyük kalite sorunları içerdiği, test edilemeyecek ve anlaşılamayacak kadar karmaşık metotlara sahip olduğu, hata dağılımının homojen olmadığı ve belli modüllerde toplandığı, nesne yönelimli tasarımın etkin yapılamadığı, sınıfların birbirine çok bağımlı ve sınıfların içerisinde bütünlük kaybı olduğu tespit edilmiştir. Bildirinin ikinci bölümünde incelemeye tabi yazılımlar, üçüncü bölümünde yazılım kalite metrikleri ve yazılım kalite modelleri, dördüncü bölümde ölçme ve değerlendirmeler anlatılarak beşinci bölümde değerlendirme sonuçları tartışılacaktır. 2. Açık Kaynak Kodlu Robot Geliştirme Yazılımları Sürücüsüz otomobiller ve insansız hava araçları gibi gelişmeler insanların robotiğe olan ilgisini artırmış ve mühendis olmayanların dahi geliştirebileceği geliştirme platformları yaygınlaştırmıştır. Bu çalışmada bu platformlar üç grupta incelenecektir: 2.1. Donanım Projeleri Robot, fiziksel bir varlıktır, donanım ve yazılımının uyumu ile çalışır. Aşağıdaki platformlar sadece yazılımı değil, donanımsal olarak robotları da geliştirmeyi sağlayacak çizimleri, tasarımları ve şemaları da içerir. Sparki: Uçtan uca bir robot geliştirme platformudur. Öğrencilerden yetişkinlere geniş kapsamda bir kullanıcı kitlesine hitap eden robotun şemaları, 3 boyutlu modelleri, sensörleri (mesafe, ivmeölçer, kızıl ötesi, kumpas, ışık sensörü vb.) açık kaynak kodlu olarak sunulmaktadır. Ardupilot: Dron tarzı uça araçları "kendin yap" felsefesi ile kontrol edebilmeyi sağlayan kapsamlı bir kit ile yazılım kütüphanesi sunar. TurtleBot: İster sağladığı kit ile isterse başka donanım ve sensörlerle geliştirmeyi sağlayan robot platformudur Yazılım Projeleri Robot sadece metal iskeletten ibaret değildir, iskelete komutları veren yazılımdır ve spesifik ya da jenerik olarak robot donanımlarına destek veren açık kaynak kodlu yazılım platformları bulunmaktadır. LeJOS: Lego Mindstorm robot setini programlamaya yarayan özellikle başlangıç seviyesi kullanıcılar için uygun Java temelli geliştirme ortamıdır. RoCK (Robot Construction Kit): Orocos gerçek zamanlı araç setine uygun olarak geliştirilen genişletilebilir ve mevcut uygulamalar için çok sayıda sürücü desteği sunan geliştirme ortamıdır. ROS (Robot Operating System): Open Source Robotics Foundation tarafından desteklenen dünya çapında kapsamlı bir topluluk tarafından geliştirilen, bilinen tüm ticari ve serbest robot donanımları ile uyumlu geliştirme ortamıdır Robot Benzetimleri Yazılımı donanıma gelişigüzel tümleştirmeden önce, robotun gerçek dünyadaki ortamdan hava koşullarına kadar değişen fiziksel kısıtlara uyumundan emin olabilmek için benzetimini gerçekleştirmek gerekir. Gazebo: Gelişmiş 3 boyutlu grafikleri, sanal sensörleri, geniş komut satırı desteği ve bulutta benzetimleri koşturabilme yeteneği ile Apache lisanslı tam bir benzetim çözümüdür. Modellemeye başlamak için gerekli bilinen robot platformları ile uyumlu çok sayıda eklentiyi destekler. MORSE (Modular Open Robots Simulation Engine): İç ve dış mekân kullanımına uygun akademik robot modellerine odaklı, Python ile programlanabilen ve Blender oyun motoru ile işlenen (render) benzetimler yapmak için kullanılır. V-REP (Virtual Robot Experimentation Platform): Windows, Mac ve Linux masaüstlerinde çalışan, çoklu programlama yaklaşımlarını ve dillerini destekleyen, gelişmiş fiziksel durumlar kadar yakınlık ve görsel sensörlerden gelen verileri de modelleyebilen benzetim geliştirme ortamıdır. 3. Yazılım Ürün Kalitesi Yazılım kalitesi denildiğinde akla ilk önce, kalite güvence olarak da bilinen, ağırlıklı olarak yazılımın belirlenen geliştirme süreci safhalarındaki üretilecek dokümantasyonu takip eden süreç kalitesi gelmektedir. Süreç kalitesi yazılımın geliştirilmesi için önemli yer tutsa da nesnel ölçütlerle değerlendirmesi zordur ve yaklaşım kurumdan kuruma değişir. Diğer taraftan ürün kalitesi ise üretilen koda ve arayüzlere 369

3 Otomatik Kontrol Ulusal Toplantısı, TOK 217, Eylül, Yıldız Teknik Üniversitesi, İstanbul odaklıdır, nesnel değerlendirme mümkündür. ISO/IEC 251 standardı yazılım ürün kalitesini 8 alt faktörde inceler: İşlevsel uygunluk, performans verimliliği, uyumluluk, kullanılabilirlik, güvenilirlik, güvenlik, bakım yapılabilirlik ve taşınabilirlik[7]. Bu faktörlerin ayrı ayrı değerlendirilmesi için sayısallaştırılabilir alt karakterler tanımlanmıştır. Örneğin bakım yapılabilirlik; tutarlılık, analiz edilebilirlik, değiştirilebilirlik, tekrar kullanılabilirlik ve test edilebilirlik adı altında 5 alt faktör açısından incelenmektedir. Güvenilirlik ise erişilebilirlik, kurtarılabilirlik, olgunluk ve hataya dayanıklılık faktörleri ile değerlendirilir. Herbir alt faktörün değerlendirilebilmesi için de ya geliştirici ya da kullanıcıya yöneltilen anket soruları, ya doldurulan kontrol listeleri ya da kod ve benzeri yazılım ürünlerinden elde edilen ölçütler kullanılır. Örneğin test edilebilirlik karmaşıklıkla ilgilidir ve kodun karmaşıklığı yüksekse test edilebilirliği ve dolayısı ile bakım yapılabilirliği azalır. gibi ölçütleri tek başlarına yazılım hakkında nesnel bir fikir edinilmesine yardımcı olacağı gibi bazı modellere girdi sağlayarak da daha geniş bir bakış açısı yakalanmasına yardımcı olur. Yazılım hakkında fikir edinmek için kullanılan en eski ve en basit ölçüt satır sayısıdır. Satır sayısı ölçütleri yazılımın büyüklüğü hakkında fikir verir ancak hataların tespitinde çok faydalı olmayabilir. Çok uzun bir metod sadece tanımlamaları içeriyordur ve hiç hata içermez. Kısa bir metot ise girift bir yapıda tanımlanmış ve çok sayıda hatayı barındırıyor olabilir. Bu nedenle 1976'da McCabe tarafından ortaya çıkarılan, metodların mantıksal karmaşıklığını hesaplayan ölçüt olan çevrimsel karmaşıklık (cyclomatic complexity) öne çıkar [8]. Koddaki her If, for/while, switch/case, try/catch gibi şart ifadesi karmaşıklığı artırır ve karmaşıklığın miktarı en az yapılması gereken test durumu sayısını verir. Çevrimsel karmaşıklık metriği yapısallığı bozan metotlar arası dallanmaları hesaba katmaz, halbuki bir satır kod ekleyerek programın yapısı alt üst edilebilir. Örneğin iç içe geçmiş 3 for bloğunun en iç noktasında kullanılacak bir return ya da go to ifadesi for döngülerinin ve metodun geri kalan kısımlarını çöpe atacak ve kullanılamaz hale getirecektir. McCabe, bu tür kullanımların oldukça tehlikeli olduğunu ileri sürerek bunu ölçen ölçütü Esas (Essential Complexity) olarak adlandırmıştır. Yazılım kalitesini ya da kaliteyi oluşturan alt faktörleri değerlendiren çok sayıda model de kalite faktörlerinin bir denetim listesinde yer alan sorulara cevap verilmesi dayalı olduğu benzer bir yöntemi izlemiştir yılında ortaya çıkan Rome Laboratuvarı Modeli yazılım güvenilirliği öngörümü (prediction) ve tahminine (estimation) yönelik kapsamlı bir yaklaşım sunar [2]. Bu model yazılım projesinin konsept aşamasından sistemin devreye alınması ve bakım sürecine kadar tüm safhalarda yazılım hakkında topladığı çeşitli veriler ile yazılımın hata yoğunluğunu (yazılımın barındırdığı satır sayısı başına hata sayısı) öngörür, sistem arızası oranını (belirli bir zaman aralığında sistem arızası oluşmasına yol açan yazılımsal hata) tahmin eder. Bu modeli geliştiren ABD Hava Kuvvetleri'nin geliştirdiği projelerden elde edilen birikim kullanılır, bir takım denetim listeleri yardımı ile öznel bilgiler derlenir, dokümantasyon, süreç, ekibin yapısı ve yazılım kodu da dahil olmak üzere kapsamlı bir veri ile güvenilirlik değerleri sayısallaştırılır. Rome lab. Modelinin kodlama aşamasında kullanılan hata yoğunluğu öngörüsünde, SX metriğinin hesaplanmasında McCabe çevrimsel karmaşıklık metriğinden faydalanılır. SM metriğinin hesaplanmasında ise birim kod büyüklüğüne bakılır. SX*SM*kodlama öncesi hata yoğunluğu değeri modelin kodlama aşaması sonundaki hata yoğunluğunu hesaplar. SX = (1.5a + b +.8c) / NM (1) SM = (.9u + w + 2x) / NM (2) a = çevrimsel karmaşıklığı 2'ye eşit veya daha yüksek olan metodların sayısı b = çevrimsel karmaşıklığı 2'den az ve 6'dan fazla olan metodların sayısı c = çevrimsel karmaşıklığı 6'dan az olan metodların sayısı u = satır sayısı 1'e eşit veya daha düşük olan metodların sayısı w = satır sayısı 1'den fazla veya 5'den az olan metodların sayısı x = satır sayısı 5'den fazla olan metodların sayısı NM = toplam metod sayısı Kodlama aşaması hata yoğunluğuna isterler ve tasarım gibi daha önceki aşamaların hiçbirisinde olmadığı kadar büyük etki eder. Rome Lab. Modelinde metot sayıları ölçülse de bu durum çok net bir gösterge sunmadığı için bunun yerine aynı kriterleri sağlayan kod satır sayılarının toplanması daha doğru bir yaklaşım olacaktır. SIG Bakım Yapılabilirlik modelinde ise metotların çevrimsel karmaşıklığı 1,1,2,5 sınır aralıklarının hangisinde olduğuna göre sınıflandırılır [9]. Bu sınıflandırmaya giren metotların satır sayılarının tüm projeye oranına göre seviye belirlenir (Tablo 1). Örneğin karmaşıklığı 5 den yüksek kod satır oranı %3, 2-5 arasında olan kod oranı %11, 1-2 arasında karmaşıklığı olan kod oranı da %23 olursa bu durum 2. Seviyeye karşılık gelir. Karmaşıklığı 5 den yüksek kod oranı sıfırlansa bile, 2 den yüksek oranı %11 olduğu için, %1 lik bir fark yüzünden seviye 2 de kalır. Kritiklik seviyesi Tablo 1: SIG Bakım Yapılabilirlik Modeli karmaşıklığın seviyelendirmeye etkisi Very high > 5 High > 2 Medium > 1 Low > Seviye Medium High Very High 1 Seviye 2,3,4 ya da 5 değilse 2 < 5% < 15% < 5% 3 < 4% < 1% < % 4 < 3% < 5% < % 5 < 25% < % < % SIG modelinde kullanılan diğer bir ölçüt ise Birim kod büyüklüğünün değerlendirilmesidir. Hesaplanış yöntemi karmaşıklık için yapılana benzemektedir. Bu modele göre satır sayısı 1 den yüksek olan metotların satır sayıları toplamı tüm projenin %5 inden yüksekse bakım yapılabilirliği oldukça zordur (Tablo 2). 37

4 Otomatik Kontrol Ulusal Toplantısı, TOK 217, Eylül, Yıldız Teknik Üniversitesi, İstanbul 4. Yazılım Kalite Değerlendirmeleri Seçilmiş olan 9 açık kaynak kodlu robot geliştirme yazılımı Github, SourceForge ve BitBucket gibi kod havuzlarından indirilmiştir. Bütün yazılımların C++ kullandığı, buna ilave olarak Python, Java, PHP ve C# gibi dillerin de tercih edildiği gözlenmiştir. Adı geçen bu dillerde geliştirilen kodlar inceleme kapsamına alınırken, Ruby, Eagle, Shell, Glsl, Cmake ve Lisp gibi dillerdeki kodlar, Understand aracının kapsamına girmediği için incelenememiştir. Understand ile Tablo 3'deki ölçütler incelenmiş, bunlardan faydalanarak bakım yapılabilirlik ve güvenilirlik hesaplamaları da yapılmıştır. Tablo 4 de ise incelenen yazılımlarına ait sayısal bilgiler sunulmuştur. Kritiklik seviyesi Tablo 2: SIG Bakım Yapılabilirlik Modeli birim satır sayısının seviyelendirmeye etkisi Birim Satır Sayısı Very high > 1 High > 5 Medium > 1 Low > Seviye Medium High Very High 1 Seviye 2,3,4 ya da 5 değilse 2 < 5% < 15% < 5% 3 < 4% < 1% < % 4 < 3% < 5% < % 5 < 25% < % < % Tablo 3: Kullanılan ölçüt ve modeller Analiz Ölçütler Kapsamı Metot seviyesi Çevrimsel karmaşıklık (vg), Esas karmaşıklık (evg), Kod satır sayısı (code), Yorum satır sayısı (comm) Sınıf seviyesi Bütünlük Kaybı (Lock of Cohesion of Methods-LCOM), Sınıflar Arası Bağımlılık (Coupling of Methods-CBO), Türetilmiş Alt Sınıf Sayısı (Number Of Children-NOC), Sınıfın Metot Sayısı (Weighted Methods For A Class-WMC), Sınıftan Yapılan Çağrı Sayısı (Response For A Class-RFC), Kalıtım Ağacı Derinliği (Depth Of Inheritance DIT), Yazılım Kalite Risk Oranı-İlk 3 (YKRO3) Proje Seviyesi Rome Lab. Güvenilirlik Hata Yoğunluğu Modeli (Metot sayısı temelli) Güvenilirlik Hata Yoğunluğu Modeli (Kod yoğunluğu temelli) SIG Bakım Yapılabilirlik Modeli ( ve Kod büyüklüğü faktörleri) 4.1 Metot Seviyesinde Değerlendirmeler Seçilen yazılımlar için metot seviyesinde yapılan değerlendirmelerde kod satır sayısı olarak 666, yorum satır sayısı olarak 2779, çevrimsel karmaşıklık olarak 1631 ve esas karmaşıklık olarak 149 gibi değerler eşiklerin çok üstünde gerçekleşen anormal ölçümlerdir (Tablo 5). TURTLE yazılımı eşik değerlere en çok dikkat edilen yazılım olmuştur. Sadece 12 metotta karmaşıklık eşik değeri olan 1 aşılmıştır. ARDU ta ise 3229 metot karmaşıklık eşiğini aşmış olup, karmaşıklığı 1631 olan metot mevcuttur. Bu metodun üzerinde güncelleme, düzeltme ve test yapmak oldukça zor ve riskli olacaktır. 666 satır uzunluğunda bir metoda sahip açık kaynak kodlu bir yazılımın bakım yapılabilirliği, güvenilirliği, güvenliği ve performansı tehdit altındadır. Metot seviyesindeki değerlendirmeler, proje seviyesinde kullanılan modellerle birlikte değerlendirildiğinde daha anlamlı olmaktadır. Tablo 4: İncelenen yazılımların sayısal özellikleri Toplam Satır Sayısı Metot sayısı Sınıf Sayısı SPARKI ARDU TURTLE LEJOS ROCK ROS GAZEBO MORSE V-REP Yazılım Adı Tablo 5: İncelenen yazılımların metot seviyesinde ölçüt değerleri (ölçülen en yüksek değer eşiği aşan metot sayısı) Çevrimsel SPARKI 3 23 ARDU TURTLE LEJOS ROCK 78-5 ROS Esas Kod Satır sayısı Yorum Satır Sayısı

5 Otomatik Kontrol Ulusal Toplantısı, TOK 217, Eylül, Yıldız Teknik Üniversitesi, İstanbul GAZEBO MORSE V-REP Sınıf Seviyesinde Değerlendirmeler Metotların uzun ve karmaşık olması projelerin anlaşılmasını, yönetilmesini ve test edilmesini zorlaştırır, kapsadığı hata sayısı ve derleme süresi açısından sorunlar içerir. Bu tür projeler üzerinde yatırım yapacak proje ekipleri, daha kodlamaya başlamadan altyapıdan gelecek sorunların çokluğundan ve alacağı risklerden haberdar olmalıdır. Açık kaynak kodlu robot geliştirme yazılımları farklı geliştirme ekiplerinin, farklı dillerde geliştirdiği kodlardan teşkil ettiği için ölçümlerden direk bir yargıya varmak doğru olmaz. CK metrik seti değerlendirmesinde 588 sınıf içeren MORSE, en iyi tasarıma sahip proje çıkmıştır (Tablo 6). Sadece Türetilen Alt Sınıf Sayısı (Number Of Children) ölçütünde eşiği aşan sınıflar bulunmuştur. Bunun dışında, NASA PROMISE araştırmalarında en çok hataya sebep verdiği tespit edilen Bütünlük Kaybı (Lock of Cohesion of Methods) ve Sınıflar Arasında Bağımlılık (Coupling Between Objects) ölçütlerinde tüm projeler eşiği aşan sınıflara sahiptir [1]. Yazılım Adı Tablo 6: İncelenen yazılımların sınıf seviyesinde ölçüt değerleri (ölçülen en yüksek değer eşik değerini aşan sınıf sayısı) LCOM SPARKI 1-14 ARDU TURTLE LEJOS 1-63 ROCK 1-12 ROS GAZEBO MORSE - V-REP CBO NOC WMC DIT RFC YKRO3 46,47 3,32 26,73 24,89 7,78 4,23 1,91 26,52 2,84 Nesne Yönelimli ölçütlerin sınıf bazında yoğunluklarına göre hesaplanan bir türetilmiş ölçüt olan YKRO değerlerine göre en yüksek ölçülen üç sınıfın toplam değerinde (YKRO) ise GAZEBO en başarılı proje olmuştur [11]. GAZEBO da CK ölçütlerine göre eşik değerinin üzerinde çıkan sınıflar çok olsa da belirli sınıflarda yığılma olmamış, en kritik üç sınıfın YKRO değerleri toplamı %1,91 gibi düşük bir değere tekabül etmiştir. GAZEBO nun bu başarısına karşılık, SPARKI %46,47 YKRO değeri ile büyük bir problem barındırmaktadır. Bu, SPARKI de 64 sınıfın 3 tanesi neredeyse tüm işlerin yarısını üslenmiş anlamını taşımakta ve sınıflar arası görev dengelemesinin doğru yapılmadığını göstermektedir. 4.3 Proje Seviyesinde Değerlendirmeler Metot ya da sınıflar tüm projeye ölçeklenmemişse düzeltilmesi kolay bir durum olabilir. Metotların karmaşıklık seviyesi ya da satır sayısı sadece eşiği aşıp aşmadığına göre değerlendirilmemeli ne kadar aştığı ve tüm projede ne kadar oranlandığı da önemlidir. Bu amaçla kullanılan SIG Bakım Yapılabilirlik Modeli karmaşıklık seviyelerini veryhigh (vg>5), high (5>vg>2), moderate (2>vg>1) ve normal (vg>1) olarak derecelendirmekte ve bunların oranlarına göre yazılıma bir not vermektedir. Örneğin veryhigh oranı %5 ten yüksek olan bir proje, bakım yapılabilirlik açısından yüksek problemlidir ve diğer dilimlere bakılmaksızın 5 üzerinden 1 puan alabilir. SIG Bakım yapılabilirlik modeli, benzer derecelendirmeyi satır sayısı, tekrarlanan kod oranı, birim test kapsama oranı gibi kriterlere göre de değerlendirmektedir. Bu çalışmada robot yazılımları sadece karmaşıklık ve satır sayısı yönlerinden ele alınmıştır. Tablo 7 de bakım yapılabilirlik hesaplamalarında kullanılan, karmaşıklık açısından ve kod satır sayısı açısından kod oranları görülmektedir. Yazılım Adı Tablo 7: İncelenen yazılımların proje seviyesinde ölçüt değerleri (%) Çok yüksek karmaşıklık (vg>5) Yüksek (5>=vg>2) Orta (2>=vg>1) Birim büyüklüğü Çok yüksek birim büyüklüğü (2>loc>1) Yüksek Birim büyüklüğü (1>=loc>5) Orta Birim Büyüklüğü (%) SPARKI 7,32 8,18 2,77 11,24 ARDU TURTLE 7,39 11,31 13,35 6,79 1,61 14,32 37,68 1,68 37,68 1,86 8,84 LEJOS 2,85 1,3 8,45 6,27 8,5 ROCK,96 3,6 7,58 2,25 7,92 ROS 8,98 1,98 12,45 5,63 8,62 1,91 GAZEBO 4,72 11,59 12,59 2,16 8,58 15,19 372

6 Otomatik Kontrol Ulusal Toplantısı, TOK 217, Eylül, Yıldız Teknik Üniversitesi, İstanbul MORSE 2,66 7,54,85 8, V-REP 5,82 12,97 15,96 2,84 1,85 15,56 5. Tartışma Tablo 8 de güvenilirlik hesaplamaları sonuçları hem Rome Lab. Modeline (metot sayısı) hem de kod oranı kriterine göre gösterilmiş, bunlara ilaveten karşılaştırma yapılabilmesi için bakım yapılabilirlik ve YKRO3 sonuçları eklenmiştir. Tabloda sıralama yapılırken, bakım yapılabilirlik notları ortalamasına bakılmış, eşit olduğu durumlarda da (ROS, ARDU ve TURTLE değerleri ortalamada en düşük değer olan 1 çıkmıştır.) kusur sayısı ortalaması kullanılmıştır. Tablo 8: İncelenen yazılımlar için özet durum tablosu (En iyi değerler koyu olarak gösterilmiştir.) düşüktür ve sıfıra yakındır. Bakım yapılabilirlik notu 4 olsa da kolaylıkla 5 e çıkarılabilecek durumdadır. MORSE, güvenilirliğe de olumlu katkıda bulunan ve hata sayısını azaltan bir şekilde geliştirilmektedir. - En popüler yazılımlardan olan ROS un yaklaşık %1 u (83 metotta 329 satır) yüksek karmaşıklık sınıfına girmektedir. Bu altyapı üzerinde yazılım geliştirmek riskler içermektedir. - Yazılımların bakım yapılabilirliğini en çok etkileyen faktör çok yüksek dilimleri olmuştur. Çoğu yazılımda yüksek ve orta aralıkları (turuncu ve gri bantlar) %7-14 arasında çıkmıştır (Bknz. Şekil 1). - SPARKI yazılım karmaşıklık ve birim kod büyüklüğü açısından en iyi ikinci olmasına rağmen, bütün işlevselliğin az sayıda sınıfta toplanması açısından nesne yönelimli tasarım bakımından kötü bir örnektir. Ürün Kalitesi Sıralaması Yazılım Adı Metot sayısı temelli öngörülen başlangıç kusur sayısı Satır sayısı temelli öngörülen başlangıç kusur sayısı (Düşük değer iyidir.) Yazılım Kalite Risk Oranı İlk 3 Toplamı Bakım yapılabilirlik notu - Bakım yapılabilirlik notu Satır sayısı (Yüksek değer iyidir.) 1 MORSE 7,2 7,6 26, SPARKI 7,4 1,2 46, ROCK 7,2 7,9 7, LEJOS 7,3 8,8 24, GAZEBO 7,4 9,7 1, V-REP 7,4 1,2 2, ROS 7,4 1,2 4, ARDU 9 TURTLE 7,4 1,5 3, ,3 14,5 26, Bu sonuçlara göre aşağıdaki çıkarımlar yapılabilir: - ROS ve ARDU gibi yüksek hacimli yazılımların güvenilirlik ve bakım yapılabilirlik sonuçları içermesi normal karşılanabilir. Ancak incelenen yazılımlarda en az satır sayısına sahip olan TURTLE en kalitesiz yazılım olmuştur. TURTLE ile kodlama aşamasında hata sayısı yaklaşık 1,5 kat artmaktadır. Tasarımsal dengesizlik mevcuttur, tüm işyükünün ¼ ünü sadece üç sınıf üstlenmektedir. - MORSE yazılımının disiplinli geliştirildiği söylenebilir. Çünkü gerek karmaşıklığında gerekse birim büyüklüklerinde çok yüksek dilimleri sıfır çıkmıştır. yüksek seviyedeki dilimleri de oldukça Şekil 1: İncelenen yazılımların karmaşık kod oranlarının görsel değerlendirmesi 6. Sonuçlar Teknolojik gelişmeler yazılımı o kadar önemli bir noktaya taşımıştır ki, yazılımdan kaynaklanan sorunlar büyük kayıplara yol açmaktadır. Yazılımın ve yazılım desteğinin kaliteli olması, itibarı, memnuniyeti ve kârı artırıcı, maliyetleri ve kazaları azaltıcı etkiye sahiptir. Donanımları aynı olan iki cep telefonundan birisi, işletim sisteminin tutarlılığı ve kullanım kolaylığından dolayı diğerine göre birkaç kat oranda fazla tercih edilmektedir. Benzer durum tüm cihazlar ve otonom sistemler için geçerlidir. Çoğu robot yarışmasında donanımlar değil, benzer donanımlar üzerinde çalışan yazılımlar yarışır. Yazılımın işlevsel olarak belirli beklentileri karşılaması yanında, performansı, kullanılabilirliği, güvenliği, güvenilirliği ve bakım yapılabilirliği de üzerinde çalıştığı donanıma artı değer katar. Bu çalışmada robot geliştirme altyapılarında en çok kullanılan 9 adet açık kaynak kodlu yazılımın ürün kalitesi incelenmiştir. Yazılımların karmaşıklık, bağımlılık, büyüklük, bütünlük gibi genel kabul görmüş ölçütlerle ve modellerle incelenmesi sağlanmış ve önemli sonuçlara ulaşılmıştır. En önemli sonuç bu yazılımlardan bazılarında rekor seviyesinde çok yüksek karmaşıklık ve büyüklük değerlerine rastlanmasıdır. yazılımın büyüklüğü ile orantılıdır. tezine ters düşen bir sonuç da 373

7 Otomatik Kontrol Ulusal Toplantısı, TOK 217, Eylül, Yıldız Teknik Üniversitesi, İstanbul ortaya çıkmış ve en az satır sayısına sahip TURTLE geliştirme platformu, en kalitesiz yazılım çıkmıştır. Arduino platformu üzerinde geliştirme yapmak için kullanılan ARDU ise aynı tezi doğrular şekilde en kalitesiz ikinci yazılım olmuştur. Robot benzetimi altyapılarından birisi olan MORSE ise ideale yakın bir kalitede geliştirilmiştir. Popüler bir altyapı olan yazılım geliştirmenin bazı riskler taşıdığı, yazılımların hataya açıklık, performans ve bakım yapılabilirlik açısından problemleri olabileceği görülmektedir. Yazılım geliştiricileri kısmen kullandığı veya üzerinde geliştirme yaptığı bu altyapıları anlayamazlar ve kalitesinden emin olamazlarsa, verdikleri emek boşa gidebilir. Elde edilen sonuçlar hızla büyüyen sektör için bir erken uyarı işaretidir. İncelenen yazılımlar bu şekilde büyümeye ve karmaşıklaşmaya devam ederse, ileride yönetilemez ve kullanılamaz duruma gelebileceği öngörülmektedir. Bu çalışma kontrol ve otomasyon sistemlerinde yazılımın önemine dikkati çekebilmek ve yazılım kalitesine ilgi uyandırabilmek amacını gerçekleştirmiştir. [9] Baggen, R., Schill, K., Visser, J., Standardized Code Quality Benchmarking for Improving Software Maintainability, 14th European Conference on Software Maintenance and Reengineering, March 15-18, 21 in Universidad Rey Juan Carlos, Madrid, Spain [1] Promise Software Engineering Repository, 26 [11] Palıgu F., Öztürk, S., Yağcı, N., Kodu İyileştirmeye Nereden Başlamalı? Bir Yazılım Metrik Yaklaşımı: Yazılım Kalite Risk Oranı, 7th Turkish National Software Engineering Symposium, İzmir, 213. Teşekkür Yazar, bu çalışmanın gerçekleştirilmesi için destek sağlayan TÜBİTAK BİLGEM Yazılım Test ve Kalite Değerlendirme Laboratuvarı'na teşekkür eder.. Kaynakça [1] Corbato, C.H., Bordignon, M., The ROSIN project: towards an EU Digital Industrial Platform for Robotics through Open-Source Software, Global ROS-I Community Meeting, 16 Mayıs 217 [2] Rome Laboratory, Reliability Engineer s Toolkit, Technical Report, [3] Washizaki, h, Kobayashi, Y., Watanabe, H., Nakajima, E., Hagiwara, Y., Hiranabe, K., Fukuda, K., Hiroyuki WATANABE3, Quality Evaluation of Embedded Software in Robot Software Design Contest, Progress in Informatics, No. 4, pp.63 78, (27) [4] Jones, C., Software Quality Metrics: Three Harmful Metrics and Two Helpful Metrics, Technical Report, 212. [5] Heitlager, I., Kuipers, T. and Visser, J., A Practical Model for Measuring Maintainability. 6th International Conference on the Quality of Information and Communications Technology, 27, pp [6] Öztürk, S., Yağcı, N. Kamu Yazılımlarında Ürün Kalitesinin Değerlendirilmesi İçin Pratik Bir Kod Kalitesi Modeli. 1. Ulusal Yazılım Mühendisliği Sempozyumu (UYMS 216), Ekim 216, Çanakkale. [7] ISO/IEC 251: 211- Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models, gue_detail.htm?csnumber=35733 [8] McCabe, T. J. A Complexity Measure, IEEE Trans. Software Eng. SE-2, 4 (Dec. 1976),