3. Plan Kavramı

Özlü Söz

Plan hiçbir şeydir, planlama her şey.

 

 

Kazanımlar

1. Plan ile proje kavramlarının farkını öğrenebilir.

2. Planlama yaparken dikkat edilmesi gereken unsurları öğrenebilir.

3. Farklı plan türleri konusunda bilgi edinebilir.

4. Planların sahip olması gereken özellikleri belirleyebilir.

5. Planlama için harcanan süreyi belirleyebilir.

 

Birlikte Düşünelim

1. Günlük yaşamda plan yapmanın önemi nedir, hangi alanlarda plan yapmaya ihtiyaç duyulur?

2. Herhangi bir konuda plan yapmadan önce nelere dikkat etmek gerekir?

3. Bir plan yaparken insanın sahip olduğu en önemli kısıtlar hangileridir?

4. Kapsam planı, zaman planı, bütçe planı ne anlama gelmektedir, bu farklı planlar bir birlerini etkiler mi?

5. Plan ve planlama arasındaki fark nedir?

 

Başlamadan Önce

Planlama; bir projede yapılacak olan tüm işlerin belirlenmesi, belirli bir sıraya konulması, hangi işin kim tarafından ne zaman ne şartlarda yapılacağının organize edilmesi işlemlerine verilen isimdir. Bir proje içerisinde aynı anda yapılabilecek işlemler olduğu gibi birbirinden faydalanan ve birbirinin sonucunu beklemek zorunda olan işlemler de bulunmaktadır. Bu açıdan plan yapmak çok önemlidir ve bir projenin başarısı büyük ölçüde planlamaya bağlıdır. Bu bölümde öncelikle planlama kavramı anlatılacak, planlama özellikleri ifade edilecek, sonrasında ise projelerde yer alan plan çeşitlerine yer verielcektir. Her projenin kendisine özgü özellikleri bulunduğu ve projenin durumuna göre projede yer alan plan çeşitlerinin değişeceği bilinmektedir ancak bu bölümde genel olarak her projede bulunabilecek olan “kapsam planı, birleştirme planı, risk planı, zaman planı, kaynak planı, maliyet planı, kalite güvence planı, test planı, eğitim planı ve devreye alma planı” açıklanacaktır.

 

 

 

3. 1. Planlama Kavramı

Planlama; bir projedeki hedeflere ulaşmak ve müşterilerin ihtiyaçlarını karşılamak için izlenecek yöntemi, yapılacak işleri, kullanılacak kaynakları ve iş takvimlerini proje kısıtlarını da dikkate alarak belirleme işlemidir. Bu yönüyle projenin gerçekleştirilmesine hizmet eder. Bir planda kimin, neyi, ne zaman, nasıl ve ne kadarlık bir maliyetle yapacağı gibi bilgiler yer almaktadır. Plan belli standartlara göre belgelenmesi ve takip edilmesi gereken bir elemandır diğer bir deyişle çoğunlukla kişilerin sadece kafalarında bir fikir olarak gelişen plan aslında bir plan değildir. Bir işlem için bir plan yapılmasının yanında yapılan planın izlenmesi, planın gerisinde kalınması halinde neden geride kalındığının analiz edilmesi gerekmektedir.

Bir projede bir plan olmaması durumunda süreyi, bütçeyi, diğer kaynakların kullanımını ve iş hedeflerini takip etmek mümkün olmaz. Bu durumda projeye mutlak olarak gerekli olan ekip ruhu kaybolur ve yazılımcılar kendi başlarına bireysel şekilde çalışmaya başlar. Bu da sonucunda başarısızlığı getirir.

Planlama birçok diğer proje faaliyeti gibi aşama aşama yapılması gereken bir işlemdir. Öncelikle genel bir plan hazırlanmalıdır. Bu genel planda adından da anlaşılacağı gibi genel olarak faaliyetlerin isimleri, ihtiyaç duydukları kaynaklar, çözüm getirecekleri sorunlar, tahminî süreler ve bütçeler ifade edilir. Sonra bu plan her aşama başında veya sonunda yapılanlar, yapılacaklar, kaynakların kullanımları ve gerçekleşen sürelerin tekrar incelenmesiyle ayrıntılı hale getirilir. Bu sırada proje geliştirme süreci en alt düzeyde tek bir kişi tarafından gerçekleştirilecek birim görevlere kadar bölünmelidir böylece aslında projenin her aşaması, genel plana bağlı olarak kendi planına sahip olur. Planlamayla ilgili genel standartlar belirlenmeli ve daha sonra bunlar her projede ihtiyaca göre özelleştirilmelidir.

Bir projede planlanması gereken birçok konu mevcuttur. Bunlar gruplanarak çeşitli standart plan türleri ortaya çıkmıştır. Geliştirilecek projenin ya da yazılımın özelliklerine göre farklı türlerde daha ayrıntılı planlar yapılması da gerekebilir.

3.2. Planlama Özellikleri

Sağlıklı ve başarılı bir planlama yapabilmek için planlama ile ilgili bazı temel kavramları açık bir şekilde bilmek gereklidir. Bu kavramlar aşağıda açıklanmıştır:

Planlamanın Önemi ve Yararları: Karmaşık bir geliştirme süreci olan ve farklı roller içeren ekiplerle yürütülen yazılım geliştirme sürecinin başarısı, kaliteli bir plana bağlıdır. Planlamanın hedeflediği alanlar ve buna bağlı yararları aşağıda sıralanmıştır.

• Projenin hedeflerini net bir şekilde ortaya koymalıdır.

• Her ürünün ortaya çıkması gereken zamanı ve bu zamana gelinceye kadar geçen sürecin aşamalarını özet olarak tarif etmelidir.

• Proje yöneticisi, takım lideri, proje ekibi, müşteriler ve diğer paydaşlar arasında bir iletişim köprüsü oluşturmalıdır.

• Her personelin görevleri, görevler arası ilişkilerini ve kaynak ihtiyacını net bir biçimde göstermelidir.

• Proje yöneticisinin yapılanları kontrol edebilmesini sağlayacak bir mekanizma oluşturmalıdır.

• Kaynaklara ne zaman ihtiyaç duyulacağını göstermelidir.

• Kontrol noktalarını ve yapısını tanımlamalıdır.

