IDEF0 metodolojisi

IDEF0 metodolojisi hiyerarşik bir diyagram sisteminin oluşturulmasını öngörür - sistem parçalarının tek açıklamaları. İlk olarak, sistemin bir bütün olarak tanımı ve dış dünya ile etkileşimi (bağlam şeması) gerçekleştirilir, ardından işlevsel bir ayrıştırma yapılır - sistem alt sistemlere ayrılır ve her bir alt sistem ayrı ayrı tanımlanır (ayrışma diyagramları) . Daha sonra her bir alt sistem daha küçük alt sistemlere bölünür ve bu, gerekli ayrıntı derecesine ulaşılana kadar devam eder.

Her biri IDEF0-diyagramlarıfakat bloklar ve yaylar içerir. Bloklar, simüle edilmiş sistemin fonksiyonlarını temsil eder. Yaylar blokları birbirine bağlar ve aralarındaki etkileşimleri ve ilişkileri görüntüler.

Diyagramlardaki işlevsel bloklar (işler), belirli bir süre içinde meydana gelen ve tanınabilir sonuçlara sahip olan adlandırılmış süreçler, işlevler veya görevler anlamına gelen kutularla gösterilir. Eserin adı, eylemi ifade eden sözlü bir isim olarak ifade edilmelidir.

IDEF0 en az üç ve en fazla altı kutuya sahip bir diyagram gerektirir. Bu kısıtlamalar, diyagramların ve modellerin karmaşıklığını okunabilecek, anlaşılabilecek ve kullanılabilecek bir düzeyde tutar.

Bloğun her bir tarafının belirli, iyi tanımlanmış bir amacı vardır. Bloğun sol tarafı girişler, üst taraf kontrol, sağ taraf çıkışlar, alt taraf mekanizmalar içindir. Böyle bir atama, belirli sistem ilkelerini yansıtır: girdiler çıktılara dönüştürülür; kontrol, dönüşümleri gerçekleştirmek için sınırlar veya koşulları belirler; mekanizmalar, bir işlevin neyi ve nasıl gerçekleştirdiğini gösterir.

IDEF0'daki bloklar, diyagramın yazarı tarafından anlaşıldığı gibi önem sırasına göre yerleştirilir. Bu göreceli düzene baskınlık denir. Baskınlık, bir bloğun diyagramın diğer blokları üzerindeki etkisi olarak anlaşılır. Örneğin, diyagramdaki en baskın blok, gerekli bir fonksiyon dizisinin ilki veya diğerlerini etkileyen bir planlama veya kontrol fonksiyonu olabilir.

En baskın kutu genellikle diyagramın sol üst köşesine, en az baskın olan kutu sağ köşeye yerleştirilir.

Sayfadaki blokların düzeni, yazarın baskınlık tanımını yansıtır. Böylece, diyagramın topolojisi, hangi özelliklerin diğerleri üzerinde daha büyük bir etkiye sahip olduğunu gösterir. Bunu vurgulamak için analist, blokları baskınlık sıralarına göre yeniden numaralandırabilir. Baskınlık sırası, her kutunun sağ alt köşesine yerleştirilen bir sayı ile gösterilebilir: 1, en yüksek baskınlığı, 2 sonrakini vb. gösterir.

Eserlerin dış dünya ile ve kendi aralarındaki etkileşimi, uçlarında oklar bulunan tek satırlarla gösterilen oklar şeklinde anlatılmaktadır. Oklar bazı bilgileri temsil eder ve bunlara isim denir.

IDEF0, beş tür ok arasında ayrım yapar.

giriş- bir sonuç (çıktı) elde etmek için çalışma tarafından kullanılan ve dönüştürülen nesneler. Çalışmanın herhangi bir giriş oku olmamasına izin verilir. Giriş oku işin sol tarafına girerken çizilir.

Kontrol-.işin eylemlerini kontrol eden bilgiler. Tipik olarak, kontrol okları, işin ne yapacağını gösteren bilgileri taşır. Her iş, işin üst yüzüne girerken gösterilen en az bir kontrol okuna sahip olmalıdır.

Çıktı- girdilerin dönüştürüldüğü nesneler. Her iş, işin sağ tarafından geliyor gibi çizilen en az bir çıkış okuna sahip olmalıdır.

mekanizma- İşi yapan kaynaklar. Mekanizma oku, işin alt yüzünden girecek şekilde çizilir. Analistin takdirine bağlı olarak, mekanizmanın okları model üzerinde gösterilmeyebilir.

Telefon etmek- farklı bir çalışma modelini gösteren özel bir ok. Çağrı oku, işin altından geliyor gibi çizilir ve simüle edilen sistem dışında bazı işlerin yapıldığını belirtmek için kullanılır.

Pirinç. 2.1 Ok türleri

IDEF0 metodolojisinde, bloklar arasındaki ilişkileri tanımlamak için sadece beş tür etkileşim gereklidir: kontrol, girdi, kontrol geri beslemesi, girdi geri beslemesi, çıktı-mekanizması. Kontrol ve giriş ilişkileri, sezgisel ve çok basit olan doğrudan eylemleri yansıttıkları için en basitleridir.

Pirinç. 2.2.Çıkış iletişimi

Pirinç. 2.3. Yönetim iletişimi

Bir bloğun çıktısı, daha az baskınlığa sahip bir bloğu doğrudan etkilediğinde bir kontrol ilişkisi oluşur.

Kontrol geribildirimi ve girdi geribildirimi, yinelemeli veya özyinelemeli olduklarından daha karmaşıktır. Yani, bir işin çıktıları, daha sonra orijinal işi etkileyecek olan diğer işlerin gelecekteki yürütülmesini etkiler.

Kontrol geri beslemesi o zaman gerçekleşir; bir bloğun çıktısı daha fazla baskın olan bir bloğu etkilediğinde.

Çıkış mekanizması ilişkileri nadirdir. Bir fonksiyonun çıktısının bir başkası için bir araç haline geldiği bir durumu yansıtırlar.

Pirinç. 2.4. Giriş Geri Bildirimi

Pirinç. 2.5. Yönetim Geribildirimi

Çıktı-mekanizma ilişkileri, kaynak kaynaklarının (örneğin, gerekli araçlar, eğitimli personel, fiziksel alan, ekipman, finansman, malzemeler) tahsisinin karakteristiğidir.

IDEF0'da bir yay nadiren tek bir nesneyi gösterir. Genellikle bir dizi nesneyi sembolize eder. Yaylar nesne koleksiyonlarını temsil ettiğinden, birden çok başlangıç ​​noktasına (kaynak) ve bitiş noktasına (hedef) sahip olabilirler. Bu nedenle, yaylar çeşitli şekillerde dallanabilir ve bağlanabilir. Yayın tamamı veya bir kısmı bir veya daha fazla bloktan çıkabilir ve bir veya daha fazla blokta sona erebilir.

Yayların ayrılan çizgiler olarak gösterilen dallanması, yayların içeriğinin tamamının veya bir kısmının her bir dalda görünebileceği anlamına gelir. Tüm kümeye bir isim vermek için bir yay her zaman bir daldan önce etiketlenir. Ek olarak, bir yayın her bir dalı aşağıdaki kurallara göre etiketlenebilir veya etiketlenmeyebilir:

etiketlenmemiş dallar, dallanmadan önce yayın etiketinde belirtilen nesnelerin ağırlığını içerir;

dal noktasından sonra etiketlenen dallar, daldan önceki yay etiketinde belirtilen nesnelerin tamamını veya bir kısmını içerir.

IDEFO'da birbirine yaklaşan çizgiler olarak gösterilen yay birleşmeleri, her dalın içeriğinin orijinal yayların birleşmesinden kaynaklanan yay için bir etiket oluşturduğunu gösterir. Bir birleştirmeden sonra, sonuçta ortaya çıkan yay, birleştirmeden sonra ortaya çıkan yeni özellik kümesini belirtmek için her zaman işaretlenir. Ek olarak, her dal, aşağıdaki kurallara göre bir birleştirmeden önce işaretlenebilir veya işaretlenmeyebilir:

Pirinç. 2.6.Çıkış mekanizması bağlantısı

etiketlenmemiş dallar, birleştirmeden sonra yayın ortak etiketinde belirtilen nesnelerin ağırlığını içerir;

birleştirmeden önce işaretlenen dallar, birleştirmeden sonra ortak işarette listelenen nesnelerin tümünü veya bir kısmını içerir,

diyagramdaki blok sayısı - N;

diyagram ayrıştırma seviyesi - L;

grafik dengesi - İÇİNDE;

bloğa bağlı ok sayısı - FAKAT

Bu faktör seti, her model diyagramı için geçerlidir. Aşağıda, grafik faktörlerinin istenen değerleri için öneriler listelenecektir.

Alt seviyelerin diyagramlarındaki blokların sayısının, ana diyagramlardaki blokların sayısından daha az olmasını sağlamak için çaba sarf etmek gerekir, yani, ayrıştırma seviyesindeki bir artışla katsayı azalacaktır. Dolayısıyla bu katsayının azalması bunu göstermektedir. model ayrıştırıldıkça fonksiyonların basitleştirilmesi gerektiği, bu nedenle blok sayısının azalması gerektiğidir.

Grafikler dengeli olmalıdır. Bu, bir diyagram çerçevesinde, Şekil 2'de gösterilen durumun olduğu anlamına gelir. 2.7: iş 1, giden oklardan önemli ölçüde daha fazla gelen ve kontrol okuna sahiptir. Bu tavsiyenin üretim süreçlerini anlatan modellerde uygulanamayacağına dikkat edilmelidir. Örneğin, bir montaj prosedürünü tanımlarken, bir blok, bir ürünün bileşenlerini açıklayan birçok ok içerebilir ve bir ok çıkabilir - bitmiş ürün.

Pirinç. 2.7. Dengesiz bir grafik örneği

Diyagramın denge katsayısını tanıtalım

için çabalamak gereklidir ky grafik için minimum oldu.

Diyagramın grafik öğelerinin analizine ek olarak, blokların adlarını da dikkate almak gerekir. İsimleri değerlendirmek için simüle edilmiş sistemin temel (önemsiz) fonksiyonlarının bir sözlüğü derlenir. Aslında, diyagramların alt, seviye ayrıştırmasının işlevleri bu sözlüğe girmelidir. Örneğin, bir veritabanı modeli için, "kayıt bul", "veritabanına bir kayıt ekle" işlevleri temel olabilirken, "kullanıcı kaydı" işlevi daha fazla açıklama gerektirir.

Kelime dağarcığını oluşturduktan ve bir sistem diyagramları paketini derledikten sonra, modelin alt seviyesini dikkate almak gerekir. Diyagram bloklarının adları ile sözlükteki kelimeler arasında bir eşleşme gösteriyorsa, bu, yeterli düzeyde ayrışmanın sağlandığını gösterir. Bu kriteri nicel olarak yansıtan katsayı şu şekilde yazılabilir: L*C- blok adlarının sözlükteki kelimelerle eşleşme sayısına göre model seviyesinin ürünü. Modelin seviyesi ne kadar düşükse (L yüksekse), eşleşmeler o kadar değerlidir.

BPWin'i başlattığınızda, ana araç çubuğu, araç paleti ve Model Gezgini varsayılan olarak görünür.

Yeni bir model oluştururken, modelin yeniden mi oluşturulacağını yoksa ModelMart deposundan mı açılacağını belirtmeniz gereken bir iletişim kutusu açılır, modelin adını girin ve modelin oluşturulacağı metodolojiyi seçin ( Şekil 2.8).

Şekil 2.8 Model oluşturma iletişim kutusu

BPWin üç metodolojiyi destekler - IDEF0, IDEF3 ve DFD. BPWin'de karma modeller oluşturmak mümkündür, yani bir model aynı anda hem IDEF0, IDEF3 hem de DFD diyagramlarını içerebilir. Araç paletinin bileşimi, bir notasyondan diğerine geçerken otomatik olarak değişir.

BPWin'deki bir model, her biri bir dizi veri üzerinde çalışan bir faaliyetler topluluğu olarak görülür. Modelin herhangi bir nesnesine sol fare düğmesiyle tıklarsanız, her bir öğesi nesnenin bazı özelliklerinin düzenleyicisine karşılık gelen bir açılır bağlam menüsü görüntülenir.

Bir sistem modeli oluşturmak, işlevselliğini tanımlayan tüm belgelerin incelenmesiyle başlamalıdır. Bu belgelerden biri, "Geliştirmenin amacı", "Sistemin amaç ve hedefleri" ve "Sistemin işlevsel özellikleri" bölümleri olan görev tanımlarıdır.

Kaynak dokümanları inceledikten ve sistemin müşterileri ve kullanıcıları ile görüştükten sonra, modellemenin amacını formüle etmek ve modele bakış açısını belirlemek gerekir. Temel özellikleri 1 No'lu laboratuvar çalışmasında açıklanan "Üniversite çerçevesinde istihdam hizmeti" sistemi örneğinde yapım teknolojisini ele alalım.

Modellemenin amacını formüle edelim: Uygulama ile ilgili ayrıntılara girmeden, kullanıcının anlayabileceği şekilde sistemin işleyişini açıklamak. Modeli kullanıcıların (öğrenci, öğretmen, yönetici, dekanlık, firma) bakış açısından oluşturacağız.

Bir IDEF0 bağlam diyagramı oluşturarak başlayalım. Sistemin tanımına göre asıl işlevi, müşterilerinden gelen talepleri işleyerek hizmet vermektir. Böylece bağlam diyagramının tek işini "Sistemin istemcisine hizmet et" olarak tanımlıyoruz. Ardından, girdi ve çıktı verilerinin yanı sıra mekanizmaları ve kontrolü tanımlarız.

Bir müşteriye hizmet verebilmek için, onu sisteme kaydettirmek, veritabanına erişim sağlamak ve talebini işleme koymak gerekir. Girilen veriler "müşteri adı", "istemci şifresi", "orijinal veritabanı", "müşteri talebi" olacaktır. İsteğin yürütülmesi ya sistemden bilgi alınmasına ya da veritabanının içeriğinin değiştirilmesine (örneğin, uzman değerlendirmeleri derlenirken) yol açar, bu nedenle çıktı "raporlar" ve "değiştirilmiş veritabanı" olacaktır. Talep işleme süreci, yöneticinin kontrolünde sistem monitörü tarafından gerçekleştirilecektir.

Böylece sistemin bağlam diyagramını tanımlamış oluyoruz (Şekil 2.9).

