SİSTEM ANALİZİ VE TASARIMI Fizibilite Analizi ve Gereksinim Belirleme

Giriş Sistem fizibilitesini tanımlayabilme Fizibilite çalışmasının gerekliliğini ve getirilerini ifade edebilme Fizibilite çeşitlerini tanımlayabilme Gereksinim belirlemeyi tanımlayabilme Gereksinim belirleme türlerini tanımlayabilme Nesne yönelimli gereksinim belirlemeyi tanımlayabilme

Fizibilite Analizi Bir çok insan iş çevresinde veya sosyal çevrede yapılan bazı değişikliklerin gereksinimden çok başkalarının yaptığı bazı değişikliklerden geri kalmama çabası olduğuna tanıklık etmiştir. Sistem analizi ve tasarımı ile görevli kişiler yapacakları değişiklikleri sistem içi verimlilik ve yararlılık merkezli yapmaları beklenir. Fizibilite çalışması bir projenin yapılabilir olup olmadığını , yapilabilir ise yararlılığını ortaya koyar . Fizibilite analizinin etkinlikleri şunlardır;

Fizibilite Analizi Mevcut Sistem Analizi (eski sistem kullanıcıları, kullanılan donanım, yapılan işlemler, dökümantasyon…) Mevcut Sistemin Sorunları (işlem gecikmesi, çakışmalar, verimsizlik, yetersizlik sorunları) Hedeflenen Sistem(sorunları çözmenin en etkili ve uygun yolunun bulunması) Sınırlılıklar Olası Seçenekler Olası Seçeneklerin Üstünlük ve Zayıflılıkları

Fizibilite Türleri Yeni bir sistemin fizibilite çalışmasını yaparken, mevcut sistemi her açıdan inceleyerek, yeni sistemde daha iyileştirici sonuçlara gidilmelidir. Bu bağlamda gerçekleştirilen fizibilite analizlerini 4 ana türde değerlendirmek mümkündür. Bu türler; işlevsel, ekonomik, teknik ve zamanlanmış fizibilite analizleridir.

1. İşlevsel Fizibilite İşlevsel fizibilite bir sistemin ne kadar işlevsel olduğunu ve olabileceğini bulmak için yapılmaktadır. Sistem kullanıcılarının yeni işlevlerle uyumu ve tepkisi ölçülür.

2. Ekonomik Fizibilite Sistem üzerinde gerçekleştirilmesi gereken değişikliklerin maliyet ve getiri hesaplamaları yapılarak en uygun çözümün, ekonomik açıdan, bulunması sağlanır. Varlığını devam ettiren profesyonel sistemlerin bir çoğu, geliştirme aşamalarında maliyeti düşürmeyi ve getirileri arttırmayı hedefler.

3. Teknik Fizibilite Sistemin donanımsal, yazılımsal ve bu donanım ve yazılımın etkili ve verimli kullanılma durumu teknik fizibilite ile görülür. Bu fizibilite ile sistemin gerekli teknolojiye sahip olup olmadığını, eğer sahipse kullanılıp kullanılmadığını, eğer sahip değilse gereksinim duyulan teknolojinin nasıl elde edilip kullanılacağının çözümlerini arar.

4. Zamanlanmış Fizibilite Düşünülen yeni sistemin kullanıcı ile anlaşılmış şartlarda ve zamanda tamamlanıp teslim edilebilirliğinin fizibilitesini yapar.

Gereksinim Belirleme Gereksinim belirleme, sistem ile ilgili doğru ve gerçek gereksinim ve bilgilerin toplanıp kayıt edilmesidir. Gereksinim belirleme işlemini zor yapan etkenlerin başında bu aşamanın net ve belirgin bir tanımının olmamasıdır. Verilen hatalı bir karar tüm analiz, tasarım ve uygulama süreçlerini etkileyecektir. Sistem analisti, sistem kaynaklarının neler olduğunu öğrenmeli ve bu kaynakların nasıl değerlendirildiği ve işlendiği iyi analiz ederek gerekli bilgileri toplamalıdır. Ulaşılmak istenen sistemde daha verimli ve etkili bir işleyiş için sistemde yer alan kişilerin beklenti, hedef ve amaç gereksinimleri tanımlanarak, düzenlemeler yapılır.

