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

Ebat: px
Şu sayfadan göstermeyi başlat:

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

Transkript

1 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

2 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 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

3 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 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

4 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ı P P P 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

5 ö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 : ( /24) = TRL / ay (kişi başına) Bilgisayar Programının Satırı Maliyeti : ( /24000) = TRL Hata Oranı : (24/24000) = Hata / Satır = 1 Hata/ 1000 Satır Bozunma Oranı: (12/24000) = 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

6 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 Turbo Pascal Fortran gcc g fp İş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

7 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? Veri haberleşmesinin önemi nedir? Gerçek zamanlı veriler kullanılacak mı? Dağıtık işlem ve süreçler var mı? Çoklu kullanıcı desteği var mı? İşletim sistemi servis desteği var mı? Kullanıcı arabirimleri tek/çoklu? Veri depolama aygıtları dağıtık mı? Program kodları yeniden kullanılır mı? 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 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

8 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 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

9 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 İş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

10 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

11 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

12 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

13 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 /V) 3 x (1/t 4 ) Burada Y, özel yetenekler katsayısıdır, küçük projeler için (KLOC = ) 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 ve iş bilgi sistemleri için 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

14 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 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

15 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 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

16 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ı 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 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

17 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ı 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ışı Personel Riskleri Kalifiye elemanların olmaması Gerekli kabiliyetlerin toplanmaması Yeterli sayıda personel olmaması 17

18 Personelin proje süresince adanmaması Yarı zamanlı personel bulunması Proje hakkında doğru beklentilerin oluşmaması Gerekli eğitimin eksik olması Ü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 İş 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

19 Geç veya hatalı ürün yüzünden oluşacak maliyet artışı 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

20 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 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

21 4. Bir arada risklerin referans düzeyine olan etkisini irdelemek Planlama Yazılım proje yönetiminde en önemli unsur projenin zamanında yetişmesidir. Mühendisliklerde eski bir kural geçerlidir: 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: 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 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

22 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 Proje Planı 22

23 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

24 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

25 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

ENM424 Endüstride Bilgisayar Uygulamaları Ders Notları

ENM424 Endüstride Bilgisayar Uygulamaları Ders Notları Çukurova Üniversitesi Mühendislik Mimarlık Fakültesi Endüstri Mühendisliği Bölümü ENM424 Endüstride Bilgisayar Uygulamaları Ders Notları Öğr. Gör. İrfan MACİT Adana,2006 Bölüm 1 Yazılım Mühendisliği ve

Detaylı

SİSTEM VE YAZILIM. o Bilgisayar sistemleri donanım, yazılım ve bunları işletmek üzere gerekli işlemlerden oluşur.

SİSTEM VE YAZILIM. o Bilgisayar sistemleri donanım, yazılım ve bunları işletmek üzere gerekli işlemlerden oluşur. SİSTEM VE YAZILIM o Bilgisayar sistemleri donanım, yazılım ve bunları işletmek üzere gerekli işlemlerden oluşur. o Yazılım, bilgisayar sistemlerinin bir bileşeni olarak ele alınmalıdır. o Yazılım yalnızca

Detaylı

FMEA. Hata Türleri ve Etkileri Analizi

FMEA. Hata Türleri ve Etkileri Analizi FMEA Hata Türleri ve Etkileri Analizi 2007 FMEA Tanımı FMEA (HTEA), bir ürün veya prosesin potansiyel hatalarını ve bunların sonucu olabilecek etkilerini tanımlama, değerlendirme, potansiyel hatanın ortaya

Detaylı

1.Yazılım Geliştirme Metotları 1

1.Yazılım Geliştirme Metotları 1 1.Yazılım Geliştirme Metotları 1 1.1 Klasik Çevrim(Waterfall) 1.2 V Modeli 1.3 Prototipleme/Örnekleme 1.4 Spiral Model 1.5 Evrimsel Geliştirme 1.6 Evrimsel Prototipleme 1.7 Artımlı Geliştirme 1.8 Araştırmaya

Detaylı

KALİTE SİSTEM YÖNETİCİSİ EĞİTİMİ

KALİTE SİSTEM YÖNETİCİSİ EĞİTİMİ FMEA-HATA TÜRLERİ VE ETKİ ANALİZİ Tanımlama Mevcut veya olası hataları ortaya koyan, bu hataların yaratabileceği etkileri göz önünde bulunduran ve etkilerine göre hataları önceliklendirerek oluşmalarının

Detaylı

Yazılım Mühendisliği Bölüm - 3 Planlama. Cengiz GÖK

Yazılım Mühendisliği Bölüm - 3 Planlama. Cengiz GÖK Yazılım Mühendisliği Bölüm - 3 Planlama Cengiz GÖK 1 Planlama Yazılım geliştirme sürecinin ilk aşaması Başarılı bir proje geliştirebilmek için projenin tüm resminin çıkarılması işlemi Proje planlama aşamasında

Detaylı

Bilgisayarda Programlama. Temel Kavramlar

Bilgisayarda Programlama. Temel Kavramlar Bilgisayarda Programlama Temel Kavramlar KAVRAMLAR Programlama, yaşadığımız gerçek dünyadaki problemlere ilişkin çözümlerin bilgisayarın anlayabileceği bir biçime dönüştürülmesi / ifade edilmesidir. Bunu

Detaylı

SİSTEM ANALİZİ ve TASARIMI. ÖN İNCELEME ve FİZİBİLİTE

SİSTEM ANALİZİ ve TASARIMI. ÖN İNCELEME ve FİZİBİLİTE SİSTEM ANALİZİ ve TASARIMI ÖN İNCELEME ve FİZİBİLİTE Sistem Tasarım ve Analiz Aşamaları Ön İnceleme Fizibilite Sistem Analizi Sistem Tasarımı Sistem Gerçekleştirme Sistem Operasyon ve Destek ÖN İNCELEME

Detaylı

Sistem ve Yazılım Nedir?

Sistem ve Yazılım Nedir? Sistem ve Yazılım Nedir? Bilgisayar Sistemleri; donanım, yazılım ve kullanıcılardan oluşur. Yazılım sadece belirli bir işlemi yapan bir program değildir. Yazılım belirli bir mantık dahilinde insanlar tarafından

Detaylı

ÇEVRE BOYUTLARININ DEĞERLENDİRİLMESİ PROSEDÜRÜ

ÇEVRE BOYUTLARININ DEĞERLENDİRİLMESİ PROSEDÜRÜ SAYFA NO 1/7 1. AMAÇ VE KAPSAM: Bu prosedürün amacı, TOTM nin faaliyetlerinin ve hizmetlerinin çevre güvenliği üzerinde gerçek veya potansiyel olarak önemli etkileri olabilecek çevresel boyutlarının (yönlerinin),

Detaylı

İç denetim birimleri, risk değerlendirme çalışmalarına ilişkin hususları bu rehbere uygun olarak kendi iç denetim birim yönergelerinde düzenlerler.

