V Süreç Modeli. V Süreç Modeli. V Süreç Modeli. Helezonik Model. Helezonik(Spiral) Modeli BIL 304 YAZILIM MÜHENDİSLİĞİ

Transkript

1 BIL 304 YAZILIM MÜHENDİSLİĞİ Yrd Doç. Dr. Turgay İBRİKÇİ V Süreç Modeli Sol taraf üretim, sağ taraf sınama işlemleridir. V süreç modelinin temel çıktıları; Kullanıcı Modeli Geliştirme sürecinin kullanıcı ile olan ilişkileri tanımlanmakta ve sistemin nasıl kabul edileceğine ilişkin sınama belirtimleri ve planları ortaya çıkarılmaktadır. Mimari Model Sistem tasarımı ve oluşacak altsistem ile tüm sistemin sınama işlemlerine ilişkin işlevler. Gerçekleştirim Modeli Yazılım modüllerinin kodlanması ve sınanmasına ilişkin fonksiyonlar. Gereksinimle r Sistem Tanımları V Süreç Modeli Sistem Altsistem Modül KULLANICI MODELİ MİMARİ MODEL Sınanmış Altsistem Sınanmış Modül GERÇEKLEŞTİRİM MODELİ Bitmiş Sistem Sınanmış Sistem Sistem V Süreç Modeli Belirsizliklerin az, iş tanımlarının belirgin olduğu yazılım projeleri için uygun bir modeldir. Model, kullanıcının projeye katkısını arttırmaktadır. Bilişim projesinin iki aşamalı olarak sunulması için oldukça uygundur: İlk kısımda, kullanıcı modeli hedeflenerek, iş analizi ve kabul sınamalarının tanımları yapılmakta, İkinci kısımda ise ilkinde elde edilmiş olan kullanıcı modeli tasarlanıp, gerçeklenmektedir. Helezonik(Spiral) Modeli Planlama Amaca, Alternatiflere ve Sınırlamalara karar verme onay ekseni Öninceleme Analizi Geliştirme Planı Birleştirme ve Test Planı Bir sonraki fazın planlanması ve kullanıcı değerlendirmesi Kullanıcı Değerlendirme Risk Analizi Risk Analizi Risk Analizi Prototip 1 Risk Analizi Prototip 2 Prototip 3 İşin Prototipi İşin Simulasyon ve Modelleme Genel Kavramı Yazılım Gereksinimi Ürün Detaylı Gereksinim Tasarımı Tasarım onaylama Kodlama Tasarımı test Etme ve onay Servis testi Kabul testi Modül Testi Birleştirme Risk Analizi Alternatifleri değerlendirme ve risk analizi Geliştirme ve bir sonraki ürünü onaylama Üretim 1. Planlama Helezonik Model Üretilecek ara ürün için planlama, amaç belirleme, bir önceki adımda üretilen ara ürün ile bütünleştirme 2. Risk Analizi 3. Üretim Risk seçeneklerinin araştırılması ve risklerin belirlenmesi Ara ürünün üretilmesi 4. Kullanıcı Değerlendirmesi Ara ürün ile ilgili olarak kullanıcı tarafından yapılan sınama ve değerlendirmeler 1

2 Helezonik modelin avantajları 1. Kullanıcı Katkısı Üretim süreci boyunca ara ürün üretme ve üretilen ara ürünün kullanıcı tarafından sınanması temeline dayanır. Yazılımı kullanacak personelin sürece erken katılması ileride oluşabilecek istenmeyen durumları engeller. 2. Yönetici Bakışı Gerek proje sahibi, gerekse yüklenici tarafındaki yöneticiler, çalışan yazılımlarla proje boyunca karşılaştıkları için daha kolay izleme ve hak ediş planlaması yapılır. 3. Yazılım Geliştirici (Mühendis) Bakışı Yazılımın kodlanması ve sınanması daha erken başlar. Helezonik Model Risk Analizi Olgusu ön plana çıkmıştır. Her döngü bir fazı ifade eder. Doğrudan tanımlama, tasarım,... vs gibi bir faz yoktur. Yinelemeli artımsal bir yaklaşım vardır. Prototip yaklaşımı vardır. Evrimsel Geliştirme Süreç Modeli İlk tam ölçekli modeldir. Coğrafik olarak geniş alana yayılmış, çok birimli organizasyonlar için önerilmektedir (banka uygulamaları). Her aşamada üretilen ürünler, üretildikleri alan için tam işlevselliği içermektedirler. Pilot uygulama kullan, test et, güncelle diğer birimlere taşı. Modelin başarısı ilk evrimin başarısına bağımlıdır. Evrimsel Geliştirme Süreç Modeli Genel Tanımlama Eşzamanlı Aktiviteler Tanımlama Geliştirme Test Etme İlk Sürüm Ara Sürümler Son Sürüm Örnek Çok birimli banka uygulamaları. Önce sistem geliştirilir ve Şube-1 e yüklenir. Daha sonra aksaklıklar giderilerek geliştirilen sistem Şube-2 ye yüklenir. Daha sonra geliştirilen sistem Şube- 3 e,. yüklenir. Belirli aralıklarla eski şubelerdeki güncellemeler yapılır. Aksaklığı Değişiklik denetimi Konfigürasyon Yönetimidir Sürüm Yönetimi Değişiklik Yönetimi Kalite Yönetimi 2

