zamanl Süreci Modelleme ve Gereksinim Analizi için bir

zamanl Süreci Modelleme ve Gereksinim Analizi için bir Yakla m An Approach for Concurrent Business Process Modeling and Requirements Analysis Ahmet Co kunçay Bili im Sistemleri Bölümü ODTÜ, Ankara ahmet@ii.metu.edu.tr Banu Aysolmaz Bili im Sistemleri Bölümü ODTÜ, Ankara banu@ii.metu.edu.tr Onur Demirörs Bili im Sistemleri Bölümü ODTÜ, Ankara demirors@metu.edu.tr Ömer Bilen T.C. Ba bakanl k Devlet Planlama Te kilat Müste arl, Ankara obilen@dpt.gov.tr dris Do an T.C. Ba bakanl k Devlet Planlama Te kilat Müste arl, Ankara dogani@dpt.gov.tr Özet süreci modelleme ve gereksinim analizi aktiviteleri farkl disiplinler içinde yer al rlar. Süreçlerini tan mlama ve onlar bilgi sistemleri ile destekleme ihtiyac nda olan bir organizasyon, bu iki aktiviteyi birlikte gerçekle tirmekten faydalanabilir. Bu makalede sunulan vaka çal mas, i süreci modelleme ve gereksinim analizinin ayn zamanda gerçekle tirilmesini mümkün k lan bütünle ik bir yakla n geli tirilmesi ve uygulanmas na odaklanmaktad r. Vaka çal mas nda, Türkiye deki Kalk nma Ajanslar n n süreçleri tan mlanm ve bu süreçler için yaz m gereksinimleri üretilmi tir. Yaz m gereksinimlerinin üretilmesi araç deste iyle otomatikle tirilmi tir. Vaka çal mas n sonuçlar, i süreci modellerinin yaz m gereksinim analizinde kullan labilece ini ve sunulan yakla n kullan lmas yla bu iki aktivitenin toplam eforunun dü ürüldü ünü göstermektedir. Abstract Business process modeling and requirements analysis activities are considered as being in different disciplines. An organization in need of defining its processes and supporting them with information systems would benefit from performing these two activities. The case study presented in this paper focuses on developing and implementing a unified approach for enabling business process modeling and requirements analysis to be performed concurrently. In the case study business processes of Development Agencies in Turkey were defined and software requirements for these processes were generated. Generation of the software requirements were automated by tool support. Results of the case study show that business process models can be utilized in software requirements analysis and the total effort of these two activities were decreased by using the presented approach. 1. Giri süreçlerini modelleme aktiviteleri organizasyonlar n süreçlerini analiz etmek, tan mlamak ve iyile tirmek için kullan r. Son y llarda i süreçlerinin yeniden yap land lmas nda yayg n kullan lan bir araç haline gelmi tir. süreçleri modelleme süreçlerin karma k ve çok yönlü oldu u ve çok fazla kullan n sistemleri kulland durumlarda çok kritiktir [1], [2]. Bu durum kurulu lar n i süreçlerini bilgi sistemleri ile desteklemeye ihtiyaç duydu u durumlarda da geçerlidir. Organizasyonlar gereklerine uygun yaz m sistemleri geli tirmek istediklerinde gereksinim analizine ihtiyaç duyarlar. Gereksinim analizi, gereksinim mühendisli i içinde yaz n s rlar ve çevresiyle etkile imlerini belirlemeye, sistem gereksinimlerini kullanarak yaz m gereksinimlerini belirtmeye ve gereksinimler aras ndaki ihtilaflar bulmaya ve çözmeye odaklanan bir basamak olarak tan mlan r [3].

