Yazılım Proje Faktörlerinin Risklerle Etkileşimi: Telekomünikasyon Örneği

Abstract

Risk management that is one of the knowledge areas of software project management process, has a direct impact on the success of the Project. the success of the project can be estimated in the project first phase by creating a predictive risk model with the risks and results in similar projects. For this purpose, the studies on risk estimation and risk evaluation have started to show increase in recent years. The previous studies on risk management and risk assessment have been investigated in this study. The relationship between the characteristics of software projects and risks has been investigated and an application has been performed for determination

-

of the factors that lead to risks. The software projects, developed by a telecommunication company between 2007 and 2014 were used for the application. Risk management in software projects makes it even more important because of rapid changes in the telecommunications industry.

As a first step, data from the application dataset selected. After cleaning the data, based on previous studies, the relationships between risk factors and project factors have been established. In order to prove the accuracy of the model generated, results from various algorithms have been evaluated. The success rates of the methods have also been shown in the study. 1

GİRİŞ Yazılım projelerinin planlanan zaman ve bütçeyle istenen fonksiyonları yerine getirmesi amacıyla yürütülen proje yönetim sürecini incelediğimizde yazılım projelerindeki başarı oranının hala düşük olduğu gözlemlenmektedir. Standish Group tarafından 2013’te yayınlanan CHAOS raporunda yazılım projelerinin başarısı önceki yıllara göre artmasına rağmen halen %39 olduğu görülmektedir. [ 1 ] Yine Gartner Institute’un bilişim sektörüne yönelik araştırmasına göre bilgi teknolojileri projelerinin %74′ü başarısızlıkla sonuçlanmaktadır. [ 2 ] Her iki araştırmada da maliyet ve zaman hedeflerini aşan veya hedeflenen özellikleri karşılayamayan projeler başarısız olarak nitelendirilmiştir. Yazılım projelerindeki bu oranlar, risk yönetimi üzerine yapılan çalışmaları önemli kılmaktadır. Çünkü proje açısından oluşabilecek tehditleri önceden belirleyip gerekli önlemleri almak projenin başarısında önemli bir rol oynamaktadır.

Riski, projedeki varsayım ve kısıttan ayıran en önemli özelliği olayın olma olasılığının %100’den küçük olması ve olayın sonucunun değiştirilebilme olasılığının olmasıdır.[ 3 ] PMI (Project Management Institute) riski tanımlarken olayın olması durumunda projeye olumlu veya olumsuz etkisi olabileceğini belirtmektedir. [ 4 ] Ancak risk yönetiminde riskin olumsuz etkisini azaltmak üzerine yoğunlaşılmaktadır.

Riskleri belirledikten sonra kontrol altında tutabilmek için öncelikle riskleri gruplandırmak gerekmektedir. Tablo 1’de gösterildiği gibi yazılım proje riskleri farklı bakış açılarına göre gruplandırılabilinir.[ 5 ]

Tablo 1. Genel Risk Kategorileri [ 5 ] Genel Riskler Ürün Bazlı Riskler Proje Riskleri

Ürün Riskleri

Dikkate Alınması Gereken Faktörler İnsan kaynağı, büyüklük, süreç, teknoloji, kullanılan araçlar, organizasyon, yönetim, müşteri, tahmin, satış, destek İş Birimi Riskleri

Bu çalışmanın ilk bölümünde yazılım projelerinde risk yönetiminin nasıl yapılacağı ve özellikleri kısaca özetlenmiştir. Çalışmanın üçüncü bölümünde ise yapılan araştırma sonucu daha önce risk yönetimi üzerine yapılan çalışmalar hakkında bilgi verilmektedir. Çalışmanın dördüncü bölümünde uygulama için kullanılan veri kümesinin özellikleri aktarıldıktan sonra beşinci bölümde bu veri kümesinin üzerinden yapılan çalışmalar ve sonucu paylaşılmıştır. 2

YAZILIM PROJELERİNDE RİSK YÖNETİMİ

Yazılım proje yönetim sürecinin temel bilgi alanlarından biri olan risk yönetiminin temel amacı, risklerin oluşması olasılığını azaltmak ve olması durumunda negatif etkisini en aza indirmektedir.[ 4 ]

Proje yöneticisinin önemli görevlerinden biri olan risk yönetimi, projenin zamanını, bütçesini veya yazılımın kalitesini etkileyecek risklerin belirlenmesi ve kontrol edilmesini kapsamaktadır.[ 6 ] Risk yönetimi dört temel aşamadan oluşmaktadır: 1. Riskin tanımlanması 2. Risk analizi 3. Risk planlama 4. Risk izleme

İlk üç adım risk değerlendirilmesinde son adım ise riskin kontrol altında tutulmasında kullanılır. 2009’da Tang ve Wang, çalışmalarında risk değerlendirmenin yazılım projelerinde risk yönetiminin temelini oluşturduğunu belirtmişlerdir. [ 7 ] Şekil 1. Yazılım Projesi Risk Değerlendirme Modeli [ 7 ]

Tang ve Wang’in Şekil 1’de gösterilen yazılım projesi risk değerlendirme modeli bulanık mantık teorisi üzerine dayanmaktadır. Uzmanlar, bu modelle risklerin olasılığını ve etkisini bulanık mantık kümeleriyle hesapladıkları gibi risklerin bileşik etkilerini de hesaplayabilmektedirler. [ 7 ] 3

RİSK YÖNETİMİYLE İLGİLİ ÇALIŞMALAR

INET-TR 2014’te sunduğumuz bildirideki[ 8 ] akademik araştırma, risk değerlendirme modelleri üzerine yapılan incelemelerle genişletilmiştir.

Yong Hu ve arkadaşlarının yapay sinir ağları ve destek vektör makinalarıyla yaptıkları risk tahminleme çalışmasında 120 örnek proje rastgele 100’ü öğrenme 20’si de test amaçlı iki gruba bölünmüştür. Modelde 63 risk faktörü girdi ve 8 proje faktörü çıktı olarak standartlaştırıldıktan sonra çıktılar birleştirilerek proje, “başarılı”, “yetersiz” ve “başarısız” olarak sınıflandırılmıştır. [ 9 ] Yaptıkları çalışma sonucunda risk tahminin yapay sinir ağlarını kullanarak %75; destek vektör makinasıyla %85 doğru yapıldığını hesaplamışlardır.

Gupta ve Sadiq’in 2008’de yayınlanan çalışmasında geliştirdikleri yazılım risk değerlendirme ve tahminleme modeli SRAEM’i (Software Risk Assessment and Estimation Model) [ 10 ], 2010’da Sadiq ve arkadaşları genişleterek SRAEP’i (Software Risk Assessment and Evaluation Process) sunmuşlardır. [ 11 ] Bu modelde riskleri tanımlarken model tabanlı yaklaşım kullanılmıştır.

2013’te Manalif tarafından geliştirilen risk değerlendirme modeli, bulanık uzman (Fuzzy Expert)-COCOMO modeline göre geliştirilmiştir.[ 12 ] Fuzzy-ExCOM olarak da isimlendirilen bu modelde 5 ölçek faktörü ve 17 maliyet kalemi girdi olarak kullanılarak proje riskleri tahmin edilmeye çalışılmıştır. Oluşturan modelde zaman, ekip, süreç, ürün, platform ve yeniden kullanım riskleri tahmin edilerek projenin riski belirlenmeye çalışılmıştır. 4

PROJE FAKTÖRLERİNE AİT VERİ SETİ YAPISI

Risk yönetimi üzerine yaptığımız çalışmalarımızda[ 8,13 ] aynı şirkete ait 2010-2012 yılları arasındaki yazılım projelerinin risk verileri kullanılarak verinin doğruluğu tespit edilmiştir. Oluşturmayı hedeflediğimiz risk değerlendirme modeli için risk verisi dışında hangi verilere ihtiyaç olduğu tespit edilmiştir. Bu amaç doğrultusunda veri kümesini genişleterek aynı şirketin 2007-2014 yılları arasında geliştirilen yazılım projelerine ait proje ve risk değerleri toplanmıştır.

