DETERMINATION, SOLUTION AND ANALYSIS OF BOTTLENECKS IN SERVICE PRODUCTION IN LARGE-SCALE SIZE ENTERPRISES

http://dx.doi.org/10.17740/eas.stat.2016-MSEMP-7

DETERMINATION, SOLUTION AND ANALYSIS OF BOTTLENECKS IN SERVICE PRODUCTION IN LARGE-

SCALE SIZE ENTERPRISES

Halim Kazan*, Ahmet Ergülen**, Bülent Çoban***

* Istanbul University, Istanbul, Turkey **Necmettin Erbakan University, Istanbul, Turkey, Beykent University***

E-mail: halim.kazan@istanbul.edu.tr*, argulen@konya.edu.tr**

Copyright © 20162016 Halim KAZAN, Ahmet ERGÜLEN, Bülent ÇOBAN. This is an open access article distributed under the Eurasian Academy of Sciences License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

ABSTRACT

Today, the need for information technologies is constantly increasing in order to take advantage of utilizing data. Information and Information Technology (IT) sometimes constitute bottlenecks for large- scale size enterprises in the intuitional dimension. Given the fact that the causes of these bottlenecks are usually grounded upon various reasons, the main reason is that not to get sufficient efficiency from the projects. In this study, software applications development processes in large-scale enterprises within the scope of the producing services (demand request, content preparation, preparation for analysis, software implementation, testing, user acceptance and reasons of constraints & bottlenecks) are examined, so that a research is done by dealing with how experiencing bottlenecks in this process affects project performance, information, information technology and project management concepts and life cycle of software projects in scope of project management. By determining failure rate of projects are still at a high level according to the literature survey and practice, in information technology (IT) projects, in particular with software application development projects, the failure rate of projects is determined to be above average. Furthermore, by working on simple linear model to measure the success of the project, among the IT workers in a large state-owned bank, a questionnaire is applied, which uses success algorithm in this model including the variables such as Feasibility (demand), Analysis, Design, Coding, Testing, Implementation and Delivery. By evaluating the results of this survey, the reasons that effects project performance are analyzed, bottleneck reasons of these factors and at which rate these factors influence the completion of the project for ever single factor are tried to be explained. In the application, by using correlation among factor tests, factor analysis and regression, determination of loads of the factors and validity of the model was investigated.

Keywords:Information, Information Technology, Software development, project management, hypothesis

JEL: C-C1-C12-C19

Büyük Ölçekli Firmalarda

Hizmet Üretiminde Oluşan Darboğazların Belirlenmesi, Çözümü ve Analizi ÖZET

Günümüzde bilgiden yararlanmak için gereken bilgi teknolojilerine olan ihtiyaç sürekli artmaktadır Bilgi ve Bilişim Teknolojisi (BT) kullanımı kurumsal boyutta büyük ölçekli işletmelerde zaman zaman

darboğazlar oluşturmaktadır. Bu darboğazların sebebi çeşitli nedenlere dayandırılmakla birlikte, asıl sebebi projelerden yeteri kadar verimin alınamamasıdır. Bu çalışmada, büyük ölçekli işletmelerde hizmet üretimi kapsamına giren yazılım uygulaması geliştirme süreçleri (Talep iletimi, kapsam hazırlığı, analize hazırlık, yazılım gerçekleştirme, test, kullanıcı kabulü ve kısıt ve darboğaz nedenleri) incelenerek, bu süreçlerde yaşanan darboğazların proje başarımını nasıl etkilediği, bilgi, bilgi teknolojisi ve proje yönetim kavramları ve proje yönetimi özelinde yazılım projelerinin yaşam döngüsü ele alınarak araştırma yapılmıştır. Yapılan literatür taramaları ve uygulamalara göre projelerde başarısızlık oranının hala yüksek seviyelerde olduğu tespit edilerek, Bilişim Teknolojisi (BT) projelerinde ve özellikle yazılım uygulamaları geliştirme projelerinde başarısızlık oranının ortalamanın üstünde olduğu belirlenmiştir. Ayrıca, proje başarısını ölçmek için basit doğrusal bir model üzerinde çalışılarak, bu modelde yer alan başarı algoritmasında kullanılan Fizibilite (talep), Analiz, Tasarım, Kodlama, Test, Gerçekleştirme ve Teslim değişkenlerini içeren bir anket büyük bir kamu bankasında BT alanında çalışanlara uygulanmıştır. Bu anket uygulaması sonuçları değerlendirilerek, proje başarımını etkileyen sebepler analiz edilmiş ve bu faktörlerin darboğaz nedenleri ve hangi oranda projenin tamamlanmasına etki ettiği faktör bazında ele alınarak açıklanmaya çalışılmıştır. Uygulamada ilişki testlerinden korelasyon, faktör analizi ve regresyon kullanılarak faktör yüklerinin belirlenmesi ve modelin geçerliliği araştırılmıştır.

Anahtar Kelimeler: Information, Information Technology, Software development, project management, hypothesis

1. GİRİŞ

Bilgi teknolojilerine olan ihtiyaç her geçen zaman sürekli artmaktadır. Gordon Moore tarafından 1975 yılında ortaya atılan ve Moore Yasası olarak anılan yasaya göre BT performansı her 18 ayda bir iki katına çıkmaktadır. Bazı sapmalar olmakla birlikte araştırmacının tecrübeleri de bunu desteklemektedir. Şöyle ki; 1995 yılında ortalama bir kişisel bilgisayarın RAM belleği 4MB civarında iken günümüzde 4GB ve daha da üstündedir. Aradan geçen 15 yılda kişisel bilgisayarların veri işleme kapasitesi 10 kattan fazla artarken, diğer taraftan bilgileri işleme ihtiyacı da daha fazla artmıştır.

