YAŞAM DÖNGÜSÜ
Geliştirilen yazılımın, üretim aşaması ve kullanım süreci boyunca geçirdiği tüm aşamalar Yazılım Geliştirme Yaşam Döngüsü olarak tanımlanır. Yazılımın üretildiği aşamadan itibaren işlevsellik ile gereksinimleri sürekli değişecek ve bu değişiklikler de yazılımın genişlemesine neden olacaktır. Dolayısı ile, bu aşamalar bir döngü olarak ele alınmak zorundadır. Bu döngü doğrusal ve tek bir yöne ilerleyen bir döngü değildir çünkü herhangi bir aşamada geriye dönmek, geliştirmeyi yapmak ve tekrar ilerlemek mümkündür.
Yazılım yaşam döngüsünün bazı temel adımları vardır. Bunları Planlama, Analiz, Tasarım, Üretim ve Bakım olarak sıralamak mümkündür.
Planlama, proje planının oluşturulduğu, fizibilite çalışmasının yapıldığı, insan kaynakları ve donanım gibi ihtiyaçların belirlendiği aşamadır.
Analiz aşamasında, var olan sistemler incelenerek sistem ve yazılım gereksinimleri ve varsa işleyişteki temel sorunlar detaylı olarak belirlenir.
Tasarım, analiz aşamasında belirlenen gereksinimleri karşılayacak olan yazılımın temel yapısının oluşturulduğu aşamadır. Bu aşamada, yazılımın
içerdiği tüm bileşenler ayrıntıları ile tanımlanır ve tasarlanır.
Üretim aşaması tasarımı yapılmış olan yazılım bileşenlerinin geliştirilmesi, test edilmesi, kurulumlarının yapılması gibi işlemleri içeren aşamadır.
Bakım ise, yazılım birimleri teslim edildikten sonra hata giderme, yeni eklentiler yapma, iyileştirmelerde bulunma faaliyetleridir.
GELİŞTİRME YÖNTEMLERİ
Yazılım ihtiyaçlarının giderek büyümesi, yazılım geliştirme faaliyetlerinde kullanılmak üzere yöntemlerin gelişimini de ortaya çıkartmıştır. Yazılım teknolojilerinin gelişmesi ile, var olan model ve yöntemler de gelişmekte ve yeni modeller ortaya çıkmaktadır. Uygun yazılım geliştirme modelleri kullanılması, yazılımın daha emniyetli, doğru, anlaşılabilir, test edilebilir ve bakım yapılabilir olarak geliştirilmesinde çok önemli rol oynar. Daha emniyetli yazılımların daha kısa sürede, daha az bütçeyle ve en önemlisi daha az hatayla geliştirilmesi için sürekli yeni teknolojiler ve modeller bulunmaya çalışılmaktadır.
Yazılım yaşam döngüsü kısmında kısaca özetlenen yazılım geliştirme temel adımlarının nasıl gerçekleştirileceğine yönelik çeşitli modeller kullanılabilmektedir. Model, yazılım geliştirme faaliyetinin nasıl yapılacağına, genel geliştirme düzeninin nasıl olacağına dair bir rehber niteliği taşır. Belli başlı yazılım geliştirme modelleri aşağıdaki gibi sıralanabilir:
Gelişigüzel Geliştirme
Barok Modeli
Şelale (Waterfall) Modeli
Helezonik (Spiral) Model
Arttırımsal (Incremental) Geliştirme Modeli
Döngüsel Model
Çevik (Agile) Yazılım Geliştirme Metodları
YAZILIM GELİŞTİRME FAALİYETLERİ
Bu faaliyet sırasında yaptığımız çalışmalar aşağıda verilmiştir:
Yazılım geliştirme planlaması
Yazılım konfigürasyon öğesi test planlaması
Sistem test planlaması
Yazılım kurulum planlaması
Yazılım geçiş planlaması
Yönetimsel gözden geçirme için zamanları da içeren takip ve plan güncellemeleri
Faaliyet sonrası aşağıda listelenmiş dokümanları hazırlar müşterilerimizle paylaşırız:
Yazılım Geliştirme Planı (SDP – Software Development Plan)
Sistem Test Planı (SyTP – System Test Plan)
Yazılım Test Planı (STP – Software Test Plan)
Yazılım Kurulum Planı (SIP -Software Installation Plan)
Sistem gereksinim analizi hazırlığı: proje ortamı ve proje takım üyelerinin sistem gereksinimlerini alma ve analiz etmek için yeterince hazırlanmış olduğundan emin olunur.
Gereksinimlerin belirlenmesi: kapsam içi ve kapsam dışı gereksinimler tanımlanır. Kurallar tanımlanır ve dokümante edilir ve uygulamadan dışarı ve uygulamaya doğru olan arayüzler belirlenir.
Süreç modelinin belirlenmesi: Sistem ile etkileşen ana iş süreçlerinin görsellerle desteklenmiş anlatımı yapılır, diyagramlar hazırlanır ve yönetilebilir fonksiyon ve alt fonksiyonlara çözümlenir.
Mantıksal veri modelinin belirlenmesi: Süreçleri ve iş kurallarını destekleyen verinin mantıksal olarak modellenir, kavramların ve diğer kavramlarla olan ilişkilerinin tanımlanır ve özellikler/nitelikler iş tanımları ile birlikte belirlenir.
Modeller ile iş gereksinimlerin bağdaştırılması: Proje takımının, süreç ve mantıksal veri modellerinin tüm gereksinim ve iş kuralları ile uyum içinde olmasını sağlanır.
İşlevsel gereksinimlerin üretilmesi: Müşterinin uygulamayı nasıl kullanacağı ve verinin nasıl alınıp, işlenip kayıt altında tutulacağının sistematik olarak tanımlanır, arayüzler, süreçler ve veriler birleştirilir.
Bu aşamada sistemin genel tasarım kararları verilir ve mimari tasarımı yapılır. Faaliyet sonrası Sistem Altsistem Tasarım Tanımı (SSDD – System Subsystem Design Description) dokümanını hazırlar müşterilerimizle paylaşırız.
Bu aşamada yazılım yapılandırma öğeleri için gereksinimler belirlenir, modül ve alt modüller tespit edilir.Faaliyet sonrası Yazılım Gereksinimleri Özellikleri (SRS – Software Requirements Specification) dokümanını hazırlar müşterilerimizle paylaşırız.
Bu aşamada yazılımın genel tasarım kararları verilir ve mimari tasarımı yapılır. Faaliyet sonrası Yazılım Tasarım Tanımı (SDD – Software Design Description) dökümanını hazırlar müşterilerimizle paylaşırız.
Bu aşamada yazılım kodlama, birim test, revizyon ve yeniden test faaliyetleri gerçekleştirilir. Yazılım geliştirme esnasında kullandığımız yaklaşımlardan biri de sürekli entegrasyondur. Sürekli entegrasyon (Continuous Integration = CI), kod üzerinde yapılan her değişikliğin ardından, tüm sistemin çalışır durumda olduğunu, yapılan değişikliğin sistemin bazı bölümlerinde kırılmalara yol açmadığını tespit etmek için kullanılan bir yöntemdir. Kırılmaları tespit edebilmek için birim testlerine ihtiyaç duyulmaktadır. Bu testler, yapılan değişikliğin neticesi olarak yeni bir yapı (build) hazırlandıktan sonra otomatik olarak çalıştırılır. Yapılan değişiklik yeni yapının bir parçası olduğu için, testlerde oluşan hatalar, yapılan değişikliğin sistemi kırdığı anlamına gelmektedir. Bu durumdan tüm programcılar haberdar edilerek, hatanın bir an önce giderilmesi ve testlerin her zaman olumlu sonuç vermesi sağlanır. Sürekli entegrasyon ile programcılar tarafından kod üzerinde yapılan çalışmalar neticesinde her zaman çalışır bir sürümün oluşması sağlanmış olur.
Faaliyet sonrası Yazılım Test Tanımı (STD – Software Test Description) dokümanını hazırlar müşterilerimizle paylaşırız.
Bu aşamada tüm yazılım bileşenlerinin ileride sistemleri oluşturmak için başka yazılım bileşenlerine entegrasyonu ve bu entegrasyonun başarılı olabilmesi için gerekli testleri gerçekleştiririz. Yapılan testler başarılı olduğunda sistem entegrasyon testi adımına ilerler, başarısız olursa da ilgili yazılım bileşenlerinde revizyona gider yeniden test yaparız.
Faaliyet sonrası Yazılım Test Raporu (STR – Software Test Report) dokümanını hazırlar müşterilerimizle paylaşırız.Faaliyet sonrası Yazılım Test Tanımı (STD – Software Test Description) dokümanını hazırlar müşterilerimizle paylaşırız.
Bu aşamada tüm yazılım bileşenlerinin (subsystem) bir arada çalışarak işlevleri kontrol edilmektedir.
Tüm testlerden başarı ile geçmiş yazılımlar için versiyon değişikliklerini gözden geçirir kullanıcıların yazılımı kullanımı ile ilgili eğitim ve dokümantasyonları hazırlar yazılımı kurarak devreye alırız.
Faaliyet sonrası aşağıda listelenmiş doökümanları hazırlar müşterilerimizle paylaşırız:
Sürüm Tanım Dokümanı (VDD – Version Description Document)
Kullanıcı Kılavuzu (UM – User Manual)
Yapılandırma yönetimini gerçekleştirmek için Collabnet Subversion (SVN) ve SubversionEdge yazılımları – Kaynak kod deposu ve depo yönetimi olarak kullanılacak web tabanlı yazılım araçları kullanılmaktadır. SVN ile yazılım yapılandırma öğelerinin (ör: kaynak kod dosyaları) sürümleri takip edilir.
[-M veya -RC]
Bu şema 3 adet bileşen içerir:
“major” numarası yazılımdaki köklü değişiklikler, yeni bir ortama uyarlamalar sonrası artırılır,
“minor” numarası yeni bir özellik eklendiğinde arttırılır,
“micro” numarası ise bir hata giderildiğinde veya önemsiz bir değişiklik yapıldığında artırılır.
Bu numaralar sonrası opsiyonel bir etiket de sürümün olgunluğunu belirtmek için kullanılır:
M (Milestone), değişiklik listesi bir sonraki milestone (M) sürümüne kadar güncellenebilir, sürüme yeni özellik eklenebilir veya çıkarılabilir anlamına gelmektedir. Yapılacak oylama sonuncu milestone (M) sürümü ilk release candidate (RC) sürümü olarak seçilebilir.
RC (Release Candidate), değişilik listesi kilitlenmiştir, tasarımda ciddi bir sorun tespit edilmedikçe bu sürüm için artık yeni bir özellik eklenemez veya çıkartılamaz. Bu etiket sürümün sadece var olan yazılım hatalarını gidermek üzere odaklandığını belirtir. Yapılacak oylama sonucu sonuncu release candidate (RC) sürümü ile general availability (GA) sürümü olarak seçilebilir.
Herhangi bir ek etiketin olmaması GA (General Availability) anlamına gelir. GA, sürümün yeterince kararlı olduğunu ve production ortamına yüklenebileceğini bildirir. GA etiketini yazmaya gerek yoktur. Ek etiket olmayan sürüm numarası kararlı sürüm olarak değerlendirilir.
Sürüm numaralandırma şeması ile ilgili örnekler aşağıda verilmiştir:
2.0.0-M1 -> 2.0.0-M3 -> 2.0.0-M3 -> 2.0.0-M4 – 2.0.0-RC1 -> 2.0.0-RC2 -> 2.0.0-RC3 – 2.0.0 -> 2.0.1 -> 2.0.2 -> 2.1.0-M1 …”