3 Artırımsal Geliştirme Süreç Modeli Üretilen her yazılım sürümü birbirini kapsayacak ve giderek artan sayıda işlev içerecek şekilde geliştirilir. Öğrencilerin bir dönem boyunca geliştirmeleri gereken bir programlama ödevinin 2 haftada bir gelişiminin izlenmesi (bitirme tezleri). Uzun zaman alabilecek ve sistemin eksik işlevlikle çalışabileceği türdeki projeler bu modele uygun olabilir. Bir taraftan kullanım, diğer taraftan üretim yapılır. Artırımsal Geliştirme Süreç Modeli Genel Gereksinim Belirlenmesi Sistem Artırılımının Yapılması Gereksinimleri Artırımlara Bölme Artırılımın Onaylanması Bitmemiş Sistem Sistem Mimarisini Tanımlama Artırılımın Birleştirilmesi Sistemin Onaylanması Son Sistem Araştırma Tabanlı Süreç Modeli Yap-at prototipi olarak ta bilinir. Araştırma ortamları bütünüyle belirsizlik üzerine çalışan ortamlardır. Yapılan işlerden edinilecek sonuçlar belirgin değildir. Geliştirilen yazılımlar genellikle sınırlı sayıda kullanılır ve kullanım bittikten sonra işe yaramaz hale gelir ve atılır. Model-zaman-fiyat kestirimi olmadığı için sabit fiyat sözleşmelerinde uygun değildir. Örnek En Hızlı Çalışan asal sayı test programı! En Büyük asal sayıyı bulma programı! Satranç programı! Metodolojiler Metodoloji: Bir BT projesi ya da yazılım yaşam döngüsü aşamaları boyunca kullanılacak ve birbirleriyle uyumlu yöntemler bütünü. Bir metodoloji, bir süreç modelini ve belirli sayıda belirtim yöntemini içerir Günümüzdeki metodolojiler genelde Çağlayan ya da Helezonik modeli temel almaktadır Kullanılacak Yöntemde Bulunması Gereken Temel Bileşenler (Özellikler) Ayrıntılandırılmış bir süreç modeli Ayrıntılı süreç tanımları İyi tanımlı üretim yöntemleri Süreçlerarası arayüz tanımları Ayrıntılı girdi tanımları Ayrıntılı çıktı tanımları Proje yönetim modeli Konfigürasyon yönetim modeli Maliyet yönetim modeli Kalite yönetim modeli Risk yönetim modeli Değişiklik yönetim modeli Kullanıcı arayüz ve ilişki modeli Standartlar 3

