Yazılım Yapılandırma Notları
Geliştiriciler için oldukça kapsamlı bir kaynak olan Code Complete kitabından giriş niteliğinde bazı notlar:
Bir yazılım oluştururken düzgün projelerde çalışmak, bize farklı bir bakış açısı sağlar, uygun olmayan işlerde çalışmak ise yazılım işini meydana getiren faaliyetler hakkında bize bazı yanlış bilgiler verebilir.
Aslında yaptığımız çoğu faaliyeti programcılık olarak tanımlayabiliriz ve yazılım genel olarak, kodlama ve hata ayıklama basamaklarından oluşur diyebiliriz. Bu kısmen doğru bir yaklaşımdır. Yazılım Yapılandırma kavramı ise meseleye daha geniş açıdan yaklaşır ve :
■ Problemleri belirleme
■ Geliştirme gereksinimleri
■ Yapılandırma planlaması
■ Yazılım mimarisi
■ Detaylı tasarım
■ Kodlama ve hata ayıklama
■ Birim (unit) testi
■ Entegrasyon testi ve entegrasyon
■ Sistem testi
■ Düzeltme ve bakım
gibi aşamalara odaklanır. Burada geliştirme (development) kelimesinin kullanılmamasının nedeni daha üst ve kapsamlı bir kavrama ulaşmak. O nedenle buna yapılandırma diyeceğiz. Biz bu yapılandırma (inşa etme) işi için her ne kadar kodlama ya da programlama kelimelerini kullansakta, yapılandırma sadece mekanik olan bir süreç değildir. Burada bolca yaratıcılık ve karar verme yeteneği gerektiren bütünsel bir iş yaklaşımından bahsediyoruz.
Bu sürece biraz daha detaylı yaklaşırsak ilgi alanımız dahilinde olacak olan konular:
■ İnşanın başarılı olması için bir altyapı çalışmasının yapıldığından emin olmak
■ Kodun nasıl test edileceğinin belirlenmesi
■ Sınıfların (class) ve rutinlerin tasarlanıp yazılması
■ Değişkenlerin oluşturulması ve adlandırılması, isimli sabitlerin oluşturulması
■ Kontrol yapılarının seçilmesi ve ifade bloklarının organizasyonu
■ Birim (unit) testi, entegrasyon testi ve kodunuzun hata ayıklamasının yapılması
■ Takım arkadaşlarınızın düşük-seviyeli tasarımlarının ve kodlamalarının gözden geçirilmesi
■ Diğer takım arkadaşlarınızın, sizin kodlamalarınızı gözden geçirmesi
■ Kodun dikkatli bir şekilde biçimlendirilerek ve değerlendirilerek düzeltilmesi
■ Birbirinden ayrı olarak oluşturulan yazılım parçalarının bir araya getirilmeleri
■ Kodun daha hızlı ve daha az kaynak kullanarak çalışması için ayarlanması
gibi konulardır.
Yukarıdaki öğelere ek olarak;
■ Yönetim
■ Geliştirme gereksinimleri
■ Yazılım mimarisi
■ Kullanıcı arayüzü tasarımı
■ Sistem testi
■ Düzeltme ve bakım
gibi konularda birincil olmasa da bir yazılımın başarıya ulaşmasında önemli bir yere sahiptir
Peki Yazılım yapılandırma neden önemli ?
Yazılım yapılandırma;
1 - Yazılım geliştirmenin büyük bir kısmını oluşturur.
2 - Yazılım geliştirmenin merkezi aktivitesidir.
3 - Yapılandırmaya odaklanarak, programcının üretkenliği arttırılabilir.
4 - Yapılandırmanın bir ürünü olan kaynak kodu, yazılımın en tutarlı açıklamasıdır.
5 - Yapılandırma, oluşturulacağının garantisi verilen tek aktivitedir.
İdeal bir yazılım projesi, yapılandırma başlamadan önce, detaylı bir geliştirme gereksinimi ve mimari tasarımı süreçlerinden geçer. Yapılandırmadan sonra ise detaylı ve istatistiki olarak konrollü olan sistem testlerinden geçmelidir.
Kusursuz olmayan yani gerçek hayattaki projeler ise genelde gereksinim ve tasarım kısımlarını atlayarak direk olarak inşa kısmına geçerler. Zamanları kalmadığı için testten dahi vazgeçerler çünkü düzeltmeleri gereken çok fazla hata vardır.
Bu nedenle bir proje ne kadar acemice planlanırsa planlansın ne kadar aceleye getirilirse getirilsin ana yapılandırma kısmından vazgeçilemez. Yapılandırmanın ilerlemesi yazılım geliştirmenin en önemli kısmıdır.
Kontrol Listesi: Gereksinimler
Kontrol Listesi, projenizin gereksinimleri ile ilgili kendinize soracağınız sorulardan oluşur. Bu liste size nasıl geliştirme yapacağınızı söylemez. Listeyi yapılandırma yaparken nasıl bir durumda olduğunuzu ve neye ihtiyaç duyduğunuzu belirlemek için kullanabilirsiniz. Maddelerin bazıları sizin projenize uygun olmayabilir. Resmi bir projede çalışmıyorsanız bazı konular hakkında düşünmenize bile gerek olmayabilir. Ancak kapsamlı bir projede tüm maddeleri gözden geçirmeniz gerekebilir.
Özel Fonksiyonel Gereksinimler (Specific Functional Requirements)
+Sisteme yapılacak olan tüm girdiler belirlendi mi?
(girdilerin kaynakları, tutarlılığı, değerlerin aralığı, ve seviyeleri )
+ Sistemden elde edilecek tüm çıktılar belirlendi mi?
(ulaşacakları yerler yönünden, format, değer aralığı, tutarlılık ve seviyeleri yönünden)
+Web sayfaları, raporlar ve buna benzer şeyler için bir çıktı formatı belirlendi mi?
+ Tüm dış donanımlar ve yazılım arayüzleri belirlendi mi?
+ Tüm dış iletişim arayüzleri belirlendi mi?
(el sıkışma, hata-kontrolü, iletişim protokolleri dahil olarak)
+ Kullanıcının yapılmasını istediği tüm görevler belirlendi mi?
+ Her görevde kullanılacak olan veri ve her görevin sonucunda oluşacak olan veri
belirlendi mi?
Fonksiyonel Olmayan Gereksinimler (Nonfunctional Quality Requirements)
+ Kullanıcının bakış açısına göre, tüm operasyonlar için beklenen cevap verme süreleri belirlendi mi?
+ İşleme zamanı, veri transfer oranı ve sistem çıktısı gibi diğer zamanlama kararları belirlendi mi?
+ Güvenlik seviyesi belirlendi mi?
+ Yazılıma olan güvenilirlik (sağlamlık açısından) belirlendi mi?
(yazılım hatalarının/çökmelerinin sonuçları, hatadan korunmak için gereken kritik önemdeki bilgiler ve hata denetleme, kurtarma stratejileride dahil olmak üzere)
+ Gerekecek olan minimum makine belleği ve boş disk alanı belirlendi mi?
+ Sistemin sürdürülebilirliği belirlendi mi?
(belirli işlevdeki değişikliklere adapte olma yetisi açısından, işletim ortamlarındaki değişimler ve diğer yazılımlarla ilgili olan arayüzlerdeki değişiklikler açısından)
+ Yazılımın, başarılı ve başarısız hallerinin bir tanımı yapıldı mı?
Gereksinimlerin Kalitesi (Requirements Quality)
+ Gereksinimler kullanıcıların anlayacağı şekilde mi yazıldı?
+ Bu konuda kullanıcılar da aynı fikirde mi?
+ Her bir gereksinim diğer gereksinimler ile çatışmadan kaçınıyor mu?
+ Birbiriyle rekabet eden özellikler arasındaki alış-veriş belirlendi mi?
(örneğin sağlamlık ve doğruluk arasındaki değiş-tokuş)
+ Gereksinimler, tasarımı belirlemekten kaçınıyorlar mı?
+ Gereksinimler, uygun derecede bir detay seviyesinde mi?
+ Herhangi bir gereksinim daha detaylı bir şekilde belirlenmeli mi?
+ Herhangi bir gereksinim daha az detaylı bir şekilde belirlenmeli mi?
+ Gereksinimler, değiştirilip başka bir yapılandırma grubuna verilebilecek kadar yeterince açık ve anlaşılır mı?
+ Geliştiriciler bu konuda sizle aynı fikirde mi?
+ Her öğe/eleman, kendi problemi ve çözümü ile alakalı mı?
+ Her öğe, problem ortamındaki doğuş kaynağına kadar, takip edilebiliyor mu?
+ Her gereksinim test edilebilir mi?
+ Her gereksinimi karşılamak için bağımsız olarak test etmek mümkün mü?
+ Gereksinimlere yapılması mümkün olan tüm değişiklikler belirlendi mi?
(Her bir değişim ihtimalini içerecek şekilde )
Gereksinimlerin Bütünlüğü (Requirements Completeness)
+Geliştirme süreci başlamadan önce, bilginin mevcut olmadığı durumlarda, tamamlanmamış/eksik olan alanlar belirlendi mi?
+ Gereksinimler, ürünün her gereksinimi karşılayacağı ve kabul edilir olabileceği bir anlamda tam mı?
+ Tüm gereksinimler konusunda rahat mısınız? Uygulanması mümkün olmayan gereksinimleri elediniz mi? Ya da sadece patronunuzu/müşterinizi yatıştırmak için mi dahil ettiniz ?
Asıl kaynak:
