Yazılım Geliştirme Sürecinde Kullanılan Ölçütler Dr. Tolga Ovatman İstanbul Teknik Üniversitesi Bilgisayar ve Bilişim Fakültesi 34469 Maslak ovatman@itu.edu.tr 08 Ağustos 2012 1
İçerik Giriş Yazılım Geliştirme Süreci Ölçme Teorisi Nesneye Dayalı Ölçütler FPA ve varyantları Süreç Ölçütleri Sonuç 2
Yazılım Geliştirme Süreci Yazılım geliştirmek, mühendislik disiplinleri içinde en fazla bireysel etkinlik içeren disiplinlerden biri. Disiplin geliştiği zamanlarda donanım kapasitesinin sınırlı olması nedeniyle daha küçük çaplı ve basit sistemler geliştiriliyordu. Yazılım projeleri yönetimi artık çok daha fazla paydaşın rol oynadığı çok boyutlu problemler haline geldi.
Yazılım Geliştirme Süreci 2000li yıllarda yazılım endüstrisinin durumu hakkında birçok araştırma yapıldı. The OASIG Study (1995) : Her 10 projeden 7si bir yönden başarısız bulunuyor The Chaos Report (1995): Projelerin %31.1'i tamamlanmadan iptal ediliyor. %52.7'si tahmin edilenin 2 katına maloluyor. The KPMG Canada Survey (1997): İncelenen projelerin %61'i başarısızlıkla sonuçlandı. The Conference Board Survey (2001): Projelerin %40 tamamlandıktan bir yıl sonra işlevini yitiriyor.
Yazılım Geliştirme Süreci Yazılım geliştirme projeleri aşağıdaki süreçleri içerir Planlama (Analiz-Tasarım) Geliştirme (Kodlama-Test) Montaj ve bakım
Yazılım Geliştirme Süreci Model: A praiseworthy example to be copied, with or without modifications. Yazılım yaşam döngüsü modelleri, geçmişten günümüze üç farklı bakış açısından oluşturulmuştur. Programlama bakış açısı: Yazılım geliştirme, fikirlerin doğrudan bir yansımasını üretmektir. Ardışıl işlem bakış açısı: Yazılım geliştirme, problem çözümlemeden çalışabilen koda uzanan bir dönüşüm sürecidir. Keşif çalışması bakış açısı: Yazılım geliştirme, problem uzayını keşfetme çabasıdır.
Yazılım Geliştirme Süreci
Ölçmenin Önemi Aşağıdaki üç soruya nasıl cevap verebiliriz? - Proje ne durumda? - Projede kötü giden şey nedir? - Proje ne zamana biter?
Ölçme Teorisi Ölçme: Fiziksel özelliklerle formal bir ölçü birimini eşleştirme işlemi. Ölçme işlemi için iki kavramı belirlemek gerek: - Ölçü (measure) - Ölçek (scale) Örneğin: Aşağıdaki iki yazılımdan hangisi daha karmaşık? - Her biri orta çok arası karmaşıklığa sahip 10 modüllü yazılım - Her biri az çok arası karmaşıklığa sahip 20 modüllü yazılım
Ölçme Teorisi 4 çeşit ölçek tipi belirlenebilir: - Nominal ölçek: Aralarında karşılaştırma yapılamayacak şekilde kaynak kümeyi parçalayan ölçekler. Forma numaraları. - Ordinal ölçek: Aralarında karşılaştırma yapılabilecek şekilde kaynak kümeyi parçalayan ölçekler: Harfli not. - Aralık ölçek: Oranlı karşılaştırmalar yapılabilecek şekilde kaynak kümeyi parçalayan ölçekler: Sıcaklık için Celsius ölçeği - Oran ölçek: Mutlak sıfır değerine sahip aralık ölçekler: Kelvin ölçeği, uzunluk, kütle ölçekleri.
Ölçme Teorisi Yapılan ölçümlerin kalitesi iki kavram ile belirlenir: - Güvenilirlik (Reliability) - Geçerlilik (Validity)
Nesneye Dayalı Ölçütler Yazılım analizinde kullanılan birçok ölçüt var, bunlardan en bilinenleri: - KLOC varyantları ve kusur oranı. - Karmaşıklık ölçütleri ve çevrel karmaşıklık varyantları
Nesneye Dayalı Ölçütler Nesneye dayalı yazılımlar için özel olarak tanımlanmış ölçüt kümeleri de mevcut. Örneğin Lorenz ölçüt kümesinde tanımlanan ölçütler ve değerleri hakkında yourmlar: - Ortalama metot boyu (LOC) : Smalltalk için <8, C++ için <24 - Sınıf başına düşen ortalama metot: 20'den az olmalı - Sınıf başına düşen ortalama değişken: 6'dan az olmalı - Sınıf hiyerarşisi derinliği : 6'dan az olmalı - Modül-modül ilişki miktarı: 6'dan az olmalı - Sınıf-sınıf ilişki miktarı: Görece yüksek olmalı - Sınıf değişkeni kullanımı: Metodların gruplaşmasına dikkat - Metot başına yorum satırı: 1'den büyük olmalı - Silinen sınıf-metot sayısı: Sabit biçimde ilerlemeli
Nesneye Dayalı Ölçütler Günümüzde en yaygın olarak kullanılan küme Chidamber ve Kemerer tarafından önerilmiştir: - WMC(Weighted Methods per Class) : Çevrel karmaşıklığa göre ağırlıklandırma yapılır - DIT(Depth of Inheritance Tree) - NOC(Number of Children of a Class) - CBO(Coupling Between Object Classes): Sınıfın metot/değişkenini kullandığı farklı sınıf sayısı. - RFC(Response for a Class) : Bir mesaja karşılık sınıf içinde çalışabilecek ortalama metod sayısı - LCOM(Lack of Cohesion on Methods): Sınıftaki ayrık metot sayısı
Nesneye Dayalı Ölçütler Chidamber ve Kemerer ölçüt kümesi üzerinde birçok çalışma yapıldı, bunlarda en ilginçlerinden biri de Rosenerg, Stapko ve Gallo tarafından yapıldı. Sorunlu bir sınıf aşağıdaki kriterlerden en az ikisine sahiptir: - RFC > 100 - RFC > 5 * sınıftaki metot sayısı - CBO > 5 - WMC > 100 - Metot sayısı > 40
Nesneye Dayalı Ölçütler Başarılı bir projeye ait zaman içinde ölçülen ölçüt değerleri
Nesneye Dayalı Ölçütler Başarılı bir projeye ait zaman içinde ölçülen ölçüt değerleri
FPA ve varyantları Yazılım geliştirme sürecinde efor kestirimi konusunda yaygın kullanılan bir ölçüt modeli FPA(Function Point Analysis). Daha sonraları bu yaklaşım Lother tarafından daha üreysel halde ele alındı. Sözü edilen Noktalar yaklaşımı na uyan bir kısım FPA varyantı: IFPUG FPA: Sistem bileşenlerini 5 ana gruba ayırarak her birinin karmaşıklığına göre ağırlıklandırmak üzere kurulu. UFP = a x input + b x output + c x requires + d x files + e x interfaces Daha sonra UFP, yazılımın 14 farklı sistem karakteristiği ile ne derece ölçüştüğünü gösteren bir başka katsayı ile çarpılarak kullanılır.
FPA ve varyantları Object Points: Nesneye dayalı sistemler için özelleştirilmiş bir FP türüdür. - Sınıf diyagramında: Sınıflar 4, kalıtılmamış özellikler 1, kalıtılmamış metodlar 3, sınıf ilişkileri 2 - Ardışıl iletişim diyagramlarında: İletiler 2, parametreler 1, yollayanlar 2, alıcılar 2 - Use case diyagramlarında: Aktörler 2, Use caseler 10, use case-aktör etkileşimi 1 sayılarak FPA gerçekleştirerek uygulanır.
FPA ve varyantları Gömülü sistemler/gerçek zaman sistemleri için FP: Mark II, Feature points, 3-D FP gibi bir takım varyantların değerlendirme kriterleri ve ağırlıkları üzerinde değişiklikler gerçekleştirmesiyle FP özelleştirilmiştir. COSMIC FFP: FPA için ortaya çıkan varyantları birleştirecek bir FP süreci tanımlamak için oluşturulmuştur. - Ağırlıklar ve işlev tipleri ortadan kaldırılmıştır. - Sadece veri hareketleri sayılır - Veri hareketleri mimari düzeydeki katmanlar arasında oluşur - Ölçümler gereksinim belgesi üzerinden yapılabilir FFP = counting(((entry,exits),(reads,writes))archicturelevel i )
FPA ve varyantları
Süreç Ölçütleri - Şimdiye kadar incelediğimiz ölçütler bireysel olarak da uygulanabilecek program analizine dayalı ölçütlerdi - Yazılım geliştirme sürecine dair ölçüt toplama ve izleme daha farklı gereksinimlere sahiptir ve genellikle istatistiksel yöntemlerin kullanılmasını gerektirir. - Literatürde tanımlanmış bol ve çeşitli miktarda süreç ölçütü bulunur. Bunları dokuz ana kategori altında toplayıp incelyebiliriz.
Süreç Ölçütleri Şimdiye İlerleme ölçütleri proje görevlerinin planlanana göre tamamlanma miktarını temsil eder. Burn-down chart lar bir ilerleme ölçütü grafiğidir.
Süreç Ölçütleri Şimdiye Efor ölçütleri zaman içinde eldeki kaynakların harcanma miktarlarındaki değişimi ifade eder. Kümülatif olarak ölçülmezler.
Süreç Ölçütleri Şimdiye Yazılım geliştirme sürecindeki en önemli maliyetlerden biri işgücüdür. Bu nedenle proje süresince harcanın kümülatif efor maliyet grafiklerinde kullanılabilir.
Süreç Ölçütleri Şimdiye Gözden geçirme ölçütleri, yazılım üzerinde gerçekleştirilen gözden geçirmeler sonucu ortaya çıkan ölçütlerdir. Şu şekilde toplanabilirler: - Formal gözden geçirme: Hata sayısı, hata bulma oranı, hata durumları. - Müşteri değerlendirmeleri - Çalışan değerlendirmeleri - Yönetim değerlendirmeleri - Kalite değerlendirmeleri
Süreç Ölçütleri Şimdiye Entegrasyon, sistem ve kabul testleri sırasında ortaya çıkan kusur sayılarına ilişkin ölçütler. Bu ölçütler şu konularda fikir sahibi olmamıza neden olur: - Kusur bulma ve çözülme oranı - Kusur tipleri ve ciddiyetleri - Test miktarı kusur ilişkisi - Modül kusur yoğunluğu - Modül kusur dağılımı
Süreç Ölçütleri Şimdiye Gereksinim değişimlerinin ölçütler yardımıyla izlenmesi problemin ne kadar iyi analiz edildiğinin bir göstergesi olarak kullanılabilir. Bu tür grafiklerde detaylandırılmamış, eksik gereksinimlere de yer verilir
Süreç Ölçütleri Şimdiye Büyüklük ölçütleri izlendiğinde mutlaka planlanan ve kestirilen rakamlarla birlikte izlenmelidir. Büyüklükteki beklenmeyen değişimler/durağanlıklar kötü gidişe gösterge olabilir.
Süreç Ölçütleri Şimdiye Bilgisayar kaynağı tüketimi ölçütlerini kullanmak yazılımın başarımına dair bilgi sahibi olmamızı sağlar. Bu ölçütün toplanmasında geliştirme sürecinin ilk safhalarında daha dikkatli olunması gerekir.
Süreç Ölçütleri Şimdiye Alınan eğitimlere dair ölçütlerin proje çalışanlarının işe alım süreçlerini etkileyebilir, bunun yanında diğer proje ölçütleriyle birlikte incelendiğinde eğitimlerin etkinliğine ve yazılım kalitesine olan etkileri de sorgulanabilir.
Sonuçlar Daha kaliteli yazılımlar üretmek ve gelişim sağlamak için ölçütlerin kullanılması elzem. Ölçütler farklı düzeylerde kullanılabilir: -Program ölçütleri: Kişisel ve takım bazında, statik analize dayalı yöntemler. -Süreç ölçütleri: Proje bazında, ölçüt değerlendirme modelleri. -Ürün ölçütleri: Kurum bazında, istatistiksel yöntemler. «You can't control what you don't measure»» -- Tom DeMarco
Teşekkürler Sorularınız ve Yorumlarınız... ovatman@itu.edu.tr
Kaynaklar - Interpreting the CMMI, A process ımprovement approach, 2nd ed., Margaret K. Kulpa, Kent A. Johnson, CRC Press, 2008 - Metrics for Process Models: Empirical Foundations of Verification, Error Prediction, and Guidelines for Correctness, Jan Mendling, Springer, 2008 - Software Process Measurement and Control A Measurement-Based Point of View of Software Processes, Reiner Dumke, René Braungarten, Martina Blazey, Heike Hegewald, Daniel Reitz, Karsten Richter - University of Southern California CSCI 577b: Software Engineering II Lecture Notes