4 Yöntemde Bulunması Gereken Temel Bileşenler Yöntem bileşenleri ile ilgili olarak bağımsız kuruluş (IEEE, ISO, vs.) ve kişiler tarafından geliştirilmiş çeşitli standartlar ve rehberler mevcuttur. Kullanılan süreç modelleri ve belirtim yöntemleri zaman içinde değiştiği için standart ve rehberler de sürekli güncellenmektedir. Bir kuruluşun kendi yöntemini geliştirmesi oldukça kapsamlı, zaman alıcı ve uzmanlık gerektiren bir faaliyet olup, istatistikler yaklaşık 50 kişi/ay lık bir iş gücü gerektirdiğini göstermektedir. Bir Yöntem Örneği Yourdan Yapısal Sistem Tasarımı Metodolojisi-Yourdon Structured Method (YSM). Kolay uygulanabilir bir model olup, günümüzde oldukça yaygın olarak kullanılmaktadır. Çağlayan modelini temel almaktadır. Bir çok CASE aracı tarafından doğrudan desteklenmektedir. Aşama Yourdon Yapısal Sistem Tasarım Yöntemi Planlama Analiz Analizden Tasarıma Geçiş Tasarım Kullanılan Yöntem ve Araçlar Veri Akış Şemaları, Süreç Belirtimleri, Görüşme, Maliyet Kestirim Yöntemi, Proje Yönetim Araçları Veri Akış Şemaları, Süreç Belirtimleri, Görüşme, Nesne ilişki şemaları Veri Akışa Dayalı Analiz, Süreç belirtimlerinin program tasarım diline dönüştürülmesi, Nesne ilişki şemalarının veri tablosuna dönüştürülmesi Yapısal Şemalar, Program Tasarım Dili, Veri Tabanı Tabloları Ne için Kullanıldığı Süreç İnceleme Kaynak Kestirimi Proje Yönetimi Süreç Analizi Veri Analizi Başlangıç Tasarımı Ayrıntılı Tasarım Başlangıç Veri tasarımı Genel Tasarım Ayrıntılı Tasarım Veri Tasarımı Çıktı Proje Planı Sistem Analiz Raporu Başlangıç Tasarım Raporu Sistem Tasarım Raporu Planlama Yazılım geliştirme sürecinin ilk aşaması Başarılı bir proje geliştirebilmek için projenin tüm resminin çıkarılması işlemi Proje planlama aşamasında yapılan işlemler Proje Kaynaklarının Belirlenmesi Proje Maliyetlerinin Kestirilmesi Proje Ekip Yapısının Oluşturulması Ayrıntılı Proje Planının Yapılması Projenin İzlenmesi Proje planı tüm proje süresince sürekli olarak kullanılacak, güncellenecek ve gözden geçirilecek bir belgedir Proje Kaynakları İnsan Kaynakları Donanım Kaynakları Yazılım Kaynakları Planlama; bu kaynakların tanımını yapar ve zaman kullanımı, görev süreleri, edinilme zamanlarını planlar İnsan Kaynakları Planlama; hangi tür elemanların, hangi süre ile ve projenin hangi aşamalarında yer alacağını belirler Proje Yöneticisi Donanım Ekip Lideri Yazılım Ekip Lideri Web Tasarımcısı Sistem Tasarımcısı Programcı Sistem Yöneticisi Veri Tabanı Yöneticisi Kalite Sağlama Yöneticisi Donanım Mühendisi Ağ Uzmanı Yazılım Destek Elemanı Donanım Destek Elemanı Eğitmen Denetleyici Çağrı Merkezi Elemanı 4

5 Donanım Kaynakları Günümüzde giderek açık sistem mimarisine dönüşmektedir. Donanım Kaynakları: Ana Bilgisayarlar Sunucular (Web, E-posta, Veri Tabanı) Kullanıcı Bilgisayarları (PC) Yerel Alan Ağı (LAN) Alt Yapısı Geniş Alan Ağı (WAN) Alt Yapısı Yazılımın geliştirileceği ortam, gerçek kullanım ortamı dışında olmalıdır. Öte yandan, geliştirme ve uygulama ortamlarının aynı konfigürasyonda olmaları, ileride kurulum sırasında ortaya çıkabilecek taşıma sorunlarını büyük ölçüde giderecektir. Yazılım Kaynakları Büyük ölçekte otomatik hale getirilmiş ve bilgisayar destekli olarak kullanılmaktadır. Bilgisayar Destekli Tasarım (CAD) ve Bilgisayar Destekli Mühendislik (CASE) araçları olarak bilinmektedirler. Yazılım Kaynakları İş sistemleri planlama araçları İş akış yapısının üst modelinin üretilmesinde kullanılır. Bilgi akışı, bilgi yapısı iş birimlerindeki tıkanıklıklar bu araçlar kanalıyla ortaya çıkarılır. Proje yönetim araçları Yönetici tarafından, projede yapılan işlerin izlenmesi, kaynak ataması, proje iş yapısının üretilmesi, gözlenen değerlerin işlenmesini sağlayan araçlar. Analiz ve tasarım araçları Kullanılan modelleme tekniklerini ayrı ayrı ya da bütünleşik olarak uygulayan araçlar. Üretilen modelin kalitesinin ölçülmesi Programlama araçları Derleyiciler, nesne-tabanlı programlama araçları, görsel programlama platformları. Yazılım Kaynakları (devam) Test araçları Yazılımı doğrulama ve geçerleme işlemlerinde kullanılır. Test verisi üreticiler, otomatik test yordamları,... Prototipleme ve simülasyon araçları Geliştirmenin erken aşamalarında kullanıcıya, sonuç ürünün çalışması ile ilgili fikir veren ve yönlendiren araçlar. Bakım araçları Programın bakımını kolaylaştıran, bir kaynak koddan program şemalarının üretilmesini, veri yapısının ortaya çıkarılmasını sağlayan araçlar. Destek araçları İşletim sistemleri, ağ yazılımları, e-posta ve ortam yönetim araçları. Proje Maliyetleri Maliyet kestirimi; bir bilgi sistemi ya da yazılım için gerekebilecek iş gücü ve zaman maliyetlerinin üretimden önce belirlenebilmesi için yapılan işlemlerdir. Kullanılan Unsurlar Geçmiş projelere ilişkin bilgiler Proje ekibinin deneyimleri İzlenen geliştirme modeli birden çok kez uygulanabilir Proje Maliyetleri Maliyet yönetimi sayesinde; Gecikmeler önlenir Bilgi sistemi geliştirme süreci kolaylaştırılır Daha etkin kaynak kullanımı sağlanır İş zaman planı etkin olarak gerçekleştirilir Ürün sağlıklı olarak fiyatlandırılır Ürün zamanında ve hedeflenen bütçe sınırları içerisinde bitirilir 5

