Örnek olarak bir bilgisayar oyunu kullanan Idef0 diyagramı. Denetimleri ve blokları adlandırma kuralları. A63 veri akış şeması

IDEF0 metodolojisi

IDEF0 metodolojisi hiyerarşik bir diyagram sistemi - sistem parçalarının tek açıklamaları - yapısını belirtir. İlk olarak, bir bütün olarak sistem ve dış dünyayla etkileşimi açıklanır (bağlam diyagramı), ardından fonksiyonel ayrıştırma gerçekleştirilir - sistem alt sistemlere bölünür ve her bir alt sistem ayrı ayrı açıklanır (ayrıştırma diyagramları). Daha sonra her alt sistem daha küçük parçalara bölünür ve istenen ayrıntı düzeyi elde edilene kadar bu şekilde devam eder.

Her biri IDEF0-çizelgelerive bloklar ve yaylar içerir. Bloklar, simüle edilen sistemin işlevlerini temsil eder. Yaylar blokları birbirine bağlar ve aralarındaki etkileşimleri ve ilişkileri temsil eder.

Diyagramlardaki fonksiyonel bloklar (iş), zaman içinde ortaya çıkan ve tanınabilir sonuçları olan adlandırılmış süreçleri, işlevleri veya görevleri temsil eden dikdörtgenlerle temsil edilir. Eserin adı, bir eylemi ifade eden sözlü bir isimle ifade edilmelidir.

IDEF0 en az üç ve altıdan fazla bloğa sahip olmayan bir diyagram gerektirir. Bu kısıtlamalar, diyagramların ve modellerin karmaşıklığını okunabilir, anlaşılabilir ve kullanılabilir bir düzeyde tutar.

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

IDEF0'daki bloklar, diyagramın yazarının anlayacağı şekilde önem sırasına göre düzenlenmiştir. Bu göreceli düzene hakimiyet denir. Baskınlık, bir bloğun diyagramdaki diğer bloklar üzerindeki etkisi olarak anlaşılır. Örneğin, bir diyagramın en baskın bloğu, gerekli bir işlev dizisinin ilki veya diğerlerini etkileyen bir planlama veya kontrol işlevi olabilir.

En baskın blok genellikle diyagramın sol üst köşesinde, en az baskın olan blok ise sağ köşede yer alır.

Sayfadaki blokların düzeni, yazarın hakimiyet tanımını yansıtır. Bu nedenle, diyagramın topolojisi, hangi özelliklerin diğerleri üzerinde en büyük 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 dikdörtgenin sağ alt köşesine yerleştirilen bir sayı ile gösterilebilir: 1 en yüksek baskınlığı, 2 sonrakini vb. Belirtir.

Eserlerin dış dünya ile ve kendi aralarında etkileşimi, uçlarında ok bulunan tek çizgilerle tasvir edilen oklar şeklinde anlatılır. Oklar bir tür bilgiyi temsil eder ve isimler olarak adlandırılır.

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

Giriş- bir sonuç (çıktı) elde etmek için iş tarafından kullanılan ve dönüştürülen nesneler. Eserde herhangi bir giriş okunun bulunmayabileceği varsayılmaktadır. Giriş oku işin sol tarafına girerken çizilir.

Kontrol -. işin faaliyetlerini yöneten bilgiler. Tipik olarak, kontrol okları, işin yapılması gerektiğini belirten bilgileri taşır. Her iş, işin üst yüzüne giriyor olarak gösterilen en az bir kontrol okuna sahip olmalıdır.

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

mekanizma - işi yapan kaynaklar. Mekanizma oku, işin alt kenarına girerken çizilir. Analistin takdirine bağlı olarak, makinenin elleri model üzerinde görünmeyebilir.

Aramak - farklı bir çalışma modeline işaret eden özel bir ok. Çağrı oku işin altından geliyormuş gibi çizilir ve simüle edilen sistemin dışında bazı işlerin yapıldığını belirtmek için kullanılır.

İncir. 2.1Ok türleri

IDEF0 metodolojisinde, ilişkilerini tanımlamak için bloklar arasında yalnızca beş tür etkileşim gereklidir: kontrol, girdi, kontrol geri bildirimi, girdi geri bildirimi, çıktı mekanizması. Kontrol ve girdi bağlantıları en basitidir çünkü sezgisel ve çok basit olan doğrudan eylemleri yansıtırlar.

İncir. 2.2.İletişimden çık

İncir. 2.3.Yönetim iletişimi

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

Kontrol geribildirimi ve girdi geribildirimi daha karmaşıktır çünkü bunlar yineleme veya özyinelemedir. Yani, bir işten çıkışlar, diğer işlerin gelecekteki performansını etkiler ve bu da daha sonra orijinal işi etkileyecektir.

Kontrol geri bildirimi daha sonra gerçekleşir; bazı bloğun çıktısı bloğu büyük bir baskınlıkla etkilediğinde.

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

İncir. 2.4.Giriş Geri Bildirimi

İncir. 2.5.Yönetim geri bildirimi

Çıkış mekanizması ilişkileri kaynak tahsisinde yaygındır (örneğin gerekli araçlar, eğitimli personel, fiziksel alan, ekipman, finansman, malzemeler).

IDEF0'da bir yay, nadiren tek bir nesneyi gösterir. Genellikle bir nesne koleksiyonunu sembolize eder. Yaylar özellik koleksiyonlarını temsil ettiğinden, birden çok başlangıç \u200b\u200bnoktasına (kaynak) ve bitiş noktasına (hedef) sahip olabilirler. Bu nedenle, yaylar çeşitli şekillerde dallanıp bağlanabilir. Tüm bir yay veya parçası, bir veya daha fazla bloktan çıkabilir ve bir veya daha fazla blokta sona erebilir.

Uzaklaşan çizgiler olarak gösterilen dallanma yayları, yay içeriğinin tamamının veya bir kısmının her dalda görünebileceği anlamına gelir. Yay, tüm kümeye bir ad vermek için her zaman çatallanmadan önce etiketlenir. Ek olarak, yayın her bir dalı aşağıdaki kurallara göre işaretlenebilir veya işaretsiz hale getirilebilir:

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

    Çatallanma noktasından sonra işaretlenen dallar, çatallanmadan önceki yay etiketinde belirtilen nesnelerin tümünü veya bir kısmını içerir.

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

İncir. 2.6.Çıkış mekanizması iletişimi

    işaretlenmemiş dallar, birleştirme sonrası genel ark etiketinde belirtilen nesnelerin ağırlığını içerir;

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

    diyagramdaki blok sayısı - K;

    grafik ayrıştırma seviyesi - L;

    denge diyagramı - İÇİNDE;

    bloğa bağlanan ok sayısı - VE

Bu faktörler kümesi, modeldeki her diyagram için geçerlidir. Grafik faktörlerinin istenen değerleri için öneriler aşağıda listelenecektir.

Alt seviyelerdeki diyagramlardaki blok sayısının ana diyagramlardaki blok sayısından daha düşük olmasını, yani ayrışma seviyesinin artmasıyla katsayının düşmesini sağlamak için çaba göstermek gerekir. Dolayısıyla bu katsayıdaki düşüş bunu göstermektedir. model ayrıştırıldıkça, fonksiyonların basitleştirilmesi, dolayısıyla blok sayısının azaltılması gerektiği.

Grafiklerin dengelenmesi gerekiyor. Bu, bir diyagram çerçevesinde, Şekil 1'de gösterilen durumun olduğu anlamına gelir. 2.7: İş 1, gidenlerden önemli ölçüde daha fazla gelen ve kontrol oklarına sahiptir. Üretim süreçlerini anlatan modellerde bu tavsiyeye uyulmayabileceği unutulmamalıdır. Örneğin, bir montaj prosedürünü açıklarken, bir blok bir ürünün bileşenlerini tanımlayan birçok ok içerebilir ve bir ok dışarı çıkabilir - bitmiş bir ürün.

İncir. 2.7.Dengesiz bir grafik örneği

Diyagramın denge faktörünü tanıtalım

İçin çabalamak gerekli Khgrafik için minimaldi.

Diyagramın grafik öğelerini analiz etmenin yanı sıra, blokların adlarını da dikkate almak gerekir. İsimleri değerlendirmek için, modellenen sistemin temel (önemsiz) işlevlerinin bir sözlüğü derlenir. Aslında, alt düzey diyagram ayrıştırma işlevleri bu sözlüğe girmelidir. Örneğin, bir veritabanı modeli için, "kayıt bulma", "veritabanına bir kayıt ekleme" işlevleri temel olabilirken "kullanıcı kaydı" işlevi daha fazla açıklama gerektirir.

Kelime dağarcığı oluşturulduktan ve bir sistem diyagramları paketi derlendikten sonra, modelin alt seviyesi dikkate alınmalıdır. Diyagram bloklarının isimleri ile sözlükteki kelimelerin tesadüfleri varsa, 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 -sözlükteki kelimelerle blok adlarının eşleşme sayısına göre model seviyesinin çarpımı. Modelin seviyesi ne kadar düşükse (L yüksek), tesadüfler o kadar değerlidir.

BPWin başlatıldığında, 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 havuzundan mı açılacağını belirtmeniz, modelin adını girmeniz ve modelin oluşturulacağı metodolojiyi seçmeniz gereken bir iletişim kutusu görünür (Şekil 2.8).

Şekil 2.8 Model oluşturma iletişim kutusu

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

BPWin'deki bir model, her biri bir veri kümesi üzerinde çalışan bir faaliyetler koleksiyonu olarak görülür. Modelin herhangi bir nesnesine sol fare düğmesiyle tıklarsanız, her biri bir nesne özelliklerinin düzenleyicisine karşılık gelen bir açılır içerik menüsü görünür.

Bir sistemin modelini oluşturmak, işlevselliğini açıklayan tüm belgeleri inceleyerek başlamalıdır. Bu belgelerden biri görev tanımı, yani "Geliştirmenin amacı", "Sistemin amaçları ve hedefleri" ve "Sistemin işlevsel özellikleri" bölümleridir.

Kaynak belgeleri inceledikten ve müşteri ve sistem kullanıcıları ile görüştükten sonra modelleme hedefini formüle etmek ve modele bakış açısını belirlemek gerekir. Ana özellikleri 1 numaralı laboratuvar çalışmasında açıklanan "Üniversite İçinde İstihdam Hizmeti" sistemi örneğini kullanarak yapım teknolojisini ele alalım.

Modellemenin amacını formüle edelim: Kullanıcısı tarafından anlaşılabilecek sistemin işleyişini uygulama ile ilgili detaylara girmeden anlatmak. Modeli kullanıcılar açısından (öğrenci, öğretmen, yönetici, dekanlık, şirket) oluşturacağız.

Bağlamsal bir IDEF0 diyagramı oluşturarak başlayalım. Sistemin açıklamasına göre asıl işlevi müşterilerinden gelen talepleri işleyerek hizmet vermektir. Bu nedenle, bağlam diyagramının tek işini "Sistem istemcisine hizmet et" olarak tanımlarız. Daha sonra, girdi ve çıktı verilerini, ayrıca mekanizmaları ve kontrolleri tanımlayacağız.

Bir müşteriye hizmet verebilmek için onu sisteme kaydettirmek, veri tabanına erişimi açmak ve talebini işlemek gerekir. Giriş verileri "müşteri adı", "müşteri şifresi", "kaynak veritabanı", "müşteri talebi" olacaktır. Bir sorgunun 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 hazırlanırken) yol açar, bu nedenle çıktı verileri "raporlar" ve "değiştirilmiş veritabanı" olacaktır. İstekleri işleme süreci, sistem monitörü tarafından yöneticinin kontrolü altında gerçekleştirilecektir.

Böylece, sistemin bağlam diyagramını tanımlıyoruz (Şekil 2.9).

Şekil 2.9.Sistem bağlam şeması

Müşteri hizmetlerinin sırasını açıklayan bağlam diyagramını ayrıştıralım:

    Sisteme erişim düzeyinin belirlenmesi.

    Alt sistem seçimi.

    Bir alt sisteme atıfta bulunarak.

    Veritabanı değişikliği (gerekirse).

Şekil 2'de gösterilen diyagramı alıyoruz. 2.10.

Bağlam diyagramının ayrıştırılmasını tamamladıktan sonra, sonraki seviye diyagramının ayrıştırılmasına ilerleyin. Genellikle, üçüncü ve alt seviyelere bakıldığında, modeller ana diyagramlara geri döner ve onları ayarlar.

İncir. 2.10."Hizmet, sistem istemcisi" çalışmasının ayrıştırılması

Elde edilen diyagramın tüm bloklarını sırayla ayrıştıralım. Sisteme erişim düzeyini belirlemede ilk adım, kullanıcı kategorisinin belirlenmesidir. Müşterinin adı, kategorisini tanımlayarak kullanıcı bazında aranır. Belirli bir kategoriye göre sistem kullanıcısına verilen yetkiler netleştirilir. Daha sonra, sisteme erişim prosedürü, erişim adı ve şifre kontrol edilerek gerçekleştirilir. Yetki ve sisteme erişim seviyesi 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 2'de gösterildiği gibi görünecektir. 2.11.

İncir. 2.11.Çalışmanın ayrıştırılması "Sisteme erişim düzeyinin belirlenmesi"

Sisteme erişim prosedüründen geçtikten sonra, monitör müşterinin talebini analiz ederek talebi işleyecek bir alt sistem seçer. “Alt Sistemin Ele Alınması” çalışmasının ayrıştırılması, modelin amacı ve bakış açısına karşılık gelmemektedir. Sistem kullanıcısı, işleminin dahili algoritmalarıyla ilgilenmez. Bu durumda, alt sistem seçiminin, müdahalesi olmadan otomatik olarak yapılması onun için önemlidir, bu nedenle, çağrının alt sisteme ayrıştırılması yalnızca modeli karmaşıklaştıracaktır.

Kullanıcı kategorilerini ve izinlerini tanımlayarak, istek işleme alt sistemi tarafından gerçekleştirilen "İstemci istek işleme" çalışmasını ayrıştıralım. Bir isteğe cevap aramadan önce, veritabanını açmalısınız (ona bağlanmalısınız). Genel olarak, veritabanı uzaktaki bir sunucuda bulunabilir, bu nedenle ona bir bağlantı kurmak gerekebilir. İş sırasını tanımlayalım:

    Veritabanını açıyorum.

    Talebin yerine getirilmesi.

    Raporların oluşturulması.

Veritabanını açtıktan sonra, veritabanı ile bağlantı kurulması konusunda sisteme bilgi verilmesi ve ardından talebin yürütülmesi ve kullanıcı için raporların oluşturulması gerekmektedir (Şekil 2.12).

"Bir talebin yerine getirilmesi" nin çeşitli alt sistemlerin çalışmasını içerdiği unutulmamalıdır. Örneğin, talep test içeriyorsa, 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 hazırlanırken veritabanının içeriğini değiştirmek gerekli olabilir. Bu nedenle, şema böyle bir olasılık sağlamalıdır.