Her ne kadar genellikle projelerin başlangıçlarında planlama ve analiz için süre ayırmak çoğunlukla gereksiz görünse de esasında planlama işlemi projelerin sonraki aşamalarında verimliliği arttırır, hataların azaltılmasına yardımcı olur. Böylece projenin önceden belirlenen bütçe ve kaynaklar ile önceden belirlenen kapsamda tamamlanması olasılığı artar.

Planlı ilerleyen bir proje ekibi; plansız ilerleyen bir proje ekibine göre ne zaman, hangi kaynakları kullanarak ne iş yapacağını daha kolay anlar ve işlemleri daha kolay bir biçimde tamamlar. Eğer bir projenin başında herhangi bir plan yapılmazsa plan için ayrılacak süre doğrudan proje faaliyetleri için kullanılmaya başlanmış ve proje faaliyetleri hiç zaman kaybetmeden başlamış gibi bir görüntü oluşur halbuki o görüntü anlık bir durumu ifade eder ve zaman ilerledikçe işlemler birbirine karışmaya, sorunlar çıkmaya, hedeflenen noktalardan uzaklaşmaya, verimlilik azalmaya başlar. Sonuçta proje başında plan yapmak için ayrılmayan süre, projenin aşamalarında çok daha fazla zaman kaybına yol açabilir ayrıca şunu da belirtmek gerekir ki projelerdeki hatalar ne kadar geç bir şekilde fark edilirse düzeltilmesi o kadar zor ve maliyetli olur. Örneğin bir inşaat projesinde yanlış yapılan bir balkon, kapı, pencere vb. düzeltmek için oldukça büyük bir iş gerekli olacaktır ve ancak yüksek bir maliyet ve emekle bu sorun çözülebilecektir. Yine aynı şekilde bir yazılım projesinde de bulunan hataların çözülmesi için yazılımın başlarına gitmek gerekli olabilecektir ki bu da belki aylardır sarf edilen emeğin boşa gitmesi anlamına gelebilecektir. Planlı olarak geliştirilen bir projede ise bu gibi sorunlar çok nadir olarak görülür. Bunun dışında plan yapmanın diğer bir faydası da müşterinin isteklerinin daha net bir biçimde karşılanabilmesidir. Plan yapılmadığı takdirde projenin sonlarında müşterilerin istek ve ihtiyaçlarının sanılandan farklı olduğunu görmek mümkün olabilir ki bu da yine projenin ilerlemesi için büyük bir sorundur. Bu sebeple proje başlarında planlama ve analiz için mutlaka bir süre ayrılması gerekmektedir ancak bu süre gereğinden uzun tutulursa Bu durumda planlama faaliyetlerinin faydası da azalır. Bu nedenle optimum bir süre tercih edilmelidir. Planlama ve analiz süresini optimum seviyede kısa tutma sebepleri aşağıdaki şekilde ifade edilebilir:

• İlk anda belirlenemeyecek konular: Planlama ve analiz süresi ne kadar uzun tutulursa tutulsun ilk anda bazı ihtiyaçları, kaynakları ve durumları vb. belirlemek mümkün olmayacaktır. Bazı ihtiyaçlar, kaynaklar ve durumlar ancak proje ilerledikçe netleşebilir. Bu sebeple proje başındaki planlarda tüm ihtiyaçları belirlemeye çalışmak ve bunun için uzun bir süre harcamak gereksiz bir çabadır.

• İhtiyaçların değişmesi: Tüm projelerde başlangıçta belirlenen ihtiyaçların bir kısmının proje içerisinde ve proje süresince değişmesi ihtimali söz konusu olduğundan tüm ihtiyaçları planın başında belirlemek mümkün değildir. Bu sebeple de proje başındaki planın tüm ihtiyaçları belirleyecek kadar uzun tutulmasına gerek yoktur çünkü zaten bir kısmı mutlaka değişecektir. En mantıklı olan, projenin temelini etkileyecek ihtiyaçların belirlenmesi, diğer ihtiyaçların esnek bırakılmasıdır.

• İlgi azalması: Plan süresi çok uzun olduğunda Bu durumda uzun bir süre projede üretilen bir şey görülemeyeceğinden projeye dış ilgi ve destek azalacaktır. Bu durumun devamında proje üst yönetiminin “Neden ortaya hiçbir şey konulmadı?”, “Bir sorun mu var?” gibi soruları gerginliğe yol açabilmektedir.

• Ekibin bir kısmının beklemesi: Projelerdeki faaliyetlerin bir kısmı planlama ve analiz ile paralel bir şekilde yürütülebilirken büyük bir kısmı ise bu ancak bu aşamalar bittikten sonra başlayabilecek, bu sebeple de planlama ve analiz sırasında boş durmak zorunda kalacaktır. Planlama ve analiz ekibi dışındaki üyelerin uzun süre beklemesi, huzursuzluğa ve sonucunda verimsizliğe sebebiyet verebilir.

• Hedefin değişmesi: Yukarıda belirtildiği gibi ihtiyaçların değişebilmesi durumu, planlama ve analiz aşamalarının çok uzaması halinde sürecin çalışma şeklinin de değişmesi olarak karşımıza çıkabilir. Kurumların yaklaşık beş yılda bir önemli teknolojik değişikliklere gittiği düşünülürse bir yıllık bir analiz süreci özel bilimsel projeler hariç çok fazla anlam ifade etmez hele ki işin içerisinde yazılım ve yeni gelişen teknolojiler bulunmaktaysa sürekli olarak güncellenmesi gerekmektedir. Süre bir yılı aşarsa firma; teknoloji, mevzuat veya firmanın çalışanları değişebilir.

Proje Büyüklüğü ve Planlama İhtiyacı: Herhangi bir ürünün ekonomik değerine bakıldığında ürünün büyüklüğü ve miktarı arttığında genellikle birim maliyetin düştüğü görülmektedir.

1 birimlik bir ürün 100 TL’ye mal oluyorsa 2 birimlik bir ürün 200 TL’ye değil daha düşük bir değere mal olacaktır ancak yazılımlar genellikle bunun tersi bir eğilim gösterir ve yazılımın büyüklüğü arttıkça gerçekleştirmek için gerekli süre, emek, bütçe gibi faktörler üstel olarak artar. 100 bin satırlık bir proje 1 ayda bitiyorsa 200 bin satırlık bir proje büyük ihtimalle iki aydan daha uzun bir süre devam edecektir. Bu sebeple özellikle yazılım projelerinde proje büyüklüğüne dikkat edilerek planlama yapılması gerekmektedir.