6 Gözlemlenebilecek değerler Projenin toplam süresi Projenin toplam maliyeti Projede çalışan eleman sayısı, niteliği, çalışma süresi Toplam satır sayısı Bir satırın maliyeti (ortalama) Bir kişi/ay da gerçekleştirilen satır sayısı Toplam işlev sayısı Bir işlevin maliyeti Bir kişi/ay da gerçekleştirilen işlev sayısı Bir kişi/ay da maliyeti Maliyet Kestirim Yöntemleri 1. Projenin boyut türüne göre Proje büyüklüğünü kestiren yöntemler Proje zaman ve işgücünü kestiren yöntemler 2. Projelerin büyüklüğüne göre Makro yöntemler (büyük boyutlu projeler 30 kişi-yıl) Mikro Yöntemler (orta ve küçük boyutlu projeler) 3. Uygulanış biçimlerine göre Çok yalın düzeyde Orta ayrıntılı düzeyde Çok ayrıntılı düzeyde Maliyet Kestirim Yöntemleri-II 4. Değişik aşamalarda kullanılabilirlik Planlama ve analiz aşamasında kullanılabilen Tasarım aşamasında kullanılabilen Gerçekleştirim aşamasında kullanılabilen yöntemler 5. Yöntemlerin yapılarına göre Uzman deneyimine gereksinim duyan Önceki projelerdeki bilgileri kullanan yöntemler Yazılım Büyüklük Kestirim Yöntemleri Yazılım büyüklük kestiriminde kullanılan yöntemler; - teknik büyüklük kestirim yöntemleri, - işlevsel büyüklük kestirim yöntemleri olarak sınıflandırılmıştır. İşlev Noktaları Yöntemi İşlev noktaları geliştirmenin erken aşamalarında (analiz aşamasında) saptanan bir değerdir. Sistemin oluşturulduğu ortamdan bağımsız elde edilir. Problem tanımı girdi olarak alınarak üç temel adım izlenir: Problemin bilgi ortamının incelenmesi Problemin teknik karmaşıklığının incelenmesi İşlev noktası hesaplama Teknik Büyüklük Kestirim Yöntemleri Satır Sayısı (Lines of Code - LOC) Tabi ki 1000 LOC değeri olan bir C++ programı, 100 LOC değerine sahip bir C++ programından 10 kat daha büyüktür. Fakat bu sayının içinde yorum satırları var mı? Yorum satırlarını dahil etmeli miyiz? (Yorum Satırının Avantajı) Deneyim ile kod oluşturulması (Aynı özellik farklı kod sayısı) Programlama dili farkı Assembler <> Visual Basic Değişkenlerin tanımlanması LOC olarak sayılmalı mıdır? 6

7 İşlev Puanı (Function Points-FP) İşlev Puanı (Function Points) (devam ) Bu yaklaşım, verimliliğin üretilen işlev puanına göre adam-ay olarak belirlenmesini öngörür. Eğer proje ile ilgili girdi çıktı gibi özellikler tahmin edilebiliyorsa, bunlar kullanılarak geliştirilecek sisteme ait bir İşlev Puanı (Function Points) hesabı yapılabilir ve sonuçlar Satır Sayısına (LOC) çevrilebilir. Bu satır sayısından maliyet, emek ve süre tahmini yapılabilir. İşlev Puanı Dış Girdilerin sayısı Dış Çıktıların sayısı Dış Sorguların sayısı İç Mantıksal dosyaların sayısı Dış Arayüz Dosyalarının sayısı Ağırlık Faktörleri ile ayarlanma Teknik Karmaşıklık Faktörleriyle ayarlama FP LOC a dönüştürme İşlev Puanını, LOC a dönüştürmek için programlama diline göre saptanan faktörler kullanılır. SLOC Problemin bilgi ortamının incelenmesi Beş paramere ile incelenir. Kullanıcı Girdileri: Kullanıcı Çıktıları: Kullanıcı Sorguları: Dosyalar: Dışsal arayüzler: Bunların ağırlık faktörleriyle çarpımları toplanarak, Ayarlanmamış İşlev Nokta (AİN) sayısı hesaplanır. İşlev Puanında Sistemin İşlevselliği Kullanıcı Girdileri: Uygulamanın dışından uygulamanın içine doğru olan süreçleri ve işlenebilir verileri gösterir. Veri genellikle uygulamaya içine eklenebilir, silinebilir veya güncellenebilir. Dış girdilere örnek olarak; kullanıcının bilgi girişi yaptığı veri giriş ekranları ve mantıksal içsel dosyalar verilebilir. Kullanıcı Çıktıları: Verinin uygulama sınırları içinden dışarı çıkmasına izin veren süreç veya işlemlerdir. Dış çıktılara örnek olarak; raporlar, doğrulama mesajları ve ekran çıktıları verilebilir. Kullanıcı Sorguları: Kullanıcı isteği doğrultusunda alınan hızlı veri çıkışlarıdır Dış sorgular dosyada saklanan veriyi değiştirmez veya güncellemez. Sadece bilgiyi okurlar. Dosyalar: Uygulama sınırları ile birlikte verilerin saklandığı mantıksal bir dosyadır. İç mantıksal dosyalara örnek olarak, içsel kullanıcı verileri, saklanan veriler verilebilir. Dışsal arayüzler: Başka bir uygulama sistemi ile olan paylaşımı ifade eder. Problem Bilgi Ortamı Bileşenleri UFP = Girdiler x W(1) + Çıktılar x W(2) + Sorgular x W(3) + İç Dosyalar x W(4) + Dış Arayüz Dosyaları x W(5) Ölçüm Parametresi Sayı Ağırlık Faktörü Yalın Ortalama Karmaşık 1-Kullanıcı Girdi sayısı? = 2-Kullanıcı Çıktı sayısı? = 3-Kullanıcı Sorgu Sayısı? = 4-Kütük Sayısı? = 5-Dışsal Arayüz Sayısı? = Toplam Sayı = Her bir bileşenin zorluk derecesi basit, orta ve karmaşık gibi Tablo da verilen rakamsal değerlere bağlı olarak ölçülebilmektedir. Bu ölçülen değerler toplanarak Düzeltilmemiş İşlev Puanı nı (Unadjusted Function Points - UFPs) oluşturmaktadır. 7

