ANALİZ.

... konulu sunumlar: "ANALİZ."— Sunum transkripti:

1 ANALİZ

2 İçerik Yazılım İster (Gereksinim) Analizi İster Nedir? İster Türleri
Alan İşlevsel, işlevsel olmayan Sistem, Kullanıcı Diğer İster Çözümleme Aşamaları İster Çözümleme Yöntemleri Doğal Dil Yapısal Doğal Dil Formlar, şablonlar aracılığı ile ifade Grafiksel Gösterim Veri Akış Şemaları UML diyagramları (Kullanım senaryoları-Use Case Sıralı-sequential ) diyagram gibi Geçerleme,Gözden Geçirme Sonuç: The software requirements document (Yazılım İster (Gereksinim) Dökümanı)

3 Yazılım İsterleri Çözümlemesi
 Bir bilgisayar programının başarısı öncelikle müşteri isteklerini tam olarak karşılamasına bağlıdır.  Yazılım isterleri çözümleme aşaması  Müşterinin yazılımdan bekledikleri belirlenir  Gereksinimler açıklığa kavuşturulur  Yazılım isterleri modellenir ve tanımlanır  Böylece de sonraki aşamalar için temel oluşturulur.

4 İster  Kullanıcı ve sistem isterleri nelerdir?
 İster nedir?  İster çeşitleri  Kullanıcı ve sistem isterleri nelerdir?  İşlevsel (functional) ve işlevsel-olmayan (non-functional) isterler nelerdir?

5 İster nedir?  İster (gereksinim): gerekli olan, istenen veya ihtiyaç duyulan.*  IEEE 729  Kullanıcı tarafından bir problemi çözme ya da bir hedefi gerçekleştirmek için ihtiyaç duyulan durum ya da yetenek * ** Pressman, R. Software Engineering: A Practitioner’s approach

6 İster mühendisliği nedir?
 Tüm bu hizmet ve kısıtlamaların  belirlenmesi  çözümlenmesi  belgelendirilmesi  ve kontrol edilmesi sürecine İster (Gereksinim) Mühendisliği denir

7 İsterler neden önemlidir?
 İsterlerden kaynaklı hatalar geç aşamalarda fark edilir  Genellikle yanlış bilgi, ihmal ve tutarsızlık kaynaklıdır  Bu durumda da düzeltilme maliyetleri yüksek olur

8 İster Türleri Görevlerine Göre İşlevsel (Functional) İşlevsel Olmayan (Nonfunctional) Detay Seviyesine Göre Kullanıcı Sistem Alan İsterleri Diğer İsterler?? İsterleri farklı detay seviyelerinde yazmak gereklidir çünkü farklı okuyucular onları farklı şekillerde kullanacaklardır

9 Kullanıcı İsterleri  İşlevsel ve işlevsel olmayan gereksinimleri tanımlamalı, böylece detaylı teknik bilgiye sahip olmayan sistemin kullanıcıları tarafından da anlaşılabilmelidir.  Kullanıcı isterleri, doğal dil, basit tablo ve formlar ve şemalar ile tanımlanır.  Sadece sistemin harici davranışlarını belirtmeli ve mümkün olduğunca tasarım özelliklerine girmekten kaçınmalıdır.  Çoğunlukla, teknik-olmayan okuyucular tarafından okunurlar

10 Sistem İsterleri  Kullanıcı isterlerinin daha detaylı belirtimidir  Sistemi tasarlamak için temel oluşturur.  İdeal olarak, basitçe, harici davranış ve kısıtlamaları tanımlar. Tasarım ve uygulama ile ilgilenmemelidir.  Fakat pratikte, tasarım bilgisi bulundurabilir.  İster belirtimine yardımcı olabilmek için bir başlangıç mimarisi tasarlanabilir  tasarımda yeniden kullanılabilir  Başka var olan sistemlerle arayüzü bulunabilir  tasarıma kısıt getirir  İşlevsel olmayan isterlere özel bir mimariye karar verilebilir  tasarıma kısıt getirir.