Şirket içinde kullanılan proje yönetim aracının veritabanında tutulan proje verileri, Şelale (Waterfall) modeline göre geliştirilen yazılım uygulamalarına ve teknik fizibilite çalışmalarına yönelik büyük projelere aittir. Çünkü şirket organizasyon yapısına göre küçük projeler için bir proje yöneticisi atanmamakta bu projeleri ilgili sistemin analisti yönetmektedir.

Veri kümesinde metin tipinde olan ve sistemin kendi ürettiği özel değerler dışında kalan veriler Tablo 2’de gösterildiği gibi proje faktörü olarak belirlenmiştir.

Faktör No

F1 F2 F3 F4 F5 F6 F7 F8 F9 F10

Model No

N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 Tablo 2. Proje Faktörleri

Proje Faktörü

Sponsor Notu

Baseline Tarihi Kullanıma Alım Tarihi Bitiş Tarihi Proje Ekip Sayısı Analiz Süresi Geliştirme Süresi Test Süresi Talep Değişikliği Sayısı Proje İptal Nedeni

Faktör No

F11 F12 F13 F14 F15 F16 F17 F18 F19 F20 F21

Proje Faktörü

Risk Sayısı

Bekleme Süresi Proje Tipi Risk Tipi Risk Olasılığı Süreçlerin Paralel İlerlemesi İzleme Süresi Projenin Durumu Proje Gecikmesi Bekleme Dönemi Sebebi Proje Süresi

Risk veritabanından elde edilen risk faktörleri ile belirlenen proje faktörleri arasındaki ilişki, Tablo 3’teki gibi değerlendirilmiştir.

Tablo 3. Risk ve Proje Faktörleri İlişkisi

Yazılım projesi risk faktörleri

Proje Faktörleri

Düşük ve kötü kullanıcı katılımı

Gerçekçi olmayan zaman planlaması Gerçekçi olmayan ya da yanlış anlaşılan proje amaçları ve hedefleri Yetersiz ekip sayısı Proje yöneticisinin yetersiz katılımı ve teknik bilgisi Kötü planlama ve stratejiler Yazılım projesi yönetiminin etkili yapılamaması Proje devam ederken organizasyonun değiştirilmesi Projenin büyüklüğü Proje gereksinimlerin düzgün belirlenmemesi F2, F9, F10, F12, F18, F20 F1, F12, F19, F21 F3, F4, F11, F13, F19 F5, F11, F18, F19 F1, F2, F10, F11, F18 F3, F4, F6, F7,F8,F14, F15 F1, F11, F16, F19 F9, F19 F11, F15, F19 F1, F6, F19 5

UYGULAMA VERİSİ ÜZERİNDE YAPILAN ÇALIŞMALAR Önceki çalışmalarda [ 8,13 ] sadece risk verileri değerlendirilirken bu çalışmada diğer proje değerleri kullanılacağı için önce proje veri kümesi temizlenmiştir. Eksik kayıtlar, (uygun olanlar için) ortalama değerle doldurulmuş; anlamlı olmayan kayıtlarsa silinmiştir. Yüksek sapma içeren kayıtlar da silinmiştir. Böylece geriye kalan 2936 kayıt üzerine aşağıdaki modeller çalışılmıştır. 5.1

Süreçlerin Paralelliği ile Risk İlişkisi

Projenin analiz ve geliştirme safhalarının paralelliğiyle proje durumu, toplam risk sayısı ve gecikme süresi arasındaki ilişki incelenmiştir. Projede analiz süreci bitmeden geliştirme başlamışsa süreçler paralel olarak değerlendirilmiş; geliştirme safhası, analiz bittikten sonra başlamışsa süreçlerin paralel olmadığından ayrı bir sınıfta değerlendirilmiştir. Karşılaştırmanın yapıldığı projenin durumunun alabileceği değerler doğrudan veri kümesinden alınmıştır. Model oluşturulurken Naive Bayes sınıflandırma yöntemi kullanılmıştır. Modelin doğruluk oranı %68,14’tür.