Proje Büyüklüğü ve Zaman/Karmaşıklık İlişkisi: Kesin bir kural olmamakla beraber genellikle küçük ölçekli yazılım projelerinde tasarım, kodlama ve birim test; büyük projelerde ise planlama, ihtiyaç analizi ve entegrasyon daha çok zaman alır diğer bir deyişle küçük çaplı projelerde işlerin yapılması, büyük çaplı projelerde ise işlerin nasıl yapılacağının belirlenmesi daha zor ve daha uzun süren bir süreçtir. Bunun temel sebebi yazılımların birbiriyle bütünleşik çalışan birçok parçadan (modüller, akış şemaları, arayüzler, veri tabanı tabloları, aracı dosyalar, veriler vb.) oluşmasıdır. Parça sayısındaki artış, proje karmaşıklığını da üstel olarak arttırır. Karmaşıklık ise planlama ihtiyacının artmasına sebep olur. Projenin büyümesiyle artan ekip sayısı da kişiler arasındaki aktif iletişim ihtiyacı ve karmaşayı arttırır.

Planın Planı: Proje türleri çeşitli olduğundan projeler için gerçekleştirilecek plan türleri de oldukça çeşitlidir. Bir projenin içerisinde de birçok farklı plan yapmak gerekebilir.

Bu plan türlerinin ortak özellikleri mevcuttur. Bu ortak özelliklerinden yola çıkarak herhangi bir alanda kullanılabilecek planın temel yapısını belirlemek mümkün olabilir. Sonuçta geliştirilen temel plana, projeye özgü değişiklikler yapılır ve projeye özgü bir plan oluşturulmuş olur. Her planda ortak olarak verilmesi gereken özellikler şu şekildedir:

• Yapılacak işin tanımı, girdileri ve çıktıları

• Yapılacak işin öncesinde tamamlanması gereken işler

• Yapılacak işin sonrasında bu işten faydalanarak gerçekleştirilecek işler

• Yapılacak işin tahmini başlangıç ve bitiş tarihi

• Yapılacak işi yapmak için gerekli uzmanlık türleri

• Yapılacak iş üzerinde alınması gereken roller ve görevler ve bu görevleri yerine getirecek proje ekibi personeli

• Yapılacak iş ile ilgili kullanılacak standart yöntemler, tercih edilen yöntem ve tercih sebepleri

• Yapılacak işin başarılı bir şekilde tamamlanıp tamamlanmadığına dair başarı kriterleri

• Yapılacak iş üzerinde çalışacak olan kişiler arasındaki iletişim yöntemi

• Yapılacak işin üzerinde gerçekleştirilecek olan kontrollerin sıklığı ve yöntemi

• Yapılacak işin kalitesi ile ilgili kısıtlar

• Yapılacak işin tahminî maliyeti

• Yapılacak iş ile ilgili ortaya çıkabilecek riskler ve bu risklerin çözüm yöntemleri

Proje Planının Diğer Belgelerle İlişkisi: Projelerinde proje planı dışında analiz, tasarım ve çalışma tablosu gibi birçok belge bulunur. Yazılım projelerinde bu belgeler daha da fazladır; veri tabanı tabloları, arayüz tasarımları, akış şemaları, UML şemaları, (Unified Modeling Language – Birleşik Modelleme Dili) modül mimarileri gibi birçok belge daha mevcuttur. Plan bu belgelerle karşılıklı etkileşimlidir diğer bir deyişle bu belgeler birbirlerini etkilerler. Genellikle diğer belgeler proje planına etki etse de bazen tam tersi de mümkün olabilir.

3. 3. Proje Plan Türleri

Bir bilgi işlem projesi diğer tüm projeler gibi kapsam, zaman, bütçe, görevler arası ilişkiler, proje kısıtları ve riskler gibi birçok farklı bakış açısından incelenebilir.

Bu elemanların her biri birbirini etkilese de ayrık bir inceleme de gerekebilir. Bu ihtiyaçlar sonucunda birçok farklı proje planı ortaya çıkmıştır. Proje büyüklük ve karmaşıklığına göre oluşturulacak plan sayısı ve türü değişebilir. Farklı türdeki planlar ayrık birer belge halinde hazırlanabileceği gibi genel bir plan içerisinde alt başlık olarak da yer alabilir. Plan türleri temelde aşağıdaki gibi ifade edilebilir:

Şekil 7. Plan Türleri

3. 3. 1. Kapsam Planı

Kapsam planı; projede yapılacak (ve yapılmayacak) temel işlerin ve bu işlerin içeriklerinin belirlendiği, proje sınırlarının çizildiği plandır. İnsan ihtiyaçlarının bir sınırı yoktur ancak elindeki imkanlarının sınırları vardır ve bu sınırlara göre hareket etmek gereklidir. Bir projede genellikle hangi işlemlerin yapılması gerektiği kolay bir biçimde belirlenebilir, asıl sorun bu işlemlerin hangi şartlar altında yapılması gerektiğini belirlemektir. Kapsamın belirlenmesinde ayrıntılı olarak yapılacaklardan ziyade üst düzey proje ve ürün yaklaşımı önem kazanır. Kapsam planı, sadece projenin ilk anında kapsamı belirlemekten ibaret değildir, kapsam proje sürecinde değişebilir. Kapsam planında aşağıdaki unsurlara dikkat etmek gereklidir:

• Kapsamı Sürümlere Dağıtarak Planlamak: Özellikle yazılım projelerinde müşterinin tüm isteklerini en önemlilerinden başlayarak gruplandırmak ve her grubu bir sürüm olarak gerçekleştirmek, projeyi planlama ve yürütmeyi kolaylaştırır. Günümüzdeki yazılım ürünlerine dikkat edilirse özellikle paket yazılımların sürümler halinde yazıldığı ve her sürümün öncekinden daha gelişmiş olduğu görülmektedir.

