ITIL ve Agile uyumluluğu sağlanabilir mi?

ITIL,Servis yaklaşımı üzerinden haraket ettiği için proje geliştirme metodolojisinin ne olduğu ile ilgilenmez.

Servis’i,uygulama veya uygulamaların bütünü olabilir.Uygulama veya uygulamalar bütününü geliştirirken,

Agile proje metodojilerinden faydalanmak isteyebilirsiniz.Bu konuda PennState University ‘de güzel bir çalışma

gördüm.Buradan ulaşbilirsiniz.


Kaynak : http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.93.8414&rep=rep1&type=pdf

Source: rss

ITIL-IT Infrastructure Library

ITIL (IT Infrastructure Library – BT Altyapı Kütüphanesi), BT Servislerini yönetmek için geliştirilmiş pratikleri sunan bir çatıdır.
80’li yılldarda OGS tarafından BT masraf ve kayıplarını enaza indirgemek,standartize etmek amacıyla ortaya çıkmıştır.
90 yıllarda bir çok firma örnek almaya başlamış,2001 ITIL v2 ve güncel hali 2007 Mart ayında ITIL v3 yayınlanmıştır.

ITIL,BT yönetiminin nasıl yapılcağını(how to) konusunda bilgi verir ve IT Service yaklaşımı sürdürülebilirliğini hedefler.

Güncel ITIL v3 ile 5 disiplin ile servis yaşam döngüsünün pratiklerini aktarır.

  • Service Strategy
  • Service Design
  • Service Transition
  • Service Operation
  • Continual Service Improvement

bu disiplinledir.Bu disiplinler ilgili yönetim süreçlerini içerir ve resimde görebilirsiniz.

İş(business)-BT(IT) yakınlaştırması,disiplinler arası döngüsel yaklaşım,şablonların (template) olması,diğer stadartlar ile uyum(cobit,iso vs.)
ITIL v2 ile ITIL v3 temel farklılıklarını oluşturuyor.

Source: rss

SCRUM (Agile) & Testing (V&V)

Bir önceki yazıda Scrum’ın bir geliştirme yaklaşımı(proje yönetim metedolojisi) olduğundan bahsetmiştik.

Testing açısından SCRUM ‘ı inceleyelim.

Testing’in tam ve genel bir tanımı olmamakla birlikte

Testing = Verification (Doğrulama) + Validation (Geçerleme) aktivitelerinin bütünü olduğunu belirtelim.

Verification (Doğrulama) :Doğru ürünü üretiyor muyuz? (What)sorusunun cevabını

Validation (Geçerleme) : Ürünü doğru üretiyor muyuz? (How)sorusunun cevabını verir.

Bu iki sorunu sorunu cevabını verebilmek için Static (statik) ve Dynamic (dinamik) testing ‘ten faydalanılır.

Static Testing     : Gözden Geçirme,inceleme aktiviteisidir.Herhangi bir koşum yapılmaz. (Quality Control) – Verification ile ilgilidir.

Dynamic Testing : Script(test) Koşum tabanlı aktivitedir. (Quality Assurance) – Validation ile ilgilidir.

Static ve Dynamic testing birbirinin tamamlayan aktivitelerdir.

Biraz da test level’larına değinelim.

  • Unit
  • Integration
  • System & Performance
  • User Acceptance(UAT)

adımlarından oluşur ve her bir adım için statik ve dinamik testing aktivitelerinde bulunulmalıdır.

Şimdi SCRUM ‘a geri dönelim.

Daily Scrum Meeting, OnSite Customer ,Refactoring,CI (Continues Integration)   verifikasyon ve validasyon

yapmanıza yapmanızı sağlayacaktır.Peki bu nasıl olacak?

Öncelikle Analiz – Development – Test aktiviteleri ve bunu her Sprint için paralel olarak gerçekleştirildiğini tekrar belirtelim.

PO(Product Owner) – müşterinin ihtiyaçlarını(onsite) toplar,gereksinimlerinizi,user story ‘lerinizin analizlerini ve yazımını
Developerlar ve testerlar birlikte yapar.(statik aktivite-gözden geçirme,inceleme,verifikasyon)

Scrum Master – Daily Scrum Meeting ‘lere başkanlık eder ve günlük bir gözden geçirme sağlanır.(verifikasyon)

Developer’lar Unit ve Integrasyon testleri hazırlar.(validasyon) ve refactoring yaparlar(verifikasyon).Tüm kodlar

source kontrol sisteminden(cvs,svn) kısa zaman aralıkları(1-2 saat) ile CI(Continues Integration) tooluna bütün

dinamik testleri ile aktarılır.Böylece Kısa zaman aralıklı ve sürekli validasyon sağlanır.

Testerlar,Sistem ve Performans testleri için test scriptlerini hazırlar.Burada Click & Record toollardan çokça faydalanılır.

