Özet. Sistem ve yazılım mühendisliği disiplinlerini kullanarak büyük ve karmaşık ürünler geliştiren organizasyonlarda proje ve süreç yönetimi faaliyetlerinin etkili bir şekilde uygulanması ve yönetilmesi kaçınılmaz olarak zorlaşmaktadır. Ayrıca günümüzde ürün geliştirme faaliyetleri genellikle organizasyonun farklı birimlerinin işbirliği ile gerçekleştirilmektedir. Bu tür büyük yapıları daha etkin yönetebilmek için süreçlerin tanımlanması, modellenmesi, çalışanlar arasında iletişim ve işbirliği platformunun sağlanması ve mümkün olan tüm yönetsel aktivitelerin otomasyonu gerekir. Bu çalışmada yazılım süreç yönetimi alt yapısı oluşturmak için, uygun bir süreç yönetimi aracı seçmek üzere, yürütülen faaliyetler anlatılmıştır. Bu kapsamda araç seçim kriterleri belirlenmiş, süreç yönetim araçları üzerinden değerlendirme yapılmış ve sonuçlar karşılaştırılmıştır.
GİRİŞ
Büyük ve karmaşık sistemler geliştiren organizasyonların ürün geliştirme süreçlerini tanımlayıp, sürekli iyileştirmesi gerekmektedir. Kalitesiz ürün geliştiren organizasyonlar itibar, müşteri ve gelir kaybı riski ile karşılabilir ve hatta organizasyonun geleceğini tehlikeye atabilirler. Bunun bilincinde olan organizasyonlar, süreç ve proje yönetimi faaliyetlerini optimize etme konusunda giderek artan bir çaba göstermektedirler.
Süreç ve proje yönetimi faaliyetlerinin en iyi uygulama pratiklerine göre yönetilebilmesi için gereksinim mühendisliği, proje yönetimi, doküman yönetimi ve konfigürasyon yönetimi yazılımları mevcuttur. Bu yazılımlar ile ürün geliştirme sırasında işletilen süreçlerin bir bölümü veya tamamı yürütülmekte veya desteklenmektedir. Ancak bu yazılımlar entegre çalışamadığından proje yöneticileri ve çalışanlar tarafından farklı alanlar için ayrı yazılımlar kullanılmakta, bu da toplam efor gereksinimini arttırarak verimliliğin azalmasına sebep olmaktadır.
Bu çalışma kapsamında özellikle ARGE faaliyetleri yürüten ve kurumsal stratejileri gereği tanımlı olan ürün geliştirme süreçlerini kısmen veya tamamen uygulaması gereken organizasyonlar için süreçlerin izlenmesi ve projelerin gerçekleşme durumlarının tek bir merkezi ortam üzerinden takibine yönelik gerçekleştirilen süreç yönetim yazılımı değerlendirmesi sonuçları sunulmuştur. Süreç yönetim yazılımı ile aşağıda detayları verilen ihtiyaç ve beklentilerin karşılanması hedeflenmiştir: o Proje yaşam döngülerine göre süreçlerin jenerik olarak modellenmesi o Projelerin özel gereksinimlerine göre süreç uyarlamalarının yapılması o Anahtar performans göstergelerinin çeşitli bilgi kaynaklarından otomatik olarak toplanabilmesi o Toplanan metriklerin ürün, proje, program veya kurumsal seviyede raporlanması o Süreçlerde tanımlı olan faaliyetlerin proje çalışanlarına görev olarak atanabilmesi o Geçmiş veri üzerinden iyileştirilmesi gereken noktaların belirlenmesi/ uyarılması o Farklı lokasyonlardaki birimler için işbirliği ve koordinasyon imkanı sağlaması
Süreç yönetim yazılımının Kurumda kullanılan konfigürasyon ve versiyon yönetimi yazılımları: ClearCase, CVS, Subversion ve proje yönetim yazılımı: MS Project ile entegre çalışması amaçlanmıştır. Süreç yönetim yazılımının, görev ve konu takibi amacıyla kullanılan JIRA yazılımının fonksiyonlarının tamamını yerine getirebilme durumu söz konusu olursa bunun yerine süreç yönetim yazılımının kullanılmasına karar verilmiştir.
Çalışmanın geri kalanında referans alınan makaleler özetlenmiş, süreç yönetim yazılımını değerlendirmek üzere yapılan ön çalışmalar ve oluşturulan kriterler sunulmuş, gerçekleştirilen değerlendirme sonuçları analiz edilmiş ve son olarak sonuçlar ve gelecekte yapılacak çalışmalar verilmiştir. 2
İLGİLİ ÇALIŞMALAR
Stefan R. Koster çalışmasında [
Berrocal J., Garcia-Alonso J., Murillo J.M. [
Kurumda 2012 yılında başlatılan “İş Süreçlerinin Yeniden Yapılandırılması”
Projesi kapsamında süreç alanları belirlenmiş ve çalışma grupları tarafından süreç
tanımları yapılmıştır. Çalışma grupları tarafından iş akışları Microsoft Visio
diyagramlarında “Business Process Modelling Notation (BPMN)” notasyonu
kullanılarak çizilmiş olup, süreç tanımlama dokümanları ve ilgili varlıkları Microsoft
Word’de oluşturulmuştur. Çalışmalar sonrasında özellikle süreç varlıklarının kağıt
üzerinden idamesinin zorluğu, süreçlerin çalışanlar tarafından anlaşılmasını
kolaylaştırmak ve süreçlerin bir bütün halinde görülmesi gibi ihtiyaçlardan hareketle
2013 yılında süreç yönetim yazılımı kullanımı söz konusu olmuştur. Bu ihtiyaçlardan
hareketle Gartner raporunda [
“Senaryo 1: Projede değişiklik yönetimi sürecini işlettiğimizi düşünelim. Bu kapsamda müşteriden onayı alınan Yazılım Gereksinimleri Belirtimi Dokümanı üzerinde müşteri tarafından talep edilen bir değişiklik isteği olsun. Bu talep Projenin Konfigürasyon Yönetimi Sorumlusu tarafından JIRA veya Rational ClearQuest aracı üzerinden değişiklik istek formu (DIF) doldurularak tanımlanır ve Proje Yöneticisine iletilir. Proje Yöneticisi formu gözden geçirir ve gerekirse formun ilgili yerlerinde düzeltmeler yapabilir. Proje Yöneticisi değişiklik isteği ile ilgili olarak Konfigürasyon Kontrol Kurulu toplanmasına gerek duyarsa kurul üyelerini belirler ve formda ilgili bölüme üyeler tanımlanır. Belirlenen üyelere sistem tarafından bilgilendirme e-postası gönderilir. Planlanan toplantıda kurul üyeleri tarafından değişiklik isteği değerlendirilir ve red veya yapılması onayı verilir. Yapılacak değişiklik istekleri için PY tarafından proje ekibinde yer alan ilgili personele JIRA veya Rational ClearQuest üzerinden DIF ile ilişkilendirilerek eylem maddesi açılır. JIRA üzerinde kapandı durumuna gelen eylem maddesi PY tarafından doğrulanır. PY tarafından doğrulanan eylem maddesi ile ilgili olarak Proje Kalite Güvence Sorumlusu tarafından da doğrulama yapılarak DIF kapatılır.
Yukarıda verilen senaryoya ek olarak süreç yönetim aracı üzerinden açık olan DIF sayısı ve kapanan DIF sayısı göstergelerinin gerçek zamanlı olarak proje ekibi tarafından izlenebilmesini istiyoruz.
Senaryo 2: Projede yazılım tasarım ve gerçekleştirme sürecini işlettiğimizi düşünelim. Yazılım Gereksinimleri Belirtimi Dokümanı müşteri tarafından onaylandıktan sonra Yazılım Geliştirme Sorumlusu tarafından yazılım mimarisi tasarlanır. Proje ekiplerinin farklı yazılım geliştirme ortamları kullandıkları göz önünde bulundurularak, bu faaliyetin çıktısı olarak herhangi bir UML diyagramı oluşturulur. Bu aşamada Yazılım Takım Lideri veya Proje Yöneticisi tarafından ihtiyaç duyulan durumlar için alternatif çözümler ve seçim kriterleri belirlenerek analiz yapılabilir. Analizin sonucu Alternatif Çözüm Analizi Raporu ile dokümante edilir. Yazılım mimarisi belirlendikten sonra gereksinimler mimari tasarım bileşenlerine Rational DOORS aracı üzerinden atanır. Atama yapıldıktan sonra yazılım mimarisi, Yazılım Geliştirme Sorumlusu tarafından proje ekibine gözden geçirmeye sunulur. Bunun için JIRA üzerinden tüm proje ekibine görev ataması yapılır. Proje ekibi personeli gözden geçirme sonucundaki bulgularını JIRA üzerinden görevle ilişkilendirerek bulgu olarak açar. Planlanan toplantıda tüm bulgular üzerinden geçilerek red veya yapılması onayı kararı alınır. Gerçekleştirilecek düzeltici faaliyetler ile ilgili olarak PY tarafından proje ekibinde yer alan ilgili personele JIRA üzerinden bulgu ile ilişkilendirilerek eylem maddesi açılır. JIRA üzerinde kapandı durumuna gelen eylem maddesi PY tarafından doğrulanır ve kapatılır. Yazılım Geliştirme Sorumlusu/Sorumluları tarafından yazılım tasarımına ve kodlama standartlarına uygun olarak kodlama ve birim testleri yapılır. Gerçekleştirilen birim ve bileşenler tümleştirme sürecine uygun olarak tümleştirilir.
Yukarıda verilen senaryoya ek olarak süreç yönetim aracı üzerinden açık olan bulgu sayısı, kapanan bulgu sayısı ve açık/kapalı eylem sayısı göstergelerinin gerçek zamanlı olarak proje ekibi tarafından izlenebilmesini istiyoruz.”
Yapılan ön görüşmeler neticesinde firmaların sistem ve yazılım mühendisliği projelerine yönelik herhangi bir deneyim ve uygulamalarının olmadığı görülmüştür. Firmalara ihtiyaçlarımızı daha net aktarabilmek ve firmaları objektif değerlendirebilmek için kriter listesi oluşturulması ve değerlendirme sonuçlarına göre seçilen firma veya firmalarla pilot proje çalışması yapılmasına karar verilmiştir. 3.1
Tablo 1’de verilen kriterler belirlenirken Koster’in [
Tablo 1. - Kriter Listesi
Farklı süreç modelleme dilleri/ notasyon1. larını desteklemesi BPMN gibi standart bir dil destekleniyorsa 6 puan buna ek olarak desteklenen diğer tüm diller için ekstra 1 puan (max. 12.
Sürecin farklı görünümler için desteklenmesi (functional, organizational, behavioural, informational) İş kurallarının süreç modelinden bağımsız tanımlanabilmesi
veya grafiksel yöntemler ile tanımlanabilmesi
Alt süreçlerden ilgili diğer süreç modellerine erişim sağlanabilmesi Süreç modeli ile ilgili/ etkileşimli diğer süreçlerin bir bütün olarak gösterilmesi Jenerik süreçlerden, tanımlanan uyarlama kriterlerine bağlı kalarak proje süreçlerinin tanımlanması (yeni bir proje başladığında proje yönetim ekibi tarafından projenin hedef ve ihtiyaçlarına göre genel tanımlı süreçlerden projeye özel süreçler belirlenebilmesi hakkında) 11.
Teknik Kriterler
Web arayüzünün gereksinimlere göre uyarlanabilmesi
tanımlanabiliyorsa 10 puan tanımlanamıyorsa 0 puan KPI'lar formlar üzerinden tanımlanabiliyorsa 7 puan, grafiksel gösterim ile tanımlanabiliyorsa 5 puan ve kod ile tanımlanabiliyorsa 3 puan Süreç modelinin farklı versiyonları tutulabiliyorsa 10 puan tutulamıyorsa 0 puan Süreç modelinin içinde alt süreç ve aktivite tanımlanabiliyorsa 10 puan tanımlanamıyorsa 0 puan Link verilebiliyorsa 10 puan verilemiyorsa 0 puan
modellerine link verilebiliyorsa 10 puan verilemiyorsa 0 puan Süreç modeli ile etkileşimli tüm süreçler gösteriliyorsa 10 puan gösterilemiyorsa 0 puan Projenin büyüklüğü, çalışan sayısı, proje yaşam döngüsü vb. kriterler temel alınarak uyarlama kriterleri belirlenebiliyorsa 5 puan Jenerik süreçlerden uyarlama kriterlerine bağlı kalarak proje süreçleri belirlenebiliyorsa 5 puan Uyarlanabiliyorsa 10 puan uyarlanamıyorsa 0 puan Görev listesi web arayüzünden görüntülenebiliyorsa 8 puan diğer bilgilendirme yöntemleri için ekstra 1 puan (max 10 puan) Çalışanlara manuel olarak görev atanabilmesi Kullanıcılara görev atandığında sistem tarafından aktif olarak bilgilendirme yapılması
(detay seviye) göstergelerin izlenmesi Veriyi daha ayrıntılı bir şekilde görüntülemek için bağlantılar sağlaması (örneğin dashboard'lardaki grafiklerden veriye erişim sağlanabilmesi) Farklı veri için farklı veri gösterim teknikleri sağlaması (örn. Histogram, bar chart, pie chart, scatter diagram gibi) İzleme ve Kontrol Kriterleri 21. 22.
Bilginin farklı görünümler için desteklenmesi (2.soru da verilen görünümler için)
Süreç modelindeki alt süreç ve aktiviteler ile Alt süreç ve aktiviteler ile kuruluşta temel alınan standart/ süreç standart/ süreç iyileştirme modiyileştirme modelleri arasında ilişki ku- elleri arasında ilişki kurulabilirulması (ISO 9001:2008, CMMI-DEV v1.3, yorsa 10 puan kurulamıyorsa 0 AQAP-160, ISO/IEC 12207:2008 vb.) puan Proje başında belirlenen uyarlanmış süreçler Uyumluluk analizleri yapılarak için kuruluşta temel alınan standart/ süreç raporlanıyorsa 10 puan iyileştirme modellerine göre uyumluluk yapılamıyorsa 0 puan analizleri yapılması ve raporlanması CMMI-DEV veya ISO/IEC 15504 Değerlendirme yapılıyorsa 10 kıymetlendirmesi için imkan sağlaması puan yapılamıyorsa 0 puan 13. 14. 15. 16. 17. 18. 19. 20. Çalışanlara manuel olarak görev atanabiliyorsa 10 puan atanamıyorsa 0 puan E-posta yoluyla bilgilendirme yapılıyorsa 8 puan diğer bilgilendirmeler için ekstra 1 puan (max 10 puan) İşletilen süreç örneği değiştirilebilir ancak bu değişiklik sadece yeni süreç örnekleri için geçerliyse 4 puan Değişiklik tüm süreçlerde zorunlu kılınıyorsa 4 puan Tasarımcı iki seçenek arasında seçim yapabiliyorsa 2 puan
im sağlanıyorsa 10 puan sağlanamıyorsa 0 puan
sağlanan diğer tüm gösterim şekilleri için ekstra 1 puan (max 10 puan) Her bir görünüm için 2.5 puan verilecektir. (10 puan) 3.2
Tablo 1’de verilen ana grupların altındaki kriterler eşit ağırlıklı olarak düşünülmüş olup, değerlendirme ve analiz ortalama puana göre yapılmıştır. Görüşülen ve değerlendirilen yazılımlar Yazılım A, B, C ve D olarak isimlendirilmiş ve sonuçlar buna göre verilmiştir. Firmalar tarafından gönderilen cevaplar Tablo 1’de verilen puanlama yöntemine göre değerlendirilmiş olup, Şekil 1’de her bir yazılımın kriterler bazında puanlaması, Şekil 2’de kriterler bazında en yüksek puanı alan yazılımlar verilmiştir.
Şekil 1. Süreç yönetim yazılımı radar şeması Şekil 1’de görüldüğü üzere yazılım A ve B üzerinden süreçlerin standart ve süreç iyileştirme modelleri ile eşleştirmesi ve uyarlanmış süreçler için uyumluluk analizleri yapılamamaktadır. Ayrıca bu yazılımların kritik performans göstergelerine ilişkin fonksiyonlar açısından yazılım C ve D’ye göre daha zayıf olduğu anlaşılmaktadır. Yazılım C tüm kriterler açısından en yüksek puanı alan yazılım olmuştur. Şekil 2. Kriterlere göre yazılım değerlendirmesi 4
Firmalarla yapılan görüşmeler neticesinde iş süreci yönetimi yazılımlarının ağırlıklı olarak bankacılık, sigortacılık ve telekomünikasyon sektörlerinde kullanıldığı ve sistem/ yazılım mühendisliği projeleri yürüten organizasyonlarda herhangi bir uygulama ve deneyimlerinin olmadığı anlaşılmıştır. Bundan dolayı kriterlerin firmalar tarafından eksik/ yanlış anlaşılmasının söz konusu olduğu düşünülmektedir. Değerlendirmenin kriterler temel alınarak belirlenen senaryolar üzerinden firmalar ile birlikte yapılmasının daha doğru olacağı düşünülmektedir. Çalışmanın bundan sonraki aşamasında değerlendirme sonuçlarına göre seçilen firma veya firmalarla pilot proje çalışması yapılması yerine görüşülen tüm firmalar ile senaryolar üzerinden kriterler temel alınarak pilot proje yapılması değerlendirilecektir. Süreç yönetim yazılımlarının çalışma ortamına kurulması ve tarafımızdan süreç modelleme, yürütme ve performans sonuçlarının alınması da düşünülmüş fakat yazılımların kullanımına yönelik herhangi bir deneyimimiz olmadığı için çalışmaların firma yetkilileriyle yürütülmesinin çok daha hızlı ve etkin olacağı değerlendirilmiştir.
Bu çalışma Kurumdaki Kalite Güvence ve Süreç Yönetim Ekipleri tarafından başlatılmış olup ilgili tüm paydaşların belirlenerek çalışma grubuna dahil edilmesi hedeflenmiştir. Bundan sonraki adım olarak süreç yönetim yazılımı seçimi gerçekleştirilecektir. Seçilen yazılımın uygulamadaki kullanımı dikkate alınarak, sistem ve yazılım mühendisliği süreçleri gereksinimlerinin ve kurumun süreç yönetim yazılımı ile ilgili hedeflerinin karşılanma durumu değerlendirilecektir.