Evet, Büyük Veri Yaşam Dönküsü ve Proje Yönetimi başlıklı bir videomuz var. Şimdi amacımız aslında büyük veri dünyasında proje yönetimi nasıl değişmektedir? Proje yönetimi dünyası büyük veriden etkilenmiş midir?
Big Data, yani büyük veriyle kastettiğimiz şey Big Data kavramıyla proje yönetimi arasında nasıl bir ilişki vardır? Bunları biraz irdelemek. Dolayısıyla proje yönetimi, klasik proje yönetimi yöntemlerinin Big Data olan büyük veri olan dünyalar nasıl değiştiğine biraz bakacağız. Ve ayrıca proje yöneticilerinin big data olan dünyada nasıl fırsatlar elde ettikleri, dikkat etmeleri gereken yeni konular nelerdir bu konulara biraz bakmaya çalışacağız literatürün oluştuğu kadarıyla. Bu videoyu 3 aşamadan ibaret planladım.
Kısa kısa tutmaya çalı��tığım için birincisi yani tek bir video böyle yarım saatte 45 dakikalık da çekilebilirdi ama 3 ayrı seriyle çekeceğim. İlk aşamada proje yönetimi yaklaşımlarından, Software Development veya Systems Development Life Cycle'dan bahsedeceğim, SELC'den. Ve genel anlamında bir proje yönetimi yaklaşımlarını toparlayan, yazılım proje yaklaşımlarını toparlayan bir video olmasını hedeflerim. Başka amaçlar için de kullanılabilir. İkinci aşamada büyük veri kavramını açıklamaya çalışacağım.
Big Data nedir? Big Data'nın kendi bir life cycle'ı var, yaşam döngüsü var. Büyük veri yaşam döngüsü diye literatüre girmiş Big Data Life Cycle, ondan biraz bahsedeceğim.
Ve üçüncü videoda da büyük veri dünyasında proje yönetimi nasıl olmaktadır, nasıl değişmektedir. Yani aslında ilk iki videoda çektiğimiz Software Development Lifecycle ve ona bağlı olarak diğer proje yönetim yöntemleriyle büyük verinin yaşam döngüsü arasındaki ilişkiyi kurup burada bize nasıl fırsatlar doğmaktadır, nasıl tehditler vardır. Hani klasik SWOT analizi, güçlü yanlarımız, zayıf yanlarımız, fırsatlar ve tehditler nelerdir.
Bunlara birazcık bakmaya çalışacağız. Şu anda dünyada da gerçek hayatta da işlemekte olan projelerden biraz bahsetmeye çalışacağız. Bu Big Data Life Cycle'ı anlatırken de daha detaylı anlatacağım. Bu kelime, bu terim farklı firmalar tarafından farklı şekillerde algılanıyor.
Dolayısıyla henüz oturmuş bir literatür yok. Farklı firmaların bakış açılarını da anlatmaya çalışacağım. Şimdi bu videodaki işimiz... Proje yönetimi yaklaşımlarını şöyle genel olarak anlatmak. Software Engineering alan arkadaşlar varsa, bir yazılım mühendisliği kavramı veya proje yönetimi kavramlarını bilen arkadaşlar varsa bu videoyu geçebilirler.
Ben hiç bilmeyen birisine konuyu anlatmak gibi bir misyonla yola çıktığım için birazcık Software Development Lifecycle'dan bahsetmek istiyorum. Yazılım dünyasında kullanılan yaklaşımlar nelerdir? Şimdi Software Development Lifecycle denilen şey aslında bir spiral yaklaşım, şöyle bir döngü şeklinde olan bir yaklaşım. Aşamalarına baktığımızda planlama, tanımlama, defining şeklinde geçen tasarım, dizayn, geliştirme, entegrasyon ve testlerden oluşan bir aşaması var.
Uygulama ve bakımdan oluşan 7 aşama sayılabilir. Bunu farklı kaynaklarda farklı adımlara bölüyorlar. Yani 10'a kadar çıkartan adım sayısını veya işte 4'e 5'e kadar indiren kişiler var. 6, 7 gibi sayılar var.
Burada 7 aşaması görülüyor. Kaynağa göre değişebilir dediğim gibi özelliği ama anlatmak istediği şey aslında aynı. Yani bir döngü içinde, hayat nasıl bir döngü içindeyse, yani işte hepimiz hayatın içinde belli döngülerde yaşıyorsak, varlığımız bile değil mi?
İnsanların varlığı bile işte doğuyorlar, yaşıyorlar, ölüyorlar, sonra toprak oluyor, sonra tekrar oradan başka bir canlı çıkıyor. Canlılık bile böyle bir döngü içinde, hayat böyle bir döngü. İşte yağmurlar yağıyor, sular birikiyor, bunlar buharlaşıyor, tekrar bulut oluyor, tekrar yağmur yağıyor, bir döngü var. Dolayısıyla bu aslında... SDLC'nin de bize anlattığı yazılımın da böyle bir kendi doğal yaşam döngüsü olduğu ve bu döngünün de doğru analiz edilmesi durumunda, doğru kontrol edilmesi durumunda başarıya bizi götüreceği.
Buna Software Development Life Cycle deniliyordu ilk başlarda. Yani yazılım yaşam döngüsü olarak kabul ediliyordu. Literatüre yazılım dünyasını kazandırdı bir yaklaşım.
Fakat Systems Development Life Cycle ismi daha çok kullanılmaya başlandı. Aslında her sistemin... geliştirilmesi için kullanılan yani sadece yazılım sistemleri değil bütün sistemlerin geliştirilmesi için kullanılan bir yapıya sahip SDLC. Dolayısıyla herhangi bir sistemi sadece yazılımı düşünmeyin.
Herhangi bir sistemi geliştirirken de bu yaşam döngüsüne bakmakta fayda var. Mesela bir diyelim ki şehir şehircilik yapıyorsunuz. Bir şehir inşa edeceksiniz. İnşaatlar yapılacak değil mi? Onun işte altyapıları var.
Ve bu yaşayacak bir organizma aslında şehir. Dolayısıyla Tabii ki orada yıkılan binalar olacak, tekrar yerine yenileri yapılacak ve bu döngünün nasıl kontrol edileceği önemli. Benzer şekilde başka örneklerde bulunabilir.
Buradaki aşamalara baktığımızda birincisi ne istediğimizi bir planlamamız gerekiyor. Bir plan aşaması var. Bu plan aşaması aslında proje yönetimlerinin en önemli aşamalarından birisi. Hepsinin de başlangıç aşaması denilebilir. Türkçede de plan olarak geçiyor malum.
Aslında işin projelendirildiği, fikrin ortaya çıkarıldığı, fikrin tartışıldığı aşama. Sonra da bunun tanımlarının yapıldığı aşamaya bakıyoruz. Genelde burada işte istenilen şeyin ne olduğu.
temel tanımlar, üzerinde konuşulacak kavramların temel olarak tanımlandığı aşamalar. Çünkü aynı şeyden bahsedilmiyorsa farklı sonuçlara varılabilir. Ve bu tanımlar üzerine bir tasarım var.
Bu aslında analiz aşaması olarak da düşünülebilir tanım aşaması. Problemin tanımlandığı veya yaşam döngüsünün tanımlandığı veya sistemin veya yazılımın tanımlandığı aşama bu tanım aşaması sırasında Bir analiz de yapılıyor olabilir. Yani neler istendiğiyle ilgili analizlerin olması da söz konusu olabilir. Sonra tasarımın yapıldığı bir aşamaya geçiyoruz.
Yazılımımız veya sistemimizin tasarımları yapılıyor. Projeleri çiziliyor. İnşaat projeleri gibi düşünülebilir.
Elektrik devrelerinin projeleri gibi düşünülebilir. Yazılımın da bir projesi var. Projeler çiziliyor.
Sonra da geliştirme aşamamız var. Yani bunu kodlama olarak da düşünebilirsiniz. Veya aslında sistemin yaşatılmaya başlandığı, ilk örneklerinin çıkmaya başladığı aşama. Entegrasyon ve testlerimiz var. Burada sistem artık hayata geçiriliyor.
Hayat içinde bir yer ediniyor. Bir şirkette kullanılacak bir yazılımdan bahsediyorsak şirkette ilgili birimlerin bu yazılımla ilgili eğitimlerin alınmasından tutun. Donanımlarının temin edilmesi, bağlantılı olduğu birimlerin buna entegre edilmesi, başka yazılımlarla bir entegrasyonu varsa bunun sağlanması, veri tabanı bağlantıları gibi pek çok aşama burada ele alınıyor. Sonra da uygulamaya geçiliyor, canlıya geçiliyor.
Artık yaşayan bir proje haline geliyor entegrasyon bittikten sonra. Kullanılıyor, problemler çıkıyor, yeni fikirler ortaya çıkıyor, yeni ihtiyaçlar ortaya çıkıyor. Ve bunlar değerlendirmelere alınıyor.
Bakımları yapılıyor tabii projenin değişik aşamalarda bu problemlerin çözümü yapılıyor. Ve yeni planlar ortaya çıkıp yeni tanımlar, yeni tasarımlar şeklinde proje hiçbir zaman bitmiyor. Yani bu yazılım işte bir üründür, tüketim ürünüdür.
Belli bir yaşam süresi vardır, belli bir süre sonra tükenir, biter. Her ürün gibi bir sarf malzemesi gibi düşünülebilir diyen bir akım var. Bunun yanında yazılım bir mühendislik projesidir.
Üretilir ve kalıcı olması beklenir. İşte uzun yıllar boyunca yaşaması beklenir. Belki hiç müdahale edilmeden, çok ufak müdahalelerle yaşanması beklenen bir yaklaşım var.
Software Development Lifecycle bunun biraz ortasında. Yani aslında evet... Bir mühendisliği bu işin yapılıyor. Bu işin bir planlaması, bir proje yönetimi var.
Ve uzun yıllar boyunca biz yazılımımızın yaşamasını istiyoruz. Ama bu yazılımın hayatını devam ettirebilmesi için belli aralıklarla ufak da olsa dokunuşlar yapılması, düzeltmeler yapılması gerekiyor. Software Development Lifecycle işte tam da bu noktada duruyor. Bu dokunuşların nasıl yapılacağını organize ediyor.
Siz bir proje yönetimi açısından baktığınızda belli aşamalardan geçtikçe biriktirdiğiniz birikimleri bir sonraki aşamada kullanmaya başlıyorsunuz. Yani mesela biz geliştirme sırasında yeni bir fikir aklımıza geldi. Ne yapacağız? Geri dönüp tanımları değiştirecek miyiz?
Tasarımı değiştirecek miyiz? Bir problem ortaya çıktığında. İşte Software Development Lifecycle bize biraz bu bilgiyi veriyor. Yani sen geliştirme aşamasına girdikten sonra, kodu geliştirip entegrasyona başladıktan sonra, Senin tanımınla ilgili bir hata ortaya çıktıysa iki ihtimalin var. Ya projeyi tamamen iptal edersin, tekrar planlamaya geri dönersin ve buradan aşamalara devam edersin.
Ya da buradaki bir entegrasyonunu yapar, projene devam edersin, uygulama bakım bittikten sonra ikinci döngünde planlama aşamasından bu bilgiyi alıp devam edersin. Dolayısıyla buradaki aslında dairesel yapı doğrusal bir yapıyı da ifade ediyor. Yani bu dairedeki... adımlar arasında bir atlama beklemiyoruz.
Ya döngüyü döneceğiz ya da bir problem varsa projeyi iptal edip tekrar baştan başlanılacak. Genelde döngünün dönülmesinin daha hayırlı olduğu yönünde çok böyle major, çok büyük bir hata, çok büyük bir problem yoksa döngü dönüyor. Bir sonraki adımda bunlar düzeltiliyor. Çünkü aslında biliyorsunuz şeyler de, kurumlar da öğreniyor. Bu yazılım kültürü denilen bir kültür var.
Bir firmanın kendi yazılımını geliştirmesi için. gereken bir kültür veya yazılımı geliştirmeyip satın almak için gereken kültür de aslında aynı yazılım kültürü. Yani siz, ya ben hiç yazılım yazdırmaktan, yazılım analizi yapmaktan, yazılımla ilgili problemleri çözmekten zevk almıyorum. Bununla ilgili hiçbir tecrübem de olmasın. Başka birisi gelsin yazsın bana ben kullanayım diyorsanız aslında çok da farklı şeylerden bahsetmiyorsunuz.
Bunların hiçbirinden kurtuluşu yok. Bu tam istediğiniz gibi bir şey. Özel bir yazılımdan bahsediyoruz tabii. istiyorsanız bunu kullanmanız lazım.
Ancak böyle şeyler nerede olur? İşte ofis programları gibi basit programları alırsınız, kullanırsınız. Onun da ne kadarını kullanacağınızı siz seçmişsinizdir. Orada şablon bazı problemler vardır. Onların çözümleri vardır.
Onları alır kullanırsınız. Ama Özel bir probleminiz olduğunda onlar için de ya pluginler satın almanız gerekiyor ya özel yazılımlar yazdırmanız gerekiyor ya da o dünyaya siz uyuyorsunuz. Böyle çok genel problemler için paket programlar yazılıp satılabiliyor ama özel problemlerimiz için hala işletmelerin kendi yazılımlarını yazdırma eğilimi devam ediyor.
Software Development Lifecycle'da aslında bu dünyanın bir parçası. Bunu bir paket programı için kullanabilir miyiz sorusu belki bu sözden sonra dünyaya akla gelebilir. Evet mümkün paket programlarda da aynı şey var. Yani böyle CODES diye geçen Customs on the Shelf şeklinde paket olarak satın alınan yazılım, Office yazılımı gibi Windows yazılımı, işletim sistemleri yazılımları gibi yazılımlar içinde bir Development Life Cycle söz konusu.
Burada tabii Development Life Cycle'da yapılan planlama binlerce kişinin, belki milyonlarca kişinin kullanacağı yazılımlar için yapılıyor. Tanımlama, tasarımlar bunun için yapılıyor. Ve burada toplanan bilgiler, uygulamalar, testler, entegrasyonlar belki şu an ben bu videoyu çekerken Windows 10'un dağıtım süreci devam ediyor.
Henüz daha çoğu ekran kartı driverları bile yüklenmemiş durumda. İnsanlara bunları veriyorlar. Bu tabii bir test sürecinin parçası. Bu test sürecine gelmeden önce de çok sayıda testler yapılmıştır mutlaka. Oradaki testler, yazılım geliştirme süreçleri biraz daha farklı işliyor.
Ama o da bir yazılım geliştirme... yaşam döngüsü olarak düşünülebilir. Avantajlarına bakalım nelerdir?
Birincisi riskimizi düşürücü bazı özellikleri var Software Development Lifecycle'ın. Bir sonraki aşamada problemin düzeltilmesi mümkün olabiliyor. İterasyonda gerçek dünyaya biraz daha yaklaşmış oluyoruz.
Gerçek dünyadaki problemlerin, geliştirme süreçlerimize dahil edilmesi söz konusu. Bilginin Enformasyonun sistematik analizi söz konusu. Enformasyonu sistematik olarak analiz edebiliyoruz.
Plan aşamasında, analiz aşamasında, tasarım aşamasında bir problem çıktığında nerede çıktı, yeni adımda eklenecek şeylerin hangi adımda eklenmesi gerektiği ortaya çıkabiliyor. Modüler bir yaklaşım uygulanabiliyor. Bir modüldeki problemin diğer modüllere yansımaması söz konusu.
Veya bir problemin bir modülün tamamen iptal edilebilmesi söz konusu. Bir yukarıdan bir bakış, high level view. sağlıyor. Yani yukarıdan bir bakış sağlıyor. Problemi yukarıdan görebiliyoruz.
Proje yönetimine yukarıdan bir bakışımız söz konusu. Kalite yönetimi aşamaları entegre edilebiliyor adımlar arasına. Adımların çıktığı ölçülebiliyor. Bir sonraki aşamaya geçmeden önce o adımın belli kalite standartlarını sağlaması.
Mesela diyelim ki şurada tanımlama bitti. Tanımlama bittikten sonra tasarıma geçilecek. Şimdi tanımlama aşamasındaki bir problem tasarıma da taşınacak demektir. Bu da tabi dezavantajlarından birisi. Bunun taşınmaması için tanımlama aşamasından sonra belli kalite standartları konulup, kalite testleri geçtikten sonra çıkan raporla ilgili tasarıma geçilmesi söz konusu olabilir.
Daha kaliteyi arttırıcı şeylerimiz var. Dinamik bir ortam, sürekli yaşayan, sürekli dönen bir ortam. Dolayısıyla dinamik ortamlar için uygun.
Yani bir proje yapacağız biz, işte mesela bir inşaat projesi yapacağız. 100 yıl boyunca o inşaatın kalmasını istiyoruz. Şimdi bu çok dinamik bir proje değil ama yazılım projeleri biliyorsunuz çok kısa. sürelerde çok büyük değişikliklere tabi tutuluyor.
Dolayısıyla SDLC burada bir avantaj sağlıyor. Dezavantajlarına baktığımızda birazcık uzmanlık gerektiren bir proje. Yönetimiyle ilgili belli tecrübelere ihtiyaç var.
En azından bir uzmanın belki projeye dahil edilmesi hız kazandırabilir. Hiç bilinmeyen birisi kullanabilir mi? Kullanabilir ama tabii bunun bir maliyeti var. Değişik problemlerle karşılaşılacaktır. Bu maliyetler göze alınmalı.
Büyük sistemler için genelde uygundur. Şimdi ufak bir proje yazacağız. Mesela diyelim ki bir hesap makinesi programı yazmak istiyoruz.
İşte bilgisayar programlamaya giriş dersinde buna benzer uygulamalar yazdırılıyor değil mi belki? 3-4 saat içinde bir programcı, iyi bir programcı bir hesap makinesi yazabilir. Şu Windows'daki Calculator'ı düşünün, hesap makinesini.
Bunun için Software Development Lifecycle'ı uygulamak gerekli mi? Çok da gerekli değil. Yani o hesap makinesiyle ilgili yeni neler istenebilir ki? İşte 4 işlem yapan bir hesap makinesi istenilirse bitti.
Hadi buna bir ileride scientific özellikler ekleyelim derseniz. Ayrı bir proje olarak ele alınabilir. Bunun analizlerinin yapılması, tasarımlarının yapılması, kalite standartlarının belirlenmesi falan mümkün mü? Mümkün. Yapılabilir mi?
Yapılabilir. Ama belki 3 saatlik proje 1 aya, 1,5 aya çıkabilir. Bu bütün aşamalar geçildikten sonra, çok detaylı bir proje yapıldıktan sonra.
Değer mi sorusu var. 3 saatlik bir projenin maliyeti belki bir programcının yazdığında 100-150 liraysa, bunu 1 aya çıkarttığınızda çok çok daha büyük, 10 bin, 20 bin, 30 bin liralık. Bütçelerden bahsedeceğiz. Değer mi?
İşte o soru birazcık proje yönetimi, oradaki risk algıları ve şeyle. Belki ufak bir proje çok kritik bir noktada kullanılıyorsa, yani böyle bir nükleer başlığı bağlayacaksanız, belki 3-5 rutinden de oluşsa, o zaman değer belki ama işte hesap makinesi yazılacak, onun için değer mi sorusu da ayrı bir soru. Dolayısıyla genelde...
bir şey olarak kalıp olarak söyleyecek olursak bu tartışmanın neticesinde büyük sistemler için daha uygun bir yaklaşım. Adım testleri atlanır. Burada her adımın sonunda test yapılması mümkün.
Yani şu adımlardan sonra bir tanımlama yapıldı. Bununla ilgili bir prototip oluşturup test yapılması, maket uygulamalar yapılması, müşteriyle bunların tartışılması, başarı kriterlerinin belirlenmesi mümkün. Fakat SDLC'de bu adımları göremiyoruz.
yöntemlerde var bu. Birazcık hızı arttırmak açısından getirilen bir şey. Bir de şuna güveniyor SDLC.
Bir life cycle olduğu için bir sonraki dönüşte bunu kullanabilme özelliği olduğu için buna güveniyor. Ama bunların adım adım test edilmesi mümkün. Ve hatanın devamı engellenemez.
Yani burada karşılaşılan bir hata ancak bir sonraki döngüde ele alınıp çözülebilecek. Dolayısıyla tanımlamadaki hata tasarım o geliştirmeyi o entegrasyon testlerine kadar taşınmak zorunda. Böyle bir yaklaşım. Şimdi SDLC'nin diğer yöntemlerle SDLC'nin içinde kullanılan modeller olarak düşünülebilir bunlar. Aslında burada bir life cycle var ama burada işte geliştirme aşamaları var, entegrasyon aşamaları var.
Birazdan diğer proje yönetim metotlarını anlatacağım. Bunlar ayrı birer proje metodu yöntemi olarak algılanabileceği gibi SDLC'nin içinde kullanılan alt proje yönetim modülleri olarak da düşünülebilir. Dolayısıyla Life Cycle olarak düşündüğünüzde, bir yaşam döngüsü olarak düşündüğünüzde, bu yaşam döngüsünün içinde çok farklı metotlarla geliştirilmiş birden fazla projeden bahsediyor olabiliriz. Bunlar geliştirilmeye devam ediyor olabilir.
Siz yaşam döngünüzün içinde bunların hepsini ele alıyor olabilirsiniz. Veya tamamen bağımsız birer proje yönetimi sistemi olarak da düşünülebilir. Waterfall model, Phantom modeli anlatacağım.
Onu yazmamışım. V-shaped model, incremental model şeklinde birkaç modelden bahsedeceğim. Şimdi bizim proje yönetimi modelleri genelde işte bu şelale modeliyle başlar.
Software engineering alan arkadaşlar bilirler. İlk anlatılan modellerden birisi budur. Proje yönetimi, yazılım proje yönetimi dersleri de şimdi başladı.
Şelale modeli aslında daha eskilerden, 70'lerden, 80'lerden gelen, hatta daha öncesinden gelen ve böyle çok daha statik, mesela bir çelik endüstrisiyle ilgili bir fabrika kuracaksınız. Şimdi bunu kurduktan sonra belki 100 yıl boyunca o fabrikanın işlemesini istiyorsunuz. Veya bir inşaat yapacaksınız uzun süreler. Bir baraj yapacaksınız, bir köprü yapacaksınız değil mi? Mesela İstanbul'da işte Boğaziçi Köprüsü yapıldı.
İşte onlarca yıldır hiç ellenmiyor. Yeni şeyler, geçenlerde bir trafiğe kapattılar. Şeylerini değiştirmek için, bağlantılarını değiştirmek için.
Yıllardır hiç ellenmeyen bir proje. Bu projeler için uygun bir model, şelale modeli. Ama yazılım dünyası böyle değil. Yani biz bir köprüyü işte... 50 yılda bir kere 50 yelim diyebilirken bir yazılım projesine belki her 5-10 dakikada yeni bir istek gelebiliyor.
Şimdi şelale modeli burada bu Güveni getirdiği ve yazılım projelerinde ilk başta bunlar uygulanmaya çalışıldı. Yazılım projelerinde biz şelale modeliyle ele alalım. Dolayısıyla daha bir sistematik yaklaşımımız olsun dendi. Tabii hiç sistem olmamasına göre iyi bir yaklaşım ama en kötü yaklaşımlardan birisi onu söyleyebilirim. Nedir aşamaları?
Planlamayla başlanıp işte analiz yapılıp projenin analizleri genelde analizler ikiye ayrılıyor. Bir durum analizi işte şu an elimizdeki kaynaklar nelerdir? Ne kadar? Mesela Windows ortamında mı geliştirilecek, cep telefonlarında çalışacak mı gibi bazı analizler.
İster analizler bir de. Requirement analizisi denilen, yani ne istiyoruz, onunla ilgili analizlerin yapılması, fonksiyonel özelliklerin içerilmesi vs. Tasarımlarının yapılması, bu analizlere göre, planlamaya göre belli tasarımlar yapılması. İşte yazılımın ekranlarının tasarlanması, fonksiyonel özelliklerin tasarlanması.
Bu tasarım aşaması biraz tabii... Geniş bir aşama, ayrı detaylı bir aşama. Mesela nesne yönelimi tasarım, nesne yönelimi bir ortamda kullanılıyorsa belki use case'lerin çizilmesi, class diagramlarının hazırlanmasına kadar giden tasarım aşamaları var. Sonra uygulamaya geçilmesi.
Bu uygulama implementation'ın Türkçesi olarak uygulama ama yani kodlama olarak düşünülebiliriz. Development. Burada tabii gene bir sürü alt aşamasından bahsedilebilir. Uygulama aşamasındaki testler, uygulama aşamasındaki... Tasarım yanlışları, analiz yanlışlarına geri dönülmesi.
Sonra sistemin genel olarak test edilmesi ve müşteriye teslim edilmesi aşamaları. Yani bu uçtan başlayıp şu ucu ulaşana kadar aslında sisteme çok dokunma şansımız yok. Ancak yeni bir şey yapılacaksa tekrar planlamaya girilip yeni bir proje olarak ele alınıyor.
Uzun süren projeler için çok ciddi bir tehdit. Çünkü düşünün bir proje bir yıl iki yıl sürüyorsa şayet... 1-2 yıl boyunca bu projenin hangi aşamasındaysa o aşamasının bitmesini beklemek zorundasınız. Müdahale etme şansınız yok. Az önce de söylediğim gibi bilişim projeleri için çok uygun bir yönetim sistemi değil.
Ama en basit, en etkili ve hepsinin temeli olan yöntem olduğu için bilmekte fayda var. Ve yine küçük projeler için de uygulanabilir. Yani nispeten küçük diyelim projeler için de uygulanabilir bir modeldir.
Size en azından hangi aşamada hata var, kimden problem kaynaklanıyor. veya işte nerede problemi çözebiliriz gibi bilgileri de verir. Genelde burada geri dönüşler de söz konusudur.
Yani tasarımda bir problem olduğunda analize, uygulamada bir problem olduğunda tasarıma dönülmesi gibi şeyler söz konusudur. Tabii hataların maliyeti giderek artar. Yani analiz aşamasındaki bir hatanın düzeltilmesi çok daha düşük olurken bu problem testte yakalanırsa tekrar analize dönülüp bunun telafisi tekrar bütün süreçlerin belki ele alınmasını gerektiriyor ve maliyet artışını...
beraberinde getiriyor. Bu Fıskiye modeli birazcık waterfall modele öykünerek oluşturulmuş bir model. Henderson, Sellers ve Edwards tarafından geliştirilmiş.
Referansını da verelim. Şöyle bir yaklaşımla farkı var waterfall'dan. Cycle'ları var.
Yani döngüler şeklinde her bir aşamada belli döngüler elde ediyor. İşte tasarım aşamasında tekrar koddan tasarıma dönülmesi, tasarımdan requirement specifications'lara ister analizlerine dönülmesi, analize dönülmesi, operasyona geçtikten sonra testlere geri dönülmesi. İşte burada maintenance ve evaluation denilen de iki ayrı aşamadan yani bir bakım ekibiniz var belki bakımla uğraşıyor. Bir de evaluation ekibiniz var.
Bunu değerlendiriyor. Yazılımla ilgili yeni kriterleri belirliyor. Böyle bir model de söz konusu ama bakın gördüğünüz üzere burada da işin özünde waterfall modeldeki adımları görüyoruz.
Aslında çok oturmuş adımlar. V-shape model'a baktığımızda V şeklinde olan modelimiz böyle bir V şekli oluşturduğu için adımları V-shape model deniliyor. Aslında waterfall modeli de benzer fakat şöyle bir farkı var ondan bahsedeceğim. Gene planlama, ihtiyaç belirleme, üst seviye ve alt seviye yani low level ve high level tasarımlar var burada. Üst seviyede daha genel bir bakışa göre tasarım yapılıyor.
Mesela da böyle DFT veya DFT level 0, level 1 şeklinde giden data flow diagramlarda ve antistrategic diagramları. bilen arkadaşlar için söyleyeyim, daha üst seviyelerde yapılan tasarımlar ve bunların sonra daha detaylı tasarımlarının yapıldığını görebiliyoruz. Daha alt seviyelerinin açıldığını, bunların hatta girdilerinin çıktılarını, beklentilerinin yazıldığını söyleyebiliriz. Neticede kodlamaya geçiyor.
Şimdi buraya kadar bir waterfall durumu söz konusu. Yani aşağıya doğru bir akan veri, akan bir proje yönetimi söz konusu. Fakat buradan sonra yukarı doğru çıkıyoruz. Bunun sebebi şu, önce adımlara bakalım. Birim testleri yapılıyor, unit testler, her üretilen modülün testi yapılıyor.
Sonra bunların birbiriyle çalışma durumu, entegrasyon testleri, kabul testleri, müşterinin kabul edip yetmemesiyle ilgili müşteriye gidiliyor, müşteri uygulamayı test ediyor ve sonra bakım ve maintenance başlıyor. Şimdi burada aynı seviyede olan şeyler var, kutular var. Mesela bakın detaylı tasarım yapıldı.
Hemen karşısında kodlama bittikten sonra birim testleri yapılıyor. Yani o yapmış olduğumuz tasarıma ait testler yapılıyor. Sonra üst seviye tasarıma ait entegrasyon testleri yapılıyor.
O her bir alt modülün birbiriyle uyumlu çalışıp çalışmadığı, üst seviyede modül olarak geçen her şeyin entegrasyon testlerinde. İhtiyaç analizlerini müşteriden istemiştik, nelere ihtiyacımız olduğunu çıkartmıştık. Bunların kabul testleri yapılıyor.
Evet o ihtiyaçlar sağlandı ve evet işte... tamamdır, uygundur şeklinde. Onunla ilgili test senaryoları hazırlanıyor.
Tabi testlik ayrı bir dünya. Senaryoları hazırlanıyor. Bunların belli örnek müşteri, şey kullanıcılar üzerinde testleri yapılıyor.
Sonra daha genelleştirilmiş testleri. Bu test işi başlı başına bir iş. Biz sadece test yapılıyor deyip geçelim. Planlamanın da sonra bakım aşamasında karşılığını görüyoruz.
Yaptığımız planlamaya uygun mu? Bakım aşamasından gelen bilgilerle bunu besliyoruz. V-shape model aslında Birazcık daha şöyle bir alta inip yukarı çıkan ve her aşamasının karşılık bulduğu, evet bir şey yaptık ama bunun karşılığı doğru mudur sorgulamasının yapıldığı, en alta kadar inip kodlamaya kadar inip sonra da yukarıya doğru sistemi taşıyan bir yapıya sahip V-shape modeli. Arttırımlı model, incremental model veya iterative model diye de geçer bazı kaynaklarda. Şöyle bir iterasyon söz konusu burada.
Bir döngü söz konusu. İterasyona tabii Türkçe'de ne denir o da ayrı bir tartışma ama. İterasyona.
Şöyle başlıyor sürecimiz. Planlama aşamasıyla başlıyoruz. Bu planlamalardan geçilip sonra planlamanın ardından bir döngüye giriyoruz.
İşte burada ister analizleri, analiz ve tasarımlar yapılıyor. Uygulamaya geçiliyor. Uygulamadan sonra iki şey oluyor.
Birincisi canlıya geçiş durumu söz konusu. Ve deploy ediliyor. Ve tabii problemler var burada. Ama bu problemler testlerin birer parçası olarak görülebilir. Bir yandan da testlerimiz devam ediyor.
Ve bu sistem, bu şeyler, problemler sistemi besliyor. Sonra tekrar değerlendirmeye tabi tutuluyor bu gelen bilgiler, testlerden gelen ve canlıdan. Sonra tekrar istaranizleri analizler ve tekrar canlıya bir bilgi verilmesi.
Ve tekrar testler değerlendirme ve tekrar canlıya bilgi verilmesi. Bu sırada planlamada değişiklikler olabiliyor tabii. Çünkü neden değişiklikler olabiliyor? Çünkü şirket...
Mesela bir şirkete yazdınız, bir tekstil firmasına yazdınız. Tekstil firmasının iş süreçleri değişiyor. Bir de web sayfası üzerinden satış yapalım diyorlar.
Web sayfası ile ilgili belki yeni ihtiyaçlar gelmeye başlıyor. Bir yandan yazılımın çalışan haliyle ilgili problemler ortaya çıkıyor. Orada şu modüle şunun ekranı da ekleyelim gibi, felanca raporu da alalım gibi şeyler çıkmaya başlıyor.
İşte bütün bunlar bu incremental model'de her seferinde arttırıla arttırıla. bir iterasyon şeklinde devam ediyor. Sürece dahil ediliyor. Bu da incremental model.
Biraz hızlanıyorum. Vaktim uzadığının farkındayım. 10 dakika demiştim. Yine uzattık lafı.
Hemen hızlanalım. Spiral modelimiz de son anlatacağımız model. Bunun da şöyle bir yapısı var. Dörde böldüğünüzü düşünün.
Bölgeleri. Şu resmin alt tarafı çıkmamış. Onu alalım yukarı.
Şöyle başlıyor spiral olarak. Bakın şu aşamaya kadar böyle bir spiral içinde dönüyoruz. Ve bu dönme sırasında prototipler çıkartıyor.
Aslında ondan bahsetmedim. Prototype model var. RAD denilen Rapid Application Development denilen başka yöntemler var. Genel hatlarıyla şeylerden bahsetmeye çalışıyoruz. Tek videoda tabii normalde bu bir dönemlik belki bunun hakkında bir bölüm kurulabilir.
Yani Software Engineering diye bölümler var değil mi? O bölümün altında her şey anlatılabilir. Tabii üstün körü birazcık geçiyoruz hızlıca ama...
Genel olarak bilmeyen birisine yazılım projeleri nedir, software engineering nedir, proje yönetimi nedir bununla ilgili bilgiler vermek amacımız. Şimdi burada prototipler çıkıyor. Prototipler nelerdir?
Maket uygulama diye Türkçe'ye çevriliyor veya prototip diye çevriliyor. Ufak bir uygulamayı gösteriyorsunuz. Onun üzerinde müşterinin, yazılımı kullanacak kişinin fikir sahibi olması daha mümkün. Şurası olmamış, böyle istiyorduk ama biz bunu istemiyorduk deme şansı daha da yüksek. Dolayısıyla bu prototip çıkartma işlemi şöyle el alınıyor.
Bir defa isterler belirleniyor. Operasyonla ilgili fikir sahibi olunuyor. Requirement'lar, ihtiyaçlar belirleniyor. Sonra risk analizleri yapılıp prototip çıkartılıyor.
Bu prototipten sonra tekrar bunun ihtiyaçlarla ilgili kontrolü yapılıp verification ve validation denilen aşamadan geçiliyor. Yani doğrulama ve onaylama diyelim biz onu Türkçe'de. Sonra development'tan...
bir daha yazılım sürecinden geçiriliyor, yazılım geçtirme sürecinden. Yine bir risk analizi yapılıp prototip 2 çıkıyor. Sonra işte müsvedde uygulama, süde uygulamalar, bunun tekrar verifikasyon ve değişiminde test planı yapılıp Risk analizi yapılıp bir prototip daha çıkıyor. Bu prototip artık Operational Prototip. Yani uygulamaya geçmeden önceki son prototip.
Bu adımların sayısı arttırılabilir bu arada. Yani işte burada bir, iki prototip var. Üç, dört prototipe gidilebilir.
Veya tek bir prototip de yeterli görülebilir projenin büyüklüğüne göre. Sonra Operasyonel Prototip'ten sonra detaylı tasarım, kodlama, entegrasyonlar, testler ve uygulama. Bu Waterfall modeliyle benzer yapıyı işliyor. Dolayısıyla aslında spiral model buraya kadar bize...
Değişik döngülerden geçen risk analizlerinin yapıldığı ve sonunda bir prototipin ortaya çıktığı ve hem yazılım geliştirme ekibinin, proje yönetim ekibinin hem de müşterinin üzerinde mütabık olduğu bir prototip ortaya çıkartıyor. Ve sonra bu prototipi gerçekleştirip canlıya çıkartıyoruz. Bu spireli de işte dörde böldüğümüzde dört aşaması var aslında her döngünün. Döngü dönüyoruz bu şeylere, spiral içinde dönüyoruz ama dört aşamadan geçiyoruz temel olarak dört adımdan. Hedeflerin belirlenmesi yani requirementlar, risklerin belirlenmesi ve çözümü, risk analizisi yapılıyor, geliştirme ve testler ve sonra da sonraki dönüşün planlanması.
Yani böyle bir döngü içinde sürekli dönüyoruz. İşte burada yukarı doğru gittikçe maliyetin büyümesi söz konusu ve sola doğru gittikçe de gözden geçirme süreçlerinin artması söz konusu ve daha da canlıya yaklaşma durumu söz konusu. Evet böyle... Seçmiş olduğum birkaç tane proje yönetim metodu ve Software Development Lifecycle'dan genel olarak bahsettiğimi zannediyorum.
Bu videoyu burada keseceğim. Daha önce iletişim bilgilerim, Şadi Evren Şeker ismim. SadiEvrenŞeker.com adresinden veya sosyal ağlar üzerinden benimle bağlantıya geçebilirsiniz.
İlk başta söylemiş olduğumuz adımları hatırlayacak olursak, bu videoda Software Development Lifecycle'ı biraz bahsettik. Proje yönetim yöntemlerinden biraz bahsettik. Bir sonraki de büyük veri nedir?
Bahsedeceğiz ve bununla ilgili Big Data Life Cycle'dan bu sefer bahsedeceğiz. Yaşam döngüsü olarak. Sonra da veri dünyasında, büyük veri dünyasında proje yönetimi ve büyük verinin bize proje yönetimi dünyası açısından kazandırdıklarını, risklerini biraz bahsetmeye çalışacağız. Böyle yarı akademik, yarı sohbet şeklinde yapmaya çalışıyorum. Umarım faydası olur.
Herkese başarılar dilerim.