Bölüm 1 Yazılım Mühendisliği ve Araçları (CASE)

Bölüm 1 Yazılım Mühendisliği ve Araçları (CASE) 1.1 Giriş Bilgisayarlar yazılımları olmadan çalışmaları mümkün olmayan makine ve makine parçaları olarak tanımlayabiliriz. Bir sabit disk düşünelim tek başına durduğunda veya elektrik besleme girişine uygun elektrik ve sinyaller verildiğinde sadece sabit diskin plakaları dönecek ve başka herhangi bir işlem yapamayacaktır. Uygun elektriksel parçalar ile bir araya getirildiğinde bilgi giriş ve çıkışı yapabilecek çevresel birimler eklendiğinde bilgisayar haline gelecektir. Yazılımı olmadan yine bilgisayar oluşacak fakat bilgi giriş ve çıkışı olmadığı için herhangi bir kullanıcı tarafından kullanılamayacaktır. Bilgisayarlar yazılımları olmadan kullanılmaları veya bilgi akışı mümkün değildir. Yazılımlar bir bilgisayara uygun arabirimler kullanarak bilgi girişi ve çıkışı yapmamıza olanak tanır. İşletim sistemleri çevresel birimlerin birbirleri ile haberleşmesini yöneten yazılımlardır. Bu sayede bilgisayarlar çevresel birimleri ile haberleşir hangi birimde neler oluyor işletim sistemi sayesinde ortaya çıkar. Yazılım nasıl yazılır sorusu her bilgisayar kullanıcısının aklına takılan bir sorudur. Yazılımlar işletim sisteminin bir sabit disk veya bilgisayar çevresel birimleri tarafından okunabilen bir ortamdan alınan ikilik bilgilerin yorumlanması ile çalışır. Yorumlanan bilgiler uygun yazılım kesmeleri ile ortamları arasında taşınır. Yazılım kesmeleri (Software Interrupt) onaltılık tabanda belirlenen komut setlerinden oluşur. Komut setleri her bir işlem için ayrı olarak 1

tanımlanmıştır. Sabit diskten bir veri okumak veya işlemciye gönderilecek olan verinin nasıl işleneceği gibi birçok komut işletim sisteminin özelliğine göre değişiklik gösterir. Yazılım geliştirme süreci çok maliyetli ve bazı durumlarda uzun zaman gerektirir. Yazılımları ilk kuşak bilgisayarlarda ölçeklemek gerekir ise küçük, orta ve büyük ölçekli olarak sınıflandırabiliriz. Bu sınıflandırma artık geçerliliğini korumamaktadır. Yazılım geliştirme her geçen gün daha detaylı ve karmaşıklaşmaktadır. Bu karmaşıklığı aşabilmek için çeşitli araçlar geliştirilmiştir. Yazılım geliştirme ekipleri bir araya geldiğinde bu araçların önemi daha çok ortaya çıkmaktadır. 1.2. Yazılım Geliştirme Araçları Yazılım geliştirme sürecinde kullanılan araçlar olduğu gibi yöntemler vardır. Bu yöntemler kullanılan araçlara veya yaklaşımlara göre de değişmektedir. Son yılara genel kabul gören yaklaşımların başında analiz ve tasarım aşamasında etkili olan sistematik yaklaşım gelmektedir. Sistematik yaklaşımda problemin analizi, yapısal tasarımı, deneysel sistemin gerçekleştirmesi, test yatağı (test bed) ve bütünleştirmeden (Integration) oluşan beş aşama vardır. Bu aşamalarda geliştirilecek olan yazılımın sistematik olarak adımlandığı ve hata bulma toleransının yüksek olduğunu görebiliriz. Sistematik yaklaşıma daha önceleri yazılım yaşam süreci (Software Life Cycle) olarak tanımlanan süreçlerden oluştuğu bilinmekteydi. i) Analiz aşaması, geliştirilecek olan yazılım ve problemin tanımının yapıldığı aşamadır. Yazılımın ölçeğine göre değişiklik gösterebilen yapısı vardır. ii) yapısal tasarım aşamasında yazlımın genelde kaç katmandan oluşacağı, denetim mekanizmaları gibi öbeklerim belirlendiği aşamadır. iii) deneysel gerçekleştirim aşamasında yapılandırma aşamasında gözden kaçan veya hata ayıklama ve toleranslarının düzeltme yüzdelerinin gözden geçirilir. iv) test yatağı aşamasına gelindiğinde yazılım artık kullanıcılar ile karşılaşacak aşamaya gelmiştir. Yazılıma bağlı platformları gözden geçirilir daha sonra kullanıcıların geri beslemeleri alınarak son ince ayarlamalar yapılır. v) bütünleştirme son aşamadır. Kullanıcıların verdiği geri beslemeye göre yazılıma görsellik kazandırılır. Diğer çalışacağı yazılım veya platformlara uygunluğu saptanır. Hatalar bu aşamada tamamen giderilmiş olur ve yazılım paketlenir. 2

1.2.1 Yazılımlarda Projelendirme Aşaması Yazılım yapan mühendisler genellikle tasarım ve projelendirme aşamasından yapısal hatalar yapmaktadırlar. Değişik aşamalarda yapılan hataların kontrol ve değerlendirme aşaması olarak kabul ettiğimiz test ve bütünleştirme aşamalarında giderildiği kabul edilse de daha sonraları bu hatalara bağlı değişik kodlama ve mantıksal hatalar ortaya çıkmaktadır. Donanımsal hataların giderilebildiği mühendislik faaliyetleri içerisinde düzelte veya yeniden işleme gibi süreçler yazılım mühendisliğinde hata ayıklama (debugging) ve yeniden kodlama (recoding) olarak tarif edilmektedir. Yazılım yapan mühendislerin hata yapması veya hata ile karşılaşılan durumlarda bu hatalar nasıl tarif edilmelidir. Hataları toleransları ve hata kriterleri neler olmalıdır gibi sorula sorulduğunda cevaplanabilir kriterlerin olması gerekmektedir. Yazılımda ölçme ve değerlendirme yapabilecek yönetici veya proje sorumlularının dikkat etmesi gereken bir çok nokta vardır. Çünkü yazılım mühendislerinin yaptıkları hataların bulunması çok zordur. Bu hatalar kod hataları ile sınırlı değildir. Yazılım mühendisi veya yazılımcı yaptığı mantık hatasının da değerlendirilmesi gerekecektir. Bir işlev için yazılan fonksiyon kodları on satır ile bitirilebildiği gibi bazı durumlarda yüz satırda da bitirilebilir. Hangi durumda kod hatalıdır belirlenecek olan kriterler ile bu problemler aşılabilmektedir. Diğer bir durumda yazılan kodlar adam/saat yerine satır/kod maliyetli ise yazılımcı satırları arttırarak maliyetleri arttırabilir. Bu gibi bir çok problemden söz edilebilir. 1.2.2 Bilgisayar Yazılımlarında Ölçme ve Değerlendirme Kriterleri Bir çok projede karşılaşılan problemin kaynağının kesin olarak bulunması mümkün değildir. Bulunan hataların değerlendirme yöntemleri ve kriterlerini ölçmek için kullanılan çeşitli yöntemler vardır. Bu yöntemler ölçülebilir büyüklükler dolaylı ve direk olarak sınıflanır. Direk olarak ölçülebilen büyüklükler yazılım maliyeti, ortaya çıkan hata sayısı, yazılımcı gayreti, yazılan satır/kod sayısı, yazılımcı adam/saat. Diğer ölçülebilen dolaylı büyüklükler ise yazılımın işlevselliği, güvenilirliği, bakım ve onarım kolaylığı, yazılımın kalitesi olarak sınıflandırılabilir. Bu tip sınıflandırma yazılım projelerinde genel bir kural olarak benimsenmeyebilir. Bunun temel nedeni yazılım projeleri aynı olsa bile çalıştırılan kodların sayılarına göre değişiklik gösterebilecektir. 3

