Özel Yazılım Geliştirme Süreci: Neler Olur ve Neden
Özel yazılım aşamalar halinde geliştirilir ve her aşama incelemenize sunulan bir çıktı üretir. Bu rehber, bizimki dahil her geliştiricinin planını değerlendirebilmeniz için bu aşamaları sade bir dille anlatır.
Özel yazılım geliştirme süreci altı aşamadan oluşur: keşif, yazılı kapsam belgesi, tasarım ve prototip, test eşliğinde geliştirme, yayına alma ve bakım. Her aşama müşterinin inceleyebileceği bir çıktıyla biter. Efor; kullanıcı rolü, iş akışı, entegrasyon ve rapor sayısına bağlıdır ve müşteri, son ödemeyle birlikte kaynak kodun ve fikri mülkiyetin sahibi olmalıdır.
Son güncelleme:
Özel yazılım geliştirmenin aşamaları nelerdir?
Özel yazılım geliştirme normalde altı aşamadan geçer ve bunlardan birini atlamak genellikle maliyeti daha sonraki, daha sancılı bir ana kaydırır. Aşamaların adları ekipten ekibe değişir; yapılan iş değişmez.
- Keşif: sorunu, kullanıcıları ve mevcut araçları anlamak.
- Kapsam belgesi: nelerin geliştirileceğinin ve nelerin geliştirilmeyeceğinin yazılı tanımı.
- Tasarım ve prototip: kod yazılmadan önce üzerinde gezinebileceğiniz ekranlar ve akışlar.
- Geliştirme ve test: sistemi küçük, incelenebilir parçalar halinde kurmak.
- Yayına alma: sistemi canlı ortama taşımak ve kullanıcıları eğitmek.
- Bakım: düzeltmeler, güncellemeler, yedeklemeler ve planlı iyileştirmeler.
Kendi yaklaşımımızı özel yazılım geliştirme sayfasında anlatıyoruz. Web uygulamaları, panolar, kurum içi araçlar ve entegrasyonlar geliştiriyoruz; mobil uygulama ya da online mağaza geliştirmiyoruz.
Keşif aşamasında neler olur?
Keşif, geliştiricinin herhangi bir çözüm önermeden önce işinizin gerçekte nasıl yürüdüğünü öğrendiği aşamadır. Çıktısı kod değil, ortak bir anlayıştır.
Sistemi kimlerin kullanacağı, bugün tablolarda, e-postada ya da başka araçlarda neler yaptıkları, nerelerde aksaklık yaşandığı ve projenin işe yaradığını nasıl anlayacağınız gibi sorular bekleyin. İyi bir geliştirici gerçek belgeleri, raporları ve örnekleri görmek ister; yalnızca sahibiyle değil, sistemi her gün kullanacak kişilerle de konuşur. Keşif, kısıtları da erken ortaya çıkarır: belirli bir yerde tutmanız gereken veriler, bağlanmanız gereken sistemler ve iş takviminize bağlı teslim tarihleri.
Bir geliştirici kısa bir görüşmenin ardından kesin bir yanıt sunuyorsa, bunu tahmin olarak değerlendirin.
Kapsam belgesinde neler bulunmalıdır?
Kapsam belgesi; yazılımın ne yapacağı, kimin için yapacağı ve bilinçli olarak nelerin dışarıda bırakıldığı konusunda yazılı bir mutabakattır. Yazılım projelerindeki anlaşmazlıkların çoğu yazıya dökülmemiş farklı varsayımlardan çıktığı için her iki tarafı da korur.
- Hedefler ve çözülen sorun, müşterinin kendi ifadeleriyle.
- Kullanıcı rolleri ve her rolün neleri görüp yapabileceği.
- Özellikler ve iş akışları, adım adım tarif edilmiş halde.
- Diğer sistemlerle entegrasyonlar ve her yönde hangi verilerin aktığı.
- Raporlar, bildirimler ve dışa aktarımlar.
- Kapsam dışı kalan unsurlar, açıkça belirtilmiş halde.
- Kabul ölçütleri: her özelliğin nasıl tamamlanmış sayılacağı.
- İçeriği, veriyi, erişimi ve onayları kimin, ne zamana kadar sağlayacağı.
Değişiklik olağandır. Kapsam belgesi, bir değişikliğin nasıl talep edileceğini, değerlendirileceğini ve yazılı olarak kabul edileceğini de belirtmelidir.
Geliştirmeden önce neden prototip tasarlanır?
Prototip, geliştirme başlamadan önce önerilen ekranlar üzerinde gezinmenizi sağlar; bu da fikir değiştirmek için en ucuz andır. Bir çizimde düğmeyi yerinden oynatmak, tamamlanmış bir özelliği yeniden kurmaktan çok daha hızlıdır.
Prototipi, onu kullanacak kişilerle birlikte inceleyin. Kayıt oluşturmak ya da rapor almak gibi gerçek görevleri tamamlamalarını isteyin ve nerede tereddüt ettiklerini not edin. Ekranların telefonda nasıl davrandığını ve kullanıcılarınız Arapça okuyorsa sağdan sola düzende nasıl göründüğünü kontrol edin. Prototip onayı kayıt altına alınmalıdır, çünkü geliştirme sırasında referans olur.
Yazılım geliştirme ve test nasıl organize edilir?
Geliştirme, her biri görebileceğiniz çalışan bir parçayla biten kısa aşamalar halinde organize edildiğinde iyi sonuç verir; böylece sorunlar erken ortaya çıkar. Test yalnızca sonda değil, süreç boyunca yapılır.
Tipik kontroller arasında geliştiricinin kendi otomatik ve elle yaptığı testler, kabul ölçütlerine göre inceleme, girişler ve yetkiler üzerinde güvenlik kontrolleri ve gerçekçi verilerle yapılan test yer alır. Siz de kullanıcı kabul testine katılırsınız: siz ya da çalışanlarınız sistemi günlük işlerindeki gibi kullanır ve hataları yazılı olarak bildirir. Geç ortaya çıkan sürprizler genellikle başlangıç ile teslim arasında işi kimsenin görmediğinin işaretidir. Düzenli demolar bunu önler.
Yayına alma neleri kapsar, sonrasında ne olur?
Yayına alma, yazılımın test ortamından canlı ortama; gerçek verilerle, gerçek kullanıcılarla ve bir şeyler bozulduğunda uygulanacak bir planla taşınması demektir. Bu, bir düğmeye basmak değil, başlı başına bir proje adımıdır.
Barındırma ve SSL, eski araçlardan veri taşıma, kullanıcı hesapları, eğitim notları ve bir geri alma planı için hazırlık yapın. Yayından sonra yazılımın bakıma ihtiyacı vardır: güvenlik güncellemeleri, yedekler, izleme, hata düzeltmeleri ve sürecinizdeki değişikliklere göre iyileştirmeler. Bunları kimin yapacağını, taleplerin nasıl iletileceğini ve sorunların ne kadar hızlı ele alınacağını belirleyin. Barındırma, SSL ve güvenlik ile bakım ve destek sayfalarımıza bakın.
Özel yazılım projesinin eforunu ne belirler?
Özel yazılım projesinin eforunu, sistemin ne kadar iş yapması gerektiği, kaç tür kullanıcısı olduğu ve kaç farklı sistemle konuşması gerektiği belirler. Fiyat eforu izler; bu yüzden teklif istemeden önce anlamanız gereken noktalar bunlardır.
| Etken | Neden efor ekler |
|---|---|
| Kullanıcı rolleri ve yetkiler | Her rolün kendi ekranları, kuralları ve testleri gerekir |
| İş akışı sayısı | Her adım, onay ve istisna tasarlanmalı ve test edilmelidir |
| Entegrasyonlar | Diğer sistemlerin kendi kuralları, sınırları ve arıza biçimleri vardır |
| Raporlar ve panolar | Veriler hesaplanmalı, kontrol edilmeli ve net biçimde gösterilmelidir |
| Veri taşıma | Eski veriler nadiren temiz ve tutarlıdır |
| Diller ve yerleşim | Arapça ve İngilizce, sağdan sola destek ve çevrilmiş içerik gerektirir |
| Güvenlik ve denetim ihtiyaçları | Kayıt tutma, erişim kontrolü ve yedeklemeler dikkatli tasarım gerektirir |
| Gereksinimlerin netliği | Belirsiz gereksinimler yeniden işe yol açar |
Web sitesine özgü maliyet etkenleri için kurumsal web sitesinin maliyetini neyin etkilediği yazısını okuyun.
Sabit fiyat mı, zaman ve malzeme mi: projenize hangi sözleşme uyar?
Sabit fiyatlı sözleşme kapsamı net ve sabit bir projeye, zaman ve malzeme modeli ise öğrendikçe değişecek bir projeye uygundur. Hiçbiri her durumda daha iyi değildir.
| Nokta | Sabit fiyat | Zaman ve malzeme |
|---|---|---|
| Uygun olduğu durum | İyi tanımlanmış kapsam | Gelişen ya da belirsiz kapsam |
| Bütçe kesinliği | Kapsam korunursa yüksek | Daha düşük; inceleme yoluyla siz kontrol edersiniz |
| Esneklik | Değişiklikler resmi bir değişiklik talebi gerektirir | Öncelikler serbestçe değişebilir |
| Sizin eforunuz | Kapsamı tanımlamak için başta yoğun | Baştan sona düzenli |
| Ana risk | Neyin dahil olduğuna dair anlaşmazlıklar | Düzenli inceleme olmadan sapma |
Bazı projeler ikisini karıştırır: kapsamı sabit bir ilk sürüm, ardından gerektiği kadar devam eden çalışma.
Kaynak kodun ve fikri mülkiyetin sahibi kimdir?
Sözleşme açıkça aksini söylemedikçe, geliştirilmesi için ödeme yaptığınız yazılımdaki kaynak kodun ve fikri mülkiyetin sahibi siz olmalısınız. Bunu varsaymayın; yazılı olarak isteyin.
Dört noktayı kontrol edin: mülkiyetin son ödemeyle birlikte devredildiğini, kaynak kodun tamamını ve belgeleri aldığınızı, üçüncü taraf ya da açık kaynak bileşenlerin ve lisanslarının listelendiğini, geliştiricinin gizli verilerinizi yeniden kullanamayacağını. Barındırma hesabının ve kimlik bilgilerinin kimde olduğunu da doğrulayın. Bu genel bir rehberdir; sözleşme ifadelerini bir avukatla doğrulayın. Bir projeyi konuşmak isterseniz bize WhatsApp'tan yazın: +90 216 393 10 07.
Sık sorulan sorular
Özel yazılımın geliştirilmesi ne kadar sürer?
Kapsama bağlıdır; bu yüzden dürüst hiçbir geliştirici keşif yapmadan süre veremez. Tek kullanıcı rolüne sahip küçük bir kurum içi araç, birkaç rolü, entegrasyonu ve raporu olan bir sistemden çok daha kısa bir projedir. Yazılı bir kapsam belgesi ve aşamalı bir plan size gerçekçi tarihler verir ve zamanın nereye gideceğini gösterir.
Geliştiriciye neler sağlamam gerekir?
Sistemi kullanacak kişilere erişim, mevcut belgelerden, tablolardan ve raporlardan örnekler, bağlanılacak sistemlerin listesi ve kararları hızla onaylayabilecek isimli bir kişi sağlayın. Yavaş yanıtlar ve değişen karar vericiler projelerin gecikmesinin yaygın nedenleridir; bu yüzden işe başlamadan önce kimin karar vereceğini belirleyin.
Geliştirme sırasında gereksinimleri değiştirebilir miyim?
Evet, ancak değişiklikler kapsam belgesinde kararlaştırılan süreçten geçmelidir: talep, süre ve efor üzerindeki etkinin değerlendirilmesi, ardından yazılı onay. Küçük düzeltmeler olağandır. Büyük değişiklikler revize edilmiş bir plan ya da ikinci bir aşama anlamına gelebilir ve bunu iş yapılmadan önce bilmek daha iyidir.
Özel yazılım, hazır bir üründen daha mı iyidir?
Her zaman değil. Hazır yazılım, sürecinize uyduğunda genellikle makul ilk tercihtir. Özel yazılım; iş akışınız kendine özgüyse, araçlar birbirine bağlanmıyorsa ya da hiç kullanmadığınız özellikler için ödeme yapıyorsanız anlamlıdır. İyi bir geliştirici, mevcut bir ürün size daha iyi hizmet edecekse bunu söyler.
Geliştirici yayından sonra ortadan kaybolursa ne olur?
Kaynak kodun sahibiyseniz, barındırma hesabı ve kimlik bilgileri sizdeyse ve teslimde belge aldıysanız korunursunuz. Bunlar varsa başka bir geliştirici işi devralabilir. Yoksa tek bir kişiye bağımlı kalırsınız. Bu noktaları iş başlamadan önce sözleşmede netleştirin.
İlgili sayfalar
Kendi işletmeniz için örnek bir tasarım görün
Yüzlerce sektörden kurgusal örnek tasarımlara göz atın. Kendi işletme türünüzü göremediniz mi? WhatsApp'tan ne iş yaptığınızı yazın, size ücretsiz ve bir yükümlülük olmadan örnek bir tasarım hazırlayalım.