İncir. 2.12.

Ortaya çıkan diyagramı analiz ederken, soru ortaya çıkıyor, rapor oluşturmanın kuralları nelerdir? Veritabanından seçimin yapılacağı önceden oluşturulmuş şablonlara sahip olmak ve bu şablonların isteklere uygun olması ve önceden tanımlanması gerekir. Ek olarak, müşteriye raporun şeklini seçme fırsatı verilmelidir.

"Rapor şablonları" ve "Veritabanını değiştirme istekleri" oklarını ve "Sistem istemcisi" tünel oku ekleyerek diyagramı ayarlayalım. Rapor formunu seçme işlevi, ana diyagramda gösterecek kadar önemli olmadığından, oku üst diyagrama yerleştirmemek için "Sistem İstemcisi" tünellemesi uygulanır.

Diyagramın değiştirilmesi tüm ana diyagramların ayarlanmasına yol açacaktır (Şekil 2.13 - 2.15).

IDEF0 metodolojisi, sistemi bilgi işleme süreçlerini zayıf bir şekilde yansıtan birbiriyle ilişkili işler dizisi olarak gördüğü için, DFD diyagramını (laboratuar çalışması No. 3) kullanarak "Bir sorgunun yürütülmesi" çalışmasının ayrıştırılması tavsiye edilir.

İncir. 2.13."İstemci isteği işleme" çalışmasının ayrıştırılması

İncir. 2.14."Sistem istemci hizmeti" çalışmasının ayrıştırılması (seçenek 2)

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

Son blok olan "Veritabanı değişikliği" nin ayrıştırılmasına geçelim. Müşterinin bakış açısından, bu sistemler tek bir veritabanında yer almaktadır. Sistemde aslında altı veritabanı vardır:

    Kullanıcı veritabanı,

    DB öğrenci, (seçenek 2)

    Boş yerlerin DB'si,

    Performans veritabanı,

    DB testler,

    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şeceği veri tabanı belirlenir.

    Operatör geçici bir veri seti oluşturur ve bunu yöneticiye sağlar.

    Yönetici verileri kontrol eder ve veri tabanına girer.

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

İncir. 2.16."Veritabanı değişikliği" çalışmasının ayrıştırılması

İncir. 2.17.Çalışmanın ayrıştırılması "Veritabanı değişikliği" (seçenek 2) İlk seçenek için, Şekil 1'de gösterilen. 2.12

"Veritabanı Değişikliklerinin" daha fazla ayrıştırılması, sistemdeki veritabanının fiziksel değişikliğinin nasıl gerçekleştirildiğini açıklayarak modeli karmaşıklaştıracaktır. Bu durumda kullanıcı, istihdam hizmeti sisteminin çalışması hakkında herhangi bir ek bilgi almayacaktır. Bu çalışmanın mantıksal bir veritabanı modeli oluşturma aşamasında bir veritabanı sistemi tasarlama sürecinde ayrıştırılması tavsiye edilir.

"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.

Şekil 2'de gösterilen modellerin nicel bir analizini yapalım. 2.12 ve 2.13, yukarıdaki prosedüre göre. Bu modeller için ^ katsayısının davranışını ele alalım. "İstemci isteği işleme" ana diyagramının katsayısı 4/2 \u003d 2'dir ve ayrıştırma diyagramı 3/3 \u003d 1'dir. Katsayının değeri azalır, bu da azalan model seviyesi ile işlevlerin açıklamasının basitleştirilmesini gösterir.

Katsayıdaki değişikliği düşünün TO b iki model varyantında.

ikinci seçenek için

katsayı TO 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 temel fonksiyonların (sistemin kullanıcısı bakış açısından) alt Seviyenin diyagramları üzerinde iş başlıkları olarak kullanıldığını varsayacağız.

Ele alınan örneği özetleyerek, bir sistemi modellerken diyagramlar için çeşitli seçenekleri göz önünde bulundurmanın önemine dikkat etmek gerekir. Bu tür varyantlar, "Bir müşteri talebinin işlenmesi" ile yapıldığı gibi diyagramları ayarlarken veya sistem işlevlerinin alternatif uygulamalarını yaratırken ("Veritabanını değiştir" çalışmasının ayrıştırılması) ortaya çıkabilir. Seçeneklerin dikkate alınması, en iyisini seçmenize ve daha fazla değerlendirme için diyagramlar paketine dahil etmenize olanak tanır.

Yayınlanan http://www.allbest.ru/

İşletmedeki bilgisayar ve diğer ekipmanların muhasebesinin otomasyonu sorununun alaka düzeyi, büyük bir bilgisayar parkı, ofis ekipmanı, ticaret ve diğer ekipmanların varlığında artmaktadır. Ekipmanla ilgili değişiklikleri hızlı bir şekilde takip etmek için nerede ve hangi birimin bulunduğunu bilmek en büyük ihtiyaç BT departmanlarından kaynaklanmaktadır. 2

Ekipman muhasebesinin otomasyon görevi, büyük işletmelerde özel bir öneme sahiptir. Giderek artan miktarda bilginin işlenmesi ancak modern bilgisayar teknolojilerinin kullanılmasıyla mümkün olmuştur. 2

Bir işletmedeki ekipman için bir muhasebe sistemi düzenlemek, bilgisayarların ve bileşenlerin kayıtlarını tutmak, artık bir bilgisayara ek yazılım yüklenmeden imkansızdır. 2

Ana hedef dönem ödevi gelişme bilgi sistemi Computer Associates AllFusion Process Modeler r7.3 yazılım ürünü aracılığıyla işlevsel modelleme metodolojisi ve IDEF0 grafik gösterimi, DFD veri akış diyagramları ve IDEF3 süreç dokümantasyon standardı kullanılarak kurumsal bilgisayar ekipmanının muhasebesi için. 2

2.1 Yazılım ürünlerinin analizi 8

GİRİŞ

İşletmedeki bilgisayar ve diğer ekipmanların muhasebesinin otomasyonu sorununun alaka düzeyi, büyük bir bilgisayar parkı, ofis ekipmanı, ticaret ve diğer ekipmanların varlığında artmaktadır. Ekipmanla ilgili değişiklikleri hızlı bir şekilde takip etmek için nerede ve hangi birimin bulunduğunu bilmek en büyük ihtiyaç BT departmanlarından kaynaklanmaktadır.

Ekipman muhasebesinin otomasyon görevi, büyük işletmelerde özel bir öneme sahiptir. Giderek artan miktarda bilginin işlenmesi ancak modern bilgisayar teknolojilerinin kullanılmasıyla mümkün olmuştur.

Bir işletmedeki ekipman için bir muhasebe sistemi düzenlemek, bilgisayarların ve bileşenlerin kayıtlarını tutmak, artık bir bilgisayara ek yazılım yüklenmeden imkansızdır.

Kurs çalışmasının temel amacı, Computer Associates AllFusion Process Modeler r7.3 yazılım ürünü aracılığıyla işlevsel modelleme metodolojisi ve grafiksel gösterim IDEF0, DFD veri akış diyagramları ve IDEF3 süreç dokümantasyon standardını kullanarak kurumsal bilgisayar ekipmanı muhasebesi için bir bilgi sistemi geliştirmektir.

Bu hedefe ulaşmak için aşağıdaki görevleri çözmek gerekir:

    Yazılım ürünlerinin analizi;

    Bilgi sistemleri tasarım yöntemlerinin incelenmesi;

    Bağlam diyagramlarının ve iş süreci ayrıştırma diyagramlarının işlevsel modellemesi (IDEF0) "Kurumsal bilgisayar ekipmanı için muhasebe";

    Veri akış diyagramlarını (DFD) kullanarak bilgi sistemi tasarımı;

    Modelleme metodolojisini ve IDEF3 süreç dokümantasyon standardını kullanma.

bilgi poliklinik belgeleme yazılımı

1. BİLGİ SİSTEMLERİ TASARIM YÖNTEMLERİ

Modern modelleme yönetimi ve üretim faaliyetlerinde, "iş süreci" terimi, modelleme nesnelerini belirtmek için kullanılır. İş süreçlerini modellerken, bir dizi faktöre dikkat edilmelidir:

    Doğru hedef belirleme;

    Kuruluşun personelinin projenin hedefleri ve sonuçları hakkında yetkin farkındalık;

    Modelleme araçlarının etkin kullanımı;

    İş süreçlerini açıklamak ve düzenlemek için kurumsal standartların mevcudiyeti.

İş süreçlerini modellemek için birkaç farklı yöntem kullanılır. Modellemeye hem yapısal hem de nesneye yönelik yaklaşımlara dayanırlar. En gelişmiş yöntemler, her iki yaklaşımın unsurlarını kullanır. En yaygın yöntemler şunları içerir:

    fonksiyonel modelleme yöntemi SADT (IDEF0);

    süreç modelleme yöntemi IDEF3;

    dFD veri akışı modellemesi;

İş modellemesi açısından, sunulan yaklaşımların her birinin kendi avantajları vardır. Nesne yaklaşımı, değişikliklere daha dirençli, daha iyi eşleşmeler sağlayan bir sistem oluşturmanıza olanak tanır

organizasyonun mevcut yapıları. İşlevsel modelleme, örgütsel yapının değişim sürecinde olduğu veya genel olarak kötü biçimlendirildiği durumlarda kendini iyi gösterir. İşleve dayalı yaklaşım, sanatçılar tarafından mevcut çalışmaları hakkında onlardan bilgi alırken sezgisel olarak daha iyi anlaşılır.

İşlevsel modelleme yöntemi IDEF0 (İşlev Modelleme), herhangi bir konu alanındaki bir nesnenin işlevsel bir modelini oluşturmak için tasarlanmış bir dizi kural ve prosedürdür. Bir nesnenin işlevsel modeli, gerçekleştirdiği eylemleri ve bunlar arasındaki bağlantıları gösterir.

Bu yönteme göre iş modeli şöyle görünmelidir:

    Modelin en üst seviyesi, yalnızca sistemin bağlamını, yani dış dünya ile etkileşimini yansıtmalıdır.

    Modelin ikinci seviyesinde, işletmenin tüm ana faaliyetleri, diğer bir deyişle, işletmenin tematik olarak gruplandırılmış iş süreçleri ve ilişkileri olmalıdır.

    İş süreçlerinin daha fazla detaylandırılması, iş işlevleri, yani belirli kriterlere göre gruplandırılmış işlem kümeleri aracılığıyla gerçekleştirilir.

    Temel işletme operasyonlarının açıklaması, uygulanması için algoritma ayarlanarak gerçekleştirilir.

Veri Akış Diyagramları (DFD) - veri akış diyagramları. Tasarlanan sistemin fonksiyonel gereksinimlerini modellemek için ana araç.

Model bileşenleri: diyagramlar; bilgi sözlüğü; süreç özellikleri.

Grafiklerin elemanları: veri akışı; depolama; dış varlık.

Veri akışı, bilgileri sistemin bir bölümünden diğerine modellemek ve aktarmak için kullanılan bir mekanizmadır.

Harici varlık-nesne \\ konu sistem bağlamının dışında, yani.

Depolama, zaman içinde süreçler arasında depolanması gereken verileri içeren bir veri akışı dilimidir.

Ana avantajlar:

    sistem içindeki ve dışındaki bilgi akışlarını analiz ederek harici varlıkları açık bir şekilde tanımlama yeteneği;

    "olması gerektiği gibi" bir model oluşturmayı kolaylaştıran yukarıdan aşağıya tasarım yapma yeteneği;

    fonksiyonel modelin mantıksal eksikliğinin üstesinden gelmeye ve geliştirilmekte olan sistemin tam bir fonksiyonel spesifikasyonunu oluşturmaya izin veren daha düşük seviyedeki işlemlerin spesifikasyonlarının varlığı;

    modeller, özgüllüklerini yeterince yansıtan çok zengin bir dizi öğeye sahiptir;

    dFD hiyerarşisinin sistemler arası, sistem içi bağlantılar ve sistem hiyerarşisini gösteren yapısal haritalara otomatik olarak dönüştürülmesi için bir dizi CASE araçları algoritması var ve bunlar destekleniyor

Dezavantajları:

    dFD açısından kontrol eylemleri (akışlar) ve kontrol süreçleri sıradan olanlardan farklı olmadığından, kontrol süreçlerinin yapay olarak girilmesi ihtiyacı;

    zaman kavramının eksikliği, yani veri dönüşümü sırasında zaman aralıklarının analizinin yapılmaması (tüm zaman limitleri işlem özelliklerinde belirtilmelidir).

IDEF3 süreç modelleme yöntemi (Proses Tanımı Yakalama Metodu için Entegre Tanımlama) bir modelleme metodolojisi ve sistemde meydana gelen proseslerin belgelenmesi için bir standarttır. Süreç Dokümantasyon Yöntemi, süreçler hakkındaki bilgileri belgelemek ve toplamak için bir mekanizma sağlar. IDEF3, durumlar ve olaylar arasındaki nedensel ilişkileri, bir sistemin, sürecin veya işletmenin nasıl işlediğine ilişkin bilgiyi ifade etmek için yapılandırılmış bir yöntem kullanarak bir uzman tarafından anlaşılabilir bir biçimde gösterir.

IDEF3 veri kümesi tanımlama tekniği yapısal analizin bir parçasıdır. IDEF3, süreçleri tanımlamaya yönelik bazı metodolojilerin aksine, analisti aşırı derecede katı bir sözdizimi çerçevesiyle sınırlamaz, bu da eksik veya çelişkili modellerin yaratılmasına yol açabilir.

IDEF3 ayrıca bir süreç oluşturma yöntemi olarak da kullanılabilir. IDEF3, IDEFO'yu tamamlar ve daha sonra simülasyon analizi için kullanılabilecek modeller oluşturmak için ihtiyacınız olan her şeyi içerir.

2. "İşletmenin bilgisayar ekipmanının muhasebesi" bilgi sisteminin tasarımı

2.1 Yazılım ürünlerinin analizi

Bu tür bilgi sistemlerinin analizi, sistemlerin avantaj ve dezavantajlarını belirlemek ve aynı zamanda işlevselliği, arayüzü, tasarımı ve kullanım kolaylığını karşılaştırmak için yapılır. Aşağıdaki mevcut bilgi sistemleri şu şekilde bulundu:

    IT Invent yazılımı (it-invent.ru)

    Donanım Denetleme Yazılımı (hwinspector.com)

    Yapılandırma 1C: Bilgisayarlar ve ekipman 8.1 için muhasebe (odineskin.ru)

İlk IS, IT Invent, yalnızca bilgisayarlar, yazıcılar, programlar ve aksesuarlardan sorumlu değildir. Bu aynı zamanda onarım ve hizmetlerin, bakım işlerinin, tedarikçilere siparişlerin, ekipman makbuzlarının ve hareketlerinin, yüklenicilerin, çalışanların ve daha fazlasının muhasebeleştirilmesidir. IT Invent programının ana formu Şekil 1'de gösterilmektedir.