Hem i süreçleri modelleme, hem de gereksinim analizi ba ar organizasyonlar için önemli aktivitelerdir. Zay f yaz m gereksinim belirtimlerinin önlenmesi kalite maliyetlerinin dü ürülmesi için önemli bir motivasyondur, çünkü kalite maliyetleri hatalar n yaz m geli tirme ya am döngüsü içinde geç safhalarda tespit edilmesiyle birlikte katlanarak artar [4]. süreçleri modelleme ise özellikle karma k yap organizasyonlar n mevcut süreçlerindeki kusurlar n belirlenmesinde etkinli i artt r [5]. Birçok vakada, i süreçlerinin modellenmesi ve gereksinim analizine duyulan ihtiyaç e zamanl ya da ard k olarak do ar. Örnek olarak, i süreçlerini modellemeyi süreçlerini tan mlamak için gerçekle tiren yeni kurulan organizasyonlar ve mevcut süreçlerini iyile tirmek isteyen organizasyonlar süreç etkinliklerini artt rmak için yaz m geli tirmeyi planlarlar. Bu da bu sistemler için gereksinim analizini bir gerek olarak ortaya kar r. Mevcut süreç modelleme dilleri ve araçlar yaz m gereksinimi aktiviteleri için bütünle ik bir yakla desteklememektedir [6], [7], pek az gereksinim mühendisli i yakla ise kendini süreç modelleme ile ili kilendirmektedir [8]. Savunma sektöründeki tecrübelerimiz yaz m gereknimlerinin do rudan süreç modellerinden üretilmesi konusunda pozitif sonuçlar göstermektedir [9]. elale yaz m geli tirme modelinde, gereksinim analizi toplam yaz m geli tirme i gücünün yüzde 16 s almaktad r [10]. süreçlerinin modellenmesi de büyük zaman ve i gücü al r. süreçleini destekleyen yaz mlar n al planlanan bir çal mada, i süreçlerinin modellenmesine 10,000 MK2 fonksiyon noktal k bir sistem için 13 ve 25,000 MK2 fonksiyon noktal k bir sistem için de 20 adamay l k i gücü harcand rapor edilmi tir [5]. Yaz m geli tirme projelerinde, süreç modelleme için harcanan gücü, gereksinim analizi için tekrarlanmakta ve süreç modelleri ile gereksinimleri senkronize etmek için de fazladan i gücü harcanmaktad r. Bu çal mada, i süreci modelleme ve gereksinim analizi aktivitelerini bütünle tirme ve gereksinim belirtimlerini süreç modellerinden otomatik olarak üretmenin bu iki aktivite için harcanan toplam gücünü dü ürece ini ve süreç modelleri ile gereksinimleri ve bu iki ürün için gerçekle tirilen akiviteleri senkronize edece ini öneriyoruz. Bu türden bütünle ik bir yakla m, mü teri ile yüklenici aras nda daha iyi bir ileti im ortam sa lama, süreç sahipleri ile yaz m mühendislerini ortak paydada bulu turma, süreç bilgisini gereksinim safhalar nda kullanma [7], modeller ve gereksinimler aras ndaki ili kileri ortaya karma ve bilgi sistemlerinin süreçlere entegre edildi i noktalar n aç a ç kar lmas yla gereksinimlerin eksiksizlik ve izlenebilirli ini artt rma [11] gibi di er faydalar da beraberinde getirebilir. Bu çal mada, kamu kurumlar nda gerçekle tirdi imiz bir vaka çal mas sunuyoruz. Bu vaka çal mas nda, gereksinim analizi ve i süreçleri modelleme aras ndaki bo lu un kapat lmas ve yukar da say lan faydalar n elde edilmesi amaçlanmaktad r. Vaka çal mas nda i süreçleri tan mlanm ve yaz m gereksinimleri bütünle ik bir yakla m kullan larak süreç modellerine entegre edilmi tir. Gereksinim belirtim dokümanlar vaka çal mas kapsam nda geli tirilen bir araç vas tas yla otomatik olarak süreç modellerinden üretilmi tir. Vaka çal mas n ana kt lar, i süreci modelleri ve gereksinim belirtimleridir. Bu ç kt lar n geçerlenmesi gözden geçirme akiviteleri ile sa lanm r. Bu çal ma be k m halinde organize edilmi tir. m 2, ara rma sorular ve vaka çal mas plan betimlemektedir. K m 3 te vaka çal mas n uygulamas safhas olu turulan i süreci modelleme ve gereksinim analizi yakla ile birlikte anlat lmaktad r. Çal man n sonuçlar ve geçerlili ine dair tehditler k m 4 te verilmi tir. Sonuçlara ili kin tart malar, elde edilen faydalar ve gelecekteki çal malar k m 5 te sunulmu tur. 2.1. Ara rma Sorular 2. Vaka Çal mas Tasar ki tane ara rma sorusu belirlenmi tir. süreci modelleri gereksinim analizinde kullan labilir mi? Gereksinim analizi aktivitelerini i süreci modelleme ile birlikte gerçekle tirmek için bir yakla m olu turmak ve böylece süreç modellerindeki bilgilerin yaz m gereksinimlerine aktar lmas amaçlanmaktad r. Süreç modellerinin gereksinim analizinde kullan lmas i süreçlerinin modellenmesi ve gereksinim analizi aktivitelerinin toplam verimlili ini artt r m? Geli tirilen yakla mla gereksinim üretmeye harcanan gücünün takip edilmesi ve geleneksel gereksinim analizi i gücü kestirimi ile kar la lmas amaçlanmaktad r. gücü kestirimi fonksiyonel büyüklük kullan larak yap lacakt r. 2.2. Vaka Çal mas Plan Ara rma sorular n de erlendirmesi için vaka çal mas nda gerçekle tirilen aktiviteler vaka çal mas

