Yazılım Geliştirme – Genel Tanımlar

Yazılım Projesi Genel Tanımlar: Yazılım: Bilgisayar programları ve gereksinimler, tasarım hedefleri, kullanıcı kılavuzları gibi tüm dokümanlar. Yazılım ürünleri başlıca iki sınıfa ayrılabilir: - Genel (Generic): Çok sayıda ve farklı müşteriye satılması için geliştirilen yazılımlar. Ör: Excel veya Word gibi PC yazılımları, çizim paketleri - Özelleştirilmiş (Customized): Bir müşterinin belirledi ğ i spesifikasyonlara göre geliştirilmiş, müşteriye özel yazılım. Ör: Hava trafik kontrol sistemi yazılımı, hastane randevu sistemi yazılımı Gitgide daha fazla yazılım şirketi genel bir sistemle başlayıp, müşterinin gereksinimlerine göre ürünü uyarlama yoluna gitmektedir. Ör: SAP 2

İ yi bir yazılımın özellikleri Bakım Kolaylı ğ ı (Maintainability): Yazılım, müşterilerin de ğ işen gereksinimlerine uyarlanacak şekilde yazılmalıdır. Güvenilirlik (Dependability): Yazılım güvenilir olmalıdır (reliable, secure and safe). Etkinlik (Efficiency): Yazılım, bellek veya işlemci gibi sistem kaynaklarını boşu boşuna kullanmamalıdır. Kullanılabilirlik (Usability): Müşteri yazılımı rahat kullanabilmelidir. Gerekli dokümantasyon ve kullanıcı arayüzleri düzgün olmalıdır. 3

Yazılım Süreci (Software Process) Yazılım süreci: Bir yazılımı geliştirmek için kullanılan aktivite kümesi. Yazılım süreçleri: - Yazılım gereksinimlerinin/isterlerinin belirlenmesi (Software specification): Müşteriler ve yazılımcıların kısıtları ve gereksinimleri belirledi ğ i adım. - Yazılım tasarımı (Software design): Yazılımın tüm donanım ve yazılım özelliklerinin tasarlandı ğ ı adım. - Yazılımı geliştirme (Software development): Yazılımın tasarlandı ğ ı biçime göre programlandı ğ ı adım. - Yazılımı do ğ rulama/test (Software validation/test): Yazılımın müşterinin isteklerini yerine getirip getirmedi ğ inin kontrol edildi ğ i adım. - Yazılımın devamı/bakımı (Software evolution/maintenance): Yazılımın de ğ işen müşteri ve pazar gereksinimlerine göre uyarlandı ğ ı adım. 4

Yazılım Lisans Türleri - Tescilli yazılım (Proprietary Software/Closed Source Software) - Açık kaynak kodlu yazılım (Open Source Software/OSS) -GPL (General Public Licence) -BSD (Berkeley Software Distribution) 5

Yazılım Lisans Türleri: GPL - GPL (General Public License) = GNU GPL - GNU Projesi: 1983, Richard Stallman, ‘free software, mass collaboration’ - ‘Free(dom) Software’ - Copyleft lisansı: Bir programı veya başka bir çalışmayı, tüm de ğ iştirilmiş ve genişletilmiş sürümleri ile birlikte özgür yapmak. Bu kavram GNU tarafından Genel Kamu Lisansı (General Public License-GPL) ile garanti altına alınmaktadır. - PERL: 1989’da GPL altında piyasaya çıktı. - GPL yazılımları ücretsiz olmak zorunda de ğ ildir. (Çok büyük bir kısmı ücretsiz.) - Genel yaklaşım: Yazılımdan de ğ il, kullanıcıya sunulan kurulum, e ğ itim, yönetim ve ek modüller yazma süreçlerinden para kazanılması. - Ör: Linux, Apache HTTP Web Server 6