Şekil 2.9. Sistem Bağlam Şeması

Müşteri hizmetleri sırasını tanımlayarak bağlam diyagramını ayrıştıralım:

Sisteme erişim seviyesinin belirlenmesi.

Alt sistem seçimi.

Bir alt sisteme erişim.

Veritabanını değiştirmek (gerekirse).

Şekilde gösterilen diyagramı alıyoruz. 2.10.

Bağlam diyagramının ayrıştırılmasını tamamladıktan sonra, bir sonraki seviyenin diyagramının ayrıştırılmasına geçerler. Genellikle, üçüncü ve daha düşük seviyeler göz önüne alındığında, modeller ana diyagramlara döner ve bunları düzeltir.

Pirinç. 2.10."Servis, sistemin müşterisi" çalışmasının ayrıştırılması

Ortaya çıkan diyagramın tüm bloklarını sırayla ayrıştırırız. Sisteme erişim düzeyini belirlemede ilk adım, kullanıcı kategorisini belirlemektir. İstemci adına göre, kullanıcı veritabanında kategorisi belirlenerek bir arama yapılır. Belirli bir kategoriye göre sistem kullanıcısına verilen yetkiler netleştirilmiştir. Ardından, sisteme erişim prosedürü gerçekleştirilir, erişim adı ve şifre kontrol edilir. İzinler ve sisteme erişim düzeyi hakkındaki bilgileri birleştirerek, kullanıcı için bir dizi izin verilen eylem oluşturulur. Böylece, sisteme erişim seviyesinin tanımı Şekil 1'de gösterildiği gibi görünecektir. 2.11.

Pirinç. 2.11."Sisteme erişim seviyesinin belirlenmesi" çalışmasının ayrıştırılması

Sistem erişim prosedüründen geçtikten sonra, monitör, talebi işleyecek bir alt sistem seçerek müşterinin talebini analiz eder. "Bir alt sisteme atıfta bulunmak" çalışmasının ayrıştırılması, modelin amacına ve bakış açısına uymuyor. Sistemin kullanıcısı, çalışmasının dahili algoritmalarıyla ilgilenmez. Bu durumda, alt sistem seçiminin müdahalesi olmadan otomatik olarak yapılması onun için önemlidir, bu nedenle alt sisteme yapılan çağrının ayrıştırılması sadece modeli karmaşıklaştıracaktır.

İstekleri işlemek, kategorileri ve kullanıcı izinlerini belirlemek için alt sistem tarafından gerçekleştirilen "Müşterinin isteğini işleme" işini ayrıştıralım. Bir sorguya cevap aramadan önce, veritabanını açmalısınız (ona bağlanın). Genel olarak, veritabanı uzak bir sunucuda bulunabilir, bu nedenle onunla bağlantı kurmak gerekebilir. İş sırasını tanımlayalım:

Veritabanını açma.

Bir isteğin yürütülmesi.

Rapor oluşturma.

Veritabanını açtıktan sonra, veritabanına bağlantı kurulması hakkında sistemi bilgilendirmeniz, ardından sorguyu çalıştırmanız ve kullanıcı için raporlar oluşturmanız gerekir (Şekil 2.12).

"Talebin yürütülmesi"nin çeşitli alt sistemlerin çalışmalarını içerdiğine dikkat edilmelidir. Örneğin, bir istek test içeriyorsa, o zaman profesyonel ve psikolojik testlerden oluşan bir alt sistem tarafından yürütülecektir. Sorgu yürütme aşamasında, örneğin uzman değerlendirmeleri derlenirken veritabanının içeriğini değiştirmek gerekebilir. Bu nedenle, şema üzerinde böyle bir olasılığın sağlanması gereklidir.

Pirinç. 2.12.

Ortaya çıkan diyagramı analiz ederken, raporlar hangi kurallara göre oluşturulur? Veritabanından seçim yapmak için kullanılacak önceden oluşturulmuş şablonların olması ve bu şablonların sorgulara karşılık gelmesi ve önceden tanımlanmış olması gerekir. Ayrıca, müşteriye raporun şeklini seçme fırsatı verilmelidir.

"Rapor şablonları" ve "Veritabanını değiştirme istekleri" oklarını ve "Sistem İstemcisi" tünel okunu ekleyerek diyagramı düzeltelim. Rapor formunun seçilmesi işlevi üst diyagramda gösterilecek kadar önemli olmadığı için oku üst diyagrama yerleştirmemek için “Sistem İstemcisi” tünelleme kullanılmıştır.

Diyagramın değiştirilmesi, tüm ana diyagramların ayarlanmasını gerektirecektir (Şekil 2.13 - 2.15).

IDEF0 metodolojisi sistemi, bilgi işleme süreçlerini zayıf bir şekilde yansıtan, birbiriyle ilişkili bir dizi çalışma olarak gördüğünden, DFD diyagramını (laboratuvar çalışması No. 3) kullanarak “Sorgu Yürütme” çalışmasının ayrıştırılması tavsiye edilir.

Pirinç. 2.13."Müşterinin talebinin işlenmesi" çalışmasının ayrıştırılması

Pirinç. 2.14."Sistemin istemcisine hizmet etmek" çalışmasının ayrıştırılması (seçenek 2)

Pirinç. 2.15. Sistem bağlam şeması (seçenek 2)

Son "Veritabanını değiştirme" bloğunun ayrıştırılmasına geçelim. Müşterinin bakış açısından, bu sistemler tek bir veritabanında bulunur. Gerçekte, sistemde altı veritabanı vardır:

kullanıcı veritabanı,

öğrenci veri tabanı, (seçenek 2)

boş iş veri tabanı,

ilerleme veritabanı,

veritabanı testi,

Uzman değerlendirmelerinin DB'si,

DB özeti.

Modellemenin amacına göre, müşterinin alınan verilerin sistemde hemen güncellenmediğini, ancak ek bir işleme ve kontrol aşamasından geçtiğini anlaması önemlidir. Değişim algoritması aşağıdaki gibi formüle edilebilir:

Bilgilerin değiştirileceği veri tabanı belirlenir.

Operatör geçici bir veri seti oluşturur ve yöneticiye sunar.

Yönetici verileri kontrol eder ve veritabanına girer.

Bu model, veri kontrol sürecini atlayarak doğrudan istek üzerine veritabanını güncelleme yeteneği sağlayarak farklı bir şekilde uygulanabilir. Bu durumda, zarar görmemesi için veritabanının bütünlüğünün sağlanması gerekir. Bu durumda, diyagram şöyle görünecektir (Şekil 2.17).

Pirinç. 2.16."Veritabanını değiştirme" çalışmasının ayrıştırılması

Pirinç. 2.17."Veritabanını değiştirme" çalışmasının ayrıştırılması (seçenek 2) Şek. 2.12

Daha fazla ayrıştırma yapmak "Veritabanındaki değişiklikler", veritabanının sistemdeki fiziksel değişiminin nasıl yapıldığını açıklayarak modeli karmaşıklaştıracaktır. Bu durumda, kullanıcı istihdam hizmeti sisteminin işleyişi hakkında herhangi bir ek bilgi almayacaktır. Bu çalışmanın ayrıştırılması, mantıksal bir veritabanı modeli oluşturma aşamasında bir veritabanı sistemi tasarlama sürecinde gerçekleştirilmelidir.

"Sorgu Yürütme" çalışmasının ayrıştırılması, bilgi işleme süreçlerini açıklamak için DFD diyagramlarının kullanımını gösteren bir sonraki laboratuvarda gerçekleştirilecektir.

Şekiller'de gösterilen modellerin nicel bir analizini yapalım. 2.12 ve 2.13, yukarıda açıklanan yönteme göre. Bu modeller için ^ katsayısının davranışını düşünün. "Bir müşteri talebini işleme" ana diyagramı 4/2 = 2 katsayısına ve 3/3 = 1 ayrıştırma diyagramlarına sahiptir. modelin.

Katsayıdaki değişikliği düşünün İLE B iki modelde.

ikinci seçenek için

katsayı İLE B değerini değiştirmez, bu nedenle diyagramın dengesi değişmez.

Ele alınan diyagramların ayrıştırma seviyesinin, modellemenin amacını yansıtmak için yeterli olduğunu ve alt Seviye diyagramlarında, eser adları olarak temel fonksiyonların kullanıldığını varsayacağız (sistem kullanıcısı açısından) .

Ele alınan örneği özetlersek, bir sistemi modellerken diyagramlar için çeşitli seçenekleri göz önünde bulundurmanın önemine dikkat etmek gerekir. Bu tür seçenekler, "Bir müşterinin isteğini işleme" ile yapıldığı gibi diyagramları ayarlarken veya sistem işlevlerinin alternatif uygulamalarını oluştururken ("Veritabanını değiştirme" çalışmasının ayrıştırılması) ortaya çıkabilir. Seçeneklerin değerlendirilmesi, en iyisini seçmenize ve daha fazla değerlendirme için diyagram paketine dahil etmenize olanak tanır.

Bir resim bin kelimeye bedeldir

halk bilgeliği

Çoğu zaman işimde sadece belirli bir sorunu incelemeye ve çözmeye değil, aynı zamanda şirketin genel modelindeki yerini belirlemeye de ihtiyaç vardır. Belirli bir birimin düzgün çalışmadığını anlamak yeterli değildir, diğerleriyle nasıl etkileşime girdiğini anlamak önemlidir. Aksi takdirde, mevcut tüm sorunları tespit etmek ve sorunu çözmek için en iyi yöntemi seçmek imkansızdır. Bunun için şirketin çalışmalarını incelemeli ve işlevsel modelini oluşturmalısınız.

Tabii ki, teoride, yönetici şirketin çalışmasının işlevsel bir modeline sahip olmalıdır ve deponun organizasyonundan mı yoksa talepten talebe kadar BT sisteminden mi bahsediyor olmamız önemli değil. Ancak gerçekte, neredeyse hiç ortaya çıkmaz ve bu nedenle, müşteri tarafından belirlenen göreve bir çözüm bulma ve arama sürecinde, aynı zamanda şirketin işlevsel bir modelini veya belirli bir süreci (fonksiyonu) oluştururum. benim.

Grafiklerin faydaları hakkında birkaç söz

Bildiğiniz gibi IDEF0 fonksiyonel modelleri her zaman grafik diyagramlardır. Kendine has özellikleri ve derleme kuralları vardır. Bunun hakkında biraz sonra konuşacağız. Ve şimdi grafiklerin etkinliğine dair birkaç örnek vermek istiyorum. Neden buna odaklanıyorum? Büyük olasılıkla, şirketin çalışmasının işlevsel bir modeline duyulan ihtiyaç hakkındaki açıklamamdan sonra, birçok kişi bunun gerekli olmadığını düşündü ve şirkette şu veya bu işlevin nasıl çalıştığını kelimelerle açıklamak mümkün oldu. Bu konu hakkında konuşmak istiyorum.

Ve başlamak için, tarihe kısa bir giriş yapalım. Rus-Türk savaşı sırasında, uzak 1877'ye geri dönelim. O zaman yazıcı Sytin, askeri operasyonları tanımlamak için grafikleri ilk kez kullandı. Şimdi tüm bunlar bize tanıdık geliyor, herhangi bir savaşı tanımlarken, gözlerimizin önünde savaşın gidişatını açıkça gösteren oklu kartlar beliriyor. Ve o günlerde askeri operasyonlar kelimelerle anlatıldı. Her dövüş için - çok, çok kelime. Ve sonunda ne olduğunu anlamak çok zordu.

Bu nedenle Sytin'in fikri gerçekten devrimciydi - tahkimatların ve askeri birimlerin yerlerinin belirlenmesiyle haritaların litografik kopyalarını basmaya başladı. Bu kartlara “Gazete Okurları İçin” deniyordu. Fayda". Fikir o kadar alakalı oldu ki, "Yardım"ın ilk baskısı anında tükendi. Ve sonra bu tür uygulamalar büyük talep gördü. Nedeni açık. Grafikler, yalnızca kelimelerin yardımıyla neyin neredeyse imkansız olduğunu anlamaya yardımcı oldu.

Sözlü betimlemelerin çaresizliğine benzer bir örneği kendi pratiğimden de verebilirim. Müşterilerimden biri, şirketi için bir ERP sisteminin uygulamasını üstlenmemi istedi. Bir tür teknik görevleri olup olmadığını sorduğumda şu yanıtı aldım: “Evet, yapıyorlar. Ama 400 sayfası var.” Aynı zamanda müşteri, daha önce iletişime geçtiği meslektaşlarımın projeyi tamamen reddetmesinden veya açıkça şişirilmiş fiyatlar aramasından çok şikayet etti. Referans şartlarının gerçekten 400 sayfa uzunluğunda olduğunu ve yalnızca metinsel bir açıklamadan oluştuğunu gördükten sonra, geliştiricilerin davranışlarının nedenlerini anladım. Böyle bir metni okumak, içine dalmak, tüm nüansları anlamak, sadece görevi anlamak ve fiyatı belirlemek gerçekten çok zor.

Bu müşteriye alternatif bir seçenek sundum - mümkün olan her şeyi grafiksel olarak notasyonlar şeklinde açıklamak. Ona modelleme örnekleri gösterdi. Sonuç olarak, şimdi isteklerini ve görev tanımlarının tasarımını yeniden düşünüyorlar.

Ayrıca iş süreçlerinin grafik modellemesinin hem meslektaşlarıma, iş danışmanları ve geliştiricilerime hem de iş adamlarının işlerinde kendilerine yardımcı olduğu birçok başka örnek biliyorum.

Bu benim işim için neden önemli?

İşim her zaman mevcut sistemde değişiklik yapmakla ilgilidir. Ve değişiklik yapmak ve istenen sonucu elde etmek için zaten var olanı incelemeniz gerekir. Ve tam olarak ne yaptığımız önemli değil - sıfırdan bir CRM sistemi kuruyoruz veya kuruyoruz, etkili bir ERP sistemi oluşturuyoruz, genel olarak işin otomasyonunu artırmak için çeşitli sistemleri entegre ediyoruz. Her durumda, başlamak için mevcut çalışma planı hakkında bir fikir edinmek gerekir ve ancak bundan sonra bazı değişiklikler önermek ve görevi çözmek için seçenekler üzerinde düşünmek mümkündür.

Mevcut durumu inceledikten sonra, diğer tüm üçüncü taraf uzmanlar gibi, mevcut durum hakkındaki vizyonumu ve ayrıca yapılması gereken eylemleri olabildiğince ayrıntılı olarak ortaya koyduğum ticari bir teklif oluşturuyorum. görevi ve elbette beklenen sonucu çözün.