plan n olu turulmas yla ba lam r. A daki aktiviteler planda yer almaktad r. Küçük bir süreç kümesi için i süreci modellerini olu tur. Yaz m gereksinimlerini süreç modellerinden türetmek için süreç modelleme yakla uyarla. Süreç modellerinden ba ms z olarak, seçilen süreç kümesi için gereksinim belirtimlerini yaz ve gözden geçir. Süreç modelleme yakla, gereksinim belirtimlerinin yap sal, linguistik ve veri gereksinimlerini kar lama aç ndan incele. Süreç modelleme notasyonunda yap lacak eklentileri ve de iklikleri tan mla. Gereksinim belirtimi doküman n süreç modellerinden üretilmesi için kullan lacak yakla tan mla. Süreç modellerinden gereksinimleri el ile türet ve gözden geçir. Tekil gereksinim belirtimlerinin ve gereksinim belirtim dokümanlar n süreç modellerinden otomatik üretilmesini sa la. Yakla daha geni süreç kümelerinde uygula. Yukar da belirtilen süreç modelleme ve gözden geçirme aktivitelerinin alan uzmanlar yla beraber çal taylarda gerçekle tirilmesi belirlendi. Modelleme çal malar ba lamadan önce gerçekle tirilecek bir e itim seans planland. E itimin konusu alan uzmanlar n i süreci modelleme konular nda e itimi olarak olu turuldu. Ön haz rl klar çerçevesinde vaka çal mas nda yer alacak roller ve sorumluluklar tan mland. Süreçlere klavuzluk eden süreç rehberleri bir araya getirildi ve analiz edildi. Vaka çal mas n sonuçlar de erlendirmede kullan lacak i gücü, karar, sorun ve iyile tirmelerin kay tlar n tutulmas na karar verildi. Projenin süreç modellerini mant ksal olarak kapsayan modüllere ayr lmas ve aktivitelerin modül baz nda çevrimler halinde ilerleyerek gerçekle tirilmesi kararla ld. Vaka çal mas n ç kt lar ; i süreci modelleri, yaz m gereksinim belirtim dokümanlar, veri sözlü ü, çal tay raporlar ve ilerleme raporlar r. Alan uzmanlar taraf ndan yap lacak iç gözden geçirmeler ve süreç modelleme uzmanlar, d alan uzmanlar ve yüklenici yaz m geli tirici taraf ndan yap lacak d gözden geçirmelerle bu ç kt lar n geçerlenmesi planland. Süreç modelleme ve gereksinim analizi aktiviteleri her bir modül için tekrarlanacak, her bir modülün ç kt lar mü teriye teslim edilecek ve kabul prosedürleri uygulanacakt r. Vaka çal mas tüm ç kt lar n olu turulup teslim edilmesi ve mü teri taraf ndan kabul edilmesiyle birlikte tamamlanacakt r. 3. Vaka Çal mas Uygulama Vaka çal mas, i süreçlerinin tan mlanmas ve bilgi sistemleri ile desteklenmesi amac yla bir proje ba latan üç kamu kurumunda gerçekle tirilmi tir. Projede Çukurova Kalk nma Ajans al kurum, T.C. Devlet Planlama Te kilat Müste arl koordinatör kurum ve zmir Kalk nma Ajans da imzalanan protokole ba kurum olarak yer almaktad r. Projenin kapsam içindeki süreçler bölgesel kalk nmay desteklemek amac yla kurulan Kalk nma Ajanslar na ait i süreçleridir. Di er payda lara ait süreçler kapsam d rak lm r. Çukurova ve zmir Kalk nma Ajanslar pilot olarak sa bir süre önce kurulan Kalk nma Ajanslar d r. Çukurova ve zmir e ek olarak Türkiye genelinde yeni kurulan ve kurulma a amas nda olan 24 Kalk nma Ajans ile beraber, tan mlanan i süreçleri ve geli tirilen yaz mlar n yakla k 900 personel taraf ndan kullan lmas amaçlanmaktad r. Proje kapsam nda yer alan ve bu makaleye konu olan vaka çal mas n bir y l sürmesi planlanmaktad r. Kalk nma Ajans i süreçlerinin ko ullar, döngüler, tlar, girdiler ve ç kt lar ve birbirine ba, hiyerar ik ve birbirine referans veren süreçleriyle karma k bir yap ya sahip olduklar görülmü tür. Bu durum i süreci modelleme çal malar n faydalar n görülmesi için bir avantaj yaratmaktad r. Vaka çal mas n uygulamas nda kullan lan ve i süreci modelleme ve gereksinim analizi aktivitelerinin birlikte gerçekle tirilmesini sa layan bütünle ik yakla m, vaka çal mas plan nda yer alan basamaklar takip edilerek gerçekle tirilmi tir. Vaka çal mas sekiz süreç modülüne ayr lm r. Bu süreç modülleri Kalk nma Ajanslar n n ana ve destek süreçlerini kapsamaktad r. Modelleme aktivitelerinin yap ld her bir çal tayda ortalama be alan uzman ve üç süreç modelleme uzman yer almaktad r. Mevzuatlar ve süreç rehberleri ile birlikte alan uzmanlar n uzmanl klar süreç modelleri için ana girdilerdir. Seçilen süreç kümesi için olu turulan süreç modelleri çal taylarda yer almayan alan uzmanlar ve i süreci modelleme uzmanlar taraf ndan gözden geçirilmi tir. Yap lan gözden geçirme seanslar sonunda gözden geçirme sonuçlar kay t alt na al nm, modeller güncellenmi ve ürünler sonland lmadan önce onaylanm r. Vaka çal mas n uygulamas nda kullan lan yakla m da betimlenmi tir. Mevcut i süreci modelleme dilleri ve araçlar, kullan lacak i süreci modelleme tekni ini belirlemek amac yla, ara rma sorular da göz önüne al narak incelendi. Geni letilmi Olay Tabanl Süreç Zinciri

