Nothing Special   »   [go: up one dir, main page]
İçeriğe atla

İşlev modeli

Vikipedi, özgür ansiklopedi

Sistem ve yazılım mühendisliğindeki işlev modeli modellenen sistem veya konu alanının işlevlerinin (faaliyetler, eylemler, süreçler, işlemler) yapısal temsilidir.[1]

Yedek parça tamir süreci fonksiyon modelinin IDEF0 gösterimi.

Etkinlik modeli veya süreç modeli ile benzer bir işlev modeli bir işletmenin belirli bir kapsamdaki işlevlerinin grafik gösterimidir. İşlev modelinin amacı, işlevleri ve süreçleri tanımlamak, bilgi ihtiyaçlarının belirlenmesine ve fırsatların tanımlanmasına yardımcı olmak, ürün ve hizmet maliyetlerini belirlemek için bir temel oluşturmaktır.[2]

Tarihçe

[değiştir | kaynağı değiştir]

Sistem mühendisliği ve yazılım mühendisliğindeki işlev modelinin temeli 1950 ve 1960'lara dayanmaktadır. Fakat işlevsel örgütsel faaliyetlerin temeli 19. yüzyıl sonlarına dayanır.

19. yüzyılın sonlarında firma faaliyetleri, eylemleri, süreçleri ya da operasyonlarını resimleyen ilk şemalar görülürken, 20. yüzyılın ilk yarısında iş süreci faaliyetlerini belgeleyen planlama yöntemleri ortaya çıktı. Bu metotlardan biri olan süreç akış tablosu 1921 yılında Frank Gilberth tarafından Amerikan Makine Mühendisleri Topluluğuna (American Society of Mechanical Engineers (ASME)) "Süreç Tablosu, En İyi Yöntemi Bulmanın İlk Adımı"[3] adlı sunumla tanıtılmıştır. Gilbreth'ın araçları endüstri mühendisliği müfredatında hızla yerini aldı.

Sistem mühendisliği alanı 1940'lara Bell Telefon Laboratuvarlarına kadar uzanır.[4] Kompleks mühendislik projelerinde parçaların özelliklerinin toplamından büyük farklılık gösterebilen bir sistemin özelliklerini tanımlama ve değiştirme ihtiyacı, disiplini uygulamak için çeşitli endüstrileri harekete geçirdi.[5] İşlev modelini bu alanda ilk tanımlayanlardan biri olan İngiliz mühendis William Gosling. Mühendislik sistemlerinin tasarımı adlı (1962, s.25) kitabında şunları söyledi:

Nitekim işlevsel bir modelin kullanılabilir olması için iki amaca ulaşması gerekir. İşlev modeli ilk ve son çıktı durumlarının yanında araya girmesi muhtemel bazı durumları da tamamen belirleyen bir üretim mekaniği tanımlamalı, aynı zamanda bu mekaniğin koşulları içinde doğru bir şekilde tanımlanan herhangi bir giriş ile gerçek sistemdekine tam olarak uygun ve söz konusu giriş ile ilgili bir çıktı sağlamalıdır. Her işlev modeli için gerekli olmayan ancak işlev modelinin yapabilmesi gereken iki şey daha belirtilebilir. Bunlar, sistemin girdi ve çıktı haricindeki sistem verilerini tanımlayabilmek ve her bir elemanın veri başına yaptığı işlemin bir açıklamasını yapabilmektir.[6]

İlk tanımlanan işlev modellerinden biri de 1950'lerde savunma ile ilgili oluşturulmuş TRW tarafından geliştirilen İşlevsel Akış Blok Diyagramıdır.[7] 1960'larda NASA uzay sistemlerinde ve uçuş görevlerinde olayların zaman sırasını görselleştirmek için kullandı.[8] Klasik sistem mühendisliği alanında sistem işlevlerinin uygulama sırasının gösteriminde daha yaygın şekilde kullanılır.[9]

İşlevsel modelleme konuları

[değiştir | kaynağı değiştir]

İşlevsel persperktif

[değiştir | kaynağı değiştir]

Sistem ve yazılım mühendisliğinde bir işlev modeli işlevsel modelleme perspektifiyle oluşturulur. İşlevsel perspektif, iş süreci modellenmesindeki perspektiflerden birisi olabildiği gibi, davranışsal, örgütsel veya bilgilendirici perspektifler de olabilir.[10]