İç denetim birimleri, risk değerlendirme çalışmalarına ilişkin hususları bu rehbere uygun olarak kendi iç denetim birim yönergelerinde düzenlerler. KAMU İÇ DENETİMİNDE RİSK DEĞERLENDİRME REHBERİ I. GİRİŞ Bu rehber, iç denetim birimlerince hazırlanacak risk değerlendirme çalışmalarının temel esaslarını belirlemek üzere, İç Denetçilerin Çalışma Usul

Detaylı

PERFORMANS YÖNETĐMĐ. Hedefe Odaklı Çalışma ve Yetkinlik Yönetimi.

PERFORMANS YÖNETĐMĐ. Hedefe Odaklı Çalışma ve Yetkinlik Yönetimi. PERFORMANS YÖNETĐMĐ Kurumların yapısına uygun performans yönetimi sistemini esnek yapı sayesinde Đnsan Kaynakları uygulaması içinde tanımlayarak takip edebilme Performans kayıtlarını yöneticilere e-posta

Detaylı

YAZILIM PROJESİ YÖNETİMİ

YAZILIM PROJESİ YÖNETİMİ YAZILIM PROJESİ YÖNETİMİ Yrd. Doç. Dr. Volkan TUNALI YZM 403 Maltepe Üniversitesi Mühendislik Fakültesi 5. BÖLÜM 2 RİSK YÖNETİMİ Genel Bakış 3 Giriş Risk ve Risk Yönetimi Nedir? Risk Kategorileri Risk

Detaylı

KAMU İÇ DENETİMİNDE RİSK DEĞERLENDİRME REHBERİ

KAMU İÇ DENETİMİNDE RİSK DEĞERLENDİRME REHBERİ KAMU İÇ DENETİMİNDE RİSK DEĞERLENDİRME REHBERİ I. GİRİŞ Bu rehber, iç denetim birimlerince hazırlanacak risk değerlendirme çalışmalarının temel esaslarını belirlemek üzere, İç Denetçilerin Çalışma Usul

Detaylı

5. PROGRAMLA DİLLERİ. 5.1 Giriş

5. PROGRAMLA DİLLERİ. 5.1 Giriş 5. PROGRAMLA DİLLERİ 8.1 Giriş 8.2 Yazılım Geliştirme Süreci 8.3 Yazılım Geliştirme Sürecinde Programlama Dilinin Önemi 8.4 Programlama Dillerinin Tarihçesi 8.5 Programlama Dillerinin Sınıflandırılması

Detaylı

BÖLÜM 4 İÇ KONTROL SİSTEMİ

BÖLÜM 4 İÇ KONTROL SİSTEMİ BÖLÜM 4 İÇ KONTROL SİSTEMİ Öğr. Gör. Mehmet KÖRPİ KONTROL KAVRAMI İşletmenin belirlenen amaçlarına ulaşması için, işletme yöneticilerinin almış olduğu önlemlere, uyguladığı yöntemlere kontrol usul ve yöntemleri

Detaylı

Sistem Geliştirme Yaşam Döngüsü (The Systems Development Life Cycle) (SDLC)

Sistem Geliştirme Yaşam Döngüsü (The Systems Development Life Cycle) (SDLC) Sistem Geliştirme Yaşam Döngüsü (The Systems Development Life Cycle) (SDLC) Sistem analistlerinin ve kullanıcı faaliyetlerinin spesifik döngüsünün kullanılmasıyla En iyi geliştirilmiş sistemin oluşmasını

Detaylı

PERFORMANS YÖNETİMİ Prof.Dr.Coşkun Can Aktan

PERFORMANS YÖNETİMİ Prof.Dr.Coşkun Can Aktan PERFORMANS YÖNETİMİ Prof.Dr.Coşkun Can Aktan Açık, ölçülebilir hedefler başarının göstergeleridir. Yüksek performanslı kuruluşlarda ölçüm bir yaşam biçimidir. Ve lider bu ölçümleri yüksek performanslı

Detaylı

CMMI. CMMI ve Çevik Yöntemler. Orhan KALAYCI Haziran 2007. Yazılım Süreç Kalitesi ve Yönetim Danışmanlığı. www.nitelik.

CMMI. CMMI ve Çevik Yöntemler. Orhan KALAYCI Haziran 2007. Yazılım Süreç Kalitesi ve Yönetim Danışmanlığı. www.nitelik. CMMI ve Çevik Yöntemler Orhan KALAYCI Haziran 2007 http:// CMMI 2 1 XP 3 CMMI nedir? 1. Seviye 2. Seviye 3. Seviye 4 2 XP Nedir? MSF XP Şelale RUP 5 CMM XP İlişkisi 6 3 PROJE YONETİMİNİ İMİNİN EVRİMSEL

Detaylı

EĞİTİM KURUMLARINDA PERFORMANS YÖNETİMİ VE ÖLÇÜMÜ Kemal Pehlivanoğlu Genel Müdür - İNKA Eğitim ve Danışmanlık A.Ş kpehlivanoglu@inkadanismanlik.com.

EĞİTİM KURUMLARINDA PERFORMANS YÖNETİMİ VE ÖLÇÜMÜ Kemal Pehlivanoğlu Genel Müdür - İNKA Eğitim ve Danışmanlık A.Ş kpehlivanoglu@inkadanismanlik.com. EĞİTİM KURUMLARINDA PERFORMANS YÖNETİMİ VE ÖLÇÜMÜ Kemal Pehlivanoğlu Genel Müdür - İNKA Eğitim ve Danışmanlık A.Ş kpehlivanoglu@inkadanismanlik.com.tr Performans yönetim sistemi, gerçekleştirilmesi beklenen

Detaylı

Arş.Gör.Muhammet Çağrı Gencer Bilgisayar Mühendisliği KTO Karatay Üniversitesi 2015

Arş.Gör.Muhammet Çağrı Gencer Bilgisayar Mühendisliği KTO Karatay Üniversitesi 2015 Arş.Gör.Muhammet Çağrı Gencer Bilgisayar Mühendisliği KTO Karatay Üniversitesi 2015 KONU BAŞLIKLARI 1. Yazılım Mimarisi nedir? 2. Yazılımda Karmaşıklık 3. Üç Katmanlı Mimari nedir? 4. Üç Katmanlı Mimari

Detaylı

SİSTEM ANALİZİ VE TASARIMI

SİSTEM ANALİZİ VE TASARIMI SİSTEM ANALİZİ VE TASARIMI BİLGİ SİSTEMİ GELİŞTİRME SÜRECİ Sistem Geliştirme Süreci ve Modelleri Sistem Geliştirme Yaşam Döngüsü Bilgi sistemlerinin geliştirilmesi için izlenen sürece Sistem Geliştirme

Detaylı

13 Aralık 2007. Đlgili Versiyon/lar : ETA:SQL, ETA:V.8-SQL. Đlgili Modül/ler : Raporlar. Kullanıcı Tanımlı Raporlar Bölümünden Yapabildiklerimiz

13 Aralık 2007. Đlgili Versiyon/lar : ETA:SQL, ETA:V.8-SQL. Đlgili Modül/ler : Raporlar. Kullanıcı Tanımlı Raporlar Bölümünden Yapabildiklerimiz 13 Aralık 2007 Đlgili Versiyon/lar : ETA:SQL, ETA:V.8-SQL Đlgili Modül/ler : Raporlar KULLANICI TANIMLI RAPORLAR Kullanıcı Tanımlı Raporlar Bölümünden Yapabildiklerimiz Kendi isteklerinize özel rapor tasarımları

