Yazılım Projesine Başlarken İlk 9 Adım

Bir yazılım projesi ihtiyaç analizi ve tanımı ile başlar. Bir yazılım projesine başlarken önce neye ihtiyacımız olduğunu belirleriz. Bazı temel işlem ve işlevleri tamamlayarak bütünü görmeye çalışırız. Bir Word belgesinde ya da bir Evernote not defterinde yazılım ile ilgili tüm detayları doküman haline getiririz. Bundan sonraki adım ise yazılımın olabildiğince hızlı bir şekilde iskeletinin oluşturulmasıdır. Yani ortaya bir prototip konmasıdır. Bunu yazılım ekibinin Senior olarak tabir edeceğiniz geliştiricisi yapabilir. İskelet ortaya çıktıktan sonra artık tüm ekip yazılımı geliştirmeye ve parçaları, modülleri kodlamaya başlar.

İskelet oluşturma bölümü yazılım projesinin başlangıcı ve bitişi açısından önemlidir. Bu nedenle bu başlangıç kısmını dokuz adımda özetleyeceğiz.

Öncelikle daha açıklayıcı olması açısından birkaç örnek verelim. Şimdi beni bir yazılım mimari olarak düşünün ve projemizin adı da “Evernote Killer” olsun. Yani projemiz yeni bir verimlilik ve not alma, organize etme uygulaması oluşturmak. Prototip için öncelikle bir ihtiyaç analizi yapmalıyız. Ne özellikler olacak, not alma işlem adımları ne olacak, uygulamanın mobil ile bağlantısı, sosyal ağlar ile ilişkisi, paylaşım yapısı… vs.

Evet, ihtiyaç analizini tamamladık. Proje yapılabilir duruyor. Ancak rakip Evernote olduğundan şu an için onun kadar işlevsel ve performanslı durmuyor. Bu yüzden projemizin Evernote kadar işlevsel ve kullanım kolaylığı sunması gerekiyor.

Bu yazıda teknik olarak bir projenin hangi dil ile, veritabanı vs. ile yazılması gerektiği gibi konulara girmeyeceğiz. Başka bir yazının konusu olabilir.

Şimdi bir başlangıç yaptık. Adımlarımız neler bakalım…

Kararlar ve Alternatifler

Her şeyden önce iyi bir dökümantasyon yapmalıyız. Bunun için bir versiyon kontrol sistemi kullanılmalıdır. Yani Git. Ekip olarak yazılım geliştirirken Github, Bitbucket ya da Gitlab kullanabilirsiniz. Ücretsiz sürümünde sunduğu özellikler ve kullanım kolaylığı açısından Gitlab bizim işimizi görüyor. Dökümantasyon için projenizin ana klasöründe README.md dosyası bulunur. Bu dosya içinde metinler Markdown formatında (başka bir yazıda Markdown’a detaylıca gireceğiz.) kaydedilir. Kısa olması önemlidir. Tüm dökümantasyon işlemi proje için alınan kararların belgelenmesi içindir. Ve tüm kararları yazarken her karar için birer alternatif daha yazmayı unutmamalıyız.

Örneğin benim iki kararım var:

1. Windows platformu için :  .Net Framework ve WPF GUI Framework kullanacağım.
   Alternatifler : Java ve XAML olabilir.
2. Programlama dili olarak C# kullanacağım.
   Alternatif: Java 7 olabilir.

Bu kararlar başlangıçta alınan büyük kararlardır. Ancak yine de bunları belgelemek gerekir. Alternatifleri de kararların hemen altında belirttik. Kararlar ekip tarafından sorgulandığında alternatiflerin analizler sonucu istenilen verimlilikte olmayacağını belirtip, kararın bu yönde alındığını söyleyebiliriz. Bu iki kararı belgelediğim için ve kararları aldığım için tam sorumluluk almış oldum. Karar alma ve belgelendirme alışkanlığı edindiğimizde ileride doğabilecek hatanın sorumlusu tartışmasız belli olacaktır.

