Methodology

Proje Geliştirme Süreçleri – V Model 1024 704 mezo

Proje Geliştirme Süreçleri – V Model

Merhaba arkadaşlar

Yeni bir gün yeni bir Proje Geliştirme Süreci olan V Model ile karşınızdayım 🙂

Daha önce ki yazılarda Waterfall ve Agile yöntemlerinden bahsetmiştik. V model biraz Waterfall metoduna benzer. Yani Waterfallda olduğu gibi tüm analiz ve dökümantasyonun en başta yapılması ve bitirilmesi ihtiyaçların kesinleştirilmesi gerekiyor. Verification and Validation olarak bilinen ve V Model olarak kısaltılan bu metotda Waterfall dan farklı olarak analiz ve ihtiyaçlar kesinleştikten sonra yazılım geliştirmeye başlamadan önce bir test planı oluşturulmalıdır. Bu modelin yazılım ve test döngüleri çizildiğinde V harfi ortaya çıkar 😀  Walla çıkar 😀 aşağıdaki resmi inceleyebiliriz 😀

V-Model

 

Resimde görüldüğü gibi V harfi çıkıyormuş 🙂 resim üzerinden bahsetmek gerekirse burada process sırası olarak sol taraftan sağ tarafa gidiliyor. Öncelikle Analizlerimiz çıkıyor sonra Fonksiyonel özellikler belirleniyor sonra Dizayn aşamasından geçiyor bu analizler ve Programcıların anlayabileceği şekle getiriliyor en ortada kocaman yazdığı gibi programı kodluyoruz sonra unit testi unutmuyoruz onlarsız olmaz 😀 unit testten sonra entegrasyon testi sonra sistem testi sonra kullanıcı kabulu ve kapanış 😀

Burada V harfininde bir özelliği var aslında şimdi her maddenin hemen karşılığında bir madde mevcut soldan sağa doğru giderken kodlama aşamasından sonra sağ tarafta bulunan aşamalardan birinde bir sakatlık bir eksik efendime söyleyeyim bir istek arzu gelirse bu hemen karşısındaki aşamaya atlar yine resimde görüldüğü gibi.

Yani User Acceptence aşamasına gelmiş bir yazılımda kullanıcı bu ürünü kabul etmezseeee 😀 en başa dönüyoruz 😀 tekrar analiz tekrar falan falan falan 😀 Sil baştan olmasada istenilen yeni özellik ile alakalı tüm processler için tekrar bir döngü tekrar bir iş tekrar bir çalışma gerekiyor 🙂

V model çokda zor değil değilmi 🙂 resim zaten açıklıyor…

Umarım yararlı olur

Bilgiyle Kalın

M.Zeki OSMANCIK

 

Kanban Ne Ola ki ? 508 212 mezo

Kanban Ne Ola ki ?

Merhaba arkadaşlar

Proje geliştirme süreçleri ve bu süreçlerde kullanılan metotlar vs ile ilgili küçük bilgiler vermeye tam gaz devam ediyorum 😀 Sırada Kanban var

Kanban, tam zamanında Üretim ortamında malzeme hareketlerinin kontrolü amacıyla kullanılan bir çizelgeleme yaklaşımıdır. Toyota’nın üretim verimliliğini artırmak amacıyla Taiichi Ohno tarafından geliştirilmiştir. Yöntem 1953’ten bu yana kullanılmaktadır. Aslında japoncada görsel işaret veya kart anlamına gelir. Üretimin tam zamanında gerçekleşmesi konusunda başarılı bir metotdur. Tüm olayları görselleştirir ve üretim sürecini büyük resimde görme imkanı sağlar.

Toyotada kullanılmaya başladığına göre küçük bir tahminle biraz hayalgücü ile bu sistemin aslında nasıl çalıştığını hayal etmek çok da zor değil. Bir üretim hattı mevcut ve bu üretim hattı üzerinde ürün bazı işlemlere tabi tutuluyor ve en son olarak bir ürün yani araba ortaya çıkıyor. Örneklemek gerekirse bir band üzerinde önce arabanın iskeletine parçalar sıra ile takılıyor kapılar , çeşitli aksamlar , motoru ,camları, iç aksesuarları gibi bu sıra ile giden işlemlerde bir aksilik olmaması önemli bunun içinde süre ve malzeme kontrolü önemli 😉 Kanban tüm bu işlemleri görselleştirip takibi kolaylaştırıyor 😉