Tablo 4. Süreçlerin Paralelliği ile Gecikme ve Risk Sayısı İlişkisi

Sınıf: Süreçlerin

Paralel Olması

Sınıf: Süreçlerin

Paralel Olmaması Özellik

Proje Durumu

Kapalı İptal Edilen Beklemede Diğer 702 158

5 101 966 0.4929 1.2289 35.4587 9.26 680 318 1464 238

10 266 1978 0.7877 1.797 9.0621 32.7536 %68,14 %31,86

Tablo 4’te gösterilen değerlere göre süreçlerin paralel olduğu projelerde risk sayısının daha az olduğu ama gecikme oranının daha yüksek olduğu saptanmıştır. Çünkü analiz süreci tamamlanmamış projede risklerin de iyi analiz edilmediği sonucuna varılabilinir Analiz ve geliştirme safhaları paralel yürüyen projelerin ilerleyen aşamalarında beklenmeyen durumlarla karşılaşılmasına ve projenin gecikmesine sebep olma olasılığı daha yüksek olduğu görülmektedir. 5.2

Analiz Süresinin Proje Sürecine Etkisi

Analiz süresinin proje durumu, kullanıma alım durumu, proje tamamlanma yüzdesi, toplam risk sayısı, bekleme durumu ve gecikme süresiyle ilişkisi incelenmiştir. Küme sayısına doğru karar verebilmek adına K-Means kümeleme yöntemi kullanılmıştır. KMeans ile oluşturulan modelin sonucu, Tablo 5’te gösterilmiştir. Projelerin %78’i birinci sınıfa; %22’si ikinci sınıfa dahil olmuştur.

Tablo 5. Analiz Süresinin Gecikme Süresi ile İlişkisi Özellik

Proje Durumu

Kullanıma alındı mı?

Proje Tamamlanma Yüzdesi

Toplam Risk Sayısı

Bekleme Süresi Var mı?

Analiz Süresi Gerçek ile Planlanan Kullanıma Alım Tarihi Farkı

Bu modele dayanarak analiz süresi uzun olan projelerin zamanında tamamlandığı ve kullanıma alınma oranın, analiz süresi kısa olanlardan daha yüksek olduğu görülmüştür. Yazılım geliştirme sürecinde analiz aşamasının önemli olduğu görülmektedir. Çünkü gereksinimlerin tam ve doğru şekilde karşılandığı adım analiz aşamasıdır. Bu sebeple analizin hatasız şekilde yapılabilmesi için yazılım projelerinde analiz sürecine yeterli zamanının ayırılması gerekmektedir.

Analiz süresi uzun olanlarda risk sayısının daha fazla olması risk analizinin doğru bir şekilde yapılmış olduğunu göstergesidir. Çünkü proje yaşam döngüsünde karşılaşılabilecek risklerin iyi analizi, bu risklere karşı önlemlerin de alınmış olması anlamına gelir.

Analiz süresi uzun olan projelerde bekleme durumuna alınma oranının daha düşük olduğu görülmüştür. Zira iyi analiz edilmiş bir projenin iptal edilme ve beklemeye alınma olasılığı da düşüktür. 5.3

İzleme Süreci ile Risklerin İlişkisi Bu modelde Fuzzy C-Means (FCM) algoritması kullanılmıştır. K-Means’ten farklı olarak bu kümeleme yönteminde K-Means'te örnekleri tam değerleriyle alıp kümelerken FCM, örnekleri 0 ile 1 arasında değişen değerlere çevirip buna göre hangi kümeye ait olduğunu bulmaktadır. Ardından gerçek değerlerin ortalamasını çıktı olarak verir. Temel olarak K-Means algoritmasına benzeyen FCM’in, K-Means’ten farkı verilerin olmamasıdır.[ 14 ] her birinin sadece bir sınıfa dahil edilme zorunluluğunun

Tablo 6. İzleme Süresi ile Risk İlişkisi İzleme

Süresi