Yazılım Lisans Türleri: BSD - BSD (Berkeley Software Distribution) - İ zin veren özgür yazılım lisansları sınıfında yer alır. - Yazılımın da ğ ıtımı ile ilgili, copyleft lisansında olmayan ufak kısıtlamalar getirir. - Orijinal BSD, Unix benzeri bir işletim sistemi olan Berkeley Software Distribution için kullanılmıştır. - Orijinal BSD lisansı zaman içinde revize edilmiştir. - Özgür Yazılım Vakfı tarafından, GPL’e uyumlu bir lisans olarak benimsenmiştir. 7

0. Adım: Planlama Adımı Planlama adımı, ihtiyaç analizi ile iç içe geçmiş bir adımdır. Mutlaka kullanıcıyla beraber yapılmalı ve her iste ğ in bir maliyeti oldu ğ u kullanıcıya anlatılmalıdır.  Şirketin nasıl bir yazılım projesine ne zamana kadar ihtiyacı oldu ğ u sorusuna genel bir cevap aranır.  Projenin hangi kaynaklarla gerçekleştirilece ğ i belirlenir.  Projenin hedef kitlesi olan kullanıcı ve türleri belirlenir.  Projede nelerin yapılıp, nelerin yapılmayaca ğ ı belirlenip, sınırlar çizilir.  Yapılacak işlerin sırası ve işlerin süreleri belirlenir.  Proje insan kaynakları planlanır. Kimler hangi görevleri yapacak, ayrıntılarıyla belirlenir.  Proje maliyet planı yapılır. Yapılan her işlemin yaklaşık maliyet ve faydası proje başlangıcında belirlenir.  Yazılacak projenin var olan projelerle birlikte çalışma şeklinin planlanması gerekir.  Proje teknik ayrıntıları planlanır.  Projede özellikle riskli ve de ğ işebilecek kısımlar belirlenir ve bu de ğ işikliklerin maliyet hesabı yapılır. 8

1. Adım: İ htiyaç/ İ ster/Gereksinim Analizi (Requirement Analysis) - 1 Müşteri ihtiyaçlarının ve sistemden beklentilerinin ayrıntılı şekilde tanımlanmasıdır. Bir ihtiyaç aşa ğ ıdaki özellikleri taşımalıdır:  Gerçekleştirilebilirlik (Feasibility)  Do ğ rulanabilirlik: Objektif veya ölçülebilir kriterlerle do ğ rulanabilir (valid) olmalıdır.  Tam anlaşılabilir: Belirsiz, birden fazla manaya gelecek ifadelerden kaçınılmalıdır.  Çözümleri de ğ il, istekleri ifade etmeli  Tutarlılık (Consistency): Di ğ er ihtiyaçlarla tezat oluşturmamalıdır.  Sistem hiyerarşisinde do ğ ru yerde tanımlanmalıdır. Sistemin genel özellikleri analiz edilirken tek bir özellik için çok fazla ayrıntının araştırılması bütünlü ğ ü bozar ve gereksiz zaman kaybına yol açabilir. 9

1. Adım: İ htiyaç/ İ ster/Gereksinim Analizi(Requirement Analysis) - 2 İ htiyaç analizi için gerekli bilgiyi nasıl toplayabilirim?  Kullanıcılarla görüşmek: Yazılım talep eden kişiler, yöneticiler, son kullanıcılar ile. Toplantı veya tek tek görüşme. Toplantıda en fazla 5-6 kişi.  Benzer uygulamalardan ve İ nternet’ten yararlanmak  Müşterinin halihazırda kullandı ğ ı yazılımı inceleyip, eksik/sorunlu noktaları idrak etmek  Müşterinin halihazırda kullandı ğ ı raporları, belgeleri, yönetmelikleri incelemek  Analiz yaparken şekiller (diyagramlar) kullanmak Kullanıcının her sözü önemlidir. Bazen tek bir cümle, hatta kelime, hatta noktalama işareti, proje analizinde geniş çaplı de ğ işikliklere sebep olabilir. Bir yazılım projesi, kullanıcıyı yazılım geliştirme ekibinin bir parçası haline getirdi ğ i ölçüde başarılı olacaktır. 10

