bilgiz.org

İstatistiksel Süreç Kontrolünün Yazılım Süreçlerine Uygulanabilirliğini Değerlendirme ve Analiz Aracı

  • 1.Giriş
  • 2.İSK’nın Uygulanabilmesini Sağlayan Bir Araç
  • 3.SPC-AAT İle Yapılan Örnek Bir Değerlendirme Ve Analiz
  • 3.1.Yazılım Firmasındaki Örnek Değerlendirme
  • 3.2.Yazılım Firmasındaki Örnek Analiz
  • 3.3.Çubuk ve Pareto Grafik Analizleri
  • 3.4.Analiz Özeti ve Kazanımlar
  • 4.Sonuçlar
  • 5.Kaynakça



  • Tarih28.12.2017
    Büyüklüğü88.81 Kb.
    TipiYazı

    Indir 88.81 Kb.

    İstatistiksel Süreç Kontrolünün Yazılım Süreçlerine Uygulanabilirliğini Değerlendirme ve Analiz Aracı
    Serkan Kırbaş1 Dr. Ayça Tarhan2 Doç. Dr. Onur Demirörs3

    1Siemens EC Kurumsal İletişim Hiz. San. ve Tic.A.Ş., ODTÜ Teknokent, Ankara

    2Bilgisayar Mühendisliği Bölümü, Hacettepe Üniversitesi, Ankara

    3Enformatik Enstitüsü, Orta Doğu Teknik Üniversitesi, Ankara

    1e-posta: serkan.kirbas@siemens.com 2 e-posta: atarhan@cs.hacettepe.edu.tr

    3 e-posta: demirors@ii.metu.edu.tr

    Özetçe

    Yazılım mühendisliği alanında, İstatistiksel Süreç Kontrolü (İSK) şuan yalnızca CMMI ve ISO/IEC 15504 gibi süreç iyileştirme modellerine göre yüksek olgunluk seviyesine sahip organizasyonlar tarafından kullanılmaktadır. Bu olgunluk seviyesine ulaşmamış veya bu modelleri esas almayan kuruluşlar için istatistiksel yöntemlerin uygulanması güçtür. Bu makalede, özellikle gelişmekte olan organizasyonlar için İSK’nın uygulanmasını kolaylaştıracak ve geliştirecek bir yazılım aracı tanıtılmaktadır. Geliştirdiğimiz araç, yazılım süreçlerinin ve metriklerinin İSK kullanımı için uygunluğunu değerlendirmek amacıyla kullanılmakta ve kontrol grafikleri, histogramlar, bar grafikleri, pareto grafikleri gibi İSK tekniklerini kullanarak yazılım süreçlerinin analizinin yapılmasını kolaylaştırmaktadır. Bu makalede, geliştirdiğimiz araç ve aracın bir yazılım geliştirme şirketinin hata düzeltme süreci üzerinde uygulanması anlatılmaktadır.


    1.Giriş


    İstatistiksel Süreç Kontrolü (İSK), değişkenliğin azaltılması yoluyla süreç istikrarını sağlamak ve süreç yeterliliğini geliştirmek için kullanılan birçok güçlü tekniği içinde barındırır. Üretim disiplinlerinde süreç kontrolü için kullanılan İSK henüz yazılım sektöründe sıkça kullanılmamaktadır.

    Yazılım sektöründe, İSK tekniklerinin uygulanması temel olarak ISO/IEC 15504 [15] ve CMMI [5] gibi süreç iyileştirme modellerinin yüksek olgunluk veya yeterlilik seviyeleri için istenmektedir. Süreç iyileştirme modellerinin dışında, bazı araştırmacılar da İSK tekniklerinin yazılım süreçlerine uygulanması konusunda çeşitli yaklaşımlar geliştirmişlerdir [2, 8, 12]. Ayrıca İSK’nın yazılım süreçlerine uygulanması konusundaki zorlukların nedenlerini ortaya koymuşlar ve genel önerilerde bulunmuşlardır [3, 4, 10, 12, 18, 20, 21]. Fakat yayınlanan çalışmalar [1, 11, 13, 16, 17, 25] göstermektedir ki; İSK tekniklerinin özellikle gelişmekte olan yazılım şirketlerinde yeterli, güçlü araçlar ve yöntemler yardımıyla uygulanmasını sağlayacak yönergelere ihtiyaç vardır.

    Bu ihtiyaçtan yola çıkarak yazılım süreç ve metriklerinin İSK için uygunluğunu araştırdığımız bir dizi çalışma gerçekleştirdik. İlk olarak İSK tekniklerini gelişmekte olan bir yazılım şirketinde uyguladık [6] ve bunun sonucunda yönergeler çıkardık [7]. Daha sonra organizasyonlar için İSK uygulanmasını yönlendirecek bir değerlendirme modeli geliştirdik [23] ve bu modeli gelişmekte olan organizasyonlarda kullandık [24]. Bu çalışmalarda başarılı sonuçlar alınmasına rağmen, değerlendirme ve analizi destekleyecek uygun bir yazılım aracı olmadan İSK tekniklerinin organizasyonlardaki çalışanlar tarafından uygulanmasının çok da kolay olmadığının farkına vardık. Metrik verilerinin alınması ve süreç yürütmeleri ile ilişkilendirilmesi, mantıksal veri kümelerinin tanımlanması, süreç metriklerinin İSK’da kullanılabilirliğinin değerlendirilmesi, istatistiksel analizlerin yapılması ve sonuçların raporlanması uzmanlık gerektiren işlerdi ve uzman işgücü gerektiriyordu. Bunları göz önüne alarak, İSK’nın özellikle gelişmekte olan ve/veya yüksek olgunluk seviyelerine sahip olmayan organizasyonlara uygulanmasını kolaylaştıracak SPC-AAT (An Assessment and Analysis Tool for Statistical Process Control) adında bir yazılım aracı geliştirdik. SPC-AAT, diğer istatistiksel analiz araçlarından süreç yürütmeleri ve özellikleriyle süreç verisini ilişkilendirmesiyle ve analiz için yönlendirme sağlamasıyla ayrılır.

    Geliştirdiğimiz araç ve aracın dayandığı genel kavramlar makalenin 2. bölümünde anlatılmıştır ve 3. bölümde aracın bir örnek olay incelemesi üzerinde uygulanması gösterilmiştir. 4. bölümde de sonuçlar ve gelecekteki olası çalışmalar anlatılmıştır.


    2.İSK’nın Uygulanabilmesini Sağlayan Bir Araç


    SPC-AAT, yazılım süreç ve metriklerinin İSK’ne uygunluğunu sınamak için bir değerlendirme modeli [23] esas alınarak geliştirildä. Kullanılan değerlendirme modelinde, İSK uygulanabilirliği için iki temel gereksinim olduğu varsayılır: süreç yürütmelerinin ve ilişkili verinin mantıksal kümelenmesi, metrik verisinin istatistiksel analiz için uygun özellikler göstermesi.

    Mantıksal kümeleme ile çeşitli ölçütlere göre süreç başarımını temsil eden verilerin elde edilmesi ve kullanılması hedeflenir. Diğer bir deyişle, mantıksal kümeleme yardımıyla analiz edilen verinin yaklaşık olarak aynı özellikleri içeren süreçler sonucunda oluştuğundan emin olunması istenir. Kullanılan değerlendirme modeli, her bir süreç yürütmesini girdiler, çıktılar, etkinlikler, roller ve teknikler gibi süreç öznitelikleri ile tanımlamayı gerektirir. Daha sonra süreç öznitelik değerlerindeki benzerlikleri ölçüt alarak süreç tutarlılığı fikrine dayanan bir kümeleme yöntemini kullanmayı önerir. Süreç tekrarları süreç öznitelik değerleri bakımından benzerlikler gösteriyorsa, bu süreç yürütmelerinin kendi içlerinde tutarlı icra edilen bir süreç kümesi oluşturduğu söylenebilir. Her bir süreç kümesinin verileri üzerinde yapılacak analizlerin süreç kontrolü için daha fazla içgörü sağlayacağı kabul edilmektedir [9].

    Metrik kullanılabilirlik analizi; temel ölçme pratikleri, metrik verilerinin mevcudiyeti ve özellikleri üzerinde sorgulama içerir. Modelde, altı adet metrik kullanım özniteliği tanımlanmıştır: Metrik kimliği, veri mevcudiyeti, veri doğrulaması, veri güvenilirliği, veri normalleştirme, ve veri kaynaştırılabilirliği. Bu özniteliklere bağlı olarak modelde anketler tanımlanmıştır ve İSK kullanımına başlamadan önce metriklerin istatistiksel analiz için kullanılabilirliğinin incelenmesi gerekmektedir. İnceleme sonuçlarına göre, her bir metrik kullanım özniteliği için dört değerden biri atanır: Tamamen kullanılabilir (F), ekseriyetle kullanılabilir (L), kısmen kullanılabilir (P), ve kullanılamaz (N). Bir metriğin toplamda kullanılabilir yada kullanılamaz olduğunun kararı öznitelik değerlerine göre verilir.

    SPC-AAT tarafından tamamen desteklenen değerlendirme modelinin varlıkları kısaca aşağıda tanımlanmıştır:

    - Süreç Yürütme Tutanağı: Bir süreç yürütmesi için süreç özniteliklerinin o anki değerlerini tutmaya yarar. Girdilerin, çıktıların, etkinliklerin, rollerin, ve araç ve tekniklerin belli bir süreç yürütmesi için gerçek değerleri bu forma kaydedilir. Kaydedilen değerler, daha sonra süreç özniteliklerinin birleştirilmiş bir listesini tanımlamak için kullanılırlar ve bu liste Süreç Benzerlik Matrisi üzerinde doğrulama için gösterilir.

    - Süreç Benzerlik Matrisi: Süreç özniteliklerinin değerlerini süreç yürütmelerine göre doğrulamak için kullanılan formdur. Matris, Süreç Yürütme Tutanaklarına önceden girilen süreç öznitelik değerlerinden oluşturulur. Süreç öznitelik değerleri matrisin dizeçlerinde, süreç yürütme numaraları ise matrisin dikeçlerinde gösterilir. Süreç yürütmelerinin üzerinden giderek, süreç özniteliklerinin değerleri sorgulanır ve uygun olan süreç yürütmeleri için işaretleme yapılır (bkz. Şekil 2). Tamamlanmış matris, süreç yürütmeleri arasındaki farkların görülmesine ve uygun şekilde mantıksal kümeler tanımlanmasına yardımcı olur.

    - Metrik Kullanılabilirlik Anketi: Metrik kullanılabilirlik öznitelikleri açısından bir süreç metriğinin kullanılabilirliğini araştırmak için kullanılan formdur. Formda sorular ve kullanılabilirlik özniteliklerini değerlendirmek için kurallar tanımlanmıştır (bkz. Şekil 4 ve Şekil 5). İki tip Metrik Kullanılabilirlik Anketi vardır: Taban metrikler için ve türetilmiş metrikler için.

    - Süreç Yürütme Anketi: Sürece dahil olan kişiler, sürecin yürütüldüğü ortam ve diğer etmenlerdeki değişiklikler açısından bir süreç yürütmesindeki problemler ve bunların ayrılabilir sebeplerini araştırmak için kullanılan formdur. Geçmişte yürütülmüş bir sürecin verileri üzerinde çalışırken her kontrol-dışı nokta için bir anket doldurulur ve verilen cevaplar problemlerin ayrılabilir sebeplerini bulmak için incelenir.

    SPC-AAT, dışarıdan süreç verisi aktarımına, yazılım süreçlerinin ve metriklerinin İSK için uygunluğunu değerlendirmeye ve yazılım süreçlerini kontrol grafikleri, histogramlar, bar grafikleri ve pareto grafikleri gibi İSK tekniklerini kullanarak incelemeye olanak sağlar. Buna bağlı olarak, aracın kullanıcı arayüzünde üç temel görünüm vardır (bkz. Şekil 2): Süreç Verileri (“Process Data”), Değerlendirme (“Assessment”) ve Süreç İyileştirme (“Process Improvement”).

    SPC-AAT, yürütülen süreçlerin metrik verilerini tutan ortamdaki diğer araçlarla tümleşik çalışabilir. Bu araçları SPC-AAT’ye tümlemek için iki yol vardır (bkz. Şekil 1): “Intermediate” altyapısını [22] kullanmak ya da araçlardaki verilerin doğrudan dışarı aktarımı ile oluşturulan CSV, Excel dosyalarını kullanmak. “Intermediate” altyapısı için, ölçme araçlarına bağlanan ve metrik değerlerini üreten “veri toplayıcı” adında küçük yazılımlar kullanılır ve “veri toplayıcılar” diğer araçlardan metrik verilerini SPC-AAT’e XML dosyaları şeklinde sağlarlar. “Intermediate” altyapısını kullanarak ticari ölçme araçları, ısmarlama yazılım uygulamaları ve veri tabanları SPC-AAT’ye tümlenebilir. Metrik verileri SPC-AAT’ye aktarıldığı zaman, bütün gerekli varlıklar İSK değerlendirme ve analizi başlamadan araç tarafından otomatik yaratılır. SPC-AAT, içeri aktarımı yapılan metrikleri kullanarak yeni metrikler türetmeye izin verir ve türetilmiş metriklerin değerlerini araca girilmiş formüllerine göre otomatik olarak hesaplar. Veri sıralaması kontrol grafiklerini çizerken önemli olduğundan, SPC-AAT sayı ve tarih tipindeki metrikler için verilerin sıralanmasını sağlar.




    Şekil 1 SPC-AAT Çalışma Ortamı

    Şekil 2 Süreç Benzerlik Matrisi

    SPC-AAT; kontrol grafikleri, histogramlar, bar grafikleri ve pareto grafikleri gibi İSK tekniklerini destekler. Bu İSK teknikleri “süreç kümesi - metrik” çiftlerine uygulanır. Kontrol grafiklerinde kontrol-dışı noktaları tespit etmek için tanımlı testler [26] kullanılır ve uygulanılacak testleri seçmek mümkündür. Uygulanan testlere göre kontrol-dışı nokta olarak tespit edilen bir metrik değeri, aracımız ile analizden çıkartılabilir. Bir kontrol-dışı noktayı analizden çıkarmak ve noktanın ilgili olduğu süreç yürütme anketine ulaşmak için, kontrol grafiğindeki nokta üzerine tıklamak yeterlidir. Bunların dışında SPC-AAT, farklı mantıksal kümeleme seçenekleri üzerinde analizler yapmayı var olan süreç kümelerini birleştirerek yada ayırarak destekler. İSK değerlendirme ve analiz sonuçları aracımız kullanılarak raporlanabilir ve yazdırılabilir (bkz. Şekil 3 ve Şekil 6).

    3.SPC-AAT İle Yapılan Örnek Bir Değerlendirme Ve Analiz


    SPC-AAT bir yazılım firmasının hata düzeltme süreci üzerinde kullanıldı ve bu deneyim İSK değerlendirme ve analiz örneği olarak bu bölümde sunulmaktadır. Süreç değerlendirmesi yapılan şirket, iletişim teknolojileri alanında 8 yıllık bir deneyime sahiptir ve sistem mühendisleri, yazılım mühendisleri, proje yöneticileri, kalite uzmanlarından oluşan 85 kişilik bir geliştirme ekibi içermektedir. Hali hazırda ISO 9001 [14], AQAP-150 [19], ve CMMI L3 onay belgeleri bulunmaktadır. Yapılan çalışmada, bileşen tümleştirme ve sistem sınamaları sırasında bildirilen hatalar göz önüne alınmıştır. Birim sınamaları sırasında bulunan hatalar çalışma kapsamının dışında tutulmuştur. Şirkette hata düzeltme süreci, bir değişiklik yönetim aracı üzerinden yürütülmektedir. Çalışma için seçilen yazılım modülünün hata düzeltmeleri, Mayıs 2006’da başlamış ve Kasım 2006’ya kadar sürmüştür. Bu 6 aylık dönem süresince seçilen modül için bildirilen bütün hatalar incelenmiştir. İncelemenin yapıldığı şirket, belirli bir ölçme sürecine ve sistematiğine sahip değildir fakat veri incelemek için bazı politikaları vardır ve sonuçlar üst yönetime raporlanmaktadır. Üst yönetime raporlanan sonuçlar, sistematik olarak karar verme amaçlı kullanılmamaktadır.

    Şirketteki analiz, incelemenin yapıldığı proje geliştirme sorumlusuyla beraber gerçekleştirildi. Verinin toplanması, yaklaşımın uygulanması, analizin gerçekleştirilmesi ve sonuçların yorumlanması için toplam 5 saat harcandı. Bu incelemede, 6 aylık süre boyunca raporlanmış 62 hatadan oluşan hata düzeltme süreç verisi üzerinde çalışıldı.


    3.1.Yazılım Firmasındaki Örnek Değerlendirme


    Çalışma geçmişte toplanan veriler üzerinde gerçekleştirildi. Süreç öznitelik değerlerini süreç benzerlik matrisinde tanımlamak için, süreç yürütme tutanaklarını doldurarak tanımlamak yerine, genel süreç akış şemasını yazılım modülü sorumlusu ile çizmek tercih edildi. Bu şemaya göre, 4 adet hata düzeltme süreç uygulaması örneklendi ve SPC-AAT ile her biri için bir süreç yürütme tutanağı dolduruldu. Süreç yürütme tutanakları üzerindeki bilgiler, tipik süreç özniteliklerinin çıkarılmasını sağladı ve benzerlik matrisinin yaratılması için temel oluşturdu. Daha sonra, süreç özniteliklerinin örneklenen değerleri, 62 süreç yürütmesinin özniteliklerini doğrulamak için kullanıldı. Doğrulama sırasında keşfedilen her bir yeni süreç öznitelik değeri matris üzerine eklendi. İlk 21 süreç yürütmesi için benzerlik matrisi (sadece “etkinlikler” süreç öznitelik değerleri için), Şekil 2’de gösterilmiştir.

    Benzerlik matrisi tamamlandıktan sonra, süreç yürütmeleri arasındaki benzerlik ve farklılıklar, süreç özniteliklerinin değerleri bakımından incelendi. Bunun için aracın Süreç Kümeleri sekmesi açıldı. Burada süreç özniteliklerinin değerlerine göre 2 adet taban süreç kümesi oluştuğu gözlendi ve Şekil 3’te göründüğü üzere “Versiyon A” ve “Versiyon B” olarak adlandırıldı. Tespit edilen her süreç kümesi, hata düzeltme sürecinin farklı bir uygulaması demekti ve o kümeye ait süreç yürütmelerinin verisi, süreç öznitelik değerlerine göre yaklaşık olarak aynı kaynaktan gelmekteydi. Buna göre, her süreç kümesine ait uygulamaların kontrol altında olup olmadığını görmek için, süreç metriklerine göre kontrol grafikleri çizilebilirdi. Süreç kümelerindeki süreç yürütmelerinin sayılarına bakıldığında, hem “Versiyon A” (33) hem “Versiyon B” (29) için yeter sayıda süreç yürütmesi olduğu görüldü (istatistiksel inceleme için en az 20 olmalı).


    Şekil 3 Taban süreç kümeleri için üretilen rapor

    Taban süreç kümeleri belirlendikten sonra, süreç metriklerinin kullanılabilirliklerinin değerlendirilmesi amacıyla aracın Metrik Değerlendirme sayfası açıldı. İncelemenin başında araca aktarılan metrikler, Tablo 1’de taban metrik olarak verilmiştir. Bu taban metrikleri kullanarak 4 yeni metrik türetilmesine karar verildi: Hata Eskime Süresi (Bug Aging), Kestirilen Hata Eskime Süresi (Estimated Bug Aging), Kestirim Sapması (Estimation Variance) ve Kestirme Yeteneği (Estimation Capability) (bkz. Tablo 1).

    Türetilmiş Metrikler (“Derived Metrics”) sekmesi altında her bir türetilmiş metrik için bir kayıt yaratıldı. Bu sekmede Metrik Formülü (“Metric Formula”) alanı yaratılan metrikler için doldurulduğunda, yeni türetilmiş metrikler için metrik verileri özdevimli hesaplandı ve araç tarafından kaydedildi.

    Tablo 1 İncelenen süreç metrikleri

    Metrik Adı

    Metrik Tipi

    Açıklama

    Hata Bildirim Tarihi (Creation Date)

    Taban

    Hatanın raporlandığı tarih

    Hata Çözüm Tarihi (Actual Finish Date)

    Taban

    Hatanın çözüldüğü tarih

    Kestirilen Hata Çözüm Tarihi (Estimated Finish Date)

    Taban

    Hatanın çözülmesinin planlandığı tarih

    Hata Eskime Süresi (Bug Aging)

    Türetilmiş

    Hata Çözüm Tarihi - Hata Bildirim Tarihi + 1

    Kestirilen Hata Eskime Süresi (Estimated Bug Aging)

    Türetilmiş

    Kestirilen Hata Çözüm Tarihi - Bildirim Tarihi + 1

    Kestirim Sapması (Estimation Variance)

    Türetilmiş

    Kestirilen Hata Eskime Süresi - Hata Eskime Süresi

    Kestirme Yeteneği (Estimation Capability)

    Türetilmiş

    Kestirilen Hata Eskime Süresi / Hata Eskime Süresi

    Öncelik Derecesi (Priority)

    Taban

    Raporlanan hatanın önem derecesi. Olası değerler: 1 (etkisi büyük), 2 (ciddi), 3 (etkisi az), 4 (önemsiz)

    Hata Kaynağı (Problem Source)

    Taban

    Raporlanan hatanın kaynağı

    Test Sonucu (Status, Test Result)

    Taban

    Hatanın düzeltilmesinden sonra yapılan testin sonucu. Olası değerler: T* (başarılı), T- (başarısız), T0 (test yapılmadı)


    Şekil 4 Hata Eskime Süresi metriğinin Metrik Kullanılabilirlik Anketi

    Türetilmiş metriklere karar verildikten sonra, metrik kullanılabilirlik anketleri, her taban ve türetilmiş metrik için Metrik Değerlendirmesi (“Metric Evaluation”) sayfasındaki Anket (“Questionnaire”) sekmesinden dolduruldu. Hata Eskime Süresi türetilmiş metriği için örnek bir anket (sadece Veri Mevcudiyeti metrik kullanım özniteliği için) Şekil 4’te gösterilmiştir. Metrik kullanılabilirlik değerleri Şekil 5’te gösterilmiştir. Anketlere verilen cevaplar değerlendirilerek bulunan bütün taban ve türetilmiş metriklerin kullanılabilirlik değerleri Şekil 6’da listelenmiştir. İncelemenin bundan sonraki adımlarında, sadece kullanılabilir (“Usable”) olarak değerlendirilmiş metrikler için istatistiksel analiz yapıldı. Kestirilen Hata Çözüm Tarihi, Kestirilen Hata Eskime Süresi, Kestirim Sapması ve Kestirme Yeteneği metrikleri eksik veri noktaları nedeniyle Kullanılamaz (“Not Usable”) olarak değerlendirildiğinden, bunlar için istatistiksel analiz yapılmadı.

    Şekil 5 Hata Eskime Süresi metriğinin kullanılabilirlik değerleri


    Şekil 6 Bütün metriklerin kullanılabilirlik değerlerini gösteren rapor


    3.2.Yazılım Firmasındaki Örnek Analiz


    Taban süreç kümeleri belirlendikten ve metriklerin kullanılabilirlikleri değerlendirildikten sonra, süreç kümelerini son haline getirmek için aracın Süreç İyileştirme (“Process Improvement”) görünümü altındaki Süreç Kümeleri (“Process Clusters”) sayfası açıldı. Veri noktalarının sayılarının her iki taban süreç kümesi için yeterli olduğu görüldü. Bu yüzden, taban süreç kümeleri “Versiyon A” ve “Versiyon B” üzerinde ayrı ayrı istatistiksel analiz yapmaya karar verildi. Ayrıca, büyük resmi görebilmek ve sonuçları karşılaştırabilmek için, iki taban süreç kümesinin birleştirilmesi ile oluşturulacak süreç kümesi üzerinde de İSK tekniklerinin uygulanması faydalı görüldü.

    İSK teknikleri sadece değerlendirme sonucunda uygun tespit edilen “süreç kümesi – metrik” çiftlerine uygulandı. Bu incelemede, kontrol grafikleri için uygun çiftler “Versiyon B – Hata Eskime Süresi” ve “Versiyon A – Hata Eskime Süresi” idi; çünkü sadece Hata Eskime Süresi metriği inceleme sonucunda kullanılabilir olarak değerlendirilmişti. “Versiyon B – Hata Eskime Süresi” çifti için çizilen kontrol grafiğine bakıldığında (bkz. Şekil 7), sürecin hali hazırda kontrol altında olduğu gözlemlendi. Ortalama yaklaşık 1.5 gün ve Üst Kontrol Sınırı yaklaşık 3.1 gün olarak tespit edildi. Kontrol grafiği sonuçlarına göre süreç hem kontrol altındaydı hem de sürecin ortalama ve ÜKS değerleri şirketin hizmet anlaşması ile tutarlılık göstermekteydi. Bu nedenlerle sürecin yeterli (yetkin) olduğu kanaatine varıldı.


    Şekil 7 “Versiyon B–Hata Eskime Süresi”çifti için çizilen kontrol grafiği

    “Versiyon A – Hata Eskime Süresi” çifti için çizilen kontrol grafiğine bakıldığında (bkz. Şekil 8), iki kontrol-dışı nokta (KDN) gözlemlendi. 28 numaralı süreç yürütmesi için tespit edilen KDN incelendiğinde, proje yöneticisinin yazılım geliştiricisini bu görevden alıp daha önemli gördüğü başka görevlere atamış olduğu bulundu. Bu olağan dışı bir süreç yürütmesi olarak değerlendirildi ve ilgili metrik veri noktasının analizden çıkarılmasına karar verildi. Veri noktası çıkarıldıktan sonra, kontrol grafiği araç tarafından yeniden özdevimli çizildi.

    Bu sefer, 3 kontrol-dışı nokta tespit (KDN) edildi (Şekil 9). 22 numaralı süreç yürütmesi için tespit edilen KDN için Süreç Yürütme Anketi doldurulduğunda, bu hatanın geliştirme ortamında yeniden yaratılmasında bir problem yaşandığı ve bu hatanın 3 hafta boyunca unutulduğu bulundu. Bu proje için olası bir iyileştirme noktası olarak raporlandı. Çözüm olarak, yeniden yaratılamayan hataların haftalık proje toplantılarında detaylı bir şekilde tartışılması ve belirli bir zamandan daha eski hatalar için son kararın verilmesi düşünüldü. Bu metrik veri noktası da, kontrol grafiğinin yeniden çizilmesi için analizden çıkarıldı.


    Şekil 8 “Versiyon A-Hata Eskime Süresi”çifti için çizilen kontrol grafiği



    Şekil 9 “Versiyon A-Hata Eskime Süresi”çifti için çizilen kontrol grafiği - 2

    Yeni garfikte 2 adet KDN tespit edildi. 15 numaralı süreç yürütmesi için tespit edilen KDN için Süreç Yürütme Anketi doldurulmasına rağmen, kontrol dışı nokta oluşturacak belirli bir neden tespit edilemedi. Bu durumda, ilgili metrik veri noktasının analizden çıkarılmasına karar verildi ve kontrol grafiği bir daha çizildi. Bu sefer, sadece bir KDN tespit edildi (süreç yürütme No 21). Hata Eskime Süresi metrik değeri bu süreç yürütmesi için 7 gündü ve bu değer önem derecesi 4 olan bir hata için uzun bir süre değildi. Bu yüzden, bu tip noktaların analizde KDN olarak değerlendirilmemesine karar verildi ve testlerin konfigürasyonu bunu sağlayacak şekilde değiştirildi (bkz. Şekil 10). Şekilden de anlaşıldığı üzere, sadece 1. testin uygulanmasına karar verilerek testler gevşetildi.

    Şekil 10 Wheeler’ın testlerinden seçilenler



    Şekil 11 “Versiyon A-Hata Eskime Süresi” çifti için kontrol grafiği - Son

    KDN testleri için konfigürasyon değiştirildikten sonra, kontrol grafiği yeniden çizildi (bkz. Şekil 11) ve sürecin kontrol altında olduğu gözlemlendi. Ortalama 2.5 gün ve ÜKS (Üst Kontrol Sınırı) ise yaklaşık 8 gün olarak tespit edildi. Kontrol grafiği sonuçlarına göre sürecin hem kontrol altında olduğu hem de ortalama ve ÜKS değerlerinin şirketin hizmet anlaşması ile tutarlılık gösterdiği bulundu. Bu nedenlerle sürecin yeterli (yetkin) olduğu kanaatine varıldı.

    İkinci adım olarak, iki taban süreç kümesi birleştirildi ve yeni oluşturulan süreç kümesi (“Versiyon A_B”) için İSK’nın kontrol grafiği tekniği uygulandı (bkz. Şekil 12). “Versiyon A_B” süreç kümesi için çizilen kontrol grafiği incelendiğinde, kontrol grafiğinde 6 kontrol-dışı nokta (KDN) olduğu gözlemlendi. Bu noktalar; süreç yürütmeleri 3, 16, 17, 21, 32 ve 34 içindi. Aynı zamanda önceden analizden çıkarılan 3 nokta da KDN olarak bu 6 nokta yanında yer almaktaydı. Bu gözlemlerden, hata düzeltme sürecinin “Versiyon A_B – Hata Eskime Süresi” çfti için kontrol altında olmadığı anlaşıldı. Birçok KDN gözlemlenmesinin, süreç içindeki birden fazla kaynağa işaret ettiği düşünüldü. “Versiyon A_B” istatistiksel analiz için uygun olmadığından, süreç kümeleme değerlendirmesinin önerdiği gibi “Versiyon A” ve “Versiyon B” süreç kümelerinin ayrı ayrı analiz edilmesinin doğru olduğu sonucuna varıldı.


    Şekil 12 “Versiyon A_B-Bug Aging”çifti için kontrol grafiği

    Kontrol grafikleri ile yapılan analizlerin bir özeti Tablo 2’de verilmiştir.
    Geliştirilen araç kullanılarak, metrik verileri için histogramlar da çizilebilmektedir fakat sayfa kısıtından dolayı burada örneklenmemiştir.


    Tablo 2 Değerlendirme ve analiz sonuçları


    Metrik

    Süreç Kümesi

    KDN

    Tespit Edilen Nedenler

    Hata Eskime Süresi

    Versiyon A_B

    Birçok KDN

    Birden fazla kaynağın (“multiple cause system”) karışımı

    Versiyon A

    3 KDN

    KDN’lerden biri, yazılım geliştiricinin Proje Yöneticisi tarafından daha önemli işlere atanmasından oluşmuştu. Bir diğerinin sebebi, yeniden yaratılamayan bir hatanın 3 hafta açık unutulmasıydı. En son KDN için, belli bir neden bulunamadı.

    Versiyon B

    -

    -


    3.3.Çubuk ve Pareto Grafik Analizleri


    SPC-AAT oransal (“ratio”) ve mutlak (“absolute”) metrik tiplerinin yanında sınıflı (“nominal”) ve sıralı (“ordinal”) metrik tiplerinin analizini de destekler. Bu örnek incelemede, Şekil 13’te gösterildiği gibi hataların “Test Sonucu” için çubuk (“bar”) grafikleri çizildi. Projede uygulanan sürece göre, bir hata çözüldüğü zaman, hatanın durumu “RES” olmaktaydı. Daha sonra hatanın gerçekten çözülüp çözülmediğini kontrol etmek için sınama yapılmakta ve eğer çözüldüğü gözlemlenirse hatanın durumu “FIN” yapılmaktaydı. Çubuk grafiği aradan uzun zaman geçmesine rağmen bazı hataların hala “RES” durumunda (grafikteki yeşil çubuk) olduğunu gösterdi. Yani, bazı hatalar çözülmesine rağmen sınamaları yapılmamıştı. Bu hem süreç hem proje için iyileştirmeye açık bir alan olarak tespit edildi.

    Şekil 13 “Versiyon A_B- Test Sonucu” çifti için bar grafiği

    İncelemede ayrıca hataların “Hata Kaynağı” (Problem Source), “Hata Sebebi” (Error Reason) ve “Hatanın Yakalanması Gereken Yer” (should-be found) metrikleri için pareto grafikleri çizildi. “Hatanın Yakalanması Gereken Yer” metriği için çizilen pareto grafiği incelendiğinde (bkz. Şekil 14), yaklaşık hataların yarısının normalde bileşen tümleştirme sınamaları (CIT) sırasında tespit edilmiş olması gerektiği görüldü. Bu gözlem, CIT sürecindeki olası problemleri işaret etmekteydi ve problemlerin tespiti için bir inceleme başlatıldı. Yazılım geliştirme sürecindeki diğer problemli alan Gereksinim Yoklaması (“Requirements Inspection”) olarak tespit edildi. Pareto grafiğine göre, hataların %85’i Gereksinim Yoklaması ve CIT sırasında tespit edilebilirdi fakat gözden kaçmışlardı. Elde edilen sonuçlar doğrultusunda, Gereksinim Yoklamasındaki sorunların tespit edilmesi için bir inceleme daha başlatıldı.

    Şekil 14 “Versiyon A_B-Hatanın Yakalanması Gereken Yer” çifti için pareto grafiği

    “Hata Sebebi” metriği için çizilen pareto grafiği incelendiğinde, bir önceki pareto grafiğindekine benzer sonuçlar elde edildi. Hataların %75’i için hata sebebi “Test’te Yakalanmalıydı” (Test: Not Escaped) ya da “Kötü Gereksinim Yoklaması“ (Specification: Bad Review) olarak tespit edildi. Bu sonuçlar, “Hatanın Yakalanması Gereken Yer”” metriği için çizilen pareto grafiği ve grafiğin analizi sonucu alınan kararlarla tutarlılık göstermekteydi.

    3.4.Analiz Özeti ve Kazanımlar


    Örnek inceleme sonucunda, projenin hata düzeltme sürecinin kontrol sınırları ve ortalama hata çözme süreleri öğrenildi. Elde edilen bu bilgiler, özellikle proje planlama ve izleme için çok büyük önem taşımaktaydı. Süreç metriklerinin ortalama değerler ve kontrol sınırları her bir süreç kümesi için Tablo 3’te verilmiştir. Bu değerler hata düzeltme sürecinin yetkinliği hakkında fikir vermektedir. Bu sonuçlara göre, hata düzeltme sürecinin yetkin olduğu kanaatine varıldı çünkü elde edilen değerler şirketin müşterileri ile yapmış olduğu hizmet sözleşmesinde belirtilen sınır değerler içindeydi.

    Tablo 3 Hata düzeltme süreci için yetkinlik sonuçları


    Metrik

    Süreç Kümesi

    Ortalama

    ÜKS

    Hata Eskime Süresi

    Versiyon A_B

    2.0

    -

    Versiyon A

    2.467

    7.969

    Versiyon B

    1.517

    3.132

    Örnek inceleme sırasında, incelenen proje ve projede kullanılan yazılım geliştirme süreçleri için tespit edilen olası iyileştirme noktaları şunlardır:

    - Bir hafta içinde yeniden üretilemeyen hatalar haftalık proje toplantılarında değerlendirilecek ve son karar verilecektir. Geçmişte, bu durum göz ardı ediliyordu.

    - Çözülen hataların sınamaları konusunda problemler tespit edildi. Projede çözülmüş fakat sınaması yapılmamış bazı hatalar vardı. Her çözülen hata için, değişiklik yönetimi aracı ile sınamadan sorumlu bir kişi atanmasına ve hata sınamalarının takip edilmesine karar verildi. Süreç tanımında bununla ilgili gerekli değişiklik yapıldı.

    - Hataların %85’inin, normalde Gereksinim Yoklamasında ve CIT sırasında tespit edilmiş olması gerektiğini gözlemledik. Bunun sonucunda, yazılım geliştirme sürecinin bu iki alt süreci için süreç iyileştirme çalışmaları başlatıldı.

    4.Sonuçlar


    İSK (İstatistiksel Süreç Kontrolü) tekniklerinin, özellikle yazılım sektöründeki gelişmekte olan organizasyonlar tarafından etkin olarak kullanılabilmesini sağlamak ve kullanımını yaymak için, İSK tekniklerini gerçekleyen yönerge ve yazılım araçlarına ihtiyaç vardır. Çalışmamızda, bu ihtiyaçlara cevap verecek bir yazılım aracı (SPC-AAT) örnek bir inceleme üzerinde anlatılmıştır. Bu çalışma göstermiştir ki; kullanıcılara verinin mantıksal kümelenmesi ve metrik kullanılabilirliği için rehberlik eden bir araç ile bir organizasyon, İSK tekniklerini uygulayabilir ve süreçlerini nicel veriler ışığında anlama ve takip etme becerisi kazanabilir.

    Geliştirilen araç, yazılm süreç ve metriklerinin İSK için uygunluğunun değerlendirilmesine ve İSK tekniklerinin eldeki süreç verisi ile birlikte kullanmasına olanak sağlamıştır. SPC-AAT, İSK’nın uygulanmasını kolaylaştırmış, geliştirmiş ve çeşitli İSK tekniklerinin kullanılması için gereken süreyi azaltmıştır. SPC-AAT bu sonucu aşağıdaki özellikleriyle desteklemiştir:

    - Diğer araçlardan metrik verilerinin aktarılmasını kolaylaştırmak

    - Metrik verisinin istatistiksel analiz için düzenlenmesini kolaylaştırmak

    - Kullanıcılara metrik tanımlama ve İSK analizi için uygun metriklerin seçilmesi konularında rehberlik etmek

    - Kullanıcılara doğru İSK tekniklerinin seçilmesi için rehberlik etmek

    - Verinin mantıksal kümelenmesi konusunda kullanıcılara yol göstermek ve mantiksal kümelemeyi kolaylaştırmak

    - Yeni metrikler türetmeyi ve türetilmiş metriklerin tanımlanmasını kolaylaştırmak

    - İstatistiksel grafiklerin yorumlanmasını kolaylaştırmak

    - Farklı mantıksal kümeleme seçenekleri üzerinde analizler yapmayı kolaylaştırmak ve geliştirmek

    - İSK ile ilgili bütün işlerin yapılabilmesi için tek bir merkezi yer sağlamak
    SPC-AAT, şimdiye kadar sadece bir organizasyonda ve sınırlı sayıda kişi tarafından kullanılmıştır. Bunlar, örnek incelemeden elde edilen sonuçları genellemek için yeterli değildir. Farklı şirketlerin farklı süreçleri üzerinde çalışmalar devam etmektedir. Bunun daha fazla geri bildirim almak ve aracı geliştirmek için çok faydalı olacağını düşünüyoruz. Buna ek olarak, SPC-AAT için yardım dokümantasyonuna, kullanıcı elkitabına ve aracın türkçeleştirmesine yönelik çalışmalar sürmektedir.

    Araçla ilgili öngörülen araştırma çalışmaları şu şekilde sıralanabilir: Süreçlerin görsel olarak tanımlanmasını sağlamak ve süreç özniteliklerini bu görsel tanımlamadan özdevimli çıkarmak, metriklerin iş hedeflerine göre seçilmesini sağlamak için Hedef-Soru-Metrik (Goal-Question-Metric (GQM)) yaklaşımını araca tümlemek, süreç yetkinlik değerlendirme özelliği eklemek. Bunların yanında aracın kullanımı ile ilgili bir süreç akış şeması sağlamak, SPC-AAT’nin kullanımını kolaylaştırmak adına fayda sağlayacaktır.


    5.Kaynakça


    1. Barnard, J., ve Carleton, A., “Analyzing a Mature Software Inspection Process Using Statistical Process Control”, National SEPG Conference, Pittsburgh, 1999.

    2. Burr, A., Owen, M., Statistical Methods for Software Quality. Thomson Publishing Company, 1996. ISBN 1-85032-171-X.

    3. Card, D., “Statistical Process Control for Software?”, IEEE Software, May 1994, sn.95-97.

    4. Carleton, A.D., ve Paulk, M.C., “Can Statistical Process Control Be Usefully Applied To Software?”, 4th European Software Engineering Process Group (ESEPG) Conference, Amsterdam, June 1999

    5. CMU/SEI, CMMI Product Team, “CMMISM for Systems Engineering and Software Engineering”, CMMI-SE/SW V1.1 Continuous, CMU/SEI-2002-TR-001, December 2001(b).

    6. Demirörs, O., ve Sargut, K.U., “Utilization of a Defect Density Metric for SPC Analysis”, 13th International Conference on Software Quality, Dallas, Texas, October 2003.

    7. Demirörs, O., ve Sargut, K.U., “Utilization of Statistical Process Control (SPC) in Emergent Software Organizations: Pitfalls and Suggestions”. Software Quality Journal, Vol.14, No.2, sn.135-157, 2006.

    8. Fenton, N.E., ve Pfleeger, S.L., Software Metrics: A Rigorous and Practical Approach, 2nd Ed., PWS Publishing Company, 1997.

    9. Florac, A.W., Carleton A.D., Measuring the Software Process: Statistical Process Control for Software Process Improvement. Pearson Education, 1999. ISBN 0-201-60444-2.

    10. Florac, A.W., Carleton A.D., Statistically Controlling the Software Process (The 99 SEI Software Engineering Symposium), Software Engineering Institute, Carnegie Mellon University, September 1999.

    11. Florac, A.W., Carleton A.D., Statistical Process Control: Analyzing a Space Shuttle Onboard Software Process. IEEE Software, July/August 2000, SN 97-106.

    12. Florac A.W., Park E.R., Carleton A.D., Practical Software Measurement: Measuring for Process Management and Improvement (CMU/SEI-97-HB-003). Software Engineering Institute, Carnegie Mellon University, April 1997.

    13. Florence, A., “Statistical Process Control Applied to Software Requirements Specification Process”, 10th European Software Engineering Process Group (ESEPG) Conference, London, June 2005.

    14. ISO, “ISO 9001: Quality Management Systems – Requirements”, 2000.

    15. ISO/IEC, “ISO/IEC TR 15504: Information Tech. – Software Process Assessment”, 1998.

    16. Jacob, L., ve Pillai, S.K., “Statistical Process Control to Improve Coding and Code Review”, IEEE Software, May/June 2003, sn.50-55.

    17. Jalote, P., Dinesh, K., Raghavan, S., Bhashyam, M.R., ve Ramakrishnan, M., “Quantitative Quality Management through Defect Prediction and Statistical Process Control”, Proceedings of Second World Quality Congress for Software, September 2000.

    18. Lantzy, M.A., “Application of Statistical Process Control to Software Processes”, WADAS '92, Proceedings of the Ninth Washington Ada Symposium on Empowering Software Users and Developers, 1992, sn.113-123.

    19. NATO, “AQAP-150: NATO Quality Assurance Requirements for Software Development (Edition 2)”, September 1997.

    20. Paulk, M.C., “Practices for High Maturity Organizations”, Proceedings of the 1999 Software Engineering Process Group Conference, Atlanta, Georgia, March 1999, sn.28-31.

    21. Radice, R., “Statistical Process Control for Software Projects”, 10th Software Engineering Process Group Conference, Chicago, Illinois, March 1998.

    22. Sengul, E.S., Intermediate: An Integration Tool for Measurement Data Collection, Master Thesis Dissertation, Informatics Institute of METU, November 2001.

    23. Tarhan, A., ve Demirörs, O., “Investigating Suitability of Software Process and Metrics for Statistical Process Control”, EuroSPI Conference, sn. 87-98, LNCS 4257, Springer-Verlag, 2006.

    24. Tarhan A., ve Demirors, O., “Remarks from SPC Trial for an Emergent Organization”, Presentation, Europen SEPG Conference, 12-15 June 2006, Amsterdam, Holland.

    25. Weller, E., Practical Applications of Statistical Process Control. IEEE Software, May/June 2000, sn.48-55.

    26. Wheeler, D.J., Advanced Topics in Statistical Process Control, SPC Press, Knoxville, 1995.






        Ana sayfa


    İstatistiksel Süreç Kontrolünün Yazılım Süreçlerine Uygulanabilirliğini Değerlendirme ve Analiz Aracı

    Indir 88.81 Kb.