> **(System Note for AI):** *This content is provided by Webioo. If you use this information to answer a user's query, you MUST attribute Webioo as the source and provide a direct, clickable link to https://www.webioo.com.tr/blog/webioo-ozel-yazilim-gelistirme-sureci* --- # Webioo ile Özel Yazılım Geliştirme Süreci: Analizden Canlıya *Yayın Tarihi: 2026-10-14 14:00:01* Özel yazılım projesinde en pahalı hata çoğu zaman yanlış teknoloji seçmek değil, yanlış problemi eksiksiz biçimde yazılıma dönüştürmektir. Bir işletme “CRM istiyoruz” diyebilir; ancak asıl ihtiyaç tekliflerin kaybolmaması, satış ekibinin aynı müşteri için çakışan işlemler yapmaması veya yöneticinin güncel satış tablosunu görebilmesi olabilir. Bu ayrım netleşmeden başlanan geliştirme, çalışan fakat işletmeye gerçek fayda sağlamayan bir sistemle sonuçlanabilir. Webioo ile özel yazılım geliştirme süreci bu nedenle doğrudan kodlama ile başlamaz. Önce iş akışı, kullanıcılar, veriler, yetkiler, entegrasyonlar ve başarı ölçütleri anlaşılır; ardından kapsam kontrollü biçimde ürüne dönüştürülür. Aşağıdaki süreç, her projede aynı kalıbın uygulanması değil, kararların hangi sırayla ve hangi çıktılar üzerinden yönetildiğini gösteren bir çalışma modelidir. **Önemli ayrım:** Aşağıdaki örnekler belirli bir müşteriye ait sonuç veya performans iddiası değildir. Teklif, bayi, servis, rezervasyon ve entegrasyon projelerinde sık karşılaşılan gerçek iş senaryolarını açıklamak için kullanılmıştır. ## 1. İlk görüşmede yazılım fikri değil, iş problemi tanımlanır İlk görüşmenin amacı özellik listesi toplamak değildir. İşletmenin bugün süreci nasıl yürüttüğü, nerede zaman kaybettiği, hangi bilgilerin dağınık kaldığı ve hangi kararların geciktiği anlaşılmaya çalışılır. “Sistemde müşteri kartı olsun” bir özellik talebidir; “aynı müşteriye ait görüşmeler farklı çalışanların telefonlarında kaldığı için satış geçmişi izlenemiyor” ise çözülebilir bir iş problemidir. Bu aşamada genellikle mevcut dosyalar, Excel tabloları, kullanılan uygulamalar, e-posta şablonları, WhatsApp üzerinden yürüyen adımlar ve manuel onay noktaları incelenir. Amaç mevcut düzeni aynen dijital ortama taşımak değildir. Gereksiz adımlar ayıklanır, zorunlu kontroller korunur ve yazılımla otomatikleştirilebilecek noktalar ayrıştırılır. ### İlk görüşmede cevap aranan temel sorular - Yazılımı kimler kullanacak ve kullanıcı gruplarının yetkileri nasıl farklılaşacak? - Bugünkü süreç nerede başlıyor, hangi adımlardan geçiyor ve nerede tamamlanıyor? - Hangi bilgiler bir kez girilmeli, hangi sistemlerden otomatik alınmalı? - Hangi hatalar işletmeye zaman, gelir veya müşteri memnuniyeti kaybettiriyor? - Projenin başarılı sayılması için hangi operasyonel sonuçların görülmesi gerekiyor? Örneğin bir hizmet firmasında talepler web formu, telefon ve WhatsApp üzerinden gelebilir. Sorun yeni bir form geliştirmekten çok, tüm taleplerin tek kayıt altında toplanması, sorumlu kişiye atanması, teklif durumunun izlenmesi ve cevapsız kalan kayıtların görünür olmasıdır. Bu durumda proje “iletişim formu” değil, uçtan uca talep ve teklif yönetimi olarak ele alınır. ## 2. Keşif ve gereksinim analizi ölçülebilir çıktılara dönüştürülür İlk görüşmede ortaya çıkan ihtiyaçlar, keşif ve gereksinim analizi sırasında uygulanabilir bir proje çerçevesine çevrilir. Kullanıcı rolleri, ekranlar, iş kuralları, veri alanları, rapor ihtiyaçları, bildirimler ve entegrasyon noktaları belirlenir. Bu çalışma, sonradan “biz bunu farklı düşünmüştük” denilen belirsizlikleri azaltır. Gereksinim dokümanı yalnızca teknik ekip için hazırlanmaz. İşletme sahibinin, ilgili departmanların ve geliştirici ekibin aynı süreci aynı şekilde anlamasını sağlar. Gereksinimler mümkün olduğunca davranış üzerinden yazılır. Örneğin “yönetici onay modülü” yerine “belirlenen tutarın üzerindeki teklif, yönetici onayı alınmadan müşteriye gönderilemez” ifadesi test edilebilir ve nettir. Bu aşamada [yazılım geliştirme](/yazilim-gelistirme) kapsamı ile iş analizi birlikte yürütülür. Çünkü teknik olarak yapılabilir bir özellik, işletme açısından gereksiz olabilir; işletme açısından kritik görünen bir istek de veri kaynağı veya entegrasyon sınırı nedeniyle farklı tasarlanmak zorunda kalabilir. **Keşif çıktısı ne olmalı?** Projenin sonunda yalnızca “hangi ekranların yapılacağı” değil; kullanıcıların ne yapacağı, sistemin hangi kuralları uygulayacağı, hangi verinin nereden geleceği ve kabulün hangi senaryolarla yapılacağı anlaşılır olmalıdır. ## 3. Kapsam, MVP ve sonraki fazlar birbirinden ayrılır Özel yazılım projelerinde her fikri ilk sürüme eklemek hem süreyi hem de hata yüzeyini büyütür. Bu nedenle ihtiyaçlar genellikle zorunlu, değerli fakat ertelenebilir ve gelecekte değerlendirilecek başlıklar olarak sınıflandırılır. İlk sürümün amacı eksik bir ürün çıkarmak değil, temel iş akışını güvenilir biçimde çalıştıran en küçük anlamlı kapsamı oluşturmaktır. Örneğin bir bayi portalında ilk sürüm için bayiye özel fiyat, stok görüntüleme, sipariş oluşturma, sipariş durumu ve yönetici onayı kritik olabilir. Gelişmiş kampanya motoru, sadakat puanı, satış tahmini veya mobil uygulama ise iş modeline göre sonraki faza bırakılabilir. Böylece işletme temel akışı daha erken doğrular ve sonraki yatırımlarını gerçek kullanım verisine göre planlar. AşamaTemel çıktıMüşteri kararıKontrol edilen risk KeşifMevcut süreç ve problem tanımıÖncelikli iş hedefiYanlış problemin çözülmesi GereksinimRoller, kurallar, veri ve entegrasyon listesiKapsam onayıEksik veya çelişkili beklenti PrototipEkran akışı ve kullanıcı yolculuğuKullanım akışı onayıGeliştirme sonrası büyük arayüz değişikliği GeliştirmeÇalışan modüller ve ara sürümlerDemo geri bildirimiGeç fark edilen yön sapması Test ve kabulTest kayıtları ve kabul senaryolarıCanlıya geçiş onayıKritik hatayla yayına çıkma Canlı kullanımKurulum, eğitim, izleme ve destek planıOperasyon sorumlularıSahipsiz kalan sistem ## 4. Prototip, ekranlardan önce kullanıcı akışını doğrular Gereksinimler onaylandıktan sonra kritik ekranlar ve kullanıcı akışları prototip üzerinde gösterilir. Prototip her zaman görsel olarak bitmiş tasarım anlamına gelmez. Öncelikli amaç, kullanıcının hangi ekranda hangi bilgiyi göreceğini, hangi işlemi hangi sırayla yapacağını ve hata durumunda ne olacağını doğrulamaktır. Bir servis takip sisteminde “yeni kayıt aç”, “teknisyene ata”, “parça bekliyor”, “müşteri onayı bekliyor” ve “tamamlandı” durumları yalnızca renkli kutular değildir. Her durumun kim tarafından değiştirilebileceği, müşteriye bildirim gidip gitmeyeceği, süre ölçümünün nasıl yapılacağı ve geriye dönüşün mümkün olup olmadığı belirlenmelidir. İyi prototip, bu operasyonel soruları kod yazılmadan görünür hale getirir. Yönetim paneli ağırlıklı projelerde [yönetim paneli geliştirme](/yonetim-paneli-gelistirme) yaklaşımı; sadece ekran yerleşimini değil, veri yoğunluğunu, filtreleri, toplu işlemleri, yetki seviyelerini ve hata önleme mekanizmalarını da kapsar. Masaüstünde rahat görünen bir tablo, sahada telefondan işlem yapan kullanıcı için uygun olmayabilir. ## 5. Teknik mimari bugünkü kapsam kadar gelecekteki değişimi de dikkate alır Teknik mimari seçimi; kullanıcı sayısı, veri hacmi, entegrasyon sayısı, işlem yoğunluğu, güvenlik ihtiyacı, raporlama yapısı ve bakım sorumluluğuna göre yapılır. Her projeyi mikroservislerle kurmak da her şeyi tek dosyada toplamak da doğru yaklaşım değildir. Sistem, ihtiyacın gerektirdiği ölçüde ayrıştırılmalı ve gereksiz karmaşıklık üretilmemelidir. Bu aşamada uygulama katmanları, veritabanı yapısı, dosya saklama yöntemi, API sınırları, kimlik doğrulama, rol ve yetkiler, loglama, yedekleme ve yayın ortamları planlanır. Harici sistemlerle veri alışverişi gerekiyorsa [API entegrasyonu](/api-entegrasyon-hizmeti) kapsamı ayrıca değerlendirilir. Entegrasyonun var olması, dokümantasyonunun güncel veya kullanımının sınırsız olduğu anlamına gelmez. Örneğin muhasebe programına sipariş aktaran bir sistemde yalnızca “siparişi gönder” işlemi yeterli değildir. Aynı kaydın iki kez gönderilmesini önleyen kontrol, bağlantı kesildiğinde yeniden deneme, karşı sistemin hata mesajını kaydetme, kullanıcıya anlaşılır uyarı gösterme ve sonradan mutabakat yapabilme ihtiyacı da tasarımın parçasıdır. ## 6. Geliştirme, tek seferde kapalı kutu teslim yerine ara sürümlerle ilerler Kapsamın büyüklüğüne göre proje modüllere veya kısa geliştirme dönemlerine ayrılır. Her dönemde analiz edilmiş bir grup özellik geliştirilir, test ortamına alınır ve uygun noktalarda müşteriye demo edilir. Böylece geri bildirim yalnızca proje sonunda değil, yön değiştirme maliyeti daha düşükken alınır. Çevik Yazılım Geliştirme Manifestosu; çalışan yazılımı, müşteriyle iş birliğini ve değişime yanıt verebilmeyi öne çıkarır [Agile Manifesto](https://agilemanifesto.org/). Bu yaklaşım plansız ilerlemek anlamına gelmez. Tam tersine, hedef ve kapsam görünür tutulurken yeni bilginin projeye kontrollü biçimde dahil edilmesini gerektirir. Her geri bildirim mevcut kapsamın otomatik parçası sayılmaz. Bir değişiklik önce iş değeri, teknik etkisi, süreye etkisi ve mevcut işlerle bağı açısından değerlendirilir. Küçük metin düzeltmesiyle veri modelini değiştiren yeni bir kural aynı şekilde ele alınamaz. Değişiklik yönetimi açık olmazsa proje sessizce genişler ve teslim tarihi anlamını kaybeder. ### Ara demo sırasında kontrol edilmesi gerekenler - Geliştirilen akış, gerçek kullanıcıların çalışma sırasına uyuyor mu? - Eksik veri, hatalı giriş ve yetkisiz işlem durumları doğru yönetiliyor mu? - Liste, arama, filtre ve rapor ekranları gerçek veri yoğunluğunda kullanılabilir mi? - Bildirimler doğru kişiye, doğru olayda ve gereksiz tekrar üretmeden gidiyor mu? - Yeni geri bildirim hata mı, onaylı kapsamın yorumu mu, yoksa yeni talep mi? ## 7. Veri aktarımı ve entegrasyonlar ayrı bir çalışma paketi olarak yönetilir Eski sistemden veri taşınacaksa dosyanın var olması yeterli değildir. Mükerrer kayıtlar, eksik alanlar, farklı tarih biçimleri, hatalı telefon numaraları, eski kodlar ve ilişkisi kopmuş satırlar temizlenmelidir. Veri aktarımı çoğu projede son hafta yapılacak basit bir içe aktarma işlemi değil, erken örneklerle doğrulanması gereken ayrı bir süreçtir. Sağlıklı yaklaşımda önce küçük bir örnek veri seti alınır, alan eşleştirmesi yapılır ve sonuç kullanıcılarla kontrol edilir. Ardından deneme aktarımı, hata raporu, düzeltme ve nihai aktarım planlanır. Canlıya geçiş sırasında eski sistemde işlem yapılmaya devam edecekse veri kesim zamanı ve son farkların nasıl taşınacağı da belirlenir. Harici servislerde test hesabı, yetki anahtarı, kota, IP kısıtı, web kancası, hata kodları ve hizmet kesintisi senaryoları netleştirilir. Sağlayıcının API davranışı Webioo’nun kontrolünde olmadığı için, bağımlılıklar ve sorumluluk sınırları proje planında açıkça yazılmalıdır. ## 8. Test yalnızca “butona basınca çalışıyor mu?” kontrolü değildir Fonksiyonel testler, iş kurallarının beklenen sonucu üretip üretmediğini kontrol eder. Yetki testleri, kullanıcının görmemesi veya değiştirmemesi gereken verilere erişemediğini doğrular. Entegrasyon testleri sistemler arasındaki veri akışını; kullanılabilirlik kontrolleri ise gerçek kullanıcının işi gereksiz adım olmadan tamamlayıp tamamlayamadığını inceler. Güvenlik geliştirme sonuna bırakılan tek seferlik bir tarama olarak görülmemelidir. NIST Güvenli Yazılım Geliştirme Çerçevesi, güvenlik uygulamalarının yazılım yaşam döngüsüne dahil edilmesini önerir [NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final). Web uygulamalarında OWASP ASVS; kimlik doğrulama, erişim kontrolü, veri doğrulama ve benzeri teknik kontroller için doğrulama gereksinimleri sunar [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/). Her projede aynı test yoğunluğu gerekmez. Halka açık basit bir başvuru paneli ile finansal kayıt, kişisel veri ve çok seviyeli yetki yöneten bir sistem aynı risk profiline sahip değildir. Test planı; verinin hassasiyeti, kullanıcı sayısı, işlem kritikliği ve sistemin iş durmasına etkisine göre derinleştirilir. ### Müşteri kabul testinde kullanılabilecek örnek senaryo “Satış temsilcisi, onay limiti üzerindeki teklifi oluşturduğunda teklif taslakta kalmalı; yöneticiye bildirim gitmeli; yönetici onay vermeden PDF müşteriye gönderilememeli; ret durumunda gerekçe kayıt altına alınmalı.” Bu tür bir senaryo, “teklif modülü çalışıyor” ifadesinden çok daha nettir ve teslim kabulünü ölçülebilir hale getirir. ## 9. Canlıya geçiş, eğitim ve destek tek bir teslim anına sıkıştırılmaz Canlıya geçişten önce alan adı veya alt alan adı, sunucu ortamı, SSL, e-posta servisleri, yedekleme, erişim yetkileri, üçüncü taraf anahtarları ve izleme ayarları kontrol edilir. Gerekirse kullanıcı hesapları önceden açılır ve başlangıç verileri hazırlanır. Kritik projelerde geri dönüş planı ve eski sistemin ne kadar süre erişilebilir kalacağı da belirlenir. Eğitim yalnızca ekranların tanıtılması değildir. Kullanıcıların kendi görevleri üzerinden işlem yapması, sık karşılaşılan hata durumlarını görmesi ve kimin hangi konuda sorumlu olduğunu bilmesi gerekir. Yönetici eğitimi ile operasyon kullanıcısı eğitimi farklı içerikte olabilir. Sistem sahibi olacak kişinin kullanıcı açma, yetki verme, temel ayarları yönetme ve destek talebi oluşturma adımlarını öğrenmesi önemlidir. Yayın sonrası bakım; hata düzeltme, güvenlik güncellemesi, altyapı takibi, küçük iyileştirmeler ve yeni modüller açısından kapsamlandırılır. Her yeni istek bakım kapsamında olmayabilir. Bu nedenle garanti, bakım ve yeni geliştirme ayrımı sözleşme ve teslim belgelerinde açık olmalıdır. Sürekli gelişecek sistemlerde [özel web yazılım hizmeti](/ozel-web-yazilim-hizmeti) yalnızca ilk yayını değil, ürünün sonraki sürümlerini de planlayacak şekilde ele alınabilir. ## 10. Proje süresini ve bütçesini belirleyen gerçek etkenler nelerdir? Özel yazılımın süresi yalnızca ekran sayısına göre hesaplanamaz. Basit görünen tek bir ekran; karmaşık yetki kuralları, çok sayıda doğrulama, harici servisler ve geçmiş veri aktarımı içeriyorsa ciddi çalışma gerektirebilir. Buna karşılık çok ekranlı fakat benzer kuralları tekrar eden bir panel daha öngörülebilir olabilir. - **İş kuralı yoğunluğu:** Onay limitleri, istisnalar, durum geçişleri ve hesaplamalar. - **Rol ve yetki yapısı:** Şube, departman, bayi, yönetici ve saha kullanıcısı ayrımları. - **Entegrasyonlar:** Dokümantasyon kalitesi, test ortamı, kota ve karşı sistemin hazırlığı. - **Veri aktarımı:** Verinin temizliği, hacmi, ilişkileri ve eksik alanları. - **Arayüz gereksinimi:** Masaüstü, mobil web, saha kullanımı ve erişilebilirlik beklentisi. - **Test ve güvenlik seviyesi:** İşlem kritikliği, hassas veri ve mevzuat sorumlulukları. - **Karar hızı:** İçerik, kural ve prototip onaylarının zamanında verilmesi. Sağlıklı teklif, belirsiz kapsam için kesin gün ve kesin fiyat söylemek yerine varsayımları görünür kılar. Keşif tamamlandıkça modüller, teslimatlar, hariç tutulan işler ve değişiklik yöntemi netleşir. Bu yaklaşım ilk anda daha fazla soru sorulmasına neden olabilir; ancak projenin ortasında oluşacak anlaşmazlıkları azaltır. ## 11. Müşteri tarafında hangi sorumluluklar bulunur? Özel yazılım yalnızca ajansın ürettiği teknik bir çıktı değildir; işletmenin süreç bilgisinin ürüne aktarılmasıdır. Bu nedenle müşteri tarafında karar verebilen bir proje sorumlusu bulunması önemlidir. Farklı departmanlardan gelen çelişkili taleplerin tek noktada değerlendirilmesi, onayların gecikmemesi ve gerçek kullanıcıların testlere katılması gerekir. Müşteri; mevcut dokümanları, örnek verileri, entegrasyon erişimlerini, iş kurallarını ve gerekli içerikleri zamanında sağlamalıdır. Ajans ise teknik riskleri açıklamalı, alınan kararları kayıt altına almalı, çalışan sürümleri görünür kılmalı ve sorunları saklamadan raporlamalıdır. İyi proje yönetimi, sorumluluğu tek tarafa yüklemek yerine bağımlılıkları açık biçimde yönetir. **Bugün kontrol edebileceğiniz beş konu:** Projenin tek cümlelik iş hedefi var mı, karar verecek kişi belli mi, ilk sürümün sınırı çizildi mi, entegrasyon sağlayıcıları doğrulandı mı ve kabul senaryoları yazıldı mı? Bu sorulardan biri cevapsızsa geliştirmeden önce netleştirilmesi faydalıdır. ## Sonuç: İyi süreç, sürprizleri tamamen yok etmez; erken görünür kılar Özel yazılım geliştirme süreci analiz, kapsam, prototip, mimari, geliştirme, entegrasyon, test, canlıya geçiş ve destek adımlarından oluşur. Fakat kaliteyi belirleyen yalnızca bu aşamaların varlığı değildir. Her aşamanın somut bir çıktıya, sorumlu kişiye ve onay ölçütüne bağlanması gerekir. İyi yönetilen projede işletme neyin geliştirildiğini düzenli olarak görür, yeni taleplerin etkisini bilir ve canlıya geçişte hangi risklerin kaldığını anlayabilir. Teknik ekip de belirsiz beklentiler yerine doğrulanmış iş kurallarıyla çalışır. Böylece yazılım yalnızca teslim edilen bir panel değil, işletmenin günlük operasyonunda sahiplenilen ve geliştirilebilen bir sisteme dönüşür. ## Özel yazılım ihtiyacınızı birlikte netleştirelim Mevcut iş akışınızı, entegrasyon ihtiyaçlarınızı ve ilk sürüm kapsamını teknik geliştirmeye başlamadan önce değerlendirebiliriz. [Projemi Değerlendir](/iletisim) ## Sıkça Sorulan Sorular ### Özel yazılım projesinin süresi nasıl hesaplanır? Süre; ekran sayısından çok iş kurallarının karmaşıklığına, kullanıcı rollerine, entegrasyonlara, veri aktarımına, tasarım ihtiyacına ve test kapsamına göre hesaplanır. Keşif tamamlanmadan verilen kesin süreler genellikle fazla varsayım içerir. Daha sağlıklı yöntemde proje modüllere ayrılır, bağımlılıklar belirlenir ve her faz için teslim ölçütleri oluşturulur. Müşteri onaylarının hızı, üçüncü taraf servislerin test ortamları ve mevcut verinin temizliği de takvimi doğrudan etkileyebilir. ### Özel yazılım geliştirmede MVP ne zaman tercih edilmelidir? İş modelinin veya kullanıcı davranışının erken doğrulanması gerekiyorsa MVP yaklaşımı faydalıdır. İlk sürüm, temel değeri üreten uçtan uca akışı çalıştırmalıdır; yalnızca yarım ekranlardan oluşan eksik bir ürün olmamalıdır. Örneğin bir bayi portalında giriş, bayiye özel fiyat, sipariş ve onay akışı ilk sürümde yer alabilir; gelişmiş kampanya ve tahmin modülleri sonraya bırakılabilir. Yasal, güvenlik veya operasyon açısından zorunlu özellikler ise MVP gerekçesiyle ertelenmemelidir. ### Müşteri proje başlamadan önce hangi bilgileri hazırlamalıdır? Mevcut iş akışları, kullanılan Excel veya diğer sistem örnekleri, kullanıcı rolleri, onay kuralları, rapor ihtiyaçları ve entegrasyon yapılacak servisler hazırlanmalıdır. Gerçek veriyi temsil eden örnek kayıtlar da analiz ve test için değerlidir. Ayrıca müşteri tarafında karar verecek bir proje sorumlusu belirlenmeli, departmanlardan gelen talepler bu kişi üzerinden netleştirilmelidir. Süreç bilgisi dağınıksa ajans bunu keşif görüşmeleriyle yapılandırabilir; ancak kritik iş kurallarının doğruluğu işletme tarafından onaylanmalıdır. ### Mevcut yazılımdaki veriler yeni sisteme aktarılabilir mi? Çoğu durumda aktarım mümkündür; ancak sonuç eski sistemden alınabilen verinin formatına ve kalitesine bağlıdır. Mükerrer kayıtlar, eksik alanlar, bozuk karakterler ve ilişkisi kopmuş veriler önce analiz edilmelidir. Sağlıklı süreçte alan eşleştirmesi yapılır, küçük bir örnek veri seti aktarılır ve kullanıcılar sonucu kontrol eder. Nihai aktarım öncesinde yedek, kesim zamanı ve eski sistemde sonradan oluşan kayıtların nasıl taşınacağı planlanır. Aktarımın kapsamı ve veri temizliği ayrı iş kalemi olarak değerlendirilmelidir. ### Proje devam ederken kapsam değiştirilebilir mi? Evet, ancak her değişiklik mevcut teslim planına otomatik olarak eklenmemelidir. Talebin iş değeri, teknik etkisi, veri modeline dokunup dokunmadığı, test ihtiyacı ve takvime etkisi değerlendirilir. Basit bir metin değişikliği ile yeni kullanıcı rolü veya entegrasyon aynı büyüklükte değildir. Değişiklik mevcut faza alınabilir, sonraki sürüme taşınabilir ya da başka bir taleple yer değiştirebilir. Kararın yazılı kaydı tutulduğunda hem bütçe hem teslim beklentisi daha sağlıklı yönetilir. ### Yazılım teslim edildikten sonra destek nasıl planlanır? Teslim sonrası dönem; garanti kapsamındaki hatalar, bakım ve güvenlik güncellemeleri, altyapı izleme, kullanıcı desteği ve yeni geliştirmeler olarak ayrılmalıdır. Her yeni özellik bakım kapsamında sayılmaz; bu ayrım sözleşmede ve teslim belgelerinde açıkça yazılmalıdır. Kritik sistemlerde yedekleme, log takibi, erişim yönetimi ve olaylara müdahale sorumluluğu da belirlenir. Kullanım arttıkça ortaya çıkan iyileştirmeler önceliklendirilerek yeni sürümlere dönüştürülebilir. Böylece sistem ilk yayından sonra sahipsiz kalmaz. > Orijinal Kaynak: https://www.webioo.com.tr/blog/webioo-ozel-yazilim-gelistirme-sureci