(eepc) model notasyonu i süreci modelleme için seçildi. eepc, süreç modellemeye hakim olmayan alan uzmanlar ile ve formal süreç belirtimi mant yerine mant ile modelleme yapmaya yatk n bir i süreci modelleme notasyonudur [12]. EPC notasyonu 1990 larda popüler olan ve süreçlerde yer alan aktiviteler aras ndaki mant ksal ili kileri tan mlamak için kullan lan bir süreç modelleme notasyonudur [13], [14]. eepc, aktivite ak temel al r ve organizasyonlar, sistemler, kurallar, girdiler ve kt lar gibi statik i kaynaklar bir araya getirir [15]. Bu çal ma içinde, eepc notasyonunda kulland z tl nesne tipleri kümesi Tablo 1 de verilmi tir. Süreç analizleri yukar dan a ya bir yakla mla yap ld. Üst seviye süreç gruplar ve bu gruplar aras ili kiler belirlendi. Ard ndan, bu süreç gruplar n her biri alt seviye süreçlere indirgendi. Alt seviyedeki her sürece bir üst seviyedeki süreçlerdeki fonksiyon nesnelerinden gelen ba lant larla ula lmaktad r. Modellerin organizasyonunun ve detay seviyesinin belirlenmesinde literatürdeki rehberler ve tecrübelerden yararlan ld [16]. Olu turulan süreç modellerinde en fazla 15 fonksiyon ve 50 nesne vard r. Di er yandan hiyerar inin derinli i en fazla be ile s rland ld. Birden fazla üst seviye süreç taraf ndan kullan labilecek yeniden kullan labilir süreçler tan mland. Yeniden kullan labilir süreçler süreç arayüzleriyle modellerdeki herhangi bir yerden ça labilmektedir. Bu vaka çal mas nda, süreç arayüzleri ve alt seviye süreçler, hiyerar ik ve modüler süreç yap biçimlendiren ana yap lar olmu tur. Bu yap lar n kullan süreçlerin anla rl ve bak artt rmaktad r. Süreç hiyerar isi ve arayüzleri üst seviye bir süreç haritas olarak kullan labilir ve süreç modülleri aras ndaki ili kileri aç a ç karmaktad r. Tablo 1: eepc modellerindeki nesne tipleri Nesne Ad Organizasyonel nesneler Position Nesne Sembolü Organizational unit Bilgi ta lar kural Süreç arayüzü Folder Document Business rule Process interface Letter Vaka çal mas ndaki alt seviye bir süreç için olu turulan eepc modeli ekil 1 de verilmi tir. Süreçte, De erlendirme Komitesi (DK) fonksiyonlar gerçekle tiren roldür. Süreç, proje tekliflerinin incelenmesi tamamland nda ve Yönetim Kurulu ndan yeniden de erlendirme iste i geldi inde ba lar. Yeniden de erlendirilecek proje listesi, yeniden de erlendirme için haz rl klar n yap lmas fonksiyonunda girdi olarak kullan r, fonksiyonun kt DK de erlendirme takvimidir ve fonksiyon bir kural taraf ndan k tlanmaktad r. Bir sonraki fonksiyon olan, yeniden de erlendirme gerekçesinin raporlanmas s ras nda yeniden de erlendirme gerekçesi olu turulur. Ard ndan gelen DK de erlendirmesi süreç arayüzü ile süreç bir ba ka süreçten devam eder. Yeniden de erlendirilecek projeler bitmediyse süreç ba a döner, e er bittiyse süreç sonlan r. Çal mada eepc d nda, bir süreç içindeki aktiviteler aras nda ak ili kisi bulunmad durumlarda, fonksiyon a açlar kullan lm r. Fonksiyon a açlar fonksiyonel hiyerar iye göre birbirine ba lanan fonksiyon nesnelerinden olu maktad r. Fonksiyon açlar n kullan hiyerar ik yap n kurulmas na katk sa lamaktad r. süreci modelleme çal malar ras nda, süreçlerdeki tüm organizasyonel nesneleri ve bunlar aras ndaki ili kileri tan mlayan organizasyon emas tutulmu tur. Fonksiyon Function Olay Event Mant ksal leçler (Ve Veya lamal veya)

Süreç modellerindeki fonksiyonlar kullan m durumu adaylar olarak al nabilir. Ancak fonksiyonlar yaz m belirtimlerine dönü türmek için aksiyonlarla detayland rmak gerekir. Bilgi ta lar sistem girdileri ve ç kt lar için fikir verebilir, ama eepc modellerindeki halleriyle sistem girdi ve ç kt lar tan mlamazlar. Kanuni ve sürece özel k tlar nedeniyle modellerdeki bilgi ta lar n tamam bilgi sistemlerinde tutulmayabilir. Bunun d nda, bilgi sistemleri için ek girdi ve ç kt lar tan mlamak gerekebilir. Girdi ve ç kt lar üzerindeki i lemler eepc modellerinde tasvir edilemez. Eksiksiz ve formale yak n bir yakla m için bu i lemlerin standart bir ekilde tan mlanabilmesi gerekmektedir. eepc modellerindeki i kurallar kanuni kurallar ve süreç k tlar tan mlar. Yaz m gereksinimleri de erlendirildi inde, mevcut i kurallar n bir k sm n yaz m karakteristiklerini yans tmad ve yaz m için baz ek kurallar n tan mlanmas gerekti i tespit edilmi tir. ekil 1: Örnek eepc modeli eepc modelleri olu turulduktan sonraki basamak, i süreci modellerinde bilgi sistemleri ile desteklenecek aktivitelerin tespit edilmesiydi. Bu aktiviteler tespit edildikten sonra, yaz m gereksinimleri için gerekli olan bilginin i süreci modellerine gömülmesi gerekiyordu. eepc modellerinin temel al nd modelleme yakla, gereksinim analizi aç ndan incelendi inde daki noktalar tespit edilmi tir. Süreç modellerindeki süreçler sistem özelli i ve baz durumlarda kullan m durumu olarak de erlendirilebilir. eepc modellerindeki organizasyonel nesneler süreçlerdeki sorumluluklar belirlemek için kullan r. Ancak, bilgi sistemlerinde ba ka organizasyonel nesneler ilgili fonksiyonlar gerçekle tirmek için yetkilendirilebilmelidir. eepc notasyonu bilgi sistemlerini tan mlayan nesneleri içermez. Yukar daki noktalar de erlendirildi inde, eepc modellerinin gereksinim analizi aç ndan olu turulan yakla n gereklerini kar lamad anla lm r. Ayr ca, bilgi sistemlerine ili kin bilgilerin eepc modellerine gömülmesi modellerin yal nl yitirmesine neden olacakt r, bu da modellerin alan uzmanlar taraf ndan kullan lmas ve anla lmas na engel olabilecektir. Bu nedenle, bilgi sistemlerine ili kin bilgilerin ayr bir model tipinde tutulmas na karar verildi. ARIS metodolojisinde hiyerar ik olarak eepc modellerinin alt nda ifade edilen Fonksiyon Da m Diyagramlar n (FAD) [15] kullan, yakla eepc modellerinde yer almayan yaz m gereksinimi bilgileriyle geni letmek için en iyi aday olarak belirlendi. FAD lar ço unlukla girdi, ç kt, uygulama ve roller gibi detaylar modelleyerek süreç modellerini yal nla rmak için kullan r. Bu tan ma göre FAD lar i süreci modellerine k yasla fazladan bilgi bar nd rmamak üzere tasarlanm r [6]. Bu çal mada FAD lar, yaz ma özgü bilgilerin eepc modellerinden ayr lmas için kullan lm r. FAD lar n yayg n kullan ndan farkl olarak, i süreçlerine sa lanan bilgi sistemleri deste i,

