İSTANBUL TEKNİK ÜNİVERSİTESİ FEN BİLİMLERİ ENSTİTÜSÜ
YAŞAM DÖNGÜSÜ YÖNETİMİ KAVRAMININ YAZILIM ÜRÜNLERİNE UYGULANMASI
YÜKSEK LİSANS TEZİ Elif ERSOY
Anabilim Dalı : İşletme Mühendisliği Programı : İşletme Mühendisliği
İSTANBUL TEKNİK ÜNİVERSİTESİ FEN BİLİMLERİ ENSTİTÜSÜ
YAŞAM DÖNGÜSÜ YÖNETİMİ KAVRAMININ YAZILIM ÜRÜNLERİNE UYGULANMASI
YÜKSEK LİSANS TEZİ Elif ERSOY
507981005
Tezin Enstitüye Verildiği Tarih : 30 Eylül 2002 Tezin Savunulduğu Tarih : 23 Ekim 2002
Tez Danışmanı : Öğr.Gör.Dr. Halefşan SÜMEN Diğer Jüri Üyeleri : Prof.Dr. Nimet Uray
Doç.Dr. Cengiz KAHRAMAN
ÖNSÖZ
Yaşam döngüsü yönetimi kavramının yazılımlara uygulanmasının incelendiği bu çalışmanın; her aşamasında desteğini esirgemeyen eşime ve aileme, projenin oluşturulmasına ve hızla yürütülmesine katkılarından dolayı başta şirketin satınalma müdürü Sn. Nükhet Yücelay olmak üzere tüm çalışma arkadaşlarıma ve son olarak da tüm konularda göstermiş olduğu yardımlardan dolayı değerli hocam Öğr.Gör.Dr. Halefşan Sümen’e teşekkürü bir borç bilmekteyim.
İÇİNDEKİLER KISALTMALAR iv TABLO LİSTESİ v ŞEKİL LİSTESİ vi ÖZET vii SUMMARY viii 1. GİRİŞ 1
1.1. Giriş, Çalışmanın Amacı ve Yöntemi 1
2. YAŞAM DÖNGÜSÜ YÖNETİMİ KAVRAMI VE YAZILIMLAR 2
2.1. Yaşam Döngüsünün Aşamaları 4
2.1.1. İhtiyaçlar 4
2.1.2. Tanımlama: Gereksinimlerin Belirlenmesi 5
2.1.3. Tasarım 9
2.1.4. Gerçekleştirme 13
2.1.5. Uygulama 16
2.1.6. Bakım ve Yenileme 20
2.2. Yaşam Döngüsü Modelleri 25
2.2.1. Yap ve düzelt modeli 25
2.2.2. Çağlayan modeli 26
2.2.3. Ön örnek geliştirme modeli 29
2.2.4. Sarmal model 31
2.2.5. Çoğalan model 32
2.2.6. RAD-Hızlı Uygulama Geliştirme 33
3. YAZILIM YAŞAM DÖNGÜSÜ KAVRAMININ EKS ECZACIBAŞI KARO SERAMİK SAN. VE TİC. A.Ş. UYGULAMASI 39
4. SONUÇ 60
KAYNAKLAR 64
EKLER 67
KISALTMALAR
YDY : Yaşam Döngüsü Yönetimi
YYD : Yazılım Yaşam Döngüsü
SGB : Sistem Gereksinimlerinin Belirlenmesi RAD : Hızlı Uygulama Geliştirme
TABLO LİSTESİ
Sayfa No
Tablo 2.1. Yaygın belgeleme araçları...……… 11 Tablo 2.2. Bakım etkinlikleri...……….. 21 Tablo 2.3. Hızlı uygulama geliştirmenin avantajları-dezavantajları... 37
ŞEKİL LİSTESİ Sayfa No Şekil 2.1 Şekil 2.2 Şekil 2.3 Şekil 2.4 Şekil 2.5 Şekil 2.6 Şekil 2.7 Şekil 2.8 Şekil 2.9 Şekil 3.1 Şekil 3.2 Şekil 3.3 Şekil 3.4 Şekil 3.5 Şekil 3.6 Şekil 3.7 Şekil 3.8
: Yazılım yaşam döngüsünün altı aşaması... : Veri akış çizelgesi... : Sipariş giriş sistemi veri akış çizelgesi... : Yap-Düzelt modeli... : Çağlayan modeli ... : Ön örnek geliştirme modeli... : Sarmal model... : Hızlı uygulama geliştirme unsurları ... : Hızlı uygulama geliştirme fazları ve kullanılan bazı metodlar... : Prismde sipariş oluşturma ekranı... : Sipariş isteği ekranı- Kayıt görünümü ... : Sipariş isteği ekranı- Liste görünümü ... : Sipariş isteklerini siparişe çevirme ekranı... : Siparişler ekranı- Liste görünümü ... : Sipariş isteği ekranı- Kayıt görünümü ... : Siparişler ekranı- Lojistik... : Siparişler ekranı- Proforma...
3 12 13 26 27 30 32 34 36 42 51 52 53 54 55 56 57
YAŞAM DÖNGÜSÜ YÖNETİMİ KAVRAMININ YAZILIM ÜRÜNLERİNE UYGULANMASI
ÖZET
Herhangi bir ürünün, yatırımın veya servisin canlı organizmalar gibi varlıklarını sürdürmelerinden hareketle yaşam döngüsü kavramı ortaya çıkmıştır. Maliyetlerin takibi ve kontrolünün yapılabilmesi için döngünün yönetilmesi gerekmektedir. Yazılımlara gelince, kullanılmakta ve geliştirilmekte olan her sistem için bir yazılım yaşam döngüsü söz konusudur ve bu döngünün de iyi yönetilmesi şarttır.
Yaşam döngüsünde genel kabul görmüş altı aşama vardır. Bunlar; ihtiyaçlar, tanımlama, tasarım, gerçekleştirme, uygulama ve bakım aşamalarıdır. Bu genel çerçeve içinde, bilgi sistemlerinin yaşam döngüsü modellerinden de bahsedilmelidir. Bu yaklaşımların ilki ve en yaygın biçimde kullanılanı, yaşam döngüsündeki aşamaların birbiri ardına sıralandığı, birinin çıktılarının bir sonraki adımın girdilerini oluşturduğu anlayışına dayanan Çağlayan Modeli’dir. Bu modelin gerçek yaşamda ortaya çıkardığı birtakım problemleri ortadan kaldırmak için öne sürülen Ön-Örnek Geliştirme Modeli, çağlayan modelinin bir türevi olan Artışlı Model ve yazılım mühendisliği sürecini her türlü uygulamayı içerecek şekilde açıklayan Sarmal Model, Hızlı Uygulama Geliştirme ve Yap ve Düzelt Modeli yaklaşımlardan belli başlılarıdır. Tüm modellerin kendi içinde zayıf ve kuvvetli yanları bulunmaktadır. Önemli olan bir uygulamada şirket kültürüne en uygun olanı benimseyebilmektir.
Uygulamaya konu olan şirkette kullanılan yazılımın yaşam döngüsünü tamamlamak üzere olduğu görülmüş, bakım ve yenileme ile ömrünün uzatılamayacağına karar verilmiştir. Bu çalışmada, yeni bir yazılımın şirket bünyesinde oluşturulması, ihtiyaçların belirlenmesi aşamasından itibaren tasarım, gerçekleştirme ve uygulama aşamaları adım adım anlatılmaktadır. Yeni yazılıma ilişkin ekranlara da yer verilerek, bu ekranların özellikleri üzerinde durulmuştur. Son olarak yeni yazılımın başarısı mevcut yazılımla karşılaştırılmalı olarak değerlendirilmiştir.
AN APPLICATION OF LIFE CYCLE MANAGEMENT ON SOFTWARE PRODUCTS
SUMMARY
Life cycle concept has emerged from the idea that all products, investments and services survives like living organisms. To track and control costs, it is necessary to manage the cycle. As for software products, those are in use and in development, has a life cycle which should be carefully managed.
There are six generally accepted phases of life cycle. They are requirements, defining, design, development, application and maintenance phases. The life cycle models of information systems should be considered in this context. First and most widely used life cycle model is the waterfall model. The waterfall model has consequently ordered phases and each phase’s output forms the input of following phase. The prototyping model was intruced to adress some problems in waterfall model. The incremental model which is derived from waterfall model, the spiral model, rapid application development and build and fix model are also widely accepted life cycle models. All models has their own weaknesses and strength. The key is to choose the model which fits the organizational culture.
In the company, which is the subject of this thesis’ last part, had found out that maintenance couldn’t extend the current software’s economical life. In this thesis the development of a new software product was examined, the life cycle of the software product was throughly observed from requirements analysis to application phase. Also the final product was explained by examining various screens. And lastly the new product’s performance was benchmarked with the previous one.
1. GİRİŞ
1.1. ÇALIŞMANIN AMACI VE YÖNTEMİ
Yaşam döngüsü kavramı, herhangi bir ürünün, yatırımın veya servisin tıpkı canlı organizmalar gibi varlıklarını sürdürdüğü gerçeğinden hareketle ortaya çıkmıştır. İçerdikleri analiz, başlangıç, giriş, geliştirme, olgunluk, iniş ve geri çekilme adımlarını yazılımlara da uyarlamak mümkündür.
Yaşam döngüsü kavramının yazılım ürünlerine uygulanması başlıklı bu çalışmanın ikinci bölümünde yaşam döngüsünün aşamaları teker teker ayrıntıları ile anlatılmıştır. Bu bölümde ayrıca, yap ve düzelt, çağlayan, ön örnek geliştirme, sarmal ve çoğalan model gibi yaşam döngüsü modellerine de yer verilmiş ve bu modellerin zayıf ve kuvvetli tarafları irdelenmiştir.
Üçüncü bölüm uygulama bölümü olup uygulamaya konu olan şirket, EKS Eczacıbaşı Karo Seramik San. Ve Tic. A.Ş.’dir. Bu bölüm, yazılım yaşam döngüsünü tamamlamış bir sistemin incelemesini ve buna alternatif yeni yazılımın geliştirilmesini içermektedir. İnceleme şemalar ve akış diyagramları ile gösterilirken, yeni yazılımın geliştirilmesi, tüm gerçekleşen proje adımlarını içerecek şekilde ekranlar aracılığı ile anlatılmıştır. Mevcut yazılımdaki darboğazlar belirtilmiş olup proje ekibinin yeni yazılım ihtiyacını belirlemesinden tasarımına ve uygulanmasına dek olan süreç bu bölümde aktarılmıştır.
Dördüncü ve son bölüm ise sonuç bölümüdür. Bu bölümde, EKS’de yapılan çalışmanın başarısı üzerinde durulmaktadır. Yaşam döngüsünü tamamlamış bir yazılımın yerine yeni bir yazılımın uygulanması sürecindeki temel adımlar gözden geçirilmiş ve yeni yazılımın gelişmeye açık yönleri vurgulanmıştır.
2. YAŞAM DÖNGÜSÜ YÖNETİMİ KAVRAMI VE YAZILIMLAR
Yaşam döngüsü yönetimi, bir ürün, yatırım veya servisin yaşam döngüsü maliyetlerinin takibi ve kontrolü için geliştirilmiş bir kavramdır. Gelişmiş maliyet yönetimi tekniklerini, performans ölçümlerini ve yatırımlar portföyü kavramını bünyesinde barındırır. Amacı yatırımın yaşamı boyunca daha fazla kullanılabilir bilginin sağlanmasıdır.
Yaşam döngüsü yönetimi (YDY) yaklaşımının ögelerini yaşam döngüsü modeli, performans kriterleri, maliyet yönetimi sistemleri ve portföy teorisi oluşturur. Yaşam döngüsü modeli, yaşam döngüsünün 7 adımını konu alır. Herhangi bir endüstrinin, yatırımın veya ürünün hayat döngüsünü analiz, başlangıç, giriş, geliştirme, olgunluk, iniş ve geri çekilme adımları oluşturur. Performans kriterleri kritik başarı faktörlerine bağlı olup sürekli izlenir. Maliyet yönetimi, maliyetleri aktiviteler bazında değil süreçler bazında izler ve son olarak portföy teorisi sayesinde yatırımlar kendi başlarına değil bir bütünün parçaları olarak analiz edilir (Adamany ve Gonsalves, 1994).
YDY, bir yatırımın yaşamının farklı bölümlerinde farklı kazançlar sağladığı varsayımını kabul eder. Bu sava göre yatırımın değerlendirilmesi yaşam döngüsünün her safhasında farklı olmalıdır. Bu uygulama ile yatırımın her safhasında farklı performans kriterleri belirlenir ve kaynak planlaması yapılır.
YDY’nin en çok uygulandığı alanlar aşağıdadır:
1. Ürün Yaşam Döngüsü Yönetimi (Stratejik) :Ürünün tasarımından, piyasadan çekilmesi aşamasına kadar olan adımları stratejik açıdan inceler. Kar maksimizasyonu birincil önceliktir.
2. Ürün Yaşam Döngüsü Yönetimi (Ekolojik) :Ürünün tasarımından, kullanımının son bulması aşamasına kadar olan adımları ekolojik açıdan inceler. Çevre güvenliği birincil önceliktir.
3. Yatırım yada Varlık Yaşam Döngüsü Yönetimi: Yatırım ve varlıkların ihtiyaç saptamasından, hurdaya ayrılmasına kadar olan adımları inceler. Yatırımın ekonomik ömrü birinci önceliktir.
4. Yazılım Yaşam Döngüsü Yönetimi: Yazılım ihtiyacının saptanmasından, kullanmama kararına kadar olan adımları inceler.
Yazılım yaşam döngüsü, bilgisayara dayalı bilişim sistemi veya alt sistemlerinin bakımında izlenen ve gelişme gösteren bir süreçtir. Bu süreç bilgisayar ile birlikte süren geleneksel bir işletim sürecidir. Bu görevin gerçekleştirimi konusunda bilgisayar bilimciler arasında bir anlaşma vardır. Sadece bazı adımların sayısı ve isimlendirilmesi konusunda ayrılıklar olmaktadır. Her yetkili bu süreci farklı bir şekilde açıklama eğilimindedir. Yakından bir inceleme yapılırsa, tüm açıklamaların aynı genel deseni açıkladığı görülür ve bu desen sistemler yaklaşımını çok yakından izler.
Bilgisayar kullanan firmalarda bir çok YYD ortaya çıkar. Bunların sayısı 100 veya daha fazlada olabilir. Kullanılmakta ve geliştirilmekte olan her sistem için bir YYD söz konusudur. Örneğin, bordro YYD, nakit akışı YYD, satış raporlama YYD, ve diğerleri bunun örnekleridir. YYD’lerinin her biri, firmanın stratejik planında bilişim kaynakları için bir deyimdir. Gerçekte, YYD’leri yönetimin stratejik planda yürüttüğü araçlardır.
Şekil 2.1. Yazılım Yaşam Döngüsünün Altı Aşaması İhtiyaçlar Tanımlama Tasarım Gerçekleştirme Uygulama Bakım
2.1. YAŞAM DÖNGÜSÜNÜN AŞAMALARI
Şekil 2.1’de de özetlendiği gibi, bazı yorumlara göre yaşam döngüsünde altı aşama vardır: (1)İhtiyaçlar (2)Tanımlama (3)Tasarım (4)Gerçekleştirme (5)Uygulama (6)Bakım
Bu altı aşama YYD işlemleri bütününü tanımlamada kullanılır. Sistem geliştirme bazen aylar, bazen de yıllar sürebilir. Bu aşamalara bir çok insan katılırken büyük maliyetlerde gerektirebilir. Altıncı aşama olan bakım ve yenileme aşaması zaman olarak en uzun süren aşama olabilir. 25-30 yıl boyunca kullanılan sistemler olabildiği gibi birkaç ay ya da birkaç hafta sonra bırakılmış sistemlere de rastlanmaktadır. Kullanım aşamasında, sistemi işletimde tutmak için kesinlikle bakım yapılmalıdır. Bazı durumlarda sisteme bakım uygulamak yerine, yönetim sistemini yeniden geliştirilmesi daha pratik bulunabilir. Bu durumda döngü yeniden başlar.
2.1.1. İhtiyaçlar
YYD, yazılım için ihtiyacın oluşması ile başlar.Bu aşama ihtiyacın ortaya çıktığı birim tarafından üst yönetime bildirilmesi ve onaylanması ile son bulur. Organizasyonun iç prosedürlerine göre değişen bu aşama kimi zaman direkt BT departmanına yapılan yazılım isteği ile son bulduğu gibi, kimi zaman da organizasyondaki onay sürecinin karmaşıklığından haftalar sürebilir. İhtiyaçların onay süreci ihtiyacın niteliğine göre de değişim gösterebilir. Zira basit bir raporlama ihtiyacı için kısa bir onay süreci gerekirken, karmaşık fonksiyonları yerine getirecek bir uzman sistem için onay süreci uzayabilir.
2.1.2. Tanımlama: Sistem Gereksinimlerinin Belirlenmesi
Sistem gereklerinin belirlenmesi, ya da daha yaygın olarak kullanılan adlarıyla, sistem çözümleme ya da sistem analizi, bilgi sistemlerinin geliştirilmesinde, hem süre, hem de işgücü bakımından en fazla yatırımı gerektiren aşamadır. Konuyla ilgilenen bütün araştırmacılar arasında, ortaya çıkacak bilgi sisteminin sağlamlığının, güvenilirliğinin ve genel olarak projenin planlanan sürede ve başarılı olarak sonuçlanmasının, başarılı bir sistem çözümleme aşamasının sonucu olduğunda görüş birliği vardır. (Blackburn, 1996)
Bilgi sistemi geliştirmede hız ve üretkenlik konusunda 1992 ve 1993 yıllarında ABD, Avrupa ve Japonya’da yapılan bir araştırmada ilginç sonuçlar alınmıştır.
Araştırma kapsamında, ABD ve Japonya’da 49 yazılım üreticisi kuruluş yetkilileriyle yapılan görüşmeler, Avrupa’da ise 12 değişik ülkede 98 yazılım üreticisi tarafından yanıtlanan anketler değerlendirilmiştir. Görüşleri alınan yöneticiler, boyları 1200 satırla 6 milyon satır arasında değişen ve 27 farklı programlama dilinin kullanıldığı yazılım projelerinde görev almış kimselerdi.
Araştırma, başlıca üç soruyu yanıtlamayı hedeflemekteydi:
1. ABD, Japonya ve Avrupa’lı bilgi sistemi üreticileri, yazılım projelerinin yönetiminde nasıl farklılıklar göstermektedir?
2. Yöneticiler, yazılım geliştirme hızını nasıl yükseltebilirler?
3. Yöneticiler, yazılım geliştirmede çalışan personelin üretkenliğini nasıl artırabilirler?
İlk soruya ilişkin olarak özetle şu sonuçlar elde edilmiştir:
Her üç ülke/kıta’daki yazılım projelerinde, proje süresinin yaklaşık 1/6’sı proje planlama ve sistem çözümleme etkinliklerine ayrılmaktadır. Japonya’da kodlama (program yazımı) aşamasına ayrılan süre, toplam sürenin yaklaşık %22’si düzeyindeyken Avrupa’da bu oran %29’a çıkmakta, buna karşılık Japonya’da planlama ve sistem çözümlemeye verilen emek (işgücü) toplam işgücünün %26’sı düzeyindeyken Avrupa’da %22 dolayında gerçekleşmektedir. Bu noktada, projenin ilk aşamasındaki %4’lük bir emek fazlasının, sonraki aşamalarda hem gerekli işgücünde hem de sürede azalmaya yol açtığı söylenebilir(Blackburn, 1996).
Bütün yöneticiler, projelerin başarılı olmasındaki en önemli etmenleri: (1)nitelikli sistem çözümleme, (2)proje ekibi içinde etkili ve başarılı iletişim (belgeleme, vb.) ve (3)nitelikli insangücü olarak saymaktalar. Öte yandan yine bütün yöneticiler, kullanılan yazılım geliştirme araçlarının ürün geliştirme süresi üzerinde belirleyici bir etkisi olmadığı görüşündeler. Başka bir deyişle, üreticilere yapılan yatırımın, bilgi sistemleri projelerinde üretim araçlarına yapılan yatırımdan daha etkili bulunduğu görülmektedir.
Bu araştırmada ortaya çıkan en önemli sonuç, projenin ilk aşamalarında ihtiyaçların belirlenmesine yapılan yatırımın, sonraki aşamalarda yapılacak değişiklik ve düzeltmeleri azalttığı, genel olarak proje süresini kısalttığı olmuştur.
Ortaya çıkan bir başka sonuç ta, sistem çözümleme aşaması dışındaki aşamalar için, daha küçük ekiplerin daha verimli çalıştıklarıdır. Belli bir sürede üretilen yazılım ürününün boyutları bakımından, çözümleme aşamasına daha fazla emek sarf eden kuruluşların, genel üretkenliklerinin tutarlı olarak daha yüksek olduğu görülmüştür.
Bilgi sistemi geliştirmede ön örnek yaklaşımının kullanılması da üretkenliği artırırken proje süresini azaltmaktadır. Bunun, öncelikle, proje sürecine “müşteri”nin katkısını artırmak yoluyla gerçekleştiği düşünülmektedir. Bu sonuç, sistem çözümlemeye verilen emeğin ve ayrılan sürenin, “maliyet”ten ziyade “yatırım” olarak düşünülmesi gereğini vurgulamaktadır. İleride anlatılacağı üzere ön örnek yaklaşımı, sistem gereklerinin belirlenmesinde doğrudan doğruya kullanıcının katkısından yararlanılmasını sağlamaktadır.
2.1.2.1. Sistem Gereksinimlerinin Belirlenmesi (SGB) Raporu Öğeleri SGB raporunun içeriği:
Uluslararası düzeyde en yaygın kabul görmüş SGB rapor standardı, Elektrik ve Elektronik Mühendisliği Enstitüsü (IEEE) tarafından önerilmiştir (IEEE Software Engineering Standards, 1988).
Bu standardın dışında, çeşitli ulusal ve uluslararası kuruluşların önerdiği rapor yapıları kullanılmaktadır.
Genel olarak SGB raporunun, anlaşılır, kesin ve eksiksiz biçimde yazılım ihtiyaçlarını ortaya koyması gerekir. “Müşteri” ile en yoğun iletişimin gerçekleştiği aşamanın sonunda yazılmış bir belge olmasıyla, bilgi sistemi geliştirme sürecindeki diğer belgelerden ayrılır. SGB raporu, müşteriyle yazılımcının teknik düzeyde yaptıkları anlaşmayı belgeler. Bu nedenle, müşteri ya da kullanıcı tarafından bütünüyle anlaşılabilmelidir. Bu, teknik olmayan bir dille yazılması anlamına gelmez. Bazı konularda kesin ve eksiksiz bilgi aktarımının yolu bazı biçimsel ve teknik terimlerin kullanılmasından geçer. Bu durumda müşteriye ya da kullanıcıya düşen, kendisi için hazırlanan sistemin ne yapacağını rahatça anlayıp onaylayabileceği ya da değişiklik isteyebileceği biçimde ayrıntıların üzerinden gitmektir.
Nitelikli bir SGB raporu nasıl olmalıdır?
Yüksek nitelikli bir SGB raporunun özellikleri şöyle sıralanabilir:
Doğruluk, tek anlamlılık, bütünlük, doğrulanabilirlik, tutarlılık, anlaşılabilirlik, geliştirilebilirlik, izlenebilirlik, ulaşılabilirlik. Bu özelliklerin her biri aşağıda kısaca gözden geçirilecektir.
Doğruluk: Doğruluk, sistem gerekleri belirtiminin, kullanıcı ihtiyaçlarını doğru olarak, eksiksiz ve fazlasız olarak ortaya koyma özelliğidir. Bu özelliğin sağlanmasında, kullanıcıya büyük sorumluluk düşer, çünkü ne isteyip ne istemediğini en iyi bilecek, yine odur.
Tek anlamlılık: Tek anlamlılık, gerekler belirtiminin yalnızca tek biçimde ve doğru olarak anlaşılabilme özelliğidir. Örneğin “Saniyede 1 Kbit hızında üretilen bilgi okunmalıdır.” gibi bir cümle tek anlamlı değildir, çünki üretim hızının mı yoksa okunma hızının mı 1Kbit/sn olmasının istendiği anlaşılamamaktadır.
Bütünlük: Bütünlük, ya da eksiksizlik, SGB raporunun, kullanıcı ihtiyaçlarının tümünü içerme özelliğidir. Bu belge, ekleriyle birlikte, tek başına, daha sonraki tasarım aşamasına yeterli dayanak oluşturabilmelidir.
Doğrulanabilirlik: Doğrulanabilirlik, kullanıcı ihtiyaçlarının belirsiz ve soyut biçimde değil, kesin, ölçülebilir biçimde ortaya konulma özelliğidir. Örneğin “veriler büyük bir hızla okunmalıdır” cümlesinde ortaya konulan istemin karşılanıp karşılanmadığı hiçbir zaman doğrulanamaz. Ne kadar hız “büyük bir hız”
dır? Oysa ki “veriler, en az saniyede 1000 harf hızıyla okunmalıdır” gibi bir belirtim kesindir ve doğrulanabilir.
Tutarlılık: Tutarlılık, SGB raporunun bir yerinde yazan ile bir başka yerindekinin çelişmeme özelliğidir. Ortaya konulan ihtiyaçların her biri, bütün diğer ihtiyaçlarla, belgenin bütününde belirtilen amaçlar, kapsam, ayrıntılı ihtiyaçlar,vb ile tutarlı olmalıdır. Bunu sağlamanın yolları arasında, gereksiz yinelemelerden kaçınmak, her konuyu yalnızca tek yerde ele almak vardır.
Anlaşılabilirlik: Anlaşılabilirlik, diğer niteliklerin yanısıra, doğru ve açık bir dilin kullanılması demektir. Kimi uygulamalarda matematiksel bir dil, kimilerinde doğal diller, ör. Türkçe, İngilizce, Fransızca, vb , kimi zaman çizimler, vb kullanılabilir. Ancak, SGB raporu, yalnızca teknik uzmanlara değil, doğrudan doğruya bilgi sisteminin kullanıcılarına da hitap eder. Bu nedenle, onların da anlayacağı ve onay verip vermemede rahatça, güvenle karar verebilecekleri bir dille hazırlanmış olmalıdır. Bilgi sistemleri çalışmalarındaki başarısızlıkların çok büyük bir bölümünün, kişilerin dil becerilerindeki yetersizlik olduğu, yazılım mühendisliği alanının belli başlı yazarlarınca defalarca dile getirilmiştir.
Geliştirilebilirlik: Geliştirilebilirlik, bilgi sistemlerinin en bilinen özellikleri arasında bulunan değişkenliğin, başarısızlığa yol açmaması bakımından önemlidir. SGB raporunda belirtilen ihtiyaçların zaman içinde değişikliklere uğraması olağandır. Bu nedenle, SGB raporunun da kolayca değiştirilebilmesi, gelişmelere açık olması gerekir. Bunu sağlamanın yolları arasında, örneğin, her konuyu yalnızca bir tek yerde ele almak, yinelemelerden kaçınmak, ele alınan her konuya çeşitli anahtar sözcükler üzerinden ulaşılmasını sağlayarak dizinlere yer vermek, vb sayılabilir.
İzlenebilirlik: İzlenebilirlik, SGB raporunun incelenmesi sırasında, ya da daha sonraki aşamalarda, tasarıma temel olarak, ya da üretilen sistemin kullanıcı ihtiyaçlarını ne ölçüde karşıladığının irdelenmesinde, bu raporun her bir bölümüne, çok çeşitli mantıksal zincirler üzerinden ulaşılması gerekebilir. Örneğin her bir tasarım öğesinin SGB raporundaki hangi maddeye karşı geldiğinin kolayca bulunabilmesi gerekir.
Ulaşılabilirlik: Ulaşılabilirlik, SGB raporundaki her türlü bilginin, doküman içinde kolayca bulunabilmesi özelliğidir. Bunun için en geçerli yöntem,
dizin(ler) kullanılmasıdır. Raporda geçen her terim, her kişi adı, her örgütsel birim, her dış kuruluş, vb. ayrı ayrı dizinlerde sıralanarak rapor içinde hangi sayfalarda geçtikleri gösterilirse, raporun ulaşılabilirlik niteliği yükselecektir.
2.1.2.2. Biçimsel yöntemler
Bilgi sistemleri geliştirme projelerinin başarısının belki de en önemli koşulu, kullanıcı ihtiyaçlarının doğru olarak anlaşılması ve tanımlanmasıdır. Buna yönelik olarak, SGB raporu üzerinde alınabilecek önlemlere daha önce değindik. Doğal dillerle (Türkçe, İngilizce, Fransızca, vb.) yapılan iletişimde, tek anlamlılık, belirsizlik, eksiksizlik, tutarlılık, ancak iletişimde bulunanların dikkat ve özeniyle sağlanır. Öte yandan, bu özellikleri zorunlu kılan, hata yapılmasına olanak vermeyen biçimsel diller de vardır. Örneğin bilgisayar programlama dilleri böyledir. Siz programı sözdizim kurallarına uygun biçimde yazarsanız, bilgisayarın bunu “yanlış anlaması” söz konusu değildir. Biçimsel diller, tutarsızlığı, çok anlamlılığı, belirsizliği önler. Bu açıdan bakıldığında, bütün bilgi sistemleri gerekleri biçimsel dillerle tanımlanabilse, bu projelerde başarı düzeyinin çok yükseleceği söylenebilir. Ancak, doğal dillerin rahatlığı, yaygınlığı ve herkes tarafından kullanılabilme özelliği, elbette biçimsel dillerde yoktur. Bu nedenle de her türlü gereksinim tanımının, sistem betimlemesinin biçimsel dillerle yapılması, en azından bu gün için olanaksızdır. Genel kabul görmüş bir yaklaşım, sistem tanımlarının yanlış anlaşılması maliyetinin çok fazla olacağı durumlarda biçimsel yöntemlerden yararlanılmasıdır.
Biçimsel betimleme yöntemlerinin belli başlıları arasında Sonlu Durum Makinası , karar çizelgeleri ve ağaçları, Tanımlama ve Betimleme Dili (Rockstrom ve Saracco, 1982), PAISLey (Zave, 1982) ve Petri Ağları vardır.
2.1.3. Tasarım
Bu bölümde, bilgi sistemlerinin, belirlenmiş ihtiyaçları yerine getirmek üzere nasıl tasarlandığı üzerinde durulacaktır. Tasarım, işlevsel (ya da işleyişe, davranışa ilişkin) ihtiyaçların, yapısal (ya da kuruluş ve örgütlenmeye ilişkin) bir sistem tanımına dönüştürülmesidir. Başka bir deyişle, ihtiyaçlar belirtimi, ya da SGB raporu, kurulacak sistemin neyi, nasıl yapması gerektiğini ortaya koyar. Sistem tasarımı ise bu sistemin yapısını, parçalarını, parçaların birbirleriyle ilişkisini, kısacası sistemin nasıl kurulacağını gösterir.
Bilgi sistemi geliştirmede genellikle ulaşılamayan ideal durum, sistemin, gereksinimler belirtiminden, türetilmesidir. Başka bir deyişle, tasarımın akılcı biçimde otomatik ve matematiksel olarak ortaya konulması, hata olasılığını en aza indirecektir. Ancak bunun olanaklı olduğu söylenemez. Bu olanaksızlığın başlıca nedenleri şunlardır:
i. Gereksinimler, hiçbir zaman tam değildir.
ii. Gereksinimler, hiçbir zaman ek destek gerektirmeden kullanılabilecek durumda değildir – yazılım araçları, biçimler, çevre sistemler standart olmayıp değişiklik gösterirler.
iii. Tasarımcıların zihinsel kapasiteleri, çoğu zaman sistemin bütün gereklerini bir arada kavrayamaz.
iv. Gereksinimler zaman içinde değişir.
v. Önyargılar, uzmanlık düzeyleri, gizli ve açık tercihler, hevesler, vb. tasarım sürecini kesinlikten uzaklaştırıp insan hatalarına yol açar.
vi. Sıfırdan başlayıp her şeyi yeniden üretmek yerine elde var olan (alt-) sistemleri kullanma çabası, tasarımı yönlendirir.
Öte yandan, akılcı biçimde yürütülmesi öngörülen bir tasarım sürecinin tanımlanması aşağıdaki bakımlardan yararlıdır:
i. İdeal süreç, tasarımcılara, işe nasıl girişecekleri konusunda yol gösterir. ii. Sistemin bütün özelliklerini gözönünde tutma çabası, birçok özelliğin birlikte dikkate alınmasını sağlar.
iii. İdeal süreç, tasarım sürecinin aşamalarını ortaya koyar, böylece gelişmenin izlenmesi, gecikmelerin fark edilmesi ve üretilen tasarımın değerlendirilmesi kolaylaşır (Parnas ve Clements, 1987).
Tasarım aşamasının sonucunda ise bir tasarım raporu oluşturulur. Tasarım raporu içeriği ise, yine kesin, açık ve tutarlı biçimde, kurulacak sistemin yapısını tanımlar. Bilgi sistemi tasarım raporu içeriği şu alt başlıkları içermelidir:
i. Birimler rehberi – Sistem birimleri arasındaki sıradüzen ilişkisini ortaya koyacak bir ağaç biçiminde, birimlerin birbirini çağırma (denetim) ilişkisi gösterilir. Bu rehberde, her birimin görev ve sorumlulukları kısaca belirtilir.
ii. Arabirimler – Her birimin kara kutu olarak dış dünyayla ilişkisi belirtilir; her birimin kullanıcıları (o birimi çağıran/işleten birimler) için gereken kullanım bilgileri verilir.
iii. Yazılım tanıtımı – Tek tek her birimin çağırılış biçimi, çağrı komut yapısı gösterilir; her çağrının ortaya çıkartacağı sonuçlar, veri yapıları üzerindeki etkileri; her çağrının başka birimler üzerindeki etkileri; zamanlama ve duyarlık düzeyleri; hata ve diğer özel durumlarda ne olacağı tanımlanır. Birim yapılarının tanımlanmasında, yine birimler rehberi yapısı kullanılabileceği gibi, her birim için veri yapıları ve bunlar üzerinde her çağrının etkileri tanımlanabilir.
2.1.3.1. Yapısal ve işlevsel tasarım yöntemleri
Bu aşamada sistem analistleri, kullanıcılar ile birlikte çalışır ve yeni sistem tasarımını aşağıda açıklanan yaygın tasarım araçları ile belgeler.
Tablo 2.1. Yaygın Belgeleme Araçları
İşlemleri Belgeleme Veri Belgeleme Grafik Araçları Sistem Akış Şeması Varlık İlişki Çizgesi
Veri Akış Şeması Yazıcı Uzayı Çizgesi Warnier-Orr Çizgesi Kayıt Anahat Çizgesi Veri Yapısı Çizgesi Anlatımsal Araçlar Yapısal İngilizce Veri Sözlüğü
Aygıtların bazıları, çözümleyicinin belgelemeyi yukardan aşağı bir biçimde yapmasını sağlar. Burada büyük bir resimle başlanır ve giderek küçük ayrıntılara inilir.Yukarıdan aşağı yaklaşım, yapısal tasarımın bir özelliğidir. Burada bir sistemden bir alt sistem düzeyine inilir (Thorp, 1998). Aşağıdaki şekiller bu yukarıdan aşağı işlemi göstermektedir.
1.2 Envanter 1.3 Faturalama 1.4 Muhasebe 1.1 Sipariş Girişi Müşteri 2 2 3 3 Tahsilat Envanter Büyük Verisi Faturalar Deyimler Müşteri Ödemeleri Tahsilat Büyük Defter Verisi Satın Alma Verisi Kabul Edilen Kalemler Kabul Edilen Sipariþler
Şekil 2.2. Veri Akış Çizgesi (Thorp, 1998)
Şekillerdeki oklar, veri akışını gösterir ve veri sözlüğünde bir giriş ile belgelenirler. Veri Sözlüğü firmanın veritabanının kapsamının resmi bir açıklamasıdır. Veri Sözlüğü, tüm proje takımlarına, firma veri kaynağını açıklamada kullanılan genel bir dil üretir. Aşağıdaki şekil, Satış Siparişleri veri akışı için veri akış sözlüğü girişidir.
İşlemler ve verinin bu belgelenişi, hem bilgisayar sistemleri hem de bilgisayarsız sistemler için taban oluşturur.Burada bir bilgisayarın kullanılacağı varsayılmıştır (Forsberg ve diğerleri, 1996).
1.2 1.3 Tamamlanmış Sipariþler Sipariş Kaydı Doldurulan Siparişleri İşaretleme Kayıtlanan Siparişler 1.1.3 1.1.4 Müşteri Satış siparişleri Reddedilmiş Satış Sipariş Uyarılar Redleri Düzenleme e Düzenlenmiş Siparişler Kredi Verisi Sipariş Verisi Düzenlenmiş ve Sýnanmýþ Siparişler Kredi Reddi Müşteri Kredi Dosyası Satış Siparişleri Kredi Reddi Satış Sipariş Düzenleme Reddi 1.1.1. SiparişVerisi Düzenleme 1.1.2 Kredi Sýnama Hesaplaması
Şekil 2.3. Sipariş Giriş Sistemi Veri Akış Çizgesi (Thorp, 1998) 2.1.4. Gerçekleştirme
Gerçekleştirme aşaması iki bölümden oluşur: Programlama ve sınama. Aşağıda bu iki bölüm ayrıntılı olarak incelenecektir.
2.1.4.1. Programlama
Programlama, bilgi sistemi geliştirmenin görece en rahat yönetilebilen, denetlenebilen, başı sonu belli aşamasıdır. Özellikle gereksinimleri belirleme çalışması yeterince nitelikli biçimde yapılmışsa, ve sistem tasarımı yeterince ayrıntılı ve doğruysa, programlama çalışması doğrudan doğruya tasarımın hedeflenen programlama diline aktarılmasından ibarettir.
Amatör çalışmalarda sistem çözümleme ve tasarım aşamaları yeterince ciddi olarak ele alınmadığından programlama, yazılım geliştirmenin en çetrefil, belki de tek aşaması olarak görülecek, ve o zaman da başarısızlık kaçınılmaz, en azından elde edilecek başarı rastlantısal olacaktır.
Burada, önceki bölümlerde ele alınan proje adımlarının tam olarak gerçekleştirildiği varsayılır. Böyle olunca, programlama hakkında söylenecek az şey kalacaktır. Bunlar (a) dil seçimi, (b) gözden geçirmeler başlıkları altında özetlenebilir.
a. Dil seçimi: Kullanılacak dilin, bir yandan hedeflenen sistemin gereklerine uygun olması, diğer yandan sistemin üzerinde çalışacağı altyapının en etkin ve verimli biçimde değerlendirilmesine olanak sağlaması, üçüncü bir yandan da, programları yazacak ekip açısından yüksek üretkenlik ve güvenilirlik düzeylerine ulaşılabilmesi için, özenle seçilmesi gerekir. Yazılım üreticileri, yeni bir dile geçmenin getireceği eğitim ve birikim oluşturma yatırımlarının maliyeti ile yeni olanakların ve artacak etkinlik ve verimlilik düzeylerin getirisini karşılaştırarak her projede yeniden bu kararı vermek durumundadırlar.
b. Gözden geçirmeler: Bilgi sistemi geliştirme projesinin her aşamasında gözden geçirmelerin, yüksek nitelik bakımından büyük önemi vardır. Programlama aşamasında da, her birimin, sınamaya geçilmeden önce, programı yazan kişinin dışındaki bir kişi (kişiler) tarafından gözden geçirilmesinin, hata bulma ve ayıklamada çok büyük yararı olduğunu yinelemek gerekir.
2.1.4.2. Sınama
Yazılım sınama sürecinin dört temel aşamadan oluştuğu kabul edilmektedir: (1) Birim sınama, (2) Bütünleşim sonrası sınama, (3) Gereksinimler sınama, (4) Sistem (ya da etki) sınama. Aşağıda, bu aşamaların her birini kısaca ele alınacaktır. Ancak bu aşamalardan önce, sınamanın planlanması gereğini de vurgulanmalıdır.
Sınama planı, ileride incelenecek her bir sınama aşamasında ne yapılacağını, alınması gereken sonuçların ayrıntılı olarak her birini, alınacak sonuçların nasıl değerlendirileceğini göstererek sınama sürecini yönlendirir.
Sınama, doğrulama, geçerlileme gibi terimler çoğu kez birbirinin yerine geçebilmekte, bunlar arasına kimi uzmanlarca ince anlam farkları yerleştirilmekte, ancak farklı kişiler, aynı terimi farklı anlamlar için yeğleyebilmektedir. (Ör. İngilizce
validation ve verification terimleri çeşitli kaynaklarda farklı anlamlarla
kullanılmaktadır.) Burada yalnızca “sınama” terimini kullanılacaktır.
1. Birim sınama: Bu aşama, her yazılım biriminin programının ortaya çıkması sırasında “beyaz kutu” yöntemiyle, programın her işlem dizisinin en az bir kez çalıştırılması ve sonuçların beklentilerle karşılaştırılması anlamına gelir. “Beyaz kutu” yöntemi, yazılım tasarımının elde bulunduğu, programın mantık yapısının ve işlem dizilerinin bilindiği varsayımına dayanır. Hataların, programın sıkça çalışan görece olağan bölümlerinden çok, seyrek olarak başvurulan, olağandışı koşullara
karşı gelen bölümlerinde bulunma olasılığının daha yüksek olduğu bilinir. Beyaz kutu yöntemi, programın sınanmamış bölümü kalmaması için kullanılır. Program biriminin, eksiksiz olarak olası her türlü veri ile işletilmesi, baştan sona olası her işlem dizisinin denenmesi çoğu zaman pratik değildir. Ancak olası her işlem dizisinin, yani işlemlerin olası her yinelenme durumunun değilse de her işlemin en az bir kez sınanması çoğu kez olanaklıdır.
2. Bütünleşim sonrası sınama: Her birimin sınanması başarılı olarak sonuçlandıktan sonra, birimlerin bir araya getirilmesi sırasında, ortaya çıkan yazılımın tasarımla karşılaştırılması gerekir. Başka bir deyişle, bu aşamada, üretilen yazılımın doğru üretilip üretilmediği sınanır. Tasarlanan sistemle yazılan programların ne ölçüde çakıştığı incelenir.
3. İhtiyaçlar sınama: Bir önceki aşamada “üretilen yazılımın doğru olup olmadığı” incelenmişken, ihtiyaçlar sınamasına “doğru yazılımın üretilip üretilmediği” incelenir. Başka bir deyişle, bu aşamada, ortaya çıkan ürünün, bu kez ihtiyaçlar belirtimine ne ölçüde uyduğu irdelenir. Eğer sistem çözümlemede ortaya konulan her bir ihtiyaç, ölçülebilir biçimde tanımlanmışsa bu aşamada yapılacak şey yalnızca sistem gereksinimleri belgesindeki her bir maddenin üzerinden giderek yazılımın hedefleneni ne ölçüde gerçekleştirdiğini saptamaktır. Bu iş, “alfa sınama” adıyla yazılım üreticisinin ortamında ve denetimli koşullarda yapılabileceği gibi “beta sınama” adıyla, kullanıcılar tarafından, kendi ortamlarında, üreticinin denetiminin dışındaki koşullarda gerçekleştirilebilir. Genellikle, ihtiyaçlar sınaması aşamasına gelindiğinde, ortaya çıkacak eksiklik ve hataların giderilmesi için vaktin geç olduğu kabul edilir. Bu aşamada görülen sorunlar, ya bir sonraki yazılım sürümünde giderilmek üzere saptanmış olur, ya da müşteri ile üretici arsındaki görüşmelerde dikkate alınır.
4. Sistem (ya da etki) sınama: Sistem sınama, yazılımın, gerçek kullanım ortamında, bir bilgi sistemi bütünlüğü içindeki etkisinin değerlendirilmesi demektir. Program yazımı, sistem geliştirme sürecinin ne kadar tanımlı bir aşamasıysa, sistem etkilerinin değerlendirilmesi de o kadar tanımsız bir süreçtir. “Etki” olarak neyin değerlendirileceği, bu etkinin ortaya çıkmasında bilgi sisteminin payının ne olduğu, bu payın nasıl ölçüleceği, hep yanıtsız sorulardır. Bir zorluk ta, kurulup işlemeye başlayan bir bilgi sisteminin büyük ölçekli etkilerinin ancak uzun bir süreden sonra ortaya çıkacağıdır. “Etki”nin nasıl tanımlanacağı sorusuna, parasal
getiriye yönelik olarak çalışan sistemlere ilişkin olarak nasıl yanıt verileceği bellidir. “Karlılık” çoğu kez yeterince kapsamlı bir hedeftir. Ancak, toplumsal, elle tutulamayan hedeflere yönelik sistemlerde bu çok daha zordur. Örneğin ulusal ölçekteki bir sağlık bilgi sisteminde, hedef “toplumun sağlık düzeyinin yükselmesi” olarak konabilir, ancak bunun ölçütlerinin tanımlanması, bu ölçütlerin net olarak elde edilmesi, ve bu hedefe yönelik başka etkenlerden bağımsız olarak yalnızca bilgi sisteminin etkisinin ölçümü olanaksız denilebilecek denli zordur. Öte yandan, bilişim sistemleri çalışmalarının, yalnızca “en son teknolojilerin peşinden ümitsizce koşmak” olmadığını bilenler için sistem sınamasının doyurucu sonuçları da olmalıdır.
Bu noktada, belki geniş ölçekli ve kurumsal düzeydeki bilgi sistemleri için değilse de en azından yazılım birimleri düzeyinde anlamlı olabilen “biçimsel doğrulama” yöntemlerinden de söz etmekte yarar var. Bu çerçevede amaç şudur: Sistem gereksinimlerini matematiksel kesinlikle tanımlayabilirsek, bunlardan yola çıkan sistem tasarımını da aynı matematiksel kesinlikle ortaya koyabilirsek, o zaman, üretilen yazılımın hem tasarıma uygunluğunu, hem de gereksinimleri karşılama düzeyini yine matematiksel kesinlikle saptayabiliriz. Bu yalnızca yazılan programların biçimsel olarak sınanıp doğrulanmasını değil, gereksinimlerden tasarımın, tasarımdan da yazılım gerçekleştiriminin otomatik olarak elde edilmesinin de olanaklı olması anlamına gelir. Günümüzde bu alanda çok sayıda çalışma yapılmaktadır. Özellikle telekomünikasyon sistemleri, donanım tasarımı gibi altyapıları, bileşenleri net olarak tanımlanabilen alanlarda biçimsel yöntemler kullanılabilmektedir. İletişim protokollerinin ve bunları gerçekleştirecek sistemlerin tanımlanmasında, tasarımında ve sınanıp doğrulanmasında biçimsel yöntemler yaygın olarak kullanılmaktadır. Bu konuda örneğin SDL, ESTELLE, LOTUS, Z gibi dil ve ortamlar kullanılmaktadır. Ancak, henüz, yönetim bilgi sistemlerinde, karar destek sistemlerinde, genel olarak biçimsel/matematiksel yöntemler yerine doğal diller kullanılmakta, bu da çok anlamlılık, belirsizlik, eksiklik, tutarsızlık gibi kaçınılmaz özellikleri birlikte getirmektedir.
2.1.5. Uygulama
Gereksinimleri belirlenmiş, tasarlanmış ve gerçekleştirilerek sınanmış bir yazılım sisteminin, bilgi sistemi içinde yerini almasına ve yeni bilgi sisteminin bütünüyle kullanıma girmesine kısaca “uygulama” denir. Uygulama süreci, çoğu kez
ilgili kuruluşun bütününü, tüm çalışanlarını ilgilendirir. Canlı bir organizmanın herhangi bir ameliyat geçirmesi gibi, yerel ve önemsiz bir boyutta olabileceği gibi o organizmanın bütün yaşamsal düzeneklerini zorlayan bir süreç de olabilir.
Uygulamanın kapsadığı adımlar şöyle özetlenebilir: 1. Uygulamanın planlanması
2. Uygulama projesinin kuruluşa duyurulması 3. Uygulamadan sorumlu çalışanların örgütlenmesi
4. Donanım ve yazılım altyapısının bütünüyle hazır duruma getirilmesi 5. Veri tabanının hazırlanması
6. Etkilenecek birimlerin ve çalışanların eğitimi 7. Fiziksel ortamın (ofis, vb) hazırlanması 8. Dönüşüm (Royce, 1998).
Bu adımların hangi sırayla geçileceği, birlikte mi ardarda mı gerçekleştirileceği ya da her birinin diğerlerine göre önemi ve gerektirdiği zaman, işgücü ve diğer kaynaklar, projeden projeye değişir. Birçok projede, diğer adımlar kaçınılmaz olduğundan, yalnızca yeterince özenle ele alınmamasında büyük sakıncalar bulunan üç en yaşamsal adımın: (1) planlama, (6) eğitim, ve (8) dönüşüm adımlarının vurgulanması yeterli olur. Aşağıda bu adımların her birini kısaca gözden geçirilecektir:
1. Uygulamanın planlanması : Bilgi sistemi projesinin en başında, olurluk çalışması aşamasında, bütün proje aşamaları planlanmış durumdadır. Özel olarak uygulama aşamasının planlanması ise, en başta yapılan bu planın gereken biçimde ayrıntılandırılması anlamına gelir. Bu planda uygulama takvimi gözden geçirilir. Kuruluş birimlerinin ve çalışanlarının yetki ve sorumlulukları belirlenir. Uygulama projesi çerçevesindeki örgütlenme oluşturulur. Uygulama planında, altyapıya ilişkin bütün hazırlıkların gereken zamanda bitirilmiş olmasının nasıl sağlanacağı da net olarak ortaya konur. Yeni sistemin yürürlüğe girmesinden önce, veri tabanının nasıl oluşturacağı, buna yönelik olarak hangi kaynakların kullanılacağı belirlenir. Birçok bilgi sistemi projesinde sistem çözümleme, tasarım ve gerçekleştirme, uzun dönemde sistemin nasıl işleyeceğini tanımlar, ancak en
başta, bir kerelik de olsa, veri tabanının nasıl oluşturulacağı, eski bilgilerin yeni sistemle nasıl bütünleştirileceği saptanmaz, bu da baştan hesaplanmayan kaynak gereksinimlerine ve gecikmelere yol açar. Doğru planlama, hem projenin başlangıcında, hem de uygulama aşamasının başında, bir kerelik ve sürekli işlerin her birinin nasıl, kim tarafından ve hangi kaynaklardan yararlanılarak gerçekleştirileceğini saptamayı içerir. Bilgi sisteminin her düzeydeki kullanıcılarının eğitimi, uygulama aşamasının önemli adımlarındandır. Belki de bütün proje sürecinde en yüksek sayıda kişinin katılımı eğitim aşamasında gerçekleşir. Alt düzeydeki kullanıcılarla üst düzeylerdeki karar vericilerin bilgi sistemiyle etkileşimi farklı olacaktır. Bu doğrultuda, alacakları eğitimin de farklı olması doğaldır. Alt düzeydeki kullanıcılar, sistemin kendi işlerinde nasıl kullanılacağını, bilgi girişini, döküm almayı, hata durumlarında ne yapılacağını öğrenmek durumundadır. Kuruluş sıradüzeninde yukarılara çıkıldıkça, basit kullanıcı eğitimi yerine çalışma ve düşünme biçimini değiştirme yönü ağır basan eğitim gereksinimleri öne çıkar. Üst yöneticilere, sınıf içinde klasik tarzda eğitim vermek yerine kimi zaman seminerler, kimi zaman tartışma grupları, kimi zaman ise yemek, kokteyl vb çok daha farklı ortamlarda yapılacak görüş alışverişleri yeğlenebilir. Eğitimde sıkça karşılaşılan bir güçlük de kuruluş için her düzeyde önemli olan kişilerin eğitim almaya daha az vakit ayırabilmeleri, eğitime vakit ayırabilenlerin ise kuruluş içinde görece daha az önemli işlerle uğraşmaları çelişkisidir. Dönüşümün nasıl gerçekleştirileceği ise başlı başına dikkat ve ustalık gerektiren, çoğu zaman hataları affetmeyen bir planlama ve yönetim sorunudur. Uygulama planlaması yalnızca yöneticilere yararlı olacak planların hazırlanmasından ibaret değildir. Bu adım, uygulamanın bütün adımları için gereken yönergeleri, kılavuzları, yetki ve sorumluluk dağılımını, sorunların nasıl çözüleceğini, vb. yazılı olarak ortaya koymayı ve bütün ilgililere dağıtmayı da içerir.
2. Uygulama projesinin kuruluşa duyurulması : Uygulama projesinin kuruluşa duyurulması, aslında uygulama aşamasına gelinmeden önce yapılması gereken ve ustalık isteyen bir iştir. Örgütlerin genel olarak her türlü yeniliğe ve değişime karşı çıktıkları bilinen bir gerçektir. Bunu aşmanın en doğal yolu ise, her birimin ve her çalışanın, değişimden nasıl somut kazanç sağlayacağının açıklanmasıdır. Bu kazanç bireysel ve parasal kazanç olmayabilir. Ancak çalışanların herhangi bir biçimde olumlu görmedikleri bir değişime katılmaları, ona katkıda bulunmaları da beklenemez. Burada yöneticilere düşen, yeni bilgi sisteminin
her düzeyde ne gibi yararlar sağlayacağı konusunda kuruluşun tümünün aydınlanmasını sağlamaktır.
3. Uygulamadan sorumlu çalışanların örgütlenmesi : Uygulamadan sorumlu çalışanların örgütlenmesi, uygulama projesinin başlı başına bir proje olarak ele alınması anlamına gelir. Sorumluları, işbölümü, kaynakları, süreleri belirlenmiş bir uygulama projesinin başarı şansı bütün bunların gelişigüzel biçimde sağlandığı (ki bu hiç te seyrek değildir) durumlardan çok daha yüksek olacaktır (MIS, 2001).
4. Donanım ve yazılım altyapısının bütünüyle hazır duruma getirilmesi : Altyapının hazır edilmesi, çok bileşene bağımlı projelerin hemen hepsinde, oldukça ciddi bir eşgüdüm çalışması gerektirebilir. Yazılımda gecikmeler, donanım olanaklarının öngörülmemiş nedenlerle kurulamaması, vb hep bu aşamayı geciktirebilen nedenlerdir.
5. Veri tabanının hazırlanması : Veri tabanının hazırlanması, birçok projede, bir kez yapılan ancak kuruluşun geçmişiyle geleceğini birbirine bağlaması nedeniyle önemli olan bir iştir. Eğer proje planlamasında yalnız geleceğe yönelik sistem gereksinimleri saptanmış ve geçmişte birikmiş verilerin yeni sistemle nasıl bütünleştirileceği açıkça ortaya konulmamışsa bu aşama önemli bir sıkıntı yaratacaktır. Bu aşama için özel yazılımlar geliştirilmesi, geçici işgücü sağlanması, belki toplu veri girişinin yapılacağı ya da belgelerin taranıp veri tabanına yükleneceği özel olanaklara gereksinim olabilir.
6. Etkilenecek birimlerin ve çalışanların eğitimi : Eğitim, yukarıda uygulamanın planlanması başlığı altında da değinildiği gibi projenin en çok kişiyi bir araya getiren aşaması olabilir. Bu kişilerin nasıl seçileceği, eğitime ilgi göstermelerinin nasıl sağlanacağı, kısaca eğitimin başarılı olmasının nasıl sağlanacağı hep yaşamsal sorulardır. Ayrıca, özellikle ülkemizde kamu kesiminde insan gücünün yeterince değerli görülmemesi, birçok uygulamada, eğitim almış kişilerin, kuruluşu yakından tanımayan yöneticiler tarafından görevlerinin değiştirilmesine ve bu da önemli kayıplara yol açabilmektedir.
7. Fiziksel ortamın (ofis, vb) hazırlanması : Fiziksel ortamın hazırlanması, görece kolay, ancak yine de belli bir yönetim becerisi gerektiren bir uygulama adımıdır. Ofislerin, iletişim olanaklarının, belki bilgisayar sistem
odalarının vb hazırlanması, güvenlik sorunlarının çözülmesi hep bu adımın parçalarıdır.
8. Dönüşüm : Dönüşüm adımı, yalnızca eski sistemin (ki bu el emeğine ve bütünüyle kağıda dayalı bir sistem olabilir) çalıştığı dönemden, yalnızca yeni sistemin yürürlükte bulunacağı döneme kadar geçen bütün süreyi kapsar. Kimi basit ve etki alanı dar uygulamalarda birden bire eskiden yeniye geçilebileceği gibi, birçok uygulamada belli bir süre iki sistem birlikte çalıştırılır. Bunun getireceği işgücü ve kaynak gereksinimi yüksek olmakla birlikte kuruluşta yeni sisteme yeterli güvenin kazanılması için zorunlu olabilir. Birçok projede de birlikte çalışmadan eski sistemin devre dışı bırakılmasına geçiş, sistemin bütünü için bir defada yapılmayıp aşamalı olarak gerçekleştirilebilir. Bu aşamalar, sistemin mantıksal parçalarının birer birer dönüştürülmesi biçiminde (ör. önce satınalma alt sistemi, sonra stok denetimi alt sistemi, sonra personel alt sistemi, daha sonra muhasebe alt sistemi ve en sonda maliyet muhasebesi alt sisteminin yeniye dönüştürülmesi) olabileceği gibi, geniş bir kuruluşun çeşitli yerleşkelerinde ya da coğrafi/idari birimlerinde bire birer yeniye geçiş yapılabilir. Dönüşüm sürecinde esas, kuruluşa en az sarsıntı getirecek, çalışanların etki ve verimlilik düzeyini en az düşürecek, ancak öte yandan gecikmelerin getireceği kayıpları da en aza indirecek dönüşüm sürecinin belirlenip uygulanmasıdır (Kitaoka, 2000).
2.1.6. Bakım ve Yenileme
Bilgi sisteminin, önceki bölümlerde kısaca gözden geçirildiği gibi kullanıma girmesi, yaşam çevriminin en başına dönülmesi anlamına gelir. Uygulama ve elde edilen etkiler değerlendirilecek ve kimi zaman yenilemeler, düzeltmeler gerekebilecektir. Günümüzde, ortalama yazılım ömrünün beş yıldan az olduğu kabul edilmekte, dünya çapında pazarlanan yazılım ürünleri, hepimizin bildiği gibi bir iki yılda bir yenileriyle değiştirilmektedir.
Bu bölümde, önce bilgi sistemlerinde bakımın anlamı ve türleri üzerinde durulacaktır. Daha sonra, yazılımda değişiklik kararına yakından bakarak, en son olarak ta bakım işinin örgütlenmesi, değerlendirilmesi ve tüm bu süreçte kullanıcılara düşen sorumluluk konularını incelenecektir.
Yukarıda, bilgi sistemleri ile iş süreçlerinin karşılıklı olarak birbirleri üzerinde belirleyici etkileri olduğunu vurgulanmıştı. Bilgi sisteminin bakım sürecinde de bu karşılıklı etkilerin belirleyici olması kaçınılmazdır.
2.1.6.1. Yazılım Bakımı Nedir?
Ne denli iyi sınanmış, doğruluğu ve güvenilirliği kanıtlanmış olursa olsun, yazılımın tümüyle kusursuz olarak kullanıma sunulması neredeyse olanaksızdır. Özellikle, tek (ya da az sayıda) kullanıcı kuruluş için özel olarak geliştirilmiş, çok geniş bir pazarda kendini kanıtlamamış bir üründe zaman içinde ortaya çıkacak kusurların bulunması doğaldır. Bunların giderilmesine düzeltici bakım denilir.
Öte yandan, kullanım süresince kullanıcı gereksinimlerinin değişmesi de doğaldır. Kuruluşlar yaşayan sistemlerdir, ve değişim kaçınılmazdır. Çevre koşulları (müşteriler, yasal mevzuat, vb) değişir, kuruluş yeni alanlara girer, vb nedenlerle yazılım değişiklikleri gerekir. Bunların gerçekleştirilmesine uyarlayıcı bakım adı verilir.
Özellikle başarılı olan, pazarda geniş kabul gören yazılım türlerinde uygulanan bakım ise üçüncü türü oluşturur. Pazar payını genişletmek, yazılıma yeni yetenekler eklemek, başarım (performans) düzeyini yükseltmek, yeni altyapılar üzerinde çalışmasını sağlamak vb amaçlarla yapılan bakıma da yetkinleştirici bakım adı verilir.
Yazılım dünyasında bakım etkinliklerinin aşağıdaki gibi dağıldığı bilinmektedir (Blackburn, 1996):
Tablo 2.2. Bakım etkinlikleri
Bakım Türü Genel İçindeki Yüzdesi
Düzeltici 21
Uyarlayıcı 25
Yetkinleştirici 50
Yazılımda hata bulma ve düzeltme maliyetinin yaşam çevrimi boyunca katlanarak arttığı da bilinmektedir. Bu artış, hataları süreç içinde olanaklı en erken zamanda bulmanın önemini açıkça ortaya koymaktadır. Öte yandan, yazılımın “bakıma uygunluk” niteliği, maliyetleri düşürmede etkili olacaktır. Yazılım nitelikleri bakımından, iyi belgelenmiş ve birimsellik niteliği yüksek ürünlerin bakımının görece kolay olacağı da açıktır.
Bakım işinin bir yönü de kendi kendini güçleştirici olmasıdır. Yazılım sistemleri bakım gördükçe bakıma uygunluk nitelikleri azalır. Aynı sistemin bakım maliyeti zamanla yükselir. Özellikle düzeltici ve uyarlayıcı bakım, çoğu kez bunalım koşullarında gerçekleştirildiğinden enine boyuna irdelenmemiş değişiklikler getirmekte, bunların sonuçları da uzun dönemde ortaya çıkabilmektedir. Bunu engellemenin yolu, bakım sürecinin biçimsel ve sağlam kurallara bağlanmasıdır.
2.1.6.2 Bakım Süreci
Yazılımda değişiklik kararı : Değişiklik kararıyla ilgili olarak şu soruların sorulması gerekir:
1. Değişiklik yapılması zorunlu mu?
2. Değişimin toplam maliyeti nedir? Bunun hesaplanmasında bütün sistem geliştirme süreci dikkate alınmalı, gereksinimlerin belirlenmesi, tasarım, geliştirme, sınama, dönüşüm, ve onun kapsadığı eğitim gibi etkinlikler gözardı edilmemelidir.
3. Değişim için gereken kaynaklar nelerdir? Zaman, işgücü, donanım, yazılım altyapıları, vb.
4. Toplam değişim süresi ne kadar olacaktır? 5. Hizmet ne süreyle duracaktır?
6. Gerekecek kullanıcı eğitiminin çapı, kapsamı, süresi, kuruluş üzerindeki etkisi ne olacaktır?
7. Yazılımın genel niteliği ve bakılabilirliği nasıl etkilenecek? Bu değişim, gelecekte gerekecek değişimleri nasıl etkileyecek?
9. Eski sistem bütünüyle mi ortadan kaldırılacak, yoksa kısman yürürlükte mi kalacak?
Bu sorulara verilecek yanıtlar, bilinen geleneksel “örgütsel tutuculuk” yönünde, değişime karşı güçleri desteklemekten çok, değişimin ne zaman ve hangi kapsamda yapılması gerektiğini belirlemede yararlı olacaktır. Bu değerlendirmenin ışığında çoğu kez, dar kapsamlı ve “önemsiz” görülen değişikliklerin gerçek çözüme götürmediği, köklü ve kapsamlı değişimlerin gerektiği ortaya çıkabilecek, kuruluşun bunun için gereken planlamayı ve yatırımı gerçekleştirmesi sağlanabilecektir.
Bakım Adımları : Bakım sürecinde kullanıcı, kullanıcı-çözümleyici-yazılımcı üçgeninin önemli bir köşesini oluşturmaktadır. Özellikle düzeltici ve uyarlayıcı bakımda süreci başlatan doğrudan doğruya kullanıcılardır. Bu nedenle, yukarıda yazılımda değişiklik kararına ilişkin olarak ortaya konulan soruların, kullanıcının kendisi tarafından yanıtlanmasıyla işe başlamakta yarar vardır.
Yazılım bakımı, çoğu zaman yazılımı geliştiren kişilerce gerçekleştirilir. Tam da bu nedenle, hep “ikinci iş” ya da “ikinci sorumluluk” olarak yapılır. Uzmanlar, genellikle yeni sistem geliştirmeyi, eskisi üzerinde çalışmaya yeğlerler. Öte yandan, eski yazılım üzerinde yapılan bakım çalışmalarının, yazılımcıların üretkenliğini düşüren belli başlı etmenler arasında olduğu da kabul edilmektedir (Genuchten, 1991).
Oysa ki bakım, yaşayan bir sistemi ayakta tutmak anlamına gelir ve birçok durumda, yeni sistem geliştirmekten çok daha etkin ve verimli bir çözüm olabilir. Bu nedenle, bakım sorumlularının belirlenmesi, bunu olanaklar elverdiğince “yan” iş olarak değil “asıl” iş olarak yapmalarının sağlanması, sorumluların yanlarında yedek personelin de görevlendirilmesi, bakım sürecinin niteliğini yükseltecektir.
Bakım süreci, aşağıdaki aşamaları içerir:
a. Bakım istemi – genellikle kullanıcı tarafından ortaya konur. Bir sorundan yakınma ya da bir gereksinimi ortaya koyma biçiminde olabilir. Acil – olağan – önemsiz biçiminde sınıflandırılabilir.
b. İstemin değerlendirilmesi – bakım isteminin, önemine göre belirlenecek bir süre içinde, bakım sorumluları ve kullanıcı (temsilcileri) tarafından değerlendirilerek, yukarıdaki soruların yanıtlanması ve bir karara varılmasını içerir.
Bu karar, “derhal değişiklik” – “bir sonraki sürüm için değişikliğin planlanması” – “hiç bir şey yapılmaması” vb biçimlerinde özetlenebilir.
c. Değişikliğin yapılması – gerekli karar verilip kaynaklar sağlandığında değişiklik işlemi gerçekleştirilir. Bu, yazılım yaşam çevriminin tümünü içerecektir. Gereksinimlerin belirlenmesi, tasarım, gerçekleştirme, sınama, dönüşüm, eğitim, ve her aşamada gereken bütün belgeleme adımları, değişiklik çalışmasını oluşturur.
d. Değişikliğin değerlendirilmesi – yine tüm yazılım yaşam çevriminde olduğu gibi, uygulama sonrasında, yapılanların etkilerinin değerlendirilmesiyle bakım süreci tamamlanmış olur.
Bakım Değerlendirmesi : Bakım değerlendirmesinde kayda geçecek ilk bilgi kullanıcı değerlendirmesidir. Bakım sürecini başlatan istemin sahipleri yeni işlevsellikten hoşnutsa, sorunsuz çalışabiliyorsa başarının ilk koşulu sağlanmış demektir.
Bakım sürecinin niteliği, yine tüm yazılım süreci gibi, yalnızca ortaya çıkan ürünle ölçülmez. Değişiklik sürecinde izlenen yöntem, gözden geçirme ve diğer nitelik öğeleri, belgeleme, sorumluların bulunabilirliği, personelin varlığı, ulaşılabilirliği, yedeklenmesi ve beceri düzeyleri hep süreç niteliğini belirleyen öğelerdir.
Bakıma harcanan zaman ve emek istatistikleri sürecin somut ve sayısal olark değerlendirilmesini sağlar.
Bakım öncesindeki ve sonrasındaki kullanıcı değerlendirmeleri ise, bu sürecin niteliksel yönünü ortaya koyacaktır. Bir birimin istekleri doğrultusunda yapılacak değişiklik, bazen, kuruluşun diğer birimlerinin olumsuz etkilenmesine yol açabilir. Bu ise, ilk karara yönelik değerlendirmenin yetersizliğini gösterir. Daha da kötüsü, yazılımın bir işlevindeki değişiklik, başka işlevlerde, giderek daha önemli ve belki de istenmeyen değişikliklere yol açabilir.
Bu nedenlerle, bakım sürecinin, belki de bütün yazılım yaşam çevriminden daha önemli yönlerinin bulunduğu da öne sürülebilir. En azından, bakımın nitelikli ve yeterli personel tarafından yapılması, değişiklik kararının, ancak yeterli bir değerlendirmeden sonra, niteliği yüksek bir süreç içinde oluşturulması, başarının yollarını oluşturacaktır (Boehm ve Ross, 1989).
2.2. YAŞAM DÖNGÜSÜ MODELLERİ
Bu bölümde, bilgi sistemlerinin yaşam döngüsü modelleri incelenecektir. Her sistem gibi bilgi sistemlerinin de yaşamından, evriminden, doğuş, gelişme, dönüşüm ve yeniden oluşumundan söz edilebilir. Bu sistemlerin yaşam döngüsü kabaca gereksinimlerin tanımlanması, sistemin tasarlanması ve kurulması, uygulamada yeni gereksinimlerin ortaya çıkması ve yeniden tasarım aşamasına dönüş olarak özetlenebilir. Aşağıda, bu genel çerçeve içinde, özellikle bilgi sistemi oluşturulmasının projelendirilmesinde izlenen belli başlı yaklaşımlar gözden geçirilecektir. Bunların ilki ve en yaygın biçimde kullanılanı, yaşam döngüsündeki aşamaların birbiri ardına sıralandığı, birinin çıktılarının, bir sonrakine girdi oluşturduğu anlayışına dayanan çağlayan modelidir (waterfall model). Çağlayan modelinin gerçek yaşamda ortaya çıkardığı birtakım sıkıntıları çözmeye yönelik olarak yaygın biçimde kullanılan ön örnek geliştirme (prototyping), ve bu yaklaşımların hepsini birlikte tanımlayan ve yazılım mühendisliği sürecini her türlü uygulamayı içerecek biçimde açıklayan sarmal modeli (spiral model) de ileride ele alınacaktır. Tüm bu modellere ek olarak modelsizlik olarak tanımlanabilecek yap ve düzelt(build&fix) ve çağlayan modelinin bir türevi olan artışlı (incremental) model de incelenecektir.
2.2.1. Yap ve Düzelt Modeli (Build & Fix)
Bu model daha önce de belirtildiği gibi modelsizlik olarak tanımlanabilir. Yazılım, ihtiyaçlar belirtimi doğrultusunda hazırlanır ve müşteri tatmin oluncaya kadar geliştirilir. Aşağıda sistemin grafik gösterimi görülebilir.
Şekil 2.4. Yap-Düzelt Modeli (Ling, 2002)
Şekilden de görüleceği üzere bu modelde hiçbir analiz ve dizayn aşaması yoktur. Müşteri tatmin oluncaya kadar gerçekleşecek çok uzun bir geliştirme döngüsü söz konusudur. Döngünün çok uzun olmasını ve beraberinde getirdiği yüksek maliyet nedeniyle “yap ve düzelt” modeli genellikle tercih edilmez. Çok küçük çaplı yazılım isteklerinde ise uygulama kolaylığı nedeniyle tercih edilebilir.
2.2.2. Çağlayan Model (Waterfall Model)
1970’li yıllarda yaygınlaşan çağlayan modeli, basit ve tek boyutlu oluşuyla, günümüzde de bilgi sistemleri geliştirmede özellikle proje sözleşmelerine temel oluşturmakta yaygın olarak kullanılmaktadır. Projenin her aşaması, çağlayanın bir düzeyi olarak görülür, süreç, ilk düzeyden son düzeye doğru geriye dönüş olmadan ilerler. Aşamalar ve düzeyler, farklı uygulamalarda farklı biçimlerde bölünebilir, ancak bu modelin belirgin özelliği, geriye dönüşlerin öngörülmemesidir. Şekilde, tipik bir çağlayan modeli örneği görülmektedir.
Şekil 2.5. Çağlayan Modeli (Ling, 2002)
Çağlayan modelinin, bilgi sistemi geliştirme projelerinde nasıl sözleşme çerçevesi olarak kullanılabileceği açıktır. İşin sahibi ile projeyi geçekleştiren kuruluş arasında, hangi aşamanın sonunda hangi ara ürünlerin teslim edileceği, bunların nasıl denetleneceği, vb hükme bağlanır, hangi aşamalarda ne kadar ödeme yapılacağı kararlaştırılır ve proje başlar. Burada önce, bu aşamaların her birinde kısaca söz edeceğiz, sonra da bu modelin olumlu ve olumsuz yanlarına kısaca göz atacağız.
Olurluk çalışması, ciddi projelerin hepsinde zorunlu görülen, yapılacak işin temel gerekçelerinin ortaya konulduğu, “neredeyiz?”, “nereye ulaşmak istiyoruz?”, “bunun çeşitli yolları nelerdir?”, “farklı seçeneklerin maliyetleri ve getirileri nelerdir?”, “girişilecek projenin temel varsayım, yöntem, aşama ve çıktıları neler olmalıdır?”, “girişilecek projenin maliyeti ve süresi nasıl öngörülmektedir?” gibi soruların tartışıldığı, projeye girişilip girişilmeyeceği konusunda verilecek karara esas belgenin hazırlanması demektir.
Gereklerin çözümlenmesi ve belirtimi, bilgi sistemi projelerinin ilk ve en önemli aşamasıdır. Bu aşamada, kurulacak sistemin kullanıcılarından, ayrıntılı olarak istemleri, sistemin hangi amaçlarla ve nasıl kullanılacağı öğrenilir. Yalnızca kullanıcılar tarafından dile getirilen istekler değil, kullanıcının temel strateji ve
hedefleri, bu hedeflere onu en doğru, etkili ve verimli biçimde ulaştıracak araçlar çözümlenir. Bu aşama, bilgi sistemleri projelerinin en belirleyici aşamasıdır. Kullanıcılar çoğu kez gerçek ve somut gereksinimlerini tanımlayamaz, en etkili çözümler için istemde bulunmazlar. Piyasanın sunduğu çözümler, sağdan soldan edindikleri duyum ve izlenimler, kişisel beklenti ve hedefleri, çoğu zaman, kurumsal gereksinimleri gölgeler. Ayrıca kullanıcı istemleri zaman içinde değişir. Projenin başında öne sürülen istemler, ortaya çıkan ürün o istemleri yüzde yüz karşılasa bile projenin sonraki aşamalarında farklı biçimde dile getirilir. “…Ama bizim istediğimiz bu değildi ki!”, ya da “…bu sistem hiç kimsenin işine yaramaz!”, ya da “…siz bizim istemlerimizi hiç anlamamışsınız!…” gibi yakınmaların duyulması, ne yazık ki bilgi sistemleri projelerinde hiç te seyrek değildir. Bu tür başarısızlıkları en aza indirmek için öncelikle gereksinimleri çözümleyen ekibin işinin ustası olması, yüksek düzeyde iletişim becerisi göstermeleri, ortaya konulan bilgilerin sistematik biçimde belgelenmesi, yanlış anlamaları önlemek için elden gelen duyarlığın gösterilmesi gerekir. Özellikle karmaşık mekanik, elektronik, vb denetim sistemlerinde, gereksinimlerin eksiksiz ve tutarlı biçimde ortaya konulabilmesi için çok sayıda biçimsel betimleme dili geliştirilmiştir. Yazılım mühendisliği konusundaki temel kaynaklar, bu aşamaya yapılacak insangücü ve süre yatırımının, bilgi sistemleri projelerinin başarısında doğrudan doğruya yansıdığında, bu aşamada yapılan hataların sonraki aşamalarda giderilmesinin zor ve pahalı olacağında birleşirler (Finkelstein ve diğerleri, 1991).
Tasarım aşaması, gerekleri belirtilen sistemin kurulması için gereken araç ve altyapıların biraraya getirilmesidir. Bilgisayar programlarının tasarlanması, kullanılacak insan – makine sistemlerinin girdi, çıktı ve süreçlerinin ortaya konulması, kurumsal örgütlenmede ve / ya da işleyişte yapılacak değişikliklerin tanımlanması, hep bu aşamada yapılır. Bilgi sistemlerinde nitelik güvencesinin önemli öğeleri olan belgeleme ve gözden geçirme tasarım aşamasında da büyük önem taşır.
Çağlayan modelinde tasarımın ardından, uygulama geliştirmeye, yani kodlama ve sınama aşamasına geçilir. Eğer gereksinim belirtimi ve ona dayalı olarak geliştirilen tasarım yeterince olgunsa ve nitelikli bir belgelemeyle ortaya konulmuşsa, bu aşama, kullanıcılarla en az etkileşim gerektiren, en “teknik”