Detaylı

VERİ TABANI SİSTEMLERİ

VERİ TABANI SİSTEMLERİ VERİ TABANI SİSTEMLERİ 1- Günümüzde bilgi sistemleri Teknoloji ve bilgi. 2- Bilgi sistemlerinin Geliştirilmesi İşlevsel Gereksinimleri 1.AŞAMA Gereksinim Belirleme ve Analiz Veri Gereksinimleri Gereksinimler

Detaylı

NAZİLLİ DEVLET HASTANESİ RİSK ANALİZİ PROSEDÜRÜ

NAZİLLİ DEVLET HASTANESİ RİSK ANALİZİ PROSEDÜRÜ Sayfa 1 / 6 1. AMAÇ 2. KAPSAM Nazilli Devlet Hastanesinde bölüm bazında risk değerlendirmeleri yaparak çalışanların çalıştıkları alanlardan kaynaklı risklerini belirlemek ve gerekli önlemlerin alınmasını

Detaylı

BLG4146 - Sistem Analizi ve Tasarımı. Öğr. Grv. Aybike ŞİMŞEK

BLG4146 - Sistem Analizi ve Tasarımı. Öğr. Grv. Aybike ŞİMŞEK BLG4146 - Sistem Analizi ve Tasarımı Öğr. Grv. Aybike ŞİMŞEK Tasarım Evresi Analiz evresinde sorulan NE sorusuyla elde edilen bilgilerin NASIL yapılacağı, NASIL gerçekleştirileceğinin ortaya konulduğu

Detaylı

BM208- Nesneye Dayalı Analiz ve Tasarım. Öğr. Grv. Aybike ŞİMŞEK

BM208- Nesneye Dayalı Analiz ve Tasarım. Öğr. Grv. Aybike ŞİMŞEK BM208- Nesneye Dayalı Analiz ve Tasarım Öğr. Grv. Aybike ŞİMŞEK Sistem Analizi ve Tasarımı Sistem analizi ve tasarımının aşağıdaki temel aşamalarla gerçekleştiği söylenebilir. Sistemin planlanması Sistemin

Detaylı

YAZILIM KAVRAMINA BİR BAKIŞ. Gürcan Banger Elektrik Yük. Müh. ESOGÜ - 9 Nisan 2007

YAZILIM KAVRAMINA BİR BAKIŞ. Gürcan Banger Elektrik Yük. Müh. ESOGÜ - 9 Nisan 2007 YAZILIM KAVRAMINA BİR BAKIŞ Gürcan Banger Elektrik Yük. Müh. ESOGÜ - 9 Nisan 2007 YAZILIM ve DONANIM Bilgisayar kavramı, donanım ve yazılım olmak üzere iki ana bileşenden oluşuyor. Elektronik, mekanik

Detaylı

Varlık davranış modeli: Bu aşama her entity ye etki eden durumların tanımlandığı, modellendiği ve dokümante edildiği süreçtir.

Varlık davranış modeli: Bu aşama her entity ye etki eden durumların tanımlandığı, modellendiği ve dokümante edildiği süreçtir. Yapısal Sistem Analiz ve Tasarım Metodu SSADM waterfall model baz alınarak uygulanan bir metottur. İngiltere de kamusal projelerde 1980 lerin başında kullanılan sistem analizi ve tasarımı konularındaki

Detaylı

BM-311 Bilgisayar Mimarisi. Hazırlayan: M.Ali Akcayol Gazi Üniversitesi Bilgisayar Mühendisliği Bölümü

BM-311 Bilgisayar Mimarisi. Hazırlayan: M.Ali Akcayol Gazi Üniversitesi Bilgisayar Mühendisliği Bölümü BM-311 Bilgisayar Mimarisi Hazırlayan: M.Ali Akcayol Gazi Üniversitesi Bilgisayar Mühendisliği Bölümü Konular Bilgisayar Bileşenleri Bilgisayarın Fonksiyonu Instruction Cycle Kesmeler (Interrupt lar) Bus

Detaylı

LKS2. Kredi Kartı Uygulamaları

LKS2. Kredi Kartı Uygulamaları LKS2 Kredi Kartı Uygulamaları LOGO Kasım 2006 İçindekiler LKS2 Kredi Kartı Uygulamalarında kullanılan parametreler... 3 Banka Hesabı Kayıt Türleri... 3 Geri Ödeme Planları... 4 Geri Ödeme Plan Bilgileri...

Detaylı

Yaşanmış Tecrübe Paylaşımı Önce Test Et Sonra Kodla XP Pratiği

Yaşanmış Tecrübe Paylaşımı Önce Test Et Sonra Kodla XP Pratiği TBD 21. Ulusal Bilişim Kurultayı Sunumu Yaşanmış Tecrübe Paylaşımı Önce Test Et Sonra Kodla XP Pratiği Hasan ÖZKESER Bimar Bilgi İşlem Hizmetleri Aş. 5 Ekim 2004 ODTÜ Kültür ve Kongre Merkezi, Ankara 2004

Detaylı

TOPLAM KALİTE YÖNETİMİ

TOPLAM KALİTE YÖNETİMİ SAKARYA ÜNİVERSİTESİ TOPLAM KALİTE YÖNETİMİ Hafta 13 Yrd. Doç. Dr. Semra BORAN Bu ders içeriğinin basım, yayım ve satış hakları Sakarya Üniversitesi ne aittir. "Uzaktan Öğretim" tekniğine uygun olarak

Detaylı

BÖLÜM12. 2- FORMÜLLER ve OTOMATİK TOPLAM. 2.1. Formüller

BÖLÜM12. 2- FORMÜLLER ve OTOMATİK TOPLAM. 2.1. Formüller BÖLÜM12 2- FORMÜLLER ve OTOMATİK TOPLAM 2.1. Formüller Formül, bir sayfadaki verilerin aritmetiksel, mantıksal, istatistiksel vb. işlemleri yapması için kullanılan denklemlerdir ve bize sonuç bildirirler.

Detaylı

Veri Toplama Teknikleri

Veri Toplama Teknikleri A. Gözlem Yoluyla Veri Toplama Teknikleri B. Soruşturma Yoluyla Nicel Veri Toplama Teknikleri Yazılı Soruşturma Tekniği Anket, Başarı Testi Yapılandırılmış Gözlem Önceden hazırlanmış göstergeler ve semboller

Detaylı

Yazılım Çeşitleri. Uygulama Yazılımları. İşletim Sistemleri. Donanım

Yazılım Çeşitleri. Uygulama Yazılımları. İşletim Sistemleri. Donanım Yazılım Yazılım Bilgisayarlar üretildikleri anda içlerinde herhangi bir bilgi barındırmadıkları için bir işlevleri yoktur. Bilgisayarlara belirli yazılımlar yüklenerek işlem yapabilecek hale getirilirler.

Detaylı