1.2.3 Yazılım Ölçmede Kullanılan Hesap Yöntemleri Yazılım projeleri değerlendirilirken dikkat edilecek kriterlerden bahsettik. Bu kriterlerin ölçümü yanı sıra hesaplanma değerleri nasıl ve hangi yöntemler ile hesaplanacaktır. Hesap yöntemleri yazılımın sadece kaç satır kod ile üretildiğini göstermemektedir. Karmaşık veya mantıksal durum ifade edebilen örneğin yapay zeka yazılımları değerlendirilirken nasıl bir yöntem izlenmelidir soru akla gelmektedir. Bu yazılımın maliyeti çok değişken ve uzun zaman alan bir süreç olabilir. Daha önceden kullanılan ve üretilen yazılım kodları da bazı durumlarda maliyeti arttırıp azaltabilmektedir. Kullanılan yazılım kodu daha önceki bir projeden oluşturulabilir veya yazılım ekibi dışında bir başkasından temin edilmesi durumu olabilir. Böyle durumlarda maliyet azalabilir veya artabilir. Yazılımın oluşturulması sırasında temel değerlendirme kriteri olarak genelde satır/kaynak kod göz önüne alınır. Ek olarak satır/kaynak kod bazı durumlarda açıklayıcı olmayabilir. Satır kaynak kod yerine açıklayıcı olabilmesi için işlevsel gösterge ölçüm birimi kullanmak daha yararlı ve sonucu almak açısından önemli olmaktadır. İşlev göstere bir puanlama şekli olarak kabul edilebilir. Bunun için kesinlik bildiren bir birimsel dönüşüm oluşturulması yararlı olur. Projelerin değişik zamanlama ve ölçüm kriterleri proje geliştiricilere bağlı olarak değişiklik gösterebilir. Burada kullanılan yöntemler daha çok genel olarak yazılım projelerinde kullanılan yöntemleri kapsamaktadır. Bir yazılım evinin geliştirdiği projelere göre örnek ele alalım. Bu örneğe göre projeye ait olarak maliyetler ve gerekli olan değerler aşağıdaki tablodaki gibi olsun. Tablo 1.1 Yazılım Projelerinde Kullanılan Sayısal Büyüklükler. Proje Satır/kod Maliyet TRL Sayfa Sayısı Hata Bozunma Yazılımcı Gayret X1000 Sayısı P1 24000 480000 300 24 12 24 18 P2 36000 640000 600 18 8 40 24 P3 48000 72000 800 20 14 50 28 Yazılım evleri diğer adları ile yazılım firmaları daha önceleri karşılaştıkları problemleri ve durumları kayıt altında tutarak bir veri tabanı oluştururlar. Bu veri tabanları yazılım projelerinde geçmiş veriler ile geliştirilen yazılımda çıkabileceklere bir öngörü/tahmin oluşturur. Daha 4

önceden geliştirilen yazılımlar yeni geliştirilen için bir emsal teşkil etmemesine rağmen bir fikir verme açısından başvurulacak bilgilerdir. Projeler bu şekilde tablo olarak göz önüne alındığında hem maliyet hem de projede karşılaşılacak diğer durumlar hakkında bilgi sahibi olunabilir. P1 yazılım projesi için bazı maliyet ve oranlar aşağıdaki gibi hesaplanmaktadır. Yazılımcı Maliyeti : (480000000/24) = 20000000 TRL / ay (kişi başına) Bilgisayar Programının Satırı Maliyeti : (480000000/24000) = 20000 TRL Hata Oranı : (24/24000) = 0.001 Hata / Satır = 1 Hata/ 1000 Satır Bozunma Oranı: (12/24000) = 0.0005 Bozunma Oranı = 0.5 Bozunma / 1000 Satır Yazılımcı maliyeti yukarıdaki hesaplamadan aylık olarak 20 milyon olarak bulunmuştur. Bunun anlamı yazılım projesinde bir yazılımcı bu proje geliştirilirken aylık maliyeti 20 milyon liradır. Hata oranına baktığımızda her bin satır kod karşılığında bir hata üretildiği veya hata oluştuğunu görmekteyiz. Buradan hareket ile hata kodları karşılığına satır sayısı LOC (Lines Of Codes) kısaltması ile bir ölçüm kriteri olarak kabul edebiliriz. Genel kabul görmüş olan LOC birimi bin satır için KLOC şeklini alacaktır. İşlevsel gösterge puanı diğer yöntemlere göre sayısal olarak verilerin gösterilmesini de sağlamaktadır. Sayısal olarak yazılımın değerlendirilmesini sağlayan bu yöntemde istenilen bileşenleri için değişik ağırlıklar verilerek yazılıma katkısı araştırılabilir. Bu tip değerlendirme sistemlerinde ağırlık ve sonuç göstergeleri yazılım yöneticisi tarafından değişik şekillerde bir araya getirilerek sayısal göstergeleri oluşturulabilir. Bu göstergelerde bulunan bileşenler yer değiştirilerek gösterge üzerinde anlamlı ifadeler çıkarılabilir. Bunu bir örnek vererek açıklamak gerekir ise kullanılan bilgisayar programlama dillerinden birisinin ikame etkisi diğer bir değiş ile diğerinin yerine kullanılması değerlendirilebilir. Fortran bilgisayar programlama dili ile yazılan bilgisayar program yerine C++ bilgisayar programlama dili kullanılarak bazı kodların fazladan yazılması engellenebilir. Nesne yönelimli dillerden birisi ile oluşturulan bilgisayar programı yerine yapısal programlama dillerinden birisi ile yapılan programlarda daha fazla kod yazmak maliyetleri ve hata oranını arttırabilmektedir. Bunun için işlevsel göstergelerin neler olduğunu veya nasıl hesaplanması gerektiğinin iyi belirlenmesi gerekmektedir. Belirleme işlemleri sırasında eş değer bilgisayar yazılım dilleri tablosu oluşturularak hangi programlama dilinin 5