Sen ne anlatıyorsun değişik 😀 Toyota kullanıyorda bizdemi araba üreteceğiz ?  diyebilirsiniz 😀 demeyin çünkü Kanban olayının yazılımada uyarlanması çok da zor değil. Adamlar yapmış 2004 yılında bu Kanban felsefesini yani görselleştirme işini yazılımada uyarlayıp bir metodoloji haline getirmişler.

Özet olarak bahsetmek gerekirse Kanban metodu mevcut sürecinizde hemen bir değişikliğe gitmenizi zorunlu kılmaması önemli avantajlarından bir tanesi. Zamanla yazılımın veya sürecin evrimleşeceğini öngörür.

Yani Kanban Yazılım Geliştirme Süreci veya Proje Yönetimi diye bir şey yoktur. Kanban bir süreç değildir, sürekli akışı teşvik eden, hafif siklet bir metodtur.

Kanban, temelde 4 temel prensibi kullanır:

  • Ne biliyorsan onunla başla,
  • Artırımsal ve evrimsel değişimi takip etmeyi kabul et,
  • Mevcut sürece, rollere, sorumluluklara ve ünvanlara saygı göster.
  • Tüm seviyelerde liderliği teşvik et

Bu prensipler akabinde Kanban’ın 5 ana özelliğide şöyle özetlenebilir :

  • İş akışını görselleştirir
  • Aynı anda yapılan işleri sınırlandırır
  • Akışı yönetmeyi ve ölçmeyi kolaylaştırır
  • Süreç ilkelerini belirgin kılar
  • İşbirliği yaparak iyileştirmeyi sağlar

Bu süreçte belli adımlarda yapılan iş diğer adımlarda yapılan işlerden daha çabuk sonuçlanabilir. Bir adımın çıktısı diğer bir adımın girdisidir. Zamanında tüketilemeyen görevler o adımda bir birikime neden olacaktır. Kanbanda her bir adımda eş zamanlı yapılacak işlerin sayısına bir sınır getirilmesi sürecin darboğazlarının azalmasına imkan tanır. Bir üretkenlik yaratılıp arkadan gelmekte olan işler için bir yer açar. Sınırlama getirilmemesi durumunda bir sürecin belli bir adımında çok iş yapılıyor olmasına rağmen biten bir iş olmayacaktır. Sonuç olarak takım ne kadar çok çalışırsa çalışsın o zamana kadar bir değer üretememiş olacaktır.

Örnek olarak bir Web sayfası yapıyorsanız bu aşamada tasarım için 1 kişi , programlama için 2 kişi olduğunu varsayarsak kodlamada gerçekleşecek bir gecikme tasarımdan çıkan işler bitip ,development aşamasına gelen işleri çoğaltacak ve bu aşamada developer arkadaşlar zorlanacak belki de yeni bir developer ihtiyacı doğacak . Ama bu işler sınırlandırılırsa bu dar boğaz yada işlerin belli aşamalarda artması durumu desek daha doğru olur biraz daha aza indirgenmiş olur. Ayrıca Kanban ile büyük resim görüldüğünden , resimde bu problemin yöneticiler tarafından görüntülenmesi  çalışanlar açısından da önemli ve rahatlatıcı bir özellik.

Kanban’da görselleştirme Değer Akış diyagramları ile ve kanban tahtası ile sağlanabilir. Değer akış diyagramları mevcut durumun, gelecekteki sistemin anlaşılması ve israfın önlenmesi için kullanılır.
Kanban Tahtası ahanda aşağıdaki gibi birşeydir.

kanban-movement

Resimde görüldüğü gibi işler belli başlıklarla ayrılır her iş bittiğinde bir sonraki aşamaya geçer ve bitirilirler.

Kanban ile kendi kişisel işlerinizi bile takip etmek kolay 😉 bunun için internet ortamında kullanılan bazı uygulamalarda mevcut. 😉

Umarım Yararlı Olur

Bilgiyle Kalın

M. Zeki OSMANCIK