İşlevsel modelleme perspektifi dinamik süreci tanımlamaya odaklanır. Bu modelleme perspektifindeki temel fikir işlev, dönüşüm, aktivite, eylem, görev, gibi bir süreç olabilir. Bu perspektifi kullanan modelleme dilinin en iyi bilinen örneği veri akış şemalarıdır.

Bu perspektif, süreci tanımlamak için dört sembol kullanır. Bunlar:

  • Süreç: Girdinin çıktıya dönüşümünü gösterir.
  • Depo: Veri yığını veya bir çeşit malzeme.
  • Akış: Süreçteki verilerin veya malzemelerin hareketi.
  • Dış Etken: Modellenen sistemin dışındadır. Ancak onunla etkileşim içindedir.

Şimdi bir süreç sembollerden oluşan bir ağ şeklinde gösterilebilir. İşte bu ayrıştırılmış süreç veri akış şemasıdır. (Data Flow Diagram(DFD))

Dinamik Kurumsal Modelleme, Kontrol Modeli, İşlev Modeli, Süreç Modeli ve Organizasyon modeli bölümlerinden meydana gelir.

İşlevsel ayrıştırma

[değiştir | kaynağı değiştir]
Sistem Analizinde İşlevsel Ayrıştırma Örneği

İşlevsel ayrıştırma, orijinal işlevin bu işlev bileşenleri kullanılarak yeniden oluşturulması yoluyla, işlevsel bir ilişkiyi oluşturan kapsamlı parçalara ayırma sürecini ifade eder. Genel olarak bu ayrıştırma süreci, ya küresel işlevin sıkıştırılmış bir temsilini elde etmek ya da işlevi oluşturan unsurların niteliğini anlamak amacıyla yapılır. Bu göre sadece işlevi meydana getiren süreçler belirli bir modülariteye sahipse yapılabilir.

İşlevsel ayrıştırmanın, ana hedefin süreci mümkün olduğunca modüler hale getirmek olduğu bilgisayar programlamada önemli bir yeri vardır. Örneğin bir kütüphane yönetim sistemi bir envanter modülüne, müşteri bilgi modülüne ve ücret değerlendirme modülüne ayrılabilir. Bilgisayar programcılığının ilk on yılında bazı önde gelen uygulayıcılar tarafından "alt program sanatı" olarak adlandırılmıştır.

Mühendislik sistemlerinin işlevsel ayrışımı, mühendislik sistemlerini analiz eden bir yöntemdir. Temel fikir blok şemasındaki her bloğun tanımında "ve" veya "veya" olmadan tanımlanması şeklinde sistemi bölümlendirmektir.

Bu uygulama, sistemin her bir bölümünü saf bir işleve sahip olmaya zorlar. Sistem saf işlevlerden oluştuğunda, bunlar yeniden kullanılabilir veya değiştirilebilir. Bloklar arasındaki arayüzlerin basit ve kendine özgü olması olağan bir yan etkidir. Arabirimler genellikle basitleştiğinden, saf bir işlevin ilgili, benzer bir işlevle değiştirilmesi daha kolaydır.

İşlevsel modelleme yöntemleri

[değiştir | kaynağı değiştir]

İşlevsel yaklaşım çoklu şematik teknikler ve modelleme gösterimlerinde genişletilir. Bu bölüm, önemli teknikler hakkında kronolojik sırayla genel bir bakış sunar.

Gemini uzay mekiğinin durum kontrol ve manevra elektronik sisteminin işlevsel blok şeması. Haziran 1962

İşlev Blok Şeması

[değiştir | kaynağı değiştir]

İşlevsel blok şema sistemin işlevlerini ve dahili ilişkilerini tanımlar. İşlevsel blok şema şunları gösterebilir:[11]

  • Bloklar ile sistemin işlevlerini
  • Çizgiler ile giriş ve çıkış öğelerini
  • İşlevler arasındaki ilişkileri
  • Madde ve / veya sinyaller için fonksiyonel sıralar ve yollar.[12]

Blok diyagramı, belirli özellikleri göstermek için ek şematik simgeler kullanabilir.

Özel bir işlev blok şeması olan klasik İşlevsel Akış Blok Şeması ve İşlev Blok Şeması, programlanabilir mantık kontrollerinin tasarımında kullanılır.

İşlevsel akış blok şeması[13]

[değiştir | kaynağı değiştir]
İşlevsel Akış Blok Şeması

