1

BIL 304 YAZILIM MÜHENDİSLİĞİ

2012-2013

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.

V Süreç Modeli

KULLANICI MODELİ Sistem Tanımları

Bitmiş Sistem

MİMARİ MODEL Sistem Sınanmış Sistem

Altsistem Sınanmış Altsistem

GERÇEKLEŞTİRİM MODELİ

Modül Sınanmış Modül

Gereksinimler

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

Risk Analizi

Risk Analizi

Risk Analizi

Risk Analizi

Proto- tip 1

Prototip 2 Prototip 3

İşin Prototipi

Öninceleme Analizi

İşin Genel Kavramı

Geliştirme Planı

Birleştirme ve Test Planı

Yazılım Gereksinimi

Gereksinim onaylama

Ürün Tasarımı

Tasarımı test Etme ve onay

Detaylı Tasarım

Kodlama

Modül Testi Birleştirme testi

Kabul testi Servis

Simulasyon ve Modelleme

Amaca, Alternatiflere ve Sınırlamalara karar verme

Alternatifleri değerlendirme ve risk

analizi

Bir sonraki fazın planlanması ve kullanıcı değerlendirmesi

Geliştirme ve bir sonraki ürünü onaylama

onay ekseni

Planlama Risk Analizi

Üretim Kullanıcı Değerlendirme

Helezonik Model 1. Planlama

Ü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

Risk seçeneklerinin araştırılması ve risklerin belirlenmesi

3. Üretim

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

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.

Eşzamanlı Aktiviteler

Tanımlama

İlk Sürüm

Genel Tanımlama

Son Sürüm

Geliştirme

Test Etme

Ara Sürümler

Evrimsel Geliştirme Süreç Modeli

Ö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

3

• Ü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 Artırımsal Geliştirme Süreç Modeli

Genel Gereksinim Belirlenmesi

Gereksinimleri Artırımlara

Bölme

Sistem Mimarisini Tanımlama

Sistem Artırılımının Yapılması

Artırılımın Onaylanması

Artırılımın Birleştirilmesi

Sistemin Onaylanması

Son Sistem

Bitmemiş 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

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.

Yourdon Yapısal Sistem Tasarım Yöntemi

Aşama Kullanılan Yöntem

ve Araçlar

Ne için

Kullanıldığı

Çıktı

Planlama Veri Akış Şemaları,

Süreç Belirtimleri,

Görüşme,

Maliyet Kestirim Yöntemi,

Proje Yönetim Araçları

Süreç İnceleme

Kaynak Kestirimi

Proje Yönetimi

Proje Planı

Analiz

Veri Akış Şemaları,

Süreç Belirtimleri,

Görüşme,

Nesne ilişki şemaları

Veri

Süreç Analizi

Veri Analizi

Sistem Analiz

Raporu

Analizden

Tasarıma Geçiş

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

Başlangıç Tasarımı

Ayrıntılı Tasarım

Başlangıç Veri

tasarımı

Başlangıç Tasarım

Raporu

Tasarım Yapısal Şemalar,

Program Tasarım Dili,

Veri Tabanı Tabloları

Genel Tasarım

Ayrıntılı Tasarım

Veri Tasarımı

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 Donanım Mühendisi

Web Tasarımcısı Ağ Uzmanı

Sistem Tasarımcısı Yazılım Destek Elemanı

Programcı Donanım Destek Elemanı

Sistem Yöneticisi Eğitmen

Veri Tabanı Yöneticisi Denetleyici

Kalite Sağlama Yöneticisi Çağrı Merkezi Elemanı

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

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

Proje Maliyetleri

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?

7

İşlev Puanı (Function Points-FP)

• 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ı (Function Points) (devam…)

İşlev Puanı

LOC’a dönüştürme

SLOC FP

•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

İşlev Puanını, LOC’a dönüştürmek için

programlama diline göre saptanan faktörler

kullanılır.

Teknik Karmaşıklık Faktörleriyle ayarlama

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

Ölçüm Parametresi Sayı Ağırlık Faktörü

Yalın Ortalama Karmaşık

1-Kullanıcı Girdi sayısı ? 3 4 6 =

2-Kullanıcı Çıktı sayısı ? 4 5 7 =

3-Kullanıcı Sorgu Sayısı ? 3 4 6 =

4-Kütük Sayısı ? 7 10 15 =

5-Dışsal Arayüz Sayısı ? 5 7 10 =

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.

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)

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

Genel S istem Özellikleri Kısa Açıklama

1 Veri İletişimleri 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 Hedefler, yanıtlama zamanı ve iş çıkarma performansı önemli

midir?

4 Çok Kullanılan Konfigürasyon Uygulamanın idare edileceği mevcut donanım platformu ne

