Makale Özeti

Yeni trend Application Lifecycle Management konusuna giriş mahiyetinde bir yazı.

Makale

Application Lifecycle Management (ALM), adını son zamanlarda sık sık duyduğumuz bir kavram. Özellikle Microsoft'un Team Foundation Server 2010 ve Visual Studio 2010 sürümlerini çıkarması ve Visual Studio 2010 Lab Management'ı duyurması ile neredeyse birçok sitede adı defelarca zikredilir durumda. Peki nedir bu ALM?

ALM kabaca bir yazılımın planlanmasını, doğuşunu, büyümesini ve gelişmesini, emekliliğini ve aramızdan ayrılmasını kontrol altında tutmayı amaçlayan bir yaklaşımdır. Yalnız burada ALM'yi Waterfall gibi klasik ya da Agile, Scrum gibi popüler yazılım metodolojilerinin bir alternatifi değil onların biraz daha üstünde bir kavram olarak düşünmek gerekir.

Neden böyle bir yaklaşıma gerek var diye bakacak olursak, yazılım (ne yazık ki) çok az önemsenen bir süreçtir; çünkü müşteri için de, çoğu zaman bizim için de, basit gelir. Sonuçta kodu yazmayı biliyorsak, herşeyi yapabiliriz değil mi? Maalesef değil, günümüzde birçok yazılım projesinin sonu aşağıdaki gibi olmaktadır.

1. Proje zamanında bitmedi, uzadı
2. Proje bütçesinin üstüne çıktı
3. Proje başarısız oldu, kabul testlerini geçemedi, müşteri nihai ürünü istemedi.

Gartner'a göre Amerika Birleşik Devletleri'nde başlanan projelerin %75'i başarısız olmaktadır. Temel sebepleri ise yine yukarıda saydığımız sebepler. [kaynak]

Yazılım projeleri böyle bitiyor çünkü yazılım geliştirme işi dışarıdan göründüğü kadar basit değil ya da sadece bir teknoloiyi ya da programlama dilini kullanabiliyor olmak bu süreci başarılı bir şekilde yürütmeye yetmiyor. Açıkçası kod yazmak uygulama geliştirme sürecinin kolay kısımlarından birisidir. Zor olan, müşteriyi ve ihtiyaçlarını doğru anlamak, bu ihtiyaçlara göre doğru sistemi oluşturmak, müşterinin isteklerini yönetmek, müşteri ilişkilerini yönetmek, ekibi planlamak, test, analiz, tasarım gibi süreçlerin doğru şekilde yapılmasını sağlamak, vb..

Gördüğünüz üzere uygulama geliştirme kod yazmaktan çok daha fazlası, bu yüzden de Microsoft kod yazılan arabiriminin (Visual Studio 2010) daha çok amaca hizmet edebilmesini sağlayan bir yapıya dönüştürdü ve içine gelişmiş bir test arabirimi ekledi, mimariyi yönetebilmek için imkanlar ekledi ve bunları Team Foundation Server 2010 ile birleştirip Visual Studio ALM konseptini duyurdu.

Şimdi standart bir yazılım sürecinin hangi aşamalardan oluştuğuna bakalım,

    1. İhtiyacın belirlenmesi
    2. Proje ekibinin oluşturulması ve projenin başlaması
    3. Müşteri ihtiyaçlarının müşteriden alınması ve analizinin çıkarılması (Gereksinim analizi süreci)
    4. Müşteri ihtiyaçlarının çözüm olacak yazılım teknik çözümünün ve tasarımının oluşturulması
    5. Toplanan gereksinimlerin sağlandığından emin olmak için test ekibince test senaryolarının oluşturulması
    6. Yazılımın yazılmaya başlanması
    7. Müşteriden gelebilecek değişiklik isteklerinin yönetilmesi
    8. Kabul testi
    9. Uygulamanın canlı hayata alınması
    10. Bakım ve destek sağlanması
    11. Uygulamanın yayından/kullanımdan kaldırılması

Saydığımız 11 aşama üç aşağı beş yukarı daha sonraki yazılarımızda daha detaylı olarak bahsedeceğimiz tüm yazılım metodolojilerinde bir şekilde yer almaktadır. Dolayısı ile şimdi her aşamaya biraz daha detaylı olarak bakalım.

1. İhtiyacın belirlenmesi: İnsanoğlu neredeyse her zaman kendi ihtiyaçlarını giderebilmek için çalışan bir organizmadır. Sadece yazılım olarak düşünmeyelim, havayolu endüstrisi insanların seyehat ile ilgili problemlerine çare olmak için gelişti, ondan önce trenler daha büyük yükleri uzun misafirlerde taşımak için, konut endüstrisi insanın barınma ihtiyaçlarına çözüm olmak için gelişti ve bugün yer, konfor, güvenlik ve teknoloji gibi değişen ihtiyaçlarına da çözüm olabilmek için bu kadar farklılaştı. Bu liste bu ve bundan sonraki tüm makalaler boyunca özetlenebilecek örneklerle uzatılabilir. Yani temelde ortada bir ihtiyaç vardır ve bizim amacımız bunu çözmektir. Yazılım projeleri de hep bu amaçla yapılmaz mı?

Bazen bir hastanenin hastalarını ve stoklarını daha iyi yönetebilmesi için, bazen de şirketin muhasebe kayıtlarını doğru şekilde tutabilmesi için. Dolayısı ile bir yazılım projesinin başlaması için ortada bir ihtiyaç olması gerekmektedir. Eğer projeniz başlıyorsa muhtemelen bir ihtiyacı görmüş ve buna çözüm bulmaya çalışıyorsunuzdur.

2. Proje ekibinin oluşturulması ve projenin başlaması: Başlanan bir projenin başarıya ulaşmasında anahtar faktör doğru insanları bi araya getirmektir. Örneğin iyi bir film yapmak için senaryo, yönetmen, çekim ekibi ne kadar önemli ise oyuncu kadrosu da aynı derecede önemlidir. Ünlü ya da ünsüz farketmez başarısız oyuncularla başlanan bir filmin başarılı olma ihtimali çok düşüktür. Yazılım projeleri için de aynı şey geçerlidir. Hangi teknoloji veya ortamda yazılım geliştiriliyor olursa olsun, doğru yetkinliğe sahip insanlar bi araya gelmezse başarısızlık kaçınılmaz olacaktır.

Proje ekibi genelde program yöneticisi (koordinatörü), proje yöneticisi, iş analistleri, yazılımcılar, test ekibi, teknik analist, mimar ve müşteri (paydaş) şeklinde vücuda gelir.

Proje, bazen müşterinin size ulaşıp çözüm talep etmesi bazen de sizin müşteriyi bulup belki henüz onun bile fark etmediği bir ihtiyacını çözüme kavuşturma teklifinizi takiben müşterinin bu teklifi kabul etmesi ile başlar.

3. Müşteri ihtiyaçlarının müşteriden alınması ve analizinin çıkarılması (Gereksinim analizi süreci): Bir yazılım projesinin köşe taşlarından birisi analiz alınma safhasıdır. İster müşteri ihtiyacını fark edip size ulaşmış olsun, ister siz müşteriye ulaşmış olun müşteriden tam olarak ihtiyacını ve isteklerini almak gerçekten başarı isteyen bir süreçtir. Bu noktada müşteri ile etkin bir iletişim şarttır. Ayrıca bu sürec program yöneticisi ve proje yöneticisinin kontrolünde alanında uzman iş analistleri tarafından yürütülür.

Deneyimli bir iş analisti, müşteriden ihtiyaçları alırken çoğu zaman müşterinin ilerde talep edebileceği şeyleri de kestirip bunları analize dahil eder. Bu da size birçok zaman kazandırır. Ancak ne kadar deneyimli olursa olsun hiç bir iş analisti müşteriden tek seferde mükemmel bir analiz alamaz. Çünkü müşteri hiç bir zaman tam olarak ne istediğini bilmez, çoğu zaman müşteri uygulamanın ilk prototiplerini gördükçe aslında neye ihtiyacı olduğunu anlamaya başlar ve burada değişiklik istekleri gelmeye başlar. Bu nokta da ise Değişiklik Yönetim Sürecini başarılı şekilde yönetmek çok önemlidir. Ayrıca daha sonra yazılım metodolojilerinden bahsederken de vurgulayacağız ama; geliştirilen birçok yazılım metodolojisi artık müşteriye erken safhalarda prototipler sunarak Değişiklik Yönetim Sürecini erken safhalarda işletmeyi hedefliyor.

