Sistem Geliştirme Süreçleri Konu Anlatımı

Sistem geliştirme süreçleri, SDLC yaklaşımıyla gereksinimden üretim ortamına kadar kontrollü ve izlenebilir bir yaşam döngüsü kurar.

SDLC birbirini izleyen aşamalardan oluşur; fizibilite, gereksinimlerin tanımlanması, tasarım, geliştirme, test, uygulama ve uygulama sonrası değerlendirme bu mantık içinde okunur.

Amaç yalnız yazılım üretmek değil, yönetim ve kontrol sağlamak, gereksinimleri netleştirmek, riskleri azaltmak, kaliteyi artırmak, iş verimliliği ve ekonomik değer üretmektir.

SDLC işletme içi geliştirmede kullanılabileceği gibi üçüncü taraf çözüm edinimiyle de ilişkilendirilebilir.

Bilgi sistemleri denetçisi açısından süreç, yönetimin projeyi izleyip izlemediği, gereksinimlerin doğrulanabilir ve test edilebilir olup olmadığı, güvenlik ve kalite kontrollerinin tasarıma gömülüp gömülmediği üzerinden değerlendirilir.

SDLC kullanılmadığında projeler kontrolsüz hâle gelebilir.

Gereksinim belirsizliği, bütçe ve zaman sapmaları, kalite sorunları, müşteri memnuniyetsizliği, kötü iş süreçleri ve kaynak israfı ortaya çıkar.

Bu yüzden gereksinim analizi hayatidir.

Gereksinimler sistemin ne yapacağını, kullanıcıların sistemle nasıl etkileşeceğini ve hangi kısıtların bulunduğunu açıklar.

Eksiksiz, tutarlı, açık, doğrulanabilir, değiştirilebilir, test edilebilir ve izlenebilir gereksinimler hedeflenir.

Kullanıcı gereksinimleri sistemsel gereksinimlere dönüştürülür; güvenlik, performans, entegrasyon, donanım ve yazılım altyapısı ihtiyaçları belirlenir.

Soru tuzağı, gereksinimi yalnız kullanıcı isteği sanmaktır; teknik ve güvenlik gereksinimleri de aynı çerçevededir.

İş analizi, projenin iş süreçlerindeki sorunu ve çözüm ihtiyacını belirler.

Mevcut süreçlerin ayrıntılarını, çevresel durumunu, zorluklarını ve paydaş beklentilerini ortaya koyar.

İş ve bilgi teknolojileri arasındaki köprü burada kurulur.

Teknik analiz ise iş gereksinimlerine göre hangi teknolojilerin, donanımın, yazılım altyapısının, güvenlik önlemlerinin, performans ölçütlerinin ve entegrasyonların gerekeceğini netleştirir.

Güvenlik gereksinimleri, veri yaşam döngüsü boyunca erişim, gizlilik, bütünlük ve değişen tehditlere uyum açısından ele alınır.

Gereksinimlerin tarihsel saklanması ve izlenebilirliği, sonradan doğacak değişikliklerin hangi ihtiyaçla bağlantılı olduğunu göstermesi bakımından önemlidir.

Gereksinim aşamasında görülen tipik hatalar sınav açısından ayırt edicidir.

Eksik veya belirsiz gereksinimler proje ekibinin ne yapacağını anlamasını zorlaştırır.

Aşırı detaylı gereksinimler esnekliği azaltır ve maliyeti artırır.

Gereksinimlerin sık değişmesi proje planını bozar; paydaşların yetersiz katılımı gerçek beklentilerin kaçırılmasına neden olur.

Gereksinimlerin izlenmemesi, değişikliklerin kapsamı bozmasına yol açar.

Farklı paydaş gereksinimlerinin çatışması, öncelik ve çözüm kararlarını zorlaştırır.

Maliyet ve fayda değerlendirmesi yapılmayan gereksinimler teknik olarak mümkün olsa bile iş değeri üretmeyebilir.

Bu nedenle gereksinim yönetimi, proje başlangıcında yazılan belgeyle biten bir faaliyet değildir.

Tasarım aşaması, tamamlanmış gereksinimlere dayanarak sistem bölümlerini, alt sistemleri, program ve veri tabanı özelliklerini, güvenlik önlemlerini ve kontrol noktalarını belirler.

İşletme içi geliştirmede tasarım, kullanıcı ihtiyaçları ile teknik çözüm arasında somut mimari kurar.

Değişim kontrol süreci bu aşamada önem kazanır; yeni gereksinimlerin kontrolsüz biçimde geliştirme sürecine girmesi engellenmelidir.

Yazılım taban çizgisi, tasarımda bir kesme noktasıdır; kullanıcı gereksinimleri zaman, fayda, etki ve maliyet bakımından değerlendirilerek belirli bir noktada dondurulur.