2. Adım: Sistem Tasarımı (System Design) Yapılan analizin, yazılım geliştirme araçlarının imkan, kural ve sınırları dahilinde bir modele dönüştürülmesi. İ htiyaç analizinden farkı: Analiz ihtiyaçları anlamaya, tasarım ise çözüme yöneliktir. Do ğ ru olan, her aşamanın ayrı ayrı belgelenmesidir. 11

3. Adım: Sistemin Gerçekleştirilmesi (System Implementation) Fiziksel veri yapılarının veritabanında oluşturulması, kodların, kullanıcı arayüzlerinin ve raporların yazılması gibi işlemleri içerir. Bu aşamada veri modeli de oluşturulaca ğ ından, verilerin ilk andaki büyüklü ğ ü belirlenir. İ leride nasıl büyüyece ğ i ile ilgili beklentilere göre tabloların, indekslerin veri dosyalarına nasıl yerleştirilece ğ ine de karar verilir. Test: Yapılanların kontrol edilmesi. Yazılım geliştirmenin her adımında oldu ğ u gibi, bu adımda da belgeleme çok önemlidir. Veri modelinin belgelenmesinde, veriler üzerinde işlem yapılırken dikkat edilmesi gereken kurallar, veri türleri, de ğ er listeleri, de ğ er aralıkları, test senaryoları gibi bilgilerin olması gereklidir. Di ğ er tüm fonksiyonlardan önce, veri modeli sa ğ lamlaştırılmalıdır. Test, deneme yanılma de ğ ildir. Deneme yanılma yöntemi, programcılıkta tercih edilecek bir yöntem de ğ ildir. 12

4. Adım: Sistemin Devamı/Bakımı (System Evolution) Test aşaması tamamlandıktan sonra kullanıcı e ğ itimleri verilmesi ve nihai projenin kurulmasından sonraki destek çalışmalarını içerir. Veri miktarındaki artışla, ani performans düşmeleri veya hatalar, başlangıçta daha sık görülmektedir -> Sistemi ilk başlarda daha dikkatli izlemek gerek! Sonrasında da, sistemi sürekli izlemek ve yeni isteklere göre uyarlamak gerekir. 13

Yazılım Geliştirme Süreci

Yazılım Geliştirme Süreci Modelleri (Software Development Process Models) Kullanıcının ihtiyaçlarını anlamak (requirement analysis), çözümleri tasarlamak (design), yazılım dilleri ile ifade etmek (implementation) ve yazılımın bakımı gibi birbirleriyle ilişkili birçok adım... Birçok yazılım geliştirme modeli olsa da, başlıca dört model sayılır:  Ça ğ layan/şelale modeli (Waterfall model):  Ça ğ layan/şelale modeli (Waterfall model): Süreci başlıca dört bölüme ayırır: İ htiyaç analizi, yazılım tasarımı, uygulama ve bakım.  Evrimsel geliştirme (Evolutionary/Iterative development):  Evrimsel geliştirme (Evolutionary/Iterative development): Yazılımın ihtiyaç analizi, tasarımı ve uygulaması içiçe geçmiştir. Müşteriden gelen ilk taleplerle, hızlıca bir sistem geliştirilip, müşteri talepleriyle şekillendirilir.  Bileşen esaslı geliştirme (Component-based software engineering):  Bileşen esaslı geliştirme (Component-based software engineering): Daha önceden geliştirilmiş çok miktarda bileşen bir araya getirilerek yeni yazılım oluşturulur. Yazılım geliştirme süreci, daha ziyade bileşenleri bir araya getirme üzerine yo ğ unlaşır.  Kitle kaynak (Crowdsourcing):  Kitle kaynak (Crowdsourcing): Gereksinimlerin ilan edilip, bir kurum veya kişinin önerece ğ i çözümü beklemek. 15