8 İşlev Puanı (Function Points) (devam ) 14 Genel Sistem Özelliğine göre sistemin beklenilen uygulama zorluğu için ilave bir teknik karmaşıklık faktörü hesaplanır. Cevaplar 0 ile 5 arasında puanlandırılır 0: hiç yok ya da etkisiz, 1: önemsiz etki, 2: az etkili, 3:orta düzeyde etkili 4: önemli düzeyde etkili, 5: güçlü etki DI = i= Cevap i TCF = 0,65 + 0,01 x DI Genel Sistem Özellikleri 1 Veri İletişimleri Kısa Açıklama Sistemin uygulaması ile bilgi değişimi veya transferinde yardımcı olmak için kaç tane iletişim aracı vardır? 2 Dağıtılan Veri/İşleme Dağıtılan bilgi ve işleme fonksiyonları nasıl idare edilmektedir? 3 Performans 4 Çok Kullanılan Konfigürasyon 5 İşlem Oranı İşlem oranı yüksek midir? Hedefler, yanıtlama zamanı ve iş çıkarma performansı önemli midir? Uygulamanın idare edileceği mevcut donanım platformu ne kadar yoğun kullanılmaktadır? 6 Çevrimiçi Veri Girişi Hangi oranda bilgi çevrimiçi girilmektedir? 7 Son Kullanıcı Verimliliği Uygulama son kullanıcı verimliliği için mi tasarlanmıştır? 8 Çevrimiçi Güncelleme Kaç veri dosyası çevrimiçi güncellenmektedir? 9 Karmaşık İşlem Yapma Dâhili işlem yapma karmaşık mıdır? 10 Yeniden Kullanılabilirlik Uygulama yeniden kullanılabilir olması için mi tasarlanmıştır? 11 Dönüştürme/Kurulum Kolaylığı Sistemde otomatik dönüşüm ve kurulum da dâhil edilmiş midir? 12 İşlevsel Kolaylık 13 Çoklu Saha Kullanımı 14 Değişimi Kolaylaştırma TCF: Technical Complexity Factors Teknik Karmaşıklık Faktörler DI: Total Degree of Influence - Etki Toplam Derecesi Yedekleme, başlatma ve kurtarma gibi operasyonlar ne kadar otomatiktir? Uygulama çoklu örgüte sahip çoklu sahalar için özellikle mi tasarlanmış, geliştirilmiş ve desteklenmiştir? Uygulama kullanıcı tarafından kullanım kolaylığı ve değişimi kolaylaştırmak için özel olarak mı tasarlanmış, geliştirilmiş ve desteklenmiştir? Satır Sayısı Kestirimi İşlev Puanı aşağıdaki formül ile hesaplanır: - FP = UFP x TCF İşlev Puanı nı, Satır Sayısına dönüştürmek için aşağıdaki formülden yararlanılır. - LOC = İşlev Puanı x Programlama Dili LOC Katsayısı Assembly 300 Cobol 100 Fortran 100 Pascal 90 C 90 Ada 70 Nesne Kökenli Diller Kuşak Dilleri 20 Kod Üreticiler 15 İP=300 ise ve Nesne Tabanlı bir dil (SmalTalk) kullanılıyor ise Satır Sayısı=300*30 olarak hesaplanır İşlev Puanı (Function Points) Örnek Proje Yazılım projesi-stok takip Sistemi- toplam yedi modülden oluşan bir Windows uygulamasıdır. Programa ilişkin modüller aşağıda verilmektedir. a) Kullanıcı Giriş Ekranı b) Ürün Arama ve Listeleme Ekranı ( Arama Kriterleri (Ürün Kodu, Ürün Adı, Kategorilere Göre Arama), Listeleme (Ürün Kodu, Ürün Adı, Kategori Sil, Stok Durumu, Aktiflik) c) Stok Giriş Güncelleme ve Silme Ekran ( Ürün Adı, Kategori, Adet, Stok Giriş, Tarihi, Hangi Bölüme Gönderilmiş,Aktif) d) Kişisel Bilgiler ( Ad, Soyad, Bölüm, Unvan) e) Kategori Bilgileri ve Demirbaş Bilgileri Giriş Ekranı. f) Personel Üzerine Demirbaş Ekranı ( Personel unvanına göre, adına,soyadına ve bölümüne göre arama yapabilmektedir. Personel üzerine demirbaş verme işlemleri yapılabilmektedir.) g) Listeme Raporlama ( Stok ismine göre, stok tipine göre, stok türlerine göre arama yapılabilmektedir. Personel üzerindeki stokları listeleyebilmektedir. Örnek Proje Stok Takip Sistemi Arama Bilgileri Giriş (Orta) Stok Girişi(Orta) Kategori Bilgisi (Basit) Login Bilgileri (Basit) Stok Takip Sistemi Dış Arayüz Personel Verileri (Basit) İç Dosyalar Personel Demirbaş Dosyası(Orta) Arama Listesi (Orta) Stok Listesi(Orta) Personel Eşleştirme (Karışık) Listeleme Raporlama(Orta) Girdiler: Çıktılar: Örnek Proje Düzeltilmemiş İşlev Puanı İç Dosyalar : 2 Basit 2 Orta 3 Orta 1 Karmaşık 1 Orta Personel Demirbaş Dosyası Dış Arayüz Dosyaları: 1 Orta Personel Listesi Basit Orta Karmaşık (1) Dış Girdiler (2) Dış Çıktılar (3) Dış Sorgular (4) İç Dosyalar (5) Dış Arayüz Dosyaları UFP = [Dış Girdiler x W(1)] + [Dış Çıktılar x W(2)] + [Dış Sorgular x W(3)] + [İç Mantıksal Dosyalar x W(4)] + [Dış Arayüz Dosyaları x W(5)] UFP = [(2*3) + (2*5)] + [(3*6) + (1*7)] + [1*13] + [1*5] = 59 Örnek Proje Düzeltilmiş İşlev Puanı 1. Sistem güvenilir yedekleme ve kurtarma gerektiriyor mu? 2 2. Veri iletişimi gerekiyor mu? 2 3. Dağıtık fonksiyon var mı? 3 4. Performans kritik mi? 2 5. Sistem çok kullanılan bir işletim ortamında mı çalışacak? 2 6. Sistem on-line veri girişi gerektiriyor mu? 3 7. On-line veri girişi, giriş işlemlerinin birden fazla ekran ya da işlem üzerinden olmasını mı gerektiriyor? 4 8. Ana dosyalar on-line mı güncelleniyor? 3 9. Girdiler, çıktılar, dosyalar ve sorgular karmaşık mı? Kod yeniden kullanabilir olarak mı tasarlanmış? İç süreç karmaşık mı? Dönüşüm ve kurulum tasarım içerisinde mi? 1 Uygulama değişik kuruluşlarda birden fazla kurulum gerektirecek şekilde mi 13. tasarlanmış? 1 Uygulama kullanıcı tarafından kolaylıkla kullanmayı ve değiştirmek üzere mi 14. tasarlanmış? 5 DI = i= Cevap i = 34 FP = UFP x (0,65 + 0,01 x DI) = 144 x (0, ,01 x 34) = LOC = 46 x = 1401,84 satırsayısı 8

9 Projenin Geliştirilmesi Sonrasında Elde Edilen Ölçütler Aynı yazılım projesi, üç farklı yazılım ekibi tarafından gerçekleştirilmiştir. Bu yazılım ekipleri aynı teknolojik altyapıyı kullanarak bu yazılım projesini geliştirmişlerdir. Yapılan çalışmalar sonucunda projeye ilişkin veriler, SourceMonitor V3.3 kullanılarak elde edilmiştir. Projenin Geliştirilmesi Sonrasında Elde Edilen Ölçütler Proje başında FP yöntemi kullanılarak tahmin edilen proje büyüklüğü 1402 satır olarak elde edilmişti. Aynı yazılım projesi, üç farklı ekip tarafından gerçekleştirildikten sonra, projelerin büyüklüğüne bakıldığında, bu üç yazılım projesinin ortalama olarak 1553 kod satırından oluştuğu görülmektedir. İşlev noktası(in) sayısı hesaplama İN=AİN*(0,65*0,01*TKF) Değişik amaçlarla kullanılabilir Üretkenlik = İN / Kişi-Ay Kalite = Hatalar / İN Maliyet = TL / İN Etkin Maliyet Modeli The Constructive Cost Model -COCOMO 1981 Boehm Mikro maliyet kestirim modeline örnektir. Kullanılacak ayrıntı düzeyine göre üç ayrı model biçiminde yapılabilir: Temel Model Ara Model Ayrıntı Model Satır Sayısı COCOMO Modeli COCOMO Modeli İş Gücü Zaman Önerilen Ölçüm Seti Ana Ölçüm Parametreleri (Metric) 1. Karmaşıklık 2.İşlev Puan (Function Point) 3.Önem 4. Ayrılan Bütçe A. İşin Büyüklüğü (Ürün) 5. Ürünün beklenen özellikleri 6. Çalışanın yeterlilikleri 7 Çalışanların Projeye katılım oranları 8. Çalışan Sayıları 9

10 B. Kaynak 9. Donanım Durumu 10.Bütçe Değişme Riski 11. Çalışan Riski 12.Donanım Riski C. Risk 13.Ürünün tanımının ve kapsamının değişme riski 14.Yazılım Geliştirme araçlarının kullanım kolaylığı 15.Yazılım Geliştirme araçlarının kullanım tecrübesi 16. Yazılım Geliştirme Araçlarının Kullanımı D. Teknoloji 17. Modern Programlama Teknikleri 18.Ortamın genel özellikleri 19.Sahiplenilme (Her bir payda türünün projeyi sahiplenmesi) 20.Baskı 21.Zaman kullanım durumu F.Ortam 22.Verimlilik durumu F.Planlar ve Tahminler 23. Tahmin 24. Planlar COCOMO formülleri İş Gücü (K) K=a*S b Zaman (T) T=c*K d a,b,c,d : her bir model için farklı katsayılar S : bin türünden satır sayısı Ayrık Projeler: Proje Sınıfları Boyutları küçük, Deneyimli personel tarafından gerçekleştirilmiş LAN üzerinde çalışan insan kaynakları yönetim sistemi gibi Yarı Gömülü: Hem bilgi boyutu hem donanım sürme boyutu olan projeler Gömülü Projeler: Donanım sürmeyi hedefleyen projeler (pilotsuz uçağı süren yazılım - donanım kısıtları yüksek) Temel Model Küçük-orta boy projeler için hızlı kestirim yapmak amacıyla kullanılır Dezavantajı: Yazılım projesinin geliştirileceği ortam ve yazılımı geliştirecek ekibin özelliklerini dikkate almaz Avantajı: Hesap makinesi ile kolaylıkla uygulanabilir Ayrık Projeler Temel Model İş Gücü K=2.4*S 1,05 Zaman T=2.5*K 0,38 Yarı Gömülü Projeler İş Gücü K=3,0*S 1,12 Zaman T=2.5*K 0,35 Gömülü Projeler İş Gücü K=3,6*S 1,20 Zaman T=2.5*K 0,32 10

11 Ara Model Temel modelin eksikliğini gidermek amacıyla oluşturulmuştur. Bir yazılım projesinin zaman ve iş gücü maliyetlerinin kestiriminde; Proje ekibinin özelliklerini, Proje geliştirmede kullanılacak araçları, yöntem ve ortamı dikkate alır. Üç Aşamadan oluşur: İş gücü hesaplama Maliyet çarpanı hesaplama İlk iş gücü değerini düzeltme İş Gücü Hesaplama Ayrık Projeler K=3.2*S 1,05 Yarı Gömülü Projeler K=3,0*S 1,12 Gömülü Projeler K=2.8*S 1,20 Maliyet Çarpanı Hesaplama Maliyet Çarpanı 15 maliyet etmeninin çarpımı sonucudur. Maliyet Etmenleri Seçenekler Maliyet etmeni Çok Çok Oldukça Yüksek Düşük Düşük Normal Yüksek Yüksek RELY 0,75 0,88 1,00 1,15 1,40 - Ürün Özellikleri DATA - 0,94 1,00 1,08 1,16 - CPLX 0,70 0,85 1,00 1,15 1,30 1,65 TIME - - 1,00 1,11 1,30 1,66 STOR - - 1,00 1,06 1,21 1,56 Bilgisayar Özellikleri VIRT - 0,87 1,00 1,15 1,30 - C= C1*C2*C3*...*C15 Personel Özellikleri Proje Özellikleri TURN - 0,87 1,00 1,07 1,15 - ACAP 1,46 1,19 1,00 0,86 0,71 - AEXP 1,29 1,13 1,00 0,91 0,82 - PCAP 1,42 1,17 1,00 0,86 0,70 - VEXP 1,21 1,10 1,00 0, LEXP 1,14 1,07 1,00 0, MODP 1,24 1,10 1,00 0,91 0,82 - TOOL 1,24 1,10 1,00 0,91 0,83 - SCED 1,23 1,08 1,00 1,04 1,10 - Ürün Özellikleri Rely: Yazılımın güvenirliği Data: Veri Tabanının Büyüklüğü. Burada program büyüklüğüne oranı dikkate alınır. Cplx: Karmaşıklığı. Bilgisayar Özellikleri Time: İşletim zamanı kısıtı Stor: Ana Bellek Kısıtı Virt: Bilgisayar Platform Değişim Olasılığı. Bellek ve Disk kapasitesi artırımı, CPU Upgrade Turn: Bilgisayar İş Geri Dönüş Zamanı. Hata düzeltme süresi. 11

12 Personel Özellikleri Acap: Analist Yeteneği: Deneyim, Birlikte çalışabilirlik. Aexp: Uygulama Deneyimi. Proje ekibinin ortalama tecrübesi. Pcap: Programcı Yeteneği. Vexp: Bilgisayar Platformu Deneyimi. Proje ekibinin geliştirilecek platformu tanıma oranı. Lexp: Programlama dili deneyimi. Proje Özellikleri Modp: Modern Programlama Teknikleri. Yapısal programlama, Görsel programlama, Yeniden kullanılabilirlik. Tool: Yazılım Geliştirme araçları kullanımı. CASE araçları Metin düzenleyiciler Ortam yönetim araçları Sced: Zaman Kısıtı. İlk İşgücü değerini Düzeltme Kd= K * C Kd= Düzeltilmiş İşgücü * Temel Formüldeki Zamanla formülü kullanılarak zaman maliyeti hesaplanır. Ayrıntı modeli Temel ve ara modele ek olarak iki özellik taşır. Aşama ile ilgili işgücü katsayıları: her aşama için (planlama, analiz, tasarım, geliştirme, test etme) farklı katsayılar, karmaşıklık belirler Üç düzey ürün sıra düzeni: yazılım maliyet kestiriminde Modül Altsistem Sistem Sıra düzenini dikkate alır Proje Ekip Yapısı Oluşturma PANDA proje Ekip yapısı temel olarak her proje biriminin doğrudan proje yönetimine bağlı olarak çalışması ve işlevsel bölümlenme esasına göre oluşturulur. Temel bileşenler Proje Denetim Birimi Proje Yönetim Birimi Kalite Yönetim Birimi Proje Ofisi Teknik Destek Birimi Yazılım Üretim Eşgüdüm Birimi Eğitim Birimi Uygulama Destek Birimi Yüklenici Proje Ekip Yapısı Proje Denetim Birimi: En üst düzey yönetimlerin proje ile ilgisinin sürekli sıcak tutulması ve onların projeye dahil edilmesi Proje Yönetim Birimi: Proje yönetiminden en üst düzeyde sorumlu birim.proje boyutuna göre bir yada daha çok yöneticiden oluşur. Kalite Yönetim Birimi: Projenin amacına uygunluğunu üretim süreci boyunca denetler ve onaylar Proje Ofisi: Her türlü yönetimsel işlerden (yazışma, personel izleme) sorumlu birimdir. 12

13 Yüklenici Proje Ekip Yapısı Teknik Destek Birimi: Donanım, İşletim sistemi, Veri tabanı gibi teknik destek Yazılım Üretim Eşgüdüm Birimi: Yazılım Üretim Ekiplerinden oluşur(4-7 kişilik sayı fazla artmaz). Eğer birden fazla yazılım Üretim Ekibi varsa Ortak uygulama yazılım parçalarının geliştirilmesinden sorumlu Yazılım Destek Ekibi de olur. Eğitim Birimi: Proje ile ilgili her türlü eğitimden sorumludur. Uygulama Destek Birimi: Uygulama anında destek. (mesela telefonla) İş Sahibi Proje Ekip Yapısı Proje Eşgüdüm Birimi Kalite Yönetim Birimi Proje Ofisi Teknik Altyapı izleme birimi Yazılım Üretim İzleme Birimi Eğitim İzleme Birimi Kullanıcı Eşgüdüm Birimi Kaynakçalar serhatkilicarslan.com ( Slides için teşekkür ederiz.) M. Erhan Sarıdoğan, PhD. Yazılım Mühendisliği Roger S. Pressman, Software Engineering A Practitioner s Approach 13