YAZILIM MÜHENDİSLİĞİNİN TEMEL İLKELERİ

Transkript

1 YAZILIM MÜHENDİSLİĞİNİN TEMEL İLKELERİ BÖLÜM 1: YAZILIM MÜHENDİSLİĞİNİN KAPSAMI Yazılım nedir? Bilim mi? Endüstri mi? Mühendislik mi? Sanat mı? Yazılım en yalın biçimiyle, bir sistemin donanım bileşenleri dışında kalan herşey olarak tanımlanabilir. Yazılımın Temel Bileşenleri = Mantık + Veri + Belge + İnsan + Program. Yazılım mühendisliği, adından da anlaşıldığı gibi bir mühendisliktir. Fakat hemen belirtilmelidir ki, yazılım mühendisliği, diğer tüm mühendislik alanları bir yana kendisi bir yana dedirtecek kadar farklı bir mühendislik alanıdır. Çünkü diğer mühendislik ürünleri birer fiziksel nesne iken, yazılım mühendisliğinin son ürünü kavramsal bir eserdir. Yazılım, diğer fiziksel ürünleri çalıştırır yönetir, kendisi değişik fiziksel ortamlarda bulunabilir. Diğer mühendislik alanları insanlığa sunabilecekleri imkânlar bakımından maddenin fiziksel sınırlamalarına bağlı iken, yazılım mühendisliği adeta bir sanat dalı gibi sunabilecekleri sadece insan zekâsı - başka bir deyişle insan yaratıcılığı- ile sınırlı olan bir mühendisliktir. Bugün için yazılım, otomobil ve uçak gibi ulaşım araçlarından tıp dünyasına, iş makinelerinden ev aletlerine, oradan askerlik, haberleşme ve eğitime kadar günlük hayatın hemen her alanını kontrol etmeye başlamıştır

2 Rekabet Gücü Unsurları: Verim, Kalite, Zamanlama (time to market) Yazılımın Mühendislik olması için; Standartlara dayanması gerekir. (kalite standartları, verimin standartları) Ölçülebilir olması gerekir. (kalitenin ölçülebilmesi, verimin ölçülebilmesi) Yazılım Mühendisliği nedir? Müşterinin ihtiyaçlarını karşılayan, öngörülmüş bütçe ile zamanında teslim edilen ve hatasız bir yazılım geliştirmek için teknik yöntemler öngören bir disiplindir

3 Tarihsel gelişim açısından bakıldığında; 1950 ler ve 1960 larda yazılım mühendisliği sadece programcılık olarak ele alınmıştır. Yazılım Krizi ilk olarak 1968 de bir NATO Konferansında dile getirilmiştir. ABD de 1970lerde kamu tarafından sipariş yolu ile satın alınan yazılım ürünlerinin ancak % 5 i kabul edilip kullanılabilmiştir, % 40 ı hiç kullanılamamış, geri kalanı ise maliyet artışı, zaman artışı, performans eksikliği veya bazı özelliklerinden taviz verilerek kullanılabilmiştir. Yazılımın yoğun kullanımı 1980 lere rastlamışsa da 1990 lara kadar büyük projelerde başarı oranı çok düşük kalmıştır. Hedef: Yazılım Krizini çözmek... Yazılım Mühendisliği kavramının ortaya çıkışında rol alan problemler; Ürünün geç teslim edilmesi. Öngörülen bütçeyi aşmak. Müşterinin ihtiyaçlarını tam manasıyla karşılayamamak

4 Yazılım krizi çözülememiştir. Yazılım krizi çözülemediği için buna yazılım depresyonu dendi. Çünkü bu çok uzun zaman almış ve öncü sınamalar kötü sonuçlanmıştır

5 Bir örnekle anlatmak gerekirse; CM NEW diye bir kodlama metodu var. (CM NEW Yeni bir programlama dili olabilir.) Bu kodlama metodu şu anda kullanılan metottan %10 daha hızlı olduğunu savunuyor. Soru : Bu kodlama metodunu kullanır mıydınız? Genel Cevap : Evet! Fakat bir yazılım mühendisi bu cevabı verirken aşağıdaki koşulları göz önünde bulundurmalı; Bu yeni kodlama metodu için eğitim maliyeti, Yeni teknolojiyi tanıtmanın olumlu veya olumsuz etkileri, Yeni metot ile geliştirilecek bir ürünün, sisteme yerleştirildikten sonra bakımının yapılması gerek, bu bakım yapılırken, bakımın maliyeti müşteri için daha fazla olacaktır. Bunun etkilerinin düşünülmesi gerekli

6 Yaşam Döngü Modeli; yazılım geliştirilirken takip edilecek safha ya da adımlardır. Teorik olarak ne yapılacağının tanımlanmasıdır. Safhaların sayısı ve niteliği modelden modele değişir. Belirli bir ürün üzerinde yapmış olduğumuz gerçek işlemlerdir

7 1. Requirements Phase: Elimizdeki problemin ne olduğunu anlamaya çalışıyoruz. Yapılan işi anlamaya çalışıyoruz. Müşterinin gereksinimlerini topluyoruz. Müşterinin gereksinimlerini belirle. Müşteri ne istiyor, ihtiyaçları neler. 2. Analysis (Specification) Phase: Toplamış olduğumuz gereksinimleri analiz ediyoruz. Analizin sonucunu şartname dokümanı olarak yazıyoruz. (Software ne yapacak) Müşterinin ne istediği değil, neye ihtiyacı olduğunu tesbit etmeye çalışıyoruz. Ayrıca müşteri ürün tesliminde ben bunu istemedim diye itiraz etmesi durumunda, bu döküman kullanılarak müşteriye isteklerinin ne olduğu gösterilir. Yazılım Proje Yönetim Planında bütün detaylarıyla yapacaklarımızı yazıyoruz. Ürünün tam olarak ne yapması isteniyor. Bu soruya cevap bulmaya çalışıyoruz

8 3. Design Phase: Tasarım safhası boyunca 2 tür tasarım yapılır. İlk olarak Mimari (Architectural) Tasarım yapılır. Kabataslak sistemin mimarisini gösteren bir plan çizilir. Sistemi modüler olarak bölmek gerekmektedir. Yani sistemin mimarisini bir ağaç olarak düşünüp daha küçük parçalara, modüllere bölerek çalışmalıyız. Daha sonra Ayrıntılı (Detailed) Tasarım yapılır. Burada da veritabanı tespit edilmeli ve ne tip algoritmaların kullanılacağı belirlenmelidir. 4. Implementation Phase: Herbir modül için kod yazıyoruz. (Coding) Herbir modülü birbirinden bağımsız olarak test ediyoruz. (Unit testing) Sistemin bir bütün olarak çalışması gerekmektedir. Bu yüzden bütün modülleri birleştiriyoruz. Modülleri birleştirirken sorun ve yanlışlıklar çıkabilir. Bunu test ediyoruz. (Integration testing) Gerçek veriyi kullanarak sistem test edilir. Kabul testi müşteri tarafından yapılır. (Acceptance testing) - 8 -

9 5. Postdelivery Maintenance: Teslim sonrası sistemde yapılan herhangi bir değişikliğe Teslim Sonrası Bakım (Postdelivery Maintenance) denir. Teslim sonrası bakımın iki çeşidi vardır: Düzeltici Bakım (Corrective Maintenance): Sistemdeki hataları düzeltmek için yapılan bakım (software repair). Özellikleri Artırılması (Enhancement) diğer bir deyişle yazılım güncellemesi (software update), şartnamede (specification) yapılan değişiklikleri ve bu değişikliklerin mevcut yazılıma uyarlanmasını içerir. Bu uyarlamanın iki çeşidi vardır; Bunlardan birincisi müşterinin düşünceleri doğrultusunda ürünün yararlılığını arttırmak için kullanılan Mükemmelleştirici Bakım (Perfective Maintenance) dır. İkincisi ise ürünün çalışma ortamında meydana gelen değişikliklere karşı yapılan Uyarlanabilir Bakım (Adaptive Maintenance) dır. 6. Retirement: Yazılım vadesini doldurduğunda, yazılımı emekliye ayırırız, elimizden çıkarırız

10 Klasik bakım, zamana bağlı olarak yapılan bir bakımdır. Önce sistem geliştirilir, sonra zamanla bakım yapılır. Teslimden sonra sistemi geliştirirken de bakım yapılabilir. Bu geçici tanımdır. Çünkü bir faaliyetin icra edilmesine bağlı olarak, klasik bakım veya klasik geliştirme olarak sınıflandırılabilir

11 Bir sisteme yazılım ürünü kurulduktan 1 gün sonra, bir hata ya da yanlış tespit edip düzelttiğimizde, buna klasik bakım (classical maintenance) diyoruz. Sisteme yazılım ürünü kurmadan 1 gün önce, bir hata ya da yanlış tespit edip düzelttiğimizde, buna klasik geliştirme (classical development) diyoruz

12 Örneğin; yazılım install oldu. Müşteri de ürünün fonksiyonlarını arttırmak ve güncellemek istiyor ya da yeni bir fonksiyon ilavesi istiyor. Bu Classical (perfective) Maintenance dır. Müşteri daha kurulum yapılmadan önce birşeyler değiştirmek isterse, bu Classical Development dır. *** Bir yazılım geliştirilirken müşterinin gereksinimlerinde sürekli değişiklik olursa buna moving target (değişen hedef) problemi denir

13 Genel olarak zamana bağlı olarak yapılan bakım olarak tanılayabiliriz. Moving target problemin dışında diğer problemler ise; Artık hiçbir sistem sıfırdan başlamamaktadır. Mevcut olan yazılımlar kullanılarak sistemler oluşturulmaktadır. Yeniden kullanımın yaygın olmasıdır. Bu nedenle bakım terminolojisi kullanıcıyı caydırır. Bu da daha modern bir bakımın tanımını doğurur

14 1995 te International Standarts Organization (ISO) ve International Electrotechnical Commission (IEC) bakımın artık zaman bağlı olmamasını, işlevsel olarak yapılmasını belirtmiştir. Artık bakım şöyle ifade ediliyor; Herhangi bir zamanda, herhangi bir nedenle yazılım bileşenlerine bir şey ilave edilecekse, ya da yeniden düzenlenecekse, bu işlemi gerçekleştiren süreç bakım olarak tanımlanmaktadır. Artık zamana bağlı değil, Hatayı düzeltme, adaptasyon, güncelleme için önce veya sonra kavramı yoktur

15 - 15 -

16 Soru: Kötü bir yazılıma mı yoksa iyi bir yazılıma mı bakım yapılır? İyi bir yazılıma bakım yapılır. Kötü bir yazılımı kullanmak istemeyiz. Bu nedenle kötü yazılımları atarız. Soru: Neden her zaman bir bakım söz konusu? Yazılım, sürekli değişen bir gerçekliğin modelidir. İyi bir yazılımın bakımdan geçmesi doğaldır. Yaşayan yazılımlara bakım yapılmazsa sistem genişleyemez

17 Teslim sonrası bakımın maliyeti artmış Şaşırtıcı şekilde, klasik evreler maliyetleri güçlükle, değiştirmiştir

18 Eski sorumuza dönersek; CT OLD mu yoksa CT NEW mi (%10 daha hızlı) daha iyi? Eğer kodlama da %10 luk bir zaman kazanımı varsa toplam kazanç % 0,85 dir. % 34 * % 25 development = 8,5 % % 10 * % 8,5 = 0,85 % Toplam Kazanç; Bu yüzden yatırım yapmaya değmez. Eğer kodlamada değilde teslim sonrası bakımı % 10 azaltacak deseydi; % 10 * % 75 = % 7,5 Toplam Kazanç Alınırdı. Çünkü iyi bir yatırım olurdu. Yazılım Mühendisi ekonomik faktörleri göz önünde tutmalıdır

19 Bir hatayı ne kadar erken bulup düzeltirsek, bize maliyeti daha düşük olacaktır. Yazılım geliştirme süreci boyunca herhangi bir iş akışında (workflow) yapılan bir hatanın maliyeti düşünüldüğünde bu durumu maliyetin en yüksek olacağı iş akışından en düşük olacağı iş akışına göre doğru sıralarsak; Teslim Sonrası Bakım > Uygulama > Tasarım > Analiz > Gereksinim Büyük bir ekmek fırınının otomasyonundan sorumlusunuz. Yazılımın geliştirilme (Development) maliyetinin $ olacağı tahmin edilmektedir. Yazılımın teslim sonrası bakımı (Postdelivery Maintenance) için yaklaşık ne kadar paraya ihtiyaç olacaktır? (Sorunun çözümü için Şekil-1- deki grafikten yaralanabilirsiniz.) $ * 75 / 25 = $

20 - 20 -

21 Yazılım yaşam çevrimi (life cycle) içinde, bir hatayı ne kadar erken tespit edip düzeltirsek, bize fiyatı maliyeti o kadar düşük olacaktır. İlk aşamada yapılan çalışmalar kâğıt üzerinde olduğu için, hatalar daha ucuza mal oluyor. En son aşamada olursa daha pahalıya mal oluyor. Eğer yazılım yaşam çevrimi içinde hata geç fark edilirse; Dokümantasyon ve kod değişir. Değişikliklerden dolayı ürün yeniden test edilecektir. Regresyon testi yeniden icra edilir. Müşterinin bilgisayarına ürün yeniden kurulur. Bu büyük bir maliyet getirir. [Regresyon Hatası (Regression Fault): Bir programın herhangi bir bölümünde yapılan değişiklikten dolayı, o değişikle alakası olmayan başka bir bölümün etkilenmesi sonucu oluşan hataya regresyon hatası denir.]

22 Büyük ölçekli yazılım ürünlerinde hataların % 60 ile % 70 arasında; gereksinimler, analiz ve tasarım aşamasında yapılan hatalardan meydana geldiği belirlenmiştir. Örnek: Jet Propulsion Laboratory yapmış olduğu incelemelerde - Şartnamelerin sayfa başına başına 1,9 nun, - Tasarımın sayfa başına 0,9 nun, - Kodlamanın sayfa başına 0,3 nün hatalı olduğu tespit edilmiştir

23 Sonuç olarak, hataları en ön saflalarda bulmalıyız. Özellikle maliyeti azaltmak için, olabildiğince hatayı erken tespit etmeliyiz

24 Donanımı ucuza satın alabiliriz. Ama yazılım pahalıdır. Büyük programları yazmak, uzun zaman gerektirir. 1 kişi ile yazılım projesi geliştirmek kolay değildir. Bunun için yazılım projesi gruplara bölüştürülmelidir. Bunun avantajı; zaman azalır, maliyer düşer. Dezavantajı ise; sistemi modüler olarak düşünürsek, bir gruptaki kişilerin projeyi paylaşması gerekecek. Bundan dolayı modüller arasında parametre sorunları yaşanabilir. Parametrelerin sayısı ve tipi aynı olmalıdır. Bir diğer dezavantaj ise grup üyeleri arasında iletişim problemleri olabilir

25 Projenin başlangıcında plan yapılmaz. Çünkü ne yapacağımızı bilmiyoruz. Ancak gereksinimler belirlenip şartname dokümanı oluşturulduktan sonra planlama yapabiliriz. Projenin başında kaba taslak planlama yapıyoruz. Buna preliminary planning (kaba taslak planlama) denir. Şartname müşteri tarafından imzalandıktan sonra Yazılım Proje Yönetim Planı (Software Project Management Plan) yapılır. Yönetici, proje boyunca SPMP ye ihtiyaç duyar. - Projede çalışacak kişi sayısı, - Testler (hangi testlerin olacağı), - Ayrılacak zaman ve bütçe gibi bilgileri izler, kontrol eder

26 Sonuç olarak planlama aktiviteleri yazılım yaşam döngüsü boyunca tamamlanacaktır. Ayrı bir planlama safhası yoktur. Testi, geliştirme safhasından sonra ya da yazılımı müşteriye teslimden önce yapmak oldukça zordur. Özel bir test safhası yoktur. Test işlemi her safhanın sonunda yoğun bir şekilde yapılır

27 Her safhanın sonunda test yapılır. Bu test işlemine verification (doğrulama) denir. Projenin sonunda, müşteriye ürünü teslim etmeden önceki testing işlemine ise validation (sağlama) denir

28 Yazılım yaşam döngüsü boyunca sürekli olarak test aktiviteleri devam ettirilmelidir. Problemin çözümü için uğraşan herkesin test yapması gerekir. Özel bir kalite güvence grubu oluşturulup, bunlara test ettirilmelidir. Test için ayrı bir safha yoktur

29 Dokümantasyon içinde durum aynıdır. Ayrı bir belgeleme safhası yoktur. Dokümantasyon her zaman güncel olmalıdır. Projenin başından itibaren dokümantasyona başlanmalıdır. Neden Devamlı dokümasyon: Projenin başındaki bireyler, proje tamamlandan ayrılabilir. Bir önceki aşamanın dökümü olmadan bir sonraki aşamaya geçilmez. Dokümantasyon olmadan test yapamayız. Dokümantasyon olmadan bakım yapılmaz

30 Sonuç olarak dokümantasyon aktiviteleri bakım ve diğer geliştirme aktivitelerine paralel olarak icra edilmelidir. Ayrı bir dokümantasyon safhası yoktur

31 1975 ile 1985 yılları arasında, yazılan programların daha az hatalı olması amacıyla, bir grup teknikler ortaya atılmıştır. Buna tekniklere structured (classical paradigm) denilmektedir lerde programların boyutları büyüktü ve bu programlamlar aynı zamanda oldukça da başarılıydılar. Ancak 1980 lerde yazılan ürünlerin den fazla satıra sahip olması üzerine bu paradigm büyük programlarda iyi sonuç vermedi ve başarısız olmaya başladı. Bu structured paradigm ın başarısız olmasının nedeni hem dataya, hem de process lere birlikte önem vermemesidir. Hiçbir metot bu ikisine bir önem vermiyor. Kullanılan metotlar bu yüzden başarısız

32 Çözüm: İkisine birden önem vermek... Object: Hem data (veri), hem de o data (veri) üzerinde çalışacak olan faaliyetleri birleştiren bir yazılım bileşenidir. Örnek: Bank Account Banka Hesap uygulamasını ele alalım. - Data (veri): Account Balance (Hesap Bakiyesi), - Actions (Faaliyetler): Depozit (Depozito), Withdraw (Para çekmek), Determine Balance (Kalan Bakiye)

33 a) Classical Paradigm b) OO Paradigm - b de para çekmek, depozito,... vs. için mesaj çekiyoruz. Mesaj gönderen Object in içini göremiyor. Sadece istekte bulunuyor

34 - a da, dairenin çevresinin kesintili olmasının nedeni verilerin herbiri daire içindeki verilerle iletişim halinde ve birbirini görebiliyor olmasıdır. Fakat herhangi bir noktada oluşan en ufak hata, bütün verilerde etkili olacaktır. - b de bilgiler saklanmış olduğundan dolayı böyle bir sorun yok. b de karşılaşılan olaylar; Information Hiding Responsibility-Driven Design Impact on maintenance, development

35 Information hiding ile data görünmediğinden için postdelivery maintenance daha güvenlidir. Farkında olmadan yapılan hatanın olasılığını (regression fault) azaltıyor. Development daha kolaydır. - Obje lerin genellikle fiziksel karşılıkları vardır. - Modelleme kolaylaşıyor. (Tasarım kolaylaşıyor.)

36 Eğer object ler daha iyi daha design edilirse, birbirinden bağımsız birimler olacaktır. - Gerçek dünyadaki object ile ilişkili olan herşey object de modelleniyor. (encapsulation) - İletişim mesaj-alıp verme ile oluyor. - Bu bağımsızlık responsibility-driven design tarafından sağlanıyor

37 Classical product temel olarak, tek bir birimden meydana gelir. OOP, karmaşıklığı azaltır. Çünkü, product ın birimleri birbirinden bağımsızdır. Bağımsız olduğundan bakımı kolaydır. Object ler birbirinden bağımsız olduğundan, OOP yeniden kullanımı (reuse) destekler. Reuse: Bir programda kullanmak için geliştirilen bir modülün, başka bir program içinde kullanılabilmesi

38 OOP da mesajla istekte bulunuyoruz. Nasıl gerçekleştirildiğini bilmiyoruz. Sorumluluk Obje ye aittir. Bunu bize sağlayan information hiding dir. Örnek: Chicago da oturan annenize bir çiçek göndereceksiniz. Ama ne çiçekçinin, ne konuştuğunuz kişinin nerede olduğu, ne de teslim yapacak olan kişinin yerini biliyorsunuz. Sonuç olarak, sorumluluk çiçeği getirecek kişiye ait

39 Classical paradigm da analiz ile design arasında keskin bir fark vardır. Modüller design safhasında ortaya çıkıyor. Analiz safhası sistemin ne yapacağı, design safhasında ise nasıl yapılacağı belirleniyor. OOP ise, objeler başlangıçta devreye giriyor, analiz workflow unda modüller ortaya çıkıyor

40 Classical paradigm da analiz safhasında; müşterinin neye ihtiyacı var, ne yapılması lazım sorularına cevap aranırken, Classical paradigm tasarım safhasında; product ı nasıl yapmamız gerektiğinin tespit edilmesi, mimari tasarım için modüllerin tespit edilmesi, ayrıntılı tasarımda da herbir modülün nasıl tasarlanacağı sorularına cevap aranır

41 OOP da Analiz workflow unda; Yapılmak isteneni belirle, Nesneleri belirle. OOP da Tasarım workflow unda; Nasıl yapılacağını belirle, Object leri tasarla. İki paradigm arasındaki fark bir sonraki slayt ta gösterilecektir

42 Classical Paradigm da Implementation safhasında Modülleri kodluyoruz. OOP da ise Implementation workflow unda class ları kodluyoruz... Burada modüller OO Analiz safhasında tanıtılır. Bu analizden tasarıma keskin bir geçiş sağlar. Object ler uygulama (implementation) iş akışı boyunca kodlanır. Tekrar kolay bir geçiş görürüz

43 OOP doğru kullanılmalıdır. Bütün paradigm lar kolaylıkla yanlış kullanılabilir. OOP doğru kullanıldığı zaman classical paradigm da karşılaştığımız bir çok problemi çözer. Tabi OOP bazı sorunları da çözememiştir, fakat şu an için en iyi alternatiftir. Tabi ileride ne olacağı bilinmez

44 Client: Müşteri (yazılım product ını user için yaptıran, satın alan kişi) Developer: Geliştirici (yazılım product ını geliştiren kişiler) User: Yazılım product ını kullanacak kişi. Internal Software (İçsel yazılım): Müşteri ve geliştirici (client & developer) aynı grupta, ya da şirkette ise buna içsel yazılım denir. Contract Software (Sözleşmeli yazılım): Müşteri ve geliştirici (client & developer) farklı grupta yada şirketlerde ise buna sözleşmeli yazılım denir. Commercial off-the-shelf (COTS) software: Bazı yazılım uygulamaları milyonlarca kişi için üretilebilir. Geliştirilen yazılım rafta duruyor, binlerce müşteriye sunuluyor. (MS Office...) Open Source Software: Geliştirilip, ücretsiz olarak dağıtılan yazılımlar. (Linux...)

45 Software (yazılım): Bir bilgisayar sisteminin donanım bileşenleri dışında kalan herşeyi yazılım olarak verebiliriz li yıllarda programlar çok küçüktü. Program: Küçük yazılımlar. Örn: Karakök alan bir program... System: Birçok programı oluşturan yazılım. Örn: İşletim sistemi... Product: Küçük, büyük program... Methodology: Metotların toplamına denir. (1970 lerde kullanılıyordu) Paradigm: Bir süreç ya da model için esas olan örnek. Bir çeşit yazılım geliştirme yöntemi. (1980 lerden sonra kullanılmaya başlandı.) - Object Oriented Paradigm, - Classical Paradigm. Technique: Metotlarda kullanılan teknikler

46 Mistake: Programlardaki hata. Fault: Hatanın (mistake) neden olduğu arıza. Failure: Hata sonucunda gözlenen programın yanlış davranışı. Error: Yanlışın, hatanın derecesi. Defect: Failure, Fault, Eror için kullanılır (eksiklik, kusur) Bug: Program tarafındaki hata

47 Object in veri bileşenleri; - State variable (durum değişkenleri) - Instance variable (Java) (örnek değişkenler) - Field (C++) (alan) - Attribute (generic) (nitelikler) Object in Olay Bileşenleri - Member function (C++) - Method (generic)

48 İyi bir yazılım geliştiricisi ve bakımcısının; Hard working (çalışkan) Intelligent (zeki) Sensible (mantıklı) Up to date and, above all, (modern) ve herşeyden önce Ethical (ahlaklı) olması gereklidir