Gereksinim Belirleme Sonuç olarak bu aşamada yapılması gerekenler şöyle ifade edilebilir; Veri toplama Gereksinimlerin düzenlenmesi Onaylatma

Gereksinim Kavramı Gereksinimleri, yeni sistem tanımlayıcıları olarak ifade etmek mümkündür. İşveren ile sistem geliştiricisi arasında yapılan anlaşma maddeleri gereksinimlerden oluşur. Başka bir deyişle bu gereksinimler, sistem tamamlanınca hangi işlevleri nasıl gerçekleştireceğini de belirler.

Gereksinim Belirlemesi Gereksinim belirlemek için kullanılan bir kaç yöntem; yazılım gereksinim mühendisliği, yapısal gereksinim analizi, problem durumu analizi vb. Özetle bu yöntemlerin amacı sistemin verdiği/vermesi gereken hizmetleri belirlemek ve sistemin sınırlılıkları gereksinimlerini belirlemektir.

Gereksinim Belirleme Yöntemleri (Veri Toplamak) En çok kullanılan veri toplama teknikleri; Görüşme Anket Gözlem Işlem ve Döküman Analizi Birleştirici Uygulama Tasarımı (JAD) Örnek (prototip) oluşturmak

Görüşme Iyi bir sistem analisti aynı zamanda iyi bir görüşme uzmanıdır. Müşteri ve kullanıcılarla görüşmeden önce bir ön çalışma yaparak sorularını hazırlar, görüşme esnasında iyi bir dinleyici olur, notlar alır ve görüşmeden sonra notları değerlendirerek düzenler.

Anket Sistem analisti önceden hazırlamış olduğu soru formlarının ilgili kişiler tarafından doldurulmasını sağlar. Formda bulunan sorular kapalı uçlu sorular, çoktan seçmeli sorular, sınıflama soruları ve aralık soruları olabilir. Etkili bir veri toplama eylemi için formda kullanılacak soruların dikkatli bir şekilde, yanlış anlamaya yer vermeden, sistemin zayıf ve güçlü noktalarını ortaya çıkaracak şekilde hazırlanmalıdır.

Gözlem Sistem analisti veya veri toplamada görevli kişi, sistemi birebir gözlemleyerek, kendi açısından gereksinimleri daha kolay belirleyebilir. Gözlemlerin, çalışan sistemi etkilememesi (sistemde bulunmadan, kamera kayıtları gibi) durumunda çok etkili ve tarafsız veri elde etmeyi sağlamaktadır.

İşlem ve Döküman Analizi Sistem analisti, yapılan işlemleri ve kayıt yöntemlerini analiz ederek sistemde gerçekleştirilenleri ve sorunları anlayabilir. Bunun yanında var olan dökümantasyon analizi yaparak da aksaklık ve sorunların giderilmesi için fikir alınabilir.

Birleştirici Uygulama Tasarımı (Joint Application Design-JAD) Sistem yoneticileri, kullanıcılar, müşteriler, destekleyiciler, sistem geliştiricileri vs. bir araya gelerek bir seri toplantı düzenlenir. Tüm katılımcıların sistem hakkında söz hakkı bulunur. Herkes sistemin işleyişi, aksaklıkları, sorunları, olası çözüm yolları üzerinde düşüncelerini ifade ederler.

Örnek (Prototip) Oluşturma Sistem analisti oluşturduğu sistem örneğiyle kullanıcılarını erkenden tanıştırarak, sistemin hayat döngüsünde, zaman kazanabilir. Kullanıcılar, bu örnek üzerinden gereksinimlerini anlar ve bu gereksinimler üzerinde düzenlemeler yapılmasına yardımcı olacak bilgileri verirler.

Gereksinimlerin Düzenlenmesi Değişik tekniklerle veri toplama işlemi gerçekleştikten sonra bu verilerin düzenlenmesi gerekir. Her alınan bilgi incelenmeli ve sistem tasarımcılarının anlayabileceği şekilde sunulmalıdır. Bu eylemi gerçekleştirmek için en bilinen ve kullanılan bazı yöntemler; veri akış şemaları, varlık ilişkili şemalar, karar tabloları ve karar ağaçlarıdır.