uygulamalara ait sistem varl klar, i kurallar ve sistem varl klar üzerindeki i lemler ile tan mlanabilmi tir. Bir sonraki basamakta, bu modelleme yakla do al dilde belirtimlerin olu turulmas sa layacakt r. FAD larda kullan lan nesneler Tablo 2 de ve fonksiyon ve varl k nesneleri aras ndaki ba lant gösterimleri Tablo 3 te verilmi tir. Fonksiyon Pozisyon Tablo 2: FAD'lardaki nesne tipleri Nesne Ad Bilgi Sistemi Sistem varl Nesne Sembolü Function Position Application system type Entity type geçirildi. Gözden geçirme sonuçlar na göre, modelleme notasyonuna eklenecek üç nokta tespit edildi. eepc modellerindeki i kurallar n, yaz m gereksinimlerine dönü türülmek üzere FAD notasyonuna eklenmesine gerek görüldü. ki ya da daha fazla i lem aras nda seçim gerekiyorsa, bu gereksinim ba lant lar üzerindeki ayn numaral etiketlerle ifade edilir. Türkçe spesifikasyonlar n olu turulabilmesi amac yla FAD lardaki nesne tipleri için standart isimlendirme kurallar olu turulmu tur. ekil 2 de verilen FAD örne inde, yeniden de erlendirme için haz rl klar n yap lmas fonksiyonunu DK üyesi gerçekle tirmektedir. PFDS sistemi üzerinde, yeniden de erlendirilecek proje listesi listelenmekte ve de erlendirme takvimi olu turulmaktad r. PFDS sistemi bir i kural ile k tlanmaktad r. ABYS sistemi üzerinde ise ar iv ç kayd yarat lmakta ve teklif ça ya da a amal teklif ça okunmaktad r. Tablo 3: Fonksiyon ve varl k nesneleri aras ndaki ba lant gösterimleri Ba lant Ad Creates (yarat labilmeli) Changes (de tirilebilmeli) Reads (okunabilmeli) Views (görüntülenebilmeli) Lists (listelenebilmeli) Ba lant Gösterimi Function "..." Entity type Yakla tan mlamada bir sonraki basamak, süreç modellerinden do al dilde yaz m belirtimlerinin türetilmesidir. Süreç modellerine nesneler ve ba lant larla gömülen gereksinimlerin toplanmas ve do al dilde belirtimlere dönü türülmesi gerekmektedir. Do al dilde yaz m belirtimleri, yaz m gereksinimlerini formal olmayan cümle yap lar ile tan mlamak için kullan r. Bu cümle yap lar için farkl uygulamalar olmas na ra men, genel olarak do al dilde spesifikasyon cümleleri, i lemleri ifade eden yüklemler ve aktörler, hedef nesneler ve girdi ve ç kt parametrelerini ifade eden isimlerden olu ur [17]. Bu de erlendirmeleri göz önünde bulundurarak, do al dilde spesifikasyonlar seçilen süreçler için süreç modellerindeki nesne ve ba lant lar kullan lmadan elle yaz ld. Bu spesifikasyonlar vaka çal mas nda yer almayan yaz m mühendisleri taraf ndan gözden ekil 2: Örnek FAD FAD lar n olu turulmas nda bilgi sistemleriyle desteklenecek fonksiyonlar belirlendikten sonra, bilgi sisteminde fonksiyonu gerçekle tirmek üzere yetkilendirilecek rol belirlenir. Sistem varl klar, fonksiyonun gerçekle tirilmesi s ras ndaki sistem girdi ve ç kt lar de erlendirilerek belirlenir. Fonksiyonlar ve varl klar aras ndaki ba lant lar, sistem varl klar üzerindeki i lemleri tan mlar. Her sistem varl muhafaza edildi i uygulamaya ba lan r. Son olarak, FAD lardaki i kurallar nda eepc modelleri ve süreç rehberlerindeki kurallardan esinlenilir. eepc modelleri ve FAD lardan olu an i süreci modelleri olu turulduktan sonra, do al dilde belirtimlerin cümle yap lar, elle yaz lan belirtimlerin gözden geçirme sonuçlar ndan yararlan larak olu turuldu. Olu turulan cümle yap ile ekil 2 deki