İşlevsel akış blok şeması, sistemin işlevsel akışının çok katmanlı, zaman aralıklı, adım adım gösterimidir.[14] Bu şema 1950’lerde geliştirilmiş ve klasik sistem mühendisliğinde geniş bir alanda kullanılmıştır. İşlevsel Akış Blok Şeması aynı zamanda İşlevsel Akış Şeması, İşlevsel Blok Şeması ve İşlevsel akış olarak da adlandırılır.[15]

İşlevsel akış blok şemaları genellikle sistemler için ayrıntılı, adım adım operasyonel ve destek dizilerini tanımlar, ancak aynı zamanda sistemleri geliştiren ve üreten süreçleri tanımlamak için de etkili bir şekilde kullanılırlar. Yazılım geliştirme süreçleri işlevsel akış blok şemalarını yoğun şekilde kullanmaktadır. Sistem bağlamında, işlevsel akış adımları, donanım, yazılım, personel, tesisler ve / veya prosedürlerin kombinasyonlarını içerebilir.

İşlevsel akış blok şeması yönteminde, işlevler mantıksal yürütme düzeni ile düzenlenir ve gösterilir. Her işlev, diğer işlevlerin yürütülmesi ve tamamlanması ile olan mantıksal ilişkisine göre gösterilir. İşlev adı ile etiketlenmiş bir düğüm, bir işlevi tasvir eder. Soldan sağa doğru oklar işlevlerin yürütme sırasını gösterir. Mantıksal semboller fonksiyonların sıralı veya paralel yürütülmesini temsil eder.[16]

Hiyerarşik Girdi İşlem Çıktısı(HIPO) ve Girdi İşlem Çıktısı(IPO)

Genişletilmiş bir IPO Modeli

Hiyerarşik girdi işlemi çıktısı(HIPO), bir sistemi hiyerarşik olarak temsil etmek[17] ve her modülü belgelmek için kullanılan ve 1970'lerde popüler olan sistem analizi tasarım yardımı ve dokümantasyon tekniğidir.[18]

İhtiyaçların geliştirilmesi, tasarım yapmak ve otomatik buluşmayı göstermek için uzman bir sistem uygulamasını desteklemek için kullanıldı. Tasarım ve uygulama yöntemi nedeniyle ayrıca sistematik doğrulama eklendi.[19]

Sistemin genel tasarımı HIPO çizelgeleri veya yapı çizelgeleri kullanılarak belgelenir.  Yapı grafiği, görünüşte bir organizasyon şemasına benzemektedir. Fakat ek ayrıntı göstermek için değiştirilmiştir. Yapı çizelgeleri, çeşitli bilgi türlerini görüntülemek için kullanılabilir, ancak en çok veri yapıları veya kod yapılarını grafik olarak göstermek için kullanılır.[17]

N2 Çizelgesi

[değiştir | kaynağı değiştir]
N2 grafiği tanımı

N2 Grafiği, sistem öğeleri arasındaki işlevsel veya fiziksel arabirimleri temsil eden bir matris şeklinde bir şemadır. İşlevsel ve fiziksel arayüzleri sistematik olarak belirlemek, tanımlamak, tablo oluşturmak, tasarlamak ve analiz etmek için kullanılır. Sistem arayüzleri, donanım ve / veya yazılım arayüzlerine uygulanır.[14]

N2 şeması öncelikle yazılım alanlarında, veri arayüzleri geliştirmek için yaygın bir şekilde kullanılmaktadır. Bununla birlikte, donanım arayüzleri geliştirmek için de kullanılabilir. Temel N2 şeması Şekil 2’de gösterilmiştir. Sistem fonksiyonları diyagonal üzerine yerleştirilir, N x N matristeki karelerin geri kalan kısmı arayüz giriş ve çıkışlarını temsil eder.[20]

Yapısal Analiz ve Tasarım Tekniği

SADT temel unsuru

Yapısal Analiz ve Tasarım Tekniği, sistemleri hiyerarşik işlevler şeklinde tanımlayan bir yazılım uygulaması taslağı oluşturmak için şematik olarak gösteren bir yazılım tekniğidir. Faaliyetleri ve varlıkları temsil etmek için yapı bloklarını ve kutuları ilişkilendirmek için çeşitli okları içerir. Bu kutu ve oklar anlamsal gayri resmi ilişkileri içerir.[21] Yapısal Analiz ve Tasarım Tekniği, belirli bir sürecin ardışık seviyelerini kullanarak işlevsel bir analiz aracı olarak kullanılabilir. Yapısal Analiz ve Tasarım Tekniği yöntemi, endüstriyel bilgi sistemlerinde kullanılan IT gelişmelerine yönelik kullanıcı ihtiyaçlarını tanımlamaya olanak tanır. Aynı zamanda bir faaliyetin üretim süreçlerini ve, prosedürlerini temsil ederek açıklar.[22]