11 Uygulama Alanı isterleri
İşlevsel veya işlevsel olmayan?? Her ikisi de olabilir. Alana özel gereksinimler, sistemin çalışacağı ortam. Kullanım ortamında gözlem yapılarak nelere gereksinim duyulduğu ve işin kapsamı belirlenir. Benzer ürünler incelenir, onlardan temel isterler çıkarılır. Gerekirse bu bilgiler bir kapsam tanımlama belgesinde toplanır

12 Uygulama Alanı isterleri
Mevcut gereksinimleri yeni fonksiyonel gereksinimleri, kısıtlamalar ekleyebilir Bu gereksinimler yerine getirilmezse sistem çalışamaz. Kütüphane sistemi uygulama alanı isterleri: Z39.50 standardı esas alınacaktır tüm veritabanları için standart bir kullanıcı arayüzü olacaktır. Telif kısıtlamalarıdan dolayı, bazı belgeleri ulaştığında hemen silinmelidir.Kullanıcı gereksinimlerine bağlı olarak, bu belgeler ya elle kullanıcıya yönlendirme veya bir ağ yazıcısı yönlendirilirilerek sistem sunucusu üzerinde yerel olarak basılacaktır. Tren sinyalizasyon sistemi Trenin yavaşlama gibi hesaplanacaktır: Dtrain = Dcontrol + Dgradient

13 İşlevsel isterler

14 İşlevsel-olmayan isterler

15 İşlevsel-olmayan ister çeşitleri
olmayan İsterler Ürün Kurum isterleri Harici isterler isterleri Kullanıla Verim Güven Taşına Teslim Gerçek bilirlik leştirim Standart Birlikte Etik Yasal bilirlik lilik ilirlik lar işlerlik İsterler isterler Performans isterleri Gizlilik isterleri Alan isterleri Güvenlik isterleri

16 İşlevsel-olmayan ister örnekleri
 İşlevsel olmayan isterler diğer işlevsel olmayan ya da işlevsel isterler ile çakışabilir ya da etkileşebilir.  Örn.  Sistem tarafından kullanılacak maksimum hafiza 4 MB den fazla olmayacak.  Sistem ADA kullanılarak yazılacak. Ada programını istenen 4MB den düşük hafıza isteri ile derlemek mümkün olmayabilir.  Başka bir geliştirme dili seçimi  Hafızayı arttırma

17 İşlevsel-olmayan isterlerin ölçümü
 Doğruluğunu sınamak zordur: Kullanılabilecek olası ölçüm yolları (metric) vardır.  Ama bazılarını belirlemek zordur: bakım gibi  Mümkün olduğunca doğruluğu sınanabilecek işlevsel- olmayan ister yazmaya çalışmalısınız

18 İşlevsel-olmayan ister ölçütleri (metrics)
 Hız:  Güvenilirlik  İşlenen işlem/saniye  Ekran yenileme  Ortalama hata sayısı zamanı (MTF-Mean Time to failure)  Kullanımda olmama olasılığı  Sağlamlık  Boyut:  K bytes  Ram miktarı  Hata sonrası yeniden başlatma zamanı  Kullanım kolaylığı  Gerekli eğitim süresi  Hataya neden olan olay yüzdesi  Yardım ekranlarının sayısı  Taşınabilirlik  Hedef sistem sayısı  Hedefe bağımlı anlatım yüzdesi

19

20 İşlevsel-olmayan ister örnekleri
 Sistem, deneyimli bir kontrolör tarafından kolayca kullanılmalı ve kullanıcı hataları en aza indirilecek şekilde organize edilmelidir.  Doğruluğu sınanabilecek şekilde yeniden yaz:  Deneyimli kontrolörler sistem fonksiyonlarını 2 saatlik bir eğitim sonrasında kolaylıkla kullanabileceklerdir. Bu eğitimden sonra, deneyimli kullanıcıların ortalama hata yapma oranı günde 2 defayı geçmeyecektir.

