25 Şubat 2016 Perşembe

Univera Test Otomasyon Deneyimleri

Tepkiler  
Söz verdiğimiz gibi Univera test otomasyonu projesi ile ilgili deneyimlerimizi paylaşmaya başlıyoruz.
Alice Harikalar Diyarında kitabında şuna benzer bir sahne vardı: Alice dehşete kapılmış bir şekilde arkasına bakmadan koşuyor. Bir süre sonra arkasındaki tehlike her neyse bir miktar geride kalıyor. Alice ise nefes nefese koşmaya devam ediyor. Birden yol ikiye ayrılıyor, tam kavşakta bir tavşan var. Alice panik içinde, bir nefeste soruyor: “Hey tavşan, hangi taraftan gitmeliyim!”

Tavşan havucundan bir diş koparıyor, ağzında güzelce çiğneyip yutuyor, sonra sakin bir tavırla soruyor: “Sen nereye gitmek istiyorsun ki?”

İşte böyle… Bizim de arkamızdan azgın bir pazar koşuyor. Ama her şey iyi bir planlamayla başlar derler. O hâlde sakin kalıp sormakta fayda var: Biz gerçekten de nereye gitmek istiyoruz?

İşte bizim zirvesine ulaşmak istediğimiz dağ:

Yazılım ve test uzmanları omuz omuza, ele ele, diz dize beraber çalışarak, hataları çözerek değil, hataların oluşmasına izin vermeden ortak ve stabil bir hat üzerinde geliştirme yapıyor.

Ortak hatta yapılan her geliştirme için –evet, main hattına yapılan her checkin için- otomatik versiyon numarası atanıyor ve sorunsuz set oluştuğu test ediliyor. Ardından ünite testi (unit test) otomatik çalışıyor.

Unite testleri 5 dakika içinde tamamlanıyor. Daha sonra son kullanıcı kabul testleri için test otomasyonu çalışıyor. Bu işlem saatler hatta belki 1 gün sürüyor

Ardından fonksiyonel olmayan testler dönüyor: Performans testi, yük testi, güvenlik testi, vs. Tabii onlar da otomatik.

Ve son olarak insana dayalı testler başlıyor: Formların genel görünümü, otomasyona girmeyen testler, genel stabilite kontrolleri, vs.

Tercihan, sonuncusu hariç hepsi insan eli değmeden otomatik çalışıyor. Sonuç: Her hafta bir set, hatta belki daha da sık!

Hedef Everest Dağı’na benziyor değil mi? Gerçekten de öyle, fakat ütopik değil. Zira pazarın bizi doğrudan zorladığı nokta tam da burası. Gün itibarıyla rakiplerimizin önünde olmamız bir teselli kaynağı olamaz. Ağrı Dağı ile yetinmeniz pazarı ilgilendirmiyor: Günü geldiğinde ya Everest’in zirvesinde olacaksınız ya da hiçbir yerde!

Bu güzel dağ manzaralı resme bakarak “test otomasyonu” kapsamında değerlendirilebilecek maddelerin üzerinden şöyle bir geçmekte fayda var:

·         Ünite testi geliştirmeleri, yazılım geliştirme sürecinin bir parçası olarak ilerliyor. Geliştirilen her komponent, sistemin bütününden izole edilerek ünite testinden geçiyor. Böylece kodlanan tüm küçük birimlerin kendi içinde sorunsuz çalıştığından emin olacağız ve her check-in için bozulmadığını tekrar tekrar kontrol edeceğiz.
·         Kullanıcı kabul testleri ise “test otomasyonu” deyince aklımıza ilk gelen testleri oluşturuyor. Yani kullanıcı ara-yüzlerini kullanarak sanki bir kullanıcı gibi sisteme ilgili girdileri verip beklenen çıktıları alıp almadığımızı kontrol ediyoruz.
·         Performans, yük ve güvenlik açıkları testleri gibi “fonksiyonel olmayan testlerin” diğer testlere göre önemsiz olduğunu kim söyleyebilir? Diğer hatalara göre nadir karşılaşılıyor olsak da, meydana çıktığında tüm sistemi ciddi seviyede etkileyebilen, kısa bir süre için bile göz ardı edilmesi mümkün olmayan ölümcül hatalar bunlar.