temel fonksiyonlardan birinin kaç satır kod ile yazılabildiğinin ortaya konulması gerekir. Bunun için temel olarak belirlenen matematiksel veya mantıksal birkaç genel kabul görmüş algoritma bilgisayar programlama dili ile programlanır ve kaç satır kod ile oluştuğu belirlenir. Bu bize bir fonksiyon veya alt programın hangi programlama dilinde kaç satır koda (KLOC) karşılık geldiği belirlenmiş olur. Satır kod sayısı işlemine programlama dillerinin işlevselliğini de katacak olursak yapılması gereken işlevsel göstergenin satır sayısı (KLOC)/ işlevsel gösterge oranının bulunması gerekecektir. Bu oransal değer bize satır kod sayısının ne kadar işlevsel olduğu hakkında oransal bilgi verecektir. Oransal değer dönüşüm tablosu oluşturmak işlemleri daha kolaylaştıracak ve yazılım kodları konusunda daha açıklayıcı bilgi edinmemizi sağlayacaktır. Tablo 1.2 Örnek Kod Satır Sayısı (LOC) / İşlevsel Gösterge Dönüşümü Tablosu Bilgisayar Programlama Dili LOC / İşlevsel Gösterge (ψ) Ağılıklı Sonuç Değerlendirme Oranı (λ) C++ 400 15 Turbo Pascal 7.0 350 18 Fortran 77 310 23 gcc 700 11 g++ 770 10 fp 420 20 İşlevsel gösterge (ψ) ve değerlendirme tablosuna göre ağırlıklı sonuç değerlendirme indeksi oluşturulur. Bu indeks yazılımı geliştiren takıma ait başarım oranım olarak kabul edilir. Ağırlıklı sonuç değerlendirme oranı işlevsel göstergeler ile sonuca etkiyen faktördür. Sonucu etkileyen faktörleri aşağıdaki gibi sıralayabiliriz. Bu sıralamada her bir ağırlık sonuç indeksine etkiyen oransal değerlere ihtiyaç vardır. Hesaplama yöntemi ise bu tablodan verilecek olan ağırlık değerlerine paralel değerlerdir. Ağırlık değerleri 0 ile 10 arasında rakamsal değerlerdir. ψ = LOC * (λ/100+ ε i /100) (1.1) 6

Tablo 1.3. Ağırlık Değerleri indeksi (ε i ) i Değer Kriteri ε i Değeri 1 Hızlı kod geliştirme desteği gerekli mi? 0..10 2 Veri haberleşmesinin önemi nedir? 0..10 3 Gerçek zamanlı veriler kullanılacak mı? 0..10 4 Dağıtık işlem ve süreçler var mı? 0..10 5 Çoklu kullanıcı desteği var mı? 0..10 6 İşletim sistemi servis desteği var mı? 0..10 7 Kullanıcı arabirimleri tek/çoklu? 0..10 8 Veri depolama aygıtları dağıtık mı? 0..10 9 Program kodları yeniden kullanılır mı? 0..10 Tablodan alınan değerler formül 1.1 de yerine konarak İşlevsel gösterge (ψ) değeri hesaplanır. Sonuç olarak bulunana değerler bütün yazılım projelerinde kesinlik belirtemeyebilir. Kesinlik durumunu belirleme oldukça zordur. İşlevsel gösterge (ψ) değeri bize daha çok somut olarak ele alamadığımız kesinlik ifade etmeyen bileşenlerin hesaplanmasında yardımcı olur. Bununla birlikte diğer ölçüm kriterleri göz önüne alınarak değerlendirme yapmak çoğu zaman daha belirleyicidir. 1.2.4. Bilgisayar Yazılımında Hesap Tahmini ve Proje Yönetimi Yazılım projelerinde maliyet hesabı diğer projelerin hesabında kullanılan yöntemlere benzemektedir. Tahmini yazılım maliyet hesaplarındaki tahmini ve sonuç arasındaki fark çoğu zaman istenen yazılım ile ortaya çıkan yazılımın arasındaki farkından oluşur. Yazılım projelerine başlarken projeci ve müşteri istenen ile projede ulaşılan sonuçları istemeyebilirler. Müşteri bazı durumlarda veya iletişim farkından veya teknik bilgi yetersizliğinden projeci ile anlaşmazlığa düşebilirler. Müşteri tam olarak kavrayamadığı bilgisayar yazılım projesinden beklentileri projede öngörülenden farklı olabilir. Yazılım projelerinde ortaya çıkan anlaşmazlıkların genelde nedenlerini şu şekilde sıralayabiliriz; i) Müşterinin teknik bilgi yetersizliği ii) Projede detayların tam olarak belirlenmemesi iii) Yazılımcıların kodlama hatası 7

iv) Geliştirme ortamlarının iyi seçilmemesi v) Müşterinin eksik bilgilendirilmesi vi) Projede kullanılan teknik donanım ile çalışacak donanımları uyumsuzluğu v.b. Yazılım projelerindeki anlaşmazlıların maliyetlere direk etkisi vardır. Geliştirilen yazılımların maliyetleri süre uzadıkça veya çalışanlar değiştikçe artmaktadır. Kesin olarak maliyetlerin miktarlarının bilinmesi de kimi zaman olanaksızdır. Yazılım projelerinde mutlaka proje yönetimi yaklaşımları kullanılmadır. Bu bize projenin mevcut durumunu, ilerleme hızını, gelinecek aşamaları ve bir sonraki aşamada neler olabileceğini göstermesi açısından da yararlı olacaktır.proje başlangıcında tahmin edilmeyen giderler projenin yürütülmesini zorlaştırabilmektedir. Doğru tahmin edilen ve sonuca ulaşan projelerde de mutlaka detaylı olarak incelendiğinde bir muğlaklık veya bilinmezlik durumu vardır. Belirsizlik durumları projede çalışanların gayretlerinin de ölçülmesini güçleştirmektedir. İlk başlarda projenin geliştirilmesinde yazınla kodların değiştirilmesi veya yeni kodların eklenmesi çok fazla zaman almamaktadır. Yazılım için geliştirilen kodlar arttıkça eklenen kodların sayısı için geçen süre üstel olarak artmaktadır. Bunu üstel dağılım ile açıklayan formül; Süre (t) = (KLOC) δ (1.2) δ : Τekrarlı komut KLOC : Satır Sayırı x 1000 ile gösterilmiştir. Formülden de anlaşıldığı gibi yazılım projelerinde satır sayısı ve tekrar edilen komutların üstel olarak artması ile sonuçlanır ve proje geliştiricileri her yeni komut veya satır eklediğinde bu durum daha da güçleşir. 1.2.5 Satır Sayısı Yöntemi ile Kestirim Bu yöntemde, proje tahmin edilen alt birimlerine ayrıştırılır. Parçala - yönet stratejisi sonucunda ortaya çıkan, üzerinde tahmin yapılması daha kolay olan daha küçük her birim için satır sayıları önerilir. Bu kestirimler yapılırken de en küçük, en olası, ve en büyük ihtimaller belirlenip bunlarla bir ortalama işlemi yapılabilir. Bir birim için tahmin edilecek en küçük satır sayısına k, en olası satır sayısı tahminine o, ve en büyük tahmin değerine de b denecek olursa, o birim için: Satır sayısı kestirimi: (k + 4o + b) / 6 şeklinde hesaplanabilir. 8

