Yazılım Geliştirme Süreci Nasıl İşler?

Yazılım geliştirme süreci nedir?

Yazılım geliştirme süreci, bir fikrin ya da iş ihtiyacının çalışan bir yazılıma dönüşmesi için izlenen aşamaların bütünüdür; literatürde yazılım geliştirme yaşam döngüsü (SDLC) olarak da geçer. İster bir web paneli, ister mobil uygulama, ister şirket içi bir otomasyon olsun, iyi yönetilen projeler benzer aşamalardan geçer: analiz, planlama, tasarım, geliştirme, test, yayın ve bakım.

Bu rehber, yazılım yaptırmayı düşünen bir işletmenin her aşamada neyle karşılaşacağını, kendisinden ne beklendiğini ve nelere dikkat etmesi gerektiğini anlatıyor.

Yazılım geliştirme aşamaları

Şelale mi, çevik mi?

Yazılım projeleri iki temel yaklaşımla yönetilir. Şelale (waterfall) yönteminde aşamalar sırayla tamamlanır: önce tüm gereksinimler yazılır, sonra tasarlanır, ardından geliştirilir. Çevik (agile) yaklaşımda ise yazılım kısa döngülerle parça parça geliştirilir ve her döngünün sonunda çalışan bir sürüm gösterilir.

2001'de yayımlanan Çevik Yazılım Geliştirme Manifestosu, bu yaklaşımın değerlerini dört maddede özetler; bunlardan biri, kapsamlı dokümantasyondan çok çalışan yazılıma değer vermektir. Çevik çerçevelerin en bilinenlerinden Scrum'da iş, "sprint" adı verilen ve en fazla bir ay süren sabit döngülerle yürür. Pratikte birçok proje iki yaklaşımı harmanlar: ana kapsam ve bütçe baştan belirlenir, geliştirme çevik döngülerle yapılır.

MVP: önce en küçük çalışan sürüm

MVP (Minimum Viable Product, minimum uygulanabilir ürün), Eric Ries'in "The Lean Startup" kitabıyla yaygınlaşan bir yaklaşımdır: ürünün yalnız temel işlevlerini içeren ilk sürümünü olabildiğince erken kullanıcıya ulaştırmak ve sonraki geliştirmeleri gerçek kullanım verisine göre yapmak. Kurumsal projelerde de aynı mantık işler; tüm modülleri bir yılın sonunda teslim etmek yerine en çok değer üreten modül birkaç ayda canlıya alınır, geri kalanı kullanıma göre geliştirilir.

Süreyi ve bütçeyi neler belirler?

Özel yazılım ve panel projelerinde ilk canlı sürüm, kapsama göre çoğunlukla 8-16 hafta içinde çıkar; kapsamlı ERP ya da CRM sistemlerinin tamamlanması ise 6-12 ay sürebilir. Takvimi uzatan şey çoğu zaman kod yazmak değildir:

• Belirsiz gereksinimler: Net tanımlanmamış bir özellik, geliştirme sırasında defalarca değişir.
• Bekleyen onaylar: Tasarım ve test onaylarının gecikmesi takvimi doğrudan kaydırır.
• Dış sistemler: Muhasebe, ERP, ödeme ya da kargo bağlantıları, karşı tarafın dokümantasyonuna ve test ortamına bağlıdır.
• Veri aktarımı: Eski sistemlerdeki verinin temizlenip taşınması çoğu zaman tahmin edilenden uzun sürer.
• Kalite gereksinimleri: Güvenlik, performans ve erişilebilirlik testleri.

Test: kalite nasıl güvence altına alınır?

• Birim testleri: Kodun küçük parçalarının tek tek doğru çalıştığını otomatik olarak doğrular.
• Entegrasyon testleri: Parçaların ve dış sistemlerin birlikte çalıştığını sınar.
• Kullanıcı kabul testi: İşletmenin kendi ekibinin gerçek senaryolarla yaptığı son kontroldür.
• Güvenlik ve performans testleri: Yetki kontrolleri, sızma denemeleri ve yoğun kullanım altındaki davranış.

Geliştirme, test ve canlı ortamların ayrı tutulması, kodun Git gibi bir sürüm kontrol sisteminde saklanması ve her değişikliğin başka bir geliştirici tarafından gözden geçirilmesi, iyi bir yazılım ekibinin olağan çalışma biçimidir.

Proje boyunca iletişim nasıl kurulmalı?

• Tek karar verici: İşletme tarafında öncelikleri belirleyen ve onay veren bir kişi (ürün sahibi) olmalıdır; farklı kişilerden gelen çelişkili talepler projeyi yavaşlatır.
• Görünür iş listesi: Yapılacak işler, yapılanlar ve bekleyenler iki tarafın da görebildiği bir iş takip panosunda tutulmalıdır.
• Düzenli demo: Her döngünün sonunda çalışan sürüm gösterilir ve kısa bir değerlendirme yapılır; sorunlar haftalar sonra değil, günler içinde fark edilir.
• Yazılı kayıt: Kararlar ve değişiklik talepleri yazılı olarak kaydedilir; aylar sonra "bunu böyle konuşmuştuk" tartışmasını önler.

Takvime yetişmek için alınan kısa yollar teknik borç olarak adlandırılır. Bunlar kayıt altına alınıp sonraki döngülerde temizlenmezse birikir ve yeni özellik eklemeyi giderek yavaşlatır.

Sözleşmede mutlaka olması gerekenler

• Kapsam ve kabul kriterleri: Her özelliğin "tamamlandı" sayılması için neyin çalışması gerektiği.
• Değişiklik yönetimi: Kapsam dışı taleplerin nasıl fiyatlanacağı ve takvime nasıl ekleneceği.
• Fikri mülkiyet ve kaynak kod: Kaynak kodun, veritabanı yapısının ve teknik dokümantasyonun teslimi; kullanılan üçüncü taraf lisansları.
• Hesaplar: Sunucu, alan adı, uygulama mağazası ve servis hesaplarının işletme adına açılması.
• Bakım ve destek: Yayından sonraki destek süresi, kapsamı ve acil durumlarda yanıt süresi.
• Gizlilik ve kişisel veriler: Ekibin erişeceği verilerin korunması ve KVKK yükümlülükleri.

İyi bir yazılım ekibi nasıl tanınır?

• Teklif vermeden önce sorular soruyor ve sürecinizi anlamaya çalışıyorsa
• Tahminlerini aşamalara bölüp varsayımlarını yazıyla paylaşıyorsa
• Düzenli aralıklarla çalışan bir sürüm gösteriyorsa
• Kaynak kod ve hesap sahipliği konusunda net ve yazılı davranıyorsa
• Yayından sonrası için bir bakım planı öneriyorsa

Sonuç

Yazılım yaptırmak; aşamalar, roller ve sahiplik baştan bilindiğinde öngörülebilir bir iştir. Net bir kapsam, hızlı onaylar, çalışan sürümlerle ilerleyen bir takvim ve yazılı bir sözleşme, projelerin büyük kısmını riskten korur. Mobil tarafı mobil uygulama nasıl yapılır, müşteri yönetim sistemlerini CRM nedir yazılarımızda anlattık. Inside Media olarak web, panel ve özel yazılım projelerini keşiften bakıma kadar yazılım ajansı hizmetimizle yürütüyoruz; kaynak kod ve hesaplar proje sonunda eksiksiz teslim ediliyor.