Bolum 5 Süreç ve Proje Metrikleri modified from Software Engineering: A Practitioner’s Approach by Roger S. Pressman Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use.

İyi bir yöneticinin ölçtüğü parametreler süreçler süreç metrikleri proje metrikleri ölçüm ürün metrikleri ürün Temel olarak neye göre ölçüm yaparız? • boyut? • fonksiyon?

Neden Ölçeriz? devam eden bir projenin durumunu değerlendirmek için, potansiyel riskleri izlemek için, “kritik” seviyeye gelmeden önce problemli alanları bulmak için, iş akışını veya görevlerini ayarlamak için, proje takımı yeteneklerinin yazılım işi ürünlerinin kalitesini kontrol etmesini değerlendirmek için.

Süreç Ölçümü Bir yazılım sürecinin etkinliğini dolayı bir şekilde ölçeriz. Yani, süreç tarafından ortaya konulabilecek çıktılara bağlı olarak metrikleri belirleriz. Çıktılar aşağıdakileri içerebilir yazılım piyasaya sürülmeden önce tespit edilmemiş hataların ölçümü son kullanıcılar tarafından bildirilen eksiklikler teslim edilen iş ürünleri sarf edilen insan gücü sarf edilen takvim zamanı uygulanan plan diğer ölçümler. Belirli yazılım mühendisliği görevlerinin karakteristiklerinin ölçümüyle de süreç metriklerini elde ederiz / türetiriz.

Süreç Metrikleri Kılavuzu Ölçüm datasını yorumlarken ortak algılamayı ve organizasyonel hassasiyeti / duyarlılığı kullan. Ölçüm ve metrikleri toplayan kişi veya takımlara düzenli olarak geri bildirim sağla. Kişileri değerlendirmek için asla metrikleri kullanma. Başarılabilecek hedef ve metrikleri ayarlayabilmek için uygulayıcılar ve takımlarla çalış. Metrikleri kişi veya takımları tehdit etmek için asla kullanma. Bir problemli alanı gösteren metrik verisi asla “negatif” olarak düşünülmemelidir. Bu veriler sürecin geliştirilmesi için birer işarettirler. Sadece bir metriğe saplanıp kalarak diğer önemli olabilecek metrikleri gözardı etme.

Hata Analizi Mantığı Bütün hata ve kusurlar kaynağına göre kategorilere ayrılır. (konfigürasyon hata, mantıkta hata, standartlara uymaması) Herbir hata veya kusuru düzeltme maliyeti kaydedilir. Herbir kategoride bulunan hata ve kusurlar sayılır ve azalan bir şekilde sıralanır. Herbir kategorideki toplam hata ve kusur maliyeti hesaplanır. Organizsasyona maliyeti yüksek olan kategori analiz edilerek tespit edilir. Maliyeti yüksek olan kategorideki hata ve kusurların tekrarının azaltılması için gerekli önlemler alınır gerekirse süreç modifiye edilir.

Bir Çalışmadaki Hatalar ve Kaynakları Mantıksal hata %20 Veri işleme / kullanma %10.5 Standartlar %6.9 Tanımlamalar / Şartnameler %25.5 Kullanıcı arabirimi %11.7 Hata kontrolü % 10.9 Donanım arayüzü %7.7 Yazılım arayüzü %6.0 Hataların kaynağını göstermek için dilimleri renklendirilmiş dilim grafiği kullanılabilir

Yazılım Sürecinin Geliştirilmesi Süreç Modeli SPI YSG Süreç Geliştirme Önerileri Geliştirme Amaçları Süreç Metrikleri

Süreç Metrikleri Kalite ile ilişkili Quality-related iş ürünlerinin veya teslimatların kalitesine odaklanır Üretkenlik ile ilişkili Productivity-related Sarf edilen çabaya ilişkili olarak iş-ürünlerin üretimi İstatistiksel SQA verisi Statistical SQA data hata sınıflandırma ve analizi Hata giderme etkinliği süreç aktivitesinden aktiviteye hataların yayılımı Verinin tekrar kullanımı Üretilen komponentlerin sayısı ve bunların tekrar kullanılabilirliğinin derecesi