4. Müşteri ihtiyaçlarının çözüm olacak yazılım teknik çözümünün ve tasarımının oluşturulması: Başlangıç analizi alındıktan ve gereksinimler belirlendikten sonra nihayatinde ortaya çıkacak uygulamanın mimari tasarımı ve teknik çözümlemesi yapılır. Bu aşama yine konusunda uzman olan ekip üyeleri tarafından yapılır. Kullanılacak teknoloji belirlendikten sonra oluşturulacak sisteminin taslağı (blue print) oluşturulur.

Burada önemli olan bir önceki adımın ne kadar başarı bir şekilde yönetildiğidir. Eğer analiz aşaması layıkınca yerine getirilmezse, yazılım geliştirme safhasında öngörülemeyecek birçok değişiklik isteği gelebilir ve bunlarda bazen sistemin başta kurulan yapısına tamemen ters düşebilir. Bu durum ise projenin kararsız haline gelmesine yol açabilir ya da ön görülmemiş ve planlanmamış bir çok eforun harcanmasına sebep olabilir.

5. Toplanan gereksinimlerin sağlandığından emin olmak için test ekibince test senaryolarının oluşturulması: Test gerçeklenmek istenen projenin, müşterinin ihtiyaçlarını tam olarak kapsayıp kapsamadığının kontrolü, üretilen çözümün kalitesinin sağlanması ve canlı hayatta istenmeyen birçok durumun önüne geçilebilmesini sağlayan hayati önemdeki bir süreçtir. Birçok proje de test süreci tamamen yanlış işletilmektedir. Örneğin test ya hiç yapılmaz ya da tamamen yazılımın sonunda yapılır; bazen de bu işin uzmanı olan ekip elemanları ile test süreci yürütülmek yerine yazılım geliştiren ekip üyeleri ile bu süreç yürütülmeye çalışılır. Bu yanlış uygulamalar da yine projenin başarısız olmasına sebep olabilmektedir.

Test yazılım geliştirmenin ayrılmaz bir parçası olup, test ile paralelde yürümesi gereken bir süreçtir. Daha en başta yazılım başlamadan önce, analiz alındıktan sonra alın an analizin uygulama ile karşılanıp karşılanmadığını ölçmek için analizlere göre test senaryoları oluşturulmalıdır. Yine burada da görülebileceği gibi analizin doğru alınmaması test sürecinin verimini düşürüp, olumsuz sonuçlara sebep olabilmektedir.

6. Yazılımın yazılmaya başlanması: Ne kadar kod yazmak, sürecin kolay kısımlarından biri desekte tabi ki aslında herşeyidir de. Sonuçta amaçlanan iş yazılım geliştirmektir, dolayısı ile bu sürecin de gerekli önem verilerek, gerekli yeterlilikteki uzmanlar ile gerçekleştirilmesi gerekir. Birçok yazılım metodolojisinde yazılım geliştirme işi farklı düzenlerde yapılmaktadır ki bunlara daha sonra ki yazılarımızda değineceğiz.

Yazılım geliştirme sürecinde önem verilmesi gereken bir konu kod gözden geçirmesidir; çünkü yazılım belli bir mimari yapıya ve kurallara uygun olarak yapılmaktadır. Özellikle yazılım ekibine yeni katılan üyeler olmak üzere yazılımcıların bu kurallara ve mimariye mümkün olduğunca sadık kalması zorlanması gerekir. Bu amaçla yazılan kodlar daha deneyimli yazılımcılar tarafından gözden geçirilerek kod kaynağına atılmalıdır ki mimariye ve kurallara uyuma gerekli önem verilsin. Şayet bu süreç de gereğince yerine getirilmezse mimariye ve kurallara uymayan yazılımcılarda bu alışkanlık haline gelecektir.