Bilgi ve BT kullanımı kurumsal boyutta büyük ölçekli işletmelerde zaman zaman darboğazlar oluşturmaktadır. Bu darboğazların sebebi çeşitli nedenlere dayandırılmakla birlikte, asıl sebebi projelerden yeteri kadar verimin alınamamasıdır. Örneğin; Ünlü Standish Group araştırmasının sonuçlarına göre; projelerin %31,1’i tamamlanmadan iptal edilmekte, %52,7’si tahmin edilenin

%18,9’una mal olmakta ve BT projelerinin %78,4’ü başta öngörülen işlevlerin %74,2’sine sahip olarak tamamlanmaktadır (Chaos-report, projectsmart, 2010).

Bu çalışmada büyük ölçekli bir işletmenin yazılım uygulamalarında takip edilen talep iletimi, kapsam hazırlığı, analize hazırlık, yazılım gerçekleştirme, test, kullanıcı kabulü ve kısıt ve darboğaz aşamalarında yaşanan sorunlar ele alındı. Bu faktörlerin darboğaz nedenleri ve hangi oranda projenin tamamlanmasına etki ettiği faktör bazında ele alınarak açıklanmaya çalışıldı. Uygulamada ilişki testlerinden korelasyon, faktör analizi ve regresyon kullanılarak faktör yüklerinin belirlenmesi ve modelin geçerliliği araştırılmıştır.

2. LİTERATÜR ARAŞTIRMASI

Araştırmacılar Bilişim Teknolojisi projelerinde yaşanan başarısızlıkları uzun yıllardır incelemektedir. 1968 yılında NATO desteklerinde düzenlenen bir konferans ile “yazılım krizleri” ve

“yazılım başarısızlıkları” konuları üzerinde durulmuştur. Katılımcılardan J.Licklider tarafından BT projelerinin büyük çoğunluğunun tamamlanamadığı dile getirilmiştir.

Bu konunun önemini göstermek açısından 1970lerde Hank Lucas “Bilişim sistemleri neden başarısız olur ?” konusunda doktora tezi yazmıştır.

Yaklaşık son 15 yıldır Standish Group tarafından yürütülen orjinal adı “CHAOS Study” olan BT projlerinde başarısılıkları inceleyen çalışmalar öncü niteliktedir. Standish Group 2006 yılında yayınladığı raporunda; %19 oranında BT projesinin tamamlanmadan iptal edildiğini, %46 sının işlevsel biçimde tamamladığını ancak aşırı maliyet/zaman kullanarak ve/veya eksik işlevsel özellikler içierdiğini raporlamıştır. Yalnızca %35 oranında BT projesi zamanında ve bütçesine sadık kalarak planlanan fonksiyonlar ile neticelenebilmektedir.

Ancak Standish Group tarafından yapılan bu çalışmalara bazı eleştiriler getirilmektedir.

Bunlardan başlıcası grubun verilerini çoğunlukla başarısız projerlerden veriler alarak çalışmasını yürüttüğü şeklindedir. İngiltere de yapılan benzer bir çalışmaya göre ise; %9 oranında proje iptal edilmekte, %13 oranında maliyet , %20 oranında takvim sapmaları gerçekleşmekte ve kapsamına uygun biçimde teslim edilemeyen proje oranı %7 seviyesinde gösterilmektedir.

Standish’in çalışması projelerdeki başarısızlık nedenleri ile ilgili değişik faktörleri ortaya çıkarmıştır. Bunlardan ilk dördü şöyledir; 1) Kullanıcı katılımı, 2) Üst yönetim desteği, 3) İhtiyaçların açık biçimde tanımlanması, 4) Uygun Planlama. Katılımcılar ilk iki sıraya Tamamlanmamış İhtiyaçlar ve Kullanıcı Katılımı Eksikliği’ni koymuşlardır ( John Suzuki, members, 2010).

3. BİLGİ VE BİLGİ TEKNOLOJİLERİ

Bilgi, insanoğlunun hayatının her merhalesinde belirsizliği azaltmak ve karar verme süreçlerinde amacına ulaşmak için ihtiyaç duyduğu araçtır. İçinde bulunulan belirsizlik seviyesi ile sahip olunan bilgi arasında sıkı bir ilişki bulunmaktadır.

Bilgi; insanları, nesneleri, olayları ve kavramları yansıtan verilerin, işlenmiş ve anlamlı hale getirilmiş şeklidir (Celep ve Çetin, 2003:9).

Bilgi verilerden elde edilen sonuçların kod haline getirilmesidir(Kazan, Ergülen ve Kaplan, 2005).

Bilgi teknolojisini bilginin yaratılması, toplanması, biriktirilmesi, işlenmesi, yeniden elde edilmesi, yayılması, korunması ve bunlara yardımcı olan araçlar olarak tanımlanabilir (Uludoğan Poje tanıtımı, hostnigde, 2010).

Yüklenmek istenen amaca uygun olarak bilgi kavramı üç şekilde ifade edilebilmektedir. Bunlar;

veri (data), bilgi (infomation) ve üstbilgi (knowledge)’dir. (Kaya, 1996:14)

Veri, gerçeklik üzerinde yapılan gözlemlerin sonucu ve bu anlamda bilginin üretildiği hammaddedir (Gökçen, 2007:4). Bilgi ise, karar vermede faydalı olacak şekilde verinin dönüştürülmesi analiz edilmesiyle anlamlı hale getirilmesidir( John Suzuki, members, 2010).

Kutadgu Bilig’te Yusuf Has Hacip bilgiyi “değeri yok olmayan bir senet” olarak tanımlamıştır (Bedük, 2002:696).

Veri-bilgi ilişkisinin diğer unsurları, örgütsel karar alma ve denetimi karmaşıklaştırır. Bir kişi için bilgi niteliğinde olan bir şey, diğer bir kişi için veri niteliğinde olabilir (Demirci, 2001).