HATAY SAĞLIK MÜDÜRLÜĞÜ HATAY SAĞLIK MÜDÜRLÜĞÜ RİSK DEĞERLENDİRME PROSEDÜRÜ

HATAY SAĞLIK MÜDÜRLÜĞÜ HATAY SAĞLIK MÜDÜRLÜĞÜ RİSK DEĞERLENDİRME PROSEDÜRÜ RİSK DEĞERLENDİRME PROSEDÜRÜ.AMAÇ Bu prosedürün, Hatay İl Sağlık Müdürlüğü, İl Ambulans Servisi Başhekimliği, İlçe Sağlık Müdürlükleri bünyesinde faaliyetleri sırasında oluşabilecek potansiyel tehlikelerin

Detaylı

DENEY 1 Basit Elektrik Devreleri

DENEY 1 Basit Elektrik Devreleri ULUDAĞ ÜNİVESİTESİ MÜHENDİSLİK FAKÜLTESİ ELEKTİK-ELEKTONİK MÜHENDİSLİĞİ BÖLÜMÜ EEM203 Elektrik Devreleri Laboratuarı I 204-205 DENEY Basit Elektrik Devreleri Deneyi Yapanın Değerlendirme Adı Soyadı : Deney

Detaylı

Sistem Programlama. Kesmeler(Interrupts): Kesme mikro işlemcinin üzerinde çalıştığı koda ara vererek başka bir kodu çalıştırması işlemidir.

Sistem Programlama. Kesmeler(Interrupts): Kesme mikro işlemcinin üzerinde çalıştığı koda ara vererek başka bir kodu çalıştırması işlemidir. Kesmeler(Interrupts): Kesme mikro işlemcinin üzerinde çalıştığı koda ara vererek başka bir kodu çalıştırması işlemidir. Kesmeler çağırılma kaynaklarına göre 3 kısma ayrılırlar: Yazılım kesmeleri Donanım

Detaylı

28.06.2012 tarihli Bankaların İç Sistemleri Hakkında Yönetmelik in Risk Yönetimine İlişkin Düzenlemeleri

28.06.2012 tarihli Bankaların İç Sistemleri Hakkında Yönetmelik in Risk Yönetimine İlişkin Düzenlemeleri 28.06.2012 tarihli Bankaların İç Sistemleri Hakkında Yönetmelik in Risk Yönetimine İlişkin Düzenlemeleri Yönetici Özeti: 28.06.2012 tarihinde yayımlanan Bankaların İç Sistemleri Hakkında Yönetmelik ile

Detaylı

Doküman No Revizyon No Yayın Tarihi Sayfa No PROSES FMEA TALİMATI

Doküman No Revizyon No Yayın Tarihi Sayfa No PROSES FMEA TALİMATI 1.0 AMAÇ VE KAPSAM Bu talimatın amacı; ürün veya proseste karşılaşabilecek potansiyel hataları ve bunların neden olabileceği sonuçları önceden analiz ederek, gerekli önlemlerin alınması için kullanılan

Detaylı

Merkezi Eğilim ve Dağılım Ölçüleri

Merkezi Eğilim ve Dağılım Ölçüleri Merkezi Eğilim ve Dağılım Ölçüleri Soru Öğrencilerin derse katılım düzeylerini ölçmek amacıyla geliştirilen 16 soruluk bir test için öğrencilerin ilk 8 ve son 8 soruluk yarılardan aldıkları puanlar arasındaki

Detaylı

DOKÜMANLARIN KONTROLÜ PROSEDÜRÜ Doküman No: Yürürlük Tarihi: Revizyon Tarih/No:

DOKÜMANLARIN KONTROLÜ PROSEDÜRÜ Doküman No: Yürürlük Tarihi: Revizyon Tarih/No: 1. AMAÇ Bu prosedürün amacı, İç Kontrol Sistemi içinde bulunan tüm dokümanların hazırlanması, onaylanması, yayını, sürdürülmesi, güncelleştirilmesi ve dağıtım esasları için yöntem ve sorumlulukları belirlemektir.

Detaylı

TURKCELL HİZMETLERİ. Kullanım Bilgileri. LOGO Kasım 2014

TURKCELL HİZMETLERİ. Kullanım Bilgileri. LOGO Kasım 2014 TURKCELL HİZMETLERİ Kullanım Bilgileri LOGO Kasım 2014 İçindekiler TURKCELL HİZMETLERİ... 3 Online Turkcell Fatura Aktarımı... 4 Fatura Eşleştirme Tabloları... 5 Online Fatura Aktarımları... 6 Toplu Mesaj

Detaylı

RİSK ANALİZ PROSEDÜRÜ

RİSK ANALİZ PROSEDÜRÜ 1.AMAÇ Karacabey Devlet Hastanesi faaliyetleri sırasında oluşabilecek potansiyel tehlikelerin ve bunlara ilişkin risklerin belirlenmesi, böylelikle beklenen veya olası risklerin kontrol altına alınmasına

Detaylı

Bilgi Güvenliği Risk Değerlendirme Yaklaşımları www.sisbel.biz

Bilgi Güvenliği Risk Değerlendirme Yaklaşımları www.sisbel.biz ISO/IEC 20000-1 BİLGİ TEKNOLOJİSİ - HİZMET YÖNETİMİ BAŞ DENETÇİ EĞİTİMİ Bilgi Güvenliği Risk Değerlendirme Yaklaşımları E1-yüksek seviye bilgi güvenliği risk değerlendirmesi Yüksek seviye değerlendirme,

Detaylı

Süreç Yönetimi. Logo

Süreç Yönetimi. Logo Süreç Yönetimi Logo Kasım 2013 SÜREÇ YÖNETİMİ Süreç belirlenen bir amaca ulaşmak için gerçekleştirilen faaliyetler bütünüdür. Örn; Sistemde kayıtlı personellerinize doğum günü kutlama maili gönderme, Deneme

Detaylı

Onaylayan: Gen. Müdür Tarih: 28/9/2009 Versiyon: 1

Onaylayan: Gen. Müdür Tarih: 28/9/2009 Versiyon: 1 Tarih: 28/9/2009 DOKÜMANTE EDİLMİŞ KALİTE PROSEDÜRLERİ Belgelerin kontrolü Bu prosedürün amacı, kalite yönetim sisteminde yer alan tüm belge ve verilerin geliştirme, inceleme, onay ve dağıtım işlemleriyle

Detaylı

END3061 SİSTEM ANALİZİ VE MÜHENDİSLİĞİ

END3061 SİSTEM ANALİZİ VE MÜHENDİSLİĞİ END3061 SİSTEM STEM ANALİZİ VE MÜHENDİSLİĞİ BİLİŞİM M SİSTEMLERS STEMLERİ GİRİŞİŞ Bir sistem analizcisinin ana misyonu, kullanıcıların fiziksel gereksinimlerini açımlamak ve bunları yazılıma dönüştürmektir.

Detaylı

Sistem Analizi ve. Tasarımı. Mustafa COŞAR

Sistem Analizi ve. Tasarımı. Mustafa COŞAR Sistem Analizi ve 1 Tasarımı 2013 Mustafa COŞAR Sunum Planı Genel Kavramlar 2 Sistem Genel Sistem Teorisi Sistemin Öğeleri Bilgi Sistemleri Sistem Analizi Sistem Geliştirme Hayat Döngüsü Sistem Analizi

Detaylı

STRATEJİK YÖNETİM VE YÖNETİMİN GÖZDEN GEÇİRMESİ PROSEDÜRÜ

STRATEJİK YÖNETİM VE YÖNETİMİN GÖZDEN GEÇİRMESİ PROSEDÜRÜ Sayfa 1/5 Revizyon Takip Tablosu REVİZYON NO TARİH AÇIKLAMA 00 01.03.2012 İlk Yayın 1. AMAÇ Bu prosedürün amacı, YTÜ nde KYS politika ve hedeflerinin belirlenmesi ve üniversite içerisinde yayılımı ilgili

Detaylı

EKLER EK 12UY0106-5/A4-1:

EKLER EK 12UY0106-5/A4-1: Yayın Tarihi: 26/12/2012 Rev. :01 EKLER EK 12UY0106-5/A4-1: nin Kazandırılması için Tavsiye Edilen Eğitime İlişkin Bilgiler Bu birimin kazandırılması için aşağıda tanımlanan içeriğe sahip bir eğitim programının

Detaylı

GİRİŞ. A. İç Kontrolün Tanımı, Özellikleri ve Genel Esasları:

GİRİŞ. A. İç Kontrolün Tanımı, Özellikleri ve Genel Esasları: GİRİŞ 5018 sayılı Kamu Mali Yönetimi ve Kontrol Kanunu ile kamu da mali yönetim ve kontrol sisteminin bütünüyle değiştirilerek, uluslararası standartlara ve Avrupa Birliği Normlarına uygun hale getirilmesi

Detaylı

DERS BİLGİ FORMU. IV Türkçe Zorunlu Ders. Haftalık. Ders. Okul Eğitimi Süresi. Saati

DERS BİLGİ FORMU. IV Türkçe Zorunlu Ders. Haftalık. Ders. Okul Eğitimi Süresi. Saati DERS BİLGİ FORMU DERSİN ADI SİSTEM ANALİZİ VE TASARIMI I BÖLÜM PROGRAM DÖNEMİ DERSİN DİLİ DERS KATEGORİSİ ÖN ŞARTLAR SÜRE VE DAĞILIMI KREDİ DERSİN AMACI ÖĞRENME ÇIKTILARI VE YETERLİKLER DERSİN İÇERİĞİ

Detaylı

YAZILIM PROJE YÖNETİMİ. Yrd.Doç.Dr.Hacer KARACAN

YAZILIM PROJE YÖNETİMİ. Yrd.Doç.Dr.Hacer KARACAN YAZILIM PROJE YÖNETİMİ Yrd.Doç.Dr.Hacer KARACAN İçerik Projenin Planlanması Proje Bütçesinin Oluşturulması Yazılım Boyut Kestirimi Maliyet Çıkarımı Proje Bütçesinin Oluşturulması Proje takvimi oluşturulduktan

Detaylı

İŞLETİM SİSTEMLERİNE GİRİŞ. Modern bilgisayar çalışma prensipleri, Von Neumann ın 1945 de geliştirdiği

İŞLETİM SİSTEMLERİNE GİRİŞ. Modern bilgisayar çalışma prensipleri, Von Neumann ın 1945 de geliştirdiği İŞLETİM SİSTEMLERİNE GİRİŞ Von Neumann Mimarisi Modern bilgisayar çalışma prensipleri, Von Neumann ın 1945 de geliştirdiği mimariyi temel almaktadır. Merkezi İşlem Birimi Aritmetik ve Mantık Birimi Kontrol

Detaylı

Kural Motoru. www.paperwork.com.tr

Kural Motoru. www.paperwork.com.tr Kural Motoru www.paperwork.com.tr İş Kuralı Örnekleri Aşağıda iş kurallarına çeşitli örnekler verilmiştir; : İş Kuralı Nedir? T üm işletmeler kural merkezli çalışırlar. Kurallar hangi fırsatların takip

Detaylı

Ücret Bütçe Simülasyonu

Ücret Bütçe Simülasyonu DESTEK DOKÜMANI Ürün Bölüm : Bordro Plus : Ücret Bütçe Simülasyonu Ücret Bütçe Simülasyonu İnsan Kaynakları Ücret Simülasyonu Genel bütçeye hazırlık için IK bölümlerinin ücret ve bordro maliyetlerini senaryolaştırabileceği

Detaylı

ÜNİT E ÜNİTE GİRİŞ. Algoritma Mantığı. Algoritma Özellikleri PROGRAMLAMA TEMELLERİ ÜNİTE 3 ALGORİTMA

ÜNİT E ÜNİTE GİRİŞ. Algoritma Mantığı. Algoritma Özellikleri PROGRAMLAMA TEMELLERİ ÜNİTE 3 ALGORİTMA PROGRAMLAMA TEMELLERİ ÜNİTE 3 ALGORİTMA GİRİŞ Bilgisayarların önemli bir kullanım amacı, veri ve bilgilerin kullanılarak var olan belirli bir problemin çözülmeye çalışılmasıdır. Bunun için, bilgisayarlar

Detaylı

PROGRAMLAMAYA GİRİŞ. Öğr. Gör. Ayhan KOÇ. Kaynak: Algoritma Geliştirme ve Programlamaya Giriş, Dr. Fahri VATANSEVER, Seçkin Yay.

PROGRAMLAMAYA GİRİŞ. Öğr. Gör. Ayhan KOÇ. Kaynak: Algoritma Geliştirme ve Programlamaya Giriş, Dr. Fahri VATANSEVER, Seçkin Yay. PROGRAMLAMAYA GİRİŞ Öğr. Gör. Ayhan KOÇ Kaynak: Algoritma Geliştirme ve Programlamaya Giriş, Dr. Fahri VATANSEVER, Seçkin Yay., 2007 Algoritma ve Programlamaya Giriş, Ebubekir YAŞAR, Murathan Yay., 2011

Detaylı

SPSS E GİRİŞ SPSS TE TEMEL İŞLEMLER. Abdullah Can

SPSS E GİRİŞ SPSS TE TEMEL İŞLEMLER. Abdullah Can SPSS E GİRİŞ SPSS TE TEMEL İŞLEMLER SPSS in üzerinde işlem yapılabilecek iki ana ekran görünümü vardır. DATA VIEW (VERİ görünümü) VARIABLE VIEW (DEĞİŞKEN görünümü) 1 DATA VIEW (VERİ görünümü) İstatistiksel

Detaylı

KALİTE YÖNETİM SİSTEMİ İş Sürekliliği

KALİTE YÖNETİM SİSTEMİ İş Sürekliliği T. C. KAMU İHALE KURUMU Elektronik İhale Dairesi KALİTE YÖNETİM SİSTEMİ İş Sürekliliği İş Sürekliliği Yönetim Sistemi Politikası Sürüm No: 5.0 Yayın Tarihi: 11.05.2014 444 0 545 2012 Kamu İhale Kurumu

Detaylı

VERİ KAYNAKLARI. Bilgi sisteminin öğelerinden biride veri