• Diğer Firmalardaki/Kurumlardaki Benzer Projelerin Kapsamını İncelemek: Özellikle benzer işler yapan firmaların/kurumların yazılım ihtiyaçları arasında mutlaka benzerlikler bulunacaktır. Yazılım ekibinin benzer bir kurumda aynı alanda çalışan yazılım projesini incelemesi ve sonuçlarını kullanıcılarla paylaşması, kapsamın doğru belirlenmesi için yol göstericidir. Burada bahsedilen durum oldukça genel bir durumdur ve yazılımların çok farklı şekillerde geliştirilebileceği, çok farklı teknolojiler kullanılabileceği, görsel olarak büyük farklılıklar gösterebileceği unutulmamalıdır. Buradaki benzerlikten kastedilen esasında yapılan işlerin benzemesidir. Örneğin tüm öğrenci işleri yazılımlarında kayıt, ders seçimi gibi işlemlerin bulunması gereklidir. Buna göre geliştirilecek olan bir yazılımda bu özelliklerin hepsinin hatta daha fazlasının bulunması gerekir. Eğer bir kurum, sahip olduğu öğrenci işleri yazılımını örneğin mobil uygulama ile birleştirmişse, bu durumda diğer kurumların da bunu gerçekleştirmeyi hedeflemesi gerekmektedir. Özellikle yazılım projelerinde her gün daha ileriye gidilmesi hedeflenmelidir.

• Firma Büyüklüğü, Kullanıcı Sayısı ve Hitap Edilen Pazarı Analiz Etmek: Her ürünü ve projeyi olduğu gibi bir yazılımı kullanan kişi sayısının artması proje büyüklüğünü planlamayı ve proje planını etkiler. Yüksek sayıda kullanıcının kullandığı basit bir arayüzü/ekranı geliştirmek bile güvenlik, performans ve gerekli donanım altyapısı için ayrıntılı planlama gerektirir.

3. 3. 2. Birleştirme (Entegrasyon) Planı

Geliştirilen projelerde yapılan işlerin, kaynakların, hedeflerin başarılı bir şekilde birleştirilmesi (entegre edilmesi) gerekmektedir yoksa yapılan bütün işler boşa gider.

Bu entegrasyon işlemi iyi bir analiz ve planlama gerektirir. Entegrasyon planında kullanılacak yöntem, arayüzler, sistemler arası veri alışverişi, yapılan işlemler, bu işlemlerin sorumluları bulunmalıdır. Entegrasyon planı da kendi içerisinde birkaç alt dala ayrılabilir:

• Plan Türleri Arası Entegrasyon Planı: Kapsam planı, maliyet planı ve risk planı gibi farklı planların entegre edilmesi ve birlikte uygulanmasının nasıl bir sonuç ortaya çıkaracağını belirleyen plandır.

• Sistemler Arası Entegrasyon Planı: Yeni yazılacak bir projenin var olan projelerle yazılım ve donanım sistemleri ile farklı versiyonlarla birlikte çalışması gerekir. Uyumluluk adı da verilen bu durum başarılı bir şekilde sağlanmazsa yazılımların başarılı bir şekilde çalışması sağlanamaz.

• Modüller Arası Entegrasyon Planı: Eğer çok büyük bir sistem tasarlanıyorsa bu sistemin alt sistemlere bölünerek tasarlanması gerekir. Bunlar arasındaki bütünleşme ve iletişim de planlanmalıdır. Bu durum yazılım modülleri için de geçerlidir.

3. 3. 3. Risk Planı

Risk, herhangi bir işlem içerisinde belirli bir zaman aralığında hedeflenen bir sonuca ulaşamama, kayba ya da zarara uğrama olasılığıdır. Bir projenin başarılı bir şekilde tamamlanması için yapılması gereken işlemlerin belirlenmesi kadar bu işlemlerin yapılmasını engelleyebilecek olan risklerin de tanımlanması gerekmektedir. Gelecekte oluşabilecek potansiyel sorunlara, tehdit ve tehlikelere işaret eden risklerin belirlenmesi, bu risklerin önem derecesinin tespit edilmesi, riskin gerçekleşmesine sebep olabilecek durumların analiz edilmesi, bu risklerin oluşması halinde nasıl çözüleceğinin belirlenmesi risk planının en önemli maddelerini oluşturmaktadır. Riskler mevcut bir tehlikenin harekete geçmesi ve tetiklenmesi ile ortaya çıktığından öncelikle mevcut tehlikelerin analiz edilmesi gerekmektedir. Tehlikeleri önlemek zordur ancak başarılı bir risk planı ile tehlikelerin riske dönüşmesi engellenebilir.

3. 3. 4. Zaman Planı

Proje zaman planının hedefi, görev takvimlerini projeyi zamanında tamamlayacak şekilde oluşturmaktır. Genellikle yazılım projelerinde zaman ile ilgili sorun olduğu bilindiğinden proje zaman planının önemi büyüktür. Projenin ilk aşamalarında başlangıç ve bitiş tarihlerinden en azından birisi kabaca belli olmaktadır. Genellikle başlangıç tarihi belli olmakla beraber bitmesi gereken tarihin belli olduğu ve projenin bu tarihe yetiştirilmesi gereken durumlar da yazılım projelerinde sıklıkla karşımıza çıkmaktadır. Başlangıç ve bitiş tarihleri dışında proje ekibinde yer alan tüm personelin her birinin görev süreleri de ilk aşamada aşağı yukarı tahmin edilmelidir çünkü bu görevlere kaynak ve iş ataması yapılırken çakışmalar olmamalı bir kaynak aynı anda yalnızca bir kişi ya da görev tarafında kullanılacağı için iyi bir şekilde planlanmalıdır diğer bir deyişle esasında her plan birbirini etkilemekte ve birbirinden etkilenmektedir.

Proje takviminin oluşturulabilmesi için yukarıda da belirtildiği gibi bir projenin ya başlangıç tarihi ya da bitiş tarihi belli olmalıdır tabi buna ek olarak projenin süresinin belirli olduğu durumlar da mevcuttur.

• Süresi Belirli Projeler: Bazı projelerde projenin gerçekleşmesi için gerekli süre üzerinde bir planlama yapılmıştır ancak yeterli kaynak bulunmadığı için projenin başlama tarihi belirlenememiştir. Özellikle ihaleyle alınan projelerde bu durum sıklıkla görülür. Şartnamede süre belirtilir ancak ihale sürecinin kendisinin ne kadar süreceği belli olmadığından projenin ilk anda başlangıç ve bitiş tarihleri net değildir. Bu tip projelerde projenin süresi belli olduğundan kritik yol üzerinde de bir çalışma yapılmıştır. Bu tip projelerde projenin başlama tarihi belli olduğu anda muhtemel bitiş tarihi de belli olacaktır.