FAD tan üretilen dad r. do al dilde yaz m belirtimi Yeniden de erlendirme için haz rl klar n yap lmas ras nda, DK üyesi taraf ndan ABYS sistemi üzerinde ar iv ç kayd yarat labilmeli, teklif ça ba vurusu veya a amal teklif ça ba vurusu okunabilmeli, PFDS sistemi üzerinde DK de erlendirme takvimi yarat labilmeli ve DK yeniden de erlendirilecek proje listesi listelenebilmelidir. ekil 2 deki i kural do al dilde spesifikasyonlarda daki gibi ifade edilmi tir. PFDS sistemi üzerinde, yeniden de erlendirilmesi kararla lan her projenin iki DK üyesi taraf ndan de erlendirilmesi planlanmal r. Gereksinimler numaraland lm ve hiyerar ik olarak alt nda bulunduklar süreçlerin alt nda grupland lm r. eepc modellerindeki süreç hiyerar isi gereksinim ba klar n ve seviyelerinin tan mlanmas nda kullan lm r. Sonuç olarak, gereksinim belirtim doküman yap, ba klar alt nda numaraland lm gereksinimler ile olu turulmu tur. Olu turulan do al dilde yaz m belirtim cümle ve doküman yap lar, yaz m belirtimlerinin elle yaz lmas nda kullan lm r. Bu elle yaz lan belirtimler, alan uzmanlar ve vaka çal mas nda yer almayan yaz m mühendisleri taraf ndan gözden geçirilmi ve geçerlenmi tir. Geçerlemenin ard ndan, do al dilde yaz m belirtimlerinin otomatik olarak üretilmesini sa layan bir araç geli tirilmi tir [18]. Geli tirilen araç, belirlenen cümle ve doküman yap lar nda gereksinim belirtimleri üretmektedir. Araç, ARIS modelleme arac ndaki veritaban objelerini kulanarak, yaz m belirtimlerini içeren bir MS Word dosyas üretir. Arac n ç kt lar, ç kt lar elle yaz lan belirtimlerle kar la larak geçerlenmi tir. 4. Vaka Çal mas Sonuçlar ve Tehditler Pilot olarak seçilen süreç kümesi için süreç modelleme ve gereksinim analizi çal malar n olu turulan yakla m ile yap lmas n ard ndan, süreç modüllerinde bu yakla n kullan lmas na ba land. Tamamlanan ve kabulü gerçekle en iki süreç modülü için 791 i FAD olmak üzere 946 i süreci modeli teslim edildi. Do al dilde yaz m belirtimleri, araç deste iyle üretildi ve toplam 1002 do al dilde belirtim içeren gereksinim dokümanlar vaka çal mas n gerçekle tirildi i organizasyonlara sunuldu. Ürünler bu organizasyonlar taraf ndan gözden geçirilip kabul edildi. Süreç modelleri için üç, yaz m belirtimleri için bir ve kullan lan yakla m için bir gözden geçirme seans yap ld. Hem süreç modelleri, hem de yaz m belirtimleri yaz mlar geli tirecek kuruma gönderildi. Bu çal mada sistem varl klar ve kullan m durumlar seviyesinde fonksiyonel yaz m gereksinimleri belirlenmi tir. Fonksiyonel gereksinimlerin tamamlanmas için öznitelik ve kullan senaryolar seviyelerine inilerek fonksiyonel gereksinimlerin belirlenmesi gerekmektedir. Bu k sm n gereksinim mühendisli i aktiviteleri içinde en fazla yüzde 50 lik ve fonksiyonel olmayan gereksinimlerin belirlenmesinin de yüzde 10 luk bir k sma kar k geldi ine yönelik tecrübeye dayal bir varsay m yapt k. Bu varsay ma göre çal mam zda geli tirilecek bilgi sistemleri için gerekli olan gereksinim mühendisli i aktivitelerinin en az yüzde 40 tamamlad z sonucuna vard k. lk iki süreç modülü için toplamda 3000 adam-saatlik gücü harcand. Bu iki süreç modülü için geli tirilecek bilgi sistemlerinin büyüklü ü için ise 11000 Cosmic fonksiyon noktal k bir büyüklük kestirimi yap ld [19]. Yaz m geli tirme ya am döngüsünde gereksinim safhas için üretkenlik derecesinin mod de eri, fonksiyon nokta ba na 0,75 adam-saattir [20]. Bu de er, 11000 fonksiyon nokta için kestirilen i gücünün 3300 adam-saat oldu unu gösterir. Kestirilen 3300 adam-saatlik i gücü, vaka çal mas nda harcanan 3000 adam-saatlik i gücüne neredeyse e ittir. Bu hesaplamalar nda, sadece gereksinim analizi için gerekli olan i gücünü harcayarak, i süreci modelleme ve gereksinim analizi aktivitelerini gerçekle tirmeyi ba ard gördük. Sonuç olarak, bu çal ma ile i süreci modelleme ve gereksinim analizi aktivitelerinin toplam i gücünde belirgin dü sa lanm r. Vaka çal mas n geçerli ine dair üç tehdit tespit edilmi tir. lk tehdit, üretilen do al dilde yaz m belirtimlerinin henüz yaz m geli tirmede kullan lmamas r. Ancak, bu spesifikasyonlar yayg n olarak kullan lan gereksinim mühendisli i tekniklerini temel almaktad r ve mü teri organizasyonlardan kabul alm ve yaz m geli tirici kuruma teslim edilmi tir. Bu sebeplerden, bu tehditin vaka çal mas n geçerli ine zarar verece ine inanm yoruz. Vaka çal mas n geçerli ine dair ikinci tehdit vaka çal mas n sonuçlar n yanl de erlendirilmesi konusunda kendimizi sorgulamam gerektirir. Bu tehditi elemek için olu turulan yakla yayg n kullan lan gereksinim mühendisli i tekniklerinden uyarlad k ve yakla n vaka çal mas nda yer almayan yaz m mühendisleri taraf ndan geçerlenmesini sa lad k. Son tehdit olu turulan yakla n tek bir vaka çal mas nda geçerlenmi olmas r. Bu tehditin