Şekil 1 "BT Buluşu"

IT Invent, sezgisel bir arayüze sahip, kullanıcı açısından tasarım açısından iyi korunan esnek ve özelleştirilebilir bir sistemdir. Program oldukça çok işlevlidir. Programın aşağıdaki temel özelliklerini not etmek istiyorum:

    MS Access ve MS SQL Server veritabanı desteği.

    Çok kullanıcılı çalışma modu - tüm şubeler tek bir tabanda çalışır.

    Çeşitli türlerde kendi ek özelliklerinizi oluşturma ve yapılandırma yeteneği.

    Kuruluş içinde her türlü işin performansının muhasebeleştirilmesi.

    Envanter etiketleri oluşturmak ve yazdırmak için benzersiz bir sistem. Barkod yazıcı desteği.

    Barkod tarayıcı ile çalışma desteği. Veritabanındaki kayıtları barkodla arayın.

    Ekipman değişikliklerinin geçmişini tutma.

    Ekipman ve bilgisayarların onarımları ve önleyici bakımı için muhasebe.

    Programların ve bileşenlerin ekipmanlarla mantıksal bağlanması.

    Sarf malzemelerinin, yedek parçaların ve büro malzemelerinin muhasebeleştirilmesi.

    Organizasyon çalışanlarına muhasebe birimleri atamak. Kabul sertifikaları.

    Tedarikçiler, hizmet kuruluşları ve diğer yüklenicilerden oluşan bir veri tabanının tutulması.

    Sistem kullanıcıları için esnek erişim haklarının farklılaştırılması.

    Programdaki olaylar için E-posta bildirimlerini yapılandırma.

    Çok sayıda yerleşik yazdırılabilir form ve rapor düzenleme özelliğine sahiptir.

    Verileri doğrudan Active Directory'den içe aktarın ve görüntüleyin.

IT Invent web tabanlıdır. Tek bir veritabanına sahip bir ağ üzerinde çalışmak için, "DBPath.ini" dosyasındaki programın her kullanıcısı için veritabanı dosyasına bağlanma yolunu belirtmek veya "Dosya" -\u003e "Veritabanı seç" menü öğesini seçerek bu yolu belirtmek gerekir. Bu durumda, tüm program kullanıcıları için okuma ve yazma izinleri için dizini veritabanı ile ayarlamayı unutmayın.

İkinci IC, Donanım Denetçisi programıdır. Program, kuruluşlardaki bilgisayar teknolojisi ve diğer ekipmanların otomatik muhasebesi ve envanteri için tasarlanmıştır. Hardware Inspector programının benzersizliği, yalnızca bilgisayar parametrelerinin mevcut durumunun değil, ayrı ayrı bileşenlerin tüm yaşam geçmişinin kayıtlarını tutma yeteneğinde yatmaktadır. Şekil 2, iş istasyonu ağacındaki cihazların görsel bir temsilini göstermektedir.

Şekil 2 "Donanım Denetçisi"

Arayüz basit ve sezgiseldir. Tasarım gelince, kabul edilebilir. Program çok işlevlidir. Aşağıdaki temel özellikleri vurgulamak istiyorum:

    Bilgisayar ve yazılımların detaylı muhasebesi;

    Muhasebe nesnelerinin yaşam döngüsü;

    Aygıtların, yazılımların, iş istasyonlarının ve ağ ayarlarının içe aktarılması;

    İşyerlerinin otomatik denetimi;

    Ağ geçişi;

    Sarf malzemelerinin hesaplanması ve planlanması;

    Kullanıcılardan gelen taleplerin muhasebeleştirilmesi;

    Muhasebe nesnelerinin envanteri;

    Esnek erişim kontrolü;

    Bilgi arayın;

    30'dan fazla yerleşik özel rapor;

    Muhasebenin tüm yönleriyle ilgili ayrıntılı kılavuzlar;

Donanım Müfettişi, ücretli. Bir lisans, programı tek bir yerel ağ, bir kuruluş içindeki herhangi bir sayıda bilgisayara yükleme hakkını verir.

Üçüncü IS, 1C yapılandırmasıdır: Bilgisayar ve ekipmanların muhasebeleştirilmesi 8.1. Ekipman muhasebesi temel olarak bar kodlamaya dayanır, bu nedenle herhangi bir arama, seçim veya teknik işlemi çok daha kolay hale gelir. Bu konfigürasyonun yardımıyla, bilgisayarların, ofis ekipmanlarının ve diğer maddi değerlerin (ekipman, telefonlar, mobilya) bir envanterini dikkate almak ve yapmak ve diğer faaliyet alanlarını otomatikleştirmek uygundur.

Şekil 3, 1C konfigürasyonunun temel şeklini göstermektedir.

Şekil 3 "1C: Bilgisayar ve teçhizat muhasebesi 8.1"

Ana ürün özellikleri:

    Herhangi bir ekipman, mobilya, yazılım için muhasebe,

    Seri, ekipman stok sayıları,

    Everest donanım denetim sisteminden içe aktarma (otomatik veri toplama)

    En uygun kullanıcı arayüzü

    Tedarikçilere verilen siparişlerin muhasebesi

kriter

Donanım Müfettişi

Yapılandırma 1C

İşlevsellik

Çok Fonksiyonlu

Çok Fonksiyonlu

Çok Fonksiyonlu

Arayüz

Sezgisel

Basit - sezgisel

En elverişli

Kabul edilebilir

Standart

Kullanıcı dostu

Kullanımı kolay

Bireysel ön ayarlar

Avantajları

Ağ üzerinden çalışır

    Yerel ağ üzerinden çalışır

    Ayda 2 kez güncelleme

    Bir lisans, bir yerel ağda, bir kuruluşta istediğiniz sayıda bilgisayara kurulabilir

Aktif ücretsiz hat e-posta ve ICQ ile istişareler ve gerekirse telefonla istişareler.

Dezavantajları

Ücretli program

Ücretli program

Ücretli program

    Kullanıcı isteklerinin muhasebeleştirilmesi ve onlarla birlikte çalışılması

    Sarf malzemeleri muhasebesi

    Tarama sırasında otomatik arama

    Bireysel ayar setleri vb.

Tablo 1'de seçilen bilgi sistemlerini aşağıdaki kriterlere göre karşılaştıralım: İşlevsellik, Arayüz, Tasarım, Kullanım kolaylığı, Avantaj ve dezavantajları;

Tablo 1 - Bilgi sistemlerinin karşılaştırılması

Sonuç: Değerlendirilen tüm bilgi sistemleri, işletmenin bilgisayar ekipmanının muhasebesi için gerekli tüm işlevleri içerir. Hepsi çok fonksiyonlu, kullanışlı ve kullanımı kolay, sezgisel bir arayüze sahip. Tüm programların tek dezavantajı, hepsine ücret ödenmesidir.

2.2 İş Süreç Şemalarının Tanımı "Kurumsal bilgisayar ekipmanlarının muhasebesi"

2.2.1 IDEF0 diyagramının açıklaması

İş sürecini oluşturmak için bir IDEF0 diyagramı kullanıldı. IDEF0 metodolojisi, hiyerarşik bir diyagram sisteminin - sistem parçalarının tek tanımlarının - oluşturulmasını öngörmektedir. İlk olarak, sistemin bir bütün olarak bir tanımı ve dış dünya ile etkileşimi gerçekleştirilir (bağlam diyagramı). Diyagramın üç seviyesi oluşturuldu:

    Bağlamsal

    Fonksiyonel ayrışma

    Her işin ayrıştırılması

Şekil 1 - Bağlam diyagramı "Kurumsal bilgisayar ekipmanı için muhasebe"

Şekil 1, "Kurumsal bilgisayar ekipmanı için muhasebe" iş sürecinin bir bağlam diyagramını göstermektedir. Sistemi bir bütün olarak görüntüler ve ana dış bilgi akışlarıyla etkileşimini gösterir.

Oklar içerik diyagramında belirtilmiştir.

Ok türleri:

İşleme için giriş bilgileri:

Bilgisayarlar - İşletmede bulunan bilgisayarlar (kişisel bilgisayarlar)

Bileşenler - bilgisayarları yükseltmek için gerekli malzemeler (ekran kartları, anakartlar, işlemciler, kasalar, güç kaynakları, bellek modülleri)

Çıktı akışları:

Rapor - kurumsal bilgisayar ekipmanlarının muhasebesi hakkında hazır bir rapor

Giriş kontrolleri:

Kurallar - hedefe ulaşmak için yerine getirilmesi gereken koşullar.

Siparişler - işletmeye atanan görev (belirli bilgi sistemlerini kullanarak işletmedeki bilgisayar ekipmanlarının kayıtlarını tutmak için)

Yöneticiler işletmenin müdürleri ve genel müdürleridir.

Girdi Kaynakları:

PC - muhasebe için kullanılan bilgisayarlar.

Çalışanlar yönetim tarafından verilen talimatları takip eden uzmanlardır. Kavramsal bir model oluşturulduktan sonra, işlevsel bir ayrışma gerçekleştirildi - sistem alt sistemlere ayrıldı ve her alt sistem ayrı ayrı tanımlandı (ayrışma diyagramları).

Şekil 2, dört işin işlevsel bir ayrışmasını göstermektedir.

Şekil 2 - İşlevsel ayrışma "Kurumsal bilgisayar ekipmanı için muhasebe"

Aşağıdaki çalışma türleri tanımlanmıştır:

    Teslimatların kaydı, ürüne id atanma, depoya gönderilme, depoya gönderilme ve ürüne ait bilgilerin programa girilmesi işlemidir.

Malzeme teslimi işi yedi sınır okunu (giriş, kontrol, mekanizma) ve bir iç ok yapraklarını (giriş ile bağlantı) içerir.

Çalışmalar arasındaki girişte ok iletişimi Teslimatların kaydedilmesi ve Bilgisayarın bakımı (bilgisayar);

Sonraki eserlerde giriş, çıkış, kontrol okları tekrarlanır.

    Bilgisayar bakımı, bilgisayarların bir araya getirildiği, onarıldığı ve yükseltildiği süreçtir.

Bilgisayar Bakım çalışması dört sınır okunu (giriş, kontrol, mekanizma, çıkış) ve birkaç dahili ok (giriş iletişimi, giriş geri bildirimi) içerir.

Ok kontrolü - kurallar, emirler, lider;

Bilgisayar bakımı ve Yerleşimi (veritabanına veri girme), Bilgisayar bakımı ve Raporlama (veriye veri girme) işleri arasında girişte ok bağlantısı;

    Düzenleme, ofislerde (ofislerde) bilgisayarların düzenlenmesinin yapıldığı bir süreçtir.

Oklar kontrolü - kurallar, siparişler, lider;

Ok mekanizması - çalışanlar;

Düzenleme ve Raporlama arasındaki girdideki ok bağlantısı (kimlik atama);

    Raporlama, cari muhasebenin önceki verileri kullanılarak elde edilen toplamların özetlenmesinden oluşan muhasebe sürecinin son aşamasıdır.

Daha sonra her bir alt sistem daha küçük ayrıştırmalara bölünür ve istenen ayrıntı derecesi elde edilene kadar bu şekilde devam eder.

Şekil 3, Tedarik çalışmalarını daha ayrıntılı olarak gösteren bir diyagramdır.

Detaylandırma sonucunda ana fonksiyonlar vurgulanmıştır. "Sarf malzemelerinin kaydı" bölümü yedi ana ok içerir (giriş, çıkış, kontrol, mekanizma).

Ok girişi - bilgisayarlar ve aksesuarlar;

Kontrol okları kurallar, emirler ve bir liderdir. Çatal oklar;

Mekanizma okları, dallanma - PC, çalışanlar;

Giriş, kontrol, mekanizma okları tüm çalışmalarda tekrarlanır.

    Numara atama - bilgisayarlara ve aksesuarlara ayrı ayrı numaralar atama.

Giriş okları - bilgisayarlar ve aksesuarlar. Raporun derlenmesi dışında sonraki çalışmalarda ok bilgisayarları tekrarlanır;

Kontrol okları - kurallar, siparişler ve lider;

Mekanizma Okları - PC ve Çalışanlar;

Eserler arasındaki girişte ok bağlantısı Bir numara atama ve Depoya mal gönderme (transfer), bir numara atama ve Dengeye koyma (tabana giriş) arasında;

    Malların depoya gönderilmesi - atanmış bir numaraya sahip malların depoya gönderilmesi.

Çıkış Ok - Bilgisayar;

Kontrol okları - kurallar, emirler ve lider.

"Depoya mal gönderme" ve "Dengeye koyma" (miktar) çalışmaları arasındaki girişte ok bağlantısı;

    Dengeleme - bilgisayara bilgi girme.

Kontrol okları - kurallar, siparişler ve lider;

Mekanizma Okları - PC ve Çalışanlar;

Şekil 4, bilgisayar bakımını daha ayrıntılı olarak gösteren bir diyagramdır.

Detaylandırma sonucunda, Bilgisayar bakımı sürecinde gerçekleştirilen ana işlevler belirlenmiştir.

Bilgisayar bakımı 4 sınır oku içerir (giriş, çıkış, kontrol, mekanizma). Dahili oklar (giriş geri beslemesi, giriş iletişimi).

    Bilgisayar montajı - bilgisayarların yöneticilerin bireysel siparişlerine göre yapılandırılması.

Giriş oku - bilgisayarlar;

Kontrol okları - kurallar, siparişler ve lider;

Mekanizma Okları - Çalışanlar;

Eserler arasındaki girişteki ok bağlantısı: "Bilgisayarların montajı" ve "Bilgisayarların onarımı" (bilgisayar);

    Bilgisayar onarımı - iyileştirme için onaylanan bilgisayarların montajı.

Giriş oku - bilgisayarlar;

Çıkış oku - tabana giriş;

Kontrol okları - kurallar, siparişler ve lider;

Mekanizma Okları - Çalışanlar;

Giriş, çıkış, kontrol, mekanizma okları dallanıyor;

Çalışmalar arasındaki girişteki ok bağlantısı: "Bilgisayar onarımı" ve "Yükseltme" (aksesuarlar);

    Yükseltme - iyileştirme, iyileştirme, bilgisayar yükseltme.

Çıkış oku - tabana giriş;

Kontrol okları - kurallar, siparişler ve lider;

Mekanizma Okları - Çalışanlar;

Kontrol okları, mekanizma dallanıyor;

Şekil 5 Raporlama çizelgesini daha ayrıntılı olarak göstermektedir. İş ayrışımı Raporlama 4 sınır oku (giriş, çıkış, kontrol, mekanizmalar) içerir. Dahili oklar (giriş geri bildirimi, giriş iletişimi).

Çalışmanın bir sonucu olarak, aşağıdaki işlevler türetilmiştir:

    Veri toplama - analiz ve karar verme için bilgi toplama.

Ok girin - bir kimlik atama;

Kontrol okları - kurallar, siparişler ve lider;