Bu tür çalışma anket raporları hacimlidir, bir yandan gerekli olan, ancak diğer yandan algıyı zorlaştıran birden fazla sayfa kaplar. İlk başta, diğerleri gibi, hacimli raporların iyi olduğunu düşündüm, çünkü bir kişi iş için para ödüyor ve ona mümkün olduğunca ayrıntılı bilgi vermeniz gerekiyor.

Yaygın hatalar

İşlevsel modelleme, modelleme amaçlı olmayanlar da dahil olmak üzere çeşitli araçlar kullanılarak gerçekleştirilir. İkinci durumda, standardın hatalarını ve sınırlamalarını kontrol etme yoktur. Görünürlüğü artırma arzusu ve deneyim eksikliği genellikle hatalarla sonuçlanır.

Farklı renklerin kullanımı

Diyagramdaki tüm öğeler eşit derecede önemlidir. Fonksiyonel modellemede az ya da çok önemli unsurlar yoktur. Herhangi birinin ortadan kalkması, sürecin kesintiye uğramasına ve üretim hatasına yol açacaktır.

Kullanıcılar genellikle kağıt üzerinde veya farklı programlarda modelleme yaparken farklı renkler kullanarak görünürlüğü artırmaya çalışırlar. Bu en yaygın hatalardan biridir. Aslında, çok renkli okların ve blokların kullanılması yalnızca ek kafa karışıklığına neden olur ve ayrıca şemanın algısını bozar.

Modeliniz herhangi bir ek renk şeması olmadan siyah beyaz olarak okunabilir olmalıdır. Bu yaklaşım aynı zamanda yanlış anlaşılmaları önlemeye yardımcı olur ve modelin yaratıcısını disipline eder, bunun sonucunda modelin okunabilirliği ve okuryazarlığı artar.

çok fazla blok

Bir model derlerken, genellikle şirketin çalışmasının tüm nüanslarını tüm ayrıntılarla birlikte tek bir sayfada göstermeye çalışırlar. Sonuç, çok sayıda kontrol okuna sahip çok sayıda bloktur. Okunabilirlik kaybolur.

En iyi seçenek, konuyu anlamak için yeterli ayrıntıyı vermektir, başka bir şey değil. Belirli bir sürecin ayrıntılı bir görünümünü seçerken, her departmanın veya hatta bir çalışanın çalışmasının ayrıntılı ayrıntıları ortaya çıkarılabilir. Ve böyle bir yapı, ancak çalışma veya karar verme için gerçekten gerekliyse oluşturulur.

Ayarlama yaparken yapının ihlali

Gelen, giden ve diğer önemli unsurlar olmadan karışıklığı veya süreçleri önlemek için dikkatlice izleyin. Örneğin yukarıdaki örnekte bakış açısını metin yazarına kaydırmayı uygun görürsem yazarı şemadan çıkarırım. Ve sonra "yazarın ve üçüncü taraf kaynakların deneyimi" ile yayın planının kontrolleri gereksiz hale gelir. Sonuçta, yazar bunları kullanıyor. Metin yazarı ses dosyasıyla çalışır. Ve genel şemada kalırlarsa, detaylandırırken anlaşılmaz bir şekilde nereye varacaklar ve kafa karışıklığı yaratacaklar.

Aynı şekilde, bir blok eklemeye karar verirsem, onun da gerekli tüm özelliklere sahip olduğundan emin olmam önemlidir. Burada dikkatli olmak çok önemlidir, çünkü karmaşık iş süreçlerini modellerken modelin bir bölümündeki değişiklikler diğerinde de değişikliklere yol açabilir. Girilmeleri gerekir.

Denetimleri ve Blokları Adlandırma Kuralları

Basit bir kuralı hatırlamak önemlidir: kontrol oklarına isim, bloklara fiil denir. Bu, IDEF0 standardında kabul edilir ve bu yaklaşım, karışıklık ve hataların önlenmesine yardımcı olur.

Çoğu zaman, blokları adlandırırken hatalar yapılır. Örneğin, "Makale oluştur" yerine "Makale oluştur" yazarlar. Bu yaklaşımdaki bloklar eylemlerdir ve bu nedenle her zaman fiil olmalıdırlar.

IDEF0 kullanmanın faydaları

• İlk fayda açıktır - görünürlüktür.Şu veya bu sistemin nasıl çalıştığını kendiniz anlamaya başlarsınız ve ayrıca bu sistemde “ince noktaların” nerede olduğunu ve çözümlerinizin onlardan kurtulmanıza nasıl yardımcı olacağını açıkça açıklayabilirsiniz.
• Karşılıklı anlayış ve anlaşmazlık eksikliği.İşlevsel modeli kullanarak şirketin çalışmalarını tartışırken, kontrollerle birlikte görsel ve sezgisel görev bloklarınız olur. Ek olarak, işlevsel modelleme, gerekirse, sembollerin ve terimlerin ortaya çıktığı bir sözlüğün oluşturulmasını içerir. Sonuç olarak, siz ve müşteriniz, yöneticiniz ve diğer çalışanlarınız bir sorunu tartışırken aynı dili konuşuyorsunuz.
• Model oluşturmanın basitliği ve yüksek hızı. Elbette modellemeyi öğrenmek göründüğü kadar kolay değildir. Sonuçta, bir şema aslında, anlamak için çok iyi olan süper yoğun bir bilgi sunumudur, ancak böyle bir sunumu uygulamak için özel bir yaklaşım gereklidir. Analistin beyni bu durumda bir yandan çok güçlü bir baskı, diğer yandan bir filtre görevi görür. Ancak tecrübe ile bu süreç çok hızlı hale gelir. Sonuç olarak, belirli bir sistemde neler olduğunu kendiniz anlamanıza yardımcı olacak bir araç elde edersiniz ve kısa sürede oluşturulan görsel bir yardım yardımıyla iş arkadaşlarınıza veya müşterilerinize önemli noktaları gösterirsiniz.
• Disiplin ve hata yok. IDEF0 standardı, katı çerçeveler ve kurallar olduğunu varsayar. Bu yaklaşım disiplinler ve standartlar çerçevesinde hareket etme alışkanlığı, dikkatsizlikten kaynaklanan hatalardan kaçınmaya yardımcı olur. Standardın herhangi bir ihlali hemen fark edilir hale gelir.

IDEF0 kullanmanın zorluğu nedir?

Sadece en basit durumlarda iki iş analistinin şirketin çalışmasını tanımlamak için tamamen aynı işlevsel modelleri yaratacağını anlamak önemlidir. Herhangi bir model, analistin deneyiminin, tanımlamaya çalıştığı işi anlama derinliğinin ve ayrıca bir şekilde bu iş hakkındaki kişisel bakış açısının bir yansımasıdır. Onlar. kişi, lidermiş gibi, liderin bakış açısından bir iş modeli geliştirir.

Aynı zamanda, bir iş analistinin tam olarak bir meslek olmadığına inanıyorum, her işletme yöneticisi veya bazı sistemlerin geliştiricisi, işi analiz eden ve en etkili sistemi kurmaya çalışan iş analitiği ile uğraşıyor. IDEF0 aracı bu kişiler ve bu amaçlar için tasarlanmıştır.

Bu nedenle, işlevsel bir iş modelini “olduğu gibi” derlerken, ayrıştırma aşamalarında otomatik olarak hatalara neden olacak hatalar yapmamak için sürekli olarak şirket başkanına danışmak çok önemlidir. Ayrıca, sonraki aşamalarda, yapısal bölüm başkanlarından ve çalışanlardan ek onaylar gerekebilir. Ancak işlevsel modeliniz "olduğu gibi" gerçek durumu gerçekten yansıtacaksa, bazı değişiklikler ve önerilerde bulunabilirsiniz. Ve bu tür çalışmalarda yüksek kaliteli sonuçlar elde etmek için, her şeyden önce, belirli bir iş türünün özellikleri hakkında pratik deneyim ve bilgi gereklidir.

Bu konuyla ilgili daha fazla makale.

Anahtar Kelimeler: yapısal analiz ve tasarım, fonksiyonel model, fonksiyonel blok, arayüz yayı, bağlam diyagramı, ayrıştırma, sözlük, amaç, bakış açısı, alt işleme, ayrıştırma, karmaşıklık sınırlaması, tünel oluşturma.

Tanım

IDEF0 (İşlev Modellemesi için Entegrasyon Tanımı) - bir işletmenin işlevlerini tanımlamak için işlevsel bir modelleme metodolojisi, iş süreci bilgi sistemlerinin analizi, geliştirilmesi, yeniden yapılandırılması ve entegrasyonu için işlevsel bir modelleme dili sunar; veya yazılım mühendisliği analizi.

IDEF0 metodolojisi, SADT (Structured Analysis and Design Technique) yapısal analiz ve tasarım yönteminin geliştirilmiş halidir.

Standart olarak IDEF0, 1981 yılında ICAM (Entegre Bilgisayar Destekli Üretim) programının bir parçası olarak geliştirilmiştir.

IDEF0 – entegrasyon Tanım dilim 0 - SADT'ye dayalı ve orijinal biçiminde her ikisini de içerir: bir grafik modelleme dilinin (sözdizimi ve anlambilim) tanımı ve modeller geliştirmek için eksiksiz (kapsamlı) bir metodolojinin tanımı.

IDEF0'ın en son revizyonu Aralık 1993'te ABD Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) tarafından yayınlandı.

1993 yılında IDEF0, Amerika Birleşik Devletleri'nde federal bir standart olarak ve 2000 yılında Rusya Federasyonu'nda bir standart olarak kabul edilmiştir.

IDEF0 Uygulaması

IDEF0 oluşturmak için kullanılır fonksiyonel model yani IDEF0 metodolojisinin sisteme uygulanmasının sonucu IDEF0 fonksiyonel modelidir.

fonksiyonel model modellenen sistem veya etki alanı içindeki işlevlerin, etkinliklerin veya süreçlerin yapısal bir temsilidir.

IDEF0 metodolojisi, hem otomatik hem de otomatik olmayan sistemlerin geniş bir yelpazesini modellemek için kullanılabilir.

Tasarım aşamasındaki sistemler için, IDEF0 önce gereksinimleri ve işlevleri tanımlamak ve ardından bu gereksinimleri karşılayan ve bu işlevleri gerçekleştiren bir uygulamaya geçmek için kullanılabilir.

Mevcut sistemler için, IDEF0 sistem tarafından gerçekleştirilen işlevleri analiz etmek ve bu işlevlerin gerçekleştirildiği mekanizmaları hesaba katmak için kullanılabilir.

IDEF0 standardının amaçları

Standardın ana amaçları (hedefleri):

IDEF0 modelleme tekniğini ve nasıl kullanılacağını belgelemek ve açıklamak;

bir sistemin veya konu alanının işlevlerinin ve bu işlevleri birbirine bağlayan veri ve nesnelerin tam ve tutarlı (tutarlı) modellemesi için bir araç sağlamak;

CASE yöntemlerinden veya araçlarından bağımsız, ancak bu yöntem ve araçlarla kullanılabilen bir modelleme dili sağlamak;

aşağıdaki özelliklere sahip bir modelleme dili sağlayın:

Genel(genel) - sistemlerin ve konu alanlarının analizi için;

katı ve kesin(kesin ve kesin) - doğru, kullanılabilir modeller oluşturmak için);

kısa bilgi(özlü) - paydaşlar arasında anlayış, iletişim, anlaşma ve doğrulamayı kolaylaştırmak. (anlama, iletişim, fikir birliği ve doğrulamayı kolaylaştırmak için);

Öz(kavramsal) - fiziksel veya organizasyonel uygulamalardan bağımsız fonksiyonel gereksinimleri temsil etmek;

esnek– proje yaşam döngüsünün çeşitli aşamalarını desteklemek.

Sertlik ve hassasiyet(Güç ve Hassasiyet)

IDEFØ kuralları, analisti aşırı kısıtlamadan ihtiyaçları karşılamak için yeterli titizlik ve kesinlik gerektirir. IDEFØ kuralları şunları içerir:

her seviyede iletilen detayların kontrolü - her bir ayrıştırma seviyesinde üç ila altı fonksiyonel blok;

Sınırlı Bağlam - yerleşik çerçevenin ötesine geçen hiçbir eksik veya fazla ayrıntı olmamalıdır;

Diyagram Arayüz Bağlantısı - düğüm sayısı, fonksiyon blokları, C numaraları ve Detay Referans İfadesi);

veri yapısı bağlantısı. (Veri Yapısı Bağlantısı) – ICOM kodları ve parantez kullanımı;

benzersiz etiketler ve başlıklar (Benzersiz Etiketler ve Başlıklar) - yinelenen başlıklar yok;

grafikler için sözdizimi kuralları (Grafikler için Sözdizimi Kuralları) - işlevsel bloklar ve oklar;

veri oku dal kısıtlamaları (Veri Oku Dal Kısıtlaması) - dallardaki veri akışı kısıtlamaları için etiketler;

verilerin Girdi ve Kontrol olarak ayrılması (Girdi ve Kontrol Ayrımı) - verilerin rolünü belirlemek için bir kural);

veri ok işaretleri. Veri Ok Etiketi Gereksinimleri (minimum etiketleme kuralları);

Kontrolün varlığı (Minimum Fonksiyon Kontrolü) – tüm fonksiyonların en az bir Kontrolü olmalıdır;

amaç ve bakış açısı (Amaç ve Bakış Açısı) - tüm modellerin bir amaç ve bakış açısı beyanı vardır.

IDEF0 ile İlgili Temel Kavramlar

Metodoloji dört ana kavram üzerine kuruludur:

fonksiyonel blok;

arayüz arkı;

ayrışma;

sözlük.

fonksiyon bloğu(Etkinlik Kutusu), dikkate alınan sistem içindeki belirli bir işlevdir.

Standardın gereksinimlerine göre, her bir fonksiyonel bloğun adı formüle edilmelidir. sözlü ruh halinde (örneğin, "hizmet sağlamak").

Diyagramda, bir fonksiyonel blok bir dikdörtgen ile temsil edilmektedir (şekil). İşlevsel bloğun dört tarafının her birinin kendi özel anlamı (rol) vardır, bununla birlikte:

üst taraf "Kontrol" olarak ayarlanmıştır;

sol taraf "Giriş" (Giriş) değerine sahiptir;

