YAZILIM MÜHENDİSLİĞİ -ANALİZ

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 Birbilgisayarprogramınınbaşarısıönceliklemüşteriisteklerini tam olarakkarşılamasınabağlıdır. Yazılımisterleriçözümlemeaşaması Müşterininyazılımdanbekledikleribelirlenir  Gereksinimler açıklığa kavuşturulur  Yazılım isterleri modellenir ve tanımlanır Böylece de sonrakiaşamalariçintemeloluş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): gerekliolan, istenenveyaihtiyaç duyulan.*  IEEE 729 Kullanıcıtarafındanbirproblemiçözmeyadabirhedefigerçekleştirmekiçinihtiyaçduyulan durum yadayetenek * http://www.webster.com ** 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. İsterlernedenö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?? • İsterlerifarklıdetayseviyelerindeyazmakgereklidirçünküfarklıokuyucularonlarıfarklışekillerdekullanacaklardır

9. Kullanıcı İsterleri İşlevselveişlevselolmayangereksinimleritanımlamalı,böylecedetaylıteknikbilgiyesahipolmayansisteminkullanı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ünolduğunca tasarım özelliklerine girmekten kaçınmalıdır.  Çoğunlukla, teknik-olmayan okuyucular tarafından okunurlar

10. Sistem İsterleri KullanıcıisterlerinindahadetaylıbelirtimidirSistemitasarlamakiçintemeloluşturur.  İdeal olarak, basitçe, haricidavranışvekısıtlamalarıtanımlar.Tasarımveuygulamaileilgilenmemelidir.  Fakat pratikte, tasarım bilgisi bulundurabilir.  İster belirtimine yardımcı olabilmek için bir başlangıç mimarisitasarlanabilir  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 ekleyebilirBu 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

14. Definitions and specifications

15. İşlevselisterler

16. İşlevsel-olmayanisterler

17. İşlevsel-olmayan ister çeşitleri İşlevsel- olmayanİsterler Kurumisterleri Hariciisterler Ürün isterleri Taşına Teslim Gerçekbilirlik leştirim Standart Birlikte Etik Yasal KullanılaVerimGüven lar işlerlik İsterler isterler bilirlik lilik ilirlik Gizlilikisterleri Performans isterleri Alanisterleri Güvenlik isterleri

18. İşlevsel-olmayan ister örnekleri İşlevselolmayanisterlerdiğerişlevselolmayanya daişlevselisterlerileçakışabilirya da etkileşebilir.  Örn.  Sistem tarafından kullanılacak maksimum hafiza 4 MB den fazlaolmayacak.  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

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-olmayanisterö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ımkolaylığı Gereklieğitimsü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

22. İşlevsel-olmayan ister örnekleri  Sistem, deneyimli bir kontrolör tarafından kolaycakullanılmalı ve kullanıcı hataları en aza indirilecek şekilde organize edilmelidir. Doğruluğusınanabilecekşekildeyenidenyaz:  Deneyimli kontrolörler sistem fonksiyonlarını 2 saatlik bireğitim sonrasında kolaylıkla kullanabileceklerdir. Bueğitimden sonra, deneyimli kullanıcıların ortalama hatayapma oranı günde 2 defayı geçmeyecektir.

23. İşlevselveişlevsel-olmayanisterlerinilgisi  Örn. Güvenlik ile ilgili bir işlevsel olmayan kullanıcı isterleribir takım işlevsel isterlerin oluşmasına neden olabilir Kimlikdenetlemeözelliği: oturumyönetimi, cookie, vb  Kimlik denetleme işlevi hem işlevsel hem işlevsel-olmayanistere ö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 Digergerekli yazılım ürünlerinin kullanımı ve ürünün yazılımlar ile olan arayüzleriburada ortaya konmalıdır. Gerekli her bir yazılım ürünü için, isim, spesifikasyonnumarası, versiyon ve kaynak belirtilmelidir. Tanımlanan her bir arayüz, mesaj içerigive 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ünmantı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 iletisimarayü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 • 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): Yeterideneyimesahipyazılımisteriçözümlemesiyapankişi  Çözümleme çalışmaları beş başlık altındaincelenebilir:  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 dakabullenmeler 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ğruolarak algılanmasına bağlıdır  Bunun için düzeylere ayrılmış sistem isterlerindenYazı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üsterininistedigi 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 • Gereksinimler, sistemin “ne” yapacagını tanımlar. • Tasarım, sistemin tanımlanan gereksinimlerinin “nasıl” gerçeklestirileceginibelirtir. • 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 iliskiiçinde gerçeklestiriliyorolabilir. • 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 sekildeyazı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ülerliginolmayısı (“Lack of modularisation”) • Dogal dilin ögeleri, sistem gereksinimlerini yapısallastırmak için yetersiz kalmaktadır. • Bu problemlere ragmendogal dilin kullanılması, müsteri ve gelistiriciarası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 girdileriyazı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ü vebilginin taşınmasını gösteren grafiksel bir tekniktir.

46. VAD simgeleri Anlam Simge - 1 Simge - 2 Örnek Dış varlık Öğrenci İşlem (süreç) Veri akışı Veri deposu 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 birişlemle ilgili olmalıdır Veri deposu bir varlıkla doğrudan ilişkide olamaz Veri akış oku çift yönlüolamaz. Bir işlemleveri deposu arasındakarşı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öndeiki uçlu okla gösterilmelidir. Veri hiçbir işlemdengeçmeden çıktığıişleme doğrudandö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 soyutlamadü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 kapsamdiyagramı(temel sistem modeli) olarak daadlandırılır:Tüm sistem tek bir balon içerisinde gösterilerek girdi ve çıktılargelen ve çıkan oklar ile ifade edilirler.