Birimler için ayrı ayrı tahminler yapılır ve daha önceki deneyimlerden benzeri birimlerin geliştirilmesindeki şirketin verimliliği gibi değerler kullanılarak satır sayısı tahminlerinden çaba, zaman ve maliyet kestirimlerine varılır. Projenin bütünü için, birimlerin çaba, zaman ve maliyet kestirimleri toplanarak değerler elde edilir. Birimlerin satır sayıları toplanarak proje bütünü hakkında çaba ve zaman gibi kestirim hesaplarını bir kerede yapmaktan kaçınılmalıdır. Satır sayısı büyüklüğü ile diğer sonuç değerlerinin doğrusal olmayan bir ilişki ile bağlantılı oldukları hatırlanmalıdır. 1.2.6 İşlev Puanı Yöntemi ile Kestirim Daha önce değinilen işlev puanı ölçme tekniği, kestirim yapılmasında da kullanılabilir. Eğer proje ile ilgili girdi çıktı gibi özellikler tahmin edilebiliyorsa (işlev puanı formülleri için gerekli bilgiler) bunlar kullanılarak geliştirilecek sisteme ait bir değer elde edilir. Satır sayısı tekniğinin tersine bu yöntemde bir yazılım birimi için -doğrudan- büyüklük tahmini yapma zorluğu yoktur. Aksine, ihtiyaçlar belirlemesi çalışmalarında ortaya çıkabilecek değerler kullanılarak sonuca varılabilir. Elde edilen sonucun diğer yöntemlerle karşılaştırılabilmeleri için Tablo 2.2 deki değerler kullanılarak işlev puanından satır sayısı değerine ulaşmak mümkündür. 1.3 COCOMO Modeli Gereken çabanın, program büyüklüğünün bir üstel değerine bağlı olması prensibi ve endüstriden toplanan bilgiler ışığı altında bina edilmiş bir kestirim metodu vardır: COCOMO (Constructıve Costing Model). Yapılacak hesapların kapsamları açısından üç değişik modelden oluşur. Basit model, orta ve detaylı modeller. Ayrıca bu modellerde kulanılacak problemler, organik, yarık ayrık ve gömülü sınıfları altında toplanmıştır: Organik problemler için küçük boyuttaki programcı takımları, bildikleri ortamlarda iyi anlaşılmış uygulamaları geliştirirler. İletişim kamburu azdır ve elemanlar çabucak işlerini halledebilecek durumdadırlar. 9

Yarı ayrık problemlerde ise ekipte tecrübeli ve tecrübesiz elemanlar bulunabilir. İlgili sistemler konusunda deneyimleri sınırlı olabilir ve geliştirilen sistemin her veçhesini bilmeyebilirler. Gömülü problemler: Geliştirilecek yazılım, sistemin donanım, kurallar, işletim süreçleri veya yazılım gibi diğer bileşenleri ile çok kuvvetli bağlantılar oluşturur. Gereksinim değişiklikleri ile problemleri halletmek olanaksızlaşmıştır. İhtiyaç belirtiminin geçerlilik irdelemesi çok pahalıdır. Elemanların herşeyi bilme olasılığı iyice azalmıştır. COCOMO bu model ve problem sınıfı saptamalarından sonra ortaya çıkan formüllerle tahmin hesaplama yolunu önerir. Tablo 2.4, problem sınıflarına göre basit model için formülleri göstermektedir. Tablo 1.4 Basit COCOMO Modelleri Problem Çaba Süre Organik Çaba = 2.4 (KLOC) 1.05 Süre = 2.5 (Çaba) 0.38 Yarı ayrık Çaba = 3 (KLOC) 1.12 Süre = 2.5 (Çaba) 0.35 Gömülü Çaba = 3.6 (KLOC) 1.20 Süre = 2.5 (Çaba) 0.32 Orta detaydaki model ise sistemin (güvenilirlik, veri tabanı büyüklüğü, işletme ve kayıt sınırlandırmaları, personel özellikleri ve kullanılan yazılım araçları gibi) diğer özelliklerinin hesaba katılması amaçlanmıştır. Belirli bir dizi özelliğin, proje açısından etkileri ayrı ayrı ağırlandırılarak katsayılar ortaya çıkarılır. Bu faktörler, ilgili özellik için düşük (<1), nominal (1) veya yüksek (>1) olarak saptanırlar. Katsayılar birbiri ile çarpıldığında Çaba Ayarlama Katsayısı (ÇAK) (Effort Adjustment Factor) bulunur. Bu katsayı 0.9 ile 1.4 arasında bir değer alır ve Tablo 1.5 de gösterilen Orta COCOMO modeli formülleri kullanılarak çaba hesaplaması sonuçlandırılır. Süre hesaplaması ise Basit COCOMO modelinde olduğu gibi yapılır. Tablo 1.5 Orta Detayda COCOMO Çaba Formülleri Problem Çaba 10

Organik Çaba = 3.2 (KLOC) 1.05 * ÇAK Yarı ayrık Çaba = 3.0 (KLOC) 1.12 * ÇAK Gömülü Çaba = 2.8 (KLOC) 1.20 * ÇAK Çaba Ayarlama Katsayısı için sözügeçen etkenleri dört grupta toplayarak Tablo 2.6 da görüldüğü gibi sıralayabiliriz. Tablo 1.6 Çaba Ayarlama Etkenleri Ürün Donanım İnsan Proje güvenilirlik Hız çözümleyici yeteneği yazılım aracı kullanımı veri büyüklüğü tabanı bellek yeterliliği uygulama deneyimi zamanlandırma ürün karmaşıklığı sanal makina geliştirme ortamı yeni programlama değişkenliği deneyimi teknikleri kullanılabilme süresi programcı yeteneği programlama dili deneyimi Detaylı COCOMO modeli ise projenin evrelerine bağlı olarak süreç içinde değişiklikleri hesaba katarak arada bir kestirim hesaplamasını önerir. Bu modelde zamana bağlılık temel değişikliktir. Projenin farklı evrelerinde çaba yoğunluğu ve yapılacak işin karmaşıklığı değişecektir. Benzer bir anlayış, yazılım eğrisi denilen bir sonucu yansıtan Putnam modelinde de kendisini gösterir. Evrelere bağlılığın bir sonucu olarak Raleigh adam-ay eğrileri ortaya çıkar. Şekil 2.2 de gösterilen bu eğriler, proje başlangıcındaki az iş gücü ile gereksinimlerin ilk çabalarını düşük düzeylerle temsil eder. Hızla tırmanan eğri, geliştirmenin analiz, tasarım ve uygulama gibi evrelerinde yükseklerdedir. Daha sonra geliştirme sonrası faaliyet azalır. İleride bakım ve onarım yine bazı geçici yükselmeler yapabilir. 11