Proje Geliştirme Süreçleri – Agile Scrum 1024 841 mezo

Proje Geliştirme Süreçleri – Agile Scrum

Merhaba arkadaşlar

Proje geliştirme süreçleri ile alakalı bilgi almaya  devam ediyoruz. Bildiğiniz gibi bir önce ki yazımda Waterfall metodunu türkçem yettikçe anlatmaya çalıştım. Bu yazımda ise farklı bir tür yeni bir trend herkesin öğrenmeye uygulamaya çalıştığı bir metot olan Agile Scrum metodundan yine türkçem yettiğince bahsetmeye çalışacağım 🙂

Agile türkçe meali Çevik olan bu metot aşamalı olarak projeleri geliştirmemizi sağlıyor ve bu sayede biraz esnek davranabilmemizi sağlıyor. Waterfall metodunda analiz kısmı bittikten sonra müşteriyle uzun süre görüşemediğimiz çok özlediğimiz doğrudur işte Agile yöntemi bu özleme son veriyor ve müşteri ile sürekli iletişim içinde bulunmamızı sağlıyor 😀 Yani kısacası Agile adı gibi projemize çeviklik kazandırıyor ve gerek hız gerek üretilen değerler açısından bize güzel faydalar sağlıyor. 🙂

Agile denen yöntemin içersinde de farklı frameworkler mevcut bunlardan biri Scrum diğeri XP dir. Windows XP değil ama 😀  meali Extreme Programming. 🙂

Bu metotlardan şimdilik Scrum dan bahsedeceğim XP için sonraki yazılardan birinde bahsedebilirim…

Scrum denilen şey itiş kakış anlamına gelen ama anlamı kadar karmaşa içinde yürümeyen bir yöntem. Bu yöntem içersinde bulunan bazı terimleri sizlere konu ile birlikte açıklamak isterim 🙂

Product Owner : İşi yaptırmak isteyen tarafta bulunan ve yazılımın tüm detayına hakim olan bize anlatabilecek arkadaştır.

Product Backlog : Yazılım için yapılmış analiz diyebiliriz. yazılımımız şöyle güzel olsun, böyle iyi olsun , hatta şöyle de güzel olsun içinden atlar kuşlar böcekler çıksın şeklinde olabilen ve ürünü yaptıracak olan Product Owner tarafından yazılmış belli formata sahip User Story‘ ler  bütünüdür.

Herneyse bu PO (Petrol Ofisi değil Product Owner 😀 ) arkadaş bizlere fantazi dünyasının sınırlarını zorlayarak bütün bir product backlogu oluşturduktan sonra bu işleri en çok önemliden en az önemliye sıralar ve teslim eder. Product Backlog yaşayan bir liste olabilir yani sürekli madde eklenebilir silinebilir vs vs. Bu PO nun zevkine kalmış artık 🙂

User Story’ler INVEST diye kısa bir isimle adlandırılan kurallar dizisini içerirler.Invest şöyle sıralanır :

  • Indipendent(Bağımsızlık):User Story kendi başına bir içeriğe sahip olmalıdır. Diğer user story’lere bağlı olmamalıdır.
  • Negotiable(Tartışılabilir): User Story’ler, bir sprint içeriğine girene kadar her an değiştirilebilir.
  • Valuable(Değer): bir user story son kullanıcı için bir değer ifade etmelidir.
  • Estimable(Tahmin yürütülebilir): Bir user story’nin süresi tahmin edilebilmelidir.
  • Sized appropriately(Makul boyut): User Story’ler plan, görev ve öncelik bakımından derecelendirilmesi ele alınabilmesi için çok kompleks yapıda olmamalıdır.
  • Testable(Test edilebilirlik): User Story’ler test edilebilirliği mümkün kılmalıdır.

Sonrasında Scrum takımı bu product backloglar içersinde (burası önemli) her seferinde bir değer üretebilecek şekilde 2 veya 4 haftalık bir süre olan proje bitimine kadar tekrar eden  ve Sprint adı verilen dönem içinde gerçekleştirilmek üzere görevleri alır sıralar kendi içinde dağıtır ve geliştirmeye başlar. Tüm bu işleri yöneten arkadaşa Scrum Master denir. Çok karizmatik bir ünvanı bulunan bu arkadaş takımın tüm yükünü omuzlarında taşır ,ihtiyaçları sağlar , engelleri kaldırır, gaz verir vs vs.