• Bitiş Tarihi Belirli Projeler: Bazı projelerde projenin bitmesi gereken kesin tarih belirlidir. Özellikle özel şirketlerdeki mali işler, stok yönetimi, okullarda ve üniversitelerde ders ve sınav takibi gibi dönem esaslı çalışan birimler için geliştirilen projeler bu türdendir. Bu tür projelerde mümkün olduğunca erkenden projeye başlamak hedeflenmelidir çünkü proje başlangıcı gecikirse proje için ayrılabilecek süre kısalır. Proje yöneticisi, bu tür projeleri mümkün olan en kısa sürede başlatmaya çalışmalıdır.

• Başlangıç Tarihi Belirli Projeler: Bazı projelerin başlangıç tarihi belirlidir. Bitiş tarihini belirlemek de proje ekibine bırakılmıştır. Proje yöneticisi ve ekip, plandaki görev akışına göre toplam süreyi ve bitiş tarihini önerir. Bu durum ideal olmakla birlikte, bu tür projeler çok nadirdir.

Zaman planında önemli bir yere sahip olan zaman çizelgeleri farklı açılardan analizler gerçekleştirilerek hazırlanır.

1. Ağ analizi: Bir projede gerçekleştirilecek olan işlemler arasındaki ilişkilerin iş akış mantığı ve ağ şeması kullanarak analiz edilmesidir.

2. Kaynak dengeleme: Kaynak kullanımının bir süre aralığında sıkışmasının önüne geçilmesi ve düzenli kullanım sağlamak için planın tekrar düzenlenmesidir. Bu işlem gerçekleştiğinde de kritik yolun değişmesi durumu söz konusudur.

3. Senaryo analizleri: Varsayılan bir özel senaryonun gerçekleşmesi halinde planın nasıl etkileneceğinin incelendiği analizlerdir.

4. Önden gitme ve bekleme: Planın önce başlama veya gecikme durumlarına göre tekrar incelenmesi ve gerekirse düzenlenmesidir.

5. Sıkıştırma: Kaynak ilavesi ve işlerin paralel hale getirilmesi, böylece proje kapsamı değişmeden süresinin kısaltılmasına yönelik yapılan çalışmalardır.

6. Kritik yol ve kritik zincir: Bir projedeki bazı işlemler, projenin herhangi bir safhasında başka işlemlerden bağımsız olarak yapılabildiği gibi bazıları farklı işlemlere bağlı olarak yapılır ve neticede projenin tamamının uzunluğunu etkiler.

Bu işlemlere kritik işlem, bu işlemlerin oluşturduğu yola da kritik yol adı verilir. Kritik kelimesinin kullanılmasının sebebi bu yolun projenin süresine doğrudan etki etmesi ve bu yol üzerindeki değişikliklerin proje üzerinde de değişikliklere neden olmasıdır. Toplam süre, projenin başlangıcından bitişine kadar birbirini takip eden görevlerin süreleri toplamıdır. Kritik yol en uzun süreli yol olduğu için projenin toplam süresini gösterir. Kritik yoldaki görevlerin herhangi birinin gecikmesi proje süresini uzatır. Tablo 3.1’de bir projenin zaman planlaması örneği, Görsel 3.1’de ise bir kritik yol örneği sunulmuştur.

Tablo 3.1. Bir Projenin Zaman Planlaması Örneği

Görev No	Görev İsmi	Tahmini Ortalama Süre	En Kısa Süre	En Uzun Süre	Önceki Görevler
1	1. Analiz	5 hafta	4	7
2	1.1 İhtiyaç Analizinin Yapılması	5 hafta	4	7
3	2. Tasarım	10 hafta	8	11
4	2.1 İş Kuralları Tasarımı	10 hafta	8	11	2
5	2.2 Güvenlik Modül Tasarımı	4 hafta	4	5	2
6	3. Kodlama	15 hafta	14	20
7	3.1 İş Kurallarının Kodlanması	15 hafta	14	20	4
8	3.2 Güvenlik Modülü Kodlanması	5 hafta	5	7	5
9	4. Test	5 hafta	4	8
10	5. Altyapı Çalışmaları	15 hafta	9	20
11	5.1 Donanım Temini	10 hafta	5	12
12	5.2 Kurulumun Yapılması	5 hafta	4	8	12
13	6.Yazılımın Kurulması	3 hafta	2	4	10;13
14	7. Devreye Alma	Proje Sonu	–	–	14

  

Görsel 3.1. Kritik Yol Örneği

Örnekte kritik yol hesabının nasıl yapılacağı grafik üzerinde gösterilmiştir. Koyu renkli okların toplam süresi, projenin toplam süresidir. Bu süre 1–2–3–5–7–8 yolundaki görevlerin toplamından 38 hafta olarak hesaplanmıştır. Ağ şemasında görevlerin birleştiği ve ayrıldığı kesişim noktalarına kilometre taşı ismi verilir. Kilometre taşları, şekilde daire içerisinde numaralarla gösterilmiştir. Görevlerin bazılarının uzaması kritik yolu değiştirebilir.

Bu durumda kritik yol haricindeki görevlerin başlangıç ve bitiş tarihlerinin ne kadar değişebileceği önem kazanır. Bu amaçla öncelikle bir görevin en erken-en geç başlayabileceği ve bitebileceği noktaların hesaplanması gerekir.

• En Z: Bir görevin en erken başlama zamanı, öncesindeki görevin en erken başlama zamanı ile yine öncesindeki görevin süresi toplamıdır. Öncesinde birden fazla görev olan bir görevin en erken başlama zamanı önceki görevler içinden erken başlama zamanıyla süresi toplamı en büyük olan seçilerek belirlenir. Şekildeki 2 noktalı kilometre taşından sonraki görevlerin en erken başlama zamanı “ihtiyaç analizi yapılması” görevi için başlangıçtan itibaren 5 haftadır. “Test yapılması” görevinin öncesinde 5 no.lu kilometre taşı mevcuttur. Bu noktaya 1–2–3–5 ve 1–2–4–5 yollarından ulaşılabilir. 1–2–3–5 yolu için en erken başlama zamanı 5+10+15=30 hafta iken 1–2–4–5 yolu için en erken başlama zamanı 5+4+5=14 hafta olarak bulunur.

