Varlık davranış modeli: Bu aşama her entity ye etki eden durumların tanımlandığı, modellendiği ve dokümante edildiği süreçtir.

Ebat: px

Şu sayfadan göstermeyi başlat:

Download "Varlık davranış modeli: Bu aşama her entity ye etki eden durumların tanımlandığı, modellendiği ve dokümante edildiği süreçtir."

Sanaz Gündoğdu
8 yıl önce
İzleme sayısı:

1 Yapısal Sistem Analiz ve Tasarım Metodu SSADM waterfall model baz alınarak uygulanan bir metottur. İngiltere de kamusal projelerde 1980 lerin başında kullanılan sistem analizi ve tasarımı konularındaki bir standartlar topluluğudur. SSADM tüm sistemin ilk tasarımdan uygulamanın fiziksel tasarımına kadarki tasarımı için yazı ve diyagramları kullanır. Teknikler Mantıksal veri modeli: Bu aşama sistemin tasarımı aşamasında gereksinimlerini tanımlama, modelleme ve dokümante etme sürecidir. Bu süreçte bilgi iş ihtiyaçların kayıtlı bilgiye dönüştüğü varlıklara(entity) ve ilişkilere(relationship) ayrıştırılır. İş akış modeli: Bu aşama verinin sistemde nasıl dolaştığının tanımlandığı, modellendiği ve dokümante edildiği süreçtir. İş akış modeli süreçleri(verinin bir yerden diğerine aktarıldığı eylemler), veri depolarını, harici varlıkları(sisteme ne gönderildi ve sistemden ne alındı) ve iş akışlarını inceler. Varlık davranış modeli: Bu aşama her entity ye etki eden durumların tanımlandığı, modellendiği ve dokümante edildiği süreçtir. Aşamalar Fizibilite Çalışması Projenin uygulanabilir olup olmadığına karar verebilmek için proje hedeflerine dair araştırma yapılmış olması gerekir. Ufak ölçekli projelerde bu önemli olmayabilir. Büyük ölçekli projelerde fizibilite informal bir algıyla yapılmalı çünkü formal bir çalışma ciddi zaman alır ya da proje 1 / 8

SSADM tüm sistemin ilk tasarımdan uygulamanın fiziksel tasarımına kadarki tasarımı için yazı ve diyagramları kullanır.

2 elzemdir ve bir yol seçilerek geliştirilmelidir. Fizibilite çalışması yürütülürken 4 ana durum göz önünde bulundurulmalıdır. Teknik; proje teknik olarak yapılabilir mi? Finansal; projenin yürütülebilmesi için yeterli para var mı? Organizasyonel; yeni sistem eskisiyle uyumlu mu? Etik; yeni sistemin etkileri sosyal açıdan kabul edilebilir mi? Fizibilite çalışması tüm sistem analizi ve tasarımı kavramının sıkıştırılmış versiyonudur. Gereksinimler ve kullanıcılar bazı business özelliklerin hazırlanması ve teknik implemantasyonun detayı için analiz edilirler. Bu aşamanın çıktısı formal bir fizibilite çalışma dokümanıdır. Mevcut Durumun Gözlemi Bu aşama SSADM nin en önemli aşamalarından biridir. Yazılımcılar yeni sistemin amaç ve hedeflerinin eskiye oranla ciddi şekilde değişmiş olmasına rağmen esas verinin çok az değişeceğini anlarlar. Çalışanlar arası görüşmeler, etrafta dolaşan soru çizelgeleri, gözlemler ve varolan dokümanlar sayesinde analistler sistemin tümünü anlamaya başlarlar. Genel prensipler: Analistler kullanıcıların ne yaptığını ve bunları nasıl yaptıklarını öğrenerek business terminolojiye aşina olurlar 2 / 8

Fizibilite çalışması tüm sistem analizi ve tasarımı kavramının sıkıştırılmış versiyonudur.

3 Eski sistem, yeni sistemin temel gereksinimlerini karşılar Hata, eksiklik ve etkisizlik noktaları belirlenmiş ve bunların çözümü gereksinimlere eklenmiştir Veri modeli çıkarılabilir durumdadır. Kullanıcılar işin içinde dâhil olmaya ve analistlerin model ve tekniklerini anlamaya başlarlar. Sistemin sınırları çizilebilir durumdadır. Bu aşamanın çıktıları şu şekildedir; Kullanıcı katalogu, sistemdeki kullanıcıları ve bunların etkileşimini tanımlar. Gereksinim katalogu yeni sistemin tüm gereksinimlerini detaylandırır Servis tanımları Mevcut mantıksal veri yapısı (ERD) İçerik diyagramı (DFD-data flow diagram) 3 / 8

Sistemin sınırları çizilebilir durumdadır.

4 Veri deposu ve varlıkları içeren tüm veri sözlüğü Business sistem seçenekleri Analistler mevcut sistemi araştırırken, yeni sistemin kapsamlı tasarımına karar vermelidir. Bunu yapmak için bir önceki aşamadaki çıktılar kullanılarak business sistem seçenekleri belirlenir. Analistler beyin fırtınası yaparak uygun tüm fikirleri değerlendirmelidirler. Sonrasında bu fikirler birleştirilerek 2 veya 3 seçenek olarak kullanıcıya sunulur. Bu seçenekler kapsamında aşağıdaki maddeler göz önünde bulundurulmalıdır; Sistemle kullanıcılar arasındaki sınır Maliyet/fayda Sistemin dağıtımı, örneğin tek bir ofis için mi özelleştirilmiş yoksa birden fazla ofiste kullanılabilir mi? Yeni sistemin etkisi Gerektiği durumda seçenekler mantıksal veri yapısı ve 1. Seviye iş akış diyagramlarıyla dokümante edilebilir. Kullanıcılarla analistler bu seçeneklerden birini seçer. Mütabık kalınan seçenek, sunulanlardan biri olabileceği gibi bu seçeneklerin karışımı da olabilir. Bu aşamanın çıktısı belirlenen bir business seçenektir. Gereksinimlerin belirlenmesi Bu aşama SSADM nin hemen hemen en karmaşık aşamasıdır. Analistler ilk aşamada belirlenen gereksinimleri kullanarak ve karar verilen business seçeneğini baz alarak, yeni sistemin ne 4 / 8

