ModelDOC: Entegre ve Katılımcı Elektronik Doküman Yönetim
Sistemi
Osman Abul1, Davut Gökhan Karatepe2, Fadime Şeyda Demetoğlu2 ve Naim Seyrek2 1 TOBB Ekonomi ve Teknoloji Üniversitesi, Ankara
2 ZEG Teknoloji, Bilkent Cyberpark, Ankara
osmanabul@etu.edu.tr
Özet. Klasik bakış açısına göre doküman insan okuyucu için hazırlanmış yapısal bir bilgi bütünüdür. Öte yandan modern teknolojik bakış açısı ile doküman ağdaki farklı kaynaklardan çeşitli tipteki bilgileri ilişkilendiren ve ayrıca birbiri ile de ilişkili bilgi grubu olarak tanımlanabilir. Ayrıca doküman oluşturmak çoğu zaman farklı birim ve uzmanlıktan kullanıcıların katılımı ve işbirliğini gerektirir. Mevcut doküman yönetim sistemleri çoğunlukla klasik bakış açısını takip ederler. Bu çalışmada modern teknolojik bakış açısı ile geliştirmiş olduğumuz ModelDOC adlı Elektronik Doküman/Belge Yönetim Sistemi (EBYS) tanıtılmaktadır. ModelDOC’un ana unsuru (i) farklı bilgi sistemleri arasında entegrasyon ve (ii) kullanıcılar arası katılımcılığı sağlamasıdır. Bir doküman model-view mantığında ilişkili olduğu tüm bilgileri tutmakta fakat bunlardan bazılarını bir şablon üzerinden insan okuyucuya göstermektedir. Bu sayede dokümanda insan okuyucunun görmediği bilgiler üzerinden indeksleme ve sorgulama imkanı sağlanmaktadır. ModelDOC’un öne çıkan diğer bir özelliği ise sadece modelleme (kodlama-derleme gerektirmeden) yaparak çekirdek EBYS’nin farklı kurumlar için çevrimiçi özelleştirilebilmesidir. Böylelikle form ve şablon tasarımları, raporlama, indeksleme, arama ve sorgulama dinamik olarak yapılabilmektedir.
Anahtar kelimeler: Yazılım Mühendisliği, Yazılım Entegrasyonu, Doküman Yönetim Sistemleri.
ModelDOC: An Integrated and Collaborative Electronic Document
Management System
Osman Abul1, Davut Gökhan Karatepe2, Fadime Şeyda Demetoğlu2 and Naim
Seyrek2
1 TOBB Ekonomi ve Teknoloji Üniversitesi, Ankara 2 ZEG Teknoloji, Bilkent Cyberpark, Ankara
osmanabul@etu.edu.tr
Abstract. From the classical point of view, the document is a set of struc-tured information for the human reader. On the other hand, from a mod-ern technological point of view, the document can be defined as a group of information that associates various types of information linked to-gether from different sources in the network. In addition, creating docu-ments often requires the participation and collaboration of users from dif-ferent units and expertise. Existing document management systems often follow the classical perspective. In this study, an Electronic Document Management System (EDMS), which is developed with a modern tech-nological perspective, is introduced. The key elements of ModelDOC are enabling (i) integration between different information systems and (ii) inter-user participation. A document holds all the relevant information in the model-view logic, but shows some of these to the human reader through a template. In this way, indexing and querying is provided on the information that is not seen by the human reader. Another feature of ModelDOC is the ability to customize the core EDMS for different or-ganizations by modeling (without coding-compiling) in an online man-ner. Thus, form and template designs, reporting, indexing, searching and querying can be done dynamically.
Keywords: Software Engineering, Software Integration, Document Manage-ment Systems.
1
Giriş
Klasik bakış açısına göre doküman insan okuyucu için hazırlanmış yapısal bir bilgi bütünü olarak tanımlanabilir [1]. Fakat günümüzde daha çok elektronik dokümanlardan bahsedildiğinden tanım da anlamsal kaymaya uğramaktadır. Öyle ki modern teknolojik bakış açısı ile doküman ağdaki farklı kaynaklardan çeşitli tipteki bilgileri ilişkilendiren ve ayrıca birbiri ile de ilişkili bilgi grubu olarak tanımlanabilir [2].
Doküman Yönetim Sistemi bir kamu kuruluşu için en önemli IT (Information Technology) sistemidir [1]. Şöyle ki, Doküman Yönetim Sistemleri bir kurum içindeki çok sayıda ve çeşitlilikteki dokümanların etkin bir şekilde oluşturulması, saklanması, indekslenmesi, aranması ve kullanıcılar arasında sirkülasyonu işlerini yerine getirir. Yönetilen dokümanlar arasında dilekçeler, dilekçelere yanıtlar, faturalar, kurum içi formlar, yönetmelikler, harici ve kurum içi yazışmalar, görevlendirmeler, teknik dokümanlar, standartlar, toplantı notları, emirler gibi çok çeşitli evraklar vardır.
Ülkemizde kurumların EBYS (Elektronik Belge Yönetim Sistemi) ihtiyaçlarını düzenlemek ve bir standartlaştırma getirmek için “TS 13298-Elektronik Belge Yönetimi standardı” [3] getirilmiştir. Bu standart ağırlıklı olarak doküman/belgenin içeriğinden çok şekilsel olarak (üst/alt bilgi, gizlilik, format, imza vb.) gereksinimlerini belirlemeye yöneliktir ve bir EBYS için olması gereken minimumları ifade eder.
Günümüzde çok sayıda kamu kurumu Elektronik Doküman/Belge Yönetim Sistemine geçmiş bulunmaktadır. Fakat bu sistemler halihazırda basılı belgenin elektronik kopyasının yönetimi boyutunda kalmaktadır. Yine de mevcut durumda bir EBYS kuruluşlara maliyet, zaman tasarrufu, kolay ve hızlı yönetim/arama ve şeffaflık avantajları sunmaktadır. Bilgi sistemleri arasında entegrasyonu vurgulayan modern teknolojik bakış açısı günümüzde daha anlamlı olmasına rağmen mevcut doküman yönetim sistemleri çoğunlukla klasik bakış açısını takip ederler.
Bir EBYS tasarımında modern teknolojik bakış açısı doğru olmasına rağmen eksiktir. Çünkü bir doküman farklı kaynaklardan bilgiler içeren bir bütün olmanın yanında, oluşturulması, düzenlenmesi, onaylanması, saklanması, sorgulanması gibi işlemler nedeniyle çok sayıda kullanıcının üzerinde katılımcı olarak iş birliği (collaboration) yaptığı bir üründür.
Gerek IT varlıklarının çeşitliliği gerekse iş süreçlerinin aynı olmaması gibi nedenlerle kurumların veri/bilgi entegrasyon ve EBYS ihtiyaçları farklılık arzetmektedir. Hatta aynı sektördeki iki kurumun EBYS ihtiyaçları bile birbirinden farklıdır. Daha da ötesi aynı kurumun EBYS ihtiyaçları zaman içinde değişebilmektedir. Bu yüzden, EBYS ürünlerinin kurum bazında kolayca özelleştirilebilmesi çok önemlidir. Çevrimiçi kullanımda yeni sürümün derleme-kodlama yapılmadan sadece veri/süreç modellemesi ile yapılabilmesi bu kolaylığın önemli bir ölçüsüdür. Türkiye’de EBYS kullanıcıları arasında yapılan geniş çaplı bir anket bu ihtiyacı açıkça ortaya koymaktadır [8].
Bu dokümanda ModelDOC adını verdiğimiz kurumsal veri/bilgi entegrasyonu tabanlı katılımcı bir EBYS ürününün tasarımı ve geliştirimi anlatılmaktadır. ModelDOC’un öne çıkan özelikleri ve avantajları aşağıda listelenmiştir.
Kodlama-derleme gerektirmeden sadece veri modellemesi ve şablon tasarımı yapılarak farklı kurumlar için özelleştirilebilme
Kurumun kullandığı kurumsal uygulamalar ile model seviyesinde entegrasyon
Kurumun kullandığı uygulamalarda bulunmayan ama ihtiyaç duyulan bilgileri tamamlayabilmek için dahili şema oluşturma
Model-view ayrımı tasarım yaklaşımı [7] ile doküman modeli ve şablon görünümünün ayrı ayrı modellenebilmesi
CWM (Common Warehouse Metamodel) [4] standardını destekleme
Dağıtık dosya mimarisi ve büyük veri yaklaşımı ile güvenli, güvenilir ve ölçeklenebilir olma
Çevrimiçi kullanımda dinanik veri modelini destekleme
Apache Solr [5] ve Elasticsearch [6] alternatifleri ile şemasız dinamik veri indeksleme ve arama
2
Kurumsal Katılımcı EBYS Entegrasyonu
IT sistemlerinin entegrasyonu temelde uygulama ve servis/veri seviyesinde olmak üzere iki farklı şekilde anlaşılabilmektedir [1]. İlki entegre sistemin ortak bir uygulama da birleştirilmesini ve ikincisi ise, ayrı ayrı bağımsız uygulamaların veri/servis paylaşımını ifade eder.
Herhangi bir büyük ölçekli kurumda EBYS yanında Muhasebe, Stok, İnsan Kaynakları, Finans vb. çok sayıda IT sistemi (kurumsal uygulama) vardır. Bunların geleneksel entegrasyonu Şekil 1’de gösterildiği gibidir. Bu yaklaşımda sistemler tamamen birbirinden bağımsız çalışmakta yalnızca kullanıcılar ve yetkilendirme ortak bir servisten (LDAP) sağlanmaktadır. Bu geleneksel anlamdaki entegrasyon daha çok veri/servis entegrasyonu olmayıp kullanıcı yönetimini (single sign on vb.) kolaylaştırmaya yöneliktir.
Şöyle bir senaryo düşünelim. Hem Stok hem de Muhasebe sisteminden veri kullanan bir evrak/belge hazırlanması gereksin. Bu durumda, evrakı hazırlayan kişi bu iki sisteme bağlanarak oradan okuduğu (eğer yetkisi yoksa telefonla yetkiliden okuttuğu) verileri manuel olarak bu belgeye girecektir. Burada ortaya temelde iki sorun çıkmaktadır: (i) gerçek anlamda birimlerin kullanıcıları arasında doküman üzerinde doğrudan bir iş birliği olmaması, (ii) evrakın gerçekte entegre olmaması. İkinci sorunu biraz daha açacak olursak, evraktaki bir bilgi kaynak uygulamadakinden kopuk olmakta ve o kaynağın herhangi bir özniteliği ile ilişkilendirilmemektedir.
Şekil 1. Geleneksel anlamda kurumsal EBYS entegrasyonu.
Dokümanların hızlı erişim için indekslenip sorgulandıklarını kabul edelim. Geleneksel entegrasyon yaklaşımında doküman içinde olmayan hiçbir alan indekslenemeyeceği için doküman içeriğinde yer almayan bir öznitelik üzerinden sorgulanamaz. Örneğin, belge içinde sadece stok adı ve miktarı yazılı ise bu belgeyi
ilgili stok kaleminin başka bir özniteliği (mesela türü, sorumlusu vb.) üzerinden sorgulayamayız. Oysa şöyle bir sorgu EBYS içinde ihtiyaç duyulabilir: X kullanıcısının sorumlu olduğu stoklarla ilgili yapılan yazışmaları getir. Benzer şekilde başka bir örnek verecek olursak, sadece öğrenci no ve adının yazılı olduğu bir yurt izin belgesinde, Y üniversitesinde okuyan öğrencilerin izin belgeleri sorgulanamaz. Oysa belge üzerinde yazmasa bile bu bilgiler entegrasyon sayesinde belge ile ilişkilendirilip indekslenebilir ve akabinde sorgulanabilir durumdadır.
Şekil 2. Veri/servis seviyesinde kurumsal EBYS entegrasyonu.
3
ModelDOC Tasarımı
ModelDOC, Şekil 2’de verilen entegrasyon mimarisi temel alınarak tasarlanmıştır. Şekil 1 ile karşılaştırıldığında ModelDOC’un diğer uygulamaların en azından belge yönetimi için gerekli veri kaynaklarına erişerek veri düzeyinde bir entegrasyon sağladığı anlaşılacaktır. Şekil 2’de “Entegrasyon” kutusu içinde diğer uygulamaların verisi modellenerek bir meta veri modeli oluşturulmakta ve bu veri EBYS’nin kendi verisiymiş gibi kullanılmaktadır. Dikkat edilmesi gereken nokta ise diğer uygulamaların bu entegrasyondan haberdar olmasına gerek olmamasıdır ve dolayısıyla veri seviyesi entegrasyonu için herhangi bir ilave servis sunmalarına ve kod güncellemelerine gerek yoktur. Yani, veri seviyesi entegrasyonunda haberdarlık tek yönlüdür. Öte yandan bazı kurumsal uygulamaların verileri ancak sunmuş olduğu servisler aracılığı ile erişilebilir olduğu durumlarda uygulamanın servisi bir veri kaynağı olarak ModelDOC açısından veritabanı yönetim sistemi rolündedir. Böylelikle
veri ve/veya servis paylaşımı olan tüm kurumsal uygulamalar ModelDOC açısından meta veri kaynağıdır. Böylelikle, ModelDOC ile diğer uygulamalar arasında kayıt bazında entegrasyon sağlanmakta ve doküman diğer uygulamalardan alınan bilgileri ve özniteliklerini doküman görünümünde olmasa bile meta veri seviyesinde ilişkilendirerek sorgulamaya izin verebilmektedir.
ModelDOC açısından Şekil 2’de dikkat edilmesi gereken bir husus ise; Stok, Muhasebe vb. uygulamaların kullanıcıları da entegrasyon modeli sayesinde doküman üzerinde işbirliği yapabilecek ve kurumsal verimlilik ve bağ artacaktır. Yani EBYS tek bir birimin değil tüm birimlerden kullanıcıların doğrudan katılımı ile daha etkin kullanılmış olacaktır.
Şekil 2’deki mimari yaklaşım bize EBYS’nin henüz tasarım aşamasında bu entegrasyonu yapması gerektiğini gösterir. Yani, Şekil 1’deki yaklaşımla geliştirilmiş bir EBYS Şekil 2’deki çalışma prensibine geçmesi imkansız değilse bile çok zordur. Çünkü en azından EBYS’nin kaynak kodu üzerinde güncellemeler yapılmalı ve kod tekrar derlenmelidir. Oysa tasarım aşamasında bu husus dikkate alındığında uygulama entegrasyonları meta veri modeli ve SQL sorguları ile yapılabilecek ve EBYS kaynak kodunda herhangi bir güncelleme ve dolayısıyla yeni bir derleme gerekmeyecektir.
Herkes tarafından bilindiği üzere hiçbir kurum diğeri ile aynı değildir ve iş süreçleri farklıdır. Bu yüzden veri entegrasyon gereksinimleri değişmektedir. Çünkü her bir kurumun sahip olduğu kurumsal uygulamalar farklıdır. Bu yüzden aynı EBYS’nin farklı kurumların iş süreçlerine ve veri entegrasyonlarına ayrı ayrı uyarlanması ve kullanıma alınması gerekir. ModelDOC yaklaşımında farklı kurumların entegrasyon ihtiyaçları analiz edilecek ve EBYS yazılımı kaynak kodu güncellenmeksizin (tekrar derlenmeksizin) entegrasyon ihtiyaçları modellenmektedir. Her bir domain (sektör) için oluşturulan bu model ModelDOC’a girdi olarak verildiğinde aynı yazılım derleme gerekmeksizin farklı kurumlarda çalışabilecektir. Anlatılan bu özellik Şekil 3’de kavramsal olarak resmedilmiştir.
Şekil 3. Farklı kurumlar/sektörler için ModelDOC’un devreye alınması.
EBYS Core olarak adlandırılan generik kısım farklı domain ihtiyaçları modeli ile ayrı ayrı entegrasyonu yerine getirmektedir. Böylelikle yeni bir kurum EBYS alımı için talep ilettiğinde yapılması gereken tek husus, kurumun diğer uygulamaları ile entegrasyon gereklerini modellemektir. Formülize edecek olursak,
ModelDOC Deployment_KurumX = ModelDOC Core + Model_KurumX İlave olarak her bir kurum ya da sektöre ait olan modeller kurumsal ihtiyaçlar değiştikçe yine kod değişikliği ve derleme gerekmeksizin çevrimiçi olarak güncellenebilmektedir. Bu şekilde bakım, idame ve yeni sürüme geçme gibi yazılım döngüsü aşamaları hızlı ve zahmetsiz bir şekilde yapılabilmektedir.
Tüm bu entegrasyon vurgusunu karşılamak üzere bir doküman ilişkili olduğu tüm kurumsal uygulamalarla arasındaki bağlantıyı bilmelidir. Şekil 4’de ModelDOC Doküman Modeli gösterilmiştir. Buna göre her bir doküman içeriği, içeriğe kaynaklık eden diğer kurumsal uygulamalarla bağı, saklandığı ortam (CMIS standardında), meta verisi, indeks bilgileri, iş akış bilgileri (BPEL standardı), e-imza bilgileri ve versiyon bilgileri ile beraber bir bütündür.
Şekil 4. ModelDOC Döküman Modeli.
ModelDOC’da doküman sınıfları hiyerarşik olarak modellenmekte ve dokümanın içeriği ve sunumu buna göre yapılmaktadır. Böylelikle yeni doküman sınıfı bu hiyerarşiye istenildiği yerden bağlanarak kodlama gereksinimi olmadan sisteme çevrimiçi olarak tanıtılabilmektedir (Şekil 5).
Şekil 5. ModelDOC Doküman Hiyerarşisi.
Gerek formatlı öznitelikler gerekse serbest metin içerik üzerinden dokümanlar indekslenip sorgulanabilmektedir. Özellikle Solr ve Elasticsearch gibi ölçeklenebilir çözümler bu amaç için uygun araçlardır. ModelDOC gerek ölçeklenebilir doküman yönetimi gerekse hızlı indeksleme ve sorgulama hedefleri nedeniyle bulut tabanlı bir web uygulaması olarak tasarlanmıştır. Bulut tabanlı olması nedeniyle bulutun maliyet ve bakım kolaylığı avantajları (7/24 çalışma, yedekleme) da beraberinde gelmektedir. EBYS sistemleri temel kullanım olarak kurumun operasyonel ihtiyaçlarına cevap verirler. Oysa sistemden iş zekası amaçlı faydalanmak da mümkündür. Böylelikle kurumun dönemsel performansı EBYS verileri üzerinden takip edilip karar destek amaçlı kullanılabilecektir. ModelDOC dokümana ilişkin meta-veriler (diğer kurumsal uygulama entegrasyon verileri dahil) bir veri ambarında tutulmakta ve OLAP analizleri yapılabilecek yapıdadır. Şekil 6’da basit bir veri ambarının star şeması kesiti örnek olarak verilmiştir.
Şekil 6. ModelDOC İş zekası şeması.
4
ModelDOC Geliştirimi
Bölüm 3’de tasarım özellikleri verilen ModelDOC EBYS ürünü Scrum metodolojisi ile geliştirilmiştir. Kaynak kod yönetimi, gereksinim yönetimi, proje yönetimi ve sürüm yönetimi için Microsoft Team Foundation Server kullanılmıştır. Yazılım geliştirme araçları/platformları olarak MS.NET, Angular, Ionic, OpenXML, Hadoop, Apache Solr, Elasticsearch ve Hadoop teknolojileri/ürünleri kullanılmıştır.
Şekil 3’de EBYS Core olarak adlandırılan bileşen temel EBYS işlemlerinin yapıldığı kısımdır. Yine Şekil 3’de gösterilen domainler için modelleme ise ModelDOC Modelleme aracı ile yapılmaktadır. ModelDOC Modelleme aracına domain ve yetkili kullanıcıların tanımlanması ile başlanır. Kullanıcılar rollere atanır. Ardından meta veri modeli oluşturulur ve modelleme tamamlandıktan sonra tüm model (bir ağaç yapısı) indekslenir ve veriler aranabilir hale getirilir. Meta veri modeli şeması XML yapısında saklanır. Şekil 7’de ModelDOC Modelleme aracı arayüzü ve Domain tanım ekranı gösterilmiştir.
Şekil 7. ModelDOC Modelleme aracı arayüzü (Domain tanım ekranı). Modelleme için öncelikle yapılması gereken kurumsal uygulama veri kaynaklarının seçilmesidir. Bu noktada çok sayıda Veri Tabanı Yönetim Sistemi’ne ODBC, JDBC ve Native bağlantı desteklenmektedir. Servis tabanlı entegrasyon için ise REST desteklenmektedir. İlave olarak dahili şema yaratılması da desteklenmektedir. Çünkü bazı çok sık ihtiyaç duyulan bilgiler (iller ve ilçeler gibi) hiç bir kurumsal uygulama da olmayabilir. Bu özelliği ile ModelDOC kurumsal veri tamamlama özelliğine de sahiptir. Modelleme kayıt bazında entegrasyon sağlar ve en sonunda ağaç yapısında bir meta veri modeli elde edilir. Bu model ilgili domain için gerekli tüm doküman görünüm, indeksleme, arama ve sorgulama için yeterlidir. Örnek bir meta veri modeli Şekil 8’de verilmiştir. Örnekte evrağın imzacısına (mezuniyeti, doğum tarihi, doğum yeri vb.) ilişkin çok sayıda öznitelik veri modelinde eklenebilir durumdadır.
Şekil 8. ModelDOC entegre meta veri modeli örneği.
Meta veri modelinde dokümanın ilgili olduğu veriler entegre bir şekilde bulunur. Fakat bu bilgilerden hangilerinin doküman görünümünde yer alacağı hangisinin almayacağı, alanlar içinse dokümanın neresinde hangi formatta yer alacağı bilgileri
şablon ve form tasarım aracı ile yapılmaktadır. Şablon ve form tasarım aracı bir Word/Excel Add-in olarak geliştirilmiştir (Şekil 9). Böylelike model-view mantığına göre dokümanın görünümü özelleştirilebilmektedir. Örneğin, imzacının isminde ünvanı yazacak mı yazmayacakmı, sola yanaşık mı sağa yanaşıkmı, yada bunların font büyüklükleri vb. tasarlanmakta ve oluşan görüntü modeli OpenXML olarak saklanmaktadır. Elbette şablon ve form üzerine serbest metin, resim vb. doküman veri modelinde olmayan içerikte eklenebillir. XSLT kullanılarak metin, sayı, tarih, tablo ve liste gibi görünüm ayarları yapılmaktadır.
Şekil 9. ModelDOC Microsoft Excel Şablon Oluşturma Add-in aracı. Gerek doküman veri modelinde gerekse görünüm veri modelinde yer alan tüm öznitelikler ve serbest metin indekslenmektedir. Böylelikle arama ve sorgulama gerek dokümanın görüntüsü (insan okuyucu) gerekse görüntü haricinde kalan öznitelikleri üzerinden yapılabilmektedir. Her bir domain modeli için indeksleme aracı olarak Apache Solr veya Elasticsearch seçilebilmektedir. Şema çevrimiçi değişebileceği için arama-indexleme motorlarının esneyebilen dynamic schema özelliği kullanılmaktadır. Performans, güvenlik ve güvenilirlik açısından Hadoop dağıtık dosya sistemi tercih edilmiştir. Performans testlerinde 6 milyona yakın doküman indekslenmiş ve arama süresi 1 saniyenin altında gerçekleşmiştir.
Meta veri modeli ağaç yapısında olduğundan veri ambarı tasarımında tercih edilen star şema ile örtüşmektedir. Veri modeli CWM meta-veri modeli standardında OpenXML olarak saklandığı için bu formatı destekleyen herhangi bir İş Zekası aracı tarafından analiz edilebilir durumdadır. Mevcut durumda ZEG Teknoloji BI.NET aracı iş zekası amacıyla ModelDOC ile entegre çalışabilmektedir.
5
Sonuç
ModelDOC tasarımdan gerçekleştirime kadar diğer kurumsal uygulamalarla entegre çalışabilecek ve kurum çalışanlarının katılımcı çalışmasına imkan verecek bir EBYS dir. Böylelikle, EBYS kurum için gerçekten de en önemli IT sistemi olacak ve kurum performansının iyileşmesine ve iş zekası özelliği ile de ölçülmesine imkan sağlayacaktır. Hedef kurum için entegrasyon gereklerinin modellemesi ile elde edilecek model sayesinde kodlama ve derleme gereksinimi olmadan hızlı bir şekilde devreye alınabilecektir. Bu özelliği sayesinde değişen kurum ihtiyaçlarına bile model değişikliği ile kolaylıkla adapte olabilmektedir. Model-view ayrımı tasarım yaklaşımı ile doküman şablonunda yer almayan içerikle ilgili öznitelikler de saklandığından zengin indeksleme, arama ve sorgulama imkanı sağlamaktadır.
Teşekkür
ModelDOC projesi TÜBİTAK TEYDEB programı kapsamında desteklenmektedir.
Kaynakça
1. Leikums, T. “A study on electronic document management system integration needs in the public sector”. International Journal of Advances in Engineering & Technology, vol.5, no.1, pp. 194-205, 2012.
2. Haider A. A., Aryati B. and Mahadi B. “Opportunities and Challenges in Implementing Electronic Document Management Systems”. Asian Journal of Applied Sciences, vol.3 issue.1, 2015.
3. TS 13298-Elektronik Belge Yönetimi standardı.
4. Common Warehouse Metamodel, ver 1.1., https://www.omg.org/spec/CWM/About-CWM/, last accessed 2019/06/17.
5. Apache Solr, https://lucene.apache.org/solr/, last accessed 2019/06/17. 6. Elasticsearch, https://www.elastic.co/, last accessed 2019/06/17.
7. Rumbaugh, J., Jacobson, I., Booch, G. “The Unified Modeling Language Reference Manual”. 2nd edn. Addison-Wesley.
8. Sezgin E., Medeni T.D., Bilge M., Önaçan K., Kömürcü R., Dalbay Ö., and Medeni İ.T. “The Perception of Electronic Document Management Systems (EDMS) as a Transforma-tional Information and Communication Technology (ICT) for Public Institutions in Turkey”, In book “Public Administration Reform: Market Demand from Public Organizations”, Edi-tion: 1, Chapter: 17, Publisher: Routledge, Editors: Yogesh K. Dwivedi, Mahmud Shareef, Sanjay K Pandey, Vinod Kumarpp. 279-300, 2013.