ortadan kalkmas için yakla n uygulanaca ba ka vaka çal malar planlanmaktad r. 5. Sonuç Bu çal mada amac z i süreci modellerinin gereksinim analizi için kullan lmas ara rmakt. Bu amaçla Türkiye deki Kalk nma Ajanslar n n süreçlerinin modellendi i ve bu süreçler için yaz m gereksimlerinin olu turuldu u bir vaka çal mas gerçekle tirildi. 11000 fonksiyon nokta büyüklü ünde bir sistem için 3000 adam-saatlik i gücü harcanarak, 946 i süreci modeli ve 1002 do al dilde yaz m belirtimi olu turuldu ve teslim edildi. Geli tirilen bir araç ile do al dilde belirtimler içeren gereksinim dokümanlar n üretilmesi otomatikle tirildi. Böylece yaz m al için gerekli teknik artname doküman da olu turulmu oldu ve gerçekle tirilecek al m sürecine ait faaliyetler kolayla ld. lk ara rma sorumuzu, i süreci modelleme ve gereksinim analizi aktivitelerini bütünle tiren bir yakla m olu turarak cevaplad k. Yakla m, birçok gözden geçirme ile olu turulan vaka çal mas ürünleri ile geçerlendi. Bu yakla m ile yaz m gereksinim dokümanlar n otomatik üretilmesi, böylece i süreçlerindeki bilgilerin yaz m gereksinimlerine dönü türülmesi sa land. Olu turdu umuz yakla m, yaz m geli tirme ya am döngüsünde gereksinim analizi safhas k smen içermektedir. kinci ara rma sorusu vaka çal mas nda harcanan gücü, sistemin büyüklü üne göre endüstri verilerine dayal i gücü kestirimi ile kar la larak cevapland. En dü ük tahminle gereksinim mühendisli i aktivitelerinin yüzde 40 tamamlam oldu umuzu varsaysak bile, i süreci modelleme ve gereksinim analizi için harcanan toplam i gücü, endüstri verilerine göre sadece gereksinim analizi için gereken gücüne denk olmaktad r. Toplam i gücü aç ndan gereksinim analizinin verimlili ini artt rmak d nda, kulland z yakla n birçok faydas gözlemledik. süreci modelleri, gereksinimlerin yap sal bir ekilde tart lmas, toplanmas ve analiz edilmesi için ortam olu turdu. Böylece bilgi sistemi gereksinimlerinin herhangi bir parças n atlanmas ya da tekrarlanmas ihtimali azalt ld. Bu durum gereksinimlerin eksiksizlik ve hatas zl k özelliklerini artt rd. süreci modelleme aktiviteleri yaz m geli tiricilerini, sistemleri yap sal bir ekilde tan mlamaya zorlar. Önceki k mlarda süreç modellerinin hiyerar ik yap n, süreçlerin modüler bir ekilde tan mlanmas ve bu süreçlerin farkl seviyelerdeki ba lant lar n aç a ç kar lmas sa lad tart lm. Bu sebeplerle, süreçlere ait yaz m gereksinimleri, yayg n do al dilde belirtimlere göre anlam aç k ve tutarl ekilde ifade edilir. Sonuç olarak, süreç modelleri gibi anlam aç k ve tutarl gereksinim dokümalar olu turmu olduk. Bunun nda gereksinimlerde tekrarlar n olmad biliyoruz çünkü süreç modellerinde tekrarlanan nesneler bulunmamaktad r. Süreç modelleri ile gereksinimler aras nda izlenebilirlik sa land için gereksinimlerin bak nda da üretkenlik artt ld. Geli tirilen araç ile gereksinimler de ti i zaman gereksinim dokümanlar da yeniden üretilebilmektedir. Gelecek çal malar için, önerilen yakla n ba ka vaka çal malar nda da uygulanmas ve metodolojinin tan mlanmas öngörülmektedir. Vaka çal malar farkl endüstrilerde ve farkl büyüklükteki organizasyonlarda gerçekle tirilecektir. Böylece tan mlanacak metodolojinin i süreci modelleme alan nda farkl gerekleri kar lamas sa lanacakt r. FAD lar kullan larak, sistemlerin tüm veri haraketleri tan mlanabilir, böylece veri tiplerinin iskeletleri türetilir. Bir di er ara rma yönü bu yöntemle elde etti imiz bilginin yaz m geli tirme ya am döngüsünde di er a amalarda kullan lmas olabilir. Kullan m durumlar ve formal spesifikasyonlar n türetilmesi için çal malar da ihtimaller aras nda yer almaktad r. Bu türden çal malar için FAD notasyonu; lem s ralamalar, sistem durumlar ve mant ksal bölünme ve ba lant larla geni letilebilir. Çal malar bu öngörüler kapsam nda geni letilmektedir. imdiden bilgi sistemi büyüklü ü için çal malar yap lm r ve sistemin fonksiyon nokta cinsinden otomatik büyüklük kestirimi olu turulmaktad r [19]. Bunun d nda süreçlerin tüm kullan lar taraf ndan pratik ekilde kullan sa layacak kullan k lavuzlar da otomatik olarak kar lmaktad r. Te ekkür Devlet Planlama Te kilat Müste arl, Çukurova Kalk nma Ajans ve zmir Kalk nma Ajans na bu çal maya verdikleri katk lar ve destek için te ekkür ederiz. Devlet Planlama Te kilat bünyesinde çal an Nahit Bingöl, Ramazan Güven, lgen erifeken, Ersay Çete, Zeyneb Ersay n, Erdem Kazaz, Selçuk Y lmaz ve Volkan Ba man a da ayr ca te ekkürlerimizi sunar z. Kaynaklar [1] Recker, J., Rosemann, M., Indulska, M. and Green, P. (2009). Business Process Modeling - A Comparative Analysis. Journal of the Association for Information Systems, 10(4), pp. 333 363. [2] Yourdon, E. (2000). Managing Software Requirements. Addison Wesley Publishing Company. [3] Abran, A., Bourque, P., Dupuis, R., Moore, J. W. and Tripp, L. L. (2004). Guide to the Software Engineering Body of Knowledge SWEBOK. 2004th ed., A. Abran, P. Bourque, R. Dupuis, J. W. Moore, and L. L. Tripp, Eds. Piscataway, NJ, USA: IEEE Press.