Yapısal Analiz ve Tasarım Tekniği, bir şirketteki işlevleri ve ilişkilerini açıklayarak herhangi bir işletmenin belirli bir fonksiyonel görünümünü içerir. Bu işlevler, satış, sipariş planlama, ürün tasarımı, parça imalatı ve insan kaynakları yönetimi gibi bir şirketin hedeflerini yerine getirir. Yapısal Analiz ve Tasarım Tekniği, basit işlevsel ilişkileri gösterebilir ve farklı işlevler arasındaki veri ve kontrol akış ilişkilerini yansıtabilir. IDEF0 biçimciliği 1985'te Douglas T. Ross tarafından geliştirilen Yapısal Analiz ve Tasarım Tekniğine dayanır.[23]

IDEF0

IDEF0 şema örneği

IDEF0, analiz, geliştirme, yeniden yapılandırma ve bilgi sistemlerinin entegrasyonu, iş süreçleri veya yazılım mühendisliği analizi için fonksiyonel bir modelleme dili sunan, imalat işlevlerini tanımlamak için kullanılan bir işlev modelleme yöntem bilimidir.[24] Yazılım mühendisliği alanında modelleme dillerinin oluşturduğu IDEF ailesinin bir parçasıdır ve Yapısal Analiz ve Tasarım Tekniği fonksiyonel modelleme dili yapısında yer almaktadır.

IDEF0 İşlevsel Modelleme yöntemi, bir organizasyonun veya sistemin kararlarını, eylemlerini ve faaliyetlerini modellemek üzere tasarlanmıştır.[25] Douglas T. Ross ve SofTech, Inc. tarafından geliştirilen ve kurulu grafik modelleme dillerinden Yapısal Analiz ve Tasarım Tekniğinden türetilmiştir. Orijinal formunda, IDEF0 grafiksel bir modelleme dili (sözdizimi ve anlambilim) hem tanımını hem de Model geliştirme için kapsamlı bir yöntem biliminin tanımını içerir.[1] ABD Hava Kuvvetleri, Yapısal Analiz ve Tasarım Tekniği geliştiricilerine, bir sistemin işlevsel perspektifini analiz etmek ve iletmek için bir işlev modeli yöntemi geliştirmeleri için yetkilendirdi. IDEF0, sistem analizinin organizasyonunda yardımcı olmalı ve basitleştirilmiş grafik yöntemler vasıtasıyla analist ve müşteri arasında etkin iletişim sağlamalıdır.[25]

Aksiyomatik tasarım

[değiştir | kaynağı değiştir]

Aksiyomatik tasarım, ürünlerin, bilgi sistemlerinin, iş süreçlerinin veya yazılım mühendisliği çözümlerinin analizi, geliştirilmesi, yeniden yapılandırılması ve entegrasyonu için bir çözüm sentez yapısı olarak kullanılan en üst düzeydeki hiyerarşik fonksiyon ayrıştırma sürecidir.[26] Yapısı, olası fonksiyonel çözüm modellerinin mimari sağlamlığını optimize etmek ve işlevler arasındaki bağlanmayı analiz etmek için matematiksel olarak uygundur.

İlgili model türleri

[değiştir | kaynağı değiştir]

Sistemler ve yazılım mühendisliği alanında sayısız spesifik fonksiyon ve fonksiyonel modeller ve yakın ilişkili modeller tanımlanmıştır. Burada sadece birkaç genel tip açıklanacaktır.