1.3 Kestirimde İzlenecek Yol Birden fazla tahmin tekniği kullanılmalıdır. Bunun yanında, herhangi bir teknik için veri toplarken değişik personelden yararlanmalı ve bireylerin özellikleri de düşünülerek veriler değerlendirilmelidir. Tahminlerin doğruluğu, önceden edinilen bilgilerin düzenli tutulmasına da bağlıdır. Önce sistem tanımındaki veriler kullanılarak bir İşlev Puanı hesabı yapılabilir ve sonuçlar satır sayısına çevrilebilir. Daha önceki verimlilik ve pahalılık gibi bilgiler ışığında bu satır sayısından maliyet, çaba ve süre tahmini yapılır. İkinci bir yol olarak elde edilmiş satır sayısından hareket ederek COCOMO modeli aracılığı ile çaba ve süre hesaplanabilir. Daha sonra diğer bir yol olarak da satır sayısı yöntemine başvurulabilir. Bu durumda sistemi üst seviyedeki bileşenlerine ayırabilmek gerekir. Bu alt sistemler için satır sayısı tahminlerinde bulunulur ve ayrı ayrı çaba, süre gibi hesaplar yapılır. Alt sistemlere ait bilgiler toplanarak sistem için izlediğimiz üçüncü kestirimler elde edilmiş olur. Ayrıca alt sistemler için de önce İşlev Puanı yöntemi uygulanabilir. Sözü geçen değişik kestirimler birbiriyle karşılaştırılarak arada çok büyük farklar gözlendiği taktirde hangi yöntemde hatalı varsayımlarımız olduğu ortaya çıkarılmaya çalışılır. Büyük fark olduğunda hangi kestirimin hatalı olabileceği yönünde bir ipucu olmak üzere bir veya bir kaç diğer yöntem sonuçları da kullanılabilir. Belirli bir kanaate ulaşılınca da bu durum kabul edilir ve bir süre olduğu gibi bırakılır. İlk kestirmeler - ki en yönlendirici olanlardır! - bilgi azlığı nedeniyle en hatalı olanlardır. Geliştirme ilerledikçe tahmin hesapları arada bir yapılabilir. Projenin sonlarında ise daha önce yapılan kestirimlerin hatalarının en çok hangi parametrelerden kaynaklandığı bulunmaya çalışılır: artık elde kesin bilgiler vardır, bu sonuç bilgileri, kestirim formüllerine geri konarak bu formüllerdeki sabit katsayılar, ayarlama katsayıları gibi değerlerde oynama yapılarak kendi şirketimiz için uyarlanmış daha geçerli formülleri ortaya çıkarmış oluruz. Bu çalışmalar, ilerde geliştirilecek projeler için daha doğru kestirim yapmaya yöneliktir. Ayrıca, ölçme bilgilerinin de tutlmasında düzenlemeler ve düzeltmeler de benzeri tedbirlerdir. 1.4 Diğer kestirim ve ölçüm teknikleri Proje yönetiminde sıkça karşımıza çıkacak tekniklere değindikten sonra ilginç bazı diğer tekniklere de içerdikleri farklı özellikler açısından bakmamızda yarar vardır. Bu bölümde bir kestirim metodu olan Putnam metodunu, ve program karmaşıklık ölçüleri olan Halstead tekniği ve çevrimsellik ölçüsünü (cyclomatic complexity) özetleyeceğiz. 12

Putnam metodunda, sistem geliştirme sürecinin zamana bağlı olarak çaba ve malıiyetin eğrilerinin sunulduğunu görüyoruz. Gerçekçi bir projede hesaplanan adam-ay değeri, süreç boyunca sabit kalmaz. Dolayısıyla bazı ayların personel gereksinimi, diğerlerine göre farklı olacaktır. Bu çaba-zaman eğrisi gözlenerek personel istihdamı ayarlanabilir. Aynı kuruluş içerisinde farklı projeler arasında eleman kaydırmaları da Putnam eğrilerinin bir sonucu olarak mümkün olur: Çaba = (LOC) x Y 0.333 /V) 3 x (1/t 4 ) Burada Y, özel yetenekler katsayısıdır, küçük projeler için (KLOC = 5... 15) değeri 0.16 iken, 70 KLOC dan büyük projeler için 0.39 dur. V ise verimliliğe bağlı olarak değişir: gerçek zamanlı sistemler için 2000 olan değer, sistem programları ve iletişim programları için 10000 ve iş bilgi sistemleri için 28000 dir. Verimliliğe etki eden bazı faktörler: süreç olgunluğu ve yönetim uygulamaları yazılım mühendisliği uygulanmasının niceliği programlama dilinin soyutlama düzeyi yazılım geliştirme ortamı ekibin yetenekleri ve deneyimi uygulamanın karmaşıklığı Halstead tekniği, bir yazılım biriminin iç yapısını inceler. Yazılım içerisinde kullanılan değişik işlemlerin sayısını ve bu işlemlere parametre olarak kullanılan değerlerin sayısını kullanarak bir karmaşıklık hesaplaması yapar. Dolayısıyla satır sayısından bağımsız, doğrudan programın yaptığı işleve yönelik bir değerlendirme girişimi olarak ortaya çıkmıştır. Daha küçük ve karmaşık projeler için bir değerlendirme aracı olarak kullanılmıştır. Veriler ve program yapılarındaki işlem dışı etkenlerin hesaba katılmadığı bir gerçektir. Çevrimsellik Karmaşıklığı ise yine bir programın iç yapısı ile ilgilidir ve komutlardaki ardışıllıktan çok çevrim ve karar verme gibi noktaların karmaşıklığı etkilediği gerçeğine dayanır. Bu gibi noktaların toplam sayısı ile ilgili bir ölçümdür. Ayrıca program yapısı bir graf a dönüştürüldüğünde bu sayının oluşacak çevrimlerin sayısı ile olan ilgisini gözlemlemek oldukça kolaydır. Örneğin bu teknik, programlama ödevlerini teslim eden öğrencilerin diğerlerinin ödevlerinden ne derece faydalandığını ortaya çıkarmak için kullanılmıştır: Programda yapıların yerleri değiştirilebilir ve farklı isimlendirmeler kulanılarak iki programdaki benzerlikler, göz ile 13

anlaşılmaları çok zor bir duruma getirilebilir. Çevrim ve karar noktalarını sayan bir teknik ile programın esas yapısının bir veçhesi kolayca ortaya çıkarılmaktadır. Bu ölçümün ortaya çıkış nedeni, test amacı ile bir programın akışı diyagramını çizecek olursak, her patikanın ele alınması için ne kadar iş yapılması gerekir gibi bir sorudur. Bu diyagram incelendiğinde, patika sayıları, karar noktaları denilen düğümlerin sayıları toplamı artı '1' dir. Karar noktaları ise 'IF' komutları (koşutlar) ve çevrimlerin başlangıç noktalarıdır. 1.8. Risk ve Planlama Yazılım proje yönetiminin önemli alanlarından biri de risk yönetimidir. Projeyi tehdit edebilecek tehlikeler önceden düşünülmeli, onları ortaya çıkmadan önleme yolları aranmalı ve yine de önlenemeyen ve gerçekleşen tehlikeler sonucunda yapılacak düzeltme faaliyetleri de bilinmelidir. Önce olası riskler tanımlanır, bunların gerçekleşme ihtimalleri kestirilir ve sonucunda projeyi ne derece etkileyebilecekleri rakamsal bir değer tahmini ile ortaya konur. Bunlara ek olarak bir de yapılan tahminlerin doğruluk olasılığı da kayıt edilir. Bir tehlikenin projeyi etkilemesi, teslim tarihinin ötelenmesi veya maliyetin artması şeklinde değerlendirilir. En kötü durumda, projenin devam etmemesine karar verilebilecek kadar bir zarar söz konusudur. Yönetim, bu sınır değerleri önceden ortaya koymalı ve projenin gelişimi devamlı izlenirken risk konusu da denetlenmelidir. Şekil 2.3 de risklerin teslim zamanı ve maliyet artışı parametreleri açısından projenin devamına karar vermede kullanılabilecek bir eğri gösterilmektedir. Ancak, proje yönetiminde yapılan süre ve çaba kestirimlerinde olduğu gibi risk ile ilgili değerlerde nesnel olmaktan uzak olacaklardır, hesap ve verilerin değerlendirilmesi sonucunda ele geçen değerler aklıselimlik ile yargılanmalı ve deneyimler sonucu elde edilen bilgi ve düşüncelerle karar verilmelidir. Örneğin Şekil 2.3 de herhangi bir riskin yerleştirileceği bölgeye göre devam kararı alınır. Ya birden fazla risk tehlike çizgisine yakınsa? Bunların birbiri ile bağlantıları da gözönünde tutularak projenin bütünü akıl kontrolünde bulunduran yönetici kararını uyarlayacaktır. Yine de rakamsal kesinlik isteyen yöneticiler, olası risklerin birlikte oluşturacağı gecikme ve pahalılaşma noktasını belirleyebilirler. Şekil 1.3 Riskin oluşturduğu tehlikeli bölge Yaygın riskler gruplanmış bulunduğundan, bu liste üzerinden giderek eldeki proje için olası riskler tanımlanarak yola çıkılabilir. Yazılım proje risklerini aşağıdaki gibi gruplarda inceleyebiliriz: Yazılım büyüklüğü 14