sağ taraf "Çıkış" olarak ayarlanmıştır;

alt taraf "Mekanizma" (Mekanizma) değerine sahiptir.

Pirinç. fonksiyon bloğu

Arayüz yayı/ok(Ok), fonksiyon bloğu tarafından işlenen veya bu fonksiyon bloğu tarafından temsil edilen fonksiyonu etkileyen sistem öğesini görüntüler. Arayüz yaylarına genellikle akışlar veya oklar denir.

Arayüz yaylarının yardımıyla, bir dereceye kadar sistemde meydana gelen süreçleri belirleyen çeşitli nesneler görüntülenir. Bu tür nesneler, gerçek dünyanın unsurları (parçalar, vagonlar, çalışanlar vb.) veya veri ve bilgi akışları (belgeler, veriler, talimatlar vb.) olabilir.

Bu arayüz yayının işlevsel bloğun hangi tarafına uyduğuna bağlı olarak, "gelen", "giden" veya "kontrol eden" olarak adlandırılır.

Standardın gereksinimlerine göre herhangi bir fonksiyonel bloğun en az bir kontrol arayüz arkına ve bir çıkışa sahip olması gerektiğine dikkat edilmelidir. Bu anlaşılabilir bir durumdur - her işlem bazı kurallara göre (kontrol yayı tarafından görüntülenen) gerçekleşmeli ve bir sonuç üretmelidir (giden yay), aksi takdirde dikkate alınması bir anlam ifade etmez.

Kontrol arayüzü yaylarının zorunlu mevcudiyeti, IDEF0 standardı ile DFD (Veri Akış Şeması) ve WFD (İş Akış Şeması) sınıflarının diğer metodolojileri arasındaki ana farklardan biridir.

Ayrışma(Ayrıştırma), IDEF0 standardının temel konseptidir. Ayrışma ilkesi, karmaşık bir süreç kurucu işlevlerine ayrıldığında uygulanır. Bu durumda, sürecin ayrıntı düzeyi doğrudan modelin geliştiricisi tarafından belirlenir.

Ayrıştırma, sistem modelini kademeli ve yapısal olarak bireysel diyagramların hiyerarşik yapısı biçiminde temsil etmenize olanak tanır, bu da onu daha az aşırı yüklenmiş ve kolayca sindirilebilir hale getirir.

IDEF0 kavramlarının sonuncusu sözlük(Sözlük).

IDEF0 öğelerinin her biri için - diyagramlar, fonksiyon blokları, arayüz yayları - mevcut standart, bu öğe tarafından görüntülenen nesneyi karakterize eden bir dizi uygun tanım, anahtar sözcük, anlatı ifadesi vb.

Bu kümeye denir sözlük ve öğenin varlığının bir açıklamasıdır. Sözlük, diyagramlara gerekli ek bilgileri sağlayarak görsel grafik dilini uyumlu bir şekilde tamamlar.

Modelleme. IDEF0 modeli her zaman sistemin bir bütün olarak görünümüyle başlar - söz konusu alanın ötesine uzanan arayüz yaylarına sahip tek bir işlevsel birim. Bir fonksiyonel bloklu böyle bir şemaya denir bağlam diyagramı.

Bağlam şeması için açıklayıcı metin şunları belirtmelidir: amaç(Amaç) kısa bir açıklama ve sabit olarak çizelgeleme bakış açısı(bakış açısı).

Tanım ve resmileştirme hedefler IDEF0 modelinin geliştirilmesi son derece önemli bir noktadır. Aslında amaç, incelenen sistemde öncelikle üzerinde durulması gereken ilgili alanları tanımlar.

Bakış açısı modelin ana gelişim yönünü ve gerekli detay seviyesini belirler. Bakış açısının net bir şekilde sabitlenmesi, sistem üzerinde seçilen bakış açısına göre gerekli olmayan bireysel unsurları detaylandırmayı ve incelemeyi reddederek modeli boşaltmanıza izin verir.

1. CASE-teknolojisi IDEF kullanarak bir bilgi sisteminin fonksiyonel modellemesi.
2. Etkileşim mantığının ve çalışma sırasının tanımı.

2. Ders planı

1. Test ederek bilgi kontrolü (ISE002 testi).
2. Teknolojileri kullanan BPwin CASE aracını kullanarak çok seviyeli bir bilgi sistemi etkinliği modelinin (AS - IS modeli) geliştirilmesi IDEF 0 Ve IDEF 3 :
   • Model özelliklerinin açıklaması (Model Özellikleri).
   • İşlevsel bir modelin İLK seviyesinin oluşturulması - bir bağlam diyagramının geliştirilmesi.
   • Fonksiyonel modelin İKİNCİ seviyesinin oluşturulması - bağlamsal çalışmanın detaylandırılması ve ayrıştırma diyagramının geliştirilmesi.
   • İşlevsel modelin ÜÇÜNCÜ düzeyinin oluşturulması - işlevi uygulayan ikinci düzeyin çalışmasının detaylandırılması Faaliyet muhasebesi kuruluşlar. Bu geliştirme aşamasının uygulanması, iki metodolojiden biri kullanılarak bir ayrıştırma diyagramının oluşturulmasına olanak tanır - IDEF 0 (1. seçenek) veya IDEF 3 (2. seçenek). 2. seçeneğe göre, bireysel çalışmaların yürütülmesi için bir senaryo ve bir sıra şeması oluşturulması (iş akışı şeması) faaliyetlerin muhasebe sürecinde IDEF 3 metodolojisi kullanılarak gerçekleştirilir.
3. Modelin karşılık gelen parçalarının bir tanımını görüntülemenize izin veren bir eserler sözlüğü ve bir ok sözlüğü geliştirilmesi.

1. Teknolojiyi kullanarak bir bilgi sisteminin fonksiyonel modellemesi IDEF CASE aracı kullanılarak yapılmalıdır BPwin, komut tarafından yüklenen Başlat/Programlar/Computer Associates/BPwin 4.0/BPwin4.0 . IDEF modellemesinin teknolojik süreçleri, 4. "Uygulamalı bir ders için teorik bilgiler" bölümünde açıklanmıştır.
2. Bir bağlam diyagramı geliştirirken, modellenen konu alanına karşılık gelen bilgiler kullanılarak modelin özelliklerinin aşağıdaki gibi düzenlenebileceği akılda tutulmalıdır:
   • Model adı : "İsim" firmasının faaliyetleri;
   • Proje (proje adı): "İsim" firmasının modeli;
   • Tam ad, grup;
   • Kapsam (modelleme alanı, modellemenin amacı, yani inşa edilen modelin cevaplaması gereken sorular) - örneğin, "Şirketin genel iş yönetimi: pazar araştırması, bileşenlerin satın alınması, ürünlerin test edilmesi ve satışı" veya "Şirket faaliyetlerinin teknolojik, finansal ve yönetimsel yönleri";
   • Zaman Çerçevesi (model tipi) : OLDUĞU GİBİ;
   • tanım (tanım , model atama) : "İmya" şirketinin faaliyetlerini anlatan eğitim modeli;
   • bakış açısı (bakış açısı – gelişim sırasında bakış açısı benimsenen kişi) : İşletme başkanı ve genel müdür;
   • Durum : ÇALIŞMA;
   • Amaç (hedef) : "İmya" şirketinin faaliyetlerini düzenlemek için mevcut iş süreçlerini modellemek;
   • Kaynak (bir kaynak bilgi): Konu alanının analizi ve girdi belgelerinin analizi;
   • Yazar Adı : AD SOYAD.
3. Yaparken bağlam diyagramı ayrıştırması olduğu dikkate alınmalıdır, ikinci seviye sistem modelinin ayrıştırılması, alt süreç veya alt iş , şeklinde uygulandı bu durumda işlev gören bağlamsal çalışma ebeveynlik işi, şeklinde uygulandı ebeveyn diyagramı (Ebeveyn Şeması) . İkinci seviyenin ayrıştırma diyagramı, biri modelleme işlevini yerine getirmesi gereken en az üç işlevsel blok içermelidir. muhasebe organizasyon ve geri kalanı modelleme işlevini yerine getirmelidir iş süreçleri sistemde uygulanmaktadır.
4. Her ayrıştırma adımında, arayüz yaylarının (okların) modelin alt seviyelerine otomatik olarak hareket etme sürecini izlemeli ve gereksiz yere tünelli okların oluşmasını engellemeye çalışmalısınız. Görünürlerse, tüneller kaldırılmalıdır.
5. uygularken üçüncü seviye Ayrıştırma, geliştirilen ayrıştırma diyagramlarının her birinin, ikinci düzeydeki işlerin ayrıştırılmasının üçüncü düzeyi olduğu ve temsil ettiği dikkate alınmalıdır. alt süreç veya çocuk işi, şeklinde uygulandı çocuk diyagramı (Çocuk Diyagramı)üçüncü seviyenin ilgili çalışması. Bu durumda ikinci seviyenin tüm çalışmaları şu şekilde hareket eder: ebeveynlik işi, şeklinde uygulandı ebeveyn çizelgeleri(Ebeveyn Diyagramları).
6. İkinci seviyedeki işin ayrıştırılması, muhasebe fonksiyonunun modellenmesi ve işlerin etkileşimi için bir senaryonun oluşturulması teknoloji kullanılarak yapılmalıdır. IDEF3, fonksiyon blokları olarak kullanan birimlerİş (İş Birimi, UOW) , ayrıca gerekli referans nesneleri (Referanslar) , ok sözlüğünden komut dosyasına dahil edilebilir veya yeniden oluşturulabilir.
7. Her model ayrıştırma düzeyinde bir iş sözlüğü ve bir ok sözlüğü oluşturulur ve bunların geliştirilmesi için gerekli bir koşul, bir iş tanımının varlığıdır. (aktivite) ve arayüz arkına kaydedilen verilerin açıklamaları ( ok) .
8. Çalışmanın sonuçlarını bir dosyaya kaydedin Function_Model IS_Name_ IDEF.bp1 klasörünüzde İMKB.
9. Genelleştirilmiş bir fonksiyonel modelin bir örneği şurada verilmiştir:

4. Pratik bir ders için teorik bilgiler

4.1. IDEF 0-teknoloji

IDEF0 metodolojisi, bir organizasyonun faaliyetlerini modellemek için tasarlanmıştır. Proje geliştirmenin ilk aşamasında, işletmedeki mevcut iş süreçlerini ve teknolojik süreçleri “OLDUĞU GİBİ” (“Olduğu Gibi”) ilkesine göre tanımlamak için bir model oluşturulur ve daha da önemlisi işletmeyi perspektiften temsil eder. bunun için çalışan ve gayri resmi olanlar da dahil olmak üzere tüm nüansları tam olarak bilen çalışanların sayısı. OLDUĞU GİBİ, “yarın ne yapacağız” a geçmeden önce “bugün ne yapıyoruz”.

Etkinlik Modeli veya başka bir deyişle, fonksiyonel model. fonksiyonel model sistemi bir küme olarak ele alır eylem, hangisinde her eylem bazılarını dönüştürür bir obje veya nesneler kümesi . teknoloji IDEF 0 prensibi kullanır fonksiyonel ayrışma sistemler (sistemi parçalara ayırma). Ayrışma ilkesi fonksiyonel modelin kurala göre inşa edilmesi gerektiği anlamına gelir. "yukarıdan aşağıya" , itibaren Genel model tipi özel modeller. Bu nedenle, genellikle bir problemi çözmek için işlevsel bir model, bir kümedir. özel fonksiyonel modeller .

Fonksiyonel modeller, özel bir unsur olarak temsil yoluyla faaliyetleri vurgular - engellemek. Engellemek – grafiksel temsili olan fonksiyonel modelin ana yapısal unsuru diyagram . Eylem adı – isim fiil veya fiil . Model ayrıştırmasının bir sonucu olarak, hiyerarşik olarak sıralanmış ve birbirine bağlı bir dizi diyagram oluşturulur. Her diyagram bir sistem açıklaması birimidir ve ayrı bir sayfada bulunur.

metodoloji IDEF 0 dört temel konsepte dayanmaktadır: fonksiyonel blok (düğüm), arayüz yayı, ayrıştırma, sözlük.

fonksiyon bloğu

Temel teknoloji kavramı IDEF 0 kavramdır fonksiyon bloğu. Belli bir türü temsil etmek içindir faaliyetler (Etkinlik) , bazı özel işlev düşünülen sistem içinde Bu işlev, sırayla, bazı eylemler (bir dizi eylem) anlamına gelir, sabit bir hedefe sahip olmak ve bir sonuca ulaşmak.

fonksiyon bloğu kenarları aşağıdaki değerlere sahip bir dikdörtgen ile temsil edilir:

• Üst taraf kontroldür.
• Alt kısım mekanizmadır.
• Sağ taraf çıkıştır.
• Sol taraf giriştir.

İşlev bloğu, sözlü ruh halinde veya sözlü bir isim olarak belirtilen bir ada sahiptir. Eylem arasındaki etkileşim ve etrafındaki dünya, diğer eylemler de dahil olmak üzere, arayüz yayları (oklar) kullanılarak görüntülenir.

Arayüz yayı

Arayüz yayı sistem öğesini görüntüler, hangi veya işlenmiş fonksiyon bloğu veya farklı bir etkiye sahip bu işlevsel blok tarafından görüntülenen aktiviteye (işlev) Arayüz yayı gösteren bir ok olarak tasvir edilmiştir. taşıyıcı Verileri veya nesneleri bir etkinlikten diğerine aktaran bir araç. Oklar, eserlerin dış dünya ile ve kendi aralarındaki etkileşimini tanımlar, bazı bilgileri temsil eder ve denir. isimler .

Okun adı onu belirtir rol (olası roller kümesi - ile gösterilir BEN COM ):

Fonksiyon bloğu girişi - i girdi .

Yönetmek - C kontrol .

Fonksiyon bloğu çıkışı - Ö çıktı .

mekanizma - m mekanizma .

Giriş) bir sonuç (çıktı) elde etmek için çalışma tarafından kullanılan veya dönüştürülen materyal veya bilgidir. Giriş oku olmayabilir.

Kontrol– işi yöneten kurallar, politikalar, prosedürler veya standartlar. Çalışmayı etkiler, ancak çalışma tarafından dönüştürülmez. Ok, işin üst yüzüne girerken çizilir. Her fonksiyon bloğunda en az bir kontrol oku olmalıdır.