VERİ KAYNAKLARI. Bilgi sisteminin öğelerinden biride veri VERİ KAYNAKLARI YÖNETİMİ İ İ 5. ÜNİTE GİRİŞ Bilgi sisteminin öğelerinden biride veri yönetimidir. Geleneksel yada çağdaş, birinci yada ikinci elden derlenen veriler amaca uygun veri formlarında tutulur.

Detaylı

Kalite Geliştirmede İstatistiksel Yöntemler ve Six Sigma

Kalite Geliştirmede İstatistiksel Yöntemler ve Six Sigma Kalite Geliştirmede İstatistiksel Yöntemler ve Six Sigma - 1 Ödevler 5 er kişilik 7 grup Hayali bir şirket kurulacak Bu şirketin kalite kontrol süreçleri raporlanacak Kalite sistem dokümantasyonu oluşturulacak

Detaylı

Şekil 7.1 Bir tankta sıvı birikimi

Şekil 7.1 Bir tankta sıvı birikimi 6 7. DİFERENSİYEL DENKLEMLERİN SAYISAL ÇÖZÜMLERİ Diferensiyel denklemlerin sayısal integrasyonunda kullanılabilecek bir çok yöntem vardır. Tecrübeler dördüncü mertebe (Runge-Kutta) yönteminin hemen hemen

Detaylı

OLASI HATA TÜRÜ VE ETKİLERİ ANALİZİ (FMEA) Mehmet Enes İnce

OLASI HATA TÜRÜ VE ETKİLERİ ANALİZİ (FMEA) Mehmet Enes İnce 1.GİRİŞ Her sektörde arzın arttığı ve iletişim teknolojilerinin çok geliştiği günümüz ekonomisinde işletmeler, varlıklarını devam ettirebilmek için sadece ucuz mal ya da hizmet üretimini değil, hem ucuz

Detaylı

Ders Notlarının Creative Commons lisansı Feza BUZLUCA ya aittir. Lisans: http://creativecommons.org/licenses/by-nc-nd/3.0/

Ders Notlarının Creative Commons lisansı Feza BUZLUCA ya aittir. Lisans: http://creativecommons.org/licenses/by-nc-nd/3.0/ Eşzamanlı (Senkron) Ardışıl Devrelerin Tasarlanması (Design) Bir ardışıl devrenin tasarlanması, çözülecek olan problemin sözle anlatımıyla (senaryo) başlar. Bundan sonra aşağıda açıklanan aşamalardan geçilerek

Detaylı

GGYS TEHLİKE ANALİZİ VE RİSK DEĞERLENDİRME PROSEDÜRÜ

GGYS TEHLİKE ANALİZİ VE RİSK DEĞERLENDİRME PROSEDÜRÜ 1. AMAÇ V KAPSAM: Gıda Güvenliği Yönetim Sisteminin uygulama alanı içinde oluşması muhtemel bütün olası tehlikelerin, Gıda Güvenliği ile ilgili sonuçlarına ve oluşma olasılıklarına göre tanımlanması ve

Detaylı

KATEGORİ MİZANI BAŞLARKEN KATEGORİ NEDİR? NEDEN N İHTİYAÇ DUYULUR?

KATEGORİ MİZANI BAŞLARKEN KATEGORİ NEDİR? NEDEN N İHTİYAÇ DUYULUR? KATEGORİ MİZANI Doküman Kodu : RNT-02 Açıklama : Vio Kategori Mizanı Kullanımı Kapsam : Vio Nitelikleri Revizyon No : 2 Yayın Tarihi : Aralık 2012 BAŞLARKEN SKOR YAZILIM tarafından geliştirilen ticari

Detaylı

25.10.2011. Arayüz Nedir? Arayüz Çeşitleri Arayüz Tasarım Yöntemleri Arayüz Tasarım Hataları. Ömer Faruk MIZIKACI 2008639402

25.10.2011. Arayüz Nedir? Arayüz Çeşitleri Arayüz Tasarım Yöntemleri Arayüz Tasarım Hataları. Ömer Faruk MIZIKACI 2008639402 Arayüz Tasarımı ve Programlama Neleri Konuşacağız Arayüz Nedir? Arayüz Çeşitleri Arayüz Tasarım Yöntemleri Arayüz Tasarım Hataları Ömer Faruk MIZIKACI 2008639402 Arayüz Nedir? Bilgisayar ve uygulamalarının

Detaylı

Ücret Simülasyonu Nasıl Yapılır?

Ücret Simülasyonu Nasıl Yapılır? Ücret Simülasyonu Nasıl Yapılır? Logo İnsan Kaynakları Ücret Simülasyonu Genel bütçeye hazırlık için IK bölümlerinin ücret ve bordro maliyetlerini senaryolaştırabileceği bir modüldür. Ücret simülasyonu

Detaylı

YILDIZ TEKNİK ÜNİVERSİTESİ MİMARLIK FAKÜLTESİ MİMARLIK BÖLÜMÜ 2013-2014 GÜZ YARIYILI

YILDIZ TEKNİK ÜNİVERSİTESİ MİMARLIK FAKÜLTESİ MİMARLIK BÖLÜMÜ 2013-2014 GÜZ YARIYILI YILDIZ TEKNİK ÜNİVERSİTESİ MİMARLIK FAKÜLTESİ MİMARLIK BÖLÜMÜ 2013-2014 GÜZ YARIYILI PROJE YAPIM YÖNETİMİ RİSK YÖNETİMİ 09071023 TUBA NUR BAZ PROJE YÖNETİMİNİN BİLGİ ALANLARI - ENTEGRASYON YÖNETİMİ - KAPSAM

Detaylı

EKLER. EK 12UY0106-4/A5-2: Yeterlilik Biriminin Ölçme ve Değerlendirmesinde Kullanılacak Kontrol Listesi

EKLER. EK 12UY0106-4/A5-2: Yeterlilik Biriminin Ölçme ve Değerlendirmesinde Kullanılacak Kontrol Listesi EKLER EK 12UY0106-4/A5-1: nin Kazandırılması için Tavsiye Edilen Eğitime İlişkin Bilgiler Bu birimin kazandırılması için aşağıda tanımlanan içeriğe sahip bir eğitim programının tamamlanması tavsiye edilir.

Detaylı

BİLİŞİM SİSTEMLERİ GÜVENLİĞİNDE YENİ EĞİLİMLER

BİLİŞİM SİSTEMLERİ GÜVENLİĞİNDE YENİ EĞİLİMLER BİLİŞİM SİSTEMLERİ GÜVENLİĞİNDE YENİ EĞİLİMLER Dr. Hayrettin Bahşi bahsi@uekae.tubitak.gov.tr 11 Mart 2010 Gündem Bulut Hesaplama Sistemleri ve Bilgi Güvenliği Güvenli Yazılım Geliştirme Hayat Döngüsü

Detaylı

COMPUTERIZED AUDIT PROGRAM BİLGİSAYARLI DENETİM PROGRAMI

