Sistem analizi ve tasarımına giriş: SDLC ve metodolojiler

Bu ders, yazılımı kodlamadan önce yapılan işin dersidir. “Ne yapacağız, neden yapacağız, nasıl yapacağız” sorularını cevaplamayı öğrenirsin. İlk hafta bütün dönemin iskeletidir: sonraki her konu (fizibilite, use case, class diagram, test) SDLC’nin bir evresine oturur. Vizede genellikle tanım soruları (“which phase…”, “which methodology…”) ve kısa bir senaryo verilip “hangi metodoloji uygun, neden” sorusu gelir.

Altın kurallar:

1. SDLC dört evredir: Planning, Analysis, Design, Implementation. Sırayı ve her evrenin sorusunu ezberle.
2. Her evre bir çıktı (deliverable) üretir. Çıktı, sonraki evrenin girdisidir.
3. Metodoloji, evrelerin nasıl sıralanacağını söyler. Evreler aynıdır, sıralanış ve tekrar sayısı değişir.
4. Doğru metodoloji projeye göre seçilir: gereksinimlerin netliği, takvim, teknik risk, kullanıcının ne zaman sistem görmek istediği.

Sistem analizi ve tasarımı nedir?

Bir bilgi sistemi (information system) donanım, yazılım, veri, süreç ve insanların birlikte bir iş ihtiyacını çözmesidir. Sistem analizi ve tasarımı (systems analysis and design, SAD), bu sistemi kurmak için izlenen düzenli süreçtir. Burada sık yapılan hata, SAD’ı sadece “programlama öncesi belge yazmak” sanmaktır. Asıl amaç iş değeri (business value) üretmektir: sistem kurumun para kazanmasına, tasarruf etmesine ya da daha iyi hizmet vermesine yarar.

Projelerin çoğu teknik nedenlerle değil, kötü analiz yüzünden batar: yanlış gereksinim, belirsiz kapsam, kullanıcının sürece katılmaması. Bu yüzden ders kodla değil, süreçle başlar.

SDLC: dört evre

Sistem geliştirme yaşam döngüsü (systems development life cycle, SDLC), her bilgi sisteminin geçtiği dört temel evredir.

[Planning]->[Analysis]->[Design]->[Implementation]
    |           |          |            |
 system      system     system      installed
 request     proposal   spec        system

Planning

Proje bir system request ile başlar: bir iş birimi bir ihtiyacı yazılı olarak bildirir. Onay komitesi (approval committee) ya da yönlendirme komitesi (steering committee) talebi değerlendirir. Fizibilite analizi (feasibility analysis) teknik, ekonomik ve organizasyonel açıdan “yapılabilir mi, değer mi” sorusuna bakar. Onaylanırsa proje yönetimi başlar: iş planı, takvim, ekip.

Analysis

Analist mevcut sistemi (as-is) inceler, yeni sistemin (to-be) ne yapması gerektiğini çıkarır. Gereksinim toplama teknikleri (görüşme, JAD, anket, gözlem) burada kullanılır. Sonra gereksinimler modellere dökülür: fonksiyonel model (use case, activity diagram), yapısal model (class diagram), davranışsal model (sequence, state machine). Hepsi bir system proposal belgesinde toplanır ve komite projeye devam edip etmemeye karar verir.

Design

Sistemin nasıl çalışacağına karar verilir: yazılımı satın mı alacağız, kendimiz mi yazacağız, dışarıya mı yaptıracağız (design strategy)? Fiziksel mimari (client-server, cloud), kullanıcı arayüzü, veritabanı ve dosya yapıları, program modülleri tasarlanır. Çıktı system specification’dır.

Implementation

Sistem yazılır, test edilir, kurulur. Eski sistemden yeniye geçiş (conversion) planlanır, kullanıcılar eğitilir, destek ve bakım planı hazırlanır. Bu evre en pahalı evredir.

TUZAK · test sadece implementation’da değil. Testi planlamak analizde başlar (kabul kriterleri), tasarımda devam eder. Kodlama ve test koşturma implementation’dadır ama “test ilk kez burada düşünülür” demek yanlıştır.

Sistem analistinin rolleri

Büyük projelerde analistlik tek kişinin işi değildir, roller ayrılır:

Analistin temel becerileri: teknik bilgi, iş bilgisi, analitik düşünme, iletişim ve etik. Analist kullanıcıyla geliştirici arasındaki köprüdür; kullanıcının dilini de programcının dilini de konuşabilmelidir.

Metodolojiler