30.03 Yukarıdaki Tablo 6’da görüldüğü üzere izleme süresinin yüksek olduğu durumlarda risk sayılarının da yüksek olduğu görülmüştür. Bu da bize risklerin tespitinin doğru yapıldığını, yüksek risk sayılarında daha uzun sürelerle izlemeler gerçekleştirildiğini göstermiştir. Çünkü kullanıma alınmış olsa bile izleme döneminin uzun olması ya kapsamın tam olarak karşılanamadığını ya da çıkan sorunların düzeltilmesi için ayrıca çalışıldığının işaretidir. 5.4

İzleme Süresinin Proje Süresine Bağlı Değerlendirilmesi İzleme süresi ve proje süresi arasındaki orana bakılarak yapılan değerlendirmede Naive Bayes sınıflandırma yöntemi kullanılarak veri, iki sınıfta incelenmiştir: “uzun” ve “normal”. Yapılan sınıflandırmada modelin doğruluk oranı %78’dir.

Tablo 7. Proje Süresine Bağlı İzleme Süresinin Diğer Etkenlerle İlişkisi Özellik

Temel Plan Sayısı

Ortalama

Standart Sapma

Proje Süresi

Ortalama

Standart Sapma

Toplam Risk Sayısı

Ortalama

Standart Sapma

Proje Sponsor Notu

Ortalama

Standart Sapma

Analiz Süresi Sınıf UZUN

2.3399 1.2463 198.2768 135.2367 0.7197 1.6984 3.8748 0.5854

NORMAL 2.3055 1.5142 210.2318 116.4358 0.6308 1.5027 3.8973 0.5892

Standart Sapma

Ortalama

Standart Sapma 62.9559 63.7302

Tablo 7’de görüldüğü gibi izleme süresi, eşik değerin üzerinde olan projelerin risk sayısı yüksektir. Beklendiği gibi izleme dönemi daha kısa olan projelerin genel proje süresinin yüksek olduğu görülmektedir. Çünkü kullanılmaya başlandıktan sonra tam karşılanamayan ya da hatalı karşılanan gereksinimler diğer bir deyişle analizi iyi yapılmayan projelerin izleme süresini uzatmaktadır. İzleme süresi normal olan projelerin sponsor notunun yüksek olması da bu durumun başka bir göstergesidir. 5.5

Proje Ekibinin Büyüklüğü ile Proje Başarısının İlişkisi

Proje ekip sayısının projenin durumu, kullanıma alım durumu, proje süresi, proje tamamlanma yüzdesi, toplam risk sayısı ve gecikme süresiyle ilişkisi incelenmiştir. KMeans kümeleme yönteminde iterasyon sayısı dört olarak belirlendiğinde elde edilen sonuçlar Tablo 9’da verilmiştir.

Tablo 8. Ekip Sayısının Diğer Etkenlerle İlişkisi Özellik

Proje Durumu

Kullanıma Alındı mı?

Proje Süresi

Proje Tamamlanma Yüzdesi

Toplam Risk Sayısı

Proje Ekip Sayısı Gerçek ile Planlanan Kullanıma Alım Tarihi Farkı

Evet

215.4322 96.2088 0.6889 9.2312 6.0735

Sınıf 1 (641) %22 İptal

Hayır 154.1669 31.3435 0.2168 6.4558 20.1248

Tablo 9’da gösterilen sonuçlara dayanarak ekip sayısının projenin zamanında bitirilmesinde etkili olduğu gözlenmiştir. Ekip sayısının az olduğu projelerde kullanıma alınma oranının daha az olduğu ve gecikme süresinin fazla olduğu görülmüştür. Ekip sayısının yüksek olduğu projelerde risk sayısının yüksek olduğu görülmüştür. 5.6

Proje Aciliyet Durumunun Risk ile İlişkisi