Şelale Modeli (Waterfall Model/ Sequential Model) - 1 İ htiyaç analizi Sistem ve yazılım tasarımı Uygulama ve birim testleri Entegrasyon ve testleri Bakım 16

Şelale Modeli (Waterfall Model) - 2 Her aşamanın sonuçları bir veya daha fazla dokümanla belgelenir. Bir önceki aşama bitmeden, bir di ğ er aşama başlamamalıdır. (Paralel olarak ilerlemez.) Şelale modelinin dezavantajları: Süreç ilerlerken, de ğ işiklikler yapmanın zor olması. Bir aşama bitmeden di ğ er bir aşamanın başlayamaması. İ htiyaçların ilk başta ve eksiksiz belirlenmesi gereklili ğ i. Sadece ihtiyaçların çok iyi bilindi ğ i ve de ğ işiklik yapılmasının pek beklenmedi ğ i durumlar için uygun. Şelale modeli genelde, birden fazla mekanda, aynı anda geliştirilen büyük ölçekli ve karmaşık yazılım projelerinde kullanılır. 17

Evrimsel Geliştirme (Evolutionary Development) Basit bir uygulama yazıp, kullanıcıdan gelen yorumlara göre bu uygulamayı iyileştirmek, de ğ iştirmek. Yazılım tamamlanana kadar birçok versiyon olur. Sorunlar:  Sürecin ileri evreleri genelde öngörülemez.  Genelde geliştirilen sistemlerin ana yapısı sa ğ lam de ğ ildir.  Farklı araçlar (ör: Hızlı prototip tasarlamak için gerekli programlama dilleri) gerekebilir.  Proje yöneticileri, ilerlemeyi görebilmek için, düzenli olarak rapora gereksinim duyarlar. Hangi durumlarda uygulanabilir?  Küçük ve orta büyüklükteki etkileşimli (interactive) sistemlerde.  Büyük sistemlerin bazı bölümlerinde (ör: Kullanıcı arayüzü tasarlama).  Kısa ömürlü sistemlerde Büyük sistemlerde, şelale ve evrimsel geliştirme modelleri birlikte kullanılmalı ve ikisinin de en iyi yönleri ortaya çıkarılmalıdır. 18

Bileşen esaslı geliştirme (Component-based software engineering) Daha önceden yazılmış bileşenler, sistematik bir biçimde yeni projelerde de kullanılır. Sürecin adımları:  Bileşen analizi (Component analysis)  İ htiyaçların düzenlenmesi (Requirements modification)  Tekrar kullanılan bileşenlerle sistem tasarımı (System design with reuse)  Geliştirme ve entegrasyon (Development and integration) Gittikçe daha fazla kullanılan bir model... 19

Kitle kaynak (Crowdsourcing) - Competition-based software development approach - Ör: TopCoder 20

Yazılım Maliyetleri - 1 Yazılım maliyetleri, genelde donanım maliyetlerinden daha fazla tutar. Özellikle uzun ömürlü sistemlerde, yazılım maliyetlerinin büyük bir bölümü geliştirmeye de ğ il, bakıma gider. Yazılım mühendisli ğ inin amacı, en az maliyetle en etkin yazılımı geliştirmektir. Kabaca, yazılım geliştirme maliyetinin %60’ı geliştirme adımına, %40’ı ise test adımına gider. 21

Yazılım Maliyetleri - 2 Yazılım maliyetleri yazılım geliştirilirken kullanılan modele göre de ğ işir. 22

Yazılım Maliyetleri - 3 Özelleştirilmiş (customized) bir yazılım geliştirme sürecine ait maliyetler: 23