COMPUTERIZED AUDIT PROGRAM BİLGİSAYARLI DENETİM PROGRAMI COMPUTERIZED AUDIT PROGRAM 1 İçerik CAP-... 3 1. Müşteri tanımları... 3 2. Kullanıcı ve Rol Tanımları... 3 3. Müşteri Kabul Politikası... 4 4. Yıllık Denetim Planı... 4 5. Devamlı Denetim Dosyası... 4

Detaylı

Algoritmaların Karşılaştırılması. Doç. Dr. Aybars UĞUR

Algoritmaların Karşılaştırılması. Doç. Dr. Aybars UĞUR Algoritmaların Karşılaştırılması Doç. Dr. Aybars UĞUR Giriş Bir programın performansı genel olarak programın işletimi için gerekli olan bilgisayar zamanı ve belleğidir. Bir programın zaman karmaşıklığı

Detaylı

BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜM BAŞKANLIĞI DERS TANITIM BİLGİLERİ

BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜM BAŞKANLIĞI DERS TANITIM BİLGİLERİ BİLGİSAYAR MÜHENDİSLİĞİ BÖLÜM BAŞKANLIĞI DERS TANITIM BİLGİLERİ Dersin Adı Kodu Sınıf / Y.Y. Ders Saati (T+U+L) Kredi AKTS YAZILIM MÜHENDİSLİĞİ BG-411 4/1 3+0+0 3+0 5 Dersin Dili : TÜRKÇE Dersin Seviyesi

Detaylı

İŞ YATIRIM MENKUL DEĞERLER A.Ş. İŞ SÜREKLİLİĞİ PLANLAMASI A. AMAÇ

İŞ YATIRIM MENKUL DEĞERLER A.Ş. İŞ SÜREKLİLİĞİ PLANLAMASI A. AMAÇ Sayfa No: 1/7 A. AMAÇ Bu politika, nin deprem, yangın, fırtına, sel gibi doğal afetler ile sabotaj, donanım veya yazılım hatası, elektrik ve telekomünikasyon kesintileri gibi önceden tahmin edilebilen

Detaylı

Ad Soyad : Fahri Dönmez Şube No : TBIL-211-01 Öğrenci No : 12213251 Bölüm : Bilgisayar Mühendisliği. Yazılım Mühendisliğine Giriş Dr.

Ad Soyad : Fahri Dönmez Şube No : TBIL-211-01 Öğrenci No : 12213251 Bölüm : Bilgisayar Mühendisliği. Yazılım Mühendisliğine Giriş Dr. Ad Soyad : Fahri Dönmez Şube No : TBIL-211-01 Öğrenci No : 12213251 Bölüm : Bilgisayar Mühendisliği Yazılım Mühendisliğine Giriş Dr. Ali ARİFOĞLU ÖDEV Kendi seçeceğiniz bir iş problemi için: a) Proje Tanımını

Detaylı

Gezgin Satıcı Probleminin İkili Kodlanmış Genetik Algoritmalarla Çözümünde Yeni Bir Yaklaşım. Mehmet Ali Aytekin Tahir Emre Kalaycı

Gezgin Satıcı Probleminin İkili Kodlanmış Genetik Algoritmalarla Çözümünde Yeni Bir Yaklaşım. Mehmet Ali Aytekin Tahir Emre Kalaycı Gezgin Satıcı Probleminin İkili Kodlanmış Genetik Algoritmalarla Çözümünde Yeni Bir Yaklaşım Mehmet Ali Aytekin Tahir Emre Kalaycı Gündem Gezgin Satıcı Problemi GSP'yi Çözen Algoritmalar Genetik Algoritmalar

Detaylı

Yazılım Mühendisliği Bölüm - 2 Yazılım Geliştirme Yaşam Döngüsü. Cengiz GÖK

Yazılım Mühendisliği Bölüm - 2 Yazılım Geliştirme Yaşam Döngüsü. Cengiz GÖK Yazılım Mühendisliği Bölüm - 2 Yazılım Geliştirme Yaşam Döngüsü Cengiz GÖK 1 Gerçek Hayatta Program Geliştirme Gereksinim Analizi Sistemin İdamesi Sistem Tasarımı Teslim Program Tasarımı Sistem Testi Program

Detaylı

MAKİNE ELEMANLARI DERS SLAYTLARI

MAKİNE ELEMANLARI DERS SLAYTLARI MAKİNE ELEMANLARI DERS SLAYTLARI TOLERANSLAR P r o f. D r. İ r f a n K A Y M A Z P r o f. D r. A k g ü n A L S A R A N A r ş. G ör. İ l y a s H A C I S A L I H O Ğ LU Tolerans Gereksinimi? Tasarım ve üretim

Detaylı

Genel Katılıma Açık Eğitimlerimiz Başlıyor!

Genel Katılıma Açık Eğitimlerimiz Başlıyor! Genel Katılıma Açık Eğitimlerimiz Başlıyor! Mavi Akademi, bünyesinde barındırdığı yetki belgeleri ve alanında uzman akademisyenler, sektör tecrübesine sahip baş denetçiler ve uzmanlardan oluşan kadrosuyla

Detaylı

ŞİDDET ŞİDDETİN DERECELENDİRME BASAMAKLARI

ŞİDDET ŞİDDETİN DERECELENDİRME BASAMAKLARI ŞİDDET ŞİDDETİN DERECELENDİRME BASAMAKLARI ÖZEL KARAMAN MÜMİNE HATUN HASTANESİ AMAÇ: Hastane hizmetlerinin sunumu esnasında meydana gelebilecek riskleri belirlemek ve ortadan kaldırmak için gerekli yöntemleri

Detaylı

Gürcan Banger 21 Mayıs 17 Haziran 2012

Gürcan Banger 21 Mayıs 17 Haziran 2012 Gürcan Banger 21 Mayıs 17 Haziran 2012 Üretim Yatırımı Girişim kapsamında hedeflenen ürün veya hizmetlerin üretilmesi için gerekli işletme faaliyetleri planlanmalıdır. Girişimcinin uzmanlığına da bağlı

Detaylı

BİLGİSAYAR DESTEKLİ TASARIM AUTOCAD DERSİ. 1. HAFTA 27.09.2012 Öğr. Gör. Serkan ÖREN

BİLGİSAYAR DESTEKLİ TASARIM AUTOCAD DERSİ. 1. HAFTA 27.09.2012 Öğr. Gör. Serkan ÖREN BİLGİSAYAR DESTEKLİ TASARIM AUTOCAD DERSİ 1. HAFTA 1 AutoCAD, tüm dünyada başta mühendisler ve mimarlar tarafından kullanılan, dünyaca tanınan yazılım firması Autodesktarafından hazırlanan, bilgisayar

Detaylı

İstatistiksel Kalite Kontrol BBY 374 TOPLAM KALİTE YÖNETİMİ 18 NİSAN 2014

İstatistiksel Kalite Kontrol BBY 374 TOPLAM KALİTE YÖNETİMİ 18 NİSAN 2014 İstatistiksel Kalite Kontrol BBY 374 TOPLAM KALİTE YÖNETİMİ 18 NİSAN 2014 İstatistiksel kalite kontrol o Üretim ve hizmet süreçlerinin ölçülebilir veriler yardımıyla istatistiksel yöntemler kullanılarak