Pazar ve yönetim gibi iş konuları Kullanıcı Süreç Geliştirme Personel 1.9 Risk Alanları Genelde riskler proje, teknik ve iş yönetimi sahalarında olur. Ayrıca müşterilerin de büyük bir risk sahası oluşturacağı düşünülürse genelde iş yönetimi alanı içinde değerlendirilebilirse de müşteri risklerini ayrıca inceleyebiliriz. Proje riskleri, teslim zamanındaki gecikme veya bütçe dışına taşma gibi sonuçlara neden olur. Bununla yakından ilgili olan teknik riskler de çaba evrelerinden herhangi birinde ortaya çıkacak yanlışlıkların sonucu oluşurlar. Ayrıca kullanılacak yeni teknolojiler de bu gruptadır. İş yönetimi açısından ise üretilecek yazılımın kullanılma nedeninin ortadan kalkması ile ilgilidir. Bu gibi nedenlere örnek olarak kullanıcının istememesi, yöneticilerin ilgi kaybı verilebilir. Kestirilebilen risklerden çok kestirilemeyen riskler zararlıdır ve bunlar konusunda alınabilecek fazla önlem de yoktur. Şekil 2.4 de bazı risk grupları ve etkiledikleri parametreler gösterilmektedir. 1.9.1 Müşteri İle İlişkili Riskler Müşterilerin yapısı aynı değildir, projeyi ilgilendiren farklılıklarından bazıları aşağıda sıralanmıştır: Değişik istekler Değişik kişilikler Değişik geliştirici ilişki düzey ve istekleri Çelişen istekler Yine sıralanan maddeler, müşteri ile ilgili risklerin irdelenmesini gerektirir: Müşterinin geliştirici için yeni olması Müşterinin ihtiyaçları somut bir şekilde bilmemesi Resmi ihtiyaçlar toplantılarına katılmak istememesi 15

Geliştirici ile haberleşme kanallarının kurulmasına karşı çıkması Değerlendirme toplantılarına katılmada isteksizlik Ürün sahasında teknik bilgiye sahip olmaması Yazılım sürecinden anlamaması 1.9.2 Süreç İle İlişkili Riskler Süreçlerin yapısı aynı değildir, projeyi ilgilendiren farklılıklarından bazıları aşağıda sıralanmıştır: Yönetimin yazılmış bir süreç politikası olmaması Proje için yazılmış bir süreç tanımı olmaması Personelin sürece göre atanmış olmaması Süreç modelinin önceden denenmemiş olması Yazılım mühendisliği eğitiminin herhangi bir personel seviyesinde eksikliği Standartlar yönetici ve geliştiriciler için temin edilmemiş olması Belgeleme kuralları sürece katılmamış olması Resmi değerlendirmeler (her evre için) ve testler düzenli olarak yapılmaması Değerlendirme sonuçlarının belgelenmemesi Kurum yönetimi (configuration management) kullanılmamas Kullanıcı ihtiyaç değişimleri istekleri denetlenmemesi Taşeronlar yönlendirilip kontrol edilmemesi 1.9.3 Teknoloji Riskleri Yeni teknolojilere geçmek, kuruluşların atması gereken bir adımdır. Personelin de özendiği bir değişimdir. İş açısından da ileride faydası görülecek bir yatırımdır. Ancak eldeki proje için risk oluşturur: Ürün teknolojisinin kuruluş için yeni olması Yeni yordamların (algoritma) ve girdi/çıktı (input/output) teknolojilerinin gerekmesi 16

Denenmemiş donanım ile arayüzün (interface) kullanılması Dışarıdan alınan ve denenmemiş yazılım birimleri ile arayüz kullanılması Yeni veritabanı ile arayüz kullanılması Özelliği olan bir kullanıcı arayüzü kullanılması Yeni çözümleme, tasarım, test metotlarının kullanılması Matematiksel metotlar, yapay us gibi alışılagelmiş geliştirme dışında tekniklerin kullanılması Aşırı performans zorlamaları 1.9.4 Geliştirme Ortamı Riskleri Yazılım proje yönetimi aracının olmayışı Yazılım süreç modelleme aracının olmayışı Çözümleme ve tasarım araçlarının olmayışı Bu araçların projeye uygun çıktılarının olmayışı Gerekli derleyicilerinin elde bulunmayışı Ürün için uygun test araçlarının bulunmayışı Yazılım kurum yönetimi araçlarının (software configuration management) olmayışı Geliştirme ortamının bir veritabanı kullanmaması Araçların bütünleşmemiş olması Araçlar için eğitim alınmamış olması Araçlar için sorulara cevap verecek yerel hizmet kuvvetinin bulunmayışı Araçlar için çevrim içi (on line) yardım ve belgeleme kolaylıklarının olmayışı 1.9.5 Personel Riskleri Kalifiye elemanların olmaması Gerekli kabiliyetlerin toplanmaması Yeterli sayıda personel olmaması 17

Personelin proje süresince adanmaması Yarı zamanlı personel bulunması Proje hakkında doğru beklentilerin oluşmaması Gerekli eğitimin eksik olması 1.9.6 Ürün Büyüklüğü İle İlgili Riskleri Genelde yazılımın büyüklüğü birliğinde riskleri getirir: Gerçekten uzak büyüklük kestirimleri Program, kütük ve sorgulama sayılarında tahmin edilen büyüklük Ortalama ürünlerden hayli büyük bir kestirim Kullanılacak veritabanı büyüklüğü Fazla kullanıcı sayısı Yeniden kullanılan yazılım (reused software) miktarı fazlalığı İhtiyaçlar değişimindeki fazlalık 1.9.7 İş Yönetimi İle İlişkili Riskler Bazen organizasyonun istekleri teknik zorluklar oluşturur. İşyeri açısından projenin yaşamsal tehlikeleri oluşabilir: Beklenen kar getirisinin az olması Üst yönetim için geçersiz olması Teslim tarihinin gerçekçi olmaması Müşteri ihtiyaçlarının ürün ile karşılanacağı şüphesinin bulunması Ürünün diğer ürünlerle birlikte çalışmasının gerekmesi Kullanıcıların yetenek eksikliği İstenen belge miktar ve kalitesindeki büyüklük Kanuni sınırlandırmalar 18

