Sistem Geliştirme Yaşam Döngüsü Yaklaşımına Alternatif Yaklaşımların Özellikleri, Avantaj ve Dezavantajları ALTERNATİF YAKLAŞIMLAR Klasik yaklaşım olarak kabul edilen Sistem Geliştirme Yaşam Döngüsü Yaklaşımının çok zaman alması, yüksek maliyetlere yol açması, esnek olmaması gibi dezavantajlarından dolayı yeni metodolojiler ve alternatif geliştirme süreçleri ortaya çıkmıştır. Prototipleme Yaklaşımı Son Kullanıcı Geliştirmesi Yaklaşımı Dış Kaynak Kullanımı Yaklaşımı Uygulama Yazılım Paketi ile Sistem Geliştirme HİBRİT YAKLAŞIMLAR PROTOTİPLEME YAKLAŞIMI Klasik sistem geliştirme yaşam döngüsünün bir parçası olarak bir prototipin kullanılması Klasik yapıdaki yaklaşımın bir uygulama paketi satın alınırken uygulanması Klasik sistem geliştirme yaşam döngüsü yaklaşımına bir son kullanıcı tarafından geliştirilmiş komponentin ilave edilmesi Prototipleme, bilgi sistemi kurma çalışmasına belirli bir soruna yönelik bir program ile başlamaktır. Temel olarak, prototip, sistem kullanıcılarına, sistemin tamamlanmış halinin ön görünümünü sağlamaktadır. İşletme bazında düşünülecek olursa, belli bir bölüm seçilmekte ve bu bölüme özgü sorunu çözmek üzere bilgi sistemi oluşturulmaktadır. Bu sistem sadece o bölüme hizmet vermektedir. Daha sonra, ihtiyaç duyulduğunda diğer bölümlerde de benzeri programlar oluşturulmaya başlanıp, bu programın parçalarının bir araya getirilmesi veya ilk yazılan programın geliştirilmesi ile istenilen bilgi sistemine ulaşılabilmektedir. Yrd.Doç.Dr. Ceyda Şen- Bilişim Sistemleri 1
PROTOTİPLEME YAKLAŞIMININ ADIMLARI Operasyonel prototip Evet Kullanıcıların temel ihtiyaçlarının belirlenmesi Çalışan bir prototipin geliştirilmesi Prototipin kullanılması Kullanıcı tatmin oldu mu? Hayır Prototipin tekrar gözden geçirilmesi Adım 1: Başlama Adım 2: Geliştirme Adım 3: Yerleştirme Adım 4: Bakım ve gözden geçirme PROTOTİPLEME METODUNUN GÜÇLÜ VE ZAYIF YANLARI BAġLICA ÜSTÜNLÜKLERĠ: Kullanıcıyı Alıştırma: Prototipleme yaklaşımının önde gelen amacı, kullanıcı ihtiyaçlarını büyük ölçüde karşılayan sistemler geliştirmektir. Hızlı Geliştirme Zamanı: Klasik yaklaşımda, anlamlı sonuçlara ulaşmak ve sistemi faaliyete geçirmek için yıllar gerekebilirken, bu yaklaşımda anlamlı sonuçlar elde edebilmek için, birkaç hafta veya ay yeterli olmaktadır. Daha Az Hata: Prototipleme yaklaşımı, hataların önceden belirlenmesini sağlamaktadır. Klasik yaklaşımla ise, hatalar belki ancak yıllar süren geliştirme sürecinin sonunda belirlenebilmektedir. Daha Çok Değişim Fırsatı: Prototipleme ile, yöneticiler, geliştirilmekte olan her bir alt sistem veya komponentin çıktıları görebilmekte ve bu çıktılarla çalışabilmektedir. Bu sayede, yöneticiler geliştirme süreci içerisinde değişim önerilerinde bulunabilmektedir. PROTOTİPLEME METODUNUN GÜÇLÜ VE ZAYIF YANLARI SON KULLANICI GELİŞTİRMESİ YAKLAŞIMI BAŞLICA SAKINCALARI: Sistem Geliştiricilerle, Yönetim Arasındaki Ortaklık İhtiyacı: Yönetimin aktif olarak projeye katılması, bazı yöneticiler tarafından ayrılmak istenmeyen bir zamana ihtiyaç duymaktadır. Toplam Geliştirme Maliyetinin Yüksek Olabilmesi: Eğer yöneticinin sürekli olarak sistemde değişiklik ihtiyacı söz konusu ise bu dezavantaj ortaya çıkmaktadır. Yeni veya Geliştirilmiş Sistemin Bilgisayar Kaynaklarını Etkin Olarak Kullanamayabilmesi: Prototipleme yaklaşımında, kullanıcı ihtiyaçlarına çok fazla önem verilirken, çeşitli komponentlerin kullanımına daha az önem verilmektedir. Sistemlerin daha hızlı ve ucuz hale gelmesiyle, bu donanım limitleri daha önemli bir hal almaktadır. Bu yaklaşıma göre, son kullanıcılar, profesyonel sistem analisti veya programcı desteği almadan sistem geliştirme araçlarını kullanarak, veri girişlerini yaparak, rapor oluşturarak, kendi bilgi sistemlerini geliştirmektedir. Son kullanıcı geliştirmesi yaklaşımı, sistem geliştirmeye kullanıcılar açısından bakmakta ve böylece yukarıdan aşağıya değil de, aşağıdan yukarıya doğru ihtiyaçların karşılanması sağlanmaktadır. Sistemin son kullanıcılar tarafından geliştirilmesi yaklaşımı, genellikle klasik sistem geliştirme yaşam döngüsü uygulamalarından çok daha hızlıdır. Yrd.Doç.Dr. Ceyda Şen- Bilişim Sistemleri 2
METODUN GÜÇLÜ YANLARI METODUN ZAYIF YANLARI Son kullanıcı geliştirmesi yaklaşımı, bir yandan, programcılara duyulan ihtiyacı azaltırken, diğer yandan organizasyon içerisindeki uygulamalara yabancı olan teknik elemanların ihtiyaçları belirleme güçlüğünü ortadan kaldırmaktadır. Sistemin geliştirilmesi ile, yerleştirilmesi aşamaları arasındaki bekleme zamanı elemine edilmektedir. Sistemin durumu ve ne gibi değişimlere gereksinim duyduğu karmaşık bir sistem analizi çalışması yerine, kullanıcı ihtiyaçları analiz edilerek belirlenebilmektedir. Temel amacı ihtiyaçların belirlenmesi olan sistem analizi aşaması, teknik uzmanlara gereksinim duyulmaksızın, kullanıcıların analiz edilmesiyle gerçekleştirilebilmektedir. Kullanıcıların sistemi kendilerinin tasarlayıp geliştireceklerini hissetmeleri motivasyonu arttırmakta, daha etkili bir sistemin geliştirilmesi sağlanabilmektedir. Kullanılan Geliştirme Araçları: Kullanıcıların sürdürmesi gereken başka işleri de bulunmaktayken, geliştirme araçlarını öğrenmek ve kendi uygulamalarını geliştirmek için çok az zamanları olmaktadır. Sistemin Teknik Kalitesi: Son kullanıcılar tarafından kurulan sistemler genellikle, profesyoneller tarafından geliştirilmiş olan sistemlerden daha kötü tasarlanmış ve daha az yapısal olmaktadır. Bu sistemler, kullanıcıların hata giderme konusunda nispeten daha deneyimsiz olması nedeniyle, hatalara daha yatkın sistemlerdir. Uzun Vadeli Bakım İhtiyacı: Son kullanıcı uygulamalarının karmaşık hale geldiği ve birçok kullanıcının dahil olduğu durumlarda, uzun vadeli bakım ihtiyacı ortaya çıkmaktadır. Son kullanıcılar, uzun vadeli bakımı asıl görev sorumluluklarını engelleyen bir faaliyet olarak görebilmektedir. DIŞ KAYNAK KULLANIMI UYGULAMA YAZILIM PAKETİ İLE SİSTEM GELİŞTİRME YAŞAM DÖNGÜSÜ Bilgi sistemlerini kurarken ve işletirken kendi içerisindeki kaynakları kullanmak istemeyen bir işletme, bu hizmetlerin sağlanması için uzman bir dış şirketi kiralayabilmektedir. Dış kaynak kullanımından en iyi şekilde yararlanılabilecek durumlar: Bir bilgi sistemi uygulaması veya uygulama dizisi ile rekabet ortamında sivrilme fırsatının düşük olduğu durumlar, Bilgi sistemi hizmetinin sürekliliğinin çok önemli olmadığı durumlar Organizasyonun mevcut bilgi sisteminin, sınırlı kapasiteli, etkisiz veya teknik olarak ikinci derece olduğu durumlar SĠSTEM ANALĠZĠ -Problemi belirleme -Kullanıcı ihtiyaçlarını belirleme -Alternatif çözümleri belirleme -Yazılım satıcılarını araģtırma -Yazılım paketlerini değerlendirme -Yazılım paketini seçme SĠSTEM TASARIMI PROGRAMLAMA ve TEST ETME FAALĠYETE GEÇĠRME ve BAKIM Yrd.Doç.Dr. Ceyda Şen- Bilişim Sistemleri 3
Teknolojiye Sahip Olma Maliyeti Total Cost of Ownership (TCO) Teknoloji kaynaklarını işletmek için harcanacaklar: ilk yatırım donanım ve yazılım maliyeti güncelleme maliyeti teknik destek eğitim Çeşitli uygulamalar için mevcut olan yazılım paketi alternatiflerinin çokluğu Yazılım paketlerinin değerlendirilmesi için endüstriyel standartların bulunmaması Yazılım paketlerinin performanslarındaki farklılıklar Doğru seçimi yapmak için gerekli olan bilgi birikimi ve tecrübenin eksikliği Müşteri ihtiyaçlarını en iyi şekilde karşılayacak yazılım paketinin değerlendirilmesi ve seçiminde sistematik bir yaklaşım ihtiyacını doğurmaktadır. YAZILIM SEÇİMİ PROBLEMLERİNİN KARMAŞIKLIĞI ÇOK KRİTERLİ BİR ORTAMDA GRUP KARARI ALMA AMAÇ Uygun Yazılım Seçimi KRĠTERLER Maliyet Kullanım Fonksiyonellik Güvenilirlik... ALTERNATĠFLER Ürün 1 Ürün 2 Ürün 3... En iyi yazılım paketinin seçimi kararı, çok kriterli bir ortamda alınan grup kararıdır. Yazılım seçimine grup yaklaşımı, alınan kararın kalitesini ve etkinliğini arttırmaktadır. Yönetimsel ve teknik kriterler olmak üzere çok sayıda kriterin ve çok sayıda karar vericinin katılımı sebebiyle alınacak karar çok boyutlu olmakta ve çözüm sürecinin karmaşıklığı artmaktadır. Bu nedenle bu tarz yapılandırılmamış ve karmaşık seçim problemlerinde yeni yaklaşımlara ihtiyaç duyulmaktadır. Yrd.Doç.Dr. Ceyda Şen- Bilişim Sistemleri 4
KURUMSAL YAZILIM PAKETİ SEÇİMİNDEKİ ANA PROBLEMLER KURUMSAL UYGULAMA YAZILIM PAKETİ SEÇİMİNDEKİ ANA ADIMLAR Doğru seçimi yapmak için gerekli olan bilgi birikimi ve tecrübenin eksikliği, İyi tanımlanmış, sistematik ve tekrarlanabilir bir sürecin eksikliği, Uygulama ihtiyaçlarını göz önünde bulundurmamak, kriterlerinin belirlenmesinde yaşanan güçlükler, Karar verme aşamasında yanlış yaklaşımın kullanımı. Seçim sürecinde oluşturulan proje takımının görevlerinin açık bir şekilde tanımlanması, kriterlerinin hiyerarşik ve detaylı tanımının yapılması, Alternatiflerin maliyet ve değer açısından birbiriyle karşılaştırılması için bir model kullanılması, sonuçlarının analizi ve özetinde uygun karar verme metotlarının kullanılması. KURUMSAL UYGULAMA YAZILIM PAKETİ SEÇİM SÜRECİ FONKSİYONEL DEĞERLENDİRME KRİTERLERİ DıĢ Kaynaklar Ġç Kaynaklar AraĢtırma Eleme Seçilen Yazılım Spesifik ve Fonksiyonel Ġhtiyaçlar Kriter Tanımla rı Kriterleri Verileri Tasarım Kısıtları Kriterlerinin Tanımlanması Sonuçların Analizi Proje Planı Organizasyonel Karakteristikler Maliyet Modelleri Değer Tahmin Modelleri Bu kriter tipi, yazılım alternatifinin hangi fonksiyonları yerine getirdiği ile ilgilenmektedir. Kısaca Sistem neyi yapar? sorusunun cevabıdır. Fonksiyonel ihtiyaçların değerlendirici tarafından tam ve tutarlı bir şekilde belirlenmesi gerekmektedir. Yani sistem kullanıcılarının ihtiyacı olan tüm hizmetler tam olarak tanımlanmalı ve tanımlanan ihtiyaçlar kendi içerisinde tutarlı olmalıdır. Bu kriter tipi, uygulamadan uygulamaya değişmektedir. Fonksiyonel kriterler yerine sistem fonksiyonları, sistem gereksinimleri, fonksiyonel ihtiyaçlar gibi ifadeler de kullanılmaktadır. Yrd.Doç.Dr. Ceyda Şen- Bilişim Sistemleri 5
FONKSİYONEL OLMAYAN DEĞERLENDİRME KRİTERLERİ Bu kriter tipi ise, yazılım alternatifinin fonksiyonları hangi kısıtlarla nasıl yerine getirdiği ile ilgilenmektedir. Ürünün genel kalitesi olarak da tanımlanmaktadır. Fonksiyonel olmayan kriterler, belirlenmesi, ölçülmesi ve test edilmesi güç olan kriterlerdir. Fonksiyonel olmayan kriterler, iki sınıfta incelenebilmektedir: Ürünle ilgili kalite kriterleri ve maliyet, satıcı özellikleri gibi organizasyonel kriterler. ISO/IEC 9126 standardı yazılım ürünü ile ilgili kalite kriterlerini tanımlamıştır. Bu değerlendirme kriterleri uygulamadan uygulamaya değişmemektedir. Önemli olan nokta, uygulamalarda dikkate alınacak olanlarının seçimidir. Fonksiyonel olmayan kriterler yerine, fonksiyonel olmayan ihtiyaçlar, sistem özellikleri, kalite karakteristikleri, kalitatif ihtiyaçlar gibi ifadeler de kullanılmaktadır. DEĞERLENDİRME KRİTERLERİNİN ÖLÇÜMÜ Yazılım alternatiflerinin fonksiyonel ve fonksiyonel olmayan değerlendirme kriterlerini karşılama derecesi kalitatif veya kantitatif yollarla ölçülmektedir. Kantitatif ölçümler, sayılar veya sembollerle objektif olarak atanabilen ölçümlerdir. (Örnek: Bir objenin uzunluk ölçüsü) Kalitatif ölçümler ise, subjektif olarak atanabilen ikili ilişkiler, karşılaştırmalar ve tercihlerdir. (Örnek: uygulamanın amacına ve kapsamına göre kısa bir obje ile uzun bir obje arasındaki tercih) KANTİTATİF ÖLÇÜM ÖRNEKLERİ Fiyat- dolar cinsinden Eğitim/Destek- satıcının ziyaret sıklığı, eğitim vereceği gün sayısı Güvenilirlik- bir zaman aralığında sistemin hatasız çalışma olasılığı Performans- birim zamandaki işlem sayısı Uygunluk- sistemi test ederek gerçekleştirdiği fonksiyon sayısını belirle (B), doğru uygulanan fonksiyon sayısını belirle (A), A/B değeri uygunluk ölçümü Satıcı riski- satıcıya B kadar soru sor, çözülenleri veya cevaplananları say (A), A/B ile satıcı riski belirlenir. DEĞERLENDĠRME SKALALARI İkili karşılaştırmalar, kalitatif değerlendirmeler bir skala kullanılarak sayısallaştırılabilmektedir. Böyle bir ölçek, karar verici için mümkün olan dilsel seçeneklerin kümesi ve bu seçeneklerin ağırlıkları arasında birebir eşleşme ile oluşturulmaktadır. Bulanık karar vermede ise, atanan ağırlıklar bulanık sayılarla ifade edilmektedir. Bu ölçeklerden en çok kullanılan iki tanesi, Saaty tarafından geliştirilen lineer skala ve üssel skaladır. Yrd.Doç.Dr. Ceyda Şen- Bilişim Sistemleri 6