Ve evet, hepsi ve belki de fazlası otomasyon kapsamına dâhil edilebilir, insan eli değmeden otomatik çalıştırılabilir, çalıştırılmalıdır.

Biraz uzattık ama “test otomasyonu” için adım atarken iki temel taşı yerine oturtmamız gerekiyor: Birincisi test otomasyonunun genel test yaklaşımında (veya toplam kalitede) nerede duracağı, ikincisi test otomasyonun kapsamı; önce kısa orta vade için, sonrasında uzun vade için.

Univera’da bizim başlangıç noktamız kullanıcı kabul testleri otomasyonu oldu.

Başlangıçta bilgi ve tecrübemiz oldukça kısıtlıydı. Test otomasyonunun Türkiye için oldukça yeni bir kavram olduğu ortadaydı. İzmir’de deneyim sahibi olan kişi bulmak imkânsız gibi bir şeydi.

Bu süreçte İstanbul’da test otomasyonu kullanan firmaları ziyaret ettik. Onların tecrübelerinden faydalandık. Konusunda uzman danışmanlarla çalıştık. Ve tabii ki bol bol internet araştırması yaptık.

İlk olarak web uygulamamız için test otomasyonu ürünümüzü seçtik. Tercihimizi “Sahi” den yana kullandık. Bir taraftan da mobil cihazlar için test otomasyonu ihtiyacımızı asla unutmadık.
Test otomasyonu mimari tasarımı ve otomasyon framework’u oluşturma için harcadığımız zamana acımadık. 

Zira başarısız olan projelerin temel sebebinin bu aşamalar için yeterince zaman ayrılmaması, alelacele senaryo kodlamasına geçilmesi olduğunu gayet iyi biliyorduk.

Test otomasyonu araçlarının ekran üstündeki objeleri tanıması gerekiyor. Obje tanımlama işlemi için temel olarak iki farklı metodoloji kullanılıyor. Birinci grup metodolojide genellikle bir agent sayesinde test otomasyon aracı test edilecek platformdaki objelerin değişken bilgilerine, örneğin id bilgisine, ulaşıyor. Daha sonra bu id kullanılarak obje üzerinde istenen işlem yapılıyor, örneğin bu id bir butona aitse, ilgili komutlarla buton tıklanması sağlanıyor.

İkinci grup metodolojide obje id’lerine ulaşılması gerekmiyor. Çünkü otomasyon aracı görüntü tanımlama metoduyla ekranda işlem yapmak istediği alana ulaşıyor. Örneğin “kapat” butonuna tıklanacaksa mouse ile kapat butonun olduğu alan çerçeve içine alınıyor. Böylece “kapat” butonunun bulunduğu bölgenin “fotoğrafı çekilmiş” oluyor. Otomasyon çalışırken ekran üzerinde bu görüntünün bulunduğu bölge bulunuyor ve istenen işlem (örneğin tıklama işlemi) yapılıyor.

Görüntü tanımlama tekniğini kullanan otomasyon araçlarında obje id’si bulmak gibi bir kaygı olmadığı için senaryo kodlama diğerine göre oldukça kolay ve hızlı ilerliyor.   

Mobil otomasyon aracı araştırırken görüntü tanımlama metodu kullanan otomasyon araçlarından bazılarını inceledik. EggPlant bu konuda ticari olarak en tanınmış ürün olarak görünüyordu. Kodlama bilgisi çok az olan hatta hiç olmayan kişiler için bile senaryo yazmayı mümkün hâle getiren kullanışlı bir yapısı var. Bununla beraber fiyatı oldukça yüksek ve bu fiyatın her sene tekrar ödenmesi gerekiyor.

Görüntü tanımlama temelli ürünler arasında alternatif olarak Sikulix adlı ürünü de inceledik. Sikulix MIT’den bir grup yazılımcı tarafından açık kaynak kod olarak geliştirilmiş. Ürünü hakkında çok sayıda olumlu yorumlar bulunuyor.