“Static Code Analiz” test araçları CI araçları ile entegre edilebilir ve bu sayade code verifikasyon aktivitelerine destek verilir.  

Sprint sonlarında müşteriye kısa bir demo(UAT) yapılır ve

onayı alınır.Müşteri için doğru ürün doğru bir şekilde üretilmiş mi? bu sorunun cevabı alınır.

Bunu 15-30 günlük Her Sprint sonu için gerçekleştirisiniz

 


Source: rss

Agile Proje Yönetimi & SCRUM

Agile,Kimine göre proje yönetişimbilimi,kimine göre çatı(framework)ler topluluğu.

Kısaca

Agile manifesto özetlenen bir yaklaşım biçimidir. İlk temeli Lean manufacturing (Toyota Production System by Taiichi Ohno)

ile atılmıştır.Yazılım geliştimeye uygulanmış hali Lean software development olarak çıkar.Fakat Agile,bir çok metodoloji ve

farklı pratikler içerir.

Lean SD’dışında  Scrum,bu metodolojilerden biridir.FDD(Feature Driven Development),DSDM(Dynamic Systems Development Method)

bu metodojilere ekleyebiliriz.XP(eXtreme Programming),BDD(Behaviour Driven Development),TDD(Test Driven Development)

CI(Continues Integration)pratikler arasında yeralır.Yani bu tekniklerden faydalarak yazılım geliştirme metodojileri uygulayabilirsiniz.

Biraz Scruma değinelim.

Scrum,adını Rugby oyunundan alır ve toplanarak oyunu başlatmanın yoludur.

Benzer şekilde Scrum Team planma oyunu yapar, roller ve görevler dağıtılarak herkesin aynı hedef için çalışması sağlanır.

Sprint,Product Backlog,Sprint Backlog kavramlarını üzerinden geçelim.

  • Scrum,iteratif ve artan bir yöntemdir.
  • Scrum,Analiz,Geliştime ve Test analizin paralel gitmesini sağlayan bir yöntemdir.

Peki bu nasıl olur?

Product Backlog,müşteri ile anlaştığınız önceliklendirilmiş high level gereksinim listesi olarak düşünebilirsiniz.

Sprint,Genelde 15-30 günlük(Time-Boxed) proje zaman dilimidir.

Ve bir proje 1’den fazla Sprint’ten oluşur.Örnek olarak 3 aylık bir proje,

15 günluk iterasyonlarla ilerleyecekse 6 Sprint’iniz olacak demektir.

Her gün Scrum takımıyla,Scrum Daily Meeting (max 30 dk ve ayakta) düzeleyerek genel durum hakkında

bilgi alırsınız.Günlük bir gözden geçirme yapmış olursunuz.

Herkese 3 soru ile bilgi sabihi olursunuz.Scrum Master üç soru sorar:

  • Dün ne yaptın?
  • Bugün ne yapacaksın?
  • Seni engelleyen ne idi?

Herbir sprintte Product Backlog’tan alacağınız bir veya birkeç  kaç grup işi yapmak için

Analiz,Development ve Test ‘i paralel olarak ilerletirsiniz.

Bir bakıma Product Backlog’un Low Level Gereksiminlerini gerçekleştirmek için

çalışırsınız.User Story oluşturarak ve bunlar üzerine Task’lar  açarak programın feature(özelliklerini) geliştrirsiniz.

Ve herbir sprint sonunda yapılan bu işler doğrultusunda Sprint Backlog’u oluşmuş olur.

Sprint Burndown Chart, ile günlük olarak sprint hedefine ne kadar kaldığınızı görebilirsiniz.

Sprint sonunda müşteriye demo yapılır.Sprint Demo.

Sprint Demo ardından,Sprinti değerlendirmek içinde bir retrorespectif toplantısı düzenleyerek SCRUM takımı özeleştirisini yapar,dersler çıkartır.

Aşağıdaki resim kısaca süreci açıklar.

Source: rss

What is New HP Quality Center 10

Hp Quality Center 10 yepyeni özellikleri ile bu yılın başında piyasaya sürülmüştü.

Belki biraz geç bir yazı oldu ama yine de ekleyelim.

Cross Project Customization,Version Control,Sharing Libraries,Baselining,Test Resources Modul

ilk etapta göze çarpan ve etkileyici yeni özellikler.

Yeni özellikler hem test üst yöneticilerinin hem de tester’ların işlerini kolaylaştıracak.

Detaylı bilgiyi ekte bulabilirsiniz.

QualityCenter 10 – WhatIsNew.pdf (193,31 kb)


Source: rss

Uygulama Yaşam Döngüsü & Yazılım Geliştirme Yaşam Döngüsü

Bu iki kavram genelde karıştırılmakta.Biraz açıklık getirelim.

ALM(Application Life Cycle Management) ve SDLC(Software Development Life Cycle)