21 İşlevsel ve işlevsel-olmayan isterlerin ilgisi
 Örn. Güvenlik ile ilgili bir işlevsel olmayan kullanıcı isterleri bir takım işlevsel isterlerin oluşmasına neden olabilir  Kimlik denetleme özelliği: oturum yönetimi, cookie, vb  Kimlik denetleme işlevi hem işlevsel hem işlevsel-olmayan istere örnektir.  Her iki çeşit ister arasında net bir ayrım yoktur.

22 Diğer İsterler Davranış şeklinde ifade edilemeyen isterlerdir. (non-behavioral requirements) Arayüz İsterleri (Interface Requirements) Kullanıcı Arayüzleri Yazılım Arayüzleri Donanınım Arayüzleri İletişim Arayüzleri

23 Kullanıcı Arayüzü Yazılım ürünü ile kullanıcısı arasındaki her bir arayüzün mantıksal özellikleri açıklanmalıdır. Bu özellikler, yazılım ihtiyaçlarının giderilmesine yönelik olan ekranformatları, pencere görünümleri, menü ya da rapor içerikleri, programlanabilir fonksiyon tusları gibi konfigürasyon özellikleridir. Ayrıca arayüzler ile sistemin kendisini kullananlara nasıl görünmesi gerektigi de tarif edilmelidir.

24 Yazılım Arayüzleri Diger gerekli yazılım ürünlerinin kullanımı ve ürünün yazılımlar ile olan arayüzleri burada ortaya konmalıdır. Gerekli her bir yazılım ürünü için, isim, spesifikasyon numarası, versiyon ve kaynak belirtilmelidir. Tanımlanan her bir arayüz, mesaj içerigi ve format yönünden açıklanmalıdır.

25 Donanım Arayüzleri İletişim Arayüzleri
Burada yazılım ürünü ile donanım bilesenleri arasındaki her bir arayüzün mantıksal özellikleri verilmelidir. Bunun yanında örnek olarak; hangi cihazların desteklenecegi, nasıl ve hangi protokollerle desteklenecegi gibi noktalar da belirtilmelidir. İletişim Arayüzleri Yerel ag protokolleri..vs gibi iletisim arayüzleri burada açıklanmalıdır.

26 İçerik Yazılım İster (Gereksinim) Analizi İster Nedir? İster Türleri
Alan İşlevsel, işlevsel olmayan Sistem, Kullanıcı Diğer İster Çözümleme Aşamaları İster Çözümleme Yöntemleri Doğal Dil Yapısal Doğal Dil Formlar, şablonlar aracılığı ile ifade Grafiksel Gösterim Veri Akış Şemaları UML diyagramları (Kullanım senaryoları-Use Case Sıralı-sequential ) diyagram gibi Geçerleme,Gözden Geçirme Sonuç: The software requirements document (Yazılım İster (Gereksinim) Dökümanı)

27 İster çözümleme aşamaları
 Çözümleyici (Analyst): Yeterli deneyime sahip yazılım isteri çözümlemesi yapan kişi  Çözümleme çalışmaları beş başlık altında incelenebilir:  Problemin anlaşılması  Problemin çözümlenmesi  Modelleme  Belirtim  Gözden geçirme

28 İsterlerin değişmesi  İsterlerin çözümlenmesi ne kadar iyi yapılırsa yapılsın, süreç sırasında da isterlerde değişiklik meydana gelebilir:  Müşteri ve geliştirici arasındaki iletişimin yeterli olmaması  Bu aşamaya çabuk geçebilmek için bazı varsayım ya da kabullenmeler yapılmış olması  Müşterinin ne istediğini tam bilememesi ve sık sık fikir değiştirmesi  Geliştiricinin deneyim eksikliği  Ayrıntılı tasarıma geçilince yeni isterlerin gerekliliğinin ortaya çıkması

29 İsterlerin Belirlenmesi
 Sistemin başarısı, sistemden ne istendiğinin doğru olarak algılanmasına bağlıdır  Bunun için düzeylere ayrılmış sistem isterlerinden Yazılım İsterleri belirtimi (SRS) çıkartılmalıdır. 