İncelemelerimiz sırasında Sikulix ile karakter tanımlama konusunda bazı sorunlar yaşadık. Örneğin ekranda 228 olan bir sayı Sikulix tarafından Z28 olarak okundu. Bu gibi sorunlarda açık kaynak kodlara yoğunlaşarak bazı çözümlere ulaşabileceğimizi görüyorduk. Ancak mevcut kaynağımızı kendini kanıtlamış, mümkün olduğu kadar az Ar-Ge çalışması gerektiren bir üründen yana kullanmayı tercih ettik.

Böylece Sikulix ile vedalaştık. Tıpkı ilk aşk gibi, “ayrıldık ama hiç unutmayacağız!”

Devam eden Ar-Ge çalışmalarının ardından Smart Bear firmasının TestComplete ürününü mobil cihazlar için test otomasyon aracı olarak seçtik. Tıpkı Sahi gibi TestComplete ürüne de yukarda açıklanan birinci tür metodolojiyi kullanıyor.

“Sahi” test otomasyonu tecrübesi ile oluşturduğumuz framework yapısını TestComplete mobil platformuna taşımamız bize büyük hız kazandırdı. TestComplete ürününün mobil yanında web ve hatta desktop uygulamalarını da test edebiliyor olması bizi heyecanlandırıyor.

Hele TestComplete ürününün farklı platformdaki testleri tek bir senaryoda yapabiliyor olması, örneğin Android cihazda başlayan bir senaryonun bilgi aktarımından sonra web uygulamasında devam edebiliyor olması şapkamızı havaya uçuruyor.

Bu günlük de bu kadar olsun. Gelecek yazıda Sahi ve TestComplete deneyimlerimiz ve kurduğumuz test otomasyon mimarisi hakkında bilgi vermeye devam edeceğim. 
Sözümüzü Google şirketinin mottolarından biriyle bağlayalım:

“Her yazılımcı test yapacak, her testçi de kodlama yapacak!”

Seyit BALKUV

7 Eylül 2015 Pazartesi

Yazılamayan “Test Otomasyonu” yazısı

Tepkiler  
Yıllar önce şöyle bir şey duymuştum: Satın aldıkları ürünü beğenen tüketiciler memnuniyetlerini 2-3 kişiye söylerken memnun olmayanlar en az 10 kişiyle şikâyetini paylaşırmış.
Bu yazıyı hazırlamadan önce, bu sözü doğru hatırladığımdan emin olmak için internette kısa bir tur yaptım ve tabii fazlasını buldum.

Mesela Pete Blackshaw adında biri şöyle bir kitap yazmış: “Mutlu müşteriler 3 arkadaşına söyler, kızgın müşteriler 3000”. Bir diğeri gül kondurmuş: “Mutlu müşteriler 3 arkadaşına söyler, kızgın müşteriler Google’a söyler”

Kendinizi düşünün, arkadaş sohbetlerinizde satın aldığınız bir ürünle ilgili daha çok memnun olduğunuz vakaları mı anlatıyorsunuz yoksa şikâyetlerinizi mi?

Demek ki, öncelikle müşteriye sorunsuz ürün vermek gerekiyor. Müşteri memnun olduğunu arkadaşlarıyla paylaşmasa da çok önemli değil. Önemli olan müşteri için şikâyet etmesini gerektirecek bir durum oluşmasını engellemek. Başka bir deyişle, odaklanmamız gereken şey, müşteriye “mutluyum” dedirtmek değil, “mutsuzum” dedirtmemek.

Elbette yazılım dünyası da farklı bir noktada değil ve elbette her sektörde olduğu gibi yazılım dünyasında da mutlu müşteri tesadüfen oluşmuyor. Yazılım geliştirirken özenle, sabırla nakış işler gibi çalışmıyorsanız müşteri sadakati sizin için hayalden öteye gitmeyecektir.

“Bir zincir en zayıf halkası kadar güçlüdür” derler. Bizim zincirimiz ürettiğimiz yazılımdır, halkalarımız da yazılım süreçlerimizdir; ihtiyaç belirleme, analiz, geliştirme ve elbette test.
Bunlardan sonuncusu, yani test prosesi şüphesiz kodlanmanın başladığı ilk günden itibaren sürecin kaçınılmaz bir parçası olmuştur. Buna rağmen, toplam yazılım geliştirme süreci içinde, kaynak, yöntem (metodoloji), kapsam ve derinlik bakımından yeri en zor tanımlanabilen element olmaya devam etmektedir.