Bu takım Scrum kuralları gereği bazı seremoniler yapmak zorundadır. Mesela her sabah maksimum 15 dk süren “Ne yaptım?” “Ne yapacağım?” “Önümde engel varmı varsa neler?” sorularının kısaca cevaplandığı bir toplantı. Sonra Sprint başlamadan önce acaba hangi taskları alsakta yapsak müşteriye nasıl bir değer üretsek sorusunun tartışıldığı Sprint Review. Bir de takımın kendi içinde birbirini tebrik ,tahrik edebildiği yanlış varsa “ben nerde yanlış yaptım” şarkısının söylendiği güzel bir durum varsa ortamın şenlendiği garip bir o kadar ilk seferde adını söylemesi zor bir toplantı vardır ki oda Retrospective toplantısıdır. 🙂

Sprint başlar mutlu yazılımcılar kodlarını yazmaya başlarlar her gün birbirlerine mutluluk içinde neler yaptıklarını anlatırlar ve 2 veya 4 hafta dediğimiz sprint süresi sonunda müşteriye bir demo gösterirler bu elle tutulur gözle görülür müşterinin test etmesine olanak veren hatta ve hatta müşterinin  “İyi olmuş hadi bunu Deploy edelim böylece” lafını söyletebilecek bir yazılım olmalıdır ki Scrum dediğimiz metot amacına ulaşabilsin 🙂

Scrum ı açıklayan çok güzel bir resim aşağıdaki gibidir 🙂

Scrum-Plan-Do-Check-Act-Diagram

 

Peki bitti mi tabiki de bitmedi 🙂 birde son olarak bahsetmek istediğim küçük bir konu da Burn Down Chart.

Born-down chart İş sonu grafiği anlamına gelir ve Sprint sırasında takım üyeleri görevlerini yerine getirildikçe kalan iş ve yapılan iş arasındaki korelasyonu belirten bir grafik ortaya çıkar.İşte bu grafik takım üyelerine veya yöneticilerine fikir verir. Aynı zamanda takımın iş için istediği sürelerin yeterli olup olmadığı ve işin zamanında tamamlanıp tamamlanamadığı konusunda da fikir veren bir grafiktir. Adının burn down olması sanırım takımın işlerini zamanla eş değer şekilde bitirmeleri yakmaları eritmeleri vs. olabilir 🙂 Bu chart örneğinide yine aşağıdaki gibi görebilirsiniz.

BurnDownChart

Kısaca fikriniz olması açısından Agile ve Scrum ı açıkladım.

Umarım Yararlı Olur

Bilgiyle Kalın

M.Zeki OSMANCIK

Proje Geliştirme Süreçleri – Waterfall 512 320 mezo

Proje Geliştirme Süreçleri – Waterfall

Merhaba arkadaşlar
Yazılım geliştirmede çok sayıda farklı model ve süreçler mecvuttur. Bu yazımda sizlere yazılım dünyasında diğer modellere de örnek olan “Waterfall Model”inden bahsetmek istiyorum .Bu model bir yazılımın geliştirme sürecini Plan, Design, Built, Test ve Deploy aşamaları olarak ele alır. Bu aşamaların her biri birbirini bekleyen ve etkileyen  süreçlerdir.
Plan (Analiz)
Bir problem çözümü olarak nitelendirilen yazılımın ne yapacağını ve nasıl yapacağını belirlediğimiz yani problemi tanımladığımız aşama analiz aşamasıdır. Yazılan kod isteneni doğru bir şekilde yerine getirebiliyorsa başarılı bir yazılım olarak nitelendirilebilir bu sebeptendir ki  öncelikle yazılımdan ne istendiğinin doğru bir biçimde anlatılması ve yorumlanması gerekir. Analiz aşaması personel, donanım ve sistem gereksinimlerinin belirlenmesi, sistemin fizibilite çalışmasının yapılması, kullanıcıların gereksinimlerinin analizi, sistemin ne yapıp ne yapmayacağının kısıtlamalar göz önüne alınarak belirlenmesi, bu bilginin kullanıcılar tarafından doğrulanması ve proje planı oluşturulması adımlarından oluşur.