Geç veya hatalı ürün yüzünden oluşacak maliyet artışı 1.9.8 Risk Kestirim Yöntemi Risklerin tanımlanmasından sonra tehlikenin gerçekleşme olasılığı ve sonucunda projeye olan etkisi nümerik değerler ile kaydedilir. Ayrıca yapılan tahminin doğruluk derecesini de nicelendirerek bu tahminlerin yanlış kullanımını azaltma yönünde çaba sarfetmiş olur. Bu konuda kullanılacak basit bir teknik, risk tablosu oluşturmaktır. Şekil 2.5, bir risk tablosu örneği vermektedir. İlk sütunda riskin tanımı, ikinci sütunda ilgili alan, üçüncü sütunda gerçekleşme ihtimali, dördüncü sütunda projeye olan etkisi ve en son olarak da bu riski önleyici, gözlemleyici ve gerçekleşme durumunda düzeltici hareketler açıklanmaktadır. Riskin projeye olan etkisi yine nicel olarak sınıflandırılmıştır. Etki Değerleri: 1. Felaket 2. Kritik 3. Sınırda 4. İhmal edilebilir Riske karşı savaşım, RMMM (Risk mitigation, monitoring and management) deyimi ile özetlenebilir. Bunun anlamı risk tablosunun son sütununda yer alan risk önleme, gözetleme ve sonucu tamir edici yöntemlerden oluşan risk yönetimidir. Proje planının bir alt bölümü olarak da düşünülebilecek olan bir RMMM planı hazırlanabilir. Böyle bir planın ana maddeleri aşağıdaki gibi sıralanabilir: 1. Giriş a. Belgenin amaç ve kapsamı b. Esas risklerin tanıtımı c. Sorumluluklar (idari ve teknik personel için) 2. Proje Risk Tablosu 19

a. Projeyi sekteye uğratacak risklerin açıklanması b. Olasılık ve etkiyi değiştirebilecek etkenler 3. RMMM 1. Risk 1 (her risk için tekrarlanmalıdır) a. Önlemler 2. Genel strateji 3. Önleyici adımlar 1 b. Gözetleme 4. Gözetlenecek parametreler 5. Gözetleme yaklaşım c. Yönetim 6. Düzeltme planı 7. Özel durumlar 4. Özet 1.4.2.1 Risk Değerlendirmesi Risklerin tanmlanması ve olasılık ile etkileri birer üçlü olarak kaydedilir: [r i, o i, e i ] Burada 'i', her bir riske karşı düşen ayrı risk numarasıdır. Daha sonra her bir risk Şekil 11.1 de gösterilen referans eğrisine göre değerlendirilir. Bazen bir arada gerçekleşecek riskler için de bu değerlendirme yapılır. Ancak bu eğriyi bir değişmez sınır olarak ele almamalıdır. Bazı bölgeler tanımsız olabilir ya da bazı durumlarda örneğin maliyet artışının önemi daha öne çıkabilir. Dolayısıyla her riske göre bu referans eğrisini gözden geçirmek gerekebilir. Yapılacak işleri özetleyebiliriz: 1. Proje için risk referans düzeylerinin tanımlanması 2. Her risk için referans düzeyleri ile ilişkiler kurulması 3. Projeyi durduracak bölgeyi ve içindeki risk referans noktalarını saptamak 20