İşletme işlev modeli İşletme İşlev Modeli, bir organizasyonun misyonunu yerine getirmek için düzenli olarak uygulanan işlemlerin genel bir tanım veya kategorisidir. Genel işletme fonksiyonlarının tanımlanması için kavramsal bir yapı sağlar.[27] İş alanı işlevleri bağlamında kritik iş süreçlerini gösterebilir. İşletme işlev modelindeki süreçler, değer zinciri modellerindeki süreçlerle tutarlı olmalıdır. Süreçler, bir nihai ürün üretmek veya bir hizmet sunmak için gerçekleştirilen bir dizi ilgili işletme faaliyetidir. Sürekli olarak gerçekleştirilen iş işlevlerinin aksine, işlemler, belirli bir başlangıç ve bitiş noktasına sahip oldukları ve istenen çıktıların teslim edilmesi ile karakterize oldukları gerçeğiyle karakterize edilir. Sağdaki şekil iş süreçleri, işletme fonksiyonları ve işletme alanının işletme referans modeli arasındaki ilişkiyi göstermektedir.[28]

İş Süreci Modeli ve Şeması

İş Süreci Modeli ve Şema Örneği

İş Süreci Modeli ve Şeması, bir iş akışında iş süreçlerini belirten grafiksel bir sunumdur. İş Süreci Modeli ve Şeması, İş Süreçleri Yönetimi Girişimi tarafından geliştirildi ve şu anda iki organizasyonun 2005 yılında birleşmesinden dolayı Nesne Yönetim Grubu tarafından sürdürülüyor. İş Süreci Modeli ve Şeması'nın güncel sürümü 2.0'dır.[29]

İş Süreci Modeli ve Şemasının özellikleri İş süreç Şemasındaki iş süreçlerini tanımlamak için grafiksel bir gösterim sağlar.[30] İş Süreci Modeli ve Şemasının amacı, hem teknik kullanıcılar hem de ticari kullanıcılar için iş süreci yönetimini, işletme kullanıcılarına sezgisel olan, ancak karmaşık süreç semantiklerini temsil edebilen bir gösterim sağlayarak desteklemektir. İş Süreci Modeli ve Şemasının özellikleri ayrıca, gösterim grafikleri ile temel yürütme dillerinin yapıları olan BPEL4WS arasında bir eşleme sağlar.[31]

İş referans modeli

[değiştir | kaynağı değiştir]
Bu FEA İş referans modeli, iş süreçleri, işletme fonksiyonları ve işletme alanının işletme referans modeli arasındaki ilişkiyi tasvir etmektedir.

İş referans modeli, bir kuruluşun, hizmet kuruluşunun veya devlet kurumunun temel işinin işlevsel ve örgütsel yönlerine odaklanan bir referans modelidir. Kurumsal mühendislikte bir iş referans modeli, bir kuruluş mimarisi çerçevesi veya mimarlık çerçevesinin bir parçasıdır ve kuruluş mimarisi ile ilişkili yapıların ve görünümlerin nasıl düzenleneceğini tanımlar.

Genel olarak referans modeli, bir şeyin temel hedefi veya fikrini somutlaştıran ve sonra çeşitli amaçlar için bir referans olarak görülebilecek bir modelidir. Bir işletme referans modeli, onları gerçekleştiren organizasyon yapısından bağımsız olarak bir kuruluşun işletme faaliyetlerini tanımlamak için bir araçtır. Diğer tip işletme referans modeli türleri, iş süreçleri, işletme fonksiyonları ve işletme alanının işletme referans modeli arasındaki ilişkiyi de tasvir edebilir. Bu referans modeli katmanlar halinde oluşturulabilir ve servis bileşenleri, teknoloji, veri ve performans analizleri için bir temel oluşturabilir.

Kullanıcı İşlev Modeli

[değiştir | kaynağı değiştir]

Kullanıcı İşlev Modeli, insan faktörleri mühendisleri tarafından kullanılan geleneksel görev analiz tekniklerine bir alternatif olarak önerilmiştir. Bir operatör işlevi modeli, bir operatörün karmaşık bir sistemi daha basit parçalara ayırıp, kontrol eylemlerini ve sistem konfigürasyonlarını koordine ederek kabul edilebilir toplam sistem performansına ulaşmasını matematiksel biçimde göstermeye çalışır. Model, karmaşık sistemlerde bilgi temsili, bilgi akışı ve karar verme ile ilgili temel meseleleri temsil eder. Miller (1985), şebeke yapısının, bir operatörün sistemin iç modelinin olası bir temsilinin yanı sıra, operatör kontrol fonksiyonlarını içeren karar problemlerini çözmek için modelin nasıl kullanıldığını belirten bir kontrol yapısı olarak düşünülebileceğini önermektedir.[32]

Kaynakça