Giriş, kontrol, mekanizma okları dallanıyor;

İşler arasındaki girişte ok bağlantısı: Veri toplama ve Veri doğrulama (kayıtlar);

    Veri doğrulama - bilgileri kontrol etme ve raporlama için gönderme.

Giriş oku - kimlik atama, veritabanına veri girme;

Çıkış oku - Rapor;

Kontrol okları - kurallar, siparişler ve lider;

Mekanizma Okları - Çalışanlar, PC;

Giriş okları (kimlik atama), kontrol, mekanizma çatallanıyor;

“Veri kontrolü” ndan “Veri toplama” ya (tekrarlanan kontrol) geri bildirim oku girin.

Görmeyi ve anlamayı öğrenin fonksiyonel yapı senin işin!

Şu anda, Rusya'da, Batı'da genel kabul gören yönetim standartlarına olan ilgi keskin bir şekilde artmıştır, ancak gerçek yönetim uygulamasında çok belirleyici bir an vardır. Birçok lider hala doğrudan soru ile şaşkına dönebilir örgütsel yapı şirket veya mevcut iş süreçlerinin şeması hakkında. Ekonomik süreli yayınları düzenli olarak okuyan en gelişmiş yöneticiler, kural olarak, sadece anladıkları hiyerarşik diyagramlar çizmeye başlarlar, ancak bu süreçte bile genellikle çabucak bir çıkmaz noktasına gelirler. Aynı durum, çeşitli hizmetlerin ve işlevsel birimlerin çalışanları ve yöneticileri için de geçerlidir. Çoğu durumda, bir teşebbüsün faaliyet göstermesi gereken kurallar sadece bir dizi hükümdür ve iş tanımları... Çoğu zaman, bu belgeler bir yıldan fazla bir süre önce hazırlandı, kötü yapılandırıldı ve birbirine bağlı değil ve sonuç olarak raflarda toz topladı. Şimdilik, böyle bir yaklaşım haklıydı, çünkü Rus piyasa ekonomisinin oluşumu sırasında rekabet kavramı pratikte yoktu ve maliyetleri dikkate almaya özel bir ihtiyaç yoktu - kâr çok büyüktü. Bunun sonucu olarak, son iki yılda oldukça anlaşılır bir tablo gördük: büyük şirketler90'lı yılların başında büyüyen, pazardan tamamen geri çekilmek için kademeli olarak pozisyonlarını kaybediyor. Bu, kısmen, işletmenin yönetim standartlarını uygulamamış olmasından, işlevsel bir faaliyet modeli ve misyon kavramının tamamen eksik olmasından kaynaklanmaktadır. Çeşitli faaliyet alanlarının modellenmesi yardımıyla, yönetimdeki darboğazları etkili bir şekilde analiz etmek ve genel iş planını optimize etmek mümkündür. Ancak, bildiğiniz gibi, herhangi bir kuruluşta, yalnızca doğrudan kâr getiren projeler en yüksek önceliğe sahiptir, bu nedenle, genellikle sadece şirketin yönetiminde somut bir kriz sırasında faaliyetlerin araştırılması ve yeniden yapılandırılması hakkında konuşuyoruz.

Pazarın yeterince rekabetçi olduğu ve işletmelerin karlılığının keskin bir şekilde düşmeye başladığı 90'lı yılların sonunda, yöneticiler ürünlerin hem karlı hem de rekabetçi kalmasını sağlamak için maliyetleri optimize etmeye çalışırken muazzam zorluklar yaşadılar. Şu anda, bir işletme çerçevesinde çeşitli alt sistemlerin birbirine bağlanmasının tüm mekanizmalarını ve ilkelerini yansıtacak bir girişim faaliyetinin gözünüzün önünde bir modele sahip olma ihtiyacı oldukça açık hale geldi.

“İş süreçleri modelleme” kavramı, çoğu analistin günlük hayatına, aynı zamanda, işletme yönetiminin karmaşık otomasyonu için tasarlanmış karmaşık yazılım ürünleri pazarında ortaya çıkmasıyla birlikte geldi. Bu tür sistemler her zaman şirketin faaliyetlerinin derin bir proje öncesi araştırması anlamına gelir. Bu anketin sonucu, faaliyetlerin yönetiminde "darboğazları" ortadan kaldırmak için münferit paragrafların önerildiği bir uzman görüşüdür. Bu sonuca dayanarak, bir otomasyon sistemi getirme projesinden hemen önce, iş süreçlerinin yeniden düzenlenmesi, bazen şirket için oldukça ciddi ve acı verici olarak gerçekleştirilir. Doğaldır ki, yıllar içinde gelişen kolektifin “yeni bir şekilde düşünmeye” zorlaması her zaman zordur. İşletmelerin bu tür karmaşık anketleri her zaman karmaşıktır ve durumdan duruma göre önemli ölçüde farklıdır. Karmaşık sistemlerin modellenmesi gibi sorunların çözümü için iyi denenmiş metodolojiler ve standartlar vardır. Bu standartlar IDEF ailesinin metodolojilerini içerir. Onların yardımıyla çeşitli bölümlerdeki çok çeşitli karmaşık sistemlerin faaliyet modellerini etkili bir şekilde görüntülemek ve analiz etmek mümkündür. Aynı zamanda, sistemdeki süreçlerin anketinin 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, IDEF ailesine aşağıdaki standartlar atfedilebilir:

IDEF0 işlevsel bir modelleme metodolojisidir. Görsel grafik dili IDEF0 yardımıyla, incelenmekte olan sistem, geliştiricilere ve analistlere birbiriyle ilişkili işlevler kümesi olarak (fonksiyonel bloklar - IDEF0 açısından) görünür. Tipik olarak, IDEF0 modellemesi herhangi bir sistem hakkında öğrenmenin ilk adımıdır;

IDEF1 - yapılarını ve ilişkilerini görüntülemenize ve analiz etmenize olanak tanıyan sistem içindeki bilgi akışlarını modellemek için bir metodoloji;

IDEF1X (IDEF1 Genişletilmiş) - ilişkisel yapılar oluşturmak için metodoloji. IDEF1X, "Varlık-ilişki" (ER - Varlık-İlişki) metodolojisinin türünü ifade eder ve kural olarak, söz konusu sistemle ilgili ilişkisel veritabanlarını modellemek için kullanılır;

IDEF2, sistem evriminin dinamik modellemesi için bir metodolojidir. Dinamik sistemlerin analizindeki çok ciddi zorluklar nedeniyle, bu standart pratik olarak terk edildi ve gelişimi çok askıya alındı. İlk aşama... Ancak, günümüzde bir dizi statik IDEF0 diyagramını “renkli Petri ağlarına” (CPN - Renkli Petri Ağları) dayalı dinamik modellere dönüştürmeyi mümkün kılan algoritmalar ve bunların bilgisayar uygulamaları vardır;

IDEF3, örneğin işletmelerdeki teknolojik süreçlerin incelenmesinde kullanılan, sistemde meydana gelen süreçleri belgelemek için bir metodolojidir. IDEF3, her işlem için senaryo ve iş akışını açıklar. IDEF3'ün IDEF0 metodolojisi ile doğrudan bir ilişkisi vardır - her fonksiyon (fonksiyonel blok), IDEF3 aracılığıyla 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 altında yatan ilkeleri görsel olarak görüntülemenizi sağlar, böylece karmaşık nesne yönelimli sistemleri analiz etmenize ve optimize etmenize olanak tanır;

IDEF5 karmaşık sistemlerin ontolojik incelemesi için bir metodolojidir. IDEF5 metodolojisi kullanılarak, bir sistemin ontolojisi, belirli bir zaman noktasında dikkate alınan sistemin durumu hakkında güvenilir ifadeler oluşturulabilen belirli bir terim ve kural sözlüğü kullanılarak tanımlanabilir. Bu ifadelere dayanarak, sistemin daha da geliştirilmesi ile ilgili sonuçlar oluşturulmakta ve optimizasyonu yapılmaktadır.
Bu yazıda, IDEF0'ın en sık kullanılan fonksiyonel modelleme metodolojisine bakacağız.

IDEF0 standardının geçmişi

