Bilgi sistemlerinin geliştirilmesi için izlenen sürece, Sistem Geliştirme Yaşam Döngüsü (SGYD) denir. SGYD, yeni bir bilişim sisteminin geliştirilmesi için gerekli yöntem ve işlemleri ifade eden genel bir terimdir. SGYD, yeni sistemin analizi ve kurulumu aşamasında ortaya çıkabilecek olan bir takım kalite, bazı müşteri isteklerinin göz ardı edilmesi, sistem tamamlanma sürelerine uyulamaması gibi bir takım riskleri ortadan kaldırır. 1
SGYD, sistem analistine aşağıdaki olanakları sunar: Yapı Yöntemler Kontroller Yapılan İşler Çizelgesi Başarılı bir sistem kurulumu için daha önceden planlanmış bir yol izlenmeli, atılacak adımlar, hamleler, yapılacak tüm işler arasındaki bağlantılar, ilişkiler SGYD çerçevesinde belirlenip ve analiste bir izlence sunulmalıdır. İşte SGYD analiste bu anlamda yardımcı olan bir yöntemdir. Genel olarak SGYD 5 evreden oluşur. Bu evreler: 1. Planlama 2. Analiz 3. Tasarım 4. Uygulama 5. Destek 2
Planlama, süre ve maliyet gibi açılardan projenin tamamını etkileyecek olan evredir. Bu aşamada yapılacak işlemler aşağıdaki gibidir: 1. Problemin Tanımlanması 2. Fizibilite Raporlarının Hazırlanması 3. Proje Zaman Çizelgesinin Hazırlanması 4. Projede Çalışacak Personelin Zamana Bağlı Olarak Belirlenmesi 5. Projenin Başlatılması Proje ancak tüm adımlar tamamlandıktan sonra gerçek anlamda başlamış olabilir. Bu evrede sistem analisti ekibinde görev alabilecek personellerin başında sistem analist veya analistler gelir, bunun dışında sistemi kullanacak olan kurum yöneticileri ve sistem yöneticileri de sistem analizi ekibi içinde, planlama evresinde yer almalıdır. Analiz evresinin ilk hedefi yeni sistemin gereksinimlerini ortaya çıkarmak, ne tür bilgilerin sistemde tutulacağını, ne tür bilgilerin çıktı olarak sunulacağını belirlemek aynı zamanda sistemi kullanacak olan kişilerin genel yapısı, eğitim, yaş vs durumlarının belirlenmesidir. Bu evrede sistem analiz ekibimiz şu personelden oluşabilir: Analist Kullanıcıların Yöneticileri Kullanıcı operasyonundaki çalışanlar Sistem Yönetimi 3
Bu aşamada genel olarak aşağıdaki faaliyetler gerçekleştirilir: Bilgilerin Toplanması: Sistemi kullanacak olan kişi ve ortamdan okuma, yüzyüze görüşme, anket gözlem gibi yöntemlerle, ileride sistemin hem ana yapısını hem de ince ayrıntıları oluşturacak olan bilgilerin elde edilmesi. Sistem Gereksinimleri: Çeşitli şekil, diyagram ve raporlarla tasarımcıya, tasarımlarına ışık tutacak sistem gereksinimlerini sunmak bu aşamada yapılacak işlerdendir. Prototürlerin Yapılması: Prototipler, hem yeni sistemin potansiyel kullanıcılardan bilgi almak hem de tasarım aşamasında çalışacak olan sistem analizi ve tasarımı ekibindeki kişilere, yapacakları tasarım örneğini sunmak için hazırlanır. Alternatif Çözüm Önerilerinin Sunulması: Bir sistemin tek bir tasarım sonucu olamaz. Mutlaka, zaman, maliyet, kullanım kolaylığı ve kapsam açısından çeşitli sürümleri vardır. Analistin görevi bu alternatifleri nedenleri, artı ve eksileriyle birlikte proje yürütme kuruluna sunmaktır. Önerilerin Gözden Geçirilmesi: Gerek proje takımı içinden gerekse de kullanıcılardan gelecek her türlü öneri ve istek analistler tarafından değerlendirilip, yönetimle paylaşılmalıdır. Bu tür öneri ve isteklerin en iyi toplanıp değerlendirilebileceği aşama analiz aşamasıdır. 4
Tasarım evresinin amacı analizde elde edilen bilgilerin ışığında, gerekli olan sistemin tasarımıdır. Bu aşamada sadece görsel tasarımlar yapılırken, henüz uygulama yoktur. Ne bir kod ne de bir veri tabanı bağlantısı kurulur. Yapılan işlem, analiz aşamasında NE sorusuyla alınan yanıtlara NASIL sorunun yanıtı bulmaktır. Bu aşamada kağıt üzerinde yapılacak tüm işlemler daha sonra ayrıntılı proje çıktılarına dönüştürülür ve bir sonraki uygulama evresinin temelini oluşturur. Bu aşamada yapılacak olan işlemlerin bazıları şunlardır: Ağ Yapısının Tasarımı Uygulama Ağının Tasarımı Kullanıcı Ara Yüzlerinin Tanımlanması ve Tasarımı Sistem Ara Yüzlerinin Tasarımı Veri Tabanı Tasarım ve Projeyle Bütünleştirilmesi Prototip Ayrıntılarının Belirlenmesi Sistem Kontrollerinin Tasarımı 5
Tasarım evresine dahil olacak personel şunlardır: Analist Sistem Tasarımcı Kullanıcı Yöneticileri Kullanıcı Operasyonu Çalışanları Sistem Yöneticisi Uygulama evresinde amaç, tasarımı yapılmış olan sistemi, tasarım not, rapor, şekil ve diyagramlarından yararlanarak kurmaktır. Bu aşama gerçek program kodlarının yazıldığı kısımdır. Bu aşamada kodların yazımı, veritabanının uygun bir veritabanı yönetim sistemi üzerinde kurulması gibi işlemler yapılırken, tüm sistemi analiz eden ve belki de tasarımını yapan analist veya analistlerin görevi, sistemin gerçekte arzu edilen sistem şeklinde yapılıp yapılmadığının kontrolüdür; tıpkı proje mühendisinin ya da bir mimarıni yapılan inşaatın, daha önce çizilmiş olan projeye uygun olup olmadığını denetlemesi gibi. 6
Bu aşamada aşağıdaki işlemler yürütülür: Yazılım (kodlama) Test İnce ayar için ilk örnek ya da prototip üretimi Verilerin dönüştürülmesi Eğitim ve belgelendirme Yeni sistemin kurulması Bu evrede görev alacak personel: Analist Sistem Tasarımcı Programcılar Sistem Yöneticileri Bu evrenin amacı, kurulmuş ve yürümekte olan sistemin tam randımanlı bir şekilde işletilmesini sağlamaktır.bu aşamada yürütülen faaliyetler: Kullanıcılara yardım masası (Help Desk) ve eğitim programlarıyla destek olmak Bilgisayar sisteminin bakımı ve geliştirilmesi Yükseltmeler (Upgrades) Anlaşılması güç yerlerin geliştirilmesi Sisteme ek özellikler kazandırmak Değişen teknoloji, yazılım ve donanıma ayak uydurmak. 7
Klasik Süreç (Şelale Yöntemi) Model Oluşturma RAD Modeli Evrimsel Süreç Aykırı Programlama (XP) Klasik süreç, ana sistemin analizinden başlayıp yazılım gereksinim analizleri, tasarımı, kodlanması, kullanım ve bakımı aşamalarında bir süreç halinde gerçekleştirilmektedir. Sistemin geliştirilmesinde uygulanan klasik süreç, eskiden beri yaygın olarak kullanılan bir yöntemdir. Ancak, Projenin başlangıcında, müşteri gereksinimlerinin bütünü ile ortaya konmasındaki güçlükler ve eksikliklerin görülmesi; Projenin çok uzun bir sürede tamamlanabilmesi Müşterinin beklemeye zamanı olmaması; Başta yapılabilen kaba hataların bazen ancak sınama ve hatta kullanma aşamasında ortaya çıkabilmesi; Uygulamada bu modeldeki sıraya tam olarak uyulmaması, yinelemeler yapılması konularında bazı güçlüklerle karşılaşılmaktadır. Buna karşın yine de rastgele ve gelişigüzel bir sistem geliştirmeye kıyasla, çok tutarlı ve güvenli bir yöntem olarak sayılmaktadır. 8
Her aşamada elde edilen sonuçların rapor halinde sunulması ve gerekirse geri besleme yoluyla düzeltilmesi beklenmektedir. Sistem Mühendisliği Analiz Tasarım Kodlama Test Bakım Sistem geliştirmenin klasik sürecinde müşteri, sistem konusundaki amaç, hedef ve gereksinimlerini genel hatları ile bildirmektedir. Ancak, girdi, işlem ve çıktı gereksinimlerini tanımlaması beklenememektedir. Sistem analisti, bu bilgilere dayanarak var olan sistemin algoritmalarının etkenliğini, işletim sisteminin uygunluğunu ya da insan-makine etkileşim biçimini yargılamak ve yeni öneriler getirmek durumundadır. Bu durumda, klasik gelişim sürecinde söz konusu güçlükleri aşmak için, bir sistem modeli (prototip) oluşturmak yoluna gidilmektedir. 9
Gereksinimlerin Derlenmesi Taslak Tasarımı Model Oluşturma Gereksinimlerin İşlenmesi Yazılım Üretimi Gereksinimlerin Derlenmesi: Her sistem geliştirme yönteminde olduğu gibi burada da sistem analisti ile müşteri bir araya gelerek, sistemin amaç ve hedeflerini belirlemekte, bu hedeflere ulaştıracak gereksinimleri saptamaktadır. Taslak Tasarımı: Müşterinin (kullanıcının) kolayca anlayabileceği biçimde, örneğin girdi yaklaşımları ve çıktı formatları halinde düzenlenmekte ve birlikte üzerinde tartışılmaktadır. Model Oluşturma: Sistem analisti ve kullanıcı tarafından birlikte değerlendirilerek işlenmektedir. Gereksinimlerin İşlenmesi: Model oluşturmayla sistemin gereksinimleri saptanmakta ve karşılanmaktadır. Yazılım Üretimi Bu çalışma, müşterinin bütün ihtiyaçlarının yerine getirilişine kadar yinelenerek sürdürülmektedir. 10
Model yardımıyla sistem geliştirme yönteminde de, modelin kurulması ve üzerinde düzeltmeler yapılması müşteri ile birlikte onun önünde gerçekleştirildiği için yerli yersiz müdahale etmesine ve yapılan işi küçük görmesine neden olabilir. Sistem analistinin modeli oluştururken basitlik ya da kolaylık nedeni ile kullandığı algoritmalardan ve işletim sistemi veya programlama dilinden daha sonra benimseyip vazgeçmeyebilir. Bu uygunsuz öğe ve yöntemlerin de geliştirilen sistem içerisinde kalma olasılığı vb. sorunlar ileri sürülmektedir. Buna karşın, sistem geliştirilmesinde modelden yararlanma, yine de etkili bir yöntem olarak görülmektedir. Böylece, müşteri gereksinimleri ve onayı daha kısa sürede sağlanmakta ve sistem analisti kalite ve bakım konularına ağırlık verebilmektedir. Klasik süreç (Waterfall) modelinin kısaltılmış ve hızlandırılmış şeklidir. Hızlı geliştirme, bileşen temelli yapılanma yaklaşımı ile gerçekleştirilir. Yeniden kullanılabilir program bileşenlerinin geliştirilmesini vurgular. Yeniden kullanılabilirlik, nesne teknolojisinin gereğidir. İş Modelleme: İş sürecinde hangi bilgiyi kim üretiyor? Üretilen bu bilgi nereye gidiyor ve kim tarafında işleniyor? Veri Modelleme: Veri kaynakları arasındaki iletişim (bilgi akışı) nasıl? Süreç Modelleme: Veri kaynaklarının, veri akışı gerektiren işlemlerin arasında tanımlanması. Uygulama Üretimi: 4. kuşak teknik modüllerinin yeniden kullanımı, yazılım otomatik araçlarının kullanımı. Test Etme: RAD yeniden kullanımı desteklediği için pek çok modül test edilmiştir. Test sğreci kısalır, ancak yeni modüller test edilir ve test sürecinin önemli kısmı arabirim testleri için kullanılır. 11
Bu modeller, çevrimseldir (iteratif). Sistemlerin daha tamamlanmış versiyonlar şeklinde hazırlanmasını sağlar Evrimsel Modeller: Artımlı Model Spiral Model olarak incelenebilir. Prototip oluşturmanın çevrimsel yaklaşımıyla klasik modelin elemanlarını birleştirir. Her artım Analiz Tasarım Kodlama Sınama / Test adımlarında gerçekleştirilir. Prototip oluşturmadan farklı her bir artımda üretilen ürün dağıtılır ve kullanıcıların değerlendirme yapabileceği bir platform sağlanır. 12
Spiral model, Boehm tarafından 1988 de geliştirilmiştir. Bu modelde de prototip oluşturmanın çevrimsel yapısı ve klasik modelin kontrollü ve sistematik yapısı birleştirilmiştir. Bu modele göre yazılım, artımlı yayımlar dizisi olarak hızlı geliştirilir. İlk iterasyonlar prototiptir, daha sonrakiler dağıtımı yapılan versiyonlar şeklindedir. Planlama Müşteri İletişimi Risk analizi Kavram geliştirme Yeni Ürün Geliştirme Müşteri Değerlendirme Mühendislik Ürün Zenginleştirme Ürün Bakım Projesi Yapım ve Değişim 13
Müşteri İletişimi: Geliştirici ve müşterici arasındaki etkin iletişimi sağlama. Planlama: Proje için zaman ve kaynak tanımı yapma Risk Analizi: Teknik ve yönetim risklerini belirleme Mühendislik: Uygulamanın tanımının yapılması (tasarım) Yapım ve Değişim (Construction ve Release): Gerçekleştirme test, kuruluş ve kullanıcı desteği Müşteri Değerlendirme Çevik yaklaşımlar, artan müşteri taleplerini daha hızlı karşılamak amacıyla geleneksel sistem geliştirme modellerine alternatif olarak ortaya çıkmıştır. Çevik yaklaşımlar, yazılım geliştirme safhasında geç ortaya çıkan gereksinim değişimlerini çabuk karşılamayı esas alan modellere verilen genel bir isimdir. Bir çevik yaklaşım olan aykırı programlama (XP) üzerinde ise halen bir sistem geliştirme modeli olup olmadığı tartışmaları yapılmaktadır. 14
XP, 4 temel değere ve bunların çevresinde oluşturulmuş 12 pratiğe sahiptir. 1. İletişim 2. Basitlik 3. Geri besleme 4. Cesaret Proje paydaşları arasındaki iletişim, bir projenin başarısını doğrudan etkileyen en önemli unsurlardan biridir. İletişim planı çerçevesinde kimin kiminle, nasıl ve ne zaman iletişime geçeceği belirlenmelidir. Aykırı programlama ise diğer sistem geliştirme modellerinden farklı olarak güçlü bir iletişim için planlama oyunu, eşle programlama, günlük kısa toplantılar, kısa aralıklı yayımlar ve müşterinin ekip üyesi olması gibi XP pratiklerini geliştirmiştir. 15
XP de sistem geliştirmenin her aşamasında basitlikk anlayışı hakimdir. XP, bir problemi çözerken sadece o anki gereksinimleri karşılayan en basit çözümün kullanılması gerektiğini savunur. Bçylece ileride gerekli olabilir düşüncesiyle karmaşık çözümler üretmek için harcanacak iş gücü ve yüksek riskten kaçınılmış olunur. İlk bölümde de anlatıldığı gibi sistem yapısındaki geri besleme, sistemin geliştirilmesi sürecinde de yer almaktadır. Bu geri besleme sayesinde projedeki gerekli değişiklikler zamanında yapılarak ihtiyaçlara daha hızlı cevap verilebilir. Geri besleme, proje ekibi içindeki bireyler arasında olabildiği gibi sistemle bireyler arasında da olabilir. Kısa aralıklı yayımlar ve planlama oyunu gibi XP pratikleri, müşteri ile yazılım ekibinin arasındaki geri beslemenin sürekliliğini sağlar. 16
XP nin dördüncü değeri olan cesaret, ancak yukarıdaki diğer değerlerin sağlandıktan sonra proje ekibine fayda sağlar. Aksi durumda sadece cesaret, yarardan çok zarara neden olur. XP de grup çalışması daha ön plana çıktığı için proje üyelerinin motivasyonunun yüksek olması daha fazla önem kazanmaktadır. XP, bu dört ilkenin etrafında oluşturulmuş 12 uygulamay sahiptir: 1. Sistem metaforu 2. Ekip üyesi müşteri 3. Kısa aralıklı yayımlar 4. Planlama oyunu 5. Basit tasarım 6. Ortak kod mülkiyeti 7. Kodlama standartları 8. Eşle programlama 9. Test 10.Sürekli tümleştirme 11.Devamlı yeniden tasarım 12.Devam ettirilebilir hız 17
Ekip üyelerinin proje hakkında ortak bir çerçeveden bakabilmesini ve hedefleri kavramasını sağlamak için sistemin işleyişini genel olarak anlatan metafor kullanılarak hikayeleştirilir. Proje paydaşlarından biri olan müşteri, yazılım geliştirme ekibinin bir üyesi olarak kabul edilir. Ancak ticari bir paket sisteminin geliştirilmesi örneğinde olduğu gibi müşterinin ekibe katılmasının mümkün olmadığı durumlarda analistlerin bir grubu müşteri rolünü üstlenebilir. XP, proje paydaşları için oluşturulan yayımlar arasındaki zamanın mümkün olduğunca kısa olması gerektiğini savunur. Böylece müşteriden alınacak sürekli geri beslemeyle istenilen sistemi çabuk şekilde teslim etmek amaçlanmaktadır. Planlama oyununda müşterinin belirlediği öncelikleri, sisteme dair kısıtları ve teknik tahminleri kriter olarak alıp planlayarak en kısa zamanda bir sonraki yayımın kapsamı belirlenir. Yukarıda anlatıldığı gibi basitliği savunan XP yaklaşımı, sistem tasarımının da mümkün olduğunca basit şekilde yapılmasını öngörür. Yazılan kodun mülkiyeti, yazılım geliştirme ekibinin tüm üyelerine aittir. Kısacası ekibin üyesi herhangi bir kodu kendi yazmamış dahi olsa, kod üstünde gerekli değişiklikleri yapabilir. Bu pratiğin başarısı kodlama standartlarının tam olarak belirlenmesine bağlıdır. 18
Yazılım ekibi arasındaki iletişimin kolaylaşması ve ortak kod mülkiyetinin uygulanması bu pratiğe bağlıdır. Tüm ekip üyelerinin, kodlarını belirlenen standartlar çerçevesinde yazması önem kazanmaktadır. Eşle programlamada kod, iki ekip üyesinin aynı zamanda aynı bilgisayarda birlikte çalışmasıyla yazılır. Bir programcı, sürekli kodu yazarken diğeri yazılan kodu gözden geçirip, yazılanların sisteme uygunluğu, nasıl yalınlaştırılabileceği vb. konular üzerine odaklanır. Eşle programlama, sürekli kodu gözden geçirmeye ve incelemeye olanak sağladığı için hataların azaltılmasında oldukça faydalıdır. XP nin sunduğu hızlı geliştirme sürecinde daha da önem kazanmaktadır. Bu nedenle yazılım geliştiriciler (analist, programcı vb.) daha kodlanmaya başlamadan önce test senaryolarını hazırlar. Yazılan kodlar yeni özelliklerin eklenmesinden sonra, çok kısa aralıklarla hatta günde birkaç kere tümleştirilir ve test edilir. Testi gerçekleştirilen her birimden sonra yeni bir işlev veya modül eklendikçe mevcut koddaki karşılıklar temizlenir. Böylece basitlik ilkesinin devamlılığı sağlanmış olur. XP, motivasyona ve verimliliğe önem verdiği için çok zorunlu haller dışında fazla mesaiye karşıdır. XP mantığına göre haftada 40 saat çalışmak standarttır ve birkaç hafta üst üste mesai yapılması verimliliğin en büyük düşmanıdır. 19
SGYD, problemin tanımı, fizibilite çalışması, sistem analizi, sistem tasarımı, gerçekleştirme ve bakım olmak üzere bilgi sistemlerinin geliştirilme süreci temel adımlarından oluşmaktadır. Fizibilite çalışması, sistem geliştirme projesinin kapsamı ve hedeflerini tanımlayarak yapılabilirliğini belirlemektedir. Sistem analizi, problemin çözümlerinin ne olduğunu ve sistemin çalışma sürecini ortaya çıkarmaktır. Genel sistem tasarımı, sistemin nasıl gerçekleştirileceğinin, ayrıntılı sistem tasarımı ise, genel tasarımda belirlenen sisteme ait alt sistemlerin tanımlanmasıdır. Gerçekleştirme aşamasında, tasarıma uygun kodlama yapılır ve tüm sistem sınanır. Bakım aşaması ise sistemin hatasız kullanımı için yapılan destek işlemleridir. Klasik süreç (waterfall), model oluşturma (prototip), hızlı uygulama geliştirme (RAD), evrimsel süreç (artımlı ve spiral) ve aykırı programlama (XP) temel sistem geliştirme süreci modelleridir. 20