END3061 SİSTEM STEM ANALİZİ VE MÜHENDİSLİĞİ BİLİŞİM M SİSTEMLERS STEMLERİ GİRİŞİŞ
Bir sistem analizcisinin ana misyonu, kullanıcıların fiziksel gereksinimlerini açımlamak ve bunları yazılıma dönüştürmektir. Tüm yazılımların kökleri bir fiziksel davranışa ya da ihtiyaca dayanır. İnsanların etkileşimi sonucu meydana gelen şeyi bir fiziksel davranış olarak tanımlayabiliriz ki, özellikle iş hayatında olduğu gibi, insanlar çoğu sistemin ana ihtiyaçlarını yaratırlar. Örneğin Ayşe tedarikçilerden faturalar aldığını ve bunları 30 gün sonra ödediğini anlattığında, fatura alma ve ödeme prosesindeki fiziksel aktivitesini açıklamaktadır.
Biliyoruz ki yazılımlar bilgisayarın sınırları içerisinde çalışmalı ve bu sistemlerde mantık çerçevesinde işlemelidir. Mantıksal çözüm her zaman fiziksel dünyada uygulanan prosedürlerin aynısını takip etmez.. Daha doğrusu Ayşenin fiziksel olarak yaptıklarından daha ve daha verimli fonksiyonları yazılım ortaya koyacaktır. Yazılım bu sebeple fiziksel dünyanın bir mantıksal eşitliği olarak düşünülebilir.
Bir Uzun Bölme Problemi
Bir Veri Akış Diyagramının (VAD) 4 Farklı Komponenti Olabilir Proses: Şu anda yapılmakta olan fonksiyonun adını ifade eder. Uygun proses verinin bir formdan diğerine transform edilmesi ile olur. Veri Akışı: Verinin, bir prosese, hariciye ya da veri deposuna giriş ya da çıkışını ifade eder. Ok akışın yönünü ifade eder. Veri Deposu: Depolanmış veri genelde bir depoda tutulur. Belirli bir bölgeden erişilebilen veriyi temsil eder. Harici: Sistemin parçası olmayan bir veri sağlayıcısı veya kullanıcısıdır. Bu sebebten bir sınırı temsil eder.
Muhasebeci Hakan ın bankada çekleri karşılıksız çıkmıştır. Bir bakiye düzeltme formu doldurur ve bunu düzeltme departmanına gönderir böylece cari hesabı düzeltilecektir. Hakan müşteriye 15 TL ceza ile birlikte (şimdi cari hesabın parçası olarak dahil edilir) yeni bir çek isteğini içeren mektubu müşteriye gönderir.
Karşılıksız Çekleri Ele Almak İçin Veri Akış Diyagramı Banka Karşılıksız çek Düzeltme Bölümü P1 Karşılşıksız çekleri ele al Düzeltme Formu Mektup V Hesap Dosyası Müşteri
Karşılıksız Çekleri Ele Almak İçin 2. Seviye Veri Akış Diyagramı
Karşılıksız Çekleri Ele Almak İçin 3. Seviye Veri Akış Diyagramı
Fonksiyonel Olarak Ayrıştırılmış Karşılıksız Çekleri Ele Almak İçin 3. Seviye Veri Akış Diyagramı
Değişiklik ve Modifikasyon Yapmak Bakım modellemesi ya da mevcut bir ürüne ek ya da değişiklik yaparken modelleme araçlarının nasıl kullanılacağı da Analiz Araçları konu başlığında yer almaktadır. 1. Modellenmiş (Pre-Modeled): Yazılıma yapılacak olan değişiklikleri etkileyecek, modellerin mevcut sistemde bulunması. 2. Eski Sistem (Legacy System): Eski sistem hiç modellenmemiş. Her yeni model için analiz araçları ilk kez kullanılacaktır.
Değişiklik ve Modifikasyon Yapmak Pre-Modeled: Modellenmiş bir ürün halihazırda yapısal olarakbiçimlendirilmiş haldedir. Bir yapısal format, Veri Akış Diyagramı gibi spesifik bir format ya da metodoloji içermektedir. Daha evvel modellenmiş araçları değiştirmenin zorlukları: 1. Evvelki versiyonlarla tutarlı olmasını sağlamak 2. Analiz değişikliklerinin izini sürebileceğimiz ve daha evvelki versiyonlarla nasıl fark yarattıklarını kontrol edebileceğimiz bir Versiyon Kontrol sistemini uygulamak.
Değişiklik ve Modifikasyon Yapmak Tutarlı-Uyumlu Olmak: Yazılım ürünlerinin yaşam çevrimlerinin ortasında, modelleme metodlarını ya da CASE araçlarını değiştirmek zordur. Bundan korunmanın en iyi yolu ilk seferinde doğru araçları ve CASE yazılımını seçmektir. Herkes hata yapabilir daha da önemlisi yeni bir CASE ürününü cazip hale gelmesi de söz konusu olabilir. Bu gibi uyumsuzluk sorunlarıyla uğraşmak zorunda kalınırsa: CASE ürününüz modelleri kes/kopyala ya da ANSII dosyası halinde nakledebilecek yetenekte olmalıdır. Çoğu programın Import/Export fonksiyonları bulunmaktadır. En azından analizci diyagramları ve veri elemanlarını başka bir programa aktarabilmelidir.
Değişiklik ve Modifikasyon Yapmak Analizcinin ileriye doğru gidebilmesi için bazı diyagram ve eleman setlerini tutması tavsiye edilir. Organizasyon farklı modelleme araçları kullanmaya karar verebilir. Örneğin VAD yerine süreç-bağımlılık diyagramları kullanmak gibi. Bu durumda analizci belli miktar reengineering yapmak zorundadır. Yeni modelleme araçlarını mevcut olanlara eşleştirmek gerekir. Bunu yapmak kolay değildir.
Değişiklik ve Modifikasyon Yapmak Versiyon Kontrolü: Yapısal metodların bir denetim izi olmalıdır. Yeni bir süreç değiştirildiğinde, eski versiyon için bir klasör yaratılmalıdır. Klasör ismi versiyonu ve tarihi içermelidir. Örn: xyz1.21206, burada xyz ürünün ya da programın ismini, 1.2 versiyonu ve 1206 versiyon tarihini göstermektedir. Bu şekilde eski versiyonlar yeniden yaratılıp, görüntülenebilir. Programın tümünü komple bir set halinde kaydetmek mümkün olmayabilir ya da çok pahalı olabilir (disk hacmi gibi). Bu durumlarda eski versiyonu kolayca restore edilebilecek şekilde yedeklemek tavsiye edilir. Her halde versiyon kontrolü için bir prosedürü uygulamak zorunludur ve periyodik olarak yedeklemek için bir süreç bulunmalıdır.
Değişiklik ve Modifikasyon Yapmak Eski Sistemler (Legacy System): Bunlar genelde eski nesil (3GL) yazılım uygulamalarıyla geliştirilmiştir. En çok bilinen business-oriented yazılımda COBOL dur. Ne yazıkki bu sistemlerin çok azı yapısal araçlar kullanılarak geliştirilmiştir. Bunlar çoğu şirkette değiştirilmekte olduğundan şüphe yoktur. Tüm yazılımlar iki temel bileşenden oluşmaktadır: süreçler ve veri. Süreçler, sistemin ihtiyacı olan gerçek mantık ve algoritmalardır. Veri ise süreçlerin depolayıp kullandıkları bilgiyi ifade eder. Soru analizcinin eşdeğer süreçleri ve veriyi eski sistemden nasıl çekeceğidir. İki temel yaklaşım Veri Yaklaşımı ve Süreç Yaklaşımı dır.
Değişiklik ve Modifikasyon Yapmak Veri Yaklaşımı : Yapısal değişiklikler amacıyla eski sistemlerin modellenmesi gerekmektedir. İlk adım mevcut dosyaların ve ilişkili ver yapılarının modellenmesi olacaktır. 3GL uygulamaları ilişkisel veya diğer veritabanı biçimlerini içermezler. Bunun için tüm veri elemanlarını toplanıp mevcut CASE aracına import edilmesi gerekir.
Değişiklik ve Modifikasyon Yapmak Süreç Yaklaşımı: Mevcut programları modellemenin en doğru yolu, en direkt yoldur: Kodu okuyarak analiz etmeye başla. Bu yaklaşım oldukça ham olsa da aynı zamanda efektiftir. Tüm programlama dilleri dosyaların ve raporların giriş ve çıkışlarının (input/output) tanımlanması için gerekli yapıya sahiptirler.böylece analizci iyi bir veri akış diyagramı yaratabilir. Örnekte İki adet dosya tanımlama tablosu vardır (COBOL). İlk tablo maaş kaydı için gerekli input dosyalarını, ikinci tablo ise maaş raporlama için output dosyalarını içermektedir.
Değişiklik ve Modifikasyon Yapmak
Program Dosya Açıklamalarının Veri Akış Diyagramına Çevrilmesi
Tanımlama (Spesifikasyon) Biçimleri Yapısal araçların grafiksel olması gerektiği söylense de, bir tanımlamanın özü uygulama programlarının algoritmalarını tarif etme-tanımlama yeteneğindedir. Bu sebebten dolayı Pseudocode yazmak zorunda kalınabilir. Pseudocode esas kodun nasıl çalısması gerektiğinin jenerik bir gösterimidir. Analizci kolay nalaşılır ve teknik açıdan doğru algoritmalar yaratabilmelidir.
Tanımlama (Spesifikasyon) Biçimleri Bu spesifikasyonların zorluk seviyesi birçok sebebe dayanmaktadır. 1. Analizcinin teknik yeterliliği. Analizci en efektif şekilde algoritma yazma yeterliliğine sahip olmalıdır. 2. Spefikasyonun zorluk seviyesi. Spesifikasyonların büyüklüğü ve kapsamı değişecebilecektir. 3. İhtiyaç duyulan spesifikasyonun tipi. Spesifikasyonun iki seviyesi vardır: iş ve programlama. İş spesifikasyonu teknik olamayan eleman tarafından incelenebilecek şekilde tasarlanır. Esas amacı daha spesifik ve teknik programala spesifikasyonuna geçmeden evvel kullanıcıların onayını almaktır. Programlama spesifikasyonu ise algoritmaların teknik açıklamalarına ihtiyaç duymakta ve teknik tasarımcılar ve programcıları hedef almaktadır. 4. Programcı kadroların yeterliliği ve de analizcilerin kendine güveni.
Tanımlama (Spesifikasyon) Biçimleri Teknik Olmayan Kullanıcılar lar Düzyazı halinde işi spesifikasyonu Teknik Kullanıcılar lar Düzyazı halinde işi spesifikasyonu Çok Teknik Kullanıcılar lar veya MIS Personeli Ayrıca bir işi spesifikasyonuna ihtiyaç yok Programlama spesifikasyonu göstermez Programlama spesifikasyonu ortaya koyup yorumlayabilir İş ve programlama spesifikasyonlarını birleştirebilir.
İş Tanımlaması Örneği
İş Tanımlaması Örneği