Proje Metrikleri potansiyel problem ve riskleri azaltmak ve gecikmelerden kaçınmak için gerekli ayarlamaların yapılarak ürün geliştirme planının minimize edilmesi amacıyla kullanılır devem eden çalışmanın ürün kalitesinin değerlendirilmesi için ve gerektiğinde kalitenin arttırılması amacıyla teknik yaklaşımın modifiye edilmesi için kullanılır. herbir projede ölçülmesi gerekenler : girişler—işi yapmak için gereken kaynakların (kişi, araç gibi) ölçümü. çıkışlar—yazılım mühendisliği süreci esnasında oluşturulan teslimatlar ve ürünlerin ölçümü. sonuçlar—teslimatların etkinliğini gösteren ölçümler.

Önceki Projelerin Etkileri Önceki projelerden elde edilen tecrübeler yeni projelerde kullanılabilir tahmin edilen ve gerçekleşen hedefler, takvimler, görevler,…

Tipik Proje Metrikleri Herbir yazılım mühendisliği için Çaba/Zaman (Effort/time) Saatlik gözden geçirmelerde tespit edilen hatalar Planlanana karşı gerçek kilometre taşı tarihleri Değişiklikler (sayı) ve karakteristikleri Yazılım mühendisliği görevlerinde çabanın (effort) dağılımı

Yazılım Ölçümleri Yazılım ölçümleri 2’ ye ayrılabilir. doğrudan ölçümler dolaylı ölçümler

Doğrudan Ölçümler Yazılım mühendisliği sürecinin ölçümleridir ve maliyet ve sarf edilen çabaları içerir. Doğrudan ölçümler aşağıdakileri içerir LOC (lines of codes – satır kod) içerir çalışma hızı hafıza boyutu / gerekliliği ayarlanmış bir zaman diliminde raporlanan kusurlar …

Dolaylı Ölçümler Dolaylı ölçümler aşağıdakileri içerir fonksiyonellik kalite karmaşıklık etkinlilik (efficiency) dayanılıklılık sürdürülebilirlik …

Metrik Kılavuzu Ölçüm datasını yorumlarken ortak algılamayı ve organizasyonel hassasiyeti / duyarlılığı kullan. Ölçüm ve metrikleri toplayan kişi veya takımlara düzenli olarak geri bildirim sağla. Kişileri değerlendirmek için asla metrikleri kullanma. Başarılabilecek hedef ve metrikleri ayarlayabilmek için uygulayıcılar ve takımlarla çalış. Metrikleri kişi veya takımları tehdit etmek için asla kullanma. Bir problemli alanı gösteren metrik verisi asla “negatif” olarak düşünülmemelidir. Bu veriler sürecin geliştirilmesi için birer işarettirler. Sadece bir metriğe saplanıp kalarak diğer önemli olabilecek metrikleri gözardı etme.

Boyuta-Dayalı Metrikler Boyuta-dayalı metrikler üretilen yazılımın boyutu gözönüne alınarak kalite ve/veya üretkenlik ölçümlerinin normalize edilmesi ile türetilir. Genellikle metriklerin kaydedilmesi için bir tablo tutulur.

Tipik Boyuta-Dayalı Metrikler errors per KLOC (thousand lines of code) defects per KLOC $ per LOC pages of documentation per KLOC errors per person-month errors per review hour LOC per person-month $ per page of documentation

Fonksiyona-Dayalı Metrikler Bu metrikler uygulama ile birlikte teslim edilen fonksiyonelliklerin bir ölçümü olarak kullanılır. Fonksiyonellik doğrudan ölçülmediği için diğer doğrudan ölçümler kullanılarak bir sonuca varılmalıdır. Bu metrikler 1979 yılında Albrecht tarafından önerilmiştir. FP: Function Points: FP yazılımın bilgi alan ölçümleri ile yazılımın karmaşıklığının değerlendirilmesine bağlı olarak deneysel ilişkiler kullanılarak türetilmiştir.

Fonksiyonel Noktaların Hesabı 5 bilgi alan karakteristiği belirlenmiştir. kullanıcı girişlerinin sayısı kullanıcı çıkışlarının sayısı raporlar, hata mesajları, ekran çıktıları vs… kullanıcı sorgu / anket sayısı anlık girişe alınan anlık çıktılar dosya sayısı harici arayüzlerin sayısı bir sistemden diğerine veri transferi için kullanılan bütün makine okuyabilir arayüzler

