Uygulama Yaşam Döngüsü için Okunulası birkaç kaynak

Uygulama yaşam döngüsü(ALM-Application Lifecycle Management) için faydalı olacağını düşündüğüm bir kaç intrenet kaynağını paylaşmak istedim.

http://davidchappellopinari.blogspot.com/2009/04/what-is-application-lifecycle.html
David Chappell ALM tanımı üzerinde durmuş

http://www.best-management-practice.com/gempdf/ITILV3_ASL_Sound_Guidance_White_Paper_Jan08.pdf
Uygulama Servis Kütüphanesi (Application Service Library-ASL) üzerinde durarak Uygulama Yönetimi(Application Management-AM)
ve Uygulama Geliştirme(ApplicationDevelopment) sorumluklarını kısaca anlatan güzel bir whitepaper.

http://www.tso.co.uk/amdemo/index.htm
Application Management üzerine TSO’nun OGC için hazırlığı kaynak.Linkteki sadece demo versiyonu.


Source: rss

Scrum in under 10 minutes by Hamid Shojaee

Scrum in under 10 minutes 

Learn the SCRUM software development methodology in less than 10 minutes. By the end of this fast-paced video, you’ll know about burn-down charts, team roles,product backlogs, sprints, daily scrum…

http://www.dailymotion.com/video/xec1mj_scrum-in-under-10-minutes_tech

 

Great Thanks to Hamid Shojaee


Source: rss

Konfigurasyon,Değişim ve Sürüm Yönetimi

Sürüm(Release Management) ve konfigurasyon(Configuration Management) yönetimi değişiklikleri yönetmenin(Change Management) ve koordine etmenin anahtarıdır.

Etkileşimini inceleyelim;

Değişim yönetimi olmadan konfigurasyon bilgileri doğruluğunu hızla kaybeder.Doğru konfigürasyon bilgisi olmaz ise,değişimler için doğru bir etki analizi(impact analysis) yapılamaz.

Konfigurasyon ve Değişim bilgileri doğru değil ise doğru bir Sürüm (Release) yönetimi gerçekleştirilemez.

Bu durumda Gereksinim belirlemesi ,Geliştirme ve Testler doğru bir şekilde yapılamaz.


Source: rss

HP PPM & QC Integrasyonları

HP PPM(Project & Portfolio Management) ve HP Quality Center arasında iki tip integrasyon mevcut.

  • CM4QC(Center Management for Quality Center)
  • ALM(Application LifeCycle Management)(eski adı MAC(Managing Application Change))

Bu integrasyonların amacı,İş Birimleri ile BT birimleri arasında yakınlaştırma(Business-Development Alignment) sağlamak,IT Servislerini daha yönetilebilir kılmaktır.
Bu integrasyonlar sayesinde ayrıca ITIL Servis yaklaşımının Servis Operasyona kadar(Service Operation) ‘a kadar ilerletilmesini sağlayabilirsiniz.
Operasyondan PPM’e gelmiş RFC’leri (Request for Change)’leri QC’ye aktarabilir ve süreçlendirebilirsiniz.

Biraz da integrasyonları ve farklılıklarını inceleyelim.

  • CM4QC ile
    • PPM içinden QC projeleri yaratabilir ve QC kullanıcılarını atayabilirsiniz.
    • PPM ‘den QC Projelerindeki durumu grafiksel ve raporlama araçları ile  kolaylıkla görebilirsiniz.
  • MAC
    • Requirement(RFC)
    • Defect
      bazında integrasyon ve senkranizasyon sağlayabilirsiniz.

Uygun süreçler ve düzenlemeler ile strateji ve IT geliştirmelerinizin uzlaşımını kolaylaştırabilir,
Risk,Zaman ve Maliyetlerinizi azaltabilirsiniz.

Source: rss

Sürekli Tümleştirme (Continuous Integration)

Sürekli Tümleştirme(Continuous Integration),geliştirilen uygulamada yapılan değişikliklerin etkisini gözlemleyebilmenizi sağlar.

Bu sayade kaynak kodunda(source code) yapılan değişikliğin uygulamanın çalışmasına etkisini görebilirsiniz.
Unit (Class),Bileşen(Component),Sistem,Fonksiyonel vb. testlerinin otomatizasyonu ve koşumunun sürekliğinin sağlanmasının
yanı sıra diğer yardımcı araçlar ile Statik Kod Analizi,Class-Unit Test Covege ‘ı da  vb. gözlemlenmesini sağlayabilirsiniz.

Bu sayade,entegrasyon sorunlarını azaltabilir ve sürekli çalışır uygulamalar(sürümler) elde etmiş olursunuz.

Martin Fowler ‘ın sürekli tümleştirme ile ilgili yazısına buradan ulaşabilirsiniz.

Sürekli Tümleştirme Nasıl Çalışır?

Yapılan geliştirme ve değişiklikler Kaynak Kodu Merkezine (Source Control Repository)
otomasyon testleri ile birlikte gönderilir.En az günde bir defa olmak üzere (genelde 2-4 saatte 1)
Kaynak Kodu Merkezinden  bütün kaynak çekilir derlenip,testleri ile birlikte çalıştırılır.Varsa hatalar
mail,hata yönetim sistemi vb. yerlere kaydedilir.
Bu sayade uygulama üzerinde hatalar gözlemlenir ve düzeltilir.

Aşağıda grafiksel olarak sistemleri görebilirsiniz.

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