Ayrıca MySQL işlemlerini SQL adı verilen, veritabanlarına erişmek için kullanılan en yaygın ve standart dil ile yapıyor.

Transkript

1 Veritabanı Tasarımı Uygulamaları Veri Tabanı Veritabanı yada ingilizce database kavramı, verilerin belirli bir düzene göre depolandığı sistemlere verilen genel bir isimdir. Günümüzde özel veya kamu kuruluşların hepsi bünyesinde barındırdıkları bilgileri veritabanında tutarlar. Nüfüs müdürlükleri, bankalar, okul ve üniversiteler kayıtlı olan onca kişi arasından istenen bilgileye saniyeler içerinde ulaşabiliyorsa bu veritabanı sistemlerinin sayesindedir. En yaygın kullanılan veritabanları Server, Access, Oracle ve Mysql dir. MS Sql MySQL Nedir? MySQL bir ilişkisel veritabanı yönetim sistemidir. MySQL in ne olduğunu tam olarak anlamak için veritabanı yönetim sistemi ve ilişkisel veritabanı terimlerini de biliyor olmalısınız. MySQL çifte lisanslı bir yazılımdır. Yani hem Genel Kamu Lisansı na (GPL) sahip özgür bir yazılım, hem de Genel Kamu Lisansı kısıtladığı alanlarda kullanmak isteyenler için ayrı bir lisansa sahiptir. Ayrıca MySQL işlemlerini SQL adı verilen, veritabanlarına erişmek için kullanılan en yaygın ve standart dil ile yapıyor. MySQL in Temel Özellikleri Nelerdir? MySQL UNIX, OS/2 ve Windows platformlarında kullanılabilmektedir. Fakat Linux altında daha yüksek performans sergilemektedir. MySQL içerisinde ODBC sürücüleri de bulunduğu için birçok geliştirme platformunda rahatlıkla kullanılabilir.

2 Farklı karakter setlerini (iso8859-9, utf-8, latin-5 ) ve onlara göre sıralama yapılmasını destekliyor, farklı dillerde hata mesajları verebiliyor. Çok esnek ve güçlü bir kullanıcı kısıtlama/yetkilendirme sistemine sahip. erişim MySQL Nerelerde Kullanılır? Güçlü bir veritabanı yönetim sistemi olan MySQL veritabanı gerektiren hemen hemen her ortamda rahatlıkla kullanılabilir. Ama özellikle web sunucularında en çok kullanılan veritabanıdır, asp, php gibi birçok web programlama dili ile kullanılabilir. Veri Tabanı Yazılım mimarisi Veri tabanı kullanan bilgi sistemi ya da bir işletmen uygulama arayüzü ile sisteme erişim sağlar. Erişim başka yazılım sisteminden yapılacaksa bir dinamik kütüphane ya da bir ileti arayüzü kullanılabilir. Erişim insan tarafından yapılacaksa uygun bir kullanıcı arayüzü bulunur.bu arayüz grafik yapıda olabileceği gibi basit bir komut satırı şeklinde de olabilir. Kullanıcı arayüzünden alınan komutlara göre sistemin tanıyacağı standart bir sorgulama yaratılır ve bunu veri erişim modülüne gönderir. Alt düzeyde bulunan erişim modülü,sorguyu açıp ne tür veri istendiğini ve bu verileri nerede bulabileceğini değerlendirir.bunun için de genellikle ayrı bir tabloda veya bir veritabanı içinde bulunan veri tanımlarını kullanır.buradan aldığı tanımlarla yerel ya da uzak veri tabanlarına erişerek fiziksel saklama yerlerinden verileri toplar,sonuçları sorgulama modülüne ulaştırır.

3 Sorgulama modülü kullanıcının sorgusuna uygun olan verileri süzer ve uygulama arayüzüne verir. SINIFLANDIRMA A-KULLANICI SAYILARINA GÖRE 1-)TEK KULLANICI 2-)ÇOK KULLANICI B-VERİ MODELİNE GÖRE 1-)Hiyerarşik veri tabanı 2-)Ağ veri tabanı 3-)İlişkisel veri tabanı 4-)Düz dosya veri tabanı Tek Kullanıcılı Veri Tabanı Adında da anlaşılabileceği gibi tek bir kullanıcı kullanabilir başka bir kullanıcı aynı anda bir veri tabanını kullanamaz. Günümüze bilgisayar tabanlı veri tabanı yönetim sistemleri de dahil tek kullanıcılı veri tabanı yönetim modeli kalmamıştır. Çok Kullanıcılı Veri Tabanı Bir veri tabanını aynı anda birden fazla kullanıcı kullanabilir.günümüzde kullanılar bütün veri tabanı yönetim modelleri çok kullanıcılıdır. Hiyerarşik Veri Tabanları Veri tabanları için kullanılan ilk veri tabanı yönetim modelidir. Bu veri tabanı yönetim tipi kişisel bilgisayarlarda kullanılmaz. Sadece ana bilgisayarlarda çalışan yazılımlar tarafından kullanılır. Bu tipteki veri tabanına örnek olarak IBM tarafından geliştirilen IMS yazılımını verebiliriz. Bu veri tabanında bilgiler bir ağaç yapısında saklanır ve

4 verilere ulaşmak çok kolaydır. Ağ Veritabanları 1960 yılında toplanan COCDASYL adlı bilimsel bir toplantıda veri tabanı çalışma grubunun ortak çalışmalarıyla hiyerarşik veri tabanın yetersizliğini gidermek için geliştirilmiş veri tabanı yönetim modelidir. Şunu söylemek gerekiyor ki ağ veri tabanları en karmaşık veri tabanı modelidir. İlişkisel Veritabanları Bu model 1970 li yıllarda E. F. Codd tarafından geliştirilmiştir. Bu veri tabanı yönetim sisteminde; veriler tablo şeklinde saklanır. Veri alışverişi için özel işlemler kullanılır ve tablolar arasında ilişkiler belirlenir. Günümüzde en çok kullanılan veri tabanı yönetim sistemidir. Bu modelde veriler tablolar halinde saklanır. Tablolar, satır ve sütunlardan oluşur. Sütunlar bilgi alanlarını, satırlar ise bilgilerin içeriğini belirler. Düz dosya Veritabanı Adından da anlaşılacağı gibi bu veri tabanı modelinde veriler düz mantıkla herşey tek bir dosyada saklanır. İstenilen veriyi bulmak zaman aldığı gibi aynı veriyi tekrar tekrar girilir. Bu dosyaların kalabalık olmasına sebep olur. Bu düz veri tabanına en güzel örnek Word ve Excel de verilerin saklanmasıdır.

5 Sistem Yaşam Süreci Veritabanı sistemleri genellikle daha büyük bilgi sistemlerinin parçası olarak yer alırlar.bu sistemlerinin geliştirilmesi de diğer sistemler gibi aynı süreci izlerler. Sistem yaşam çevrimi: 1-Sistem Tanımı Veri tabanı sisteminin kapsamı,kullanıcıları ve uygulamaları tanımlanır. 2-Tasarım Veritabanı sisteminin mantıksal ve fiziksel tasarımı yapılır. 3-Gerçekleştirim Sisteme ait kavramsal tanımlamalar yapılır içsel ve dışsal veri tanımlama yapılır.boş veritabanı dosyaları yaratılır.yazılım modülleri geliştirilir. 4-Veri Yükleme Veritabanı sistemlerine büyük miktarda veriler ya elle girilir ya da daha önce olan aynı ya da farklı biçimdeki veriler gerekli çevrimler yapılarak aktarılır. 5-Test Oluşturulan sistem kullanıcı isteklerine göre sınanır,doğrulama ve geçerli işlemleri işlemleri yürütülür. 6-Kullanım Sistem kullanıma sunulur. 7-İzleme Sistemin büyüyen veri miktarları sürekli izlenir, fiziksel sınırlar göz önünde bulundurularak düzenlemeler veya

6 kaydırmalar yapılır, yedekler alınır. 8-Bakım Sistem üzerinde zaman içinde değişiklikler uygulanır. değişen isteklere göre Veri tabanı sistem tasarımı Veri tabanı tasarlamaya başlamadan önce ihtiyaç analizinin doğru yapılması gerekmektedir. Veri tabanı ihtiyaç analizi yapılırken hazırlanacak olan sistemin neye hizmet edeceği, veri tabanını ne iş yapacağı ve hangi ihtiyaçları karşılayacağına, veri tabanının hangi verileri depolayacağı, veri tabanını oluşturan tabloların neler olacağı ve ne tür verileri saklayacağı vb. gibi sorulara cevap vermek gerekmektedir. 1-)İsterlerin Belirlenmesi Hedef kullanıcı kitlesi ile uygulama alanı tanımlanır.işletim ortamı,veri bilgi işleme gereksinimleri belirlenir 2-Veritabanı tasarımı Veri tabanı isterlerine göre verilerin yapıları, anlamları, ilişkileri, bağımlılık ve uyulması gereken kısıtlamalar üst düzeyde, kavramsal olarak ve belirli sisteme bağlı olmaksızın modellenir. 3-Veritabanı yönetim sistemi seçimi Eğer veritabanı özel olarak geliştirilmeyecekse, hazır olan kullanımı mümkün olan sistemler arasında teknik ekonomik ya da yönetilen kararlara göre uygun bir veritabanı yönetim sistemi seçilir. 4-Mantıksal tasarım Daha önce oluşturulmuş veri modelleri, seçilen veritabanı

7 yönetim sistemlerine göre kavramsal modellere dönüştürülür. 5-Fiziksel Tasarım Tasarlanan veritabanı fiziksel olarak bir VTYS üzerinde hayata geçirilir. Veritabanının fiziksel olarak saklandığı dosyalar, dizinler hazır olarak kullanılan veritabanı yönetim sisteminin önerdiği şekilde ya da başka nedenlerle daha iyi tasarım elde etmek üzere tasarlanır.burada hedeflenen en iyi erişim zamanı en düşük saklama alanı ve en yüksek veri debisidir. 6-Gerçekleştirim Seçilen veritabanı yönetim sistemine özgü veri tanımlama dili ile yapılan tasarım gerçekleştirilir, derleme yapılır, veri dosyaları oluşturulur, veri girişine hazır hale getirilir. REFERANSLAR Veri Tabanı Yönetim Sistemlerinin Sınıflandırılması %C4%B1m%C4%B1-temel-bilgileri-eb2159cf-1e30-401a-8084bd4f9c9ca1f5https:// ani-cesitleri-nelerdir/ İlişkisel Veritabanı Yönetim Sistemleri (RDBMS) Gereksinim_Analizi

8 Yazılım Geliştirme Pratik Öneriler için 1.Yönetsel Öneriler Proje Yönetimi İnsan Kaynakları Planlaması Maliyet Kestirimi Ve Planlaması Metrik Kullanımı Kazanılmış Değerlerin İzlenmesi Disiplinin Sağlanması 1.1 Proje Yönetimi uyazılım proje yönetimi,yazılım projelerinde kaynakların en etkin biçimde kullanılmasını sağlamaya yöneliktir. Yazılım projeleri diğer projelere benzememekle beraber, yeni bir yazılımın geliştirilmesi veya mevcut yazılımların geliştirilmesinde benzeri deneyimleri paylaşmaktadırlar. Bu kursun amacı genel proje yönetimi kavram, araç, teknik ve sözlüğünü yazılım projeleri özelinde ele alarak yazılım projelerinin başarıyla yönetimini sağlamaktır.etkin proje yönetimi gerçekleştirmek için,insan kaynakları,problem ve yazılım geliştirme sürecindeki işlemler göz önünde bulundurulmalıdır.

9 1.2 İnsan Kaynakları Planlaması Planlama;Hangi tür elemanların,hangi süre ile ve projenin hangi aşamalarında yer alacağını belirler. Şekide verilen görev tanımlarına, içerik sağlayıcılar ya da yazılım projesinin konusuna bağlı olarak gerekebilecek senaryo uzmanları, çoklu ortam uzmanları ve danışmanlar dahil edilmemiştir. Yazılım projesinin boyutuna göre bu görev tanımlarının tümünde görev yapacak elemanlar tam zamanlı olarak ya da parça zamanlı olarak kullanılabilir. Planlama, hangi tür elemanların hangi süre ile ve projenin hangi aşamalarında yer alacağını belirler.süre kestirimlerinin nasıl yapılacağı, Proje Maliyeteleri ile ilgili bölümde anlatılmaktadır. 1.3 Maliyet Kestirimi Ve Planlaması ubir bilgi sistemi ya da yazalım için gerekebilecek iş gücü ve zaman maliyetlerinin yapılan işlemlerdir. üretininden önce belirlenmesi için Kullanılan Unsurlar; * Geçmiş projelere ilişkin bilgiler * Proje ekibinin deneyimler * İzlenen geliştirme modeli birden çok kez uygulanabilir. 1.4 Metrik Kullanımı Yazılım metrikleri, geliştirilen yazılım ürününü ölçekleyebilecek ve ürünün kalitesini kontrol altında altında tutabilmek için nicel gözlem yapabilmeyi mümkün kılacak ölçü birimlerini temsil eder. Yazılan kod satır sayısı, eyclomatic karmaşıklık,fonksiyon noktası, miras derinliği, birleşim, kohezyon, kod satır sayısına düşen hata oranı, bakım indisi gibi metrikler, var olan yazılım projemizin durumu ile ilgili

10 nicel değerler vermesi açısından önemlidir. Yazılım metriklerinin önemini Ölçemiyorsanız, kontrol edemezsiniz. 1.5 Kazanılmış Değerlerin İzlenmesi Sabit bir bütçesi ve süresi olan bir projenin; * Bütçe limitleri içinde yapılmakta olup olmadığını, * Planlanan programlama uygun ilerleyip ilerlemediğini, Bu gidişle projenin ne zaman ve ne kadar maliyetle bitirebileceğimizi önceden haber vererek, proje bitiminde farklı bir durumla karşılamayı önleyen bir proje performans ölçüm ve analiz sistemidir. 1.6 Disiplinin Sağlanması Yazılım projeleri sonuç olarak bireyler tarafından geliştirildikleri için bireylerin yetenek ve çalışma disiplinleri bir projenin başarısında doğrudan etkilidir.yazılım mühendisliği alanında bugüne kadar tasarım, test ve yönetim alanlarında bir çok çalışmalar yapılmakla beraber yazılım geliştirmede bireysel disiplinin üzerine fazla gidilmemiştir.bu alandaki eksiklik ise Watt Humprey in PSP(Personal Software Process) ve TSP(Team Software Process) konularındaki çalışmaları ile giderilmiştir. PSP bireysel TSP ise takım içinde yer alan disiplini belirtir. Açıkça anlaşılabileceği gibi TSP PSP yi kapsar fakat şu gerçek unutulmamalı ki takımlar bireylerden oluşur ve PSP nin önemi buradan anlaşılmaktadır. Takım iki yada daha fazla sayıdaki bireyin oluşturduğu, ortak bir hedef için ve birbirleri ile ilişkili görevleri bulunan gruba verilen isimdir. Yazılım projeleri sonuç olarak bireyler tarafından geliştirildikleri için bireylerin yetenek ve çalışma disiplinleri bir projenin başarısında doğrudan etkilidir.yazılım mühendisliği alanında bugüne kadar tasarım, test ve yönetim alanlarında bir çok çalışmalar yapılmakla beraber yazılım geliştirmede bireysel disiplinin üzerine fazla

11 gidilmemiştir.bu alandaki eksiklik ise Watt Humprey in PSP(Personal Software Process) ve TSP(Team Software Process) konularındaki çalışmaları ile giderilmiştir. PSP bireysel TSP ise takım içinde yer alan disiplini belirtir. Açıkça anlaşılabileceği gibi TSP PSP yi kapsar fakat şu gerçek unutulmamalı ki takımlar bireylerden oluşur ve PSP nin önemi buradan anlaşılmaktadır. Takım iki yada daha fazla sayıdaki bireyin oluşturduğu, ortak bir hedef için ve birbirleri ile ilişkili görevleri bulunan gruba verilen isimdir. 2.Süreçlere yönelik Öneriler İsterlerin Yönetimi Ve İzlenmesi Sistem Tabanlı Yazılım Tasarım Beraber Çalışabilirlik Arayüzlerin Tanımlanması Ve Denetimi 2.1 İsterlerin Yönetimi Ve İzlenmesi Gereksinim yönetimi faaliyetlerinin planlanması, müşteri ihtiyaçlarından başlayarak, gereksinimlerin geliştirilmesi, tanımlanması ve ayrıştırılması, sistem gereksinimlerinin yazılım ve donanıma tahsisi, gereksinimlerin doğrulanması ve geçerli kılınması, temel çizgilerin (baseline) oluşturulması, gereksinimlerin çift yönlü izlenebilirliğinin sağlanması örneklerle aktarılmaktadır. Eğitimde gereksinim özellikleri ve gereksinimlerin yönetimi sürecinin performansının izlenmesi için örnek yöntemler aktarılmaktadır. Eğitim süreçlerin yapılandırılmasında kullanılması gereken ve süreç alt faaliyetlerini tanımlayan IEEE, Mil-Std, DID gibi standartlarla desteklenmektedir.

12 2.2 Sistem Tabanlı Yazılım Tasarım İnternet teknolojilerinin ve sanal piyasanın büyük yükseliş gösterdiği açık bir şekilde karşımıza çıkmaktadır. Bu yükselişte web tabanlı yazılımların önemi çok büyük olduğu gibi, wev tabanlı yazlım uygulamalarının sunduğu fırsatlar da çok fazladır. Bir ev hanımının büyük faydalar sağlayabileceği bir sistem olduğu gibi, büyük şirketlerin de büyük faydalar sağlayabileceği günümüz gelişmiş sistemleri arasında yer almaktadır. 2.3 Beraber Çalışabilirlik Gerek ticari gerekse açık kaynak coğrafi bilgi sunucu yazılımları ile veri sunma ve sunulan bu verilerin, ticari ya da açık kaynak coğrafi bilgi istemci yazılımları ile bir arada karşılıklı olarak kullanılabilmesini sağlama hizmetidir. 2.4 Arayüzlerin Tanımlanması Ve Denetimi Nesne yönelimli programlama dillerinde arayüz, değişik sınıflardan nesnelerin kategorize edilmesini sağlayan bir soyut tür çeşitidir. Tanımlanmakta olan kategorinin birbirleriyle alakasız sınıfları ortak bir çatı altında toplaması nedeniyle, arayüz tanımları, soyut sınıfların aksine, listeledikleri iletilerin gerçekleştirim ayrıntısı olan herhangi bir bilgi içeremezler. Dolayısıyla, bir arayüz tanımı iletilere karşılık gelen bir alt yordam gövdesi veya aldalan tanımı içeremez. Bir başka açıdan bakarsak, arayüz tanımında yer alan programlama öğelerinin zaman içinde değişme olasılığı düşük öğeler olması gerekir. Buna göre, arayüz tanımları gerçekleştirimci ile kullanıcının paylaştığı ve sabit olma özelliği bulunan alt yordam imzaları ile simgesel sabit tanımlarını barındırabilir. 3.Geliştirmeye Yönelik Öneriler Tasarım

13 Tekrar Kullanım İsterlerin Ve Tasarımın Denetlenmesi Gerçekleştirim Sürekli Test Sık Derleme Ve Test Hata Ayıklama Ölçme Süreçi Uygulaması 3.1 Tasarım Algı ile kavram arasında bir bağlama aracıdır. Önemli özelliklere dikkat çeken tasarımın nesnel gerçeklik ile doğrudan ilişkisi yoktur.tasarım bilgi edinme öğesidir. Çünkü duyumsal tasarım ile zihinsel tasarım daima birbirini etkiler. Bu nedenle duyumsal bilgi ile ussal bilgi her zaman iç içedir. Gerçek bilgi ise böylelikle oluşur. Tasarım, yaratıcı sürecin kendisi olup faaliyet için gerekli olan eskiz ve planların hazırlanması sürecindeki çalışmaları kapsamaktadır.tasarım, bir şeyi zihinde biçimlendirme, kurma, tasavvur etmedir.bilgisayar alanında ise araştırma bürolarında, yeni bir ürünün tasarımı için kullanılabilen bilişim tekniklerinin tümü. Veri Tasarım Yapı tasarımı, arayüz ve süreç tasarımından önce ilk yapılması gereken veri tasarımıdır. Bilgi saklama ve soyutlama bu işlem için değerli kavramlardır. Yapısal tasarım Yapısal tasarımın ana hedefi, modüler bir yapı geliştirip modüler arasındaki kontrol ilişkisini temsil etmektedir.ayrıca

14 yapı tasarımı bazen veri akışlarını da gösteren bir içerime de yönelebilir. Genel Tasarım Hedef, yapı diyagramı çizmektir. Veri akış diyagramından yola çıkılarak işlem türlerinin bölgelerini tanımlar ve bu bölgelere karşı düşecek yapısal öğeler ortaya çıkarılmiş olur. 3.2 Tekrar Kullanım Tekar kulllanım esasları Yazılım Geliştirme planında yer almaktadır. Tekrar kullanılacal ürünler, önce proje isterlerinie göre kendi başlarına test edilmelidir. Tekrar kulllanıma esas olacak öğeler, hazır ticari ürünler ve özel üretilmiş birimler gibi geliştirme sürecinde üretilmeyecek alınmalıdır. yazılımlar birer risk unsuru olarak ele Geliştirme süreci dışında temin edilecek öğelerin tekrar kullanımı ancak bu tür öğelerin özel bir denetim sonucu kabul edilmesinden sonra yapılmalıdır. Tasarım sürecinin tüm etkinlikleri Yazılım Geliştirme Planında belirtilen yöntemlere göre yapılmalıdır.ortaya çıkan ürünün özelliklerinin doğrulanması için testler yapılması tasarım standartlarının bir parçası olarak degerlendirilmelidir. İzlenebilirlik, tasarım, gerçekleştirim ve test sırasında devam ettirebilmektedir. Her türlü tasarım düzenleşim yönetim sistemine girmeden önce yapısal bir incelemeden geçirilmelidir. 3.3 İsterlerin Ve Tasarımın Denetlenmesi Geliştirilen yazılım ürünleri düzgün iletişim yönetim sistemi

15 altına alınmadan önce resmi bir test ve denetimden geçirilmelidir. Bundan sonra bu ürünler başka ürünlerin geliştirilmelerinde temel alınırlar. Denetim, yazılım geliştirme planında belirtildiği şekilde, o ürün için geçerli olabilecek kabul esaslarına dayalı bir süre şeklinde yapılamalıdır. 3.4 Gerçekleştirim Gerçekleştirim çalışması, tasarım sonucu üretilen süreç ve tabanının fiziksel yapısını içeren fiziksel modelin bilgisayar ortamında çalışan yazılım biçimine dönüştürülmesi çalışmalarını içerir. APL, diziler ve vektörlerle işlem yapmak için iyi bir gerçekleştirim aracıdır. Matematik problemlerin çözümlerinde bir miktar kullanım yeri bulmuştur. Gerçekleştirm aşaması sonunda, yürütülebilir kod veya dinamik kütüphane şeklinde yazılım birimleri elde edilir.pek çok yerde bu birimlere program denmektedir. 3.5 Sürekli Test Kaliteli yazılımlar, kabul edilebilir düzeyde hatasız, planlanan bütçe ile zamanında bitirilip dağıtılabilen, gereksinimleri ve/veya beklentileri karşılayabilen ve sürdürülebilir özelliklere sahip yazılımlardır. Ancak, kalite terimi kişilere göre oldukça değişebilen bir terim olup müşterisinin kim olduğuna ve tasarımda hedeflenen unsurlara bağlı olarak farklılıklar gösterebilmektedir. Doğal olarak, her kişinin kalite hakkında bireysel eğilimleri veya tercihleri söz konusu olmasına karşın kaliteyi ortaya koyan nesnel yöntemler yansız değerlendirmeleri olanaklı kılmaktadır. Test, bir sistemi manuel veya otomatik yollarla deneyerek veya değerlendirerek, belirlenmiş gereksinimleri karşıladığının doğrulanması veya beklenen ile gözlenen sonuçlar arasındaki farkların belirlenmesi sürecidir. Yazılım testi ise bir yazılımın sonsuz sayıdaki çalışma alanından, sınırlı sayıda ve

16 uygun şekilde seçilmiş testler ile beklenen davranışlarını karşılamaya yönelik, dinamik olarak yapılan doğrulama faaliyetlerini kapsamaktadır. 3.5 Sık Derleme Ve Test Ana sistem testleri tamamlandıktan sonra hedef sistem testleri olabildiğince kısa sürede yapılamlıdır.bu şekilde, sık derleme ve üretme bulunması sağlanır. Test sistemi üzerinde en küçük yazılım yapısı oluşur. Oluşmaz testlere başlanmalıdır. Bu maksatla kullanılacak yazılımlar sık sık derlenip üretilmelidir. 3.5 Hata Ayıklama Test aşaması için kapsamlı test senaryoları hazırlanmalı ve her senaryo mutlaka sonuna kadar çalıştırılmalıdır. Bu şekilde, olası yazılım kusurlarının varlığının belirlenmesine çalışılmalı, kusur belirlendikten sonra temizleme aşamasına geçilmelidir. Testler kötümser bir yaklaşımla yapılandır ki kusurlar ortaya çıksın. Yakalanan her kusur ileride olası bir yazılım hatasına engel olacaktır.hata ayıklama sırasında yeri belirlenen yazılım kusurunun giderilmesi sırasında yeni bir kusur katılması yüksek bir olasılıktır.bu nedenle kusurlar birer birer ele alınmalı, çok fazla değişiklik yaparak birden fazla kusuru bir defada gidermeye çalışılmamalıdır.çoklu programlama ortamlarında hata ayıklama son derece güçtür.bu tür ortamlar tasarlanırken modüllerin ayrı ayrı test edilebilmelerine olanak tanınması çok önemlidir. 3.6 Ölçme Süreçi Uygulaması Örgüt içerisindeki herkesin ölçme sürecinin yeteneklerini ve kısıtlarını anlaması sağlanmalıdır. Metriklerin bir anlam ifade edebimesi için herkesin ölçülelen verilerin ne anlama geldiğini hakkında aynı düşünceye sahip

17 olması gereklidir. Önce küçük hedeflerle işe başlanmalı, yalnızca birkaç temel ölçüm kullanılmalı ve etkileri kontrol edilmelidir. 4.Niteliği Artırmak İçin Öneriler İşlevsel Nitelik Güvenilirlik Bakım Kolaylığı Kullanışlı Sistem Geliştirme 4.1 İşlevsel Nitelik İşlevlerin tutarlılığı ve doğru uygulanması isterler çözümlemesi aşamasından başlayarak yönetilmelidir. Ürün mümkünse ayrı işlevlere sahip, ayrı bileşenler halinde geliştirilmeli ve her bileşen ayrı bir ürün gibi kabul edilerek kullanıcı memnuniyeti ölçülmelidir. 4.2 Güvenilirlik Bir uygulamanın her seferinde aynı girişler için aynı çıkışları vermesine güvenilirlik denir.güvenilirlik için; Veri kaybı mümkünse sıfıra indirilmelidir. Veri tabanı kısıtları ile hatalı veri girişi engellenmelidir. Yazılım mantık hatalarından arındırılmalı ve yazılımın nondetermenistik (beklenmeyen) hareketler yapmasının önüne geçilmelidir. Hata yakalama prosedürleri çalıştırılmalı ve yazılımın kesilmesi yerine uygun hata mesajları sunulmalıdır.

18 4.3 Bakım Kolaylığı Bakım,işletime alınan yazılımın sağlıklı olarak çalişması ve ayakta tutulabilmesi için yapılması gereken çalişmalar bütünü olarak tanımlanır. Ürün bileşenlerinin bakım kapsamında yer alacak değişiklikleri sorunsuz içerebilmeleri için tasarımda ekler yapılmalı, esnek tasarımlar geliştirilmelidir. Tasarım sırasında, problemin yalnızca bugünkü şeklini çözmeye değil, gelecekteki gerelsinimlerini de karşılamak hedeflenmelidir. 4.4 Kullanışlı sistem Geliştişme İlk öncelik, sürekli kaliteli yazılım teslimatıyla müşteri memnuniyetini sağlamaktır. Proje ne kadar ilerlemiş olursa olsun değişikler kabul edilir. Mümkün olduğunca kısa zaman aralıklarıyla (2-6 hafta arası) çalışan kaliteli yazılım teslimatı yapılır. Analistler, uzmanlar, yazılımcılar, vs. Tüm ekip elemanları bire bir iletişim halinde, günlük olarak birlikte çalışır. Ekip içerisinde kaliteli bilgi akışı için yüz yüze iletişim önemlidir. Çalışan yazılım projenin ilk gelişim ölçütüdür. Çevik süreçler mümkün olduğunca sabit hızlı sürdürülebilir geliştirilmeye önem verir. Sağlam teknik alt yapı be tasarım çevikliği artırılır. Basitlik önemlidir. En iyi mimariler gereksinimler ve tasarımlar, kendini organize edebilen ekipler tarafından yaratılır.

19 Düzenli aralıklarla ekip kendi yöntemlerini gözden geçirerek verimliliği artırmak için gerekli iyileştirmeleri yapar. İyi projeler motivasyonu yüksek bireyler etrafında kurulur. Ekip elemanlarına gerekli destek verilmeli, ihtiyaçları karşılanarak proje ile ilgili tam güvenilmelidir. Referanslar etimi Yazılım mühendisliği Ali Arifoğlu

20 Proje yönetimi Giriş Proje, belirli bir başlangıç ve bitiş noktası olan, amacı, kapsamı, bütçesi açıkça tanımlanmış ve bir defaya mahsus olarak gerçekleştirilen planlanmış aktiviteler bütünüdür. Proje, tanımlanabilen bir sorunun çözümüne yöneliktir. Proje, bir sonuca ulaştırılması gereken, özgül, dinamik, süreli bir değişim sürecidir. Proje yönetimi zaman içinde planlamacıların maliyet denetimi, zaman çizelgesi geliştirme, kaynak planlama, risk yönetimi gibi teknikleri geliştirip proje çalışmalarına dahil

21 etmeleriyle ortaya çıkmıştır. Yönetimin, etkinliklerin insanlar tarafından etkin bir şekilde yapılmasını sağlayan süreç olduğunu kabul ederek, modern yönetim örgütleri proje yönetiminin avantaj kazandırdığını keşfettiler. Proje yönetimi sayesinde müşterilere daha iyi ve daha hızlı ürün veya hizmet verilebilmektedir. Proje nedir? Belirli amaçları gerçekleştirmek üzere sistemli ve düzenli bir şekilde yapılanmış insan gruplarına örgüt(organization) denir. Örgütler iş yapmak üzere kurulur. İş genelde işletim ve projeleri kapsar. İşletim ve projelerin ortak özellikleri arasında sonlu kaynak kullanmaları, süreçlerle tanımlanabilmeleri, yürütülmeleri ve denetlenmeleri sayılabilir. planlanıp İşletimler sürer, gider ve tekrarlanırlar projeler ise geçici ve özgündürler. Proje, belirli bir başlangıç ve bitiş noktası olan, amacı, kapsamı, bütçesi açıkça tanımlanmış ve bir defaya mahsus gerçekleştirilen etkinlikler bütünüdür. Projenin mutlaka bir sonu vardır. Sürekli devam etmez ve bütünüyle tekrar etmez. Proje boyutları çok büyüdüğünde, birden fazla proje içerdiğinde ve ürün belli bir takvime göre tekrarlanarak uygulama gereksinimi olduğu durumda proje program haline dönüşür. Program, ilgili projelerin tek tek yürütülmesi yerine daha üst düzeyde bir yönetim altında ve eşgüdümlü bir şekilde yürütülmeleri durumunda daha fazla yarar sağlaması amacıyla oluşturulur.

22 Proje yönetimi Proje yönetimi, etkinliklerin insanlar tarafından ve insanlar üzerinden etkin ve verimli bir şekilde yapılmasını sağlayan süreçtir. Bu süreci tanımlayabilecek modern proje yönetimi bilimi 1950 li yılların sonlarında ortaya çıkmıştır. İlk başlarda inşaat ve mühendislik alanlarında kullanılmıştır, daha sonra giderek genişleyerek sağlık, eğitim, medya gibi alanlarda da etkin biçimde kullanılmaya başlanmıştır. Oluşturulan projeler tek bir birimi ilgilendirebileceği gibi, aynı anda farklı birimleri de kapsayabilir. Çapraz örgüt yapıları gerektirebilir. Proje yönetiminin bir başka tanımı ise bölüp yönetmek ve birleştirip denetlemektir. Proje yönetimi iş süreçlerini planlamada ve denetimde daha iyi iletişimin sağlanabileceği örgüt yapılarını kullanır. Bu sayede yapılması gereken etkinlikler, karşılaşılabilecek riskler, var olan kısıtlar ve başarı kıstasları bütün örgüt tarafından doğru anlaşılır ve zorluklara karşı bir takım halinde karşı koyma olanağı oluşmuş olur. Üst yönetim ise, projenin hedefleri doğrultusunda kaynakların ne kadar etkin ve verimli kullanıldığını projenin her adımını izleme imkanı bulmuş olur. Proje hazırlarken başarısızlığa götürecek her türlü etmen ve koşulların ortadan kaldırılmasına çalışılmalıdır. Bu kapsamda aşağıda belirtilen önlemlerin alınması gerekir : Tüm proje yaşam süresince doğru zamanda doğru karar alma disiplini sağlanmalıdır. Proje sonuçlarını etkileyen firma, kurum, devlet politikaları gibi iş ve dış kaynaklı politikalar dikkate alınmalı ya da proje bu politikalara uygun hale getirilmeye çalışılmalıdır.

23 Projede belirlenen hedefler, projeden yarar sağlayan gruplara veya müşterilere sürdürülebilir hizmet sağlamalıdır. Çevresel ve toplumsal değerlerin korunması dikkate alınmalıdır. Teknik, yönetsel, maddi ve diğer riskler önceden bilinmeli, önlemler alınmalıdır. Proje hedefleri Her projenin kapsamı ve hedefi olmalıdır. Proje özgün olmalıdır. Hedefler ölçülebilmeli yani istenen niteliğe, kıstasa ve başarı ölçütüne sahip olmalıdır. Projeye gerçekçi ve somut hedefler konulmalı, müşteri tatminini riske sokacak her türlü soyut fikirden kaçınılmalıdır. Ortaya konulan hedeflerin izlenebilirliği sağlanmalıdır. Proje süreci ve Proje başlatılması Kullanıcı daha çok kendi gereksinimlerini içeren bir tanımlamayı bir görev gereksinimi tanımlama belgesiyle ilgili onay makamlarına gönderir. Geliştirici ise, proje hakkındaki ön çalışmalarını bir proje önerisi ile ilgili onay makamına bildirir. Onay makamı kullanıcıdan gelen öneriyi kabul ederse, gerekli

24 bütçe düzenlemesi yaparak bir edinme süreci başlatır. Proje yönetim süreçleri Başlangıç Proje tümleştirme yönetimi Proje kapsam yönetimi Proje zaman yönetimi Proje maliyet yönetimi Proje nitelik yönetimi Proje insan kaynakları yönetimi Proje iletişim yönetimi Proje risk yönetimi Proje edinme yönetimi Kapanış Proje Tümleştirme Yönetimi Proje Tümleştirme Yönetimi, çeşitli proje unsurlarının uygun bir eşgüdüm halinde tümleştirilmesini sağlayan süreçleri tanımlar. Bu yönetim altında; Proje planı oluşturma, Proje planının yürütülmesi, Tümleşik değişiklik denetimi bulunur. ve denetlenmesini