Projenin yer aldığı dönemin özelliği sınıf özellik olarak seçilerek projenin acil (Urgent) ya da acil olmayan/planlanan (Roadmap) olmasının projenin süresiyle, projenin tamamlanma yüzdesiyle, toplam risk sayısıyla, gecikme süresiyle ve analiz, geliştirme ve test süreçlerinin süreleriyle ilişkisi Naive Bayes Sınıflandırma yöntemi kullanılarak incelenmiştir. Modelin doğruluk oranı, %89’dur. Tablo 10’da gösterildiği üzere acil projelerin, acil olmayanlarla benzer analiz süresine sahip olduğu ancak geliştirme ve test sürelerinin daha kısa olduğu görülmüştür.

Acil projelerde risk sayısının daha fazla olduğu görülmüştür. Hızlı ilerlemesi gereken projelerde amaç ihtiyacı olabildiğince çabuk karşılamak olduğundan, zaman baskısı sebebiyle her zaman doğru çözümler üretilemeyebilir. Bu da risk sayısının fazla olmasına sebep olabilir. Bu nedenle acil projelerde ürün kullanılmaya başlandıktan sonra bile risk sayısının fazla olması sebebiyle acil olmayan projelere göre daha uzun süre takip edilmesi gerekebilir.

Tablo 9. Projenin Aciliyeti ile Diğer Etkenlerin İlişkisi Özellik

Sınıf Roadmap 0.2458 0.8502 0.0121 0.1667

Ortalama

Standart Sapma

Gerçek ile Planlanan Kullanıma

Alım Tarihi Farkı

Ortalama Standart Sapma Yazarlar, çalışmanın temelini oluşturulan veri kaynağının sağlanmasında Turkcell Teknoloji A.Ş.’ye teşekkürlerini sunarlar.

References

1. The Standish Group. Chaos Manifesto 2013 Report . The Standish Group International, Inc., ( 2013 )

2. Gartner Institute , http://www.gartner.com/technology/home.jsp

3. Albayrak , B. : Proje Yönetimi, Nobel Yayın Dağıtım ( 2005 )

4. Project Management Institute, http://www.pmi.org

5. Realsearch , Risk Managemet, http://agile.csc.ncsu.edu/SEMaterials/RiskManagement.pdf

6. Sommerville , I. : Software Engineering, 9th ed., Addison-Wesley , ( 2011 )

7. Tang , A. , Wang , R. : Software Project Risk Assessment Model Based on Fuzzy Theory” , International Conference on Computer and Communication Technologies in Agriculture Engineering, ss. 328 - 330 , ( 2010 )

8. Olcaysoy Buharalı , A. Kalıpsız , O. : Bilişim Projelerinde Yazılım Risk Yönetimi: Telekomünikasyon Örneği , 19 . Türkiye'de Internet Konferansı - INET-TR 2014 , İzmir ( 2014 )

9. Hu , Y. ve arkadaşları : An Intelligent Model for Software Project Risk Prediction , International Conference on Information Management, Innovation Management and Industrial Engineering , pp. 629 - 639 , ( 2009 )

10. Gupta , D. , Sadiq , M. : Software Risk Assessment and Estimation Model, International Conference on Computer Science and Information Technology , ( 2008 )

11. Sadiq , M. ve arkadaşları: Software Risk Assessment and Evaluation Process (SRAEP) using Model Based Approach , Proceedings of the International Conference on Networking and Information Technology , pp. 171 - 177 , ( 2010 )

12. Manalif , E. : Fuzzy Expert-COCOMO Risk Assessment and Effort Contingency Model in Software Project Management" . University of Western Ontario - Electronic Thesis and Dissertation Repository . p. 1159 , ( 2013 )

13. Olcaysoy Buharalı , A. , Kalıpsız , O. : Data Verification of Telecommunication Projects for Risk Assessment Models , The First International Conference on Advances and Trends in Software Engineering - SOFTENG , Barselona ( 2015 )

14. Işık , M. , Çamurcu , A.Y.: K-Means , K-Medoids ve Bulanık C-Means Algoritmalarının Uygulamalı Olarak Tespiti, İstanbul Ticaret Üniversitesi Fen Bilimleri Dergisi Yıl: 6 Sayı:11, ss . 31 - 45 , ( 2007 )