Verinin girdi mi yoksa kontrol mü olduğunu belirlemek genellikle zordur. Çalışmadaki veriler değiştirilirse veya işlenirse, bu büyük olasılıkla bir girdidir ve değilse kontroldür. Bir okun durumunu belirlemek zorsa, bir kontrol oku çizilmesi önerilir.

Çıktıİş tarafından üretilen malzeme veya bilgi. İşin sağ tarafından en az bir çıkış oku gelmesi zorunludur.

Yürütme mekanizması (Mekanizma)– işi gerçekleştiren kaynaklar (örneğin, personel, makineler, cihazlar, vb.). Ok, işin alt yüzüne girerken çizilir. Mekanizma ibreleri görüntülenmeyebilir. Genel olarak, fonksiyonel blok Şekil 2'de gösterilmektedir. 2.1.

Şek. 2.1 tüm arayüz yayları adlandırılmış oklar olarak gösterilir. Standardın gereksinimlerine göre, her bir görev (süreç) çözümü için en az bir çıktı ve en az bir kurala sahip olması gerektiğinden, her işlevsel bloğun en az bir çıktısı ve bir kontrolü olmalıdır. Arayüz yayı "Mekanizma" görüntülenmeyebilir.

Arayüz yaylarıyla gerekli şekilde bağlanan birkaç fonksiyonel bloktan, fonksiyonel model.

İşlevsel blokların gerekli bağlantılarını yapmak için okların dallanabileceğini unutmayın.

giriş fonksiyonel blok sadece çıktı başka bir işlevsel blok, aynı zamanda onun kontrol ya da mekanizma. Sonuç olarak, işlevsel modelde, bilgi sistemindeki sorunları çözmek için çeşitli, oldukça karmaşık ve olağandışı süreçler olabilir.

IDEF0 teknolojisinde diyagramlar oluşturma

Bir kuruluşun faaliyet modeli geliştirilirken üç tür diyagram kullanılmalıdır:

• Diyagram Tip I – Bağlam Diyagramı (sadece bir tane olabilir) - sistemin tanımının ve dış çevre ile etkileşiminin en soyut seviyesi olan ağaç yapısının tepesi. tanımlar bağlam işlevi;
• II grafik türü - Ayrışma grafiği .

Ayrışma diyagramları, çalışmayı detaylandırmak için tasarlanmıştır ve şunları içerir: ilişkili iş, yani çocuk ortak olan işler ebeveynİş. Alt seviye işler, üst seviye işler ile aynıdır, ancak daha detaylıdır. Diyagramlar, bir inceleme oturumu yürütmek, yani diyagramı bir konu uzmanıyla tartışmak için bir analist tarafından oluşturulur.

Her ayrıştırma oturumundan sonra, inceleme oturumları düzenlenir - konu uzmanları, gerçek iş süreçlerinin oluşturulan diyagramlara uygunluğunu gösterir. Bulunan tutarsızlıklar düzeltilir ve ancak sınavı geçtikten sonra açıklamalar olmadan sonraki ayrıştırma oturumuna geçebilirsiniz. Bu, modelin, modelin her seviyesinde gerçek iş süreçleriyle eşleşmesini sağlar.

Çalışma sayısını altıdan (3-6) fazla olmayacak şekilde ayarlamak gerekir, aksi takdirde diyagram zayıf okunabilir (aşırı doygun). Üst sınır (altı), tasarımcıyı karmaşık konuları tanımlarken hiyerarşileri kullanmaya zorlar ve alt sınır (üç), karşılık gelen diyagramın, yaratılışını doğrulamak için yeterli ayrıntıya sahip olmasını sağlar.

Ayrışma diyagramında sol üstte en önemli ve ilk yapılan iştir. Daha az önemli olan veya daha sonra gerçekleştirilen işler sırayla azalır.

• Şema Tip III – Düğüm Ağacı Şeması işlerin hiyerarşik bağımlılığını gösterir, ancak işler arasındaki ilişkiyi göstermez (ağaç herhangi bir derinliğe inşa edilebileceğinden ve mutlaka kökten olması gerekmediğinden, bu diyagramlardan herhangi bir sayıda olabilir).

4.2. Teknolojik süreç IDEF0-simülasyonu:

Pirinç. 2.2

BPWin CASE aracı, gerekli işlevsel modelleri ve senaryoları oluşturmak için basit ve sezgisel bir kullanıcı arayüzüne sahiptir. Kullanılan teknolojiye bağlıdır. Şek. 2.2 BPWin penceresini gösterir ( Bilgisayar Ortakları BPWin ).

Ana pencere araç çubuğu Bilgisayar Ortakları BPwin aşağıdaki düğmeleri içerir:

	– yeni bir modelin oluşturulması,
	– mevcut bir modelin açılması,
	– inşa edilen modeli kaydetme,
	- modelin basılması,
	- ölçek seçimi
	- ölçekleme,
	- yazım denetimi,
	– model gezginini etkinleştirme/devre dışı bırakma,
	– Model Mart'ı açın/kapatın.

Model gezgini, modelin geliştirme düzeyine göre bileşimini gösterir. Bununla, seviyeden seviyeye kolayca ve hızlı bir şekilde geçebilirsiniz. Model gezgini ile çalışmak, Windows Gezgini ile çalışmaya benzer.

Özel araç çubuğu aşağıdaki ana düğmeleri içerir:

Model penceresi, incelenen sistemin işlevsel bir modelini oluşturma yeridir. İçinde fonksiyonel bloklar oluşturulur ve düzenlenir, oklar çizilir ve düzenlenir ve ayrıştırma gerçekleştirilir.

Model hazırlama

1. İletişim kutusunu açmak için model oluştur düğmesine tıklayın BPWin(Şekil 2.3):

iletişim kutusunda BPWin aşağıdaki eylemleri gerçekleştirin:

• Seçme İş Süreci (IDEF0);
• model adını ayarlayın ve düğmesine tıklayın Tamam;
• pencerede Yeni Modelin Özellikleri modelin yazarının adını düzeltin;
• düğmesine basın Tamam .

1. takım Model/Model Özellikleri bir iletişim kutusu aç Model Özellikleri (Şekil 4), modelin özelliklerinin bölüm 2'de özetlenen metodolojik önerilere göre düzenleneceği yer.

İlk seviye modelleme

1. Aşağıdakileri yaparak model penceresindeki işlevsel bloğu süsleyin:
   • fonksiyon bloğunun içerik menüsünde komutu seçin İsim… ;
   • iletişim kutusunda Aktivite Özellikleri (Şekil 2.5) sekmesinde İsim Sor isim bu fonksiyon bloğuna ve sekmeye yerleştirilen çalışma (kısa) Tanım tarlada Tanım tanımİş;
   • yer imi Yazı tipi yazı tipini ayarla Arial Cyr ve bu yazı tipini diyagramın tüm fonksiyon bloklarında kullanmak için onay kutularını ayarlayın ( Bu şemadaki tüm etkinlikler, Bu modeldeki tüm etkinlikler Ve Bu yazı tipinin tüm oluşumlarını model ), ardından düğmesine basın Tamam.

• iletişim kutusunda Ok Özellikleri (Şekil 2.7), sekmesinde İsim okun adını (kısa) ayarlayın ve sekmede Tanım tarlada Tanım yeterince ayrıntılı girin tanım bu okun hedefi;