Aşağıdaki soruları zaman zaman kendine sormayan yazılım şirketi yoktur sanırım :
  • Saha hatalarının birinci derecede sorumlusu test bölümü müdür?
  • Yazılım geliştirme ekibi ile test ekibi personel sayıları arasındaki oran ne olmalıdır?
  • Yazılım geliştirme ve test süreçleri 2 ayrı süreç mi olmalıdır yoksa içiçe geçmiş tek bir süreç mi olmalıdır?
  • Hangi durumlarda yapılan geliştirmeye (veya hataya) özgü özel test yapılmalı, hangi durumlarda sistemin bütünü test edilmelidir?
  • Bu hafta test ekibi çok hata yakalamış. Acaba bu, test ekibinin iyi çalıştığının göstergesi midir, yoksa yazılım ekibinin kötü çalıştığının göstergesi midir?
  • Önceki hafta test ekibi çok az hata yakalamış. Acaba bu, yazılım ekibinin iyi çalıştığının göstergesi midir, yoksa test ekibinin kötü çalıştığının göstergesi midir?
  • Ya diğer testler: İhtiyaç, analiz, kod geliştirme çalışmaları olması gerektiği yöntem ve kapsamda yapıldığını test etmeli miyiz?
  • Mevcut test politikamızın beraberinde getirdiği riskleri biliyor muyuz? Test sıklığı, kapsamı,  derinliği konusunda sınır değerlerimiz ne olmalıdır?
  • Test otomasyonu uygulamasına başlamalı mıyız?

Soru sormak iyidir. “Soru” bizi bir yerden bir yere taşıyacak ilk adımdır. Soru sormayan, sorgulamayan kişi bulunduğu yerden memnun demektir, bir anlamda statükocudur. Hiçbir şeyin birbiriyle aynı olmadığı ve her şeyin sürekli değişim halinde olduğu bu evrende uzun süre barınması mümkün gözükmemektedir.

Bu arada bilmeyenler için hatırlatalım: Son maddede bahsettiğimiz “Test otomasyonu” özetle bir yazılımın (yani ürünün) başka bir yazılım tarafından (yani test otomasyonu yazılımı tarafından) otomatik test edilmesi işlemidir.

Ve aslında bu yazının konusu test otomasyonu konusunda edindiğimiz tecrübeleri okurla paylaşmak olacaktı. Gelgelelim havadan-sudan bahsederken test otomasyonu için yerimiz kalmadı.

Belki de, blog yazarlarını “test eden” bir mekanizma olmadığından bu duruma düşmüş olabiliriz.

Gelecek yazımızda test otomasyonu konusunu hakkıyla irdeleyeceğimiz sözü vererek müsaadenizi isteyelim.

Seyit BALKUV


1 Eylül 2015 Salı

Material Design Nedir?

Tepkiler  
Material Design nedir, ne işe yarar, işimizi nasıl kolaylaştıracak?


Şekil 1 - Material Design UI Örneği

Material Design, Google tarafından geliştirilen bir tasarım dilidir. 2014’te I/O konferansında Android 5.0 Lollipop ile beraber duyurulmuştur.

Temel olarak, kullanıcılara daha kararlı bir arayüz sağlayabilmeyi amaçlıyor. Yeni gelen bu tasarım standartları ile Android uygulamalarındaki uyuşmazlık, tutarsızlık, dokümantasyon eksikliği gibi konulara bir çözüm getirilmiş oldu. Böylece kullanıcılar, daha tahmin edilebilir bir ortamda oldukları için uygulamalar arası geçişlerde zorlanmayacak,  bir uygulamanın nasıl çalıştığını daha çabuk kavrayabilecek ve daha kolay alışabilecekler.

Özellikle farklı ekran boyutlarında uygulama geliştirenlerin yaşadıkları problemleri ortadan kaldıracak ve farklı ekran boyutlarını uyumlu hale getiren akıllı arayüz geliştiricilerinin işini bir hayli kolaylaştıracak.


Şekil 2 - Işık ve Gölgelendirme Çalışmaları

Material Design Prensipleri 

Material design üç prensibe dayanıyor;