Bilgi (Knowledge), bu süreçteki üçüncü aşamadır. Enformasyonun, bilgiye dönüşmesi, bireyin onu algılaması, özümsemesi ve sonuç çıkarmasıyla gerçekleşir. Dolayısıyla bireyin algılama yeteneği, yaratıcılık, deneyim gibi kişisel nitelikleri de bu süreci doğrudan etkilemektedir.

Bilgelik (Wisdom) ulaşılmaya çalışılan noktadır ve bu kavramların zirvesinde yer alır. Bilgilerin kişi tarafından toplanıp bir sentez haline getirilmesiyle ortaya çıkan bir olgudur. Yetenek, tecrübe gibi kişisel nitelikler birer bilgelik elemanıdır (Öğüt, sertacogut, 2010).

Bilgelik (Wisdom) ulaşılmaya çalışılan noktadır ve bu kavramların zirvesinde yer alır. Bilgilerin kişi tarafından toplanıp bir sentez haline getirilmesiyle ortaya çıkan bir olgudur. Yetenek, tecrübe gibi kişisel nitelikler birer bilgelik elemanıdır (Öğüt, sertacogut, 2010).

Şekil 1 : Veriden Bilgeliğe

Kaynak: Spitzer Dean R., Transforming Performance Measurement: Rethinking the Way We Measure and Drive, Newyork, 2007, AMACOM, s.106

Veri 

Kalite Doğruluk Açıklık Düzen Sunum Araç

Zamanlılık Zamana duyarlı İstisnai raporlama Geçerlilik Sıklık

Bilgi Tamlık Konu Özlük Ayrıntı İlgililik

Şekil 2 : Verinin bilgiye dönüşümü süreci

Kaynak : Pamela S.Lewis, Stephen H. Goodman ve M. Fandt, Management: Challenges in the 21st Century, St.Paul, Minn, West Publishing Company, 1995 s.601.

2.1. Yazılım Geliştirmede Modeller ve Yaklaşımlar Veri (data)

Enformasyon (information)

Bilgi (knowledge)

Sarf Edilen Çaba

Anlam Derinliği

Bilgelik (wisdom)

Veri İşleme Dönüşümü

Kalite Zamanlılık Tamlık

Çalışma kapsamında proje yönetim süreçleri, Uygulama (yazılım) Geliştirme açısından değerlendirildi. Bilgi teknolojileri kullanılarak belli bir amaç doğrultusunda bir görevi yerine getirmek üzere yazılım uygulamalarının geliştirilmesi proje olarak değerlendirildi.

İkinci dünya savaşından sonra özellikle askeri projelerde çapı ve maliyeti artan yazılım projelerinin geliştiğini görmekteyiz. 1960’ların sonlarında yeni yaklaşımlar ve modellere ihtiyaç duyulmasından dolayı, yazılım projelerinin başarılı olması için bazı özel tekniklerden faydalanılmaya başlanmıştır. Başta Amerika Birleşik Devletleri olmak üzere, örneğin; PERT, CPM ve WATERFALL gibi proje modelleri geliştirilerek uygulamaya konulmuştur.

Yazılım geliştirme süreci sadece kod yazmak şeklinde düşünülmemelidir. Yazılım geliştirme projeleri, ihtiyaç ya da talebin ortaya çıkması aşamasından nihai ürünün teslimine kadar hatta yazım sonrası destek aşaması gibi pek çok aşamadan oluşmaktadır.

Her ne kadar günümüzde çok sayıda yazılım geliştirme metodundan bahsedilse de temelde iki yazılım geliştirme metodu çalışma açısından incelenecektir (Systems Development Life Cycle, en wikipedia, 2010). Bu metotlar, waterfall (şelale) ve spiral metodudur. Şimdi sırayla bu iki metot incelenecektir.

Waterfall Metodu

Bu metot bilinen en eski yazılım geliştirme metodudur. 1970’lerin ortalarında ABD Savunma Departmanı tarafından, maliyetleri düşürme ve yazılım sistemlerinin güvenilirliğini artırma amacıyla geliştirilmiştir

Waterfall metodu aşama temelli bir yöntemdir. Uygulamada bir aşama bitmeden bir sonraki aşamaya geçişi yasaklayan ara hedefler (milestone) vardır. Bu aşamalar kendi içinde tanımlama, analiz, dizayn yapılandırma, test, geçiş ve üretim gibi bölümlere ayrılır.

Şekil 3 : Klasik Waterfall Modeli

Kaynak: Dawson Christian W., Projects in Computing and Information Systems, Addison- Wesley, London, 2009, s.119

2.1.1. ‘b’ Modeli

1988 yılında Birrell ve Ould tarafından waterfall modelindeki yetersizliklerin üstesinden gelebilmek amacıyla geliştirilmiştir. Bakım süreci, sürekli ve açık uçludur. Bakım süreci toplam proje

Kurulum ve Kul. Kabul İhtiyaçların tanımlanması

İhtiyaç Analizi/ Fonksiyonel analiz/ Sistem Analizi

Tasarım A. – Sistem Tasarımı, Modül Tasarımı

... ve Birim Testi

Enteg. ve Sistem Testi Fizibilite (talep)

Analiz

Tasarım

Kodlama Test

Gerçekleştirim Teslim

yaşam süresinin %70 ine denk gelir (msInSwe, cmpe.boun, 2010).

Şekil 4 : 'b' Modeli Süreç İşleyiş Şeması

Kaynak: Birrell N. D., Ould Martyn A., A Practical Handbook for Software Development, Cambridge University Press, Melbourne,1986, s.4

2.1.2. Spiral Modeli

Önceden kullanılan yöntemlere göre waterfall metodu yazılım geliştirme projelerinde çok büyük bir atılım idi. Zaman içerisinde bu metodun uygulanması büyük ölçekli projelerde sorunlara ve maliyet artışlarına neden olmuştur. Güvenilirliğinin de düşmesi ile bu metot zamanla terk edilmiştir.

1988 yılında Barry W. Boehm tarafından geliştirilen spiral model ile bu dezavantajlar ortadan kaldırılmış ve yazılım geliştirme projelerinde tekrarlı metotlar kullanılır hale gelmiştir. Waterfall modelinin aksine tekrarlı metotlar (spiral) önceki safhalara ihtiyaç halinde yeniden dönebilir. Modeli gösteren şekil aşağıdaki gibidir.

Başlangıç

Tanımlama

Tasarım

Üretim

Kabul

Üretim Tasarım

Tanımlama

Başlangıç Evrim

İşletim

Geliştirme rotası

Şekil 5: Spiral Modeli

Kaynak: Barry W. Boehm, Aspiral Model of software Development and Enhancement,IEEE Computer Society Pres, Vol:21, Issue 5, 1988, USA.

2.1.3. Prototip Metodu

Önceki modellere getirilen en büyük eleştirilerden biri, kodlamanın ve dolayısıyla nihai ürüne ait ilk emarelerin projenin çok ileri aşamalarında görülebilir olmasıdır.

2.1.4. RAD - Rapid Application Development (Hızlı Uygulama Geliştirme)

Klasik waterfall metodu zamanla ticari projelerde başarısız hale gelmeye başlamıştır. Zamanla hedefi ilk olarak görsellik ve kullanıcılardan hızlıca geri besleme alabilmek için prototipler üretmek olan ve sonrasında hızlı bir şekilde temel vazifelerini yerine getirerek en fazla faydayı sağlamayı hedefleyen RAD ile değiştirilmeye başlanmıştır.

Günümüzde ticari yazılım uygulamaları geliştirilmesinde en çok tercih edilen araçlar hızlı yazılım geliştirme araçlarıdır (RAD). Bu araçlar ile yazılım geliştirenler, teknik altyapıyı hazırlamak gibi işlemlere zaman ayırmak yerine bunları uygulama geliştirme araçlarında hazır, hızlı ve güvenir biçimde kendilerine sunan RAD uygulama geliştirme araçlarını tercih etmektedir. Böylece yazılım geliştiriciler asıl amaçlarına odaklanmakta ve zamanlarını asıl ihtiyacı karşılamaya daha çok ayırmaktadır. Zira yapılan pek çok işlem aslında tekrarlanmakta ve standart işlemleri gerektirmektedir.

Bu işlemleri hazır ve otomatikleştirilmiş biçimde sunan RAD araçlarının ekonomik katkıları yüksektir.

Ancak bu araçlar genelde üst seviye yazılımları yapma konusunda daha başarılıdır.

RAD, kullanıcı girdilerini de çalışmalara dâhil eden katılımlı uygulama tasarımı (joint application development JAD), prototip hazırlama, CASE teknolojisi, uygulama üretici hazır programlar ve çalışmalarda zaman kazandırıcı araçlar kullanan bir metodolojidir (Dawis, 1998:267)

2.1.5. JAD-Joint Application Development (Katılımlı Uygulama Geliştirme)

Bir RAD uygulaması geliştirmenin kritik başarı faktörlerinden birisi de ihtiyaçların nasıl tanımlandığı ve işlendiği ile ilgilidir. Katılımlı Uygulama Geliştirme (JAD) , yazılımcıların, yöneticilerin ve müşteri gruplarının birlikte çalışarak bir RAD ürün geliştirmesidir.

JAD oturum ya da toplantılarının amacı, kullanıcı ara yüzlerini belirli RAD araçları ile tanımlamaktır. Her bir proje için bir ya da daha fazla JAD oturumu mevcuttur. JAD grupları normalde bir oturum yöneticisi/yönlendiricisi, iki veya daha fazla son kullanıcı temsilcisi, müşteriyi temsilen birisi, bir ya da daha fazla yazılımcı ve birde oturum yazıcısından oluşur. Her bir kişi bütün JAD oturumlarına katılmalıdır. JAD oturumlarında aşağıdakiler yerine getirilir:

 İhtiyaçların netleştirilmesi

 İş akış tanımının geliştirilmesi

 Sistemin veri gruplarının ve işlevlerinin tanımlanması

 Rapor ve ekranların tasarlanması

 Dış sistemlerle olan bağlantı ara yüzlerinin tanımlanması

Yazılım uygulaması talep eden müşteriler her ne kadar ihtiyacı fark edip talepte bulunsalar bile ayrıntılar konusunda fazla bir şey ortaya koyamazlar. Bu nedenle somut ürününün ortaya konması aşamasından sonra daha farklı ihtiyaçlarında karşılanması ve ihtiyacın daha farklı olduğu yönündeki talepler ortaya çıkar. Sayılan bu olumsuzlukları aşmak için müşteri ve kullanıcıyı daha tasarım aşamasında ve belki daha öncesinde sürece dahil ederek beklentilerin daha net biçimde karşılanması ve müşteriyi daha memnun eden bir ürünü ortaya koymak ve yeniden çalışma/üretme gerekliliklerinin de azaltılması sağlanmış olur.

3. PROBLEM CÜMLESİ VE ÇALIŞMANIN MODELİ

Projenin türü göz önüne alınarak projenin gerçekleşmesi için çeşitli aşamalar kullanılır. BT projelerinde Waterfall bu aşamaları; Talep iletimi, Kapsam Hazırlığı, Analize Hazırlık, Yazılım Gerçekleştirme, Test, Kullanıcı Kabulü, Kısıt ve Darboğaz olarak ele almaktadır. Ancak bu aşamaların büyük ölçekli işletmelerde hizmet üretiminde yazılım uygulaması geliştirme sürecinde problemlere neden olduğu düşünülmektedir. Bu nedenden dolayı, basit bir savla talep iletimi, Kapsam Hazırlığı, Analize Hazırlık, Yazılım Gerçekleştirme, Test, Kullanıcı Kabulü, Kısıt ve Darboğaz proje başarımını etkilemektedir cümlesinden hareketle bu problemin çözümünde doğrusal model kullanılarak modelin gerçekten doğru sonuçlar ürettiği sonucuna varılmıştır.

