1 Bölüm 9 İhtiyaçları Anlama (Understanding Requirements) Modified from Software Engineering: A Practitioner’s Approach by Roger S. Pressman For non-profit.

... konulu sunumlar: "1 Bölüm 9 İhtiyaçları Anlama (Understanding Requirements) Modified from Software Engineering: A Practitioner’s Approach by Roger S. Pressman For non-profit."— Sunum transkripti:

1 1 Bölüm 9 İhtiyaçları Anlama (Understanding Requirements) Modified from Software Engineering: A Practitioner’s Approach by Roger S. Pressman For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author. All copyright information MUST appear if these slides are posted on a website for student use.

2 2 İhtiyaç Mühendisliği-I Başlangıç—aşağıdakilerin anlaşılması için soruların sorulması  problemin temel olarak anlaşılması  çözüm isteyen kişi  istenen çözümün yapısı  müşteri ve geliştirici arasında etkili iletişimin ve işbirliğinin sağlanması Ortaya çıkarma/ öğreme—bütün paydaşlardan ihtiyaçları al/öğren Detaylandırma—veri, fonksiyonel ve davranışlar ihtiyaçları ortaya koyan bir analiz modeli oluştur. Müzakere /Görüşme Negotiation—müşteri ve geliştirici için gerçekçi olan teslim edilebilir sistem üzerinde anlaş.

3 3 İhtiyaç Mühendisliği-II Tanımlama /Şartname hazırlama—aşağıdakilerden herhangi birisi olabilir  yazılı bir doküman  çeşitli modeller  matematiksel ifade  çeşitli kullanıcı senaryoları (use cases)  prototip Doğrulama / Onaylama—aşağıdakileri gözden geçirme mekanizması  kapsam veya yorumlamadaki hatalar  açıklığa kavuşturulması gereken alanlar  eksik bilgi  tutarsızlıklar  çatışan veya gerçekçi olmayan ihtiyaçlar İhtiyaç Yönetimi

4 4 Başlangıç Paydaşları belirler  “başka kimle konuşmalıyım?” Farklı görişleri belirle İşbirliğini oluşturmaya çalış İlk sorular  Bu işin olmasını isteyen kim?  Çözümü kim kullanacak?  Başarılı bir çözümün ekonomik faydası ne olacak?  İhtiyacınız olan başka bir çözüm kaynağı var?

5 5 İhtiyaçların Ortaya Çıkarılması yazılım mühendisleri ve müşterilerin katıldığı ve toplantılar yapılır hazırlık ve katılım kuralları belirlenir bir ajanda önerilir bir “hakem” veya yönetici toplantıyı yönlendirir. Bu kişi müşteri, geliştirici veya dışarıdan birisi olabilir. bir tanımlama mekanizması kullanılır (çalışma tabloları, post it, elektronik ilan tablosu, chat odası veya sanal forum gibi) Amaç  problemi tanımlamak  çözüm parçalarını sunmak  farklı yaklaşımları tartışmak  ön çözüm ihtiyaçlarının belirlenmesi

6 6 İhtiyaçların Ortaya Çıkarılması

7 7 Kalite Fonksiyon Konuşlandırılma Fonksiyon konuşlandırma; sistem için gereken herbir fonksiyonun değerinin (müşteri tarafından algılanan) belirlenmesi Bilgi konuşlandırma veri nesne ve olaylarını tanımlar Görev konuşlandırma sistemin davranışını inceler Değer analizi ihtiyaçların bağıl önceliğini belirler

8 8 İş Ürünlerini Ortaya Çıkarma fizibilite ve ihtiyacın ifade edilmesi. sistem veya ürün için kasamın sınırlarının ifade edilmesi ihtiyaçların belirlenmesine katılım sağlayacak müşterilerin, kullanıcıların ve paydaşların listesi sistemin teknik ortamının tanımlanması ihtiyaç listesi ve her bir ihtiyaca uygulanacak alan şartları farklı yönetim şartlarında sistemin veya ürünün kullanımı hakkında fikir verebilecek kullanım senaryoları ihtiyaçların daha iyi tanımlanması için bir prototipin geliştirilmesi.

