TBML306-Yazılım mühendisliği

Bölüm 1: Yazılım Mühendisliği Gerçeği

1.1. Yazılım Evrimi

Bilgisayarların doğduğu bu yıllarda üretilen yazılımlar temel olarak, yığınsal kökenli (kullanıcı ile birebir iletişimde bulunmayan, işlerin toplu olarak verilip yalnızca yazıcı çıktılarının alındığı) biçimde geliştirilmişti. Ayrıca bugünün bilinen anlamında ürün tarzında değil bütünüyle kendisi için yapılan kuruluşa özel biçimde geliştirme yapılmaktaydı.

Artık bilgisayarlar gelişmiş, bugünün anaçatı bilgisayarları olarak adlandırılan çok kullanıcılı sistemlerin ortaya çıktığı bu çağda, çok kullanıcılı, gerçek zamanlı yazılımlar üretilmeye başlanmıştı. Veri tabanı yönetim sistemleri önce yapılandırılmış kütük sistemleri ile ortaya çıkmıştı. Bugün bile anaçatı bilgisayarlarda kullanılan birçok veri tabanı yönetim sisteminin geçmişi bu yıllara dayanır. Ayrıca bu dönemde, ürün türü yazılımların yavaş yavaş ortaya çıkmaya başlamıştır.

Kişisel bilgisayarların oldukça yaygınlaştığı ve açık sistem mimarisinin tanıtıldığı bu dönemde ürün bazlı yazılımlar oldukça yaygınlaşmış, bilgisayarlar evlere girmiştir. Bilgisayar ağ altyapısının güçlenmesiyle, dağıtık yazılım sistemleri geliştirilmeye başlanmıştır. Yapay us teknolojisinin gelişmesi “akıllı uygulama yazılım”larının üretilmeye başlanmasını sağlamıştır.

Yapay us donanımlarının, paralel donanım mimarilerinin geliştirildiği bu dönemde, uzman sistem yazılımları oldukça gelişmiş ve mikrobilgisayarlar üzerinde yaygınlaşmıştır. Yazılım kalite sağlama olgusunun önem kazandığı bu dönemde, yazılım ile ilgili standartlar olgunlaşmış ve yazılım üretimi ve ürünlerinin değerlendirmesi amacıyla üzere kurumlar oluşmaya başlamıştır.

 1.2. Temel Kavramlar

1.2.1. Yazılım

Yazılım en yalın biçimiyle “Bir sistemin donanım bileşenleri dışında kalan her şey” olarak tanımlanabilir. Yazılım, yalnızca bilgisayar programı ya da programlar kümesi biçiminde algılanmamalıdır. Yazılımı oluşturan bileşenler:

biçiminde açıklanabilir. Yazılım, bütün bu bileşenlerin, belirli bir üretim amacına yönelik olarak biraraya getirilmesi, yönetilebilmesi için kullanılabilecek ve üretilen, yöntem, araç, bilgi ve belgelerin tümünü içerir.

Yazılım, herşeyden önce bir işin bilgisayar aracılığı ile yapılması amacına yöneliktir. Bu nedenle bilgisayarlaştırılmak istenen işin mevcut mantığı yazılıma da yansıtılmak durumundadır. Bu nedenle mantık bileşeni yazılımın en önemli bileşenlerinden biridir.

Her tür yazılım mutlaka bir veri üzerinde çalışmak durumundadır. Söz konusu veri dış ortamdan alınabilir ya da yazılım içerisinde üretilebilir. Yazılımın temel amaçlarından biri de “veri” yi “bilgi”ye dönüştürmektir. Veri işlemeyen yazılımın geliştirilmesi söz konusu değildir.

Yazılım üretimi, bir mühendislik disiplini gerektirir. Mühendislik çalışmalarında izlenen yol ya da kullanılan yaklaşımlar yazılım üretimi için de geçerlidir. Yazılım Yaşam Döngüsü (Bkz Bölüm 2) mühendisler tarafından üretim sırasında kullanılan yaşam döngüsünden esinlenerek oluşturulmuştur. Yazılım üretimi sırasında, bir çok aşamada yapılan ara üretimler, bilgi belge üretimidir (planlama bilgileri, çözümleme bilgileri, tasarım bilgileri, gerçekleştirim bilgileri vb).

Yazılımın insan bileşeni iki boyutludur; Yazılımı geliştirenler ve yazılımı kullananlar. Günümüzde yazılım çok kişili ekiplerle geliştirilme boyutuna gelmiştir. Artık tek kişi ile yazılım geliştirmekten söz edilmemektedir. Bunun temel nedeni yazılımın yaygınlaşması ve boyutlarının büyümesidir. Bu nedenle yazılım üretimi için, takım oluşturma ve takımın uyumlu çalışabilmesi için yöntem kullanımı gerekmektedir. Günümüzde, ülkemizde bile 100 kişi ya da daha fazla sayıda eleman bulunduran yazılım geliştirme ekipleri bulunmaktadır.

Yazılımın ana çıktısı sonuçta bir bilgisayar programıdır. Söz konusu program, işletime alındıktan sonra bakım çalışmaları sürekli olarak gündeme gelir. Bunun iki temel nedeni vardır. Birincisi, hiçbir program bütünüyle her olasılık göz önüne alınarak sınanamaz. Programlarda her zaman hata çıkma olasılığı vardır. İkincisi, işletmeler, doğaları gereği dinamik bir yapıya sahiptir ve süreç içerisinde sürekli olarak yeni istek ve gereksinimler ortaya çıkabilir. Bu tür değişikliklerin mevcut yazılıma da yansıtılması gerekir.

1.2.2. Yazılım-Donanım : Karşılaştırma

Donanım fabrika üretimi biçiminde çoklu üretim ortamlarında. üretilebilir. Bir başka deyişle donanımı üreten bileşenler, aynı üretim ortamında çoklu olarak üretilerek ya da dışarıdan edinilerek üretim hattında birleştirilip ortaya çıkarılabilir. Örneğin, otomobil üretiminde olduğu gibi. Boya, lastik, hava yastığı, güvenlik sistemi vb bir çok bileşen farklı üretim yerlerinde, bazen farklı üreticiler tarafından üretilerek ana fabrikada birleştirme sonucu otomobil üretimi gerçekleşir. Yazılım üretiminde ise durum bundan farklıdır. Bir yazılımı oluşturan parçaların dışarıda var olanlardan edinilmesi yöntemiyle yapılan yazılım üretimleri yok denecek kadar azdır. Bu durum yazılım mühendisliğinde “Yeniden Kullanılabilir Yazılım” olarak bilinmektedir. Günümüzde yazılım üretiminde “Yeniden Kullanılabilir Yazılım” oranı %1-2 dolayındadır. Bu oran giderek artmaktadır. Yazılım bütünüyle insanların oluşturdukları tezgahlarda üretilir.

Her donanımın ya da onu oluşturan parçaların belirli bir kullanım ömrü vardır. Örneğin otomobil fren balatalarının 15 ya da 20 bin kilometre sonra kullanılamaz biçime gelmeleri gibi. Bu durumda ilgili donanım bileşeni, eskisinin aynı işlevi gören yenisiyle değiştirilir. Yazılımda ise bu anlamda bir eskime söz konusu değildir. Yazılımın eskimesi, ancak kulanım süresince ortaya çıkabilecek yeni gereksinimleri karşılayamaması, kullandığı teknolojinin eskimesi biçiminde tanımlanabilir. Hiçbir zaman, belirli bir yazılım bileşeninin eskimeden ötürü asıl kopyası ile değiştirilmesi söz konusu değildir. Yazılım yaşam döngüsündeki bakım aşamasının temel işlevlerden biri de ortaya çıkabilecek yeni gereksinimlerin karşılanmasının mevcut yazılıma ekler yaparak yansıtılmasıdır.

Hatta, bazı durumlarda , bir yazılım üretimi projesinde, fazla personel kullanımı, proje süresini kısaltmaktan çok uzatabilir. Daha çok sayıda personel, daha çok iletişim enerjisi anlamına gelir. Donanım üretiminde ise durum farklıdır. Üretimde daha çok sayıda tezgah ve insan kullanımı, daha fazla sayıda üretim anlamına gelir.

Günümüzde yazılım, yaşamsal önemi olan pek çok konuda kullanılmaktadır. Finansal sistemler, hava kontrol sistemleri, enerji sistemleri, sağlık sistemleri gibi. Japonya’da bir telefon yazılımında çıkan yazılım hatası onbinlerce abonenin birkaç saat telefon konuşması yapamamasına neden olmuştur. Diyaliz makinelerinde kullanılan yazılımların 2000 yılı uyumsuzluğundan ötürü, bir çok diyaliz makinesi çalışamamış ve böbrek hastaları zor durumda kalmıştır. Günümüzde, giderek bilgisayar kullanımı artan toplumlarda yazılım yaşamsal önem taşımaktadır.

Bir çok uygulamada, sistemlerin sürekli olarak ayakta tutulmasını sağlamak amacıyla aynı işi görecek birden fazla donanım aygıtı kullanılır. Öyle ki, sistemlerden biri, bir hata nedeniyle bozulup çalışmaz duruma geldiğinde, diğerinin hiçbirşey olmamış gibi çalışmayı devralması ve sürdürmesi biçiminde planlamalar yapılır. Bir çok kritik uygulamada, birden fazla bilgisayar, diğerinin işini devralacak ve çalıştıracak biçimde kullanılmaktadır. Donanım için geçerli olan bu durum, yazılım için geçerli değildir. Örneğin iki farklı bilgisayar üzerinde aynı işi yapan iki yazılım sisteminin kopyalarının bulunduğunu ve bilgisayarların paralel olarak çalıştırıldığını varsayalım. Yazılımda çıkabilecek bir hata sonucu her iki sistem de duracaktır. Zira, her iki sistemde de aynı yazılım çalışmaktadır. Birinde oluşacak bir hata aynı şekilde ötekinde de oluşur. Eğer sistemlerin bu tür bir yazılım hatası durumunda durmaması isteniyor ise, bu durumda bilgisayarlara aynı yazılım sistemlerinin eş kopyalarının değil, aynı işi gören ve birbirinden farklı ekipler tarafından geliştirilmiş iki farklı yazılım sisteminin yüklenmesi gerekirdi. Kritik yazılım sistemleri (uçak avionics yazılımları vb) için bu tür uygulamalar yapılmaktadır.

1.2.3. Tipik Bir Yazılım Üretim Ortamı

Bilindiği gibi günümüzde yazılım, yazılımevlerinde, büyük kuruluşların bilgi işlem merkezlerinde ve bireysel olarak kişiler tarafından geliştirilmektedir. Tipik bir yazılım üretim oramı incelendiğinde:

• Değişik yetenekte bir çok personel (belgeleme uzmanı, sınayıcı, programcı, çözümleyici vb.)
• Yalnızca yazılımın çıktısı ile ilgilenen ve bilgi teknolojileri konusunda bilgili olmayan kullanıcılar,
• Yeniliğe tepki gösteren kullanıcı ve yöneticiler,
• Yeterince tanımlanmamış, oldukça karmaşık kullanıcı beklentileri,
• Personel değişim oranının yüksekliği,
• Yüksek eğitim maliyetleri
• Dışsal ve içsel kısıtlar (zaman, maliyet, işgücü vb)
• Standart ve yöntem eksiklikleri,
• Verimsiz kaynak kullanımı,
• Mevcut yazılımlardaki kalitesizlik
• Yüksek üretim maliyetleri

gibi olumsuzluklar kolayca gözlemlenebilir. Bir bakıma, bu tür olumsuzlukların giderilmesi amacıyla Yazılım Mühendisliği disiplini geliştirilmiştir.

1.2.4. Yazılım Mühendisliği

Yazılım Mühendisliği, yazılım üretiminin mühendislik yöntemleriyle yapılmasını öngören ve bu yönde yöntem, araç, teknik ve metodolojiler üreten bir disiplindir. Bu bakımdan Yazılım Mühendisliği bir yöntemler kümesi, teknikler kümesi ya da araçlar kümesi olarak değerlendirilebilir. Yazılım üretiminde Yazılım Yaşam Döngüsünde belirtilen aşamaların sistematik olarak izlenmesi ve gerçekleştirilmesi yazılım mühendisliği için ön koşuldur.

Yazılım mühendisliği, yazılım üretimindeki karmaşıklıkları gidermeyi hedefler. Geçmişte kullanılan iş akış şemaları gibi yöntemler, günümüzde, yazılım projelerinin boyutlarının büyümesinden dolayı yetersiz kalmıştır. Öte yandan artık yazılım üretim işi, tek kişinin başarabileceği boyuttan çıkmış ve takım işi biçimine dönüşmüştür. Yazılım mühendisliği bu olgular üzerine önem kazanmıştır.

Günümüzde, doğrudan yazılım mühendisi mezun eden üniversite bölümleri yeni yeni oluşmaya başlamıştır. Daha çok yüksek lisans eğitimi ile başlayan Yazılım Mühendisliği disiplini, lisans düzeyine taşınmaktadır.

Yazılım Mühendisliği ile Mühendislik Yazılımı terimlerinin karıştırılmaması gerekir. Mühendislik yazılımları, daha çok donanım bileşeni ile ilgisi olan (örneğin sürücüler vb) yazılımlardır. Yazılım mühendisliği ise, yazılım mühendisi yetiştirmeyi amaçlayan bir disiplindir.

1.2.5. Yazılım Mühendisi

Yazılım mühendisliği işini yapan kişidir. Değişik bilgisayar bilimi teknolojilerinin ve kişilerin bir bilgi ya da yazılım sistemi oluşturmak amacıyla biraraya getirilmesinde bir bütünleştirici gibi çalışır. Temel hedefi, söz konusu üretimin en az maliyet ve en yüksek nitelikli biçimde yapılmasıdır.

Yazılım Mühendisi bir programcı değildir. Ancak Programcının tüm yeteneklerine sahiptir. Programcı, ağırlıklı olarak kodlama, sınama işi ile ilgilenir. Yani Programlarla ilgilenir. Yazılım Mühendisinin işi daha çok insanlarla ilişkiyi gerektirir. Yazılımın daha çok mantıksal boyutuyla ilgilenir.

Yazılım Mühendisi ile Sistem çözümleyici arasındaki belirgin fark ise, Sistem çözümleyicinin üretimin yalnızca Çözümleme aşamasında, Yazılım Mühendisinin ise tüm aşamalarında yer almasıdır.

 1.2.6. Yazılım Hataları

Yazılım hataları, yazılım yaşam döngüsünde çık önemli yer tutan unsurlardan biridir. Teorik olarak bir program tüm ayrıntıları ile sınanabilir. Ancak, uygulamada bu mümkün değildir. Bu durum aşağıda çok yalın bir örnekle açıklanmaktadır.

Dışarıdan girdi olarak A ve B gerçel sayı değerlerini alıp, bu sayıların toplamını C değişkenine aktararak ekranta görüntüleyen bir bilgisayar yazılımı düşünelim. Bu yazılımın tüm olasılıklarla sınanması demek, çalışılan bilgisayarda tanımlanabilecek tüm gerçel sayı değerlerini A ve B değişkenleri için girdi olarak vererek C değerinin doğru olarak elde edilip edilmediğini araştırmak anlamına gelir. Çalışılan bilgisayardaki gerçel sayı sayısının yaklaşık 264 olduğu varsayılırsa söz konusu programın, bu sayıda farklı A ve B değerleri vererek çalıştırılması ve sonucunun doğruluğunun araştırılması gerekir. Bu da programı 264 kez çalıştırmak anlamına gelir. Her bir çalıştırmanın ve sonucunun doğruluğunu araştırmanun en az 10 saniye sürdüğü varsayılsa bile bu tür bir işin hemen hemen olanaksız olduğu ortaya çıkar.

1.2.6.1. Yazılımların Sınanması

Bir önceki sayfadaki yalın örneği karmaşık programlar için düşündüğümüzde, yazılımın tüm olasılıkların göz önünde bulundurularak sınanmasının olanaksızlığı daha da belirginleşir. Bu durumda yazılım ancak sınırlı sayıda veri ile sınanabilir. Bu amaçla, yazılımın sınanmasına yönelik çeşitli yöntem ve metodolojiler geliştirilmiştir. Sonuç olarak, işletmeye alınan ve üretimi tamamlanmış her yazılım %100 hatasız çalışıyor anlamına gelmez. Her zaman bir hatanın ortaya çıkma olasılığı vardır.

Yazılım üretimi sırasında oluşan hataların dağılımı aşağıda verilmiştir:

Yazılım Üretiminde Hataların Dağılımı
Mantıksal Tasarım	% 20
İşlevsel Tasarım	% 15
Kodlama	% 30
Belgeleme ve Diğerleri	% 35

Yukarıdaki tablodan da görüldüğü gibi, yazılım üretiminde özellikle belgeleme konusunda yapılan hatalar önemli bir yer tutmakta ve bunun doğal sonucu olarak yazılım bakımı zorlaşmakta zaman zaman olanaksızlaşmaktadır.

1.2.6.2. Hataların "Yayılma" Özelliği

azılım üretiminde hatalar "yayılma" özelliğini içerir. Yazılım üretimi aşamalı bir üretim olup; bir aşamanın çıktısı bir sonraki aşamaya girdi olduğundan ötürü herhangi bir aşamada yapılan yanlış izleyen aşamalara otomatik olarak yansır. Bu nedenle hata düzeltme maliyetleri ilerleyen aşamalarda giderek artar. Aşağıdaki Tablo 1.2'de Çözümleme aşamasındaki birim hata düzeltme maliyeti bir olarak alınarak, göreli olarak izleyen aşamalardaki hata düzeltme maliyetleri verilmiştir.

Yazılım Üretiminde Hata Düzeltme Maliyetleri
Çözümleme	1
Tasarım	5
Kodlama	10
Test	25
Kabul Testi	50
İşletim	100

1.2.7. Yazılım Maliyetleri

Günümüzde yazılım maliyetlerindeki artışlar giderek artmaktadır. “Yazılımımızı alırsanız yanında donanımı ücretsiz olarak sağlayacağız” deyişi zaman içerisinde giderek doğrulanmaktadır. Örneğin, günümüzde bir kopyası yüzbin dolar dolayında satılan kurumsal kaynak planlama yazılımlarının bulunduğu gözlemlenmektedir. Öte yandan bir kişisel bilgisayar ise 1000 ABD dolarının altında satılmaktadır. Yazılımın kopyalanma maliyeti ile donanım kopyalama maliyetinin arasındaki farklılık dikkate alındığında, yazılım maliyetlerinin, donanım maliyetlerine oranla oldukça yüksek olduğu ortaya çıkar.

1.2.8. Yazılım Sistemlerinin Sınıflandırması

Yazılım sistemlerinin çeşitli gruplar altında sınıflandırılması mümkündür. Bu bölümde;

İşleve Göre Sınıflandırma
Hesaplama Veri İşleme Süreç temelli Kural temelli	Sayısal Çözümleme CAD Bankacılık Gömülü Sistemleri,Sinyal İşleme Robotik, Yapay Us
Zamansal Özelliklere Göre Sınıflandırma
Toplu (Çevrim-dışı) ) Gerçek Zamanlı	Çevrim-içi
Boyuta Göre Sınıflandırma (SS: satır sayısı)
Küçük (SS <=2,000)	PC Oyunları, Öğrenci Projeleri
Orta (2,000 <= SS <=100,000)	CAD, BDE yazılımları
Büyük (100,000 < SS <= 1 milyon )	İşletim Sistemleri Benzetim Sistemleri
Çok Büyük ( SS > 1 milyon)	Komuta Kontrol Sistemleri, Hava Tahmin Sistemleri Yıldız savaşları Sistemleri

1.2.9. Yazılım Kalite Sağlama

Özellikle 90’li yıllarda önemi giderek artan “Yazılım Kalite Sağlama” etkinlikleri günümüzde yazılım üretiminin vazgeçilmez bir parçası olmuştur. Artık “Kalite” unsurları içermeyen yazılım üretiminden söz edilememektedir. En yalın anlatım biçimiyle, Yazılım Kalite Sağlama, üretim süreci boyunca, ara ürünlere ilişkin kalite standartları geliştirmek ve geliştirmenin bu standartlara uygunluğunun denetilmesi olarak tanımlanır. Kalite sağlama ayrıca sonuç ürünün de belirlenen kalite kriterlerine uygunluğunun sağlanması amacını da taşır. Bazı örnek Yazılım Kalite kriterleri aşağıda verilmiştir:

Yazılım kalite sağlama etkinliklerinin başlıca amaçları, yazılım maliyetlerinin düşürülmesi, yazılım üretiminin yönetiminin kolaylaştırılması, belgeleme ve standart sorunlarının giderilmesi olarak özetlenebilir.

Yazılım kalite sağlama etkinlikleri, üretim ortamına “bir düzen” getirmeyi hedefler. Yönetimin etkin biçimde yapılmasını ve kayıtların düzenli olarak saklanmasını olanaklı kılar.

Sorular

1) Yazılım ile program arasındaki farklılığı belirtiniz.

2) Yazılım ile donanım arasındaki farklılıkları belirtiniz.

3) Bildiğiniz bir paket yazılımın bir kopya fiyatı ile yine bildiğiniz bir donanımın fiyatını karşılaştırınız.

4) Neden yazılım giderek pahalılaşırken, donanım ucuzlamaktadır?

5) Yazılım mühendisliği ile diğer mühendislik disiplinlerini karşılaştırınız.

6) Bu bölümde verilen yazılım sınıflandırmasını dikkate alarak, her sınıflandırma için bir yazılım örneği veriniz.

7) Yazılım mühendisi ile programcı arasındaki farklılığı belirtiniz.

8) Yazılım Kalitesini Tanımlayınız. Yazılım kalitesinin evrensel bir tanımı yapılabilir mi?

Değerlendirme Soruları

 Bölüm 2: Yazılım Geliştirme Yaşam Döngüsü

2.1. Giriş: Temel Adımlar

Yazılım Yaşam Döngüsü, herhangibir yazılımın, üretim aşaması ve kullanım aşaması birlikte olmak üzere geçirdiği tüm aşamalar biçiminde tanımlanır. Yazılım işlevleri ile ilgili gereksinimler sürekli olarak değiştiği ve genişlediği için, söz konusu aşamalar bir döngü biçiminde ele alınır. Döngü içerisinde herhangi bir aşama da geriye dönmek ve tekrar ilerlemek söz konusudur. Bu nedenle yazılım yaşam döngüsünün tek yönlü ve doğrusal olduğu düşünülmemelidir. Yazılım yaşam döngüsü temel adımları:

Planlama: Üretilecek yazılım ile ilgili olarak, personel ve donanım gereksinimlerinin çıkarıldığı, olurluk çalışmasının yapıldığı ve proje planının oluşturulduğu aşamadır.

Çözümleme: Yazılımın işlevleri ile gereksinimlerin ayrıntılı olarak çıkarıldığı aşamadır. Bu aşamada temel olarak mevcut sistemde varolan işler incelenir, temel sorunlar ortaya çıkarılarak, yazılımın çözümleyebilecekleri vurgulanır. Temel amaç, bir yazılım mühendisi gözüyle mevcut yapıdaki işlerin ortaya çıkarılması ve doğru olarak algılanıp algılanmadığının belirlenmesidir.

Tasarım: Çözümleme aşamasından sonra belirlenen gereksinimlere karşılık verecek yazılım ya da bilgi sisteminin temel yapısının oluşturulması çalışmalarıdır. Bu çalışmalar, mantıksal tasarım ve fiziksel tasarım olmak üzere iki gruba ayrılır. Mantıksal tasarımda, mevcut sistem değil, bu kez önerilen sistemin yapısı anlatılır. Olası örgütsel değişiklikler önerilir. Fiziksel tasarımda ise yazılımı içeren bileşenler ve bunların ayrıntıları içerilir.

Gerçekleştirim: Tasarım aşaması biten yazılımın kodlama, sınama ve kurma çalışmalarının yapıldığı aşamadır.

Bakım: İşletime alınan yazılım ile ilgili olarak, hata giderme ve yeni eklentiler yapma aşamasıdır. Bu aşama yazılımın tüm yaşamı boyunca sürer.

Yukarıda belirtilen adımlar, yazılım yaşam döngüsünün “çekirdek süreçleri” olarak tanımlanır. Bu süreçlerin gerçekleştirilmesi amacıyla

• Belirtim Yöntemleri
• Süreç Modelleri

kullanılır. Bu konular izleyen kesimlerde açıklanmıştır. Belirtim yöntemleri ve süreç modelleri biraraya gelerek metodolojileri oluşturur.

2.2. Belirtim Yöntemleri

Bir çekirdek sürece ilişkin işlevleri yerine getirmek amacıyla kullanılan yöntemler “belirtim yöntemleri” olarak anılmaktadır. Farklı işlevler için kullanılan belirtim yöntemleri üç sınıfa ayrılabilir.

Süreç akışı için kullanılan belirtim yöntemleri: Süreçler arası ilişkilerin ve iletişimin gösterildiği yöntemlerdir. Veri akış şemaları, yapısal şemalar, nesne/sınıf şemaları, vb bu tür belirtim yöntemlerine örnek olarak verilebilir.

Süreç Tanımlama Yöntemleri: Süreçlerin iç işleyişlerini göstermek için kullanılan yöntemlerdir. Farklı aşamalar için aynı ya da farklı süreç tanımlama yöntemi kullanılabilir. Düz metin, yapısal İngilizce, şablon, karar tabloları, karar ağaçları, algoritma anlatım dili bu tür yöntemlere örnek olarak verilebilir.

Veri Tanımlama Yöntemleri: Süreçler tarafından kullanılan verilerin tanımlanması amacıyla kullanılan yöntemlerdir. Nesne-ilişki modeli, veri sözlüğü, veri tabanı tabloları ya da programlama platformuna bağlı veri tanımlama yöntemleri bu tür yöntemlere örnek olarak verilebilir.

 2.3. Süreç Modelleri

2.3.1. Gelişigüzel Model

Adından da anlaşılacağı gibi, geliştirme ortamında herhangi bir model ya da yöntemin kullanılmadığı, yalnızca geliştiren kişiye bağımlı, daha ötesi geliştiren kişinin bile aradan belirli bir zaman süreci geçtikten sonra anlayamayacağı ve değiştirme güçlüğü yaşanılan ortamlardaki üretim tarzı “Gelişi güzel” model olarak adlandırılmaktadır. Bu modelle üretilen ürünlerin izlenebilirliği, bakılabilirliği oldukça zor, bazı durumlarda olanaksızdır. 60’lı yıllarda, daha çok tek kişilik üretim ortamlarında kullanılan yöntemlerdir.

2.3.2. Barok Modeli

Barok modeli, özet olarak, yaşam döngüsü çekirdek süreçlerinin doğrusal bir biçimde gerçekleştirilmesini öngörür. Kullanılan terminoloji farklı olmasına karşın planlama, çözümleme, tasarım ve gerçekleştirim işlevleri içerilmektedir. Barok modeli 70’li yılların ortalarından başlanarak kullanılmaya başlanmıştır. Bu modelin ayırıcı özelliği, “Belgeleme” olgusuna ayrı bir önem atfetmesi ve belgelemeyi bir süreç olarak ele almasıdır. Belgelemenin , yazılımın geliştirilmesi ve sınanmasından hemen sonra yapılması öngörülmektedir. Günümüzde kulanılan süreç tanımlama yöntemleri ya da metodolojilerde belgeleme biçiminde ayrıca bir işlev bulunmamaktadır. Belgeleme yapılan işin doğal bir ürünü olarak düşünülmekte ve her aşamaya ilişkin bilgi ve belgeler o aşamanın gerçekleştirilmesi sırasında üretilmektedir. Barok modelin diğer bir zayıf tarafı da aşamalar arasındaki geri dönüşlerin nasıl yapılacağının tanımlı olmamasıdır.

Özetle Barok Modeli, gerçekleştirim aşamasına daha fazla ağırlık veren bir model olarak gözlenmekte ve günümüzde kullanımı önerilmemektedir.

 2.3.3. Çağlayan Modeli

2.3.3.1. Çağlayan Modeli Temel Sorunları

Çağlayan Modeli ile geliştirilen uygulamalarda yaşanan temel sorunlar:

• Gerçek yaşamdaki projelerin çok azı yineleme gerektirmez.
• Yazılımın kullanıcıya ulaşma zamanı oldukça uzundur.
• Gereksinim tanımları çoğu kez net olarak yapılamaz, bu konudaki eksiklik ya da yanlışın ortaya çıkma zamanı gerçekleştirim sonrasına rastlar. Bu durumda yanlışların düzeltilme ya da eksikliklerin giderilme maliyetleri oldukça yükselir.
• Yazılım üretim ekiplerinde görev alan programcı ve diğer teknik uzman, gerek yetişme tarzlarından gerekse bilgisayar disiplininin özelliğinden dolayı bir an önce program yazma, kodlama, çalıştırma ve sonucunu görme eğilimindedirler.
• Çağlayan model ise söz konusu işleri üretim aşamasının sonunda öngörmekte, bu aşamaya kadar yapılması gereken işler (planlama, çözümleme, tasarım, kalite etkinlikleri vb.) teknik personel için çoğu kez önemsiz hatta angarya olarak görülebilmektedir. Bu nedenle bu model ile yapılan üretimlerde yazılım ekipleri mutsuz olmakta ve kod yazma dışında olan ve işyükünün yaklaşık %80'ini kapsayan kesimine yeterli önemi vermemektedir. CASE araç ve yöntemlerinin ortaya çıkmaları ve ilgi görmelerindeki en büyük etmenlerden biri budur. CASE araçları sayesinde yazılım ekiplerinin bilgisayar kullanmaya yazılım geliştirmenin erken aşamalarında başlamaları sağlanmaktadır.
• Üst düzey yönetimlerin hedeflenen ürünü görme süresinin uzun oluşu uzun zaman alan projelerde sorunlara yol açmaktadır. Zaman zaman projelerin bitmeyeceği ve sürekli gider merkezi haline geldiği düşüncesi yaygınlaşmaktadır.

2.3.4. V Süreç Modeli

Şekil 2.3 V-Süreç Modeli

V-Süreç Modeli, Çağlayan Modelin uygulanmasını, “Üretim” ve “Sınama” işlevlerinin ne zaman yapılacağını vurgulayarak daha anlamlı hale getirmektedir. Bu nedenle bu model, Çağlayan modelinin bir uyarımı olarak nitelenebilir. Şekil 2.3’den de kolayca görülebileceği gibi V’nin sol tarafı üretim, sağ tarafı ise sınama işlevleri ile ilgilidir. Model aynı zamanda sınama işlemlerinde hata bulma durumunda nereye dönüleceğini de belirtmektedir. Sağ tarafta yapılan sınama işlemlerinde bulunan bir hata durumunda, yatay olarak karşısına gelen sol taraf işlevlerine dönülmektedir. Örneğin sistem sınama işlemlerinde bulunan yanlışların düzeltilmesi amacıyla mimari modelin sol tarafındaki sistem tasarımına dönülmekte, alt sistem tasarımı, modül geliştirme, modül sınama, alt sistem sınama ve sistem sınama işlemleri yinelenmektedir.

V süreç modelinin temel çıktıları: Kullanıcı modeli, mimari model ve gerçekleştirim model olarak adlandırılan üç alt modeldir.

Kullanıcı modeli, geliştirme sürecinin kullanıcı ile olan ilişkilerini tanımlamaktadır. Söz konusu ilişkiler, gerek üretim gerekse kabul (sınama) açısından kullanıcıdan beklenenleri ortaya koymaktadır. Üretim amacıyla, kullanıcı gereksinimlerini tanımlamakta ve bu yolla sistem tanımları ya da belirtimleri ortaya çıkarılmakta, öte yandan sistemin nasıl sınanacağı ya da kabul edileceğine ilişkin sınama belirtimleri ve planları ortaya çıkarılmaktadır.

Mimari Model, sistem tasarımı ve oluşacak alt sistem ve tüm sistemin sınama işlemlerine ilişkin işlevleri içermektedir.

Gerçekleştirim Modeli, yazılım modüllerinin kodlanması ve sınanmasına ilişkin işlevleri içermektedir.

Belirsizliklerin az, iş tanımlarının belirgin olduğu BT (Bilgi Teknolojileri) projeleri için V süreç modeli, uygun bir model olarak gözlemlenmektedir. Model kullanıcının projeye katkısını arttırmaktadır.

V süreç modeli, BT projesinin iki aşamalı ihale şeklinde gerçekleştirilmesi için oldukça uygun görülmektedir. Birinci ihalede, kullanıcı modeli hedeflenerek, iş çözümlemesi ve kabul sınamalarının tanımları yapılmakta, ikinci ihalede ise ilkinde elde edilmiş olan kullanıcı modeli tasarlanıp gerçekleştirilmektedir.

 2.3.5. Helezonik Model

2.3.5.1. Helezonik Model'in Üstün Yönleri

Özellikle büyük ve uzun zaman alan projelerde helezonik model oldukça başarılı sonuçlar vermektedir. Helezonik modelin üstün yönlerini aşağıdaki biçimde sıralayabiliriz:

Kullanıcı katkısı: Helezonik modele göre oluşturulan metodolojiler üretim süreci boyunca ara ürün üretme ve üretilen ara ürünün kullanıcı tarafından sınanması temeline dayanır. Özellikle uzun projelerde kullanıcının erken dönemlerde sürecin içerisine katılması, sürekli geri bildirimler vermesi ve proje bitiminde sürprizlerle karşılaşılmaması gibi olgular üretim başarısını olumlu olarak etkiler.

Yönetici bakışı : Gerek proje sahibi gerekse yüklenici tarafındaki yöneticiler, çalışan yazılımlarla (ara ürün) proje süreci boyunca karşılaştıklarından dolayı daha kolay izleme ve hakediş planlama kolaylığı elde ederler.

Yazılım Geliştirici ya da Mühendisi Bakışı: Yazılımın kodlanma ve sınanması Çağlayan modeline oranla daha erken başlar.

Burada açıklanan biçimiyle Helezonik Model, daha çok bir üst model ya da tanımlama modeli olarak görülmektedir.

 2.3.5.2. Helezonik Model'in Uyarımları

2.3.5.2.1. VP Süreç Modeli

Şekil 2.5 VP- Süreç Modeli

VP süreç modeli, V süreç modelinin sol tarafına (üretim ile ilgili olan) prototip işlevlerinin yüklenmesi ile elde edilir. Gerek kullanıcı modeli gerek mimari model gerekse gerçekleştirim modeli için farklı prototip çalışmaları yapılır. Prototipleme işlevinin temel amacı, ilgili alt modellerde ortaya çıkabilecek belirsizlikleri gidermek dolaysıyla riskleri azaltmaktır. Prototip çalışması araştırma türü bir çalışma olabileceği gibi sonradan atılacak bir yazılım parçası olabilir. Burada sözü edilen prototip çalışması tüm sistemin prototipinin geliştirilmesi ya da prototiplemeyi bir sistem geliştirme yaklaşımı olarak kullanmak değildir. Aşağıda iki prototip çalışması türü örneği verilmektedir.

Örnek-1: Bir BT çalışması sırasında sistem çözümleme ve sistem gerekleri belirtimlerinin üretimi çalışmasında (Kullanıcı Modeli) kullanıcının defter üzerinde sakladıkları bilgilerin deferlerde ne oranda dolu ya da boş olduklarını ve hangi sıklıkta günlendiğini öğrenmek istediğinizi varsayalım. Bu bilginin sizin için veri tasarımı yapmanız açısından çok önemli olduğunu düşünelim. Elinizde toplam olarak yaklaşık beş milyon kayıt içeren yüzlerce defter olduğunu varsayarsak, aradığınız sorunun yanıtını bulmak için yapacağınız çalışma bir prototip çalışması olacaktır. Bu çalışmayı yapmak için istatistiksel yöntemler kullanıp, seçeceğiniz örneklem (sınırlı sayıda defter) üzerinde uygulayarak sorunuzun yanıtı konusunda fikir edinebilirsiniz. Görüldüğü gibi, bir belirsizliği gidermek için bir araştırma yaptınız ve bu araştırma için kullandığınız yöntem ve araçların sizin geliştireceğiniz yazılım ile doğrudan ilgisi yok. Sonuçları aldıktan sonra araştırmanıza ilişkin kullandığınız yöntem ve araçların sizin için artık önemi yok.

Örnek-2: Kullanacağınız bilgisayarın oldukça büyük veri tabanlarında (örneğin 100 milyon kayıt) erişim performansını araştırmak istiyorsunuz. Ancak milyonlarca kaydı bilgisayar ortamına aktarma şansınız yok. Bu durumda bilgisayarınızda büyük bir veri tabanı oluşturmak ve gerek rasgele gerekse sıradan erişimler yapıp performansını ölçmeniz gerekiyor. Bunun için yapmanız gereken, elinizdeki veri tabanı yönetim sisteminin olanaklarını kullanarak yazacağınız bir program ile otomatik olarak oldukça büyük bir veri tabanı yaratabilir, bir başka program ile de erişim sınamaları yapabilirsiniz. Sonuçları aldıktan sonra da bu programlar sizin için artık anlamsızdır.

Bir prototip geliştirimindeki iş adımları:
n100 Belirsizliği tanımla
n200 Çözümleri tanımla
n300 Prototip çalışması yap
n400 Belirsizliğin sonucunu elde et

biçimindedir. Prototiplemenin temel aksak yönü, kaynak maliyetlerinin kestirimindeki zayıflığıdır. Bir prototip çalışmasının ne kadar süreceği, ne kadar iş yükü gerektireceği kolayca kestirilememekte ve yönetimi zorlaşmaktadır.

2.3.5.2.2. Evrimsel Geliştirme Süreç Modeli

Şekil 2.6 Evrimsel Geliştirme Süreç Modeli

Bu model aynı zamanda “ilk tam ölçekli model” olarak ta bilinmektedir. Her aşamada üretilen ürünler, üretildikleri alan ya da saha için tam işlevselliği içermektedir. Evrimsel Geliştirme Süreç modeli, daha çok coğrafik olarak geniş alana yayılmış, çok birimli organizasyonlar için önerilmektedir. Bu tür kuruluşlar için yapılan geliştirmelerde “pilot yaklaşımı” izlenmektedir. Pilot yaklaşımı, çok birimli bir kuruluşun sınırlı sayıda birimi için tam işlevselliğe sahip sistemlerin geliştirilmesi ve uygulamaya alınması, belirli bir süre sonra uygulama eksiklikleri giderildikten sonra diğer birimlere taşınmasını öngörmektedir. Diğer birimlere taşınma sırasında, o birimde bulunan farklı işlevlerde sisteme eklenerek taşıma yapılmaktadır. Bu nedenle her bir birim farklı bir sistem evrimi olarak düşünülmektedir. Örneğin, bu model, çok birimli banka uygulamaları için oldukça uygun görülmektedir.

Modelin başarısı büyük ölçüde ilk evrimin başarısına bağlıdır. Çünkü diğer tüm evrimler ilk evrimin üzerine inşa edilmektedir.

Evrimsel geliştirme modelinin iş bölümlemesi:

0000 Tüm geliştirmeyi planla
1000 Birinci evrimi üret
1000 İkinci evrimi üret
………
n000 n’inci evrimi üret
her evrim için
k100 evrimi planla
k200 evrimi üret
k300 evrimi kur ve çalıştır

biçimindedir. Modelin temel sorunu değişiklik denetimi ve konfigürasyon yönetimidir (Bkz. Bölüm 11).

2.3.5.2.3. Artımsal Geliştirme Süreç Modeli

Bu model aynı zamanda “Belirli özellikleri içeren model” olarak ta anılmaktadır. Modelde üretilen ve uygulamaya alınan her ürün sürümü birbirini içerecek şekilde giderek artan sayıda işlev içerecek biçimde geliştirilmektedir. Öncelikle ürüne ilişkin çekirdek bir kısım geliştirilerek uygulamaya alınmakta ardından yeni işlevsellikler eklenerek yeni sürümler elde edilmektedir. Modelin, Evrimsel Geliştirme Süreç modelinden farkı, her artımda üretilen ürünlerin tam işlevselliği olmaması, bazı işlevlerinin eksik olmasıdır. Üretimin sonunda elde edilen ürün tam işlevselliğe sahip olmaktadır. Kolay algılanması amacıyla, şöyle bir örnek verilebilir. Öğrencilere, bir dönem boyunca geliştirmeleri gereken bir programlama ödevi verildiğini ve her 2 haftada bir ödevin gelişiminin öğretmen tarafından izleneceğini varsayalım. İlk izlemede, büyük bir olasılıkla önünüze gelen programlarda bazı seçenekleri seçtiğinizde “Bu kısım henüz yazılmadı” biçiminde iletiler alacaksınız. Sonraki izlemelerde bu tür iletiler giderek azalacak ve dönem sonunda hiç kalmayacaktır. Bu tür bir geliştirme tarzı, artımsal geliştirme tarzıdır.

Şekil 2.7 Artımsal Geliştirme Süreç Modeli

Artımsal Geliştirme Süreç Modelinin temel iş bölümleme yapısı aşağıda belirtilmektedir:

1000 Tüm geliştirmeyi planla
2000 Taslak kullanım kılavuzları Üret
3000 Tasarım Yap
4000 Çekirdeği üret
4100 Çekirdek için gerçekleştirim modeli üret
4200 Çekirdek yazılımı üret

5000 Birinci Artımı üret
5100 Birinci Artım için gerçekleştirim modeli üret
5200 Birinci Artım yazılımını üret
5300 .....
5n00 Modeli çekirdekle birlikte gözden geçir
6000 İkinci Artımı üret
6100 İkinci Artım için gerçekleştirim modeli üret
6200 İkinci Artım yazılımını üret
6300 .....
6n00 Modeli çekirdek ve birinci artımla birlikte gözden geçir
……….

Uzun zaman alabilecek ve sistemin eksik işlevsellikle çalışabileceği türdeki projelerde artımsal geliştirme yaklaşımı oldukça uygun bir yaklaşım olarak görülmektedir. Bir taraftan kullanımın diğer taraftan ise üretimin olduğu bir ortam söz konusudur. Bu nedenle, destek birimi ve kullanıcı iletişimi oldukça önem kazanmaktadır. Her artımdan sonra çekirdek sürekli olarak gözden geçirilmekte ve bir sonraki artım, bir öncekini de içerecek tarzda üretim yapılmaktadır. Bu nedenlerle değişiklik yönetimi ve konfigürasyon yönetimi oldukça önem kazanmaktadır.

2.3.5.2.4. Araştırma Tabanlı Süreç Modeli

Bu model “yap-at prototipi” olarak ta bilinmektedir. Araştırma ortamları bütünüyle belirsizlik üzerinde çalışan ortamlardır. Yapılacak işlerden edinilecek sonuçlar belirgin değildir ve bir sonraki adımın iş tanımları büyük ölçüde bir önceki adımın sonuçlarına bağlıdır. Bu nedenle gerek zaman gerekse işgücü planlamasında zorluklarla karşılaşılır. Helezonik modelin “küçük” dönüşleri biçiminde gerçekleştirilir. Geliştirilen yazılımlar genellikle sınırlı kez kullanılır ve kullanım bittikten sonra işe yaramaz hale gelir ve atılırlar. Modelin temel çıktısı, küçük ya da büyük, gelecekteki çalışma adımlarını yönlendirebilecek herhangi bir sonucu üretecek bir yazılım parçası ya da kağıt üzerinde bir araştırmadır.

Bu modelde yapısal bir yönetim yaklaşımı uygulanamaz. Model, zaman ve işgücü kestirimlerinin olanaksızlığı nedeniyle sabit-fiyat sözleşmeleri için uygun değildir.

 2.4. Metodolojiler

2.4.1. Bir Metodoloji Örneği

Bu kesimde Yourdon Yapısal Sistem Tasarımı Metodolojisi özetlenmektedir. Bu metodolojinin seçilme nedeni günümüzde oldukça yaygın olarak kullanılıyor olması ve kolay uygulanabilmesidir. Adından da anlaşılabileceği gibi, metodoloji, nesne kökenli yöntemleri içeren bir metodoloji değildir. Yourdon Yapısal Sistem Tasarımı Metodolojisi, Çağlayan modeli temel olarak alan ve yapısal sistem geliştirme yöntemlerini içeren bir metodolojidir. Günümüzde birçok bilgisayar destekli yazılım mühendisliği aracı (CASE aracı) bu metodolojiyi doğrudan desteklemektedir. Bu bölümde metodolojinin yalnızca bir tablo (Tablo 2.1) şeklinde temel özeti verilmektedir. Metodoloji, bölüm 2.4’te açıklanan tüm bileşenleri içermektedir.

Aşama	Kullanılan Yöntem/Araçlar	Ne için kullanıldığı	Çıktı
Planlama	Veri Akış Şemaları, Süreç Belirtimleri, görüşme Maliyet kestirim yöntemleri Proje Yönetim Araçları	Süreç İnceleme   Kaynak Kestirimi Proje Yönetimi	Proje Planı
Çözümleme	Veri Akış Şemaları, Süreç Belirtimleri, Görüşme Nesne İlişki şemaları, Veri Sözlüğü	Süreç Çözümleme Veri Çözümleme	Sistem Çözümleme Raporu
Çözümlemeden tasarıma geçiş	Akışa dayalı çözümleme, Süreç Belirtimlerinin Program tasarım diline dönüştürülmesi Nesne ilişki şemalarının veri tablolarına dönüştürülmesi	Başlangıç Tasarım Ayrıntılı Tasarım   Başlangıç Veri Tasarımı	Başlangıç Tasarım Raporu
Tasarım	Yapısal Şemalar Program Tasarım Dili Veritabanı tabloları Veri Sözlüğü	Genel Tasarım Ayrıntılı Tasarım Veri Tasarımı	Sistem Tasarım Raporu

Tablo 2.1 Yourdon Yapısal Sistem Tasarımı Metodolojisi Özeti

Bölüm Özeti

Herhangibir BT projesine başlanılmadan önce, planlama aşamasında mutlaka bir metodoloji çalışması yapılmalıdır. Sözkonusu çalışma, kalite yönetimi ve ekiplerle birlikte yapılmalıdır. Ekiplerin ve kalite yönetiminin dışında oluşturulan bir metodolojinin benimsenmesi ve uygulanması zordur. Ya varolan metodolojilerden biri benimsenmeli, ya da bir metodoloji geliştirilmelidir. Aksi durumda projenin batacağı kesindir.

Metodolojilerin oluşturulması göreli olarak kolay ancak uygulaması zordur. Üretim ekipleri metodolojileri genelde fazla bürokrasi olarak görürler. Bu konuda proje yönetimi ve Kalite yönetimine önemli roller düşmektedir. Zaman zaman zorlamalarla metodoloji kullanımının mutlaka sağlanması gerekir.

Metodoloji kullanımı, iş sahibi kuruluş açısındanda çok önemlidir. Bilinçli bir alıcı, metodoloji kullanımını adım adım denetlemelidir. Aksi durumda projenin izlenebilirliği olanaksız olur. Projenin başarısı tehlikeye girer.

Sorular

1) Yazılım yaşam döngüsünün temel adımlarını açıklayınız.

2) Süreç modelleri ve belirtim yöntemlerinin önemini belirtiniz.

3) Süreç modeleri ile belirtim yöntemleri arasındaki farklılıkları belirtiniz.

4) Barok modeli tanımlayınız , yararlarını ve aksak yönlerini belirtiniz.

5) Çağlayan modeli tanımlayınız , yararlarını ve aksak yönlerini belirtiniz.

6) Helezonik modeli tanımlayınız, ayrırcı özelliklerini belirtiniz. Yararlarını ve aksak yönlerini açıklayınız.

7) V model kullanılarak geliştirlecek örnek bir proje tanımı yapınız.

8) VP süreç modeli ile geliştirilecek bir projede uygulanabilecek üç prototipleme örneği veriniz.

9) Evrimsel Geliştirme süreç modelinde Konfigürasyon yönetimi ve değişiklik denetimi neden sorundur?

10) Artımsal geliştirme süreç modelini tanımlayınız, yararlı ve aksak yönlerini belirtiniz.

11) Artımsal geliştirme süreç modeli kullanılarak geliştirilecek bir proje örneği veriniz. Gerekçenizi açıklayınız.

12) Araştırma tabanlı süreç modeli için uygun proje örnekleri veriniz.

13) Metodolojiyi tanımlayınız. Bildiğiniz metodoloji örneklerini listeleyiniz.

14) Yourdon Yapısal Sistem Geliştirme Metodolojisini tamamlayınız.

15) Süreç modelleri, belirtim yöntemleri ile metodolojiler arasındaki ilişkiyi belirtiniz.

Değerlendirme Soruları

 Bölüm 3: Yazılım/Bilgi Sistemi Geliştirme Aşamaları

3.1. Planlama

Yazılım geliştirme sürecinin ilk aşaması, planlama aşamasıdır. Başarılı bir proje geliştirebilmek için projenin tüm resminin çıkarılması gerekmektedir. Bu resim, proje planlama çalışmaları sonucunda üretilir. Bu çalışmalar, bir inşaata başlamadan yapılan çalışmalara benzer. İnşaat terminolojisinde kullanılan, statik proje, mimari proje, avam proje, elektrik projesi gibi projelerin tümünde yapılan işlemlerin yazılım için eşdeğer olanları, yazılım mühendisliğinde, proje planlama aşamasında yapılır.

Proje planlama aşamasında yapılması gereken çalışmalar;

Proje kaynaklarının belirlenmesi Proje maliyetlerinin kestirilmesi Proje ekip yapısının oluşturulması Ayrıntılı proje planı yapılması Projenin izlenmesi

biçiminde özetlenebilir. Bu konulara ilişkin açıklamalar izleyen alt bölümlerde verilmektedir. Proje planlama aşamasının temel çıktısı olan proje planı, bir sonraki aşamada bir kez kullanılacak bir çıktı değildir. Proje planı, tüm proje süresince sürekli olarak kullanılacak, günlenecek, gözden geçirilecek bir belgedir. Bu bağlamda, Planlama aşaması, diğer aşamalardan farklıdır.

3.2. Proje Kaynakları

Bir yazılım projesinde yer alacak kişilerin olası görev tanımları aşağıda verilmektedir.

• Proje Yöneticisi
• Kalite Uzmanı
• Yazılım Ekip Lideri
• Donanım Ekip Lideri
• Web Tasarımcısı
• Donanım Mühendisi
• Proje Sekreteri
• Bilgisayar Ağ Uzmanı
• Sistem Çözümleyici
• Yazılım Destek Elemanı
• Sistem Tasarımcı
• Donanım Destek Elemanı
• Programcı
• Eğitim Ekip Lideri
• Sistem Yöneticisi
• Eğitmen
• Veri Tabanı Yöneticisi
• Denetleyici
  
• Kalite Sağlama Yöneticisi
• Çağrı Merkezi Elemanı

Yukarıda verilen görev tanımlarına, içerik sağlayıcılar ya da yazılım projesinin konusuna bağlı olarak gerekebilecek senaryo uzmanları, çoklu ortam uzmanları ve danışmanlar dahil edilmemiştir. Yazılım projesinin boyutuna göre bu görev tanımlarının tümünde görev yapacak elemanlar tam zamanlı olarak ya da parça zamanlı olarak kullanılabilir. Planlama, hangi tür elemanların, hangi süre ile ve projenin hangi aşamalarında yer alacağını belirler. Süre kestirimlerinin nasıl yapılacağı, proje maliyetleri ile ilgili bölümde anlatılmaktadır.

Günümüzde donanım sistemleri giderek açık sistem mimarisine dönüşmektedir. Geçmişteki marka bağımlılığı giderek ortadan kalkmaktadır. Yazılım projelerinde kullanılacak donanım kaynakları:

• Ana bilgisayarlar
• Sunucular (Web sunucu, e-posta sunucu, Veri Tabanı Sunucuları vb)
• Kullanıcı bilgisayarları
• Yerel alan ağı alt yapısı
• Geniş alan ağı alt yapısı

olarak sınıflandırılabilir. Donanım kaynakları planlanırken, yazılımın geliştirileceği ortamın, gerçek kullanım ya da uygulama ortamı dışında bulundurulmasına özen gösterilmelidir. Burada, geliştirilme sırasında ortaya çıkabilecek donanımsal hataların uygulamayı etkilememesi amaçlanmaktadır. Öte yandan, geliştirme ortamı ile uygulama ortamlarının aynı konfigürasyonda olmaları, ileride, kurulum sırasında ortaya çıkabilecek taşıma sorunlarını büyük ölçüde giderecektir.

Günümüzde, yazılım projelerinin geliştirilmesinde kulanılan araç ve yöntemler büyük ölçekte otomatik hale getirilmiş ve bilgisayar destekli olarak kullanılmaktadır. Bilgisayar destekli bu araçlar, Bilgisayar Destekli Tasarım (BDT) ya da Bilgisayar Destekli Mühendislik (BDM-CASE) araçları olarak bilinmektedir. Bu araçların bazıları aşağıda açıklanmaktadır.

İş Sistemleri Planlama Araçları: İş sistemleri planlama araçları, kurumlardaki iş akış yapısının üst modelinin üretilmesinde kullanılmaktadır. Bilgi akışı, bilgi yapısı, iş birimlerindeki tıkanıklıklar bu araçlar kanalıyla ortaya çıkarılır.

Proje Yönetim Araçları: Proje yöneticisi tarafından, projede yapılan işlerin izlenmesi, kaynak ataması, proje iş yapısının üretilmesi, gözlenen değerlerin işlenmesi türündeki işlerin yapılmasını sağlayan araçlardır.

Çözümleme ve Tasarım Araçları: Çözümleme ve Tasarımda kullanılan modelleme tekniklerini ayrı ayrı ya da bütünleşik olarak uygulayan araçlardır. Bu araçlar, aynı zamanda üretilen modelin kalitesinin ölçülmesine ilişkin yöntemleri de içermektedir.

Programlama Araçları: Sistem yazılım kulanıcı yordamları, metin düzenleyiciler, derleyiciler, hata ayıklayıcılar, nesne kökenli programlama araçları, görsel programlama platformları türündeki programlama araçları yazılım geliştirmede kullanılması kaçınılmaz araçlardır.

Sınama Araçları: Kapsam çözümleyiciler, sınama verisi üreticiler, otomatik sınama yordamları, yazılımın doğrulama ve geçerleme işlemlerinde kullanılmaktadır.

Prototipleme ve Benzetim Araçları: Bu araçları temel olarak, geliştirmenin erken aşamalarında kullanıcıya, sonuç ürünün çalışması ile ilgili fikir vermek ve yönlendirmek amacıyla kullanılmaktadır. Basit ekran oluşturma işlevi görenlerinden, gerçek zamanlı sistemler için zaman ve süreç benzetimi (uçak simulatörleri gibi) yapanlara kadar geniş bir yelpazeye yayılmışlardır. Bu araçlar sayesinde, kullanıcı sonuçta elde edeceği ürünün davranışı ile ilgili bilgiler edinir ve sonradan ortaya çıkabilecek farklı yorum ve algılamalar önlenmiş olur.

Bakım Araçları: Program bakımını kolaylaştıran, programın anlaşılmasına yönelik olarak kullanılan tersine mühendislik ya da yeniden mühendislik araçları bakım araçlarına örnek olarak verilebilir. Bu araçlar, verilen bir kaynak kodundan, program şemalarının üretilmesi, program veri yapısının ortaya çıkarılması gibi işlevleri yerine getirirler.

Destek Araçları: İşletim sistemleri, belge işleme sistemleri, ağ yazılımları, elektronik posta ve ortam yönetim araçları, bu araçlara örnek olarak verilebilir.

 3.3. Proje Maliyetleri

Maliyet kestirimi, herhangibir bilgi sistemi ya da yazılım için gerekebilecek iş gücü ve zaman maliyetlerinin üretimden önce belirlenmeye çalışılması için yapılan işlemler olarak tanımlanabilir ve bilgi sistemi geliştirme projesinin zaman ve iş planlaması açısından oldukça önem taşır. Giderek artan geliştirme maliyetleri, projelerin uzun zaman aralığına yayılması ve bitirilememesi gibi etkenler, sözkonusu maliyetlerin ayrı bir önemle ele alınmasını gerektirmiş ve bu konuda çeşitli yöntemler geliştirilmiştir. Maliyet kestirim yöntemleri olarak anılan bu yöntemler, geçmiş projelere ilişkin bilgiler, proje ekibinin deneyimleri, izlenen geliştirme modeli gibi unsurları kullanırlar ve duyarlık artırmak amacıyla, geliştirme süreci boyunca birden çok kez uygulanma yoluyla yaşama geçirilirler.

Geliştirme süreci içerisinde maliyet yönetimi önemli bir yer tutar. Maliyet yönetimi sayesinde;

gecikmelerin önlenmesi, bilgi sistemi geliştirme sürecinin kolaylaştırılması , daha etkin kaynak kullanımının sağlanması, iş zaman planının etkin olarak gerçekleştirilmesi, ürünün sağlıklı olarak fiyatlandırılması, ürünün zamanında ve hedeflenen bütçe sınırları içerisinde bitirilmesi

sağlanır. Maliyet yönetimi genellikle üretim sürecinin değişik aşamalarında bir önceki aşamanın ve daha önce başarılmış olunan projelerin gözlemlenen somut bilgileri ya da geri bildirimleri kullanılarak ileriye yönelik olarak yapılacak kestirimler kümesi olarak tanımlanır. Bu bağlamda Maliyet Kestirim yöntemleri, proje yönetimde önemli yer tutar.

3.3.1. Gözlemlenebilecek Değerler

Bir projenin tümü ya da belirli bir kısmı bitirildikten sonra projeye ilişkin bir takım bilgiler daha sonraki projelerde maliyet kestirimi açısından oldukça önem taşır. Bu bilgiler, kolayca gözlemlenebilen, ayrıca üretkenlik açısından da önem taşıyan bilgilerdir. Bu tür bilgilere örnek olarak;

Projenin (başlangıçtan sonuca) toplam süresi Projenin (başlangıçtan sonuca) toplam maliyeti Projede çalışan eleman sayısı, niteliği, çalışma süreler Toplam satır sayısı Bir satırın parasal maliyeti (Ortalama) Bir kişi-ay da gerçekleştirilen satır sayısı Ortalama) Toplam işlev noktası sayısı Bir işlev noktasının parasal maliyeti (Ortalama) Bir ayda gerçekleştirilen işlev noktası sayısı (Ortalama) Bir kişi-ay da gerçekleştirilen işlev noktası sayısı Ortalama) Bir kişi-ay maliyeti

verilebilir. Görülebileceği gibi bu değerler bitirilmiş projeler için kolayca edinilebilir. Burada sözü edilen satır sayısı kullanılan uygulama geliştirme ortamına bağlı olarak (3. Kuşak dili, 4. kuşak dili, CASE aracı vb) elde edilen kaynak program satır sayısını belirtmektedir.

 3.3.2. Maliyet Kestirim Yöntemleri

En sık kullanılan maliyet kestirim yöntemlerinin bazıları Tablo 3-1’de verilmiştir. Bu yöntemler incelendiğinde, çeşitli biçimlerde sınıflandırmalar yapılarak gruplandırılabilir.

Yöntem/Model Adı	Yıl	Yöntem/Model Adı	Yıl
Delphi	1867	SOFTCOST	1981
Nelson's SDC	1966	Bailey&Basili Model	1981
Satır Sayısı	1970	Kolay Belgele	1982
İşgücü bölümlemesi	1970	SPQR	1984
Wolverton	1974	Bang Metrics	1984
RCA Price-S System	1976	Feature Points	1986
Software Science	1977	Mark II Function Points	1988
Walston and Felix Model	1977	Pfleeger Model	1989
Esterling	1980	Tasarım Modeli	1991
Parr Model	1980	TIC	1991
Maliyet Kestirim Metodolojisi	1991

Sınıflandırma-1: Bu sınıflandırmada, yöntemler, proje boyut türüne göre gruplandırılır. Buna göre yöntemler, Proje büyüklüğünü (Satır sayısı, işlev Sayısı vb) kestiren yöntemler ve Proje zaman ve iş gücünü kestiren (kişi-ay, ay gibi) yöntemler olarak iki gruba ayrılırlar.

Sınıflandırma-2: Yöntemler uygulandıkları projelerin büyüklüğüne göre sınıflandırılır. Makro yöntemler büyük boyutlu projeler (Örneğin 30 kişi- yıl ve daha fazla), mikro yöntemler, orta ve küçük boyutlu projeler için kestirimleri içerir.

Sınıflandırma-3: Yöntemler uygulanış biçimlerine göre sınıflandırılmaktadır. Buna göre yöntemler çok yalın düzeyde, orta ayrıntı düzeyinde ve çok ayrıntı düzeyinde uygulanabilen yöntemler olarak üç grupta sınıflandırılabilir.

Sınıflandırma 4: Bu sınıflandırmada yöntemler, projenin değişik aşamalarında kullanılabilirliklerine göre sınıflandırılabilir. Buna göre yöntemler; Planlama ve Çözümleme aşamasında kullanılabilecek yöntemler, Tasarım aşamasında kullanılabilecek yöntemler ve gerçekleştirim aşamasında kullanılabilecek yöntemler olarak üç sınıfta toplanır.

Sınıflandırma-5: Yöntemler yapılarına göre sınıflandırılabilir. Buna göre; Uzman deneyimine fazlasıyla gereksinim duyan doğrusal kestirim yöntemleri ve önceki projelerden edinilen geri bildirimleri kullanarak üretilen katsayıları kullanan, genellikle doğrusal olmayan denklemleri kullanan kestirim yöntemleri olmak üzere iki grupta toplanır.

Yöntemler ayrıntılı olarak incelendiğinde hepsinde ortak olan özellikler:

1. Projenin uygulandığı aşamaları temel olarak girdi alması,
2. Projeye ilişkin çevresel özellikleri girdi olarak alması,
3. Doğrusal ya da doğrusal olmayan denklemler kullanması,
4. Projeye ilişkin, satır sayısı, işlev nokta sayısı, zaman, iş-gücü (kişi-ay), parasal maliyet gibi çıktılar vermesi,

olarak göze çarpar. Projenin zaman ve bütçe planlaması açısından özellikle yukarıda belirtilen son özellik büyük önem taşımaktadır. En sık kullanılan maliyet kestirim yöntemlerinden ikisi (İşlev Noktaları ve etkin maliyet yöntemi COCOMO) ve Maliyet Kestirim metodolojisi, izleyen kesimlerde açıklanmaktadır.

 3.3.2.1. İşlev Noktaları Yöntemi

İşlev noktaları, geliştirmenin erken aşamalarında (çözümleme aşamasında) saptanan bir değerdir. Bu değer sistemin oluşturulduğu uygulama geliştirme ortamından bağımsız olarak elde edilmektedir. Işlev noktalarının hesaplamasında problem tanımı girdi olarak alınarak üç temel adım izlenir:

Problemin bilgi ortamının incelenmesi: Bu aşamada problemle ilgili temel girdiler, çıktılar, kütükler, sorgular ve arayüzler incelenir.

Problemin Teknik karmaşıklığının incelenmesi: Probleme ilişkin dışsal etkenlerin değerlendirilmesi yapılır.

İşlev Noktası hesaplama: Bilinen ve sık kullanılan deneysel formül kanalıyla ilk iki adım sonucundaki bulgular kullanılarak işlev nokta sayısı belirlenir.

Özellikle, çözümleme çalışması, yapısal yöntemlerle yapıldığında, işlev noktaları yarı otomatik bir biçimde kolayca elde edilebilir. İşlev noktaları yönteminin proje geliştirme sürecinin erken aşamalarında oldukça etkili olduğu belirtilmektedir.

3.3.2.1.1. Problem Bilgi Ortamının İncelenmesi

Tablo 3.2’de belirtildiği gibi, Problem Bilgi ortamı, 5 ana bileşenden oluşur.

Ölçüm ParametresiSayı	Sayı	Ağırlık faktörü
		Yalın	Ortalama	Karmaşık
Kullanıcı Girdi sayısı		3	4	6
Kullanıcı Çıktı Sayısı		4	5	7
Kullanıcı Sorgu Sayısı		3	4	6
Kütük sayısı		7	10	15
Dışsal arayüz sayısı		5	7	10
Toplam Sayı

Tablo 3.2 Problem Bilgi Ortamı Bileşenleri

Yazılıma girdi olarak verilen her farklı uygulama bileşeni bir kulanıcı girdisi olarak sayılır. Kulanıcı girdilerinin sayısı hesaplanırken, alan bazında değil, daha genel olarak mantıksal kayıt bazında uygulama yapılmalıdır. Örneğin, bir personel sisteminin geliştirilmesinden söz edildiğinde, personel sicil bilgileri, personel izin bilgileri gibi bilgiler ayrı kullanıcı girdileri olarak sayılabilir. Personel sicil no, personel adı soyadı türündeki alan bilgileri kullanıcı girdisi olarak sayılmamalıdır.

Kullanıcıyı ilgilendiren her tür mantıksal çıktı, kullanıcı çıktısı olarak sayılmalıdır. Bu kapsamda kullanıcı çıktılarına örnek olarak, raporlar, ekran çıktıları, hata iletileri vb verilebilir. Girdiler gibi çıktılar da genel olarak sayılmalıdır. Bir raporun içerisindeki bir alan kullanıcı çıktısı olarak sayılmamalıdır. Öte yandan, aynı bilgileri içeren ancak bilgi düzeni ya da sıralaması farklı olan raporlar da ayrı kullanıcı çıktısı olarak ele alınmamalıdır. Örneğin, soyadına göre sıralanmış personel listesi ve sicil no’suna göre sıralanmış personel listesi raporları farklı kullanıcı çıktıları olarak sayılmamalıdır.

Kullanıcı sorgusu, çevrim içi olarak bilgisayara verilen bir girdi sonucu yine çevrim içi olarak bir kullanıcı çıktısı alınması biçiminde tanımlanmaktadır. Her farklı sorgu ayrı olarak sayılmalıdır. Örneğin: Personel sicil bilgilerinin sorgulanması, personel maaş bilgilerinin sorgulanması vb.

Her mantıksal bilgi yığını ya da kütük ayrı olarak sayılmalıdır. Personel sicil kütüğü, personel maaş kütüğü, personel hareket kütüğü vb.

Geliştirilmesi öngörülen bilgi sisteminin, gerek kurum içinde gerekse kurum dışında bir başka bilgi sistemi ile bilgisayar ortamında bir iletişimi (çevrim dışı disket vb ya da çevrim-içi doğrudan bağlantı) söz konusu ise bu durum bir dışsal arayüz olarak sayılmalıdır. Kağıt ya da rapor türündeki arayüzler bir dışsal arayüz sayılmazlar. Örneğin, personel bilgi sistemi, yine aynı kurumda olduğu varsayılan muhasebe bilgi sistemine, personel maaşlarına ilişkin bilgiyi bilgisayar ortamında aktarması bir dışsal arayüz olarak sayılabilir.

3.3.2.1.2. Problem Teknik Karmaşıklığının İncelenmesi

Problem Teknik Karmaşıklık Faktörü (TKF), tablo 3.3’de belirtilen ve problemin karmaşıklığına ilişkin sorulara verilecek yanıtların toplamıyla elde edilir. Uygulama ortamının ve uygulamanın özellikleri dikkate alınarak her soruya 0 ile 5 arasında bir yanıt verilir. Örneğin, 8. soruyu dikkate alalım. Eğer uygulama, ana veritabanının, tümüyle çevrim içi olarak günlenmesini gerektiriyorsa bu durumda yanıtımız 5 olacaktır. Ancak, bazı veri tabanı işlemleri (örneğin %10 gibi) çalışma saatleri dışında, çevrim dışı olarak yapılıyorsa bu durumda 4 gibi bir yanıt verilebilir.

1. Uygulama, güvenilir yedekleme ve kurtarma gerektiriyormu? 2. Veri İletişimi gerekiyor mu? 3. Dağıtık İşlem işlevleri var mı? 4. Performans Kritik mi? 5. Sistem mevcut ve ağır yükü olan bir işletim ortamında mı çalışacak? 6. Sistem, çevrim içi veri girişi gerektiriyor mu? 7. Çevrim içi veri girişi, bir ara işlem için birden çok ekran gerektiriyor mu? 8. Ana kütükler çevrim-içi olarak mı günleniyor? 9. Girdiler, çıktılar, kütükler ya da sorgular karmaşık mı? 10. İçsel işlemler karmaşık mı? 11. Tasarlanacak kod, yeniden kullanılabilir mi olacak? 12. Dönüştürme ve kurulum, tasarımda dikkate alınacak mı? 13.Sistem birden çok yerde yerleşik farklı kurumlar için mi geliştiriliyor? 14. Tasarlanan uygulama, kolay kullanılabilir ve kullanıcı tarafından kolayca değiştirilebilir mi olacak?

Yanıt Kılavuzu:     0 : Hiçbir Etkisi Yok 1: Çok az etkisi var 2: Etkisi Var 3: Ortalama Etkisi Var 4: Önemli Etkisi Var 5: Mutlaka olmalı, Kaçınılamaz

Tablo 3.3 TKF Soruları

3.3.2.1.3. İşlev Nokta Sayısı Hesaplama

Gerek AİN, gerekse TKF önceki bölümlerde açıklandığı gibi hesaplandıktan sonra, geliştirilecek bilgi sistemine ilişkin İşlev Nokta Sayısı (İN) aşağıdaki formül kullanılarak hesaplanır.

İN = AİN x (0.65 x 0.01 x TKF)

İşlev Nokta Sayısı çeşitli amaçlarla kullanılabilir:

Üretkenlik = İN / Kişi-Ay
Kalite = Hatalar / İN
Maliyet = $ / FP

İşlev Noktaları, başka yöntemlerle birlikte kullanılmak istenildiğinde, kullanılacak yazılım geliştirme platformuna göre aşağıdaki değerler kullanılarak kolayca satır-sayısı kestirimine dönüştürülebilir.

Programlama Platformu	Satır Sayısı/İN (Ortalama)
Assembly Dili	300
COBOL	100
FORTRAN	100
Pascal	90
C	90
Ada	70
Nesne-Kökenli Diller	30
4. Kuşak Dileri	20
Kod Üreticiler	15

Örneğin İN kestirimi olarak 300 İN bulduğumuzu varsayalım. Eğer nesne-kökenli bir dil kullanarak (smalltalk gibi) yazılımı geliştirecek isek yaklaşık satır sayısı kestirimi 300x30= 9000 satır olacaktır.

 3.3.2.2. Etkin Maliyet Modeli - COCOMO

COCOMO, 1981 yılında Boehm tarafından yayımlandıktan sonra oldukça ilgi görmüş bir maliyet kestirim modelidir. COCOMO mikro model olarak belirtilen maliyet kestirim modellerine iyi bir örnektir. Uygulama, kulanılacak ayrıntı düzeyine göre üç ayrı model biçiminde yapılabilir:

• Temel Model
• Ara Model
• Ayrıntı Model

Tüm COCOMO modelleri, temel girdi olarak satır sayısı kestirimini alır ve çıktı olarak iş-gücü (Kişi-ay, Kişi-yıl vb) ve zaman (ay, yıl, hafta vb) çıktılarını verir (Bkz. Şekil 3.1).

Şekil 3.1 COCOMO Modelleri

İş gücü değerinin zaman değerine bölünmesiyle yaklaşık kişi-sayısı kestirimi de elde edilmiş olur. Tüm COCOMO modelleri gerek işgücü, gerekse zaman için doğrusal olmayan, üssel formüller kullanır.

İş gücü (K) K = a x Sb
Zaman (T) T = c x Kd
a, b, c, d : her bir model için farklı olan katsayılar
S = bin türünden satırsayısı

Öte yandan COCOMO modeleri farklı türdeki yazılım projelere farklı biçimde uygulanır. Projeler üç biçimde sınıflandırılmaktadır:

Ayrık Projeler, deneyimli ve küçük proje ekipleri tarafından geliştirilecek, boyutları küçük (bir kaç bin satırdan bir kaç on bin satıra kadar) bilgi sistemi projeleridir. Bu tür projelerde, bir donanımın yazılım tarafından sürülmesi ya da yönetilmesi söz konusu değildir. Genellikle, yerel ağ üzerinde çalışan, girdi ve çıktıları tümüyle veri-bilgi tabanlı olan projelerdir. Örneğin, bir kurumun yerel ağ üzerinde çalışan insan kaynakları yönetim sistemi vb.

Yarı-Gömülü projeler hem bilgi boyutu hemde donanım sürme boyutu olan projelerdir.

Gömülü projeler, donanım sürmeyi hedefleyen (avionics, süreç denetimi, pilotsuz uçağı yönlendiren yazılım projeleri vb) ve donanım kısıtları yüksek projelerdir.

3.3.2.2.1. Temel Model

Temel Model, küçük-orta boy projeler için hızlı kestirim yapmak amacıyla kullanılır. Yalnızca, iki COCOMO formülünün kullanılmasından ibarettir.

Kullanılan formüller:

Ayrık Projeler:
K = 2.4 x S1.05 İş Gücü
T = 2.5 x K0.38 Zaman

Gömülü Projeler:
K = 3.6 x S1.20 İş Gücü
T = 2.5 x E0.32 Zaman

Yarı-Gömülü Projeler:
K = 3.0 x S1.12 İş Gücü
T = 2.5 x K0.35 Zaman

Yukarıdaki formüllerden de kolayca görülebileceği gibi, proje karmaşıklığı arttıkça, gerekecek iş gücü de artmaktadır (İş gücü formüllerinde üs katsayılarının farklılaşmasını gözleyiniz). Temel model’in aksak yönlerinden biri, yazılım projesinin geliştirileceği ortam ve yazılımı geliştirecek ekibin özelliklerini dikkate almayışıdır. Bununla birlikte, bir hesap makinesi yardımıyla kolayca uygulanabilme özelliğine sahiptir.

3.3.2.2.2. Ara Model

Ara model, temel modelin eksikliğini gidermek üzere oluşturulmuştur. Bir yazılım projesinin zaman ve iş gücü maliyetlerinin kestiriminde, proje ekibinin özellikleri, projenin geliştirilmesinde kullanılacak araç, yöntem ve ortamı dikkate almak gerekliliği üzerine kuruludur. Örneğin, aynı yazılımı yeni mezun ve deneyimsiz bir ekip ile geliştirmekle, deneyimli bir proje ekibi ile geiştirmek arasında zaman ve iş gücü açısından oldukça farklılıklar vardır. Ara model üç aşamalı olarak uygulanır:

1. Aşama : İş gücü hesaplama:

Ara modelde bu aşamada kullanılacak iş gücü hesaplama formülleri aşağıda verilmiştir.

Ayrık Projeler:  K = 3.2 x S1.05
Yarı Bağımlı Projeler: K = 3.0 x S1.12
Gömülü Projeler: K = 2.8 x S1.20

2. Aşama : Maliyet Çarpanı Hesapla:

Maliyet Çarpanı ( C ) , Tablo 3-4’de belirtilen değerler arasından seçilecek 15 maliyet etmeninin (ci ) çarpımı sonucu elde edilir.

Herbir maliyet etmeninin seçilmesinde yardımcı olacak bilgiler aşağıda verilmiştir.

Tablo 3.4 Maliyet Etmenleri

Maliyet Etmenleri	Seçenekler
	Çok Düşük	Düşük	Normal	Yüksek	Çok Yüksek	Oldukça Yüksek
Ürün Özellikleri
RELY	0.75	0.88	1.00	1.15	1.40	-
DATA	-	0.94	1.00	1.08	1.16	-
CPLX	0.70	0.85	1.00	1.15	1.30	1.65
Bilgisayar Özellikleri
TIME	-	-	1.00	1.11	1.30	1.66
STOR	-	-	1.00	1.06	1.21	1.56
VIRT	-	0.87	1.00	1.15	1.30	-
TURN	-	0.87	1.00	1.07	1.15	-
Personel Özellikleri
ACAP	1.46	1.19	1.00	0.86	0.71	-
AEXP	1.29	1.13	1.00	0.91	0.82	-
PCAP	1.42.	1.17	1.00	0.86	0.70	-
VEXP	1.21	1.10	1.00	0.90	-	-
LEXP	1.14	1.07	1.00	0.95	-	-
Proje Özellikleri
MODP	1.24.	1.10	1.00	0.91	0.82	-
TOOL	1.24	1.10	1.00	0.91	0.83	-
SCED	1.23	1.08	1.00	1.04	1.10	-

Gereken Yazılım Güvenirliği. Yazılımın işletimi sırasında ortaya çıkabilecek bir hatanın kullanıcıya olası etkileri dikkate alınarak seçilir. Örneğin, yazılım hatası geliştiriciler tarafından kısa sürede giderilebilecek bir hata ise ‘çok düşük’, insan yaşamına malolacak kadar etkili ise ‘çok yüksek’ seçeneği seçilir.

Veri Tabanı Büyüklüğü. DATA maliyet etmeninin seçiminde, yazılım tarafından oluşturulacak veri tabanı büyüklüğünün, program büyüklüğüne oranı dikkate alınır. 10-100-1000-10000 kat oranlarına göre ‘düşük’ ile ‘çok yüksek’ arasında seçim yapılır.

Ürün Karmaşıklığı. Geliştirilecek yazılım ürününü karmaşıklığı, genel olarak dikkate alınarak seçim yapılır.

İşletim Zamanı Kısıtı. Geliştirilecek yazılımın, işletileceği bilgisayarın zaman kaynaklarının oranına göre seçim yapılır. Örneğin, söz konusu oran %50 ise ‘normal’, %5 ise ‘oldukça yüksek’ seçeneği seçilir.

Ana Bellek Kısıtı. TIME maliyet etmenindeki örnekleme, yazılımın işletileceği bilgisayarın ana bellek kullanım kısıtları dikkate alınarak yapılır.

Bilgisayar Platform Değişim olasılığı. Yazılımın geliştirildiği bilgisayar platformu ile ilgili olası değişiklikler dikkate alınarak seçim yapılır. Ana bellek ya da disk sığalarının arttırımı, bilgisayarın bir üst modele yükseltimi, kapalı sistemlerden açık sistemlere geçiş gibi durumlar dikkate alınarak ‘düşük’ ile ‘çok yüksek’ arasında seçim yapılır.

Bilgisayar iş geri dönüş zamanı. Programcıya yönelik olarak işin geri dönüş zamanı dikkate alınarak seçim yapılır. Örneğin, etkileşimli sistemler için '‘düşük’, geri dönüş süresi 12 saatten fazla olan sistemler için ‘çok yüksek’ seçenekleri seçilebilir.

Çözümleyici yeteneği. Çözümleyici ekibin deneyimi, birlikte çalışabilirliği iş gücü maliyetlerini oldukça etkilemektedir. Yeni mezun kişilerden oluşan bir ekip için ‘düşük’, ortalama deneyimleri 5 yıldan fazla olan bir ekip için ‘çok yüksek’ seçeneği seçilebilir.

Uygulama Deneyimi. Proje ekibinin ortalama uygulama deneyimi dikkate alınarak seçim yapılır. 4 aydan daha az süreli deneyimler için ‘çok düşük’, 12 yıldan daha fazla deneyimler için ‘çok yüksek’ seçenekleri seçilebilir.

Programcı Yeteneği. ACAP maliyet etmenindeki açıklamalar, programcılar için dikkate alınarak seçim yapılır. Söz konusu seçim genel olarak yapılmalı, tek tek programcılar için yapılmamalıdır.

Bilgisayar platformu deneyimi. Proje ekibinin, geliştirme için kullanılacak bilgisayar platformunu tanıma oranı ile ilgilidir. Bir aydan daha az deneyimler için ‘çok düşük’, üç yıldan daha fazla deneyimler için ‘yüksek’ seçenekleri seçilebilir.

Programlama dili deneyimi. Programlama ekibinin, kullanılacak yazılım geliştirme platformuna ilişkin deneyimi dikkate alınarak seçim yapılır. Bir aydan daha az deneyimler için ‘çok düşük’, üç yıldan daha fazla deneyimler için ‘yüksek’ seçenekleri seçilebilir.

Modern programlama teknikleri. Proje ekibi tarafından, modern programlama tekniklerinin (yapısal programlama, yukarıdan aşağıya geliştirme, yapısal metodolojiler vb) kullanım oranı dikkate alınarak ‘çok düşük’ ile ‘çok yüksek’ arasında seçim yapılır.

Yazılım geliştirme araçları kullanımı. Proje ekibi tarafından, bilgisayar destekli yazılım geliştirme araçlarının (CASE araçları, metin düzenleyiciler, ortam yönetim araçları vb) kullanım oranı dikkate alınarak ‘çok düşük’ ile ‘çok yüksek’ arasında seçim yapılır.

3. Aşama : İlk işgücü değerlerini düzeltme

Maliyet Çarpanı ( C ), 2. adımda elde edildikten sonra ilk aşamada elde edilen iş gücü değeri ( K ) ile çarpılarak düzeltilmiş iş gücü değeri ( Kd ) elde edilir.

Kd = K x C

Elde edilen düzeltilmiş iş gücü değeri, temel modelde kullanılan zaman formüllerinden ilgili olanı kullanılarak zaman maliyetleri hesaplanır.

3.3.2.2.3. Ayrıntı Modeli

Ayrıntı Modeli, bu kitabın kapsamında değildir. Ancak ayrıntı modeli, temel ve ara modellere ek olarak iki ek özellik taşımaktadır.

Aşama ile ilgili iş gücü katsayıları:
Yazılım üretiminde, her aşama (planlama-çözümleme-tasarım-geliştirme-sınama-kurulum) eş değer karmaşıklık düzeyine sahip değildir. Ayrıntı modelde her aşama farklı olarak ağırlıklandırılmıştır.

Üç düzey ürün sıra düzeni:
Ayrıntı model, yazılım maliyetlerinin kestiriminde modül-alt sistem-sistem sıra düzenini dikkate almayı gerektirir. Yani kestirimler, önce modül bazında, daha sonra alt sistem bazında ve en sonunda da tüm sistem bazında yapılır.

 3.3.3. Maliyet Kestirim Metodolojisi

3.3.3.1. Metodoloji Gereksinimi

Mevcut maliyet kestirim yöntemlerinin gerek endüstriyel gerekse bilimsel alanlardaki uygulamalarına bakıldığında aşağıdaki gözlemler kolayca edinilebilir:

Maliyet Kestirim Yöntemleri henüz gelişme aşamasındadırlar: Kullanılan kestirim yöntemlerinin bir çoğu kullanıldıkları çevrenin özelliklerine oldukça bağımlıdır. Bir başka deyişle kullanılan denklemler çoğunlukla genel amaçlı değil, kullanıldıkları organizasyondaki verilere bağımlıdır. Çok az sayıda yöntem genel amaçlıdır.

Tek bir yönteme bağımlılık ve sınırlı sayıda kestirim: Uygulamada, kullanan kurumların, yalnızca bir kestirim yöntemini benimsediklerini, bunu da, üretim süreci boyunca çoğunlukla bir kez (planlama aşamasında) ya da iki kez kullandıkları görülmektedir. Bu durumda üretim maliyetlerinin yönetiminden söz edilememekte, denetim zorlaşmaktadır.

Maliyet Kestirim Döngüsü gereksinimi: Bir kestirim yönteminin başarısı, başlangıç aşamasında yapılan kestirimlerle sonuçta elde edilen gerçek değerler arasındaki farkın +/- %30 dolayında olmasıyla ölçülür. Bu nedenle maliyet kestirimi işleminin üretim süreci boyunca yalnızca bir kez değil, değişik aşamalarda birden çok kez uygulanması, projenin zaman ve iş planının sağlıklılığı açısından arıtılması gerekmektedir. Herbir ardışık kestirimin ardından, ilgili aşama ya da adım tamamlandıktan sonra gerçekleşen değerlerle karşılaştırma yapılmalı ve kalan aşamalar için yeniden kestirim yapılmalıdır. Proje geliştirme sürecinde hangi noktalarda kestirim yapılacağı projenin özelliğine, kullanılan üretim modeli biçimine ve proje boyutuna bağlıdır. Ayrıca, üretim süreci, farklı ve bütünleşik aşamalardan oluştuğundan ötürü kullanılacak maliyet kestirim yöntemlerinde de farklılıkların olması gerekmektedir. Bu nedenlerle Maliyet Kestirim döngüsü olarak adlandırılan, üretim yaşam döngüsüne koşut olarak uygulanması gereken bütünleşik kestirim ve arıtım işlemlerine gereksinim vardır.

3.3.3.2. Metodoloji

Şekil-3.2’den de kolayca görülebileceği gibi Maliyet Kestirim Metodolojisi, üretim süreci boyunca uygulanacak iki temel adımdan oluşur:

Şekil –3.2 Maliyet Kestirim Metodolojisi

Bu iki adımın kaç kez uygulanacağı, iş planında belirtilen üretim aşaması sayısı kadardır. Bu adımlar aşağıda ayrıntılı olarak açıklanmıştır.

Adım-1: Maliyet Hesaplama

Temel olarak bu yaklaşım, bilinen maliyet hesaplama yöntemlerinin bir ya da birden fazlasının bütünleşik olarak kullanılmasını içermektedir. Bu yaklaşımın üç temel adımı:

-Boyut Kestirimi
-İşgücü ve zaman Kestirimi
-Değerlerin gerçek zamana dayalı değerlere uyumlanması biçimindedir.

Boyut kestirimi proje büyüklüğü (satır sayısı, işlev nokta sayısı) konusunda uygulanabilecek yöntemleri içerir. Kullanılabilecek örnek yöntemler olarak Satır sayısı kestirim yöntemi, iş gücü kestirim yöntemi, işlev noktaları yöntemi verilebilir.

Zaman ve işgücükestiriminde, önceki adımda hesaplanan boyut bilgisi işgücü (kişi-ay) ve zaman (ay) bilgisine dönüştürülür. Örnek yöntemler olarak COCOMO ve değişik uyarımları verilebilir.

İkinci adımda ham olarak elde edilen işgücü ve zaman bilgileri, çalışma gün ve ortamının değişik özellikleri dikkate alınarak gerçek takvim zamanı bilgilerine dönüştürülür. Bu amaçla kullanılabilecek yönteme örnek olarak Esterling zaman modeli verilebilir.

Adım-2 : Gözleme ve Arıtma

Üretim sürecinin herhangibir aşaması tamamlandıktan sonra ilk bölümde sözü edilen değerler gözlenerek bitirilen adım için yapılan kestirimlerden sapmalar belirlenir, nedenleri araştırılır ve bir sonraki aşama için yeniden kestirim yapılır. Bu biçimde sürekli arıtımlarla kestirilen değerlerle gerçek değerlerin birbirine yakınlaştırılması sağlanır.

 3.4. Proje Ekip Yapısı Oluşturma

Bir yazılım projesinin etkin olarak çalışabilmesi, oluşturulacak proje ekip yapısına büyük ölçüde bağlıdır. Ekip yapısı, projedeki işyükünün işlevsel olarak tanımlanması ve projede çalışan kişiler arasında etkin iletişim oluşturulması amacıyla yapılır. Hemen hemen tüm proje yönetim metodolojileri bir ekip yapısı önerir. Bu bölümde Panda Modellerinin (Arifoğlu, 99) herbirinde öngörülen proje ekip yapısı anlatılmaktadır.

Proje ekip yapıları, hem projeyi yapan yüklenici kuruluş hemde proje sahibi kuruluş tarafında oluşturulmalıdır. Yüklenici tarafında oluşturulacak yapı temel olarak projenin geliştirilmesine, İş sahibi tarafında oluşturulacak yapı ise projenin koordinasyonuna yönelik olmalıdır.

İzleyen bölümlerde PANDA Proje ekip yapısı, yüklenici ve iş sahibi tarafında olmak üzere ayrı ayrı açıklanmaktadır.

3.5. Proje Planı

Proje maliyetlerini, zaman ve iş adımlarını ve proje müşterileri ile olan ilişkileri izlemek amacıyla oluşturulan bilgi ve belgelere Proje Planı adı verilir. Proje planının temel amacı proje sahibinin gereksinimlerini listelemek ve bu gereksinimlerin yüklenici tarafından ne zaman hangi iş gücü ile karşılanacağını belirlemektir. İş sahibi bu planı, proje ile ilgili yapılmakta olan işleri izlemek amacıyla kullanır. Plan, aynı zamanda sistemin tüm amaçlarını içeren bir belge ya da araç olarak ta kullanılabilir. Proje planını oluşturan temel bileşenler yanda belirtilmiştir.

Proje Kapsamı, geliştirilecek sistemin genel tanımını ve sınırlarını içerir. Yalnızca neyin yapılacağı değil neylerin yapılmayacağı da Proje Kapsamında yer almalıdır.

Projede yapılacak işlerin iş adımları, zamanlaması, ara ürünlerin neler olacağı ve ne zaman üretileceği, kimler tarafından üretileceği türündeki bilgiler Proje Zaman-İş Planında yer alır. Bu plan proje geliştirme döngüsü sürecinde neler yapılacağını zaman boyutuyla içerir. Proje Zaman-İş Planını hazırlamak amacıyla geliştirilmiş bir çok araç ve yöntem bulunmaktadır. Bu araçlardan en yaygın olarak kullanılanına örnek olarak MS Project verilebiilir.

Ekiplerin yapılanması da önemlidir. Klasik yaklaşımlarda, bir programcı aynı zamanda ekibin kütüphanecisidir. Bazı durumlarda bu kütüphaneci programlama yapmaz. Görevi, yazılan kodları ve belgeleri sınıflandırmak ve saklamaktır. Ayrıca programcılara gerekli algoritmalar, yeniden kullanılacak kod parçaları bulmakta yardımcı olur. Ekibin ürettiği son çıktı onun bir araya getirdiği bir bütünleştirme ürünüdür. Ekiplerin bir lideri olur ve genellikle bu lider de programcıdır. Aynı zamanda kod geliştirilmesi ile uğraşır. Ancak grubun uyumlu çalışmasını sağlamakla görevlidir. Alışılagelmiş fazla denetleyici bir yönetici görünümünden uzak olmalıdır. Bu konuda da değişik yaklaşımlar mevcut olsa da, genelde programcılar üzerinde fazla sıkı bir yönetim yapısı benimsenmemektedir. Ekiplerde kütüphaneci ve olası diğer kritik alan bilgisi gerektirecek rolleri üstlenen üyelerin yedeklenmesi gerekir. Bu yedekleme de genelde ekip içerisinden sağlanır. Yedeklemenin amacı ayrılacak bir üyenin proje devamını çok etkilememesidir.

Proje Planında, projede kullanılacak donanım, ağ alt yapısı, işletim sistemi, veri tabanı yönetim sistemi vb yazılımlara ilişkin özellikler. Önerilen Sistemin Teknik Tanımların bölümünde yer alır. Varsa özel amaçlı donanımlar ve bunların çizimleri, kablolama, işletim zamanı kısıtları gibi gerekler ayrıca belirtilir. Projeyi geliştirirken kullanılacak yazılım geliştirme araçları (CASE araçları, görsel programlama platformları, programlama dilleri vb) bu kesimde açıklanmalıdır.

Projenin geliştirilmesi amacıyla kullanılacak Standartlar, Yöntem ve Metodolojiler proje planında yer almalıdır. Söz konusu standart, yöntem ve metodolojilere örnek olarak:

1. Çözümleme aşamasında kullanılacak yöntemler
2. Tasarım Aşamasında kullanılacak yöntemler
3. Belgeleme standartları
4. Tasarım standartları vb.

verilebilir. Bu konuda en önemli kaynaklardan biri IEEE Standart ve Rehberleridir.

Projede yapılan işlerin doğruluğunun denetlenmesi, proje standartları ve izleme yöntemlerinin oluşturulması, Proje Kalitesinin sağlanması amacıyla Kalite Sağlama Planı oluşturulur. Bu plan ayrıca, Projede oluşturulacak Kalite Yönetim Biriminin görev ve iş tanımlarını yapar. Ana ilke olarak her ara ürün ancak Kalite Denetiminden geçtikten sonra iş sahibi ya da müşteriye verilir.

Sistemin geliştirilmesi sırasında herhangi bir aşamada oluşabilecek değişikliklerin kaydedilmesi, izlenmesi için kullanılacak yöntem ve yönergeler Konfigürasyon Yönetim Planında yer alır. Bu plan temelde müşteri ya da iş sahibine değişiklikleri bildirme ve izleme konusunda yardımcı olması amacıyla hazırlanır.

Projenin, geliştirme süreci boyunca fiziksel kaynaklarının (donanım, yazılım ortamı, işletim sistemi vb), insan kaynaklarının, ve finans kaynaklarının yönetimi, sürekliliğinin sağlanma biçimi ile ilgili konular Kaynak Yönetim Planı içerisinde yeralır.

Büyüklüğü ne olursa olsun, her proje, eğitim boyutu içerir. Bir proje için sağlanacak en düşük düzeydeki eğitim, geliştirilen uygulama yazılımları ile ilgili olarak uç kullanıcıların eğitimidir. Bu eğitimin yanısırı bir proje için gerekebilecek eğitimlere örnek olarak Kullanıcılar için Temel Bilgisayar Kavramları, Windows, Ofis yazılımları (word,excel,access vb), Teknik eğitim (Bilgisayar ağları, sistem yönetimi, veritabanı yönetim sistemleri, yazılım geliştirme platformları vb) eğitimleri verilebilir. Söz konusu eğitimlerin ne zaman, kime, hangi ortamda verileceği gibi bilgiler Eğitim Planında yer alır.

Her Proje Planı, geliştirme sürecinde üretilecek ürünün gerek teknik açıdan gerekse kullanıcı açısından nasıl sınanacağına ilişkin bilgileri içermek durumundadır. Aksi durumda projenin sonlandırılması olası olmaz. Söz konusu bilgiler Proje Sınama Planı içerisinde yer alır.

Bakım Planı, Proje uygulama aşamasına geçtikten sonra gerekebilecek değişikliklerin ne zaman ve nasıl yapılacağını içerir.

Sorular

1)

COCOMO temel modeli kullanarak, aşağıdaki projelerin zaman ve iş gücü maliyetlerini hesaplayınız: 50,000 satırlık yarı-bağımlı türde bir proje 25,000 satırlık gömülü türde bir proje 300,000 satırlık gömülü türde bir proje 100,000 satırlık doğal türde bir proje

2) Organik, gömülü ve yarı-gömülü projelere ikişer örnek veriniz.

3. Yöneticiler için yazılım ediniminde en önemli kararlardan biri Dışarıdan satın alma ya da kendi kaynaklarını kullanarak üretim yapma seçeneklerinin birinin tercih edilmesidir. Yazılım üretim maliyeti 20 $/satır olan bir yazılım biriminin yöneticisi olduğunuzu varsayalım. Size satış ederi 50,000 $ olan ve 5000 satırdan oluşan bir yazılım ürünü öneriliyor.

Teknik ekibiniz söz konusu yazılım ürününde hiçbir değişiklik yapılmaksızın kuruluşunuzda ürünün kullanılabileceğini belirtiyor. Satın alma ya da kendiniz yapma seçeneklerinden hangisini tercih edersiniz? Gerekçelerinizi ve varsayımlarınızı belirtiniz.

Üzerinde bir süre çalıştıktan sonra, teknik ekibiniz, söz konusu ürünün kuruluşunuzda kullanılabilmesi için yaklaşık 1000 satır üzerinde değişiklik yapma ya da ekleme türünde bir iş yapılması gerektiğini belirtiyor. Satın alma ya da kendiniz yapma seçeneklerinden hangisini tercih edersiniz? Gerekçelerinizi ve varsayımlarınızı belirtiniz.

4) 1960’lı yılların başlarında geliştirilmiş bir mühendislik yazılımı, kurumunuz için hala yaşamsal önem taşımakta. Yazılım 300,000 satırdan oluşmakta ve sürekli bakım sorunu yaşanmakta. Beş yıl süreyle yaptığınız gözlemler sonucunda, yazılım bakımı amacıyla ortalama her yıl 10,000 satırın değiştiğini saptadınız. Son beş yıl içinde gözlemlediğiniz satır başına bakım maliyetleri aşağıda verilmiştir.

1. Yıl 40 $/satır

2. Yıl 42 $/satır

3. Yıl 45 $/satır

4. Yıl 50 $/satır

5. Yıl 60 $/satır

Yazılım Mühendisliği grubunuz, söz konusu mühendislik yazılımını yeniden yaklaşık 175,000 satır olarak geliştirebileceğini belirtmekte. Şu anda kurumunuzdaki yazılım üretim maliyetleri ise ortalama 25 $/satır dolayında. Söz konusu yazılımın yeniden üretilip üretilmeyeceği konusunda yatırım geri dönüş çözümlemesi yapınız.

5) Uluslararası bir yayın kuruluşunun temsilcisi olan bir kitapevi işlerini bilgisayar aracılığı ile yürütmek istiyor. Kitapevinin iki şubesi var. Genel olarak kitapevinde yapılan işlemler, Kitap siparişi, satışı, müşteri izleme, abonelik, muhasebe, müşteriye kitaplarla ilgili bilgi verme, muhasebe , Web hazırlama vb. Biçiminde tanımlanmakta. Her iki şubede de yerel bilgisayar ağı kurulması ve şubelerin internet üzerinden birbirine bağlanması planlanmakta. Geliştirilecek yazılımın Veri Tabanı Yönetim Sistemi kullanması ve Web tabanlı olması istenmekte.

Bu tanımı kendi varsayımlarınızla genişleterek, Kitapevi için gerekecek yazılımın Hangi bileşenlerinin hazır yazılım olarak karşılanabileceğini belirtiniz.

Yazılımın geliştirilmesi için gerekecek işgücü ve zamanı İşlev Noktaları ve COCOMO yöntemlerni kullanarak ayrı ayrı hesaplayınız. Hesaplamalar sırasındaki varsayımlarınızı belirtiniz.

6) COCOMO ara model parametrelerini inceleyerek, nitelikli iş gücü kullanıp kullanmamanın proje süre ve iş gücünü hangi oranda etkilediğini belirleyiniz.

7) İş Sahibi Proje ekibinin, proje başarısı açısından önemini tartışınız.

8) Proje zaman ve iş gücünün izlenebilmesi amacıyla kullanılabilecek bilgisayar destekli araç ve yöntemlere örnekler veriniz.

9) Yazılım projelerinde standartların önemini tartışınız. Standart kullanımının yararlarını ve aksak yönlerini belirtiniz.

Değerlendirme Soruları

 Bölüm 4: Sistem Çözümleme

4.1. Giriş

Sistem çözümleme çalışması, üretim sürecinin başlangıcıdır. Bu aşamada temel olarak mevcut sistemin nasıl çalıştığı araştırılır. Mevcut sistemin incelenmesi sırasında temel hedef gereksinimlerin saptanmasıdır. Bu işlemden sonra önerilen sistem için modelleme yapılır. Söz konusu model, mantıksal model olarak bilinir.

Çözümleme çalışmasında mutlaka bir model/yöntem kullanma zorunluluğu vardır. Aksi durumda, çalışma dağınık biçimde sürer, denetlenemez ve başarısız olur. Bu bölümde, yapısal sistem geliştirme yaklaşımında kullanılan yöntemlerden en yaygın olanlarına örnekler verilmiştir. Yöntemler, veri modelleme ve süreç modelleme yöntemleri olarak iki başlık aktında incelenmiştir. Örneğin, Veri akış diyagramları ve Nesne ilişki şemaları yaygın olarak kullanılan süreç modelleme ve veri modelleme yöntemleridir.

Çözümleme çalışması, değişik açılardan değelendirilmelidir. Bu tür bir çalışmanın nasıl değerlendirileceği bu bölümde incelenmektedir.

4.2. Gereksinim Nedir?

Bir sistem geliştirirken, kullanıcının sistemin işlevleri ile ilgili beklentileri sistemin amaçlarını oluşturur. Gereksinim, sistemin amaçlarını yerine getirme yeteneği olan bir özellik ya da belirtim olarak tanımlanmaktadır. Bir kuruluş için personel bordro sistemi geliştirdiğimizi varsayalım. Maaş bildirim formlarının aylık olarak hazırlanması, kuruluşun değişik birimlerinden bu bilgilere erişim istekleri, gereksinimlere örnek olarak verilebilir.

Gereksinim, sistemin ya da işlevlerinin nasıl gerçekleştirileceği ile ilgili değildir, ne olduğu ile ilgilidir. Hangi veri tabanı tablolarının kullanılacağı, ne kadar bellek harcanacağı gibi konular gereksinim çözümleme çalışmasında değil tasarım ve gerçekleştirim çalışmalarında ele alınabilecek konulardır.

Gereksinim, kullanıcı ve tasarımcı ya da yazılım mühendisi ile ilgili olarak iki amaca yönelik olacak biçimde tanımlanmalıdır; Kullanıcılar, geliştirilecek sistemin amaçları istenilen ölçüde tanımlanmış mı sorusuna yanıt ararken, tasarımcılar ise gereksinimlerin tasarıma dönüştürülebilme uygunluğunu ararlar. Bu nedenle Gereksinim Çözümleme amacıyla kullanılacak araç ve yöntemler hem kullanıcı hem de tasarımcı tarafından algılanabilir düzeyde olmalıdır.

Temel olarak, gereksinimler iki ana grupta incelenebilir:

İşlevsel Gereksinimler: Sistem ile çevresi arasındaki iletişimi belirleyen gereksinimler işlevsel gereksinim olarak tanımlanır. İşlevsel gereksinimler ayrıca sistemin herhangi bir durum karşısındaki davranışını belirler. Maaş çeki hazırlama örneğine dönecek olursak, işlevsel gereksinimler; maaş çekinin ne zaman hazırlanacağı, çek hazırlamak için ne tür girdiler verilmesi gerektiği, hangi koşullarda birkişiye maaş verilmeyeceği gibi gereksinimler işlevsel gereksinimlerdir.

İşlevsel Olmayan Gereksinimler: Kullanıcının sorunundan bağımsız olarak çözülmesi gereken sorunlar İşlevsel olmayan gereksinim olarak tanımlanır. Bir çok kaynakta bu terim yerine “Sistem Kısıtları” terimi de kullanılmaktadır. Kullanılacak bilgisayarın türü, yazılım geliştirme ortamı, kullanılacak veri tabanı yönetim sistemi vb bu tür gereksinimlere örnek olarak verilebilir.

4.3. Gereksinim Türleri

• İşlevlerin geliştirileceği, işletileceği aygıtlar nerededir.
• Sistem tek bir yerde mi olacak, birden çok, fiziksel olarak bribirinden ayrılmış yerler söz konusu mu?
• Sıcaklık, nem oranı veya manyetik etkileşim gibi çevresel kısıtlamalar var mı?
• Girdiler bir mi, yoksa birden çok sistemden mi geliyor?
• Çıktılar bir mi, yoksa birden çok sisteme mi gidiyor?
• Verinin nasıl biçimlendirileceğine ilişkin önerilen bir yol var mı?
• Verinin kullanılacağı, önerilen bir ortam var mı?
• Sistemi kim kullanacak?
• Çeşitli tipte kullanıcılar olacak mı?
• Her bir kullanıcı tipinin yetenek düzeyi nedir?
• Her kullanıcı tipi için ne tür bir eğitim gereklidir?
• Bir kullanıcının sistemi anlaması ne denli kolay olacaktır?
• Bir kullanıcının sistemi kötü amaçlı kullanabilmesi ne ölçüde zordur?
• Sistem ne yapacak?
• Sistem bunu ne zaman gerçekleştirecek?
• Sistem nasıl ve ne zaman değiştirilebilir veya güçlendirilebilir?
• Çalışma hızı, yanıt süresi ya da çıktı üzerinde kısıtlayıcı etmenler var mı?
• Ne kadar belgeleme gereklidir?
• Belgeleme hangi kullanıcı kitlesini hedeflemektedir?
• Hem giriş hem çıkış için verinin biçimi ne olmalıdır?
• Bu veri ne sıklıkta alınacak veya gönderilecektir?
• Bu veri kesinlik (doğruluk) ölçüsü ne kadar olmalıdır?
• Hesaplamalar hangi duyarlık derecesine kadar yapılacaktır?
• Sistemden ne kadar veri akışı olacaktır?
• Belli bir zaman süresince veri kaynağında saklanacakmıdır?
• Sistemi kurmak, kullanmak ve bakımını yapmak için ne kadar malzeme, personel ve diğer kaynaklara ihtiyaç vardır?
• Geliştiriciler hangi yeteneklere sahip olmalıdır?
• Sistem ne kadar bir fiziksel yer kaplayacaktır?
• Güç (besleme), ısıtma veya soğutma için gereksinimler nelerdir?
• Geliştirim için tavsiye edilen bir zaman çizelgesi var mıdır?
• Geliştirme veya yazılım ve donanım için harcanacak para üzerinde bir sınırlama var mıdır?
• Sisteme veya bilgiye erişim denetlenmeli midir?
• Bir kullanıcının verisi diğerlerininkinden nasıl ayrıştırılacaktır?
• Kullanıcı programları diğer program ve işletim sistemlerinden nasıl ayrı tutulacaktır?
• Sistem hangi sıklıkta yedeklenecektir?
• Yedek kopyaları başka bir yerde mi saklanmaktadır?
• Yangın ve hırsızlığa karşı ne tür önlem alınacakır?
• Güvenirlik için gereksinimler nelerdir?
• Sistemin özellikleri, insanlara nasıl aktarılmalıdır?
• Sistem, hataları kendisi bulup gidermeli midir?
• Sistem çökmeleri arasında öngörülen zaman nedir?
• Bir çöküm sonrasında sistemi tekrar başlatmak için uygun görülebilecek bir süre var mıdır?
• Sistem, tasarımda yapılacak değişiklikleri nasıl özümseyecektir?
• Bakımdan anlaşılan sadece hata gidermek midir, yoksa sistemi geliştirmeyi de içerir mi?
• Kaynak kullanımı ve yanıt süresine ilişkin verimlilik ölçütleri nedir?
• Sistemi bir yerden bir yere veya bilgisayardan diğerine taşımak ne kadar kolaylıkta olmalıdır?

 4.4. Gereksinim Özellikleri

Görüldüğü gibi, gereksinimler sadece bir sisteme ve sistemden bilgi akışını ve sistemce yapılan veri dönüşümünü tanımlamaz, aynı zamanda sistemin performansı üzerindeki kısıtları da tanımlar. Bu yüzden, gereksinimler üç amaca hizmet eder. Birincisi; geliştiricilerin, müşterilerin sistemin nasıl çalışmasını istediklerini anlamalarını sağlar. Gereksinimler, ayrıca tasarımcılara, sonuç sistemin ne işlevsellik ve özellikte olacağını söyler. Üçüncüsü; gereksinimler, sınama ekibine, kullanıcıyı, sunulan sistemin istenen sistem olduğuna ikna etmek için neler göstermeleri gerektiğini söyler. Özellikle, gereksinimlerde belirtilen performans özellikleri ölçülebilir birimler olmalıdır ve böylece her sınama için bir hedef sağlanmalıdır.

Hem geliştiriciler hem de kullanıcılar gereksinimleri kullandığı için, gereksinimlerin geçerliliğinin doğrulanması gerekir. Doğrulama süreci aşağıda belirtilen yedi kriteri içerir:

1. Gereksinimler doğru oluşturulmuş mudur? Hem geliştirici, hemde kulanıcı tarafından belirsizliği giderilmiş, hatasız olarak onaylanmış olduğunu güvenceye almak için gözden geçiriniz.
2. Gereksinimler tutarlı mı? Yani, hiç çelişen, çift anlamlı, anlaşılmayan gereksinimler var mı?
3. Gereksinimler tam mı? Eğer tüm olası durumlar bir gereksinimle açıklanıyorsa, gereksinimler tamdırlar. Bu nedenle, örneğin bir çalışan ücretsiz izne çıktığında, birisi terfi ettiğinde veya bir kişi avans istediğinde, ne olacağı, örneğin bir PERSONEL sistemi tarafından açıklanmalıdır. Tanımlama, kullanıcı tarafından istenen tüm özellikleri içeriyorsa, bir sistem için ‘’dışsal tam’’ dır denir. Bir tanımlama; eğer gereksinimler içersinde açıklanmamış referanslar yoksa ‘’içsel tam” olarak tanımlanır.
4. Gereksinimler gerçekçi mi? Kullanıcının sistemden istediği gerçekten yapılabilir mi? Geliştirme zamanının uzun olduğu durumlarda, teknolojik değişime uyulabilecek biçimde tanımlı mı?
5. Her gereksinim kullanıcı tarafından istenen bir şeyi mi tanımlamaktadır? Bazı durumlarda bir gereksinim bizi gereksiz yere kısıtlayabilir. Örneğin, kullanıcı, ünü iyi olduğundan dolayı, belirli bir XYZ bilgisayarının kullanılmasını isteyebilir. Öte yandan, XYZ, istenen sistemin gerçekleştirmesi için en uygun bilgisayar olmayabilir. Bu tür gereksinimler doğrudan sistemin hedeflerini adreslemez. Yalnızca kullanıcının sorununu çözmek için doğrudan işe yarayacak gereksinimler üzerinde yoğunlaşılmalıdır.
6. Gereksinimler doğrulanabilir mi? Gereksinimlerin karşılandığını gösterebilmek için sınama senaryoları oluşturulabilir mi? Ya da doğrudan sınama yapılabilir mi?. Kullanıcı, bir hız tanımlaması yapmadan ve yanıt süresinin koşullarını tanımlamadan ‘hızlı yanıt süresi’ isteyebilir. Örneğin, ‘hızlı yanıt süresi’, daha doğrulanabilir olarak şu şekilde tekrar tanımlanabilir; ‘sistemde kelime işlem programını kullanan en çok (örneğin: 32) sayıda kullanıcı ile, sistem bir kullanıcının ekranına bir belgeyi bir sonraki sayfasıyla birlikte en çok 5 saniyede getirmelidir.’
7. Gereksinimler izlenebilir mi? Her sistem işlevi, kendisini zorunlu kılan bir dizi gereksinim olarak izlenebilir mi? Sistemin özel bir yönüyle ilgili bir dizi gereksinim bulmak kolay mı? Örneğin, tüm iletişim gereksinimlerini gözden geçirmek için bütün gereksinimler okunmak zorunda mı?

4.4.1. Gereksinim Özellikleri -Örnek-

Gereksinim örnekleri bize bu özellikleri nasıl seçeceğimizi gösterebilir. Bir uzay mekiği sistemi için bir gereksinim şu şekilde öngörüldüğünü varsayalım:

“Görev planlaması için kesinlik(doğruluk) yeterli olacaktır.”

Bu gereksinimi karşılayıp karşılamadığını görmek için sistem nasıl sınanabilir? Görev planlamasının ne anlama geldiği tartışılıp gereksinim, daha yönlendirici ve sınanabilir biçimde yeniden aşağıdaki şekilde tanımlanabilir:

“Pozisyon hatası, yörünge boyunca 50 feet’ten; yörünge dışında 30 feet’ten az olacaktır.”

Bu durumda, pozisyon hatasını sınanabilir ve gereksinimin kesin olarak karşılanıp karşılanmadığı belirlenebilir. Benzer şekilde, sınanamayacak gereksinimlerden kaçınılmalıdır. Örneğin,

“Sistem, sorgulamaları gerçek-zamanlı olarak yanıtlamalıdır.”

türündeki bir gereksinim tanımında “Gerçek-zamanlı yanıtın” tanımı net olarak bilinmelidir. Eğer gereksinim

“Sistem, kişi sorgulamaya en çok iki saniyeden daha az zamanda cevap verecektir.”

biçiminde olsaydı, sistemi sorgulama işlevinin nasıl sınanacağı kesin olarak bilinebilirdi.

Gereksinimler, gerçekçi olmalıdır. Bir sistemin, binlerce km. uzaktaki bir ana bilgisayardaki yanıt süresi ile sisteme yerel ağ üzerinden erişen kullanıcılar için beklenen yanıt süresinin aynı olmasının istendiğini varsayın. Bu tür bir gereksinim gerçekçi değildir. İletişim hatları üzerinden erişimin daha fazla zaman alacağı açıktır.

 4.5. Sistem Çözümleme Çalışması

Şekil 4.2 Gereksinim Çözümleme Çalışması

Geliştirilecek bilgi sistemi ya da yazılımla ilgili olarak tüm gereksinimlerin araştırılması, tanımlanması, ortaya çıkarılması ve bir gösterim biçimi ile açıklanması (modellenmesi) çalışmaları Sistem Çözümleme Çalışması olarak adlandırılır. Bu çalışmada işlevsel gereksinimler, yazılımları geliştirilecek sistemlerin veri yapıları ve süreç boyutları ile irdelenir. Temel olarak çözümleme çalışması:

• Mevcut Sistemin İncelenmesi,
• Önerilen Sistemin Modellemesi,

Olmak üzere iki aşamalı yapılır. Öncelikle mevcut sistem incelenir bu incelemenin tamamlanmasından sonra önerilen yapı modellenir. Bu çalışma düzeni şekil 4.2’de gösterilmektedir.

4.5.1. Mevcut Sistemin İncelemesi

Bu çalışmada temel amaç yazılım gelişitirilecek olan sistemin anlaşılması ve tanınmasıdır. Bu amaçla görüşme yapma, gerekirse anket yapma yöntemleri kullanılır.

Yapılacak görüşmelerde, mevcut sistemde elle yürütülen tüm işlemler, girdi, işlev, çıktı ve diğer işlevlerle olan ilişkiler bazında sorgulanır. İlgili yönerge, kanun ve yöntemler kullanıcıdan edinilir. Sorgulama ya da inceleme işleminin belirtilmesi amacıyla çeşitli yöntemler kullanılır. Sorgulama sonucu elde edilen bulgularla ilgili olarak kullanıcıdan geri bildirim alınır.

Mevcut sistemde elle yürütülen işlerde, kullanılan form, defter ve yazışma örnekleri, sistemin veri boyutunu oluşturur. Bu tür bilgilerin birer kopyaları bir sonraki aşamada veri modellemesi için edinilir.

4.5.2. Önerilen Sistem Modellemesi - Mantıksal Tasarım

Mevcut sistemin modellenmesinden sonra, bilgisayarlı ortamda işlerin yapılabilmesi amacıyla önerilecek sistemin modeli oluşturulur. Bu model, önerilen sistemin işlevsel yapısı, veri yapısı ve kullanıcı arayüzünü içerir.

Bu modelleme daha çok, bilgi sistemini geliştirecek teknik personele (sistem tasarımcıları, programcılar) yöneliktir. Bu model aynı zamanda ‘mantıksal Model’ olarak ta tanımlanır. Mantıksal model, önerilen sistemin veri yapısını ve süreç yapısını hem genel hemde ayrıntılı olarak tanımlar. Mantıksal Model, kolaylıkla fiziksel modele (Program parçaları, veri tabanı tabloları vb) dönüştürülebilir bir yapıdadır.

Bazı yazarlar, ‘mantıksal model‘ üretimini tasarım aşamasının bir parçası olarak ele alırlar ve konuyu ‘Tasarım’ başlığı altında incelerler.

 4.5.3. Kullanılan Yöntemler

Çözümleme çalışması sırasında kullanılan yöntemler;

• Gereksinim Verisi Toplama Yöntemleri
• Veri Modelleme Yöntemleri
• Süreç/İşlem Modelleme Yöntemleri

olmak üzere üç grupta incelenebilir.

Veri modelleme yöntemleri, geliştirilecek bilgi sisteminin veri yapısını açıklamak amacıyla kullanılan yöntemlerdir. Süreç/işlem modelleme yöntemleri ise bilgi sisteminin işlevini açıklamak için kullanılan yöntemlerdir. Bu yöntemler, izleyen kesimlerde açıklanmaktadır.

 4.5.3.1. Gereksinim Verisi Toplama

Mevcut sistemin incelenmesi sırasında kulanılabilecek temel yöntemler:

• Sorma
• Psikolojik türetme teknikleri
• İstatistiksel teknikler

biçiminde özetlenebilir. Bu teknikler, izleyen alt kesimlerde açıklanmaktadır.

4.5.3.1.1. Sorma Yöntemi

Sorma yöntemi, gereksinim verilerinin toplanması sırasında kullanılan en önemli yöntemlerden biridir. Karşılıklı görüşme ya da anket yolu ile uygulanır.

Karşılıklı Görüşme: Karşılıklı görüşme sırasında, gereksinimleri ilişkin amaçlar, düşünceler, remi olmayan yöntemler, duygular ve düşünceler araştırılır. Karşılıklı görüşme, veri toplama için en etkin yollardan biridir. Sorma yönteminde açık uçlu sorular (yanıtları kişiden kişiye değişebilen, yoruma açık sorular) ya da kapalı uçlu sorular (yanıtları evet hayır ya da bir sayı biçiminde kesin olan sorular) sorulabilir. Çözümleme kolaylığı, verinin güvenliği ve duyarlığı açısından kapalı uçlu sorular tercih edilmelidir. Sorular, dağınık olarak değil, yapısal bir biçimde sorulmaıdır. Bu nedenle aşağıdaki üç tarzdan biri seçilmelidir (bkz şekil 4.3):

Piramit Tarzı: Özel sorularla başlayıp, giderek genel sorularla sürdürme

Koni Tarzı: Genel sorularla başlayıp özel sorularla sürdürme

Elmas tarzı: Özel sorularla başlayıp, genel sorularla sürdürme, tekrar özel sorularla sona erdirme.

Şekil 4.3 Yapısal Soru Türleri

Sorular sırasında dikkat edilecek önemli konu; yönlendirici sorular ve iki nesneli sorulardan kaçınmak olmalıdır.

Yönlendirici soru, daha çok gürüşmeyi yapanın kendi düşüncelerini yansıtan ve bir anlamda onay istenen soru türüdür. Örneğin, görüşmecinin “Efendim bence sizin kurumunuzdaki personel bölümünün işleyişini şu şekilde değiştirmek gerekir. Ne dersiniz?” türündeki sorusu yönlendirici bir sorudur. Temel olarak mevcut sistemde neler yapıldığı araştırılırken bu tür sorular anlamsızdır.

İki nesneli soru ise içinde birden fazla soru sözcüğü taşıyan sorudur. Örneğin: “Ne zaman …. Nasıl …. ve nerede ….?” Türündeki sorular gibi. Görüşülen kişi sorunun ilk kısmını yanıtlar ve diğer soruları unutur, soru yinelenmek zorunda kalınır.

Anket yöntemi, bir başka veri toplama yöntemidir. Kullanıcı sayısının fazla olduğu durumlarda, eğilimleri ve davranış biçimlerini saptamak amacıyla yapılır. Genelde yazılı test biçiminde hazırlanır. Bir anket sorusu temel olarak soru kısmı ve yanıt kısmı olmak üzere iki kısımdan oluşur. Yanıt kısmı da tanımlama ve ölçek kısmı olmak üzere iki bölümden oluşur (Bkz. Şekil 4.4)

Anket sorularına karşı yanıtlayıcılar bazı tipik davranış örnekleri gösterirler. Bazı kişiler, önlerine gelen anketi hiç düşünmeksizin, o konuya ilişkin görüşleri olumsuz ise hep olumsuz olarak, olumlu ise hep olumu olarak işaretlerler. Bu tür kişiler “kolay yanıtlayıcılar” olarak adlandırılır. Bazı kişiler ise, “suya sabuna dokunmayan” kişiliklerinden ötürü bütün sorulara “ortalama” yanıt verirler. Uç noktaları işaretlemezler.

Anket soruları, tanımlama ve ölçek kısımları hazırlanırken bu konulara dikkat edilmelidir.

Şekil 4.4 Bir anket sorusunun yapısı

4.5.3.1.2. Psikolojik Türetme Teknikleri

Özellikle, belirsizliğin fazla olduğu ve zayıf yapılı ortamlarda, bilgi edinebilmek amacıyla insan psikolojisine dayalı teknikler kullanılır. Bu teknikler temelde görüşme ve ankete dayalı tekniklerdir. Diğerlerinden farkı, bilgi üretmek için psikolojide bilinen “üçleme” tekniğini kullanmasıdır.

Bazı diğer psikolojik türetme yöntemleri, karar verme ortamlarında bilgi gereksinimlerini saptamak amacıyla algılama haritaları ve neden-etki çizgeleri kullanmaktadır.

4.5.3.1.3. İstatistiksel Teknikler

Veri yoğun ve veri hacmi yüksek olan ortamlarda, verinin özelliklerini belirlemek amacıyla istatistiksel teknikler kullanılır. Bu yöntemlerden en çok bilinen ikisi Örnekleme yöntemi ve PIRA modelidir.

Örnekleme yöntemi, bir topluluk içerisinden, sistematik yolla temsil edici örnek alma biçiminde tanımlanır. Amaç, veri toplama hızınını arttırmak ve verilerdeki çelişkileri önlemektir. Değişik örneklem türleri kullanılabilir; Basit gelişigüzel örneklem, kamaşık gelişigüzel örneklem, amaçlı örneklem vb. Örneklem boyutu, belirli bir güvenirlik düzeyinde olmak koşulu ile yine istatistiksel teknikler kullanılarak belirlenir.

PIRA (Personal, Interactive, Report and Analysis) modeli bilgi gereksinimlerinin tanımlarını belirli normlara bağlı olarak açıklamayı hedefler. Kişilerin bilgiye dayalı tercihlerini belirlemek amacıyla kulanılır.

 4.5.3.2. Veri Modelleme Yöntemleri

Önerilen sistemin mantıksal modelinde veri yapısını açıklamak amacıyla ‘Veri Modelleme’ yöntemleri kullanılmaktadr. Bu yöntemler, veri yapısını çeşitli düzeylerde tanımlama (en soyut düzeyden en ayrıntı düzeye kadar) amacını güder. Sistem Çözümleme aşamasında kullanılan, en yaygın olarak kullanılan veri modelleme yöntemleri:

Nesne ilişki Şemaları Veri Sözlüğü

olarak bilinmektedir. Nesne-İlişki Şemaları, veri yapısını en soyut düzeyde tanımlamak amacıyla kullanılır. Veri sözlüğü ise veri yapısınına ilişkin ayrıntı bilgileri içerir. Günümüzde Bilgisayar Destekli Yazılım Geliştirme Araçlarında bu yöntemler bütünleşik olarak kullanılmaktadır. Bu yöntemler aşağıda özetlenmektedir.

4.5.3.2.1. Nesne-İlişki Şemaları

Şekil 4.5 Örnek bir Nesne İlişki Şeması

Nesne ilişki şemaları, veri tasarımı açısından çok önemlidir. Geliştirilecek sistemin kullanacağı ana veri nesneleri ve aralarındaki ilişkileri belirtir. Günümüzde birçok CASE aracı nesne ilişki şemalarını otomatik olarak veri tabanı tablo yapılarına dönüştürmektedir. Şekil 4.5'te bir nesne ilişki şeması örneği verilmektedir.

Bir veri nesnesi, üç temel özelliği ile bilinir:

• Veri nesnesi varlığının adı : Veri nesnesi varlığını tanımlayan özelliktir.
• Veri nesnesi varlığının özellikleri
• Veri nesnesi varlığının diğer veri nesnesi varlıklarına referansı: Veri nesnesi varlığının diğer veri nesneleri ile olan ilişkisinin belirtilmesi amacıyla kullanılır. Bu amaçla herbir veri nesnesini tek olarak belirleyen bir belirteç (anahtar) kullanılır. Söz konusu belirteç. veri nesnesi varlığının ad özellikleri arasında yer alır.

4.5.3.2.2. Nesne-İlişki Şemaları -Örnek-

ARABA ve İNSAN adlı iki veri nesnesi düşünelim;

Yukarıda ARABA ve İNSAN nesnelerinin özellikleri verilmektedir. Araba nesnesinin varlıklarına ilişkin örnekler ise aşağıda (şekil 4.6) belirtilmektedir.

Şekil 4.6 Veri nesnesinin veri tabanı tablosuna dönüşmüş şekli

4.5.3.2.3. Nesne İlişkileri

Şekil 4.7 Değişik Nesne Türleri

Veri nesneleri arasındaki ilişkiler bire bir (1-1), bir den çoğa (1-N ya da N-1) ya da çok tan çoğa (M-N) tanımlanabilir. Örneğin:

1 – 1 ilişki : Bir İNSAN ancak bir ARABA sahibi olabilir.
1 – N ilişki: Bir İNSAN birden çok ARABA sahibi olabilir:
M – N ilişki: Birden çok İNSAN birden çok ARABA sahibi olabilir

Nesne ilişki şemaları, veri tabanı yönetim sistemleri dalının temel konularından biridir. Bu nedenle bu kitapta ayrıntılı olarak incelenmemiştir.

4.5.3.2.4. Veri Sözlüğü

Nesne İlişki şemalarında belirtilen nesne özelliklerinin ayrıntılı tanımları Veri Sözlüğünde yer alır. Söz konusu ayrıntılı tanımlar genel olarak:

Veri Adı
Veri Eş-adı (Aynı veri için kullanılan diğer ad)
Nerede/nasıl kullanıldığı
İçerik tanımı

türünde bilgileri içerir. Veri nesnelerinin sırasının tanımlanması, birden çok veri nesnesi arasından seçim ve veri nesnelerinin yinelemeli gruplamaları için özel gösterim biçimleri kullanılarak karmaşık veri nesneleri tanımlanır. Gösterim biçimleri Şekil 4.8’de verilmiştir.

Örnek: Kişi telefon bilgisinin tanımlanması
telefon no = [ yer kodu | numara ]
yer kodu = [ 212 | 242 | ….. | 312 ]

numara = *yedi basamaklı herhangi bir sayı*

Şekil 4.8 Veri Sözlüğü Gösterim Biçimleri

 4.5.3.3. Süreç/İşlem Modelleme Yöntemleri

Süreç/İşlem modelleme yöntemleri, geliştirilecek sistemin süreç ya da işlemlerini ve bu süreçler arasındaki ilişkileri tanımlamak amacıyla kullanılan yöntemlerdir. En yaygın olarak kullanılan Süreç Modelleme Yöntemlerine örnek olarak;

• Veri Akış Diyagramları (VAD)
• Süreç Tanımlama Dili (STD)
• Karar Tabloları
• Karar Ağaçları
• Nesne Şemaları

verilebilir. İzleyen kesimlerde bu yöntemlerden VAD genel modelleme yöntemine örnek olarak ve STD ise ayrıntı modelleme yöntemine örnek olarak anlatılmaktadır.

4.5.3.3.1. Veri Akış Diyagramları

VAD kullanılarak, geliştirilecek sistemin mantıksal modeli, ‘Yukarıdan Aşağıya’ bir yaklaşımla oluşturulur. Sistem önce en genel biçimiyle ele alınır, yalnızca dışsal ilişkileri incelenir. Daha sonra, sistemin iç yapısındaki süreçler ve bu süreçler arasındaki ilişkiler belirlenen bir ayrıntı düzeyine kadar modellenir.

Yapısal sistem geliştirme metodolojilerinde kullanılan tek veri modelleme yöntemi, Veri Akış Diyagramları (VAD) yöntemidir. VAD günümüzde oldukça yaygın olarak kullanılmaktadır. Hemen hemen bütün CASE araç ve ortamları VAD yöntemini içermektedir. VAD’nin oldukça yaygın olarak kullanılmasındaki temel etmen, hem bilgisayara yabancı olan kullanıcılar, hem de yazılım geliştiriciler için oldukça kolay algılanması ve kullanılabilmesidir. VAD, Şekil 4.9 de gösterilen 4 temel sembol kulanılarak oluşturulur. Süreç ya da işlemleri belirtmek amacıyla çember şekli kullanılmaktadır. Verilerin alındığı, ya da gönderildiği dış birimleri göstermek amacıyla dikdörtgenler kullanılmaktadır.

Şekil 4.9 VAD Yönteminde Kulanılan Semboller

Mantıksal veri yığınlarını göstermek amacıyla ucu açık dikdörtgenler kullanılmaktadır.

Gerek süreçlerarası gerekse süreçler ile veri kaynakları ve veri depoları arasındaki veri akış ilişkileri göstermek amacıyla oklar kullanılmakadır.
Temel olarak bir sistemin mantıksal modelinin süreç yapısı, üç tür Veri Akış Diyagramı çizilerek elde edilir.

Kapsam Diyagramı, geliştirilecek bilgi sisteminin dışsal ilişkilerini göstermek amacıyla kulanılır. Yalnızca bir çember ve gerekli sayıda veri kaynağı ile aralarındaki veri akışlarının belirtiminden oluşur.

Genel Bakış Diyagramı: Bir Bilgi sisteminin ana işlevlerini, bu işlevlere ilişkin veri kaynaklarını, veri depolarını ve işlemler arasındaki ilişkileri içeren VAD, Genel Bakış Diyagramı olarak tanımlanmaktadır. Genel Bakış Diyagramı, kapsam diyagramının ayrıştırılmış ya da “patlatılmış” biçimidir. Bir bilgi sistemi için, bilgi sisteminin büyüklüğüne göre en çok bir kaç Genel Bakış Diyagramı çizilir.

Detay Diyagramlar: Genel Bakış Diyagramında belirtilen her ana işlev, belirli bir ayrıntı düzeyine kadar (en fazla 7+/- 2) detay VAD oluşturularak ayrıştırılır. Genellikle detay VAD’larda, Veri kaynakları gösterilmez.

Bu biçimde, Kapsam diyagramı, genel bakış Diyagramı ve ayrıntı diyagramlardan oluşan VAD kümesi, geliştirilecek bilgi sisteminin ayrıştırılmış işlev ve veri akış yapısını içerir. Bu şekilde oluşturulan VAD kümesi, “Düzeylendirilmiş VAD” olarak ta tanımlanır. Şekil 4.10’te VAD örneği verilmektedir.

4.5.3.3.2. VAD Neyi Gösterir?

1. VAD, bilgi sisteminin durağan yapısını gösterir.
   
   
2. VAD, bilgi sisteminin süreçlerini, bu süreçler arasındaki veri akış ilişkilerini gösterir.
   
   
3. VAD, bilgi sistemi süreçleri ile ilgili olan kurum birimlerini ya da dış birimleri bilgi kaynakları olarak gösterir.
   
   
4. VAD, bilgi sistemi için gerekli olan ana veri depolarının neler olduğunu ve hangi süreçler tarafından kullanıldığını gösterir.
   
   
5. VAD, bilgi sistemi süreçlerini, yukarıdan aşağıya doğru ayrıştırarak gösterir. Böylelikle süreçler ve aralarındaki ilişki, en soyut (genel) düzeyden en ayrıntılı düzeye kadar belirli bir sıra düzen içerisinde belirtir.

4.5.3.3.3. VAD Neyi Göstermez?

1) VAD bilgi sistemi süreçlerinin zamana ilişkin durumunu ve bu durumla ilgili bilgileri göstermez.

2) VAD, bilgi sistemi süreçlerinin kendi aralarındaki “karar” ilişkisini göstermez.

3) VAD, gerek bilgi sistemi süreçleri, gerek veri akışları gerekse bilgi kaynakları ve bilgi depoları için ayrıntı içermez.

• Şekil -a-
• Şekil -b-
• Şekil -c-

---

Kapsam Diyagramı Örneği (DB: Dış birim, BS: Bilgi Sistemi)

Şekil 4.10 Veri Akış Diyagramları

4.5.3.3.4. Süreç Tanımlama Dili (STD)

Veri akış diyagramlarında isimleri belirtilen, aralarındaki ilişkiler gösterilen ve yukarıdan aşağıya ayrıştırılmış olan bilgi sistemi süreçlerinin iç yapılarını belirtmek amacıyla kullanılan araç, yöntem ya da gösterim biçimleri Süreç tanımlama dili olarak tanımlanmaktadır. Bu dil yardımıyla yapılan süreç içi tanımları, fiziksel tasarım aşamasında oluşturulacak program modüllerinin iç yapısını tanımlamak için temel oluşturur. Temel olarak STD için üç farklı yaklaşım izlenmektedir:

• Düz Metin,
• Şablon,
• Yapısal İngilizce

bu üç yaklaşım arasındaki ilişki aşağıda bir örnekle açıklanmaktadır.

Örnek: Süreç Tanımlama Dili

Detay Veri akış diyagramlarının birinde aşağıdaki biçimde yer almış ve bir üçgeni inceleyen ve üçgen türünü belirleyen bir süreç olduğunu varsayalım.

Her üç yaklaşım kullanılarak bu sürecin tanımları aşağıda verilmektedir:

Düz Metin:

Üçgeni İncele süreci üçgenin kenar boyutlarını (A,B,C) girdi olarak alır. Süreç önce bütün bu değerlerin pozitif olup olmadığını denetler. Eğer değerlerden biri negatif ise hata iletisi verir. Süreç, tüm kenar boyutlarının bir üçgeni belirleyecek biçimde geçerli olup olmadığını denetler. Eğer geçerli değerler ise üçgenin türünü (eşkenar üçgen, ikizkenar üçgen, çeşitkenar üçgen) belirler. Değil ise hata iletisi verir.

Şablon:

Süreç: Üçgeni İncele
Girdi: Üçgenin kenar boyutları (A,B,C)
Çıktı: Üçgen Türü, Hata iletisi
İşlem: A,B,C değerlerin pozitif olup olmadığını denetle. Eğer değerlerden biri negatif ise hata iletisi ver. A,B,C değerlerinin geçerli olup olmadığını denetle. Eğer geçerli değerler ise üçgenin türünü (eşkenar üçgen, ikizkenar üçgen, çeşitkenar üçgen) belirle. Değil ise hata iletisi ver.

Yapısal İngilizce:

Procedure : Üçgeni İncele
Üçgenin kenar boyutlarını oku;
if herhangibir boyut negatif then hata iletisi ver; endif;
if en büyük kenar diğer ikisinin toplamından küçük then
begin
eşit kenar sayısını belirle;
if üç kenar eşit then tür eşkenardır; endif;
if iki kenar eşit then tür ikizkenardır; endif;
if hiç bir kenar eşit değil then tür çeşitkenardır; endif;
üçgen türünü yaz;
end;
else değerler üçgeni belirtmiyor iletisi ver; endif;
endproc

 4.6. Kullanıcı Arayüz Prototipleme (KAP)

Gereksinim tanımlama, ya da sistem çözümleme çalışmasının önemli bir bileşeni, oluşturulacak bilgi sistemine ilişkin girdi ve çıktı gereksinimlerinin tanımlanmasıdır.Özellikle klavye-ekran aracılığı ile bilgisayara veri girişi ya da sorgulama amacıyla aktarılacak girdiler, ekran ya da yazıcıdan alınacak çıktıların biçimleri bu aşamada belirlenir.

Geleneksel yaklaşımlarda bilgi sistemi girdi ve çıktılarının tanımları el ile, kağıt üzerinde yapılır ve kullanıcıdan bu biçimiyle onay alınmasına çalışılır, kullanıcı, kağıt üzerinde gördüğü ekran tasarımlarına onay vermek durumunda bırakılırdı. Bu durum, daha sonra geliştirmenin ilerleyen aşamalarında, kullanıcı gerçek programlarla karşı karşıya kaldığında sorunlara yol açmaktadır. Kullanıcı ile geliştirici arasında sık sık "Ben bu ekranı böyle istememiştim, Şu özelliği de koysak nasıl olur?", “Bunu yapmamız çok zor, işimizi oldukça yavaşlatacak, neden daha önce belirtmediniz?” türünde tartışmalar her bilişim çalışanına yabancı olmayan sorunlardır. Günümüzde, görsel yazılım geliştirme platformlarının oldukça ileri düzeye gelmiş olması, bu tür sorunları gidermek amacıyla hızlı prototip geliştirmeyi olanaklı kılmıştır.

Kullanıcıya, bilgi sistemi yazılımı ile etkileşiminin nasıl olacağı ile ilgili gerçek bilgisayar ortamında fikir vermek amacıyla Kullanıcı Arayüz Prototipleme (KAP) yöntemi önerilmektedir.

KAP Yöntemi, gereksinim çalışmasının hemen sonunda kullanıcıya gösterilecek bir prototip yazılım hazırlanmasını içermektedir. Söz konusu prototipin gerçekten içsel olarak çalışmayan ancak ekranlar, menüler ve bunların aralarındaki geçişlerin çalıştığı bir yazılımdır. Burada, kullanıcıya ekranların nasıl olacağı, ekranlar arasındaki geçişlerin nasıl olacağı, rapor biçimlerinin nasıl olacağı ile ilgili bir benzetim sunulması ve kullanıcının, daha işin başında, geliştirme tamamlandıktan sonra ne tür bir sistemle karşılaşacağı ile ilgili bilgilendirilmesi amaçlanmaktadır. Bu yolla, yazılım geliştirmede en önemli sorunlardan biri olan “gereksinimlerin kesinleştirilmesi” kolaylaşmaktadır.

4.6.1. KAP için Ekranlar Nasıl Hazırlanır?

Herhangi bir görsel programlama aracı kullanılarak KAP ekranları hazırlanır. Günümüzde teknolojisi oldukça gelişmiş olan görsel yazılım geliştirme platformları bu işlemi oldukça kolaylaştırmaktadır. KAP ekranları hazırlanırken dikkat edilmesi gereken konular aşağıda belirtilmektedir. Aksi durumda, gecikmeler ve uygulamanın prototipleme yaklaşıımı ile geliştirilmesi gündeme gelir. Eğer bu önceden planlanmamış ise zaman ve iş gücü kayıpları söz konusu olur.

1) KAP hazırlama süresi uygulamanın boyutu ne olursa olsun, ekranlar ve ekranlar arası geçişlerin hazırlanması için gerekecek iş gücü ve zaman, sistem çözümleme için ayrılan zamanın %5’ini aşmamalıdır.

2) Bir özellik yalnızca bir kez gösterilmelidir. Bir özellik birden fazla ekranda yer alsa bile yalnızca bir ekranda gösterilmelidir. Örneğin, şehir listesini içeren bir kombo listesi, bir kaç şehir bilgisi içermeli ve yalnızca bir ekranda kulanıcıya gösterilmelidir. Başka ekranlarda aynı liste varsa, gösterilen ile aynı olduğu belirtilmelidir.

3) KAP hiçbir içsel işlem içermemelidir. Örneğin: Bir ekranda kişilerle ilgili sorgulama yapıldığını düşünelim. Adı soyadı bilinen bir kişinin, bu bilgi verildiğinde, diğer ayrıntı bilgilerinin ekranda görüntüleneceğini varsayalım. Kullanıcı, Ad Soyad bilgisini girecek, ve ilgili sorgulama tuşunu etkinleştirdikten sonra ekranda hep aynı bilgiler görünecektir. Yani, KAP, Ad soyad bilgisine göre KİŞİ tablosundan arama yapmayacak, program içerisinde hep aynı sonuçları ekrana verecektir. Çünkü Kişi tablosu nun yaratılması ya da kullanılması söz konusu değildir. Burada amaç, kullanıcıya, sorgulama biçimini ve sorgulama sonucunda elde edilecek bilgileri açıklamaktır. Sorgulanan bilginin içeriği bu aşamada önemli değildir. Kulanıcıdan, sorgulama sonucu gelen bilgi türlerine ilişkin, sorgulama işleminin işlem akışına ilişkin bilgi alınması hedeflenir.

4.6.2. KAP için Raporlar Nasıl Hazırlanır?

Bilgi sisteminden yazıcıçıktısı biçiminde alınması istenen raporlar, bir metin düzenleyici (örneğin MS Word) aracılığı ile hazırlanır ve belirli bir biçimde numaralandırılır. KAP, sözkonusu raporun alınacağı ekranda, kullanıcı fare imleci ile “Rapor al” tuşuna tıkladığında ya da ilgili tuşa bastığında “Şu anda …….. no’lu rapor yazıcıdan dökülmektedir” iletisi verir. Kullanıcıya daha önceden hazırlanmış olan rapor örneği gösterilerek, sistem çalışmaya başladığında bu raporun basılacağını belirtir.

Örnek: Geliştirilecek bilgi sisteminin İnsan Kaynakları Yönetim Bilgi Sistemi (İKYS) olduğunu varsayalım. İKYS Atama Modülüne ilişkin raporların örneklerini MS Word ile hazırlayarak bu raporlara İKYS-AT-R1, İKYS-AT-R2… vb numaralar verelim. Kullanıcı için hazırladığımız prototipi, kullanıcıya gösterirken, kullanıcı rapor almak amacıyla ilgili tuşa bastığında ya da fare imleci ile ilgili rapor alma düğmesini etkinleştirildiğinde KAP “Şu anda yazıcıdan İKYS-AT-R1 no ‘lu rapor dökülmekte” iletisi türünde bir ileti verecektir. Kullanıcı bu iletiyi gördüğünde , daha önceden MS Word ile hazırlamış olunan ve İKYS-AT-R1 biçiminde numaralanmış raporu kullanıcı ya göstererek, ileride yazılımı bitirip, sistemi hazır hale getirdiğimizde bu rapor un aynısının yazıcıdan alınacağını belirtiriz. Kulanıcı bu durumda bize, rapor alanları, raporun tetiklendiği ekranla ilgili geri bildirimlerini ve değişiklik isteğini iletir. Bu değişiklikler yapıldıktan sonra sözkonusu raporla ilgili gereksinimler kesinleştirilmiş olur.

4.7. Sistem Çözümleme Raporu İçeriği

Sistem çözümleme çalışması, sistem çözümleme raporu ile sonuçlandırılır. Söz konusu rapor, çalışmanın tüm ayrıntılarını içerir. Raporun genel yapısı tablo 4.1’de verilmiştir. Geliştirilecek yazılımın ayrıntısına göre işlevsel model, veri modeli ve ilgili kesimler ayrıntılandırılır.

1	Giriş
	1.1	Amaç
	1.2	Kapsam
	1.3	Tanımlar, Kısaadlar ve Kısaltmalar
	1.4	Kaynaklar
	1.5	Bölüm Açıklamaları
2	Mevcut Sistem İncelemesi
	2.1	Örgüt Yapısı
	2.2	İşlevsel Model
	2.3	Veri Modeli
	2.4	Varolan Yazılım/Donanım Kaynakları
	2.5	Varolan Sistemin Değerlendirilmesi
3	Gereksenen Sistemin Mantıksal Modeli
	3.1	Giriş
	3.2	İşlevsel Model
		3.2.1	Genel Bakış
		3.2.2	Bilgi Sistemleri/Nesneler
	3.3	Veri Modeli
	3.4	Veri Sözlüğü
	3.5	İşlevlerin Sıradüzeni
	3.6	Başarım Gerekleri
4	Arayüz Gerekleri
	4.1	Yazılım Arayüzü
	4.2	Kullanıcı Arayüzü
	4.3	İletişim Arayüzü
5	Belgeleme Gerekleri
	5.1	Geliştirme Sürecinin Belgelenmesi
	5.2	Eğitim Belgeleri
	5.3	Kullanıcı El Kitapları
Ekler

Tablo 4.1 Sistem Çözümleme Raporu İçeriği

 4.8. Çözümleme Çalışması Nasıl Değerlendirilir?

Sistem çözümleme çalışması sonuçlandıktan sonra, elde edilen ara ürünün (mantıksal model) istenenleri karşılayıp karşılamadığının belirlenmesi amacıyla değerlendirilmesi gerekir. Bu nedenle temel olarak:

• Kullanıcıların benimsemesi ve onayı
• Tutarlılık, tamlık ve uygunluk
• Tasarım çalışması için yeterliliği

Kriterleri baz alınarak değerlendirme çalışması yapılır. Sorular ve anketlerin değerlendirilmesi için istatistiksel yöntemler kullanılır.

4.8.1. Tamlık ve Tutarlılık

Tamlık, bilgi sitemi ya da yazılımın tüm öğeleri ve bunların arasındaki ilişkilerin tanımlanmasını gerektirir. Tutarlılık ise, önerilen modelin kendi içerisinde hatasız, çelişkisiz olması anlamındadır. Tamlık ve tutarlılık denetimi, bir programlama dilinde yazılmış bir programın söz dizim kurallarının denetimine benzer. Örneğin, modelleme aracı olarak VAD kullanıldığında

• Bütün süreçlerin girdi ve çıktıları var mı?
• Süreçler, veri akışları, dış birim ve veri depoları uygun şekilde adlandırılıp numaralandırılmış mı?
• VAD’ de ki tüm isimler veri sözlüğünde yer almış mı?
• Planlama aşamasında öngörülen belirtimlerin hepsi ele alınmış mı? vb.

gibi kriterlerin denetlenmesi gerekir. Bu tür sınamaların çoğu CASE araçları tarafından otomatik olarak yapılmaktadır.

Eğer gereksinimler formal olarak (RSL,PSL/PSA vb) tanımlanmış ise bu tür denetimler formal tanımlar üzerinde simgesel uygulamalarla yapılabilir.

4.8.2. VAD Dengeleme

Bir VAD’nın dengelenmiş olması : “Bir düzeydeki süreç bir alt düzeye detaylandırıldığında, alt düzey, üst düzeydeki sürecin tüm girdi ve çıktılarını içermeli, başka hiç bir girdi ya da çıktı içermememelidir.” kuralı ile belirlenir. Bir başka deyişle, bir alt düzeydeki süreç ve veri depolarını bir çember içine aldığımızda bir üst düzeyi elde etmeliyiz. Şekil 4.11’de dengelenmiş ve dengelenmemiş VAD örnekleri verilmektedir.

Şekil 4.11 VAD Dengeleme

4.8.3. Olurluluk

Olurluluk, sistem çözümleme sırasında yapılan çalışmanın, planlama aşamasında yapılan çalışmaya uygunluğunun belirlenmesi için yapılan çalışmaları içerir. Maliyet kestirim çalışması yinelenir, sapmalar saptanır, kaynaklar yeniden planlanır. Sapmalar olduça fazla olursa, yapılan çalışmanın yeniden gözden geçirilmesi gerekir.

Bu aşamada, maliyet kestirimi için daha fazla bilgi mevcuttur. VAD yöntemi, maliyet kestirim yöntemlerinin kolayca uygulanabilmesini olanaklı kılar. Örneğin İşlev Noktalarının belirlenmesinde VAD’den;

Girdi ve Çıktı sayıları: Girdi ve Çıktı sayıları doğrudan genel bakış diyagramındaki veri akışlarının incelenmesiyle elde edilir.

Kütük sayısı: Genel bakış diyagramlarındaki veri depoları sayılarak elde edilir.

Sorgu Sayısı: Sorgu sayısı genel bakış diyagramı ve detay diyagramlardaki süreçlerin incelenmesiyle elde edilir.

Arayüz sayısı: Arayüz sayısı, kapsam diyagramındaki dış birimlerle olan ilişkiler incelenerek elde edilir.
biçiminde yararlanılabilir.

4.8.4. VAD Ayrıştırma

Gereksinim tanımlarını, tasarım belirtimlerine dönüştürebilmek amacıyla çeşitli teknikler kullanılır. Dönüştürme Çözümlemesi ve Ara işlem Çözümlemesi en yaygın olarak kullanılan tekniklerdir.

Bir VAD yapısının, dönüştürme akışı özellikli olması, girdilerin belirli bir süre sonunda kaybolması ve iç süreçler tarafından çıktıların oluşturulması biçiminde tanımlanır. Şekil 4.12’de dönüştürme akışındaki sınırlar dış girdilerin yok olduğu ve çıktıların başladığı kesimleri belirtmektedir.

Araişlem akışlı VAD’larında işlemlerin bir süreç tarafından başka süreçlere dağıtılma özelliği bulunmaktadır.

Şekil 4.12 Bir Sistemdeki Bilgi Akışı

Bir VAD kümesinde bulunan diyagramların bir kısmı Dönüştürme akışı özelliği taşırken diğer bir kısmı ise ara işlem akışı özelliği taşıyabilir. Bu durumda tasarıma geçilirken her iki özelliğin birarada ele alınması gerekir.

Bölüm Özeti

Sistem Çözümleme aşaması, uç kullanıcı ile iletişimin en fazla olduğu aşamadır. Kullanıcıların Bilişim teknolojileri konusundaki bilgi düzeyleri genelde yok denecek ölçüde düşüktür. Bu nedenle kullanıcı ile olan iletişimin olabildiğince kullanıcıya görsel olanaklar sunularak yapılması önemlidir. Bu nedenle, özellikle kullanıcı arayüzünün belirlenmesi için en etkili yöntem olarak Kullanıcı Arayüz Prototipleme yöntemi önerilmektedir (Bkz. Bölüm 4.6). KAP yöntemini kullanıcılarla birlikte tartışırken, “iş senaryoları” oluşturmanın oldukça yararı vardır. Her iş senaryosu, bir iş probleminin çözümüne karşılık gelecek biçimde hazırlanmalı ve KAP üzerinde sınanmalıdır. BU yolla, kullanıcı, işeride bilgisayarlı uygulamaya geçildiğinde, nasıl bir ortamla karşı karşıya geleceğine ilişkin fikir sahibi olur.

Bu yöntemin kullanılması ileride ortaya çıkabilecek belirsizlik ve riskleri de büyük ölçüde ortadan kaldırır. Üretim sonucunda elde edilecek ekran ve rapor görüntülerinin bu aşamada olabildiğince kesinleştirilmesi, hem üretim yapan yazılım mühendislerinin hem de kullanıcının işini oldukça kolaylaştırır.

Kullanıcılar, genellikle görüşme tutanaklarını imzalamakta çekingenlik gösterirler.’Siz hazırlayın, bize gönderin bizde imzalar size göndeririz ‘ biçiminde yöntemler önerirler. Görüşme tutanaklarınızı anında iki kopya olarak tutun ve hemen görüşme bitiminde imzalatma yöntemini benimseyin ve uygulayın. Aksi durumda, ileride ortaya çıkabilecek sorunlarda kaybeden taraf siz olursunuz.

Tüm görüşme ve toplantı kayıtlarınızı olabildiğince bilgisayarlı ortamda saklayın. Aradan, uzun bir süre geçtikten sonra, eski kayıtlara erişimde büyük kolaylıklar sağladığını göreceksiniz. Bu amaçla Visual Source Safe türü basit bir araç bile kullanabilirsiniz.

Sorular

1) Sistem Çözümleme çalışmasının amaç ve önemini belirtiniz.

2) Gereksinim modelleme çalışmasında neden grafiksel araç ve yöntemler daha sıklıkla kullanılır?

3) Mevcut sistemin incelenmesi için kullanılabilecek yöntemleri açıklayınız.

4) İş senaryosunu tanımlayınız. Bir PERSONEL bilgi sistemi uygulaması için üç iş senaryosu örmneği veriniz.

5) Çevrenizde var olan bir CASE aracını inceleyip, sistem çözümleme çalışması ile ilgili olarak hangi olanakları içerdiğini araştırınız.

6) Gereksinimlerin belirlenmesi sırasında ortaya çıkabilecek riskleri sıralayınız.

7) Beş adet açık uçlu soru örneği veriniz.

8) Beş adet kapalı uçlu soru örneği veriniz.

9) İstediğiniz bir konuda 20 soruyu içeren bir anket hazırlayınız. Anket yanıtlama problemlerini dikkate alınız.

10) Kaset, CD satan ve kiralayan bir müzik dükkanında yapılan işlemleri, yapısal VAD kullanarak modelleyiniz. Süreç tanımlama dili olarak düz metin kullanınız. Veri yapısını Nesne-İlişki diyagramları ile modelleyiniz..

11) 8. Soruda oluşturduğunuz VAD üzerinde

-Dönüştürme akış özelliklerini

-Araişlem akış özelliklerini gösteriniz.

12) Kullanıcı arayüz prototiplemenin amacı nedir? Yararlı ve aksak yönleriyle belirtiniz.

13) VAD, süreç tanımlama dili ve nesne ilişki şemaları kullanılarak yapılan bir modellemenin, fiziksel tasarıma nasıl yardımcı olacağını açıklayınız.

14) Tasarımla çözümleme arasındaki ilişkiyi belirtiniz.

Değerlendirme Soruları

 Bölüm 5: Tasarım

5.1. Giriş

Şekil 5.1 Çözümleme-Tasarım İlişkisi

Tasarım, sistem çözümleme çalışması sonucunda üretilen mantıksal modelin Fiziksel Modele dönüştürülme çalışması olarak tanımlanabilir. Fiziksel model, geliştirilecek yazılımın hangi parçalardan oluşacağını, bu parçalar arasındaki ilişkilerin neler olacağını ve parçaların iç yapısının ayrıntılarını, gerekecek veri yapısının fiziksel biçiminin (kütük, veri tabanı tablosu vb) tasarımını içerir. Fiziksel tasarımın temel çıktısı doğrudan programlanabilecek program ve veri tanımlarıdır. Çözümleme aşamasından tasarım aşamasına geçiş şekil 5.1 ve şekil 5.2’ de belirtilmiştir.

Bazı yayınlarda tasarım kavramı hem mantıksal hem de fiziksel modeli içermektedir. Bizim bu konudaki tercihimiz, mantıksal ya da kavramsal modelin Çözümleme Çalışması içerisinde bulunması gerektiği yönünde olmuştur. Bundan ötürü bu bölümde tasarım olarak anılan konular bütünüyle fiziksel tasarıma yönelik olarak hazırlanmıştır.

Tasarım, daha çok yazılım geliştiricilere yönelik bir çalışmadır. Tasarım sonucunda oluşacak modelin kullanıcıları doğrudan programcı ya da sistem geliştiricilerdir. Tasarım çalışmasının temel çıktıları olan genel tasarım, yazılım birim ya da bileşenlerinin ayrınıtlı yapısı ve veri yapısı programcılar için girdi olarak alınır ve bu yapılar kullanılarak yazılımın kodları üretilir.

Şekil 5.2 Çözümlemeden Tasarıma Geçiş

Tasarım çalışması, iki aşamada yapılır; Genel tasarım ve Ayrıntı tasarım. Her iki aşamada yapılacak işlemlerin ayrıntıları izleyen kesimlerde açıklanmıştır.

Tasarım aşamasında hızlı prototipleme yöntemi, etkin kullanıcı iletişimi açısından önerilmektedir. Bu amaçla önerilen Kullanıcı Arayüz prototipleme yöntemi bu kesimde anlatılmıştır.

 5.2. Tasarım Kavramları

Yazılımın ögelere ayrılması, ayrıntılı veri ve işlev yapılarının kavramsal temsilden gizli tutulması, ve tasarımın kalitesinin sağlanması gibi isteklere değinilmiştir. Bu yönde yardımcı olabilecek 'soyutlama', 'iyileştirme' ve 'modülerlik' gibi kavramlar bulunmaktadır.

Soyutlama, detayları gizleyerek yukarıdan bakabilme şansını tanır. İyileştirme ise soyutlama ile yakından ilişkili bir kavramdır. Bir soyutlama düzeyinde irdeleme bittikten sonra daha alt sevyelere inilerek tanımlamalarda ayrıntı ve bazen de düzeltmeler yapılarak tasarım daha kesinlik kazanır. Modülerlik de soyutlama ve iyileştirme kavramlarının uygulanacağı organizasyonu oluşturur: sistemi, istenen kalite faktörleri ışığında parçalara ayrıştırma sonucunda elde edilir. Bir işlev için sistemin tümü değil, ayrılmış bir kısmı üzerinde çalışma yapabilme olanağını sağlar.

Soyutlama kavramı veri, işlev ve yapısal açılar için geçerlidir. Örneğin bir kapı nesne olarak ele alındığında onun kulpu, rengi, menteşeleri, malzemesi gibi detayları düşünmeden kapıyı bir ev mimarisi içinde değerlendirebiliriz. Aksi taktirde diğer detaylara yoğunlaşan bir tasarımcı 'oda' düzeyinde görsel canlandırmalara hakim olamaz. Kapıyı tanımladıktan sonra bu ögenin iyileştirilmesi sırasında daha alt düzeylere inilerek kapı kolu veya menteşe gibi alt birimlerin detayları tanımlayabiliriz. Kapı ve pencerenin de kendi ayrıntılarını, birer kelime ile soyutladığımız isimleri içerisinde saklamaları, onları birer nesne olarak bir oda içerisinde 'modüler' bir yapı düzeninde olabilmelerini sağlar. Bir pencerenin yerini değiştirmek, tasarım esnasında onun camı, menteşesi ve malzemesi gibi detayından bağımsız, aynı zamanda da odadaki diğer 'modüllerden' hemen hemen bağımsız olarak ele alınabilir.

İşlev açısından da soyutlama yapılır. Kapıyı açmak işlemi önce ona yaklaşmak sonra kapı kulpunun çevrilmesi, kapının menteşe etrafında döndürülmesi gibi alt düzeyde detayları açıklanabilecek üç işlemden oluşur. Kapı açma denildiğinde bu detaylardan soyutlanmış olarak üst düzeyde bir işlev temsil edilmiş olur. Benzer şekilde gittikçe ayrıntıları artan şekilde ve daha alt düzeydeki hareketleri tanımlayarak işlev iyileştirilmesi elde edilir.

5.2.1. Modülerlik (Birimsellik)

Bütün karmaşıklığın tek bir modülde toplanması yerine anlaşılabilirlik ve dolayısıyla projenin zihinsel kontrol altında tutulabilmesi için sistem bir çok modüle ayırılır. Modüller isimleri olan, tanımlanmış işlevleri bulunan ve hedef sistemi gerçekleştirmek üzere tümleştirilen birimlerdir. Karmaşıklığın idaresi açısından aşağıdaki formül 'parçala yönet' prensibini açıklamaktadır:

K(p1 ) ve K(p2), p1 ve p2 problemlerinin karmaşıkları olsun; K(p1+p2), p1 ve p2 problemlerinin birleşmesinden oluşacak daha büyük bir problemin karmaşıklığı ise,

K(p1+p2) > K(p1) + K(p2) dir.

Bunun anlamı, tek modül halindeki büyük problemin karmaşıklığının küçük iki modülün karmaşıklıklarının toplamından büyük olmasıdır. Dolayısıyla aynı büyüklükteki bir problemi ne kadar fazla sayıda modüle ayırırsak toplam karmaşıklık o kadar azalacak gibi görünmektedir. Ancak bu bakış açısının geçerli olduğu bir sınır vardır; bu sınırın ötesindeki modül fazlalığı, bu sefer modüllerin tümleştirilmesi için harcanacak çabanın fazlalığı dolayısyla toplam çaba konusunda zararlı olmaktadır. En verimli modül sayısı için bir nominal değer bulunmaktadır. Ancak tasarım sırasında böyle bir sayının hesabı yapılmaktansa modüllerin uyması gereken kurallar daha öne çıkar. Şekil ???? bir sistemin modüllerden oluşmasını simgelemektedir. Aynı zamanda Şekil 5.3, sistemin 'kontrol hiyerarşisi'ni de belirtmektedir. Bir modülün hangi modülleri kullanarak işlevini gerçekleştirdiği bu hiyerarşide görünmektedir.

Şekil 5.3 Sistem ve Modülleri

5.2.2. İşlevsel Bağımsızlık

Tasarım sırasında dikkat edilecek en önemli konulardan biri de modüllerin işlevsel bağımsızlığıdır. Böylece hem anlama kolaylaşacaktır hem de test ve bakım işlemleri. Yapılan bir hatanın diğer işlevlere yansıması ve yapılan değişikliklerin sistem genelinde yan tesirleri gibi konuların kontrolü daha kolaylaşacaktır. Bu konunun abartılı uzantısı yapıtaşı teknolojisidir; yapıtaşları bir sistem için değil, genel amaçlı olarak herhangi bir sisteme bütünleştirilmek üzere üretilirler. Bu durumda yapıtaşlarının bağlanacakları ortamdan bağımsız olarak işlevsellikleri ve bağlanma protokolleri tanımlanmalıdır. Modüllerde bu kadar bağımsızlık söz konusu olmak zorunda değilse de bu prensipten elden geldiğince yararlanılmalıdır. İşlevsel bağımsızlığı temin etmek için modüller arasındaki ilişkililiği (bağlantılılık) olduğunca azaltmak ve bir modülün yalnızca bir işlev ile görevlendirilmesini sağlamak (sıkılık) gerekir.

5.3. Veri Tasarımı

Yapı tasarımı, arayüz ve süreç tasarımından önce ilk yapılması gereken, veri tasarımıdır. Bilgi saklama ve soyutlama bu işlem için değerli kavramlardır. Çözümlemede faydalandığımız veri sözlüğü, tasarımda da yararlı olacaktır. Ayrıca veri tasarımı yaparken dikkat edilecek konular:

• Değişik veri yapılanmaları değerlendirilmelidir. Veri modellemesi sırasında belirlenen yapıların etkileri sorgulanmalıdır.
• Bütün veri yapıları ve bunlar üzerinde yapılacak işlemler tanımlanmalıdır.
• Alt düzeyde tasarım kararları tasarım süreci içerisinde geciktirilmelidir.
• Bazı çok kullanılan veri yapıları için bir kütüphane oluşturulmalı ve her projede bu yapılar tekrar tasarlanmamalıdır.
• Kullanılacak olan programlama dili soyut veri tiplerini desteklemelidir.

Veritabanları artık bir çok yazılım ortamının bütünleşik parçası halindedirler. Bunun gibi bazı soyut veri yapıları da artık programlama dillerince desteklenen yapılar haline gelmişlerdir. Örneğin bir tablo veya kuyruk gibi yapıları çalışacağınız programlama dili içeriyor olabilir. Bazı veri yapısı paketleri, C ve Pascal gibi birçok dilde kullanılabilecek modüller olarak ayrıca temin edilebilen yazılımlardır. Bu gibi temel öğeleri baştan tasarlayıp kodlamak yerine elde edip kullanmak gerekir.

Tasarım sırasında, çözümlemede ortaya çıkarılan modellerin uygulanmasında pratik sorunlar irdelenir, gerekirse çözümleme modelinin değişmesi bile istenebilir. Çözümden kopuk olarak yapılmış modeller, verimlilik gibi bazı ana noktaları göz ardı edebilirler.

Veri tasarımı çalışması, çözümleme çalışması sonucunda elde edilen Nesne-İlişki şemalarının, veri tabanı tablolarına dönüştürülmesi, gerekli diğer tablo yapılarının oluşturulması ve bu yapıların detaylandırılması çalışması olarak tanımlanabilir. Bu dönüştürme, bütünleşik CASE araçları tarafından otomatik olarak yapılabilmektedir. Veri tablolarının üzerinde, yüksek nitelik, hız ve verimlilik amacıyla yapılacak normalizasyon çalışmaları Veri Tabanı Yönetim Sistemleri dalının konusudur. Bu nedenle bu bölümde ayrıntıya girilmemiştir.

 5.4. Yapısal Tasarım

Yapısal tasarımın ana hedefi, modüler bir yapı geliştirip modüller arasındaki kontrol ilişkilerini temsil etmektir. Ayrıca yapı tasarımı bazen veri akışlarını da gösteren bir içerime de yönelebilir. Geleneksel tasarımda en çok veri akışı ile ilgili modellemelerden yola çıkılarak bir mimari oluşturulmağa çalışılır. Veri akış diyagramlarında programın modüllerini oluşturacak olan süreçler yuvarlak şekiller ile temsil edilmekte idi. Bu süreçler, veri akışkarı da göz önünde bulundurularak bir modüller hiyerarşisi şeklinde yapı diyagramlarına çevrilebilirler. Temeli veri ve onun akışına bağlı yaklaşımların çokluğu sözkonusu ise de yapıyı öne çıkaran yaklaşımlar da vardır.

Örneğin Soyut Tasarım dünya görüşünde, tasarımcının daha üst düzeyde düşünen ve sistemin yapıtaşlarını ilk olarak ele alan bir insan olduğu varsayılır. Tasarımcı bu durumda sistemi hemen yapısal ögelerine ayrıştırarak işe başlar. Bu yaklaşımda tasarımcı bir miktar da çözümleme işlemini bir arada yürütmektedir. Geleneksel metodolojilerde ise modelleme yapan insanların alt düzeylerdeki bilgileri toparlayarak bir araya getirmesi ile süreç başlamaktadır. Verilerin belirlenmesi, ve hangi süreçlere girip çıkacaklarının saptanmasından sonra sistemin tümü hakkında yapılaştırılma başlanır.

 5.4.1. Genel Tasarım

Hedef, yapı diyagramı çizmektir. Veri akış diyagramından yola çıkılarak işlem türlerinin bölgeleri tanımlanır ve bu bölgelere karşı düşecek yapısal öğeler ortaya çıkarılmış olur. İstenilen yapı diyagramı kontrol hiyerarşisini de göstermektedir.

5.4.1.1. Dönüştürme Akışları

Genelde veri akışlarını üç parçaya ayırmak mümkündür. Girdi akışı, çıktı akışı ve işlem akışı. Sözü geçen işlem bölgeleri bu üç akış parçasına karşı düşer. Çıktı akışı, işlem bölgesindeki sürece bağlı olarak bir veya birden fazla olabilir. Tek çıktı akışına, dönüştürme türü bir süreç yol açar.

Şekil 5.4a: Dönüştürme Akışları

5.4.1.2. Ara İşlem Akışları

Birden çok çıktı akışına ise ara işlem bir süreç yol açar. Aşağıda bu iki tür akışa birer örnek verilmektedir. Bu örneklerde değişik bölgeler ayrılmış ve isimlendirilmiştir. Bu ayrıştırma işlemi tasarımcının insiyatifinde olmak üzere değişik şekillerde olabilir.

Şekil 5.4b: Ara İşlem Akışları

5.4.1.3. Yapı Diyagramlarında İlk Adım

Veri akış diyagramlarında kontrol bilgisi olmadığı hatırlanmalıdır. Bunlarda hangi işlemin önce yapılacağı gibi bir sıralandırma söz konusu değildir. Bu yüzden, yapı diyagramı çizildiğinde eğer kontrol bilgisi de içerilmek isteniyorsa tasarımcı biraz daha yaratıcı olup veri akış diyagramında olmayan kontrol akışlarını çıkartmak durumundadır. Bire bir karşı düşme yerine ekleme ve çıkartmalar da yapılır.

Şekil 5.5: Yapı Diyagramlarında İlk Adım

5.4.1.4. Yapı Diyagramlarında İkinci Adım

Veri akışında işlemlerin sırası görünmese de, para gönderme işlemini yaparken kullanılacak bakiye hesabı veya para çekme işlemleri için gereken miktar ve hesap numarası gibi bilgiler ilgili süreçlere gönderilebilir. Bu işlemler sıra halinde göz önünde canlandırılırsa, aslında ayrık çıktı akışlarının ilk süreçleri hariç sonraki işlemlerde ortak süreçler kullanılması olasıdır.

Yapı diyagramlarında bir ana süreç, girdi, işlem ve çıktı akışlarını temsil eden 3 alt öge ile temsil edilerek hiyerarşik modül yerleşimini temel alan çizimler yapılır. Veri işleme türünde bu üç öğe birer modül olarak ana sürecin altında yer alır. İşlem kararı türündeki akışlarda ise ana sürecin dönüştürme ve araişlem şeklinde iki alt modülü olur. Araişlem modülünün altında ise değişik çıktı akışları, birer modül olarak temsil edilirler. Geçiş işlemi genelde iki adımdan oluşur.

İlk adımda bölgeler ayrılarak kavramsal öğelere karşı düşürülür. İkinci adımda ise veri akış diyagramındaki süreçler modül olarak yapı diyagramlarında yerlerini alırlar. Bu işlemler de bir kerelik düşünülmemelidir, tasarımda sürekli bir iyileştirme çabası söz konusudur.

5.4.1.5. Genel Prensipler

Geçiş işlemini özetleyecek olursak yapılacak işler aşağıdaki gibi maddelendirilebilir:

• Sistem belirtimi ve çözümleme modellerinin incelenmesi
• Veri Akış Diyagramları irdelenerek gerekli iyileştirmeler yapılır. Ayrıntılı süreçler tanımlanırken modülerlik prensiplerine uygun davranılır (sıkılık ve bağlantısızlık).
• Akış türünün dönüştürme ya da ara işlem türünde olduğuna karar verilir.
• Veri işleme (ara işlem kararı) alt kümesini oluşturacak diyagram bölgesi saptanır. Üç değişik tür akış bölgeleri sınırlarıyla birlikte ortaya çıkar (girdi, işlem/karar, ve çıktı akış bölgeleri).
• İlk adım geçiş çizimi yapılır. Sözü geçen üç tür akışlar, soyutlanmış birer modül olarak sürecin tümüne karşı gelen kavramsal modülün altında yerlerini alır. (Şekil 5.4a)
• İkinci adım çizimi yapılır. İşlem merkezinden dışarıya doğru olmak üzere girdi akışları ve çıktı akışları, süreçlerin birer modül şeklinde temsil edilmesiyle alt alta yapı diyagramında yerlerini alırlar. Bir girdi akışına karşı düşen iki süreç, veri akış diyagramında akış yönündeki sıralandırılmalarının tersinde bir sıralandırma ile 'girdi akışı'na karşı düşen soyut modül altında dizilirler. Bu sıranın ters dönmesinin nedeni, işlem merkezinden dışa doğru bir kontrol hiyerarşisinin gerekliliğidir. Çıktı akışlarında ise sıra korunur. Modüller ortaya çıktıktan sonra bunların süreç belirtimleri de kısaca yapılabilir. Bu belirtimde:
  • Modüle giren ve modülden çıkan bilgiler
  • Modül içinde saklanacak bilgiler
  • Ana karar ve görev noktalarını açıklayıcı bir metin
  • Varsa diğer özel durumlar (zamanla ilgili, kütük işlemi gibi)yer almalıdır.
• Bütün yapılan işlemin tasarım prensipleri gözönünde tutularak iyileştirilmesi. Bir çıktı akışı, kendi içerisinde bir veri işleme türünden akış olarak tanımlanabilir ve alt düzeyde bir yapı diyagramı olarak şekillendirilebilir. Genel iyileştirme davranışına uygun olarak hiyerarşik şekilde yapı diyagramı da detaylandırılabilir. Özet olarak bir girdi veya çıktı akışı, ilk adımlarda tek modül iken daha sonra ayrı bir yapı diyagramı olarak ana diyagramda yerini alabilir: ilk adımdaki tek modülün altında çizilir.

 5.4.2. Ayrıntı Tasarım - Süreç/İşlem Tasarımı

Süreç tasarımı, veri, yapı, ve arayüz tasarımlarından sonra yapılır. İdeal şartlarda bütün algoritmik detayın belirtilmesi amaçlanır. Ayrıca süreç belirtiminin tek anlamlı olması gerekir. Değişik insanlar tarafından değişik yorumlanmamalıdır. Yine diğer öğelerde olduğu gibi süreç öğelerinde de doğal dillerle (Türkçe, İngilizce gibi) açıklamalar yapılabilir, ancak doğal diller tek anlamlı değildir. Daha formal yapılara gerek duyulur. Süreç belirtiminde grafiksel yöntemler olduğu gibi anlamlı olabilecek metin ortamları da kullanılabilir. Sürecin algoritmik yapısı gereği ayrıca matematiksel modeller de süreç belirtimini desteklemek üzere kullanılabilir. En çok kullanılan iki grafik süreç tasarım belirtimi, program akış diyagramları ve kutu diyagramlarıdır. Ayrıca tablo yapıları ile de süreç belirtimleri yapılabilir.

5.4.2.1. Yapısal Program Yapıları

Herhangi bir süreci veya programı üç temel yapının kompozisyonları ile ifade etmek mümkündür. 'Yapısal Programlar' bu üç yapıyı örgütlü olarak kullanırlar. Bu yapılar tek giriş ve tek çıkışlı, ardışıl, şartlı ve yinelemeli (döngü) yapılardır.

“Yapısal program”, tanımı gereği, yukarıda belirtilen üç temel kalıptan oluşmaktadır. Yapısal programlamanın temel amacı, program karmaşıklığını en aza indirmek ve programın anlaşılabilirliğini arttırmaktır. Teorik olarak herhangi bir programın yalnızca bu yapılar kullanılarak geliştirilebileceği kanıtlanmıştır. Bir başka deyişle, herhangi bir program “go to“ deyimi kullanılmaksızın yazılabilir. Bu nedenle, günümüzdeki programlama dilleri derleyicilerinin son sürümleri “go to” deyimini içermemektedir.

5.4.2.2. Program Akış Diyagramları

Yapısal programlamanın üç temel yapısına karşı düşen şekiller ile grafik olarak bir program temsil edilebilir. Aşağıdaki şekil program akış diyagramı öğelerini göstermektedir.

Şekil 5.7: Program Akış Diyagramı Yapıları

Program Akış Diyagramları yapısal program kuralları dışına çıkmayı engellemez. Örneğin, bir tekrar yapısının orta yerinde dışarıya veya dışarıdan içeriye dallanma yapmak mümkündür.

5.4.2.3. Kutu Diyagramları

Program Akış Diyagramları yapısal program kuralları dışına çıkmayı engellemez. Örneğin bir tekrar yapısının orta yerinde dışarıya veya dışarıdan içeriye dallanma yapmak mümkündür. Kutu diyagramları yapısal programlama için tasarlanmıştır. Yapıların içerdiği bölgeler daha açıkça görsellenebilmektedir. Şekil 5.8 da Kutu Diyagramı yapıları gösterilmektedir.

Şekil 5.8 Kutu Diyagramı Yapıları

5.4.2.4. Karar Tabloları

Bazen karmaşık koşul değerlendirmeleri yapmak gerekir. Bunların düzenli bir gösterimi karar tablolarında yapılabilir. Önce bütün işlemler saptanmalıdır. Sonra oluşabilecek ön-koşul olarak nitelenebilecek koşullar saptanır. Belirli işlemlerle belirli koşul kümelerini ilişkilendirilerek tablo doldurulur. Tablonun ilk satırları koşullar içindir ve sol tarafta satır başlıkları olarak koşullar yazılır. Alt tarafta ise işlemler benzer satırlar olarak başlıklarıyla yer alır. Tablonun ilk satırı, kuralları numaralandırmak üzere ve (ilk sütun dışında) her sütuna bir numara düşecek şekilde kullanılır. İlk sütun dışında her sütun bir kuralı temsil eder. Şekil 5.9 bir karar tablosunu göstermektedir.

Şekil 5.9 Karar Tablosu Örneği

5.4.2.5. Program Tasarım Dili

Bu diller, süreç belirtiminde doğal dillerin programlama dilleri ile sentezlenmesi şeklinde ortaya çıkmışlardır. Doğal dildeki sözcükler, programlama dilinin şekilselliği içerisinde kullanılarak yapılacak işlemler tanımlanmaktadır. Tasarım diline kısaca PDL (Program Design Language) denir. Bazen Yapısal İngilizce anlamına gelen 'Structured English' adı da kullanılır. Doğal dil kısmı İngilizce olarak tanımlanmışsa da istenildiği taktirde diğer doğal dillere de uyarlanabilir. Hangi programlama dilinden yola çıkıldığından bağımsız olarak belirli özellikler bulunmalıdır:

• Yapısal ögeler, veri yapıları ve modülerlik temellerini yansıtacak değişmez sözdizim
• Süreç ayrıntısını anlatacak serbest yapılı bir doğal dil
• Basit ve karmaşık veri yapılarını belirtebilecek kolaylıklar
• Alt program çağırma teknikleri

Aşağıda 'c' programlama dili ve Türkçeyi esas alan bir PDL ile yazılmış küçük bir örnek süreç belirtimi verilmiştir:

DO
        Hesap Numarasını Oku
        IF (hesap Numarası geçerli değil) başlangıca dön
        İşlem Türünü iste
        IF (para yatırma işlemi){PARA_YATIR();başlangıca dön}
        Şifre iste
        IF (şifre geçerli değil) başlangıca dön
        IF (İşlem Türü = bakiye) {BAKIYE(); başlangıca dön}
        IF (yeterli bakiye yok) başlangıca dön
        IF (İşlem Türü=gönderme) {PARA_GONDER(); başlangıca dön}
        IF (yeterli nakit yok) başlangıca dön
        ELSE PARA_VER()
WHILE ( devamlı)

5.5. Tasarlanması Gereken Ortak Alt Sistemler

Özellikle kurumsal uygulamalar, geliştirilecek bilgi sistemi yazılımlarının farklı kullanıcılar için farklı yetkilendirme düzeyleriyle kullanılmasını gerektirir. Dolaysıyla, bu tür uygulamalarda, kullanıcı tanımlama, kullanıcıyı yetkilendirme işlevlerinin tasarlanması gerekir. Kurumsal uygulamalarda kullanıcı yetkilendirmeleri;

İşlev bazındaki yetkilendirmeler, kullanıcıların bir işlevin tümüne erişmesini, olanaklı ya da olanaksız kılan yetkilendirmelerdir. Örneğin bir insan kaynakları yönetimi bilgi sisteminde, terfi işlemleri kullanıcısına, tayin İşlemleri ile ilgili yazılım birimine erişim yetkisinin verilmemesi gibi.

Ekran bazındaki yetkilendirmeler, bir ekranın tümüyle farklı kullanıcılara kapatılıp kapatılmayacağına ilişkin yetkilendirmelerdir. Yukarıda verilen örneği sürdürürsek, insan kaynakları yönetimi bilgi sisteminin, terfi işlemleri kullanıcılarından bazılarına yalnızca yeni terfi işleme, diğer bazılarına ise terfi raporlarını alma olanaklarını veren ekranlara erişim yetkilerinin tanımlanması gibi.

Ekranın alanları bazındaki Yetkilendirmeler, bir ekranın belirli alanlarının, yetkisi olan kullanıcılara gösterilip gösterilmemesi, yalnızca gösterme ancak günleme yetkisinin verilip verilmemesi türündeki yetkilendirmelerdir. Bu yetkilendirmeler, uygulamanın gereği olarak, menü listesindeki işlevler bazında olabileceği gibi, araç çubuğundaki düğmeler, ya da ekrandaki diğer veri alanları bazında istenebilir.

Yukarıdaki açıklamalardan da anlaşılabileceği gibi kullanıcı yetkilendirme ve tanımlama işlevleri, kullanılan yazılım geliştirme ya da veri tabanı yönetim sisteminin sağladığı kullanıcı yetkilendirme olanaklarıyla yapılamaz. Çünkü bu işlevler, çoğunlukla, geliştirilen uygulamanın kullanıcı ara yüzüyle doğrudan ilintilidir. Öte yandan kullanılan platformun yetkilendirme olanakları kullanılmaksızın, yetkilendirme alt sistemini gerçekleştirmek te her zaman olanaklı olmayabilir. Örneğin, ORACLE VTYS platformunun sağladığı kullanıcı yetkilendirme olanakları, veri tabanına erişim ile sınırlıdır. Bu nedenle, özellikle işlev bazında yapılacak yetkilendirmelerde doğrudan kullanılamayabilir. Öte yandan, ekran alanları bazındaki yetkilendirmeleri, eğer ORACLE platformu kullanılıyor ise, bu platformun sağladığı yetkilendirme olanakları kullanılarak gerçekleştirmek oldukça kolaydır.

Güvenlik alt sistemi, bilgi sisteminde yapılan işlerin ve yapan kullanıcıların izlerinin saklanması ve gereken durumlarda sunulması ile ilgilidir. Bir çok yazılım geliştirme ortamı ve işletim sistemi, bu amaca yönelik olarak, “sistem günlüğü” olanakları sağlamaktadır. Sistem Günlüğü ile sunulanın olanaklar yeterli olmadığı durumlarda ek yazılımlar geliştirilmesi gerekmektedir.

Kritik uygulamalarda, çevrim içi izleme ve denetime yönelik olan güvenlik alt sistemlerinin tasarlanması gerekmektedir. Özellikle, internete dayalı uygulamaların artmasından sonra, güvenlik konusu çok önem kazanmıştır. Güvenlik unsurunu geliştirme sürecinin tümüne yayan “Toplam Güvenlik Yönetimi” araştırmaları sürmektedir [Rayis 2000].

Her bilgi sistemi, olağan dışı durumlara hazırlıklı olmak amacıyla, kullandığı veri tabanını yedekleme ve yedekten geri alma işlevlerine gereksinim duyar. Günümüzde tüm veri tabanı yönetim sistemi geliştirme platformları, oldukça zengin yedekleme ve yedekten geri alma olanakları sağlamaktadır. Bu konuda, tasarım bağlamında yapılması gereken, yedekleme işleminin düzenlenmesini tasarlamak olmalıdır. Yedeklemenin hangi sıklıkla yapılacağı, ne zaman, elle ya da otomatik olarak yapılıp yapılmayacağı gibi planlamalar, tasarım aşamasında yapılmalıdır.

Coğrafik olarak dağıtık hizmet birimlerinde çalışan kurumlar için geliştirilecek bilgi sistemlerinde veri iletişim alt sistemleri önem kazanmaktadır. Veri iletişim alt sistemi, verilerin değişik hizmet birimleri arasında güvenli bir biçimde iletilmesi işlemlerini içermektedir. Uygulamada, temel olarak iki veri iletişim türü bulunmaktadır:

Çevrim-içi veri iletişimi: Verinin bir birimden diğerine anında iletilmesi olarak tanımlanır. Bu tür veri iletişimi, gerçek zamanlı sistemler için oldukça önemlidir. Bilgi Sistemi uygulamalarında, -zamansal kritiklik, gerçek zamanlı uygulamalara oranla daha az olduğu için - bu tür iletişim çok yaygın değildir.

Günümüzde bilgi sistemlerinin uygulamalarında, giderek web tabanlı tasarımlara yönelinmektedir. Çevrim-içi veri iletişimi, kurumsal internet ağı üzerinden gerçekleştirilecek biçimde tasarlanmalıdır.

Özellikle iletişim alt yapısının yetersiz olduğu durumlarda, “kargo” tipi veri iletişim alt sistemleri planlanmaktadır. Bu tür alt sistemlerde, gerek gönderici tarafında gerekse alıcı tarafında, gerekli düzenlemeleri yapacak modüllerin geliştirilmesi gerekmektedir. Söz konusu düzenlemeler; kargonun hazırlanması (paketleme), kargonun gönderilmesi, kargonun açılması, kargonun izlenmesi, kaybolma ya da iletilememe durumunda yeniden gönderilmesi vb türünde işlemlerdir. Kargo işlemleri genellikle, günün ölü saatlerinde gerçekleştirilmektedir.

Çevrim-dışı veri iletişimi: Bilgilerin iletişim hatları kanalıyla değil, çevrim dışı ortamlar (teyp, disket, cd vb) aracılığı ile iletilmesi çevrim dışı iletişim olarak tanımlanmaktadır. Kısacası, yukarıda “kargo” olarak tanımlanan iletişimin, el ile yapılan türüdür. Ağ iletişiminin sağlanamadığı durumlarda kullanılan bir yöntemdir. Kullanımı giderek azalmaktadır.

Arşiv alt sistemleri, bilgi sistemi uygulamalarında, belirli bir süre sonrasında sık olarak kullanılmayacak olan bilgilerin ayrılması ve gerektiğinde bu bilgilere erişimi sağlayan alt sistemlerdir.

Örnek: İnsan kaynakları yönetimi bilgi sisteminde, emekli olan bir kişiye ilişkin bilgilerin, çevrim-içi olarak tutulan veri tabanından alınarak, çevrim dışı bir ortama alınması ve aradan örneğin beş yıl geçtikten sonra, pasaport işlemleri için gerek duyulabilecek kişi bilgilerine erişilmesini sağlayan işlemler arşiv alt sistemleri tarafından gerçekleştirilmektedir.
İşlem türü olarak ortak bir çok özellik içeren arşiv alt sistemleri, uygulama bazında az da olsa farklılaşabilmektedir.

Geliştirilen bilgi sistemi yazılımı, uygulamaya alınmadan önce, varsa veri dönüştürme (mevcut sistemde bilgisayar ortamında saklanan bilgilerin yeni geliştirilen bilgi sistemi ortamına aktarılma) gereksiniminlerine ilişkin işlemler Dönüştürme alt sistemi tarafından gerçekleştirilir. Mevcut uygulamalardaki bilgisayar ortamında saklanan bilgilerin ortam çeşitliliği dönüştürme işlemlerini zorlaştırır.

 5.6. Kullanıcı Arayüz Tasarımı

Gerçekte, iki tür arayüz ve bunların tasarımından söz edebiliriz. Kullanıcı ile ilişkisi olmayan arayüzler; modüller arası arayüz ve sistem ile dış nesneler arasındaki arayüzdür. Diğer tür ise kullanıcı arayüzüdür. Modüller arası arayüz, temelde veri akış diyagramındaki süreçler arasında akan verinin özellikleri ile ortaya çıkar. Dış nesneler ile olan arayüzler de benzer şekildedir. Veri iletişiminde bulunacak iki tarafın gereksinimleri incelenir ve uygulamada bu akacak olan verinin biçemi ve zamanlamasının kontrolü ile arayüzler tanımlanır. Veri birimlerinin alt ve üst değer sınırları gibi bilgilerin de belirtilmesi ve bunların çalışma sırasında kontrol edilmesi ve sistemin buna göre yanıtının neler olabileceği tasarlanmalıdır.

Kullanıcı arayüzleri, yalnızca sistem ve modelleri ile değil, insanları da konu alan bir çalışma gerektirir. Kullanıcı özellikleri öne çıkmaktadır. Ürünün başarısı, kullanıcıların onu ne kadar benimsedikleri ile orantılı olacaktır. Ayrıca kaliteye etki eden faktörlerden bazıları da kullanıcı arayüzü ile yakından bağlantılıdır. Kullanım kolaylığı, öğrenim zamanı kısalığı gibi faktörler çok önemlidir. Yeni kullanıcının çabuk öğrenmesi yanında deneyimli kullanıcıların da bazı komutları kısayoldan geçebilmeleri gibi daha karmaşık işlemleri daha çabuk yapmalarına yönelik önlemler de bulunmalıdır.

Kullanıcı arayüzleri, özellikle Windows gibi grafik ağırlıklı programlama ortamlarının yayılmasından sonra çok fazla önem kazanmıştır. Arayüz çabasının projenin içinde en önemli kısmı olduğu savunulmaktadır. Hatta, “program = arayüz” gibi abartılı deyimler de kullanılmıştır. Kullanıcı arayüzü öntiplemesi de güncel olarak çok önemli olduğu için, bu çalışma tasarım çalışması içerisinde önemini korumakla birlikte, gereksinim çalışması sırasında da kısmen gerçekleştirilen bir çalışmadır.

5.6.1. Kullanıcı Arayüzü Özellikleri

• Komut seçimi, veri giriş formlarının şekli gibi bir çok konuda tutarlı bir yapı izlenmelidir,
• Önemli silmelerde teyit alınması,
• Çoğu işlemin gerçekleştirildikten sonra kolayca geri alınabilmesi,
• İşlemler arasında ezbere tutulacak bilgi miktarının azaltılması,
• Kullanıcı hareketleri, düşünme ve algılamasında verimlilik,
• Hataların affedilmesi: yanlış giriş olduğunda program korunmalı ve düzeltme şansı vermeli,
• İşlemleri sınıflandırıp ekran geometrisini buna uygun olarak kullanmak,
• İçinde bulunulan konuya duyarlı yardım kolaylıklarının temini,
• Komut isimlerinin kısa ve basit olması,
• Eğer Windows ortamında çalışılıyorsa bu sahada en yaygın programlardaki menü ve diğer etkileşim yapılarına uygun standart yapılar tasarlanmalıdır. Örneğin çıkış komutu en soldaki menünün en altta gösterilen komutu olmalıdır.
• Yalnızca içinde bulunulan konu çerçevesi ile ilgili bilgi gösterilmeli
• Veri çokluğu ile kullanıcı bunaltılmamalı, graf ve resim temelli gösterimler yeğlenmeli
• Tutarlı başlıklar, renklemeler ve kısaltmalar kullanılmalı: Ekran yapılarını anlamak için dış kaynaklara ihtiyaç olmamalıdır
• Büyükçe bir grafik gösterim ekranın dışına taşıp kaydırlımağa başlaması durumunda bir köşede şeklin tümü küçük bir çerçevede, ve ne kadarının ekranda gösterilmekte olduğunu belirleyecek şekilde verilmelidir
• Hata mesajları açıklayıcı ve anlaşılır olmalı, hata kodları ile yetinmekten kaçınmalıdır
• Büyük/küçük harf, tutarlı aralıklandırma ve sözcük gruplandırması gibi tekniklerle anlaşılırlık arttırılmalıdır
• Değişik tür bilgileri sınıflandırmak için pencere yapılarından faydalanılmalıdır
• Rakamsal ifadelerden çok 'analog' görüntülere yer verilmelidir: Depodaki benzin miktarını gösterirken '%67' yerine termometreye benzeyen bir şekil tercih edilmelidir.
• Kullanıcı hareketlerini en aza indirmelidir. Yazma yerine ekrandaki listelerden seçme, bir komuta en az sayıda fare tıklamasıyla erişme gibi
• Gösterim ve girdi sahalarını ayırdedecek biçemler (renk, büyüklük, yerleşim..) tutarlı olarak kullanılmalıdır
• Kullanıcı uyarlamasına izin verilmelidir: Kullanıcı yeni komutlar tanımlayabilir, bazı uyarı mesajlarını istemeyebilir
• Fare veya klavyenin seçilmesi gibi seçenekli girdi yöntemlerine yol açılmalıdır
• Kullanılan konu içinde geçersiz komutlar geçici olarak etkisizleştirilmelidir
• Kullanıcı, kontrol akışını belirleyebilmelidir: mümkün olduğunda istediği sırada işlemleri yönlendirebilmelidir
• Bütün girdi işlemleri için yardım kolaylıkları olmalıdır.

5.6.2. Kullanıcı Arayüz Prototipi

Tasarım çalışması sonucunda, daha önceden gereksinim çalışması sırasında hazırlanmış olan kullanıcı arayüz prototipi, ekran ve rapor tasarımları biçimine dönüşür. Ekranlar, son halini alır, raporların biçimleri kesinleştirilir. Kullanıcıya gösterilerek onay alınır. Ekran tasarımları yapılırken, daha önceki bölümlerde belirtilen kullanıcı arayüz standartları ve ipuçları kullanılmalıdır.

Genellikle büyük boyutlu uygulamalar yüzlerce ekran içerebilmektedir. Birden fazla ekibin yer aldığı bir geliştirme ortamında, kullanıcıya yazılımın tek elden çıktığı izlenimini vermek, hem kullanım kolaylığı, hem de bakım rahatlığı açısından önemlidir. Bu nedenle tüm uygulama ekranlarının aynı şablon üzerine oturtulması önerilmektedir. Tipik bir şablonda bulunması gereken alanlar :

Menü çubuğu Araç Çubuğu Gövde Durum Çubuğu

biçiminde özetlenebilir. Tüm uygulama ekranları için menü çubuğu, araç çubuğu, ve durum çubuğu aynı olmalı, uygulamanın parçalarına göre, menü detayları ve gövde değişmelidir. Çok gerekiyorsa araç çubuğu ve menü çubuğu üzerinde en çok %5 oranında değişikliklere izin verilebilir.

5.7. Diğer Tasarım Etkinlikleri

Tasarım çalışmasında, geliştirilecek yazılımın yalnızca veri ve süreç tasarımı yapılmaz, diğer öğeler de dikkate alınır. Sınama belirtimleri hazırlanır, kullanıcı kılavuzları daha detaylandırılır..

Tasarımda, yazılımın her bileşeni ya da modülü ayrıntılı olarak ortaya çıktığı için sınama belirtimleri kolayca hazırlanır. Sınama belirtimlerinin yapısına ilişkin bilgiler Bölüm 7’de verilmiştir. Sınama belirtimleri, birim sınama, bütünleştirme sınama ve sistem sınama belirtimleri olarak hazırlanır. Özellikle sistem sınamaya ilişkin belirtimler iş fonksiyonlarına yönelik senaryolar biçiminde hazırlanır. Bu belirtimler, gerçekleştirim çalışmasında sınama girdisi olarak kullanılır.

Kullanıcı Kılavuzlarına ekran görünümleri, rapor görünümleri ve bir ya da bir kaç ekran ve rapor ile ilgili ayrıntılı açıklamalar eklenir.

 5.8. Tasarım Çalışmasının Değerlendirilmesi

Tasarım çalışmasının kalitesini ölçmek amacıyla çeşitli yöntemler kullanılmaktadır. Bu bölümde, iki temel yaklaşım anlatılmaktadır. Tasarım Denetim listesi ve Tasarım Kalite ölçütleri.

5.8.1. Tasarımın Gözden Geçirilmesi

Başlangıç tasarım gözden geçirme çalışmasında, kavramsal tasarımı kullanıcılarla birlikte incelenir. Ayrıntı tasarımda ise, tasarım teknik yönüyle incelenir. Gözden geçirme çalışmaları izleyen bölümde açıklanmıştır.

Başlangıç Tasarımı Gözden Geçirme çalışmasının temel amacı, yapılan tasarım çalışmasının bir önceki geliştirme aşaması olan çözümleme aşamasında belirlenen gereksinimleri karşılayıp karşılamadığının belirlenmesidir. Bu çalışma:

• Sistem gereksinimlerine yardımcı olan kullanıcılar,
• Sistem çözümlemeyi yapan çözümleyiciler,
• Sistemin Kullanıcıları,
• Tasarımcılar,
• Yönlendirici,
• Sekreter,
• Sistemi Geliştiriecek kişilerden

oluşan bir ekip tarafından yürütülür. Bu çalışma denetim listeleri kullanılarak yapılır. Denetim listelerinde aşağıdaki soruların yanıtları aranır:

• Yazılım gereksinimlerin tümü genel tasarımda içerilmiş mi?
• Etkin modülerlik sağlandı mı? Modüller işlevsel olarak birbirinden bağımsız mı?
• Dışsal sistem öğeleri için arayüzler tanımlanmış mı?
• Veri yapısı yazılım gereksinimleri ile uyumlu mu?
• Bakım faktörü dikkate alınmış mı?
• Kalite ölçütleri kullanılmış mı?

Başlangıç tasarımı gözden geçirme çalışmasının başarılı bir biçimde tamamlanmasından sonra, tasarımın teknik uygunluğunu belirlemek için Ayrıntılı Tasarım Gözden Geçirme çalışması yapılır. Bu çalışmada Çözümleyiciler, Sistem tasarımcıları, Sistem Geliştiricileri ve Sekreter den oluşan bir ekip kullanılır. Bu çalışmada

1. Algoritmalar istenen işlevleri karşılıyor mu?
2. Arayüzler genel tasarımla uyumlu mu?
3. Mantıksal karmaşıklık anlamlı mı?
4. Veri yapısı çözümleme çalışması sırasında elde edilen veri modeli ile uyumlu mu?
5. Belirlenen tasarım standartlarına uyulmuş mu?
6. Hata çözümleme tanımlanmış mı?
7. Yerel veri yapıları uygun olarak tanımlanmış mı?
8. Tasarım, kullanılacak programlama diline uygun mu?
9. İşletim sistemi ve programlama diline yönelik kısıtlar ya da özellikler kullanılmış mı? Kullanılmış ise hangileri?
10. Bakım dikkate alınmış mı?

sorularına yanıtlar aranır. Çalışma denetim listeleri kullanılarak yapılır.

 5.8.2. Tasarım Kalite Ölçütleri

 5.8.2.1. Bağlaşım

Bağlaşım, modüllerarası bağlılığın ölçülmesi için kullanılan bir ölçüttür. Yüksek kaliteli bir tasarımdan beklenen bağlaşım ölçümünün az olmasıdır. Düşük bağlaşıma sahip olan bir tasarım, iyi bölümlenmiş bir sistem anlamını taşır. Bağlaşımın düşük olması:

• Hatanın, dalgasal yayılma özelliğinin azaltılması (bir modülde oluşacak bir hatanın diğer modüllere yayılmaması),
• Modüllerin bakım kolaylığı,
• Modüller arası ilişkilerdeki karmaşıklıkların azaltılması
  

nedenleriyle istenmektedir. Yalın Veri Bağlaşımı, Karmaşık Veri Bağlaşımı, Denetim Bağlaşımı, Ortak Veri Bağlaşımı, İçerik Bağlaşımı olmak üzere beş bağlaşım türü bulunmaktadır.

Yalın Veri Bağlaşımı: Herhangi iki modül arasındaki iletişim yalın veriler (tamsayı, karakter değişkenler vb) aracılığı ile gerçekleştiriliyorsa bu iki modül yalın veri bağlaşımlıdır şeklinde tanımlanır. Bir tasarımda modüller arası iletişim kaçınılmaz olduğundan dolayı veri bağlaşımı da kaçınılmazdır.

Şekil 5.10 Yalın veri bağlaşımlı iki modül örneği

Şekil 5.10’ da MAAŞ HESAPLA ve NET ÜCRET HESAPLA modülleri arasındaki iletişim “Brüt Maaş” adlı yalın veri ( bu örnekte bir gerçel değer) aracılığı ile yapılmaktadır.. Bu nedenle bu modüller , yalın veri bağlaşımlıdır. Bir tasarımda, modüller arasında Yalın veri bağlaşımı olması istenen bir özelliktir. Ancak, tasarımda, hiçbir değişikliğe uğramadan modüller arası dolaşan yalın veri kullanımından kaçınılmalıdır.

Karmaşık Veri Bağlaşımı: Herhangi iki modül arasındaki iletişimde kullanılan parametrelerin karmaşık veri yapısı (dizi, kayıt vb) olması durumunda bu modüller karmaşık veri bağlaşımlı olarak tanımlanır.

Şekil 5.11 Karmaşık Veri Bağlaşımlı modüller

Şekil 5.11’’de “İşçi Kaydı” olarak belirtilen parametrenin bir kayıt yapısı olduğu varsayılmaktadır. Bu nedenle şekildeki iki modül karmaşık veri bağlaşımlıdır. Modüller arası karmaşık veri iletişiminde, gerekli olmayan verilerin yer alması (Örneğin: bir dizinin yalnızca bir eleman ile ilgili işlem yapmak için bu eleman yerine tüm diziyi parametre olarak göndermek gibi) ve gereksiz gruplama (örneğin, bir biri ile hiçbir ilgisi olmayan birden fazla yalın veriyi bir kayıt içerisinde toplayarak bu kaydı parametre olarak gönderme gibi) işlemlerden kaçınılmalıdır.

Denetim Bağlaşımı: İki modül arasında iletişim parametresi olarak “denetim verisi” kullanılıyorsa bu iki modül denetim bağlaşımlı olarak tanımlanır. Denetim verisi, modül içerisinde koşullu işlemlerdeki koşul içerisinde kullanılan sayısal ya da mantıksal içerikli veridir. Örneğin Kütük-sonu-göstergesi vb.

Kütük –Sonu-Göstergesi (Şekil 5.12) girdi kütüğünün sonuna ulaşılıp ulaşılmadığını gösteren mantıksal bir değer (Doğru ya da yanlış) içermektedir. Bu değer MAAŞ HESAPLA modülünde bir koşullu işlem içerisinde denetim amacıyla kullanılmaktadır. Bu türde bir modülden diğerine denetim amacıyla parametre gönderilmesi, tasarımda “zayıf bölümleme”yi göstermektedir.

Ortak Veri Bağlaşımı: Eğer iki modül, ortak bir alanda tanımlanmış verilere ulaşabiliyorlarsa, bu iki modül , ortak veri bağlaşımlı olarak tanımlanır. Ortak veri bağlaşımı, aşağıda belirtilen temel nedenlerden ötürü tasarımda istenmeyen bir özelliktir.

- Ortak alanda tanımlanmış ve birden çok modülün eriştiği bir veri alanını izlemek zordur. Bu, programların anlaşılabilirliğini zorlaştırır.

- Ortak veri kullanan modüllerde yapılan değişiklikler, diğer modülleri etkiler. Program bakımı zorlaşır.

- Ortak veri üzerinde yapılan değişikliklerde, bu veriyi kullanan modüllerin de dikkate alınması gerekir.

İçerik bağlaşımı: En istenmeyen bağlaşım türü içerik bağlaşımıdır. Modüllerin iç içe tasarlanmaları sonucu, bir modülün bir başka modül içerisinde tanımlanmış veri alanına erişebilmesi olanaklaşır ve bu durum içerik bağlaşımına neden olur.

Örneğin, öbek yapılı dillerde bir modülün bir başka modülü içermesi ve içteki modülün, kendini içeren modüldeki veri alanına ulaşabilmesi gibi.

5.8.2.1.1. Bağlaşım Hesaplama

Tablo 5.1 Bağlaşım Türleri

Tablo 5.1’de verilen ölçekler kullanılarak, bir tasarımın bağlaşım düzeyi iki adımda hesaplanabilir:
Adım-1: Her Modül ikilisinin bağlaşım düzeyini hesapla
Adım-2: Tüm tasarımın bağlaşım düzeyini hesapla

Adım-1 : Her Modül ikilisi için Bağlaşım Düzeyi Hesaplama:
Herhangi bir modül ikilisi arasındaki bağlaşım düzeyinin hesaplanması için öncelikle bu iki modül arasında geçişen parametrelerin incelenmesi gerekmektedir. Söz konusu parametre türleri:
1 – Yalın Veri
2 – Karmaşık Veri
3 – Denetim Verisi
4 – Ortak veri
5 – İçerik Verisi

biçimindedir. Bu durumda , iki modül arasındaki bütün parametre türleri öncelikle belirlenmelidir. Herhangi iki modül arasındaki iletişimde birden fazla türde parametre kullanılabilir. Örneğin: Bir modül diğerine yalın veri içeren bir parametre gönderip, ondan denetim verisi içeren bir parametre alabilir. Bu durumlarda iki modül arasındaki bağlaşım düzeyine karar verebilmek için iki stratejiden biri izlenebilir.

Strateji-1: İki modül arasnda birden fazla bağlaşım özelliği varsa en yüksek dereceli olanını al. Örneğin; A ve B modülleri arasındaki iletişimde üç bir yalın veli parametresi ve bir denetim verisi parametresi kullanılıyorsa, A ve B modüllerinin denetim bağlaşımlı olduğuna yani bağlaşım düzeyinin 3 olmasına karar verilmesi.

Strateji-2: iki modül arasındaki her bağlantı türünü ayrı ayrı dikkate almayı öngörür. Bu amaçla aşağıdaki algoritma kullanılır.

her farklı bağlantı türü için
parametre sayısını hesapla
bu sayıyı o bağlantı türüne karşılık gelen ölçek sayısı ile çarp
bütün bağlantı türleri için elde edilen çarpım sonuçlarını topla
Toplam sonucu toplam parametre sayısına böl
Yukarıda verilen basit algoritmanın uygulanması ile iki modül arasındaki tüm bağlantı türleri ayrı ayrı dikkate alınmış olur.
Aşağıdaki örnekte her iki strateji arasındaki farklılık gösterilmektedir.

Örnek:
Bir tasarımda bulunan A ve B modülleri arasındaki iletişmde, 1 denetim verisi, 4 yalın veri, 2 karmaşık veri, ve 1 ortak veri kullanıldığını varsayalım. Bu durumda Strateji-1 ve Strateji-2’ye göre A ve B modüllerinin bağlaşım düzeyi (Cp (A,B) ) aşağıdaki gibi hesaplanacaktır:

Strateji-1: Cp(A,B) = 4
(A ve B modülleri arasındaki bağlaşım türlerinden en yüksek dereceli olanı ortak veridir. Yukarıdaki tabloda ortak veri için ölçek 4’tür.)

Strateji-2:
Cp(A,B) = ( 4 x 1 + -- 4 yalın veri
2 x 2 + -- 2 karmaşık veri
1 x 3 + -- 1 denetim verisi
1 x 4 ) / 8 -- 1 ortak veri, toplam 8 parametre
= 15 /8 = 1,875

Uygulama kolaylığı ya da bu amaca ilişkin olarak elde bulunan aracın özelliklerine göre iki stratejiden biri benimsenebilir. Sonuç olarak, elde edilen değerin 1’e yakın olması istenen durumdur. Kullanılacak stratejiye göre, modüller arasındaki bağlaşım için sınır değerler saptanarak, uygulamada bu değerlerin üzerine çıkılmaması istenebilir. Örneğin Strateji-1 için modüller arasındaki bağlaşım düzeyinin 3’ten fazla olmaması gibi bir sınır değeri tanımlayıp, tasarımı incelerken, bu değerin üzerinde bağlaşım değeri olan modüllerin yeniden ele alınması, tasarımlarının değiştirilmesi gibi bir uygulama endüstride yaygın olarak kullanılmaktadır.

Adım-2 : Tüm Tasarımın Bağlaşım Düzeyinin Hesaplanması:
Tüm tasarımın bağlaşım düzeyi, yalın olarak modül çiftlerinin bağlaşım düzeyi olarak hesaplanabilir. Yine kullanılacak stratejiye göre, tüm tasarım bazında bir bağlaşım düzeyi sınırı saptanabilir ve bu sınır düzeyinin üzerine çıkan tasarımlar kabul edilmez.

 5.8.2.2. Yapışıklık

İşlevsel yapışık bir modül, tek bir iş problemine ilişkin sorunu çözen modül olarak tanımlanır. Örneğin, Sinüs-Hesapla, Maaş-Hesapla, Maaş-Çeki-Hazırla gibi modüller işlevsel yapışık modüllerdir. Çünkü her biri, ilgili oldukları işe yönelik bir iş problemini çözmektedir.

Öte yandan Kayıt-oku gibi bir modül işlevsel yapışık değildir. Bazı kaynaklarda, işlevsel yapışıklık terimi yerine “dışsal yapışıklık” terimi kullanılmaktadır.

Bir Modülün içerisindeki işlemler incelendiğinde, bir işlemin çıktısı diğer işleme girdi olarak kullanılıyorsa, bu modül sırasal yapışık bir modül olarak adlandırılır. Aşağıda bu tür bir modül örneği verilmektedir.

Module Kayıt-Oku-Düzelt Uses Ham-Veri-Kaydı
Ham-Veri-Kaydı nı Düzelt
Düzeltilmiş- Ham-Veri-Kaydı nı Doğrula
Doğrulanmış-Düzeltilmiş Ham-Veri-Kaydı nı Gönder
End module

Bir Modülün içerisindeki işlemler incelendiğinde, eğer farklı işlemler aynı girdi ya da çıktıyı kullanıyorlarsa bu modül iletişimsel yapışık bir modül olarak adlandırılır. Aşağıda bu tür bir modül örneği verilmektedir.

Module Kişi-Detay-Bul
Uses Kişi-Sicil-No
Kişi-Adres-bilgisi bul
Kişi Maaş-Bilgisi bul
Kişi-Adres-Bilgisi, Kişi-Maaş-Bilgisi gönder
End module
Yukarıdaki örnekte, Kişi-Sicil-No bilgisi, modül içinde bulunan Kişi-Adres-Bilgisi bul ve Kişi-Maaş-Bilgisi bul işlemleri tarafından girdi olarak kullanılmaktadır. Bulma işlemlerinin uygulama sırası önemli değildir. Bu özelliği ile iletişimsel yapışık modüllerin bakımları kolaydır.

Yordamsal Yapışık bir modüldeki işlemler arasında denetim ilişkisi bulunmaktadır. İşlemlerin birbirleri ile veri ilişkisi yoktur. Ancak işlem sırası önemlidir. Büyük olasılıkla bu tür modüller tam bir işlev görmeyip, başka modüler tarafından belirli bir akış mantığı içinde çağrılan belirli işlevleri yerine getiren modüllerdir. Aşağıda bu modüllere bir örnek verilmektedir.
Module Oku-Yaz uses Yazılacak-Veri
Yazılacak-Veri yi yaz
Giriş-Kaydı nı oku
Giriş-Kaydı nı gönder
End Module
Bu modüldeki varsayım, modülün çağıran modül tarafından bir döngü içerisinde çağrıldığı, gelen bilgiyi yazma ve yeni bilgiyi okuma işlevlerini yerine getirdiğidir. Yazılacak-Veri bilgisinin bir bölümünde önceden okunmuş Giriş-Kaydı bilgisi olduğu varsayıldığından, okuma ve yazma sırası önemlidir.

Bir modülün içerisindeki işlemleri n belirli bir zamanda uygulanması gerekiyor ve bu işlemlerin kendi aralarında herhangi bir ilişkisi yok yani aralarında veri iletişimi yok ve işlemlerin sırası önemli değil ise bu tür modüller zamansal yapışık modüller olarak nitelenir. Zamansal yapışık modüller ile yordamsal yapışık modüller birbirlerine benzemektedir.

Aralarındaki tek fark, yordamsal yapışık modüllerde işlem sırası önemli iken, zamansal yapışık modüllerde işlem sırası önemli değildir. Zamansal yapışık modüle örnek olarak, Alarm zilini çal, Kapıyı aç, Kamerayı çalıştır gibi işlemleri bünyesinde toplayan bir modül verilebilir.

Mantıksal olarak aynı türdeki işlemlerin bir araya toplandığı modüller mantıksal yapışık modül olarak nitelendirilir. Bu modüllerde yapılan işlemlerin sırası önemli değildir. Aralarında veri iletişimi yoktur.
Module değişkenlere-Başlangıç-Değeri-Ver
define A dizisi as 100 integer elements,
B kaydı as 80 char,
C dizisi as 50 real elements,
Toplam, N as integer,
for N = 1 to 100
A dizisi (N) = 0
endfor
for N = 1 to 50
C dizisi (N) = 0.0
end for
Toplam = 0.0
B-Kaydını sıfırla doldur
Return A dizis, B kaydı, C dizisi, Toplam
end module

Gelişigüzel yapışık bir modülün işlemleri arasında herhangi bir anlamlı işilki bulunmaz. Aşağıda bir örnek verilmektedir.

Module Çeşitli-İşlemler
Ara-kayıt oku
B-dizisi ne başlangıç değerleri ata
Stok kütüğünü oku
Hata iletisi yaz
end module

Bu tür modüllerdeki işlemler arasında veri, zaman, denetim ilişkilerinden hiçbiri bulunmaz. Bu nedenle bu yapışıklık türü, diğerleri arasında en kötü olanıdır.

5.8.2.2.1. Yapışıklık Hesaplama

Tablo 5.2 Yapışıklık Türleri

Yapışıklık hesaplama için kullanılacak ölçekler tablo 5.2’de verilmiştir. Şekil 5.13’de verilen karar ağacı, bir modülün yapışıklık düzeyini belirlemek amacıyla kullanılabilir.

Genel olarak bir modülün yapışıklık düzeyini hesaplamada bazı güçlüklerle karşılaşılabilir. Çünkü, bir modüldeki işlemler hep aynı tür özellik göstermeyebilir. Yani, hep sırasal işlemlerden oluşan ya da hep iletişimsel işlemlerden oluşan modüller yazmak, teorik olay kolay ancak uygulamada zordur. Bu durumda yapışıklık düzeyi kararı nasıl verilecektir?

5.8.2.2.2. Yapışıklık Düzeyine Karar Verilmesi

Bir modülün yapışıklık düzeyine karar verilebilmesi için aşağıdaki iki etken dikkate alınmalıdır.

1) Modüldeki bütün işlemler arasındaki ilişkiler incelendiğinde birden fazla yapışıklık özelliği gösteren farklı işlemler bulunabilir. Bu durumda modül için en zayıf yapışıklık düzeyine karar verilmelidir. Örneğin bir modüldeki işlemlerden bazılarının sırasal yapışıklık, bazılarının iletişimsel yapışıklı diğerlerinin ise yordamsal yapışıklık özellik gösterdiğini varsayalım. Bu özelliklerden en zayıfı yordamsal yapışıklıktır.

Bu durumda, bu modül yordamsal yapışık bir modüldür kararı verilir ve yapışıklık düzeyi 4 olarak alınır.

Şekil 5.13 Modül Yapışıklığı İçin Karar Ağacı

2) Modüle tüm olarak bakıldığında birden fazla yapışıklık özelliği ortaya çıkıyorsa bu durumda en güçlü yapışıklık düzeyine karar verilmelidir. Örneğin, bir modül hem mantıksal yapışıklık özelliği hemde, işlemleri incelendiğinde iletişimsel yapışıklık özelliği gösteriyorsa bu modül için iletişimsel yapışıklık özelliğine sahiptir denir ve yapışıklık düzeyi 3 olarak belirlenir.

Yapışıklık, modül özelinde bir ölçüt olduğu için bir tasarımın tümünün yapışıklık düzeyinden söz edilemez. Tek tek modüllerin yapışıklığından söz edilebilir. Bir tasarımdaki tüm modüller incelendiğinde gelişigüzel yapışık modüllerin hiç bulunmaması gerekir. Mantıksal yapışık modül sayısının düşük tutulması, olabilirse sırasal yapışık modül sayısının yüksek tutulması önerilmektedir.

 5.9. Tasarım Raporu İçeriği

Örnek tasarım raporu içeriği izleyen sayfada verilmiştir. İçeriğin hazırlanmasında IEEE/ANSI standartları kullanılmıştır.Büyük boyutlu projeler için burada verilen içerik, genel mantık aynı kalmak koşulu ile detaylandırılabilir. Örneğin 200 kişi-yıllık işgücü gerektiren bir BT projesi, şekil 5.1’te belirtilen biçimde bölümlenebilir.

Şekil 5.14 Büyük Bir BT Projesindeki Sıradüzen

5.9.1. Örnek Tasarım Raporu İçeriği

Bu bölümlemede, BT projesi, birbiriyle ilişkili kümeler ve her küme de bilgi sistemlerinden oluşmaktadır. Örneğin, Sağlık Bakanlığı Çekirdek Kaynak Yönetim Sistemi Projesi; İnsan Kaynakları Yönetim Kümesi, Mali Kaynaklar Yönetim Kümesi, Malzeme Kaynakları Yönetim Kümesi, İlaç-Eczacılık Kümesi biçiminde dört ana kümeye ayrılmış, her bir küme de kendi içerisinde bilgi sistemleri bazında bölümlenmiştir. Bu durumda Yazılım Tasarım Raporu, tüm kümeler için ortak bir rapor ve her bir küme için ayrı ayrı raporlar biçiminde hazırlanmalıdır.

1.Giriş
     1.1.Kapsam
     1.2.Tanımlar, Kısa Adlar ve Kısaltmalar
     1.3.Referanslar
     1.4.Belgenin Yapısı.
2.Genel Tasarım Bilgileri
     2.1.Genel Sistem Tanımı
     2.2.Varsayımlar ve Kısıtlamalar
     2.3.Sistem Mimarisi
     2.4.Dış Arabirimler
     2.4.1.Kullanıcı Arabirimleri
     2.4.2.Veri Arabirimleri
     2.4.3.Diğer Sistemlerle Arabirimler
2.5.Veri Modeli
     2.6.Testler
     2.7Performans
3.Veri Tasarımı
     3.1.Tablo tanımları
     3.2.Tablo- İlişki Şemaları
     3.2.Veri Tanımları
     3.3.Değer Kümesi Tanımları
4.Süreç Tasarımı
     4.1Genel Tasarım
     4.2Modüller
          4.2.1XXX Modülü
               4.2.1.1 İşlev
               4.2.1.2 Kullanıcı Arabirimi
               4.2.1.3 Modül Tanımı
               4.2.1.4 Modül iç Tasarımı
          4.2.2YYY Modülü
     4.3Kullanıcı Profilleri
     4.4Entegrasyon ve Test Gereksinimleri
5.Ortak Alt Sistemlerin Tasarımı
     5.1.Ortak Alt Sistemler
     5.2.Modüller arası Ortak Veriler
     5.3.Ortak Veriler İçin Veri Giriş ve Raporlama Modülleri
     5.4.Güvenlik Altsistemi
     5.5.Veri Dağıtım Altsistemi
     5.6.Yedekleme ve Arşivleme İşlemleri
EKLER
EK-ARapor Görünümleri
EK-BTest Belirtimleri
EK-CKullanıcı Kılavuzu Örneği

Bölüm Özeti

1) Ortak alt sistemler oldukça önemlidir. Tasarlanması ve geliştirilmesi için ayrı bir yazılım ekibi kullanılması gerekir. Aksi durumda, tutarsızlık ve işlem tekrarı gündeme gelir, işgücü kaybına neden olunur.

2) Özellikle, coğrafik olarak birden çok alana yayılmış kuruluşlar için geliştirilecek bilgi sistemlerinde gerek merkez gerekse bağlı birimlerde çalışacak yazılımın aynı yazılım olarak tasarlanıp geliştirilmesi uygulama ve bakım kolaylığı açısından önerilmektedir. Genellikle bu tür uygulamalarda, merkezdeki yazılım, birimlerdeki yazılımlara oranla daha farklı unsurlar içermekte, ancak birimlerdeki uygulamaları da kapsamaktadır. Bu durumda, neden merkezdeki yazılımın işlevlerini, kullanılmayacaklarını bile bile birimlere de taşıyalım sorusu akla gelebilir. Zira bu durum kaynak kullanımı açısından birimlere ek yük getirmektedir. Bu durumda bakım ve kurulum kolaylığı ve fazla kaynak kullanımı arasında bir tercih yapmak gerekmektedir. Günümüzde, bilgisayar kaynaklarının giderek ucuzladığı düşünüldüğünde bu tercihin, bakım ve kurulum kolaylığı yönünde yapılması önerilmektedir.

3) Genellikle kurumsal BT projelerinde veri iletişiminin tüm türlerine (Çevrim-içi anında, çevrim-içi kargo, çevrim dışı) rastlanmaktadır. Bu durumda, Veri İletişim alt sistemlerinin bu özellikleri içerecek biçimde tasarlanması gerekmektedir. Özellikle çevrim içi ve anında iletişim gerektiren durumlarda, işlemlerin izlenmesi ve herhangi bir aksaklık durumunda geri alınması gibi işlevlerin tasarımda içerilmesi gerekmektedir.

4) Dönüştürme işlemleri, yazılım gereksinim tanımlarında oldukça az ve yetersiz biçimde tanımlanmakta ve bu durum yüklenici ile iş sahibi arasında sorunlara yol açmaktadır. Geçmiş uygulamalarda, bilgisayar ortamında saklanan bilgilerin yeni uygulama ortamında oluşturulacak veri tabanına aktarılmasında ortaya çıkan temel sorun, geçmiş verilerdeki tutarsızlıklardır. Bir taraftan bu tür tutarsızlıkların yeni sistemde bulunmaması öngörülürken, öte yandan tutarsızlık içeren geçmiş verilerin aktarılması istenir. Bu durum tasarımda içerilmemişse büyük zorluklarla karşılaşılır. Örneğin, nüfus uygulamasındaki kişilerin evlilikleri ile ilgili bağ alanlarının dolu olması bir zorunluluk olarak öngörüldüğünü varsayalım. Öte yandan, bilgisayar ortamındaki mevcut verilere bakıldığında bir çok bağ alanının boş olduğu görüldüğünde mevcut verilerin aktarımında zorluklar çıkar. Veri tabanındaki kısıtlar kaldırılıp veriler olduğu gibi aktarılsa bile, bu verilere ilişkin ileride ortaya çıkabilecek işlemlerde yine sorunlar oluşabilir. Bu tür durumların, yazılım gereksinim tanımlarında ayrıntılı olarak tanımlanması, tasarım sırasında dikkatlice ele alınmalarını sağlar.

Sorular

1) Yazılım tasarım sürecinin temel işlemlerini sayınız. E-R diyagramı çizerek ilişkilerini gösteriniz.

2) Geliştireceğiniz bir uygulama için ekran şablonunuzu belirleyiniz.

3) Bağlaşım ve yapışıklık kavramlarını açıklayınız. Program bakımı ile ilişkilerini belirtiniz.

4) Bir sistem tümüyle bağlaşımsız biçimde tasarlanabilir mi? Yani sistemin tüm modülleri arasında hiç bağlaşım olmadan tasarım yapılabilir mi?

5) Tümüyle işlevsel yapışık modüllerden oluşan bir sistem tasarlanabilir mi? Neden yapılabilir? Neden yapılamaz?

6) Bağlaşım ile Yazılım Taşınabilriliği arasındaki ilişkiyi belirtiniz.

7) Aşağıdaki program kesiminde oluşabilecek bağlaşım türlerini belirtiniz.

procedure Coupled (var A,B,C,D,E,F,G:integer; Ch1,Ch2:char); begin case Ch1 of ‘a’: write(Newfile, ‘ilk harf’); ‘b’: readln(Oldfile,’Ch2); ‘c’: C:=Convert (D,E); {Convert bir kullanıcı tanımlı fonksiyondur } ‘d’:GlobalVar := A + B; ‘e’: D := ord(Ch2); (Ord bir sistem fonksiyonudur) } end {case}; end {procedure Coupled};

8) Aşağıdaki program modüllerinin yapışıklık düzeylerini belirtiniz:

ANA-EKRAN-GORUNTULE : Bir uygulama yazılımının ana ekranını görüntüleyen modül.

FORM-YAZ: Veriyi çeşitli kaynaklardan alıp, önceden belirlenmiş bir biçimde listeleyen bir hazır sistem modülü

KISI-BILGISI-AL: Kişi sicil no bilgisini anahtar olarak kullanıp, kişilerin değişik bilgilerini içeren KISI tablosundan ana bilgileri, ve aynı anahtarı kulanarak KISI-AILE tablosundan aile bilgilerine erişerek ekranda görüntüleyen ve yazıcı çıktısına olanak sağlayan modül.

9) Tasarım gözden geçirmenin önemi nedir? Yapılmaması ne tür sonuçlara yol açar?

10) Arşiv alt sistemi ile yedekleme alt sistemi arasındaki benzerlikleri ve farklılıkları belirtiniz.

11) XYZ seyahat şirketi şehirler arası yolcu taşımacılığı yapmaktadır. 1970’li yıllarda 5 otıbüs ile başlayan firmanın bugün 120 otobüsü bulunmakta ve ülkenin 22 şehrinde şubeleri bulunmaktadır. Firma bütün işlemlerini elle yürütmekte, bilişim teknolojilerini kulanmak istemektedir. Firma ve şubelerinde yapılan işlemler:

1. Bilet satışı,
2. Rezervasyon,
3. Rezervasyon iptali,
4. Seyahat planlama,
5. Günlük ve aylık satış raporlarının düzenlenmesi,

biçiminde özetlenmektedir. Firma ve şubelerinde kullanılmak üzere oluşturulacak XYZ bilgi sistemini web-tabanlı olarak tasarlayınız.

12) Tasarım ile sınama arasındaki ilişkiyi belirtiniz.

13) Geliştirdiğiniz bir uygulama tasarımı için

1. Bir birim sınama belirtimi
2. İki sistem sınama belirtimi (senaryo) hazırlayınız.

Değerlendirme Soruları

 Bölüm 6: Gerçekleştirim

6.1. Giriş

Gerçekleştirim çalışması, tasarım sonucu üretilen süreç ve veri tabanının fiziksel yapısını içeren fiziksel modelin bilgisayar ortamında çalışan yazılım biçimine dönüştürülmesi çalışmalarını içerir. Yazılımın geliştirilmesi için her şeyden önce belirli bir yazılım geliştirme ortamının seçilmesi gerekmektedir.

Söz konusu ortam, kullanılacak programlama dili ve yazılım geliştirme araçlarını içerir. Söz konusu ortamda belirli bir standartta geliştirilen programlar, gözden geçirilir, sınanır ve uygulamaya hazır hale getirilir. Üretilen kaynak kodların belirlenecek bir standartta üretilmesi yazılımın daha sonraki aşamalardaki bakımı açısından çok önemlidir. Tersi durumda kaynak kodların okunabilirliği, düzeltilebilirliği zorlaşır ve yazılımın işletimi süresince ortaya çıkabilecek sorunlar kolayca çözülemez. Şekil 6.1'de genel hatlarıyla gerçekleştirim süreci gösterilmektedir.

Şekil 6.1: Gerçekleştirim Çalışması

 6.2. Yazılım Geliştirme Ortamları

Yazılım geliştirme ortamı, tasarım sonunda üretilen fiziksel modelin, bilgisayar ortamında çalıştırılabilmesi için gerekli olan:

• Programlama Dili
• Veri Tabanı Yönetim Sistemi
• Hazır Program Kitapçıkları
• CASE araçları

bileşenlerinden oluşur. Günümüzde söz konusu bileşenler oldukça farklılık ve çeşitlilik göstermekte ve teknolojinin değişimine uygun olarak gelişmektedir. Bu bileşenler aşağıda açıklanmaktadır.

6.2.1. Programlama Dilleri

Yoğun matematiksel ve mantık işlemi gerektiren uygulamalarda, (NASA, uçak mühendisliği vb) program kütüphanelerinin zenginliği nedeniyle halen en yaygın olarak kullanılan programlama dilleri arasında, FORTRAN yer almaktadır. Yeni geliştirilen, bu tür uygulamalarda ağırlıklı olarak C programlama dili kullanılmaktadır.

Teknolojik gelişim, bu tür uygulamaları hızlandırmak amacıyla paralel işlem yapmayı olanaklı kılmış, bu bağlamda Paralel Programlama dilleri gelişmiştir. Ayrıca mevcut programlama dillerinin paralel sürümleri geliştirilmiştir (Paralel FORTRAN, Paralel C vb). Bu alanda kullanılan programlama dillerinin bir başka özelliği ise, yüksek duyarlıkta işlem yapmayı olanaklı kılmalarıdır.

Süreç ağırlıklı uygulamalar, bir başka deyişle “gerçek zamanlı” uygulamalarda, veri işleme ve matematiksel işlem yapma boyutlarının yanı sıra süreçler arası eşgüdüm, donanımın yazılım aracıyla sürülmesi boyutları önem kazanmaktadır. Bazı işletim sistemi yazılımları, uçak kontrol sistemleri, bankacılık sistemleri bu tür yazılımlara örnek olarak verilebilir. Bu tür uygulamalarda genellikle düşük düzey programlama dilleri (assembly dili) ve özel programlama dilleri ve henüz yaygınlaşmamış olmakla birlikte C programlama dili kullanılmaktadır.

Sistem programlamaya yönelik uygulamalar, bilgisayarın yönetimine ilişkin uygulamalardır (İşletim sistemi vb). Bu tür yazılımlarda kullanılan programlama dili kapalı sistemler için assembly programlama dili, açık sistemler için ise, assembly dili ile birlikte C programlama dilidir.

Yapay us uygulamaları, kural-çıkarım ilkelerine dayalı uygulamalardır. Kuralların tanımlanması, bu kurallardan çıkarımlar yapılması ve çıkarımlardan yeni kurallar tanımlanması biçiminde etkileşimli olarak çalışmayı gerektiren uygulamalardır. Bu tür uygulamalarda en yaygın olarak kullanılan programlama dilleri ise Lisp ve Prolog’dur.

 6.2.2. Veri Tabanı Yönetim Sistemleri

Birbiri ile ilişkili veriler topluluğu veri tabanı olarak tanımlanmaktadır. Veri tabanı herhangi bir boyutta ya da karmaşıklıkta olabilir. Kişisel telefon rehberinizdeki adres bilgileri bir veri tabanı örneği oluşturduğu gibi, maliye bakanlığı bünyesinde saklanan ve vergi ödemesi gereken tüm kişilerin bilgilerinin saklandığı uygulama da bir başka veri tabanı örneğidir. Veri tabanını oluşturan veriler birbiriyle ilişkili verilerdir. Bir veritabanında veriler arası ilişkiler ile veri değerleri bulunur.

Kullanıcıların veritabanındaki verileri soruşturmasını, veritabanına yeni veriler eklemesini, varolan verilerde değişiklik yapmasını sağlayan yazılım Veri Tabanı Yönetim Sistemi (VTYS) olarak tanımlanır. VTYS, genel amaçlı bir yazılımdır.

Bütün VTYS yazılımları (Oracle, Informix, Sybase vb), kullanıcıya, veri tabanı yapısı tanımlama, veri tabanını sorgulama, değiştirme ve raporlama olanakları verirler. Bu durum Şekil 6.2’de yalın olarak belirtilmektedir.

Şekil 6.2 - Veri Tabanı Sistemleri

6.2.2.1. Veritabanı Yaklaşımını Geleneksel Kütük Kavramından Ayıran Özellikler

Uygulama yazılımında kullanılan tüm veri tanımlarının yapısal ve ayrık bir biçimde saklanmasını sağlayan bir katalog bilgisi veya veri sözlüğünün varlığı.

Veri tabanı yaklaşımının bir temel karakteristiği kullanıcıdan verinin saklanması konusundaki detayları gizleyerek veri soyutlamasını sağlamasıdır. Bu soyutlamayı sağlayan ana araç veri modelidir. Veri modeli şu şekilde tanımlanabilir. Bir veri modeli bir veritabanının yapısını açıklamakta kullanılan kavramlar setidir. Bir veri tabanının yapısı ile veri tipleri, ilişkiler ve sınırlamalar kastedilmektedir. Pek çok veri modeli ayrıca veritabanı üzerinde belirtilen getiri (çağrı) ve güncellemeler için temel işlemler setini içerir. Davranışı belirlemek üzere veri modelinin içine kavramları da eklemek mümkündür. Bu da, temel işlemlere ek olarak kullanıcı tarafından tanımlanmış işlemlerin de veri modeline eklenmesiyle mümkündür. Bir veri modelindeki genel işlemlere örnek olarak Ekle, Sil, Değiştir, Eriş verilebilir.

Geleneksel dosya işleme yönteminde, veri dosyalarının yapısı bu dosyalara erişim programları içine gömülmüştür. Bundan dolayı da dosyanın yapısındaki herhangi bir değişiklik bu dosyaya erişen tüm programlarda değişiklik yapılmasını gerektirir. Tersine VTYS erişim programları veri dosyalarından bağımsız olarak tasarlanmışlardır. VTYS de saklanan Veri dosyalarının yapısı erişim programlarından ayrı olarak katalogda tutulduğundan program ve veri bağımsızlığı sağlanır.

Örneğin bir veri dosyasına yeni bir alan eklenmek istendiğinde, bu veri dosyasını kullanan tüm programlara bu alanın eklenmesi gerekir. VTYS yaklaşımında ise sadece katalogdaki veritabanı tanımlarına bu alan eklenerek bu sorun çözülebilir.

Nesne-kökenli veritabanları ve programlama dillerindeki son gelişmeler kullanıcının veri üzerindeki işlemleri veritabanıtanımının bir parçası olarak tanımlamasına olanak tanımaktadır.

Bir işlev iki kısma ayrılır. Bir işlevin arayüzü, işlemin adını ve parametrelerinin veri tiplerini içerir. İşlevin metodu ise ayrıca belirlenen bir kısımdır ve arayüzü etkilemeden değiştirilebilir. Kullanıcı uygulama programları, işlemlerin nasıl uygulandığından bağımsız olarak, işlemlerin isimlerini ve argümanlarını kullanarak, işlemler aracılığıyla veri üstünde çalışabilirler. Bu durum, program-işlem bağımsızlığı olarak adlandırılabilir.

Program-veri bağımsızlığı ve program-işlem bağımsızlığını sağlayan özelliğe veri ayırma denir. Bir VTYS kullanıcılara verinin kavramsal temsilini sağlar. Burada verinin nasıl saklandığına ilişkin fazla ayrıntı bulunmaz. Bir veri modeli bu kavramsal temsili sağlamak için kullanılan bir veri ayırma yöntemidir. Veri modeli, nesneler, özellikleri, birbirleriyle ilişkileri gibi çoğu kullanıcının bilgisayar depolama kavramlarından daha kolaylıkla anlayabileceği mantıksal kavramları kullanır. Böylece veri modeli çoğu veritabanı kullanıcıları için ilgi çekici olmayan depolama ayrıntılarını saklamış olur. Veri-tabanı yaklaşımında her dosyanın ayrıntılı yapısı ve yapılanması katalogda depolanır. Veritabanı kullanıcıları dosyaların kavramsal temsiline başvururlar ve VTYS yazılımı tarafından dosya depolanmasının ayrıntıları gerektikçe bunlar yine VTYS tarafından katalogdan çıkartılırlar. Bu veri ayırma işlemini sağlamak için bir çok veri modelleri kullanılabilir.

Son yıllarda nesne-yönelimli veritabanlarına olan ilginin artmasıyla ayırma işlemi, yalnızca veri yapısı değil veri üstünde yapılan işlemleri de içerecek şekilde bir adım ileri götürülmüştür.

Bir veritabanının birçok kullanıcısı vardır ve bunların herbiri veritabanının farklı bir görüntüsüne gereksinim duyabilir. Bir görüntü veritabanının alt kümesi olabilir veya veritabanından elde edilmiş fakat kesin olarak saklanmamış sanal veri içerebilir. Bazı kullanıcılar, kullandıkları verilerinin veritabanından türetilmiş veriler mi? Yoksa veritabanında gerçekte saklanan veriler mi olup olmadığı ile ilgilenmezler. Kullanıcıları farklı uygulamalara sahip çok kullanıcılı bir VTYS çoklu görüntü tanımlama olanaklarını sağlamalıdır.

Çok kullanıcılı VTYS yazılımlarının temel rolü eş zamanlı işlemlerin karışıklık olmadan doğru bir şekilde yapılmasına olanak tanımak işlemlerin doğru olarak yapılmasını garanti etmektir. Bu özellik veri tabanı (VT) kavramını, dosya işleme kavramından ayıran en önemli özelliktir. Bu kontrol aynı anda birden çok kullanıcının aynı veriyi güncellemeye çalışmasını, güncellemenin doğru olması açısından garanti eder.

6.2.2.2. VTYS Kullanımının Ek Yararları

VTYS kullanımının ek yararları ise;

• Genişleme potansiyeli
• Esneklik
• Uygulama geliştirme zamanının azalması
• Güncel bilgilerin tüm kullanıcılara aynı zamanda ulaşması
• Ölçümde ekonomi.
• İşletme ortamındaki ortak verilerin tekrarının önlenmesi verilerin merkezi denetiminin ve tutarlılığının sağlanması
• Fiziksel yapı ve erişim yöntemi karmaşıklıklarının Her kullanıcıya yanlız ilgilendiği verilerin kolay anlaşılır yapılarda sunulması
• Uygulama yazılımı geliştirmenin kolaylaşması
• Uygulamaların fiziksel ve kavramsal düzeydeki değişikliklerden etkilenmemesi

şeklinde özetlenebilir. Günümüzde VTYS yazılımları oldukça gelişmiş, görsel programlama platformları ve Web tabanlı geliştirme platformları ile bütünleşik çalışma olanakları sağlanmıştır. Artık, geleneksel kütük düzenleme ve erişim yöntemlerinin doğrudan programlanarak bilgi sistemi uygulaması geliştirilmemektedir. VTYS yazılımları, kişisel bilgisayar düzeyine indirgenmiştir.

6.2.2.3. Veri Modelleri

Veri modelleri, veri tabanının yapısını anlatmak için sağladıkları kavram tipine göre sınıflandırılırlar. Yüksek-düzey ya da kavramsal veri modelleri kavramları kullanıcının veriyi gördüğü ya da anladığı şekline yakın bir biçimde sağlarlar.

Fiziksel veri modelleri ise verinin bilgisayarda nasıl saklandığının detayları ile ilgili kavramları sağlarlar. Bu ikisinin arasında ise gösterimsel veri modelleri vardır ki bunlar, hem kullanıcı tarafından anlaşılan hem de verinin bilgisayar içerisindeki gösteriminden çok da fazla uzak olmayan kavramları sağlarlar.

Yüksek düzey veri modelleri varlık, özelik ve ilişki gibi kavramları kullanır. Varlık veri tabanında saklanan ve gerçek dünyadan bir nesne veya kavramdır; proje, işçi gibi. Özelik, varlığı anlatan bir özelliği gösterir işçinin adı, ücreti gibi. Bir veya daha fazla varlık arasındaki ilişki ise bir işçi ve proje arasındaki çalışma ilişkisidir.

Gösterimsel veri modelleri, ticari veri tabanlarında sıklıkla kullanılır ve belli başlı veri üç modeli içerir. İlişkisel, ağ ve hiyerarşik veri modeli. Nesne yönelimli veri modelleri daha yüksek seviyeli gerçekleştirim veri modelleridir ve kavram veri modeline daha yıkındır.

Fiziksel veri modelleri bilgiyi kayıt biçemi, sırası ve erişim yollarıyla göstererek verinin bilgisayar ortamında nasıl saklandığını açıklar. Burada erişim yolu, belirli bir veritabanı kaydını etkin bir şekilde aramayı sağlayan yapıdır.

6.2.2.4. Şemalar

Herhangi bir veri modelinde veri tabanının tanımlanması ile kendisini ayırmak önemlidir. Veri tabanının tanımlamaları veri tabanı şeması veya meta-veri olarak adlandırılır. Veri tabanı şeması, tasarım sırasında belirtilir ve sıkça değişmesi beklenmez. Pek çok veri modeli şemaları, diyagramlar halinde göstermek için belli gösterim biçimlerine sahiptir. Diyagramlar her kayıt tipinin yapısını gösterir fakat kaydın gerçek örneğini göstermez.

Bir veri tabanındaki gerçek veri sıkça değişebilir. Herhangi bir zamanda veritabanındaki veri, veritabanı durumu olarak tanımlanır. Belirli bir veri tabanı, durumunda her şema veri tabanının o andaki örneklerine sahiptir. Herhangi bir veriyi değiştirdiğimizde veya eklediğimizde veritabanı bir durumdan diğerine geçiş yapar.

Veritabanı şeması ile veritabanı durumu arasındaki fark çok önemlidir. Yeni bir veritabanı tanımladığımızda sadece onun şemasını VTYS’ne tanımlarız. O andaki veri tabanı durumu boş durumdur yani verisizdir. Veriyi ilk girdiğimiz andaki durum ise başlangıç durumudur.

6.2.2.5. VTYS Mimarisi

Bu mimarinin amacı kullanıcı uygulamaları ile fiziksel veritabanını birbirinden ayırmaktır. Bu mimaride şemalar 3 seviyede tanımlanabilir. Bu nedenle üç şema mimarisi olarak ta anılır.

1. İçsel Düzey: veritabanının fiziksel saklanma yapısını açıklar. Fiziksel veri modeli kullanır ve veritabanına erişim yolu ile veri saklamanın tüm detaylarını açıklar.
   
   
2. Kavramsal Düzey: Kavramsal şema içerir ve kullanıcılar için veritabanının yapısını açıklar. Gerçek fiziksel yapının detaylarını kullanıcıdan gizler, veri tipleri, varlıklar ilişkiler, kullanıcı işlemleri ve sınırlamalar üzerine konsantre olmamızı sağlar. Daha yüksek seviyede veri modeli veya gerçekleştirim veri modeli bu seviyede kullanılabilir.
   
   
3. Dışsal Düzey: Bu düzey, dış şemalar veya kullanıcı görüşleri içerir. Her dış şema veritabanının bir bölümünü açıklar ve her gruba kendi ilgilendiği görüşü sunarken, diğer bir gruptan ilgilenmediği görüşü saklar. Daha yüksek düzeyde veri modeli veya gerçekleştirim veri modeli bu seviyede kullanılabilir.

Pek çok VTYS bu üç düzeyi tam olarak birbirinden ayırmaz. Burada bu 3 şemasında verinin tanımlayıcı olduğuna dikkat etmek gerekir, sadece fiziksel düzeyde gerçek veri bulunur. Üç şema mimarisine dayalı VTYS’lerde her kullanıcı kendi dış şemasıyla ilgilidir. Bundan dolayı VTYS, dış şemasında belirlenmiş bir isteği kavramsal şemaya dönüştürmek ve daha sonrada iç şemaya dönüştürmek gereklidir. İstek ve sonuçları düzeyler arasındaki dönüştürme işlemine eşleme denir.

6.2.2.6. Veritabanı Dilleri ve Arabirimleri

Veritabanının tasarımı tamamlandıktan sonra bir VTYS seçilir. Seçilen VTYS’de bulunan dil olanakları Tablo 6.1’de verilmiştir.

Günümüzde bu diller birbirlerinden bağımsız olarak kullanılmamaktadır. Bunun yerine daha geniş, ayrıntılı ve tüm bu fonksiyonları yerine getiren tümleşik bir dil kullanılmaktadır. Bunun tipik bir örneği olarak daha sonraki bölümlerde de anlatacağımız SQL verilebilir.

Veri Tanımlama Dili (VTD)
Saklama Tanımlama Dili (STD)	İçsel şemayı tanımlamak için kullanılır.
Görüş Tanımlama Dili (GTD)	Görüş tanımlama dili kullanıcı görüşlerini tanımlamak ve kavramsal şemaya dönüştürmek amacıyla kullanılır.
Veri İşleme Dili (VİD)	Veri işleme dilidir. Veri tabanı oluşturulduktan sonra Veri tabanına veri eklemek, değiştirmek, silmek veya eklenmiş veriyi getirmek amacıyla kullanılır.

Tablo 6.1 VTYS dilleri

İki tip VİD vardır;. yüksek düzeyli ve düşük düzeyli. Yüksek düzeyli VİD, bir bilgisayar terminalinden etkileşimli olarak kullanılabildiği gibi bir programlama dili içerisine de yerleştirilebilir. Düşük düzeyli VİD’de ise VİD bir programlama dili içerisine gömülü olarak çalışır.

VTYS Arabirimleri olarak Menü-Tabanlı, grafiksel, form tabanlı ve doğal dil arabirimleri kullanılmaktadır. Menü tabanlı arabirimlerde kullanıcıya çeşitli seçenekler sunulurken, grafiksel arabirimde kullanıcıya veritabanı şeması diyagramı halinde sunulur. Kullanıcı bu diyagram yardımıyla sorgu belirtebilir. Form tabanlı arabirimler ise kullanıcıya doldurulmak üzere bir form sunarlar. Doğal dil arabirimleri İngilizce yazılan sorguları kabul eder ve anlamaya çalışırlar.

6.2.2.7. Veri Tabanı Sistem Ortamı

VTYS, karmaşık bir yazılım sistemidir. Bu bölümde bir VTYS’yi oluşturan yazılım bileşenlerden söz edilmektedir. Tipik bir VTYS yazılımı bileşenleri, VTYS Kataloğu, veri tabanı derleyicisi (VTD), veri yöneticisi, VİD derleyicisi, VT işlemcisi ve yardımcı yazılımlar biçimindedir.

Veri tabanı ve VTYS kataloğu genellikle disk üzerinde saklanır. Diske erişim öncelikle işletim sistemi tarafından kontrol edilse de Yüksek-Düzeyde saklanmış veri yöneticisi modülü disk üzerinde bulunan VTYS bilgilerine erişimi denetler. VTD derleyicisi şema tanımlarını işler ve şema belirtimlerini (meta-veri) VTYS kataloğunda saklar. Katalog dosya adı, veri adedi, her dosya için saklama detayları, şemalar arasındaki mapping bilgileri ve sınırlamaları gibi bilgiler içerir. VTYS yazılım modülleri bu bilgilere gereksinim duyduğunda kataloğa erişmek durumundadır.

İşletim ortamındaki Veri tabanı işlemcisi, işletim sırasında veri tabanına erişimi yönetir. Erişim veya güncelleme işlemlerini alır ve VT üzerinde gerçekleştirir.

Diske erişim, veri yöneticisi tarafından gerçekleştirilir. Sorgu derleyicisi etkileşimli olarak girilmiş yüksek düzeyli sorguları gerçekleştirir. Sorgu derlenmesi şu şekilde gerçekleştirilir. Her sorgu öncelikle çözülür ve analiz edilir ve işletim zamanı işlemcisinin bu isteği gerçekleştirmesi için çağrı yapılır.

Ön derleme VİD komutlarını bir programlama dilinde yazılmış uygulama programından alır. Daha sonra bu komutlar VİD derleyicisine kaynak kodun oluşturulması amacıyla gönderilir.

Yükleme, Yedekleme, performans ölçme, sıralama, veri sıkıştırma, ve benzeri fonksiyonları yerine getirmek amacıyla veri tabanı yardımcı yazılımları bulunur.

VTYS’leri, bulundukları siteden uzakta olan VT kullanıcılarının, uçlar aracılığıyla VT’nına erişebilmesine olanak tanımak amacıyla iletişim yazılımlarına gereksinim duyarlar. İstemci-Sunucu yapısı da VTYS ile birlikte sıklıkla kullanılır. Bu yapıda, uygulama fiziksel olarak bir sunucu makinede çalışır. Veri depolama ve erişim ise başka bir sunucu bilgisayar tarafından yönetilir.

6.2.2.8. VTYS'nin Sınıflandırılması

Bir VTYS’ni sınıflandırmada kullanılan temel kriter VTYS’nin dayandığı veri modelidir. En fazla kullanılan veri modelleri ilişkisel, ağ, hiyerarşik, nesne-yönelimli ve kavramsal modellerdir.

Buna göre VTYS’leri, ilişkisel, ağ, sıradüzensel, ve nesne-yönelimli olarak sınıflandırılırlar. İlişkisel modelde veritabanı bir tablolar yığınından oluşmuştur. Her bir tablo farklı bir dosya olarak saklanabilir. Ağ modeli, veriyi kayıt ve küme tipleri olarak gösterir. Sıradüzensel veri modelinde, veri ağaç yapısında gösterilir. Nesne-yönelimli model ise veri tabanını nesneler, özellikleri ve işlemleri biçiminde gösterir. Buna göre aynı yapı ve davranıştaki nesneler aynı sınıfa aittir ve sınıflar da bir sıradüzen içerisinde düzenlenirler. Her sınıfa ilişkin işlemler ise ‘yöntemler’ biçiminde tanımlanmıştır.

İlişkisel VTYS’leri, veri modellerini genişleterek nesne-yönelimli kavramları da veri modellerine dahil etmektedirler. Bunlar genişletilmiş ilişkisel sistemler ya da nesne-ilişkisel sistemler olarak adlandırılmaktadır.

Bir VTYS’ni sınıflandırmadaki diğer bir kriter sistem tarafından desteklenen kullanıcı sayısıdır. Bu sistemler tek-kullanıcılı veya çok-kullanıcılı olarak sınıflandırılırlar. VTYS’leri sınıflamada kullanılan diğer bir kriter, veritabanının kaç site’ye (yere) dağıtıldığıdır.

Pek çok VTYS merkezidir yani bir bölgedeki tek bir bilgisayara depolanmıştır. Böyle bir sistem aynı anda çok-kullanıcılı olabilir fakat VT’nın kendisi ve VTYS aynı bilgisayar üzerinde depolanmıştır. Dağıtık bir VTYS (DVTYS) aynı anda bilgisayar ağları aracılığıyla birbirine bağlı pek çok bölgedeki pek çok bilgisayara depolanmış olabilir. VTYS’leri sınıflandırmadaki bir başka kriter ise maliyettir.

6.2.3. Hazır Program Kitaplıkları

Hemen hemen tüm programlama platformlarının kendilerine özgü hazır program kitaplıkları bulunmaktadır. Söz konusu kitaplıklar, hemen hemen tüm uygulamalarda kullanılabilecek ortak program parçaları (OCX,VBX vb), sistem yönetimine ilişkin yazılımları içerir. Söz konusu yazılımlar program geliştirme hızını oldukça arttırmaktadır. Günümüzde bu tür kitaplıkların edinilmesi, internet sayesinde oldukça kolaylaşmıştır.

6.2.4. CASE Araç ve Ortamları

Günümüzde bilgisayar destekli yazılım geliştirme ortamları (CASE) oldukça gelişmiş durumdadır. CASE araçları, yazılım üretiminin hemen her aşamasında (planlama-çözümleme-tasarım-gerçekleştirim-sınama) üretilen bilgi ya da belgelerin bilgisayar ortamında saklanmasını, bu yolla kolay erişilebilir ve yönetilebilir olmasını olanaklı kılar. Hemen tüm CASE araçları, belirli bir standarda uygun olarak geliştirme yapmayı zorlar. Bu yolla yapılan üretimin yüksek kalitede olması sağlanır. ­CASE araç ve ortamları Bölüm 12’de ayrıntılı olarak incelenmiştir.

 6.3. Kodlama Stili

Hangi platformda geliştirilirse geliştirilsin, yazılımın belirli bir düzende kodlanması yazılım yaşam döngüsünün uygulama boyutu açısından oldukça önem taşımaktadır. Yazılım ya da bilgi sistemleri, doğaları gereği durağan değildir. Uygulamanın gerektirdiği güncel değişikliklerin ilgili yazılıma da aktarılması gerekir. Bu nedenle yazılımın kodlarına zaman zaman başvurmak, yeni kod parçaları eklemek ya da var olan kodlarda değişiklikler yapmak yazılım yaşam döngüsünün işletimsel boyutunun en önemli işlevlerinden biridir. “Bakım Programcısı” kavramı bu tür gereksinimlerden doğmuştur. Bakım programcısının temel görevleri, varolan yazılıma ilişkin kodlar dahil üretilmiş tüm bilgi ve belgeleri incelemek ve yazılım üzerinde değişiklikler yapmak biçiminde özetlenebilir. Kolay okunabilir, anlaşılabilir kodları olmayan yazılımın bakımı oldukça zorlaşır ve büyük maliyetlere ulaşır.

Yazılım Kod stili konusunda herhangi bir kabul edilmiş standart bulunmamaktadır. Bu konuda, yazılım geliştiren ekiplerin, kodlama aşamasına başlamadan Kodların düzeni konusundaki standartlarını ya da kurallarını geliştirmeleri ve bu kuralların uygulamaya geçmesini sağlamaları önerilmektedir.

Kodlama stili açısından her bir program modülü (alt program, işlev, ekran kodları vb) için en az düzeyde kullanılması gereken etkin kod yazım stili bileşenleri aşağıda verilmektedir.

• Açıklama satırları
• Kod yazım düzeni
• Anlamlı İsimlendirme
• Yapısal Programlama Yapıları

6.3.1. Açıklama Satırları

Bir program parçasını anlaşılabilir kılan en önemli unsurlardan biri bu program kesiminde içerilen açıklama satırlarıdır. Her bir program modülü içerisine

1. Modül başlangıç açıklamaları
2. Modül Kod Açıklamaları
3. Boşluk satırları

eklenmelidir.

Her bir modülün temel işlevleri, yazan kişi vb bilgiler ilgili modülün en başına modül başlangıç açıklama satırları olarak eklenmelidir. Şekil 6.3’de C programlama dili için kullanılabilecek bir modül başlangıç açıklama satırında bulunması gerekenler şablon biçiminde verilmektedir.

/*******************************************************
* © *
*******************************************************
* Modül Adı :
* Kütük Adı :
* İşlevi :
* Desteklenen Platformlar :
* Desteklenen Derleyiciler :
* Taşınabilirlik Konuları :
* Kullanılan işlevler :
* Hatalar
* Bilinen Düzeltilmemiş Yanlışlar :
* Programcı :
* Tarihçe Günlüğü
* İsim Tarih Açıklama *
* *
*******************************************************

Şekil 6.3 ‘.c’ ve ‘.h’ kütükleri için modül başlangıç açıklama satırı şablonu

Bir programın karmaşıklığını arttıran en önemli bileşenler, program içerisinde kullanılan denetim yapılarıdır (Koşullu deyimler, döngü deyimleri). Bu tür deyimlerin hemen öncesinde bu denetim işleminin açıklamasını ve bu deyimde olabilecek olağan dışı durumları içeren kod açıklama satırları koyulmalıdır.

Program kodu içerisine, kodların görünebilirliğin ve anlaşılabilirliğini arttırmak amacıyla yeterli oranda boşluk satırı, koyulmalıdır. Boşluk satırları programın etkinliğine (bellek kullanımı, performans vb) hiçbir olumsuz etki yapmaz. Bu nedenle gerek kod satırları arasına uygun olarak, gerekse bir satırın kendi içerisinde yeterli boşluk bırakılması önerilmektedir.

6.3.2. Kod Biçimlemesi

DO I=1 TO N-1;T=I; DO J=I TO I+1;IF A(J)< A(T) THEN DO T=J;
END;
IF T<>I THEN DO H=A(T);A(T)=A(I); A(I)=T;END;END;

(a)Kötü stilde kodlanmış program parçası

DO I = 1 TO N-1;
T=I;
DO J = 1 TO I+1;
IF A(J) < A(T) THEN DO
T=J;
END;
IF T <> I THEN DO
H = A(T);
A(T) = A(I);
A(I) = H;
END;
END;
(b)İyi stilde kodlanmış program parçası

Şekil 6.4 Kötü ve iyi stilde kodlanmış program kesimleri

Ancak Program kodlama düzeni ise gerçekleştirim aşamasında çözümlenir. Programların okunabilirliğini arttırmak, anlaşılabilirliğini kolaylaştırmak amacıyla açıklama satırları kullanımının yanı sıra belirli bir kod yazım düzeni kullanılması gerekmektedir. Şekil 6.4’te belirli bir düzende kodlanmamış ve kodlanmış pragram parçalarından örnekler verilmektedir.

Kodlarınızın yazım düzenini oluştururken aklınızda bulundurmanız gereken en önemli düşünce “Acaba ben başkası tarafından yazılmış olan bir programı okumak ve anlamak isteseydim, kodların yazım düzeni nasıl olmalıydı?” olmalıdır.

6.3.3. Anlamlı İsimlendirme

Kodların okunabilirliğini ve anlaşılabilirliğini sağlayan önemli unsurlardan biri de kullanılan ve kullanıcı tarafından belirlenen belirteçlerin (Değişken adları, kütük adları, Veri tabanı tablo adları, işlev adları, yordam adları vb) anlamlı olarak isimlendirilmesidir.

İsimlendirme yöntemi uygulamayı geliştirenler tarafından çözümleme-tasarım aşamalarında belirlenmeli ve gerçekleştirim aşamasında uygulanmalıdır. Kod incelenirken en azından ilk bakışta

• Hangi değişkenlerin hangi veri tabanı tablosuna ilişkin oldukları,
  
• Hangi değişkenlerin klavye ve ekran aracılığı ile değer aldıkları
  
• Hangi değişkenlerin yazıcı çıktılarında görülmek üzere kullanıldıkları,
  
• Hangi değişkenlerin yalnızca ilgili kod içerisinde ara değişkenler olarak kullanıldıkları,

türündeki bilgiler yalnızca değişken adına bakılarak anlaşılabilmelidir.

6.3.4. Yapısal Programlama Yapıları

Program kodlarının, okunabilirlik, anlaşılabilirlik, bakım kolaylığı gibi kalite etmenlerinin sağlanması ve perogram karmaşıklığının azaltılması amacıyla “yapısal programlama yapıları” kullanılarak yazılması önemlidir. Yapısal Programlama Yapıları, temelde, içinde “go to” deyimi bulunmayan, “tek giriş ve tek çıkışlı” öbeklerden oluşan yapılardır. Teorik olarak herhangi bir bilgisayar programının, yalnızca Yapısal Programlama Yapıları kullanılarak yazılabileceği kanıtlanmıştır.

• Üç temel Yapısal Programlama Yapısı bulunmaktadır:
• Ardışıl işlemler, herhangi bir koşula bağlı olmaksızın birbiri ardına uyglanması gereken işlemler olarak tanımlanır. Hemen her tür programlama dilinde bulunan, aritmetik işlem deyimleri, okuma/ yazma deyimleri bu tür yapılara örnek olarak verilebilir.
• Üç tür Koşullu işlem yapısı bulunmaktadır: tek koşullu işlem yapısı (if-then), iki koşullu işlem yapısı (if-then-else) ve çok koşullu işlem yapısı (case-when). 70’li yılların ortalarından sonra gelen programlama dillerinin hemen hepsinde, bu yapılar doğrudan desteklenmektedir.
• Döngü yapıları, belirli bir koşula bağlı olarak ya da belirli sayıda, bir ya da daha çok kez yinelenecek işlemler için kullanılan yapılardır. Temelde üç tür döngü yapısı bulunmaktadır:

1. Belirli sayıda yinelenecek işlemler için kullanılan yapılar (for yapısı) ,
2. Bir koşula bağlı olarak, sıfır ya da birden çok kez yinelenecek işlemler için kullanılan yapılar (while-end yapısı),
3. Bir koşula bağlı olarak, bir ya da daha çok kez yinelenecek işlemler için kullanılan yapılar (repeat-until yapısı).

Bu yapıların her biri “tek girişli ve tek çıkışlı” yapılardır. Programlar, yalnızca bu yapılar kullanılarak kodlandığında ve uygun açıklama satırları ile desteklendiğinde, program bakımı kolaylaşmakta ve geliştirme hızlanmaktadır.

 6.4. Program Karmaşıklığı

Program karmaşıklığını ölçmek için bir çok teorik model geliştirilmiştir. Bu modellerin en eskisi ve yol göstericisi McCabe karmaşıklık ölçütüdür. Bu bölümde bu ölçüt anlatılmaktadır. Söz konusu ölçüt 1976 yılında McCabe tarafından geliştirilmiştir. Bu konuda geliştirilen diğer ölçütlerin çoğu, bu ölçütten esinlenmiştir.

McCabe ölçütü, bir programda kullanılan “koşul” deyimlerinin program karmaşıklığını etkileyen en önemli unsur olduğu esasına dayanır ve iki aşamada uygulanır.

• Programın çizge biçimine dönüştürülmesi
• Mc Cabe Karmaşıklık Ölçütünün hesaplanması

6.4.1. Programın Çizge Biçimine Dönüştürülmesi

Bir program bir ana program ve onunla ilgili birden fazla alt programdan oluşur. Gerek ana program gerekse alt programların tümü, McCabe Karmaşıklık ölçütünün hesaplanmasından önce çizge biçimine dönüştürülmelidir. Bir program parçasının çizge biçimine dönüştürülmesi için gerekli kurallar aşağıda açıklanmaktadır.

Açıklamaları görmek için butonlara tıklayınız.

• Sıradan İşlemler:
• Koşullu İşlemler:
• Döngü İşlemleri:

---

Sıradan işlemler: Bir sıradan işlem ya da birden fazla ardışık sıradan işlem Çizgede bir düğüme dönüştürülür.

Programın çizge biçiminde, Mc Cabe ölçütü açısından, çizgedeki düğümleri bitiştiren çizgilerin yönleri yani oklar önem taşımaz. Burada oklar, döngü işlemlerindeki denetimlerin yapıldıkları yerleri belirginleştirmek amacıyla kullanılmıştır.

6.4.2. McCabe Karmaşıklık Ölçütü Hesaplama

Ana program ve alt programlar çizge biçimie dönüştürüldükten sonra programın McCabe karmaşıklık ölçütü (V(G))

V(G) = k - d + 2p

biçiminde hesaplanır. Bu formülde :

k : Çizgedeki kenar çizgi sayısı
d : Çizgedeki düğüm sayısı
p : Programdaki bileşen sayısı.

anlamında kullanılmıştır. p sayısı ana program ve ilgili alt programların sayısını göstermektedir. Hiçbir alt program kullanılmadığı durumda p sayısı 1 olarak alınmaktadır. Örneğin bir ana program ve üç alt programın kullanıldığı bir programda p sayısı 4’tür.

6.4.3. McCabe Ölçütü

McCabe ölçütü, bugün yazılım endüstrisinde birçok uygulamada kullanılmaktadır. Herhangi bir program bileşeni (ana program ya da alt program) için V(G) ölçütü, yalnızca o bileşen için uygulandığında elde edilecek değerin 10’dan fazla olmaması önerilmektedir. Bir başka tanımıyla, V(G), bir programdaki kararla ilgili deyimlerin (koşullu deyim, döngü deyimi) bir fazlasına eşit olmaktadır. Dolaysıyla bir program bileşeninde 10’dan fazla karar deyimi kullanılması o programın karmaşıklığının yüksek olduğu anlamına gelmektedir

Şekil 6.5

Şekil 6.5 (a) da bir programın iş akış şeması verilmekte, (b) kısmında ise önceki kesimde verilen kurallar uygulanarak programın çizge biçimine dönüştürülmüş biçimi verilmektedir.

McCabe Karmaşıklığını hesaplamak için kenar ya da dallar ve düğümler sayılıp formülün uygulanması gerekir. Bu örnekte

k = 11 -- Kenar sayısı
d = 9 -- Düğüm sayısı
p = 1 -- Bileşen sayısı
karmaşıklık
V(G) = 11 - 9 + 2 x 1
= 4

olarak hesaplanır.

 6.5. Olağan Dışı Durum Çözümleme

Olağan dışı durum, bir programın çalışmasının, geçersiz ya da yanlış veri oluşumu ya da başka nedenlerle istenmeyen bir biçimde sonlanmasına neden olan durum olarak tanımlanmaktadır. Genelde kabu edilen kurall, bir programın işletiminin sonlandırılması işleminin -elektrik kesintisi vb donanım hataları dışında- bütünüyle program denetiminde olmasıdır. Bu kural olağan dışı sonlandırma işlemini de kapsamaktadır. Bu nedenle program kodları oluşturulurken, olağandışı durumların da dikkate alınması ve bu durumlardaki program davranışına ilişkin yöntemler geliştirilmesi gerekmektedir. Örneğin, normalde sıfır değeri almaması gereken bir değişken sıfır değerini aldığında program, bu değişkene ilişkin bir bölme işleminde “sıfıra bölme hatası” nedeniyle işletim sistemi tarafından kesilmemeli, bu tür bir yanlış uyarısı vererek durmalıdır. Günümüzdeki programlama dilleri, bu tür olağan dışı durumlarda programın yapması gereken işlevi kapsayacak “olağan dışı durum çözümleyicileri ya da yordamları” tanımlarını içermektedir. Örneğin ADA Programlama dilinde, olağan dışı durumlar ilgili program öbeği içerisinde tanımlanabilmektedir (Bkz. Şekil 6.6).

begin
. . . .
. . . .
. . . . Program kod satırları
. . . .
. . . .
. . . .
exception
when CONSTRAINT_ERROR => SINIR_HATASI; . .
when TABLO_DOLU => . . .
end;

Şekil 6.6 Ada Dili Olağandışı Durum Çözümleme Yapısı

Yukarıdaki örnekte “begin ………end;” arasında kalan program satırları arasında bir CONSTRAINT_ERROR (sınır olağan dışı durumu, bir dizinin dizin değeri dizinin eleman sayısından daha fazla bir değer aldığında, ya da sınırları önceden belirlenmiş bir alanın sınırları dışında olan bir değer ataması yapılması vb) olağan dışı durumu oluştuğunda program denetimi “SINIR_HATASI” adlı yordama sapmaktadır. Söz konusu yordamın içeriğinin, programcı tarafından oluşturulmuş olması gerekmektedir.

6.5.1. Olağandışı Durum Tanımları

Olağan dışı durumlar, programlama dili tarafından tanımlı durumlar olduğu gibi kullanıcı tarafından da tanımlanabilmektedir. Yukarıdaki örnekte, CONSTRAINT_ERROR adlı olağan dışı durum ADA Programlama dili tarafından tanımlanmış, TABLO_DOLU adlı olağan dışı durum ise programcı tarafından tanımlanmıştır. Bu tür olağan dışı durumlar, olağan dışı durumu tanımlayan ve sonucunda “doğru” ya da “yanlış” değeri üreten biri mantıksal yordam ya da fonksiyon tanımından oluşmaktadır. Şekil 6.7‘de ADA Programlama dili platformunda kendiliğinden tanımlı olağandışı durum örnekleri verilmektedir.

CONSTRAINT_ERROR : dizin taşması, alan sınır değerlerinin aşılması
NUMERIC_ERROR : sayısal hesaplamalarda taşma durumu
PROGRAM_ERROR : “select” deyiminde hiçbir seçeneğin seçilmemiş olması ve “else” kısmının bulunmaması
STORAGE_ERROR : Bellekte yeterli yer bulunamaması

TASKING_ERROR : Eşzamanlı yordamların çalışması sırasında

Şekil 6.7 ADA Diline İlişkin Bazı Olağan Dışı Durum Örnekleri

Programcı tarafından tanımlanabilecek olağandışı durumlara örnek olarak, özellikle günümüzde görsel programlama platformlarında geliştirilen yazılımlarda ekranlardan girilecek verilerin doğrulama ve geçerleme durumları, fare’nin hareketlerinin denetimi, işlev tuşlarının kullanımının denetimi vb durumlar gösterilebilir.

6.5.2. Farklı Olağandışı Durum Çözümleme Yaklaşımları

Herhangi bir olağandışı durumda, program tarafından değişik işlemler yapılabilir, değişik önlemler alınabilir. Bu konudaki yaklaşımlar, aşağıda belirtilmiştir.

Anında Durdurma: Hata bulunduğunda program açıklayıcı bir ileti vererek sona erer. Bu iletinin yanı sıra onaltılı sistemde bir döküm de verir. MS Office paketlerinde alınan “This Program Performed an illegal operation” iletisi ve ardından programın durması, bu tür olağandışı durum çözümleme yaklaşımına örnek olarak verilebilir. Bu yaklaşımda, verilen hata iletisinin anlamlı olması ve programcıya düzeltebilmek amacıyla yol gösterici olması önemlidir.

Hata Kodu Verme: İlgili program modülünden başarısız şekilde çıkıldığında, programın bir hata kodu vermesi biçminde bir yaklaşımdır. Söz konusu kod “başarılı” ya da “başarısız” durumu belirten mantıksal bir kod olabileceği gibi, bazı uygulamalarda sayısal ya da metin biçiminde olabilir. Bu yaklaşımda, ilgili programında hata oluştuğu anlaşılabilmekte ancak hatanın hangi deyimde oluştuğu anlaşılamamaktadır.

Tanımlı Olağandışı yordam Çalıştırma: Programlama dili platformunun tanımladığı olağan dışı durum çözümleme olanaklarını kullanmak biçimindedir. COBOL Programlama dilindeki “ON READ ERROR” deyimi gibi.

Hata Yordamı Çalıştırma: Olmayacak Değer Döndürme: Yordamın beklenmeyen bir değer geri döndürmesi gibi bir yaklaşımdır. Örneğin yaş hesaplaması yapıp, yaş bilgisini geri döndüren bir programın eksi değer döndürmesi gibi.

 6.6. Kod Gözden Geçirme

Hiç kimse, önceki sürümlerini gözden geçirmeden ve incelemeden okunabilir bir program yazamaz. Hiçbir yazı editörün onayını almadan basılamayacağı gibi hiçbir program da incelenmeden, gözden geçirilmeden işletime alınmamalıdır. Kod gözden geçirme ile program sınama işlemlerini birbirinden ayırmak gerekir.

Program sınama, programın işletimi sırasında ortaya çıkabilecek yanlış ya da hataları yakalamak amacıyla yapılır. Kod gözden geçirme işlemi ise, programın kaynak kodu üzerinde yapılan bir incelemedir. Kod gözden geçirmelerinde program hatalarının %3-5 oranındaki kesimi yakalanabilmektedir. Eğer programı yazan kişi, yazdığı programın hemen sonra bir “kod inceleme” sürecine girdi olacağını bilerek program yazdığında daha etkin, az hatalı ve okunabilir programlar elde edilebilmektedir.

6.6.1. Gözden Geçirme Sürecinin Düzenlenmesi

Gözden geçirme sürecinin temel özellikleri

-Hataların bulunması, ancak düzeltilmemesi hedeflenir,

-Olabildiğince küçük bir grup tarafından yapılmalıdır. En iyi durum deneyimli bir inceleyici kullanılmasıdır. Birden fazla kişi gerektiğinde, bu kişilerin, ileride program bakımı yapacak ekipten seçilmesinde yarar vardır.

-Kalite çalışmalarının bir parçası olarak ele alınmalı ve sonuçlar düzenli ve belirlenen bir biçimde saklanmalıdır.
biçiminde özetlenebilir. Burada yanıtı aranan temel soru, programın yazıldığı gibi çalışıp çalışmayacağının belirlenmesidir. Gözden Geçirme çalışmasının olası çıktıları

• Programı olduğu gibi kabul etmek,
• Programı bazı değişiklerle kabul etmek,
• Programı, önerilen değişikliklerin yapılmasından sonra tekrar gözden geçirmek üzere geri çevirmek.

Gözden geçirme çalışması sonucu, önerileri içeren bir rapor biçiminde sunulur. Üst yönetim sonuç ile ilgili olarak bilgilendirilir.

6.6.2. Gözden Geçirme Sırasında Kullanılacak Sorular

1. Her öbek tek bir işlevsel amacı yerine getiriyor mu?
2. Öbek adı, işlevini açıklayacak biçimde anlamlı olarak verilmiş mi?
3. Öbek tek giriş ve tek çıkışlı mı?
4. Öbek eğer bir işlev ise, parametrelerinin değerini değiştiriyor mu?

1. Öbek, doru biçimde giriş açıklama satırları içeriyor mu?
2. Giriş açıklama satırları, öbeğin amacını açıklıyor mu?
3. Giriş açıklama satırları, parametreleri, küresel değişkenleri içeren girdileri ve kütükleri tanıtıyor mu?
4. Giriş açıklama satırları, çıktıları (parametre, kütük vb) ve hata iletilerini tanımlıyor mu?
5. Giriş açıklama satırları, öbeğin algoritma tanımını içeriyor mu?
6. Giriş açıklama satırları, öbekte yapılan değişikliklere ilişkin tanımlamaları içeriyor mu?
7. Giriş açıklama satırları, öbekteki olağan dışı durumları tanımlıyor mu?
8. Giriş açıklama satırları, Öbeği yazan kişi ve yazıldığı tarih ile ilgili bilgileri içeriyor mu?
9. Her paragrafı açıklayan kısa açıklamalar var mı?

1. İşlevsel olarak ilintili bulunan veri elemanları uygun bir mantıksal veri yapısı içinde gruplanmış mı?
2. Değişken adları,işlevlerini yansıtacak biçimde anlamlı mı?
3. Değişkenlerin kullanımları arasındaki uzaklık anlamlı mı?
4. Her değişken tek bir amaçla mı kullanılıyor?
5. Dizin değişkenleri kullanıldıkları dizinin sınırları içerisinde mi tanımlanmış?
6. Tanımlanan her gösterge değişkeni için bellek ataması yapılmış mı?

1. Öbekte yalnızca yapısal programlama yapıları kullanılmış mı?
2. Öbek, algoritmanın her adımını içeren paragraflara ayrımış mı?
3. Koşullu deyimlerde bütün olası durumlar içerilmiş mi?
4. Döngü deyimlerinde bitirme koşulları açık ve algoritma ile uyumlu mu?
5. Her döngü bitiyor mu?
6. Bitmeme olasılığı görünen döngü var mı?
7. Öbekteki uygulanabilir deyim sayısı mantıklı mı?

1. Her satır, en fazla bir deyim içeriyor mu?
2. Bir deyimin birden fazla satıra taşması durumunda, bölünme anlaşılabilirliği kolaylaştıracak biçimde anlamlı mı?
3. Koşullu deyimlerde kullanılan mantıksal işlemler yalın mı?
4. Bütün deyimlerde, karmaşıklığı azaltacak şekilde parantezler kullanılmış mı?
5. Bütün deyimler, belirlenen program stiline uygun olarak yazılmış mı?
6. Öbek yapısı içerisinde akıllı “programlama hileleri” kullanılmış mı?

Bölüm Özeti

• Bakım Programcısı kavramı uygulamada çalışmamakta, genellikle yazılımı geliştiren, bakımını da yapmakta ve, usta-çırak ilişkisi içinde işler devredilmeye çalışılmaktadır. Bu durum, zaten kısıtlı olan bilişim insan gücü kaynağının verimsiz olarak kullanılmasına neden olmakta ve “kişiye bağlı” yazılımlar geliştirilmektedir.
  
  
• Özellikle C programlama dili için programlama stili çok önemlidir. Sözdizim tanımları gereği C programları, okunmaları ve anlaşılmaları kolay olmayan programlardır. Bu nedenle, kodlamaya başlanılmadan önce, bu konuya ilişkin kullanacağınız standartları oluşturulmalı ve kodlama sırasında bu standartlara uyulup uyulmadığını denetlemeniz gerekmektedir.
  
  
• Açıklama satırları ile ilgili kod uyumlu olmalı. Kod satırları arasında, süreç içerisinde yapılan değişiklikler, yeni eklentiler açıklama satırlarına yansıtılmamakta, bu durum, programların okunabilirliğini giderek zorlaştırmaktadır.
  
  
• Süreç içinde anlamlı isimlendirmeler kaybolabilmektedir. Program bakımı, belli bir sistematik içerisinde yapılmamakta ve izlenmemektedir. Programların, süreç içerisinde, “yamalı bohça” ya dönüşmesi söz konusudur. Bir sistematik ve izleme olmadığında, bakım giderek zorlaşmaktadır.
  
  
• Gözden Geçirme çalışmasının yapılması amacıyla yönetimi ikna etmek zor. Bu tür bir örgütlenmeye sıcak bakılmamakta, öte yandan, programcılar da benzer tepkiyi vermekte ve “sanki kendilerini denetliyorlarmış” mantığı ile davranmaktalar. Oysa, Gözden geçirme çalışması yapılmadığında, özellikle büyük yazılım projelerinin geliştirilmesi olanaksız.

Sorular

1) Kendi yazılım geliştirme ortamınızı açıklayınız.

2) Veri tabanı ile veri tabanı yönetim sistemi arasındaki farkı belirtiniz.

3) Veri tabanı Yönetim Sistemi kullanarak, uygulama geliştirme zamanının hasıl kısalacağını açıklayınız.

4) Veri tabanı Yönetim Sistemi kullanımının yararlarını ve aksak yönlerini belirtiniz?

5) Kullandığınız bir veri tabanı yönetim sistemini inceleyiniz. VTD, STD, GİD, GTD dillerinin özelliklerini araştırınız.

6) Kendi kullanımınız için kodlama stili geliştiriniz.

7) Kodlama stilleri ile programlama dilleri arasındaki ilişkiyi belirtiniz.

8) Bildiğiniz bir programlama dilinin, yapısal programlama yapılarından hangilerini doğrudan desteklediğini, hangilerini desteklemediğini araştırınız. Desteklenmeyen yapıların, bu programlama dilinde nasıl gerçekleştirilebileceğini belirtiniz.

9) Verilen bir N doğal sayısının asal olup olmadığını belirleyen bir programı dört değişik biçimde yazınız. Programlar arasındaki zaman farklılıklarını ölçünüz.

10) Program geliştirirken kullandığınız olağan dışı durum çözümleme yöntemlerini açıklayınız?

11) Geliştirdiğiniz bir program için, bölüm içerisinde verilen gözden geçirme sorularını yanıtlayınız. Programınızın niteliği hakkında ne söyleyebilirsiniz?

Değerlendirme Soruları

 Bölüm 7: Yazılım Doğrulama ve Geçerleme

7.1. Giriş

Geliştirilecek bilgi sistemi yazılımının Doğrulanması ve Geçerlenmesi üretim süreci boyunca süren etkinliklerden oluşur. Söz konusu etkinlikler:

1. Yazılım belirtimlerinin ve proje yaşam sürecindeki her bir etkinlik sonunda alınan çıktıların, tamam, doğru, açık, ve önceki belirtimleri tutarlı olarak betimler durumda olduğunun doğrulanması.
2. Proje süresince her bir etkinl,ik ürününün teknik yeterliliğinin değerlendirilmesi ve uygun çözüm elde edilene kadar aktivitenin tekrarına sebep olması.
3. Projenin bir aşaması süresince geliştirilen anahtar belirtimlerin önceki belirtimlerle karşılaştırılması.
4. Yazılım ürünlerinin tüm uygulanabilir gerekleri sağladığının gerçeklenmesi için sınamaların hazırlanıp yürütülmesi.

biçiminde özetlenebilir. “Doğrulama” ve “Geçerleme“ arasındaki temel fark:

Doğrulama: Doğru ürünü mü üretiyoruz?
Geçerleme: Ürünü doğru olarak mı üretiyoruz?

sorularının yanıtları ile açıklanabilir. Kolayca da anlaşılabileceği gibi “Doğrulama”, ürünü kullanacak kişilerin isteklerinin karşılanıp karşılanmadığı, “Geçerleme” ise ürünün içsel niteliğine ilişkin izleme ve denetim etkinliklerinden oluşur.

Doğrulama ve Geçerleme işlemleri temel olarak çeşitli düzeylerde sınama, gözden geçirme, denetim ve hata giderme süreçlerinden oluşur.

İzleyen kesimlerde, sınama işlemleri ayrıntılı olarak açıklanmaktadır.

7.2. Sınama Kavramları

Sınama ve bütünleştirme işlemlerinin bir strateji içinde gerçekleştirilmesi, planlanması ve tekniklerin seçimi gerekmektedir. Bütünleştirme işleminde en küçük birimlerden başlanarak sistem düzeyine çıkılmaktadır. Bu değişik düzeylere hitap edecek sınama yöntemleri olmalıdır. Şekil 8.1'de uygulandığı hedef açısından sınama yöntemleri gruplandırılması gösterilmektedir. Buradaki sınama işlemleri:

Birim sınama: Bağlı oldukları diğer sistem unsurlarından bütünüyle soyutlanmış olarak birimlerin, doğru çalışmalarının belirlenmesi amacıyla yapılır. Birimler, ilişkili yapıtaşlarının bütünleştirilmesinden oluşurlar.

Alt-sistem sınama: Alt sistemler ise modüllerin bütünleşmesi ile ortaya çıkar. Yine bağımsız olarak sınamaları yapılmalıdır. Bu düzeyde en çok hata arayüzlerde bulunmaktadır, arayüz hatalarına yönelik sınamalara yoğunlaşılmalıdır.

Sistem sınaması: Üst düzeyde bileşenlerin sistem ile olan etkileşimlerinde çıkacak hatalar aranmaktadır. Ayrıca belirtilen ihtiyaçların doğru yorumlandıkları da sınanmalıdır.

Kabul sınaması: Çalıştırılmadan önce sistemin son sınamasıdır. Artık yapay veri yerine gerçek veriler kullanılır. Bu sınama türü alfa sınaması ve beta sınaması olarak ta bilinir. Alfa sınamada, tanımında, sınamanın geliştirici organizasyonun yerleşkesinde, kullanıcıların da gelerek katkıda bulunması içerilir. Daha sonra ürünün pazarlama işlemi sırasında beta sınama denilen, sınama, kullanıcının kendi yerleşkesinde, geliştirici gözetiminde yapılır.

Şekil 7.1 Sınama İşlemleri

Daha önce de tanımlanmadan değinilen ve Şekil 7.1in belirtilen evrimsel bütünleştirme, her ekleme adımından sonra sınama fikrini ortaya çıkarır. Ancak bu sınamalar yalnızca ekleme yerelinde yapılacak kolay sınamalar olamaz. bütünleştirmenin getirdiği zincirleme etkiler söz konusudur ve daha önce yapılan bir çok sınamanın yinelenmesi de gündeme gelir. Özellikle modüller arası bağımlılığın fazla olduğu durumlarda bu yinelemeli sınamaların ortaya daha fazla hata çıkaracağı beklenir.

Sınamalar, hatalardan kurtulmanın bir güvencesi değildir. Hatalardan bütünüyle arınıldığı gibi bir kanı edinilmemelidir. Yalnızca, sınamalar uzadıkça hata bulma sıklığı azalır, daha zor bulunacak hatalar gizli kalmağa devam eder. Ne kadar hata sıklığına erişildiğinde sınama işleminin durdurulacağı, maliyet ve kalite arasında bir en iyileme yapma gereğini öne çıkarır. Aynı zamanda vakit de önemli bir unsurdur. Daha uzunca süreler vakitler harcanarak daha az hatalar bulunmaya devam eder. Yazılımın kritiklik düzeyine göre, sınamaya ayrılan süre ve çaba artar.

7.3. Doğrulama ve Geçerleme Yaşam Döngüsü

Doğrulama ve geçerleme işlemleri yazılım üretim yaşam döngüsünün tüm süreçlerinde ve bu süreçlere koşut olarak sürer (bkz Şekil 8.2). Gerçekleştirim aşamasına kadar olan süreçlerde doğrulama ve geçerleme işlemlerinin planlaması yapılır. Planlama, genel olarak, birim, alt sistem, bütünleştirme, sistem ve kabul sınamalarının tasarımlarını içerir. Gerçekleştirim aşamasının sonunda ise söz konusu planlar uygulanır.

Şekil 7.2 Doğrulama ve Geçerleme Yaşam Döngüsü

Uygulama sonucu elde edilen bulgular, Yazılım Doğrulama ve Geçerleme raporları biçiminde sürekli olarak raporlanır. Bu bilgiler, değişiklik denetim sistemi ve sorun yönetim sistemlerinde girdi olarak kullanılır. Değişiklik Denetim sistemi, sınama süresince elde edilen bulguların izlenmesi amacıyla oluşturulan bir sistemdir. Bu sistemde, sınama sonucu elde edilen bulgular ve bunlara karşı sorun yönetimi tarafından alınan önlemler izlenir.

 7.4. Sınama Yöntemleri

Sınama işlemi, geliştirmeyi izleyen bir düzeltme görevi olmak ile sınırlı değildir. Bir “sonra” operasyonu olmaktan çok, geliştirme öncesinde planlanan ve tasarımı yapılması gereken bir çaba türüdür. Her mühendislik ürünü, iki yoldan biri ile sınanır: Sistemin tümüne yönelik işlevlerin doğru yürütüldüğünün (kara kutu – black box) veya iç işlemlerin belirtimlere uygun olarak yürütüldüğünün bileşenler tabanında sınanması (beyaz kutu – white box).

7.4.1. Beyaz Kutu Sınaması

Beyaz kutu sınaması tasarlanırken, birimin süreç belirtiminden yararlanılır. Yapılabilecek denetimler arasında:

1. Bütün bağımsız yolların en azından bir kere sınanması
2. Bütün mantıksal karar noktalarında iki değişik karar için sınamaların yapılması
3. Bütün döngülerin sınır değerlerinde sınanması
4. İç veri yapılarının denenmesi

bulunur.

Sınamaları yürütürken sınırlı çabamızı yerinde kullanmamız gerekir. Bunun için hataların bazı özelliklerinin bilinmesinde yarar vardır:

• Bir program kesiminin uygulamada çalıştırılma olasılığı az ise o kesimde hata olması ve bu hatanın önemli olması olasılığı fazladır.
  
  
• Çoğu zaman, kullanılma olasılığı çok az olarak kestirilen program yolları, aslında çok sıkça çalıştırılıyor olacaktır.
  
  
• Yazım hataları rasgele olarak dağılır. Bunlardan bazılarını derleyiciler bulur, bazıları da bulunmadan kalır.

7.4.2. Temel Yollar Sınaması

Şekil 7.3 Bir program iş akış şeması

Daha önce çevrimsellik karmaşıklığı konusunda gördüğümüz hesap yöntemi ile bir programdaki bağımsız yollar bulunduktan sonra. bu kadar sayıda sınama yaparak programın her birimini bir şekilde sınamalara dahil etmiş oluruz. Bağımsız yolların saptanması için önce program, çizgesel bir biçime çevrilir. Bunu yapmak için ise program iş akış şemaları diyagramları iyi bir başlangıç noktasıdır. Şekil 7.3 de bir program akış diyagramı ve Şekil 7.4’te ise buna karşı düşen çizgesel diyagram görüntülenmektedir.

Program akış diyagramları matematiksel titizlik ile tanımlanmayan daha serbestçe program yapılarını alt düzeyde modelleyen çizimlerdir. Akış diyagramları ise Çizge Teorisi dalında kabul görecek şekilde bir "Çizge"dır. Her çizgede olduğu gibi burada da düğümler ve dallar (veya kirişler) bulunur. Program akış diyagramından akış diyagramına geçmek için süreç kutuları ortadan kaldırılır, koşul baklavaları yerine düğümler çizilir ve her koşul düğümüne karşı düşecek birleştirme düğümleri eklenir. Birleştirme düğümleri, koşul kollarının kapandığı noktaya konur. Artık bu çizge üzerinden temel yol sayısını da verecek olan çevrimsellik karmaşıklığı sayısını hesaplayabiliriz:

E - N + 2

Burada E, toplam dal sayısı, N ise toplam düğüm sayısına karşı düşmektedir. Bağımsız temel yol sayısı kadar temel yolları çizge üzerinde (sonunda programa yansıtılmak üzere) veya program üzerinde işaretlenir. Sonra bu yolların hepsinin koşturulacağı sınama programları tasarlanır.

Şekil 7.4 Program Grafik Diyagramı

Şekil 7.4’teki deki çizgede bu formüle göre bağımsız yol sayısı:

11 - 9 + 2 = 4

Bunun anlamı da şöyle açıklanabilir: Çizgedeki her dal sınama işleminde kapsanmalıdır. Bu, sınama sırasında her işlemin çalıştırılması demektir. Her dalın en az bir kere kapsanacağı ve en az sayıda yollar bulunmalıdır. Programa ortadan giremeyeceğimize göre de bu yollar başlangıç noktasından bitiş noktasına kadar uzanmalıdır. Son olarak ta minimum sayıda yol ile bu şartları sağlamalıyız. Bu sayının 4 olduğu, daha önce yukarıdaki formülde hesaplanmıştı.

 7.5. Sınama ve Bütünleştirme Stratejileri

Genellikle sınama stratejisi, bütünleştirme stratejisi ile birlikte değerlendirilir. Ancak bazı sınama stratejileri bütünleştirme dışındaki tasaları hedefleyebilir. Örneğin yukarıdan aşağı ve aşağıdan yukarı stratejileri bütünleştirme yöntemine bağımlıdır. Ancak işlem yolu ve gerilim sınamaları, sistemin olaylar karşısında değişik işlem sıralandırmaları sonucunda ulaşacağı sonuçların doğruluğunu ve normal şartların üstünde zorlandığında dayanıklılık sınırını ortaya çıkarır.

 7.5.1. Yukarıdan Aşağı Sınama ve Bütünleştirme

Yukarıdan aşağı bütünleştirmede önce sistemin en üst düzeylerinin sınanması ve sonra aşağıya doğru olan düzeyleri, ilgili modüllerin takılarak sınanmaları söz konusudur. En üst noktadaki bileşen, bir birim/modül/alt sistem olarak sınandıktan sonra alt düzeye geçilmelidir. Ancak bu en üstteki bileşenin tam olarak sınanması için alttaki bileşenlerle olan bağlantılarının da çalışması gerekir. Alt bileşenler ise bu stratejiye göre henüz hazırlanmış olamazlar. Bunların yerine üst bileşenin sınaması için kullanılmak üzere 'koçan' programları yazılır. Koçanlar, bir alt bileşenin, üst bileşen ile arayüzünü temin eden, fakat işlevsel olarak hiç bir şey yapmayan, boş çerçeve programlarıdır. Üst bileşenin sınanması bittikten sonra bu koçanlar, içleri doldurularak kendi kodlama ve birim sınama işlemlerini tamamladıktan sonra üst bileşen ile yeniden sınanırlar.

Örnek: A, B, C birimlerinden oluşan ve birim şeması şekil 7.5 (a)’da belirtilen bir sistemin bu tür koçan kullanılarak sınanması şekil 7.5 (b) ve şekil 7.5 (c)’de belirtilmektedir.

Şekil 7.5 Bütünleştirme sınamasında “koçan” kullanımı

İlk adımda A ve B birimleri bütünleştirilir, C için bir “koçan” yazılır. İkinci adımda ise “koçan“ kaldırılır ve C ile yer değiştirilerek A-B-C bütünleştirilir.

Yukarıdan aşağıya doğru bütünleştirme işleminde iki yaklaşım izlenebilir.

7.5.1.1. Yaklaşım -1- Düzey Öncelikli Bütünleştirme

En üst düzeyden başlanır, öncelikle aynı düzeylerdeki birimler bütünleştirilir. Bu yaklaşım kullanılarak şekil 7.6 de belirtilen sistemin bütünleştirme adımlarındaki sıralama:

1 adım: B1-B2 ( KoçanB3 - KoçanB4– KoçanB5 - KoçanB6)
2. Adım: B1-B2 – B3 (KoçanB4– KoçanB5 - KoçanB6)
3. Adım:B1-B2-B3-B4 ( KoçanB7 - KoçanB8– KoçanB5 - KoçanB6)
4. Adım: B1-B2-B3-B4-B5 ( KoçanB7 - KoçanB8– KoçanB6 )
5. Adım: B1-B2-B3-B4-B5-B6 ( KoçanB7 - KoçanB8 )
6. Adım: B1-B2-B3-B4-B5 –B6-B7 ( KoçanB8 )
7. Adım: B1-B2-B3-B4-B5 –B6-B7 –B8 biçimindedir.

Şekil –7.6 Yukarıdan aşağıya bütünleştirme için kullanılan sistem örneği

7.5.1.2. Yaklaşım -2- Derinlik Öncelikli Bütünleştirme

En üst düzeyden başlanır. Birim şemasında bulunan her dal soldan sağa olma üzere ele alınır. Bir dala ilişkin bütünleştirme bitirildiğinde diğer dalın bütünleştirmesi başlar. Bu yaklaşım kullanılarak şekil 7.6’da belirtilen sistemin bütünleştirme adımlarındaki sıralama:

1 adım: B1-B2 ( KoçanB3 - KoçanB4– KoçanB5 - KoçanB6)
2. Adım: B1-B2 – B5 (KoçanB3– KoçanB4 - KoçanB6)
3. Adım:B1-B2-B5-B6 (KoçanB3 - KoçanB4)
4. Adım: B1-B2-B5-B6-B3 (KoçanB4 )
5. Adım: B1-B2-B5-B6-B3-B4 ( KoçanB7 - KoçanB8 )
6. Adım: B1-B2-B5-B6-B3-B4-B7 (KoçanB8 )
7. Adım: B1-B2-B5-B6-B3-B4-B7-B8

Şekil –7.6 Yukarıdan aşağıya bütünleştirme için kullanılan sistem örneği

7.5.2. Aşağıdan Yukarıya Sınama ve Bütünleştirme

Aşağıdan yukarı bütünleştirmede ise, önceki yöntemin tersine uygulama yapılır. Önce en alt düzeydeki işçi birimleri sınanır ve bir üstteki birimle sınama edilmesi gerektiğinde bu üst bileşen, bir 'sürücü' ile temsil edilir. Yine amaç, çalışmasa bile arayüz oluşturacak ve alt bileşenin sınanmasını sağlayacak bir birim edinmektir. Bu kez kodlama, bütünleştirme ve sınama aşağı düzeylerden yukarı düzeylere doğru gelişir ve yukarı düzeylerde önce sürücü olarak yazılan birimler sonra gerçekleriyle yer değiştirerek o düzeyin birimleri/alt sistemleri olurlar Şekil 7.7, aşağıdan yukarıya sınama sürecini belirtmektedir.

Şekil 7.7 Aşağıdan yukarı bütünleştirme

1. Belirli bir yazılım alt işlevini gören alt düzey birimler kümeler biçiminde oluşturulurar,
2. Denetim amaçlı bir sürücü programı sınama işlemi için girdi ve çıktı oluşturmak amacıyla yazılır,
3. Sürücüler aşağıdan yukarı kaldırılır ve gerçek birim ya da birim kümeleriyle değiştirilerek sınama işlemi sürdürülür.

Bütünleştirme yukarı doğru yapıldıkça daha az sürücü gereği duyulur.

Uygulamada Hem aşağıdan yukarıya hem de yukarıdan aşağıya sınama stratejilerinin iki stratejinin birleştirildiği de olur. 'Sandöviç' adı verilen bu karma yaklaşımda hem üstten hem alttan sınama etkinliği sürer.

7.6. Sınama Planlaması

Sınama işlemi çok kapsamlıdır. Bir plan güdümünde gerçekleştirilmelidir. Böyle bir planın temel bileşenleri yukarıda belirtimiştir: Yazılım yaşam döngüsünün süreçlerine koşut olarak farklı ayrıntı düzeylerinde birden fazla sınama planı hazırlanır (bkz. Şekil 7.8).

Giriş Amaç Tanım ve Kısaltmalar Referanslar

Sınama Yönetimi Sınama Konusu Sınama Etkinlikleri ve Zamanlama Temel Sınama Etkinlikleri Destek Etkinlikler Kaynaklar ve Sorumluluklar Personel ve Eğitim Gereksemeleri Sınama Yaklaşımı Riskler ve Çözümler Onaylar

Sınama Ayrıntıları Sınanacak Sistemler Girdiler ve Çıktılar Sınamaya başlanma koşulları Girdilerin Hazır Olması Ortam Koşulları Kaynak Koşulları Sınama Tamamlama Kıstası Sınama geçme-kalma kıstası Sınama askıya alınma kıstası ve sürdürme gerekleri Sınama Sonuçları.

Şekil 7.8 Sınama Planı Bileşenleri

Sınama planları; Birim (Modül) sınama planı, Alt Sistem Sınama Planları, Bütünleştirme Sınama Planları, Kabul Sınama Planları, Sistem Sınama Planları biçimindedir.

Her Sınama Planı, sınama etkinliklerinin sınırlarını, yaklaşımını, kaynaklarını ve zamanlamasını tanımlar. Plan neyin sınanacağını, neyin sınanmayacağını, sorumlu kişileri ve riskleri göstermektedir. Sınama planları, sınama belirtimlerini içerir.

7.7. Sınama Belirtimleri

Sınama belirtimleri, bir sınama işleminin nasıl yapılacağına ilişkin ayrıntıları içerir. Bu ayrıtılar temel olarak:

• sınanan program modülü ya da modüllerinin adları,
• sınama türü, stratejisi (beyaz kutu, temel yollar vb),
• sınama verileri
• sınama senaryoları

türündeki bilgileri içerir.

Sınama verilerinin elle hazırlanması çoğu zaman kolay olmayabilir ve zaman alıcı olabilir. Bu durumda, otomatik sınama verisi üreten programlardan yararlanılabilir.

Sınama senaryoları, yeni sınama senaryosu üretebilmeye yardımcı olacak biçimde hazırlanmalıdır. Zira sınama belirtimlerinin hazırlanmasındaki temel maç, etkin sınama yapılması için bir rehber oluşturmasıdır. Sınama işlemi sonrasında bu belirtimlere,

1. sınamayı yapan,
2. sınama tarihi
3. bulunan hatalar ve açıklamaları

türündeki bilgiler eklenerek sınama Raporları oluşturulur. Sınama Raporları, sınama bitiminde imzalanır ve yüklenici ile iş sahibi arasında resmi belge niteliği oluşturur.

7.8. Yaşam Döngüsü Boyunca Sınama Etkinlikleri

Sınama etkinlikleri, üretim aşamasının en başından başlayarak planlanır, ayrıntılandırılır ve raporlanır. Şekil 7.9’da’de sınama etkinliklerinin yaşam döngüsü çekirdek adımlarındaki dağılımı gösterilmektedir. Yapılan işe ilişkin bilgi düzeyi arttıkça, sınama planları soyut durumdan somut sınamalara dönüşür.

Planlama aşamasında genel sınama planı oluşturulur. Söz konusu plan tüm sınama etkinliklerini çok genel hatlarıyla tanımlar ve bölüm 7.6’da verilen bilgileri içerir.

Şekil 7.9 Yaşam Döngüsü Boyunca Sınama Etkinlikleri

Çözümleme aşamasında sistemler ve alt sistemler ortaya çıkarılır ve sınama planı alt sistemler bazında ayrıntılandırılır.

Tasarım aşaması, tüm yazılım modüllerinin ortaya çıkarıldığı aşamadır. Bu aşamanın başlangıcında yazılım modülleri için sınama planı detaylandırılır ve sınama belirtimleri hazırlanır. Söz konusu belirtimler, kullanıcı kılavuzları ile birlikte sınamaya ilişkin eğitim için temel bilgileri oluşturur.

Gerçekleştirim aşamasında teknik sınamalar yapılır, sınama raporları hazırlanır ve kullanıcı sınayıcıları eğitilir..

Kurulum aşamasından hemen sonra kullanıcı sınamaları yapılarak sınama raporları hazırlanır.

Hazırlanan sınama raporları, bölüm 7.3’te anlatılan doğrulama ve geçerleme yaşam döngüsü işlemleri gereği “sorun yönetimi” ne iletilir. Bu bölümde hatalar kaydedilir ve bulunan hatalara karşı yapılacak işlemler planlanır.

Sınamalar sırasında bulunan her bulgu ya da hata olarak belirtilen her durum gerçekte hata olmayabilir. Farklı sınayıcılardan biri, bir durumu hata olarak nitelerken diğeri aynı durumu doğru olarak değerlendirebilir. Bu nedenle sınama raporlarında hata olarak bildirilen her durum hemen düzeltilmek üzere ele alınmaz. Önce çözümlenir, kullanıcı çelişkileri giderilir ve gerçekten hata olduğuna karar verilirse düzeltilir. Söz konusu karar kullanıcı temsilcileri ile birlikte alınır.

Sınama sırasında bulunan her hata için, değişiklik kontrol sistemine (DKS), “Yazılım değişiklik isteği” türünde bir kayıt girilir. Hatalar, DKS kayıtlarında aşağıdaki gibi gruplara ayrılabilir:

Onulmaz Hatalar: BT projesinin gidişini bir ya da birden fazla aşama gerileten ya da düzeltilmesi mümkün olmayan hatalardır.
Büyük hatalar: Projenin kritik yolunu etkileyen ve önemli düzeltme gerektiren hatalardır.
Küçük Hatalar: Projeyi engellemeyen, ve giderilmesi az çaba gerektiren hatalardır.
Şekilsel Hatalar: Heceleme hatası gibi önemsiz hatalardır.

Her sınama bitiminde, o sınama için, tüm ilgili DKS kayıtları kullanılarak ayrıntı raporlar alınabileceği gibi, genel hata istatistikleri elde edilebilir.

 7.9. Bir Uygulama: Görsel Yazılım Geliştirme Ortamında Sınama

Bu kesimde, gerçek yaşam ortamında, Oracle Designer CASE aracı ve Developer görsel yazılım geliştirme platformu kullanılarak geliştirilen yazılım modüllerinin sınanması işleminin nasıl yapılacağı ve buraya kadar açıklanan sınama yöntemlerinin nasıl uygulandıkları bir örnek üzerinde anlatılmaktadır.

Oracle Developer kullanılarak geliştirilen her yazılım formlardan oluşur. Bir form, bir ekran ve bu ekranda yapılan işlemlere karşılık gelen PL/SQL kodları biçiminde tanımlanır. Bu örnekte elimizde, sınama işlemine koşulacak ve uygulamanın çeşitli işlevlerine ilişkin bir dizi form olduğunu düşünebiliriz. Bu örnekte söz edilen uygulama, 2000’denfazla kullanıcısı olan, ülkenin çeşitli yörelerine dağılmış birimlerde çalışacak biçimde tasarlanmış ve 1000’den fazla Developer formundan oluşmaktadır. Uygulamanın sınama aşamasına gelmesi, 2 yıllık bir süre ve yaklaşık 100 kişi-yıl’lık bir iş gücü gerektirmiştir. Uygulama beş ana kümeye bölünmüş ve her küme belirli sayıda bilgi sistemini içermektedir. Toplam olarak 30 bilgi sistemi bulunmaktadır. Uygulama sıra düzeni şekil 7.10’da verilmektedir.

Şekil 7.10 Örnek BT Projesi Sıradüzeni

7.9.1. Sınama Ortamı Oluşturulması

Üretimin etkilenmemesi amacıyla, yalnızca sınayıcıların kullanacakları ve ayrı bilgisayarlardan oluşan bir sınama ortamı oluşturuldu. Oluşturulan sınama ortamı ile üretim ortamının bir bir aynı olması sağlandı. Üretimi biten yazılım parçaları, bir kayıt düzeni içerisinde sınama ortamına alındı.

7.9.2. Sınama Yöntemlerine Karar Verilmesi

Üretim ortamında yapılacak sınama olarak karar verildi. Bu sınama, modül sınaması ve bütünleştirme sınaması olarak üretim ekipleri tarafından gerçekleştirildi. Modül sınama yöntemi olarak “beyaz kutu” sınama yöntemi uygulandı. Tüm program deyimleri en az bir kez, tüm döngüler en az 10 kez yinelenecek biçimde sınama yapıldı.

Bütünleştirme sınama yöntemi olarak, “yukarıdan aşağıya sınama yöntemi” ve “derinlik öncelikli bütünleştirme” stratejisi uygulandı.

Üretim ekiplerinden bağımsız olarak, sınama ekipleri tarafından yapılan sınamadır. Bu sınama, Developer formları üzerinde görsel olarak yapıldı. Amaç, formların, önceden kararlaştırılan standartlara uygunluğunun saptanmasıydı. Örneğin, form alanları, kararlaştırılan uzunlukta mı? Başlıklar istenilen gibi koyu mu? Yardım düğmesi hep aynı yerde mi vb.

Sınama, formlar işletilmeden yapılır. Tüm formlar tek tek incelenir ve standartlara uygun olmayanlar belirlenip, düzeltilmek üzere üretim ekibine geri iletilir.

Biçimsel sınamaların yapılması amacıyla denetim listeleri hazırlanır ve sınama sırasında bu listeler kullanılır. Listelere kaydedilen her sonuç DKS’ye aktarılır. Bu yolla üretim ekiplerinin performansı izlenebilir.

Üretim ekiplerinden bağımsız olarak, sınama ekipleri tarafından yapılan sınamadır. Biçimsel sınama işlemi bittikten sonra yapılır. Bu sınamada her form ayrı ayrı çalıştırılarak işlem yapılır. Amaç, formun çalışıp çalışmadığının belirlenmesidir. Form alanlarının sınır değerlerle çalışıp çalışmadığı, aykırı değer verildiğinde uygun hata iletisi alınıp alınmadığı vb belirlenmeye çalışılır.

Sınama ekipleri tarafından yapılan sınamadır. Ancak, senaryoların hazırlanması sırasında üretim ekipleri ile birlikte çalışılır.

Amaç, birden fazla formun bir arada sınanmasıdır. Bu amaçla, “senaryo”lar hazırlanır. Her senaryo, çözümleme aşamasında belirlenen bir iş fonksiyonuna karşılık gelecek biçimde. hazırlanır.

Kullanıcılar tarafından yapılması öngörülen sınamadır. Senaryo sınamasının kullanıcı tarafında yapılan biçimi olarak düşünülebilir.

7.9.3. Kullanıcı Sınama Eğitimi

Sınama yapılacak kullanıcı sınayıcılarına, sınamaların nasıl yapılacağına ilişkin eğitim verilmesi gerekmektedir. Eğitim kitapçıklarının hazırlanması amacıyla, senaryo sınamalarında kullanılan “senaryo” lar ve kullanıcı kitapçıkları kullanılır.

7.9.4. Sınamaların Yapılması

Sınamalar sırasıyla:

Teknik Sınama, Biçimsel Sınama, İşletimsel Sınama, Senaryo Sınaması, Kullanıcı sınama

biçiminde yapılır. Sınamalar sırasında yapılan her işlem, DKS’de izlenir. Özellikle kullanıcı sınamalarının izlenmesi ve ortaya çıkabilecek tartışmaların önlenmesi bu yolla sağlandı.

Yaklaşık 100 kullanıcı sınayıcısının, birbirinden farklı yerlerde yaptıkları sınamalar için “haftalık sınama sonuçları” formları toplandı. Yerinde destek elemanları, sürekli olarak kullanıcı sınayıcılarını ziyaret ederek sınama sonuçlarının düzenli olarak toplanmasını sağladı. Bu formlar DKS’ye aktarılarak, daha sonra Yazılım Doğrulama ve Geçerleme Raporları için önemli girdiler oluşturdu.

Bölüm Özeti

Sınamalar sırasıyla:

Teknik Sınama, Biçimsel Sınama, İşletimsel Sınama, Senaryo Sınaması, Kullanıcı sınama

biçiminde yapılır. Sınamalar sırasında yapılan her işlem, DKS’de izlenir. Özellikle kullanıcı sınamalarının izlenmesi ve ortaya çıkabilecek tartışmaların önlenmesi bu yolla sağlandı.

Yaklaşık 100 kullanıcı sınayıcısının, birbirinden farklı yerlerde yaptıkları sınamalar için “haftalık sınama sonuçları” formları toplandı. Yerinde destek elemanları, sürekli olarak kullanıcı sınayıcılarını ziyaret ederek sınama sonuçlarının düzenli olarak toplanmasını sağladı. Bu formlar DKS’ye aktarılarak, daha sonra Yazılım Doğrulama ve Geçerleme Raporları için önemli girdiler oluşturdu.

Sorular

1) Doğrulama ile Geçerleme arasındaki farklılıkları belirtiniz. Birer örnekle açıklayınız.

2) Sınama Yöntemlerini açıklayınız.

3) “Beyaz Kutu” sınama ile “Temel Yollar Sınama” Yöntemleri arasındaki farlılıkları belirtiniz.

4) Sınama Yöntemleri ile sınama belirtimleri arasındaki farkı belirtiniz.

5) Yukarıdan aşağıya doğru bütünleştirme ve aşağıdan yukarıya bütünleştirme yöntemlerinin zorluklarını ve kolaylıklarını belirtiniz.

6) Sınama belirtimlerinin önemi nedir.

7) Kullanıcı sınaması sırasında yaşanabilecek sorunları belirtiniz.

Değerlendirme Soruları

 Bölüm 8: Bakım

8.1. Giriş

Sınama işlemleri bitirilen yazılımın kullanıcı alanına yüklenmesi ve uygulamanın başlatılması gerekmektedir. Yazılım kullanıma geçtikten sonra, yaşam döngüsünün en önemli ve hiç bitmeyecek aşaması olan “bakım” aşaması başlar. İzleyen kesimlerde, kurulum ve bakım aşamasında yapılması gerekenler açıklanmaktadır. Bakım bölümüne ilişkin yapılan açıklamalarda IEEE 1219-1998 standardı baz olarak alınmıştır.

 8.2. Kurulum

Sınanmış yazılımların kullanıcı sahasına aktarılması ve yazılımın gerçek yaşamda uygulamasının başlatılması için yapılan işlemler kurulum işlemleri olarak tanımlanmaktadır. Kurulum işlemleri

• Donanım kurulumu,
• Sistem yazılımları kurulumu,
• Veri tabanı kurulumu,
• Uygulama yazılımları kurulumu,
• Eğitim ve
• Yerinde destek

biçiminde sınıflandırılabilir. Bütün bu kurulum işlemlerinin, dikkatlice planlanarak birbiri ile eşgüdüm içerisinde yapılması gerekir. Özellikle büyük boyutlu, uzun zaman alan ve coğrafik olarak çok alana yayılmış projelerde eşgüdüm daha da önem kazanmaktadır.

Donanım kurulumu, yazılımın yerleştirileceği sahadaki donanımın, ağ alt yapısının ve kullanıcı uçlarının hazırlanma çalışmalarını içerir.

Sistem yazılımı kurulumu, işletim sistemi, hazır yordamlar, anti-virüs yazılımları ve kullanıcı tarafından kullanılacak ofis yazılımları türündeki yazılımların kurulumlarını içermektedir.

Veri tabanı kurulumu, uygulama yazılımları tarafından kullanılacak veri tabanı yazılımının (Örneğin Oracle) sunucu bilgisayarlara ve uygulamaya ilişkin veri tabanı platformunun istemci bilgisayarlara yüklenmesi işlemlerini içermektedir.

Uygulama yazılımlarının ana sunucu ve istemci bilgisayarlara yüklenmesi kurulum işleminin hedef işlemidir.

Kurulum işlemlerine koşut olarak kullanıcılara gerek yazılım gerekse donanım sistemlerine ilişkin eğitim verilmelidir. Söz konusu eğitim; genel bilgisayar kullanımı eğitimi, teknik eğitim ve uygulama yazılımı kullanıcı eğitimi biçiminde üç ayrı alanda sağlanmalıdır.

Sistemlerin kurulumu sırasında ve sonrasında kullanıcı alanında sürekli kalınarak verilen destek, “yerinde destek” olarak tanımlanmaktadır. İzleyen kesimde yerinde destek organizasyonunun yapısı açıklanmaktadır.

Kurulum işlemleri, yazılımı üreten ekipten bağımsız bir ekip tarafından gerçekleştirilir.

8.2.1. Yerinde Destek Organizasyonu

Yerinde destek ekibi, kullanıcı alanında yerleşik olarak bulunan gerekli sayıda elemandan oluşan bir ekiptir. Bu ekibin temel görevleri:

1. Kullanıcıları ziyaret ederek sorunlarını belirlemeye çalışmak,
2. Giderilebilen kullanıcı sorunlarını gidermek ve giderilemeyenleri üretim sahasındaki uygulama yazılımı destek ekibine iletmek,
3. Kullanıcıya işbaşında uygulama eğitimi vermek,
4. Kullanıcı sınama günlüklerini toplamak
5. Yapılan tüm işlemleri konfigürasyon veri tabanına kaydetmek biçimindedir.

Şekil 8.1 Yerinde Destek Organizasyonu

Bilişim uygulamalarının, uygulamaya geçiş aşamasında, özellikle, ilk bilgisayarlı uygulama olma durumunda, “geçiş dönemi” büyük önem taşımaktadır. Geçiş döneminde, hem bilgisayarlı uygulama hem de elle yapılan işlemler belirli bir süre için aynı anda yürütülür. Bu dönemde, yerinde destek elemanlarına oldukça önemli görevler düşer.

Yerinde destek ekibi, hem temel bilgisayar kullanımı, hemde uygulama yazılımı kullanımı konusunda eğitilmiş elemanlardan oluşur.

 8.3. Yazılım Bakımı

• Tanım
  
• Bakım Süreç Modeli
• Sorun Tanımlama Süreci
• Çözümleme Süreci
• Tasarım Süreci
• Gerçekleştirim Süreci
• Sistem Sınama Süreci
• Kabul Sınaması Süreci
• Kurulum Süreci

8.3.1. Tanım

Bakım, işletime alınan yazılımın sağlıklı olarak çalışması ve ayakta tutulabilmesi için yapılması gereken çalışmalar bütünü olarak tanımlanır. Uygulamada çalışan bir yazılımın üç tür bakım gereksinimi bulunmaktadır:

• Düzeltici Bakım: Teorik olarak bir yazılımın tümüyle sınanabilmesi olası olsa bile, pratikte bu sağlanamaz. Bu nedenle çalışan bir yazılımda her an hata ile karşılaşma olasılığı vardır. Bu nedenle zaman zaman çalışan yazılımda ortaya çıkan hataların düzeltilmesi gerekir. Bu tür düzeltme çalışmaları “Düzeltici bakım olarak adlandırılır.
  
  
• Uyarlayıcı Bakım: Uygulama yazılımları, işletme ya da kuruluşlarn günlük yaşamlarında yaptıkları işleri bilgisayar ortamında yapmalarını sağlayan araçlardır. Her kuruluş ya da işletme canli bir varlık gibi düşünülebilir. Hiçbir işletme durağan değildir. Süreç içinde değişkenlik gösterir. İşletme ya da kuruluşlarda değişiklik, yapılan işlerin yapılma tarzının değişmesi, yeni iş türlerinin ortaya çıkması biçiminde kendini gösterebilir. İşletme ya da kuruluşlarda yaşanan değişikliklerin, o kuruluşun işlerini bilgisayar yardımı ile yapmalarını sağlayan uygulama yazılımlarına da yansıtılması gerekir. Bu yansıtma işlemi, “Uyarlayıcı Bakım” olarak tanımlanır.
  
  
• En iyileyici Bakım: Zaman zaman uygulama yazılımlarının çalışma performanslarının iyileştirilmesi amacıyla yapılan çalışmalar “en iyileyici bakım” olarak tanımlanır.

Bakım yazılım yaşam döngüsünün en önemli ve en maliyetli aşamalarından biridir. Bakım süreci, yazılım yaşam döngüsünde “buzdağının görünmeyen kısmı” olarak adlandırılır. Bakım maliyetleri, zaman zaman üretim maliyetlerinin %60’ını geçer.

Bu bölümde, yazılım bakımı ile ilgili kavramlar açıklanmaktadır. Bu kavramların açıklanmasında IEEE 1219 standardı baz olarak alınmıştır.

 8.3.2. Bakım Süreç Modeli

IEEE 1219 standardı tarafından önerilen bakım süreç modeli şekil 8.2’de belirtilen şablonu kullanarak bakım süreçlerini tanımlamaktadır. Bakım süreç modelinin süreçleri:

Şekil 8.2 Bakım süreç modeli şablonu

1. Sorun Tanımlama/sınıflandırma,
2. Çözümleme,
3. Tasarım,
4. Gerçekleştirim,
5. Sistem Sınama,
6. Kabul Sunama ve
7. Kurulum

biçimindedir. Görüldüğü gibi, bakım süreci, yazılım yaşam döngüsü çekirdek adımlarının bir anlamda yinelenmesinden oluşmaktadır. Bu yinelenme yalnızca değişiklik isteklerinin varolan koda aktarılması amacıyla yapılmaktadır. Bakım süreçleri aşağıda açıklanmaktadır.

8.3.2.1. Sorun Tanımlama Süreci

Sorun tanımlama sürecinin genel yapısı şekil 8.3’te belirtilmektedir.

Şekil 8.3 Sorun Tanımlama Süreci

Girdi: Sorun tanımlama sürecinin temel girdisi, Bakım isteğidir. Herhangi bir bakım isteğine örnek olarak:

1. Sistemde beklenen ve yeni düzenlemelere ilişkin değişiklikler,
2. Yeni işlev istekleri,
3. Yazılımda bulunan yanlışların düzeltilme istekleri,
4. Performans artımına ilişkin istekler,
5. Yeni iş yapma türlerine ilişkin istekler ve
6. Teknolojinin zorlaması sonucu oluşan istekler türündeki istekler verilebilir.

İşlem/Süreç: Yazılım bakım isteği oluştuğunda yapılması gereken işlemler:

1. Değişiklik isteğine bir tanım numarası verilmesi,
2. Değişiklik türünün sınıflandırılması,
3. Değişiklik isteğinin kabul, red ya da daha ayrıntılı incelenmesi yönünde karar alınması,
4. Değişiklik ile ilgili zaman/boyut/işgücü kestirimi yapılması,
5. Değişiklik isteğinin önceliklendirilmesi
6. Değişiklik isteğinin diğerleri ile birlikte zaman ve iş planına kaydedilmesi biçiminde özetlenebilir. Bu işlemlerin birçoğunda, değişiklik isteğini yapan kişi, kullanıcı temsilcileri, yazılım mühendisleri ve konu uzmanları birlikte çalışıp karar verirler.

Denetim: Sorun tanımlama aşamasında, değişiklik isteğinin daha önceden yapılıp yapılmadığı denetlenmeli ve tek olduğu belirlenmelidir. Bu amaçla, daha önceki değişiklik istekleri taranır.

Çıktı: Bu sürecin temel çıktısı, doğrulanmış ve geçerlenmiş ve karar verilmiş Bakım İsteğidir. Bir veri tabanında saklanan bu isteğin ayrıntıları:

1. Sorun ya da yeni gereksinimin tanımı,
2. Sorun ya da gereksinimin değerlendirmesi,
3. Başlangıç öncelik,
4. Geçerleme verisi (Düzeltici bakım için),
5. Başlangıç kaynak gereksinimi,
6. Mevcut ve gelecekte kullanıcılar üzerindeki etkileri,
7. Yararlı ve aksak yönleri

Ölçüt: Sorun tanımlama sırasında kullanılabilecek ölçütler:

1. Bakım isteklerinde kabul edilmeyen madde sayısı,
2. Gelen bakım istekleri sayısı ve
3. Sorun geçerleme için harcanan kaynak ve zaman biçimindedir.

8.3.2.2. Çözümleme Süreci

Çözümleme süreci, veri tabanında saklanmış ve geçerlenmiş bakım isteğini girdi olarak alır, projeye ilişkin bilgi ve belgeleri kullanarak söz konusu isteğin yerine getirilmesi için gerekli genel planı yapar (Şekil 8.4).

Şekil 8.4 Çözümleme Süreci

Girdi: Çözümleme sürecinin girdileri:

1. Geçerlenmiş bakım isteği,
2. Başlangıç kaynak gereksinimleri ve diğer veriler ve
3. Mevcut proje yada sistem bilgi ve belgeleri biçimindedir:

İşlem/Süreç: Çözümleme süreci temel olarak iki aşamadan oluşur: Olurluk aşaması ve ayrıntılı çözümleme aşaması. Mevcut sisteme ya da projeye ilişkin yapısal belgelerin bulunmadığı durumlarda tersine mühendislik yöntemi kullanılır.

Olurluk çalışması,

1. Değişikliğin etkisi,
2. Prototiplemeyi içeren seçenek çözümler,
3. Dönüştürme gereksinimlerinin çözümlemesi,
4. Güvenlik ve emniyet zorunlulukları
5. İnsan faktörleri,
6. Kısa ve uzun erimli maliyetler ve
7. Değişikliği yapmanın yararları bilgilerini içerir.

Ayrıntılı çözümleme çalışmasında, değişiklik isteği için ayrıntılı gereksenim tanımlaması yapılır. Bu çalışmada etkilenen yazılım öğeleri (yazılım tanımları, yazılım gereksinimleri, tasarım, kod, vb) belirlenir. Yazılım öğelerinin değişmesi gereken kısımları belirlenir. En az üç düzeyli sınama stratejisi (birim sınaması, bütünleştirme sınaması ve kabul sınaması) tanımlanır. Bu aşamanın son çalışması ise, kullanıcıya en az etki yapacak şekilde değişiklik gereksinimlerinin nasıl karşılanacağı bilgilerini içeren “Başlangıç gerçekleştirim planı” dır.

Denetim: Çözümleme çalışmasının denetiminde aşağıdaki işlemler yapılır.

1. Gerekli proje yada sistem bilgi/belgelerine erişimin sağlanması (Ortam denetim organizasyonundan)
2. Önerilen değişikliklerin ve çözümleme çalışmasının teknik ve ekonomik olurluğunun gözden geçirilmesi,
3. Güvenlik ve emniyet konularının tanımlanması,
4. Önerilen değişikliğin, mevcut yazılımla bütünleştirilmesinin dikkate alınması,
5. Proje belgelerinin düzgün olarak günlendiğinin denetimi,
6. Çözümleme belgelerinin düzgün olarak hazırlanmasının sağlanması,
7. Sınama stratejilerinin uygun olarak belirlenmesi.

Çıktı: Çözümleme çalışmasının çıktıları:

• Değişiklik isteklerine ilişkin olurluk çalışması,
• Ayrıntılı çözümleme raporu,
• İzlenebilirlik listesini içeren günlenmiş gereksinim tanımları,
• Başlangıç değişiklik listesi,
• Sınama stratejisi,
• Gerçekleştirim planı

Ölçüt: Çözümleme çalışmasında kullanılabilecek ölçütler:

1. Gereksinimlerdeki değişiklik sayısı,
2. Belgeleme hata oranı,
3. Her işlev alanı için gerekecek işgücü ve
4. Toplam zaman biçimindedir.

8.3.2.3. Tasarım Süreci

Çözümleme süreci, veri tabanında saklanmış ve geçerlenmiş bakım isteğini girdi olarak alır, projeye ilişkin bilgi ve belgeleri kullanarak söz konusu isteğin yerine getirilmesi için gerekli genel planı yapar (Şekil 8.4).

Şekil 8.5 Tasarım Süreci

Tasarım aşamasında, değişiklikten etkilenebilecek tüm proje bilgi ve belgeleri üzerinde çalışma yapılıp söz konusu bilgi ve belgeler değişiklikle ilgili olarak günlenir.

Girdi: Tasarım çalışmasının girdileri:

1. Çözümleme çalışması çıktıları
2. Ayrıntılı çözümleme,
3. Günlenmiş gereksinim tanımları,
4. Başlangıç değişiklik listesi,
5. Sınama stratejisi,
6. Gerçekleştirim planı
7. Sistem ve proje belgeleri ve
8. Varolan kaynak kodları açıklamalar ve veritabanları biçimindedir.

İşlem/Süreç: Tasarım için gerekli temel işlemler aşağıda belirtilmektedir.

1. Etkilenen yazılım modüllerinin tanımlanması,
2. Yazılım modül belgelerinin değiştirilmesi,
3. Yeni tasarım için, güvenlik ve emniyet konularını da içeren sınama senaryolarının hazırlanması,
4. İlişki sınamalarının tanımlanması,
5. Kullanıcı belgelerinin günleme gereksinimlerinin tanımlanması
6. Değişiklik listesinin günlenmesi

Denetim: Tasarım çalışmasında aşağıdaki denetim ortamı kurulmalıdır.

Tasarımın belirlenen standartlara uygunluğunun denetlenmesi,

1. Güvenlik ve emniyet konularını içeren yeni tasarım belgesinin tasarım belgesinin ve bilgilerinin oluşturulmasının sağlanması,
2. Sınama bilgilerinin günlenmesinin sağlanması,
3. Gereksinimlerden tasarıma izlenebilirliğin sağlanası.

Çıktı: Bakım tasarımı çalışmasının çıktıları:

1. Gözden geçirilmiş değişiklik listesi,
2. Günlenmiş tasarım
3. Günlenmiş sınama planları,
4. Günlenmiş ayrıntılı çözümleme,
5. Günlenmiş gereksinimler,
6. Gözden geçirilmiş gerçekleştirim planı
7. Risk ve kısıtlar listesi biçimindedir.

Ölçüt: Tasarım çalışması için kullanılabilecek ölçütler aşağıda verilmektedir.

• Yazılım karmaşıklığı,
• Tasarım değişiklikleri
• Her işlev alanı için gerekecek işgücü,
• Toplam zaman,
• Sınama yönerge ve plan değişiklikleri,
• Önceliklendirmedeki hata oranları,
• Varolan kodda, eklenen, çıkarılan ve değiştirilen satır sayısı,
• Uygulama sayısı.

8.3.2.4. Gerçekleştirim Süreci

Gerçekleştirim süreci, temel olarak tasarım çıktılarını ve kaynak kodları girdi olarak almakta ve değişiklik isteğini gerçekleştiren kod parçaları ile günlenmiş yazılım kodlarını üretmektedir. Günlenmiş yazılıma ilişkin sınama bilgi ve belgelerinin ve eğitim belgelerinin üretimi de bu süreçte yapılmaktadır (Şekil 8.6).

Şekil 8.6 Gerçekleştirim Süreci

Girdi: Gerçekleştirim sürecinin girdileri:

1. Tasarım çalışması sonuçları,
2. Varolan kaynak kodlar, açıklamalar, belgeler ve
3. Proje ve sistem belgeleri biçimindedir.

İşlem/Süreç: Gerçekleştirim sürecinin dört ana işlemi vardır:

1. Kodlama ve birim sınama
2. Bütünleştirme
3. Risk çözümleme
4. Sınama hazırlığı gözden geçirme

Kodlama işleminde, değişiklik isteğini karşılayan yazılım kodları, varolan yazılıma eklenmektedir. İşlem sonucunda elde edilen yeni, değişmiş modüllere birim sınama uygulanmaktadır. Birim sınama işlemini, bütünleştirme sınama izlemekte, tüm sistem yeniden sınanmaktadır.Uygulamadaki riskleri gidermek amacıyla, gerçekleştirim aşamasında sürekli risk çözümleme yapılmaktadır.

Denetim: Gerçekleştirim sürecinde oluşturulacak denetim yapısı, aşağıdaki özellikleri sağlamalıdır:

• Belirlenen standartlara uygun olarak kod ve yazılım gözden geçirmeleri yapılması,
• Birim ve bütünleştirme sınamaları ile ilgili bilgilerin derlenmesi ve kaydedilmesinin sağlanması,
• Sınama belgelerinin günlenmesi ve oluşturulmasının sağlanması,
• Sınama hazırlık gözden geçirmeleri sırasında risk çözümlemenin sağlanması,
• Yeni yazılımın, yazılım ortam yönetimi altında kaydedilmesi ve denetlenmesinin sağlanması,
• Teknik ve eğitim belgelerinin günlenmesinin sağlanması,
• Tasarımdan koda izlenebilirliğin sağlanması

Çıktı: Gerçekleştirim süreci aşağıdaki çıktıları vermelidir:

1. Günlenmiş Yazılım,
2. Günlenmiş tasarım bilgi/belgeleri,
3. Günlenmiş sınama belgeleri,
4. Günlenmiş kullanıcı belgeleri,
5. Günlenmiş eğitim kılavuzları,
6. Riskler ve kullanıcılara etkileri,
7. Sınama hazırlığı gözden geçirme raporu

Ölçüt: Gerçekleştirim çalışmasında kullanılabilecek ölçütler:

1. Değişiklik oranı ve
2. Hata oranı biçimindedir.

8.3.2.5. Sistem Sınama Süreci

Şekil 8.7 Sistem sınama Süreci

Değişikliklerin varolan yazılıma yansıtılmasından sonra elde edilen yeni yazılım sürümünün belirlenen standartlara uygun olarak tümüyle bütünleşik sistem üzerinde sınamaların yapılması gerekmektedir. Sistem sınamalarının, kullanıcı ve üretici ekiplerin tanıklığında bağımsız bir yapı tarafından gerçekleştirilmeleri önerilmektedir.

Girdi: Sistem sınama sürecinin girdileri:

1. Sınama hazırlık raporu
2. Belgeler
3. Sistem sınama planları,
4. Sistem sınamaları,
5. Sistem sınama yönergeleri,
6. Kullanıcı kılavuzları,
7. Tasarım
8. Günlenmiş sistem biçimindedir.

İşlem/Süreç: Sistem sınama, tümüyle bütünleşik bir sistem üzerinde yapılmalıdır. Bu aşamada, işlevsel sistem sınama, arayüz sınama, regresyon sınama ve sınama hazırlık raporunun gözden geçirilmesi işlemleri yapılır.

Denetim: Sistem sınamaları, üretici ve kullanıcılardan bağımsız bir grup tarafından gerçekleştirilmelidir. Yazılım kodları ve her türlü bilgi belge, yazılım ortam yönetimi tarafından saklanır.

Çıktı: Bu aşamanın temel çıktıları:

1. Sınanmış tümüyle bütünleşik sistem,
2. Sınama raporu,
3. Gözden geçirilmiş sınama hazırlık raporu biçimindedir.
   

Ölçüt: Bu aşamada kullanılabilecek ölçütler, üretilen ve düzeltilen hata oranlarıdır.

8.3.2.6. Kabul Sınaması Süreci

Kabul sınaması süreci, kullanıcılar ya da kullanıcı temsilcileri tarafından gerçekleştirilen bir süreçtir. Kullanıcıların, değişiklikleri içeren yeni yazılımı sınamaları ve kabul etmeleri beklenmektedir (Şekil 9.7).

Şekil 9.7 Kabul Sınama Süreci

Girdi: Kabul sınama sürecinin girdileri:

1. Gözden geçirilmiş sınama hazırlık raporu,
2. Tümüyle bütünleşik sistem,
3. Kabul sınama planları,
4. Kabul sınamaları ve
5. Kabul sınama yönergeleri biçimindedir.
   

İşlem/Süreç: Kabul sınaması işlemleri:

1. İşlevsel kabul sınamalarının yapılması,
2. Birlikte çalışabilirlik sınaması,
3. Regresyon sınaması biçimindedir.

Denetim: Kabul sınamaları sırasında denetimi aşağıdaki işlemleri içermektedir.

1. Kabul sınamalarının uygulanması,
2. Sınama sonuçlarının raporlanmasının sağlanması,
3. İşlevsel denetim yapılması,
4. Yeni sistemin oluşturulması,
5. Kabul sınama belgelernin yazılım konfigürasyonuna yerleştirilmesi.

Çıktı: Kabul sınamalarının çıktıları, yeni sistem, işlevsel konfigürasyon denetim raporu ve kabul sınaması raporudur.

Ölçüt: Bu aşamada kullanılabilecek ölçütler: üretilen ve düzeltilen hata oranlarıdır.

8.3.2.7. Kurulum Süreci

Şekil 9.8 Kurulum Süreci

Kurulum süreci, geliştirilen ya da değiştirilmiş yeni yazılım sürümünün, uygulama sahasına aktarılma işlemlerini içerir.

Girdi: Bu sürecin temel girdisi, tümüyle sınanmış ve kabul edilmiş yeni yazılım sürümüdür.

İşlem/Süreç: Bu sürecin işlemleri:

• Fiziksel ortam denetiminin yapılması,
• Kullanıcıların bilgilendirilmesi,
• Varolan sistemin yedeklerinin alınması ve
• Kullanıcı tarafında kurulum ve eğitimlerin yapılması biçimindedir.

Denetim: Denetim işlemleri:

1. Fiziksel ortam denetiminin yapılması,
2. Sistem ile ilgili bilgi ve belgelerin kullanıcıya ulaştırılması,
3. Sürüm Tanımlama raporunun tamamlanması ve
4. Yazılım konfigürasyon ortamına aktarımın sağlanması

alanlarını içermektedir.

Çıktı: Bu sürecin temel çıktıları, fiziksel ortam denetim raporu ve Sürüm tanımlama raporudur.

Ölçüt: Bu süreçte kullanılabilecek ölçüt, belgeleme değişiklikleridir.

Bölüm Özeti

1) Kurulum planlamasında mevsimsel koşulların dikkate alınması önemlidir. Örneğin, kış mevsiminde yoğun kar alan doğu bölgelerindeki sahalara kurulum zaman zaman olanaksızdır. Bu nedenle, kurulum planlamasında, bu tür bölgeler bahar ya da yaz ayları içerisinde planlanmalıdır.

2) Kurulum, yalnızca uygulama yazılımı sürümlerinin yüklenmesini içermemekte, zaman zaman teknolojik alt yapı değişebilmekte ve yeni sistem yazılımı sürümlerinin yüklenmesi gerekebilmektedir. Bu nedenle, kurulum elemanlarının, gerekli teknik bilgilerle donatılması ve teknolojik değişimleri izlemelerinin sağlanması gerekmektedir.

3) Uç kullanıcılar zaman zaman kendi bilgisayarlarına dışarıdan getirdikleri ya da internet ortamından sağladıkları yazılımları yüklerler. Virüs riski taşıyan bu tür yazılımlara karşı kullanıcıları sürekli uyarmak ve anti-virüs yazılımlarının kullanımını özendirmek gerekmektedir.

4) Ülkemizde kullanılan yazılım üretim yöntemleri düşünüldüğünde, bilinen anlamda bakım yapılmadığı, yazılımları hazırlayan kişilerin yıllarca kendi yazdıkları yazılıma yamalar yaptıkları, yazılımı usta-çırak ilişkisi içerisinde başkalarına devretmeye çalıştıkları ve çalışan yazılıma ilişkin elde düzgün teknik belgelerin olmadığı bir ortamla karşılaşılmaktadır. Bu durum zaten pahalı olan bilişim işgücünü verimsiz kullanmamıza neden olmaktadır.

5) Kullanıcı ve yerinde destek elemanları arasındaki tüm iletişimin kayıt altına alınmasının sağlanması ve izlenmesi gerekmektedir.

Sorular

1) Kurulum işlemlerini belirtiniz.

2) Yerinde destek ekibinin görev ve sorumluluklarını tanımlayınız.

3) Uygulamakta olduğunuz bir proje için yaptığınız ya da yapmayı düşündüğünüz kurulum işlemlerini açıklayınız.

4) Geçiş dönemini tanımlayınız.

5) Bir uygulama yazılımının ömrü nasıl belirlenir?

6) Yazılım Bakımını tanımlayınız, bakım türlerini açıklayınız.

7) Bakım süreçlerinin her birinde oluşabilecek risklere birer örnek veriniz.

Değerlendirme Soruları

 Bölüm 9: Nesneye Yönelik Çözümleme ve Tasarım

 Bölüm 10: Yazılım Mimarileri

 Bölüm 11: Yazılım Kalite ve Konfigürasyon Yönetimi

 Bölüm 12: CASE: Bilgisayar Destekli Yazılım Mühendisliği Araç ve Ortamları

Kaynaklar 

1- Yazılım nedir?

Yazılım bir ihtiyacı karşılayan programlar+veriler+yapılandırma+dokümantasyonun bütünüdür.

2- Yazılım mühendisliği nedir?

Yazılımı sistematik, ölçülebilir biçimde geliştirme, işletme ve bakım disiplinidir.

3- Yazılım mühendisliğinin bilgisayar biliminden ne farkı vardır?

Bilgisayar bilimi kuram ve genel tekniklerle ilgilenir. Yazılım mühendisliği bu bilgiyi ürünleştirir.

4- Yazılım mühendisliği ile sistem mühendisliği arasında ne fark vardır?

Sistem mühendisliği, insan, donanım, yazılım ve sürecin yaşam çevrimi ile ilgilidir. Yazılım mühendisliği yazılımın derinliği ile ilgilenir.

Yazılım geliştirme ve sınama maliyetleri oranları nedir?

Yazılım maliyetinin %60'ı yazılım geliştirme ve %40'ı yazılım sınama maliyetleridir.

5- Yazılım süreci nedir?

Gereksinim → analiz/tasarım → geliştirme → test → dağıtım/işletme → bakım döngüsüne yazılım süreci denir.

6- Yazılım süreç modeli nedir?

Yazılım süreç modeli, yazılım geliştirme, bakım ve yönetimi için gerekli tüm görevleri, adımları ve aşamaları tanımlayan çerçevedir. Bu model, bir yazılım projesini baştan sona yönetmek için yol haritası sunar. Başlıca örnekleri Şelale, Çevik (Agile) ve V-Model'dir.

7- Requirement nedir?

sistemin yapması gereken doğrulanabilir ifade.

8-V&V nedir?

V&V doğrulama ve geçerlemedir:

doğrulama: doğru yaptık mı?

geçerleme: doğru şeyi yaptık mı?

 

9- Mimari tasarım denir?

MİMARİ TASARIM. Mimari tasarım, bir yazılım sisteminin genel yapısını ve ana bileşenlerini belirleme sürecini ifade eder. 

10- Mimari tasarımın amaçları nelerdir?

sistemin yapısını tanımlamak

kalite niteliklerini sağlamak

iletişimi kolaylaştırmak

geliştirme sürecini yönlendirmek

11- Teknik borç nedir?

Teknik borç hız için alınan kalite borcudur, faizi bakım maliyeti ve hata oranı olarak geri döner.

12- Yazılım mühendisliğinde ana test yüzeyleri nelerdir?

birim testi

entegrasyon testi

sistem testi

kabul testi

13- Agilenin popüler olmasının sebepleri nelerdir?

değişen gereksinime uyum

erken değer

geri bildirim döngüsünün kısalığı

14- Temel üçlü nedir?

Temel üçlü UML'in en sık kullanılan ve en temel diyagramlarını ifade eder: use-case, class, sequence

15- SOLID nedir?

single responsibility

open/closed principle

Liskov substitution

interface segregation

dependency inversion

 

16- Yüksek bağlaşıklık nedir?

Bir modül içindeki elemanlar (fonksiyonlar, sınıflar) güçlü bir şekilde birbiriyle ilişkili ise yüksek bağlaşıklık vardır.

17- Düşük bağlayıcılık nedir?

Modüller ve sınıflar arasındaki bağımlılıkların minimumda tutulmasına düşük bağlayıcılılık denir.

18- DRY nedir?

Don't repeat yourself.

19- KISS nedir?

Keep it simple, stupid.

20- YAGNI nedir?

You aren't gonna need it.

 21. En yaygın kullanılan yazılım modelleme dili hangisidir?

UML

22. Bilgi sisteminin bileşenleri nelerdir?

donanım

yazılım

veri

insan

süreç

23. En çok maliyet gerektiren sistem bileşeni hangisidir?

yazılım

24) ... bilgi sisteminin soyut ve işlevsel bileşenidir

yazılım

25) Sistem yaşam çevrimi nedir?

Sistem yaşam çevrimi, bir yazılımın ya da bilgi sisteminin fikir aşamasından başlayıp kullanımdan kalkana kadar geçen tüm süreçleri kapsayan modeldir. Ana evreleri  şunlardır:

Planlama

Analiz

Tasarım

Kodlama

Test

Kurulum ve bakım

Bir e-ticaret sitesi için ana evreler:

PLANLAMA. Hangi ürünlerin satılacağı, hedef kitlenin kim olduğu belirlenir.

ANALİZ. Müşterilerin ürünleri nasıl arayacağı, sepetine nasıl ekleyeceği gibi gereksinimler toplanır.

TASARIM. Sitenin ana sayfası, ürün sayfaları ve ödeme sayfasının taslakları oluşturulur.

KODLAMA. Front-end ve back-end kodları yazılarak site işlevsel hale getirilir.

TEST. Sitedeki tüm bağlantıların çalıştığı, ödeme sisteminde hata olmadığı kontrol edilir.

KURULUM VE BAKIM. Site yayına alınır ve sonrasında kullanıcı geri bildirimlerine göre hatalar düzeltilir veya yeni özellikler eklenir.

26) Front-end nedir?

Bir web sitesinin kullanıcı ile doğrudan etkileşime giren kısmına front-end denir.

27) Back-end nedir?

Bir web sitesinin arka planda çalışan kısmına back-end denir.

1950-1960 yılları arasında geliştirilen yazılımların temel özellikleri nelerdir?

Bilgisayarların doğduğu bu yıllarda üretilen yazılımlar temel olarak, yığınsal kökenli biçimde geliştirilmişti. Ayrıca bugünün bilinen anlamında ürün tarzında değil bütünüyle kendisi için yapılan kuruluşa özel biçimde geliştirme yapılmaktaydı.

Yazılımın temel amaçları nelerdir?

Veriyi bilgiye dönüştürmek.

İnsan hatasına açık işleri makineye devretmek.

Fiziksel sistemleri kontrol etmek.

İnsan-insan ve sistem-sistem etkileşimi sağlamak.

Bilgiyi kalıcı, güvenli ve hızlı erişilebilir tutmak.

Seçenekler arasından en iyiyi seçmek.

Karmaşıklığı gizlemek.

Güvenlik-kritik sistemlerde riski azaltmak.

Süreçleri senkronize etmek.

Kullanıcıların hedefe hızlı ve hatasız ulaşmasını sağlamak.

İçerik üretmek.

Tasarım yapmak.

Yazılım üretimi, bir ... disiplini gerektirir. 

mühendislik 

Yazılımın insan bileşeninin boyutları nelerdir?

yazılım geliştirenler

yazılım kullananlar

Yazılımın ana çıktısı nedir?

Yazılımın ana çıktısı bilgisayar programıdır.

Yazılım modelleme dili yazılım sistemi geliştirmede kullanılan ... bir araçtır.

görsel

İyi bir yazılımın özellikleri nelerdir?

İyi yazılım kullanıcıya gereken fonksiyonelliği ve performansı sağlamalı ve bakımı yapılabilir, güvenilebilir ve kullanılabilir olmalıdır.

Temel yazılım mühendisliği etkinlikleri nelerdir?

yazılım spesifikasyonu

yazılım geliştirme

yazılım doğrulama

yazılımın evrimi

Yazılım mühendisliği ile sistem mühendisliği arasında ne fark vardır?

Sistem mühendisliği donanım, yazılım ve süreç mühendisliği dahil olmak üzere bilgisayar tabanlı sistem geliştirmenin tüm yönleri ile ilgilenir. Yazılım mühendisliği bu daha genel sürecin parçasıdır.

Yazılım mühendisliği ile ilgili temel zorluklar nelerdir?

artan çeşitlilikle başa çıkma

daha kısa teslim süresi talepleri ve 

güvenilir yazılım geliştirme

Yazılım mühendisliğinin maliyetleri nelerdir?

Yazılım maliyetlerinin kabaca %60'ı geliştirme maliyetleridir, %40'ı sınama maliyetleridir. Özel ısmarlama yazılım için evrim maliyetleri genellikle geliştirme maliyetlerini aşar.

En iyi yazılım mühendisliği teknikleri ve yöntemleri nelerdir?

Tüm yazılım projelerinin profesyonel olarak yönetilmesi ve geliştirilmesi gerekir ama farklı sistem türleri için farklı teknikler uygundur. Örneğin oyunlar her zaman bir dizi prototip kullanılarak geliştirilmeliyken, hayati tehlike arz eden kontrol sistemleri tam ve analiz edilebilir bir spesifikasyonun geliştirilmesini gerektirirler. Her şey için iyi olan yöntemler ve teknikler yoktur.

İnternet yazılım mühendisliğinde ne değişiklik yapmıştır?

İnternet sadece çok büyük, çok dağıtık servis-tabanlı sistemlerin geliştirilmesine yol açmamıştır, aynı zamanda yazılımın ekonomisini değiştiren mobil cihazlar için bir uygulama (app) endüstrisi yaratılmasını desteklemiştir.

 (1) Mühendislik nedir?

-Mühendislik, doğadaki maddenin ve enerji kaynaklarının insanların kullanımı için yararlı hale getirilmesi için bilimsel ve matematiksel prensiplerin uygulanmasıdır.

(2) Yazılım mühendisliği nedir?

-Yazılım geliştirmek, çalıştırma ve devam ettirmek için sistematik disiplinli ölçülebilir yaklaşımın uygulanmasına yazılım mühendisliği denir.

(3) Yazılım projelerindeki başarısızlıklar daha çok neden kaynaklanmaktadır?

-Yazılım projelerindeki başarısızlıklar daha çok başarısız proje yönetiminden kaynaklanmaktadır.

Bir müşteri için geliştirilen profesyonel yazılımın niçin sadece geliştirilen ve teslim edilen programlar olmadığını açıklayınız.

Profesyonel yazılım, sadece çalıştırılabilir koddan (programlardan) ibaret değildir. Müşteri için geliştirilen yazılım, bir bütün olarak bir yazılım sistemini temsil eder ve bu sistem aşağıdaki bileşenleri de içerir:

Gereksinimler: Yazılımın ne yapacağını belirten dokümanlar (kullanıcı ve sistem gereksinimleri).

Tasarım Modelleri: Yazılımın mimarisi, yapısı ve bileşenlerinin nasıl çalıştığını açıklayan tasarımlar.

Test Planları ve Raporları: Yazılımın doğruluğunu ve kalitesini gösteren test dokümanları.

Kullanım Kılavuzları: Kullanıcıların ve sistem operatörlerinin yazılımı nasıl kullanacağını açıklayan materyaller.

Kurulum/Yapılandırma Dosyaları: Yazılımın farklı ortamlara kurulması ve yapılandırılması için gerekli dosyalar.

Sürüm Kontrol Bilgileri: Yazılımın geliştirilmesi sırasında yapılan değişikliklerin kaydı ve yönetimi.

Bu ek bileşenler olmadan yazılımın doğru bir şekilde anlaşılması, kullanılması, sürdürülmesi ve geliştirilmesi mümkün olmaz. Müşteri, sadece programı değil, bu programın nasıl çalıştığını, ne yaptığını ve nasıl destekleneceğini de bilmek ister.

Genel özellikli yazılım ürünü geliştirme ile ısmarlama yazılım geliştirme arasındaki en önemli fark nedir? Genel amaçlı yazılım kullanıcıları için pratikte bu ne demektir?

En Önemli Fark:

• Genel Özellikli Ürün Yazılımı: Özellikleri, yazılım geliştiricisi tarafından belirlenir ve geniş bir pazara hitap eder.

• Ismarlama (Müşteriye Özel) Yazılım: Özellikleri, müşteri tarafından belirlenir ve belirli bir organizasyonun veya kullanıcının özel ihtiyaçlarını karşılar.

Genel Amaçlı Yazılım Kullanıcıları İçin Pratik Sonuçları:

1. Kontrol Eksikliği: Kullanıcılar, yazılımın spesifikasyonları üzerinde doğrudan bir kontrole sahip değillerdir. İstekleri, ancak geliştiricinin gelecekteki sürümlere eklemeyi kabul etmesi durumunda yerine getirilebilir.

2. Uzlaşma İhtiyacı: Kullanıcılar, yazılımın sağladığı özelliklerle kendi iş süreçlerini veya ihtiyaçlarını uzlaştırmak (adaptasyon sağlamak) zorundadırlar. Yazılım, onların iş akışına tam olarak uymayabilir.

Tüm profesyonel yazılımların özellikle sahip olması gereken dört önemli özellik nedir? Bazen önemli olabilecek dört diğer özellik öneriniz.

Tüm Profesyonel Yazılımların Sahip Olması Gereken Dört Önemli Özellik (4 Temel Öznitelik):

1.      Sürdürülebilirlik (Maintainability): Yazılımın hataları düzeltecek, yeni gereksinimlere uyum sağlayacak ve gelecekteki çevresel değişikliklere adapte olacak şekilde kolayca değiştirilebilir olması.

2.      Güvenilirlik ve Güvenlik (Dependability and Security):

o    Güvenilirlik (Reliability): Yazılımın kullanıcı beklentilerine uygun olarak hizmet sunması ve makul bir hata oranıyla çalışması.

o    Güvenlik (Security): Yazılımın kötü niyetli veya kazara yapılan saldırılara ve yetkisiz erişime karşı dayanıklı olması.

3.      Verimlilik (Efficiency): Yazılımın bellek, işlem gücü ve enerji gibi sistem kaynaklarını israf etmeden, kabul edilebilir bir performansla çalışması.

4.      Kullanılabilirlik (Usability): Yazılımın hedef kullanıcıları tarafından kolayca öğrenilebilmesi, anlaşılabilmesi ve kullanılabilmesi.

Bazen Önemli Olabilecek Dört Diğer Özellik:

1.      Taşınabilirlik (Portability): Yazılımın, minimum değişiklikle farklı işletim sistemlerine veya donanım platformlarına taşınabilme yeteneği.

2.      Yeniden Kullanılabilirlik (Reusability): Yazılım bileşenlerinin veya kodlarının, gelecekteki farklı sistemlerin geliştirilmesinde tekrar kullanılabilme yeteneği.

3.      Uyumluluk (Compatibility): Yazılımın diğer sistemlerle veya eski sürümlerle sorunsuz bir şekilde etkileşim kurabilme yeteneği.

4.      Esneklik/Ölçeklenebilirlik (Scalability): Artan kullanıcı sayısına, veri hacmine veya iş yüküne cevap verebilmek için sistemin performansının kolayca artırılabilme yeteneği.

Heterojenlik, işteki sosyal hayattaki değişiklikler ve güven ve güvenlik problemlerinden başka, yazılım mühendisliğinin 21. yüzyılda karşılaşması beklenen diğer problemler ve güçlükler neler olabilir?

Sommerville, 21. yüzyıl yazılım mühendisliğinin temel zorlukları olarak Heterojenlik (farklı teknolojilerin entegrasyonu), Sosyal ve İş Değişiklikleri (hızlı adaptasyon ihtiyacı) ve Güven/Güvenlik sorunlarını belirtir. Bunlar dışında öne çıkan zorluklar şunlar olabilir:

1.      Büyük Veri (Big Data) ve Analitik: Büyük hacimli veriyi işleyebilen, analiz edebilen ve anlamlı çıkarımlar sunabilen yazılımların geliştirilmesi.

2.      Akıllı Sistemler ve Yapay Zeka (AI/ML): Öğrenen, tahmin eden ve otonom kararlar veren karmaşık sistemlerin gereksinimlerinin belirlenmesi, test edilmesi ve güvenilirliklerinin sağlanması.

3.      Sistemlerin Sürekli Evrimi: Yazılım sistemlerinin sürekli "hizmet olarak" sunulması (SaaS) ve kesintisiz, hızlı güncellemelerle evrim geçirmesi gerekliliği (DevOps kültürü).

4.      Kritik Sistemlerin Karmaşıklığı ve Güvenirliği: Hayati risk taşıyan sistemlerin (tıbbi cihazlar, otonom araçlar, endüstriyel kontrol) hatasız ve yüksek güvenilirlikle tasarlanması.

5.      Enerji Verimliliği ve Sürdürülebilirlik: Yazılım sistemlerinin artan enerji tüketimini azaltacak, çevre dostu (yeşil bilişim) çözümlerin geliştirilmesi.

6.      Uç Bilişim (Edge Computing) ve IoT: Milyarlarca küçük, dağıtık ve kısıtlı kaynaklara sahip cihazdan oluşan sistemlerin yönetimi ve güvenliği.

İyi mühendislik uygulamalarının omurgasını oluşturan ilkeler nelerdir?

• Süreç (Process): Bir geliştirme sürecinin (şelale, çevik, vb.) tanımlanması, geliştirmenin organize, disiplinli ve öngörülebilir bir şekilde ilerlemesini sağlar. Rastgele bir yaklaşım yerine sistematik bir yaklaşım benimsenir, bu da hataları azaltır.
• Güvenilirlik (Dependability/Reliability): Bir yazılımın hatasız çalışması ve kullanıcılarına güvenilir hizmet sunması, türü ne olursa olsun her sistem için temel bir beklentidir. Bir eğlence uygulamasının çökmesi sadece can sıkıcıyken, bir kontrol sisteminin çökmesi felaketle sonuçlanabilir. Bu ilke, tüm sistemlerde riski yönetmeye yarar.
• Gereksinim Yönetimi (Requirements Management): Ne geliştirildiğini ve müşteri/kullanıcı beklentilerini tanımlar. Gereksinimlerin doğru anlaşılması, izlenmesi ve yönetilmesi, hatalı veya kullanışsız bir ürün geliştirme riskini ortadan kaldırır. Bu, herhangi bir projenin başarısının anahtarıdır.
• Yeniden Kullanım (Reuse): Yeni yazılımların sıfırdan oluşturulması yerine, mevcut kanıtlanmış bileşenlerin veya kodların kullanılması anlamına gelir. Bu, geliştirme süresini azaltır, maliyeti düşürür ve zaten test edilmiş bileşenler kullanıldığı için güvenilirliği artırır.

Web'in evrensel kullanımının yazılım sistemlerini ve yazılım sistem mühendisliğini nasıl değiştirdiğini açıklayınız.

Web'in evrensel kullanımı (genellikle Web 2.0 ve sonrası), yazılım sistemlerinin ve mühendisliğinin doğasını kökten değiştirmiştir:

1.      Dağıtık Hesaplama (Distributed Computing) Standart Hale Geldi: Yazılımlar tek bir bilgisayarda çalışmak yerine, internet üzerinden birbirine bağlı birçok sunucu ve istemci (tarayıcı, mobil cihaz) üzerinde çalışır hale geldi. Bu, ağ ve güvenlik mühendisliğinin önemini artırdı.

2.      Hizmet Odaklı Mimari (SOA) ve Mikrohizmetler: Web, yazılımların hizmetler (API'lar) aracılığıyla iletişim kurmasına olanak sağladı. Bu, daha büyük sistemlerin küçük, bağımsız ve farklı teknolojilerle geliştirilmiş parçalardan (mikrohizmetler) oluşmasına yol açtı.

3.      Hızlı Yayın Döngüleri (Çevik/DevOps): Geleneksel uzun yayın döngüleri yerine, Web uygulamaları haftalarca, hatta günde birden fazla kez güncellenebilir hale geldi. Bu, Çevik (Agile) ve DevOps metodolojilerini standart hale getirdi.

4.      Kullanıcı Deneyimi (UX) Önceliği: Web uygulamalarında arayüz, işlevsellik kadar kritik hale geldi. Yazılım sistem mühendisliği, teknik gereksinimlerin yanı sıra kullanıcı etkileşimi ve arayüz tasarımına büyük önem vermeye başladı.

5.      Ölçeklenebilirlik Zorunluluğu: Milyonlarca kullanıcıya hizmet verebilme gerekliliği, yazılım tasarımında yatay ölçeklenebilirlik ve yük dengeleme gibi mimari yaklaşımları zorunlu kıldı.

Profesyonel mühendisliğin doktorlar ve avukatlar gibi lisanslanıp lisanslanmaması konusunu tartışınız.

Bu, yazılım mühendisliği alanında uzun süredir devam eden önemli bir etik tartışmadır.

Lisanslanmayı Destekleyen Argümanlar (Gereklilik):

1.      Halkın Güvenliği: Birçok yazılım sistemi (tıbbi cihazlar, uçak kontrol sistemleri, enerji santralleri) hayati risk taşır. Lisanslama, yazılım mühendislerinin minimum yeterlilik ve etik standartlarına sahip olmasını sağlayarak halkın güvenliğini korur.

2.      Profesyonel Standart: Lisanslama, yazılım mühendisliğini "yazılımcı" gibi daha geniş terimlerden ayırarak bir meslek olarak itibarını artırır ve sektörde bir minimum kalite standardı oluşturur.

3.      Hesap Verebilirlik: Lisanslı bir mühendis, mesleki hataları ve etik ihlalleri nedeniyle lisansını kaybetme riskiyle karşı karşıya kalır. Bu, daha fazla dikkat ve hesap verebilirlik sağlar.

Lisanslamaya Karşı Argümanlar (Zorluklar ve Gereksizlik):

1.      Alan Çok Hızlı Değişiyor: Yazılım teknolojileri ve araçları o kadar hızlı değişiyor ki, sabit bir sınav ve lisanslama sistemi, hızla güncelliğini yitirecek ve inovasyonu kısıtlayacaktır.

2.      Yazılımın Geniş Kapsamı: Birçok yazılım (eğlence uygulamaları, basit web siteleri) halkın güvenliği için risk taşımaz. Tek bir lisans, bu kadar geniş bir alanı kapsayacak şekilde nasıl tasarlanabilir?

3.      Kim Lisanslayacak?: Lisanslama otoritesini kimin oluşturacağı ve sürdüreceği (devlet, endüstri kuruluşu, vb.) büyük bir zorluktur.

4.      Yeterlilik Kanıtı: Doktorlar ve avukatlar gibi bir "ustalık" anı belirlemek zordur; deneyim ve sürekli öğrenme yazılımda daha önemlidir.

Terörizme karşı koymaya yardımcı olmak için birçok ülkede çok sayıda vatandaşın hareketlerini izleyen bilgisayar sistemleri geliştirdiği veya geliştirmeyi planlandığı tartışılıyor. Tabii ki bunun mahremiyete etkileri var. Bu tür bir sistemin geliştirilmesinde çalışmanın mahremiyete etkilerini tartışınız.

Bir terörle mücadele izleme sistemi üzerinde çalışmak, yazılım mühendisleri için etik bir ikilem yaratır: Ulusal güvenlik ve kamu yararı ile bireysel mahremiyet hakları arasındaki gerilimi yönetmek.

Mahremiyete Etkileri ve Mühendisin Sorumlulukları:

1.      Gözetim Altında Yaşam Korkusu: Sistemin varlığı bile, vatandaşların sürekli izlendiği hissini yaratarak ifade özgürlüğünü kısıtlayabilir ve toplumsal güveni zedeleyebilir.

2.      Yanlış Pozitifler ve Damgalama: Hatalı (yanlış pozitif) sonuçlar nedeniyle masum insanların terörist olarak yanlış etiketlenmesi ve haksız soruşturmalara maruz kalması riski.

3.      Verinin Kötüye Kullanımı: Sistemin, terörle mücadele dışındaki siyasi veya kişisel amaçlarla kötüye kullanılması riski. (Örn: Siyasi muhalifleri izlemek).

4.      Veri Güvenliği: Toplanan devasa hassas kişisel veri havuzunun siber saldırılar veya içeriden tehditlerle ihlal edilme riski.

Mühendisin Etik Sorumlulukları:

·         Veri Minimallendirme: Mühendis, sistemi tasarlarken sadece kesinlikle gerekli olan verinin toplanmasını (ve anonimleştirilmesini/kullanılmamasını) sağlamalıdır.

·         Şeffaflık ve Hesap Verebilirlik: Sistemin karar alma süreçlerinin şeffaf olması (kısmen) ve hata yapıldığında sorumluluk mekanizmalarının tanımlanmış olması için çalışmalıdır.

·         Sınırlı Amaç: Mühendis, yazılımın sadece belirtilen amaç (terörle mücadele) için kullanılmasını sağlayan teknik kısıtlamaların (erişim kontrolü, denetim kaydı) uygulanmasını savunmalıdır.

·         Bağımsızlık ve İtiraz: Mühendis, tasarımdaki bir özelliğin mahremiyeti gereksiz yere ihlal ettiğini veya etik olmadığını düşünüyorsa, bunu açıkça (ve uygun kanallardan) dile getirme ve hatta projeden çekilme hakkını kullanma sorumluluğuna sahiptir (1.9'daki "Yargı" maddesi).

Yazılım geliştirme sürecinin yayınlanmış ilk modeli hangisidir?

Waterfall

Waterfall Modeli nedir?

 Requirements definition (gereksinimlerin tanımlanması)

System and software design (sistem ve yazılım tasarımı)

Programming and unit testing (gerçekleştirme ve birim sınama)

Integration and system testing (bütünleştirme ve sistem sınama)

Operation and maintenance (işletim ve bakım)

UP Yayım döngüsü nedir?

flowchart TD
    A[Bir Yayım için Kullanıcı Öykülerini Seç] -->|Adım 1| B[Öyküleri Görevlere Böl]
    B -->|Adım 2| C[Yayımı Planla]
    C -->|Adım 3| D[Geliştir / Bütünleştir / Test Et]
    D -->|Adım 4| E[Yazılımı Yayımla]
    E -->|Adım 5| F[Sistemi Değerlendir]
    F -->|Adım 6| A
    

Bütünleşik Geliştirme Ortamının amacı nedir?

Bütünleşik Geliştirme Ortamının (IDE) amacı geliştiricilerin kod yazma, derleme, test etme ve hata ayıklama gibi görevleri daha verimli ve hızlı bir şekilde gerçekleştirmesini sağlamaktır.

Scrum modeline göre müşteriden ve son kullanıcıdan gelen gereksinimleri hangisi ifade eder?

Backlog

Otomotiv sektöründe, üretilen motorun birden fazla modelde kullanılması durumu yazılımda neyi karşılar?

yeniden kullanılabilirlik

Bilgisayar yazılım mühendisliği ... yılında NATO tarafından gerçekleştirilen bir konferans esnasında ortaya çıkarn yeni bir kavram ve yeni bir mühendislik alanı olarak ortaya çıkmıştır.

1968

ERP sistemlerinin öne çıkan en önemli özelliği nedir?

ERP sistemlerinin öne çıkan en önemli özelliği entegrasyondur.

Genel olarak ... denildiğinde bilgisayar donanımı, yazılım, veri kullanım yönetimi ve insanın oluşturduğu sistemlerden söz edilmektedir.

bilgi sistemi

Cleanroom'u kimler ortaya atmıştır?

Cleanroom’u 1980’lerde Mills, Dyer ve Linger ekibi ortaya attı.

SDLC nedir?

Yazılım Geliştirme Yaşam Döngüsü

Spiral modelini kim önermiştir?

Barry Boehm

ACM/IEEE Software Engineering Code of Ethics’in sekiz ilkesi nelerdir?

PUBLIC

CLIENT AND EMPLOYER

PRODUCT

JUDGMENT

MANAGEMENT

PROFESSION

COLLEAGUES

SELF

Takım modelleri nelerdir?

CC

CD

DD

Yazılım süreçlerinin dört temel etkinliği nelerdir?

Specification (Gereksinimler) → Design & Implementation (Geliştirme) → Validation → Evolution

Çevik manifesto ilkeleri nelerdir?

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 

CBSE nedir?

Bileşen Tabanlı Yazılım Mühendisliği

Fonksiyon noktasını kim önermiştir?

Allan J. Albrecht (IBM), yıl 1979.

Kodlama açısından en büyük dezavantaja sahip model hangisidir?

4GT

Cleanroom’da işlevler, ... yapıları ile tanımlanır.

kutu

SRS belgesiyle özdeşleştirilen belirtim türü hangisidir?

kara kutu

Gerçek kodlama SDLC’de ... aşamasında yapılır.

uygulama/geliştirme

SDLC nedir?

Yazılım geliştirme yaşam döngüsü

SRS nedir?

Yazılım gereksinimleri dokümanı

V&V nedir?

Verification and validation

SDLC adımları nelerdir?

analiz

tasarım

gerçekleştirim

test

teslimat

bakım

Yazılım yaşam döngüsünün çekirdek süreçlerinin sıralaması nasıldır?

planlama

çözümleme

tasarım

gerçekleştirim

COCOMO nedir?

Constructive cost model

COCOMO'yu kim önermiştir?

Barry Boehm

KLOC nedir?

bin satır kod

EK: YAZILIM TEST MÜHENDİSLİĞİ