PB= β0 + β1* TI + e (1)

PB = β0 + β1* KH +e (2)

PB = β0 + β1* YG + e (3)

PB = β0 + β1* AH +e (4)

PB = β0 + β1* KH + e (5)

PB = β0 + β1* T + e (6)

PB = β0 + β1* KK + e (7)

PB = β0 + β1* K&D + e (8)

PB = β0 + β1* TI + β2* KH + β3* YG + β4* AH + β5* KH+ β6* T+ β7* KK+ β8* K&D+e (9) (PB= Proje Başarımı, TI=Talep İletimi, KH= Kapsam Hazırlığı, YG= Yazılım

Gerçekleştirme, AH=Analize Hazırlık, T= Test, KK=Kullanıcı Kabulü, K&D= Kısıt Ve Darboğaz, e=hata)

Şekil 6: Çalışmanın Kavramsal Modeli 3.1. Araştırmanın Hipotezleri

H0: Büyük ölçekli firmaların hizmet üretiminde (talep iletimi, kapsam hazırlığı, analize hazırlık, yazılım gerçekleştirme, test, kullanıcı kabulü, kısıt ve darboğaz) proje başarımını etkilememektedir.

H1: Büyük ölçekli firmaların hizmet üretiminde (talep iletimi, kapsam hazırlığı, analize hazırlık, yazılım gerçekleştirme, test, kullanıcı kabulü, kısıt ve darboğaz) proje başarımını etkilemektedir.

4. METODOLOJİ VE UYGULAMA

Çalışmanın Konusu: Bilgi teknolojilerinde veri ve bilgilerin işlenmesi, anlamlandırılması ve yorumlanması gibi pek çok süreçte yazılım teknolojilerinden yararlanılmaktadır.

Çalışmanın Amacı: Proje başarısını etkilediği düşünülen, talep iletimi, Kapsam Hazırlığı, Analize Hazırlık, Yazılım Gerçekleştirme, Test, Kullanıcı Kabulü, Kısıt ve Darboğaz değişkenlerinin hangi oranda etkilediğini belirlemek için, doğrusal model kullanılarak modelin gerçekten doğru sonuçlar üretip üretmediği tespit edilmeye çalışılmıştır.

Proje Başarımı Kapsam Hazırlığı

Yazılım Gerçekleştirme Analize Hazırlık Talep İletimi

Test

Kullanıcı Kabulü

Kısıt ve Darboğaz

Çalışmanın Önemi: Üzerinde çalışılan yazılım geliştirme projeleri günümüzde giderek yaygınlaşmakta ve bu projelere tahsis edilen kaynaklarda paralel biçimde çoğalmaktadır. Bahsi geçen projelerde çoğunlukla yüksek eğitim seviyesinde, nitelikle ve nispeten pahalı iş gücü ve bunun yanında pahalı donanımlar kullanılmakta ve yüksek fırsat maliyetlerine katlanılmaktadır. Ayrıca üçüncü parti bir kuruma ihale edilen yazılım projelerinin maliyetleri de çok yüksek meblağlara erişmektedir. Bütün sayılan bu gerekçeler göz önüne alındığında, başarısızlığa uğrayan bir yazılım geliştirme projesinin ekonomiye ve işletmelere yüklediği zararlar büyük miktarlara ulaşabilmektedir. Başarısızlığa neden olan unsurlardan temel seviyede olan her birinin tespiti ve çözümü ciddi kazançlar sağlanmasına imkân verebilecektir.

Çalışmanın Sınırlılıkları: Çalışma, sağlıklı bir biçimde sonuçlandırılabilmek için;

araştırmacının imkân ve kabiliyetleri ile sınırlı bir çerçevede yürütülmüştür. Bu kapsamda anket çalışması büyük ölçekli bir banka ve bu bankaya hizmet veren büyük ölçekli bir BT firması esas alınarak yürütülmüştür.

Çalışmanın İçeriği: Çalışma, büyük ölçekli yazılım projeleri ve bilgi teknolojisi hizmetleri veren bir işletme esas alınarak, yazılım geliştirme süreçlerinde proje başarımına etki eden unsurların belirlenmesi amacıyla bir anket çalışması yapılmıştır.

Uygulama: Çalışma Türkiye’de faaliyet göstermekte olan büyük ölçekli banka çalışanları ve bu bankaya hizmet veren Bilişim Teknolojisi şirketi çalışanlarının katılımı ile yürütülmüştür. Üzerinde çalışma yapılan banka hizmetlerinin büyük bir kısmını, Bilişim Teknolojisi hizmeti veren şirketten almaktadır.

Örnek Hacmi: Örnekleme hacmini belirlemek için, banka çalışanlarından, rasgele örnekleme yöntemi kullanılarak, 100. Aynı yöntem BT şirketi için kullanılarak 250 çalışan olarak belirlenerek, çalışmada toplam 350 kişilik örneklem hacmi oluşturulmuştur.

4.1. Verilerin Tamamının Bir Arada Değerlendirilmesinde Güvenirlik Analizi Sonuçları

Yazılım geliştirme faaliyetlerinde başarısızlığa neden olan unsurların faktör bazında incelenerek güvenirliğinin ortaya konulması araştırmanın sağlıklı bir araştırma olması açısından önem taşımaktadır.