7. Müşteriden gelebilecek değişiklik isteklerinin yönetilmesi: Üçüncü adımdaki müşteri ihtiyaçlarının toplanması süreci ne kadar başarılı şekilde yürütülmüş olursa olsun, daha önce de bahsettiğim gibi müşteriler tam olarak ihtiyaçlarının ne olduğunu bilemezler. Gereksinim analiz sürecinde harcanan onlarca saate ve yapılan onlarca toplantıya rağmen müşteri sonuçta ortaya çıkacak resmi göremedikçe kendilerinin bile fark etmediği ihtiyaçlarını size aktaramayacaktır. Bu ihtiyaçlarda yazılım sürecinin ilerleyen safhalarında size değişiklik isteği olarak dönecektir.

Yazılım projelerinde bu değişiklik isteklerini doğru şekilde yönetmek hayati ise öneme sahiptir. İlerleyen yazılarımızda bu isteklerin en sorunsuz şekilde yönetilmesi için izlenmesi gereken yöntemlerden de bahsedeceğiz.

8. Kabul testi: Yazılım sürecinin sonunda ortaya çıkan uygulamanın canlı hayata alınması için öncelikle müşterinin katılımı ile gerçekleştirilen bir teste tabi tutulması gerekir. Bu testte ortaya çıkan nihai ürünün müşteri ihtiyaçlarını ne kadar karşıladığı ve kabul edilebilir olup olmadığı test edilir.

Kabul testlerinin uygulanması da çoğu zaman önemsenmeyen bir durumdur ya da yanlış şekilde uygulanması da sık sık karşılaşılan bir durumdur.

9. Uygulamanın canlı hayata alınması: Yazılımı tamamlanan ve kabul testlerinden geçen projelerin canlı hayata alınması sürecine geçilir. Bu süreç normalde bu konu için özelleşen ekipler tarafından yürütülmesi en idalidir. Ancak yine çoğu zaman görülüyor ki bu işte proje ekibine kalmaktadır.

Uygulamanın canlı hayata nasıl alınacağı gereksinim analizi sürecinden sonra belirlenmesi gerekir. Çünkü bazen projenin sonuna gelindiğinde uygulamanın canlı hayata alınma şekli tamamen projenin yapısına ters düşmekte ve yine planlanmayan eforların harcanmasına sebep olmaktadır.

10. Bakım ve destek sağlanması: Uygulama canlıya alındıktan sonra, garanti süresine benzeyen bir süreç yürütülür. Uygulama da kodlamadan veya yazılımdan kaynaklanan oluşabilecek kesintilere destek verilir ve anlaşmalara bağlı olmak üzere yazılım üzerindeki güncelleştirmeler ile bakım yapılır.

Bu süreç de profesyonelce yürütülmesi gereken bir süreçtir, çünkü bu süreci yürütmekteki başarınız size aynı müşteriden yeni işlerin gelmesini sağlayıp müşteri memnuniyetini arttırabileceği gibi; sürecin başarısız bir şekilde yürütülmesi halinde ise hukuki anlaşmazlıklara varan sorunların ortaya çıkması mümkündür.

11. Uygulamanın yayından/kullanımdan kaldırılması: Her şeyin bir sonu olduğu gibi, onca emek ile oluşturulan projenin de elbet bir sonu olacaktır. Bu son sadece uygulamayı silmek kadar basit değildir, uygulamayı yayından kaldırmakta başlı başlı başına üzerinde durulması gereken bir eylemdir.

Bu süreç müşteri ve program yöneticisi tarafından alınan karar ile başlar ve iki tarafın gözetiminde uygulama yayından kaldırılır.

Bu yazımızı ALM'nin tarifi ve standart bir yazlım sürecinin aşamalarını anlatarak noktalıyoruz. Bundan sonraki makalelerimizde yazılım metodolojilerini, Visual Studio 2010 ile ALM gibi konulara bakacağız.

Application Lifecycle Management