IDEF0 metodolojisi, fonksiyonel sistemleri SADT (Yapısal 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, Rusya'da aynı addaki kitabın SADT diyagramlarını oluşturmanın temel prensiplerini tanımlamaya yönelik küçük bir baskısı yayınlandı. Tarihsel olarak, IDEF0 standart olarak kapsamlı bir otomasyon programının bir parçası olarak 1981 yılında geliştirilmiştir. endüstriyel GirişimcilikICAM (Entegre Bilgisayar Destekli Üretim) adını taşıyan ve departman tarafından önerilen Hava Kuvvetleri AMERİKA BİRLEŞİK DEVLETLERİ. IDEF standart ailesi, atamasını bu programın adından miras almıştır (IDEF \u003d ICAM TANIMI). Süreç içerisinde pratik uygulamaICAM programına katılanlar, endüstriyel sistemlerde etkileşim süreçlerini analiz etmek için yeni yöntemler geliştirme ihtiyacı ile karşı karşıya kaldılar. Aynı zamanda, iş süreçlerini açıklamak için geliştirilmiş bir işlevler setine ek olarak, yeni standardın gerekliliklerinden biri, "analist-uzman" çerçevesinde etkileşim için etkili bir metodolojinin mevcudiyetiydi. Diğer bir deyişle, yeni yöntem projeye katılan tüm analistlerin ve uzmanların doğrudan katılımıyla modelin oluşturulması üzerine grup çalışması sağlaması gerekiyordu.

Uygun çözüm arayışlarının bir sonucu olarak, IDEF0 fonksiyonel modelleme metodolojisi doğdu. 1981'den bu yana, IDEF0 standardı, çoğunlukla sınırlayıcı nitelikte birkaç küçük değişikliğe uğramıştır ve son revizyonu ABD Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) tarafından Aralık 1993'te yayınlanmıştır.

IDEF0'ın temel öğeleri ve kavramları

Grafik dili IDEF0 şaşırtıcı derecede basit ve uyumludur. Metodoloji dört ana kavram üzerine kuruludur.

Bunlardan ilki Etkinlik Kutusu kavramıdır. Fonksiyonel bir blok grafik olarak bir dikdörtgen şeklinde gösterilir (bkz. Şekil 1) ve söz konusu sistem çerçevesinde bazı belirli işlevleri kişileştirir. Standardın gerekliliklerine göre, her bir işlevsel bloğun adı fiil modunda formüle edilmelidir (örneğin, "hizmet üretimi" değil, "hizmet üretme").

Fonksiyonel bir bloğun dört tarafının her birinin kendine özgü bir anlamı (rolü) vardır:

  • Üst taraf “Kontrol” dür;
  • Sol taraf “Giriş” olarak ayarlanmıştır;
  • Sağ taraf "Çıktı" olarak ayarlanır;
  • Alt taraf “Mekanizma” dır.

    • Tek bir dikkate alınan sistemdeki her fonksiyonel bloğun kendine özgü bir kimlik numarası olmalıdır.

    Şekil 1. Fonksiyonel blok.

    IDEF0 metodolojisinin ikinci "balinası", bir arayüz yayı (Ok) kavramıdır. Ayrıca, arayüz yaylarına genellikle akışlar veya oklar denir. Arayüz yayı, bir fonksiyon bloğu tarafından işlenen veya o fonksiyon bloğu tarafından görüntülenen fonksiyonu başka şekilde etkileyen bir sistem öğesini görüntüler.

    Arayüz yayının grafiksel gösterimi tek yönlü bir oktur. Her arabirim yayının kendine özgü bir adı olmalıdır (Ok Etiketi). Standardın gerektirdiği gibi, isim isim devri olmalıdır.

    Arayüz yaylarının yardımıyla, sistemde gerçekleşen süreçleri bir dereceye kadar belirleyen çeşitli nesneler görüntülenir. Bu tür nesneler gerçek dünyanın öğeleri (parçalar, arabalar, çalışanlar, vb.) Veya veri ve bilgi akışları (belgeler, veriler, talimatlar, vb.) Olabilir.

    Verilen arayüz yayının hangi taraf için uygun olduğuna bağlı olarak, buna “gelen”, “giden” veya “kontrol” denir. Ek olarak, sadece fonksiyonel bloklar her bir fonksiyonel arkın “kaynağı” (başlangıç) ve “lavabo” (sonu) olabilirken, “kaynak” sadece bloğun çıktı tarafı olabilir ve “lavabo” kalan üç taneden biri olabilir.

    Standardın gerekliliklerine göre herhangi bir fonksiyonel bloğun en az bir kontrol arayüzü arkına ve bir giden bloğa sahip olması gerektiğine dikkat edilmelidir. Bu anlaşılabilir bir durumdur - her işlem bazı kurallara uymalıdır (kontrol yayı tarafından görüntülenir) ve bir sonuç üretmelidir (giden yay), aksi takdirde bunu dikkate almak mantıklı değildir.

    IDEF0 - diyagramlarını oluştururken, gelen arayüz yaylarını kontrol olanlardan doğru bir şekilde ayırmak önemlidir, bu genellikle zordur. Örneğin, şekil 2 "İş parçasını işle" fonksiyon bloğunu göstermektedir.

    Gerçek bir süreçte, işlemeyi gerçekleştiren işçiye işleme için bir iş parçası ve teknolojik talimatlar (veya makineyle çalışırken güvenlik kuralları) verilir. Hem boş hem de teknolojik talimatlara sahip belgenin gelen nesneler olduğunu düşünmek yanlış olabilir, ancak bu böyle değildir. Aslında, bu işlemde, iş parçası sırasıyla kontrol arayüzü arkının göstermesi 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, zaten gelen bir arayüz arkı olarak görüntülenirler ve kontrol nesnesi, örneğin, bu değişikliklerin yapıldığı temelde yeni endüstriyel standartlardır.


    Figür 3.

    Yukarıdaki örnekler, gelen ve giden arayüz yaylarının görünüşte benzer doğasını vurgular, ancak aynı sınıftaki sistemler için her zaman belirli farklılıklar vardır. Örneğin, işletmelerin ve kuruluşların dikkate alınması durumunda, beş ana nesne türü vardır: malzeme akışı (parçalar, mallar, hammaddeler, vb.), finansal akışlar (nakit ve gayri nakdi, yatırımlar, vb.), belge akışları (ticari, finansal ve organizasyonel belgeler), bilgi akışları (bilgi, niyetlere ilişkin veriler, sözlü talimatlar) vb.) ve kaynaklar (çalışanlar, makineler, makineler vb.). Bu durumda, çeşitli durumlarda, her tür nesne, yalnızca belge ve bilgi akışlarıyla ilgili olanları kontrol eden gelen ve giden arabirim yayları tarafından görüntülenebilir ve yalnızca kaynaklar yay mekanizmaları tarafından görüntülenebilir.

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

    IDEF0 standardının üçüncü temel konsepti Ayrıştırmadır. Ayrışma ilkesi, karmaşık bir işlemi kurucu işlevlerine ayırırken uygulanır. Bu durumda, sürecin detay seviyesi doğrudan model geliştirici tarafından belirlenir.

    Ayrışma, sistem modelini kademeli olarak ve yapılandırılmış olarak, bireysel diyagramların hiyerarşik bir yapısı olarak temsil etmenizi sağlar, bu da daha az aşırı yüklenmesini ve sindirilmesini kolaylaştırır.

    IDEF0 modeli her zaman sistemin bir bütün olarak sunulmasıyla başlar - dikkate alınan alanın ötesine uzanan arayüz yaylarına sahip tek bir fonksiyonel blok. Bir fonksiyonel bloğa sahip böyle bir şemaya bağlam diyagramı denir ve “A-0” tanımlayıcısı ile gösterilir.

    Bağlam diyagramı için açıklayıcı metin, şemayı formda oluşturmanın Amacını belirtmelidir kısa açıklama ve bakış açısı (Bakış açısı) sabitlenir.

    Bir IDEF0 modeli geliştirme hedefinin belirlenmesi ve resmileştirilmesi son derece önemlidir. Aslında amaç, incelenen sistemde öncelikle odaklanılması gereken ilgili alanları tanımlar. Örneğin, gelecekte bu modele dayanarak bir bilgi sistemi kurmak için bir işletmenin faaliyetlerini modellersek, o zaman bu model aynı işletme için geliştireceğimiz modelden önemli ölçüde farklı olacaktır, ancak tedarik zincirlerini optimize etmek amacıyla.

    Bakış açısı, modelin ana gelişim yönünü ve gerekli ayrıntı seviyesini tanımlar. Bakış açısının net bir şekilde sabitlenmesi, sistemdeki seçilen bakış açısına dayanarak gerekli olmayan bireysel unsurları detaylandırmayı ve incelemeyi reddederek modeli boşaltmanıza izin verir. Örneğin, aynı işletmenin baş teknoloji uzmanı ve mali direktör açısından fonksiyonel modelleri, detaylandırma yönünden önemli ölçüde farklılık gösterecektir. Bunun nedeni, sonuçta, CFO'nun hammaddelerin üretim makinelerinde işlenmesi yönleriyle ilgilenmemesidir ve baş teknoloji uzmanının çizilmiş finansal akış şemalarına ihtiyacı yoktur. Doğru seçim bakış açısı, 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 delinir. İ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 göre bir alt diyagram olarak adlandırılır (bir alt diyagrama ait fonksiyonel blokların her birine sırasıyla bir çocuk bloğu - Çocuk Kutusu denir). Buna karşılık, ana fonksiyon bloğuna alt diyagrama (Ana Kutu) göre ana blok adı verilir ve ait olduğu şemaya ana diyagram (Ana Diyagram) denir. Çocuk diyagramının alt fonksiyonlarının her biri, karşılık gelen fonksiyonel bloğun benzer bir ayrıştırılmasıyla daha da detaylandırılabilir. Fonksiyonel bir bloğun her ayrışması durumunda, bu blokta yer alan veya ondan çıkan tüm arayüz yaylarının alt diyagramda sabitlendiğini belirtmek önemlidir. Bu, IDEF0 modelinin yapısal bütünlüğünü sağlar. Ayrışma ilkesi Şekil 4'te açıkça gösterilmiştir. Fonksiyonel blokların ve diyagramların numaralandırılması arasındaki ilişkiye dikkat etmelisiniz - her bloğun diyagram üzerinde kendi benzersiz seri numarası vardır (dikdörtgenin sağ alt köşesindeki sayı) ve sağ açıda 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ığı anlamına gelir.

    Hiyerarşide belirli bir seviyenin altındaki alt diyagramlardaki bireysel arayüz yaylarını ya da tam tersini düşünmeye devam etmenin mantıklı olmadığı durumlar vardır - bireysel yaylar belirli bir seviyenin üzerinde pratik anlam ifade etmez. Örneğin, “bir torna üzerinde işlenir” fonksiyon bloğunun girişinde bir “detay” ı gösteren arayüz arkını daha yüksek seviyeli diyagramlarda yansıtmak mantıklı değildir - bu sadece diyagramları aşırı yükler ve anlaşılmasını zorlaştırır. Öte yandan, ayrı “kavramsal” arayüz yaylarından kurtulma ve bunları belirli bir seviyeden daha derin detaylandırmama ihtiyacı var. Bu tür sorunları çözmek için IDEF0 standardı tünelleme kavramını sağlar. Arabirim yayının başlangıcında iki parantez biçimindeki Ok Tüneli ataması, bu yayın fonksiyonel ana bloktan miras alınmadığını ve sadece bu diyagramda ("tünelden") ortaya çıktığını gösterir. Buna karşılık, alıcı bloğun hemen yakınındaki arayüz yayının ucu (ok) etrafındaki aynı isim, bu yayın görüntülendiğini ve bu bloğun alt diyagramında dikkate alınmayacağı anlamına gelir. Çoğu zaman, tek tek nesneler ve bunlara karşılık gelen arayüz yayları hiyerarşinin bazı ara seviyelerinde dikkate alınmaz - bu durumda, önce "tünele daldırılırlar" ve ardından gerekirse "tünelden geri döndürülürler".

    IDEF0 kavramlarının sonuncusu Sözlük'tür. IDEF0 öğelerinin her biri için: diyagramlar, işlevsel bloklar, arayüz yayları, mevcut standart, bu öğe tarafından görüntülenen nesneyi karakterize eden bir dizi ilgili tanımın, anahtar kelimelerin, anlatımların, vb. Oluşturulması ve sürdürülmesi anlamına gelir. Bu kümeye sözlük denir ve bu öğenin özünün bir tanımıdır. Örneğin, kontrol arayüzü ark “ödeme emri” için, sözlükte ark, gerekli vize seti vb. İle ilgili belgenin alanlarının bir listesini içerebilir. Sözlük, grafik dilini uyumlu bir şekilde tamamlayarak diyagramlara gerekli ek bilgileri sağlar.


    Şekil 4. Fonksiyonel blokların ayrışması.

    IDEF0 diyagramlarının karmaşıklığını sınırlama ilkeleri

    Tipik olarak, IDEF0 modelleri karmaşık ve konsantre bilgiler taşır ve tıkanıklıklarını sınırlamak ve okunabilir hale getirmek için karşılık gelen karmaşıklık sınırları ilgili standartta kabul edilir:

    Diyagramdaki fonksiyonel blok sayısının üç ila altı ile sınırlandırılması. Üst sınır (altı) tasarımcıyı karmaşık öğeleri tanımlarken hiyerarşiler kullanmaya zorlar ve alt sınır (üç) ilgili diyagramda oluşturulmasını haklı çıkarmak için yeterli ayrıntı olmasını sağlar;

    Bir fonksiyonel blok (bir fonksiyonel blok bırakarak) için uygun arabirim arklarının sayısını dört ile sınırlamak.
    Tabii ki, bu kısıtlamalara kesinlikle uymak gerekli değildir, ancak deneyimin gösterdiği gibi, bunlar gerçek işte çok pratiktir.

    IDEF0 modelinin geliştirilmesi üzerine grup çalışması disiplini

    IDEF0 standardı, simüle edilmiş sistemin farklı alanlarından büyük bir grup insanın bir model geliştirmesine ve üzerinde anlaşmasına izin veren bir dizi prosedür içerir. Tipik olarak, geliştirme süreci yinelemelidir ve aşağıdaki koşullu aşamalardan oluşur:

    İşletmenin çeşitli alanlarıyla ilgili bir grup uzman tarafından bir model oluşturulması. IDEF0 açısından bu gruba Yazar denir. Bir başlangıç \u200b\u200bmodeli oluşturmak, yazarların çeşitli süreçlerin yapısı hakkında yetkin kişilerle röportaj yaptığı dinamik bir süreçtir. Mevcut hükümler, belgeler ve anket sonuçlarına dayanarak, modelin bir taslağı (Model Taslağı) yaratılır.

    İnceleme, onay ve yorumlar için taslağın dağıtımı. Bu aşamada taslak model, kuruluştaki çok çeşitli yetkin kişilerle (IDEF0 okuyucuları açısından) tartışılmaktadır. Bu durumda, taslak modelin diyagramlarının her biri eleştirilir ve yazılı olarak yorumlanır ve ardından yazara aktarılır. Yazar, sırayla, eleştiriyle yazılı olarak hemfikirdir veya karar verme mantığını özetleyerek reddeder ve gözden geçirilmiş taslağı daha fazla ele almak için geri gönderir. Bu döngü yazarlar ve okuyucular bir fikir birliğine varıncaya kadar devam eder.

    Model onayı. Onaylanan model, modelin yazarları ile okuyucuların yeterliliği konusunda anlaşmazlıkları olmaması durumunda çalışma grubu başkanı tarafından onaylanır. Nihai model, işletmenin (sistemin) belirli bir bakış açısından ve belirli bir amaç için tutarlı bir görünümüdür.
    IDEF0 grafik dilinin görünürlüğü, modeli yaratılış projesinde yer almayan insanlar için oldukça okunabilir hale getirir, aynı zamanda şovlar ve sunumlar için etkilidir. Gelecekte, inşa edilen model temelinde, işletmede (sistemde) değişiklik yapmaya yönelik yeni projeler organize edilebilir.

    IDEF0 ile fonksiyonel modelleme kullanma ulusal uygulamasının özellikleri

    Son yıllarda, IDEF ailesinin metodolojilerine ilgi Rusya'da giderek artmaktadır. Bu standartların temel ilkelerini kısaca anlatan kişisel web sayfama (http://www.vernikov.ru) çağrı istatistiklerine bakarak bunu sürekli gözlemliyorum. Aynı zamanda, IDEF3-5 teorik ve IDEF0 gibi standartlara olan ilgiyi pratik olarak haklı olarak adlandırırım. Nitekim, DFD ve IDEF0 diyagramlarının oluşturulmasına izin veren ilk Vaka araçları, 1996 yılında Rusya pazarında, aynı zamanda SADT standartlarında modelleme ilkeleri hakkındaki popüler kitabın yayınlanmasıyla birlikte 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 yolu olmaktan ziyade bir moda ifadesi olarak görmektedir. Bunun nedeni büyük olasılıkla hakkında bilgi eksikliği pratik uygulama bu metodolojiler ve yayınların mutlak çoğunluğunun vazgeçilmez yazılım önyargısı ile.

    Şu anda Rusya'daki işletmelerin finansal ve ekonomik faaliyetlerinin araştırılması ve analizi için neredeyse tüm projelerin bir şekilde inşaatla ilgili olduğu bir sır değil. otomatik sistemler yönetimi. Bu nedenle, çoğunluğun anlaşılmasındaki IDEF standartları, bilgi teknolojilerinin uygulanmasından şartlı olarak ayrılmaz hale gelmiştir, ancak bunların yardımıyla, küçük bir yerel problemi bile tam anlamıyla bir kalem ve kağıt yardımıyla etkili bir şekilde çözmek mümkündür.

    Karmaşık kurumsal anket projeleri yürütürken, IDEF0 standardında modellerin geliştirilmesi, kurumsal faaliyetlerin tüm mekanizmasını görsel olarak ve etkili bir şekilde istenen bağlamda görüntülemenizi sağlar. Ancak en önemlisi, IDEF0'ın sağladığı işbirliği. Uygulamamda, modelin inşasının çeşitli departmanlardaki çalışanların doğrudan yardımı ile gerçekleştirildiği birçok durum vardı. Aynı zamanda danışman, IDEF0'ın temel prensiplerini oldukça kısa bir sürede açıkladı ve onlara ilgili uygulama yazılımı ile nasıl çalışılacağını öğretti. Sonuç olarak, çeşitli departmanların çalışanları, aşağıdaki soruları cevaplayacak olan fonksiyonel birimlerinin faaliyetlerinin IDEF diyagramlarını oluşturdu:

    "Girişte" birime ne gidiyor?

    Ünite içinde hangi fonksiyonlar ve hangi sırayla gerçekleştirilir?

    Her fonksiyondan kim sorumlu?

    Her bir işlevi yerine getirirken yürütücü ne tarafından yönlendirilir?

    Ünitenin çalışmasının (çıktısının) sonucu nedir?

    Her bir bölüm içindeki taslak diyagramları üzerinde anlaştıktan sonra, danışman tarafından tüm girdi ve çıktı elemanlarının bağlı olduğu bir taslak işletme modeline monte edilirler. Bu aşamada, bireysel şemaların tüm çelişkileri ve tartışmalı yerleri kaydedilir. Ayrıca, bu model daha fazla mutabakat ve gerekli düzenlemeler için fonksiyonel bölümlerden tekrar geçer. Sonuç olarak, oldukça kısa bir sürede ve bir danışmanlık firmasından minimum insan kaynağının dahil edilmesiyle (ve bu kaynaklar, bildiğiniz gibi, çok pahalıdır), bir işletmenin IDEF0 modeli "Olduğu gibi" prensibine göre elde edilir ve önemli olan, içinde çalışan ve gayri resmi olanlar da dahil olmak üzere tüm nüansları iyi bilen çalışanların pozisyonları. Gelecekte, bu model analiz ve işleme için şirket yönetiminde darboğazları arayacak ve kilit süreçleri optimize edecek ve “Olduğu gibi” modeli karşılık gelen “Olması gerektiği gibi” görünümüne dönüştürecek iş analistlerine aktarılacaktır. Bu değişikliklere dayanarak, yönetim sisteminin yeniden düzenlenmesi için öneriler içeren nihai bir sonuç çıkarılır.

    Tabii ki, böyle bir yaklaşım, öncelikle anket yapılan işletmenin yönetiminde bir takım örgütsel önlemler gerektirir. Bunun nedeni, bu tekniğin, yeni metodolojilerin geliştirilmesi ve pratik uygulamasında bazı personele ek sorumluluklar atanması anlamına gelmesidir. Bununla birlikte, sonuçta, bu, karşılığını verir, çünkü bireysel çalışanların birkaç gün boyunca ek bir veya iki saatlik çalışması, üçüncü taraf bir şirkete danışmanlık hizmetleri için ödeme yaparken önemli ölçüde tasarruf sağlayabilir (bu, her durumda, aynı çalışanların çalışmalarını anketler ve sorularla ortadan kaldıracaktır). İşletmenin çalışanlarının kendilerine gelince, şu ya da bu şekilde, onların tarafında herhangi bir açık itirazla karşılaşmadım.

    Tüm bunların sonucu şu şekilde yapılabilir: her zaman standart sorunlara çözüm bulmak hiç gerekli değildir. Birini veya diğerini analiz etme ihtiyacı ile karşı karşıya kaldığınızda fonksiyonel sistem (uzay aracı tasarım sisteminden karmaşık yemek hazırlama sürecine kadar) - yıllar boyunca denenmiş ve test edilmiş yöntemleri kullanın. Bu yöntemlerden biri, basit ve anlaşılabilir araçlarının yardımıyla karmaşık yaşam sorunlarını çözmenizi sağlayan IDEF0'dır.

    Bir resim bin kelimeye bedeldir
    Halk bilgeliği

    Çoğu zaman çalışmamda sadece belirli bir problemi incelemek ve çözmek değil, aynı zamanda şirketin çalışmasının genel modelindeki yerini tanımlamak da gerekir. Belirli bir departmanın düzgün çalışmadığını anlamak yeterli değildir, başkalarıyla nasıl etkileşime girdiğini anlamak önemlidir. Aksi takdirde, mevcut tüm sorunları tanımlamak ve seçmek mümkün değildir. en uygun yöntem Sorunu çözmek. Bu, şirketin çalışmalarını incelemeyi ve işlevsel modelini oluşturmayı gerektirir.

    Tabii ki, teoride, yönetici şirketin çalışmasının işlevsel bir modeline sahip olmalı ve bir depodaki çalışmayı veya bir BT sisteminden kurşuntan uygulamaya düzenleme hakkında konuşmamızın önemi yok. Fakat gerçekte, neredeyse hiç görünmüyor ve bu nedenle, müşterinin ortaya koyduğu soruna bir çözüm bulma ve araştırma sürecinde, şirketin çalışmasının işlevsel bir modelini veya kendi başıma belirli bir süreci (işlevi) oluşturuyorum.

    Grafiklerin yararları hakkında birkaç kelime

    Bildiğiniz gibi, IDEF0 fonksiyonel modelleri her zaman grafik diyagramlardır. Kendi karakteristikleri ve derleme kuralları vardır. Bunun hakkında biraz sonra konuşacağız. Şimdi grafiklerin etkinliğine dair birkaç örnek vermek istiyorum. Neden buna odaklanıyorum? Büyük olasılıkla, şirketin çalışmasının fonksiyonel bir modeline duyulan ihtiyaç hakkındaki iddiamdan sonra, birçok insan tüm bunların gereksiz olduğunu düşündü, bu veya bu işlevin şirkette nasıl çalıştığını kelimelerle açıklamak mümkündür. Bahsetmek istediğim bu.

    Öncelikle, tarihe küçük bir gezi yapalım. Rus-Türk Savaşı sırasında uzak 1877'ye geri dönelim. O zaman poligrafçı Sytin, askeri operasyonları tanımlarken ilk kez grafikleri kullandı. Şimdi bizim için tüm bunlar tanıdık, herhangi bir savaşı tanımlarken, herkesin gözlerinin önünde, savaşın gidişatını açıkça gösteren oklar olan kartlar görünüyor. Ve o günlerde askeri eylemler kelimelerle anlatılıyordu. Her dövüş için pek çok kelime var. Ve sonunda ne olduğunu anlamak çok zordu.

    Bu yüzden Sytin'in fikri gerçekten devrimciydi - askeri birliklerin surlarını ve yerlerini gösteren haritaların litografik kopyalarını yazdırmaya başladı. Bu kartlara “Gazete okurları için. Yarar ". Fikir o kadar alakalı çıktı ki, “Kılavuzlar” ın ilk baskısı anında tükendi. Ve sonra bu tür uygulamalar büyük talep gördü. Nedeni açıktır. Grafikler, sadece kelimelerin yardımıyla neyin imkansız olduğunu anlamaya yardımcı oldu.

    Kendi uygulamamdan sözlü tanımlamaların çaresizliğine benzer bir örnek verebilirim. Müşterilerimden biri, şirketi için bir ERP sisteminin uygulanmasını çok istedi. Teknik bir görevi olup olmadığı sorulduğunda, cevabı aldım: “Evet, var. Ama 400 sayfası var. " Aynı zamanda müşteri, daha önce temasa geçtiği meslektaşlarımın projeyi tamamen reddettiğinden veya açıkça şişirilmiş fiyatlar olarak adlandırdığından çok şikayet etti. Referans koşullarının gerçekten 400 sayfaya sahip olduğunu ve sadece bir metin açıklamasından oluştuğunu gördükten sonra, geliştiricilerin davranışlarının nedenlerini anladım. Böyle bir metni okumak, içine girmek, sadece görevi anlamak ve fiyatı adlandırmak için tüm nüansları sıralamak gerçekten çok zordur.

    Bu müşteriyi teklif ettim alternatif seçenek - grafik olarak gösterebileceğiniz her şeyi açıklayın. Ona modelleme örnekleri gösterdi. Sonuç olarak, şimdi isteklerini ve teknik görevin tasarımını yeniden düşünüyorlar.

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

    İş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ı incelemelisiniz. Ve tam olarak ne yaptığımız önemli değil - genel olarak işin otomasyonunu artırmak için sıfırdan bir CRM sistemi kuruyor veya kuruyoruz, etkili bir ERP sistemi oluşturuyoruz, çeşitli sistemleri entegre ediyoruz. Her durumda, başlangıç \u200b\u200bolarak, mevcut iş düzeni hakkında bir fikir edinmeniz gerekir ve ancak bundan sonra bazı değişiklikler önerebilir ve sorunu çözmek için seçenekleri düşünebilirsiniz.

    Mevcut durumu inceledikten sonra, diğer herhangi bir üçüncü taraf uzmanı gibi, mevcut duruma ilişkin vizyonumu, görevi çözmek için yapılması gereken eylemleri ve tabii ki beklenen sonucu mümkün olduğunca ayrıntılı olarak açıkladığım ticari bir teklif oluşturuyorum.

    Çalışma anketine ilişkin bu tür raporlar hacimlidir, bir yandan birden fazla sayfayı kaplar, bir yandan gerekli ve diğer yandan algıyı zorlaştırır. İlk başta, diğerleri gibi, hacimli raporların iyi olduğunu düşündüm, çünkü bir kişi iş için ödeme yapar ve mümkün olduğunca ayrıntılı bilgi sağlanmalıdır.

    Tipik hatalar

    Fonksiyonel modelleme, modelleme amaçlı olmayanlar da dahil olmak üzere çok çeşitli araçlar kullanılarak gerçekleştirilir. İkinci durumda, hata kontrolü ve standart sınırlamalar yoktur. Görünürlüğü artırma arzusu ve deneyim eksikliği çoğu zaman hatalarla sonuçlanır.

    Farklı renkler kullanma

    Diyagramdaki tüm öğeler eşit derecede önemlidir. Fonksiyonel modellemede az çok önemli unsurlar yoktur. Herhangi birinin ortadan kaybolması işlemin bozulmasına ve üretim hatalarına yol açacaktır.

    Çoğu zaman, kağıt üzerinde veya farklı programlarda modelleme yaparken, kullanıcılar farklı renkler kullanarak görünürlüğü artırmaya çalışırlar. Bu en yaygın hatalardan biridir. Aslında, renkli oklar ve blokların kullanımı sadece karışıklığa katkıda bulunur ve diyagramın algısını bozar.

    Modeliniz, herhangi bir ek renk şeması olmaksızın siyah beyaz olarak okunabilir olmalıdır. Bu yaklaşım aynı anda yanlış anlaşılmaları önlemeye yardımcı olur ve modeli oluşturan kişiyi disipline eder, bu da modelin daha iyi okunabilirliği ve okuryazarlığı ile sonuçlanır.

    Çok fazla blok var

    Bir model çizerken, genellikle şirketin çalışmalarının tüm nüanslarını tek bir sayfada tüm ayrıntılarıyla görüntülemeye çalışırlar. Sonuç, çok sayıda kontrol okuna sahip çok sayıda bloktur. Bu durumda, okunabilirlik kaybolur.

    En iyi seçenek ayrıntıdır, sorunu anlamak için yeterlidir ve daha fazlası değildir. Belirli bir sürecin ayrıntılı bir görünümünü seçerken, her bir departmanın veya hatta çalışanın çalışmalarının ayrıntılı detayları ortaya çıkarılabilir. Ve böyle bir yapı sadece iş veya karar verme için gerçekten gerekliyse yaratılır.

    Ayarlamalar yaparken yapının bozulması

    Gelen, giden ve diğer önemli unsurlar olmadan karışıklık veya süreçler oluşturmamaya dikkat edin. Örneğin, yukarıdaki örnekte, bakış açısını metin yazarına kaydırmak için uygun görürsem, yazarı şemadan kaldıracağım. Ve sonra yayın planının yanı sıra "yazar deneyimi ve üçüncü taraf kaynakları" kontrolleri de gereksiz hale geliyor. Sonuçta, yazar onları kullanıyor. Bir metin yazarı bir ses dosyasıyla çalışır. Ve eğer kalırlarsa genel şema, sonra, detaylandırılırken, anlaşılmaz bir yere götürecek ve karışıklığa neden olacaklardır.

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

    Denetimleri ve blokları adlandırma kuralları

    Basit bir kuralı hatırlamak önemlidir: kontrol oklarına isimler, bloklara fiiller denir. Bu IDEF0 standardıdır ve bu yaklaşım karışıklığı ve hataları önlemeye 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 faydası açık - görünürlük. Şu veya bu sistemin nasıl çalıştığını kendiniz anlamaya başlıyorsunuz ve ayrıca bu sistemdeki “darboğazların” nerede olduğunu ve kararlarınızın bunlardan kurtulmanıza nasıl yardımcı olacağını açık bir şekilde açıklayabilirsiniz.
    • Karşılıklı anlayış ve tutarsızlık eksikliği. Fonksiyonel bir model kullanarak bir şirketin çalışmasını tartışırken, kontrol elemanlarına sahip görsel ve sezgisel görev bloklarınız var. Ek olarak, işlevsel modelleme, gerekirse, sözleşmelerin ve terimlerin açıklandığı bir sözlüğün oluşturulmasını içerir. Sonuç olarak, siz ve müşteri, yönetici ve diğer çalışanlar sorunu tartışırken aynı dili konuşursunuz.
    • Basitlik ve yüksek model oluşturma hızı. Elbette, modellemeyi öğrenmek göründüğü kadar kolay değildir. Sonuçta, bir plan, aslında, anlamak için çok iyi olan, ancak böyle bir sunumun uygulanması için ultra yoğun bir bilgi sunumudur. özel yaklaşım... Analistin beyni bu durumda bir yandan çok güçlü bir basın, diğer yandan bir filtre görevi görür. Ancak deneyim ile bu süreç çok hızlı olur. Sonuç olarak, belirli bir sistemde neler olduğunu anlamanıza yardımcı olacak bir araç elde edersiniz ve kısa sürede oluşturulan görsel bir yardımla, iş arkadaşlarınıza veya müşterilerinize önemli noktaları gösterin.
    • Disiplin ve hata eksikliği. IDEF0 standardı katı çerçeveler ve kurallar varsayar. Bu yaklaşım disiplinlidir ve standart dahilinde hareket etme alışkanlığı dikkatsiz hataları önlemeye yardımcı olur. Standardın herhangi bir ihlali anında görülür.

    IDEF0'ı Kullanmanın Zorluğu Nedir?

    İki iş analistinin şirketin çalışmasını tanımlamak için tam olarak aynı işlevsel modelleri yaratacağını anlamak sadece en basit durumlarda önemlidir. Herhangi bir model, analistin deneyiminin, tanımlamak istediği işi anlama derinliğinin ve bir şekilde bu iş hakkındaki kişisel bakış açısının bir yansımasıdır. Şunlar. bir kişi, bir lider olarak, sanki lidermiş gibi bir iş modeli geliştirir.

    Aynı zamanda, bir iş analistinin bir meslek olmadığına inanıyorum, her iş lideri veya bazı sistemleri geliştiren, işi analiz eden ve en etkili sistemi kurmaya çalışan iş analitiği ile uğraşıyor. Bu insanlar için ve bu amaçlar için IDEF0 aracı amaçlanmıştır.

    Bu nedenle, "olduğu gibi" işlevsel bir iş modeli oluştururken, ayrışma 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ı ve çalışanlarla ek koordinasyon gerekebilir. Sadece işlevsel modeliniz "olduğu gibi" gerçekten gerçek durumu yansıtıyorsa, bazı değişiklikler ve öneriler yapabilirsiniz. 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 konuda daha fazla makale.

    6.2. SADT metodolojisinin (IDEF0) amacı ve bileşimi

    SADT metodolojisi (Yapısal Analiz ve Tasarım Tekniği - yapısal analiz ve tasarım metodolojisi) bir sistemin işlevsel bir modelini oluşturmak için tasarlanmış bir dizi yöntem, kural ve prosedürdür.

    Bu yöntemin geliştirilmesi 60'lı yılların ortalarında Douglas Ross (ABD) tarafından başlatılmıştır. XX yüzyıl. O zamandan beri, SofTech, Inc.'den sistem analistleri. SADT'yi geliştirdi ve çok çeşitli sorunları çözmek için kullandı. Telefon ağı yazılımı, teşhis, uzun vadeli ve stratejik Planlama, bilgisayar destekli üretim ve tasarım, bilgisayar sistemi konfigürasyonu, personel eğitimi, finansal ve malzeme yönetimi alanlardan bazılarıdır etkili uygulama KKHD. Geniş ürün yelpazesi alanlar SADT metodolojisinin çok yönlülüğünü ve gücünü gösterir. ABD Savunma Bakanlığı'nın Bütünleşik Bilgisayar Destekli Üretim (ICAM) programı, SADT'nin faydasını kabul etti. Bu 1981 yılında bir bölümünün yayınlanmasına yol açtı. IDEF0 (Icam DEFinition), federal yazılım geliştirme standardı olarak. Bu isim altında SADT, askeri ve endüstriyel organizasyonlarda binlerce profesyonel tarafından kullanılmıştır. Son revize IDEF0 standardının% 'si Aralık 1993'te piyasaya sürüldü. Ulusal Standartlar ve Teknoloji Enstitüsü (NIST).

    Bu metodoloji, bir bilgi sisteminin fonksiyonel yönünün tanımlanmasında veri akışına yönelik (DFD) yöntemlerle rekabet eder. Bunun aksine, IDEF0 şunları sağlar:

    Sadece bilgi sistemlerini değil, herhangi bir sistemi tanımlayın (DFD yazılımı tanımlamak içindir);

    Sistemin nihai gereksinimlerini tanımlamadan önce sistemin ve dış ortamının bir tanımını oluşturun. Başka bir deyişle, bu metodolojinin yardımıyla, uygulamayı hayal etmek hala zor olsa bile sistemi yavaş yavaş inşa edebilir ve analiz edebilir.

    Bu nedenle, IDEF0, geniş bir sistem yelpazesi oluşturmanın ilk aşamalarında uygulanabilir. Aynı zamanda, fonksiyonları analiz etmek için kullanılabilir mevcut sistemler ve gelişimleri için çözümler geliştirmek.

    IDEF0 metodolojisi, grafiksel bir süreç açıklama diline dayanmaktadır. IDEF0 gösterimindeki bir model, hiyerarşik sıralı ve birbirine bağlı diyagramların bir koleksiyonudur. Her bir diyagram, bir sistem açıklaması birimidir ve ayrı bir sayfada yer alır.

    Model (AS-IS, TO-BE veya SHOULD-BE) içerebilir 4 tür çizelge [ , ]:

    Bağlam diyagramı;

    Ayrıştırma diyagramları;

    Düğüm ağacı diyagramları;

    Sadece gösterim şemaları için (FEO).

    Bağlam diyagramı (üst düzey diyagram), diyagramların ağaç yapısının en üstünde olan sistemin (ana işlev) amacını ve dış çevre ile etkileşimini gösterir. Her model için yalnızca bir bağlam diyagramı olabilir. Ana fonksiyonun tanımlanmasından sonra, fonksiyonel ayrışma gerçekleştirilir, yani ana işlevi oluşturan fonksiyonlar belirlenir.

    Ayrıca, işlevler alt işlevlere bölünür ve bu, çalışılan sistemin gerekli ayrıntı düzeyine ulaşılana kadar devam eder. Sistemin bu tür parçalarını tanımlayan şemalara ayrışma diyagramları ... Her ayrıştırma seansından sonra sınav seansları yapılır - konu alanı uzmanları gerçek süreçlerin oluşturulan diyagramlara uygunluğunu belirtir. Bulunan tutarsızlıklar ortadan kaldırılır, daha sonra süreçleri daha da detaylandırmaya devam ederler.

    Düğüm ağacı diyagramı işlevlerin (çalışmaların) hiyerarşik bağımlılığını gösterir, ancak bunlar arasındaki ilişkiyi göstermez. Birkaç tane olabilir, çünkü ağaç keyfi bir derinliğe ve keyfi bir düğümden inşa edilebilir.

    Pozlama çizelgeleri sistemde meydana gelen süreçler için alternatif bir bakış açısı sergilemek üzere modelin münferit parçalarını göstermek için üretilmiştir (örneğin, kuruluşun yönetimi açısından).

    6.3. IDEF0 grafik gösteriminin öğeleri

    IDEF0 metodolojisi, temel olarak modeli oluşturmak için kullanılan basit grafiksel gösterimden dolayı yaygın bir kabul ve uygulama bulmuştur. Modelin ana bileşenleri diyagramlardır. Sistemin işlevlerini dikdörtgen biçiminde, ayrıca dış çevre arasındaki oklarla oklarla gösterirler. Sadece iki grafik ilkel (dikdörtgen ve ok) kullanmak, bu metodolojiye aşina olmayan kişilere IDEF0 diyagramları oluşturmanın kurallarını ve ilkelerini hızlı bir şekilde açıklamanızı sağlar. Bu avantaj, müşterinin iş süreçlerini resmi ve görsel bir grafik dili kullanarak açıklamadaki aktivitesini bağlamayı ve etkinleştirmeyi mümkün kılar.

    Aşağıdaki şekilde IDEF0 grafik gösteriminin temel öğeleri gösterilmektedir.

    İncir. 6.1. IDEF0 grafik gösteriminin öğeleri

    Dikdörtgen iş (süreç, aktivite, işlev veya görev) sabit bir hedefi olan ve bazı sonuçlara yol açan. Çalışmanın adı, eylemi ifade etmelidir (örneğin, "Bir parça imalatı", "İzin verilen hızların hesaplanması", "3 numaralı merkezi ev listesinin oluşturulması").

    Çalışmaların kendileri ve dış dünya arasındaki etkileşimi oklar şeklinde tanımlanmaktadır. IDEF0 ayırt ediyor 5 ok türü :

    - giriş (İngilizce giriş) - bir sonuç elde etmek için iş tarafından kullanılan ve dönüştürülen malzeme veya bilgiler (çıktı). Giriş, "Ne işlenecek?" Sorusunu yanıtlar. Girdi, bir malzeme nesnesi (hammadde, bir parça, bir sınav bileti) veya net fiziksel konturlara sahip olmayan bir nesne (veri tabanına bir sorgu, bir öğretmenden bir soru) olabilir. Çalışmanın herhangi bir giriş oku bulunmayabileceği varsayılmaktadır. Giriş okları her zaman işin sol tarafına girilir;

    - kontrol (İngilizce kontrol) - çalışmayı yönlendiren kontrol, düzenleyici ve düzenleyici veriler. Departman, "İşler nasıl yapılıyor?" Sorusuna cevap veriyor. Yönetim işi etkiler, ancak onun tarafından dönüştürülmez, yani. bir sınırlama görevi görür. Yönetim olarak kurallar, standartlar, düzenlemeler, fiyatlar, sözlü talimatlar olabilir. İşin üst yüzünün bir parçası olarak kontrol okları çizilir. Bir diyagram oluştururken, yukarıdan veya soldan bir okun nasıl doğru bir şekilde çizileceği sorusu ortaya çıkarsa, onu bir girdi olarak çizmeniz önerilir (soldaki ok);

    - çıktı (İngilizce çıktı) - çalışmanın sonucunu temsil eden materyal veya bilgiler. Çıktı, "Çalışmanın sonucu nedir?" Çıktı ya maddi bir nesne (bir parça, bir araba, ödeme belgeleri, bir ifade) ya da bir maddi olmayan (bir veri tabanından veri örnekleme, bir soruya cevap, sözlü talimat) olabilir. Çıkış okları işin sağ tarafından dışarıya doğru çizilir;

    - mekanizma (eng. mekanizması) - iş yapan kaynaklar. Mekanizma "İşi kim veya hangi yollarla yapıyor?" Mekanizma bir işletmenin personeli, bir öğrenci, bir makine, ekipman, bir program olabilir. Mekanizmanın okları işin alt yüzüne girecek şekilde çizilir;

    - aramak (İngilizce çağrı) - ok, bazı işlerin söz konusu blokun dışında yapıldığını gösterir. Çıkış okları işin alt kenarından çizilir.

    6.4. İşler arasındaki bağlantı türleri

    Fonksiyonların kompozisyonunu ve aralarındaki ilişkileri belirledikten sonra, doğru kompozisyonlarının (alt sistemleri) modüllerle (ilişkilendirilmeleri) ortaya çıktığı sorusu ortaya çıkar. Bu, her ayrı işlevin kesin olarak tanımlanmış bir sorunu çözmesi gerektiği anlamına gelir. Aksi takdirde, işlevlerin daha fazla ayrıştırılması veya ayrılması gerekir.

    Fonksiyonları alt sistemlerde birleştirirken, dahili bağlantının (bir modül içindeki fonksiyonlar arasında) mümkün olduğu kadar güçlü ve harici (farklı modüllerdeki fonksiyonlar arasında) mümkün olduğunca zayıf olması için çaba sarf etmek gerekir. Metodoloji bağlantılarının semantiğine dayanarak, fonksiyonlar (eserler) arasındaki bağlantıların sınıflandırılmasını tanıtacağız. Bu sınıflandırma bir uzantıdır. Tahvil türleri azalan önem sırasına göre sıralanmıştır (bağlayıcı kuvvet). Belirtilen örneklerde, kalınlaştırılmış çizgiler, aralarında dikkate alınan bağlantı türünün bulunduğu işlevleri vurgulamaktadır.

    1. Hiyerarşik ilişki (ilişki "bölüm" - "bütün") işlevi ve içerdiği alt işlevler arasında gerçekleşir.

    İncir. 6.2. Hiyerarşik ilişki

    2. Düzenleyici (kontrol, alt) iletişim bir işin çıktısı diğerini kontrol etmek için gönderildiğinde, bir işlevin diğerine bağımlılığını yansıtır. Denetimden ayrılan işlev, düzenleyici veya denetleyici olarak kabul edilmeli ve içine girdiği - ikincil. Ayırmak doğrudan kontrol bağlantısı kontrol daha yüksek seviyeli bir işten daha düşük seviyeli bir işe aktarıldığında (Şekil 6.3) ve yönetim geri bildirimi kontrol aşağı akıştan yukarı akışa aktarıldığında (Şekil 6.4).

    3. Fonksiyonel (teknolojik) iletişim bir işlevin çıktısı bir sonraki işleve giriş işlevi gördüğünde oluşur. Maddi nesnelerin akışı açısından bu bağlantı bu nesneleri işleme teknolojisini (iş sırasını) gösterir. Ayırmak doğrudan giriş bağlantısı çıktı üst düzey işten alt düzey işe aktarıldığında (Şek.6.5) ve geri bildirim girişi çıktı aşağı akımdan yukarı akışa aktarıldığında (Şekil 6.6).
    İncir. 6.5. Doğrudan giriş iletişimi İncir. 6.6. Girdi Geri Bildirimi

    4. Tüketici iletişimi bir fonksiyonun çıkışı bir sonraki fonksiyonun mekanizması olarak işlev gördüğünde meydana gelir. Böylece, bir işlev diğeri tarafından üretilen kaynakları tüketir.

    İncir. 6.7. Tüketici iletişimi

    5. Mantıksal bağlantı mantıksal olarak homojen fonksiyonlar arasında gözlenir. Bu işlevler, kural olarak, aynı işi, ancak farklı (alternatif) yollarla veya farklı başlangıç \u200b\u200bverileri (materyalleri) kullanarak gerçekleştirir.

    İncir. 6.8. Mantıksal bağlantı

    6. Profesyonel (metodik) iletişim çalışma algoritması aynı kontrol tarafından belirlenen fonksiyonlar arasında gerçekleşir. Bu tür bir iletişimin analogu, talimat ve emir veren (kontrol sinyalleri) şefe bağlı bir bölümün (meslektaşları) çalışanlarının ortak çalışmasıdır. Böyle bir bağlantı, bu işlevlerin çalışması için algoritmalar, bir yönetim görevi gören aynı metodolojik destek (SNIP, GOST, resmi düzenleyici malzemeler, vb.) Tarafından belirlendiğinde de ortaya çıkar.

    İncir. 6.9. Metodik bağlantı

    7. Kaynak bağlantısı işleri için aynı kaynakları kullanan işlevler arasında oluşur. Kaynağa bağlı işlevler genellikle eşzamanlı olarak çalışamaz.

    İncir. 6.10. Kaynak bağlantısı

    8. Bilgi iletişimi girdi ile aynı bilgileri kullanan işlevler arasında gerçekleşir.

    İncir. 6.11. Bilgi iletişimi

    9. Geçici bağlantı başka bir işlevden önce veya sonra eşzamanlı olarak yürütülmesi gereken işlevler arasında oluşur.

    Şekilde gösterilen durumlara ek olarak, bu bağlantı aynı zamanda bir işleve giren diğer kontrol, giriş ve mekanizma kombinasyonları arasında da gerçekleşir.

    İncir. 6.12. Geçici bağlantı

    10. Rastgele bağlantı işlevler arasında çok az veya hiç belirli bir bağlantı olmadığında oluşur.

    İncir. 6.13. Rastgele bağlantı

    Yukarıdaki bağlantı türlerinden en güçlüsü, aslında fonksiyonların modüllere (alt sistemler) kombinasyonunu belirleyen hiyerarşik bağlantıdır. Düzenleyici, işlevsel ve tüketici bağları biraz daha zayıftır. Bu bağlantılara sahip işlevler genellikle tek bir alt sistemde uygulanır. Mantıksal, meslektaş, kaynak ve bilgi bağlantıları en zayıf olanlardır. Bunlara sahip olan işlevler, kural olarak, mantıksal olarak homojen işlevler (mantıksal bağlantıyla bağlanan işlevler) dışında farklı alt sistemlerde uygulanır. Geçici bağlantı, işlevlerin birbirine zayıf bir şekilde bağımlı olduğunu gösterir ve bunların ayrı modüllerde uygulanmasını gerektirir.

    Bu nedenle, fonksiyonları modüllerle birleştirirken, ilk beş bağlantı türü en çok arzu edilen şeydir. Son beş bağlantıyla ilişkili işlevler en iyi şekilde ayrı modüllerde uygulanır.

    IDEF0, [,] modelini okumayı ve incelemeyi kolaylaştırmak için diyagramlar oluşturmak için kurallara (kurallar ve yönergeler) sahiptir. Bu kurallardan bazıları otomatik olarak CASE desteklidir, diğerleri manuel olarak uygulanmalıdır.

    1. Bir model oluşturmadan önce, sistemin hangi model (ler) inin inşa edileceğine karar vermek gerekir. Bu, modelin oluşturulduğu konumu tanımlamanın yanı sıra AS-IS, TO-BE veya SHOULD-BE tipini tanımlamayı gerektirir. Bir kişinin veya nesnenin bir "bakış açısını", sistemi çalışırken görebilmesi için içinde durması gereken bir yer (pozisyon) olarak hayal etmek en iyisidir. Örneğin, bir bakkalın işletilmesi için bir model oluştururken, sistemin bakış açısı dikkate alınan olası başvuru sahipleri arasından bir satıcı, kasiyer, muhasebeci veya yönetmen seçebilirsiniz. Genellikle, sistemin çalışmasının tüm nüanslarını en iyi şekilde kapsayan bir bakış açısı seçilir ve gerekirse, bazı ayrışma diyagramları için alternatif bir bakış açısı gösteren FEO diyagramları oluşturulur.

    2. İçerik diyagramı, sistemin amacını gösteren bir blok görüntüler. Her iki taraftan içeri ve dışarı giden 2-4 ok göstermesi önerilir.

    3. Ayrışma diyagramlarındaki blok sayısı 3-6 aralığında önerilir. Ayrışma diyagramında iki blok varsa, genellikle mantıklı değildir. Huzurunda büyük bir sayı blok şeması aşırı doygun hale gelir ve okunması zordur.

    4. Bozunma diyagramındaki bloklar soldan sağa ve yukarıdan aşağıya doğru düzenlenmelidir. Bu düzenleme, mantığı ve çalışma sırasını daha net bir şekilde yansıtmanıza izin verir. Ayrıca, ok yolları daha az kafa karıştırıcı olacak ve minimum sayıda kavşağa sahip olacaktır.

    5. İşlev için hem kontrol hem de giriş oklarının olmamasına izin verilmez. Bu, bu fonksiyonun başlatılmasının kontrol edilmediği ve herhangi bir keyfi zamanda meydana gelebileceği veya asla gerçekleşmeyeceği anlamına gelir.

    İncir. 6.14. Kontrol ve giriş olmadan fonksiyon

    Sadece kontrolü olan bir blok parametresiz bir fonksiyonun (prosedürün) bir programında çağrı olarak görülebilir. Bloğun bir girişi varsa, programdaki parametrelerle bir işlevi çağırmaya eşdeğerdir. Bu nedenle, kontrol ve giriş içermeyen bir blok, programda asla yürütülmesi çağrılmayan bir işleve eşdeğerdir.

    İncirde. 6.7-6.12, IDEF0 diyagramlarının parçalarını gösteren giriş ve kontrolsüz bloklar vardır. Bu bir hata olarak görülmemelidir, çünkü bu oklardan birinin olması gerekir.

    6. Her bloğun en az bir çıkışı olmalıdır.

    İncir. 6.15. Çıkış fonksiyonu yok

    Sonuçsuz işler anlamsızdır ve modellenmemelidir. İstisnalar AS-IS modelinde gösterilen işlerdir. Onların varlığı, teknolojik süreçlerin verimsizliğini ve kusurunu gösterir. Bu faaliyetler TO-BE modelinde bulunmamalıdır.

    7. Diyagramlar oluştururken, kavşak, döngü ve ok dönüş sayısını en aza indirmelisiniz.

    8. Geri bildirim ve yinelemeler (döngüsel eylemler) geriye dönük yaylar kullanılarak tasvir edilebilir. Giriş hakkındaki geri bildirim "alt" döngü, kontrol hakkında geribildirim - "üst" tarafından çizilir (bkz. Şekil 6.4 ve 6.6).

    9. Şemalardaki her blok ve her okun bir adı olmalıdır. Dallanma (ayrışma) veya birleştirme (kompozisyon) okları kullanmasına izin verilir. Bunun nedeni, bir iş tarafından oluşturulan aynı veri veya nesnelerin aynı anda birkaç başka işte kullanılabilmesidir. Tersine, farklı eserler tarafından üretilen aynı veya homojen veriler ve nesneler tek bir yerde kullanılabilir.

    İncir. 6.16. Dallanma okları

    Bu durumda, dallandıktan sonra (birleştirmeden önce) okun farklı dallarına niteleyici adlar atanmasına izin verilir. Daldan sonraki herhangi bir dal adlandırılmazsa, adın daldan önce kaydedilen ok adına karşılık geldiği kabul edilir.

    Yani, şek. 6.16 "Parçaların üretimi" ve "Ürünün montajı" bloklarına dahil edilen kontroller açıklayıcı anlamlara sahiptir ve daha genel kontrol "Çizimler" in ayrılmaz bir parçasıdır. Tüm çizimler Kalite Kontrol bloğunun çalışması için kullanılır.

    Dallanma öncesi ve sonrası adlandırılmadığında oklar diyagramda çizilemez. İncirde. 6.17 "Tipik listelerin oluşturulması" bloğunda yer alan okun dallanmadan önce ve sonra adı yoktur, bu bir hatadır.

    İncir. 6.17. Yanlış ok isimleri

    10. Daha iyi okunabilirlik için diyagramlar oluştururken, ok tünel açma mekanizması kullanılabilir. Örneğin, üst düzeylerin (ebeveyn) diyagramlarını gereksiz ayrıntılarla karıştırmamak için, ark başlangıcı ayrışma diyagramlarındaki tünele yerleştirilir.

    İncir. 6.18. Tünel açma okları

    Bu örnekte, bir iletken modeli oluştururken yeni yıl partisi "iki eksen" mekanizması, adil bir sorunun ortaya çıkabileceği üst seviyelerin şemalarında görüntülenmeyecektir: "Yeni Yıl partisinde neden iki eksen gerekli?"

    Benzer şekilde, ters hedefle tünel oluşturabilirsiniz - okun diyagramlarda gösterilmesini önleyebilirsiniz düşük seviyeler... Bu durumda, parantezler okun sonuna yerleştirilir. Bağlam diyagramında (bkz. Şekil 6.21), "İzin Verilen Hızların Belirlenmesi" bloğunda bulunan "Yol Servis Mühendisi" mekanizması tünellenmiştir. Bu karar, mühendisin bu bloğun ayrışma diyagramında görüntülenen tüm çalışmaya doğrudan dahil olması nedeniyle verilmiştir (bkz. Şekil 6.22). Bu bağlantıyı göstermekten ve ayrışma diyagramını karıştırmamak için ok tünel açıldı.

    11. Bloğa giren ve çıkan tüm oklar, blok için bir ayrıştırma diyagramı oluştururken, blok üzerinde gösterilmelidir. İstisna tünel oklarıdır. Ayrışma diyagramına sürüklenen okların adları, üst düzey diyagramda gösterilen adlarla eşleşmelidir.

    12. İki ok paralel ilerlerse (bir işin aynı yüzünden başlayıp başka bir işin aynı yüzünde sona ererse), mümkünse birleştirilmeli ve tek bir terim olarak adlandırılmalıdır.

    İncir. 6.19. Bağlantıları birleştirme

    13. Diyagramlardaki her bloğun kendi numarası olmalıdır. Grafik numaraları, hiyerarşideki herhangi bir grafik veya bloğun konumunu belirtmek için kullanılır. Üst düzey diyagramdaki blok 0 ile gösterilir, ikinci seviye diyagramlardaki bloklar - 1'den 9'a kadar rakamlarla (1, 2, ..., 9), üçüncü seviyedeki bloklar - iki sayı ile, birincisi ana diyagramdan ayrıntılı blok sayısını gösterir ve mevcut diyagramda sırayla ikinci blok numarası (11, 12, 25, 63), vb. Bağlam diyagramı "A - 0" olarak adlandırılır, birinci seviye ayrıştırma diyagramı "A0", sonraki seviyelerin ayrıştırma diyagramları harften oluşur " A "ardından ayrıştırılacak bloğun numarası (örneğin," A11 "," A12 "," A25 "," A63 "). Şekilde numaralandırma ile tipik bir diyagram ağacı (düğüm ağacı diyagramı) gösterilmektedir.

    İncir. 6.20. Grafikler hiyerarşisi

    Modern CASE araçlarında iş numaralandırma mekanizmaları otomatik olarak desteklenir. CASE araçları ayrıca, yalnızca hiyerarşik bağlantılar içeren düğüm ağacı diyagramlarının otomatik olarak oluşturulmasını sağlar. Böyle bir diyagramın üstü herhangi bir düğüm (blok) olabilir ve herhangi bir derinliğe çizilebilir.

    6.6. İzin verilen hızları belirlemek için bir sistem için IDEF0 modeli oluşturmaya örnek

    İzin verilen tren hızlarının hesaplanması zahmetli bir mühendislik işidir. Bir tren herhangi bir bölümden geçtiğinde, trenin gerçek hızı izin verilen maksimum hızı aşmamalıdır. İzin verilen maksimum hız, çalışma deneyimine ve hareket dinamikleri ve vagonların pisti üzerindeki etkisi üzerine özel olarak yapılan testlere dayanarak ayarlanır. Bu hızın aşılmaması tren trafiğinin güvenliğini, yolcular için rahat koşulları, vb. Garanti eder. Bunlar demiryolu taşıtının tipine (lokomotif markası ve vagon tipi), üst ray yapısının parametrelerine (raylar, balast, traversler gibi) ve plana (yarıçap) bağlı olarak belirlenir. eğriler, geçiş eğrileri, dış rayın yüksekliği, vb.). Kural olarak, izin verilen hızları belirlemek için, en az iki (düz çizgiler üzerinde) ve beş (eğriler halinde) nihai izin verilen hızın hesaplananların en küçüğü olarak seçilmesi gerekir. Bu hızların hesaplanması, 12 Kasım 2001 tarihli Rusya Demiryolları Bakanlığı'nın Emri ile düzenlenmiştir. "Federal Demiryolu Taşımacılığının 1520 (1524) mm ölçülü demiryolu raylarında izin verilen haddehane hızları için standartlar".

    Belirtildiği gibi, IDEF0 modelinin oluşturulması, tüm sistemi basit bir bileşen (bağlam diyagramı) olarak temsil etmekle başlar. Bu diyagram sistemin amacını (ana işlevi) ve gerekli giriş ve çıkış verilerini, kontrol ve düzenleme bilgilerini ve mekanizmaları gösterir.

    İzin verilen hızları belirleme probleminin bağlam diyagramı Şekil 6.21'de gösterilmektedir. Modeli oluşturmak için Computer Associates'in BPwin 4.0 ürününü kullandık.


    İncir. 6.21. İzin verilen hızları belirlemek için sistemin bağlam şeması (metodoloji IDEF0)

    Gibi arkaplan bilgisi, izin verilen hızların belirlenmesi esas alınarak kullanılır:

    Yeni bir hattın veya bir yeniden inşa projesinin projesinin verileri (projenin uygulanması için gerekli tüm bilgileri, yani kilometre, ayrı noktaların eksenleri, çizgi planı vb.);

    Ayrıntılı boyuna profil (yukarıda tartışılanlara benzer bilgiler içerir);

    Parkur pasaportu (yukarıda tartışılana benzer bilgileri ve parkurun üst yapısı (VSP) hakkında bilgi içerir);

    Pist ölçme aracı tarafından pist planının araştırmasının sonuçları hakkındaki veriler;

    Eğriler halinde dış rayın kotlarının listesi (rayın planı hakkında bilgi içerir).

    Orijinal bilgilerin bir kısmı çeşitli kaynaklardan alınabilir. Özellikle, planla ilgili bilgiler (eğrilerin parametreleri) yeni bir hat projesinden veya bir yeniden inşa projesinden, ayrıntılı bir uzunlamasına profilden, yol mesafesinin pasaportundan vb. Alınabilir.

    Kontrol verileri şunlardır:

    Yolun ray servisi başkanı veya Rusya Demiryolları ray ve yapı bölümünün hesaplanması için talimatlar;

    İzin verilen hızları belirlemek için normatif ve referans bilgileri, prosedürü ve formülleri içeren Sipariş No. 41;

    Mevcut veya planlanan tren trafiği hakkında bilgi (kullanılan lokomotiflerin markaları ve kullanılan araba türleri hakkında veriler);

    Parkurun planlı onarımları, yapıların ve cihazların yeniden inşası ve yeniden inşası hakkında bilgi.

    Sonuç sistemin çalışması şöyle olmalıdır:

    Hesaplanan hızların her türünü içeren ve sınırlamalarının nedenini belirlemenize izin veren izin verilen hız sayfaları;

    Yolda kabul edilen formata göre yolun izin verilen hızlarının ve ayrı noktaların (Sipariş "N") oluşturulmasına ilişkin yol başkanının sırasının bülteni. Onaylı "N" Emri, izin verilen tren hızlarını resmen sabitler;

    Tren tarifesinin geliştirilmesi için planlanan izin verilen hızları içeren 1, 1a ve 2 sayılı Tipik Formlar.

    "H" Sırası ve standart formlarda bulunan hızlar, izin verilen hız sayfalarında hesaplanan ve gösterilenlerden farklı olabilir. Bunun nedeni, hız sınırlarını sadece hadde stoğunun tasarımı, VSP parametreleri ve eğrileriyle değil, aynı zamanda cihazların ve yapıların durumu (yol yatağının deformasyonu, temas ağı desteklerinin eğrilmesi, vb.) İle yansıtmalarıdır. Ek olarak, planlanan ray onarımları, yapıların ve cihazların vb. Yeniden yapılandırılması ve yeniden düzenlenmesi dikkate alınarak ayarlanırlar.

    Oluşturulduktan sonra, bağlam diyagramı, birinci düzey bir ayrışma diyagramı kullanılarak detaylandırılır. Bu diyagram, ana fonksiyon içinde uygulanacak sistemin fonksiyonlarını göstermektedir. Ayrıştırmanın gerçekleştirildiği diyagram, onu ayrıntılandıran diyagramlarla ilişkili olarak adlandırılır. ebeveyn ... Ebeveyne ilişkin ayrıştırma diyagramı denir bağlı .

    Söz konusu problem için birinci seviye ayrışma diyagramı Şekil 6.22'de gösterilmektedir. Kural olarak, bir ayrışma diyagramı oluştururken, orijinal işlev (ayrıştırılacak) 3-8 alt işleve (bloklar) ayrılır. Bu durumda, ayrışma diyagramındaki blokların soldan sağa, yukarıdan aşağıya yerleştirilmesi tavsiye edilir, böylece alt fonksiyonların etkileşimi dizisi ve mantığı daha iyi görülebilir.


    İncir. 6,22. Seviye 1 Ayrışma Şeması (IDEF0 Metodolojisi)

    Söz konusu sorunun çözümü için işlevlerin yerine getirilme sırası aşağıdaki gibidir:

    Yol bölümleri (blok 1 ve 2) ile ilgili referans bilgi ve verilerin girilmesi ve ayarlanması;

    Hesaplama için ödev hazırlama (blok 3). Hangi bölüm ve yolun yanı sıra lokomotifin markası ve vagonların türü için hesaplama yapılması gerektiğini gösterir;

    Sipariş No. 41'de (blok 4) belirtilen prosedüre ve formüllere göre izin verilen hızların hesaplanması. İlk bilgiler, bölümün yolu boyunca veriler (plan, parkurun üst yapısı, vb.) Ve hesaplama için göreve göre seçilen standartlardır;

    İzin verilen hızların listelerinin oluşturulması (blok 5). Hesaplamanın sonuçlarına dayanarak, bir yandan hız sınırlarının nedenini tanımlamaya izin veren, diğer yandan düzenlenmiş belgelerin hazırlanmasına temel oluşturan çeşitli çıktı belgeleri oluşturulur;

    Taslak oluşturulması ve hazırlanması "N" ve standart sayfalar (blok 6 ve 7).

    Birinci seviye ayrıştırma diyagramı oluşturulduktan sonra, üzerinde belirtilen fonksiyonlar için ayrı diyagramlar (ikinci seviye ayrıştırma diyagramları) oluşturulur. Daha sonra, ayrışma süreci (bina şemaları), işlevlerin daha fazla detaylandırılması anlamını kaybedene kadar devam eder. Temel bir işlemi (yani, ayrıştırma diyagramı olmayan bir işlevi) tanımlayan her atomik işlev için, özelliklerini ve uygulama algoritmasını tanımlayan ayrıntılı bir belirtim hazırlanır. Spesifikasyonu desteklemek için algoritmaların akış şemaları kullanılabilir. Böylece, işlevsel modelleme süreci yavaş yavaş bir işlevler hiyerarşisi oluşturmayı içerir.

    6.7. ICOM kodları

    Üst seviye diyagramda bloğa giren ve çıkan oklar, alt seviye diyagrama giren ve çıkan oklarla aynıdır, çünkü blok ve diyagram sistemin aynı bölümünü temsil eder (bkz. ve). Sonuç olarak, üst düzey işlevin sınırları ayrışma diyagramının sınırları ile aynıdır.

    ICOM kodları (Giriş, Kontrol, Çıkış ve Mekanizma kısaltması) sınır oklarını tanımlamak içindir. ICOM kodu, ok türüne (I, C, O veya M) ve bir sıra numarasına karşılık gelen bir önek içerir (şekle bakın).

    Bölümden malzemeler Statinler
    Kalp yetmezliği için klinik kılavuzlar KKY'li hastaların prognozunu etkileyen temel ilaçlar
    Kalp yetmezliği için klinik kılavuzlar KKY'li hastaların prognozunu etkileyen temel ilaçlar
    Levofloksasin: Analoglar, Levofloksasine Benzer Temel İlaçların İncelenmesi
    Levofloksasin: Analoglar, Levofloksasine Benzer Temel İlaçların İncelenmesi