Computer-Aided Software Engineering (CASE) Tasarım sırasında kullanılan metodları otomatikleştirmek ve yazılımcıların tekrar tekrar yapmak zorunda kaldıkları işleri yaparak maliyeti azaltan yazılımlar. CASE araçları, düzgün bir dokümantasyon üretilmesini ve ekip içindeki çalışanların koordinasyonunu kolaylaştırır. CASE araçları, otomatik olarak çalışan çizelge, diyagram ekran çıktısı, rapor veri sözlü ğ ü, gelişmiş raporlama araçları, kod üreticileri ve doküman üreticilerinden oluşur. Asıl amaçları: Verimlilik ve kaliteyi arttırmak. Ör: UML, Rational,... 24

TopCoder : Developing Software through Crowdsourcing

Ortaya Çıkış yılında kurulmuş. - Kurucusu Hughes’nun, önceki şirketindeki sıkıntıları: - İ şe alım süreci: Maliyetli ve çok vakit harcatan bir süreç. İ stenilen kalitede programcıları de ğ erlendirmek zor. - En donanımlı programcının bilgisi bile, 1-2 sene sonra zayıflayabiliyor. Sektör içinde yo ğ un bir devirdaim var. - Her bir programı sıfırdan yaratmak yerine, programların bileşenlerini yeniden kullanarak, müşterinin maliyetini de düşürmek mümkün olabilir. 26

Yazılım geliştirme için “çift taraflı bir platform” ortaya çıkarmayı hedefliyor: 1. Müşteri tarafı: Yazılıma ihtiyacı var. 2. Programcı tarafı: Para kazanmak için bir yarışma dahilinde birbiriyle yarışan programcılar. TopCoder bu iki tarafın ortasında konumlanacak TopCoder en çok parayı, müşterinin problemini anlayıp, problemi bileşenlere bölme adımından kazanıyordu. Ama bu sayede tekrar kullanılabilecek bileşenlerden oluşan bir katalog oluşturdular Platform manager’ların yaptı ğ ı işler arasında: Problemi anlama, isterleri çıkarma, bunları bileşenlere bölme, sonrasında da, bileşenleri bir araya getirip hata ayıklama işlemleri var. 2008’de bu işleri de community’e yaptırmaya başladılar sonlarında, TopCoder iki tip yarışma düzenliyordu. 1. Algoritmalar 2. Müşteri yazılımı geliştirme.

yılları arasnda, TopCoder her sene yaklaşık yeni programcıyı bünyesine katarak ilerledi TopCoder 8 senede toplam 20 milyon $ ödül da ğ ıttı, ancak bunun üyeler arasıdaki da ğ ılımı tabii ki eşit de ğ il. Ödülün %80’ini, community’nin %5’i alıyor. Bazı üyeler çok başarılı. Örne ğ in Paweska adlı bir üye senede $ kazanıyor Üyelerin bir di ğ er para kazanma şansı da Digital Run. Digital Run sisteminde, her yarışmanın sonunda en iyi 5 kişi belirleniyor ve onlara yüksek puanlar veriliyor. Her ayın sonunda, TopCoder üyeleri sıralıyor ve yüksek puan alanlara binlerce dolar bonus teşvik da ğ ıtıyor. Bunu kazanmak için en iyi olmak de ğ il, düzenli olarak yarışmalara katılıp ilk 5’e girmek gerekiyor

Ortaya Çıkış yılında kurulmuş. - Kurucusu Hughes’nun, önceki şirketindeki sıkıntıları: - İ şe alım süreci: Maliyetli ve çok vakit harcatan bir süreç. İ stenilen kalitede programcıları de ğ erlendirmek zor. - En donanımlı programcının bilgisi bile, 1-2 sene sonra zayıflayabiliyor. Sektör içinde yo ğ un bir devirdaim var. - Her bir programı sıfırdan yaratmak yerine, programların bileşenlerini yeniden kullanarak, müşterinin maliyetini de düşürmek mümkün olabilir. 29

30