Bu nedenle, tutarlılığı bozan soruların tespit edilerek analizden çıkarılması gözlem birimlerinin birbirinden bağımsız olduğundan emin olunması, her soru çifti 2 değişkenli normal dağılıma sahip olup olmadığının gösterilmesi, kullanılan ölçeğin toplanabilir ve her sorunun toplam skorla doğrusal ilişki içinde olup olmadığı işlemleri yapılarak aşağıdaki tabloda verilen değerlere ulaşılmıştır.

Tablo 1. Güvenirlik Analizi ALINAN DEĞER Cronbach's

Alpha

N of Items

Grand Mean

F Sig

VERİLERİN HEPSİ BİR ARADA DEĞERLENDİRİLDİĞİNDE

,834 85 2,70 6,102 ,000

A3B1B2B5B6B7B8B9C1C2C5C6C7C 9D2D3D4E1E3E4F3F5F8G16 ATILDIĞINDA

,928 61 2,59 9,829 ,000

A1A2A6A7A8A9B3B4C3C4C8D1D6 E2E6F1F2 ATILDIĞINDA

,951 44 2,54 ,117 ,000

A5D7F6 ATILDIĞINDA ,952 41 2,53 ,505 ,000 A4D5E5F4F7G2 ATILDIĞINDA ,961 35 2,49 ,065 ,000

Cronbach's Alpha değerinin sorular arası korelasyona bağlı uyum değerini yansıttığı göz önüne alınırsa, veriler bir bütün olarak değerlendirildiğinde Cronbach's Alpha değerinin, 834 olduğu görülmektedir. Bu değerin güvenilir olduğu literatürce desteklenmektedir. Ancak İstatistik toplam veri tablosundaki değerlerin, Alfa sütununa analiz aşamalarında bakılarak bazı soruların atılmasıyla güvenirlik derecesinin, 961 e kadar yükseldiği yukarıdaki tablodan görülebilir. Bu durumda ölçeğin yüksek derecede güvenli olduğu görülmektedir. Yukarıdaki tabloda F değerlerine ve Sig değerlerine bakıldığında anlamlı farklılıkların olduğu görülmektedir.

Ayrıca, geliştirdiğimiz ölçekteki soruların cevaplayıcılar tarafından aynı yaklaşımla algılanıp algılanmadığı ve ölçeğimizde yer alan soruların zorluk derecesinin eşit olup olmadığını ortaya koymak için aşağıdaki tabloda Hotelling's T-Squared Testi yapılmıştır. Bu teste göre cevaplayıcılar arasında algılamada anlam farklılığının olduğu görülmektedir.

Tablo 2. Hotelling's T-Squared Test

Hotelling's T-Squared F df1 df2

S Sig

541,977 4,765 42 24

0 000

4.2. Faktör Analizi Değerlendirmesi

Geliştirilen ölçekte sorulan soruların cevaplayıcılar tarafından kaç değişik boyutta algılandığını ve bu algı bozukluğunu ortaya koymak için faktör analizi uygulanmıştır. Çünkü yazılım geliştirme aşamasında (Fizibilite (talep), Analiz, Tasarım, Kodlama, Test, Gerçekleştirme ve Teslim) aşamaları arasında farklı anlayışların olduğuna inanılmaktadır. Bu yüzdende gerekli başarı elde edilememektedir. Bu durumun tespiti için faktör analizi uygulanmıştır. Faktör analizinin amacı çok sayıdaki değişken değerlerini çok az sayıda değişkene indirgeyerek en fazla etkiye sahip olan değişkenleri tespit etmektir. Yazılım geliştirme faaliyetlerinde izlenen adımlar (Fizibilite (talep), Analiz, Tasarım, Kodlama, Test, Gerçekleştirme ve Teslim) sırasında aralarında yüksek korelasyon olan değişkenler setinin bir araya getirilerek genel değişkenlerin (faktörleri) oluşturulması ve böylece başarısızlığa neden olan aşamaların tespit edilmesine çalışılmıştır.

Önce faktör analizi yapabilmenin ön şartı değişkenler arasında belli bir oranda ilişki bulunmasıdır. Aynı zamanda örnekleme yeterliliğinin de değişkenler arası korelasyonların faktör analizine uygunluğunun test edilmesi gerekir. Bu aşamalar sırasıyla, Bartlett's Testi ve Kaiser-Meyer- Olkin teslerini yaparak, gerekli yeterlilikler aşağıdaki tablodan görülmektedir.

Tablo 3. Faktör Analizi

FAKTÖRLER Fizibilite (talep) Analiz Tasarım Kodlama

KMO Meas.of Samp. Ad.

,660 ,578 ,550 ,562

Bartlett's Test of Sph.

App.Chi-Squ

232,199 157,492 70,295 92,375

Df 36 36 36 36

Sig ,000 ,000 ,000 ,000

Tablo 3’ün devamı: Faktör Analizi

Faktör bazında yapılan faktör analiz sonuçları yukarıdaki tabloda verilmiştir. Tablo değerlendirilmeden önce araştırmacıların görüşleri kesin bir ölçüt olmamakla beraber, bazı araştırmacılar 0,50 nin altındaki faktör ağırlığına sahip soruları elerken bazıları da bu sınırı 0,70 olarak belirlemektedir. Bu yaklaşımlar baz alındığında; Fizibilite=78,573, Analiz=62,288, Tasarım= 63,717, Kodlama=53,241, Test=94,608, Gerçekleştirim=57,932 ve Teslim=70,763 olarak ağırlık kazanmaktadır. Yazılım geliştirme faaliyetlerinde, en az başarıya katkı sağlayan faaliyetlerin başında (53,241) ile kodlama birimi gelirken, başarıda en çok etkisi olan faaliyet ise (94,608) ile test birimi aşaması olmuştur.

4.3. Korelasyon Analizi