• okun içerik menüsünde komutu seçin Yazı tipi… ;
• iletişim kutusunda Ok Özellikleri (Şekil 2.8), sekmesinde Yazı tipi yazı tipini ayarla Arial Cyr ve tüm grafik okları için bu yazı tipini kullanmak için kutuları işaretleyin ( Bu diyagramdaki tüm Oklar, Bu modeldeki Tüm Oklar, Bu Ok'un tüm örnekleri Ve Modelde bu yazı tipinin tüm oluşumlarını değiştir );

1. ok ok Çıktı, ayrıldı sınırlar Sağ;
2. ok ok Kontrol , bunun için 2. adımı tekrarlayın, ayrıldı sınırlar üst;
3. ok ok mekanizma, neden değiştirerek 2. adımı tekrarlayın ayrıldı sınırlar daha düşük.

İkinci seviye modelleme

Herhangi bir modelleme seviyesi

Herhangi bir modelleme seviyesinde bir model ayrıştırması oluşturmak için şu adımları izleyin:

• belirli bir fonksiyon bloğunu etkinleştirmek için tıklayın;
• modelin mevcut seviyesi için 3. adımı tekrarlayın.

1. Ok tasarımının türü ve stili, okun bağlam menüsünden Stil komutuyla çağrılan Ok Özellikleri iletişim kutusunda (Şekil 2.9) seçilebilir.

1. Kurulum için kelime kaydırma adı vurguladıktan sonra, dikdörtgenin boyutunu küçültün, ardından otomatik olarak aşağı doğru artacaktır.
2. Daha yüksek seviyeli bir diyagramda çizilen her ok, daha düşük seviyeli bir diyagramda bulunmalıdır.
3. Düşük seviyeli diyagramda çizilen yeni ok (çözülmemiş ( çözülmemiş) ok), böyle bir okun yokluğunu daha yüksek bir seviyede vurgulayan köşeli parantezler (tünel) içine yerleştirilir. Tünelleri kaldırmak için:
   • menü öğesini seç Ok Tüneli ;
   • iletişim kutusunda Kenar Ok Düzenleyicisi(Sınır Ok Düzenleyicisi) seçeneği seçin Border Arrow olarak çöz (Sınır oku olarak izin ver). Sonuç olarak, mevcut seviyedeki tünel kaldırılacak ve bir önceki seviyede ok görünecek ve eğer ilk değilse tünel açılmıştır (Şekil 2.10).

1. Tünelli okları alt seviyeden üst seviyeye kopyalamak için:
   • köşeli parantezlere sağ tıklayın;
   • menü öğesini seç Sayfa Dışı Referans;
   • iletişim kutusunda Off_Page Ok Referansı okun yerleştirileceği diyagramı seçin ve gerekli ok tipi anahtarı ayarlayın (Şekil 2.11);

• düğmelerden birine basın: Tamam ve Diyagrama Git (seçilen şemaya gidin) veya Tamam ve Mevcut Diyagramda Kal (geçerli şemada kalın).

Serbest sınır okları bırakarak ( bağlantısız sınır oku) – ana diyagramdan otomatik olarak ayrıştırma diyagramına aktarılan oklar (mod göç atıcı). Bu oklar işlerle ilgili değildir ve Ok Oluşturma modundaki işlerle bağlantılı olmalıdır ( Öncelik Ok Aracı – ).

Okların varsayılan olarak doğru konumunu ve stilini yapmak:

• komut çalıştır Model/Model Özellikleri;
• pencerede Model Özellikleri(Şekil 2.12) bir yer imi seçin Yerleşim ;
• onay kutusu (seçenek) Otomatik olarak boşluk okları grup içinde oklar

1. Ok oluştururken yönetim geri bildirimi ok yönünü belirtmek için seçeneği ayarlayın Ekstra Ok Ucu (bağlam menüsünden).
2. Oklardaki etiketler başarısız bir şekilde yerleştirildiyse (çok uzak vb.), etiketi yerleştirmek için Squiggle onay kutusunu (bağlam menüsünde) seçmelisiniz.

1. Ayrışma şemasında, sol üstte, en önemli ve ilk olarak yapılan işi içeren bir fonksiyonel blok vardır. Daha az önemli olan veya daha sonra gerçekleştirilen işler sırayla azalır.
2. kelime kaydırma işin içinde modda gerçekleştirilir isim düzenleyici… bir tuşa basarak Giriş.
3. Dikdörtgenin sol üst köşesindeki köşegen, karşılık gelen çalışmanın ayrıştırılmadığı anlamına gelir.
4. Yalnızca otomatik olarak görünen alt işlerin sayısını değil, aynı zamanda (A) öneklerini de göstermek için komutu seçmelisiniz. Model/Model Özellikleri, yer imi numaralama, onay kutusu (seçenek) Ön eki göster(Şekil 2.13).

1. Alt işler için iş numaralarını ve seviye numaralarını (iki, üç, dört basamaklı sayılar) göstermek için komutu seçin Model/Model Özellikleri, yer imi numaralama, onay kutusu (seçenek) Diyagram numaralandırma biçimini kullan (Şekil 2.13).
2. Aynı diyagramın farklı versiyonlarını ayırt etmek için, ayrı versiyonlara menüde keyfi olarak ayarlanmış numaralar (C - numarası) atanmalıdır. Diyagram Özellikleri yer iminde takım.

Model ağacının oluşturulması

• takım Diyagram/Ekle/Düğüm Ağacı bir iletişim kutusu aç Düğüm Ağacı Sihirbazı_Adım 1 / 2 (Şekil 2.14);
• gerekli sayıda düğüm ağacı seviyesini seçerek bir diyalog yürütün ( Seviye sayısı );
• düğmesine basın Hazır.

4.3. IDEF3 teknolojisi

teknoloji IDEF3 dikkate alan bir süreç tanımlama metodolojisidir. yürütme sırası Ve sebep sonuç ilişkileri durumlar ve olaylar arasında. IDEF3'ü kullanarak iş yürütme mantığını, başlama ve tamamlama sırasını tanımlarlar.

IDEF3 teknolojisi kategoriyi kullanır senaryolar karmaşık çok aşamalı bir sürecin açıklamalarının yapısını basitleştirmek. Senaryo (Senaryo) – bir organizasyonda veya sistemde mevcut olan tipik bir problem sınıfını tanımlayan tekrar eden bir durum veya eylemler dizisi ve ayrıca incelenen süreç içindeki nesne özellikleri dizisinin bir açıklamasıdır. IDEF0 modelleri, IDEF3 betikleri ile ilişkilidir, çünkü her IDEF0 modeli bir veya daha fazla IDEF3 betiği olarak temsil edilebilir.

IDEF3 teknolojisi, süreç verilerinin toplanması için tasarlanmıştır ve şunları yapmanızı sağlar:

• Konu alanındaki uzmanların bir anketi sırasında, örneğin, sürecin teknolojisi hakkında mevcut verileri belgelemek;
• mevcut süreçleri analiz etmek ve yenilerini geliştirmek;
• durumları belirleyerek modelleri modelleyin. karar verme sürecin yaşam döngüsünü etkileyen, örneğin nihai ürünün tasarımında, teknolojik veya operasyonel özelliklerinde bir değişiklik;
• sürecin yeniden düzenlenmesinde optimal kararların benimsenmesini teşvik etmek.

IDEF3 teknolojisinde senaryo

Senaryo Diyagramları Belirli bir süre içinde işlenmesi gereken eylemleri ve olayları tanımlar. Senaryoya süreçlerin bir açıklaması eşlik eder ve sistemin her işlevini belgelemek için kullanılabilir. Bu nedenle senaryolar, durumu zamanında analiz etmeyi ve aynı anda bir sürece katılan nesneleri tanımlamayı mümkün kıldıkları için sistem analizinin bir parçasıdır.

IDEF3 teknolojisini kullanırken, tüm yapılar iki tür diyagrama dayanır:

1. İşlem adımlarının sırasını açıklayan diyagram.
2. Nesne durum diyagramı.

Aşağıdaki standart sözleşmeler kullanılır:

	Davranışın işlevsel öğesi,
	Bir eylemin bir işlevsel davranış öğesinden (önceki) diğerine (sonraki) aktarılması ( öncelik ),
	İşten işe veri akışının geçişi ( nesne akışı ),
	Verilerin işe ilişkisi ( Açıklaması ),
	Eserler arası iletişim ( ilişkisel ),
	Nesnenin durumu.

İş birimlerinin yürütme sırasının düzenlenmesi, şemaya dahil edilerek gerçekleştirilir. kavşak (Kavşak noktası) farklı amaçlar için.

sembol J kesişim aşağıdaki değerlerden birini alabilir:

• & – birleşme oklar kesişme noktasına girerse tüm eylemlerin sonuçları; başlatmak oklar dışarı çıkarsa tüm eylemler;
• HAKKINDA - birleşme girdi eylemlerinden en az biri tamamlanmışsa eylemlerin sonuçları; başlatmak en az bir eylem
• X - birleşme kavşakta yer alan bir sayıdan yalnızca bir eylem; başlatmak ondan ortaya çıkan tek bir eylem.

Bir kavşak kullanımının bir gösterimi işlem adımlarının sırasını açıklayan diyagramlarşek. 2.15. Bundan, kesişmenin karmaşık dallı teknolojik süreçler oluşturmanın bir yolu olduğu sonucu çıkar.

İlk olarak geliştirilen veya araştırılan teknolojinin tanımı teknolojik sürecin aşamalarının sırasını açıklayan diyagramlar , ve sonra formda nesne durum diyagramları gerçekleştirilen eylemlerin ve uygulama sonuçlarının tam bir resmini verir.

	İş 3, İş 1 ve İş 3 yapıldığında gerçekleşir
	İş 1 ve İş 2 birlikte gerçekleşir
	İş 3, İş 1 veya İş 2 veya her ikisi birden yapıldığında gerçekleşir
	İş 1 ve İş 2 birlikte veya ayrı ayrı gerçekleşir
	İş 3, İş 1 veya İş 2 yapıldığında gerçekleşir
	İş 1 veya İş 2 devam ediyor

Sonuç olarak, bilgi sistemleri yöneticilerinin ve geliştiricilerinin elinde, çalışma ve otomasyon gerektiren karmaşık yönetim süreçleri için senaryolar oluşturmak için güçlü bir araç vardır.

4.4. IDEF3 modelleme iş akışı

Model hazırlama

1. Bir model oluşturmak için düğmeye basın.
2. iletişim kutusunda BPWin aşağıdakileri yapın:
   • Seçme Süreç Akışı (IDEF3);
   • modelin adını ayarlayın;
   • düğmesine basın Tamam;
   • iletişim kutusunda Yeni Modelin Özellikleri orada belirtilen özellikleri onaylayın.

Eylem yapmak

1. Eylem oluştur düğmesine tıklayın ( Etkinlik Kutusu Aracı ).
2. Model penceresinde istenen konumda farenin sol düğmesine tıklayın.
3. Eylemin bağlam menüsünde, komutu seçin İsim…
4. iletişim kutusunda Aktivite Özellikleri, yer iminde İsim eylemin adını ayarlayın (Şekil 2.16).

1. iletişim kutusunda Aktivite Özellikleri yer imi Yazı tipi Sor Arial Cyr, Tamam.

Veri biçimlendirme

1. Veri oluştur düğmesini tıklayın. ( Referans Aracı ).
2. pencerede doğru yerde Açıklaması oluşturulan varlık sözlüğünden veri adlarını gömmek için sol tıklayın (seçenek varlık) veya oluşturulan ok sözlüğünden (seçenek Ok) veya yeniden oluşturun (seçenek Diğer) (Şekil 2.17).

1. diyalogda Referans Özellikleri penceresi (Şekil 2.18) sekmesinde Yazı tipi Sor Arial Cyr gerekli onay kutularını seçin ve düğmesine tıklayın Tamam.

5. Bir sonraki ders için ödev

1. Bilgi kaynakları veya alıcıları olan maddi nesneleri veya bireyleri (dış varlıklar) düşünün ve tanımlayın.
2. Bilgi sistemi tarafından işlenen ilişkisel bir veri modeli üzerinde düşünün ve geliştirin:
   • varlıkların ve niteliklerinin bir listesini yapmak,
   • varlıklar arasındaki ilişkileri gösterir.
3. Geliştirilen görev tanımlarına dayanarak, ikinci seviye ayrıştırma şemasında yer alan anahtar çalışmaların her birini gerçekleştirme sürecinde sistemde uygulanan bireysel çalışmaların adlarını öğretmene düşünün ve sunun.
4. p.p.'nin yerine getirilmesi 1–3 ev ödevini “adlı bir dosyada düzeltin” 3. ders için bilgiler.doc ”, Word'de yapıldı ve öğretmene sunuldu.
5. Bölüm boyunca çalışın Pratik bir ders için teorik bilgiler» 3. derste atölye çalışması.

1.6. İkinci seçeneğe (IDEF3) göre faaliyetler için blok muhasebesinin ayrıştırılması sırasında düğüm ağacının diyagramının parçası (Düğüm Ağacı Şeması)

Etkinlik Sözlüğü

İsim	Tanım
	Belirtilen kriterleri karşılamak için veri tabanından okunan bilgilerin analizi
Doküman Analizi	Mevzuata uygunluk için eşlik eden ve gelen belgelerin analizi
Veritabanı Bakımı	Veri Yenileme İşlemlerini Gerçekleştirme
GERÇEKLEŞTİRİLDİ GÖREV	Simülasyonun AMACI ve SINIRLARINI tanımlayan bağlam fonksiyonunun adı
Bitiricilik	Bir karar verme ve formüle etme (veriler belirtilen kriterleri karşılıyorsa POZİTİF, aksi takdirde OLUMSUZ), ayrıca gerekli belgelerin oluşturulması ve işlenmesi
Kalite kontrol ve test	Bir üretim veya geliştirme sürecini tamamlayan çalışma
Veri işleme	Veri arama ve analiz işlemlerinin gerçekleştirilmesi ve analize dayalı olarak karar verilmesi
Kalite kontrol sonuçlarının işlenmesi	Standarda uygunluk için sonuçların sistematizasyonu ve analizi
Test sonuçları işleniyor	Servis verilebilirlik, güvenilirlik ve beka için sonuçların analizi
evrak	Veritabanına girmek için belgelerin kabulü ve bilgilerin seçimi
	Kullanıcı tarafından oluşturulan sorgulara dayalı olarak veritabanı tablolarında veri arama
Veritabanı yenileme	Veritabanı tablolarına yeni veri girme
Belgelerin alınması ve kaydı	Gelen eşlik eden belgelerin kabulü ve kaydı
Üretim veya geliştirme	Şirketin ana iş sürecinin adı (konu alanının üretim bölümünün modeli)
İş sürecinin 1. aşamasında çalışın1	Üretim sürecinin ilk aşamasında teknolojik işlemleri özetleyen bir eylem
İş sürecinin 2. aşamasında çalışın1	Üretim sürecinin ikinci aşamasında teknolojik işlemleri özetleyen bir eylem
İş sürecinin 3. aşamasında çalışın1	Üretim sürecinin üçüncü aşamasında teknolojik işlemleri özetleyen bir eylem
Üretim faaliyetlerinin sonuçlarının işlenmesi	Devam eden çalışma ve kontrol sonuçlarına dayalı olarak belgelerin kabulü ve analizi
Veritabanı düzenleme	Veritabanı tablolarındaki kayıtları değiştirme
MUHASEBE	Belge işleme ve raporlama (üretim dışı alan modeli)

Ok Sözlüğü

İsim	Tanım
	Standardın gerekliliklerini karşılamayan nesneler
GİRİŞ VERİLERİ	Gelen belgeler ve işleme nesneleri
DB girişi	Veritabanı tablolarına yazılacak veriler
Gelen Belgeler	İşleme nesnelerine eşlik eden belgeler ve bir iş sürecini başlatan belgeler
ÇIKTI	Giden belgeler, yeni ve değiştirilmiş nesneler
Giden belgeler	Muhasebe sürecinde oluşturulan belgeler (formlar, raporlar, talimatlar, beyanlar, sözleşmeler vb.)
devlet standardı	Evrak işleri için devlet standardı
DB tablo verileri	Veritabanı tablolarından okunan veriler
Analizden elde edilen veriler	Giden belgelerin işlenmesine yönelik ve karar vermede kullanılan bilgiler
Belgelerle çalışmanın sonuçlarını karakterize eden veriler	İşlenen nesnelerin ayrıntılarını (nitel ve nicel özellikleri) yansıtan bilgiler
Test ve kontrol sonuçlarına ilişkin belgeler	Nesnelerin işlenmesinin son aşaması aşamasında elde edilen verileri yansıtan belgeler
İş tanımı	Sanatçının görevlerini yansıtan talimat
Kullanıcı istekleri
Yeni ve değiştirilmiş nesneler	Üretim döngüsünün uygulanması sırasında oluşturulan ve değiştirilen nesneler
veritabanı nesneleri	Tablolar, formlar, sorgular, raporlar, makrolar ve modüller
Nesneleri işleme	Üretim sürecinin yürütülmesinin farklı aşamalarında değişen nesneler
1. aşamada işlenen nesneler	Üretim sürecinin 1. aşamasında değiştirilen nesneler
2. aşamada işlenen nesneler	Üretim sürecinin 2. aşamasında değiştirilen nesneler
3. aşamada işlenen nesneler	Üretim sürecinin 3. aşamasında değiştirilen nesneler
	Oluşturulan nesnenin standardın gerekliliklerine uygunluğunu kontrol eden teknik kontrol departmanı
Şirketin bölümleri ve uzmanlar-uzmanlar	Üretim sürecinde veya geliştirme sürecinde yer alan kuruluşlar
PERFORMANS KURALLARI	İşlem ve Veri Dönüştürme Kuralları
muhasebe kuralları	Üretim sürecine veya geliştirme sürecine eşlik eden belgelerin muhasebe ve kayıt sistemi
KARAR	Analiz edilen verilerin belirtilen kriterlerle tatmin edilmesine bağlı olarak verilen olumlu veya olumsuz bir karar
Kabul Edilen Belgeler	Kayıt altına alınan belgeler
Yazılım	Geliştirilen veritabanının uygulandığı platform
Doküman Analizi Sonuçları	Standartlara uygunluk için gelen ve beraberindeki belgelerin analizinden sonra elde edilen sonuçlar
Kalite kontrol sonuçları
arama sonuçları	Kullanıcı istekleriyle elde edilen veritabanı tablolarından bilgiler
Test sonuçları	İşlemenin son aşamasında alınan veriler
Kullanici rehberi	Veritabanıyla çalışmak için talimatlar ve kurallar
muhasebe hizmeti	Muhasebe ve dokümantasyon sürecinde yer alan departmanlar
eşlik eden belgeler	Gelen işleme nesnelerine eşlik eden belgeler
Uzmanlar-profesyoneller	Üretim faaliyetlerinde yer alan kuruluşlar
teknolojik talimat	Süreç akışı
Kullanıcı istekleri	Veritabanından gerekli bilgileri seçmek ve çıktı belgeleri oluşturmak için kullanıcı tarafından oluşturulan sorgular
YÜRÜTME MEKANİZMASI	Girdiyi çıktıya dönüştüren kaynaklar
Yeni girişler	Yeni veriler girildikten sonra ortaya çıkan veritabanı tablolarındaki kayıtlar
Düzeltme
	Sınavı yapan konu

Baskı versiyonu

İşletmenizin fonksiyonel yapısını görmeyi ve anlamayı öğrenin!

Şu anda, Batı'da genel olarak kabul edilen yönetim standartlarına ilgi Rusya'da keskin bir şekilde arttı, ancak gerçek yönetim uygulamasında çok önemli bir an var. Birçok yönetici, şirketin organizasyon yapısı veya mevcut iş süreçlerinin şeması hakkında doğrudan bir soruyla hala şaşkına dönebilir. En gelişmiş ve düzenli olarak okuyan ekonomik dergi yöneticileri, kural olarak, yalnızca kendileri tarafından anlaşılabilen hiyerarşik diyagramlar çizmeye başlarlar, ancak bu süreçte genellikle hızla durma noktasına gelirler. Aynı durum, çeşitli hizmet ve fonksiyonel birimlerin çalışanları ve başkanları için de geçerlidir. Çoğu durumda, bir işletmenin faaliyet göstermesi gereken tek kurallar dizisi, bir dizi ayrı düzenleme ve iş tanımıdır. Çoğu zaman, bu belgeler bir yıldan daha uzun bir süre önce derlenmiştir, kötü yapılandırılmıştır ve birbiriyle ilgisizdir ve sonuç olarak raflarda toz toplar. Şu an için böyle bir yaklaşım haklıydı, çünkü Rus piyasa ekonomisinin oluşumu sırasında rekabet kavramı pratikte yoktu ve maliyetleri hesaplamaya özel bir gerek yoktu - kâr devasaydı. Sonuç olarak, son iki yılda oldukça anlaşılır bir tablo gördük: 90'ların başında büyüyen büyük şirketler, piyasadan tamamen çekilmeye kadar yavaş yavaş zemin kaybediyor. Bu kısmen, işletmede yönetim standartlarının getirilmemesinden kaynaklanmaktadır, işlevsel bir faaliyet modeli ve misyon kavramı tamamen yoktur. Çeşitli faaliyet alanlarını modelleyerek, yönetimdeki "darboğazları" etkin bir şekilde analiz etmek ve genel iş planını optimize etmek mümkündür. Ancak, bildiğiniz gibi, herhangi bir işletmede, yalnızca doğrudan kâr getiren projeler en yüksek önceliğe sahiptir, bu nedenle genellikle faaliyetlerin incelenmesi ve yalnızca şirket yönetimindeki somut bir kriz sırasında yeniden düzenlenmesi sorunudur.

1990'ların sonlarında, pazar rekabetçi olmaya başladığında ve işletmelerin karlılığı düşmeye başladığında, yöneticiler, ürünlerin hem karlı hem de rekabetçi kalmasını sağlamak için maliyetleri optimize etmeye çalışmakta büyük zorluk hissettiler. Tam o anda, bir işletme içindeki çeşitli alt sistemlerin birbirine bağlanmasının tüm mekanizmalarını ve ilkelerini yansıtacak bir işletmenin faaliyet modeline sahip olma ihtiyacı açıkça ortaya çıktı.

"İş süreçlerinin modellenmesi" kavramı, kurumsal yönetimin karmaşık otomasyonu için tasarlanmış karmaşık yazılım ürünlerinin piyasaya çıkmasıyla aynı anda çoğu analistin hayatına girdi. Bu tür sistemler her zaman şirketin faaliyetlerine ilişkin derin bir proje öncesi anketi gerektirir. Bu anketin sonucu, faaliyetlerin yönetimindeki "darboğazları" ortadan kaldırmak için tavsiyelerin ayrı paragraflarda sunulduğu bir uzman görüşüdür. Bu sonuca dayanarak, otomasyon sisteminin uygulanmasından hemen önce, iş süreçlerinin sözde yeniden düzenlenmesi, bazen şirket için oldukça ciddi ve acı verici bir şekilde gerçekleştirilir. Bu, elbette, yıllar içinde gelişen bir ekibin "yeni bir şekilde düşünmesini" sağlamak her zaman zordur. İşletmelere ilişkin bu tür kapsamlı anketler her zaman karmaşıktır ve durumdan duruma önemli ölçüde farklılık gösterir. Karmaşık sistemlerin modellenmesine ilişkin bu tür sorunları çözmek için yerleşik metodolojiler ve standartlar vardır. Bu standartlar, IDEF metodoloji ailesini içerir. Onların yardımıyla, çeşitli bölümlerdeki çok çeşitli karmaşık sistemlerin aktivite modellerini etkin bir şekilde görüntüleyebilir ve analiz edebilirsiniz. Aynı zamanda, sistemdeki süreçlerin incelenmesinin genişliği ve derinliği, oluşturulan modelin gereksiz verilerle aşırı yüklenmemesine izin veren geliştiricinin kendisi tarafından belirlenir. Şu anda, aşağıdaki standartlar IDEF ailesine atfedilebilir:

• IDEF0, işlevsel bir modelleme metodolojisidir. Görsel bir grafik dili olan IDEF0'ın yardımıyla, incelenen sistem geliştiricilere ve analistlere bir dizi birbiriyle ilişkili işlev (işlevsel bloklar - IDEF0 açısından) olarak görünür. Tipik olarak, IDEF0 modelleme herhangi bir sistemi öğrenmenin ilk adımıdır;
• IDEF1 - yapılarını ve ilişkilerini görüntülemenize ve analiz etmenize izin veren bir sistem içindeki bilgi akışlarını modellemek için bir metodoloji;
• IDEF1X (IDEF1 Extended), ilişkisel yapılar oluşturmaya yönelik bir metodolojidir. IDEF1X, Varlık-İlişki (ER) metodolojilerinin türüne aittir ve genellikle söz konusu sistemle ilgili ilişkisel veritabanlarını modellemek için kullanılır;
• IDEF2, sistem gelişiminin dinamik modellemesi için bir metodolojidir. Dinamik sistemlerin analizindeki çok ciddi zorluklar nedeniyle, bu standart pratik olarak terk edildi ve gelişimi daha ilk aşamada askıya alındı. Ancak şu anda, bir dizi IDEF0 statik diyagramını “renkli Petri ağları” (CPN – Renkli Petri Ağları) temelinde oluşturulmuş dinamik modellere dönüştürmeye izin veren algoritmalar ve bunların bilgisayar uygulamaları vardır;
• IDEF3, örneğin işletmelerdeki teknolojik süreçlerin incelenmesinde kullanılan, bir sistemde meydana gelen süreçleri belgelemek için bir metodolojidir. IDEF3, her işlem için senaryoyu ve işlem sırasını açıklar. IDEF3'ün IDEF0 metodolojisi ile doğrudan bir ilişkisi vardır - her fonksiyon (fonksiyonel blok), IDEF3 araçları kullanılarak ayrı bir süreç olarak temsil edilebilir;
• IDEF4, nesne yönelimli sistemler oluşturmak için bir metodolojidir. IDEF4 araçları, nesnelerin yapısını ve etkileşimlerinin temel ilkelerini görsel olarak görüntülemenize olanak tanır, böylece karmaşık nesne yönelimli sistemleri analiz etmenize ve optimize etmenize olanak tanır;
• IDEF5, karmaşık sistemlerin ontolojik çalışması için bir metodolojidir. IDEF5 metodolojisini kullanarak, bir sistemin ontolojisi, belirli bir terim ve kurallar sözlüğü kullanılarak tanımlanabilir ve buna dayanarak, incelenmekte olan sistemin belirli bir zamandaki durumu hakkında güvenilir ifadeler oluşturulabilir. Bu ifadelere dayanarak, sistemin daha da geliştirilmesi hakkında sonuçlar çıkarılır ve optimizasyonu gerçekleştirilir.

Bu yazı çerçevesinde en sık kullanılan IDEF0 fonksiyonel modelleme metodolojisini ele alacağız.

IDEF0 standardının tarihi

IDEF0 metodolojisi, işlevsel sistemler SADT'yi (Yapılandırılmış Analiz ve Tasarım Tekniği) tanımlamak için iyi bilinen grafik dilinin geliştirilmesinde bir sonraki aşama olarak düşünülebilir. Birkaç yıl önce, SADT diyagramları oluşturmanın temel ilkelerini açıklamaya adanmış aynı adı taşıyan bir kitabın küçük bir baskısı Rusya'da yayınlandı. Tarihsel olarak, bir standart olarak IDEF0, 1981 yılında, ICAM (Entegre Bilgisayar Destekli İmalat) adını taşıyan ve ABD Hava Kuvvetleri Departmanı tarafından önerilen kapsamlı bir endüstriyel otomasyon programının parçası olarak geliştirildi. IDEF standartlar ailesinin kendisi, atamasını bu programın adından almıştır (IDEF=ICAM DEFinition). Pratik uygulama sürecinde, ICAM programının katılımcıları endüstriyel sistemlerde etkileşim süreçlerini analiz etmek için yeni yöntemler geliştirme ihtiyacıyla karşı karşıya kaldılar. Aynı zamanda, iş süreçlerini tanımlamak için geliştirilmiş bir dizi fonksiyona ek olarak, yeni standardın gereksinimlerinden biri, “analist-uzman” içinde etkileşim için etkili bir metodolojinin mevcudiyetiydi. Başka bir deyişle, yeni yöntemin, projeye dahil olan tüm analistlerin ve uzmanların doğrudan katılımıyla modelin oluşturulması üzerinde grup çalışması sağlaması gerekiyordu.

Uygun çözüm arayışları sonucunda IDEF0 fonksiyonel modelleme metodolojisi doğdu. 1981'den bu yana, IDEF0 standardı, çoğunlukla kısıtlayıcı olmak üzere birkaç küçük değişiklik geçirdi ve son revizyon Aralık 1993'te ABD Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) tarafından yayınlandı.