30 İçerik Yazılım İster (Gereksinim) Analizi İster Nedir? İster Türleri
Alan İşlevsel, işlevsel olmayan Sistem, Kullanıcı Diğer İster Çözümleme Aşamaları İster Çözümleme Yöntemleri Doğal Dil Yapısal Doğal Dil Formlar, şablonlar aracılığı ile ifade Grafiksel Gösterim Veri Akış Şemaları UML diyagramları (Kullanım senaryoları-Use Case Sıralı-sequential ) diyagram gibi Geçerleme,Gözden Geçirme Sonuç: The software requirements document (Yazılım İster (Gereksinim) Dökümanı)

31 Gereksinim Çıkarma ve Analizi – Zorluklar
Yazılım gelistirme çalısmalarının ön asamaları Kimse birbirini tanımıyor, sistemi bilmiyor Yöntem, teknoloji, vb. yeni olabilir Kullanıcı odaklı problemler yasanabilir. Kullanıcılar ne istediklerini bilmeyebilir. Kullanıcılar isteklerini kendi terimleriyle ifade edebilir. Farklı kullanıcıların çelisen istekleri olabilir. Farklı grupların beraber çalısmasını gerektiriyor. Kullanıcı grupları, analiz uzmanları, mimari/tasarım uzmanları Kurumsal ve politik etkenler sistem gereksinimlerini etkileyebilir. Analiz boyunca gereksinimler degisebilir; yeni kullanıcılar çıkabilir ve is ortamı degisebilir.

32 Gereksinim Geçerleme Gereksinimlerin müsterinin istedigi sistemi tanımladıgını güvence altına almayı hedefler. Gereksinimlerden kaynaklanan bir hatayı sonradan düzeltmenin maliyeti yüksek oldugundan, geçerleme büyük önem tasır. Gereksinim geçerleme teknikleri: Gözden geçirme – gereksinimlerin sistematik ve paydaslara dayalı analizi Prototip olusturma – sistemin çalısan bir taslagı üzerinden kontrol Test durumu gelistirme – sistemin test edilebilirligini kontrol amacıya gereksinimler için test durumu gelistirme

33 Gözden Geçirme Gözden geçirme çalısmalarında hedefimiz, yazılım gereksinimlerinin asagıdaki özellikleri tasıdıgından emin olmaktır: Tam ve dogru Anlasılabilir Tutarlı Test edilebilir Diger belgelerde tanımlanan is/kullanıcı/sistem gereksinimlerine izlenebilir

34 Gereksinimler ve Tasarım
Gereksinimler, sistemin “ne” yapacagını tanımlar. Tasarım, sistemin tanımlanan gereksinimlerinin “nasıl” gerçeklestirilecegini belirtir. Pratikte, gereksinimler ve tasarım her zaman net olarak ayrılamayabilir. Sistem mimarisi, gereksinimleri yapısallastırmak için tasarlanır. Sistem islevleri, tasarımı kısıtlayan diger sistemlerle iliski içinde gerçeklestiriliyor olabilir. Müsteri tarafından, sistemin özel bir tasarıma uyması isteniyor olabilir. Gereksinimlerin türlerine göre ayrı baslıklar altında tanımlanması, bu karısıklıgı azaltacaktır.

35 Doğal Dil İle İlgili Problemler
Muglaklık (“Ambiguity”) Gereksinimler, okuyan herkes tarafından aynı yorumlanacak sekilde yazılmalıdır. Dogal dil muglak ifadelere açıktır. Asırı esneklik (“Over-flexibility”) Bir gereksinim, dogal dil ile çok farklı sekillerde ifade edilebilir. Modülerligin olmayısı (“Lack of modularisation”) Dogal dilin ögeleri, sistem gereksinimlerini yapısallastırmak için yetersiz kalmaktadır. Bu problemlere ragmen dogal dilin kullanılması, müsteri ve gelistirici arasındaki iletisim açısında önem tasımaktadır.