25 Proje planı Proje planı, diğer bir adıyla Proje Yönetim Planı(Project management plan) stratejik planların uygulanabileceği şekilde projenin yürütülmesi ve denetlenmesi ile ilgili planların yer aldığı bir belgedir. Yürütmeyle ilgili çeşitli kılavuzluk bilgileri, tahminler, paydaşlar arası ilişkiler, kısıtlamalar, iş paketleri, temel zamanlamalar, ölçme ve sabitleme için dayanaklar ile gerekli görülen diğer ayrıntılar bu belge içinde tanımlanır. Farklı sözleşme yüklenicileri aynı proje altında çalışıyorsa bu plan tümleşik proje planı adını alır. Proje yönetim management plan) planı(project

26 İş dağılım ağacı (work breakdown structure) İş dağılım ağacı(work breakdown structure), proje kapsamını tanımlayan ve düzenleyen bileşenlerin ürüne veya hizmete göre gruplandırılmasıdır. Genellikle sıradüzensel bir ağaç yapısı şeklinde veya bir liste şeklinde gösterilir. Her öge için maliyet kodu adıyla ayrı bir tanımlayıcı belirlenir. En alt düzeydeki ögeler iş paketi olarak tanımlanır. İş paketi tanımları genelde bir sözlük içinde toplanır ve böylelikle iş paketi tanımları oluşturulur.

27 Proje Kapsam Yönetimi Her türlü projede ilk olarak yapılması gereken ne yapılacağının belirlenmesi yani kapsamın tanımlanmasıdır. Kapsam yönetimi projede istenilen işin tamamını ve sadece isteneni yapabilmek için gerekli süreçleri içerir. Proje başlatıldığında kapsamı bir belge halinde tanımlanır. Proje Tanımlama Belgesi(Project Definition Document) adı verilen bu belgenin biçemi oldukça çeşitlidir. Tamamen hazırlayıcısına göre değişen içeriği, kısıtlamalar, öngörüler, varsayımlar içerir, yapılacak işleri tanımlar. Projenin sonunda ortaya çıkacak ürünün ayrıntılı tanımı yapılır. Kapsama göre resmi kabulü için gerekli koşullar belirlenir. Bir projenin başlatılabilmesi için problemin tanımlanması ön

28 çözümlemelerin yapılması gerekir. Proje yöneticisinden öncelikli olarak istenen de projenin ne kadar sürede biteceği ve maliyetine yönelik niceliksel kestirimlerdir. Projenin başlarında elde kesin bilgiler olmadığı ve ister çözümlemesi henüz yapılmadığı için tahminde bulunmak zordur. Fakat genelde projelerde kestirimlerin hemen yapılması istenir. Bu nedenle kapsam yönetimi, proje yönetimi için önemli bir aşamadır. Proje Zaman Yönetimi Projeler gerçekleştirilirken kullanılan öz kaynakların planlanması büyük önem taşır.bu planlama genellikle projenin amacına, kaynaklara ve maliyete bağlı olarak yapılır. Planlamadaki hassaslık bazen maliyetten daha önde gelebilir. Bu durumda yeterli öz kaynak sağlanması gerekir. Projenin zamanında tamamlanmasını sağlamak üzere etkinlik tanımlama, etkinlik sıralama, etkinlik için süre kestirimleri, program oluşturma ve program denetimi zaman yönetimi altında yer alan süreçlerdir. Ağ diyagramı İş dağılım ağacı, kapsam tanımı, kısıtlamalar, varsayımlar ve uzman görüşleri alınarak etkinliklerin tanımlaması yapılır. Etkinlikler, belirli bir mantığa göre sıralanır, elle veya bilgisayar destekli olarak bir liste oluşturulur.

29 Birbirine, dış olaylara bağımlı işler, takip eden işler ve bunlar arasındaki öncelikler belirlenir. Bunlar dört şekilde olabilir: Bitişten başlangıca :Bir sonraki işin başlaması bir önceki işin tamamlanmasına bağlıdır.(en yaygın olan ) Bitişten bitişe :Bir sonraki işin tamamlanması bir önceki işin tamamlanmasına bağlıdır. Başlangıçtan başlangıca : Bir sonraki işin başlaması bir önceki işin başlamasına bağlıdır. Başlangıçtan bitişe : Bir sonraki işin tamamlanması bir önceki işin başlamasına bağlıdır. PERT ve CPM PERT (Program Evaluation and Review Technique) diyagramları ve CPM (Critical Path Method) proje yönetimi için kullanılan ve projedeki işlerin sırası, verimliliği, önemi veya aralarında problem olan işlerin ve bu problemlerin etkileri gibi kritik bilgilerin gözlemlenmesi için kullanılan yöntemlerdir. Basitçe bir projedeki işler ve bu işlerin sürelerinin çıkarılması ile işe başlanır. Ardında projedeki işlerin hangi işlere bağlı olduğu bulunur ve sonrasında PERT diyagramı çizilebilir. CPM ise PERT diyagramları üzerinde kullanılan bir yöntemdir. Bir örnek üzerinden PERT diyagramının nasıl çizildiğini gösterelim. Öncelikle işleri ve öncesinde bitmesi gereken

30 işleri örnek olarak verelim. Burada işler için A, B gibi harfler kullanılmıştır ancak gerçek hayatta bu işler yönetilen projenin alt işleri olarak düşünülebilir. Örneğin bir yazılım projesindeki müşteri görüşmeleri, projenin fonksiyonel özelliklerinin yazıldığı adımlar veya testler gibi projede yer alan işlemler düşünülebilir. Buradaki öncelikler veya işlemlerin süreleri genelde uzmanlar tarafından belirlenir. İşlem sürelerinin belirlenmesi çoğu projede problem olabilmektedir. Bunun için farklı yöntemler kullanılabilir. Örneğin Scrum Poker veya Delphi Metodu gibi tahmin yöntemleri kullanılabileceği gibi işlerin kestirilmesinin zor olduğu durumlarda daha alt işlere bölünmesi veya benzer işlerin sürelerinin kullanılması gibi yaklaşımlar da uygulanabilir. Proje Yönetimi ile İlgili İstatistikler Amerika da Standish Group tarafından yapılan bir araştırmaya göre yazılım projelerinin: %33 ü bitmeden iptal edilmekte, %53 ünde maliyet tahminleri % 189 oranında aşılmakta, Proje süre aşımı ortalama olarak % 222 oranında olmaktadır. Sebepler: Hedeflerdeki belirsizlikler, Kötü planlama, Teknolojideki yenilikler, Proje yönetim yöntemi eksikliği, Kaynaklar 1. onetimi-ile-ilgili.html 2. Erhan SARIDOĞAN, yazılım mühendisliği, papatya yayınları. 3.

31 İ ş dağılım ağacı örneği, Konfigürasyon Yönetimi Konfigürasyon Yönetiminin Tanımı Konfigürasyon: Mevcut olan veya tasarlanan bir ürünün, teknik dokümanlarda tanımlanan ve daha sonra ulaşılması amaçlanan fonksiyonel ve fiziksel karakteristiğidir. Konfigürasyon Yönetimi : Ürün veya sistemin ömür devri (yaşam döngüsü) boyunca hem fiziksel hem de fonksiyonel konfigürasyonunun izlenmesi ve kontrol edilmesi sürecidir. Şekil 1. Yönetimi Konfigürasyon Konfigürasyon yönetiminin öncelikli hedefi;

32 Müşteriye teslim edilen ürünün sözleşmede belirtilen çizim ve şartnamelerdeki fonksiyonel ve fiziksel özelliklere sahip olduğunu garanti etmek, Fiziksel konfigürasyonu ürünün tekrar üretilmesine imkan sağlayacak, Beklenmedik operasyon, tamirbakım ve değiştirme ihtiyaçlarını karşılayabilecek bir detaya kadar dokümante edildiğinden emin olmaktır. Konfigürasyon Yönetimini Süreçleri Şekil 2. Süreçler Müşteri isteklerinin belirlenmesi, Ürün yapısı ve konfigürasyon birimlerinin belirlenmesi, Konfigürasyon birimlerinin dokümante edilmesi, Konfigürasyon birimlerinin numaralandırılması, Konfigürasyon anahatlarının oluşturulması faaliyetlerini kapsamaktadır. Konfigürasyon Dokümantasyonu: konfigürasyona tabi parçaların fonksiyonel ve fiziksel karakteristiklerini tam olarak tanımlamak için ihtiyaç duyulan, resmi olarak onaylanmış ve dağıtımı yapılmış teknik dokümanları içermektedir. Bu dokümanlar; ürün, proses ve malzeme şartnameleri, teknik resimler, ilgili parça listeleri, akış şemaları ve teknik el kitaplarıdır. Konfigürasyon anahat dokümanlarının oluşturulmasından sonra konfigürasyona tabi parçaya ilişkin değişikliklerin teklif edilmesi, değerlendirilmesi, koordinasyonu ve onaylanması için gerçekleştirilen sistematik işlemler bütünüdür. Konfigürasyon Kontrol Kurulu (Configuration Control Board) kurulur. Konfigürasyon değişiklikleri mühendislik değişiklikleri, sapma ve feragatler olmak üzere üçe ayrılmaktadır. Mühendislik

33 Değişiklik Teklifi Formu- MDT Formu ile yapılır. Sınıf-I ve Sınıf-II olmak üzere ikiye ayrılan mühendislik değişiklikleri, konfigürasyona tabi parçanın veya anahat dokümanının, oluşturulduktan sonra değiştirilmesidir Sınıf-I değişiklikler, ürünün şekil, uyum ve işlevinde değişikliğe yol açan ve değiştirilebilirlik ile lojistik desteği etkileyen değişikliklerdir. Sınıf-II değişiklikler, Sözleşmeyi ve spesifikasyonları etkilemeyen ve Sınıf-I kapsamına girmeyen değişikliklerdir. Şekil 3. Mühendislik Değişiklik Teklifi Formu Konfigürasyon Değişiklik Kontrolü Sapma (Deviation): Sapma, konfigürasyona tabi parçanın üretimden önce, spesifikasyonlarda belirlenmiş olan performans veya tasarım isteklerinden, çizimlerden veya diğer dokümanlardan farklılığına belli sayıda veya belli bir süre için verilen izindir. Sapma ve mühendislik değişiklikleri arasındaki en temel fark; onaylanmış bir mühendislik değişikliğinin, ilgili birimi tanımlayan dokümanlarda revizyonu gerekli kılması; sapmaların, mevcut şartname veya çizimlerde herhangi bir değişikliğe neden olmaması ve anahat

34 dokümanlarını etkilememesidir. Sapma/Feragat İstek (Request for Deviation/Waiver RFD/RFW) kullanılır. Formu Feragat (Waiver): Feragat, bir konfigürasyon biriminin üretimi veya muayeneye sunulması sırasında belirlenmiş isteklerden ayrıldığının ve olduğu gibi kullan veya yeniden işle kararlarının verilmesine uygun olmadığının tespit edilmesi halinde, konfigürasyona tabi parçanın belirli bir miktarı için bu şekliyle kabul edildiğini belirten yazılı izindir. Feragatler, anahat dokümanlarını etkilemeyen değişikliklerdir. Feragat ve sapma arasındaki temel fark; sapmanın değişikliğe oluşmadan önce, feragatin ise oluştuktan sonra izin vermesidir. Bir konfigürasyon birimine aynı konuda ikiden fazla sapma ve feragat gerekiyorsa, bu durumda mühendislik değişikliği daha uygundur. Konfigürasyon Durum Değerlendirmesi Şekil 4. Konfigürasyon Durum Değerlendirmesi Konfigürasyon durum değerlendirmesi için bilgi yönetim sistemlerinden yararlanılmalı ve bir veritabanı oluşturulmalıdır. Dokümanların onaylanarak yayınlanmasından itibaren tüm tarihsel bilgi ve değişiklik kayıtları tutulmalı ve değişikliklerin izlenebilirliği sağlanmalıdır. Konfigürasyon listesindeki değişiklikler için konfigürasyon veritabanı güncellenir ve gerektiğinde çıktı alınarak konfigürasyon durumu raporlanır.

35 Konfigürasyon Denetimi Konfigürasyona tabi parçanın, konfigürasyon yönetim personeli tarafından ilgili konfigürasyon dokümanlarına uygunluk bakımından resmi olarak kontrol edilmesi, Hem ürün çizim ve şartnamelerinin talep edilene uygunluğunun ve üretim işlemlerinin bu dokümanlara göre devam edeceğinin teyit edilmesi, Üretilen ürünün istenilen performans değerlerini sağladığının kanıtlanması anlamına gelmektedir. Konfigürasyon denetimleri, fonksiyonel konfigürasyon denetimi ve fiziksel konfigürasyon denetimi olmak üzere iki çeşittir. Fonksiyonel konfigürasyon denetimi, konfigürasyona tabi parçanın kabulünden önce, konfigürasyon dokümantasyonunda belirtilmiş olan fonksiyonel ve performans özelliklerine ulaşıldığının kontrolü ve doğrulanması amacıyla, test verilerinin ve kayıtlarının incelenmesidir Bu denetim seri üretim için onay verilecek konfigürasyonu temsil eden prototip üzerinde, prototipin olmadığı durumlarda ise üretilen ilk parça üzerinde yapılmalıdır. Fiziksel konfigürasyon denetimi, imal edilmiş konfigürasyona tabi bir parçanın imalat konfigürasyonunun, tasarım dokümanlarına göre uygunluğunun denetlenmesidir. Fonksiyonel konfigürasyon denetiminin başarıyla tamamlanmasının ardından üretimin ilk parçası üzerinde uygulanan bu denetim, ürünle ilgili teknik resim, şartname, test gereksinimleri ve diğer teknik veriler ile tasarım dokümanları, el kitabı ve listelerin detaylı denetimini içermektedir. Prototip kafile üretimi sırasında üretim dokümanlarında yer alan muayene ve test gereksinimlerinin konfigürasyon dokümanlarına uygunluğunun değerlendirilmesi ve seri üretim sırasında bu üretim dokümanlarının kullanılacağından emin olunmasının sağlanmasıdır.

36 Konfigürasyon Yönetim Planı Konfigürasyon yönetim politikası ve hedefleri, Konfigürasyon yönetim organizasyonu, sorumluluk ve yetkileri, Konfigürasyon yönetim kaynakları ve bu kaynakların nasıl elde edileceği, Konfigürasyon kontrol yöntemi, Konfigürasyon denetimlerinin nasıl ve ne zaman yapılacağı, Konfigürasyon durum değerlendirmesinin nasıl ve ne zaman yapılacağı, Konfigürasyon yönetiminin müşteri ve alt yükleniciler ile nasıl koordine edileceği. Şekil 5. Konfigürasyon Yönetim Planı Konfigürasyon Yönetim Organizasyonu Şekil 6. Konfigürasyon Yönetim Organizasyonu

37 Referanslar * MIL-HDBK-61B DoD Military Handbook Configuration Management Guidance, * MIL-STD-3046 Department of Defense Interim Standard Practice Configuration Management, * MSB.lığı SATEM K.lığı, Konfigürasyon Yönetimi Seminer Notları, Ankara. * EIA Standard 649, National Consensus Standard for Configuration Management, U.S.A., * Ünal Hande, Konfigürasyon Yönetimi ve Savunma Sanayiinde Uygulaması, Gazi Üniversitesi Fen Bilimleri Ankara, 2005, (Yayımlanmamış Yüksek Lisans Tezi). Enstitüsü, * unumu Yazılım Nitelik Güvencesi

38 1.YAZILIM NİTELİK GÜVENCESİ (SOFTWARE QUALITY ASSURANCE) Bilgisayar tabanlı sistemlerin düzgün çalışması, insanların isteklerini en iyi şekilde karşılamak için uygun niteliğe sahip olmaları gerekir. Nitelik kelimesiyle anlatmak istediğimiz bir ürün veya hizmetin belirlenen istekleri karşılayabilme yeteneğine yönelik özelliklerin tümüdür. 1.Yazılım Niteliği (Software Quality) Yazılım mühendisliğinin temel amacı yüksek nitelikli yazılım üretmektir. Bunun için yazılımda belirleriz. Yazılım niteliği; belirli nitelikler Kullanım amaçlarına göre işlev ve başarım gereksinimlerine uyum, İşlev ve başarım gereçlerine uyum, Kullanıcı isterlerine yanıt verebilme, Yazılım geliştirme standartlarına sadık kalma, Yüksek güvenirlilik sağlama,

39 Teslim sonrası destek, İşlevselliklerle tanımlanır. 1.1 Nitelik Etmenleri (Quality Factors) İyi bir yazılımda aranan ve ürünün kalitesini anlamamızda yardımcı olan nitelikler vardır. Nitelik etmenleri farklı ürünleri birbirleriyle kıyaslamak amacıyla 3 grup altında incelenir. Kullanıma yönelik özellikler Taşınmaya yönelik özellikler Yenileştirmeye yönelik özellikler Tablo 1. Nitelik Etmenleri Sınıflandırması 1.2 Nitelik Metrikleri (Quality Metrics) Nitelik etmenlerinin ölçülmesi çoğu zaman oldukça zordur, hatta bazen de imkansızdır. Bu nedenle bazı metrikler ya da bir diğer ismiyle ölçütler tanımlanır her metrik için bir not verilir (1 ile 10 arasında) ve bu notlar yardımıyla sayışıl

40 değerler elde edilir. Değerlendirmede dikkate alınabilecek metriklerin bir kısmı şunlardır; Denetlenebilirlik Doğruluk Hassaslık Başarım Arayüzün yaygınlığı Verilerin yaygınlığı Bütünlük Büyüklük Tutarlılık Hata dayanıklılığı Verimlilik Genişleyebilirlilik Donanım bağımlılığı İzlenebilirlilik Modülerlik Kullanım kolaylığı Bakım kolaylığı Belgelendirme Müşteri tatmini 1.3 Nitelik Requirement) Güvence Gereksinimi (Quality Assurance Her yazılım geliştirici grup, kurum ya da fırına niteliği artırmaya ve korumaya yönelik birtakım düzenler kurmaktadırlar. Her türlü düzenin en alt düzeyinde mühendislik işlerini yürüten bireyin nitelik anlayışı bulunmaktadır. En üst düzeyde ise, nitelikli yazılım geliştirebilmek üzere standartları koyan, yöntemleri belirleyen ve bunların uygulanmasını sağlayan yazılım nitelik güvence ekibi bulunur. Yazılım geliştiren grup veya firmalar bu düzeyler arasında herhangi bir yerde bulunabilirler. Genel yönetim işlevlerinin nitelik politikası belirleyen ve uygulayan bölümüne Nitelik Yönetimi denir. Nitelik yönetimi

41 uygulaması için gereklidir. geliştiricinin yeterli nedeni olması Nitelik güvence etkinliklerinin olumlu yanları; Geliştirilen yazılımın azaltılmış olur sonradan ortaya çıkan kusurları Test ve bakım aşamalarında daha az işgücü gerekir Yüksek güvenilirlik müşteri memnuniyetini arttırır Bakım maliyeti düşer Yazılımın tüm yaşam çevrimi maliyeti düşer Çalışanlar arasında kurulan iş disiplini sayesinde verimlilik artar. Nitelik güvence etkinliklerinin olumsuz yanları; Küçük örgütlenmelerde ayrı bir ekip oluşturmak güçtür. Çünkü asıl geliştirme etkinlikleri için ayrılacak özkaynaklar dahi kısıtlıdır. Alışık olmayan kurum ya da firmalar için köklü değişiklikler gerekir. Belirli bir düzene uyum sağlama kültürel bir sorun olabilir. Yazılım geliştirme etkinlikleri dışında önemli bir bütçe ayrılması gereklidir. 1.4 Nitelik Activities) Güvence Etkinlikleri (Quality Assurance Yazılım mühendisliği yöntembilimleri; Yazılım mühendisliği çözümleme, tasarım, gerçekleştirim ve test için kullanılan yöntemlerin ve araçların tanımlandığı belirli geliştirme yöntemlerini ve standartları uygulayan bir yöntembilime göre yürütülür. Standartlar ve yöntemler;

42 Yazılım nitelik güvencesi, çözümleyici ve tasarımcının işini daha iyi yapabilmesine yardımcı olan bir dizi kurallardan oluşan teknik yöntemlerle yapılır. Bu iş için çeşitli araçlarda kullanılabilir. Nitelik güvence, çeşitli standartları olan bu yöntem ve araçların tanımlanması ve kullanımının kabul edilmesiyle başlar. Nitelik güvence denetimi; Nitelik güvence denetimi nitelikle ilgili etkinliklerin sonuçlarının. planlanan düzenlemelere uyup uymadığının, düzenlemelerin etkili olarak uygulanıp uygulanmadığının amaca ulaşmak için uygun olup olamadığının sistematik tarafsız olarak incelenmesidir. ve bu ve ve Resmi teknik gözden geçirmeler; Resmi teknik gözden geçirmeler, her aşamada ortaya çıkan her ürün için uygulanan bir inceleme yöntemidir. Çözümleme ve tasarımın nitelikli bir şekilde yapıldığının denetlenmesi için teknik personel ile belirli kurallara bağlı olarak toplantılar yapılır. Bu gözden geçirme toplantıları yazılımın testten geçirilmesi gibidir; hatta, olası hataların önceden bulunup giderilmesini sağladığı için daha da etkindir. Yazılım düzenleşim yönetimi; Yazılımın herhangi bir geliştirme aşamasında ya da kullanımı sırasındaki bakım aşamasında isterlerde çeşitli değişiklikler yapılması olağandır. Fakat denetim altında yapılmayan her değişiklik, aslında, yeni bir kusura neden olması veya yan etkiler yaratması açısından potansiyel birer tehlikedir. Yazılım niteliğini düşürecek bu tehlikeyi en aza indirgemenin tek yolu da düzenleşim yönetiminin bir parçası olan değişiklik denetim sürecinin uygulanmasıdır. Ölçme; Ürün niteliği ile ilgili temel veriler genellikle kullanıcı

43 ile beraber çalışan geliştirme, test, destek, hizmet ve satış birimlerinde toplanır ve değerlendirilir. Yazılım niteliğini ölçmek, harcanan özkaynakları saptayabilmek ve daha iyi planlama yapabilmek için yazılım metrikleri kullanılır. Nitelik güvence etkinliklerinden biri olan yazılım metrikleri önceden belirlenir, toplanır, değerlendirilir ve somut sonuçlar elde edilerek daha sonraki geliştirme etkinliklerinde kullanılır. Teknik gözden geçirmeler, denetimler, değişiklik denetimi, testler ve diğer nitelik güvence etkinliklerinin kayıt altında tutulması ile projenin bir tarihçesi oluşturulur. Gerektiğinde bu tarihçe hem hata gidermede bir başvuru kaynağı olarak kullanılabilir, hem de diğer projeler için örnek oluşturur. Geliştirici personel bu teknik ve nitelik güvence kayıtlarını inceleyerek daha nitelikli yazılım üretir. Test; Yazılımın bir ürün haline gelip kusurlarından arındırılması için önceden tasarlanmış test yordamlarıyla bir dizi test yapılır. Dikkatli bir şekilde ve belirli yöntemlere göre yapılan testler hataların ayıklanması için önemli bir aşama olur. Ancak, nitelik güvence denetimi altında yapılmayan testler yalnızca deneme-yanılma taktiği ile, ya zaman elverdiği sürece yapılır ya da yeteri kadar kusursuz yazılım üretilinceye kadar devam ettirilir. Her iki durumda da aşırı maliyet artışı söz konusudur. Belgelendirme; Yapılan her işin ve etkinliğin seçilmiş olan yöntembilimin gerektirdiği şekilde belgelendirilmesi, hem yapılanların kayıt altına alınması hem de daha sonraki geliştirme ve değişiklik işlerinde kolaylık sağlaması nedeniyle nitelik güvence etkinliklerinin tanımında kullanılır. 1.6 Nitelik Güvence Yönetimi (Quality Assurance Management) Her projede mutlaka belirli bir nitelik güvence yönetimi

44 bulunmalıdır. Bir yazılım geliştirme kurumu ya da firması yazılım nitelik güvence etkinliklerini yerine getirmeni karar verdiyse belirli standartlar seçilerek kullanılmalı ve bir yazılım nitelik güvence planı (software Quality assurance plan) hazırlanmalıdır. Bu plan için IEEE 730 standardı kullanılabilir. Yazılım nitelik güvence planı geliştirme etkinlikleri boyunca nitelik yönetimine ait ne tür işlerin yapılacağını hangi standartların kullanılacağını gözden geçirme ve denetimlerin ne şekilde yapılacağını belirleyen ve diğer destek etkinliklerini tanımlayan bir yol haritası gibidir. Nitelik güvence yöneticisi bulunmalıdır. sorumlulukları maddeler halinde sıralanırsa; Bu yöneticinin Proje yönetimine yardımcı olmak üzere kendi sorumluluk alanıyla ilgili bir plan (Nitelik Güvence Planı) hazırlamak ve proje yönetimine onaylatmak, Nitelik Güvence Planı kapsamında düzenli aralıklarla proje etkinliklerini değerlendirmek, ortaya çıkan hataları derlemek, düzeltici işlem talebinde bulunmak ve takibini yapmak; bu kapsamda durum raporları hazırlamak ve yönetimin dikkatine sunmak, Proje uygulamalarını standartlar ve sözleşme isterleri doğrultusunda denetlenmesiyle ilgili etkinliklerin yürütülmesinde proje yönetimine yardımcı olmak, 1.Kendi sorumluluk alanıyla ilgili olarak yönetime yardımcı olabilecek tüm bilgileri derleyip toplamak. 2.Yönetimin dikkatine sunmak, proje yönetimi ile ilgili toplantılara katılmak, gözden geçirmeleri yapmak 3.Belgelendirme çalışmaları sonunda ortaya çıkan belgeleri onaylamak ya da geri çevirmek 4. Belgelerde içerik denetimi yapmak, içeriğin şablonlara uygunluğunu denetlemek

45 5.Yazılım geliştirmede kullanılan gereçlerin seçilmiş olan standartlara uygunluğunu denetlemek 6.Yazılım geliştirme süreciyle ilgili her türlü planlamayı onaylamak 7.Geliştirilen her ürünün kayıt altında olduğunu denetlemek, belgelerin ve kaynak kodların tahsisli yerlerinde olduğunu denetlemek, eksiklikleri uyarmak ve tedbir alınmasını sağlamak 8.Uygulama alanı ile ilgili standartları ve yenilikleri takip etmek 1.7 Toplam Nitelik Yönetimi (Total Quality Management) Toplam Nitelik Yönetimi, yürütülen bir işin bütününde etkinliğin, esnekliğin. iyileştirici ve rekabeti artırıcı düzenlemelerin tümüne verilen addır. Örgütlenmenin her düzeyinde ve çalışan herkesi kapsar. Gerçekten etkin bir örgüt içinde tüm bölümler birlikte çalışırlar; her birey diğerini etkiler ve kendisi de etkilenir. Nitelik tanımlaması işletme içinde yukarıdan aşağıya doğru tanımlanır. Niteliği sağlamada başarı yatay örgüt yapısındadır. Örgüt içindeki bir bölümün başarısızlığına neden olabilecek yanlış ürün üretilmesini ya da geliştirilmesini diğer bölüm önlemeye çalışır. Toplam Nitelik Yönetimi uygulayarak fırına ya da kurumlar asıl hedeflere odaklanırlar, yüksek başarım elde ederler, sorunları daha kısa sürede çözerler, ürün niteliğini giderek artırırlar. Tabii ki, bunun için niteliği anlamak, inanmak, belirli bir politika ortaya koymak, iyi örgütlenmek, iyi planlama ve ölçüm yapabilmek, denetimi sağlamak gerekmektedir. 1.8 Örgütleme Ve Nitelik (Organizing and Quality) Örgütlenmelerin olgunlaştırılması için yazılım ve süreç arasındaki ilişkinin bilinmesi ve uygulanması gereklidir. Süreç (process), belirli bir işi yapmakta izlenen yordamdır.

46 Genellikle, altsüreçlerden, onlar da adım ve işlemlerden oluşur. Sürecin amacı belirli bir standart oturtmak, değişkenliği azaltmak ve iyileştirmeye olanak sağlamaktır. Süreç yazılı halde bulunur, tekrarlanabilir şekilde tanımlanmıştır. Girdileri ve çıktıları vardır. Örneğin; İsterler çözümlemesi süreci. 2.NİTELİK SİSTEM STANDARTLARI (QUALITY SYSTEM STANDARDS) Standart oluşturan kuruluşlar; Amerikan Ulusal Standartlaştırma Enstitüsü (American National Standardization Institute -ANSI) 1. BSI(ingiltere) 2. AFNOR(fransa) 3. A m e r i k a B i r l e ş i k Devletleri Savunma Bakanlığı (Department Of Defense-DOD) 4. NATO 5. Uluslararası Standartlaştırma Standardization Office-ISO) Ofisi(ınternational 6. Elektrik Ve Elektronik Mühendisleri Enstitüsü(ınstitute Of Electrical And Electronics Engineers-IEEE) 7. Yazılım Mühendisliği Enstitüsü (Software Engineering Institute-SEI) Standart oluşturan kuruluşlar birbirleri ile sürekli ilişki içerisinde olup ortak standart üretmektedirler. Ortak çalışmalar sonucu uluslararası kabule sahip nitelik yönetim sistemi standartları oluşmuştur: 1. Watts Humphrey ve Yetenek olgunluk Modeli (CMM) 2. I S O N i t e l i k Y ö n e t i m i v e N i t e l i k G ü v e n c e Standartları Seçim ve Kullanım Rehberi 3. ISO 9001 Nitelik Sistemleri Tasarım, Geliştirme, Üretim,

47 Tesis ve Servis İçin Nitelik Güvence ISO 9002 Nitelik Sistemleri Üretim ve Tesis İçin Nitelik Güvence ISO 9003 Nitelik Sistemleri Son Muayene ve Testlerde Nitelik Güvence ISO 9004 Nitelik Yönetimi ve Nitelik Sistemi Öğeleri Trillium (Kanada) SPICE 2.1 CMM (Capability Maturity Model) CMM Amerika Savunma Bakanlığının 1980 lerde ortaya çıkan yazılım krizine çözüm bulması amacıyla Carnegie Mellon Üniversitesinden yardım istemesi üzerine üniversitede kurulan SEI tarafından geliştirilmiştir. İlk CMM geliştirilmiş ve 1990 da yayımlanmıştır. yazılım için CMM yazılım süreç iyileştirmede kullanılacak araç ve olgunluk sorguları aracılığıyla oluşturulmuş bir modeldir. Bu modelin ortaya çıkmasının nedeni yazılım sektöründeki kalite ve verimlilik sorunlarıdır. Bunlar; zaman, para, durağanlık olarak sayılabilir. Tüm bu sorunlar için yazılım sürecinin olgunluğu hakkında karar vermek ve endüstrideki pratiklerle karşılaştırmak amacıyla çeşitli ölçüm araçları ortaya atılmıştır. CMM asıl olarak olgun olmayan bir süreçten olgun ve disiplinli bir sürece giden evrimsel bir yol çizer. Olgun bir yazılım örgütlenmesine giden aşamaları öncelik sırasıyla veren bir modeldir. CMM nin yapısı; 1.Olgunluk tanımlar. 2.Anahtar belirler. düzeyleri süreç (maturity alanları (key levels):süreç process yeteneğini area):hedefleri

48 3.Ortak öznitelikler (common features):gerçekleştirim kurumsallaşma için gerekli özelliklerdir. ve 4.Anahtar uygulamalar (key practices):temel etkinliklerdir. CMM uygulaması için sıradüzensel olarak; Düzey belirleme, Bir sonraki düzeye geçmeden önce eksiklikleri belirleme, Eksiklikleri sıradüzensel sıraya dizme, Eksikliklerin giderilmesi için plan yapma, Planı hayata geçirmek için kaynak ayırma ve uygulama, Döngüye yeni baştan başlama Aşamaları uygulanır. 2.2 CMMI (CMM Integration) Çeşitli uygulamalardan edinilen deneyimlerle, pazarlama, sistem, yazılım ve donanım temsilcilerinin bir arada çalışmalarıyla verimliliğin arttığı gözlemlenmiştir. CMM ile sağlanan başarımdan sonra, sistem mühendisliği, insanlar, tümleşik ürün geliştirme, yazılım edinme, yazılım nitelik güvence, ölçme gibi konulardaki istekler üzerine başka CMM ler geliştirilmiştir. Bu kadar çok çeşitli model olunca da birbirine karışmalar, örtüşmeler ve tezatlar oluşmuş, kolay anlaşılır olmayan arayüzler ve standartlar ortaya çıkmıştır. Bunlara ek olarak ISO 9001 ve ISO denetimlerinin kullanılması sonucunda da yüksek maliyetler ve kafa karıştırıcı uygulamalar oluşmuştur. Karşılaşılan sorunları çözmek üzere, var olan gelecekte var olacak modelleri birleştirecek bir yapı kurmak ve başlangıç için bir tümleşik modeller seti oluşturmak amacıyla, Amerikan

49 Savunma Bakanlığı nın desteğiyle SEI tarafından CMM Tümleştirme (CMM Integration) Projesi başlatılmıştır. Projenin amacı, üç kaynak modelini birleştirmekti. Bunlar: Capability Maturity Model for Software (SW-CMM) v2.0 Electronic Industries Alliance Interim Standard (EIA/IS) 731 Integrated Product Development Capability Maturity Model (IPB-CMM) v0.98 CMMI sürüm-1.1 Mart 2002 yılında ortaya çıkartılmıştır. CMMI, sürekli ve basamaklı olmak üzere iki gösterim şekli kullanmaktadır. Sürekli (continuous) CMM gösterimi yetenek düzeylerini tanımlarken basamaklı CMM gös-ı terimi olgunluk düzeylerini tanımlar. Yetenek düzeyleri, bir örgütün herbir süreç alanında süreç iyileştirmede gösterdiği başarı için uygulanır. 6 yetenek düzeyi vardır: Eksik (incomplete) Yerine getirilen (performed) Yönetilen (managed) Tanımlı (defined) Nicel olarak yönetilen (quantitatively managed) Eniyilenen (optimizing) 2.3 Trillium Trillium modeli kanada geliştirilmiştir. iletişim sektörü tarafından Yol haritası yaklaşımını getirmiştir bu yaklaşım ürün geliştirme süreci içerisinde bir örgüt alanına bir gereksinime yada bir öğeye odaklanan uygulamalar seti olarak tanımlanır. Trillium un 8 yetenek alanından oluşur.

50 Örgüt süreç niteliği İnsan kaynakları geliştirme ve yönetimi Süreç Yönetim Nitelik Sistem geliştirme uygulamaları Geliştirme ortamı Müşteri desteği. 2.4 TickIT Daha çok İngiltere ve Norveç yazılım geliştiricileri tarafından desteklenen TickIT, yazılım sektöründeki yetkili belgelendirme kuruluşları aracılığıyla nitelik yönetim sistemi belgelendirmesi yaparak; Pazar güvenilirliğini artırmak. Bu sektördeki nitelik yönetim sistemi denetleyicileri için profesyonel yöntemleri geliştirmek. Yetkili bir kılavuz yayınlamak. Amacıyla oluşturulmuş bir yordamlar topluluğudur. ISO 9001 in karşılaştığı bir takım çıkarılmış, onun da yetersiz modeli ortaya çıkarılmıştır. TickIT, sisteminde ISO 9001 standardına olmadığını araştırır. güçlükler nedeniyle ISO kalması üzerine TickIT değerlendirdiği nitelik göre uyumsuzluk olup Yazılım geliştiricilerin nitelik güvence sistemlerinin belgelendirmesi Ingiliz ve Norveç kurumları tarafından yetkilendirilmiş üçüncü parti bağımsız ve yetkili organlar

51 tarafından yapılır. İngiltere devlet daireleri tarafından resmi olarak tanınan TickIT içinde ISO 9001, ISO 9002 ve ISO 9003 standartları kullanılmaktadır. Değerlendirme en az iki aşamalı bir süreçtir. llkinde, örgütün nitelik sistemi, standarda (Ticle için: ISO 9001) göre değerlendirilir. İkincisinde, örgütün pratikte gerçekten kendi nitelik sistemine ve standarda uyumlu çalışıp çalışmadığı denetlenir, nitelik sisteminin etkinlik derecesine bakılır. 2.5 SPICE (Software determination ) Process Improvement and Capability Yazılım Süreci İyileştirme ve Yetenek Belirleme dir yılında ISO ve IEC tarafından çıkarılmıştır. Yazılım geliştirme projelerinin yönetim tarafı çoğunlukla yetersiz planlama, geliştirme süreçlerin tam anlaşılmaması, iyi bir yönetim çerçevesinin olmayışı gibi problemlerle karşı karşıyadır. Bu çerçevede daha disiplinli geliştirme süreçleri için standartlar geliştirilmeye başlanmıştır. SPICE da bu standartlardan biri olup, yazılım süreçlerini iyileştirmek ve süreç yeteneklerini belirler. SPICE İlkeleri; Standartlaşma Değerlendirme, yetenek belirleme ve iyileştirme Diğer modellere uyum sağlama Gelişmeyi ölçme Nesnel, tutarlı ve tekrarlanabilir olma Sertifikasyon amacı taşımaz SPICE süreç boyutu ve yetenek seviyeleri olmak üzere iki boyuttan oluşur. Süreç boyutları 5 e ayrılmaktadır. Bunlar: Müşteri-satıcı süreçleri (Customer-supplier) Mühendislik süreçleri (Engineering)

52 Yönetim süreçleri (Management) Destek süreçleri (Support) Organizasyon süreçleri (Oganization) İkinci boyut olan yetenek düzeyleri altı adet olarak tanımlanmıştır. Bunlar; Düzey Düzey adı Açıklama 5 Eniyileşen (optimizing) Geri beslemelerde sürekli iyileştirme vardır Denetim altındaki süreçte ayrıntılı 4 Kestirilebilir(predictable) başarım ölçümleri toplanır ve ona göre yönetilir. 3 Yerleşmiş (established) 2 Yönetilen (managed) Süreç tanımlanır. İş planı uygulanır 1 Yerine getirilen(performed) Planlama yapılmadan süreçler genel olarak yerine getirilir. 0 Eksik (incomplate) Başarı sadece bireylere bağlıdır. Örgütlenmede belgelendirilmiş standart süreçler ve uygulamalar vardır. Tablo 2. SPICE ye ait yetenek düzeyleri 2.6 ISO 9000 Uluslararası Standartlaştırma Örgütü (International Standardization Organization -ISO) tarafından yayınlanan ISO 9000 serisi Nitelik Sistemi ve Güvencesi Özellikle Avrupa da büyük ilgi görmüştür. Standartları 1987 yılında ilk ISO 9000 (Ed. l ) serisi standartlar oluşturulmuştur yılında ikinci ISO 9000 (Ed.2) serisi standartlar tamamlanmıştır. ISO 9000 serisi standartlar çok çeşitlidir, ancak ana kaynaklar ele alındığında, yayınlanmış ve sürekli güncellenen bu nitelik sistemlerine ilişkin beş temel ISO standardı vardır. ISO 9000 Nitelik Yönetimi ve Nitelik Güvence Standartları Seçim ve

53 Kullanım Rehberi ISO 9001 Nitelik Sistemleri Tasarım, Geliştirme, Üretim, Tesis ve Servis İçin Nitelik Güvence ISO 9002 Nitelik Sistemleri Üretim ve Tesis İçin Nitelik Güvence ISO 9003 Nitelik Sistemleri Son Muayene ve Testlerde Nitelik Güvence ISO 9004 Nitelik Yönetimi ve Nitelik Sistemi Öğeleri ISO 9000 Kalite Standartları Serisi, kuruluşların kaliteye önem verdiğini ve kalite ihtiyaçlarını karşılayabileceklerini müşterilerine kanıtlayacak etkin bir kalite sistemini kurulması, dökümante edilmesi ve sürekliliğinin sağlanması konusunda yol gösterir. Bu nedenle bir çok resmi veya özel kuruluş tarafından ihale şartı olarak istenmektedir. Yazılımda nitelik için ISO 9001 öngörülebilir. Ancak bu standart bir süreç modelinden farklı olarak, dışarıya nitelik güvencesi vermeye yönelik belgelendirmeye önem verirler. Bir denetim yöntemine gereksinim duyan bu standartlar, firma düzeyi hakkında ayrıntı değil, genel bir bilgi verirler 2.7 AQAP (Allied Quality Assurance Publications) 150/160 NATO içinde müşterek uygulamaların temini için standardizasyon anlaşması (STANAG-MOS) çerçevesinde Müttefik Nitelik Güvence Yayınları (Allied Quality Assurance Publications-AQAP) 1983 ten itibaren uygulamaya alınmıştır. NATO tarafından ISO nitelik standartlarındaki son gelişmeler göz önüne alınarak savunma sistemlerinin edinilmesinde ISO 9000 serisi nitelik güvence standartlarının 1994 ten itibaren uygulanması zorunlu

54 kılınmıştır. Daha sonra, ISO sürümü dikkate alınarak 1995 Şubat ında yeni AQAP belgelerinin kullanımına başlanmıştır. NATO ülkelerinde askeri amaçlı ürün geliştiren firma veya kuruluşlarda AQAP-150 veya 160 belgesi aranmaktadır. Bu belgeler her devletin yetkilendirdiği organlarca verilmekte, belirli aralıklarla yenilenmektedir. Türkiye de bu konudaki denetimleri Milli Savunma Bakanlığı yapmakta, savunma sistemleri ile ilgili ihalelere giren firmalardan bu belge istenmektedir. 2.8 Karşılaştırma Tablo 3.Nitelik sistem standartları karşılaştırılması 3. RESMİ NİTELİK GÜVENCE ASSURANCE SYSTEMS) SİSTEMLERİ (OFFICIAL QUALITY Nitelikli bir yazılım geliştirmek her geliştiricinin sorumluluğundadır. Bu sorumluluğun belirli kurallar çerçevesinde yürütülmesi için resmi yöntemler ortaya atılmıştır. Bu yöntemlerden birkaçı şunlardır; Doğruluğun kanıtlanması

55 İstatiksel yaklaşım Temiz oda süreci Yardımcı araç desteği 3.1 Doğruluğun Kanıtlanması Bilgisayar bilimlerinde bir programın istenen özellikleri yerine getirip getirememesine verilen isimdir. Buna göre şayet bir program, istenen durumu tam ve eksiksiz yerine getiriyor, istenmeyen sonuçlar ortaya çıkmıyor ve program başladıktan sonra her durumda başarılı bir şekilde bitiyorsa bu programa tam doğru ( total correctness) ismi verilir. Bazı program hataları yalnızca zarar verir, ancak bazıları yaşamı ve ekstremiteyi tehlikeye atabilir. Bir daha ki sefere, uçağın seyir sisteminde doğru program davranışının önemini düşünerek bir dakika harcayın. Üreticinin programın bir takım ampirik testlere dayanılarak doğru olduğunu düşün istemesini mi, yoksa kesin ve kesin bir ispatı mı tercih edersiniz? Program doğruluğunun hem mühendislik hem de teorik sorun olarak önemini ortaya koyduğumuzda, dikkatimizi aslında onu çözmeye dönebiliriz. Örneğin, bir programın belirli bir belirtimi doğru bir şekilde uyguladığını kontrol eden (veya kanıtlayan) genel algoritmaların bulunmadığı kanıtlanabilir. Daha basit problemler için de genel çözümler veremiyoruz. Örneğin, rasgele bir programın belirli bir girdi için yürütmeyi durdurup durdurmayacağına karar verebilecek bir algoritma yoktur. Yazılımın doğruluğunun matematiksel olarak kanıtlanması oldukça pahalı bir yöntemdir.ancak, otomatik kod üreten yazılım araçlarının geliştirilmesinde bu yaklaşımın da kullanımında yarar vardır. 3.2 İstatiksel Yaklaşım

56 İstatistiksel olarak toplanmış bilgilere artırıcı yaklaşımda şu aşamalar bulunur: göre niteliği 1. Yazılım kusurları toplanır ve sınıflandırılır. 2. Her kusur izlenerek neden kaynaklandığı bulunur ve bu bilgiler de kaydedilir. 3. Neden olan ortak kusurlar bulunur. 4. Bulunan kusurlar düzeltilir. Bu yöntemin işleyebilmesi için uzun süreli, yoğun bir geliştirme yapılması ve bilgilerin eksiksiz toplanması gereklidir. Yazılım kusurlarının oluşmasına neden olan en yaygın nedenler arasında şunları sayabiliriz: 1. Hatalı yapılmış isterler çözümlemesi ortaya çıkan hatalı belirtim İsterlerin yanlış anlaşılması Kodlama standartlarına uyulmaması Veri yapılarında hata Tutarlı olmayan modül arayüzleri Tasarımda mantık hatası Tasarımı koda geçirmede yapılan hata Kodlamada yapılmış hatalar Yetersiz yapılmış testler Hatalı veya eksik belgelendirme İnsan-makine arayüzündeki eksiklikler ve hatalar Dikkatsiz ve isteksiz çalışma Yazılım kusurunun oluşmasına neden olan durumun belirlenmesinden sonra her bir kusura ilişkin istatiksel veriler toplanır ve bir sıraya konulur. Buradan yola çıkılarak yeni bir hata oluştuğunda çözüm için incelenecek yol konusunda bir fikir elde edilmiş olur 3.3 Temiz Oda Süreci (Clean Room Process) Nitelikli yazılım geliştirmenin ve doğruluğunu kanıtlanmanın bir tekniği de temiz oda sürecidir (cleanroom process).endüstride çeşitli alanlarda kullanılan bu teknikte ilke olarak geliştirme ortamının her türlü zararlı etmenden

57 arındırıldığı kabul edilir. Örneğin, yüksek nitelikli bir elektronik tümdevre üretim hattında havanın temizliği esastır. Bunun için ortam hataya sebebiyet verecek en küçük toz parçacıkları dahi ortamdan uzaklaştırılır. Burada hatanın oluşmasına engel olmak amaçlanır. Benzer bir şekilde istatiksel nitelik denetimi uygulanarak, matematiksel olarak yapılan doğrulama işlemleri ile, ilk testlerden bile daha önce, hataların büyük ölçüde bulunup giderilmesi sağlanır. Amaç, hatanın oluşabileceği ortamı ortadan kaldırmaktır. Fakat bunun için matematik modellerinin çok iyi geliştirilmiş ve oturtulmuş olması gereklidir. Bu nedenle, temiz oda süreci daha çok, küçük ölçekli yazılım projelerinde kullanılmaktadır. 3.4 Yardımcı Araç Desteği Günümüzde pek çok yardımcı araç nitelikli kod üretimi ve üretilen kodun sınanması (bellek ve işlemci kullanımının ölçülmesi gibi) amacıyla kullanılmaktadır. Sıkça kullanılan yazılım modüllerinin ortak hale dönüştürülmesi ve kalıpsal bir yapıya sokulması hem hataları azaltır hem de geliştirme süresini düşürür. Bunun yanında, verilen parametrelere göre aynı tür kod üreten araçlar da bulunmaktadır. Hatta, bu koddan belgelendirme de yapabilen araçlar da vardır. Genel olarak nitelik güvence ekibi tarafından benimsenmiş araçlarla yapılan yazılım geliştirme sonucu elde edilen ürün yüksek nitelikli olarak kabul edilir. 4.REFERANSLAR 1. ty-model

58 ce-software-process.html -suerecleri-safhalar/yueruetme/kaliteyoenetimi/iso-9000-nedir /lecture9.htm 0/program-dogrulugu-program-correctness/ Dr. M. Erhan SARIDOĞAN Yazılım Mühendisliği (İstanbul Papatya yayıncılık Ocak 2008 ) Sistem Analizi Giriş Birbiriyle ilişkili ve ortak amaca yönelik olarak hareket eden parçalardan oluşan bütüne sistem adı verilmektedir. Sistem kavramı, özellikle endüstri devriminden sonra ekonomik ve sosyal alanlarda kullanım alanı genişleyen bir kavramdır. Sistemin bazı temel ortak özellikleri vardır. İlişkiler, amaçlar, eylemler, hedefler, bütünlük, işbirliği gibi. Sistem, bir bütünlük oluşturacak şekilde bir arada bulunan unsurlar (öğeler), bu unsurlar arasındaki ilişkiler ve bunların birbiriyle ve çevreyle ilişkili ve bağlantılı olan nitelikleri dizisidir.

59 Resim 1.Sistem Etki Alanı Herhangi bir projede anlaşılan, konuşulan kavramların anlaşılabilir olması gerekmektedir. Bunun nedeni projenin iki taraftanda aynı şekilde kabul görmeli. Bir tarafın konuyu yanlış anlaması projeninde olumsuz sonuçlanmasına yol açar. İsteklerin, hedeflerin ve bunlar dahilindeki ulaşılması gerekilen sonucun açık olması hangi alana ne dahilinde ulaşılması gerektiği belirlenmelidir.

60 Projeye Başlama Noktası Problemi Bulma Ve Çözme Bu durum iki başlıkta incelenebilir ; Programdaki sıkıntılar Programdaki geliştirmeler Mevcut bir yazılımda problem kullanıcıların yazılımdaki süreç, teknoloji, performans gibi bazı sıkıntılarında geliştirme yapılabilir. Veya yazılımda ekstra bir eklenti gibi bir talepte bulunulması durumunda mevcut yazılım geliştirilmesi gerekmektedir. Proje Alanını Anlamak Proje alanını anlamak için ; Bu alanı küçük parçalara ayırmak Oluşan parçalar hakkında sorular sormak Yapılan parçalar net olmalı ve büyük sistemin parçaları olmalıdır.

61 Şekil 2.Elektrik Araba Motoru Örneğin bir banka sistemi Banka yazılımları çeşitli varyasyonlara sahiptir; Müşteri bilgileri Ödeme bilgileri İşlem Tarihleri Database bilgileri Ve bunun gibi bir çok farklı özellikleri vardır. Tablo 2.Banka Şubeleri

62 İster Nedir? Kelime anlamı bakımından bir işin gerektirdiği, yapılabilmesinin ya da olabilmesinin bağlı bulunduğu şey, gerek, zorunluk anlamına gelir. Aslında baside indirgersek müşteri veya kullanıcının bizden istekleridir. İsterler tipleri bakımında iki başlık altında incelenir ; 1. Fonksiyonel isterler 2. Fonksiyonel olmayan isterler 6.1 Fonksiyonel isterler 1. Sistemin yerine getirmesi gereken görevleridir. Bu isterlerin sağlanmaması durumunda sistemde aksama ve bozulmalar yaşanabilir. 2. Örneğin : Hesap makinesinde dört işlemin yerine getirilmesi için yapılan hesaplamaları sistem kendiliğinden yerine getirir. 6.2 Fonksiyonel olmayan isterler 1. Sistemin onlar olmadanda işlemesinde herhangi bir sıkıntı olmayan lakin dış görünüş veya bazı formatlar açısından kullanımda yardımcı olan isterlerdir. 2. Örneğin : Hesap makinesindeki arayüzün kullanıcı dostu olması açısından düzenli ve çekici bir görünüşe sahip olması veya bir rapor programında şirketin verdiği rapor çıktısına uygun sayfa düzeninin yazılıma tanıtılmış olmasıdır. Ne kadar yazılımda risk etmesede şirket için belirli forma uygun olmaması sorun teşkil edebilir. Sistem Analizi Yöntemleri 7.1 Yapılandırılmış analiz (Kağıt prototip yöntemi) Eski bir metoddur. Fazlar şeklinde düzenlenir

63 Yazılı belgelere dayanır Proje yönetimi araçları ve tekniklerine çok uygundur. Gereksinimler çok erken tanımlanır. Değişiklikler çok maliyetli olabilir. Kullanıcılar fonksiyon ve özelliklerin örneklerini görmeden ihtiyaçları belirlemek zorunda kalabilir. 7.2 Nesne Tabanlı Analiz Objeler gerçek hayatı temsil eder. Her obje bir classa denk gelir. Nesne tabanlı analiz sistemin ne yaptığını odaklanır. Yeniden kullanılabilir bileşenler tasarlanarak hem sistemin geliştirilmesi hızlanır hemde geliştirme ve analiz maaliyeti azalmış olur. Büyük sistematik yazılımlarda karışıklık yapabilir.iş büyüdükçe daha karmaşık bir hale gelir. Şekil 3.Yapboz 7.3 Agile Yoğun bir takım çalışması gerektirmektedir.

64 Projenin öncelikle haftalık, aylık bazen de biraz daha uzun sürebilecek süreçler içerisinde değerlendirilir. Devam eden bu süreçte; tasarlanır geliştirilir ve test edilir. Esnek ve değişime müsaittir. Ürünleri bileşenler halinde test etmeye olanak sağlar. Uzman bilgi ve iletişim becerisi gerektirir. Yapı ve dökümasyon eksiklikleri görülebilir. Şekil 4.Agile Yapısı İster Analizi Raporu Gereksinimlerin rapor edilmesi ve isterlere göre projeye başlanması için gerekli rapordur. İki riskli durum söz konusudur; 1. Raporun gereğinden fazla detaycı ve büyük bir yaklaşım sergilemiş olması Bu gereksiz olduğu gibi maaliyet açısındanda büyük sıkıntı kaynağıdır. 2. Raporun üstün körü olması ve isterlerin tam anlaşılamama durumu Bu da yapılması istenen projenin dışında bir proje yapılması sonucu doğurabilir.

65 İster Analizinin Olmazları Maaliyetin çıkarılmış olması Tutarlı olması Gerçekci olması Doğrulanabilir olması Tekrar olmamalı ve net olmalı Önemli konular anlaşılmış olmalı Tutarlı olmalıdır. Takip edilebilir olmalı (Talebe göre referans verilmeli) İster Analizindeki Sorunlar Anlaşılamama durumları (Etki alanı analizi) İstek çakışmaları Adapte olma sorunu Bunun gibi sorunlar ortaya çıkabilir. Şekil 5.Çıkmazlar Referanslar Sadi Evren Şeker İş Analistli olmak, Analiz Raporları ve İster Analizihttps://

66 utr i2t4d5f.pdf acikarsiv.ankara.edu.tr/browse/26903/sistem%20analizi%20 Sunum-1.pdf content.lms.sabis.sakarya.edu.tr/uploads/49866/38790/09. hafta.pdf Proje Maliyet Yönetimi 1.Giriş Yazılım proje yönetimini tanımlamak için önce proje yönetiminin tanımlanması gerekmektedir. Proje yönetimi; etkinliklerin düzenlenmesi amacıyla bilgi, beceri, araç ve tekniklerin uygulanarak gereksinimlerin karşılanmasıdır. Proje yönetimi, başlama, planlama, yürütme, izleme, denetim ve kapanış işlemleriyle gerçekleştirilir. Projelerde insanın yanı sıra diğer kaynaklar da kullanılır. Bu kaynaklar projelere mali yükümlülük getirir Proje maliyet yönetimi yapılacak tüm harcamaların projenin planlanması aşamasında önceden tahmin edilmesini, bütçelenmesini ve proje devam ederken izleme ve kontrol sürecindeyken projenin maliyet kontrolünü içermektedir. Proje maliyet yönetimi kaynak planlaması, maliyet tahmini, maliyet bütçelemesi ve maliyet kontrolü olmak üzere dört temel alt süreçten oluşur. Öncelikle proje etkinliklerinin yürütülmesi için gerekli öz kaynaklar ve bunların ne miktarda kullanılacağının belirlenir daha sonra bu kaynakların toplam maliyet tahmini yapılır. Belirlenen bütçe çeşitli iş

67 kalemlerine dağıtılarak izleme ve kontrol gerçekleştirilir. Son olarak proje maliyetinde yapılacak değişiklikler kontrol edilir. 2.Proje Nedir? Proje, bir bir zaman noktasına sağlayacak yenilik getirmek üzere belirli bir yerde, belirli ve bütçe çerçevesinde, bir başlama ve bitiş sahip, hedeflenen belirli amaçlara ulaşılmasını olan faaliyetler topluluğudur. Bir fikrin, bir hedefin, bir gelişimin vb. hayata geçirilmesi için gereken amaç odaklı, organizasyonlu aksiyondur. Yeni bir sistem, ürün, tesis, yapı, vb. ortaya koymak için gereken sürecin bütünüdür. Proje boyutlarının çok büyümesi, birden fazla proje içermesi,, geliştirilen ürünün belirli bir takvime göre tekrarlanarak uygulanma gereksinimi olması durumunda proje bir program haline dönüşür.

68 Tablo 1: Proje çeşitleri örnekleri. 3.Proje Yönetimi Yönetim, etkinliklerin insanlar tarafından ve insanlar üzerinden hem etkin hem de verimli bir şekilde yapılmasını sağlayan süreçtir. Bu süreci tanımlayabilecek Modern Proje Yönetim Bilimi 1950 li yılların sonlarında ortaya çıkmıştır. İlk başlarda öncelikle inşaat ve mühendislik alanlarında kullanılan bu tekniğin uygulama alanları giderek genişlemiş bilişim, sağlık, eğitim, savunma, medya, bankacılık gibi pek çok alanda etkin bir biçimde kullanılmaya başlanmıştır. Proje yönetimi, belirli bir projenin hedef ve amaçlarına ulaşıp bitirilmesi için kaynakların planlanması, organize edilmesi, tedarik edilmesi ve yönetilmesi işlemidir. Proje Yönetiminde gösterilen temel çaba, proje hedef ve amaçlarına ulaşmaya çalışırken önceden belirlenmiş proje kısıtlarının da dışına çıkmamaktadır. Tipik proje kısıtları; kapsam, zaman ve bütçedir.

69 Şekil 1: Proje Yönetimi Üçgeni. Proje yönetimi çeşitli alanları kapsayan alt süreçler ve onların bileşenleri halinde yürütülür. Şekil 2: Proje Yönetim Süreçleri.

70 Bu alt süreçler, her biri ayrı birer yönetim süreci olan aşağıdaki bileşenlerden oluşur. Proje Kapsam Yönetimi: Projenin öngörülen hedeflerine başarıyla ulaşması için gerekli ve yeterli tüm çalışmaların yerine getirilmesini sağlayan süreçleri tanımlar. Proje Zaman Yönetimi: Projenin zamanında tamamlanmasını sağlayan süreçleri tanımlar. Proje Maliyet Yönetimi: Projenin onaylanmış bütçe sınırları içinde tamamlanması için gerekli süreçtir. Kaynak planlaması, maliyet tahminleri, maliyet bütçeleme ve maliyet denetimini kapsar. Proje Kalite Yönetimi: Projenin ihtiyaçlarını tam olarak karşılayacağı bir sistem oluşturma sürecidir. Proje İnsan Kaynakları Yönetimi: Projede yer alacak doğru kişilerin belirlenmesi ve bu kişilerin en etkili şekilde görevlerini yapması süreci olarak tanımlanır. Proje İletişim Yönetimi: Projenin sağlıklı ilerleyebilmesi için, proje çerçevesinde bir araya gelmiş farklı kişiler arasında etkin bir iletişim ağı kurulma sürecidir. Proje Risk Yönetimi: Proje risklerinin tanımlandığı, çözümlendiği ve önlemlerin alındığı süreçleri tanımlar. Proje Tedarik Yönetimi: Hemen hemen tüm projelerde proje dışından mal ve hizmet alımı yapılır. Bunların sistemli bir şekilde yürütülmesidir.

71 Şekil 3: Proje Yönetim Süreci bileşenleri. 4.Proje Maliyet Yönetimi Ekonomik unsurların son derece önemli ve ön planda olduğu günümüz dünyasında maliyet yönetimi bir firma, kurum ya da kuruluşun varlığına etki eden en önemli etmenlerden birisidir. Bu amaçla yürütülen Proje Maliyet Yönetimi, projenin onaylanmış bütçe sınırları içinde tamamlanmasını sağlamayı hedefler. Maliyet yönetimi aşağıdaki süreçleri kapsamaktadır: 1. Kaynak Planlaması: Proje etkinliklerinin yürütülmesi için gerekli öz kaynakların (insan, cihaz, malzeme) ve bunların ne miktarda kullanılacağının belirlenmesi. 2. Maliyet Kestirimi: Proje etkinliklerinin tamamlanması için gereksinim duyulan kaynaklar için toplam maliyet tahmininin yapılması. 3. Maliyet Bütçelemesi: Genel maliyet tahmininin çeşitli iş kalemlerine dağıtılarak izleme ve değerlendirme için temel oluşturulması. 4. M a l i y e t Kontrolü: Proje bütçesine yapılacak değişikliklerin kontrol edilmesi.

72 Maliyet yönetimi sayesinde; Bilgi sistemi geliştirme sürecinin kolaylaştırılması, Gecikmelerin önlenmesi, Daha etkin kaynak kullanımının sağlanması, İş zaman planının etkin olarak gerçekleştirilmesi, Ürünün sağlıklı olarak fiyatlandırılması, Ürünün zamanında ve hedeflenen bütçe sınırları içerisinde bitirilmesi sağlanır. Şekil 4: Proje Maliyet Yönetim Süreci. 4.1.Kaynak Planlaması Kaynak planlama, proje faaliyetlerinin gerçekleştirilmesi için gerekli olan insan, araç ve materyal gibi kaynakların hangi miktarda kullanılacağının belirlenmesidir. Kaynak planlamasında faaliyetleri gerçekleştirmenin zorluk dereceleri, iş paketlerinin neler olduğu, ne gibi kaynaklar gerektirdiği ve bu kaynakların ne ölçüde temin edileceği sorularına cevap aranır. Bilgisayar sistemleri geliştirme projeleri için donanım, yazılım ve insan olmak üzere gerekli kaynakları üç grupta toplayabiliriz.

73 4.1.1.Donanım Kaynakları Bilgisayar tabanlı bir sistemi geliştirmek ve çalıştırmak için mutlaka yeterli donanımın bulunması bir ön koşuldur. Günümüzde giderek açık sistem mimarisine dönüşmektedir. Donanım Kaynakları: Ana Bilgisayarlar Sunucular (Web, E-posta, Kullanıcı Bilgisayarları Yerel Alan Ağı (LAN) Alt Geniş Alan Ağı (WAN) Alt Veri Tabanı) (PC) Yapısı Yapısı Yazılım Kaynakları Büyük ölçekte otomatik hale getirilmiş ve bilgisayar destekli olarak kullanılmaktadır. Bilgisayar Destekli Tasarım (CAD) ve Bilgisayar Destekli bilinmektedirler. Mühendislik (CASE) araçları olarak Günümüzde yazılım geliştirebilmek için kullanıma sunulmuş pek çok tümleşik geliştirme ortamı bulunmaktadır. Planlayıcı her türlü yazılım paketi için gereksinimleri baştan belirlemelidir. Verilen kararlar neticesinde genel proje bedeli oluşturulur İnsan Kaynakları Yazılım projesi ancak belirli bir örgütlenmeye göre düzenli ve disiplinli bir şekilde çalışan insan/insan grubu sayesinde başarıya ulaşabilir. Küçük projelerde bir ya da birkaç kişi tüm işleri halledebilir ancak büyük projelerde planlayıcı tarafından yönetici, kıdemli mühendisler, görevliler ve tüm geliştirici personel belirlenmelidir. Bir yazılım projesinde çalışacak personel sayısını belirlemek için metriklere dayanan bir iş gücü çözümlemesi yapılmalı, kaç kişinin ne kadar süreyle çalışacağı bunun maliyetinin ne olacağı

74 hesaplanmalıdır. Tablo 2: Projede hangi tür elemanlarının yer alacağını belirleyen bir tablo Planlama Yazılım proje planlayıcısı sonuç olarak geliştirmeye esas üç şeyin kestirimini yapar: gerekli zaman, gerekli çaba ve gerekli personel sayısı. Bunlara ek olarak, geliştirme ve test için kullanılacak yazılım ve donanım malzemesinin kestirimi yapılmalı, olası risklerin önceden görülmesine çalışılmalıdır. Proje boyunca kullanılacak personel, makine, hizmet ve malzeme gibi öz kaynakları tanımlamak ve bunların kullanım ilkelerini belirlemek üzere Öz Kaynak Yönetim Planı (Resource Management Plan) hazırlanabilir. Bu plan aşağıdaki bilgileri içerir: Personel: Her bir kişinin adı, bölümü, iletişim adresi, çalışma takvimi, proje deneyimleri, uzmanlık alanları, devam eden projeler, normal ve fazla mesai ücreti, uygun olduğu zaman aralıkları. Makine: Makinenin adı, kodu, demirbaş veya kira durumu, özellikleri, bulunduğu yer, ekonomik ömrü, işletme maliyeti ve amortisman gibi değerler.

75 Yazılım: Geliştirme etkinliklerinde kullanılacak her türlü yazılım paketine ait ad, özellik, ortam, sürüm, kullanım yeri, maliyeti, lisans sayısı ve süresi, erişim durumları. Malzeme: Malzemenin adı, özelliği, cinsi, satın alma maliyeti, stok durumu, dayanma ömrü. Sağlayıcı: Bir kaynağın satın alınacağı yer olan sağlayıcı firma bilgileri, deneyimleri, üstleneceği yükümlülükler, iletişim bilgileri. Şekil 5: Kaynak Planlaması. 4.2.Maliyet Kestirimi Maliyet kestirimi, proje faaliyetlerinin tamamlanması için gerekli kaynakların maliyetlerinin yaklaşık olarak belirlenmesi sürecidir. Fiyatlandırma ise maliyet tahmini yanında daha birçok unsuru da göz önünde bulunduran bir iş kararıdır. Matematiksel olarak; Yazılımın fiyatı=maliyet + kar olarak tanımlanabilir. Kurumsal, iktisadi, siyasi ve ticari etkenler fiyatlandırmayı etkiler.

76 4.2.3.Maliyet Kestirim Yöntemleri Projenin toplam süresi, projenin toplam maliyeti, toplam satır sayısı, projede çalışan eleman sayısı-niteliği-çalışma süresi, bir kişi-ay maliyeti gibi bilgiler proje bittikten sonra ya da projenin çoğu bittikten sonra diğer projeler için maliyet kestirimi hakkında önemli bilgiler verir. Maliyet kestirimi çeşitli teknikler ve araçlar kullanılarak yapılabilir. Bunlardan biri benzeşim yoluyla kestirimdir. Yukarıdan aşağıya değerlendirme; sistemin mimarisi ve bu sistemin parçası olabilecek bileşenler hakkında bilgi olmadan da yapılabilir. Bütünleşme, yapı yöneticiliği ve belgelendirme maliyeti dikkate alınarak hesaplanır. Aşağı seviyede teknik sorunların çözümü ile bağlı maliyetlerin değerlendirilmemesi sorun oluşturabilir. yeterince Aşağıdan yukarıya değerlendirme ise sistemin mimarisi belli ise ve bileşenler tanımlanmış ise kullanılabilir. Eğer sistem ayrıntılı tasarlanmışsa kesin sonuçlar veren yaklaşımdır. Bütünleşme ve belgelendirme gibi yüksek seviye girişimleri maliyetlerinin oluşturabilir. yeterince dikkate alınmaması sorun Tablo 3: En çok bilinen maliyet kestirim model/modelleri.

77 Bu yöntemler projenin büyüklüğüne, yöntemlerin uygulanış biçimi gibi durumlara göre sınıflandırılmaktadır. Bu yöntemlerin ortak özellikleri şöyledir: Projenin uygulandığı aşamaları temel olarak girdi alması, Projeye ilişkin çevresel özellikleri girdi olarak alması, Doğrusal ya da doğrusal olmayan denklemler kullanması, Projeye ilişkin, satır sayısı, işlev nokta sayısı, zaman, iş gücü, parasal maliyet gibi çıktılar vermesi. En sık kullanılan maliyet kestirim yöntemlerinden ikisi İşlev Noktaları ve Etkin Maliyet Yöntemi COCOMO dur. Değerlendirmeler başlıca olarak deneyime dayalıdır. Ancak yeni yöntem ve teknolojiler bu tür değerlendirmelerin kesinliğini azaltır. Bu yöntemler; İşleve yönelik geliştirme yerine nesneye yöneliktir. Büyük bilgisayar sistemleri yerine istemci-sunucu sistemleri vardır. Standart (satılan) bileşenlerden oluşur. Bileşen tabanlı yazılım mühendisliğidir. Yazılım Geliştirme araçları ve program üreticilerinden oluşur COCOMO COCOMO, 1981 yılında Boehm tarafından yayınlandıktan sonra çokça ilgi görmüş bir maliyet kestirim modelidir. Uygulama, kullanılacak ayrıntı düzeyine göre üç ayrı model biçiminde yapılabilir: 1. Temel model 2. Ara model 3. Ayrıntı model Tüm COCOMO modelleri temel girdi olarak satır sayısı

78 kestirimini alır ve çıktı olarak iş gücü ve zaman çıktılarını verir. İş gücü değerinin zaman değerine bölünmesiyle yaklaşık olarak kişi sayısı kestirimi elde edilmiş olur. Şekil 6: COCOMO Modeli. Tüm COCOMO modelleri iş gücü ve zaman değerleri için doğrusal olmayan üssel formüller kullanır; İş Gücü (K) K=a*Sb Zaman (T) T=c*Kd a,b,c,d : her bir model için farklı katsayılar S : bin türünden satır sayısı Farklı proje türlerinde kullanılan değişiklik göstermektedir. COCOMO formülleri A. Temel Model Küçük ve orta boy projeler için hızlı kestirim yapmak amacıyla kullanılır. Avantajı: Hesap makinesi ile kolayca uygulanabilir olmasıdır. Dezavantajı: Yazılım projesinin geliştirileceği ortam ve yazılımı geliştirecek ekibin özelliklerini dikkate almaz.

79 Şekil 7: Farklı projelerde kullanılan COCOMO model formülleri. B. Ara Model Temel modelin eksikliğini gidermek amacıyla oluşturulmuştur. Bir yazılım projesinin zaman ve iş gücü maliyetlerinin kestiriminde; Proje ekibinin özelliklerini, Proje geliştirmede kullanılacak araçları, yöntem ve ortamı dikkate alır. Üç Aşamadan oluşur: 1. İş gücü hesaplama 2. Maliyet çarpanı hesaplama 3. İlk iş gücü değerini düzeltme 1.İş Gücü Hesaplama

80 2.Maliyet Çarpanı Hesaplama Maliyet Çarpanı Hesaplama: 15 maliyet etmeni çarpımının sonucudur. 3. İş gücü değerlerini düzeltme Kd = K x C (Kd = Düzeltilmiş İşgücü) Temel Formüldeki Zamanla formülü kullanılarak zaman maliyeti hesaplanır. C. Ayrıntı Model Temel ve ara modele ek olarak iki özelliği vardır. Aşama ile ilgili işgücü katsayıları: Her aşama için (planlama, analiz, tasarım, geliştirme, test etme) eşit düzeyde karmaşıklık düzeyine sahip değildir. Bunun için her aşama farklı ağırlıktadır. Üç düzey ürün sıra düzeni: Yazılım maliyet kestiriminde Modül, Alt Sistem, Sistem Sıra düzenini dikkate alır. Yani maliyet kestirimleri önce modül en son sistem bazında gerçekleştirilir. 4.3.Maliyet Bütçeleme Proje başarımını ölçebilmek için önce dayanak olarak kullanılabilecek bir maliyet sabitlemesinin yapılması

81 gereklidir. İzleme ve değerlendirme amacıyla, tahmin edilen tüm bütçeyi alt etkinliklere ve iş paketlerine paylaştırarak bir maliyet bütçelemesi yapılır. Maliyet bütçelemesi zaman bağlı olarak yapılan bir planla sabitlenir. Ödemeler taraflarca uzlaşılan bir takvime göre, projelerin belirli aşama noktalarında ve zamana yayılmış bir şekilde yapılabilir. Eğer hedeflerde değişiklik olmuşsa bunun maliyete etkisi en kısa zamanda değerlendirilmeli ve ona göre bütçelendirilmelidir. 4.4.Maliyet Kontrolü Şekil 8: Kontrol döngüsü. Proje kontrol sürecinde gerçekleştirilen maliyet kontrolü, plandan sapmaları, maliyet performans kontrolünü ve proje bütçesinin güncellenmesini kapsar. Bu süreçte maliyette meydana gelen pozitif veya negatif değişimler için neden sorusunun cevabı aranır. Maliyet kontrolü kazanılmış değer hesaplamasıyla yapılır. Planlı bir iş birimi tamamlandığında o ana kadar o iş için harcanmış maliyetler toplanır, önceden yapılan kestirimler sonucu elde edilen değerle karşılaştırılır ve o iş için ne kadar kar veya zarar olduğuna bakılır. Proje yöneticisi kazanılmış değere göre ilerlemeyi ölçmelidir.

82 Kazanılmış Değer Analizi: Projenin performansını zaman, maliyet ve kapsama göre ölçmek için kullanılır ve kazanılmış değer ölçümü ile proje izlenir. Bunun sonucunda projenin ne kadara mal olacağı, belirlenen sürede tamamlanıp tamamlanmayacağı, tamamlanmazsa ne kadar daha maliyet gerekeceği, önleyici ve düzenleyici önlemlerin alınmasını, projenin güncellemesinin yapılmasını ve proje paydaşlarının bilgilendirilmesini sağlar. Maliyet kontrol sürecinde bütçe aşımı söz konusu ise kabul edilebilir seviyelere çekilmesi sağlanmalıdır. Gerçekleşen değişimlerin iyi yönetilmesi ve proje paydaşlarının bilgilendirilmesi gerekir. 5.Referanslar /ymg_hafta_3.pdf mi 6. imi-221.pdf 7. oads/2015/11/proje-y%c3%b6netimi-1-3.pdf 8. e=web&cd=4&ved=0ahukewi4jrndlqjxahusfowkhaszab8qfghjmam& url=http%3a%2f%2fmimoza.marmara.edu.tr%2f~burakarzova%2f projeyonetimi.ppt&usg=aovvaw1ind_b1ao6jzfdpyv6oira e=web&cd=1&ved=0ahukewjw0nprhajxahxrguwkhxthbr4qfggpmaa& url=http%3a%2f%2fmembers.comu.edu.tr%2fmsalahli%2fproje_ web%2fproje_9.ppt&usg=aovvaw0r9ikim_vndcb-0yostjnc

83 11. e=web&cd=1&ved=0ahukewjmipxrl6jxahuraqkhv7aamkqfggpmaa&url=http%3a%2f%2fyunus.hacettepe.edu. tr%2f~gkose%2f bahar%2fbstlecture1.ppt&usg=aovvaw 1QdB_YlUdZaaq8Ro-feKhp kisi.deu.edu.tr/userweb/ozlem.dogan/proje%20ynt.ppt 13. Burhan Albayrak, Proje Yönetimi Analizi ve Danışmanlık, Nobel Akademik Yayıncılık Eğitim Danışmanlık TİC. LTD. ŞTİ., Nisan Dr. Ali Nizam, Yazılım Proje Yönetimi, Papatya Yayıncılık Eğitim, Ocak Dr. M. Erhan Sarıdoğan, Yazılım Mühendisliği, Papatya Yayıncılık Eğitim, 2.Basım Ocak 2008 YAZILIM BAKIMI 1.Yazılım Bakımı Nedir? (Software Maintenance) Bilgisayar tabanlı sistemlerin tasarlanıp geliştirilmesinden ve kullanıcıya tesliminden sonra bakım (maintenance) aşaması başlar. Bilgisayar tabanlı sistemlerde bakım donanım bakımı ve yazılım bakımı olarak ayrılabilir. Donanım bakımı eskimiş veya arızalanan parçaların değişimi veya parçaların temizlenmesi şeklinde yapılır. Yazılım bakımında ise bu tür eskime veya değişim durumu yoktur. Yazılım bakımında zaman içerisinde ortaya çıkan yeni isteklerin karşılanması ve oluşan hataların giderilmesi yazılım bakımının temelini oluşturur. Yazılım bakımı, yazılım mühendisliğinin temel konulardan

84 birisi ve yazılım yaşam döngüsünün ayrılmaz bir parçasıdır. Ana amacı teslimat sonrasında çıkan sorunları gidermek ve performansı artırmak için yazılım uygulamasını değiştirmek ve güncellemektir. Bu değişimler basit kodlama hatası şeklinde olabileceği gibi tasarımdan kaynaklanan hataların giderilmesi şeklinde de olabilir. Yazılım bakımı, yazılımın yaşamına devam edebilmesi için gerekli değişikliklerin uygulamasıdır. Yazılım, gerçek dünyanın bir modelidir. Gerçek dünya değiştikçe yenilikler oluştukça, yazılımda da değişiklik gerektirir. Yazılım bakımı, yazılımın uygulanmasındaki en zor işlerden biridir. Bu zorluğun temel nedenlerinden biri yeterli deneyime sahip olmayan personelin bakımcı olarak çalıştırılması ve yazılım üreten işletmelerde bakım için ayrı bir iş bölümümün tanımlanmamış olmasıdır. Bir yazılımda yazılım geliştirme yazılımın %40 maliyetini, bakım ise %60 maliyetini etkilemektedir. İyi bakım iyi bakımcılar ile yapılır. Bakımı yapan kişiler en az bakımın yönetimi, süreçlerin analizi ve bakımın sonuçlandırılması kadar önemlidir ve yazılım bakımına ait insan kaynakları üç temel alanda sınıflandırılmaktadır 2.Yazılım Bakımının Temelleri Yazılım bakımı gelişen koşullara göre ortaya çıkar. Yazılım bakımı, yazılımın geliştirilmesinden daha fazla zaman ve iş gücü gerektirir.

85 2.1.Bakım Türleri Düzeltici Bakım Uyarlayıcı Bakım İyileştirici Bakım Önleyici Bakım 2.2.Örgütlenme 2.3.Bakım Aşamaları 2.4.Raporlama 2.1.Bakım Türleri Düzeltici Maintanence) Bakım (Corrective Yazılımın teslim edilmesinden sonra kullanıcı tarafından bildirilen yazılım kusurlarının düzeltilmesi, yazılımda değişiklikler yapılması amacını taşımaktadır. Kodlama hatalarını düzeltmek genelde az maliyetlidir. Tasarımdan kaynaklı hataların giderilmesi yüksek maliyetlidir. Çünkü tasarımdan kaynaklı hatalarda bazı sistem bileşenlerini baştan yazmak gerekebilir Uyarlayıcı Maintenance) Bakım (Adaptable Yazılımın teslim edilmesinden sonra, çalışma ortamının, işletim sisteminin, üzerinde veya birlikte çalıştığı donanım ürünlerinin değişmesi durumunda, yeni çalışma ortamına ait gerekli değişikliklerin ve uyarlamaların yapılması amaçlanmaktadır.

86 İyileştirici Mainteance) Bakım(perfective Yazılımın teslim edilmesinden sonra, yazılımın performansının artırılması veya yeni özelliklerin eklenmesiyle yazılıma gelecek yeni versiyonlar kazandırılması amacıyla yapılan değişikliklerdir Önleyici Maintenance) Bakım ( Preventive Yazılımın teslim edilmesinden sonra, olası yanlışları önlemek amaçlı olarak yapılan bakım türüdür. Sistemin performansı, verimliliği, güvenliği ve güvenilirliğini devam ettirmek için yapılan bakım türüdür. Lientz ve harcanan uyarlayıcı bakım için Swanson un çalışmasına göre, bakım türlerine göre çaba aranları; iyileştirici bakım için %50, bakım için %25, düzeltici bakım için %20 e önleyici %5 olarak verilmektedir. 2.2.Örgütlenme Genel olarak yazılım geliştiriciler bakım işleri için özel bir ekip ayırmazlar. Ancak yazılımla ilgili kullanım sırasında ortaya çıkan sorun veya yeni kullanıcı gereksinimlerinin değerlendirilmesi belirli bir örgütlenmenin tanımlanması gereklidir.

87 2.3.Bakım Aşamaları Bakım evresinde bulunan yazılım için bir bakım işi ortaya çıktığında geliştirici tarafından bir süreç izlenmelidir. Bu sürecin aşamaları tıpkı yazılım geliştirme sürecine benzer. Tek farkı hazır olan bir belge ve kod yapısı üzerinde değişikliklerin uygulamasıdır Müşteri Talepleri Yazılımın temel amacı müşterinin problemlerine çözüm sunmak ve gereksinimlerini karşılamak olduğu düşünüldüğünde bu aşamanın projenin temelini oluşturduğu görülür. Müşteri istekleri, uygulanabilirlik, donanım yeterlilikleri, süre ve maliyet konuları detaylı şekilde değerlendirilmeli, tüm konular açıklığa kavuşturulduktan sonra sözleşme hazırlanmalıdır. Bu aşamada değerlendirilmeyen veya gözden kaçan hususlar gereksiz

88 masraflara, zaman kaybına hatta projenin yarım bırakılmasına sebep olabilir Planama Projeye başlamadan önce kullanıcı istekleri de dikkate alınarak proje gereksinimleri belirlenir. Projenin başlangıcından sonuçlandırılmasına kadar ki sürede izlenecek yol ve yöntemler ile donanım maliyeti, personel iş bölümü, proje yöneticisinin öngörü ve seçimleri, proje adımlarının sürece dağıtılması gibi unsurlar bu evrede değerlendirilir Çözümleme ve Tasarım Sistemin çalışmasıyla ilgili işlev ve görevler donanım, yazılım ve kullanıcılara dağıtılır. Donanım için tanımlamalar yapılarak hazır ticari ürünlerin siparişleri verilir, özel donanımlar tasarlanıp geliştirilir ve üretimi yapılır. Kullanılacak donanımlara göre yazılım ihtiyaçları belirlenerek, çalışma ortamı ve veritabanı modellenir, kütüphaneler oluşturulur, kullanıcı ara yüzü tasarlanır, kodlama yapılır, hatalar giderilir ve modüller birleştirilerek yazılım oluşturulur Sistem Tümleştirme Geliştirilen yazılım öğeleri, üretilen ya da hazır olarak alınan donanım öğeleriyle tümleştirilir. Tümleştirme işlemi karmaşık donanım yapılarının birlikte çalıştığı projelerde daha titiz bir çalışma gerektirir. Bu aşama için yeterince zaman ayrılarak üretilen prototipler üzerinde deneysel testler yapılır, hata oranları incelenir, gerekli görülürse yazılımsal ve donanımsal düzenlemeler gerçekleştirilir. Bu süreç aynı zamanda sistemin doğrulama ve sağlamasını da içerir. 2.4.Raporlama Kullanıcının bakım isteği olduğu gibi yazılım geliştirme sırasında da bakım istekleri ortaya çıkabilir. Bu isteklerin

89 standart bir şekilde ortaya konulması gerekir. Yazılımda bir değişiklik yapılması için istekler Değişiklik Önerisi(Change Proposal) ile sorunlar da Yazılım Sorun Raporu(Software Trouble Report) ile bildirilir. Değişiklik Önerisi kullanıcı tarafından verilebileceği gibi yazılım geliştirici personel tarafından da bir öneri şeklinde verilebilir. Değişiklik Önerisi en az aşağıdaki bilgileri içermelidir.. Sistem veya alt sistem adı. Değişikliğin tanımlanması.yapıların değişiklikten etkilenmesi. İsteğin öncelik derecesi.isteğin numarası (takip edilmesi için ). Öneriyi inceleyen makamların imzaları ve tarihleri. Karar (incelemenin sonunda oluşturulur.) Herhangi bir yazılım kusurunu raporlamak için kullanılan Yazılım Sorun Raporu da benzer şekilde olup en az aynı bilgileri içerir. 3.Bakım Kolaylığı Bir yazılımın önemli özelliklerinden biride yazılım kolaylığıdır. Bu özelliği yazılımın anlaşılmasındaki, düzeltilmesindeki, uyarlama ve iyileştirilmesinde kolaylıklar olarak tanımlayabiliriz. Teknik olarak istenilen her istek gerçekleştirilebilir ancak önemli olan, bunu en düşük maliyette en kısa sürede, doğru olarak ve yazılım sistemini bozmadan yapmaktır. Ve bir yazılım birden fazla bakıma uğrayabilir bu nedenle bakıma etki eden etmenler dikkate alınmalıdır.

90 3.1.Denetim Etmenleri Yazılım bakımının önemi hem geliştirici tarafından hem de kullanıcı tarafından uzun vadede anlaşılır olmasıdır. Bu önemin iyi bir şekilde anlaşılmasında yazılım bakımını denetleyen çeşitli etmenlere bağlıdır Geliştirme Ortamına Bağlı Olanlar. Yazılım geliştirme personelinin varlığı. Sistem yapısının anlaşılması. Sistemin işletim kolaylığı. Standart bilgisayar donanımı kullanımı. Standart işletim sisteminin kullanımı. Standart programlama dillerinin kullanımı. Standart belgelendirme yöntemlerinin kullanımı Personele Bağlı Olanlar. Personelin iş disiplini. Kullanılan geliştirme sürecindeki deneyim. Personelin aynı konudaki geliştirme deneyimi. Personelin uygulama alanı hakkındaki bilgisi Müşteriye Bağlı Olanlar. Kullanıcıların tek veya çok sayıda olması. Müşteri isteklerinin değişme sıklığı. Müşteri ile geliştiricinin yazılım yaşam çevrimi boyunca olan ilişkisi

91 . Müşterinin ortam değiştirme sıklığı. Uygulama alanı isterlerinin değişme sıklığı 3.2.Bakımın Niteliği Bir yazılım projesinin nitelikli bir bakım evresine sahip olabilmesi için işin başında bazı noktalara önem verilmesi gereklidir..bakım istekleri her zaman bir kapsamında ele alınmalıdır. Değişim.Bakım istekleri getirebilmelidir. hızlı.bakım istekleri yapılabilmelidir. yeterince için süre ve Denetim olarak maliyet Süreci yerine kestirimi.bakım isteklerinin durumu sistematik olarak izlenmelidir..bakım istekleri her zaman resmi olarak tanımlanmalı ve yönetilmelidir. Bakım istekleri gelişigüzel ele alınmamalıdır..bakım sırasında da geliştirme standartlara uyulmalıdır. sürecinde.verimliliği artırıcı kullanılmalıdır. kolaylaştırıcı ve bakımı izlediğimiz araçlar.uygun özellikte teknik personel kullanılmalıdır. 3.3.Niceliksel Ölçümler Bakım işlemlerinin özelliklerini dikkate alarak bazı metrikleri ortaya koymak ve niceliksel ölçümler yapmak mümkündür. Ancak nitelik ve güvenirlik oldukça zordur. Bu niceliksel metriklerin önemli ve yaygın olanları şunlardır:

92 . Sorunu belirlenip ve rapor edilmesi.idari işlemlerdeki gecikme süresi.sorunların çözümlenme süresi.değişiklik tanımlanması için geçen süre.sorun bildirimlerinin müşterilere göre dağılımı.sorun bildirimlerinin hatalara göre dağılımı.sorun bildirimlerinin modüllere göre dağılımı.düzeltilmesi için geçen zaman.yerel test süresi.toplam süre.toplam iş gücü ve maliyet 3.4. Bakım Sorunları Bakım sırasında karşılaşılan sorunları bilmek,soruna karşı hazırlıklı olabilmek için yarar sağlayacaktır. Geliştirilen yazılımın bakıla bilirlik özelliğinin eksik olmasının asıl kaynağı bir disiplin içerisinde geliştirilmemiş olmasıdır. Sorunları şu şekilde sıralayabiliriz:.bakımın çok fazla sürümü ortaya çıkarsa bakım o derece zorlaşır..yazılımın geliştirildiği süreci aynen takip etmek zaman ve işgücü açısından çoğu zaman olanaksızdır..bir başkasının yazdığı kodu anlamak oldukça zaman alır. Eğer kod içerisindeki açıklamalar yetersiz ise ciddi sorunlar ortaya çıkabilir..belgelendirme yetersiz, eksik veya hatalı olabilir bu durum karşısında yalnızca kodu okuyup anlamamız gerekir.

93 .Yazılım üzerinde değişiklik yapılabilecek şekilde tasarlanmadıkları bir gerçektir. Eğer belirli nesnelerden oluşmuyorsa yazılım üzerinde değişiklik yapmak. 3.5.Geliştirici İçin Kurallar. Bakım isteklerinin durumu sistematik olarak izlenmesi. Bakım istekleri her zaman resmi bir Değişiklik Denetim Süreci kapsamında ele alınmalıdır.. Bakım istekleri için süre ve maliyet oranlarını doğru olarak yapılabilmelidir.. Müşterinin yazılımla ilgili bildirdiği sorun veya yeni gereksinimler proje yöneticisin görevlendireceği bir kişi veya ekip tarafından toplanmalıdır.. Bakım projeleri tanımlanmalı ve yönetilmelidir.. Bakım sırasında da geliştirme sürecinin belgelendirme standartlarına uymalıdır.. Verimliliğe yardımcı olacak araçlar kullanılmalıdır.. Uygun nitelikte teknik personel kullanılmalıdır 4.Bakımın Yan Etkileri Yazılımın bakımı genellikle biraz tehlike içerir. Test edilmiş ve kullanıma sunulmuş bir üründe küçük sayabileceğimiz bir değişiklik bile, iyi çözümlenmez ve iyi tasarlanmaz ise bu büyük yan etkilere yol açabilir. Karmaşık bir algoritmada küçük bir değişkenin değerinin değişmesi yada yeni bir deyimin eklenmesi tüm yazılımın hatalı çalışmasını veya çökmesine yol açabilir. Kodlamanın Etkilenmesi

94 Verilerin Etkilenmesi Belgelendirmenin Etkilenmesi Başarımın Etkilenmesi 4.1. Kodlamanın Etkilenmesi İnsanoğlu bilgisayar donanımı ile programlama dili aracılığı ile iletişim kurmaktadır. Kodların bir kısmı otomatik olarak üretilse de büyük bir kısmı elle yazılmaktadır. Buda hatalara açık olması demektir. Yazılım mühendisliği ne adar iyi olursa olsun, kod yazan kişilerin deneyimi, disiplini ve dikkati büyük önem taşır. Bazen bakım sırasında kod içinde bir tek deyim satırını değiştirmek bile büyük hatalara yol açabilir. Veya geçici olarak eklenen deyimler unutulabilir. Test sırasında veya kullanım sırasında olumsuz sonuçlar doğurabilir. Aynı şekilde geçici olarak çalışması engellenen deyimlerin sonradan açılması unutulabilir ve bu deyimler de yanlış çalışmaya neden olabilir. En çok hataya yol açacak kod deyimleri şunlardır:.bir deyim silinmiş veya değiştirilmiş olabilir.. Bir tanımlayıcı silinmiş veya değiştirilmiş olabilir.. Değişiklikler başarımı arttırmaya yönelik olarak tanımlanmış olabilir.. Mantıksal operatörlerin değiştirilmesi.. Dosya giriş/çıkış için gerekli olan dosya adı, dizin adı ve açma/kapama tutamaçlarında değişiklik yapılmıştır.. Farklı dosya veya modüllerde bulunan, fakat aynı adı taşıyan

95 tanımlayıcılar birbiri yerin kullanma karmaşıklığına yol açmıştır.. Küçük olarak görülen taraşım değişikliği büyük oranda kod değişimine yol açmıştır..tip değişkenlerinin yapılaması nedeniyle verilerin sınır değeri değişmiştir.. Değişiklik sonrası kod içerisindeki fazla satırlar ve akışı izleme düzenekleri bırakılmıştır, bunlar sistemin başarımını etkilemiştir Verilerin Etkilenmesi Veri yapısının değişmesi de tasarım ile uyumunu ortadan kaldıracağı için tasarımında mutlaka bu verilerin değişikliğine uyulması gerekmektedir. Aşağıdaki değişiklikler çoğunlukla hatanın kaynağı olarak değerlendirilir.. Evrensel değişkenlerin, sabitlerin, biçemlerinin tekrar tanımlanması. kayıt ve dosya. Dizilerin boyları veya veri tiplerinin sınır değerlerinin değişmesi.. Evrensel veriler üzerinde değişiklik yapılması.. Durum değişkenlerine, işaretçilere ilk değer atamalarının yeniden yapılması.. Yordam parametrelerinin yeniden düzenlenmesi.. Giriş/çıkış için kullanılan veri yapılarının düzenlerinin değiştirilmesi Belgelendirmenin Etkilenmesi Yazılım bakımı sadece koda yönelik değildir. Belgeler ve tüm yardımcı araçlarla birlikte, yazılım düzenleşim sistemine

96 giren her şey bakım işlemine dahildir. Herhangi bir değişiklik kod içerisinde olduğu kadar belgelere de değişiklik yapılmalıdır. Veri akışında, tasarımda, yazılım mimarisinde, algoritmalarda yapılan bir değişiklik belgeler de işlenmelidir. Çünkü daha sonra değişiklik yapanlar yazılım özelliklerini anlamakta zorluk çekebilirler bundan dolayı yapılan değişiklikler eksiksiz bir şekilde belgelere işlenmelidir. Bu belgeler kullanıcı açısında bir kullanım kılavuzlarıdır. Eğer bir değişiklik yapılmış ve bu kullanım kılavuzlarına işlenmemişse bunun yan etkileri kullanım sırasında ortaya çıkar. 4.4.Başarımın Etkilenmesi Bazı yazılımlar sisteminde genel başarımını ön planda tutmak zorundadırlar. Böyle sistemler üzerinde bakım yapılırken, işlevsel bir değişiklik yapıldığında başarım olumsuz olarak etkilenebilir. Yeni bir özellik için eklenen veri yapısı bellek gereksinimlerini artırabilir. Bakım amacıyla yapılan bir değişiklik çalışmanın yanında azaltılmış başarıma yol açabileceği için dikkatli kodlama ve test gereklidir. 5. Belgelendirilmemiş Yazılımların Bakımı Yazılım geliştirmekle görevli grupların amaçları istenen bir sorun da hiçbir kayıt ve belge bulunmayan eski yazılımların bakımını yürütmektir. On veya yirmi yıl önce yazılmış kodların bugün tekrar kullanmak için yeni ortamlara uyarlamak değişiklik yaparak kullanmaya devam etmek gerekebilir. Bu yazılımları geliştirmiş olan kişiler artık o grupta veya o firma yada kurulumda olmayabilir. Gelişimi sırasında belirli yönteme uyulmamış, yapılması gereken belgelendirme çok az veya hiç yapılmamış olabilir. Bu gibi durumlarda bakım için uygulanacak yöntemler:

97 Aynı kod üzerinde değişiklik yapılabilir. Kod başka ortamlara taşınabilir. Tersine mühendislik yapılabilir Aynı Kod Üzerinde Bakım Her yazılım geliştirici grup eski kodlarla uğraşmak zorunda kalabilmektedir. Böyle bir bakım işinde başarıya ulaşmak için aşağıdaki öneriler dikkate alınmalıdır:. Herhangi bir değişikliğe başlamadan önce belirsizlikten dolayı paniğe kapılmamalıyız, yazılım hakkında bilgi toplamaya çalışmalıyız.. Başta kodun ayrıntılarıyla değil de programın akışı hakkında bilgi sahibi olmaya çalışmalıyız.. Belge yok ise durumu özetleyen akış diyagramları çizmeliyiz ve mantık akışını kısaca özetlemeliyiz..temel veri yapılarını, evrensel değişkenleri belirleyip tanımlandıkları yerleri diyagramda işaretlemeliyiz.. Derleyici tarafından üretilen simge tablosu, referans listesi gibi çeşitli yardımcıları kullanmaya çalışmalıyız.. Kodu değiştirirken çok çok dikkatli olmalıyız. Gerekirse parça parça yapılan değişiklikleri anında test etmeliyiz.. Kodun içinde izlenmiş olan biçimleri korumaya çalışmalıyız.. Eğer gerçekten emin değilsek hiçbir kod parçasını silmeyin. Çıkarmak istediğimiz yeri açıklama satırları ile iptal edebiliriz.. Kod arasında kendi yorumlarımızı içeren yeni açıklama satırları ilave edebiliriz.. Başka bir işleme neden olmamak için var olan değişkenleri kullanmamalıyız, kendi değişkenlerimizle işlem yapmalıyız.

98 . Orijinal kodu ve değişiklik yapılan her sürümü dikkatle saklamalıyız.. Yaptıklarımızı ayrıntılı bir şekilde kayıt altına almalıyız. Kod içinde kendi yaptığımız değişiklikleri uygun ve kolay bulunur bir şekilde markalamalıyız ki bizden sonrada gelen aynı kod ile uğraşanlar olacağını unutmamalıyız.. Kodu bir kenara atıp yeni baştan yazmaya kalkışmamalıyız. Bazı durumlarda iyi gözükse de çok iyi çözümleme yapılmadan işe başlanırsa daha zor durumlara düzebiliriz. 5.2.Kod Taşıma Kod taşıma (porting), daha önce belirli bir bilgisayar mimarisi veya işletim sistemi için geliştirilmiş kodu yeni ortamlara çalışır hale getirme işlemidir. Üç tür kod taşıma sistemi uygulanır. Kaynak Kodu Aynen Taşımak Yazılım kaynak kodu değiştirilmeden yeni bilgisayar sistemi üzerinde, yeni derleyici ile çalışır hale getirilebilir. Bunu yapabilmek için aynı programlama dilini destekleyen uygun bir derleyici bulmak gerekir. Yeni ve eski bilgisayar mimarisinin özellikleri taşıma konusunda önemli rol oynarlar. Kaynak Kodu Kapsayıcı İçine Almak Eski kaynak kodu daha modern bir programlama diliyle kullanmak mümkün olabilir. Çünkü programlama dilleri arasında birbirini destekleyen geçişler vardır. Yazılımın asıl çalışma mantığını sağlayan kısımları eski dilde bırakıp onun etrafına yeni dille bir kapsayıcı (encapsulator) yapmak bir yöntem olarak kullanılabilir. Kapsayıcı kısım kullanıcı veya aygıt arayüzünü sağlar. Yeni Bir Dille Yeniden Yazmak

99 Yapılması en güç ve kapsamlı bakım işlerinden biridir. Çünkü eski kaynak koda bakılarak yeni bir yazılım yaratmak kolay değildir. Yazılımda yapılması gereken bakımın eski kodda yapılmayacağı değerlendirilirse, mevcut koddan yararlanılarak yeni bir tasarım yapılır. 5.3 Tersine Engineering) Mühendislik(Reverse Tersine mühendislik temel olarak elektronik yada mekanik mühendisliğinde uygulanmaya başlamıştır. Bir elektronik sistem donanımının veya mekanik parçaların nasıl çalıştığını, bu ürünün nasıl üretildiğini anlamak üzere inceleme ve testler yaparlar. Üretimin sırlarını ortaya çıkarmaya çalışırlar. Bu şekilde bir ürünün kopyasını elde etmeye veya benzerini geliştirmeye gayret ederler. Yazılımda uygulanan tersine mühendislik de aynı sayılır. Üzerinde çalışılan ürün başka bir geliştiriciye ait olabileceği gibi aynı geliştiriciye ait daha önce üretilmiş yazılımlarda olabilir. Herhangi bir belge bulunmadığı için kaynak kod bir gizem içerisindedir. Gelişimi üzerinden yıllar geçince ve geliştiricilerden kimse bulunmayınca bakım işi tam karmaşık hale dönüşür. Bu durumlarda uygulanan tersine mühendislik yazılımı kaynak koddan daha üst seviyede ki soyutlama ile tanımlamaya çalışma sürecidir. Bu süreç aslında tasarımın geri kazanılmasıdır Yeniden Yapılanma(Re-Engineering) Tersine mühendisliğe benzer olarak, yeniden yapılanma (reengineering) süreci, var olan yazılımı daha iyi bir niteliğe ulaştırma, yeni işlevler eklemek üzere yeniden tasarlamak ve gerçekleştirmektir. Bunu ana nedeni geliştiricinin o alanda daha fazla deneyim kazanması nedeniyle mevcut yazılımları daha iyi hale getirme arzusudur. Ancak pek çok yönden bu uygulama fazla pratik değildir. Çünkü bazı yazılımlar az değişiklik

100 isterler ve bu tür yeniden yapılandırma için gerekli gayrete değmezler. Fazla iş gücü ve maliyet gereksinimleri vardır ve bundan dolayı yeniden yapılandırmayı sağlayacak yardımcı araç ve gereçler tam olarak gelişmiş değil. Eğer elde çok karmaşık bir şekilde yazılmış programlar varsa değişen kullanıcı isterlerine uyarlayabilmek için izlenilmesi gereken ana yöntemler şunlardır:. Herbir değişiklik isteğini ayrı ayrı dikkate alıp tasarım ve kaynak kod içinde gereken değişiklikleri yapmak.. Daha etkin değişiklik yapabilmek için yazılım derinliklerini anlamaya çalışmak, ve buna göre daha köklü değişiklik yapmak..yazılım mühendisliği yaklaşımıyla kodlamak ve testlerden geçirmek. yeniden tasarlamak,. Mevcut tasarımı anlamaya yardımcı araçlar kullanılarak, tersine mühendislik ve yeniden yapılanma süreci içinde yazılımın tümünü yeniden tasarlamak, kodlamak ve testlerden geçirmek. 6. Riskler Yazılım bakım aşamasında dikkate alınması gereken risklerden bazıları şunlardır: Geliştirme ve test ortamının bulunması: Yazılımın kullanım süresi boyunca her sürüm için uygun bir geliştirme ve test ortamının çalışır durumda tutulması gereklidir. Bunu sağlamak için ayrı ayrı bir yatırım gerekebilir. Personel devamlılığı: Yazılımı geliştiren kişilerin daha sonra ayrılması durumunda deneyim sahibi personel kalmayabilir. Eğer yeterli belgelendirme yoksa bu değişiklik için çok zaman harcanabilir. Personel deneyimi: Yeni personelin bakım aşamasındaki

101 değişiklikleri anlaması, uygulaması için önemli bir zaman geçebilir. Eski teknolojinin getirebileceği zorluklar: Bakım aşamasında üzerinde değişiklik yapılması, yazılımın kullanıldığı teknolojinin eski olması durumunda, yeni isterlerin uygulaması tahmin edildiğinden daha zordur. Müşteri hoşnutsuzluğu: Üzerinde değişiklik yapılan yazılımın bazı kısıtlarını etkilenmesi nedeniyle müşteri hoşnutsuzluğu ortaya çıkmıştır. Eski yazılıma değişiklik uygulamanın güçlüğü: yazılıma yeni yazılımın değişiklikleri uygulamaya baştan geliştirmekten daha pahalıya mal olur. Eski bir çalışmak, Eski yazılımı yeniden geliştirme arzusu: Eski yazılımda değişiklik yapmak yerine, yeni baştan geliştirmek için arzu duyulabilir. Dikkatle değerlendirilmediğinde gerekenden fazla maliyet doğurabilir. Referanslar TEL.pdf YAZILIM MÜHENDİSLİĞİ, DR.M Erhan Yayıncılığı, 2.Basım Ocak 2008 SARIDOĞAN, Papatya rme-asamasi/

102 Proje Risk Yönetimi 1.Proje Nedir? Belirli bir yerde, belirli bir süre içerisinde belirli bir bütçe ile, net olarak tanımlanan araçların, gerçekleştirilmesine yönelik faaliyetler bütünüdür. 2.Proje Yönetim Süreçleri Proje fikrinin doğması Proje yapılabilirliğinin araştırılması Projenin tanımlanması/tasarlanması ve onay alması Projenin planlanması Projenin yürütülmesi ve değerlendirilmesi Projenin sona erdirilmesi 3.Risk Nedir?

103 Zarar, kayıp, tehlike veya hasar olmasına yönelik belirsizlik içeren unsur, etken veya gidişattır. 4.Projede Risk Yönetimi Risk projenin zamanında ve eksiksiz olarak tamamlanmasına engel olabilecek etmendir.projede risk oluşturabilecek unsurların belirlenmesi çok önemlidir.bu şekilde erken önlem alınabilir.buradan yola çıkarak projede karşılaşılabilecek riskler belirlenmeli ve listelenmelidir.ardından bu oluşabilecek risklere karşı alınabilecek önlemler belirlenmelidir. Risk yönetimi, sistemin ilk kavramlarının tanımından itibaren uygulanarak sürdürülür. sistemin kullanımdan kalktığı ana kadar 5.Risklerin İzlenmesi Büyük projelere ait riskler mutlaka bir veritabanında tutulmalı ve izlenmelidir.proje çalışanları ve ya projeye yeni katılan birisi bu risklerden haberdar olur ve uygun bir yol izlerler.veritabanının yönetimi proje yöneticisi ve risk yöneticisinde olur.çözümü bulunamayan riskler için gerekirse yeni çözüm planı çıkartılır. 6.Yazılım Risk Yönetimi

104 Yazılım projelerinde oluşabilcek riskler maliyet, zamanlama, teknik başarı, yazılım niteliği ve personel morali üzerinde etkili olabilir.yazılım risklerine verilebilecek örnekler şöyle olabilir: İsterler Müşteri Yönetim Personel Teknoloji Bağımlılık Dış Kaynaklar 6.1.İsterler Ne üretileceğinin tam anlaşılmamış olması Yeni isterlerin ortaya çıkma durumu İsterlerin belirsizlikleri Ürün isterlerinin sabitlenmesi için anlaşma olmaması Teknoloji ve uygulama alanlarının değişmesi Değişen isterlerin takip edilememesi gibi risk unsurları oluşabilir. 6.2.Müşteri Müşteri ile iletişim eksikliği Müşterinin ne istediğini tam bilmemesi Uygulama alanının özelliği Birden fazla müşteri olması durumunda çelişkilerin oluşması gibi nedenler. 6.3.Yönetim Yönetimin proje durumunu iyi takip edememesi Yönetimin bilgi ve deneyim eksikliği Proje için oluşturulan takımlarda uyum sorunları İletişim eksikliği Kişilerin yetki ve sorumluluklarının belirlenmesindeki eksiklikler

105 6.4.Personel Personel eğitiminin yetersizliği Personel deneyimin az olması Oluşan yeni teknolojilerin kabul edilme ve uygulanma güçlüğü Yazılım mühendisliği kültürünün yerleşmemiş olması gibi nedenler 6.5.Teknoloji Geliştirme araçlarının tam oturmuş olmaması Başka sistemlerle olan arayüzlerin değişikliğe uğraması 6.6.Bağımlılık Müşteri tarafından sağlanan bilgilere ve yazılımlara bağlı kalmak Eğitimli ve deneyimli personelin paylaşılamaması Alt yüklenicilere olan bağımlılık Tekrar kullanım için gösterilen fazla çaba 6.7.Dış Kaynaklar Geliştirici ve müşteri arasında gerçekleşen olumsuz ilişkiler Zamanın dar olması halinde oluşan psikolojik baskı Müşterinin beklenmedik kabul ölçütleri ortaya konması Farklı dilde çalışanlar için çeviri sorunu gibi nedenler gösterilebilir. 7.Kaynakça [1].Sarıdoğan,E.(2008).Yazılım Yayıncılık Eğitim Mühendisliği.İstanbul:Papatya [2]. [3]. [4].

106 [5]. aclari/proje-yonetimi-1 Kod Çevrim İşlemi 1.Giriş İnsanlar günlük konuşma dili kullanırken makineler dil olarak 0 ve 1 i tercih etmektedir. İnsanların kullandığı dil ile makine dilinin farklı gözle görülür biçimdedir. İnsanların kullandığı dilin bir şekilde bilgisayarlara öğretilmesi gerekmektedir. Farklı bir bakış açısı ile günlük dilin bilgisayar diline dönüştürülmesi gerekmektedir. Dolayısıyla arada iletişimi sağlayacak bir çevirmene gerek vardır. Çevirmen görevini derleyici (compiler) üslenmekte, bağlayıcı (linker) ve yorumlayıcı (interpreter) derleyicileye yardım etmektedir. Derleyici üst seviye programa dillerini bilgisayarın anlaması için bilgisayar diline çevirme ve kodda varsa eğer hataları düzeltirken yorumlayıcı sadece kısım kısım kod çevirme işlemi yapmaktadır. Bağlayıcı da parça parça olan kodları derleyerek bir bütün haline getirmektedir. 2.Programlama Dilleri Programlama dili, yazılımcının bir algoritmayı ifade etmek amacıyla, bir bilgisayara ne yapmasını istediğini anlatmasının tektipleştirilmiş yoludur. Bir programcı komutları yazmak

107 için farklı programlama dilleri kullanabilir. Programlama dilleri, programcının bilgisayara hangi veri üzerinde işlem yapacağını, verinin nasıl depolanıp iletileceğini, hangi koşullarda hangi işlemlerin yapılacağını tam olarak anlatmasını sağlar. Programlama dilleri insanların algılamasına yakın olmasına göre 3 gruba ayrılır. Alt seviye programlama dilleri: Makine koduna oldukça yakın programlama dilleridir. Makina hakimiyeti oldukça gelişmiştir. Bu programlama dillerini bilen kişilerin mikro işlemciler hakkında bilgi sahibi olması gereklidir.(assembly programlama dili gibi) Orta seviye programlama dilleri: Oldukça esnek olan bu diller hem üst hem alt seviye programlama yapabilirler. Alt seviye dillere oranla biraz daha anlaşılırdır. (C programlama dili gibi.) Üst seviye programlama dilleri: Olay tabanlı programlama dilleri olarak da adlandırılırlar yalnız bu programlama dilleri sadece belirli fonksiyonlar etrafında çalışırlar ve programlama hakimiyetini azaltırlar. En hızlı ve en etkili programlama dilleri bu kategoridedir. (visual basic ve pic basic pro gibi) Diğer programlama dillerine kıyasla daha kolay öğrenildiği ve uygulandığı için yeni başlayanlara en uygun diller üst seviye programlama dilleridir. Yüksek seviyeli programlama dillerinde yazılan programın çalışabilmesi için makine diline çevrilmesi gerekir. Bunun için program hangi yüksek seviyeli dil ile yazıldıysa o dilin derleyicisi kullanılır. Böylece yüksek seviyeli programlama dili ile yazılmış olan kaynak program, makine dilindeki amaç programa dönüştürülür. Kaynak programın içeriğinin değiştirilmesi mümkündür, ancak derlenmiş olan amaç programın içeriğine müdahale etme imkanı yoktur.

108 2.1.Bazı Programlama Dilleri Assembly Programlama Dili C Programlama Dili C++ Programlama Dili C# Programlama Dili Visual Basic Programlama Dili Delphi Programlama Dili Java Programlama Dili JavaScript Programlama Dili PHP Programlama Dili Python Programlama Dili Pascal Programlama Dili Pic Basic Pro Programlama Dili 3.Makine Dili Makine dili mikroişlemci ya da mikrodenetleyici gibi komut işleme yeteneğine sahip entegrelerin işleyebilecekleri komutlardan ve buna uygun söz diziminden oluşan dile verilen addır. Makine dili, işlemcinin verilen komutlar doğrultusunda çalıştırılmasını sağlayan ve işlemci mimarisine göre değişen en alt seviyedeki programlama dilidir. Bu dil sadece 0 ve 1 (binary) ikililerinin anlamlı kombinasyonlarından meydana gelmektedir. Bu nedenle, makine dilinin anlaşılması çok güçtür. Ayrıca diğer programlama dillerin gerektirdiği derleyici ya da yorumlayıcı kullanımını gerektirmediğinden ve donanımı doğrudan kontrol etme gücü olduğundan kullanılır. Kullanılan işlemcinin komut setinden ibaret olan makine dili komutları donanıma bağımlıdır. Günümüzde kullanılan i386(32bit intel) ve i486 gibi işlemci standartlarının her birine ait birer komut seti bulunmaktadır ve bu komut seti yalnız o mimariye yöneliktir. Bunun temelinde yatan asıl sebep işlemcinin hafıza birimi üzerinden okuduğu bir veri parçasının(bir ya da birkaç bayt) işlemciye bir emir teşkil

109 edicek bir ifade olabilmesi için bu veri parçasının işlemci üzerinde donanımsal olarak bir işleme karşılık gelmesi gerekliliğinden kaynaklanır. 4.Kod Çevrim İşlemi Programlama dillerinin en önemli özelliklerinden biri de insan ile makine arasında ne tür bir geçiş sağlandığıdır. İnsanlar normal karakter ile gösterilen yazı ve sayıları anlayabilirler. Ancak bir bilgisayar yalnızca 0 ve 1 değerlerini anlayabilen ikili düzenden, yani bit lerden anlamaktadır. Bilgisayar komutları da 0 ve 1 lerden oluşmuş sayı dizileridir. Her bir komutun işlemcide yaptığı bir iş vardır. Ve bu 0-1 ler bizim istediğimiz sırada çalıştırıldığında bir işi gerçekleştirir. Bu komutların bütününe ise program, yazılım deriz. Yazılım bilgisayarda bir işi yapan komutlar bütünüdür. Bir yazılımı bilgisayardaki simgesine tıklayarak çalıştırdığımızda aslında yaptığımız şey yazılımın içindeki kodları hafızaya yüklemektir. Bu yüklenen kodlar ise sırası geldiğinde çalışarak programı yürütürler ve program ne için tasarlanmışsa o işi yaparlar. Bilgisayarda ikili sayı sisteminin kullanılma nedeni ise bilgisayarın temelde sadece iki durumu ölçebilmesindendir. Bu durumu Sinyal yok 0, sinyal var 1 şeklinde özetleyebiliriz. Aslında bilgisayarların tüm bildiği, ölçebildiği budur. Fakat saniyede milyarlarca işlemi artarda yapabilirler ve programla dilleri kullanılarak programlanabilirler. 4.1.Derleyici(Compiler) Derleyiciler herhangi bir programlama dilinde yazılmış olan kaynak kodunu başka bir dile çeviren program ya da program dizilerine verilen genel isimdir. Genel olarak kod dönüşümü

110 yüksek seviyeli dillerden makine diline yapılmaktadır. Hedef dil genellikle makine kodu olarak bilinen ikili formdadır. Kaynak kodun makine koduna dönüştürülmek istenmesinin temel nedeni çalıştırılabilir bir program elde edilmek istenmesidir. Derleyiciler sözcüksel analiz, sözdizimi analizi, anlamsal analiz, kod üretimi ve kod optimizasyonu işlemlerinden birkaçını ya da hepsini yapabilirler. Derleyiciler tarafından hatalı üretilen programların problemlerini bulmak ve geçici bir çözüm üretmek çok zor olabilir. Bu sebeplerden dolayı, derleyici geliştiren firmalar kendi yazılımların doğruluğunu sağlayabilmek için çok büyük yatırımlar yaparlar Tek Geçişli(One Pass) ve Geçişli(Multi Pass) Derleyiciler Çok Bu başlıkta geçiş ile kastedilen kavram, bir derleyicinin kaynak kodu baştan sona kadar okunmasıdır. Yani tek geçişli derleyicilerde kaynak kod baştan başlanıp sona kadar bir kere okunmakta buna mukabil çok geçişli derleyicilerde (örneğin iki geçişli bir derleyicide) birden çok kereler (örneğin iki kere) kaynak kod baştan sona kadar taranmaktadır. Tek geçişli derleyiciler tahmin edileceği üzere çok geçişlilere göre çok daha hızlı çalışmaktadırlar. Ancak bazı durumlarda dilin tasarımı tek geçişli derleyicilere izin vermemektedir. Örneğin kodun sonlarına doğru kodun başında yapılan bir tanımı etkileyecek bir işlem yapıldığını düşünün bu durumda tek geçişle bu olayın algılanması ve kodun doğru şekilde derlenmesinin yapılması mümkün olamaz. Tek geçişli derleyicilerin diğer bir eksik yanı ise kod iyileştirmesi sırasında kodun üzerinden sadece bir kere geçtiği için kodun önceki satırlarında bulunan ve daha sonradan anlaşılan iyileştirmelerin yapılamamasıdır

111 4.1.2.Derleyici(Compiler) Nasıl Çalışır? Compiler, tıpkı iki kişinin arasında görevli bir tercüman gibi iki programlama dili arasında tercüme görevini üstlenir. Üst seviye programlama diliyle yazılan bir kaynak kodu, daha alt seviyeli bir makine diline dönüştürür. Yine bir tercümanın yaptığı gibi Compiler da bu tercüme işlemini yaparken, kaynak kodun içerisinde yer alan hataları bulur ve iletişimin sorunsuz olması için saptadığı hataları yazılımın geliştiricisine bildirir. Bu açıdan bakıldığında Compiler kaynak kodların sorunsuz şekilde bir alt programlama diline dönüştürülmesi aşamasında etkin bir rol üstlenir Derleyicinin Genel Çalışma Şekli

112 Tüm programı bir kerede denetler Sözlüksel ve sözdizimsel hataları bulur Hata yok ise, programı nesne koda çevirir. Nesne kod daha sonra çalışabilir koda çevrilir. 4.2.Bağlayıcı(Linker) Bir derleyici tarafından üretilmiş olan kodları bağlayarak işletim sisteminin çalıştırabileceği tek bir kod üreten

113 programdır. Günümüzde hızla gelişen programlama ihtiyaçları sonucunda programlamada modüler yaklaşıma geçilmiştir. Buna göre büyük bir yazılım küçük alt parçalara bölünmekte ve her parça ayrı ayrı işlenerek büyük program elde edilmektedir. Yapısal programlamanın da çıkış sebeplerinden birisi olan bu yaklaşıma göre dillerde fonksiyon desteği gelmiş ve değişik parametrelere göre aynı kodun farklı sonuçlar üretmesi sağlanmıştır. Daha sonradan gelişen nesne yönelimli programlama bu konuda bir sonraki nesil olarak kabul edilebilir. Nesne yönelimli programlamada, programlar nesnelere bölünerek farklı bir yaklaşım izlenmiştir. Bu yaklaşımların derleyicilere yansıması da uzun sürmemiş, daha yapısal programlamanın ilk geliştiği günlerde derleyiciler de farklı kütüphaneler ve bu kütüphaneleri birleştirmeye yarayan başlamışlarıdır. harici programlar kullanmaya Kodun birden fazla parçaya bölünmesi ve her parçanın ayrı ayrı üretilmesi durumunda bu parçaların birleştirilmesi ve tek bir program halinde üretilmesinden sorumlu bağlayıcı (linker) adı verilmektedir. olan programlara

114 4.3.Yorumlayıcı(Interpreter) Bir programı ya da bir komutu çalıştırmaya yarayan programlar için kullanılır. Yorumlayıcılar da aynı derleyiciler gibi aynı görevi üstlenmektedir. Yorumlayıcı, kaynak kodu kısım kısım ele alarak doğrudan çalıştırır. Yorumlayıcılar standart bir çalıştırılabilir kod üretmezler. Yorumlama işlemi aşama aşama yapılmadığı için genellikle ilk hatanın bulunduğu yerde programın çalışması kesilir. Derleyicilerin tersine kodun işlenmeyen satırları üzerinden hiç geçilmez ve buralardaki hatalar ile ilgilenilmezler. Yorumlayıcılar genelde kaynak koddan, makine diline anlık olarak dönüşüm yaptıkları için, derleyicilere göre daha yavaş çalışırlar. Ayrıca kodu iyileştirme (optimizasyon) imkanı da çoğu zaman yoktur. Yorumlayıcıların Basitçe Görevleri ve Tipleri Kaynak kodu çalıştırmak Bir kaynak kodu çalıştırılabilir farklı bir kod haline tercüme etmek Daha önceden hazırlanmış olan (çoğu zaman önceden derlenmiş bir koddur) kodları yeri geldiğinde çalıştırmak Yorumlayıcının Genel Çalışma Şekli

115 Tüm programı kısım kısım denetler. Bir döngü içindeki tüm kısımlar her seferinde çevrilir. Yavaştır. 4.4.Derleyiciler (Compiler) İle Yorumlayıcılar (Interpreter) Arasındaki Farklar Basitçe, bir kaynak kodu hedef koda çevirdikten sonra çalıştıran ve dolayısıyla koddaki hataları yakalama işlemini ve kodun iyileştirilmesini daha kod çalıştırmadan yapan çeviricilere derleyici, kodu satır satır veya bloklar halinde çalıştırıp sırası gelmeyen satırları hiç çalıştırmayan bu satırlardaki hataları hiçbir zaman göremeyen ve kodun bütününe ait iyileştirmeleri yapamayan çeviricilere de yorumlayıcı (interpreter) adı verilmektedir. Genel kanının tersine bir dilin derleyici veya yorumlayıcı özelliği yoktur. Yani C dili için sadece derleyicisi bulunan

116 bir dildir demek yanlış olur. Bu durum bütün diller için geçerlidir. Her dil için bir derleyici veya yorumlayıcı tasarlanabilir. Ama daha genel bir bakışla, her dilin aslında yorumlayıcı (interpreter) yapısında bir çalışması olduğunu söylemek yanlış olmaz. Sonuçta bilgisayarın işlemcisinde anlık olarak tek bir işlem yapılabilmektedir ve çalışması istenen kod, işlemciye sırayla verilecek ve satır satır çalıştırılacaktır. Derleyiciler, yorumlayıcılara göre daha hızlıdır. Çünkü yorumlayıcılar ilk kod satırından son kod satırına kadar her satırını teker teker yorumlar ve kodun karşılığındaki işlemi gerçekleştirir. Derleyicilerse kodların tamamını bilgisayar diline çevirir. Eğer hata varsa, tüm hataları programcıya bildirir. Ancak yorumlayıcılar karşısına ilk çıkan hatayı bildirmektedir, ilk hata çözülene kadar diğer hataları bulamaz çünkü satır satır işlem yapmaktadır. Derleyiciler bilgisayarın anlayacağı bir dile çevirip işlemciye veriler gönderdikten sonra karşımıza sonuç/çıktı çıkarırken yorumlayıcılar kodun karşılığındaki işlemi karşımıza çıkarır. Derleyici kullanan program dillerine örnek olarak; Pascal, C++, Ada, Visual Basic, C gibi bir çok örnek verebiliriz. Yorumlayıcı kullanan program dillerine örnek olarak; HTML, XML, PHP, Script Dilleri gibi bir çok örnek verebiliriz. Hem Derleyicileri hemde Yorumlayıcıları kullanan program dillerinden biri de JAVA dır. 4.5.IDE Nedir? (Integrated Development Environment Tümleşik Geliştirme Ortamı) DE bilgisayar programcılarının hızlı ve rahat bir şekilde program geliştirebilmesini amaçlayan, geliştirme sürecini organize edebilen birçok araç ile birlikte geliştirme sürecinin verimli kullanılmasına katkıda bulunan araçların

117 tamamını içerisinde barındıran bir yazılım türüdür Bazı Örnek IDE Programları Anjuta Code::Blocks Dev-C++ Eclipse Geany JDeveloper KDevelop Microsoft Visual Studio NetBeans Zend Studio C++ Builder Visual Studio Express Bir Tümleşik Geliştirme Ortamında Olması Gereken En Temel Özellikler Programlama diline göre söz dizimi renklendirmesi yapabilen kod yazım editörü, Kod dosyalarının hiyerarşik olarak görülebilmesi amacıyla hazırlanmış gerçek zamanlı bir ağaç, Tümleşik bir derleyici, yorumlayıcı ve hata ayıklayıcı, Yazılımın derlenmesi, bağlanması, çalışmaya tümüyle hazır hale gelmesi, Daha birçok ek işi otomatik olarak yapabilmek amacıyla küçük inşa araçlarının bütünüdür Farklı IDE Türleri Geliştiricilerin çalıştığı birçok farklı yolla ve ürettikleri farklı kod türleri için çeşitli farklı IDE ler vardır. Belirli bir dil, bulut tabanlı IDE ler, mobil uygulamaların geliştirilmesi için veya HTML için özelleştirilmiş IDE ler ve

118 özellikle Apple ın geliştirilmesi veya Microsoft un geliştirilmesi için geliştirilmiş IDE lerle çalışmak üzere tasarlanan IDE ler var Çok Dilli IDE ler Eclipse, NetBeans, Komodo, Aptana ve Geany gibi çok dilli IDE, çoklu programlama dillerini destekler. Eclipse: C, C ++, Python, Perl, PHP, Java, Ruby ve daha fazlasını destekler. Bu ücretsiz ve açık kaynak editörü pek çok geliştirme çerçevesinin modeli. Eclipse, bir Java geliştirme ortamı olarak başladı ve eklentiler aracılığıyla genişletildi. Eclipse, Eclipse.org Konsorsiyumu tarafından yönetilir ve yönetilir. NetBeans: Java, JavaScript, PHP, Python, Ruby, C, C ++ ve daha fazlasını destekler. Bu seçenek ayrıca ücretsiz ve açık kaynaktır. IDE nin tüm işlevleri, her biri iyi tanımlanmış bir işlev sağlayan modüller tarafından sağlanmaktadır. Ek programlar yükleyerek diğer programlama dillerine destek eklenebilir. Komodo IDE: Perl, Python, Tcl, PHP, Ruby, Javascript ve daha fazlasını destekler. Bu kurumsal düzeydeki araç daha yüksek bir fiyat noktasına sahiptir. Aptana: Eklentiler yoluyla HTML, CSS, JavaScript, AJAX ve diğerlerini destekler. Bu, web uygulaması geliştirme için popüler bir seçimdir. Geany: C, Java, PHP, HTML, Python, Perl, Pascal ve çok daha fazlasını destekler. Bu, geniş bir eklenti setiyle çok özelleştirilebilir bir ortamdır Microsoft veya Apple a Özgü IDE ler Bu IDE ler, Microsoft veya Apple ortamlarında çalışanlara hitap eder: Visual Studio: Visual C ++, VB.NET, C #, F # ve diğerlerini destekler. Visual Studio, Microsoft un

119 IDE dir ve Microsoft platformu için uygulamalar oluşturmak üzere tasarlanmıştır. MonoDevelop: C / C ++, Visual Basic, C # ve diğer.net dillerini destekler. Xcode: Objective-C ve Swift dillerini ve Cocoa ve Cocoa Touch API larını destekler. Bu IDE yalnızca ios ve Mac uygulamaları oluşturmak içindir ve bir iphone / ipad simülatörü ve GUI oluşturucu içerir. Espresso: HTML, CSS, XML, JavaScript ve PHP yi destekler. Bu, Mac web geliştiricileri için bir araçtır. Coda: PHP, JavaScript, CSS, HTML, AppleScript ve Kakao API sını destekler. Coda kendisini Mac kullanıcıları için tek pencere geliştirme olarak fatura eder Bulut Tabanlı IDE ler Bulut tabanlı IDE ler ana akım haline gelmeye başlamıştır. Bu web tabanlı IDE lerin yetenekleri hızla artıyor ve çoğu büyük tedarikçinin büyük olasılıkla birinin rekabet edebilmesi için teklif vermesi gerekecek. Bulut IDE leri, geliştiricilerin kodlarına her yerden erişmesini sağlar. Örneğin, Nitrous, Ruby, Python, Node.js ve daha fazlasını destekleyen bulut tabanlı bir geliştirme ortamı platformudur.cloud9 IDE, PHP, Ruby, Python, Node.js ve Go ile JavaScript dahil 40 dan fazla dili destekliyor. Heroku, çeşitli programlama dillerini destekleyen bulut tabanlı bir geliştirme platformudur (PaaS) IDEONE

120 Ideone, kullanıcıların çevrimiçi olarak kod paylaşmasına ve çalıştırmasına olanak tanıyan çevrimiçi bir IDE (Integrated Development Environment) ve hata ayıklama aracıdır. Programcılar ve geliştiriciler için özel olarak tasarlanmış bir pasteben gibidir. Tüm kod parçacıkları Ideone da çalışır ve karma bağlantılarla rahatça erişilebilir. Ideone, bellek kullanımı, yürütme süresi, derleyici sürümü, program tarafından oluşturulan çıktı ve hata iletileri dahil olmak üzere kodu ve onun yürütülmesi ile ilgili ayrıntılar sağlar. Bu hizmet, kodu hızla çalıştırmanız gerektiğinde ve bir masaüstü IDE yüklü olmadığında çok yararlı olacaktır Codepen.io Ücretli ve ücretsiz iki versiyonu olan Codepen, frontend dünyasının en ünlü online editörü konumunda bulunuyor. SCSS, SASS, LESS, Stylus gibi pre-process lerin hepsine destek vermesi yönüyle CSS severlerin desteğini kazanmış durumdadır. CSS konusuna ilgisi olanlara önerilen bir platformdur. Diğerlerinin aksine daha sosyal bir dünya sunan Codepen sayesinde, yaptığınız sayfaları geliştiriciler daha rahat inceleyebiliyor. Aynı şekilde siz de geliştirdiğiniz kodları paylaşabiliyorsunuz Jsfiddle

121 Site Piotr Zalewa tarafından geliştirilmiştir. Amacı; JavaScript geliştirme ortamı sunmak. Sitede temel olarak 4 bölüm yer alıyor. HTML, CSS ve JavaScript kod bloklarını oluşturabileceğiniz üç kısım ve çalıştırılan kodun çevrimiçi görülebileceği Result bölümü. Projenize yerleştirmek için elinizde bulunan bir kod parçasını öncelikle burada test ederek çok rahat bir şekilde kontrolünü yapabilme imkanı sunuyor Cloud9 Arayüz geliştiricileri için javascript ve html, bankend developerlar için nodejs ve yazılım geliştiriciler için birden çok dil desteği bulunan kullanışlı bir bulut tabanlı bütünleşik geliştirme ortamı. Sağladığı bazı özelliklere göre ücretli ve ücretsiz iki versiyonu bulunmaktadır Codebox

122 Codebox, hem masaüstü hem de bulut tabanlı çalışan bir platform. Gelişmiş kod editörü onlarca dili destekliyor. Git gibi dünyanın en popüler sürüm kontrol sistemi ile entegre çalışabilmesi ve bir çok test araçları ile bir kere de olsa denenmeyi hak ediyor Codiad Codiad, küçük bir alan ve minimum gereklilikleri olan web tabanlı bir IDE çerçevesidir. Codiad, büyük masaüstü editörlerinin büyük masrafları olmaksızın hızlı, etkileşimli bir gelişime olanak tanıyan basitlik düşünülerek