Ana içeriğe atla

ALM (Application Lifecycle Management) Nedir?

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

Yorumlar

  1. Siteniz cok faydali. Senide benim soteme beklerim www.sinavdonemi.blogspot.com

    YanıtlaSil

Yorum Gönder

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara