Muhasebe Bilgi Sisteminin Geliştirilmesi: İşletme, Veri Tabanı ve Arayüz Modülleri

Muhasebe Bilgi Sisteminin Geliştirilmesi: Kurumsal, Veritabanı ve Arayüz Modülleri!

Çeşitli muhasebe özellikleri sunan çeşitli muhasebe yazılım paketleri bulunmaktadır. Özelleştirilmiş muhasebe yazılımlarının maliyetinden çok daha düşük maliyetlidir. Bununla birlikte, bu yazılım paketleri yalnızca muhasebe bilgi sistemleri için yapı sunar. En çok, muhasebe bilgi sistemleri için programlama çabasını azaltır.

Resim Nezaket: bestsmallbizhelp.com/wp-content/uploads/2011/07/1018910261.jpg

Muhasebe bilgi sistemlerinin geliştirilmesi, defter deftere nakil ve rapor oluşturma yazılımlarından çok daha fazladır. Ayrıca veri toplama ve dağıtma prosedürlerinin oluşturulmasını ve muhasebe bilgilerinin analizini içerir.

Bir muhasebe bilgi sisteminin geliştirilmesi, orta ila büyük ölçekli bir işletme girişiminin gerekliliklerine özel bir referansla açıklanmaktadır. Bununla birlikte, bu adımlar bir ticari işletmedeki diğer çoğu bilgi sistemleri için ortak olacaktır.

1. Kurumsal Modül:

Bilgi sistemi geliştirme kurumsal modülü, temel varlıkların ve aralarındaki ilişkilerin tanımlanmasını, temel faaliyetlerin tanımlanmasını ve bu faaliyetlerin alt sistemlere yeniden gruplandırılmasını içerir. Ardından, öncelikler işletme için maliyet-fayda analizi temelinde belirlenir.

Varlıkları Tanımlama:

Bir ticari işletmede çok sayıda işletme vardır ve liste ticari faaliyetler kadar değişkendir. Bununla birlikte, bu aşamada, öncelikli kaygı, her biri bir grup temel varlık içeren geniş birimleri tanımlamaktır. Kerner ⁵, bir ticari işletmedeki altı temel varlığa işaret eder.

Müşteriler, ürünler, satıcılar, personel, tesisler ve paradır. Bir muhasebe bilgi sisteminde, işlemler, hesap ve işlem süresi olmak üzere üç temel varlık vardır. Bu varlıklar arasındaki ilişkiler, Şekil 8.2'de gösterilen ER şemaları kullanılarak ifade edilebilir.

İşlemler makbuzlar, ödemeler, satışlar, satın alımlar, varlıkların satın alınması veya borçların geri ödemeleri vb. Gibi farklı türlerde olacaktır ve her birine daha düşük seviye işletme denilebilir. Benzer şekilde, hesaplar varlıklar, borçlar, gelir ve gider gibi farklı türlerde olabilir.

Bu başkanların her birinin sabit varlıklar ve cari varlıklar gibi düşük seviyeli varlıkları olabilir. Bu kuruluşlar, arazi ve bina, tesis ve makine vb. Gibi hala düşük seviyeli varlıklara ayrılabilir. Ancak, bu aşamada, geniş işletmelerin tanımlanması gerekir. Ayrıntılar, veritabanlarını tasarlarken işlendi.

İşletmeler bilgi sisteminin kapsamını ve odağını tanımlamak amacıyla ve bunlar ışığında tanımlanmaktadır. Örneğin, eğer bilgi sistemi stratejik bir bilgi sistemi olarak görülüyorsa, geniş bilgi kaynakları, işletmenin bilgi sistemi yardımıyla faaliyetlerine vermeyi planladığı stratejik itiş güçleri ışığında tanımlanmalıdır.

Bu itişler maliyet azaltma, müşteri hizmetleri, ürün farklılaştırması ve stratejik ittifaklar olabilir. Böyle bir durumda temel varlıklar müşteriler, kanallar, rakip işletmeler, ürünler vs. olabilir.

Etkinlik Analizi:

Girişim modülünün bir diğer önemli yönü de işletmelerle ilişkili faaliyetlerin tanımlanmasıdır. Bu etkinlikler genel olarak ER diyagramlarındaki ilişkiler şeklinde tanımlanmaktadır. Ancak, faaliyet analizi yardımı ile detaylar elde edilmektedir. Mevcut organizasyon yapısı, teşebbüsün üstlendiği geniş kapsamlı faaliyetlerle ilgili önemli bir bilgi kaynağıdır.

Ancak, mevcut organizasyon yapısından bağımsız bilgi sistemleri geliştirmek için, faaliyet analizini yukarıda tanımlanmış olan temel varlıklara dayandırmak esastır. Bir sonraki aktivite analizi seviyesi yaşam döngüsü aktivitelerinin tanımlanmasını içerir. 'İşlemler' bir muhasebe bilgi sistemindeki temel varlıklardan biri olduğunda, dört geniş yaşam döngüsü aktivitesi vardır:

1. Satın alma ömrü

2. Üretim yaşam döngüsü

3. Gelir yaşam döngüsü

4. Yatırımlar yaşam döngüsü

Benzer şekilde, işleme süresi iki temel yaşam döngüsü aktivitesine sahiptir, yani:

a. Planlama ve kontrol yaşam döngüsü

b. İç ve dış raporlama yaşam döngüsü

Bu yaşam döngüsü aktiviteleri devam eden aktivitelerdir ve sürekli olarak yapılmaktadır. Bu faaliyetlerin her biri diğer bazı faaliyetlerle sırayla ilişkili olabilir. Üçüncü seviye aktivite analizi, yaşam döngüsü aktivitelerinin fonksiyonlara bölünmesini içerir.

Örneğin, her işlem türü başlatılmalı ve tanınmalıdır; Daha sonra işlemle ilgili veriler yakalanmalı, gelecekteki sınıflandırma için kodlanmalı, sınıflandırılmalı, özetlenmeli ve raporlanmalıdır. Bu işlevler farklı işlem türleri için farklı gerçekleştirilmelidir. İşlevlerin tanımlanması süreci, yalnızca işletmenin veritabanında bilgi oluşturan, güncelleyen veya kullanan etkinliklere odaklanır.

Bu aktivite analizi düzeyinde, faaliyetler kendi içindedir, olayları veya düğümleri başlatma ve sonlandırma ve tanımlanabilir bir kişi veya fonksiyonu yerine getirmekten sorumlu bir grup kişiyi açıkça tanımlamıştır.

Bu fonksiyonlar daha sonra, fonksiyonlar bilgisayar programları için modülü tanımlayacak kadar spesifik olana kadar alt fonksiyonlara bölünebilir. Yaşam döngüsü aktivitelerinin fonksiyonlara ve alt fonksiyonlara bölünmesi, birden fazla yaşam döngüsü aktivitesinde tekrarlanan fonksiyonların tanımlanmasına yardımcı olur.

Örneğin, elde edilen verilerin sınıflandırılması işlevi, satın alma ve pazarlama yaşam döngüleri içerisinde gerçekleştirilebilir. Bu tür faaliyet analizi, mevcut tasarımın iyileştirilmesi için fırsatların belirlenmesinde yardımcı olur:

1. gereksiz işlevleri ortadan kaldırarak

2. çoğaltılan fonksiyonları birleştirmek

3. İşleme yöntemlerinin basitleştirilmesi ve iyileştirilmesi

Artıklık, faaliyetlerin dikkatlice analiz edilmesiyle tespit edilebilir. İşlemeyi geliştirmek için fırsatlar sunması muhtemel olan faaliyetler şunları içerir:

a. Bu başka yerde de yapılabilir

b. Diğer aktivitelerle birleştirilebilir

c. Bu başka bir kişi tarafından da ele alınabilir

d. Bu, bilgi sisteminin ürün veya hizmetine değer katmayan, yaşam döngüsünün başka bir aşamasında gerçekleştirilebilir.

Burada dikkat edilmesi gereken bir şey, tüm artıklıkların kötü olmamasıdır. Aslında, bazı fazlalıkların veya kopyaların kasıtlı olarak sisteme sürünmesine izin verilebilir. Bu, sistemin performansını ve güvenilirliğini artırmak için yapılabilir.

Örneğin, yinelemelerin bazıları prosedürlerin basitliğini sağlamak ve işlem hızını artırmak için gerekli olabilir. Artıklığın ortadan kaldırılması “tüm yumurtaları bir sepete koymak” ile sonuçlanabilir ve bu nedenle güvenilirliği etkileyebilir. Beklenmeyen sonuçların ortaya çıkma riski ve önerilen yeni yöntem veya prosedürden düşük getiri, bilgi sisteminde değişiklik yapılmadan önce dikkat edilmesi gereken diğer faktörlerdir.

Faaliyetleri Alt Sistemlere Göre Gruplama:

Faaliyetler yukarıda kabul edilen yukarıdan aşağıya yaklaşım kullanılarak tanımlandıktan sonra, alt sistemler oluşturmak için yeniden toplanırlar. Bu aşamada alınacak önemli bir karar gruplama esasına dayanmaktadır. Bir faaliyetin hangi alt sisteme ait olduğuna karar vermek için tek bir objektif kriter olmayabilir.

Mevcut organizasyon yapısı, faaliyetlerin gruplandırılması için temellerden birini sağlayabilir. Ancak, mevcut organizasyon yapısı değişebilir ve bilgi sisteminin faydası kaybolabilir.

Faaliyetleri alt sistemde gruplamak için organizasyon teorisinden yardım alıyoruz. Herhangi bir iyi organizasyon yapısının temel özelliklerinden biri, faaliyetlerin koordinasyonunu kolaylaştırmayı amaçlamasıdır.

Daha iyi bir koordinasyon için etkili bir iletişim sistemi gereklidir. Bu nedenle, faaliyetleri grup içinde iletişimin kolaylaştırılması ve grup içi iletişim ihtiyacı en aza indirilecek şekilde gruplamak önemlidir.

Faaliyetlerin alt sistemlerde gruplandırılmasını temsil etmek ve belgelendirmek amacıyla, yapı çizelgeleri veya hiyerarşik blok şemaları kullanılır. Şekil 8.3, gelir döngüsünün bileşenlerini gösteren yapı şemasını vermektedir.

Diğer yapı kümeleri için benzer yapı tabloları hazırlanabilir ve son olarak, bu alt sistemler bir muhasebe bilgi sistemi için yapı taşları sağlayacak şekilde birbirleriyle bütünleştirilir.

Faaliyetlerin kümelenmesi ile tespit edilen alt sistemler, organizasyon yapısında varlıklar olduğu için ciddi rakiplerdir. Faaliyetlerin gruplandırılmasında kümelenme yönteminin avantajı, gruplandırmanın coğrafi bölgelere değil işlevlere ve kaynaklara dayanmasıdır.

İşlevler temelinde bu tür bir kümelenme, alt sistemlerin her biriyle ilişkili olan insan grubunun üyeleri arasında homojenliği sağlar. Bilgi sistemi organizasyonunun organizasyon yapısı üzerindeki etkisi nadir değildir.

Genellikle, yeni bilgi sistemlerinin insanların bir organizasyonda çalışma şeklini değiştirmesi nedeniyle organizasyon yapılarındaki değişikliklerle birlikte bilgi sistemlerinin tanıtılması da beraberinde getirilmiştir.

Bu nedenle, bilgi sistemi tasarımcılarının, faaliyetlerini kümeler halinde ve alt sistemlerde gruplandırırken, organizasyon geliştirme çalışanlarıyla aktif bir ilişki içinde çalışması daha da önemlidir. Bu, yalnızca yeni yapının daha pragmatik olmasını değil aynı zamanda insanlar için daha kabul edilebilir olmasını sağlar. Bu gibi durumlarda, eski sistemden yenisine geçiş daha az acı verici ve daha ucuzdur.

Öncelikleri belirlemek:

Alt sistemler tanımlandıktan ve bir bütün olarak entegre edildikten sonra, önceliklerin her bir sistemdeki çeşitli alt sistemler ve özellikler arasında belirlenmesi gerekir. Bilgi sistemi, finansal kaynakların taahhüdünü gerektirecektir.

Ek olarak, yeni sistemin operasyon sürecindeki gerekli değişiklikler açısından örtülü maliyetleri olabilir. Bu nedenle, her bir alt sistemin ve alt alt sistemin artı ve eksilerini tasarlanmadan ve uygulanmadan önce ölçmek önemlidir.

Her alt sistem, kritik başarı faktörleri (CSF) açısından tanımlanan iyi tanımlanmış değerlendirme kriterleri temelinde değerlendirilir. Bu faktörler daha önce Bölüm 8.2'de tanımlanmıştır.

Diğer yöntem, beyin fırtınasıdır; burada organizasyondaki ilgili kişiler, öncelikleri belirlerken dikkate alınması gereken faktörleri tanımlamak için bir araya gelirler. İlk aşamada serbest fikir akışı teşvik edilir.

Buradaki temel ilke, bu aşamada hiçbir fikrin aptalca veya ilgisiz olmadığıdır. İkinci aşamada, eleme süreci başlar ve tartışmalardan sonra öneriler sonuçlandırılır.

Faktörler listesi tamamlandıktan sonra, göreceli ağırlıklar atanır ve önerilen muhasebe bilgi sisteminin her bir bileşenini değerlendirmek için bir kriter fonksiyonu tanımlanır.

2. Veritabanı Modülü:

Muhasebe bilgi sistemi, büyük miktarda veriyi işler. Verileri yönetmek, bu nedenle, geliştirme sürecinde göz önünde bulundurulması gereken en önemli hususlardan biridir. Veri tasarımına iki temel yaklaşım vardır:

a. Geleneksel, uygulamaya yönelik yaklaşım ve

b. Veri tabanı yaklaşımı.

Geleneksel yaklaşım:

Veri tasarımına geleneksel yaklaşım, uygulamaya yöneliktir; her uygulama için, gereksinimlerine göre ayrı bir veri dosyaları kümesi oluşturulur. Başka bir deyişle, veri dosyaları belirli bir uygulamaya adanmıştır ve bir şekilde uygulamaya aittir.

Örneğin, bir alacak hesabı başvurusu, müşteri ana veri dosyasına, bir satış işlemi dosyasına ve müşterilerin işlem dosyasından bir alındıya sahip olacaktır. Bu veri dosyaları yalnızca alacak hesapları başvurusu için kullanılır.

Bu yaklaşım sadeliği nedeniyle daha küçük muhasebe bilgi sistemleri için uygundur. Bununla birlikte, bilgi sistemi veri hacmi ve analizin karmaşıklığı bakımından büyüdükçe, bazı problemlere de yol açmaktadır.

Geleneksel yaklaşımla ilgili temel sorun, uygulama programlarının kullandıkları ve değiştirdikleri veri dosyalarına bağlı olmasıdır. Sonuç olarak, veri dosyasındaki herhangi bir değişiklik (veri maddesinin eklenmesi veya silinmesi anlamında) veri dosyasını kullanan tüm programlarda değişiklik yapılmasını gerektirir.

Bu veri bağımlılığı, esneksizliğe yol açan veri dosyalarındaki değişiklikleri engeller. Veriler üzerinde rutin tipte veri yönetimi faaliyetlerinin gerçekleştirilmesi için herhangi bir aracın bulunmaması durumunda, bu imkanlar veri dosyasını kullanan programlara dahil edilecektir. Bu, programı zorlaştırıyor. Diğer bir sorun, geçici sorguyu karşılamakla ilgilidir.

Beklenmeyen türde bir sorgu için, özel programların yazılması gerekir. Bu tür özel programların geliştirilmesi zaman alır ve yalnızca bir kez kullanımına sahiptir ve bu nedenle pahalıdır. Veri öğelerinin kaydedilmesinde çok fazla çoğaltma var.

Örneğin, müşteri adı, fatura numarası, fiyat vb. Gibi veri kalemleri, müşteri siparişi işleme uygulaması için işlem dosyalarına ve alacak hesapları hesabına dahil edilebilir. Bu, verilerde fazlalığa neden olur.

Veri fazlalığı, depolama ortamının yetersiz kullanımına neden olur. Ayrıca, belirli bir veri maddesinin güncellenmesi, bu veri maddesinin depolandığı tüm dosyalarda yer almayabileceğinden, veri kalitesini etkiler.

Veri tabanı yaklaşımı:

Veri tasarımına modern yaklaşım veritabanı yaklaşımıdır. Bu yaklaşım, birçok uygulamanın ortak olan veri setlerini gerektirdiği varsayımlarına dayanmaktadır. Bu nedenle, bilgi sistemindeki her uygulamanın veri gereksinimlerini karşılayan ortak bir veri havuzuna sahip olmak daha iyidir.

Ortak havuz veritabanı olarak adlandırılır ve Veritabanı Yönetim Sistemi (DBMS) adlı bir yönetim sistemi tarafından yönetilir. DBMS, veri tabanlarındaki verileri uygulama programlarının yanı sıra doğrudan kullanıcılardan gelen taleplere göre yönetmek için özel olarak tasarlanmış bir yazılımdır. Veri tabanı ortamının kavramsal tasarımı, Şekil 8.5'in yardımı ile gösterilmiştir.

Veri tabanı yaklaşımı, uygulama yaklaşımının sorunlarını önemser. DBMS veri tabanından uygulama programlarına akışını sağladığı için veri bağımsızlığı sağlar. Kullanıcı uygulamasının, verilerin veritabanındaki konumu ile ilgili herhangi bir sıkıntı olması gerekmez. Bir veri sözlüğü tutulur ve veri sözlüğünde belirtilen kelimeler kullanılarak veri çağrılabilir.

Veri tabanı yaklaşımı, uygulama programlarının boyutunu ve karmaşıklığını da azaltır; çünkü sıralama gibi DBMS tarafından yapılan rutin veri işleme işlemleri. DBMS ayrıca geçici sorgunun gereksinimlerini karşılamak için de kullanılır. DBMS, Kullanıcı ile veritabanı arasındaki haberleşmenin dili olarak Structured Query Language (SQL) kullanır.

Dil çok basittir ve İngilizceye oldukça yakındır. Bu, kullanıcının veritabanından gerektiğinde ve gerektiğinde bilgi alabilmesini sağlar. Geçici sorgular yapmak için yöneticilerin ihtiyaç duyduğu eğitim miktarı asgari düzeydedir ve birkaç saatlik eğitim dili kullanma konusunda temel becerileri sağlayabilir. Belki de veritabanı yaklaşımının en önemli avantajı veritabanlarındaki fazlalıkların azaltılmasıdır.

Veritabanlarının tasarımında yaygın olarak kullanılan birçok model vardır. Bununla birlikte, modern yaklaşım, veri tabanı tasarımının ER Modelini takip etmektir. Bu yaklaşım yukarıdan aşağıya yaklaşımdır ve Kurumsal Modül'de daha önce çizilen ER çizelgeleri başlangıç ​​noktası haline gelir.

Her varlık ve ilişki için, özellikler Genişletilmiş ER şemalarında (EER şemaları) tanımlanır ve belgelenir. Bir muhasebe bilgi sisteminde, EER her işletme (işlem ve hesap) için çizilebilir ve işlem hesaplarının ilişkisi (etki) ER diyagramında gösterilir. Örneğin, bir satış işlemi için, özellikler Şekil 8.6'da gösterildiği gibi belirtilebilir ve belgelenebilir.

Bu nitelikler, her varlık için veri dosyasındaki bir kayıttaki veri öğeleri (alanlar) haline gelir (bu durumda satış işlemi dosyası). Benzer şekilde, diğer varlıklar ve ilişkiler için bu Genişletilmiş ER (EER) diyagramları çizilir.

Bu nitelikler tanımlandıktan sonra, özelliklerin bazılarının farklı EER listelerinde ortak olması muhtemeldir. Bu gibi ortak özelliklerin çoğaltılmasını önlemek için verilerin normalleştirilmesi yapılır.

3. Arayüz Modülü:

Bir arayüz modülü, veri maddelerinin kaynaklarını ve sistemde kullanılacak olan giriş / çıkış ve diyalog ekranlarının formatlarını tanımlar. Ayrıca, bilgi formatlarının bir bölümünden diğerine navigasyon için rapor formatlarını ve ekranları da tanımlar.

Başka bir deyişle, modül, kullanıcı ve makine arasındaki ara yüzün tanımlanması ile ilgilidir. Arayüz modülünün önemi, kullanıcı ve bilgi sistemleri arasındaki iletişimin artması nedeniyle artmıştır.

Hem veri girişi hem de veri sorgusu etkileşimli hale geldi. Çoğu durumda, giriş formları işlemden kaldırılır ve veri girişi doğrudan yapılır. Veri sorgusunun değişen gereksinimleri, birçok rapor formunu çok katı kılar. Etkileşimli rapor ekranları, veri sorgulamada daha fazla esneklik sağlar ve görüntüleme ve yazdırma için kullanıcı tanımlı rapor formatlarına izin verir.

Giriş ekranları:

Giriş ekranları, ticari faaliyetlerin doğal süreçleri ışığında tanımlanmıştır. Bu nedenle, öncelikle işletme tarafından ilk alındıklarında verileri manuel olarak kaydetmek için kullanılan formlara dayanırlar. Bir muhasebe bilgi sisteminde bu formlar fatura, satınalma siparişi, müşteri siparişi, gider fişi vb. İçerebilir.

Böylece arayüz modülünde formlar da gözden geçirilir; Yeniden tasarlanan ve giriş ekranları işletme tarafından kullanılan formlar ışığında tanımlanır. Bir muhasebe bilgi sisteminde, ekran tasarımı konusunda daha dikkatli olunması gerekir.

Veri girişinde tasarruf sağlayan giriş ekranındaki küçük bir gelişme, veri giriş ekranının kullanılma sayısı çok büyük olduğundan büyük tasarruflara neden olabilir. Giriş ekranı tasarlanırken aşağıdaki faktörler göz önünde bulundurulabilir:

(a) Formlarla eşleştirmek:

Giriş ekranı formatı giriş formlarıyla eşleşmelidir. Bazen, giriş formu tarafından kullanılan aynı formatta benimsemek öder. Mümkün olduğu ölçüde, ekranın arka planının rengi bile giriş formunun rengiyle eşleştirilebilir.

(b) Etkileşimli:

Giriş ekranı etkileşimli olmalıdır. Veri girişi sırasında giriş sırasındaki hataları belirtmeli ve düzeltmelere izin vermelidir. Her veri öğesi bir miktar veri doğrulama koşuluna sahip olmalı ve bu veri doğrulama koşullarının ihlal edilmesi veri girişi sırasında otomatik olarak vurgulanmalıdır.

Örneğin, fatura girişi için bir veri giriş ekranı, tarihin geçersiz olması durumunda tarih girişinde hataya işaret etmelidir. Tarih, hesap döneminin dışında olduğu veya girilen ayın on ikiden büyük olması nedeniyle geçersiz olabilir.

(c) Tutarlılık:

Giriş ekranları, bazı yaygın veri öğesi türleri için terimler ve konum tanımında tutarlı olmalıdır. Alışkanlığı arttırdığı için eğitim süresini azaltmada yardımcı olur; örneğin, işlem tarihi her zaman işlem belgesinin her birinin sağ köşesine yerleştirilebilir.

(d) Sadelik:

İyi bir giriş ekranının temel özelliklerinden biri basitliğidir. Çok fazla vurgulanmış bölüm, değerlerin veya niteliklerin yanıp sönmesi veya çok fazla kutu koymak ve altını çizmek yalnızca karmaşıklığa ve karışıklığa neden olur. Bazen, veri girişi hatalarını göstermek için bipler kullanılır. Bu tür bip seslerinin makul kullanımı olmalı ve genellikle bunlardan kaçınılmalıdır.

(e) Esneklik:

Giriş ekranı değişikliklere uygun olmalıdır. Kullanıcılara, veri maddesinin eklenmesi veya silinmesi ve taşınması konusunda değişiklikler yapma izni vermelidir. Değişiklik prosedürü basit olmalıdır. Bu günlerde, çeşitli yazılım üreticilerinin ürettiği Ekran Jeneratörleri, fare gibi sıradan bir işaretleme aygıtı kullanarak herhangi bir veri öğesini ekrandan sürükleyip sabitleme / bırakma gibi özellikler sunuyor.

(f) Özel yapım:

Ekranlar, her kullanıcı kategorisi için özel olarak hazırlanmalıdır. Bu, aşırı uzun başlangıç ​​ve giriş prosedürlerini azaltacaktır.

Rapor ekranları:

Raporlar, başka bir bilgisayar programı veya kullanıcı tarafından daha fazla analiz için hazırlanabilir. Elektronik tablolar, istatistiksel paketler, kelime işlemciler gibi bilgisayar programları tarafından işlenmeye yönelik veriler veri dosyalarında tutulur.

Kolayca erişilebilmeleri için standart veri biçiminde koymak daha iyidir. Kullanıcılar için hazırlanan raporlar normalde metin, tablo ve grafik şeklinde tutulur. Raporların zamanında, doğru, net ve düşük bir maliyetle yapılmasını ve iletilmesini sağlamak için çaba gösterilmelidir.

Diyalog ekranları:

Diyalog ekranları, bilgi sistemindeki görevleri tanımlamak ve gerçekleştirmek için kullanılan ekranlardır. Bilgi sisteminin yardımı ile neler yapılabileceğini, bir görev / prosedürden diğerine nasıl gidileceğini ve bilgi sisteminin izin verdiği çeşitli görevlerin nasıl gerçekleştirileceğini tanımlar.

Bu ekranlar basit ve açık olmalıdır. Sadelik, Grafik Kullanıcı Arabirimi (GUI) sağlayarak ve bir ekranda sınırlı sayıda menü öğesine sahip olarak tanıtılabilir. Bir menüden diğerine gezinme prosedürü basit, doğru sırada ve takip etmesi kolay olmalıdır. Ayrıca, egzersiz seçeneklerinde yanlışlığa işaret etmeli ve prosedürü düzeltmeye istekli olmalıdır.

Ekran tasarımı için CASE araçları:

Formlar, ekranlar ve raporlar tasarlamak için çeşitli CASE araçları mevcuttur. Bu araçlar, yeni bir kullanıcı için bile esnek ve basit bir tasarım ortamı sunma avantajına sahiptir.

Bu araçlar ekran prototipleme olanaklarına sahip olduklarından, kullanıcıların ekran tasarımı sürecine daha fazla dahil olmaları mümkündür. Tabii ki, bu tür araçlar son uygulamaya yönelik kodlar üreterek hızlı değişikliklere izin verir ve programcıların verimliliğini artırır. Bu gelişme süresinin azalmasına neden olur.

Formlar, giriş / çıkış ekranları ve iletişim ekranları hazır olduğunda, uygun şekilde test edilmeli ve değiştirilmelidir. CASE araçları kullanılarak tasarlanan formlar ve ekranlar kolayca değiştirilebilir. Bu nedenle, formların ve ekranların uygun şekilde test edilmesi ve tadil edilmesi yoluyla sistemin kabul edilebilirliğini iyileştirmek için çaba gösterilmelidir.

4. Uygulama Modülü:

Bu modül, işletme modülünde önceden tanımlanmış alt sistemleri genişletir. Yapı şemasında tanımlanan her alt sistem için, bu modülde ayrıntılı işlem prosedürleri tanımlanmıştır.

Başka bir deyişle, uygulama modülü öncelikle girdi verilerinin arayüz modülünde tanımlandığı gibi raporların bir parçasını oluşturacak değerlere dönüştürülmesinde yer alan işlemlerle ilgilidir. Sadece bu işlemlerin tanımlanması gerektiği not edilebilir.

(a) Veritabanlarındaki değerleri değiştirin veya

(b) Veritabanının bir parçası olmayan ancak arayüz modülünde tanımlanan raporlarda zorunludur.

Veritabanında zaten mevcut olan değerlere, bu amaç için programlar geliştirmeden kullanıcıların ihtiyacına göre DBMS sorgu dili kullanılarak erişilebilir. Böylece, uygulama modülünün görevi, veritabanı tasarımında ve ekran tasarımında halihazırda yapılan çalışmalarla azalır.

Veri akış şeması:

Yöneticinin bu modüldeki rolü temel olarak temel işlem prosedürünü tanımlamaktadır. Ayrıntılı algoritmalar genellikle yöneticinin aktif yardımı ile elbette bilgi sistemi uzmanı tarafından tanımlanır ve belgelenir.

Girdi verisini çıktıya dönüştürmek için gerçekleştirilecek işlemleri ifade etmek için kullanılan araç Veri Akış Şemasıdır (DFD). Veri akışını açıklar. Ne yapılması gerektiğini tanımlar ve nasıl yapılması gerektiğini veya daha önce nasıl yapıldığını görmezden gelir. Bu yaklaşım sistemde değişiklik yapılmasına izin verir ve mevcut yaklaşımın zayıf yönleri bu yaklaşımın ardından kaldırılabilir.

DFD sembolleri:

DFD'lerde kullanılan dört temel sembol vardır. Onlar:

(i) Sonlandırıcı:

Terminatör, harici bir veri akışı kaynağı veya harici veri havuzudur. Dış bir varlık veya müşteri, satıcı, hissedarlar vb. Gibi bir nesnedir. Sonlandırıcılar dış kuruluşlar olduğu için sonlandırıcılar arasındaki iletişim sistemden çıkarılır. Sonlandırıcı bir dikdörtgenle (genellikle gölgeli) sembolize edilir ve etiket dikdörtgenin içine yerleştirilir.

(ii) Veri akışı:

Veri akışı, sonlandırıcı tarafından başlatılan olayla ilgili bir dizi veri öğesi taşır. DFD'de bir okla sembolize edilir ve akış yönü ok yönünde gösterilir. Oklar, genellikle, veri dosyalarına yönlendirilmediği sürece etiketlenir. Daha önce belirtildiği gibi, iki sonlandırıcı arasındaki veri akışları DFD'ye dahil edilmez ve bu nedenle, veriler iki sonlandırıcı arasında doğrudan akamaz.

(iii) Süreç:

İşlem, gelen verileri yeniden yönlendirme için veri deposuna veya sonlandırıcıya dönüştürür. Köşeleri yuvarlatılmış bir dikdörtgen veya daire ile sembolize edilmiştir. Elbette bir fiil ile etiketlenir.

(iv) Veri deposu:

Dosyalar bilgi sistemlerindeki veri depolarıdır ve DFD'lerde açık dikdörtgenler şeklinde gösterilir. Genellikle, veritabanlarındaki tablolara karşılık gelirler. Satış siparişi işleme için veri akış diyagramının kısmi bir görünümü Şekil 8.7'de sunulmuştur.

DFD'nin çeşitli bileşenlerini temsil eden sembollerdeki bazı ek sembollerin ve küçük değişikliklerin de kullanımda olduğu not edilebilir. Yukarıdaki semboller en çok kullanılan sembollerdir ve Gane ve Sarson tarafından önerilen grafik kurallarına göredir.

Çoğu zaman, bir yönetici DFD'nin çizimini çok zor ve sinir bozucu bir deneyim olarak görüyor. Her biri bir DFD çizdiğinde, veri akışının bir veya diğer yönünü göz ardı ettiği tespit edilir. Neyse ki, mevcut CASE araçları DFD'leri oluşturmak ve değiştirmek için olanaklara sahiptir. Ancak, yeni başlayanlara bu sorunun üstesinden gelmek için aşağıdaki adımları izlemeleri önerilir:

(a) Giriş veri akışlarını sola ve çıkış veri akışını sağa koyarak tüm giriş veri akışlarını ve çıkış veri akışlarını sonlandırıcılar ile birlikte ayrı ayrı tanımlayın.

(b) Veri akış ismi veya sıfat isimlerini kullanarak sonlandırıcıları etiketleyin.

(c) Giriş veri akışlarından ileri ve çıkış veri akışlarından geriye doğru ortada bir araya gelinceye kadar olan işlemleri belirleyin.

(d) Fiil adlarını kullanarak işlemleri etiketleyin.

DFD'yi yeniden çizmek için bir yönetici hazırlanmalıdır, çünkü çoğu zaman veri akışları yalnızca DFD'yi çizdikten sonra yöneticiye açıklık kazandırır. Bu aşamada kullanıcının katılımı sadece yönetici kısmındaki çabayı azaltmada değil aynı zamanda DFD'nin iyileştirilmesinde de çok yararlıdır.

DFD'nin testi:

DFD'nin kesinleşmeden önce iyice test edilmesi önerilmektedir. DFD tasarımındaki yaygın hatalardan bazıları şunlardır:

a. Sonlandırıcı etiketi, sınıf yerine bir kişinin veya işletmenin adı olabilir. Örneğin, bir sonlandırıcı M / s olarak etiketlenebilir. Tek satıcı yerine BR Ltd. Başka bir hata, taşıyıcının doğrudan veri akışıyla ilişkili olan harici varlık yerine sonlandırıcı olarak konulması olabilir.

b. Veri doğrudan bir sonlandırıcıdan başka bir sonlandırıcıya akabilir.

c. Bir işlemden veya işlemden hiçbir veri akışı gösterilemez.

d. Veri akışı, sonlandırıcıdan bir veri deposuna (dosya) veya bir dosyadan sonlandırıcıya veya işlem görmeden iki dosya arasında gösterilir.

e. İşlemler, fatura gibi nesneler veya rezervasyon memuru gibi bir isim olarak etiketlenir.

Her alt sistem için DFD'ler çizildikten sonra, gelecekteki işleme detayları yapılandırılmış İngilizce olarak (psedo kodları) tanımlanabilir ve tanımlanabilir. Bu psedo kodları daha sonra uygulamaları kodlamak için kullanılır. Yöneticinin bu süreçteki rolü, yalnızca bilgi işlemlerinde profesyonel olan ve işleme dahil olan algoritmaları tanımlayan ve anlayan profesyonellere yardım etmekle sınırlıdır.

5. Uygulama Modülü:

Bu modül temel olarak sistemin test edilmesi, kullanıcıların eğitimi ve sistemin kurulumu ile ilgilidir.

Sistemin Test Edilmesi:

Çeşitli modüllerin testi, geliştirme sürecinin çeşitli aşamalarında yapılır. Test sırasında akılda tutulması gereken altın kural, testin sistemin başarısız olma ihtimalini belirlemek için test yapılması gerektiğidir. Sistemin tasarım şartnamesine göre çalışacağını kanıtlama hedefi olmamalıdır. Sistemin test edilmesi, iki temel soruya cevap bulma sürecidir:

1. Bilgi sisteminin, işletmenin bilgi ihtiyaçlarına hizmet edip etmediği? Bu soruya cevap arayan süreç bilgi sistemi uzmanları tarafından sistem doğrulama süreci olarak adlandırılmaktadır.

2. Bilgi sistemi doğru çalışıyor mu? Doğrulama süreci bu soruya cevap arar.

Sistem geliştirmenin farklı aşamalarında hataların niteliği ve ciddiyeti derecesi farklı olduğu için, farklı modüller ve bir bütün olarak sistemde farklı testler uygulanmaktadır.

Ünite testi:

Modül düzeyinde kullanılan testler birim testleri olarak adlandırılabilir. Bu testler arayüzler, veritabanları, aritmetik işlemler ve kontrol mantığındaki hataları tespit etmek için yapılır. Sistemin test edilip edilmediğini test etmek için özel olarak tasarlanmış test verileri üzerinde bir bilgi sistemi modülü çalıştırılarak gerçekleştirilirler:

a. Yanlış veri tipini kabul eder (örn. İsim için sayısal değeri kabul eder);

b. Geçerli aralık verilerinin dışında kabul eder (örneğin, 12 aydan büyük olan tarihi kabul eder);

c. Bir prosedürden başka bir prosedüre yanlış atlamaya neden olur.

Sistem testi:

Ünite testleri yalıtılmış olarak yapıldığından, bu ünitelerin grup olarak doğru çalışıp çalışmadığını kontrol etmek için entegrasyon testlerinin yapılması önemlidir. Hataların çeşitliliği nedeniyle, geçerliliği kontrol etmek ve sistemi doğrulamak için farklı test stratejileri izlenmelidir. Fertucks, bilgi sistemini test etmek için üç strateji önermektedir:

(a) Açık kutu testi:

Bu stratejide, testler işleme için takip edilen prosedürlerin uygulamanın gereklilikleri ile aynı olup olmadığını belirlemek için tasarlanmıştır. Bu, geliştirme aşamasında doğrudan ilişkili olmayan diğer bilgi sistemi uzmanları tarafından gözden geçirme yardımı ile sağlanabilir.

Alternatif olarak, yapısal adım adım yöntemi kullanılabilir. Bu yöntemde, bir grup kişi prosedürleri inceler, önce hataya açık kısımlara bakar ve yapılması gereken düzeltmeleri belirler. Ardından, grup üyeleri sistemin belirli bir giriş türü için sunacağı çıktıyı değerlendirir ve sistemin çıktısının doğru olup olmadığını test eder.

(b) Kara kutu testi:

Bu stratejide, sistem geçersiz veriler veya sistemin işleyişinde hataya neden olabilecek veriler için test edilir. Herhangi bir hatanın olup olmadığını anlamak için çıkış kontrol edilir. Örneğin, veriler sipariş edilen miktar için negatif değer veya yalnızca tam değeri alabilen bir değişken için kısmi bir değer içerebilir.

(c) Onay kutusu testi:

Bu strateji, tamamen hatasız bir bilgi sistemi sunmanın asla mümkün olmadığını varsaymaktadır. Bu nedenle, tüm test ve modifikasyonlardan sonra, sistemde kalan hataların sayısını tahmin etmek gerekir. Bu sayıyı tahmin etmek için, sisteme kasıtlı olarak birkaç hata verilebilir. Ardından hataları tespit etmek için testler tekrar yapılır.

Tespit edilen ortaya çıkan hataların oranı, önceki testler sırasında tespit edilen gerçek hataların oranının bir tahmini olarak alınmıştır. Bu nedenle, işaretleme kutusu testi sırasında ortaya çıkan hataların% 90'ı tespit edilirken, başlangıçta temiz kutu testi ve kara kutu testi sırasında toplam 450 hata tespit edilirse, 50 gerçek hatanın sistemde tespit edilmeden kalmaya devam ettiği anlamına gelir.

Kurulum:

Kurulum eski sistemi yeni bir sistemle değiştirme işlemidir. Genel olarak, kurulum için dört yaklaşım vardır. 'Soğuk' kurulum eski sistem derhal durdurulduğunda ve yerine yeni bir sistem yapıldığında yapılır.

Böyle bir kurulum, yeni sistemin kullanılması gerçeğiyle daha hızlı psikolojik uyum sağlama avantajına sahiptir. Ancak, önceki sistemden eski veriler değerliyse veya yeni sistemde bazı sorunlar varsa, böyle bir yaklaşım uygun olmayabilir. Muhasebe bilgi sistemlerini kurmak için bu yaklaşım kabul edilebilir bulunmamıştır. Alternatif yaklaşımlar şunları içerir:

(a) Pilot kurulum:

Bir sistem, yalnızca sistemi gerçekten kullanarak bu sistemi test eden belirli bir temsili kullanıcı grubu tarafından kullanılmak üzere kurulabilir. Diğer kullanıcılar eski sistemi kullanmaya devam ediyor. Sistemdeki sorunlar halledildiğinde, diğer kullanıcılar da sistemi kullanmaya başlar. Bu yaklaşım aynı zamanda muhasebe bilgi sistemleri için pek popüler değildir çünkü tüm muhasebe veritabanının kullanıcılar tarafından kullanılmadan önce güncellenmesi gerekir.

Kullanıcının bilgi gereklilikleri, organizasyon şemasındaki bölüm ve bölümlerin sınırlarını aşmaktadır. However, this approach may be used for complete accounting entities such as branch, regional office, etc. Thus, an accounting information system may be used by selected branches. Once they are found to be error free, they may be used by other branches as well.

(b) Phase-in installation:

Under this approach, the installation takes place in stages. These stages are independent components of the information system. So, the revenue life cycle of an accounting information system may be first installed and other life cycles may follow one after the other. This approach helps in focusing on a selected part of the system. It helps in improving the acceptability of the system among users because it enables the user to cope up with change easily.

(c) Parallel installation:

The parallel installation means running both the old and the new system simultaneously for a certain period until the utility of the new system is proved. This method is most popular for accounting information system because this is the safest of all other methods. The only difficulty, here, is the cost of parallel run and the tendency to extend the period of parallel run by those who resist change.

Post Implementation Review:

Each system must be reviewed after implementation is complete. Such a review not only helps in identifying the weaknesses of the system but also prepares an agenda for modification for future. It is, in fact, a learning process. System audit can also be conducted to examine how successful the system is, in terms of cost, delivery schedule, completeness and quality.