Yeni Fonksiyonel Noktalar : Özellik Noktaları algoritmalar Boeing tarafından veri boyutunun fonksiyonel ve kontrol boyutları analize dahil edildi ve 3D fonksiyonel nokta indeksi ortaya konuldu. veri boyutu : alıkonulan veri (iç veri yapısı, dosyalar) sayısı ve harici veri sayısı (girişler, çıkışlar, harici referanslar vs. ) ve bunlara ek olarak veri boyutu sayısını türetmek için gereken karmaşıklık fonksiyonel boyut: Girişi çıkışa dönüştürmek için gereken iç işlem sayısı. semantik cümleler kümesi kontrol boyutu: Durumlar arasındaki geçiş sayısı.

Tipik Fonksiyona-Dayalı Metrikler errors per FP defects per FP $ per FP pages of documentation per FP FP per person-month

LOC ve FP yi Etkileyen Sebepler programlama dilleri tasarımın kalitesi

LOC ve FP’nin karşılaştırılması Representative values developed by QSM

Neden Fonksiyona-Dayalı Metrik tercih edilir? Programlama dili bağımsız Yazılım sürecinden önce tespit edilen hasır sayılabilir karakteristikleri kullanılır Daha az LOC içeren dahice (kısa) uygulamaları, hantal versiyonlarına karşılık cezalandırmaz. Tekrar kullanılabilir elemanların etkisini ölçmeyi kolaylaştırır

Nesneye-Dayalı Metrikler Number of scenario scripts (use-cases) Number of support classes (required to implement the system but are not immediately related to the problem domain) Average number of support classes per key class (analysis class) Number of subsystems (an aggregation of classes that support a function that is visible to the end-user of a system)

WebApp Proje Metrikleri Statik web sayfası sayısı Dinamik web sayfası sayısı İç sayfa bağlantı sayısı Kalıcı veri nesnesi sayısı Statik içerikli nesne sayısı Dinamik içerikli nesne sayısı Çalıştırılabilir fonksiyonlar …

Kalitenin Ölçülmesi Doğruluk — İstenen özelliklere göre programın işletilmesinin derecesi Sürdürülebilirlik—programın değişimlere cevap verebilme derecesi Bütünlük—programın dış saldırılara karşı dayanılılıklığının derecesi Kullanılabilirlik—programın kolay kullanılabilirliğinin derecesi

Hata Kaldırma Etkinliği (Defect Removal Efficiency) DRE = E /(E + D) eşitlikte: E yazılım son kullanıcıya teslim edilmeden önce bulunan hata sayısı D teslimattan sonra bulunan kusur (defect) sayısı DRE: hem proje hem de süreç seviyesinde yararlanılabilecek bir kalite metriğidir. DRE için ideal değer 1’dir.

Küçük Organizasyonlar için Merikler istek yapılma zamınndan değerlendirme tamamlanana kadar geçen zaman (saat veya gün), tqueue. değerlendirmeyi yapmak için gereken efor/çaba (insan- saat), Weval. değerlendirme tamamlanmasından personele değişiklik işinin verilmesi için geçen zaman (saat veya gün), teval. değişikliği yapmak için gereken efor/çaba (insan-saat), Wchange. saat ve/veya gün cinsinden değişikliği yapmak için gereken zaman, tchange. değişikliği yaparken ortaya çıkan hatalar, Echange. değişiklik müşteriye yansıtıldıktan sonra ortaya çıkan kusurlar Dchange.

Bir Metrik Programının Oluşturulması İş amaçlarını belirle. Ne bilmek veya öğrenmek istediğini belirle. Alt amaçları belirle. Alt amaçlar ile ilgili varlıkları ve özellikleri belirle Ölçüm hedeflerini formülleştir. Ölçüm amaçlarınıza ulaşmanızı sağlayacak ölçülebilir sorular ve indikatörler belirle Sorularınıza cevap bulmada yardımcı olabilecek indikatörleri oluşturacak veri elemanlarını belirle. Kullanılacak ölçümleri tanımla ve bu tanımları kullanıma hazır yap. Ölçümleri uygulamak için yapılabilecek aksiyonları belirle. Ölçümleri uygulamak için bir plan yap.