Korelasyon tablosunda değişkenler arasında anlamlı bir ilişkinin olmadığı, işlemlerin gerçekleştirme aşaması ile test aşaması arasında pozitif yönde zayıf bir ilişki olduğu, analiz ile fizibilite arasında, Kodlama ile fizibilite arasında, gerçekleştirme ile fizibilite ve analiz arasında, teslim ile tasarım, kodlama, test ve gerçekleştirme arasında negatif yönde zayıf ilişkilerin olduğu gözlenmektedir. Ayrıca korelasyon tablosundan da anlaşıldığı üzere değişkenler

FAKTÖRLER Test Gerçekleştirim Teslim

Kaiser-Meyer- Olkin Measure of Sampling Adequacy

,737 ,496 ,798

Bartlett's Test of Sphericity Approx. Chi- Square

114,193 80,780 1900,793

Df 15 28 666

Sig ,000 ,000 ,000

Initial Eigenvalues

% of Variance=X Rotation Sums of Squared Loadings

% of Variance=Y

X Y X Y X Y

Total Variance Explained

47,008 16,581 12,838 10,094 8,086 5,392 94,608

24,729 19,455 13,749 57,932

22,181 17,891 17,862 57,932

38,650 6,163 5,737 5,022 4,694 4,219 3,248 3,030 70,763

15,787 11,382 9,442 8,778 8,631 6,654 6,626 3,463 70,763

arasında anlam farkı olmadığı gözlenmektedir. Bu aşamalar arasındaki zayıflık, Yazılım geliştirme faaliyetlerinde başarısızlığa neden olmaktadır.

Tablo 4. Korelasyon