[değiştir | kaynağı değiştir]
  1. ^ a b FIPS Publication 183 27 Şubat 2009 tarihinde Wayback Machine sitesinde arşivlendi. released of IDEFØ December 1993 by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST).
  2. ^ Reader's Guide to IDEF0 Function Models 4 Mart 2016 tarihinde Wayback Machine sitesinde arşivlendi..
  3. ^ Ben B. Graham (2002). Detail Process Charting. p.2.
  4. ^ Schlager, J. (July 1956). "Systems engineering: key to modern development". IRE Transactions. EM–3 (3): 64–66. doi:10.1109/IRET-EM.1956.5007383.
  5. ^ Arthur D. Hall (1962). A Methodology for Systems Engineering. Van Nostrand Reinhold. ISBN 0-442-03046-0.
  6. ^ William Gosling (1962) The design of engineering systems. p. 23
  7. ^ Tim Weilkiens (2008). Systems Engineering with SysML/UML: Modeling, Analysis, Design. Page 287.
  8. ^ Harold Chestnut (1967). Systems Engineering Methods. Page 254.
  9. ^ Thomas Dufresne & James Martin (2003). "Process Modeling for E-Business". INFS 770 Methods for Information Systems Engineering: Knowledge Management and E-Business. Spring 2003
  10. ^ Process perspectives. In: Metamodeling and method engineering, Minna Koskinen, 2000.
  11. ^ James Perozzo (1994) The complete guide to electronics troubleshooting. p. 72
  12. ^ William H. Von Alven (1964) Reliability engineering explains: "Functional block diagrams show functional sequences and signal paths, and items which are wired in parallel are drawn in parallel" (p. 286)
  13. ^ Systems Engineering Fundamentals. Defense Acquisition University Press, 2001
  14. ^ a b The first version of this article is completely based on the NAS SYSTEM ENGINEERING MANUAL SECTION 4.4 VERSION 3.1 06/06/06.
  15. ^ Task Analysis Tools Used Throughout Development. FAA 2008. Retrieved 25 Sept 2008.
  16. ^ FAA (2006). NAS SYSTEM ENGINEERING MANUAL SECTION 4.4 VERSION 3.1 06/06/06.
  17. ^ a b Sandia National Laboratories (1992). Sandia Software Guidelines Volume 5 Tools, Techniques,and Methodologies SANDIA REPORTS 85–2348qUC–32
  18. ^ IBM Corporation (1974).HIPO—A Design Aid and Documentation Technique, Publication Number GC20-1851, IBM Corporation, White Plains, NY, 1974.
  19. ^ Mary Ann Goodwin and Charles C. Robertson (1986). EXPERT SYSTEM VERIFICATION CONCERNS IN AN OPERATIONS ENVIRONMENT. NASA paper N88-17234.
  20. ^ NASA (1995). "Techniques of Functional Analysis". In: NASA Systems Engineering Handbook June 1995. p.142.
  21. ^ John Mylopoulos (2004). Conceptual Modelling III. Structured Analysis and Design Technique (SADT). Retrieved 21 Sep 2008.
  22. ^ SADT at Free-logistics.com. Retrieved 21 Sep 2008.
  23. ^ Gavriel Salvendy (2001). Handbook of Industrial Engineering: Technology and Operations Management.. p.508.
  24. ^ Systems Engineering Fundamentals. Defense Acquisition University Press, 2001.
  25. ^ a b Varun Grover, William J. Kettinger (2000). Process Think: Winning Perspectives for Business Change in the Information Age. p.168.
  26. ^ Suh (2001). Axiomatic Design: Advances and Applications, Oxford University Press, 2001, ISBN 0-19-513466-4
  27. ^ Paul Grefen (2010) Mastering e-Business. p. 5-10
  28. ^ US Department of Interior (2000-08) Analyze the Business and Define the Target Business Environment. Accessed 27 Nov 2008.
  29. ^ "BPMN Information". Retrieved 2008-11-02.
  30. ^ Richard C. Simpson (2004). An XML Representation for Crew Procedures. Final Report NASA Faculty Fellowship Program - 2004. Johnson Space Center.
  31. ^ S.A. White, "Business Process Modeling Notation (BPMN)," In: Business Process Management Initiative (BPMI) 3 May 2004.
  32. ^ Operator Function Model (OFM). Accessed 27 Nov 2008.
"https://tr.wikipedia.org/w/index.php?title=İşlev_modeli&oldid=33320127" sayfasından alınmıştır