Material Metaforu

Material derken aslında ne demek istiyoruz? Özellikleri neler? Nasıl davranır?

                                                                                                                   
Rasyonel düzlem ile hareket sistemini bileştiren bir teoridir aslında material metaforu. Google’ın tanımına göre metarial, dokunulabilir gerçeklik üzerine kurulu, kâğıt ve mürekkepten ilham alınmış buna rağmen teknolojik açıdan gelişebilir ve yaratıcı düşünceye açık bir malzemedir. Işığın, yüzeyin ve hareketin temel prensipleri bize objelerin nasıl hareket ettiği, nasıl etkileşime geçtiği ve uzayda ki varlığı ile ilgili bilgi verir.


Yani özetle, fizik kurallarını aşmadığımız ve inandırıcılığımızı kaybetmediğimiz sürece hayal edebileceğimiz her şeyi yapabiliriz.

Material Design Özellikleri

  I.   Ortam

Material design ile tasarım yaparken kullandığımız ortam 3D ortamdır. Yani x, y ve z düzlemlerini kullanıyoruz. Z ekseni ekrana dik bir şekilde konumlandırılmış. Böylece pozitif z - ekseninde yapılan artışlar kullanıcıya doğru yapılmış oluyor. Ve kullanıcı gerçeklik hissine kapılıyor.


Işık ve gölgelendirmeler,  z - ekseninde ki yükseltme işlemini yapmamıza yarıyor. Bu sayede elementler arasında ki yükseklik farkını gösterebiliyoruz. Anahtar ışığı açılı gölgeler oluştururken, ortam ışığı daha yumuşak ve her yönden gölge oluşturur.


Şekil 3 – Z – eksenindeki Yükseltme(Elevation) İşlemi



II.   Fiziksel Yapısı

Material x ve y eksenlerinde farklı ölçülere sahip olabilirler. Ama z ekseninde sabit ve 1 dp kalınlığında olmalıdır. Uygulamalarımız da ki elementlerin kâğıtlardan oluştuğunu düşünüyoruz. İçeriklerin herhangi bir kalınlığı yoktur.


Nesnelerin gölgeleri yüksekliklerine bağımlı bir şekilde doğal olarak değişmeli. Renklendirme ile gölgelendirmeyi arttırmaktan kaçının. Cismin yüksekliğine bağlı olarak değişen gölgelendirme sistemini kullanın böylece istikrarlı bir yapıdan vazgeçmemiş oluyoruz

Doğru : Nesneler birbirinden yükseklikleri ile ayrılır

Yanlış : Nesneleri renklendirerek gölgelendirme




Material katı bir cisimdir. Dolayısıyla inputlar sadece ön plandaki nesneyi etkileyebilir.


Birden fazla material aynı noktada bulunamaz. Eğer bulunacaksa bile aynı köşelere sahip olmaları gerekir ki buna da seam(dikiş) demişler.


Birbirlerinin içinden geçemezler


Material şekil değiştirebilir, kendi ekseninde büyüyüp küçülebilir. Floating Action Button, nam-ı değer FAB material’in bu özelliğinin en güzel örneği bence.  FAB ile yeni bir pencere açabilir ya da pop-up dialoglar yaratabilirsiniz
Kendi ekseninde büyür, küçülür.

Şekil değiştirebilir


Material katlanamaz ya da kıvrılamaz. Online Ikea kataloglarında ki o kıvırma olayını rafa kaldırıyoruz. Ayrıca Smart Paper’dan da biraz bahsetmek istiyorum. Akıllı kâğıt dedikleri şey ayrılabilir, parçalanabilir ve ayrıldıktan sonrada tekrar iyileşebilir yani mükemmel bir şekilde tekrar bir araya gelebilir bir kâğıt yapısıdır

Yanlış : Katlanamaz Kıvrılamaz

Doğru : Smart Paper Liste Örneği

Doğru : Smart Paper


Yükseklik (Elevation)



Nesnenin z - eksenindeki pozisyonuna göre yapılan gölgelendirmedir. Resimde card, app bar ve FAB yapılarını görüyoruz. Bu nesnelerin her birinin kendine özel bir yüksekliği vardır