(Fizibilite (talep)

Analiz Tasarım Kodlama Test Gerçek- leştirme

Teslim

Fizibilite (talep)

r 1

Sig.

Analiz,

r -,010 1

Sig. ,930

Tasarım, r ,014 -,003 1

Sig. ,904 ,982

Kodlama, r -,094 ,143 107 1

Sig. ,411 ,213 353

Test r ,030 053 164 201 1

Sig. ,794 650 152 077

Gerçek- leştirme

r -,011 ,177 035 105 299^** 1

Sig. ,925 124 762 365 008

Teslim r ,039 074 ,180 ,084 ,140 -,011 1

Sig. ,734 522 112 467 223 ,926

**. Correlation is significant at the 0.01 level (2-tailed).N=79

4.4 Regresyon Analizi

Tablo 5. Model Summary^b

Model R R

Square

Adjusted R Square

Std.

Error of the Estimate

Change Statistics

Durbin- Watson

R Square Change Change df1 df2 Sig. F

Change

1 187^a 35 -0,064 0,744 0,035 351 7 8 0,927 1,784

Tablo 6. ANOVA^b

Model Sum of

Squares df Mean Square F Sig.

1

Regression 1,361 7 0,194 0,351 ,927^a

Residual 37,626 68 0,553

Total 38,987 75

Yukarıdaki anova tablosuna bakıldığında sig değeri, 927 ve F değeri, 351 olması modelin bir bütün olarak anlamlı olmadığını göstermektedir.

Tablo 7. Coefficients^a Model

Unstandardized Coefficients Standardized

Coefficients t Sig.

B Std. Error Beta

1

(Constant) 4,105 0,617 6,653 0

Analist, yazılımcı, test uzmanı gibi kaynakların yetersizliği

0,073 0,08 0,113 0,915 0,363

Kullanıcı kabul testi yapacak olan kişilere uygun test şartları sağlanıyor

0,021 0,086 -0,032 -0,247 0,806

Yazılım bittiğinde yapılan testler için yeterli süre tanınıyor

0,018 0,091 -0,026 -0,196 0,845

Yazılım yapılması süreci ihtiyaçlara uygun bir prosedüre sahip

0,078 0,116 0,084 0,677 0,5

Kapsam dökümanları, analiz için yeteri kadar ayrıntı içeriyor

0,027 0,104 0,032 0,261 0,795

Talepler kapsam hazırlığı için yeterli bilgi içeriyor

0,095 0,098 -0,121 -0,972 0,334

Müşterinin ifade ettiği talep BT tarafından net biçimde anlaşılıyor

0,057 0,089 -0,077 -0,646 0,52

Yukarıdaki tabloda modelin tahmini sonucu elde edilen parametre değerleri ve bunlara ilişkin t değerleri görülmektedir. Parametrelere ait t istatistik değerlerinden modele dahil edilen her bir değişkenin ayrı ayrı anlamlı olmadığı görülmektedir. t istatistiğinden anlaşıldığı üzere değişkenlerin ayrı ayrı anlamlı olup olmadığı ölçülmüş, ayrı ayrı olarak da anlamlı olmadığı görülmüştür. Yukarıdaki tabloda sabit terim 4,105 olarak bulunmuştur. Bunun anlamı yukarıda analiz edilen 7 değişkenin değeri sıfır bile olsa projenin 4,105 lik kısmı başarılmaktadır.

Katsayılar tablosundaki B sütununda yer alan negatif değerli değişkenler proje başarımını ters yönde etkilerken, diğer 3 değişken değeri proje başarımına küçük oranlarda katkı sağlamaktadır.

5. SONUÇ VE ÖNERİLER

Günümüzde işletmelerin ölçekleri ne olursa olsun bir şekilde bilgiye ve bilgi teknolojilerine ihtiyaç duymaktadır. Bu ihtiyacın karşılanması, bazen doğrudan ve başka bir çaba gerektirmeksizin çözümü edinip kullanma şeklinde olmakta çoğu zaman ise bir proje ile gerçekleştirilmektedir. İş hayatında pek çok aşamada olduğu gibi proje yürütme aşamalarında da sorunlar yaşanmaktadır. Bu sorunlar ile BT projelerinde daha yüksek bir oranla karşılaşılmaktadır. Bilginin ve bilgi teknolojilerinin hayatın her aşamasında her geçen gün daha fazla yer aldığı günümüz ortamında bu projelerde sorunlara ve darboğazlara yol açan unsurlar, günümüze kadar yaşanan başarısız deneyimlerden elde edilen tecrübe ile azalacağına bilakis artmaktadır.

Çalışmada bilgi, bilgi teknolojisi ve proje yönetim kavramları ve proje yönetimi özelinde yazılım projelerinin yaşam döngüsü ele alınmıştır. Son kısımda ise yapılan uygulamanın sonuçları verilmiş ve önemli görülen hususlar değerlendirilmiştir.

Büyük ölçekli firmaların hizmet üretiminde yazılım geliştirme faaliyetlerinin

gerçekleştirilmesinde kullanılan talep iletimi, kapsam hazırlığı, analize hazırlık, yazılım

gerçekleştirme, test, kullanıcı kabulü, kısıt ve darboğaz proje başarımını ters yönde

etkilediği analizlerde görüldü.

Büyük ölçekli firmaların hizmet üretiminde talep iletimi, kapsam hazırlığı, analize hazırlık, yazılım gerçekleştirme test, kullanıcı kabulü, kısıt ve darboğaz gibi aşamaların gözden geçirilerek projenin başarısızlığına sebep olan durumların ortadan kaldırılması proje yöneticilerinin üzerinde durması gereken en önemli husus olmalıdır.

Çalışmaya göre, proje süreçlerinde görev alan kişilerin değişmeden korunması sorunların önlenmesinde bir unsur olarak öne çıkabilir. Ayrıca bir başka bulguya göre müşteri birimini temsil eden kişilerin başta analiz çalışmaları olmak üzere, süreçte daha etkin rol almasının faydalı olabileceği düşünülebilir. Bu durumda JAD yazılım geliştirme modelinin kullanımının değerlendirilmesi faydalı olacaktır.

Planlama konusunda da bazı sorunlar yaşandığı tespit edilmiş olup, kişilere işlerini planlaması ve planlarını gerçekleştirmesi konularında gerekli yönlendirme desteğin verilmesinin süreçlerin işleyişine olumlu katkı yapacağı düşünülebilir. Motivasyonu artırmak için ödül/ceza sisteminin yetersizliği ve inisiyatif kullanamama önemli bir araç olarak kullanılabilir.

Kişilere yaptıkları işin sorumluluğunu alabilme, gerekli yerlerde inisiyatif kullanabilme, kolaylaştırma yönünde gerekli ortam hazırlanabilmeli ve kişiler bu yönde desteklenebilmelidir.

Çalışma, araştırmacının imkanları doğrultusunda ampirik düzeyde yürütülmüş olup sonuçlar istatistik ilişki testleri uygulanmış ve sonuç karşılaştırma olarak değerlendirilmiştir.

KAYNAKLAR

BARRY, W. Boehm, (1988), Aspiral Model of software Development and Enhancement,IEEE Computer Society Pres, Vol:21, Issue 5, USA.

BEDÜK, Aykut, (2002), “Bilgi Çağı, Örgütlerde bilginin Önemi Ve Bilgi Teknolojilerinin Örgütlere Sundukları Değişim Ve Olanaklar” ,I.Ulusal Bilgi, ekonomi ve Yönetim Kongresi Bildiriler Kitabı, Hereke, Kocaeli, s.696 BIRRELL, N., OULD, D and MARTYN, A (1986), ‘‘A Practical Handbook for Software Development’’, Cambridge University Press, Melbourne, s.4

CELEP Cevat ve ÇETİN Buket (2003), ‘‘Bilgi Yönetimi’’, Anı Yayncılık, Ankara, s.9

DAWİS William S (1998), ‘‘ The Information System Consultant’s Handbook(System Analisys and Design), CRC Pres, Florida, s.267

DAWSON Christian W..(2009) , ‘‘Projects in Computing and Information Systems’’, Addison-Wesley, London, s.119

DEMİRCİ, Ahmet Emre (2001), ‘‘İşletmelerin Yeniden Yapılanma Faaliyetlerinde Bilgi Teknolojilerinin Kullanılması ve

MİTAŞ A.Ş. de Bir Uygulama (Yüksek Lisans Tezi), Eskişehir.

GÖKÇEN Hadi (2007), ‘‘ Yönetim Bilgi Sistemleri’’, Palme Yayıncılık, Ankara, s.4.

KAZAN, H., ERGÜLEN, A. ve KAPLAN, M (2005), ‘‘Bilişim Teknolojilerinin üretim sürecine katkılarının Ampirik Analizi: Adana İlinde Bir Araştırma’’, 1. Yerel Ekonomiler Kongresi, Karaman, 401-416.

ÖĞÜT, Sertaç (2010), ‘‘ Veri Madenciliği Kavramı ve Gelişimi’’

www.sertacogut.com/blog/wp- ontent/uploads/2009/03 acces date: 06.01.2010

PAMELA, S. Lewis, STEPHEN H. Goodman and FANDT, M.

(1995)‘‘ Management: Challenges in the 21st Century’’

St.Paul, Minn, West Publishing Company, s.601.

SPITZER Dean R. (2007) ‘‘ Transforming Performance Measurement: Rethinking

the Way We Measure and Drive’’, Newyork, AMACOM, s.106

KAYA, Türksel (1996) ‘‘Bilgi Teknolojileri ve Örgütsel Değişim’’, Türkiye ve Ortadoğu Amme İdaresi Enstitüsü Yayını, 1.Baskı, Ankara, s14.

http://www.projectsmart.co.uk/docs/chaos-report.pdf acces date:

15.01.2010

http://members.cox.net/johnsuzuki/softfail.htm acces date:

12.01.2010

http://host.nigde.edu.tr/uludogan/proje_tanitimi.htm, acces date:

05.01.2010

http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle acces date:10.01.2010

http://www.cmpe.boun.edu.tr/graduate/msInSwe/courses/swe523/fal l2004/ppt/06.p pt acces date: 13.01.2010