• En Erken Bitiş Zamanı: Görevin en erken başlama zamanı ile süresi toplamıdır.

• En Geç Başlama Zamanı: Bir görevin proje süresini uzatmayacak en geç başlama zamanıdır. Proje bitişinin en geç başlama zamanı ile en erken başlama zamanı eşit kabul edilir. Önceki bir görevin en geç başlama zamanı bu görevin süresi sonraki görevin en geç başlama zamanından çıkartılarak bulunur. Şekildeki 8 numaralı kilometre taşına bağlı “yazılım kurulması” görevinin en geç başlama zamanı 38-3=35 haftadır.

5 noktasının en geç başlama zamanı 35-5=30 haftadır. 3 noktasının 30-15=15 ve 4 noktasının 30-5=25 hafta seklinde hesaplanır. 2 noktasında plan iki yola ayrılmaktadır. Bu yollardan 7–5–3–2 sırası izlendiğinde en geç başlama zamanı 5, 7–5–3–2 izlendiğinde en geç başlama zamanı 21 olarak bulunur.

• En geç bitiş zamanı: Bir görevin proje süresini geciktirmeden en son bitebileceği zamandır. En geç başlama zamanı ile görev süresi toplamıdır.

Kritik yol haricindeki bir görevin bitişinde kritik yolun süresini aşmayacak kadar gecikme olması projenin gecikmesine yol açmaz. Bir görevin proje süresini uzatmayacak kadar geç başlayabileceği süreye toplam bolluk-gevşeklik süresi denir. Bir görevin diğer hiçbir görevi geciktirmeyecek kadar gecikebileceği süreye özgür bolluk-gevşeklik süresi denir olarak isimlendirilir. Kritik yolda bolluk süresi yoktur.

3. 3. 5. Kaynak Planı

Kaynak planlama aşamasında öncelikle projede hangi kaynaklara hangi zaman aralığında ihtiyaç duyulduğu belirlenir. Sonrasında bu kaynakların nasıl sağlanacağı belirlenerek plana eklenir. Kaynak planı hazırlanması, zaman ve maliyet planlarıyla birlikte yürütülmesi gereken bir çalışmadır. Projedeki hedefleri gerçekleştirmek ve görevleri yerine getirmek için kullanılan her şey projenin kaynağı olarak kabul edilebilir. Bunlar görev yapan kişi, işlerin yapılmasında kullanılan malzeme, teçhizat, makine ve diğer mali değerler olarak sayılabilir. Kaynaklar yapılarına göre farklı şekillerde sınıflanabilir. Her kaynak türü kendi içerisinde farklı özellikler gösterir. Kaynak türü kaynağın nasıl sağlanacağını kullanım şeklini ve maliyetini belirlerken yardımcı olur. Kaynak türleri aşağıdaki gibi özetlenebilir:

• İnsan: İşlerin yerine getirilmesi için gerekli uzmanlıklara sahip olan proje personelidir. İnsan her projenin değişmeyen kaynağıdır ve genellikle diğer kaynaklardan ayrı değerlendirilir.

• Malzeme/Teçhizat/Makine: Farklı projelerde ham maddeler; yazılım projelerinde ise kırtasiye, bilgisayar, yazılım, donanım gibi dışarıdan alınacak unsurlar şeklinde sayılabilir. Malzemelerin hem satın alma ve hem de bakım maliyetleri dikkate alınmalıdır.

• Malî: Doğrudan mali değer olarak ifade edilen kaynaklardır. Yapılan teknik gezi masrafları, kiralar, lisans ücretleri gibi maliyetler örnek verilebilir.

• Diğer: Projenin yapılması için gerekli altyapı, kurumsal standartlar, önceki projelerden elde edilen tecrübeler gibi kurumsal kaynaklardır.

Kaynakların projede aktif görev alabileceği süre, katılım yüzdesi ve takvimi belirlenmelidir. Kişi ve diğer kaynakların proje çalışmalarını etkileyecek tüm bilgileri sisteme girilmelidir. Girilmesi unutulan her süre, projeye olumsuz yansır ve riski arttırır. Hastalık gibi beklenmeyen durumlar düşünülerek belli bir esneklikte zaman bırakılmalıdır. Projelerde kritik bir öneme sahip olan kaynak atama işlemi, görev ile ilgili kişi ve diğer kaynakların eşleştirilmesi olarak tanımlanabilir. Kişi göreve atandığında kişinin uzmanlığı, proje takvimi ve kişinin takvimi karşılaştırılarak görevin alacağı toplam süre bulunur. Görev için harcanacak emek ve süre aşağıdaki değişkenlerle modellenir:

• Süre: Görev için planlanan toplam süredir. Çoğunlukla gün cinsinden ölçülür. Uzun projelerde ay olarak da verilebilir.

• Birim: Bir kaynağın toplam zamanının ne kadarını görev için ayırabileceğidir. Yüzde cinsinden ölçülür. Özellikle insan kaynağı için önemli bir birimdir. Bir insan birçok farklı projede ve işte çalışıyor olabilir buna göre her projeye ayıracağı zaman miktarı farklı farklı olacaktır.

• Çalışma: Görevi yapmak için fiilen ne kadar zaman gerektiğidir. Saat cinsinden ölçülür.

Bir kişi 2 gün süren bir görevi tamamlamak için günlük 8 saatlik mesainin 4 saatini harcamışsa süre 2 gün, birim %50 ve çalışma 8 saat olarak yazılabilir. Görevin süresi, harcanacak emek ve kaynak ilişkisinde “Süre x Birim = Çalışma” denklemi kullanılır. Buradaki denklemde değişkenlerden birisi sabit kabul edilirse kalan iki değişken birbirini etkiler. Burada bir görev için temelde üç durum söz konusudur.

• Sabit Süre: Görevin alabileceği toplam süre sabittir. Süre ilave kaynaklarla değişmez. Örneğin donanım temini görevi ne kadar kaynak ilave edilirse edilsin, sağlayıcı firmanın teslimat süresine bağlıdır.