Tasarımcılar uygun olan yükseklikler ile ilgili standartlar koymuşlar. Mesela, cardlar normalde 2 dp yükseklikte durmalı, basıldığında ise 8 dp yüksekliğe çıkmalıdır. Bu standartları detaylı olarak

Google’ın design sayfasında bulabilirsiniz:


Basıldığında yüksekliğin artması kullanıcıya mıknatıs hissi vermek için yapılmış. IOS’ tada basıldığında koyulaşan butonlar kullanıcının etkileşime geçtiğini anlaması için önemli.



Şekil 1: FAB(Floating Action Button)

Şekil2 : Raised Button


Nesnelerin diğer nesneler ile ilişkisi, ağaç yapılarına benziyor. Aynı şekilde XML dosyalarında ki parent - child ilişkisine bağlı. Her objenin bir ebeveyni vardır ve her obje istediği kadar çocuk edinebilir. Çocuk ebeveyninden dönüşüm özelliklerini alabilir. Pozisyonu, rotasyonu, ölçüsü (scale), yüksekliği (elevation) gibi.

Şekil 1’ deki card yapıları scroll edilirken FAB sabit kalıyor. Çünkü FAB, card koleksiyonunun çocuğu değil. Şekil 2’deki raised button yapısı ise card yapısının çocuğu olduğu için (kalıtım sebebiyle) scroll hareketini yapıyor.

Cesur, Grafik, Amaca Yönelik

Grafik tabanlı bir tasarım için tipografi, gridler, layoutlar ve renk gibi konularda dikkat edilmesi gerekilen noktalar nelerdir?

Genel olarak arayüz elementlerinin göze güzel gelmekten çok daha fazlasını yaptığını anlatıyor. Aslında arayüz kullanıcıya uygulamayı nasıl kullanması gerektiğini göstermelidir. Kullanıcı aktivitelerinin vurgulanması, ana fonksiyonları görünür kılar ve kullanıcıya bir yol haritası sunar. Bu yüzden material design ile düşünülerek seçilmiş renkler, köşeden köşeye resimler, büyük ölçekli yazılar kullanarak cesur ve grafik bir arayüz yaratmaya çalışıyoruz.

Özetle amaca yönelik olmalı, grafik olmalı ve sizi yansıtmalı böylece kullanıcı ile aramızda evrensel bir dil kullanmış oluruz.

Renk Paletleri

Google'ın Material Design sitesinde ki renk paletleri



Google renk paletleriyle Material design için geniş bir renk yelpazesi vermiş. Burada bilmemiz gereken en önemli şeylerden birisi bu renkleri nerelerde ve nasıl kullanmamız gerektiği. PrimaryColor ve AccentColor neyi ifade eder?

PrimaryColor, uygulamamızın app barında kullandığımız ve genel olarak markamızı ya da uygulamamızı tanıttığımız temel rengimizdir.

AccentColor ise, vurgulamak istediğimiz ya da ana metinden ayırmak isteğimiz noktalarda kullandığımız rengimizdir.

AccentColor yanlış tercih edilirse aşağıda örnekte ki gibi amacımıza ulaşamayız o yüzden renklere de dikkat etmeliyiz.

İkonlar 



Uygulama ikonu kullanıcı dostu, basit ve güçlü olmalı. Markanın görsel temsilcisi olduğu için ürüne özel olmalı ve markayı yansıtmalı.

Kendilerinin tasarladıkları sistem ikonları olduğu gibi istersek biz de ikon tasarlayabiliyoruz. Burada dikkat edilmesi gereken noktalardan biri sistem ikonlarının hepsinin 24x24 px boyutunda olması gerektiği. Daha sonraki boyut ayarlamalarını dp (density-independent pixels) üzerinden yapıyoruz.

Tipografi

Roboto ve Noto adında iki yazı tipi geldi. Roboto sadece Latin ve Latin benzeri dilleri karşılayabiliyor. Güney, Güneydoğu Asya ve Orta Doğu dillerini (Korece, Japonca, Çince, Farsça, Arapça, Hintçe vb.) ise Noto karşılıyor



Faydalı Linkler : 
Renk ve Tema: 


Roboto ve Noto:


Yazım ile ilgili: 


Layout ve Rehber Gridlerin Standartları:


Component:


Patterns:


Devices:


What is New:


Referans:


Yağmur GÜLDALI

10 Ağustos 2015 Pazartesi

ALM (Application Lifecycle Management) Nedir?

Tepkiler  
Son dönemde arama motorlarında SDLC(Software Development Life Cycle)  arattığımızda; karşımıza gelen listede SDLC nin yanında  ALM  adında birçok sonuç görmekteyiz. Peki nedir bu ALM ? SDLC ile ALM arasındaki farklar nelerdir? Bu yazımızda bu konuya açıklık getirmeye çalışacağım.

Uygulama yaşam döngüsü (ALM-Application Life Cycle Management) kavramını kısa bir şekilde açıklamak o kadar kolay değil.  SDLC ile ALM birbirlerine çok yakın kavramlar gibi gözükse de bu yaklaşım çok sınırlı ölçüdedir. ALM , SDLC’den çok daha büyük bir kavramdır.

Yazılım Mühendisliği altında bir kavram olarak SDLC yi incelediğimizde; SDLC çeşitli yazılım geliştirme metodolojilerini kapsamaktadır. 

ALM, bir uygulamanın yaşamını(büyümesi, geliştirilmesi, bakımı) yöneten ve devamlılık arz eden bir süreçtir.  ALM’i  iş yönetimi ile yazılım mühendisliğinin birlikteliği olarak düşünebiliriz. ALM  İstek Yönetimi, Mimari, Tasarım, Kodlama, Test , izleme, Sürüm Yönetimi’ nin  bir arada çeşitli araçlar yardımıyla yürütülmesini kolaylaştıran metodolojileri sağlar. ALM bir uygulamanın yaşamını araç ve süreçler ile destekler. Araç, insanların daha verimli olmasını, süreç ise ürünün daha kaliteli olmasını sağlar.

ALM araçlarından bazıları aşağıdaki gibidir.
       HP Quality Center
       IBM Rational
       Oracle Team Productivity Center
       Atlassian JIRA
       Microsoft Team Foundation Server

ALM ile ilgili genel bilgileri verdikten sonra ALM’i detaylı incelemeye başlayalım.
ALM iş yönetimi ve yazılım mühendisliği birlikteliği dediğimize göre ALM'i 3 ana başlıkta detaylı inceleyelim.
  1. Yönetim
  2. Geliştirme
  3. Operasyonlar


Şekil 1: ALM alanları
İnsan yaşamında olduğu gibi uygulama yaşam döngüsü de belirli durumlarda sınırlar içerisine alınmıştır. Kişilerin aklına önce bir fikir gelir bunu uygulamaya dökmek ister. İlk önce uygulama yaratılır, bir sonraki büyük adım ise uygulamanın geliştirilmesi ve uygulama tamamlandıktan sonra sahaya dağıtılmasıdır. Uygulama sahadan yeni taleplerin gelmesi sonucunda güncellenebileceği gibi atıl duruma da geçebilir, atıl duruma geçen uygulamanın yaşamı son bulur.

Yönetim, bir uygulamanın başlangıcından itibaren proje yönetimi ve tüm karar verme süreçlerini kapsar. 

Geliştirme, fikir ve dağıtım süreci arasında, uygulamanın fiilen oluşturulma işlemleridir. Çoğu uygulamada, geliştirme süreci uygulamanın yaşamında; birçok kez uygulamanın üst versiyona geçirilmesi yada tamamıyla yeni versiyonlar için tekrarlanır. 

Operasyonlar, uygulamanın çalışması ve yönetimi üzerinde çalışır. Kısaca dağıtım öncesinde başlar. Burada bahsi geçen üç alan önemli oluduğundan dolayı daha detaylı bir incelemeyi hakediyor.

     YÖNETİM

ALM içerisinde yönetimin amacı, uygulamanın saha ihtiyaçlarını sağladığından emin olmaktır.
Şekil 2: Uygulama bütününde yönetim aşamasının detayları

     

ALM Yönetim sürecindeki ilk adım iş ihtiyacı geliştirmedir. Şekil-2, yazılım geliştirme süreç öncesinde ihtiyacın incelenerek analiz yapılması gerektiğini gösterir. İhtiyaç analizi kabul edilir, uygulama geliştirmesi başlar, ve yönetim proje portfolyo yönetimi uygulanır.