Detaylı

Algoritma ve Akış Diyagramları

Algoritma ve Akış Diyagramları Algoritma ve Akış Diyagramları Bir problemin çözümüne ulaşabilmek için izlenecek ardışık mantık ve işlem dizisine ALGORİTMA, algoritmanın çizimsel gösterimine ise AKIŞ DİYAGRAMI adı verilir 1 Akış diyagramları

Detaylı

Çizelgeleme Nedir? Bir ürünün üretilmesi/hizmetin sunumu için

Çizelgeleme Nedir? Bir ürünün üretilmesi/hizmetin sunumu için Üretim Çizelgeleme Çizelgeleme Nedir? Bir ürünün üretilmesi/hizmetin sunumu için işgörenin nerede, ne zaman gerekli olduğunun, gerekli faaliyetlerin zamanlamasının, üretime başlama ve üretimi tamamlama

Detaylı

BULANIK MANTIK VE SİSTEMLERİ 2014 2015 BAHAR DÖNEMİ ÖDEV 1. Müslüm ÖZTÜRK 148164001004 Bilişim Teknolojileri Mühendisliği ABD Doktora Programı

BULANIK MANTIK VE SİSTEMLERİ 2014 2015 BAHAR DÖNEMİ ÖDEV 1. Müslüm ÖZTÜRK 148164001004 Bilişim Teknolojileri Mühendisliği ABD Doktora Programı BULANIK MANTIK VE SİSTEMLERİ 2014 2015 BAHAR DÖNEMİ ÖDEV 1 Müslüm ÖZTÜRK 148164001004 Bilişim Teknolojileri Mühendisliği ABD Doktora Programı Mart 2015 0 SORU 1) Bulanık Küme nedir? Bulanık Kümenin (fuzzy

Detaylı

HASTANE PERFORMANS İYİLEŞTİRME SÜREÇ(PROSES)LERİNDE İLETİŞİM, VERİ / BİLGİ ve PAYLAŞIM POLİTİKASI

HASTANE PERFORMANS İYİLEŞTİRME SÜREÇ(PROSES)LERİNDE İLETİŞİM, VERİ / BİLGİ ve PAYLAŞIM POLİTİKASI HASTANE PERFORMANS İYİLEŞTİRME SÜREÇ(PROSES)LERİNDE İLETİŞİM, VERİ / BİLGİ ve PAYLAŞIM POLİTİKASI Prof.Dr.Mithat ÇORUH Başkent Üniversitesi Toplam Kalite Yönetimi Merkezi Başkanı Önsöz Hastane performansının

Detaylı

MerSis. Bilgi Güvenliği Danışmanlık Hizmetleri

MerSis. Bilgi Güvenliği Danışmanlık Hizmetleri o MerSis Danışmanlık Hizmetleri Çalışanlarınız, tesisleriniz, üretim araçlarınız koruma altında! Bilgileriniz? danışmanlık hizmetlerimiz, en değerli varlıklarınız arasında yer alan bilgilerinizin gizliliğini,

Detaylı

İş Akış Yönetimi LOGO Kasım 2014

İş Akış Yönetimi LOGO Kasım 2014 İş Akış Yönetimi LOGO Kasım 2014 İçindekiler İş Akış Yönetimi... 3 Görevler... 4 Görev Bilgileri... 5 Mesajlar... 7 Zaman Ayarlayıcı İşlemler... 8 Zamanlanmış Görevler... 10 Zamanlanmış Görev Bilgileri...

Detaylı

Uygulamaları ulut bilişime geçirmeden önce, firmanızın/şirketinizin ya da. işinizin gereksinimlerini göz önüne almanız gerekir. Aşağıda bulut bilişime

Uygulamaları ulut bilişime geçirmeden önce, firmanızın/şirketinizin ya da. işinizin gereksinimlerini göz önüne almanız gerekir. Aşağıda bulut bilişime Bulut Bilişim-Planlama Uygulamaları ulut bilişime geçirmeden önce, firmanızın/şirketinizin ya da işinizin gereksinimlerini göz önüne almanız gerekir. Aşağıda bulut bilişime geçemden önce dikkat edilmesi

Detaylı

ISL 201 Pazarlama İlkeleri. Doç. Dr. Hayrettin ZENGİN

ISL 201 Pazarlama İlkeleri. Doç. Dr. Hayrettin ZENGİN ISL 201 Pazarlama İlkeleri Doç. Dr. Hayrettin ZENGİN Pazarlama Bilgi Sistemi (PBS) Bir işletmenin pazarlama ile ilgili kararlarının alınmasına yardımcı olacak bilgilerin toplanması, işlenmesi, saklanması

Detaylı

Mühendislikte Sayısal Çözüm Yöntemleri NÜMERİK ANALİZ. Prof. Dr. İbrahim UZUN

Mühendislikte Sayısal Çözüm Yöntemleri NÜMERİK ANALİZ. Prof. Dr. İbrahim UZUN Mühendislikte Sayısal Çözüm Yöntemleri NÜMERİK ANALİZ Prof. Dr. İbrahim UZUN Yayın No : 2415 İşletme-Ekonomi Dizisi : 147 5. Baskı Eylül 2012 - İSTANBUL ISBN 978-605 - 377-438 - 9 Copyright Bu kitabın

Detaylı

R KARLILIK VE SÜRDÜRÜLEB

R KARLILIK VE SÜRDÜRÜLEB ÜRETİMDE İNOVASYON BİLAL AKAY Üretim ve Planlama Direktörü 1 İleri teknolojik gelişme ve otomasyon, yeni niteliklere ve yüksek düzeyde eğitim almış insan gücüne eğilimi artıyor. Mevcut iş gücü içinde bu

Detaylı

Yaz.Müh.Ders Notları #4 1

Yaz.Müh.Ders Notları #4 1 YAZILIM MÜHENDİSLİĞİ Şubat 2012 Yrd.Doç.Dr. Yunus Emre SELÇUK 1 NESNEYE YÖNELİK ÇÖZÜMLEMENİN TEMELLERİ Çözümleme (Analiz): Bir şeyi anlayabilmek için parçalarına ayırmak. Sistemi anlamaya yönelik çalışmalardan

Detaylı

Proje Yönetimi Uygulamaları Görev Tanımlama

Proje Yönetimi Uygulamaları Görev Tanımlama Girişimcilik ve İnovasyon Dersi Proje Yönetimi Uygulamaları Görev Tanımlama Yrd. Doç. Dr. Ali Nizam Prof. Dr. Fevzi YILMAZ Mühendislik Fakültesi Fatih Sultan Mehmet Vakıf Üniversitesi 2015 İş Paketi -

Detaylı

Ara Katman Yazılımları İçin İşlemci Değer Birimi Lisanslaması

Ara Katman Yazılımları İçin İşlemci Değer Birimi Lisanslaması IBM Software Ara Katman Yazılımları İçin İşlemci Değer Birimi Lisanslaması Geleceğe İlişkin Temelin Sağlam Olabilmesi İçin Yapının Geliştirilmesi Müşteri Sunumu 2006 IBM Corporation Gündem Ara katman yazılımı

Detaylı