Cevap

Tarihsel olarak sistem analistleri, genellikle bir şirketin iş süreçlerini derinlemesine analiz ederek işe başlarlardı. Bu, bilgi sisteminin organizasyonun faaliyetlerini nasıl otomatikleştirebileceğini veya optimize edebileceğini anlamaya yardımcı olurdu. Ancak genellikle iş süreçleri analizi ile teknik tasarım arasındaki sınırlar karışmaktadır.

Temel Özellikler:

• İş süreçlerinin tanımlanması, organizasyonun faaliyetlerini bir sistem olarak belirlemeye ve biçimlendirmeye yöneliktir, IT araçları ile uygulama detayları göz önünde bulundurulmadan.
• Bilgi sisteminin tasarımı, gereksinimlerin belirlenmesinden sonra başlar ve mimari, arayüzler, entegrasyonlar, veri formatları gibi unsurların üzerinde çalışmayı içerir.
• Bu aşamaların ayırt edilmesi önemlidir: önce analist "ne yapmalı"yı belirler, sonra ise "nasıl yapmalı"yı.

Konunun Tarihçesi

Bu aşamalar arasındaki sınır daha netti: iş analisti süreçlerin modellemesinden, sistem analisti ise gereksinimlerin teknik spesifikasyonlara dönüştürülmesinden sorumluydu. Modern uygulamalarda ise görevler sıklıkla karışmaktadır.

Problem

Birçok analist, süreçleri tam olarak analiz etmeden sistem tasarımına başlamaktadır, bu da yanlış gereksinimlerin belirlenmesine ve aşırı teknik detaylandırmaya yol açmaktadır.

Çözüm

Konu alanı analizinin tasarımdan net bir şekilde ayrılması, süreçlerin tanımlaması için BPMN ve EPC kullanmak, tasarım için ise UML, veri akış diyagramları (DFD) gibi yöntemler kullanmak.

Soru-Cevap

Hangisi daha önemlidir — iş süreçlerini analiz etmek mi yoksa sistemi tasarlamak mı?

Tek bir şey vurgulanamaz: süreç analizine doğru gereksinimlerin belirlenmesi için ihtiyaç vardır, tasarım ise onların uygulanması içindir. Bu ardışık aşamalardır.

Süreçleri tanımlamak ve sistemi tasarlamak için aynı diyagramlar kullanılabilir mi?

Hayır, BPMN/EPC süreçler için, UML/DFD ise yapısal veya nesne yönelimli analiz ve tasarım için uygundur.

Hangi durumda iş süreçleri modellemeden geçilebilir?

Sadece proje küçükse ve süreçler belgelerde veya standartlarda tamamen biçimlendirilmişse geçilebilir. Çoğu durumda modelleme gereklidir.

Tipik Hatalar ve Anti-Desenler

• İş hedefleri anlaşılmadan veri şemasına erken detaylı geçiş.
• Süreç tanımı ile teknik çözümlerin karıştırılması.
• Nihai kullanıcıların çıkarlarının görmezden gelinmesi.

Hayattan Bir Örnek

Olumsuz vak'a:
Analist hemen veri tabanı ve servis şemasını çizmeye başladı, çalışanların nasıl çalıştığını ve neye ihtiyaç duyduğunu incelemeden. Artılar: hızlı uygulama, herkes ilk versiyondan memnun.
Eksiler: sistem gerçek ihtiyaçları karşılamıyor, kullanıcılar memnun değil, yeniden düzenlemeye ihtiyaç duyuldu.

Olumlu vak'a:
Analist öncelikle çalışanlarla bir dizi röportaj yaptı, BPMN'i oluşturdu, ardından API ve veri tabanı tasarımına geçti. Artılar: gereksinimler net, sistem gerçek süreçleri kapsıyor.
Eksiler: projenin başlaması daha uzun sürüyor, analiz maliyetleri daha yüksek.