9 9 Analiz Modelinin İnşa Edilmesi Analiz modelinin elemanları  Senaryo-tabanlı elemanlar Fonksiyonel—yazılım fonksiyonlarının gelişen açıklaması Kullanım-durumları (Use-case)—bir aktör ve sistem arasındaki etkileşimin tanımlanması  Sınıf-tabanlı elemanlar Senaryolar tarafından ima edilen /kastedilen  Davranışsal elemanlar Durum diyagramları  Akış-yönelimli elemanlar Veri akış diyagramı

10 10 Kullanım Durumları (Use-Cases) sistemin parçalarını tanımlayan kullanıcı senaryolarının toplamıdır. Herbir senaryo bir aktörün (kullanıcı veya aygıt) Herbir senaryo aşağıdaki sorulara cevap verir:  Ana aktör, ikinci aktör kimdir?  Aktörün amacı nedir?  Hikaye başlamadan önce hangi önşartlar belli olmalıdır?  Aktör tarafından hangi ana görev ve fonksiyonlar işlenir?  Hikaye tanımlanıyorken hangi eklentiler düşünülmelidir?  Aktörün etkileşiminin türevleri nelerdir?  Aktör hangi sistem bilgisini alacak, üretecek veya değiştirecek?  Aktör, dış ortamdaki değişiklikleri sisteme bildirmek zorundamıdır?  Aktör sistemden hangi bilgileri beklemektedir.  Aktör beklenmeyen değişikliler hakkında bilgi sahibi olacak mı?

11 11 Kullanım-Durumu Diyagramı

12 12 Sınıf Diyagramı SafeHome sistemi için …

13 13 Durum Diyagramı Reading Commands System status = “ready” Display msg = “enter cmd” Display status = steady Entry/subsystems ready Do: poll user input panel Do: read user input Do: interpret user input State name State variables State activities

14 14 Analiz Örüntüleri Pattern name: A descriptor that captures the essence of the pattern. Intent: Describes what the pattern accomplishes or represents Motivation: A scenario that illustrates how the pattern can be used to address the problem. Forces and context: A description of external issues (forces) that can affect how the pattern is used and also the external issues that will be resolved when the pattern is applied. Solution: A description of how the pattern is applied to solve the problem with an emphasis on structural and behavioral issues. Consequences: Addresses what happens when the pattern is applied and what trade-offs exist during its application. Design: Discusses how the analysis pattern can be achieved through the use of known design patterns. Known uses: Examples of uses within actual systems. s commonly used with the named pattern; (2) it is structurally similar to the named pattern; (3) it is a variation of the named pattern. Related patterns: On e or more analysis patterns that are related to the named pattern because (1) it is commonly used with the named pattern; (2) it is structurally similar to the named pattern; (3) it is a variation of the named pattern.

15 15 Tartışma / Müzakere İhtiyaçları Ana paydaşları belirle  Tartışmaya dahil olacak kişiler bu kişilerdir Herbir paydaşın “kazandığı durumları” belirle  Bazen açık olmayabilir Müzakere et /Tartış  “kazan-kazan” “win-win” durumuna yol açacak ihtiyaçları belirlemek için çalış.

16 16 İhtiyaçları Onaylama - I Herbir ihtiyaç sistemin amaçlarıyla tutarlı mı? Bütün ihtiyaçlar uygun bir soyutlama seviyesinde belirtildimi? Yani, Bu aşamada uygun olmayan derecede teknik detay sağlıyormu? İhtiyaç gerçekten tereklimi veya sistemin amacına uygun olmayan eklenebilir bir yapıyı mı içeriyor. Herbir ihtiyacın sınırları bellimi ve kesin mi? Herbir ihtiyacın özellikleri var mı? Yani, her bir ihtiyacın özellikleri, kaynağı kaydedildi mi? Herhangi bir ihtiyaç diğer bir ihtiyaçla çatışıyormu?

17 17 İhtiyaçları Onaylama - II Herbir ihtiyaç sistemin çalışacağı teknik ortam için temin edilebilir mi? Herbir ihtiyaç test edilebilir mi, daha önce uygulandıvmı? İhtiyaçlar, inşa edilecek sistemin bilgi, fonksiyon ve davranışlarını uygun bir şekilde yansıtıyor mu? Herbir ihtiyaç sistemin detaylı bir şekilde bölmelendi mi? Is each requirement achievable in the technical environment that will house the system or product? İhtiyaç örüntüleri ihtiyaç modelini basitleştirmek için kullanıldımı Heribr örüntü onandımı? Bütün örüntüler müşteri ihtiyaçlarıyla tutarlımı?