IDEF0'ın temel öğeleri ve kavramları

IDEF0 grafik dili son derece basit ve uyumludur. Metodoloji dört ana kavram üzerine kuruludur:

Bunlardan ilki konsept fonksiyon bloğu (Etkinlik Kutusu). İşlevsel blok, bir dikdörtgen olarak grafiksel olarak gösterilir (bkz. Şekil 1) ve dikkate alınan sistem içindeki bazı özel işlevleri temsil eder. Standardın gerekliliklerine göre, her bir işlevsel bloğun adı sözlü ruh halinde formüle edilmelidir (örneğin, “hizmet üretmek” ve “hizmet üretmek” değil).

İşlevsel bloğun dört tarafının her birinin kendi özel anlamı (rol) vardır, bununla birlikte:

• Üst taraf "Kontrol";
• Sol taraf "Giriş";
• Sağ taraf “Çıkış” olarak ayarlanmıştır;
• Alt taraf “Mekanizma” (Mekanizma) anlamına gelir.

Söz konusu tek sistem içindeki her işlevsel birim, kendi benzersiz kimlik numarasına sahip olmalıdır.

Şekil 1. Fonksiyon bloğu.

IDEF0 metodolojisinin ikinci “balina” kavramıdır. arayüz yayı (Ok). Ayrıca, arayüz yaylarına genellikle akışlar veya oklar denir. Bir arayüz yayı, bir fonksiyon bloğu tarafından işlenen veya bu fonksiyon bloğu tarafından görüntülenen fonksiyonu etkileyen bir sistem öğesini temsil eder.

Arayüz yayının grafik görüntüsü tek yönlü bir oktur. Her arayüz yayının kendi benzersiz adı (Ok Etiketi) olmalıdır. Standarda göre, isim bir ismin cirosu olmalıdır.

Arayüz yaylarının yardımıyla, bir dereceye kadar sistemde meydana gelen süreçleri belirleyen çeşitli nesneler görüntülenir. Bu tür nesneler, gerçek dünyanın unsurları (parçalar, vagonlar, çalışanlar vb.) veya veri ve bilgi akışları (belgeler, veriler, talimatlar vb.) olabilir.

Bu arayüz arkının hangi tarafa yaklaştığına bağlı olarak “gelen”, “giden” veya “kontrol eden” olarak adlandırılır. Ek olarak, her bir işlevsel yayın "kaynağı" (başlangıç) ve "alıcı" (son) yalnızca işlevsel bloklar olabilirken "kaynak" yalnızca bloğun çıkış tarafı olabilir ve "alıcı" herhangi biri olabilir. kalan üç kişiden.

Standardın gereksinimlerine göre herhangi bir fonksiyonel bloğun en az bir kontrol arayüz arkına ve bir giden ark olması gerektiğine dikkat edilmelidir. Bu anlaşılabilir bir durumdur - her işlem bazı kurallara göre (kontrol yayı tarafından görüntülenen) gerçekleşmeli ve bir sonuç üretmelidir (giden yay), aksi takdirde dikkate alınması bir anlam ifade etmez.

IDEF0 diyagramlarını oluştururken, gelen arayüz yaylarını kontrol yaylarından doğru bir şekilde ayırmak önemlidir, bu genellikle kolay değildir. Örneğin, Şekil 2 “İş parçasının işlenmesi” fonksiyonel bloğunu göstermektedir.

Gerçek bir süreçte, işlemeyi gerçekleştiren işçiye bir iş parçası ve işleme için teknolojik talimatlar (veya makineyle çalışırken güvenlik düzenlemeleri) verilir. Hem iş parçasının hem de teknolojik talimatları içeren belgenin girdi nesneleri olduğu yanlışlıkla görünebilir, ancak durum böyle değil. Aslında, bu süreçte iş parçası, sırasıyla kontrol arayüzü yayı tarafından gösterilmesi gereken teknolojik talimatlarda yansıtılan kurallara göre işlenir.

Şekil 2.

Başka bir şey, teknolojik talimatların baş teknoloji uzmanı tarafından işlenmesi ve bunlarda değişiklik yapılmasıdır (Şekil 3). Bu durumda, gelen arayüz yayı tarafından zaten görüntülenirler ve kontrol nesnesi, örneğin, bu değişikliklerin yapıldığı yeni endüstriyel standartlardır.

Figür 3

Yukarıdaki örnekler, gelen ve kontrol eden arayüz yaylarının görünüşte benzer doğasını vurgulamaktadır, ancak aynı sınıftaki sistemler için her zaman belirli ayrımlar vardır. Örneğin, işletme ve kuruluşlar düşünüldüğünde, beş ana nesne türü vardır: malzeme akışları (parçalar, mallar, hammaddeler vb.), finansal akışlar (nakit ve nakit dışı, yatırımlar vb.), belge akışlar (ticari, finansal ve organizasyonel belgeler), bilgi akışları (bilgi, niyet verileri, sözlü siparişler vb.) ve kaynaklar (çalışanlar, makineler, makineler vb.). Aynı zamanda, çeşitli durumlarda, gelen ve giden arayüz yayları, yalnızca belge ve bilgi akışıyla ilgili olanları yöneten her tür nesneyi görüntüleyebilir ve yalnızca kaynaklar yaylar-mekanizmalar olarak görüntülenebilir.

Kontrol arayüzü yaylarının zorunlu mevcudiyeti, IDEF0 standardı ile DFD (Veri Akış Şeması) ve WFD (İş Akış Şeması) sınıflarının diğer metodolojileri arasındaki ana farklardan biridir.

IDEF0 standardının üçüncü temel konsepti, ayrışma. Ayrışma ilkesi, karmaşık bir süreç kurucu işlevlerine ayrıldığında uygulanır. Bu durumda, sürecin ayrıntı düzeyi doğrudan modelin geliştiricisi tarafından belirlenir.

Ayrıştırma, sistem modelini kademeli ve yapısal olarak bireysel diyagramların hiyerarşik yapısı biçiminde temsil etmenize olanak tanır, bu da onu daha az aşırı yüklenmiş ve kolayca sindirilebilir hale getirir.

IDEF0 modeli her zaman sistemin bir bütün olarak görünümüyle başlar - söz konusu alanın ötesine uzanan arayüz yaylarına sahip tek bir işlevsel birim. Bir fonksiyon bloğuna sahip böyle bir diyagrama bağlam diyagramı denir ve "A-0" tanımlayıcısı ile gösterilir.

Bağlam diyagramı için açıklayıcı metinde, diyagramı kısa bir açıklama şeklinde oluşturmanın amacı (Amacı) belirtilmeli ve sabitlenmelidir. bakış açısı(bakış açısı).

Bir IDEF0 modeli geliştirme amacının belirlenmesi ve resmileştirilmesi son derece önemli bir noktadır. Aslında amaç, incelenen sistemde öncelikle üzerinde durulması gereken ilgili alanları tanımlar. Örneğin, gelecekte bu modele dayalı bir bilgi sistemi kurmak için bir işletmenin faaliyetlerini modellersek, bu model aynı işletme için geliştireceğimizden önemli ölçüde farklı olacaktır, ancak optimizasyon amacıyla. tedarik zinciri.