Metodoloji (methodology), SDLC evrelerini uygulamanın formalize edilmiş yoludur: hangi adımlar, hangi sırayla, hangi çıktılarla. Metodolojiler üç büyük gruba ayrılır.

1. Yapısal tasarım (structured design)

Waterfall. Evreler sırayla yapılır, bir evre bitip onaylanmadan diğerine geçilmez. Geri dönmek mümkündür ama pahalıdır.

Planning
   \--> Analysis
           \--> Design
                   \--> Implementation

Güçlü yanı: gereksinimler kodlamadan önce netleşir, belgeleme güçlüdür. Zayıf yanı: kullanıcı çalışan sistemi çok geç görür; iş ortamı değişirse sistem çıktığında artık doğru olmayabilir.

Parallel development. Planlama ve analizden sonra genel bir tasarım yapılır, sistem alt projelere bölünür ve her alt proje aynı anda tasarlanıp yazılır. Sonda entegrasyon yapılır. Süre kısalır; ama alt projeler birbirine bağımlıysa entegrasyon zordur.

V-model. Waterfall’ın bir türevidir: her geliştirme evresinin karşısında bir test seviyesi vardır (gereksinim ↔ kabul testi, mimari ↔ sistem testi, modül tasarımı ↔ birim testi). Test planı erken yazılır.

2. Hızlı uygulama geliştirme (RAD)

RAD (rapid application development) kullanıcıya erkenden çalışan bir şey göstermeyi hedefler.

• Iterative (phased) development: Sistem sürümlere bölünür. Sürüm 1 en önemli gereksinimleri içerir ve kurulur, sonraki sürümler eklenerek büyür. Kullanıcı erken değer görür, ama ilk sürüm eksiktir.
• System prototyping: Analiz, tasarım ve implementation aynı anda hızla yapılır, prototip kullanıcıya gösterilir, geri bildirimle büyüyüp sistem olur. Risk: aceleyle yapılan prototip, iyi düşünülmemiş bir tasarıma dönüşebilir.
• Throwaway prototyping: Prototip sadece belirsiz gereksinimleri anlamak için yapılır (çoğu zaman bir arayüz taslağı), sonra atılır. Sistem sağlam bir tasarımla yazılır.

3. Çevik geliştirme (agile)

Agile, Agile Manifesto’nun değerlerine dayanır: süreç ve araçlardan çok bireyler ve etkileşim, kapsamlı belgeden çok çalışan yazılım, sözleşme pazarlığından çok müşteriyle iş birliği, plana bağlı kalmaktan çok değişime yanıt verme.

Extreme Programming (XP): Kısa sürümler, test-first (önce test yazılır), pair programming, sürekli entegrasyon, refactoring, ortak kod sahipliği, müşteri ekibin yanında.

Scrum: En yaygın agile çerçevedir.

Agile’ın zayıf yanı: büyük ve dağıtık ekiplerde, sıkı belgeleme gerektiren (sağlık, savunma) projelerde zorlanır.

Unified Process (RUP)

Unified Process, nesne yönelimli (object-oriented) projeler için UML ile birlikte kullanılan bir metodolojidir. Üç özelliği vardır: use-case driven, architecture-centric, iterative and incremental. İki boyutludur: zaman boyunca dört evre, her evrenin içinde iş akışları.

İş akışları (engineering workflows): business modeling, requirements, analysis, design, implementation, test, deployment. Her iş akışı tüm evrelerde vardır ama yoğunluğu değişir: requirements Inception ve Elaboration’da, implementation Construction’da yoğundur.

TUZAK · UP evresi ≠ SDLC evresi. “Elaboration = Analysis” diye birebir eşleme yapma. UP’de her evrede birden çok iş akışı aynı anda çalışır. Elaboration’da analiz yoğundur ama tasarım ve kodlama da başlar.

Metodoloji seçimi: çözümlü örnek

Senaryo: Bir spor salonu zinciri üyelik sistemi istiyor. Yönetim ne istediğini tam bilmiyor, “görünce anlarız” diyor. Sistem 4 ay içinde yeni şubeyle birlikte açılmalı. Ekip küçük ve tecrübeli.

Kriterlere tek tek bak:

Sonuç: Scrum ya da system prototyping. Waterfall uygun değil çünkü gereksinimler belirsiz ve kullanıcı erken görmek istiyor.

Karşı senaryo: Bir bankanın faiz hesaplama modülü. Kurallar yasal mevzuatla kesin tanımlı, değişmiyor, hata maliyeti çok yüksek, denetim için belge şart. Burada waterfall ya da V-model mantıklıdır.

Sık yapılan hatalar