Veri Akış Şemaları Veri akış şemaları (Data Flow Diagram - DFD) ile verinin sisteme girişini, sistemde işlenişini, işleniş esnasında sistem içindeki hareketleri, işlendikten sonra sistem içinde saklanması veya sistem dışına gönderilmesi gibi aşamalarda izledigi yol görsel olarak ifade edilir. Verinin işleyiş sırasında kimler tarafından ve ne şekilde işlendiği de gözler önüne seriliyor.

Veri Akış Şemaları Veri akış şemaları fiziksel ve mantıksal olarak ikiye ayrılırlar. Fiziksel Veri Akış Şemaları: bu şemalar uygulama bağımlı şemalardır. Gerçek sistemde yer alan donanım, değişik bölümlerdeki değişik insanlar vb. Bu şemalarda yer alır. Mantıksal Veri Akış Şemaları: sistemdeki eylemlerin nasıl gerçekleştiğinden çok sistemde nelerin yer aldığı üzerinde durulur.

Veri Akış Şeması Elemanları Özellikler Gösterimi Yourdon & Coad Gane & Sarson İşlem(Process): veri üzerinde gerçekleşen iş birimidir. Numarası, adı, tipi, tanımlaması, girdilerin ve çıktıların veri akışı, notlar Veri Akışı (Data Flow):işlemler arası verinin akışını gösterir Numarası, adı, tipi, tanımlaması, başka isim, nitelik, notlar VERI AKIŞI Veri Depolama (Data Storage):verinin mantıksal depolanması Veri Deposu Dış Varlık (External Entity):verinin kaynağı yada gideceği yerdir. Etiketi, tipi, tanımlaması, başka isim, nitelik, notlar İŞLEM İŞLEM Veri Deposu Dış Varlık Dış Varlık

Veri Akış Şemaları Bu elemanlar kullanılarak bir veri akış şeması çizilebilir ancak dikkat edilmesi ve uyulması gereken bazı kurallar bulunmaktadır. Her işlem için bir giriş bir de çıkış veri akışı olmalıdır Her işlem kendine gelen veriyi işleyip yeni bir veri üretmelidir. Her veri deposu en az bir tane veri akışına katılmalıdır. Her dış varlık en az bir veri akışına katılmalıdır Bir veri akışı en az bir işleme eklenmelidir.

Örnek Bu kurallar doğrultusunda, bir kumaş fabrikasından kumaş alıp, aldığı kumaşı işleyip müşterilerine satan bir firmanın veri akış şeması: Şekilde kumaş fabrikası ve müşteri dış varlık, dikiş ise işlemdir. Bu elemanlar arasında ilişki olduğunu gösteren oklar ise veri akışını ifade etmektedir. İlişki: kumaş fabrikasından gelen kumaşlar dikiş işleminden geçip müşteriye sunulmakta, aynı zamanda müşterilerden bir karşılık alınıp kumaş fabrikasına verilmektedir. KUMAŞ FABRIKASI DİKİŞ MÜŞTERI

Örnek Veri akış şemalarında genelden özele denebilecek bir yapıyla ele alınmaktadır. Bu yapının daha iyi işleyebilmesi için veri akış şemaları katmanlardan oluşur. Bu katmanlarda sistem en üst katmanda en genel durumuyla en alt katmanda ise istenen en özel birimiyle ifade edilir

Örnek

Varlık İlişkili Şemalar Varlık ilişkili şemalar (Entity Relationship Diagram – ERD) sistemin kullanacağı veritabanı tasarımında kullanılır. Bir sistemdeki varlıkların birbirleriyle olan karşılıklı ilişkileri görsel olarak ifade eden şemalardır. Varlık ilişkili şemaları sistemde gerçekleşen bütün işlemlerin veritabanı eksenli düşünülmesi ile ortaya çıkan şemalardır. Sistemde yer alan bütün veriler varlıklara ve bu varlıklar arasındaki ilişkilere aktarılır.

