Sunum yükleniyor. Lütfen bekleyiniz

Sunum yükleniyor. Lütfen bekleyiniz

YAZILIM MÜHENDİSLİĞİ- ANALİZ. İçerik Yazılım İster (Gereksinim) Analizi İster Nedir? İster Türleri Alan İşlevsel, işlevsel olmayan Sistem, Kullanıcı Diğer.

Benzer bir sunumlar


... konulu sunumlar: "YAZILIM MÜHENDİSLİĞİ- ANALİZ. İçerik Yazılım İster (Gereksinim) Analizi İster Nedir? İster Türleri Alan İşlevsel, işlevsel olmayan Sistem, Kullanıcı Diğer."— Sunum transkripti:

1 YAZILIM MÜHENDİSLİĞİ- 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

14 Definitions and specifications

15 İşlevsel isterler

16 İşlevsel-olmayan isterler

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

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

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

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

21

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

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

24 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

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

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

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

28 İç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ı)

29 İster çözümleme aşamaları  Çözümleyici (Analyst): Yeteri 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

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

31 İ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. 

32 İç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ı)

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

34 Gereksinim Geçerleme Gereksinimlerin müsterinin istedigi sistemi tanımladıgını güvence altınaalmayı 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

35 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

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

37 Doğal Dile İ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.

38 Gereksinimleri Yazmak İçin Öneriler:Doğal Dil Kullanımı İçin Standart bir biçim belirleyerek gereksinimleri tanımlarken kullanın. Her gereksinime bir numara verin. Dogal dili tutarlı olarak kullanın. Zorunlu ve seçimli gereksinimleri farklı kalıplarla ifade edin. Gereksinimlerin önemli kısımlarını ayırt etmek için farklı yazı tipi (büyük harf, alt çizme, farklı renk, vb.) kullanın. Bilgisayar terimlerini kullanmaktan kaçının.

39 Gereksinimlerin Bulanıklıgı Gereksinimler net olarak ifade edilmedigi zaman problemler yasanır. Bulanık gereksinimler gelistiriciler ve kullanıcılar tarafından farklı algılanabilir. Örnek: “Sistem, kullanıcının doküman ambarındaki dokümanları okuması için, uygun görüntüleyiciler saglamalıdır.” “uygun görüntüleyiciler”: Kullanıcı yorumu : her farklı doküman tipi için farklı kullanıcı Gelistirici yorumu : her dokümanın içerigini gösteren bir metin görüntüleyici

40 Gereksinimlerin Tamlığı ve Tutarlılıgı Gereksinimler tam ve birbiriyle tutarlı olarak ifade edilmelidir. Tamlık : Sistemin beklenen tüm özellikleri tanımlanmalıdır. Tutarlılık: Sistemin tanımlanan özellikleri arasında çeliskiler bulunmamalıdır. Pratikte, dogal dilden kaynaklanan zorluklar sebebiyle, gereksinimleri tam ve tutarlı olarak ifade etmek çok kolay degildir. Tanımlanan gereksinimlerin ilgili tüm kisilerce gözden geçirilmesi, tamlıgı ve tutarlılıgı büyük ölçüde saglamanın en basit yoludur. VAD kullanılması durumunda aşağıdaki gibi kriterler denetlenmelidir Bütün süreçlerin girdi ve çıktıları var mı? Süreçler, veri akışları, dış birim ve veri depoları uygun şekilde adlandırılıp numaralandırılmış mı? Planlama aşamasında öngörülen belirtimlerin hepsi ele alınmış mı?

41 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

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

43 Çizelge şeklinde gösterim

44 VAD- Veri Akış Diyagramı  Sistem içinde her verinin nasıl taşındı ğ ı ve bu veri akışını sa ğ layan fonksiyonların (işlevlerin) neler oldu ğ u veri akış diyagramında (VAD-DFD) tarif edilir.  Sistemin varlıkları  Süreçleri  Sistemdeki veri depoları  Ve bunlar arasındaki verinin nasıl aktı ğ ını gösterir