36 Doğal Dile Alternatifler
Yapısal Doğal Dil Formlar, şablonlar aracılığı ile ifade Grafiksel Gösterim VAD UML diyagramları (Kullanım senaryoları-Use Case Sıralı-sequential ) diyagram gibi

37 Yapısal Dogal Dil – Örnek: Form Esaslı Tanımlama

38 Çizelge şeklinde gösterim

39 Analysis Model - UML Function Data Behavior Class diagram
Object State-chart diagram Interaction diagram Class diagram Object diagram Use case diagram Activity diagram Data Behavior Function

40 Unified Modeling Language (UML)
Yazılım sistemlerinin modellemesi için geliştirilmiş standart bir dildir Yazılım is ürünlerinin; tanımlanması, görsel hale getirilmesi, belgelendirilmesi Açık standarttır; birçok araç tarafından desteklenir Tüm yazılım geliştirme sürecini destekler Çıkış hedefleri: Kullanımı kolay, görsel bir modelleme dili sunmak Programlama dillerinden ve geliştirme sürecinden bağımsız olmak En iyi yöntemleri bütünleştirmek

41 Unified Modeling Language (UML)
Sundukları: Yazılım ürünlerinin gösterimi için yapı tasları ve ilişkiler Sunmadıkları: Sisteminin nasıl gelistirilmesi gerektigini tanımlamaz Nesne yönelimli yazılım modellemesi için yapılar sunar, ancak; Bu yapıların hangi sıra ile kullanılması gerektigini tanımlamaz Yapıların gelistirme sürecinin hangi asamalarında kullanılması gerektigini tanımlamaz

42 UML Türleri

43 UML Türleri Use case diyagramı:       Aktörler ve use case’ler arasındaki ilişkiyi gösterir. Etkinlik (Activity) diyagram:        Çoğu durumun eylem durumu olduğu ve geçişlerin bir durumdaki eylemin sonuçlanması ile tetiklendiği özel bir durum diyagramı türüdür. Bu diyagram daha çok iç işlemler esnasındaki akışı gösterir.

44 Sıralı Diyagramlar (Sequence diagrams)

45 Use Case Elemanları Aktör: Sistemin kullanıcıları
Use-case: Sistemin destekleyeceği isler

46 Use Case Elemanları . "uses" ilişkisi ana use case in bir alt kümesidir, “extends" ilişkisi ise ana use case den farklı özellikleri (alternatif seçenekleri) olan bir use case ile ilişkilendirilir.

47

48

49

50

51

52 Gereksinim Analizinde Use Case
Bakıs açısı: Sistem, kullanıcısı için “ne” yapacak ? Sistem kapalı bir kutu (“black-box”) Sistem-kullanıcı etkilesimi Sistemin dısarıdan görünen davranısı Ilgilenmediklerimiz: Sistemin iç yapısı Sistem belirlenen davranısı “nasıl” yapacak ? Belirlenen davranıs “nasıl” kodlanacak ? Bu bakıs açısı, sistemdeki tüm islevselligi degil, kullanıcılar için artı deger olusturacak islemleri düsünmemizi saglar

53 Gereksinim Analizinde Use Case
Kullanıcının gereksinimi olmayan özellikleri tanımlamamızı engeller Kullanıcının da anlayabilecegi sekilde sistemin davranıslarını ve sorumluluklarını tanımlar Kullanıcı ile iletisimi kolaylastırır Kullanıcı arayüzlerinin tasarlanmasını kolaylastırır Kullanıcı kılavuzlarını yazarken baslangıç noktasını olusturur Gelistirme sürecini baslatır ve tüm temel is adımlarını birbirine baglar Tasarlanacak test durumlarına esas olusturur

54 Aktivite Diyagramları
Genel olarak bir akısı veya islemi göstermek için kullanılırlar. (“flowchart” benzeri bir yapı) Activity diyagramın içerisinde Etkinlik (“activity”) Sistem ve aktörler tarafından yapılan isleri ifade etmek için kullanılır Geçis (“transition”) Etkinlikler arasındaki geçisleri ifade etmek için kullanılır

55 ATM Aktivite Diyagramı