Design (Tasarım)
Yazılımın analizini yaptık ihtiyaçlarını belirledik artık bilgi sahibiyiz ne nasıl olur az çok biliyoruz bundan sonra ki aşamada neler yapacağiz peki ? Analizin sonucunda belirlenen ihtiyaçlara yanıt verecek yazılımın temel yapısının oluşturulduğu aşamadır. Yazılım tasarımı, bir bileşen veya sistemin nasıl gerçekleştirileceğini belirlemek için kullanılan teknikler, stratejiler, gösterimler ve desenlerle ilgilidir. Bu aşama yazılım bileşenleri arasındaki ara yüzler, mimari tasarım, veri tasarımı, kullanıcı ara yüzü tasarımı, tasarım araçları ve tasarımın değerlendirilmesi alt süreçlerini de kapsamaktadır. Tasarım aşaması, yazılımın hem kullanıcı ara yüzünü hem de programın omurgasını ortaya koymaktadır. Yapılacak tasarım, yazılımın işlevsel gereksinimlere uygun olmasının yanı sıra kaynaklar, performans ve güvenlik gibi kavramları da göz önüne alınarak gerçekleştirilmelidir. Kısaca tasarım kısmında yazılım içersinde karşılaşılabilecek tüm herşey göz önüne alınarak kodlama için start verilmeye uygun ortam hazırlanır.
Build (Kodlama)
Şimdiki kısım bizim en sevdiğimiz kısım Kodlama 😀 Bu aşama, tasarım sürecinde ortaya konan veriler doğrultusunda yazılımın gerçekleştirilmesi yani kodların yazılması aşamasıdır. Bu süreç programlama çalışmalarının yanı sıra yazılımın geliştirilmesi ve kullanıcıya ulaştırılması sürecindeki bütün çalışmaları kapsar. Tasarım sonucu üretilen süreç ve veri tabanının fiziksel yapısını içeren fiziksel modelin bilgisayar ortamında çalışan yazılım biçimine dönüştürülmesi çalışması olarak da nitelendirilebilir. Yazılım geliştirme ortamı, programlama dili, veri tabanı yönetim sistemi, yazılım geliştirme araçları seçimi kodlama aşamasında gerçekleştirilir.
Test
Yazılımı yazdık bitirdik yada sadece bitirdiğimizi sanıyoruz 😀 şimdi sıra geldi Test aşamasına, yazılım kodlanması sürecinin ardından gerçekleştirilen sınama ve doğrulama aşamasıdır. Elde edilen uygulama yazılımının hem belirlenen gereksinimleri sağlayıp sağlamadığı hem de gerçekleştirimin beklentilere uygun olup olmadığını kontrol etmek için statik ve dinamik sınama tekniklerinden yararlanır. Statik teknikler, yazılımın tüm yaşam döngüsü boyunca elde edilen gösterimlerin analizi ve kontrolüyle ilgilenirken, dinamik teknikler sadece gerçekleştirilmiş sistemi içerir. Yazılım üretiminde ilk testler genelde geliştirme sürecinde programcı tarafından yapılır. Bununla birlikte, asıl hata ayıklama ve geribildirim hizmeti test ekipleri tarafından yapılır. Testler ve geribildirim müşteri yazılımı kullandığı sürece devam eder. Test sürecinde en faydalı geribildirimler son kullanıcı test gruplarından gelir.
Deploy
Yazılımımız yapılan analiz doğrultusunda beklendiği gibi çalışıyor ve testlerinden de başarılı şekilde geçti sıra geldi artık müşterimizin kullanımına açmaya. Bu aşama tüm gereksinimler tamamlanmış ve müşterimiz memnun şekilde projesini teslim etme aşamasıdır. Bu aşamadan sonra belki bakım aşamasıda bu sürece dahil edilebilir.

Aşağıdaki resimde waterfall yönteminin işleyişini görebiliriz.

waterfall

Umarım Yararlı Olur
Bilgiyle Kalın
M.Zeki Osmancık

    Join our Newsletter

    We'll send you newsletters with news, tips & tricks. No spams here.