45 VAD- Veri Akış Diyagramı  Bilgi bilgisayar sistemi içerisinde akarken dönüşür  Sistem çeşitli formlarda girdi alır ve bu girdileri yazılım, donanım ve insan elemanları ile işleyerek çeşitli formdaki çıktılara dönüştürür.  VAD verinin girişten çıkışa dek olan dönüşümü ve bilginin taşınmasını gösteren grafiksel bir tekniktir.

46 VAD simgeleri AnlamSimge - 1Simge - 2Örnek Dış varlık Öğrenci İşlem (süreç) Veri akışı Veri deposu

47 VAD Kuralları İşlemin sadece çıkışı olamaz. İşlemin sadece girişi olamaz. İşlem girişleri istenen çıkışı verecek kadar yeterli olmalıdır.

48 VAD Kuralları Her veri deposu bir işlemle ilgili olmalıdır Veri deposu bir varlıkla doğrudan ilişkide olamaz Veri akış oku çift yönlü olamaz. Bir işlemle veri deposu arasında karşılıklı veri akışı varsa farklı tek yönlü oklarla gösterilmelidir.

49 VAD Kuralları Bir işlemden farklı iki işleme gidecek olan aynı veri, aynı yönde iki uçlu okla gösterilmelidir. Veri hiçbir işlemden geçmeden çıktığı işleme doğrudan dönmez Veri akış okları üzerinde gösterilen veri, sadece isim formatında olmalıdır

50 VAD Düzeyleri  VAD bir sistemi ya da yazılımı herhangi bir soyutlama düzeyinde göstermek için kullanılabilir.  VAD artan bilgi akışı ve işlevsel detayları içerecek şekilde çeşitli seviyelere bölünebilir.  Seviye 0 olarak gösterilen VAD aynı zamanda kapsam diyagramı (temel sistem modeli) olarak da adlandırılır:Tüm sistem tek bir balon içerisinde gösterilerek girdi ve çıktılargelen ve çıkan oklar ile ifade edilirler.

51 VAD Düzeyleri  Seviye0olan VAD daha detaylı bilgi akışı ve süreçleri içerecek şekilde ek süreçlere(balonlara) ayrılır.  Seviye 1 VAD 5 ya da 6 süreç(balon) ve bunlar arasındaki akışları gösterir.  Seviye 1 de gösterilen süreçler kapsam modelinde yer alan ana sistemin alt fonksiyonlarını içerir.

52 VAD Örneği  Seviye 0 Diyagram

53 VAD Örneği  Seviye 1 Diyagram

54 VAD Örneği  Süreç 2.0 için Seviye 2 Diyagram

55 VAD çizim yöntemi  Süreç hikayesi gramer olarak ayrıştırılır. (tüm isim ve fiiller ayrıştırılır)  Eş anlamlı olan isim ve fiiller atılır.  Gramatik ayrıştırmaya dayalı olarak bir model çıkmaya başlar:  Tüm fiiller sistem süreçleridir: VAD içerisinde balonlar içerisinde yer alır  Tüm isimler harici varlıklar, veri ö ğ esi ya da veri deposudur.  Seviye 0 VAD çizilir  Seviye 0 Seviye 1 modele detaylandırılır daha sonra da Seviye 1’deki süreçler Seviye 2 olarak detaylandırılırlar

56 Software Engineering Lab., FCU 56 Analysis Model - UML Data Behavior Function Object State-chart diagram Interaction diagram Class diagram Object diagram Use case diagram Activity diagram

57 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 57

58 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 58

59 UML Türleri

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

61 Sıralı Diyagramlar (Sequence diagrams)

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

63 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. Include” ilişkisi ise bir “use-case”in digerinin davranısını içermesi 63

64 64

65 65

66 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 66

67 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 67

68 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 68

69 ATM Aktivite Diyagramı 69


"YAZILIM MÜHENDİSLİĞİ- ANALİZ. İçerik Yazılım İster (Gereksinim) Analizi İster Nedir? İster Türleri Alan İşlevsel, işlevsel olmayan Sistem, Kullanıcı Diğer." indir ppt

Benzer bir sunumlar


Google Reklamları