• Sabit Birim: Çalışan kişinin göreve ayıracağı birim zaman sabittir. Bu birim zaman görev süresi veya çalışma değişiminden etkilenmez. İlave kaynak atanırsa süre kısalır. Bir programcı tek görevdeki birbirine bağlı iki ekranı 4 günde yazıyorsa ikinci bir programcı ilavesi süreyi 2 güne düşürebilir. Bu kaynak artırımı farklı projelerde (inşaat/üretim vb.) kesin olarak süre düşürmeyi sağlayabilir ancak yazılım projelerinin özelliklerinden dolayı her zaman bu durum kesin değildir.

• Sabit Çalışma: Toplam fiili çalışma süresi sabittir. Fiili çalışma süresi görevin süresindeki veya birim çalışmadaki değişimden etkilenmez. Kişilerin çalışma yüzdesi artarsa görev süresi kısalır. Kişinin zamanının %50’ini harcayarak 40 saatlik çalışmayla ve 10 günde geliştirdiği ekran eğer zamanın %100‘ünü harcarsa yine 40 saatte ancak bu defa 5 günde tamamlanır. Çalışma birimi %25’e düşerse görev 20 gün sürer ancak bu durum fazla mesai yani maliyetin artması anlamına gelecektir.

Sıralanan bu durumların her zaman geçerli olduğu söylenemez. Örneğin sabit birim türünden 10 gün süren bir göreve 9 kişi ilave etmek süreyi her zaman 1 güne düşürmez. Proje yönetim yazılımlarının bu konuda yaptıkları otomatik hesaplar ancak kontrol edildikten sonra plana uygulanmalıdır. Kaynakların işlere atanması sonrasında bazı kaynaklar üzerinde birden fazla iş aynı zamanda çakışabilir. Bu durumda kişi veya diğer kaynak aşırı yüklenmiş olur ve bu durumda kaynaklardan verim alınamayacağı için aynı anda birçok işlem yapmak ile elde edilmeye çalışılan avantaj, dezavantaja dönüşebilir. Kaynak dengeleme, aşırı yüklü bir kaynağın iş yükünün yapılacak düzenlemeyle azaltılmasıdır. Aşırı yüklemeleri düzenlemek görevlerin önceliklendirilmesi önerilmektedir.

3. 3. 6. Maliyet Planı

Maliyet planı; yapılacak işler için gerekli maliyetlerin kullanılacak kaynaklara bağlı olarak plana eklenmesi, bütçeleme, harcama takvimi ve harcama kontrol işlemlerinin belirlenmesinden oluşur. Bir projede kaynakların arttırılması, işlerin daha ayrıntılı bir şekilde yapılabilmesi, zamanın kısaltılması gibi konuların hepsinde bütçe gerekli olduğundan maliyet planlaması diğer planları da etkileyen en önemli planlardan biridir. Bir yazılım projesindeki maliyet kalemleri aşağıda sıralanmıştır:

• Yönetim: Proje yönetiminde görevlendirilecek kişilerdır.

• Geliştirme Ekibi: Geliştirmede görevlendirilecek kişilerin istihdamıdır.

• Yazılım Altyapısı: Geliştirme, yönetim, test otomasyonları, veri tabanı, arayüz geliştirmek için kullanılacak hazır şablonlar, kendi yazılımını geliştirmek için kullanılacak olan platformlar gibi dışarıdan satın alınması gereken yazılımlar

• Donanım Altyapısı: Yazılım geliştirme ve çalıştırma ortamında gerekli sunucu, istemci ve ağ altyapıları

• Teslimat: Yazılımı müşteri ortamına kurmakla ilgili yardım belgesi ve kılavuzlar

• Test: Yazılımlar üzerinde gerçekleştirilecek olan kontrol faaliyetleri

• Bakım Destek Hizmetleri: Müşteriye garanti süresince sağlanacak destek, danışmanlık ve eğitim gibi hizmetler

• Diğer Giderler: Çalışma ortamı kurma, kırtasiye harcaması, seyahat vb.

3. 3. 7. Kalite Güvence Planı

Proje ve ürün için kalite gereksinimlerinin ve/veya standartlarının belirlenmesi ve projenin bunlara uyulduğunu nasıl göstereceğinin belgelenmesi için yapılan işlemlerin tümüne verilen isimdir. Tüm diğer planlarda olduğu gibi kalitenin planlanması da diğer unsurların planlanmasına bağlıdır. Örneğin belirlenen kalite standartlarına uyulması amacıyla üründe yapılması önerilen değişiklikler, maliyet ya da zaman çizelgesinde ayarlama yapılmasını ve planlar üzerindeki etkilerin ayrıntılı bir risk analizinden geçirilmesini gerektirebilir. Projelerdeki kalite planlamaları; “kalitenin planlanması”, “kalite güvencesinin sağlanması” ve “kalite kontrolünün izlenmesi” şeklinde üç kısımda incelenir. Genellikle aynı anlamda kullanılmakla beraber kalite güvencesi ile kalite kontrolü farklı kavramlardır. Kalite güvencesi, bir projenin daha başından itibaren kaliteli olması için yapılması gereken işlemlerin planlanması olarak düşünülebilirken kalite kontrolü, proje bittikten sonra projenin istenilen hedeflere uygun olup olmadığının belirlenmesi olarak ele alınabilir diğer bir deyişlebirinde ortada bir ürün yokken baştan hazırlık yapılmaktadır, diğerinde ise ortada hazır bir ürün mevcuttur ve belli şartlara uyup uymadığı analiz edilmelidir.

3. 3. 8. Test Planı

Yazılım testi, bir yazılımın gereksinimleri karşılayıp karşılamadığını, uygun şekilde hazırlanmış test senaryoları ile hata bulma amaçlı yapılan birim çalışmalarına verilen isimdir. Hiçbir yazılım hatasız olmadığından yazılım kalitesini ölçmek için test işlemi yapılması önemlidir. Yazılım testinin yapılma amaçları:

• İleriye dönük kodun geliştirilme masraflarını azaltmak,

• Ürün çalıştırılmadan önce kalitesini ölçmek,

• Yapılan hataların tekrarlanmasını önlemek,

• Zaman ve maliyet tasarrufu yapmak,