Bakış açısı, modelin gelişiminin ana yönünü ve gereken detay seviyesini belirler. Bakış açısının net bir şekilde sabitlenmesi, sistem üzerinde seçilen bakış açısına göre gerekli olmayan bireysel unsurları detaylandırmayı ve incelemeyi reddederek modeli boşaltmanıza izin verir. Örneğin, baş teknoloji uzmanı ve mali direktör açısından aynı işletmenin işlevsel modelleri, detaylandırma yönünde önemli ölçüde farklılık gösterecektir. Bunun nedeni, sonuçta, finans direktörünün üretim makinelerinde hammadde işleme yönleriyle ilgilenmemesi ve baş teknoloji uzmanının çizilmiş finansal akış şemalarıyla ilgilenmemesidir. Doğru bakış açısı seçimi, nihai modeli oluşturmak için harcanan zamanı önemli ölçüde azaltır.

Ayrıştırma sürecinde, bağlam diyagramında sistemi bir bütün olarak gösteren fonksiyonel blok, başka bir diyagramda detaylandırılmıştır. İkinci seviyenin ortaya çıkan diyagramı, bağlam diyagramının fonksiyonel bloğunun ana alt fonksiyonlarını gösteren fonksiyonel blokları içerir ve buna bağlı olarak bir çocuk diyagramı (Alt diyagram) olarak adlandırılır (alt diyagrama ait fonksiyonel blokların her biri sırasıyla alt blok olarak adlandırılır - Alt Kutu). Buna karşılık, işlevsel blok - ata, alt diyagrama (Üst Kutu) göre ana blok olarak adlandırılır ve ait olduğu diyagrama ana diyagram (Üst Diyagram) denir. Çocuk diyagramının alt işlevlerinin her biri, karşılık gelen işlevsel bloğunun benzer bir ayrıştırmasıyla daha da detaylandırılabilir. Bir fonksiyonel bloğun her bir ayrıştırılması durumunda, bu bloğa dahil edilen veya ondan çıkan tüm arayüz yaylarının alt diyagramda sabitlendiğini not etmek önemlidir. Bu, IDEF0 modelinin yapısal bütünlüğünü sağlar. Ayrıştırma ilkesi Şekil 4'te açıkça gösterilmiştir. Fonksiyonel blokların numaralandırılması ile diyagramlar arasındaki ilişkiye dikkat etmelisiniz - diyagramda her bloğun kendine özgü bir seri numarası vardır (dikdörtgenin sağ alt köşesindeki sayı) , ve sağ köşedeki atama , bu blok için alt diyagramın numarasını gösterir . Bu atamanın olmaması, bu blok için herhangi bir ayrışma olmadığını gösterir.

Genellikle, alt diyagramlardaki bireysel arayüz yaylarını hiyerarşide belirli bir seviyenin altında düşünmeye devam etmenin mantıklı olmadığı veya tam tersi durumlar vardır - bireysel yaylar belirli bir seviyenin üzerinde pratik bir anlam ifade etmez. Örneğin, "Torna tezgahında işleme" fonksiyon bloğunun girişinde bir "ayrıntı" gösteren bir arayüz yayı, daha yüksek seviyelerdeki diyagramları yansıtmanın bir anlamı yoktur - bu sadece diyagramları aşırı yükleyecek ve okunmasını zorlaştıracaktır. Öte yandan, ayrı "kavramsal" arayüz yaylarından kurtulmak ve onları belirli bir seviyeden daha derin detaylandırmamak gerekiyor. Bu tür sorunları çözmek için, IDEF0 standardı şu konsepti sağlar: tünel açma. Arayüz yayının başlangıcında iki parantez şeklinde “tünel”in (Ok Tüneli) belirtilmesi, bu yayın işlevsel ana bloktan miras alınmadığı ve yalnızca bu diyagramda (“tünelden”) göründüğü anlamına gelir. Buna karşılık, alıcı bloğun hemen yakınındaki arayüz yayının ucundaki (ok) aynı gösterim, bu yayın görüntülenmeyeceğini ve bu bloğun alt diyagramında dikkate alınmayacağı anlamına gelir. Çoğu zaman, bireysel nesneler ve bunlara karşılık gelen arayüz yayları, hiyerarşinin bazı ara seviyelerinde dikkate alınmaz - bu durumda, önce “tünele dalarlar” ve sonra gerekirse “tünelden dönerler”.

IDEF0 kavramlarının sonuncusu sözlük. IDEF0 öğelerinin her biri için: diyagramlar, fonksiyon blokları, arayüz yayları, mevcut standart, bu öğe tarafından görüntülenen nesneyi karakterize eden bir dizi karşılık gelen tanım, anahtar sözcük, anlatı ifadesi vb. Bu kümeye sözlük denir ve bu öğenin özünün bir açıklamasıdır. Örneğin, kontrol arayüzü yayı "ödeme emri" için sözlük, belgenin yayına, gerekli vize setine vb. karşılık gelen alanların bir listesini içerebilir. Sözlük, diyagramlara gerekli ek bilgileri sağlayarak görsel grafik dilini uyumlu bir şekilde tamamlar.

Şekil 4. Fonksiyonel blokların ayrıştırılması.

IDEF0 Diyagramlarının Karmaşıklığını Sınırlandırma İlkeleri

Tipik olarak, IDEF0 modelleri karmaşık ve yoğun bilgiler taşır ve tıkanıklıklarını sınırlamak ve bunları okunabilir kılmak için ilgili standartta ilgili karmaşıklık kısıtlamaları benimsenmiştir:

• Diyagramdaki fonksiyon bloklarının sayısını üç ila altı ile sınırlandırmak. Üst sınır (altı), tasarımcıyı karmaşık konuları tanımlarken hiyerarşileri kullanmaya zorlar ve alt sınır (üç), karşılık gelen diyagramın, yaratılışını doğrulamak için yeterli ayrıntıya sahip olmasını sağlar;
• Bir fonksiyonel bloğa yaklaşan (bir fonksiyonel blok bırakarak) arayüz yaylarının sayısının dörde sınırlandırılması.

Tabii ki, bu kısıtlamalara kesinlikle uymak gerekli değildir, ancak deneyimlerin gösterdiği gibi, bunlar gerçek işte çok pratiktir.

IDEF0 modelinin geliştirilmesinde grup çalışması disiplini

IDEF0 standardı, modellenmekte olan sistemin farklı faaliyet alanlarına mensup geniş bir grup insan tarafından bir modelin geliştirilmesini ve onaylanmasını sağlayan bir dizi prosedür içermektedir. Tipik olarak, geliştirme süreci yinelemelidir ve aşağıdaki koşullu adımlardan oluşur:

• İşletmenin çeşitli alanlarıyla ilgili bir grup uzman tarafından bir model oluşturulması. Bu gruba IDEF0 terimleriyle Yazarlar denir. Başlangıç ​​modelinin oluşturulması, yazarların yetkin kişilere çeşitli süreçlerin yapısı hakkında sorular sorduğu dinamik bir süreçtir. Mevcut hükümler, belgeler ve anket sonuçlarına dayanarak, modelin bir taslağı (Model Taslağı) oluşturulur.
• Taslağın değerlendirme, onay ve yorumlar için dağıtılması. Bu aşamada taslak model, işletmede geniş bir yelpazede (IDEF0 okuyucuları açısından) yetkin kişilerle tartışılır. Aynı zamanda taslak modelin diyagramlarının her biri yazılı olarak eleştirilir ve yorumlanır ve ardından yazara aktarılır. Yazar da eleştiriyi yazılı olarak kabul eder veya kararın mantığının bir ifadesi ile reddeder ve düzeltilmiş taslağı daha fazla değerlendirilmek üzere tekrar gönderir. Bu döngü, yazarlar ve okuyucular bir fikir birliğine varana kadar devam eder.
• Model onayı. Modelin yazarları ve okuyucuların yeterliliği konusunda herhangi bir anlaşmazlığı olmaması durumunda, onaylanan model çalışma grubu başkanı tarafından onaylanır. Nihai model, belirli bir bakış açısından ve belirli bir amaç için işletmenin (sistemin) tutarlı bir görünümüdür.

IDEF0 grafik dilinin görünürlüğü, modeli oluşturma projesinde yer almayan insanlar için oldukça okunabilir ve gösteriler ve sunumlar için etkili kılar. Gelecekte, oluşturulan model temelinde, işletmede (sistemde) değişiklik yapmaya yönelik yeni projeler düzenlenebilir.

IDEF0 araçlarını kullanarak işlevsel modellemeyi kullanma ulusal uygulamasının özellikleri

Son yıllarda, Rusya'da IDEF ailesinin metodolojilerine olan ilgi giderek artıyor. Bu standartların temel ilkelerini kısaca açıklayan kişisel web sayfama (http://consulting.psi.ru) yapılan isabet istatistiklerine bakarken bunu sürekli gözlemliyorum. Aynı zamanda, IDEF3-5 gibi standartlara olan ilgiyi teorik olarak adlandırırdım ve IDEF0'da oldukça pratik olarak haklıdır. Nitekim, DFD ve IDEF0 diyagramlarının oluşturulmasına izin veren ilk Case araçları, SADT standartlarında modelleme ilkeleri üzerine popüler bir kitabın yayınlanmasıyla eş zamanlı olarak 1996'da Rusya pazarında ortaya çıktı.

Bununla birlikte, çoğu yönetici hala IDEF standartlarında modellemenin pratik uygulamasını mevcut iş yönetim sistemini optimize etmenin etkili bir yolundan ziyade modaya bir övgü olarak görmektedir. Büyük olasılıkla, bu, bu metodolojilerin pratik uygulaması hakkında belirgin bir bilgi eksikliğinden ve yayınların büyük çoğunluğunun vazgeçilmez yazılım önyargısından kaynaklanmaktadır.

Rusya'daki işletmelerin finansal ve ekonomik faaliyetlerinin neredeyse tüm araştırma ve analiz projelerinin şu ya da bu şekilde otomatik kontrol sistemlerinin inşasıyla bağlantılı olduğu bir sır değil. Bu sayede, çoğunluğun anlayışındaki IDEF standartları, bilgi teknolojisinin tanıtılmasından şartlı olarak ayrılmaz hale geldi, ancak onların yardımıyla, bazen küçük yerel sorunları bile kelimenin tam anlamıyla bir kalem ve kağıtla etkili bir şekilde çözmek mümkün.

Karmaşık kurumsal anket projeleri yürütürken, IDEF0 standardındaki modellerin geliştirilmesi, bir kuruluşun faaliyetlerinin tüm mekanizmasını doğru bağlamda görsel olarak ve etkili bir şekilde görüntülemenize olanak tanır. Ancak en önemlisi, IDEF0'ın sağladığı işbirliği yeteneğidir. Uygulamamda, modelin inşasının çeşitli departmanların çalışanlarının doğrudan yardımıyla gerçekleştirildiği birkaç durum vardı. Aynı zamanda danışman oldukça kısa bir sürede onlara IDEF0'ın temel ilkelerini açıkladı ve ilgili uygulama yazılımıyla nasıl çalışacaklarını öğretti. Sonuç olarak, çeşitli departmanların çalışanları, aşağıdaki soruları cevaplaması gereken fonksiyonel birimlerinin faaliyetlerinin IDEF diyagramlarını oluşturdular:

• "Girişte" birime ne girer?
• Ünite içinde hangi işlevler ve hangi sırayla gerçekleştirilir?
• Her işlevden kim sorumludur?
• Her bir işlevin performansında icracıya rehberlik eden nedir?
• Birimin çalışmasının (çıktı) sonucu nedir?

Her bir özel departman içindeki taslak diyagramları koordine ettikten sonra, bir danışman tarafından tüm girdi ve çıktı unsurlarının bağlantılı olduğu taslak bir kurumsal modelde birleştirilirler. Bu aşamada, bireysel diyagramların tüm tutarsızlıkları ve tartışmalı yerleri sabitlenir. Ayrıca, bu model daha fazla koordinasyon ve gerekli ayarlamaların yapılması için tekrar fonksiyonel departmanlardan geçer. Sonuç olarak, oldukça kısa sürede ve danışmanlık şirketinden minimum insan kaynağının katılımıyla (ve bildiğiniz gibi bu kaynaklar çok pahalıdır), “As'a göre bir işletmenin IDEF0 modeli elde edilir. ' ilkesidir ve daha da önemlisi, içinde çalışan ve informal olanlar da dahil olmak üzere tüm nüansları tam olarak bilen çalışanların pozisyonlarına sahip bir işletmeyi temsil eder. Gelecekte, bu model analiz ve işleme için şirketin yönetiminde "darboğazlar" arayacak ve ana süreçleri optimize ederek "Olduğu Gibi" modelini karşılık gelen "Olması gerektiği gibi" modele dönüştürecek olan iş analistlerine aktarılacaktır. ” temsili. Bu değişikliklere dayanarak, yönetim sisteminin yeniden düzenlenmesi için öneriler içeren nihai bir sonuca varılır.

Tabii ki, böyle bir yaklaşım, öncelikle ankete katılan işletmenin yönetimi adına bir dizi organizasyonel önlem gerektirir. Bunun nedeni, bu tekniğin yeni metodolojilerin geliştirilmesi ve pratik uygulaması için bazı çalışanlara ek sorumluluklar verilmesini içermesidir. Bununla birlikte, sonunda, bu kendini haklı çıkarır, çünkü bireysel çalışanlar tarafından birkaç gün boyunca ek bir veya iki saatlik çalışma, üçüncü taraf bir şirketten danışmanlık hizmetleri için ödeme yapmaktan önemli ölçüde tasarruf sağlayabilir (ki bu her durumda çalışmayı kesintiye uğratır) anketler ve sorularla aynı çalışanlar). İşletmenin çalışanlarına gelince, uygulamamda onlardan açık bir muhalefetle karşılaşmadım.

Tüm bunlardan şu sonuç çıkarılabilir: Her seferinde standart problemler için çözümler bulmak kesinlikle gerekli değildir. Belirli bir işlevsel sistemi (uzay aracı tasarım sisteminden karmaşık bir akşam yemeği hazırlama sürecine kadar) analiz etme ihtiyacıyla karşı karşıya kaldığınızda, yıllar içinde kanıtlanmış ve alıştırma yöntemlerini kullanın. Bu yöntemlerden biri, karmaşık yaşam problemlerini çözmek için basit ve anlaşılır araçlarını kullanmaya izin veren IDEF0'dır.