Bu çizgiden sonra her değişiklik etkisi analiz edilerek ele alınmalıdır.

Geliştirme aşaması tasarımı çalışan ürüne dönüştürür; ancak yalnız kod yazmak değildir.

Yapısal analiz, tasarım ve geliştirme teknikleri klasik SDLC için vazgeçilmez kabul edilir.

Varlık ilişkisi diyagramları, sistem akışları, girdi ve çıktı tanımları, denetim izleri, işlem bütünlüğü ve hatalı veriyi algılama yeteneği tasarım ve geliştirme boyunca düşünülür.

Bilgi sistemleri denetçisi, kalite güvence sonuçlarını, risk yönetiminin yeterliliğini, sistem girdi ve çıktılarının doğruluğunu, hesaplamaların bütünlüğünü ve denetim izlerinin izlenebilirliğini değerlendirebilir.

Güvenlik gereksinimleri geliştirme sonunda eklenen süs değil, tasarım ve kod yapısının parçasıdır.

Test aşaması, sistemin gereksinimleri karşılayıp karşılamadığını ortaya koyar.

Birim testleri bileşenleri, entegrasyon testleri bileşenler arası veri akışını, sistem testleri tamamlanmış işlevselliği, performans testleri yük altındaki davranışı, kullanıcı kabul testleri ise iş biriminin ihtiyacının karşılanıp karşılanmadığını değerlendirir.

Kullanıcı kabul testi, teknik ekibin “çalışıyor” demesinden farklıdır; iş kullanıcısının gereksinimlere göre kabulüdür.

Regresyon testi, yeni değişikliklerin eski işlevleri bozup bozmadığını kontrol eder.

Bağımsız test ilkesi, hatayı çözen kişi ile tekrar testi yapan kişinin mümkün olduğunca farklı olmasını destekler.

Üretim ortamına aktarım, başarılı testlerden sonra değişim kontrol prosedürlerine göre yapılır.

Uygulamaya almanın planlanması, gerekli onayların alınması, güvenlik erişimlerinin tanımlanması, geri dönüş senaryolarının hazırlanması, sürüm yönetimi ve kullanıcı bilgilendirmesi bu aşamanın parçalarıdır.

Başarısız uygulama hâlinde dönülecek sürümün bilinmesi gerekir.

Sürüm kontrol sistemleri, değişikliklerin hangi commit veya sürümle ilişkili olduğunu göstererek izlenebilirlik sağlar.

CI ve CD gibi modern yaklaşımlar değişikliklerin test edilmesini ve dağıtımını hızlandırabilir; fakat hız, değişiklik kontrolü ve onay gereğini ortadan kaldırmaz.

Uygulama sonrası gözden geçirme, sistem hedeflerine ulaşılıp ulaşılmadığını değerlendirir.

Kontrollerin tasarıma göre çalışıp çalışmadığı, kullanıcı değişiklik taleplerinin karşılanma düzeyi, zaman ve maliyet memnuniyeti, uygulama kontrollerinin etkinliği, güvenlik erişim kısıtlamaları ve iş sürekliliği etkileri incelenir.

Proje tamamlandıktan sonra bakım ve destek süreçleri başlar; bu da SDLC'nin döngüsel doğasını gösterir.

Gereksinimler değişebilir, hatalar bulunabilir, performans ihtiyaçları farklılaşabilir.

Ancak her değişiklik, geliştirme sürecindeki disiplinle aynı izlenebilirlik ve kontrol çerçevesinde yönetilmelidir.

Özetle sistem geliştirme süreçlerinde başarı, gereksinimlerin doğru tanımlanması, tasarımın bu gereksinimlere dayanması, geliştirme ve testin izlenebilir olması, üretime geçişin değişiklik kontrolüyle yürütülmesi ve uygulama sonrası kontrollerin değerlendirilmesiyle sağlanır.

Sınav tuzağı, SDLC'yi sadece yazılım geliştirme aşamaları listesi gibi ezberlemektir.

Doğru cevap, her aşamanın amacını, çıktılarını, risklerini ve denetçinin hangi kontrole bakacağını ilişkilendirir.

Gereksinim net değilse tasarım, tasarım kontrollü değilse geliştirme, test izlenebilir değilse üretim, üretim sonrası izleme yoksa bakım güvenilir olmaz.

Paket yazılım edinimi, geliştirme süreçlerinin dışında görünse de gereksinim aşamasından sonra verilen stratejik bir karardır.

İşletme hazır çözüm alacaksa teklif talebinde ürün ve sistem gereksinimleri, tedarikçinin çözüm yeteneği, destek süreçleri, kabul testi, bakım yaklaşımı ve kaynak kod mevcudiyeti gibi hususlar netleşmelidir.