ALM ,SDLC den daha geniş bir kavramdır.SDLC süreci geliştirme sürecini ele alıp

SDLC=>Scope(initiaition)+Requirment Management+Build or Coding+Testing+Operations and Maintenance

süreçlerinden oluşurken ALM’de  bu süreçlere İş Yönetimi (Business Management)  de dahildir.

ALM = Governance+Development+Operation

ALM, iş yönetimi ile yazılım mühendisliğinin evliliği olarak düşünülebilir. 


Source: rss

Güncel Bi-Log

Blog’umu güncelledim.Yeni tasarım ve yeni kullanım özellikleri ile karşınızda…

Umarım yeni tasarımı beğenirsiniz.Görüş ve isteklinizi paylaşabilirseniz memnum olurum.

Hem blogun gelişmesi hem hem kendi gelişimim için faydalı olacaktır.

 


Source: rss

FMEA – Hata Modu ve Etki Analizi Tekniği – Severity – Priority – Likelihood – RPN

FMEA(Failure Mode & Effect Analysis) Proje ve Test yönetimi açısından önemlidir.

Öncelikle bir takım kavramların üzerinden geçelim.Kısaca anlatmaya çalışayım.

Risk : İstenmeyen bir olayın veya zararın gerçekleşme olasılığıdır.
Yazılım projeleri için genel olarak iki risk vardır.

Ürün(Yazılım) Riski ve Proje Riski

Ürün(Yazılım) riski,muhtemel risk alanlarınıza göre testlerinizi ve kaynakalrınızı nasıl yöneteciğinizi belirler.

1)ilk adımda kalite risk kategorisini belirleyerek işe başlarsınız.Yazılım projeleri için
Fonksiyonelite,Performans,Yük Kapasite,Operasyon ve Sürdürülebilirlik,Veri Kalitesi,Entegrasyon vb…
alanlara göre risk kategorilerinizi oluşturabilirsiniz.

2)Muhtemel Risk Alanlarının Girilmesi

Aşağıdaki gibi bir cetvel risk alanlarınızı kayıt altına alınmasını ve hesaplanmasını sağlar.

No Risk Kategorisi Muhtemel Hata Severity Priority Likelihood RPN Test yoğunluğu  Paketteki
İlgili
Modul
                 
1.001 Fonksiyonalite Açık hesap limitini aşmış müşterinin alışverişe devam edebilmesi
1.002                
               
2.001 Performans              
2.002                

Şimdi bu alanların üstünden geçelim.

Risk No, adından da anlaşılabileceği gibi risk id’si.

Kalite Risk Kategorisi : 1.Adımda bahsettiğimiz kategoriler.

Muhtemel Hata : İstenmeyen olay veya zarar

3) Derecelendirme yapın 

Severity : Sistem tarafından önemi,sistem derinliği,teknik taraftan değerledirilir

Priority : Müşteri tarafından önceliği,iş derinliği(değeri),iş(business) tarafıdan değerlendirilir

Likelihood : Gerçekleşme olasılığı

Severity & Priority genelde aşağıdaki katsayılar ile değerlendirmeye alınır.

1)Urgent
2)Very High
3)High
4)Medium
5)Low

Likelihood ise

1)Muhtemel(Yüksek)
2)Mümkün(Orta)
3)İhtimal Dahilinde olmayan(düşük)

olasılıklara sahip olur.

No Risk Kategorisi Muhtemel Hata Severity Priority Likelihood RPN Test yoğunluğu  Paketteki
İlgili
Modul
                 
1.001 Fonksiyonalite Açık hesap limitini aşmış müşterinin alışverişe devam edebilmesi 2 1 2 AddToCart
1.002                

 

4)Risk Önem Katsayısını hesaplayın

RPN=Severity X Priority X Likelihood ile hesaplanır

No Risk Kategorisi Muhtemel Hata Severity Priority Likelihood RPN Test yoğunluğu  Paketteki
İlgili
Modul
                 
1.001 Fonksiyonalite Açık hesap limitini aşmış müşterinin alışverişe devam edebilmesi 2 1 2 4 AddToCart
1.002                

5)Test yoğunluğunu belirleyin

RPN ‘den çıkan değer göre Test yoğunluğunuzu belirleyin.

Katsayı ne kadar küçük çıkarsa o kadar çok test yoğunluğuna sahip olacaktır.
Aralıkları aşağıdaki şekilde belirmek

1-20   : A
21-50 : B
51-65:  C
66-75 : D

Test önceliğiniz kapsam,zaman ve maliyet göz önüne alındığında

A>B>C>D olacaktır.

No Risk Kategorisi Muhtemel Hata Severity Priority Likelihood RPN Test yoğunluğu  Paketteki
İlgili
Modul
                 
1.001 Fonksiyonalite Açık hesap limitini aşmış müşterinin alışverişe devam edebilmesi 2 1 2 4 A AddToCart
1.002                

sample

Source: rss