Kararlar belgelenirken bir yerde en fazla 12 kararı belgelemeniz ve dahası için farklı alternatiflere yönelmeniz iyi olacaktır. [

Örneğin: Java için JavaDoc iyi bir alternatiftir. PHP için bu Apigen olabilir.

Endişeler, kaygılar..

README.md dosyasını kullanırken açıklamalar konusunda dikkatli olmalıyız. Endişeler derken demek istediğim projeye başlamadan önce ya da başladıktan sonra oluşabilecek sorunlar, problemler vs. dir. Dolayısıyla aslında ilk endişemiz README.md dosyasına girilen açıklamaların doğru şekilde, anlaşılır girilmesidir. Örneğin: “Bizim yapacağımız yazılımın Evernote kadar kullanışlı olması gerekiyor.” Şeklinde bir açıklama gereksiz olacaktır.

Burada bizim endişelerimiz gerçekçi olarak Performans ve Ölçeklenebilirlik olabilir.

Bu iki endişe detaylı olarak ele alınmalıdır. Yukardaki ilk maddede kararlar ve alternatiflerde programlama dili ve kütüphane seçimi vardı. Bu gibi kararlar bu aşamada tekrar gözden geçirilebilir.

Bu yüzden endişeleri giderici açıklama satırları oluşturmak gerekir. Alınan kararları destekleyici nitelikte olmalıdır.

Açıklama satırları ve yorumlar dürüstçe oluşturulmalıdır. 🙂

Varsayımlar

Yeterince somut bilginin olmadığı durumlarda varsayımlara başvurabiliriz. Bunun amacı prototip üzerinde çalışırken boşlukları doldurmaktır. Varsayımlar programlama dilinin  yeterliliği, kütüphanenin yeterliliği, sosyal platformlar tarafından bir engel çıkabileceğinin varsayımı gibi tahminler olabilir.

Riskler

Bu adımda tüm olası sorunları listeliyoruz. Bu sorunların olası etkilerini tahmin etmeye çalışıyoruz.

Örneğin:

1. Java programlama dilinin dökümantasyon yetersizliği ya da dökümantasyonun çok anlaşılır olmaması. [6×9]
2. Sosyal platformlar tarafında oluşabilecek engeller (Login, Register vs.) [8×9]

Köşeli parantez içindeki ilk sayı olasılık ve ikinci sayı 0-9 arasındaki etki ölçeğini tanımlıyor. Eğer her iki sayı 9 ise bu bir risk değil bir gerçek olduğu anlamına gelir. Eğer her iki sayı 0 ise, bu durumu görmezden gelebilirsiniz.

Şu an sadece iki risk yazdık. Ancak normalde 4 ile 12 arasında risk belirlenmesi önemlidir. Bu sayede prototip daha iyi bir şekilde ortaya çıkacaktır.

Sürekli Entegrasyon (Continuous Integration – CI)

Sürekli entegrasyon kodlar üzerinde yapılan her değişiklikten sonra tüm yazılımın çalışır durumda olup olmadığının kontrolüdür. Yazılımın farklı yerlerinden bozulmalara neden olup olmadığını tespit etmek için kullanılan yöntemdir. Sürekli entegrasyon yapabilmek için :

• Projeyi bir sürüm kontrol sistemi ile yürütüyor olmak (Github, Gitlab vs.)
• Projeyi test ederek geliştirmek
• Ve bir “Continuous Integration” aracı (tool) kullanmak

Popüler Araçlar :

• Bamboo
• Jenkins
• Travis CI
• PHPCI

Daha detaylı bir liste istiyorsanız: https://en.wikipedia.org/wiki/Continuous_integration#Software

Statik Analiz

Herhangi bir yazılım projesinin bir başka önemli bileşenidir. Statik kod kalitesini analiz etmek gerekir. Statik kod analizi sistemi çalıştırmadan hatalarını bulmak ve kodlama kurallarına, standartlarına uygunluğunu test etmek için kullanılan yöntemlerdir.

Neredeyse tüm programlama dilleri için birçok statik kod analiz aracı bulunmaktadır. Manuel analiz yerine araç kullanmanız daha iyi olacaktır.

Code Coverage

Yazılım test sürecinde temel faktörlerden biridir. Kodun ne kadarının test edildiğini gösterir.  Test kapsamı tüm inşaası yapılan modülleri içine almalıdır. Düşük bir test kapsamı başarısız bir sonuç ortaya çıkaracaktır. Ve tam anlamıyla test gerçekleştirilmemiş olacaktır.

Kurulum Paketi Oluşturulması

Bu adımda yazılımı bir ürün haline getiriyoruz. Yani tek tıkla kurulum işlemleri başlayacak bir yapıya getirmeliyiz.

Bunun için işlem adımlarını Java’dan örnekleyecek olursak :

• JAR dosyası oluşturulması
• JAR dosyasının paketlenmesi
• JAR dosyasının repo’ya yüklenmesi
• JavaDoc oluşturulması
• JavaDoc’un buluta yüklenmesi.

Sunum ve Kabul

Projenin ekibe, proje yöneticisine ve sponsora sunulması aşamasıdır. Aslında projenin kabul aşamasıdır. Bu adımda tüm aktörler tarafından proje kabul görmelidir.

Aslında bana kalırsa amaç patronu ya da yöneticiyi mutlu etmek değildir. Alınan kararlara, risklere ve varsayımlara göre olabilecek en mükemmel prototipi ortaya çıkarmaktır.

Eğer proje başarısız olursa Yazılım Mimarınızla özel bir görüşme yapmalısınız 🙂

Yazıyı faydalı bulduysanız, paylaşarak destek olabilirsiniz… Görüşmek üzere.