Yazılım Mühendisliği Nedir?
Yazılım mühendisliği karmaşık yazılım sistemlerinin belirli bir hedefe ve sisteme dayalı olarak ve işbölümü yapılarak, belirli prensipler, yöntemler ve araçlar kullanılarak geliştirilmesidir.Yani yazılım mühendisliği yazılım geliştirme ile ilgilenen bilim dalıdır.Yazılım geliştirmenin yanında yazılımı işletmek de yazılım mühendisliğinin en önemli görevlerindendir.
Yazılım Mühendisliği Süreçleri
Karmaşık yazılımları geliştirmek ve bakımını yapmak çok masraflı ve zordur. Bu yüzden, yazılımlar yazılım mühendisleri tarafından nizami olarak planlı bir proje şeklinde geliştirilmektedir. Bu nizami geliştirme planına yazılım geliştirme süreci adı verilmektedir. Yazılım geliştirme süreci, zamanlamaya dayalı, içerik olarak bölünmüş ve görselleştirilmiş aşamalardan oluşmaktadır. Bu sayede yazılım adım adım ve planlı bir şekilde geliştirilmektedir. Bu aşamalar birbirleri ile bağlantılı olarak geliştirilmektedir.
Planlama: Yazılım yaşam döngüsünün ilk aşamasıdır. Temel ihtiyaçlar belirlenir, proje için fizibilite çalışmaları yapılır (maliyetlerin ve sistemin yararlarının tanımlanması) ve proje planlaması gerçekleştirilir.
Analiz: Bu aşamanın amacı sistemin işlevlerini ve kesin gereksinimleri açıklığa kavuşturmak ve sonucunda bunları belirli bir formatta dokümante etmektir. Bu çalışma müşteri, yazılım mühendisi, sistem analisti, iş analisti, ürün yöneticisi vb. rollerin bir araya geldiği gruplar tarafından yapılabilir. İhtiyaçların net olmadığı durumlarda yazılım mühendisi ve müşteri arasında iletişim ve birlikte çalışmanın çok daha fazla olması gerekir. Çeşitli yazılım geliştirme metodolojilerinde bu aşamada kullanım dokümanları ve test plan dokümanları da oluşturulabilir.
Tasarım: Gereksinimlerin tamamlanmasıyla beraber sistem tasarım aşamasına başlanır. Yazılım ürün tasarımı, müşterinin gereksinim ve isteklerini karşılamak üzere yazılım ürününün özellikleri, yetenekleri, ve arayüzlerinin belirlenmesi etkinliğidir. İki tür tasarımdan bahsetmek mümkündür (Yüksek düzeyde tasarım – Mimari tasarım ve Detaylı tasarım).
Mimari tasarım, yazılım modüllerinin genel yapıları ve organizasyon içerisindeki etkileşimleri ile ilgilenir. Sonucunda mimari tasarım dokümanları oluşturulur. Detaylı tasarım aşamasında Mimari tasarım dokümanları genelde revize edilirler. Tasarım ve analiz aşamalarının ayrımı “Problem Ne?/Problem Nasıl Çözülür?” sorularının kullanımı ile ilgilidir. Gereksinimlerin belirlendiği analiz aşaması problemin ne olduğu ile ilgilidir. Unutmamak gerekir ki sistemdeki tüm problemler yazılım ürününün tamamlanması ile çözülmeyecektir. Maalesef çoğu zaman Ne söylemi tasarım kararı olurken Nasıl söylemi de müşterinin gereksinimi olabilmektedir. Bu duruma dikkat etmek gerekir.
Yazılım tasarımında kullanılan en önemli tekniklerden birisi Soyutlama (Abstraction) dır. Soyutlama, problemlerin çözümlerini kolaylaştırmak için nesnelerin, olayların ve durumların bazı özelliklerin görmezden gelinmesidir. Problemi basitleştirerek en önemli kısımlarına odaklanmamızı sağlar. Modelleme ise temel tasarım aracı olup statik ve dinamik modellerden bahsetmekten mümkündür. Statik model, programın çalışması sırasında değişmeyen yönlerini ifade etmek için kullanılırken (sınıf ve nesne modelleri), dinamik model programın çalışması sırasındaki işleyişi ifade etmek için kullanılır ( durum ve sıra diyagramları).
Gerçekleştirim (Kodlama ve Test)
Tasarım aşamasının belirli bir olgunluğa ulaşmasıyla birlikte kodlama aşaması başlar. Müşteriye teslim edilecek ürünü programlama aşamasıdır. Kaliteli kodlama üzerine önümüzdeki yazılarda bayağı kafa yoracağız. Şimdilik kısaca değinelim. İyi kod, okunabilirliği ve bakımı kolay olan basit koddur. KISS (Keep it simple) prensibine göre yeni mezun olmuş birisine kodunuzu verdiğinde 1-2 gün içerisinde anlayabiliyor ve değiştirebiliyorsa kodunuz iyi bir koddur. İster bir şirkette çalışın ister bireysel projeler geliştirin mutlaka belirli bir kodlama kalite standardınız olsun (İsimlendirme standartları, yorum satırı kullanımları, tekrar eden kodlar, dev –if koşul blokları, aşırı benzer işlevler, uzun metotlar vb.)
Kodlama süresince ve kodlama sonrasında yapılan diğer önemli aşama test’tir. Erken test et yaklaşımı ile (early testing) hareket edip, analiz aşamasından itibaren test bakış açısına sahip olmamız hata yapma oranımızı ve maliyetleri (zaman, para, prestij vb.) düşürecektir. Birim testleri, duman testleri, yanlış değer testleri, kabul testleri, kullanım senaryo testleri, yük testleri, kullanıcı kabul testi, yoldan geçen adam testi, test otomasyonu gibi sürece ve duruma göre uygulanabilecek çok farklı kategoride ve derinlikte test türü bulunmaktadır.
Teslim ve Bakım
Tüm test aşamaları tamamlandıktan sonra yazılım ürünün sahaya teslim edilebilir bir versiyonu çıkartılır ve teslim aşaması gerçekleştirilir. Teslim çıktısı olarak ürün tek başına yeterli değildir. Mutlaka son kullanıcılar için kullanım kılavuzu ve versiyon fark dokümanı oluşturulmalıdır. Teslim ile birlikte bakım aşaması da başlar. Hata giderici, önleyici, altyapıyı iyileştirici, ürüne yeni özellikler ekletici gibi farklı bakım faaliyetleri mevcuttur.
Yazılım Geliştirme Modelleri
Waterfall: Basit ve kolay yazılım programları için uygundur. Yazılım
şirketleri bu modeli kullanarak uygulama geliştirdiklerinde, her bir
bölüm ardışık olarak yapılır, her bölümden sonra gerçekleştirilen
bölümün sonuçları gösterilir. Fakat waterfall model uzun süreli projeler için uygun olmamakla beraber,esneklik sağlamamaktadır.
Spiral: Bu modelin temelinde, yazılım geliştirme süreci boyunca risk analizi önemlidir. Bu modelde,her bir klasik waterfall modeli, çok sayıda iterasyona bölünür ve her iterasyonda planlamayı ve risk analizini inceler. Bu modelde bir yazılım
geliştirildiği zaman, her bir iterasyonda bir çıktı elde edilecektir ve
bu çıktılar elde edilirken belirli riskler altında
gerçekleştirilecektir. Bu modele uyum sağlamanın maliyeti oldukça
fazladır.
V-Shape: Waterfall
modeline çok benzemektedir, temel farkı onaylama sahası ve test
işlemidir. Testlere dökümantasyon bölümünde başlanır, integrasyon
süresince, kodlamada ve yazılım ürünün testinin gerçek gerçekleştiriminde devam edilir. V tasarımı, ileriye yönelik test yapılmasını sağlar.
Iterative: Yazılım
şirketine, yazılım geliştirme döngüsünün erken bölümlerinde hataların
bulunmasına ve çözülmesine olanak sağlayan bir modeldir. Böylece
geliştirme süreci daha etkin olacaktır. Bundan dolayı yaşam döngüsü
birçok parçaya bölünür ve süreçlerin kontrolü küçük parçalar üzerinde
yapılır. Bu model sayesinde, ilk iterasyon tamamlandığında, yazılımın
basit bir ürünü elde edilir.
Agile Development: Temel
olarak iterative modele benzer, insan faktörünü kullanarak geliştirme
sağlar. Geliştirme süreci boyunca, yazılım takımının geri dönüşlerinden
yararlanılır.
Agile Geliştirme ve Scrum
Agile(Çevik yazılım Geliştirme) dünyada kabul edilmiş en hızlı ve en güvenli yazılım geliştirme metodları arasında yer almaktadır. Sık aralıklarla, parça parça yazılım teslimatını ilke olarak edinmiştir. Agile; değişimi, takım iletişimini, parça parça oluşan yazılım teslimatını, test odaklı yazılım geliştirmeyi ve uyumlu planlamayı teşvik etmektedir.
Yazılımcıların projelerde karşılaştığı sorunlardan
- Teknolojinin çok hızlı gelişmesi ve bu yeniliklerin projeye uygulanamaması
- Müşterilerin proje başlangıcında büyük resmin tamamını yani bütün gereksinimleri ortaya koyamamaları
- Müşterilerin gereksinimlerinin çok çabuk ve sık değişmesinden dolayı müşterilerin güncel ihtiyaçlarına cevap veremeyen bir yazılım ortaya çıkması
- Projelerin yönetiminin gittikçe daha zor ve karmaşık hale gelmesi (bir yazılım geliştirme sürecinde 102 ayrı role'un olduğunu duymuştum)
Manifestonun açıkca belirtiği gibi Agile geliştirme sürecinin amacı; plan, dökümantasyon, proses ve araçlardan ziyade müşteri memnuniyeti, çalışan yazılım, uyumlu yazılım geliştirme takımı ve müşteri isteklerinde oluşan değişikliklere göre kısa zamanda geliştirilebilecek yazılımlar üretmek (buradan Agile yazılım geliştirmenin plansız, dökümansız yazılım geliştirmeyi teşvik ettiği sonucuna varmamak gerekiyor çünkü Agile yazılım geliştirme sadece bunlardan daha önemli kavramların olduğunu vurguluyor). "Agile yazılım geliştirme" süreçlerin, dökümanların ve dizaynların proje başlangıcında tümüyle tanımlanmasını değil, geliştirme aşamasında karşılaşılan ve değişen koşullara göre gerekli kararların verilmesi gerektiğini savunuyor.
Scrum'u Agile yazılım geliştirme metodunun yukarıda bahsettiğimiz presiplerine uygun olarak geliştirilmiş ve tasarlanmış bir metod olarak tanımlayabiliriz.Scrum diğer agile yöntemleri gibi çok fazla kuralı olmayan, sadece belirli prensipleri olan ve kolayca projelere uygulanabilecek bir yöntem.
Scrum'ı sadece yazılım geliştirmek için değil hayatta karşılaşabileceğiniz her türlü olaya uygulanabilecek bir yöntem olarak düşünebilirsiniz.
1- Roller (Roles)
- Ürün Sahibi (Product Owner)
- Scrum Yöneticisi (Scrum Master)
- Takım Üyesi (Team Member)
- Sprint Planlama (Sprint Planning)
- Sprint gözden geçirme (Sprint Review)
- Günlük Scrum toplantısı (Daily Scrum)
- Ürün gereksinim dökümanı (Product Backlog)
- Sprint dökümanı (Sprint Backlog)
- Sprint kalan zaman grafiği (Burndown Chart)
Gereksinimler belirlendikten sonra yazılım geliştirme takımı Sprint planlama toplantısında bir sonraki Sprint'de geliştirilmek üzere ürün gereksinim dökümanından ürün sahibinin belirlediği yüksek öncelikli gereksinimleri seçerek Sprint dökümanına aktarırlar. Bu toplantıya Scrum yöneticisi, ürün sahibi ve takım üyeleri katılırlar ve Sprint süresi en az 2 en fazla 4 hafta olarak belirlenir.
Sprint planlama toplantılarını Scrum yöneticisi yönetir. Scrum yöneticisinin asıl görevi Scrum'un temel prensiplerinin projeye uygulanmasını, bu prensiplerin takım üyelerince doğru şekilde anlaşılmasını sağlamaktır. En önemli görevi ise Sprint süresince takımı dışardan gelebilecek etkilere karşı korumak ve takımın ihtiyaçlarını karşılamaktır.
Scrum her Sprint'in sonunda mutlaka ürün sahibine kullanabileceği bir yazılım sağlamayı hedefler, bundan dolayı planlanan Sprint süresi (2-4 hafta) asla uzatılmaz. Fakat eğer bir gereksinim belirlenen Sprint süresi içerisinde gerçekleştirilemeyecekse bir sonraki Sprint'e aktarılabilir. Ve aynı şekilde eğer Sprint süresi bitmeden Sprint dökümanındaki gereksinimlerin hepsi tamamlanmışsa ürün gereksinim dökümanından yeni gereksinimler Sprint dökümanına aktarılabilir.
Sprint planlama toplatısında belirlenen gereksinimler takım üyelerince küçük görevlere (tasks) bölünerek takım üyelerine geliştirilmek üzere atanır. Scrum takımı geleneksel yazılım geliştirme süreçlerinden farklı olarak kesin rollere (architect, tester, developer, disagner vb.) sahip değildir. Scrum takımındaki bütün üyeler çapraz görevlerde yer alabilirler, böylece kodun tek bir kişiye bağımlılığı riski ortadan kaldırılmış olur. Sprint dökümanının sahibi bu sefer ürün sahibi değil yazılım geliştirme takımıdır, dolayısıyla bu dökümana ürün sahibi değil takım üyeleri katkıda bulunurlar.
Sprint dökümanına aktarılan gereksinimlerin tahmini geliştirme süresi saat bazında takım üyelerince belirlenir ve Sprint boyunca sürekli olarak tahmini bu zamanlar güncellenerek Sprint kalan zaman grafikleri (burndown chart) oluşturulur. Böylece Sprint süresince ürün sahibi ve scrum yöneticisi Sprint'in genel gidişi hakkında bilgi sahibi olur, aynı zamanda takım elemanları da kalan iş sürelerini ve harcadıkları zamanı takip edebilirler.
Scrum'un belki de verimliliği artıran en önemli kavramlarından biri de günlük Sprint toplantılarıdır. Bu toplantılar her gün belirli saatlerde farklı bir takım üyesinin liderliğinde ayak üstü yapılır ve en fazla 15 dakika sürer. Bu toplantılarda her takım üyesi şu 3 soruya cevap verir;
- Dün ne yaptım?
- Bugün ne yapacağım?
- Önümde olan engeller ve karşılaştığım sorunlar neler?
Her Sprint'in bitiminde ortaya konulan ürün hakkında geri besleme alabilmek için yazılımla alakalı her türlü kişiye (Ürün sahibi, pazarlama, diğer takımlar vs.) açık Sprint gözden geçirme toplantısı yapılır. Bu toplantının amacı yazılımın ürün sahibinin gereksinimlerine uygun olarak geliştirildiğinden emin olmaktır. Bu sayede müşterinin gereksinimleri bir şekilde yanlış anlaşılmış ise bu farkedilir ve bir sonraki Sprint'de bu hataların önüne geçilir.
Bu adımlar ürün sahibinin ürün gereksinim dökümanına yazdığı, zaman içinde geliştirip, değiştirdiği gereksinimler bitene kadar tekrarlanır.