kadar yoğun kullanılmaktadır?

5 İşlem Oranı İşlem oranı yüksek midir?

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 Yedekleme, başlatma ve kurtarma gibi operasyonlar ne kadar

otomatiktir?

13 Çoklu Saha Kullanımı Uygulama çoklu örgüte sahip çoklu sahalar için özellikle mi

tasarlanmış, geliştirilmiş ve desteklenmiştir?

14 Değişimi Kolaylaştırma

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?

• 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=1.. 14 Cevapi

TCF: Technical Complexity Factors Teknik Karmaşıklık Faktörler

DI: Total Degree of Influence - Etki Toplam Derecesi

TCF = 0,65 + 0,01 x DI

Satır Sayısı Kestirimi

Assembly 300

Cobol 100

Fortran 100

Pascal 90

C 90

Ada 70

Nesne Kökenli Diller 30

4. 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ı 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ı

İş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

Stok Takip Sistemi

Login Bilgileri (Basit)

Arama Bilgileri Giriş

(Orta)

Stok Girişi(Orta)

Arama Listesi (Orta)

Listeleme Raporlama(Orta)

Personel Verileri (Basit)

İç Dosyalar

Kategori Bilgisi (Basit)

Stok Listesi(Orta)

Personel Eşleştirme (Karışık)

Personel Demirbaş

Dosyası(Orta)

Dış Arayüz

Örnek Proje – Düzeltilmemiş İşlev Puanı

Girdiler: 2 Basit

2 Orta

Çıktılar: 3 Orta

1 Karmaşık

İç Dosyalar : 1 Orta Personel Demirbaş Dosyası

Dış Arayüz Dosyaları: 1 Orta Personel Listesi

Basit Orta Karmaşık

(1) Dış Girdiler 3 5 6

(2) Dış Çıktılar 4 6 7

(3) Dış Sorgular 3 5 6

(4) İç Dosyalar 7 13 15

(5) Dış Arayüz Dosyaları 5 9 10

UFP = [(2*3) + (2*5)] + [(3*6) + (1*7)] + [1*13] + [1*5] = 59

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)]

Ö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ı? 1

10. Kod yeniden kullanabilir olarak mı tasarlanmış? 3

11. İç süreç karmaşık mı? 2

12. Dönüşüm ve kurulum tasarım içerisinde mi? 1

13. Uygulama değişik kuruluşlarda birden fazla kurulum gerektirecek şekilde mi

tasarlanmış? 1

14. Uygulama kullanıcı tarafından kolaylıkla kullanmayı ve değiştirmek üzere mi

tasarlanmış? 5

DI = i=1.. 14 Cevapi = 34

FP = UFP x (0,65 + 0,01 x DI) = 144 x (0, 65 + 0,01 x 34) = 58.41

LOC = 46 x 169.92 = 1401,84 satırsayısı

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ı(İN) 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

COCOMO Modeli

COCOMO Modeli

Satır Sayısı

İş 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ı

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*Sb

• Zaman (T) T=c*Kd

a,b,c,d : her bir model için farklı katsayılar

S : bin türünden satır sayısı

Proje Sınıfları • Ayrık Projeler:

– 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

Temel Model • Ayrık Projeler

– İş Gücü K=2.4*S1,05

– Zaman T=2.5*K0,38

• Yarı Gömülü Projeler – İş Gücü K=3,0*S1,12

– Zaman T=2.5*K0,35

• Gömülü Projeler – İş Gücü K=3,6*S1,20

– Zaman T=2.5*K0,32

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*S1,05

• Yarı Gömülü Projeler K=3,0*S1,12

• Gömülü Projeler K=2.8*S1,20

Maliyet Çarpanı Hesaplama

• Maliyet Çarpanı 15 maliyet etmeninin çarpımı sonucudur.

C= C1*C2*C3*...*C15

Maliyet Etmenleri Maliyet etmeni

Seçenekler

Çok

Düşük Düşük Normal Yüksek

Çok

Yüksek

Oldukça

Yüksek

Ürün Özellikleri

RELY 0,75 0,88 1,00 1,15 1,40 -

DATA - 0,94 1,00 1,08 1,16 -

CPLX 0,70 0,85 1,00 1,15 1,30 1,65

Bilgisayar Özellikleri

TIME - - 1,00 1,11 1,30 1,66

STOR - - 1,00 1,06 1,21 1,56

VIRT - 0,87 1,00 1,15 1,30 -

TURN - 0,87 1,00 1,07 1,15 -

Personel Özellikleri

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,90 - -

LEXP 1,14 1,07 1,00 0,95 - -

Proje Özellikleri

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.

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.

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