• Saygınlık kazanmak,

şeklinde sıralanır. Oldukça önemli bir husus olan testin ne şekilde, ne zaman, kim tarafından yapılacağı, kaç kez tekrarlanması gerektiği, bu süreçte manuel test mi otomasyon mu kullanılacağı, hangi yazılımlar üzerinde hangi testlerin gerçekleştirilmesi gerektiği gibi unsurları belirleyen plana test planı adı verilir.

3. 3. 9. Eğitim Planı

Yazılım, birçok parçadan oluşan karmaşık bir üründür ve birçok farklı özelliğe sahip olabilecek olan kullanıcıların yazılım hakkında teknik bilgileri bilmesi beklenmez. Bu yüzden yazılımı devreye almadan önce son kullanıcıya az da olsa bir eğitim verilmelidir. Büyük yazılımlarda son kullanıcıya sadece doğrudan kullanacağı alt sistem ve bunun ana sistemle ilişkisi konusunda eğitim verilebilir. Eğitim planı; eğitime katılacak kişiler, eğitimi verecek kişi, eğitim içeriği, yer, tarih ve süre bilgilerini içerir.

3. 3. 10. Devreye Alma Planı

Yazılımın devreye alma aşamasında izlenecek yöntem, görev alacak kişiler ve tarihlerin belirlendiği plandır. Devreye alma planı; eğitim, yazılım ve teknik altyapının kurulumu işlemlerini de içerir. Yazılım kısmı tamamen bitmesine rağmen, donanım teminindeki veya farklı konulardaki aksaklıklardan dolayı devreye girmesi geciken projeler görülmektedir. Örneğin devreye alma aşamasında sunucu odasında yeni makine koymak için yer olmadığı ya da o sunucuya uygun kablo teçhizatının bulunmadığı ya da yeterli sayıda ethernet bağlantısının bulunmadığı fark edilebilir. Bu durumda yeni bir oda, ağ ve elektrik altyapısı hazırlanması aylar alabilir. Devreye alma planlarında aşağıdaki bilgilerin bulunması beklenir:

• Altyapı yazılımları ve kurulacak yazılım bileşenleri arası ilişkiler

• Projenin çalışma ortamındaki donanımlar ve aralarındaki ilişkiler

• Donanımlar üzerinde yük paylaşımı

• Yedekli çalışma planı

• Kurulumu yapacak kişilerin görev ve sorumlulukları

• Kurulumda oluşabilecek sorunlar ve bunların çözüm yöntemleri

• Yedekleme ve test sisteminin kurulumu

 

Bölüm Özeti

•  Projelerde yapılacak işler, harcanacak kaynaklar, işlerin ne kadar zaman alacağı, ne kadarlık bir bütçe harcanarak tamamlanabileceği, bu işi gerçekleştirmek için bitmesi gereken diğer işler, bu işten faydalanabilecek olan diğer işler, işin gerçekleşmesini engelleyebilecek olan risk unsurları vb. konuların ele alınması, belirlenmesi ve organize edilmesine plan adı verilir. Bir projede plansız hiçbir işlemi yapmak doğru değildir çünkü plansız olarak başlanan iş büyük ihtimalle sonradan sıkıntılar çıkartacaktır. Bu sıkıntılar kaynak yetersizliği, zaman ve maliyet tahminlerinin tutmaması, fizikî sorunlar, donanım temini ile ilgili sorunlar, proje ekibinde yaşanabilecek sorunlar gibi birçok kategoride ele alınabilir. Proje planlaması içerisinde ayrık olarak kapsam planı, entegrasyon planı, risk planı, zaman planı, kaynak planı, maliyet planı, kalite güvence planı, test planı, eğitim planı ve devreye alma planı gibi planlar bulunabileceği gibi tüm işler tek bir plan üzerinden gerçekleştirilip bu kısımlar birer bölüm olarak da düşünülebilir. Proje planlamasında dikkat edilmesi gereken en önemli husus her unsurun diğer unsurları etkilemesinden dolayı her planın diğer planlardan etkilenebileceğinin unutulmamasıdır. Projedeki plan türleri aşağıda kısaca açıklanmıştır.

▶ Kapsam Planı: Projede yapılacak (ve yapılmayacak) temel işlerin ve bu işlerin içeriklerinin belirlendiği, proje sınırlarının çizildiği plandır.

▶ Birleştirme Planı: Geliştirilen projelerde yapılan işlerin, kaynakların, hedeflerin başarılı bir şekilde birleştirilmesi için yapılan plandır.

▶ Risk Planı: Bir projenin başarılı bir şekilde tamamlanması için yapılması gereken işlemlerin yapılmasını engelleyebilecek olan risklerin tanımlandığı plandır.

▶ Zaman Planı: Görev projeyi zamanında tamamlayacak şekilde oluşturmayı hedefleyen plandır.

▶ Kaynak Planı: Projede hangi kaynaklara ne zaman ihtiyaç duyulduğunun belirlendiği plandır.

▶ Maliyet Planı: Yapılacak işler için gerekli maliyetlerin eklenmesi, bütçeleme, harcama takvimi ve harcama kontrol işlemlerinin belirlenmesini gerçekleştiren plandır.

▶ Kalite Güvence Planı: Proje ve ürün için kalite gereksinimlerinin ve/veya standartlarının belirlenmesi için yapılan plandır.

▶ Test Planı: Bir yazılımın gereksinimleri karşılayıp karşılamadığını, uygun şekilde hazırlanmış test senaryoları ile hata bulma işlemini gerçekleştiren plandır.

▶ Eğitim Planı: Kullanıcılara verilecek eğitimin özelliklerinin belirlendiği plandır.

▶ Devreye Alma Planı: Yazılımın devreye alma aşamasında izlenecek yöntem, görev alacak kişiler ve tarihlerin belirlendiği plandır.

 

Kaynakça

Barutçugil, İ. (2008). Proje Yönetimi. Kariyer Yayınları.

Goldratt, E. M. ve Cox, J. (2006). Amaç. Optimist Yayın Dağıtım.

Project Management Institute (2017). A guide to the Project Management Body of Knowledge (PMBOK guide).

Türkan, Y. S. (2015). Proje Yönetiminde Planlama ve Kontrol Teknikleri. Doğu Kütüphanesi Yayınevi.