Bilgisayar Sistemleri; donanım, yazılım ve kullanıcılardan oluşur. Yazılım sadece belirli bir işlemi yapan bir program değildir. Yazılım belirli bir mantık dahilinde insanlar tarafından oluşturulan program, veri ve belgeler topluluğudur.
Her tür yazılım mutlaka bir veri üzerinde çalışmak durumundadır. Veri dış ortamdan alınabileceği gibi, yazılım içerisinde de üretilebilir. Yazılımın temel amacı veri yi belirli algoritmalar kullanarak bilgi ye dönüştürmektir.
Yazılımın ana çıktısı sonuçta bir bilgisayar programıdır. Program işletime alındıktan sonra bakım çalışmaları sürekli olarak gündeme gelir. Bunun iki temel nedeni: hiç bir program bütünüyle her olasılık göz önüne alınarak test edilemez. işletmeler doğaları gereği dinamik bir yapıya sahiptir ve zaman içerisinde sürekli olarak yeni istek ve gereksinimler ortaya çıkabilmektedir.
Yazılım üretimi bir mühendislik disiplini gerektirir. Mühendislik çalışmalarında izlenen yol ve kullanılan yaklaşımlar yazılım üretimi için de geçerlidir. Yazılım üretimi sırasında, bir çok aşamada (planlama, analiz, tasarım, gerçekleştirim, vb.) yapılan ara üretimlere ait bilgiler belli bir düzende belgelenmelidirler.
IEEE (The Institute of Electrical and Electronics Engineers) Tanımı (1993) Yazılım Mühendisliği: Sistemli, düzenli, ölçülebilir bir yaklaşımın yazılım geliştirmede, yazılımın işlenilmesinde ve bakımında uygulanmasıdır. Diğer bir deyişle mühendisliğin yazılıma uygulanmasıdır.
Yazılım mühendisliği bir yöntemler, teknikler ve araçlar kümesi olarak değerlendirilebilir. Yazılım mühendisliğinin hedefi; yazılım üretimindeki karmaşıklıkları gidermektir. Geçmişte kullanılan iş akış şemaları gibi yöntemler günümüzde yetersiz kalmaktadır. Ayrıca, yazılım üretimi işi tek kişinin başarabileceği boyuttan çıkmış ve bir takım işi biçimine dönüşmüştür.
Yazılımın daha çok mantıksal boyutuyla ilgilenir ve işi insanlarla ilişkiyi gerektirir. Temel hedefi; üretimin en az maliyet ve en yüksek nitelikte yapılmasını sağlamaktır. Programcı değildir. Ancak programcının tüm yeteneklerine sahiptir. Sistem analisti de değildir. Farkı; analist sadece sistemin analiz aşaması ile ilgilenirken, yazılım mühendisi tüm aşamaların içindedir.
Üretim Süreci Boyunca ara ürünlere ilişkin kalite standartlarının geliştirilmesi ve geliştirme işlemlerinin bu standartlara uygunluğunun denetlenmesidir. Yazılım kalite sağlama etkinlikleriyle; Yazılım maliyetleri düşürülür, Yazılım üretiminin yönetimi kolaylaşır, Belgeleme ve standart sorunları giderilir.
Herhangi bir yazılımın, üretim aşaması ve kullanım aşaması birlikte olmak üzere geçirdiği tüm aşamalar olarak tanımlanır. Yazılım işlevleri ve ihtiyaçlar sürekli değiştiği ve geliştiği için bir döngü biçiminde düşünülür. Yazılım yaşam döngüleri tek yönlü, doğrusal olarak düşünülmemelidir.
1. Planlama Personel ve donanım gereksinimlerinin çıkarıldığı, fizibilite çalışmasının yapıldığı ve proje planının oluşturulduğu aşamadır. 2. Analiz Sistem gereksinimlerinin ve işlevlerinin ayrıntılı olarak çıkarıldığı aşama. Var olan işler incelenir, temel sorunlar ortaya çıkarılır. 3. Tasarım Belirlenen gereksinimlere yanıt verecek yazılım sisteminin temel yapısının oluşturulduğu aşamadır. mantıksal; önerilen sistemin yapısı anlatılır (akış şemaları) fiziksel; yazılımı içeren bileşenler ve bunların ayrıntıları (ekran tasarımları)
4. Gerçekleştirim Kodlama, test etme ve kurulum çalışmalarının yapıldığı aşamadır. 5. Bakım Hata giderme ve yeni eklentiler yapma aşaması (teslimden sonra).
Herhangi bir kuraldan bağımsız, yalnızca geliştiren kişiye bağımlı hatta onun bile bir zaman sonra anlayamadığı ve değiştirme zorluğu yaşadığı modeldir. 60 lı yıllarda tek kişinin ürettiği programlar böyledir. Basit öğrenci projeleri böyledir.
İnceleme Analiz Tasarım Kodlama Modül Testleri Altsistem Testleri Sistem Testi Belgeleme Kurulum Yaşam döngüsü temel adımlarının doğrusal bir şekilde geliştirildiği model. 70 li yıllarda kullanılan model. Belgelemeyi ayrı bir süreç olarak ele alır, ve yazılımın geliştirilmesi ve testinden hemen sonra yapılmasının öngörür. Halbuki, günümüzde belgeleme yapılan işin doğal bir ürünü olarak görülmektedir. Aşamalar arası geri dönüşlerin nasıl yapılacağı tanımlı değil. Gerçekleştirim aşamasına daha fazla ağırlık veren bir model olup, günümüzde kullanımı önerilmemektedir
Gereksinimlerin Tanımlanması Sistem ve Yazılım Tasarımı Kodlama ve Modül test etme Birleştirme ve Sistemi test etme Sistemin Bakım ve İdamesi
Yaşam döngüsü temel adımları baştan sona en az bir kez izlenerek gerçekleştirilir. 70 li yılların ortalarında yapısal programlama ile kullanılmaya başlanan bu modelin kullanımı günümüzde azalmıştır. Belgeleme üretimin doğal bir sürecidir. İyi tanımlı projeler ve üretimi az zaman gerektiren projeler için uygundur. Belirsizlik oranı düşükse ve az zaman alacağı öngörülüyorsa (küçük boyutlu kamu sistemleri,personel,bütçe vb.) kullanımı önerilir.
Gereksinimler Sistem Sistem Tanımları KULLANICI MODELİ Bitmiş Sistem Sistem MİMARİ MODEL Sınanmış Sistem Altsistem Sınanmış Altsistem Modül Sınanmış Modül GERÇEKLEŞTİRİM MODELİ
Sol taraf üretim, sağ taraf sınama işlemleridir. V süreç modelinin temel çıktıları; Kullanıcı Modeli: Geliştirme sürecinin kullanıcı ile olan ilişkileri tanımlanmakta ve sistemin nasıl kabul edileceğine ilişkin sınama belirtimleri ve planları ortaya çıkarılmaktadır. Mimari Model: Sistem tasarımı ve oluşacak alt-sistem ile tüm sistemin sınama işlemlerine ilişkin işlevler. Gerçekleştirim Modeli: Yazılım modüllerinin kodlanması ve sınanmasına ilişkin fonksiyonlar.
Belirsizliklerin az, iş tanımlarının belirgin olduğu BT projeleri için uygun bir modeldir. Model, kullanıcının projeye katkısını arttırmaktadır.
Planlama Amaca, Alternatiflere ve Sınırlamalara karar verme onay ekseni Bir sonraki fazın planlanması ve kullanıcı değerlendirmesi Kullanıcı Değerlendirme Öninceleme Analizi Geliştirme Planı Birleştirme ve Test Planı Risk Analizi Risk Analizi Risk Analizi Prototip 1 Risk Analizi Prototip 2 Prototip 3 İşin Prototipi İşin Simulasyon ve Modelleme Genel Kavramı Yazılım GereksinimiÜrün Detaylı Gereksinim Tasarımı Tasarım onaylama Kodlama Tasarımı test Etme ve onay Servis testi Kabul testi Modül Testi Birleştirme Risk Analizi Alternatifleri değerlendirme ve risk analizi Geliştirme ve bir sonraki ürünü onaylama Üretim
Risk Analizi Olgusu ön plana çıkmıştır. Her döngü bir fazı ifade eder. Doğrudan tanımlama, tasarım,... vs gibi bir faz yoktur. Yinelemeli artımsal bir yaklaşım vardır. Prototip yaklaşımı vardır.
Eşzamanlı Aktiviteler Tanımlama İlk Sürüm Genel Tanımlama Geliştirme Ara Sürümler Test Etme Son Sürüm
İlk tam ölçekli modeldir. Coğrafik olarak geniş alana yayılmış, çok birimli organizasyonlar için önerilmektedir (banka uygulamaları). Her aşamada üretilen ürünler, üretildikleri alan için tam işlevselliği içermektedirler. Pilot uygulama kullan, test et, güncelle diğer birimlere taşı. Modelin başarısı ilk evrimin başarısına bağımlıdır.
Çok birimli banka uygulamaları. Önce sistem geliştirilir ve Şube-1 e yüklenir. Daha sonra aksaklıklar giderilerek geliştirilen sistem Şube-2 ye yüklenir. Daha sonra geliştirilen sistem Şube-3 e,. yüklenir. Belirli aralıklarla eski şubelerde de güncellemeler yapılır.
Üretilen her yazılım sürümü birbirini kapsayacak ve giderek artan sayıda işlev içerecek şekilde geliştirilir. Öğrencilerin bir dönem boyunca geliştirmeleri gereken bir programlama ödevinin 2 haftada bir gelişiminin izlenmesi (bitirme tezleri). Uzun zaman alabilecek ve sistemin eksik işlevlikle çalışabileceği türdeki projeler bu modele uygun olabilir. Bir taraftan kullanım, diğer taraftan üretim yapılır
Genel Gereksinim Belirlenmesi Gereksinimleri Artırımlara Bölme Sistem Mimarisini Tanımlama Sistem Artırılımının Yapılması Artırılımın Onaylanması Artırılımın Birleştirilmesi Sistemin Onaylanması Son Sistem Bitmemiş Sistem
Metodoloji: Bir BT(Bilgisayar Teknoloji) projesi ya da yazılım yaşam döngüsü aşamaları boyunca kullanılacak ve birbirleriyle uyumlu yöntemler bütünü. Günümüzdeki metodolojiler genelde Çağlayan ya da Helezonik modeli temel almaktadır
Konfigürasyon yönetim modeli Maliyet yönetim modeli Kalite yönetim modeli Risk yönetim modeli Proje yönetim modeli Değişiklik yönetim modeli Kullanıcı arayüz ve ilişki modeli Standartlar Ayrıntılandırılmış bir süreç modeli Ayrıntılı süreç tanımları İyi tanımlı üretim yöntemleri Süreçlerarası arayüz tanımları Ayrıntılı girdi tanımları Ayrıntılı çıktı tanımları
Testin en belirgin amacı, yazılımın uygunluğu ile ilgili karar vermektir. Yazılımı yayıma uygunluğu, standartlara uygunluğu, kabul şartnamesine uygunluğu gibi konular test aktiviteleri ile belirlenir.
Doğrulama Doğru ürünü mü üretiyoruz? ürünü kullanacak kişilerin isteklerinin karşılanıp karşılanmadığı Geçerleme Ürünü doğru olarak mı üretiyoruz? ü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.
Sınama Yöntemleri hedef açısından şu şekilde gruplandırılır. Birim sınama Alt sistem sınama Sistem sınaması Kabul sınaması
Birim sınama Modül sınama Alt Sistem sınama Sistem sınama Bileşen sınama Bütünleştirme sınaması Teslim alma sınaması Kesin Kabul Testi
Birim Sınama: Bağlı oldukları diğer sistem unsurlarından tümüyle soyutlanmış olarak, birimlerin doğru çalışıp çalışmadıklarının belirlenmesi amacıyla yapılır. Alt Sistem Sınama: Alt-sistemler modüllerin bütünleştirilmeleri ile ortaya çıkarlar. Yine bağımsız olarak sınamaları yapılmalıdır. Bu aşamada en çok hata ara yüzlerde bulunmaktadır.
Sistem Sınaması: Üst düzeyde, bileşenlerin sistem ile olan etkileşiminde çıkacak hatalar aranmaktadır. Ayrıca, belirtilen ihtiyaçların doğru yorumlanıp yorumlanmadıkları da sınanmalıdır.
Kabul Sınaması: Çalıştırılmadan önce sistemin son sınamasıdır. Artık, yapay veriler yerine gerçek veriler kullanılır. Alfa Sınamada; sistemin geliştirildiği yerde kullanıcıların gelerek katkıda bulunması sistemi test etmesi amaçlanmaktadır. Beta Sınamasında; kullanıcı, geliştirilen sistemi kendi yerleşkesinde, bir gözetmen esliğinde yapar.
Yazılım testleri sistem bilgisine göre de iki şekilde test edilir. Bir yazılım uzmanı sistemini bu iki testten geçirmelidir. Kara kutu testi (Black-Box Testing): Sistemin tümüne yönelik işlevlerin doğru yürütüldüğünün testidir. Sistem şartnamesinin gerekleri incelenir. Beyaz kutu testi (White-Box Testing): İç işlemlerin belirtimlere uygun olarak yürütüldüğünün bileşenler tabanında sınanmasıdır.
Yazılım geliştirme faaliyeti, bir veya birkaç ekip tarafından yürütülmektedir. Bir ekibin yapısı; projenin ve üretilecek yazılımın özelliklerine, ekibi oluşturan üyelerin karakterlerine ve yeteneklerine uygun olarak kurulmalıdır. Genel olarak ekip yapısı: demokratik, şef, hiyerarşik biçimlerde olabilmektedir
Bütün üyeler eşit olup, aynı yetkiye sahiptirler. Yazılım geliştirme amaçlarının ve yöntemlerinin saptanması, gerekli kararların alınması anlaşma yoluyla sağlanmaktadır. Ekip başkanlığı, sıra ile ve dönemsel olarak yürütülmektedir.
Ürünün tasarımı, geliştirilmesi ve diğer teknik konularda kararlar şef tarafından alınmaktadır. Görev dağıtımını da şef yapmaktadır. 2-5 kişiden oluşan üyeler de kodlama, hataları izleme ve düzeltme, belgeleri hazırlama, ürünü sınama vb. rutin işleri üstlenirler. Ekipte ayrıca bir arşivci ve şef yardımcısı bulunabilmektedir
Şef sisteminde kararlar bir kişi tarafından alındığı için işler daha hızlı yürütülmektedir. Ancak kararların doğruluğu ve tutarlılığı, şefin yeteneğine bağlı olmaktadır.
Bir proje yöneticisine bağlı birkaç ekip oluşturulmaktadır. Ekipte 2-5 genç üye ve başlarında deneyimli bir şef bulunmaktadır. Proje yöneticisi; görevleri belirlemekte, çalışmaları izlemekte ve denetlemekte, sorun alanlarını bulmakta, iş yüklerini dengelemekte ve teknik çalışmalara katılmaktadır. Ekip şefleri, kendilerine ayrılan alt sistem veya modülün geliştirilmesinden sorumlu bulunmaktadır.
Bu sistemde hiyerarşik olarak şeflik sistemi, yatay yönde de demokratik sistem uygulanmaktadır.
Hiyerarşik sistem, yazılım ürünlerinin hiyerarşik yapıda alt programlara ayrılabilmesi halinde uygulanan bir yöntemdir. Böylece, her ekip bağımsız olarak bir alt program üzerinde çalışmaktadır. Bu sistemin sakıncası, teknik konularda çok başarılı fakat yönetim bakımından yeteneksiz kişilerin de şef ya da proje yöneticisi olabilmesidir.