[4] Westland, J.C. (2002). The Cost of Errors in Software Development: Evidence from Industry. The Journal of Systems and Software, 62, pp. 1-9. [5] Tarhan, A., Gencel, C. and Demirors, O. (2007). Pre- Contract Challenges: Two Large System Acquisition Experiences. Book chapter in Enterprise Architecture and Integration: Methods, Implementation and Technologies, IGI Global. [6] Specht, T., Drawehn, J., Thranert, M. and Kuhne, S. (2005). Modeling Cooperative Business Processes and Transformation to a Service Oriented Architecture. In 7th International IEEE Conference on E-Commerce Technology, pp. 249-256. [7] Cox, K., Phalp, K. T., Bleistein, S. J. and Verner, J.M. (2005). Deriving Requirements from Process Models via the Problem Frames Approach. Information and Software Technology, 47, pp. 319-337. [8] Berenbach, B., Paulish, D., Kazmeier, J. and Rudorfer, A. (2009). Software & Systems Requirements Engineering: in Practice. 1st ed. McGraw-Hill, Inc. [9] Demirors, O., Gencel, C. and Tarhan, A. (2003). Utilizing Business Process Models for Requirements Elicitation. Proceedings of the 29th Conference on EUROMICRO, p. 409. [10] Yang, Y., He, M., Li, M., Wang, Q. and Boehm, B. (2008). Phase Distribution of Software Development Effort. In Proceedings of the Second ACM-IEEE international Symposium on Empirical Software Engineering and Measurement, pp. 61-69. [11] Nicolas, J. and Toval, A. (2009). On the Generation of Requirements Specifications from Software Engineering Models: A Systematic Literature Review. Information and Software Technology, 51, pp. 1291-1307. [12] van der Aalst, W. (1999). Formalization and Verification of Event-driven Process Chains. Information and Software Technology, 41(10), pp. 639-650. [13] Scheer, A.W. and Schneider, K. (2006). Aris - Architecture of Integrated Information Systems. In P. Bernus, K. Mertins and G. Schmidt (Ed.), Handbook on Architectures of Information Systems, pp. 605-623. [14] Mendling, J. (2008). Metrics for Process Models: Empirical Foundations of Verification, Error Prediction, and Guidelines for Correctness. Springer Publishing Company, Incorporated. [15] Davis, R. and Brabänder, E. (2007). ARIS Design Platform: Getting Started with BPM, 1st ed. Springer. [16] Mendling, J., Reijers, H. A. and van der Aalst, W. M. P. (2010). Seven Process Modeling Guidelines (7pmg). Information and Software Technology, 52(2), pp. 127 136. [17] Saeki, M., Horai, H. and Enomoto, H. (1989). Software Development Process from Natural Language Specification. 11th International Conference on Software Engineering. [18] Coskuncay, A. (2010). An Approach for Generating Natural Language Software Specifications by Utilizing Business Process Models. M.S. Thesis, METU Informatics Institute, Ankara. [19] Kaya, M. (2010). E-Cosmic: A Business Process Model Based Functional Size Estimation Approach. M.S. Thesis, METU Informatics Institute, Ankara. [20] Jones, T. C. (1998). Estimating Software Costs. McGraw-Hill, Inc.