6 isinpar

1,032
-1

Published on

2 Comments
0 Likes
Statistics
Notes
  • - URUS SRP, NIK BEACUKIA PENERBITAN BARU
    - URUS SRP, NIK BEACUKAI DITOLAK.
    - URUS SRP, NIK BEACUKAI DIBLOKIR
    - URUS SRP, NIK BEACUKAI PINDAH ALAMAT,

    URUS IZIN USAHA:
    - URUS PENDIRIAN PT – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS PENDIRIAN PMA – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS PENDIRIAN CV – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS APIU – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS APIP – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS NPIK – Seluruh Indonesia
    - URUS NIK BEACUKAI – Seluruh Indonesia
    - Urus IT Plastik
    - Urus IT CAKRAM OPTIK
    - Urus IT KOSMETIK
    - Urus IT ALAS KAKI
    - Urus IT MAKANAN DAN MINUMAN
    - Urus IT MAINAN ANAK-ANAK
    - Urus IT ELEKTRONIKA
    - Urus IT OBAT TRADISIONAL DAN HERBAL
    - Urus IT PRODUK MAKANAN DAN MINUMAN
    - Urus Izin Prinsip
    -Urus SIUP.
    -Urus TDP
    -Dll

    PT. LEGALITAS SARANAIZIN INDONESIA.
    Gedung Maya Indah Lt 2 Jakarta Pusat 10450
    Telp. 021-3142566
    Fax. 021-3928113
    HP. 081385042000
    Flexi. 021-70940216
    Website: http://www.saranaijin.com
    Email legal@saranaizin.com
    Pin BB 2262D175
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • URUS NIK BEACUKAI / REGISTRASI PABEAN / SRP BEACUKAI
    Peraturan Menteri Keuangan No. 63/PMK.04/2011

    - URUS SRP, NIK BEACUKIA PENERBITAN BARU
    - URUS SRP, NIK BEACUKAI DITOLAK.
    - URUS SRP, NIK BEACUKAI DIBLOKIR
    - URUS SRP, NIK BEACUKAI PINDAH ALAMAT,

    URUS IZIN USAHA:
    - URUS PENDIRIAN PT – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS PENDIRIAN PMA – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS PENDIRIAN CV – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS APIU – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS APIP – Jakarta, Bekasi, Depok, Tangerang, Krawang, Bandung
    - URUS NPIK – Seluruh Indonesia
    - URUS NIK BEACUKAI – Seluruh Indonesia
    - Urus IT Plastik
    - Urus IT CAKRAM OPTIK
    - Urus IT KOSMETIK
    - Urus IT ALAS KAKI
    - Urus IT MAKANAN DAN MINUMAN
    - Urus IT MAINAN ANAK-ANAK
    - Urus IT ELEKTRONIKA
    - Urus IT OBAT TRADISIONAL DAN HERBAL
    - Urus IT PRODUK MAKANAN DAN MINUMAN
    - Urus Izin Prinsip
    -Urus SIUP.
    -Urus TDP
    -Dll

    PT. LEGALITAS SARANAIZIN INDONESIA.
    Gedung Maya Indah Lt 2 Jakarta Pusat 10450
    Telp. 021-3142566
    Fax. 021-3928113
    HP. 081385042000
    Flexi. 021-70940216
    Website: http://www.saranaijin.com
    Email legal@saranaizin.com
    Pin BB 2262D175
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Views
Total Views
1,032
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
2
Likes
0
Embeds 0
No embeds

No notes for slide
  • Organic : Kolay, basit, fazla yenilik gerektirmeyen, yazılım ekibinin aşina olduğu uygulama Embedded : Geniş, donanım, yazılım ve işletim kısıtlarıyla geliştirilen, yenilik gerektiren tasarıma sahip Semi-detached : Orta seviyede karışık ekiplerin bir arada çalıştığı, katı ihtiyaçlar seti olan uygulama
  • 6 isinpar

    1. 1. İŞ YAPIM ÇÖZÜMLEMESİ VE PROJE TAHMİNLEME Metin ŞEN 91090017996 28/03/11 M. Fatih AKBAŞ 91070015954 Hazırlayan
    2. 2. İçerik <ul><li>İş yapım çözümlemesi geliştirme </li></ul><ul><li>Yan ürünler ile kilometre taşları arasındaki farkı tanımlama </li></ul><ul><li>Proje hesaplama yöntemlerinin birkaçını tanımlama ve uygulama. Delphi tekniklerini, aşağıdan yukarıya hesaplama, yukarıdan aşağıya hesaplama, zaman yönetimi(time boxing) </li></ul>28/03/11
    3. 3. <ul><li> Bilim dünyasının proje yönetim kuruluşu (PMBOK) projenin zamanında bitmesini sağlamak ve projenin oluşum çizelgesini oluşturmak için gerekli işlemler üzerine odaklanır. PMBOK’ta da tanımlandığı gibi proje zamanlama yönetimi şunları içerir; </li></ul><ul><li>Etkinlik tanımlama - Proje kapsamındaki yan ürünleri sırasıyla oluşturmak için, hangi etkinliklerin tamamlanması gerektiğinin belirlenmesi. </li></ul><ul><li>Etkinlik sıralaması - Etkinlikler paralel yürütülebilir mi ya da sırayla tamamlanabilir mi diye belirleme ayrıca etkinlikler arası muhtemel bağlara bakma </li></ul><ul><li>Etkinlik sürecinin kestirimi - Her bir etkinliğin tamamlanma süresini kestirme. </li></ul>28/03/11 Giriş
    4. 4. <ul><li>Oluşum çizelgesi geliştirme - Kaynakların geçerliliğine dayanır. Etkinlikler,onların sıralanması, zamanlama kestirimleri ve bütçe oluşum çizelgesi geliştirilebilir. </li></ul><ul><li>Oluşum çizelgesinin denetlenmesi - Proje oluşum çizelgesindeki değişiklikleri denetleme ve uygun işlemlerin ve yöntemlerin yapılmasını sağlama </li></ul><ul><li>Bu bölümde bu iki işleme yoğunlaşacağız: Etkinlik tanımlama ve etkinlik kestirimi. Bunlar özel dikkat isteyen kilit işlemlerdir. Çünkü bunlar projenin çizelgesini ve bütçesini belirleyen ağ modelinin, geliştirilmesi için veri girişi gerektirmektedirler. Bir sonraki bölümde proje taslağını detaylandırmak için bunların hepsini nasıl bir araya getirdiğimizi göreceksiniz. </li></ul>28/03/11 Giriş
    5. 5. Giriş <ul><li>Bu bölümün geri kalan kısmında ise birkaç önemli tekniklerden, araçlardan ve görüşlerden bahsedilecektir. Öncelikle iş yapım çözümlemesi (WBS) işlendi. Bu, projeyi tamamlamak için sırayla yapılması gereken işleri ve etkinlikleri ana hatlarıyla belirleyen sıradüzen bir yapı sağlar. WBS, proje detayları ve proje kapsamı arasındaki köprüyü sağlar. Bu köprü proje yazılım yönetimi paketine dahil edilir. </li></ul><ul><li>Bugün bir çok proje yazılım yönetim paketi oldukça ucuz ve zengin içeriklidir. Bir araç olmadan bir projeyi taslak haline getirmek ve yönetmek herhangi biri için kestirim edilemez bir şeydir. Birinin iyi grafik ve rapor oluşturma yeteneği ile ya da proje yazılım yönetimi paketi tecrübeleriyle, projenin başarısı kestirim edilemez. </li></ul>28/03/11
    6. 6. Giriş <ul><li>Öncelikle proje etkinlikleri tanımlandı. Bir sonraki basamak, kestirim yöntemleri ve tekniklerinden burada bahsedilmesine rağmen, her bir etkinliğin ne kadar zaman süreceğini kestirmektedir. Tahmin etmek tam olarak bir bilim değildir. Tahmin etmek de bazı değişkenlere bağlıdır-etkinliğin zorluğu, etkinliği tamamlamak için ayrılmış kaynaklar, araçlar ve etkinlikteki özel çalışmaları destekleyen bir çevre (teknoloji,alışkanlıklar vs.) Projenin başlarında kestirimler zayıf olacaktır çünkü sorunu tam olarak anlama ve eldeki imkanlar az olacaktır. Hiç bir tek yöntem her zaman %100 kesinlik sağlamamasına rağmen, tek yöntem ya da yöntemlerin birarada kullanımı kestirimlerde tercih edilirler. </li></ul>28/03/11
    7. 7. İŞ YAPIM ANALİZİ (The Work Breakdown Structure-WBS) <ul><li>En son bölümde proje kapsamının nasıl tanımlandığını ve yönetildiğini öğrendiniz. Tasarım tanımlama işleminin bir parçası gibi birkaç araç ve tekniklerden de bahsedildi. Örneğin, yan ürün tanımlama masası (DDT) ve yan ürün yapı çizelgesi, proje takımı tarafından sağlanması gereken yan ürünleri tanımlar. </li></ul><ul><li>Öncelikle projenin tasarımı tanımlanır, sonraki basamakta ise etkinlikler ve görevler tanımlanır. Proje takımı yan ürün tasarımı için gerekli olanları tamamlamalıdır. İş yapım çözümlemesi proje taslağını geliştirmek için kullanışlı bir araçtır ve proje tasarımı ile oluşum çizelgeleri ve bütçe arasında bağ kurar. Gregory T. Haugan (2002)’a göre </li></ul>28/03/11
    8. 8. İŞ YAPIM ANALİZİ (The Work Breakdown Structure-WBS) <ul><li>WBS ürün,servis ya da doğal bölünmenin nasıl gerçekleştirildiğini göstermek ve ona odaklanmak için işin yerel dağılımını gösterir. Bu gerçekleştirilmesi istenen işin özetidir. (17) </li></ul><ul><li>WBS proje taslağı yapısının geliştirilmesi için taktiksel bir taslak çerçevesi oluşmasını sağlar. PMBOK “yan ürün-yönlenmiş sıradüzen” gibi WBS’yi asıl olarak tanımlar. Ama WBS’nin görüntüsünün neye benzediği ve nasıl inşa edilmesi gerektiği ile ilgili bir çok tartışma ve karışıklık vardı. Son zamanlarda Proje Yönetim Enstitüsü, WBS için standart önerilerinde bulunması amacı ile bir komite kurdu. Komite her hangi bir sınırın olmaması gerektiğini ve WBS’nin esnek olması gerektiğini önerdi. Sonrasında WBS, takımın ve proje yönetiminin ihtiyaçları doğrultusunda çeşitli yollarda kullanılabildi. </li></ul>28/03/11
    9. 9. İŞ YAPIM ANALİZİ (The Work Breakdown Structure-WBS) <ul><li>WBS projeyi daha kolay yönetilebilir olan küçük parçalara böldü. Buna çalışma paketleri dendi. Çalışma paketleri proje etkinliklerini tanımlamak için yerel taban sağladı ve diğer etkinlikler için kaynaklar ayırdı. Böylece tüm proje çalışması tasarlanmış oldu (Haugan 2002) Çalışma paketleri, proje taslağını, oluşum çizelgesini ve bütçeyi geliştirmeyi mümkün kılar. Sonra da projenin ilerleyişini gözlemeyi sağlar. </li></ul>28/03/11
    10. 10. İŞ YAPIM ANALİZİ (The Work Breakdown Structure-WBS) <ul><li>Şekil 6.1 de gösterildiği gibi, bir çalışma paketi belki projeyle birlikte kendi kendine başlayan bir sıradüzen gibi görülebilir. Proje her biri bir ya da daha fazla yan ürüne sahip safhalara ayrılır. Bu yan ürünler, yan ürün tanımlama masasında ve yan ürün çözümleme oluşum çizelgesinde tanımlanır. Dahası her bir safha en azından bir özel yan ürünü sağlamalıdır. </li></ul>28/03/11
    11. 11. Yan Ürünler ve Kilometre Taşları ( Deliverables and Milestones ) <ul><li>Kilometre Taşları, yan ürünün bittiğini gösteren ya da aşamanın resmen sonlandığı gösteren önemli başarı kanıtlarıdır. </li></ul><ul><li>Yan ürünler ve kilometre taşları birbirleriyle yakından ilişkilidir fakat aynı şey değildirler. Yan ürünler, sunum ya da raporları, taslaklarını, ilk örnekleri ve son uygulama dizgelerini içerebilir. Diğer taraftan bir kilometre taşı başarıya odaklanmalıdır. </li></ul><ul><li>Teoride, eğer proje takımı oluşum çizelgesinde belirtilmiş kilometre taşlarının hepsi için toplantılarda başarılı olursa, proje öngörülen zamanda bitebilir. Eğer proje takımının hünerleri başarı olarak görülüyorsa, gerçekçi bir kilometre taşı takımın motivasyonunu arttırabilir. Eğer bir kilometre taşı önemli bir noktayı işaret ediyorsa, takım bu başarıdan memnun olur ve diğer aşamaya geçer. </li></ul>28/03/11
    12. 12. Yan Ürünler ve Kilometre Taşları ( Deliverables and Milestones ) <ul><li>Kilometre taşları projenin riskini de azaltır. Bir kilometre taşının üzerinden geçmek ,özellikle bir aşamanın kilometre taşıysa, projenin ilerlemesinin görülmesini sağlar. Her bir kilometre taşının tamamlanmasının başarılı olması için ilave kaynaklar bağımlı olmalıdır. Eğer proje kilometre taşlarıyla buluşamazsa, her bir kilometre taşının tamamlanması için alınacak uygun taslaklar ve adımlar yani ilave kaynaklar proje ile bağımlı olmalıdır. </li></ul><ul><li>Kilometre taşları, görüşlerin ispatı ya da düğüm noktası gibi davranarak riski azaltmak için de kullanılabilirler. Çoğu zaman önemli riskler ,BT projeleriyle ilgili, yeni teknolojilere ya da teknolojinin özgünlüğüne dayanır. Düğüm noktası, bir fikrin denemesi, görüş ya da teknoloji olabilir. Bu projenin başarısı için kritiktir. </li></ul>28/03/11
    13. 13. Yan Ürünler ve Kilometre Taşları ( Deliverables and Milestones ) <ul><li>Örneğin, belirli bir vericinin ilgili veritabanını ilk kez kullanarak, bir veri deposu inşa ediliyor varsayın. Bu projenin düğüm noktası birkaç farklı dizgeden veri toplanması olabilir. Veriler temizlenir ve sonra verileri ilgili veritabanı yönetim dizgesi için kullanışlı hala getirilir. Takım belki, sadece deneme verilerinin küçük bir kısmını kullanarak başarıya ulaşmayı sağlayabilir. Öncelikle takım bu sorunu küçük ölçüde çözer. Veri deposundaki birkaç dizgeden veri almak için teknikleri ve görüşleri var ve başarılı olabilirler. Bu atılım, bütün öğrendiklerini daha büyük bir ölçekte birleştirmelerini sağlar. Sonrasında bu düğümü çözmek kilometre taşıdır. Bu, projeyi tamamlamak için daha çok zaman harcamak ve kaynak bulmak için cesaret verir. </li></ul>28/03/11
    14. 14. Yan Ürünler ve Kilometre Taşları ( Deliverables and Milestones ) <ul><li>Kilometre taşları kalite denetleme için mekanizmada sağlarlar. Örneğe devam edecek olursak, kullanıcılara sadece ara yüz sağlamak, onlar tarafından kabul edileceğini garantilemez. Kullanıcı ara yüzünün yan ürününün tamamlanması sadece onların onayıyla son bulur; diğer taraftan proje takımı düzenlemeler için fazla zorlanacaktır. Kısacası yan ürün sadece yapılmamalı, doğru yapılmalı. </li></ul>28/03/11
    15. 15. WBS’yi Geliştirme <ul><li>WBS’yi geliştirmek için, bütün işlerin etkinliklerini içerdiğine herkes güvenene kadar, birkaç versiyon gerekebilir. İşi kim yapacaksa o kişiyi işe dahil etmek iyi bir fikirdir. Çünkü çalışacak kişi neyin daha iyi olacağını herhangi birinden daha iyi bilir. WBS projenin büyüklüğüne ve doğasına dayanır. Adımların içeriğini göstermek için son bölümden bir örnek ile devam edelim. Hatırlayacağınız üzere proje kapsamını tasarlamak için DDT ve DSC’yi yarattık. Takibi kolaylaştırmak için projenin bir parçasına odaklanalım ‘Deneme sonuç raporlarını gösteren belgeyi oluşturma’ Şekil 6.2 bölüm 5te geliştirdiğimiz DSC yi gösteriyor.Gördüğünüz üzere 2 yan ürün-deneme taslağı ve deneme sonuç raporu- projenin deneme aşamasında tamamlandı. </li></ul>28/03/11
    16. 16. WBS’yi Geliştirme <ul><li>DSC bizim projemiz için aşamaları tanımlar. Bir sonraki basamak, her bir aşama ve yan ürün için çalışma paketlerinin geliştirilmesidir. Takımın buluşmasından sonra, deneme sonuç belgelerini oluşturmak için ihtiyacımız olan etkinlikleri tartıştık ve tanımladık diyebiliriz: </li></ul><ul><li>Deneme taslağını müşteri ile gözden geçirin. Böylece neyin deneme edileceği, nasıl deneme edileceği ve denemelerin ne zaman yapılacağı konusunda rahat olurlar. Bu gözden geçirme nezaket icabı olabileceği gibi gerçekten müşteri desteğine ihtiyacımız olduğu içinde yapılabilir. Bu nedenle desteklerine ihtiyacımız olabileceğini düşünüp onları bilgilendirmemiz gerekir. </li></ul><ul><li>Müşteriyi bilgilendirdikten sonra dizgeyi deneriz. Deneme taslağından çıkmadan denemeyi yaparız. </li></ul>28/03/11
    17. 17. WBS’yi Geliştirme <ul><li>Öncelikle deneme sonuçlarını toplamamız ve çözümlememiz gerekir. </li></ul><ul><li>Sonuçları çözümleme ettikten sonra, sonuçları raporlamamız ve müşteriye sunmamız gerekir. </li></ul><ul><li>Eğer hepsi düzgün giderse müşteri deneme sonuçlarını kabul eder. Böylece projenin yürütme aşamasına geçebiliriz. Eğer işler düzgün gitmezse sorunu bulmamız ve çözmemiz gerekir. Aklınızda bulunsun, deneme aşaması, deneme taslağını yapıp deneme raporu oluşturunca sonlanmaz. Müşteri sadece, dizge önceden belirlenmiş kalite standartlarında çalışırsa deneme aşamasını onaylar. </li></ul>28/03/11
    18. 18. WBS’yi Geliştirme <ul><li>Şekil 6.3, projenin deneme aşamasının detayları ile birlikte bir WBS örneği gösteriyor. Projede WBS’nin işleme şeklini, aşamaları, yan ürünleri, görev/etkinlikleri ve kilometre taşı bileşenlerini şekil 6.1de de görebilirsiniz. WBS çoğunlukla ondalık dizgedeki sayılarla takip edilir bu detayların derecelerini görmemizi sağlar. Örneğin ‘-6.2 deneme rapor sonuçlarına tıklamak detayları ‘+6.2 Deneme sonuç raporları’ içinde gösterir. Benzer şekilde ‘+’ şeklindeki he hangi bir şeye tıklayınca, onunla alakalı bilgileri göstermek için açılır. </li></ul><ul><li>WBS hazır ve amaçlı olmalıdır. Hatırlayın, bir projenin amacı bir şeyler üretmektir. Sadece belirlenmiş etkinliklerin tamamlanması değildir. WBS herhangi bir döngü sağlamamasına rağmen, bazı etkinlikler, kilometre taşı başarıya ulaşana kadar tekrar edilmelidir. </li></ul>28/03/11
    19. 19. WBS’yi Geliştirme <ul><li>WBS Projenin MOV’unu desteklemelidir. WBS, yan ürünün teslim edilmesi için gerekli olan sadece görev ve etkinlikleri içermelidir. Proje taslağının geliştirilmesine devam etmeden önce proje takımı, proje tasarımında tanımlanan bütün proje yan ürünlerinin WBS desteğiyle teslim edilmesini sağlamalıdır. Bu durum, projenin MOV’una ulaşmasını sağlayacaktır. Eğer WBS’nin her bir seviyesi etkinlikleri %100 takip ederse, proje oluşum çizelgesini geliştirirken etkinliklerin hepsinin tanımlanmış olduğuna emin oluruz. İş için gerekli bütçeyi oluşturduğumuzda, gerekli tüm hesaplar ve kaynaklar tanımlanacaktır. </li></ul>28/03/11
    20. 20. WBS’yi Geliştirme <ul><li>WBS’yi geliştirmek için, bütün işlerin etkinliklerini içerdiğine herkes güvenene kadar, birkaç versiyon gerekebilir. İşi kim yapacaksa o kişiyi işe dahil etmek iyi bir fikirdir. Çünkü çalışacak kişi neyin daha iyi olacağını herhangi birinden daha iyi bilir. WBS projenin büyüklüğüne ve doğasına dayanır. Adımların içeriğini göstermek için son bölümden bir örnek ile devam edelim. Hatırlayacağınız üzere proje kapsamını tasarlamak için DDT ve DSC’yi yarattık. Takibi kolaylaştırmak için projenin bir parçasına odaklanalım ‘Deneme sonuç raporlarını gösteren belgeyi oluşturma’ Şekil 6.2 bölüm 5te geliştirdiğimiz DSC yi gösteriyor.Gördüğünüz üzere 2 yan ürün-deneme taslağı ve deneme sonuç raporu- projenin deneme aşamasında tamamlandı. </li></ul>28/03/11
    21. 21. WBS’yi Geliştirme <ul><li>Detayların seviyesi, taslak haline getirme ve denetleme ile desteklenmelidir. WBS, proje taslağı ve proje kapsamı arasında köprü oluşturur. Bu köprü bütçe ve oluşum çizelgesidir. Bu nedenle detayın seviyesi, sadece proje taslağını oluşturmayı desteklememelidir. Fakat proje yöneticisine ve takımına, asıl oluşum çizelgesinin ve bütçenin işleyişini izleme ve hisselendirme imkanı verir. WBS geliştirilirken yapılan 2 hata; çok fazla ya da çok ince detaylardır. Çok ince detaylar, projedeki önemli etkinlik ve görevleri ihmal etmemizi ya da gözden kaçırmamıza neden olabilir. Bu, fazlasıyla iyi bir bütçe ve oluşum çizelgesi gerektirir. Diğer bir taraftan WBS 1 saatlik görevlerden oluşan bir yapılacaklar listesine dönüşmemelidir. Aşırı detaylar ayrıntılı çalışma gerektirir ve projede bazı yan etkilere neden olabilir. Öncelikle takımın moralini etkileyebilir. </li></ul>28/03/11
    22. 22. WBS’yi Geliştirme <ul><li>WES geliştirirken,o konuda çalışacak kişi de projeye dahil edilmelidir. WBS’de detayın seviyesini uygun bir şekilde ayarlamak için gidilecek yollardan biri de bu konuda çalışacak kişiyi, geliştirme çalışmalarına dahil etmektir. Bir alanda uzman ve tecrübeli olan bir kişi, özel proje geliştirmelerinde neye ihtiyaç olacağını daha iyi bilir. </li></ul><ul><li>Döngüyü ve dersleri öğrenme WBS’nin geliştirilmesini destekler. Daha iyi bir WBS geliştirmek için proje takımı, öğrenme döngüsünün fikrini kullanarak neyi bildiklerine (gerçekler), neyi bildiklerini düşündüklerine (kanı) ve neyi bulmaları gerektiğine (araştırma) odaklanabilirler. Önceki projelerden öğrenilen dersler, WBS’yi oluşturmaya ve sonraki proje taslağını çıkarmaya ve tamamlamaya yardımcı olabilir. </li></ul>28/03/11
    23. 23. PROJE TAHMİNLEME <ul><li>Öncelikle proje yan ürünleri ve etkinlikler tanımlandı. Projenin oluşum çizelgesinin ve bütçesinin geliştirilmesindeki diğer adım, her bir etkinliğin sürecinin kestirilmesi. Proje yönetimindeki çok önemli ve zor etkinliklerden biri de görevlerin tamamlanması için gerekli zamanın hesaplanmasıdır. Görevi tamamlamak için gerekli olan maliyetin hesaplanması da görevin bir parçası gibi görülmelidir. Görevin tamamlanması için gerekli zaman, projenin bütçesi ile doğrudan bağlantılıdır. T. Capers Jones (Jones 1998)’un değindiği gibi; Büyük yazılım çekirdeklerindeki sorunlar, genellikle yazılımın başlangıcındaki ilk 3 ayda görülür. Hasty’e göre , proje yönetim fonksiyonunda mantıksız vaatler, profesyonel olmayan kestirim teknikleri ve dikkatsizlik, sorunlar için fonksiyon oluşturur. </li></ul>28/03/11
    24. 24. PROJE TAHMİNLEME <ul><li>Tahmin Etme </li></ul><ul><li>Tahmin ederek hesaplama ya da sadece havadan sayıları toplama, projenin oluşum çizelgesine ve bütçesine uymak için iyi bir yol değildir. Ne yazık ki birçok tecrübesiz proje yöneticisi tahmin ederek hesaplama yapmaya eğilimlidir. Çünkü bu hızlı ve kolaydır. Örneğin deneme aşamasının 2 hafta süreceğini tahmin edebiliriz. Neden 2 hafta? Neden 3 hafta ya da 10 hafta değil ? Çünkü sayıları havadan hesaplıyoruz ve güven oldukça düşük oluyor. Sayıları kafadan atabilirsiniz. Tahmin etmek hislere dayanır gerçek kanıtlara değil, bu da sorun teşkil eder. </li></ul><ul><li>Bununla birlikte çoğu zaman proje yöneticisi, bir noktanın üzerinde durur ve kabataslak bir şekil çıkarır. Bir zaman çerçevesi yada fiyat belirlerken dikkatli olun çünkü yaptığınız tahminler kayıt altına alınır. </li></ul>28/03/11
    25. 25. PROJE TAHMİNLEME <ul><li>İnsanlar genelde iyimserdir ve dolayısıyla tahminleri de iyimser olur. Değerlendirmeyi eksik yapmak kaliteyi düşürür, fazladan zaman harcatır ve müşteriden tahmin edilmeyen sorunlar çıkarır. Eğer kendinizi tahmin etmeye zorlanırken bulursanız, ilk işiniz konuyla ilgili bilgi edinmek için zaman kazanmak olsun. Eğer bunu yapamıyorsanız en iyi yaklaşım bir aralık vermek şeklinde olacaktır. Örneğin bir şeyin 3 ay süreceğini ve 30000 $’a mal olacağını düşünüyorsanız, 3-6 ay arası 30000$-60000$ arası şeklinde konuşun. Hemen sonra bir küçük araştırmayla daha kesin bir sayı verebileceğinizi söyleyin. En iyi ihtimalin 3 ay 30000$ olduğunu söyleyin. 2 ya da 6 ay olmadığını belirtin. Çünkü insanlar iyimserliğe eğilimlidir ve işin 3 ay içinde bitmesi onlar için iyi bir durum olur </li></ul>28/03/11
    26. 26. PROJE TAHMİNLEME <ul><li>Delphi Tekniği </li></ul><ul><li>Delphi tekniği, bir konu üzerinde görüş birliğine sahip çok yönlü uzmanları kapsar. Delphi tekniği genellikle küme karar alma-uygulamaları için kullanılmasına rağmen tahmin yürütme için de kullanışlı olabilmektedir (Roetzheim ve Beasley 1998). </li></ul><ul><li>Aynı maddeyi tahmin etmede Delphi tekniklerini kullanmak için, birkaç yeni uzman işe alınmalıdır. Her bir uzman tahminde bulunur sonra sonuçlar kıyaslanır. Eğer tahminler birbirlerine yakınsa, ortalamaları alınır ya da bir tanesi kullanılır. Diğer bir şekil ise, tahminler uzmanlara geri dağıtılır, farklılıkları tartışırlar ve yeni öneri oluştururlar. </li></ul><ul><li>Genellikle bu turlar gizli yapılır ve bazıları görüş birliği yakalanana kadar sürer. </li></ul>28/03/11
    27. 27. PROJE TAHMİNLEME <ul><li>Zaman Kısıtlama(Time Boxing) </li></ul><ul><li>Zaman kısıtlama bir tekniktir. Özel etkinlik ya da görevler için ayrılmış zaman dilimlerinden oluşur. Bu ayırma işlemi,sadece tahmin işleminden ziyade gerekliliğe dayanarak yapılır. Örneğin bir proje takımının ilk örneği oluşturmak için sadece 2 haftası var. 2 haftanın sonunda işlemin hepsinin bitip bitmemesi önemsenmeden, ilk örnek üzerinde çalışma durur. </li></ul><ul><li>Etkili kullanılırsa zaman kısıtlama yöntemi, proje takımını önemli ve kritik görevler üzerinde odaklandırır. Uygunsuz zamanda ya da çok sıklıkla uygulanıra çalışanlar sıkılabilir ve sinirlenebilir. </li></ul>28/03/11
    28. 28. PROJE TAHMİNLEME <ul><li>Yukarıdan Aşağı Hesaplama </li></ul><ul><li>Aşağı yukarı tahmin yöntemi, projenin kısımlarının ne kadar zaman alacağı ve ne kadara mal olacağını tahmin etmeyi kapsar. Aşağı yukarı tahmin, üst yönetimin emirleri doğrultusunda sürekli ortaya çıkarılır. (örneğin,projeyi 6 ay içinde bitireceksin ve 500000$’dan fazla harcamayacaksın) </li></ul><ul><li>Oluşum çizelgesi ve bütçe genellikle, bir izlenecek yol taslağı ile ya da birilerinin kesinlikle öyle olacağını söyledikleri bir fikir ile oluşturulur. Diğer bir taraftan aşağı-yukarı tahmin iş çevresine de etkili olabilir. Örneğin bir yarışma olabilir ve proje 6 ay içinde bitmelidir ya da müşterinin sadece 6 ay vakti vardır. Müşteri kazanmak için yapılabilir. </li></ul>28/03/11
    29. 29. PROJE TAHMİNLEME <ul><li>Öncelikle bütçe veya oluşum çizelgesindeki hedef maddeler tanımlanmalı. Çeşitli proje yaşam döngü aşamalarını yüzde olarak hisselendirmek, görev ve etkinlikler arası bağı kurmak proje yöneticisinin işidir. Son projeden alınan veriler yüzdelik hesaplarına başvurma ve tahminleri geçerli kılmak için çok faydalı olabilir. Hedef objeler gerçekçi, nedenli ve elde edilebilir olduğu zaman, aşağı yukarı tahmin çok iyi çalışır. Proje takımından bağımsız kişiler tarafından yapıldığında bu hedefler fazlasıyla iyimser ve sinirli olabilir. </li></ul>28/03/11
    30. 30. PROJE TAHMİNLEME <ul><li>Projenin parametreleri, oluşum çizelgesini, maddeleri, bütçeyi ya da diğer kaynakları, fonksiyonelliği, başarım gerekliliğini, özellikleri ya da projenin diğer açılarını içerir. Ölü mart yazılım projesinin anlamı, bir yada daha fazla kısıtlamalara maruz kalmışlıktır. </li></ul><ul><li>Projenin oluşum çizelgesini, asıl tahminden %50 ‘den daha az sıkıştırılmıştır. </li></ul><ul><li>Projeyi tamamlamak için malzemenin %50’sinden daha azı azaltılmıştır. </li></ul><ul><li>Bütçe ve kaynaklar %50 ya da daha fazla azaltılmalıdır. </li></ul><ul><li>Fonksiyonellik, özellikler ya da diğer başarım veya teknik gereklilikler, olmasın gerekenlerin 2 kat altında olmalılar. </li></ul>28/03/11
    31. 31. PROJE TAHMİNLEME <ul><li>Diğer taraftan aşağı-yukarı tahmin hesaplamalara ve oluşum çizelgesi çözümlemesine çok etkili olabilir (Royce 1998). Aşağı-yukarı yaklaşımı, proje yöneticisini projenin risklerini daha yakından fark etmesini dolayısıyla özel bütçe yada oluşum çizelgesi hedefine ulaşmasını sağlayabilir. Riskleri, fedakarlıkları ve objektif yaklaşımları anlayarak, çeşitli proje ortakları, daha iyi tahminlere eğilim gösteren ortak bir görüş geliştirebilirler. Bu yaklaşım için tüm hissedarlar gönüllü olmalı ve değiş-tokuş yapmalıdırlar. </li></ul><ul><li>  </li></ul>28/03/11
    32. 32. PROJE TAHMİNLEME <ul><li>Aşağıdan Yukarıya Hesaplama </li></ul><ul><li>Dünyadaki en gerçek tahminleme aşağıdan-yukarıya tahminleme kullanılarak yapılır (Royce 1998). Aşağıdan yukarıya tahmin projeyi küçük parçalara böler. Doğrudan, insan-saatler, insan-haftalar, insan-aylar şeklinde bölümler oluşturur ve gerekli zaman ve gayreti hesaplar. İş yapım çözümlemesi, aşağıdan yukarıya tahmine temel oluşturur. </li></ul><ul><li>Projenin yöneticisi yada projede iyi olan biri her bir etkinlik için mantıklı zamanlama tahminleri yapabilir. Kısacası aşağıdan yukarıya tahminleme, gösterilecek gayretin hesaplanması ile ve tüm gerekli görevlerin ya da etkinliklerin listelenmesiyle başlar. Her bir etkinlik için toplam zaman ve yaklaşık tutar, projenin hedef oluşum çizelgesine ve bütçesine temel oluşturur. </li></ul>28/03/11
    33. 33. PROJE TAHMİNLEME <ul><li>Önceki örneğimize devam edelim. Yazılım denemelerini yapan kişiyle görüştükten sonra, takip eden etkinlikler için devam sürecini düşünün: </li></ul><ul><li>  </li></ul><ul><li>6.2 Deneme sonuçlarının raporu </li></ul><ul><li>6.2.1 Müşteriyle deneme taslağını gözden geçirme 1 gün </li></ul><ul><li>6.2.2 Deneme taslağını uygulama 5 gün </li></ul><ul><li>6.2.3 Sonuçları çözümleme 2 gün </li></ul><ul><li>6.2.4 Deneme sonuç raporlarını ve sunumu hazırlama 3 gün </li></ul><ul><li>6.2.5 Deneme sonuçlarını müşteriye sunma 1 gün </li></ul><ul><li>6.2.6 Herhangi bir yazılım sorununu belirleme 5 gün </li></ul>28/03/11
    34. 34. PROJE TAHMİNLEME <ul><li>Eğer bütün tahmini süreçlerini birbirine eklersek, deneme sonuç raporlarını oluşturmanın 17 gün alacağını buluruz. Bu hesapları nasıl çıkardık? Tahmin mi ettik ? Umarım ki hayır! Bu hesaplamalar tecrübeye dayanmalıdır. Yazılım denetçileri geçmişte muhtemelen defalarca bunu yaptılar bu nedenle hangi etkinlikleri yapmaları gerektiğini ve her birinin ne kadar zaman süreceğini biliyorlar. Ya da bu projeye benzer başka projelerden bu hesaplamaları çıkartabiliriz. Paralel hesaplama önceki projelerden benzerliği olana benzer şekilde tahminlemeye dayanır (Rad 2002) </li></ul><ul><li>Aklınızda bulunsun hesaplamalar kendi etkinliğinin fonksiyonudur, kaynaklar ve destekler gibi. Bir etkinliği hesaplama süreci öncelikle etkinliğin doğasına dayanır. Genellikle çok karışık ve çözümlemesi olmayan etkinlikler, sade ve iyi çözümlenmiş olanlara oranla daha çok zaman alırlar. </li></ul>28/03/11
    35. 35. PROJE TAHMİNLEME <ul><li>Bir etkinliğin kaynakları da hesapları etkiler. Örneğin iyi eğitimli, tecrübeli biri daha az zaman harcamak demek. Acemi biriyle ise daha çok zaman harcanır. Uzmanlık ve tecrübe eşitliğin bir parçasıdır. Çalışanın motivasyon ve heves seviyesini de göz önünde bulundurmak zorundayız. </li></ul><ul><li>Sonuç olarak bizim sağladığımız destek de hesaplamalarımızı etkiler. Destek olarak teknoloji, araçlar, fiziksel çalışma ortamı düşünülebilir. </li></ul><ul><li>Bunlar hesaplama yaparken göz önünde bulundurmamız gereken bazı değişkenler. Siz muhtemelen başkalarıyla da karşılaşacaksınız. Hesaplama her zaman bir tahmin olacaktır; büyük bir resme bakarak ve anlayarak güvenimizi arttırabiliriz. </li></ul>28/03/11
    36. 36. Yazılım Mühendisliği Ölçümleri ve Yaklaşımları 28/03/11
    37. 37. Yazılım Mühendisliği Ölçümleri ve Yaklaşımları Hazırlayan M. Fatih AKBAŞ 91070015954 28/03/11
    38. 38. Amaç ve İçerik <ul><li>Yazılım Mühendisliği Nedir? </li></ul><ul><li>Yazılım Ölçümleri Nedir? </li></ul><ul><li>Yazılım Mühendisliği Kestirim Modeli </li></ul><ul><li>Kod Satır Sayısı (Line Of Code) </li></ul><ul><li>İşlev Noktaları Çözümlemesi(Function Points Analysis) </li></ul><ul><li>Düzenlenmemiş İşlev Noktası (UAF) ve UAF’nin Hesaplanması </li></ul><ul><li>Yazılım Büyüklük Kestirimi </li></ul><ul><li>Teknik Ayarlama Etkenleri (Technical Adjustment Factors) </li></ul><ul><li>Genel Sistem Karakteristiği ve Hesaplamalar </li></ul><ul><li>Yaklaşımlar </li></ul><ul><li>İşlev Noktasından LOC’a Çevrim </li></ul><ul><li>COCOMO (Yapısal Maliyet Modeli) </li></ul><ul><li>Buluşsal Yöntemler,Sezgiler </li></ul><ul><li>Otomatik Kestirim Araçları(Automated Estimating Tools) </li></ul><ul><li>Kestirmenin En iyi Yolu ve Sonuç </li></ul>28/03/11
    39. 39. Giriş <ul><li>Yazılım Mühendisliği; yazılım geliştirmek için kaliteli yaklaşım geliştirme ve bu doğrultuda süreçlere, araçlara ve yöntemlere odaklanan bir disiplindir. (Pressman, 2001) </li></ul><ul><li>Diğer yandan ölçümler yazılım mühendisliğinin temelini oluşturur ve bilgisayar yazılımına tarafsız olarak değer biçmek için geniş çaplı ölçümlere başvurur. </li></ul>28/03/11
    40. 40. Yazılım Ölçümü Nedir? <ul><li>Yazılım ölçümü , bir yazılımın herhangi bir niteliğinin, ya da o yazılımın teknik özelliklerinin bir ölçümüdür. </li></ul><ul><li>Nicel yöntemlerin diğer bilim dallarındaki başarılı uygulamaları nedeniyle bilgisayar bilimleri denemecileri ve kuramsalcıları aynı yaklaşımların yazılım geliştirme için de uygulanması konusunda uzun uğraşlar vermişlerdir. Bir Yazılım Mühendisliği profesyoneli olan Tom DeMarco, &quot;Ölçülemeyen şeyler denetlenemezler&quot; demiştir. </li></ul>28/03/11
    41. 41. Yazılımın Kestirilmesi <ul><li>Bir bilgi teknolojileri projesinin kestirilmesinin en büyük zorluğu projenin (uygulama sisteminin) dağıtılabilir hale gelmesi için kestirilen zaman ve çabadır. </li></ul><ul><li>Projelerin bakımı ve paketlenmiş yazılımın kurulumu da benzer zorluklardandır. </li></ul>28/03/11
    42. 42. Yazılımın Kestirilmesi <ul><li>Asıl zorluk fiziksel şeylerden ziyade mantıksal bazı şeylerin kestirilmesinde yatar.Bunlar, projenin yaşam döngüsünün ileriki aşamalarına kadar iyi tanımlanmazlar. </li></ul><ul><li>Kapsam tanımı projenin kapsam sınırları içinde neyin olup neyin olmadığına dair sadece yüksek düzey bir görünüm sağlar.Özel gereksinimler (özellikler ve işlevsellik şartları gibi) genellikle tasarım aşamasında tanımlanmazlar. </li></ul>28/03/11
    43. 43. Yazılımın Kestirilmesi <ul><li>Bu doğrultuda ek olarak projenin ilk aşamalarında bilinen ve bilinmeyen bir takım özelliklerin çalıştırılmasının teknik zorlukları ve karmaşıklığını sayabiliriz. </li></ul><ul><li>Sonuç olarak bir bilgi teknolojileri projesini kestirmek hareket eden bir hedefi vurmaya çalışmak gibidir.Bu doğrultuda sürekli bir düzen, uyum gereklidir. </li></ul>28/03/11
    44. 44. Yazılım Mühendisliği Kestirim Modeli <ul><li>Şekilde gösterilen ilk adım bilgi teknolojileri uygulamasının büyüklüğünü doğru olarak saptamaktır.(Jones 1998) </li></ul><ul><li>Diğer bir ifadeyle uygulama ne kadar büyük? </li></ul><ul><li>Bu noktada çok fazla detaya girmeden şunu söyleyebiliriz, küçük bir sisteme göre daha büyük bir sistem inşa etmek daha fazla çaba gerektirir.(Kaynaklar,bütçe,zamanlama vb..) </li></ul><ul><li>Buna rağmen uygulamanın büyüklüğünü kestirme bulmacanın parçalarından sadece biridir. </li></ul>28/03/11
    45. 45. Yazılım Mühendisliği Kestirim Modeli 28/03/11 Büyüklük Karmaşıklık Kısıtlar&Etkiler Uygulamanın Kestirilmesi
    46. 46. Yazılım Mühendisliği Kestirim Modeli <ul><li>Zamanın ve çabanın önemli bir kısmı, daha karmaşık olan özelliklere ve işlevselliğe harcanacaktır.Sonuç olarak daha büyük karmaşıklık demek, daha fazla zaman ve çaba harcamak demektir. </li></ul><ul><li>Aynı zamanda kısıtlamalar ve çeşitli bir takım etkiler belirli bir uygulamayı geliştirmek için gerekli olan zaman ve çabayı da etkiler. Bu kısıtlamalar uygulamanın özellikleri olabilir (Jones 1998) veya süreçleri, insanları, teknolojiyi, çevreyi ve ürün için gerekli olan kaliteyi içerebilir.(Royce, 1998) </li></ul><ul><li>Bir kez kaynaklar ve zaman kestirimi bilinirse, özel aktiviteler veya görevler, projenin zamanlaması ve bütçesini oluşturma süreci ardışık bir şekilde sıralanır. </li></ul>28/03/11
    47. 47. Yazılım Ölçümleri <ul><li>Yazılım projelerinin başlangıcında yaşanan en büyük zorluk, geliştirme süreci sonucunda ortaya çıkacak yazılım ürününün büyüklüğünün doğru kestirilememesidir. </li></ul><ul><li>Bu kestirimin yapılma aşamasında kullanılabilecek bir çok yöntem vardır. </li></ul><ul><li>Bunlardan en yaygın olarak kullanılanları ise; </li></ul><ul><li>- LOC (Kod Satır Sayısı) </li></ul><ul><li>- Function Points (İşlev Noktaları Çözümlemesi) </li></ul><ul><li>- Complexity (Karmaşıklık) </li></ul><ul><li>- Kod Satırına Düşen Hata Sayısı </li></ul>28/03/11
    48. 48. Kod Satır Sayısı (Line Of Code) <ul><li>Uygulamanın büyüklüğünü anlamak için bilgisayar programlarındaki kodların satırlarını sayma en geleneksel ve en yaygın şekilde kullanılan yazılım ölçümüdür. Aynı zamanda en tartışılan olanıdır. </li></ul><ul><li>Tabi ki 1000 LOC değeri olan bir Java programı 100 LOC değerine sahip bir Java programından 10 kat daha büyüktür.Fakat bu sayının içinde yorum satırları var mı? Yorum satırlarını dahil etmeli miyiz? </li></ul><ul><li>Yorum satırları kodun bize ne yaptığını anlatması açısından önemlidir. </li></ul>28/03/11
    49. 49. Kod Satır Sayısı (Line Of Code) <ul><li>Bu aynı zamanda koddaki hataların ayıklanması açısından işleri daha da kolaylaştırır ve diğer insanların programdaki kod parçalarının ne yaptığına dair bir fikir edinmelerini sağlar. </li></ul><ul><li>Değişkenlerin tanımlanması? LOC olarak sayılmalı mıdır? </li></ul><ul><li>Tüm bunlara ek olarak, deneyimli programcılar, işe yeni başlayan programcılara göre daha az kod yazmaya eğilimlidirler. </li></ul><ul><li>Deneyimli bir programcı, işe yeni başlayan bir programcının yazdığı kod ile aynı işlevi gören, daha az sayıda satırdan oluşan ve daha etkili bir kod yazabilir. </li></ul>28/03/11
    50. 50. Kod Satır Sayısı (Line Of Code) <ul><li>Aynısı farklı programlama dilleri için de söylenebilir. </li></ul><ul><li>Assembler’de program yazmak, benzer programı Visual Basic’de yazmaktan daha fazla sayıda satırdan oluşan kod yazmayı gerektirir. </li></ul><ul><li>LOC bir verimlilik ölçümü olarak kullanılırsa, biri LOC saymanın programcının etkisiz, gereksiz fazladan kod yazmaya özeneceğini iddia edebilir. </li></ul><ul><li>Sonuç olarak, programı yazmak için gerekli olan kod satır sayısını kestirmektense, yazılmış bir programdaki kodun satırlarını saymak çok daha kolaydır. </li></ul>28/03/11
    51. 51. Kod Satır Sayısı (Line Of Code) <ul><li>İki başlıca SLOC Kaynak Kod Satır Sayısı ölçüm çeşidi vardır. Bunlar; </li></ul><ul><li>- Fiziksel SLOC </li></ul><ul><li>- Mantıksal SLOC </li></ul><ul><li>Örnek 1 </li></ul><ul><li>for (i=0; i<100; ++i) printf(&quot;hello&quot;); /* How many lines of code is this? */ </li></ul><ul><li>1 Fiziksel Kod Satırı </li></ul><ul><li>2 Mantıksal Kod Satırı (for ve printf ifadesi) </li></ul><ul><li>1 Yorum Satırı </li></ul>28/03/11
    52. 52. Kod Satır Sayısı (Line Of Code) <ul><li>Örnek 2 </li></ul><ul><li>Programcıya göre ve/veya kodlama standartlarına göre </li></ul><ul><li>Örnek 1’deki kod aşağıdaki şekilde de yazılabilir. </li></ul><ul><li>for (i=0; i<100; ++i) </li></ul><ul><li>{ </li></ul><ul><li>printf (&quot;hello&quot;); </li></ul><ul><li>} /* Now how many lines of code is this? */ </li></ul><ul><li>4 Fiziksel Kod Satırı </li></ul><ul><li>2 Mantıksal Kod Satırı </li></ul><ul><li>1 Yorum Satırı </li></ul>28/03/11
    53. 53. İşlev Noktaları (Function Points) <ul><li>LOC’daki kestirim ve verimlilik problemleri daha iyi bir yazılım ölçümü gerekliliğini getirdi.1979’da IBM’den Allan Albrecht Kaliforniya’da bir konferansta işlev noktaları fikrini ortaya attı.(Albrecht,1979) </li></ul><ul><li>İşlev noktaları saat,kilo,ton,derece gibi günlük yaşamda kullanılan bir yapay ölçümdür. </li></ul><ul><li>Bununla birlikte işlev noktaları bir uygulama sisteminin veya belirli bir modülün işlevselliğine ve karmaşıklığına odaklanır. </li></ul><ul><li>Basit bir örnek; Sıcaklığı 20 derece olarak ölçülen bir gün, 10 derece olarak ölçülen bir güne göre daha ılıktır.Benzer şekilde değeri 1000 olan işlev nokta uygulaması, değeri 500 olan işlev nokta uygulamasına göre daha büyük ve daha karmaşıktır. </li></ul>28/03/11
    54. 54. İşlev Noktaları (Function Points) <ul><li>İşlev noktaları çözümlemesinin güzel yanı teknolojiden bağımsız olmasıdır. Daha özel olarak işlevsellik ve teknoloji birbirinden ayrı tutulur. Böylece farklı programlama dillerini veya teknoloji ortamlarını kullanan veya kullanmayan farklı uygulamaları karşılaştırabiliriz. </li></ul><ul><li>Örneğin COBOL’da yazılan bir uygulama ile Java’da geliştirilen bir diğer uygulamayı karşılaştırabiliriz. </li></ul><ul><li>İşlev noktaları çözümlemesi güvenilirdir. </li></ul><ul><li>İşlev noktaları çözümlemesinde deneyimli ve aynı nitelikleri olan iki kişi yapılan çözümleme sonucunda işlev nokta sayılarını aynı sayıda veya kabul edilebilir bir hata payı ile elde ederler. </li></ul>28/03/11
    55. 55. İşlev Noktaları (Function Points) <ul><li>İşlev nokta çözümlemesini ciddi bir şekilde öğrenmek isteyenlerin sertifikalı olması önerilir. </li></ul><ul><li>Birden fazla işlev nokta kurumu olmasına rağmen, IFPUG (Uluslararası İşlev Nokta Kullanıcıları Grubu) ve UFPUG (Birleşik Krallık İşlev Nokta Kullanıcıları Grubu) gibi kar amacı olmayan, kuralları, standartları ve yetkilendirmesi olan iki temel kuruluş vardır. </li></ul><ul><li>İşlev noktalarının sayımında anahtar nokta kullanıcının gereksinimlerini iyi anlamaktan geçer. </li></ul>28/03/11
    56. 56. İşlev Noktaları (Function Points) <ul><li>Projenin başında, işlev nokta çözümlemesi projenin kapsamı çerçevesinde yürütülür. </li></ul><ul><li>Kullanıcının gereksinimleri doğrultusunda daha ayrıntılı çözümleme, tasarım ve çözümleme aşamalarında yapılabilir. </li></ul><ul><li>İşlev nokta çözümlemesi proje yaşam döngüsünün çeşitli aşamalarında yürütülebilir. </li></ul><ul><li>Örneğin; proje kapsamı tanımında, kestirim ve proje planının geliştirilmesi için kullanılabilir. Çözümleme ve tasarım aşamasında ise işlev noktaları ilerleyişin yönetilmesi ve raporlanması ayrıca kapsamın izlenmesinde kullanılabilir. Ek olarak projenin yaşama geçirilmesinden sonra tüm işlevselliğin ulaştırıldığının saptanmasında da faydalı olabilir. </li></ul>28/03/11
    57. 57. İşlev Noktaları (Function Points) <ul><li>Bu bilginin yakalanarak veritabanında tutulması ile ve diğer yazılım ölçümleri ile birleştirilerek gelecekteki projelerin kestirilmesi, kalite sınaması, yeni yöntemlerin, araçların, teknolojilerin tanıtılması açısından faydalı olabilir. </li></ul>28/03/11
    58. 58. İşlev Nokta Çözümlemesi için Uygulama Sınırı 28/03/11 Dış Girdiler Dış Çıktılar Dış Sorgular Uygulama Sınırı İç Mantıksal Dosyalar (ILF) Dış Girdiler Dış Çıktılar Dış Sorgular Dış Uygulama Dış Arayüz Dosyaları (EIF)
    59. 59. İşlev Nokta Çözümlemesi <ul><li>Yukarıdaki şekilde görüldüğü gibi işlev nokta çözümlemesi 5 veri ve işlem ölçümüne dayanır.Bunlar; </li></ul><ul><li>1. İç Mantıksal Dosyalar (Internal Logical File, ILF) </li></ul><ul><li>2. Dış Arayüz Dosyaları (External Interface File, EIF) </li></ul><ul><li>3. Dış Girdiler (External Input, EI) </li></ul><ul><li>4. Dış Çıktılar (External Output, EO) </li></ul><ul><li>5. Dış Sorgular (External Inquiry, EQ) </li></ul>28/03/11
    60. 60. İşlev Nokta Çözümlemesi <ul><li>1 . İç Mantıksal Dosyalar (Internal Logical File, ILF) </li></ul><ul><li>Uygulama sınırları ile birlikte verilerin saklandığı mantıksal bir dosyadır. ILF’nin karmaşıklığı, veri elemanlarının sayısına göre az, orta ve yüksek olarak sınıflandırılır. </li></ul><ul><li>Veri elemanları müşterinin adı, numarası, adresi, telefon numarası vs.. olabilir. </li></ul>28/03/11
    61. 61. İşlev Nokta Çözümlemesi <ul><li>2. Dış Arayüz Dosyaları (External Interface File, EIF) </li></ul><ul><li>Dı ş arayüz dosyası, iç mantıksal dosyaya benzer.Bununla birlikte EIF başka bir uygulama sistemi tarafından kontrol edilen bir arayüz dosyasıdır. </li></ul><ul><li>EIF’nin karmaşıklığı, ILF’de kullanılan aynı ölçüt ile saptanır. </li></ul>28/03/11
    62. 62. İşlev Nokta Çözümlemesi <ul><li>3. Dış Girdiler (External Input, EI) </li></ul><ul><li>Dış girdiler, uygulamanın dışından uygulamanın sınırları içine doğru olan süreçlere ve işlenebilir verileri gösterir. </li></ul><ul><li>Veri genellikle uygulamaya içine eklenebilir,silinebilir veya güncellenebilir.En yaygın örnek kullanıcının bilgi girişi için kullandığı klavye ve faredir. </li></ul>28/03/11
    63. 63. İşlev Nokta Çözümlemesi <ul><li>4. Dış Çıktılar (External Output, EO) </li></ul><ul><li>Verinin uygulama sınırları içinden dışarı çıkmasına izin veren süreç veya işlemlerdir. </li></ul><ul><li>Dış çıktıların örnekleri raporları,doğrulama mesajları,hesaplanan toplam değerler, çizgeler, çizelgeleri içerir. </li></ul><ul><li>Veriler ekrana, yazıcıya veya diğer uygulamalara gidebilir. </li></ul><ul><li>Dış çıktıların sayısı sayıldıktan sonra, karmaşıklıklarına göre derecelendirilirler. </li></ul>28/03/11
    64. 64. İşlev Nokta Çözümlemesi <ul><li>5. Dış Sorgular (External Inquiry, EQ) </li></ul><ul><li>Dış sorgular, elde edilen veri için iki yönlü iç dosyalardan dışarı veya dışarıdan uygulama içerisine girdilerin ve çıktıların birleşimini içeren bir süreç veya işlemdir. </li></ul><ul><li>Dış sorgular dosyada saklanan veriyi değiştirmez veya güncellemez. </li></ul><ul><li>Sadece bilgiyi okurlar. </li></ul>28/03/11
    65. 65. Düzenlenmemiş İşlev Noktası (UAF) <ul><li>Tüm iç mantıksal dosyalar,dış arayüz dosyaları,dış girdiler, dış çıktılar ve dış sorgular sayıldıktan sonra ve karmaşıklıkları oranlandırıldıktan sonra Düzeltilmemiş İşlev Noktası (Unadjusted Function Point, UAF) sayısı saptanır. </li></ul><ul><li>Örneğin; bir uygulama sisteminin gözden geçirildikten sonra aşağıdaki değerler saptanmıştır. </li></ul><ul><li>ILF : 3 Basit, 2 Orta, 1 Karmaşık </li></ul><ul><li>EIF : 2 Orta </li></ul><ul><li>EI : 3 Basit, 5 Orta, 4 Karmaşık </li></ul><ul><li>EO : 4 Basit, 2 Orta, 1 Karmaşık </li></ul><ul><li>EQ : 2 Basit, 5 Orta, 3 Karmaşık </li></ul>28/03/11
    66. 66. UAF’nin Hesaplanması <ul><li>Karmaşıklık____ </li></ul><ul><li>Düşük Orta Yüksek Toplam </li></ul><ul><li>İç Mantıksal Dosyalar(ILF) 3 x7=21 2 x10=20 1 x15=15 56 </li></ul><ul><li>Dış Arayüz Dosyaları(EIF) _ x5=_ 2 x7=14 _ x10=_ 14 </li></ul><ul><li>Dış Girdiler(EI) 3 x3=9 5 x4=20 4 x6=24 53 </li></ul><ul><li>Dış Çıktılar(EO) 4 x4=16 2 x5=10 1 x7=7 33 </li></ul><ul><li>Dış Sorgular(EQ) 2 x3=6 5 x4=20 3 x6=18 44 </li></ul><ul><li>___________________________________________________ </li></ul><ul><li>Toplam Düzeltilmemiş Noktalar 200 </li></ul>28/03/11 UAF = İç Mantıksal Dosyalar x K(1) + Dış Arayüz Dosyaları x K(2) + Dış Girdiler x K(3) + Dış Çıktılar x K(4) + Dış Sorgular x K(5)
    67. 67. Yazılım Büyüklük Kestirimi 28/03/11 İşlev Noktası Kod Satır Sayısı İç Mantıksal Dosyalar Dış Arayüz Dosyaları Dış Girdiler Dış Çıktılar Dış Sorgular Ağırlıklandırma katsayıları ile veya Teknik Düzenleme Etkenleri (TDI) kullanılır. LOC’a çevirmek için programlama diline göre saptanan etkenler kullanılır. <ul><ul><li>Kullanıcının gereksinimleri doğrultusunda geliştirme sürecinin başlarında kolay bir şekilde hesaplanabilir. </li></ul></ul><ul><ul><li>Geliştirme dilinden bağımsızdır. Genelde ilk aşamalarda işlev noktaları çözümlemesi kullanılıp daha sonra SLOC’a geçilir. </li></ul></ul>
    68. 68. Teknik Ayarlama Etkenleri (Technical Adjustment Factors) <ul><li>1. Sistem güvenilir yedekleme ve kurtarma gerektiriyor mu?(Reliable backup and </li></ul><ul><li>recovery) </li></ul><ul><li>2. Veri iletişimi gerekiyor mu? (Data communications) </li></ul><ul><li>3. Dağıtık fonksiyon var mı? (Distributed data processing) </li></ul><ul><li>4. Başarım kritik mi? (Performance) </li></ul><ul><li>5. Sistem çok kullanılan bir işletim ortamında mı çalışacak? </li></ul><ul><li>6. Sistem çevrimiçi veri girişi gerektiriyor mu? (On-line data entry) </li></ul><ul><li>7. Çevrimiçi veri girişi, giriş işlemlerinin birden fazla ekran ya da işlem üzerinden </li></ul><ul><li>olmasını mı gerektiriyor? (Multiple screens or operations) </li></ul><ul><li>8. Ana dosyalar çevrimiçi mi güncelleniyor? (On-line updating) </li></ul><ul><li>9. Girdiler, çıktılar, dosyalar ve sorgular karmaşık mı? </li></ul><ul><li>10. Kod yeniden kullanılabilir olarak mı tasarlanmış? </li></ul><ul><li>11. İç süreç karmaşık mı? (Complex processing) </li></ul><ul><li>12. Dönüşüm ve kurulum tasarım içerisinde mi? </li></ul><ul><li>13. Uygulama değişik kuruluşlarda birden fazla kurulum gerektirecek şekilde mi </li></ul><ul><li>tasarlanmış? </li></ul><ul><li>14. Uygulama kullanıcı tarafından kolaylıkla kullanmayı ve değiştirmek üzere mi </li></ul><ul><li>tasarlanmış? </li></ul>28/03/11
    69. 69. Teknik Ayarlama Etkenleri (Technical Adjustment Factors) 28/03/11 TDI =  i=1.. 14 Cevap i 0 = Hiç yok ya da Etkisiz 1 = Önemsiz Etki 2 = Az Etkili 3 = Orta Düzeyde Etkili 4 = Önemli Düzeyde Etkili 5 = Güçlü Etki Her bir Genel Sistem Karakteristiği için 0’dan 5’e kadar kullanılan ölçek (TDI = Toplam Etki Derecesi) VAF = (TDI x 0,01) + 0,65 (VAF = Değer Düzenleme Etkeni) FP = UAF x VAF (UAF = Düzenlenmemiş Toplam İşlev Noktaları) (FP = Toplam Düzenlenen İşlev Noktaları)
    70. 70. Genel Sistem Karakteristiği <ul><li>Genel Sistem Karakteristiği Etkinin Derecesi </li></ul><ul><li>Veri İletişimi 3 </li></ul><ul><li>Dağıtık Veri İşleme 2 </li></ul><ul><li>Başarım 4 </li></ul><ul><li>Çok Kullanılan Bir İşletim Ortamı 3 </li></ul><ul><li>İşlem Oranı 3 </li></ul><ul><li>Çevrimiçi Veri Girişi 4 </li></ul><ul><li>Uç Kullanıcı Verimliliği 4 </li></ul><ul><li>Çevrimiçi Güncelleme 3 </li></ul><ul><li>Karmaşık İşlemler 3 </li></ul><ul><li>Yeniden Kullanılabilirlik 2 </li></ul><ul><li>Kurulum Kolaylığı 3 </li></ul><ul><li>İşlemsel Kolaylık 3 </li></ul><ul><li>Birden Fazla Kurulum 1 </li></ul><ul><li>Uygulamanın Değiştirilebilirliği 2 </li></ul><ul><li>Toplam etki derecesi (TDI) 40 </li></ul>28/03/11
    71. 71. Hesaplamalar <ul><li>VAF (Değer Düzenleme Etkeni) </li></ul><ul><li>VAF = (TDI x 0,01) + 0,65 formülü ile hesaplanır. </li></ul><ul><li>VAF = (40 x 0,01) + 0,65 = 1,05 bulunur. </li></ul><ul><li>Buradan FP’yi yani toplam düzenlenmiş işlev noktalarını bulmak için; </li></ul><ul><li>FP = UAF x VAF formülü kullanılır. </li></ul><ul><li>FP = 200 x 1,05 = 210 bulunur. </li></ul>28/03/11
    72. 72. Yaklaşımlar <ul><li>Örneğe devam edersek uygulamayı gözden geçirdikten sonra, gösterilen etki dereceleri toplamda 210 düzenlenmiş işlev noktası üretmek için düzenlenmiştir. </li></ul><ul><li>Peki toplam düzenlenmiş işlev nokta sayısı ile neler yapabiliriz? </li></ul><ul><li>Öncelikle toplam düzenlenmiş işlev nokta sayısı hesaplanır,işlev nokta sayısı geliştirme kestirimlerine dönüştürülür. </li></ul><ul><li>İlk yaklaşım verimlilik üzerine yoğunlaşır.Örneğin programcı bir kişiye bir ay,bir hafta, bir gün gibi belirlenmiş bir sürede işlev noktasının kesin sayısını üretebilir. </li></ul>28/03/11
    73. 73. Yaklaşımlar <ul><li>Sonra, işlev noktası bilgi havuzu oluşturulması ve diğer ölçümler kuruluşa çeşitli projeleri karşılaştırma ve daha gerçekçi kestirimleri desteklemesine izin verir. </li></ul><ul><li>İkinci yaklaşım işlev nokta sayısını koddaki satır sayısına eşdeğer duruma getirme üzerine odaklanır. </li></ul><ul><li>Örnek verecek olursak; farklı programlama dilleri için kaç satırdan oluşan kod parçasına ihtiyaç olacağını saptayabiliriz. </li></ul><ul><li>Aşağıdaki şekilde bazı popüler programlama dillerinin her bir işlev noktası için gereken kod satır sayısı yaklaşık olarak gösterilmiştir. </li></ul>28/03/11
    74. 74. İşlev Noktasından LOC’a Çevrim <ul><li>210 İşlev Noktasına Sahip </li></ul><ul><li>Her bir İşlev Noktasına Karşılık Bir Uygulama İçin Ortalama </li></ul><ul><li>Dil Ortalama Kaynak Kod Satır Sayısı Kaynak Kod Satır Sayısı </li></ul><ul><li>Access 38 (210 x 38) = 7980 </li></ul><ul><li>Basic 107 22470 </li></ul><ul><li>C 128 26880 </li></ul><ul><li>C++ 53 11130 </li></ul><ul><li>Cobol 107 22470 </li></ul><ul><li>Delphi 29 6090 </li></ul><ul><li>Java 53 11130 </li></ul><ul><li>Makine Dili 640 134440 </li></ul><ul><li>Visual Basic 5 29 6090 </li></ul>28/03/11 LOC = (İşlev Noktaları Sayısı) x (Programlama Dili LOC Katsayısı)
    75. 75. İşlev Noktasından LOC’a Çevrim <ul><li>Görüldüğü gibi kodu satır sayısı programlama dillerine bağlıdır. </li></ul><ul><li>Toplamda 210 düzenlenmemiş işlev noktaları gerektiren bir uygulama veya modül eğer makine dili ile programlanmışsa 134440 kod satırına gerek varken Visual Basic 5’de bu değer 6090 kod satırıdır. </li></ul><ul><li>Bu kestirimler uygulamanın sadece büyüklüğünü değil aynı zamanda uygulamanın karmaşıklığını da kestirir. </li></ul><ul><li>Buna ek olarak T.Capers Jones çok kapsamlı bir araştırma sonucunda backfiring (patlama) denen bir teknik buldu ki bu teknik uygulama kaynak kodunu doğrudan eşdeğer işlev nokta sayısına çevirir. </li></ul><ul><li>Bireysel programlama teknikleri, LOC sayısında çeşitliliğe neden olabilir.Bu yüzden bu tekniğin doğruluğu çok yüksek değildir. </li></ul>28/03/11
    76. 76. COCOMO (Yapısal Maliyet Modeli) <ul><li>Yapısal Maliyet Modeli, (COnstructive COst MOdel) baş harflerinin bir araya gelmesi ile COCOMO adını almıştır. </li></ul><ul><li>İlk olarak 1981 yılında Barry Boehm tarafından, Yazılım Mühendisliği Ekonomisi kitabında tanıtılmıştır. </li></ul><ul><li>Zamanın,çabanın ve maliyetin kestirilmesinde kullanılır.(Boehm,1981) </li></ul><ul><li>Orijinal COCOMO modeli yaygın bir merak konusu uyandırdı. </li></ul><ul><li>Herkese açık bir modeldir. Bunun anlamı denklemlerin,varsayımların,tanımların herkese açık olmasıdır. </li></ul><ul><li>Orijinal COCOMO modeli 63 proje çalışmasına ve kestirme modelleri sıradüzeni temellerine dayanır. </li></ul>28/03/11
    77. 77. COCOMO (Yapısal Maliyet Modeli) <ul><li>COCOMO bir parametrik model örneğidir. Çünkü maliyet veya süre gibi bağımlı değişkenler kullanır. </li></ul><ul><li>COCOMO ile kestirim süreci, projenin tipinin saptanması ile başlar. </li></ul><ul><li>Proje tipleri şu şekilde sınıflandırılabilirler; </li></ul><ul><li>Organik: Teknolojinin,süreçlerin,insanların tümünün hep beraber sorunsuz bir şekilde çalışılması beklenen alışagelmiş projelerdir. </li></ul><ul><li>Gömülü: Bir gömülü proje, uğraştırıcı bir proje olarak görünür.Bu, yeni bir iş sürecini destekleyen bir sistem olabilir.İnsanlar daha az deneyimli ve süreçler ile teknoloji yeterince olgunlaşmamış olabilir. </li></ul><ul><li>Yarı-Ayrık: Organik projeler kolay, gömülü projeler zor ve uğraştırıcı olarak değerlendirilirse yarı-ayrık projeler bunların ortasında bir yerdedirler. Bu projeler kolay olmayabilir fakat kuruluş insanların,teknolojinin ve süreçlerin beklentileri karşılayacağına inanır. </li></ul>28/03/11
    78. 78. Buluşsal Yöntemler,Sezgiler <ul><li>Buluşsal yöntemler pratik zeka ürünü kurallardır. (Rules of thumb) </li></ul><ul><li>Sezgisel Yaklaşımlar karakteristik bir yazılım geliştirme projesi için gerekli olacak aynı temel etkinliklerdir. </li></ul><ul><li>Bu etkinlikler tüm çabanın kestirilebilir bir yüzdesini gerektirecektir.(Roetzheim ve Beasley,1998) </li></ul><ul><li>Örneğin bir yazılım geliştirme görevi için zaman kestirilirken önceki projelere göre toplam çabayı oluşturan yüzde şu şekilde olabilir; </li></ul><ul><li>- %30 Planlama </li></ul><ul><li>- %20 Kodlama </li></ul><ul><li>- %25 Bileşen Testi </li></ul><ul><li>- %25 Sistem Testi </li></ul>28/03/11

    ×