Bileşen Temelli Yazılım Sistemleri Geliştirmek-3

Bu serideki önceki yazılarımızda, tüm yazılım bileşenlerimizi kendi imkanlarımız ile geliştirme eğiliminden çıkılması gerektiğini ve hazır bileşenlerin (Ticari, Açık Kaynak) değerlendirilmesi gerektiğini belirtmiştik.

Bu bileşen kümesinin birlikte çalışabilmesi için, yazılım sistemimizin mimarisi açısından nasıl bir yöntem izlemeliyiz?
Tüm yazılım bileşenlerimizin dışarıdan temin edildiği durumu düşünelim. Bileşenlerin birbiri ile etkileşimi için gerekli tanımları ve ortak ihtiyaçlarımızı nasıl yöneteceğiz?
Bunun için, temel bir taşıyıcı alt yapıya ihtiyacımız var. (Foundation -> Framework -> Platform)
Bilgisayar dünyasından örneklemek gerekirse; Bilgisayar Kasası ve Ana kart, farklı seviyelerde taşıyıcı alt yapılardır.
Sadece bilgisayar kasası ve/veya ana kart üretip, tüm bileşenlerini dışarıdan temin eden markalar var.

Bizde, bu yaklaşımı takip edebiliriz. Öncelikli, temel alt yapımız ve asıl işimiz ile ilgili bileşenlerimizi hedeflemeliyiz. Ürünümüzü çıkarmalıyız.
Daha sonraki süreçte daha geniş imkanlarımız olduğunda, dışarıdan aldığımız diğer bileşenlerimizi de geliştirilebiliriz.

Bileşen Temelli Yazılım Sistemleri Geliştirmek-2

Yazılım sistemleri geliştirirken, hazır bileşen (Ticari,Açık Kaynak) kullanımında nasıl bir yaklaşım takip etmeliyiz?
Öncelikli işimiz, bize verilen işi zamanında ve planlanan kaynaklarla tamamlamaya çalışmaktır. Çoğu zaman kaynak planlamasında yaşanan sıkıntılar (Software Estimation), gereksinimlerin iyi belirlenememiş olması veya yeterli olmayan kaynaklar sebebiyle, en önemli aksaklıklar yaşanmaktadır. Bunlar aynı zamanda, proje yönetimi açısından riskleri ifade etmektedir.

Riskleri düşürebilmek ve kaynaklarımızı asıl işimize yoğunlaştırabilmek açısından, hazır bileşen kullanımı değerlendirilmelidir. Şunu unutmayalım ki, aynı problemleri başkaları da yaşıyor. Problemler genele doğru gittikçe, bulunabilecek çözümlerin sayısı artıyor. Bu çözümleri, projemizin bir parçası olarak görebilmeliyiz. Hatta birlikte çalıştığımız proje ekiplerimiz olarak adlandırabiliriz.

Biz de, en genel ihtiyaçlarımızdan başlayarak özele (asıl iş alanımıza) doğru, bir özellik değerlendirmesi yapabilir ve proje kaynaklarımız nispetinde bir denge takip edebiliriz.
Sonraki yazıda ise, özel ve genel bileşenlerin, yazılım mimarisi açısından nasıl bir yöntemle geliştirilebileceği konusunda bilgi paylaşacağım.

Bileşen Temelli yazılım Sistemleri Geliştirmek-1

Yazılım Sistem tasarımının en önemli stretejilerinden birisi, alt sistemlere ayrıştırmaktır. (Subsystem Decomposition, Modularity)
Yani, büyük sistemi birbiri ile etkileşimde olan daha küçük sistemler olarak ele alabilmeliyiz.
Her alt sistem, hizmet aldığı diğer sistemler ile standartlar üzerinden haberleşir.

Tasarım stratejileri içinde yer alan diğer önemli bir soru ise ; “Yazılım bileşenlerimiz temini için, nasıl bir yol izleyeceğiz? “Geliştirmek, Satın almak, Açık kaynak kodlu bileşenler kullanmak”

Kısıtlı proje kaynakları ile, teknik ve iş alanına bağlı gereksinimleri yönetmek zor. Tüm bileşenlerimizi kendimiz geliştirelim eğiliminden çıkılması gerekiyor.

İş ihtiyaçlarımızı güncel olarak karşılayacak bileşenleri (Ticari, Açık Kaynak) değerlendirmeliyiz.

Peki bu geliştirme dengesini nasıl sağlayacağız ? Nasıl bir yaklaşım takip etmeliyiz? sorularına sonraki yazılarda cevap vereceğiz.

Yazılım alt yapı bileşenleri (Framework) geliştirmek üzerine – 2

Başlangıç olarak; ilk etapta açmamız gereken projelerimizi (Framework.Main, Framework.Common, Framework.Mail) açalım. Metodumuzu, ilgili bileşenimize koyalım. Framework üzerinden Eposta bileşenimizi hazır hale getirelim.

Şu an için, sadece mail atan bir framework bileşenine sahibiz. Yeni ihtiyaçlarımız geldiğinde; yine bir yardımcı metot. Eğer yoksa, metoda ait bir yeni bir bileşen projesi. Bu bileşenin Framework ile entegrasyonu.

İhtiyaçlarımızı ne kadar üst seviye modelleme imkanına sahip olursak, yeniden düzenleme de o kadar az olacaktır. (Refactoring)

Projelerimizdeki “Utility – Yardımcı” metotlarımızı, bu şekilde framework projesine çevirebilir. Framework proje yönetimi ile ilgili temel kısıtlardan kurtulabiliriz.

Sonraki proje de ise, hazır olan bir çok işlevimiz olacaktır. Bundan sonrasını, yöneticilerimize daha kolay anlatabiliriz.

Yazılım alt yapı bileşenleri (Framework) geliştirmek üzerine – 1

Birbirine yakın özellikleri olan yazılımların, ortak ihtiyaçları da aynıdır. Bu ortak ihtiyaçların, bir framework projesi olarak ele alınması, asıl iş ihtiyaçlarından bağımsız olarak geliştirilmesi mümkün olabilir.

Burada en önemli kısıt, böyle bir proje için bütçe oluşturabilmek ve kurumumuzun yazılım geliştirme vizyonuna yerleştirebilmektir. Çoğu zaman, bunu yöneticilerimize anlatabilmemiz bile zor olabilir. (“No Time, No Money” Yazılım Mühendisliği literatürüne de girmiş durumdadır.)

İmkanların çok kısıtlı olduğu durumlarda bile, framework projesi modelleyebilirsiniz. Tekrar kullanılabilirlik hakkında yazdığım daha önceki yazılarımda ifade ettiğim gibi, en küçük birim metotdur. EPosta gönderen bir metot yazdığınızı düşünelim. Bu metot aslında, Framework projemizin, Eposta bileşenin bir metodu olmalıdır.