Varlık İlişkili Şemalar Varlık İlişki Şeması Elemanları Simgeler Varlık (Entity): verinin depolanmak istendiği somut veya mantıksal nesnelerdir. Varlıklar; görevler, olaylar, yerler, somut nesneler ve kavram olarak beş şekilde sınıflandırılır. İlişki (Relationship): iki varlığın veritabanı içinde veriyi nasıl paylaştıklarını ifade eder. Nitelik (Attribute): varlığın özelliklerini tanımlar. VARLIK İLİŞKİ NİTELİK

ÖDÜNÇ-VERİLEN-KİTAPLAR Örnek adı adresi KullID eseradı KID yazar KİTAPLAR KULLANICILAR 1:N 1:N ÖDÜNÇ-VERİLEN-KİTAPLAR KID Iade tarihi KullID

Örnek Yukarıdaki örnek bir kütüphane sisteminin kitap ödünç verme modülü için hazırlanmış basit bir varlık ilişki şemasıdır. Bu şemada “ÖDÜNÇ-VERİLEN-KİTAPLAR”, “KİTAPLAR” ve “KULLANICILAR” birer varlık olarak yer almaktadır. Şemada 1:N ifadesi ilişkinin nasıl bir ilişki olduğunu ifade eder. “KullID”, “Adı” gibi ifadeler de varlığın bazı değerlerini tutmaya yöneliktir ve varlığın niteliklerini ifade eder.

Karar Tabloları Sistemde yer alan bütün verileri ve etkinlikleri görülebilmesi hatta olası durumların sezilebilmesi ve gözden kaçırılmaması için etkili bir şekilde kullanılabilirler. Karar tabloları, karar verme mantığının tablolar üzerinde ifade edilmesiyle oluşur. Karar tabloları bir sistem işlemini anlaşılabilir olması için o işlemin koşulları ve çalışma biçimini ayırarak sunar. Gorulebilmesi hatta

Karar Tabloları Bir karar tablosunu meydana getiren 4 eleman vardır. 1. Koşullar: bir karar tablosunda gerekli olan bütün sınamaların listelemesi bazı kaynaklarda “şartlar” şeklinde de kullanılmaktadır. 2. Eylemler: karar tablosunda yer alan bütün işlemlerin listelenmesi, bazı kaynaklarda “faaliyetler” şeklinde de kullanılmaktadır. 3. Koşul Kuralları: koşulların gerçekleşmesinde karşılaşılabilecek olası durumları listelemesi 4. Eylem Kuralları: koşul kurallarına göre karar verilen eylemin belirtilmesi.

Örnek Karar Tablosu

Karar Ağaçları Karar verme aşamalarının kök dallanmalı bir yapıyla ortaya çıktığı durumlarda oldukça verimli kullanılan bir yöntem olan karar ağaçları dallanmaların grafiksel olarak gösterildiği şemalardır. Karar ağaçları kararların, olayların, bir sorunun sonuçları ile ilgili durumların iki boyutlu grafiklerle sunulmasıdır. Karar ağaçları, sistemle ilgili olası, beklenen, alternatif durumları belirlemek için kullanırlar. Bununla beraber birbiri ardına gelen kararlar dizisinin nasıl ilerlediğini gösteren yolda karar ağaçları ile ifade edilebilir. Karar ağaçları kök denebilecek bir tek durumla başlar ve her biri bir çıktı (karar) olan birden fazla eylemle son bulur.

Karar Ağacı Örneği

Gereksinimlerin Onaylatılması Sistem geliştiricileri, sistem analizi ve tasarımı aşamalarının hepsinde kullanıcı onayını almak durumundadırlar. Kullanıcıların onayı alınmadan yapılan analiz ve tasarımların yanlış veya eksik olma olasılıkları oldukça yüksektir. Bununla beraber yapılan analiz ve tasarımların doğruluk payı yüksek olmasına rağmen, kullanıcıların görüşünün alınmamasının bazı sorunlar çıkarması gibi durumlar da yaşanabilmektedir. Kullanıcılar analiz ve tasarım aşamasının dışına itildiklerini ve bu aşamaların kendi isteklerine parallellik göstermeyeceğine yönelik şartlanmalar geliştirebilmektedirler. Unutulmamalıdır ki kullanıcılar onaylamadıktan sonra geliştirilen sistemin hayata geçmesi mümkün olmayacaktır.