Sunum yükleniyor. Lütfen bekleyiniz

Sunum yükleniyor. Lütfen bekleyiniz

ANALİZ. İç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ı.

Benzer bir sunumlar


... konulu sunumlar: "ANALİZ. İç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ı."— 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  İ 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 İşlevsel- olmayan İsterler Ürün isterleri KullanılaVerimGüven bilirliklilikilirlik Performans isterleri Alan isterleri Kurum isterleri TaşınaTeslimGerçek bilirlikleştirim StandartBirlikte larişlerlik Harici isterler EtikYasal İsterleristerler Gizlilik 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ı istenen4MB 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:  İ şlenen işlem/saniye  Ekran yenileme  Boyut:  K bytes  Ram miktarı  Kullanım kolaylı ğ ı  Gerekli e ğ itim süresi  Yardım ekranlarının sayısı  Taşınabilirlik  Hedef sistem sayısı  Hedefe ba ğ ımlı anlatım yüzdesi  Güvenilirlik  Ortalama hata sayısı zamanı (MTF-Mean Time to failure)  Kullanımda olmama olasılı ğ ı  Sa ğ lamlık  Hata sonrası yeniden başlatma zamanı  Hataya neden olan olay 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 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 ne Gereksinimler, sistemin “ne” yapacagını tanımlar. nasıl 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 Software Engineering Lab., FCU 39 Analysis Model - UML Data Behavior Function Object State-chart diagram Interaction diagram Class diagram Object diagram Use case diagram Activity diagram

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 40

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 41

42 UML Türleri

43 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. 43

44 Sıralı Diyagramlar (Sequence diagrams)

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

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. 46

47 47

48 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 52

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 53

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 54

55 ATM Aktivite Diyagramı 55


"ANALİZ. İç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ı." indir ppt

Benzer bir sunumlar


Google Reklamları