Sonrasında bu fikirler birleştirilerek 2 veya 3 seçenek olarak kullanıcıya sunulur.

5 yapması gerektiğini gösteren kapsamlı bir mantıksal tanımlama(logical specification) geliştirmelidir. Bu yapı hatalardan, belirsizliklerden ve tutarsızlıklardan arındırılmış olmalıdır. Mantıksal tanımlama yapmak için analistler DFD ve ERD ler için veri modeli oluştururlar. Bu aşamanın çıktısı aşağıdaki adımlardan oluşan Gereksinim Tanım Dokümanıdır; Güncel veri katalogu Güncel gereksinim katalogu Kullanıcı rol/fonksiyon matrisi Fonksiyon tanımları Mantıksal veri modeli Teknik Sistem Seçenekleri Bu aşama, yeni sistemin fiziksel implemantasyonuna doğru atılan ilk adımdır. Business sistem seçeneği gibi bu aşamada da yeni sistem için sunulan birçok seçenek değerlendirilir. Bu seçenekler kapsamında aşağıdaki maddeler göz önünde bulundurulmalıdır; Donanım mimarisi Kullanılacak yazılım 5 / 8

Bu aşamanın çıktısı aşağıdaki adımlardan oluşan Gereksinim Tanım Dokümanıdır; Güncel veri katalogu Güncel gereksinim katalogu Kullanıcı rol/fonksiyon matrisi Fonksiyon tanımları Mantıksal veri

6 İmplemantasyonun maliyeti Gerekli ekip Fiziksel sınırlar Kullanıcı arayüzü formatı Bu aşamanın çıktısı belirlenmiş teknik sistem seçeneğidir. Mantıksal Tasarım Bir önceki aşamada implemantasyonun detayları belirtilirken ve bu aşamanın çıktıları implemantasyon bağımsızlığı ve kullanıcı arayüzü gereksinimlerine yoğunlaşılmasıdır. Bu kapsamda kullanıcıların sistemle konuşması üzerinde durulur. Mantıksal tasarım, menü ve komut yapısı açısından etkileşimin metotlarını tanımlar. Bu aşamanın çıktıları veri katalogu ile mantıksal veri yapısını içeren mantıksal tasarımdır. Fiziksel Tasarım Bu aşama, sistemin mantıksal tanımlamalarının yazılımsal ve donanımsal tanımlanmasına dönüştüğü son aşamadır. Oldukça teknik bir aşamadır ve basit şekilde bir genel görünüm sunumu yapılır. 6 / 8

Bu kapsamda kullanıcıların sistemle konuşması üzerinde durulur. Mantıksal tasarım, menü ve komut yapısı açısından etkileşimin metotlarını tanımlar.

7 Mantıksal veri modelinin yerini fiziksel mimari(veritabanı yapısı) alır. Sistem özelliklerinin tam yapısı ve nasıl implemente edildiği belirtilmiştir. Fiziksel veri modeli gereksinimleri karşılayacak şekilde büyüklük ve performans olarak optimize edilmiştir. Bu aşamanın çıktısı yazılımcılara sistemin yazılımsal, donanımsal detaylarla ve uygun standartlarla nasıl geliştirileceğinin anlatıldığı Fiziksel Tasarımdır. Avantaj ve Dezavantajlar Avantajlar: Sisteme 3 farklı bakış, İyi tanımlanmış teknikler ve dokümantasyon, sistemin mantıksal ve fiziksel yönünün ayrılığı Kaliteli ürün Dezavantajlar: SSADM nin büyüklüğü onu her durumda kullanmaya engeldir. Bu tekniği kullanmak için yüksek bir yatırım maliyeti ve insan yetiştirmek için zaman gerekir. Bir aşama tamamlanmadan diğerine geçilmediği için ciddi zaman gereklidir. 7 / 8

Bu aşamanın çıktısı yazılımcılara sistemin yazılımsal, donanımsal detaylarla ve uygun standartlarla nasıl geliştirileceğinin anlatıldığı Fiziksel Tasarımdır.

8 Kullanıcılar çok dahil edilmediği için kullanıcı ihtiyaçları nadiren tam olarak karşılanır. İteratif yerine ardışık olduğu için değişiklikler kolay implemente edilemez Çok fazla dokümantasyon 8 / 8

İteratif yerine ardışık olduğu için değişiklikler

Benzer belgeler

Bir yazılım geliştirme metodolojisi aşağıdaki adımlardan meydana gelir; Yazılım geliştirme sürecine destek verecek araçlar, modeller ve yöntemler.

Bir yazılım geliştirme metodolojisi aşağıdaki adımlardan meydana gelir; Yazılım geliştirme sürecine destek verecek araçlar, modeller ve yöntemler. Yazılım Mühendisliği kapsamındaki Yazılım Geliştirme Metodolojileri, bir bilgi sistemini geliştirme sürecinin yapımını, planlamasını ve kontrolünü sağlayan bir framework tür. Her farklı framework güçlü