Bazı firmalarda, bu iş kolay yoldan halledilir. Bir proje yöneticisi geliştirme ekibine yada yazılım ekibinde bu rolu üstlenen teknik bir kişiye bağlı olabilir. Diğer firmalar, merkezi bir proje yönetim ofisi ile hazırlanmış işleyiş prosedurlerinin uygulamasını sağlamak için resmi bir yaklaşım kullanır.

Geliştirmesi tamamlanmış uygulamanın versiyon seti yayınlanır, bu firmanın uygulama protfolyosunun bir kısmını oluşturur. Bir uygulama, diğer uygulamalara benzer bir şekilde firmaya kazanç sağlamalıdır bu nedenle kurum devam eden uygulamanın getiri ve giderlerini analiz etmelidir. Uygulama Portfolye Yönetimi(Application Portfolio Management(APM)) bunu sağlar, farklı uugulamalardaki geçişlerde kullanılan çoklama fonksiyonlarından kaçınmayı önerir, hatta sahaya dağıtılmış uygulamanın yönetim(kontrol) işini de sağlar. Aslında, Yönetimin APM kısmında, uygulamada herbir revizyon için daha ayrıntılı olarak iş ihtiyacının analiz edilmesi ve proje portföy yönetimi geliştirme çizgisi üzerinde gösterir.

Yönetimdeki önemli olan şey; içinde bulunulan ALM zaman çizgisinin başından sonuna kadar devam etmesidir.


GELİŞTİRME

Yazılım geliştirme süreci ile ALM’i kıyaslamamak gerekir. Geliştirme süreci uygulama yaşam döngüsünun temel parçasıdır.



Şekil 3: Geliştirme uygulama yaşam döngüsünün ilk bölümünde başlar. Uygulamanın gelişmesi periyodik olarak gerçekleşir.

Sahadan gelen işin kabul edilmesi ile yazılım yaşam döngüsü(SDLC) başlar. Şekil 3 teki geliştirme çizisinin SDLC kısımlarını açacak olursak, yeni bir iterasyonun bir serisindeki yazılım geliştirmeyi göstermektedir. Her bir iterasyon istek maddeleri ,dizayn, geliştirme, test aktivitelerini içermelidir.

Sahaya verilmiş uygulamanın ilk versiyonu için SDLC işlemi bir kez işler. Çoğu uygulama için , uygulamanın sahaya dağıtılması, geliştirmenin tamamlanması anlamına gelmez. Uygulamanın periyodik olarak update edimesi gerekebilir. Resimde de görldüğü gibi, bir geliştirme birden fazla SDLC’den oluşabilir. Her versiyon için ayrı bir SDLC süreci oluşturulur.

ALM ile SDLC yi eş anlamlı düşünmek doğru değildir. ALM bir süper küme SDLC ise bu kümenin içerisinde yer alan alt küme olarak düşünülmelidir.


OPERASYONLAR

Sahaya verilmiş her uygulama izlenir ve yönetilir. Şekil 4 operasyonlar sırasındaki bazı önemli kısımları göstermektedir.



Şekil 4: Operasyon işlemleri; Uygulama sahaya dağıtılmadan önce başlar, uygulamanın sahadan kaldırılmasına kadar devam eder.

Yönetimde olduğu gibi , operasyonlarda geliştirme çizgisiyle bağlıdır. Örneğin, uygulama tamamlanmadan önce uygulamanın sahaya dağıtılması ile ilgili planlama yapılır.

Dağıtım, operasyonların temel parçasıdır. Uygulama bir kez dağıtılır, yaşamı boyunca izlenir. Uygulamada yapılan her türlü güncelleme tamamlandığında bir kez sahaya verilmesi de benzer bir durumdur.

Sonuç olarak; ALM kod yazmaktan ibaret bir yapı değildir. ALM içerisindeki yönetim, geliştirme ve operasyonlar önemlidir.

Referans :
http://www.davidchappell.com/
https://en.wikipedia.org/wiki/Application_lifecycle_management
https://social.msdn.microsoft.com

Neslihan ÇALIŞKANEL