4. Bir arada risklerin referans düzeyine olan etkisini irdelemek. 1.10. Planlama Yazılım proje yönetiminde en önemli unsur projenin zamanında yetişmesidir. Mühendisliklerde eski bir kural geçerlidir: 80-20 kuralı: Bir projenin %80 lik kısmı (beklenen işlevselliğin veya tahmin edilen ürün büyüklüğünün % 80'i) proje süresinin %20 sinde tamamlanır. Geriye kalan %20'lik iş ise zamanın % 80'ini alır. Bu kural ilk derslerde ortaya konan çaba dağılımı ile ilgili bilgileri desteklemektedir (Şekil 1.3). Yazılım mühendisliğinde ise benzer kuraldan biraz ayrıntı katılarak söz edilebilir: 40-20-40 kuralı olarak değişen bu kural, toplam çabanın %40'ı kodlama öncesi, kalan %40'ı ise bu ilk tanımlama işlemine karşı düşen test çabalarına ayrılacağını belirtmektedir. %20 ise kodlama çabasının payıdır. Ayrıca erken evrelerde kalite için yapılacak yatırım, bu dağılımlarda hesaba katılmayan bakım çabasını azaltacaktır. Zamanlama ile ilgili diğer ilginç bir bilgi de proje zamanını uzatarak kazanılacak toplam çaba miktarıdır. Ayrıca bu kazanılmış vaktin oluşturacağı ikincil yararlar da kalite göstergelerini etkiler. Bu gerçeği daha önce sözü geçen Putnam formülü ile gösterebiliriz: Çaba = (LOC) x Y 0.333/V)3 x (1/t4) Burada Y, özel yetenekler katsayısıdır, projeler büyüklüğüne bağlı olarak 0.16 ile 0.39 arasında değişir. 'V' ise 2000'in altında değerlerden başlayan 30000e yaklaşabilen verimlilik faktörüdür. 't' ise proje süresidir. 33 KLOC büyüklüğünde gerçek zamanlı bir sistem için 12 adam-ay çaba tahmin edilmiştir. 8 kişi ile bu proje 1.3 yılda tamamlanabilir. Ancak süreyi 1.75 yıla çıkarma şansımız varsa, Putnam fomülünün ortaya koyacağı sonuca göre toplam çaba 12 adam-ay'dan 3.8 adam-ay'a düşecektir. Bu sonuç bize az da olsa süre arttırımının sağlayacağı büyük rahatlığı göstermektedir. 1.11 Görev Dağıtımı Yazılım geliştirme projesi boyunca yapılacak bütün işler, ayrıştırılmış görevler olarak düzenlenmelidir. Bu görevlerin başlama ve bitme zamanları, üstlenecek personel isimleri ve ihtiyaç duyulacak kaynaklar (araçlar, altyapı, yazılım vb.), son olarak da görevin çıktısı olacak ürün tanımlanır. Bir büyük görev, alt görevlere de ayrılabilir. Bu ayrıştırmayı yaparken proje 21

takvimi gözönünde tutulmalıdır. Bazı görevler diğerlerine bağlı olacaklardır ve bitiş zamanları proje teslimini etkileyecektir. BDYM araçları konusunda gösterilen proje yönetimi araç grafikleri bu sahada kullanılmaktadır. Şekil 2.6 ve 2.7 de gösterilen grafikler taskların sıralanması ve bağımlılıklarını sunmaktadırlar. Daha önce Gantt diyagramı olarak adlandırılan ve genelde zaman çizgisi diyagramları sınıfından olan görev sıralandırma amaçlı grafik yöntem, Şekil 2.6 da yinelenmektedir. Bu görev ayrıştırılmasının yapılabilmesi için önceden yapılmış olması gereken işlemler vardır: Çaba tahminleri Ürün işlevlerinin ayrıştırılması Süreç modelinin seçilmesi Görevler arasındaki bağımlılığın da incelenmesini ve aslında zamanlamanın bu bilgiler ışığında yapılmasını isteriz. Şekil 2.7 de gösterilen görevler arasındaki bağımlılık ise PERT ve CPM gibi araçlar tarafından irdelenebilmektedir. Bu araçlar yardımı ile projenin 1. Kritik yolu 2. Görevlerin en olası tamamlama süresi (statistiksel metodlar kullanılarak) ve 3. Görevlerin zamanlarının sınır değerleri bulunup görselleştirilir. Kritik yol üzerindeki görevlerin gecikmeleri proje teslim tarihini etkiler. Çabanın diğer yoldaki işlemlerin tamamlanmasından daha çabuk biteceği biliniyorsa, belgeleme görevindeki kabul edilir bir gecikme proje tesliminde bir gecikmeye sebep olmaz. Ancak kabul edilir şeklinde sözü geçen gecikme, bu görevin sınır değerlerinden olan en geç tamamlanma değerini de aşmamalıdır. Ayrıca bu görevlerin geliştirme sırasında da gözetlenmesi ve proje teslimini geciktirici durumların farkedilerek planda değişiklik yapılması da sıkça rastlanan bir durumdur. Proje süresince gözetleme devam etmeli ve tablolar tutularak kayıt edilmelidir. Şekil 2.8 bu tür gözlem sonuçlarının yansıtıldığı bir proje tablosunu göstermektedir. 1.12 Proje Planı 22

Planlama ile ilgili bilgiler, verilen kararlar ve olası önlemler bir belge şeklinde sunulmalıdır. Bu proje planı belgesi, projenin amacını yönetici ve teknik kadrolara olduğu gibi müşteriye de aktarabilmelidir. Riskler, maliyet ve zamanlama açıklanmalı ve projenin her safhasında bütün personeli kapsayıcı genel yaklaşım belirtilmelidir. Ayrıca kalitenin nasıl teminat altına alınacağı da belirtilmelidir. Ana hatları ile bir proje planı taslağı aşağıda verilmektedir: 1. Giriş A. Planın amacı B. Projenin amacı ve konumu 1. Konum ve sınırlandırmalar 2. Ana işlevler 3. Performans parametreleri 4. Yönetim ve teknik ile ilgili sınırlandırmalar 2. Proje Kestirimleri A. Kullanılan tarihi veriler B. Kestirim teknikleri C. Çaba, maliyet ve süre kestirimleri 3. Risk yönetimi stratejisi A. Risk tablosu B. Yönetilecek risklerin açıklanması C. Her risk için RMMM planı: 1. Önlemler 2. Gözetleme 3. Düzeltme yönetimi 4. Zamanlama A. Projenin ayrıştırılmış görev yapısı B. Görev bağımlılık diyagramı 23

C. Görev zamanlama diyagramı (Gantt Diyagramı) D. Kaynaklar tablosu 5. Kaynaklar A.Personel B. Donanım ve yazılım C. Özel kaynaklar 6. Personel organizasyonu A. Programcı takımları B. Yönetim raporları 7. Gözetleme A. Kalite teminatı ve denetimi B. Değişim yönetimi ve denetimi 8. Ekler 1.13 Programcı Takımları Kodlama ile ilgili görevler genellikler programcı takımlarına atanır. Bu takımlar 2 kişiden başlayarak büyük gruplara kadar uzanan sayıdan oluşabilirler ancak bu sayının fazla büyük tutulması pratik değildir. En çok 4 ila 7 kişilik gruplar söz konusu ise de bu sayının ideal olarak 4 veya 5 ile sınırlandırılması gerekir. Grup büyüdükçe bireyler arası iletişim yolları da artacak ve çabanın büyük bir kısmını iletişim işlemi tüketecektir. Ortalama oran değişmekle birlikte bir programcının toplam çaba kapasitesinin belirli bir oranının her iletişim bağlantısı için aynı olmak üzere ayrılacağı geçerli bir yaklaşımdır. Buradan yola çıkarak iletişim bağlantıları arttıkça toplam çabanın daha büyük bir kısmının iletişime ayrılacağı görülür. Her iletişim bağlantısı için bir programcının toplam çabasının %10'unu harcayacağını varsayarsak, 4 kişilik bir takımda iletişim kaybı %30 olacakken 7 kişilik bir takımda bu kayıp %60'a çıkacaktır. Bir programcı takımı ve iletişim bağlantıları modellenmektedir. Takımların yapılanması da önemlidir. Klasik yaklaşımlarda bir programcı aynı zamanda takımın kütüphanecisidir. Bazı durumlarda bu kütüphaneci programlama yapmaz. Görevi yazılan kodları ve belgeleri sınıflandırmak ve saklamaktır. Ayrıca programcılara gerekli algoritmalar, yeniden 24

kullanılacak kod parçaları bulmakta yardımcı olur. Takımın ürettiği son çıktı onun bir araya getirdiği bir bütünleştirme ürünüdür. Takımların bir lideri olur ve yine genellikle bu lider de programcıdır. Aynı zamanda kod geliştirilmesi ile uğraşır. Ancak grubun uyumlu çalışmasını sağlamakla görevlidir. Alışılagelmiş fazla denetleyici bir idareci görünümünden uzak olmalıdır. Bu konuda da değişik yaklaşımlar mevcut olsa da genelde programcılar üzerinde fazla sıkı bir yönetim yapısı benimsenmemektedir. Takımlarda kütüphaneci ve olası diğer kritik alan bilgisi gerektirecek rolleri üstlenen üyelerin yedeklenmesi gerekir. Bu yedekleme de genelde takım içerisinden sağlanır. Fazla ara vermeden toplantılar düzenlenerek takım elemanları ve hatta takımlar arasında bilgi paylaşımı arttırılmalıdır. Bu şekilde yedeklemelere hazırlık yapılmış olur. Yedeklemenin amacı ayrılacak bir üyenin proje devamını çok etkilememesidir. Son olarak da bir programcının genelde çabasının ne gibi işlemlere harcadığı hakkında yapılmış bir araçtırmadan söz edeceğiz. Bu araştırma, çabaları bir programcının temel görevi olan üretim ile doğrudan ilgilenmesi, diğer elemanlar ile iletişimde bulunması ve üretken olmayan işler yapması olarak üç sınıfta incelemektedir. Sonuçlar çabanın yarısı gibi bir oranının iletişim, kalan yarının da çoğunun üretken olmayan (toplantılar, eğitim vb.) etkinliklere ve en az oranının da program yazmak gibi temel göreve ayrıldığını göstermektedir. Bu sonucun verimsizlik olarak yorumlanmasına gerek yoktur. 25