ALM - Uygulama Yaşam Döngüsü Yönetimi - Uygulama yaşam döngüsü yönetimi.

Yazılım geliştirme oldukça karmaşık bir girişimdir. Yeterince iyi tanımlanmış özelliklere sahip, kabul edilebilir kalitede, ayrılan bütçe dahilinde ve zamanında gerçekleştirilen bir yazılım ürünü oluşturmak, çok sayıda uzman arasında çok sayıda eylemin sürekli koordinasyonunu gerektirir. Son 15 yılda, yazılım ürünü geliştirme tam teşekküllü bir endüstri haline geldi, belgelenmemiş, tamamen bireysel bir yaklaşıma yer yok, bu nedenle uygulama yaşam döngüsü yönetimi metodolojisinin ortaya çıkmasının gözle görülür bir trend haline gelmesi doğaldır.

Elbette, yazılım geliştirme sürecinde, yetenekli programcıların sanatına ve bir yazılım ürünü oluşturma süreçlerinde diğer katılımcıların mesleki becerilerine yer olacaktır, ancak bugün, bu gerçeğin önemli bir farkındalığı haline geldi. aktivitede bireyin tutarsızlığına, kayıtsızlığına ve diktesine yer yoktur. Yazılım sistemleri endüstrisinde bu yüzyılın ilk on yılındaki en dikkate değer trendlerden biri, ALM'nin (Uygulama Yaşam Döngüsü Yönetimi, ALM) ortaya çıkmasıydı - uygulama yaşam döngüsü yönetimi .

Böyle bir yaklaşım, bir yazılım ürününün yaratılmasını bir iş süreci olarak ele alarak ve döngüsel yapısını dikkate alarak yönetim disiplinini geliştirmeye getirmelidir. ALM fikrine uygun olarak, herhangi bir yazılım çözümü üzerindeki çalışma, devreye alma aşamasında bitmez: sistem modernleştirilir ve geliştirilir, her seferinde uygulama yaşam döngüsünün bir sonraki turunu başlatan yeni sürümler yayınlanır.

Forrester Research analistleri, yazılım endüstrisi için ALM ile ERP'yi karşılaştırıyor. Doğru, ALM'nin geçmişi çok daha kısadır ve henüz karşılaştırılabilir bir başarılı uygulama listesiyle övünemez. Analistler, bu tür çözümlere yönelik nesnel ihtiyaçlara rağmen, ALM araçlarının hala sınırlı kullanımda olduğunu ve pazarlarının hâlâ parçalı olduğunu kabul ediyor. Piyasa gözlemcileri, mevcut ALM tekliflerinin hiçbirinin uygulama yaşam döngüsü yönetimi otomasyon araçlarının tüm potansiyel faydalarını ve yeteneklerini tam olarak gerçekleştirmediğine inanıyor. Bununla birlikte, güvenilir ve yüksek kaliteli yazılımlar oluşturmak için kontrollü, öngörülebilir, verimli süreçlere yönelik geliştirme gelişimine, bu süreçleri otomatikleştirmek için uygun platformların ortaya çıkması eşlik edemez.

ALM satıcıları, yazılım geliştirme sürecini desteklemek için çeşitli araçlar ve teknolojiler sağlar. Bu araçlar, bireysel geliştiricinin geleneksel üretkenlik araçlarının çok ötesine geçer. Yazılım geliştirme üzerine toplu çalışmaya odaklanan metodolojiler ve araçlar sağlamayı amaçlarlar. Geçerli bir ALM çözümü oluşturmak için satıcılar, "genişletilmiş" yazılım geliştirme ekibinin ihtiyaçlarını göz önünde bulundurmalı ve ürünlerine daha büyük sürece katılan rolleri dahil etmelidir.

BT uzmanı D. Chappel, genellikle yalnızca yazılım geliştirme yaşam döngüsü (Yazılım Geliştirme Yaşam Döngüsü, SDLC) ile tanımlanan ALM'nin basit bir görüşüne karşı uyarıda bulunur: başlatma, yinelemeli geliştirme döngüsü, ürün sürümü ve uygulama. ALM disiplini, uygulamalar gibi bir kurumsal kaynağın varlığının tüm yönlerini göz önünde bulundurarak daha geniş bir görev yelpazesini kapsar. Tanım olarak, D. Chappel, bir uygulamanın yaşam döngüsü, bir kuruluşun bu kaynağa şu veya bu şekilde yatırım yaptığı tüm aşamaları içerir - bir yazılım çözümünün ilk fikrinden, kullanım ömrünün sonundaki yazılımın elden çıkarılmasına kadar .

Bu tanım HP'de son derece ayrıntılıdır - şirkete göre döngü, tam teşekküllü bir modelin aşamalarından yalnızca biridir.

ALM, uygulama teslim aşamasıdır (Şekil 3.14) ve bunun yanında planlama, işletme ve hizmetten çıkarma da vardır. Döngü kapalıdır: Kuruluş, uygulamanın yararsızlığı hakkında nihai sonuca varana kadar gelişmeye devam eder. ALM'nin yetkin bir şekilde uygulanması, diğer şeylerin yanı sıra, bir yazılım çözümünün etkin çalışma süresini uzatmayı ve sonuç olarak satın alma veya temelde yeni yazılım ürünleri oluşturma maliyetini düşürmeyi amaçlar.

İş ihtiyaç analizi

Öncelik ve yatırım

Wor4dlenne SHSHDOISH "Programların izlenmesi

mükemmellik

Planlama

Yol gösterici kararlar

Düzeltme

hatalar

izleme

ayar

uygulama yaşam döngüsü

uygulamalar

Uygunluk

Gereksinimler

tekrarlanan

islopkyuvanis

başlatma

geliştirme yinelemeleri

Teslimat

Hizmetten çıkarma

Serbest bırakmak

penetrasyon

Pirinç. 3.14. ALM modeli

D. Chappel, ALM'nin üç ana alanını vurgulayarak yaşam döngüsünün resmini doğrusal bir resme genişletir: yönetim (yönetim), geliştirme (geliştirme) ve operasyon (operasyonlar). Bu alanlara karşılık gelen süreçler, yeni bir uygulama fikrinin başlangıcından veya mevcut olanın modernizasyonu fikrinin başlangıcından, dağıtım aşamasına ve operasyonun tamamen tamamlanmasına kadar örtüşerek akar.

ALM'deki yönetişim, uygulama yaşam döngüsü boyunca uygulanır ve karar verme ve proje yönetimi ile ilgili tüm süreç ve prosedürleri içerir. Buradaki ana görev, uygulamanın ALM'nin bu bileşeninin önemini belirleyen şu veya bu iş hedefini karşılamasını sağlamaktır. Yönetim süreçlerine ilişkin olarak, D. Chappel, geliştirme aşamasından önce gelen ayrıntılı bir yatırım teklifinin (gelecekteki bir uygulama ile ilişkili maliyetler, faydalar ve risklerin bir analizini içeren bir iş vakası) geliştirilmesine atıfta bulunur; proje ve portföy yönetimi için yöntem ve araçları kullanarak geliştirme yönetimi (Proje Portföy Yönetimi, PPM); çalışan bir uygulamayı kurumsal uygulama portföy yönetiminin bir parçası olarak yönetme (Uygulama Portföyü Yönetimi, AWP).

Uygulama geliştirme, fikrin doğduğu andan bitmiş çözümün dağıtımına kadar gerçekleşir. Geliştirme süreçleri, uygulamanın yükseltilmesi veya yeni sürümlerin yayınlanması gerektiğinde dağıtım sonrasında da uygulanır. Geliştirme, tümü tipik olarak birden çok yinelemede tamamlanan gereksinimlerin tanımlanmasını, tasarımını, kodlamasını ve test edilmesini içerir.

Operasyonlar, geliştirme tamamlanmadan kısa bir süre önce planlanan ve başlatılan ve kullanımdan kaldırılana kadar devam eden, çalışan bir uygulamayı izleme ve yönetme süreçlerini ifade eder. Operasyonel süreçlerin yazılım yaşam döngüsüne dahil edilmesi anahtardır: Kurumsal uygulamaların en akut sorunlarından biri olarak kabul edilen geliştirme ekiplerinin ve operasyonel personelin parçalanmasıdır ve bunların ALM kullanılarak entegrasyonu, iş kullanımının verimliliğinde ciddi bir artış vaat eder. yazılım. Tek sorun, ALM ortamlarında bu tür entegrasyonun gerçek bir uygulama değil, hala iyi bir hedef olmasıdır.

ALM'nin pratikte açıklanan genel resmi, yazılım yaşam döngüsünün birçok aşamasını planlama ve otomatikleştirme ihtiyacına dönüştürülür. İdeal ALM ortamı, tüm katılımcıları uygulama yaşam döngüsüne entegre eder, onlara uygun kaynaklara ve görevlere tutarlı erişim sağlar ve aynı zamanda her bir rolün bağlamını anlayarak, uygulayıcılarına doğru araçları sağlar.

ALM süreçlerinde katılımcıların rollerinin ve ilgili araç takımı tarafından desteklenmesi gereken görevlerin genişletilmiş listesi şunları içerir:

• üst düzey yöneticiler - proje portföylerini yönetin ve riskler ve ürün kalitesi dahil olmak üzere temel yazılım yaşam döngüsü ölçümlerini kontrol etmek için gösterge tablolarını kullanın;
• proje yöneticileri - projenin uygulanmasını planlar ve kontrol eder, olası riskleri analiz eder ve kaynakların tahsisinden sorumludur;
• analistler - iş kullanıcılarıyla etkileşime girer, bir yazılım ürünü için gereksinimleri tanımlar, gereksinimleri ve proje boyunca değişikliklerini yönetir;
• mimarlar - işlevsel bileşenleri, verileri ve süreçleri dahil olmak üzere bir yazılım sisteminin mimarisini modellemek;
• geliştiriciler - kodlama aşamasında entegre geliştirme ortamlarını ve çeşitli yazılım kalite güvence araçlarını kullanarak kod yazarlar;
• kalite departmanı mühendisleri - otomatik test araçlarını kullanmak da dahil olmak üzere testler oluşturun ve yönetin, işlevsel, regresyon testi, performans testi yapın;
• operasyonel personel - uygulamayı izler ve yönetir ve ortaya çıkan sorunlar hakkında geliştirme ekibine geri bildirim sağlar;
• iş kullanıcıları - özel araçların yardımıyla gereksinimleri formüle edebilir, uygulama hatalarını bildirebilir ve yapılan değişikliklerin durumunu takip edebilirler.

Bununla birlikte, "geleneksel" ALM süreci, kuruluş için kar yaratmada tam potansiyeline ulaşamaz. Buradaki nokta, birçok satıcının, müşterileri kapalı teknoloji platformlarına bağlamayı amaçlayan sınırlı uçtan uca ALM çözümlerini agresif bir şekilde piyasaya sürmesidir. Müşteriler çok geçmeden bu çözümlerin mevcut geliştirme süreçleri, araçları ve platformlarıyla bütünleşmediğini keşfeder. Ne yazık ki bu, geliştirme ekiplerini ALM'nin silolu süreçleri ve veri karmaşası ile baş başa bırakır ve bu da onların ALM'nin tüm potansiyelini gerçekleştirmelerini engeller.

Birleşik ALM yazılım ortamı, yapılandırma ve değişiklik yönetimine ve yazılım sürüm kontrolüne dayalı olarak çalışma ve süreçleri yönetmeye yönelik araçlar sağlamak üzere tasarlanmıştır. Genel olarak, ALM yaklaşımlarının ve araçlarının uygulanması, uygulamaları oluşturmak ve çalıştırmak için standart süreçler oluşturmanıza, tüm projelerde bunlarla uyumluluğu kontrol etmenize, katı bir değişiklik yönetimi süreci uygulamanıza, bunların BT ortamı ve bir bütün olarak iş üzerindeki etkilerini tahmin etmenize olanak tanır. , kalite ölçümleri, üretkenlik ve geliştirme riskleri sistemi oluşturun, yaşam döngüsü boyunca bu ölçümleri takip edin ve analiz edin ve nihayetinde oluşturduğunuz uygulamaların iş hedeflerinizle gerçekten uyumlu olmasını sağlayın.

Başlangıçta, ALM'nin önemini anlayan ve ürün yayınlama stratejilerini bunu açıkça desteklemek için değiştiren birkaç yenilikçiden bazıları Borland ve IBM Rational'dı. Açık fırsatlara tepki gösteren diğer şirketler kazanan ALM konseptine katıldı: Microsoft, Telelogic, Mercury, Serena, Compuware, CollabNet ve Mercury. Bugün ALM, yerleşik bir trend ve analistler tarafından tanınan büyüyen bir endüstridir. ALM satıcıları, yazılım geliştirme sürecini desteklemek için çeşitli araçlar ve teknolojiler sağlar. Bu araçlar, bireysel geliştiricinin geleneksel üretkenlik araçlarının çok ötesine geçer. Yazılım geliştirme üzerine toplu çalışmaya odaklanan metodolojiler ve araçlar sağlamayı amaçlarlar. Geçerli bir ALM çözümü oluşturmak için satıcılar, daha büyük yazılım geliştirme ekibinin ihtiyaçlarını göz önünde bulundurmalı ve ürünlerine daha büyük sürece katılan rolleri dahil etmelidir.

İlk ALM sistemlerinin ortak bir dezavantajı, yaşam döngüsünün farklı aşamaları için modüllerin hem bir üreticinin platformu içinde hem de farklı satıcılardan gelen çözümler içinde zayıf entegrasyonuydu. Kapsamlı bir ALM platformunu kullanamayan müşteriler, onu farklı parçalardan oluşturdular ve bu da onları uçtan uca yaşam döngüsü süreç yönetimini manuel olarak uygulamaya zorladı ve böylece ALM otomasyonunun ana potansiyel faydasını eşitledi. Bu nedenle, dört yıl önce, Forrester analistleri, yaşam döngüsündeki farklı rolleri desteklemek için ortak hizmetler sağlayacak, geliştirme yapıtlarının tek bir fiziksel veya sanal deposunu kullanacak olan ALM ortamlarını iyileştirmenin ana yönü olarak entegre ALM 2.0 platformlarının ortaya çıkışını öngördü. mikro ve makro yaşam döngüsü süreçlerini yönetmek, farklı roller için araçlardan oluşan tek bir ortama entegrasyon sağlamak, yaşam döngüsünün farklı aşamaları için desteklenen uçtan uca raporlama yetenekleri.

Bugün ALM için yeni gereksinimler var ve hızlı (çevik) geliştirme yöntemlerinin yaygın kullanımı bunda belirleyici bir rol oynuyor. Birkaç yıl önce, en ünlü erken dönem Scrum yöntemlerinden birinin yaratıcısı olan D. Sutherland, erken gelişim fikirlerinin yaklaşmakta olan toplam uyarlamasını duyurdu. Bir abartı gibi görünüyordu, ancak tahminin doğru olduğu ortaya çıktı. Capgemini Group analistleri ve HP Software & Solutions tarafından yapılan ortak bir araştırmaya göre, 2010 yılında şirketlerin %60'ından fazlası çevik geliştirmeyi kullanmış veya kullanmayı planlamış ve Forrester anketi katılımcıları arasında yalnızca %6'sı hala yalnızca hızlı yöntemlere baktıklarını kabul etmiştir. , geri kalanların hepsi bir dereceye kadar bunları kullanıyor, %39'u ise uygulamalarının oldukça olgun olduğunu düşünüyor.

Geliştiriciler, çevik yöntemler kullanır ve ürünü, çevik geliştirmenin gerçeklerini dikkate almayan, çalışan uygulamaların iş gereksinimlerindeki değişikliklere yanıt verme hızının ve bunun sonucunda esnekliğin (çeviklik) önünde ciddi engeller oluşturan üretime sokar. işin özü. İşletim personelinin geliştiriciler tarafından yapılan uygulama ortamındaki değişikliklere yanıt verememesi veya isteksizliği, genellikle, yayımlanan yazılım sürümünün bileşenleri arasındaki temel bağımlılıkları yansıtmadan aşama aşama geçirilen belgelerdeki eksikliklerle ilişkilidir ve daha fazlası geliştiriciler ve operasyonel personel arasında güvenilir ve otomatik bir iletişim kanalının olmaması nedeniyle küresel olarak. Bu sorun, modern veri merkezi yönetim otomasyon araçlarının yaygınlaşması ve bulutlar da dahil olmak üzere BT altyapılarının uygulanmasına yönelik yeni yaklaşımlarla daha da kötüleşiyor. Son derece otomatikleştirilmiş ve uygulamaları olabildiğince hızlı dağıtmak için tasarlanmış bu tür ortamlar, otomatik bir iletişim kanalının yokluğunda ve geliştirme ve operasyon aşamaları arasında uçtan uca süreçlerin uygulanması olmadan değişikliklere yanıt veremez.

Sorunun ciddiyetine ilişkin farkındalık ve buna çözüm arama eğilimi, geliştirme ve operasyonlar arasındaki etkileşimi geliştirmeye yönelik kavram ve teknolojilere atıfta bulunan yeni DevOps terimini bile ortaya çıkardı. Bu fikirlerin uygulanmasına yönelik ana umutlar, analistler tarafından teoride değil pratikte uygulama yaşam döngüsünün önemli aşamalarının entegrasyonunu sağlayacak yeni nesil ALM ortamlarına yerleştirilir. Bugün oluşturulan uygulamalar, çoğu durumda, hizmet ilkeleri temelinde, farklı platformlar için farklı programlama dillerinde uygulanan bileşenlerin yanı sıra harici sistemlerin ve eski çözümlerin kodlarını birleştirir ve entegre eder. ALM ortamının yaşam döngülerini yönetmek için birden çok geliştirme ortamını ve çalışma zamanı platformunu (NET ve J2EE gibi) ve ayrıca kaynak kodunu, lisanslamayı ve harici uygulama bileşenlerinin geliştirme durumunu kontrol etme becerisini desteklemesi gerekir.

Analistler, Çevik süreçlerin yaygın olarak benimsendiğinin işaretleri arasında, bu yöntemlerle ilgili olarak ortodoksiden uzaklaşan kuruluşlara işaret ediyor. Geliştiriciler, yeni sistemler üzerinde çalışmayı optimize etmelerine izin veriyorsa, farklı süreçleri birleştirmekten korkmazlar, bu nedenle ALM 2.0 ortamı, geliştirme, portföy yönetimi ve ürün kalite güvencesi alanlarında farklı süreçleri ve metodolojileri desteklemelidir. İkincisi özellikle önemlidir: gereksinimlerin tanımlanmasından test edilmesine ve çalıştırılmasına kadar uçtan uca kalite yönetimi süreçlerini otomatikleştirmek, uçtan uca bir ALM platformunun en güçlü yönlerinden biri olabilir.

Yazılım yaşam döngüsünün çeşitli aşamalarını desteklemek için Rational ürün grubu, her zaman genişliği ve modüllerin kendi aralarında entegrasyonuna odaklanmasıyla ayırt edilmiştir. Butler Group analistleri, uygulanan ALM bileşenlerinin çeşitliliği açısından IBM Rational Software and Systems Delivery'yi piyasadaki en eksiksiz çözüm olarak değerlendirdi. Bu paket proje portföy yönetimi, model tabanlı tasarım ve geliştirme, gereksinim yönetimi, yapılandırma ve değişiklik yönetimi, kalite yönetimi, oluşturma ve sürüm yönetimi; yazılım yaşam döngüsü süreçlerini düzenlemek ve bu süreçlere ilişkin raporlama ve dokümantasyon sağlamak. Adındaki Systems kelimesi, çözümleri sistem mühendisliği süreçlerini desteklemeye odaklanan ve artık Rational portföyüne entegre edilen Tellogic'in satın alınmasından sonra ortaya çıktı. IBM ALM ortamına dahil edilmeleri, yazılım ve sistem geliştirme süreçleri arasındaki yakınsama eğilimini ve onlar için tek bir yaşam döngüsü yönetimi ortamının oluşumunu yansıtır.

Ancak IBM'in ALM teknolojilerinin geliştirilmesine en önemli katkısı, Jazz'ın entegre bir kurumsal uygulama yaşam döngüsü yönetimi platformunu uygulamaya yönelik bir altyapı oluşturmaya yönelik uzun vadeli projesidir. Bugüne kadar Rational ailesindeki birçok ürün Jazz platformuna entegre edildi, orijinal olarak Jazz üzerinde çalışmak üzere tasarlanmış birçok yeni çözüm piyasaya sürüldü ve gelecekte tüm platformlarda Jazz altyapısı için destek sağlanacak. Rational ailesinin bileşenleri.

Jazz'ın özü, Jazz Team Server ve bir dizi ek entegrasyon modülünü birleştiren Jazz Foundation platformudur. Jazz Team Server, yaşam döngüsünün farklı aşamaları için bileşenleri entegre etmek için ALM için yeni bir yaklaşım sergiliyor (Şekil 3.15, ). Geleneksel olarak bu tür entegrasyon, bireysel ürünler arasında noktadan noktaya bağlantıya dayalıysa, Jazz, enstrümantal bileşenlerin birbirleriyle basit bir etkileşimini sağlayan (bir tür ALM Web) REST standardına dayalı açık bir dağıtılmış hizmet mimarisi uygular. . RESTful arabirimi, çeşitli modüllerin verilerinin ve işlevlerinin hizmetler olarak temsil edilmesini sağlar. Web standartlarına dayalı bir yaklaşım kullanmak, Jazz'ı yüksek düzeyde ölçeklenebilir hale getirerek platformu küçük ekiplerde ve büyük geliştirme ekiplerinde ALM görevlerini destekleyebilen çok yönlü bir çözüm haline getirir.

Proje ve Ekip Yapısı

olay bildirimi

Caz Takımı Sunucusu

Gereksinimler Öğeler ve ilişkiler IlJ Olay geçmişi,

"Vakaları ...... Öğe geçmişi eğilimlerini kullanın

Kaynak kodu oluşturur. Test durumları Test sonuçları

Güvenlik ve Erişim

Pirinç. 3.15. Entegre Kurumsal Uygulama Yaşam Döngüsü Yönetim Platformu

Jazz Foundation, modern bir uygulama yaşam döngüsü yönetimi ortamının temel yeteneklerini etkinleştirmek için tüm ALM bileşenlerinde ortak olan hizmetler sağlar. Bunlar, örneğin, ortak sorunları çözme sürecinde çeşitli ekip üyelerinin etkileşimini sağlayan, yaşam döngüsünün farklı aşamaları arasındaki ilişkileri sürdüren ve aynı zamanda ALM'deki her belirli rolün bağlamını dikkate alan işbirliği hizmetleridir. . Caz destekli işbirliği araçları, anında mesajlaşma, uzun tartışma araçları, wiki'ler ve diğer popüler Web 2.0 özelliklerini kullanır. Bu durumda, ekip üyeleri arasındaki tüm etkileşimler, bu etkileşimlerin kaynağı olarak hizmet eden eserler (örneğin, kusurlar veya test durumları) ile bağlantılı olarak depolanan proje kaynakları olarak kabul edilir.

Jazz Foundation hizmetleri ayrıca, Rational Unified Process ve çeşitli hızlı geliştirme seçenekleri dahil olmak üzere çeşitli metodolojilere göre süreçleri tanımlamanıza ve yürütmenize olanak tanır. Bu amaçla olay bildirim araçları, belirli iş akışlarının yürütülmesinde ekip üyeleri arasındaki iletişim için destek, kuralların uygulanmasının belirlenmesi ve kontrol edilmesi, temel görevlerin otomatikleştirilmesi, yaşam döngüsünün farklı aşamaları için araçlar kullanılarak iş akışlarının düzenlenmesi sağlanır. Projenin durumu, sorunları ve riskleri hakkında kesin süreç metriklerinin sunulduğu ve gerçek zamanlı da dahil olmak üzere çeşitli düzeylerde takip edilmesi için gösterge tablolarının sağlandığı yaşam döngüsü süreçlerinin ve süreç yönetiminin şeffaflığının sağlanmasına çok dikkat edilir, bireysel süreç katılımcılarından ekibe ve portföy yönetimi düzeyine. Diğer Jazz Foundation hizmetleri arasında arama motorları, güvenlik araçları, rol tabanlı erişim ve tüm geliştirme kaynakları için dağıtılmış bir havuz bulunur.

Jazz platformu, bir dizi görünüm ve projeksiyon sağlayarak Eclipse geliştirme ortamıyla bütünleşir. Bazı Jazz bileşenleri ayrıca web istemcilerini de destekler. Jazz çerçevesi Eclipse için iki önemli görüş sağlar: Team Central ve Team Artifacts. Her iki görünüm de bilgi toplamak için kullanılır ve Jazz platformu bileşenleriyle genişletilebilir. Eclipse tarafından geliştirilen Jazz platformunun bazı bileşenleri, kullanıcıların doğrudan bir web tarayıcısından Jazz sunucusuna erişmesine olanak tanır.

Jazz web kullanıcı arayüzü bu özelliği sağlar. Bu arabirim, istemci bilgisayara herhangi bir özel yazılım yüklenmesini gerektirmediğinden, bir IDE yerine ara sıra veya ara sıra kullanıcılar için daha uygundur; tek ihtiyacınız olan bir web tarayıcısı. Her Jazz sunucusunun, kullanıcının bir proje alanı seçip oturum açabileceği bir ana web sayfası vardır. Oturum açtıktan sonra, kullanıcı Jazz sunucusuyla etkileşime girebilir ve en son olayları kontrol etme, iş akışı öğelerini girme ve güncelleme ve derlemeleri indirme dahil olmak üzere Jazz deposundaki bilgileri keşfedebilir.

Rational ailesine özellikle Jazz üzerinde çalışmak üzere inşa edilen en heyecan verici yeni eklemeler arasında, tamamen Jazz mimarisi üzerine inşa edilmiş bir işbirliği ve yazılım yaşam döngüsü süreç otomasyon ürünleri paketi olan Rational Team Conceit (RTC) yer alıyor. IBM Rational Team Concert, birçok geliştiricinin öğrendiği çok projeli bir ortamda bilgi sistemlerinin geliştirilmesini organize etmek için tasarlanmış eksiksiz bir ortamdır. Araç, geliştirme uzmanlarının çabalarını birleştirmenize, etkin etkileşimlerini düzenlemenize ve proje boyunca tüm proje faaliyetleri üzerinde en yüksek düzeyde kontrol sağlamanıza olanak tanır.

RTC, yazılım konfigürasyon yönetimini, görev ve yapı yönetimini ve yineleme planlamasını ve proje raporlamasını uygular, çeşitli geliştirme süreçlerini tanımlar ve eksiksiz yazılım yaşam döngüsünü desteklemek için diğer Rational ürünleriyle bütünleşir. 2009'da IBM, Jazz tabanlı bir test yönetimi portalı olan Rational Quality Manager'ı ve yüksek seviyeli geliştirme projesi portföy yönetimi için Cognos analitiğini kullanan Jazz platformu için oluşturulmuş bir performans yönetimi aracı olan Rational Insight'ı da piyasaya sürdü.

IBM Rational Team Concert'in kapsamlı bütünleştirme yetenekleri, bu aracı kesinlikle benzersiz kılıyor. Mevcut entegrasyonlar arasında aşağıdakilere dikkat edilmelidir.

• 1. İş emirlerini, bu görevler temelinde oluşturulan veya değiştirilen gereksinimlerle ve bunun tersini, gereksinimler için iş planlaması için oluşturulan görevlerle ilişkilendirmenize olanak tanıyan, işbirliğine dayalı uygulama yaşam döngüsü yönetiminin (CALM) bir parçası olarak IBM Rational Requirements Composer ile bütünleştirme. bu gereksinimlerin uygulanması.
• 2. Yayınlanan yazılım ürünlerinin testi sırasında gerçekleştirilen testlerin sonuçlarına dayalı olarak kusur izlemeyi organize etmenin mümkün hale geldiği, işbirliğine dayalı uygulama yaşam döngüsü yönetiminin bir parçası olarak IBM Rational Quality Manager ile entegrasyon.
• 3. Klasik IBM Rational ClearQuest geliştirme yönetimi aracında tanımlanan iş emirlerini ve değişiklik isteklerini senkronize etmek için IBM Rational ClearQuest ile entegrasyon.
• 4. İki araç arasında sürüm oluşturma ve yapılandırma yönetimi yapılarını eşitlemek için IBM Rational ClearCase ile bütünleştirme.

IBM Rational Team Concert'ın temelini oluşturan açık Jazz Entegrasyon Mimarisi, bir kuruluş genelinde devreye alınabilen ve aktif olarak kullanılabilen diğer sistemlerle yeni entegrasyon mekanizmalarının ek olarak geliştirilmesine olanak tanır. Bu sistemlerle entegrasyon seçeneklerinden biri, IBM Rational Team Concert çalışma görevlerinin önceden tanımlanmış bir formattaki e-posta mesajlarına göre senkronizasyonunu sağlayan Fineco Soft şirketinin RTC Email Reader ürününün kullanılması olabilir. Aynı zamanda, yerleşik IBM Rational Team Concert bildirim alt sistemi sayesinde ters senkronizasyon da mümkündür.

Ayrıca, geliştirme ortamının (IDE) bu araçla doğrudan entegrasyonu olmasa bile, IBM Rational Team Concert'e dayalı sürüm oluşturma ve konfigürasyon yönetiminin hemen hemen her projede düzenlenebileceği unutulmamalıdır. Bu, IBM Rational Team Concert kalın istemci ve entegre edilemeyen bir IDE kombinasyonu ile mümkün olur. Dolayısıyla, Eclipse IDE, IBM Rational Software Architect, IBM Rational Application Developer ve Microsoft Visual Studio için bu tür entegrasyonlar mevcutsa, örneğin Delphi ile, ek olarak "kalın istemci" IBM Rational Team Conceit'i kullanmanız gerekecektir. çok zor değil.

Uygulama Yaşam Döngüsü Yönetimi (ALM) hızla gelişiyor. Bu, yazılım geliştirme sürecini iyileştirmek için umut verici bir yaklaşımdır. Bununla birlikte, "geleneksel" ALM süreci, kuruluş için kar yaratmada tam potansiyeline ulaşamaz. Neden? Niye? Çünkü satıcılar, müşterileri kapalı teknoloji platformlarına bağlamayı amaçlayan sınırlı uçtan uca ALM çözümlerini agresif bir şekilde piyasaya sürüyorlar. Müşteriler çok geçmeden bu çözümlerin mevcut geliştirme süreçleri, araçları ve platformlarıyla bütünleşmediğini keşfeder. Ne yazık ki bu, geliştirme ekiplerini ALM'nin silolu süreçleri ve veri karmaşası ile baş başa bırakır ve bu da onların ALM'nin tüm potansiyelini gerçekleştirmelerini engeller.

Bu sorunu çözmek için yeni bir yaklaşıma ihtiyaç vardır. Müşterilerin karma bir geliştirme ortamı kullanarak yazılım oluşturmasına olanak tanıyan bir yaklaşım. Borland'ın Open ALM çözümleri ile kuruluşlar, mevcut geliştirme kaynaklarından ve araçlarından yararlanabilir. Bu, yazılım geliştirme döngüsü boyunca şeffaflık, kontrol ve disiplin sağlamaya yardımcı olacaktır. Müşteriler artık optimize edilmiş bir ALM platformundan ve tek, yönetilebilir ve ölçülebilir bir yazılım geliştirme sürecinden yararlanabilir.

Öngörülebilir Yazılım Geliştirme: İmkansız Misyon?

Yazılım geliştirme aslında oldukça karmaşık bir girişimdir. Yeterince iyi tanımlanmış özelliklere sahip, kabul edilebilir kalitede, ayrılan bütçe dahilinde ve zamanında gerçekleştirilen bir yazılım ürünü oluşturmak, çok sayıda uzman arasında çok sayıda eylemin sürekli koordinasyonunu gerektirir.

Kuruluşlar dağıtılmış geliştirme modellerini (offshore programlama veya geçici işçi ve taşeron kullanımı gibi) kullanmaya karar verdiğinde, yazılım projelerini yönetme ve izlemenin karmaşıklığı artar. Sonuç olarak, projelerin başarısız tamamlanması veya sona ermesi yaygın bir olay haline geliyor. Maliyet aşımları, kaçırılan programlar, düşük kalite ve zayıf güvenilirlik, yazılım endüstrisinde norm haline geldi. Buna göre, yazılım geliştirme kuruluşlarından giderek daha akıllı yaklaşımlar almaları isteniyor. Daha geleneksel mühendislik disiplinlerinin adımlarını takip eden, iyi yönetilen, sistemli ve süreç odaklı yaklaşımları benimsemelidirler. bir

Artan standardizasyon ve kurumsal geliştirme platformlarının kullanımıyla, endüstrinin karşılaştığı zorluklar daha az teknik hale geldi. Yazılım geliştirmeden istikrarlı ve öngörülebilir karlar elde etme yeteneği, birçok bilgi teknolojisi (BT) uzmanı için büyük ölçüde bir öncelik haline geldi. Ekiplerinin yazılım geliştirme açısından etkili olacağına dair güvene ihtiyaçları var. Borland, bu düşünceleri göz önünde bulundurarak ALM için platformlar geliştirmiştir. Yazılım geliştirme sürecinin istikrar ve öngörülebilirliği sorununu çözmek için tasarlanmıştır.

1 CMM/CMMI süreç iyileştirme çerçevesinin hızla benimsenmesi ve dış kaynaklı geliştirme modellerinin artan kullanımı gibi başlıca endüstri eğilimleri, yazılım geliştirme endüstrisindeki bu belirgin dönüşümle yakından ilişkilidir.

ALM'nin ortaya çıkışı

Uygulama geliştirme araçları endüstrisi, öngörülebilir yazılım geliştirme ihtiyacına yanıt verdiğinden, bireysel geliştiricilere yönelik araçlardan daha fazlasına odaklanmıştır. Üreticiler tekliflerini genişletti ve hem mevcut hem de yeni özellikleri ürünlerine entegre etti. Artık çözümleri, yazılım geliştirme sürecindeki diğer rollerle ilgili görevleri yerine getiriyor. Genellikle işbirlikçi geliştirme platformları olarak pazarlanan ve satılan bu ürün paketleri, Uygulama Yaşam Döngüsü Yönetimi (ALM) teknolojisinin ortaya çıkışına işaret ediyordu. Pazarda yeni bir kategori ve yazılım geliştirmede ayrı bir disiplin haline geldi. ALM platformları, yazılım geliştirme sürecinin öngörülebilirliğini ve bütünlüğünü artırmanın zorluklarını karşılamak için özel olarak tasarlanmıştır. Süreçte yer alan her bir ana rol için entegrasyon ve otomasyon sağlayarak ve bir dizi işlevi otomatikleştirerek bu sorunları çözerler.

Bu yetenekler, BT liderlerinin yazılım proje portföylerini dengelemelerine ve önceliklendirmelerine olanak tanır. Ekiplerinin daha yüksek düzeyde yönetimini ve projelerin yürütülmesinde çok daha fazla şeffaflığı elde edebilirler. ALM ile yöneticiler ayrıca yazılım geliştirme süreci üzerinde çok daha fazla kontrol sahibi olabilirler. Bu, kurumsal yönetim için daha iyi fırsatlar sağlar ve kuruluşun çeşitli kural ve düzenlemelere uyum göstermesine yardımcı olur.

ALM Sanayi

Başlangıçta, ALM trendinin önemini anlayan ve ürün lansman stratejilerini bunu açıkça desteklemek için değiştiren birkaç yenilikçiden bazıları şunlardı: Borland ve IBM Rasyonel. Bariz fırsatlara tepki gösteren diğer şirketler kazanan ALM konseptine katıldı: Microsoft, IBM Rational / Telelogic, Mercury ve Serena. Bugün ALM, yerleşik bir trend ve analistler tarafından tanınan büyüyen bir endüstridir. ALM satıcıları, yazılım geliştirme sürecini desteklemek için çeşitli araçlar ve teknolojiler sağlar. Bu araçlar, bireysel geliştiricinin geleneksel üretkenlik araçlarının çok ötesine geçer. Yazılım geliştirme üzerine toplu çalışmaya odaklanan metodolojiler ve araçlar sağlamayı amaçlarlar. Geçerli bir ALM çözümü oluşturmak için satıcılar, "genişletilmiş" yazılım geliştirme ekibinin ihtiyaçlarını göz önünde bulundurmalı ve ürünlerine daha büyük sürece katılan rolleri dahil etmelidir.

Risk, ilerleme ve kalite gibi önemli proje ölçütlerini kapsayan, yöneticilerin ihtiyaçları için portföy düzeyinde panolar sağlanır.

Proje yöneticilerinin ihtiyaçları için proje planlama ve kontrol, olası alternatiflerin analizi ve kaynak tahsisi için araçlar sağlanmaktadır.

Analistlerin ihtiyaçları için, gereksinimleri tanımlamak, son kullanıcılar ve projenin diğer paydaşları ile etkileşim kurmak için araçlar sağlanır. Ayrıca bu seviyede, müteakip değişiklikler de dahil olmak üzere projenin yaşam döngüsü boyunca gereksinimleri yönetmek için araçlar vardır.

Mimarların ihtiyaçları için, uygulamanın çeşitli yönlerinin (bileşenler, veriler, süreç) görsel modellemesi için araçlar ve ayrıca tasarım kalıplarını ve kurumsal mimariyi tanımlamaya yönelik araçlar sağlanmaktadır.

Geliştiricilerin ihtiyaçları için çeşitli programlama ortamlarının yanı sıra kod düzeyinde kalite güvence araçları sağlanır (örneğin, yürütme profil oluşturucuları ve ayrıca birim testi ve otomatik kod denetimi için araçlar).

Kalite mühendislerinin ihtiyaçları için, testler oluşturmak ve yönetmek, regresyon ve fonksiyonel testler için araçlar ve ayrıca otomatikleştirilmiş performans testi için araçlar sağlanmaktadır.

Kolektif bir altyapı, tüm grubun ortak sorunlarını çözmeye hizmet eder. İşbirliği, süreç yönetimi, değişiklik yönetimi ve sürüm kontrolü için araçlar sağlar.

Yazılım geliştirme sürecinin yöneticilerinin ihtiyaçları için, bir dizi kurumsal teknolojik standardı modelleme ve uygulama araçları sağlanır.

Son kullanıcıların ve kuruluş içindeki diğer paydaşların ihtiyaçları için, gereksinim yönetimini otomatikleştirecek araçlar sağlanır. Ayrıca, gereksinimler hakkında bilgi paylaşma, kusurları bildirme ve ortaya çıkan sorunların durumunu takip etme fırsatları da verilir.

ALM teknolojisi, uygulama geliştirme araçları endüstrisi ve müşterileri için ileriye doğru atılmış büyük bir adım olarak kabul edilmektedir. İlginç bir şekilde, Standish Group'un en son "Kaos raporu", başarısız yazılım projelerinin oranının son on yılda yarıya düştüğünü gösteriyor. Bu gelişme kısmen ALM'ye atfedilebilir. Bununla birlikte, müşteri ihtiyaçlarına daha yakından bakıldığında, ALM'nin bariz faydalarına rağmen, bu teknolojinin tam potansiyelini gerçekleştirmenin hala zor olduğunu göstermektedir. Bunu yapmak için, yazılım yaşam döngüsünde yer alan süreçleri ve araçları entegre etmek için kullanılan temel yaklaşımı değiştirmeniz gerekir.

ALM'nin iş potansiyeli potansiyeli büyük ölçüde kullanılmamış

Mevcut çözümlerin neden iş için ALM'nin tamamen kilidini açmayı zorlaştırdığını daha iyi anlamak için, tipik yazılım geliştirme ve operasyon ortamlarına daha yakından bakalım. Yazılımın nasıl üretildiğini ve uygulandığını süreçler, geliştirme araçları ve üretim platformları açısından inceleyeceğiz. Sonuç olarak, bu tartışma, yazılım üretiminin neden otomatikleştirilmeyi bırakın - istikrarlı ve öngörülebilir bir şekilde gerçekleştirilmeyen son iş süreçlerinden biri olarak kaldığını açıklıyor.

Kurumsal BT ortamı: heterojenlik sorunu

İnternetin ortaya çıkışı ve ticaret için ana platform olarak genişlemesi, geleneksel BT organizasyonlarında önemli değişiklikler getirdi. Bu aynı zamanda kaynak eksikliği ve yüksek esneklik gereksinimleri karşısında zorunlu sürekli çalışmayla da kolaylaştırıldı. Bu değişimlerin sorunu mimari evrimle ilgilidir. Eski teknolojilerden yeni, modern uygulama platformlarına geçerek BT ​​yanıt hızını ve hizmet düzeylerini ve verimliliğini artırmak için tasarlanmıştır. İşte bu evrimin kilit alanları.

Ana bilgisayarlarda çalışan monolitik özel uygulamalardan J2EE ve .NET gibi kurumsal dağıtılmış platformlar için yeni geliştirme araçlarına geçiş.

SAP NetWeaver ve Oracle Fusion gibi eski mimariler üzerine kurulu paket kurumsal uygulamalardan işleme ve birleşik uygulama çalışma zamanlarına geçiş.

Özel platformların özel ihtiyaçları için kullanın. Bunlar, örneğin, veritabanlarını (PHP, Ruby, vb.) kullanan web uygulamaları için betik dilleri veya zengin web ve multimedya özelliklerine sahip uygulama geliştirme platformlarıdır (örn. Adobe® Flash®/Flex™).

Bu teknolojilerin her biri, belirli uygulama geliştirme araçlarıyla (genellikle farklı satıcılar tarafından sunulur) ilişkilidir. Bu araçlar analiz, tasarım, kodlama, kalite kontrol, sürüm kontrolü ve konfigürasyon yönetimini kapsar.

Özellikle orta ve büyük şirketler için, öngörülebilir bir gelecekte her kurumsal BT ortamının şu dağıtım platformlarından en az üçünü içereceğini varsaymak mantıklı olacaktır: ana bilgisayar, dağıtılmış ortam (J2EE veya .NET) ve bir sistem. iş otomasyonu - süreçler (SAP veya Oracle). Ayrıca bazı kuruluşların hem J2EE platformuna hem de .NET'e yazılım dağıttığı görülüyor (ve giderek daha net hale geliyor). 2

Çakışan Programlar

Bazı BT çözümü satıcılarının, bariz nedenlerle, kurumsal BT ortamının heterojen yapısını mümkün olduğunca etkilemeye çalıştıklarını belirtmek ilginçtir. Bu satıcılar, eksiksiz "ömür boyu" çözümleri pazara sunarak BT ortamının organizasyonunu tamamen "devralmak" istiyor. Yazılım geliştirme araçları, uygulamaları çalıştırmak için bir ortam ve ağları ve sistemleri yönetmek için araçlar içerirler. En büyük üreticiler ayrıca çözümlerinde bir işletim sistemi ve hatta donanım içerir. Bu tür çözümlerin profesyonel hizmetlerin önemli bir bileşenini içerdiğini söylemeye gerek yok.

Kapsamlı tek satıcılı çözümlere yönelik bu büyük baskıya rağmen, gerçek şu ki birçok müşteri için bu yaklaşım işe yaramayacaktır. Bu tür organizasyonlar her düzeyde heterojenliği arttırır. Bu nedenle, belirli hedefleri müşteri (tedarikçi için değil) için önemli kılan bir dizi farklı önceliğe sahiptirler.

Rekabet gücünü maksimize etmek. En iyi ürünü veya hizmeti sunmaya çalışan kuruluşlar, genellikle tasarım açısından en iyi platformları ve geliştirme araçlarını seçerler. Bu yaklaşım, her platformun belirli son kullanıcılar için sunduğu avantajları elde etmelerine yardımcı olur. Bu genellikle ayrı projelerde olur, ancak aynı proje içinde de olabilir. Bu, sonunda birden çok teknoloji alanını kapsayan "hibrit" uygulamalara yol açar. İşte bazı ilgili örnekler.

o Anabilgisayar, paket uygulamalar ve şirket içinde geliştirilen dağıtılmış uygulamaları içeren bileşik uygulamalar veya hizmetler.

o İstemci tarafında .NET özelliklerini ve kullanıcı arabirimini kullanan J2EE/.NET hibritleri. Sunucu tarafında, J2EE teknolojisinin ölçeklenebilirliğinden, yönetilebilirliğinden ve güvenliğinden yararlanırlar. Bu mimari model, özellikle finansal dikeyde yaygındır. Yüksek performanslı ticaret platformları için kullanılır, çünkü Wall Street'te Windows masaüstü bilgisayarlar için fiili standarttır.

o Flash/J2EE melezleri. Video akışı ve zengin İnternet uygulamaları için bir platform olarak Adobe Flash'ın gücünü sunucular için J2EE teknolojisinin avantajlarıyla birleştirirler. Bu, yüksek derecede ölçeklenebilirlik ve zengin medya arabirimi sağlar.

Geliştirme maliyetlerini azaltmak. Kuruluşlar, hem açık kaynak kodlu hem de özel araç ve programları birleştirerek yazılım geliştirme ve dağıtım maliyetlerini düşürmeye çalışıyor. Bu bağlamda, LAMP paketinin (Linux, Apache, MySQL, PHP) artan popülaritesinden ve organizasyonlarda artan kullanımından bahsetmeye değer.

Ürünler için pazara sunma süresinin kısaltılması. Kuruluşlar, sundukları belirli iş avantajları nedeniyle belirli geliştirme araçlarını tercih edebilirler. Bu, ürünlerin piyasaya sürülme süresini önemli ölçüde azaltma potansiyeline sahiptir.

Halihazırda yapılan yatırımların etkin kullanımı. Herhangi bir "yok et ve değiştir" yaklaşımı önemli engellerle karşılaşır. Bunun nedeni, çoğu kuruluşun eski programlara ve araçlara yapılan önemli yatırımlardan vazgeçmek istememesidir.

Risk azaltma. BT endüstrisindeki bazı satıcılar, platformları için standart olmayan tescilli destek sağlar. Müşterilerinin gözünde bu bir risk olarak görülüyor. Belirli bir BT satıcısının platformuna kilitlenmek, özellikle bu satıcı gelecekte bir rakipse (veya olacaksa) önemli iş risklerine neden olabilir.

2 CMM/CMMI süreç iyileştirme ortamının hızla benimsenmesi ve dış kaynaklı geliştirme modellerinin artan kullanımı gibi başlıca endüstri eğilimleri, yazılım geliştirme endüstrisindeki bu belirgin dönüşümle yakından ilişkilidir. Steve McClure tarafından hazırlanan J2EE ve .NET Kullanımına ilişkin IDC Insight Raporu aşağıdakileri belirtir. Mevcut .NET kullanıcılarının %10,4'ü önümüzdeki 12 ay içinde J2EE/J2ME'yi de kullanmayı bekliyor; J2EE/J2ME kullanıcılarının %11,9'u önümüzdeki 12 ay içinde .NET geliştirme sürecine dahil olmayı bekliyor.

BT Heterojenliği: ALM'nin En Büyük Zorluğu

Kısacası, BT endüstrisindeki birçok kuruluş, heterojenliği tek alternatif olarak görüyor, çünkü onunla ilişkili birçok ticari fayda var. Geliştirme ekipleri sıklıkla birlikte çalışmak üzere tasarlanmamış farklı araçlar kullanır. Tek bir yazılım projesi bağlamında gerekli tüm eylemler için araçları sağlayan tek bir üretici yoktur. Ayrıca, üç ana alanı tam olarak kapsayabilecek tek bir satıcı yoktur: eski sistemlerin desteklenmesi ve modernizasyonu, paketlenmiş uygulamaların genişletilmesi ve özelleştirilmesi ve yeni dağıtılmış uygulamaların geliştirilmesi. Bu nedenle, kuruluşların aynı proje içinde ve farklı teknoloji alanlarında farklı geliştirme araçlarını kullanmaya devam etmesi çok muhtemeldir. Bu nedenle, ALM'nin uygulanmasındaki en büyük sorun, geliştirme araçlarının heterojenliğidir. ALM'nin otomatik ölçülebilirlik, tutarlılık ve disiplin yoluyla yazılım üretim sürecinde öngörülebilirlik ve bütünlük sağlamaya çalıştığını hatırlayın. Ancak, yüksek derecede heterojenliğe sahip bir ortamda, yazılım üretim sürecinin bu niteliklerini elde etmek çok daha zordur.

Ölçülebilirlik, çeşitli uygulama geliştirme araçlarından ve havuzlarından metrikler hakkında bilgi toplanmasını gerektirdiğinden, bu tür veri toplama için genel kabul görmüş bir standart yoktur. Sürece dahil olan tüm araçlar için ortak bir bilgi şeması olmadığından, toplanan ölçümleri "normalleştirmek" ve bir şekilde belirli projeler bağlamında bunları karşılaştırmak da gerekli hale gelir.

Hizalama, BT stratejilerinden dağıtılan modüllere kadar süreç boyunca izleme faaliyetleri ve çıktıları gerektirir. Kaynaklar ve süreç faaliyetleri farklı araçlara ve havuzlara dağıldığında, bu düzeyde operasyonel kontrol elde etmek çok zordur. Kontrol bilgilerinin otomatik olarak tanımlanmasını, toplanmasını, yönetilmesini ve kullanılmasını sağlayan standart araçlar yoktur.

Disiplin, yazılım üretimini yönetmek için çeşitli ortak süreçlerin dağıtımını, benimsenmesini ve kontrolünü gerektirir. Bu, alt süreçler çeşitli süreç araçları arasında "süreç adaları" olarak aktığında çok daha karmaşık hale gelir. Bu tür alt süreçlerin koreografisini yapmak için (üst düzey sürece göre) veya bu araçlar için süreç bileşenlerini dağıtmak için standart bir mekanizma yoktur. Birbirinden farklı araçlar ortamındaki süreçleri tanımlamak için tek bir terminoloji de yoktur. Hepsi "elemanlar", "eserler", "projeler" vb. için kendi dillerini kullanırlar. Disiplinin bir başka yönü, yönetim ve etki analizinde önemli değişiklikler gerektirir. Ancak bu yetenekler, uçtan uca operasyonel kontrolün doğru şekilde uygulanmasını gerektirir. Daha önce de belirtildiği gibi, heterojen bir geliştirme ortamında uçtan uca kontrolün başarılması çok daha zordur.

Bu sorunları ele almak için, ALM uygulayan kuruluşlar, genellikle kullanılan çeşitli geliştirme araçları arasındaki teknoloji boşluklarını tipik olarak dolduran birçok özelleştirilmiş noktadan noktaya entegrasyon geliştirmeyi bırakır. Bu tür entegrasyonlar güvenilir değildir. Araçlar güncellendiğinde veya değiştirildiğinde bozulurlar ve oluşturulması ve bakımı pahalıdır. Ayrıca kolayca ölçülemeyen ve kontrol edilemeyen, yönetilmesi zor yazılım süreçlerinin ortaya çıkmasına neden olurlar. Böyle bir yaklaşımın kabul edilemez ve yararsız olduğu açıktır.

Bu nedenle, ALM çözüm sağlayıcıları için çoğu BT kuruluşu büyük bir zorluk teşkil etmektedir. Bu kuruluşlar ALM'den daha fazla değer elde etmek, yani yazılım üretim sürecinde kendilerine ihtiyaç duydukları istikrar ve öngörülebilirliği sağlayacak önemli bir gelişme elde etmek istiyor. Ancak bunun ötesinde, ALM müşterileri de daha fazlasını istiyor.

İş hedefleri açısından bir çalışma platformları karışımını en optimal şekilde kullanma yeteneği.

Dağıtım ihtiyaçları için optimize edilmiş çeşitli ticari ve açık kaynaklı uygulama geliştirme araçlarının ücretsiz kullanımı.

Kuruluş tarafından benimsenen kültür, proje türleri ve temel teknoloji için optimize edilmiş çeşitli ticari veya özel yazılım geliştirme süreçlerinin ücretsiz kullanımı.

Bu karmaşık gereksinimleri karşılamak için ALM'ye yeni bir yaklaşım gerekiyor. Müşterilerin heterojen bir BT ortamında ALM'den tam olarak yararlanmasını sağlayacak bir yaklaşım. Borland kısa süre önce Open ALM adlı yaklaşımını ve ürün stratejisini duyurdu. Bu yaklaşım doğrudan bu sorunu çözmek için tasarlanmıştır. BT kuruluşlarının kendi zaman dilimlerinde tahmin edilebilir bir şekilde yazılım oluşturmasını sağlamak için sıfırdan tasarlanmış tek ALM çözümüdür.

Heterojenliğin Üstesinden Gelmek: ALM'nin Son Sınırı

Açık ALM yaklaşımı, Borland'ın yerleşik vizyonunu ve ürün stratejisini uygular. Bu yaklaşım, ticari ALM pazarında benzersiz olan önemli bir mimari değişimi temsil etmektedir. Aslında, tam olarak uygulanırsa, Borland Open ALM platformu ve ilgili uygulamaları, Borland'ın uygulama geliştirme araçlarından hiçbirini kullanmayan müşterilere bile önemli faydalar sağlayabilir. Kuşkusuz, Borland alet işini hayati olarak görüyor. Şirket, bunları geliştirmeye ve geniş bir yazılım geliştirici ekibi için sınıfının en iyisi araçları sunmaya devam edecek. Borland'ın araçları, Açık ALM stratejisini desteklemek için kademeli olarak değişecektir. Bu, Open ALM'ye dayalı yazılım üretiminin düzenlenmesine katılmalarına izin verecektir.Ancak, müşteriler bu noktayı görürse, Borland araçları, geliştirme gereksinimlerini destekleyen herhangi bir ürünle değiştirilebilir. Üçüncü taraf veya açık kaynaklı bir ürün olabilir. Bu modülerlik ve esneklik düzeyi, Borland'ın ürün stratejisini, çoğu yazılım tedarik zincirinin tamamına "sahip olmaya" çalışan diğer ALM satıcılarından ayırır.

OpenALM'nin Faydaları

Açık ALM, süreç, araç ve platform seviyelerinde rakipsiz bir esneklik derecesi sağlarken ALM'nin işlevsel değerini sağlar. Özellikle, Open ALM kullanıcıları aşağıdaki özelliklere sahiptir.

Tek bir yazılım projesi bağlamında veya aynı anda birkaç farklı proje için herhangi bir platform ve çalışma alanı kombinasyonunu seçme özgürlüğü. Bu durumda, iş öncelikleri veya projeye uygunluk temelinde seçim yapılır.

Ekonomi, üretkenlik ve teknik uygunluğa dayalı olarak seçtiğiniz platformlar için en iyi geliştirme araçlarını seçme özgürlüğü.

Projelerine ve seçilen platformlara en uygun geliştirme süreçlerini seçme veya tasarlama özgürlüğü ve ayrıca

organizasyon kültürü ve pazara sunma süresi gereksinimleri.

Open ALM platformu ve destekleyici araçları, ilk kez, heterojen uygulama geliştirme ortamlarını dağıtan BT kuruluşlarına aşağıdaki yetenekler sağlayacaktır.

Proje yönetimi ve süreç iyileştirme girişimlerini desteklemek için proje ve portföy ilerlemesi, kalite ve risk ölçütlerinin mükemmel bir çok boyutlu ve özelleştirilebilir görünümü.

Kutsal Kase: Tam operasyonel kontrol ve yaşam döngüsü takibi. Bu, geliştirme süreci boyunca iş hedeflerinin ve faaliyetlerinin gerçek bir şekilde hizalanmasını sağlayacak, son kullanıcı beklentileri ile proje sonuçları arasında daha iyi bir bağlantı sağlayacak ve doğru ve kapsamlı etki analizi yoluyla daha iyi proje yönetimi yetenekleri sağlayacaktır.

Süreçlere dayalı olarak, yaşam döngüsüne dahil olan uzmanların ve araçların eylemlerinin otomatik koordinasyonunun yardımıyla yeni bir yazılım geliştirme süreç yönetimi seviyesi.

Bu yetenekler, mükemmel ekip performansı sağlar, kalite iyileştirme girişimlerini destekler ve iç ve dış düzenlemeleri karşılamanın yükünü hafifletir. Bunlar, bir dizi altyapı düzeyinde bileşen ve ALM kurumsal kontrolleri olarak sağlanacaktır. Ayrıca müşteriler, Borland'ın sınıfının en iyisi entegre uygulama geliştirme ve proje yönetimi araçlarını da kullanabilir. Bu, dört ana süreç alanında değer kazanmalarını sağlayacaktır.

Proje portföy yönetimi (Proje Portföy Yönetimi, PPM). Tüm yazılım geliştirme stratejisinin gelişiminin yanı sıra bir yazılım geliştirme projeleri portföyünün yürütülmesini yönetmek için araçlar ve otomatik süreçler.

Gereksinimlerin tanımı ve yönetimi (Gereksinimlerin Tanımlanması ve Yönetimi, RDM). Proje gereksinimlerinin doğru ve eksiksiz olmasını, iş hedeflerine göre verimli bir şekilde izlenebilmesini ve yazılım testleriyle en iyi şekilde kapsanmasını sağlayan bir dizi araç ve en iyi uygulama.

Yaşam döngüsünde kalite yönetimi (Yaşam Döngüsü Kalite Yönetimi, LQM). Yazılım geliştirmenin tüm aşamalarında kalitenin tanımını ve ölçümünü yönetmek için prosedür ve araçlar. Bu araçlar, kalite sorunlarını bir projede düzeltme maliyetinin nispeten düşük olduğu erken dönemde tespit etmek ve önlemek için tasarlanmıştır. Ayrıca, KG ekiplerinin testlerinin eksiksiz olduğundan ve son kullanıcı gereksinimlerine dayalı olduğundan emin olmaları gerekir.

Değişim Yönetimi (CM). Değişimin etkisini tahmin etmeye yardımcı olan altyapı ve araçlar. Ayrıca hem çok düğümlü hem de tek düğümlü modellerde kaynakları ve yaşam döngüsü değişikliği etkinliklerini yönetmeye yardımcı olurlar.

Borland Açık ALM Çözümü

Daha önce de belirtildiği gibi, ALM'nin temel amacı, otomatik ölçülebilirlik, hizalama ve disiplin yoluyla öngörülebilir ve yönetilebilir bir yazılım geliştirme süreci elde etmektir. ALM'nin üç boyutunun her birinin heterojen bir uygulama geliştirme ortamında çok daha zor hale geldiğini ve bu nedenle ALM kullanıcıları için bir takım özel zorluklar sunduğunu gördük. Borland Open ALM platform mimarisi, her biri temel ALM etki alanlarından birindeki bir sorunu çözmek için özel olarak tasarlanmış üç çözüm alanı kümesidir. Open ALM çözümünün her alanı, son derece modüler ve genişletilebilir bir altyapı katmanına dayanmaktadır ve özel uygulamalardan oluşan bir koleksiyondur. Altyapı katmanının amacı, Open ALM platformunun, üreticiden veya beklenen işletim ortamı teknolojisinden bağımsız olarak, ticari veya açık kaynak geliştirme araçları ve süreçlerinin herhangi bir kombinasyonuyla çalışmasını sağlamaktır. Bir sonraki sayfadaki diyagram, bir Borland ALM çözümünün kavramsal bir diyagramını göstermektedir.

Borland Open ALM Çözüm Mimarisi

ALM için Açık İş Zekası

ALM için Açık İş Zekası (OBI4ALM), heterojen bir uygulama geliştirme ortamındaki yazılım projeleri için ilerleme ölçülebilirliğini, performans iyileştirmesini veya diğer herhangi bir özel metriği artırmak için standart altyapı ve uygulamaları temel alır. OBI4ALM, gizlice dağıtılmış veri toplamanın yanı sıra bunun için kayıtlı herhangi bir uygulama geliştirme aracından gelen metriklerin korelasyonu ve analizi için bir çerçeve sağlar. OBI4ALM çerçevesi, veri kaynaklarından önceden tanımlanmış metrikleri çıkararak, yazılım geliştirme döngüsü boyunca dağılmış farklı bilgileri bir araya getirir. Bu konsolidasyon büyük fırsatlar sunuyor. Örneğin, proje metriklerinin toplu bir görünümünü oluşturabilir ve birden çok alt düzey metriği birleştiren yeni proje metrikleri tanımlayabilirsiniz. OBI4ALM altyapısı bir veri deposu kullanır. Bu havuz, yazılım geliştirme sürecinin çeşitli aşamalarında yer alan araçlardan toplanan güncel ve geçmiş bilgileri içerir. Sorgulama ve veri analizi için optimize edilmiş bir yapı kullanır. OBI4ALM uygulamaları, toplanan metrikleri ona dayalı kararlar almaya uygun bilgilere dönüştürebilir. Bu, karar verme ve sorunların erken bildirimi için destek sağlar.

Gerçek Zamanlı Veri Panoları - Zaman içindeki eğilimleri gösteren KPI'ların özelleştirilebilir görünümleri.

Metrik tabanlı uyarılar, belirli koşullar oluştuğunda (örneğin, bir trend belirli bir sınırı aştığında) tetiklenen özelleştirilebilir uyarılardır. Uyarılar, çeşitli proje sorunları için yönetim esnekliğini artırmaya yardımcı olur: yavaş ilerleme, düşük kalite, düşük performans veya metrikler kullanılarak ölçülebilen diğer sorunlar.

Karar araçları, proje yönetimi kararlarının alınmasına yardımcı olmak için bir proje (veya birden fazla proje) hakkında geçmiş bilgileri kullanan analitik araçlardır.

ALM için Açık Süreç Yönetimi

Son tahlilde süreç, tüm yazılım yaşam döngüsüne nüfuz eden en önemli kavram haline gelir. Bir süreç, farklı roller tarafından kullanılan araçlar arasında bilgi yapılarını paylaşmaktan veya kullanıcı arabirimi düzeyinde yeteneklerin entegrasyonunu sağlamaktan daha fazlasıdır. Süreç, yazılım geliştirme sürecine dahil olan insanların ve sistemlerin faaliyetlerini koordine etmek için gerçek bir potansiyele sahiptir. Aynı zamanda süreç, yerleşik politikalara uyumu ve uygulamanın kalite kontrolünü sağlar.

ALM için Açık Süreç Yönetimi (OPM4ALM), heterojen bir uygulama geliştirme ortamında çeşitli yazılım süreçlerini modellemek, dağıtmak ve uygulamak için kullanılan altyapı bileşenleri ve bir dizi uygulama sağlar. OPM4ALM, süreç katılımcıları arasında rehberlik sağlamaktan ve görevleri dağıtmaktan çok daha ileri gider. Bu yöntem aynı zamanda, süreç modellerinde sabitlenmiş kurallara göre istemci tarafı, sunucu tarafı ve metodolojiyi entegre etmek için ana "yapıştırıcı" görevi gören süreç otomasyon katmanını da kullanır. Bu açıdan bakıldığında, uygulama geliştirme araçları arasındaki entegrasyon aslında alt düzey süreçler tarafından sağlanmaktadır. Bu, ekibin etkili çalışmasının temel temeli haline gelir.

OPM4ALM altyapısı, dağıtılmış bir süreç motoruna dayanmaktadır. Heterojen bir geliştirme araçları ortamında çoklu yazılım geliştirme süreçlerinin modellenmesini, özelleştirilmesini, devreye alınmasını, düzenlenmesini ve koreografisini sağlar. OPM4ALM çerçevesinin önemli bir parçası, süreç olaylarının yönetimi ve tanımlanmasıdır. Open ALM Workbench, bu olaylara abone olabilir ve bunları "dinleyebilir" ve meydana geldiklerinde bilgilendirilebilir. Process Engine ayrıca esnek kural tanımlama ve değerlendirme sağlar. Uygulama geliştirme ilkelerini tanımlamaya ve uygulamaya yardımcı olur.

OPM4ALM uygulamaları, süreç altyapısı katmanından değer sağlar. Aşağıdaki özellikleri sağlarlar.

Modelleme, özelleştirme, uydurma ve yeniden kullanma süreçleri için araçlar. Zengin bir yazılım geliştirme modeli kullanarak ticari veya özel yazılım süreçlerinin verimli bir şekilde tasarlanmasını sağlarlar.

Birleştirilmiş bir kuş bakışı gösteren bir kurumsal yazılım süreç konsolu. Bu görünüm, farklı geliştirme araçlarını içeren çeşitli projelerde devreye alınan tüm yazılım süreçlerini içerir.

Süreç Uyumluluğu Araç Çubuğu. Süreç sapmalarını ve bunların olası sonuçlarını gösterir ve uyumluluk girişimlerinin uygulanması için faydalı olan raporlama yetenekleri sağlar.

Her süreç için belirli metriklere dayalı ölçüm ve raporlama.

ALM için açık denetim

Uçtan uca süreç kontrolü, ALM'nin birçok önemli avantajını destekler. İşte bunlardan bazıları: gereksinimlere dayalı geliştirme, gereksinimlere dayalı geliştirme ve testlerin uygulanması ve değişikliklerin etkisinin doğru bir şekilde analiz edilmesi için önemli bir araçtır. ALM için Açık İzlenebilirlik (OT4ALM), yazılım geliştirme sırasında oluşturulan kaynaklar arasındaki ilişkileri oluşturmak ve sınıflandırmak için bir çerçeve sağlar. Ayrıca ilgili kaynaklar için esnek bir bağlantı planı oluşturur. Bu kaynakların hangi araçlarda bulunduğu önemli değildir. Ayrıca bu teknoloji, kaynaklar arasındaki bağlantıların diyagramında gezinmenin yanı sıra optimal sorgular oluşturmak ve bu diyagramın içerdiği verileri çıkarmak için araçlar sağlar.

OT4ALM, toplanan kontrol verilerini karar vermek için bilgiye dönüştüren uygulamalar sağlar.

Otomatik planlama, etki analizi, doğru maliyet ve bütçe tahminleri.

Sınır Kontrolü - Verilen sınırlardan (örneğin, gereksinimleri karşılamayan kaynaklar) ve gerçekleştirilmemiş gereksinimlerden sapma konusunda erken uyarı.

Yeniden Kullanım Çözümleyicisi - yalnızca kod modüllerini yeniden kullanmak yerine tüm kaynak ağaçlarını (gereksinimler ve modellerden kod ve testlere kadar) yeniden kullanmanıza olanak tanır.

TraceView - Çeşitli projeler için etkileşimli iz görüntüleyiciler. Bu, tüm süreç kaynaklarını bulmaya ve bunları diğer kaynaklarla karşılaştırmaya yardımcı olur.

Ortak Platform Altyapısı

Open ALM çerçevesi, çözümün tüm alanlarında kullanılan iki bileşen içerir.

ALM meta modeli. Yazılım süreçlerini, süreç kaynakları (kontrol olasılığı) ve ölçüm birimleri (metrikler) arasındaki bağlantıları tanımlamak için ortak bir dil. ALM üst modeli, yazılım geliştirme alanı için zengin bir kavramsal model sağlar. Bu, tüm Open ALM uyumlu araçların anlaması gereken standart bir kelime dağarcığı tanımlamak için gereklidir. Bu anlayış, Open ALM platformu içinde etkin iletişimi sağlayacaktır.

ALM entegrasyon seviyesi. Genişletilebilir ve gömülebilir entegrasyon motoru ve SDK. ALM araçlarının çalışması, ALM ölçümlerini toplaması ve kaynak izleme için grafikler oluşturması için standart bir yol tanımlar. ALM platformunu desteklemek ve katılmak için bir araç, standart Open ALM API'sini karşılayan bir platform eklentisi sağlamalıdır. Ayrıca, Open ALM platformu tarafından düzenlenen işlemler aracılığıyla aracı diğer uygulama geliştirme ortamlarına bağlayan özel bir adaptör de kullanabilirsiniz.

ALM'yi Açmaya Giden Yol

Önümüzdeki 24 ay içinde Borland, Open ALM platformunu oluşturan altyapıyı, uygulamaları ve araçları giderek daha fazla genişletecek. Borland ayrıca bu ürünü, kurumsal Açık ALM uygulamalarının dağıtımını ve başarısını hızlandırmak için tasarlanmış çok çeşitli profesyonel hizmet programları ile tamamlamayı amaçlamaktadır. Open ALM'nin bazı avantajları bugün müşterilere sunulmaktadır. Kaliteyi geliştirmek ve değişim ve proje yönetimi süreçlerini iyileştirmek isteyen kuruluşlar, Borland'ın mevcut çözümünü çok çekici bulacaktır. Bu çözüm, uygulama geliştirme sürecinin dört önemli alanı için yüksek düzeyde otomatikleştirilmiş ve entegre destek sağlar:

Proje Portföy Yönetimi (PPM);

Gereksinim tanımı ve yönetimi (RDM);

Uygulama Yaşam Döngüsü Yönetimi (LQM);

Değişim Yönetimi (CM).

Bu çözümler, Borland ürünleri ve üçüncü taraf araçları arasındaki sıkı entegrasyon yoluyla sağlanır. Bu, müşterilere ihtiyaç duydukları esnekliği verir ve günümüzde yazılım projelerini yönetme yeteneklerini büyük ölçüde artırır.

Neden Borland?

Borland, uzun tarihi boyunca, en uygun şekilde yazılım oluşturmalarını sağlamak için müşterileri ile sürekli olarak ortaklık kurmuştur. Borland, standartlara dayalı geliştirme ve platform desteğine kendini adamıştır. BT kuruluşlarına ihtiyaç duydukları esnekliği ve seçim özgürlüğünü sundu. Open ALM'nin gelişiyle birlikte Borland, geleneksel değerlerini tamamen yeni bir seviyeye taşıyor. Bu, şirketi diğer ALM çözümleri satıcılarından ve kar amacı gütmeyen ALM girişimlerinden açıkça ayırmaktadır.

ALM, IBM Rational ve Microsoft gibi en büyük çözüm üreticileri söz konusu olduğunda, müşteri hizmetleri pek de onların birinci önceliği değildir. Her iki şirket de müşterileri kendi ara yazılım çözümlerine ve sistem yönetimi platformlarına bağlamak için geliştirme araçlarından sürekli olarak yararlanmaya çalışıyor.

Bu yaklaşımın aksine, Borland her zaman Java ve J2EE standartlarını desteklemekte ısrar etti ve platform, diller ve geliştirme araçları için güçlü ve entegre destek sundu. Microsoft. Borland, ALM için Microsoft çözümünü açıkça genişletmeye devam ediyor. Borland, en son Microsoft teknolojilerini desteklemek için büyük yatırımlar yaptı. Örneğin, Team System için ilk tam entegre gereksinim yönetimi çözümü olan CaliberRM, VSTS aracı tarafından sağlanan temel gereksinim yönetimi işlevselliğini genişletmek için Microsoft tarafından önerilmektedir. Borland, Java ve .NET platformları arasındaki işbirliğini genişletmeye devam edecek. UML'den C#'a kod üretimi ve Microsoft Etki Alanına Özel Diller için destek (UML'nin yerine Microsoft'un alternatifi) gibi ek özellikler sağlama planları var.

Açık kaynağa geçiş, heterojenliğin ALM için ortaya koyduğu zorluklarla da ilgilidir. Birkaç Eclipse girişiminin (Application Lifecycle Framework (ALF), Corona ve Eclipse Process Framework (EPF)) hedefi, Borland Open ALM'ninkine benzer. Borland bu projelerin arkasındaki motivasyonu anlarken, şirket onların yaklaşımını yetersiz buluyor. Hem ALF hem de Corona, yalnızca Open ALM altyapı bileşenleri sağlamaya çalışıyor. Ancak, Open ALM daha bütünsel bir yaklaşımdır. Bu yaklaşım aynı zamanda müşterilerin bir dizi eklenti uygulaması aracılığıyla önceden oluşturulmuş altyapıların iş değerinden yararlanmasına olanak tanır. Borland, Open ALM'ye doğru hareketinde diğer ALM satıcılarından daha ileri gidiyor. Şirket son zamanlarda ufkunu genişletti ve ek uygulama geliştirme alanlarını da kapsamayı hedefliyor. Borland ayrıca SAP NetWeaver ve Oracle Fusion platformlarında paket uygulama geliştirme projelerini desteklemek için en iyi yaklaşımı arıyor.

Çözüm

Borland'ın konumu benzersizdir, çünkü şirket ALM kullanıcılarının kendi zaman dilimlerinde yazılım geliştirmelerine yardımcı olur. Açık ALM yaklaşımı ve ürün stratejisi, Borland'ı diğer ALM satıcılarından ve açık kaynak girişimlerinden açıkça ayırır. Borland, BT heterojenliği gerçeğini en başından beri tanıyan tek büyük ALM satıcısıdır. Bu şirket, ALM kullanıcılarının süreçlerde, çalışma alanlarında ve geliştirme araçlarında mevcut araçları etkin bir şekilde kullanmalarına yardımcı olmaya çalışıyor. Borland'ın süreç tabanlı entegrasyon yaklaşımı, şirketi rakiplerinden daha da ayırıyor. Bu, Borland'ın ALM stratejisi boyunca şeffaflık, kontrol ve düzen sağlamasına olanak tanır.

Borland, Open ALM için altyapı, uygulamalar ve ilgili geliştirme araçlarını oluşturmaya başlar. Bu nedenle, müşteriler ilk kez ALM'nin yeteneklerini tam olarak kullanma fırsatına sahip olacaklar. Tamamen sorunsuz, yönetilebilir ve ölçülebilir bir yazılım geliştirme sürecinden faydalanabileceklerdir.

Carolyn Pampino (IBM)
Uygulama tabanlı: Rational Team Konseri Beta 3, Rational Quality Manager Beta 3, Beta 3

Gözden geçirmek

Zorlu rekabet, birçok kuruluşu daha kısa sürede ürün yaratmaya zorlarken, onları daha da yenilikçi hale getiriyor. Yazılım geliştirme başlı başına karmaşık bir iştir, bu nedenle bilgi sistemleri ve cihazları geliştiren kuruluşlar tarafından oluşturulan sistemler de son derece karmaşıktır. Sıkı teslim tarihlerine sahip ekipler, bunu kaliteden ödün vermeden veya bütçeyi artırmadan yapmalıdır. Bunu yapmak için stratejileri, yazılım geliştirmenin verimliliğini artırmak olmalıdır. Bu ikilemin çözümü, uygulama yaşam döngüsü yönetimi (LCM) aracılığıyla yaşam döngüsü etkileşimlerini iyileştirmektir.

Yazılım geliştirme projelerini desteklemek için tasarlanan uygulama yaşam döngüsü yönetimi çözümleri, planlama, değişiklik yönetimi, gereksinim tanımı ve yönetimi, mimari yönetimi, yazılım yapılandırma yönetimi, oluşturma ve devreye alma ile ilgili etkinlikleri içeren yinelemeli bir yazılım geliştirme döngüsünde insanları, süreçleri ve araçları koordine eder. otomasyon, kalite yönetimi. LCA çözümlerinin ana özelliklerine ek olarak, yaşam döngüsü yapıtları arasında izleme, süreç tanımı ve güvencesi ve raporlamayı içerirler.

Bir PLC çözümünün en önemli faydası, proje paydaşları için yenilikçi ürünler yaratmak amacıyla bir projede yer alan insanları, süreçleri, bilgileri ve araçları koordine etme yeteneğidir. Herkese uyan tek bir çözüm olmadığı için, müşterilerimize kuruluşlarının kültürüne ve ortamına en uygun yaşam döngüsü yönetimini uygularken aşağıdaki ilkelere odaklanmalarını tavsiye ediyoruz:

• Gerçek zamanlı zamanlama kullanın;
• İlgili yapıtlar için yaşam döngüsü izlemesi sağlayın;
• Bağlamda etkileşim için fırsatlar sağlayın;
• Geliştirme için iş analitiği uygulayın;
• Geliştirme sürecinde sürekli iyileştirme uygulayın.

Gerçek zamanlı planlama

Planlıyoruz çünkü belirli bir hedefe ulaşmak istiyoruz ve ne zaman ulaşılacağını bilmek istiyoruz. İşin ne zaman yapıldığını bilmenin tek bir yolu var. Bunun için planların projenin yürütülmesi ile tam entegre olması ve her zaman güncel olması gerekmektedir. Aşağıdaki tablo, yapmanız veya yapmamanız gereken birkaç tipik planlama etkinliğini listeler.

Aşağıdaki resim, harcanan zamanı doğrudan bir iş öğesinden güncellemenin, planların doğru tutulmasını nasıl kolaylaştırdığını gösterir.

Pirinç. 1. İş öğesinden harcanan zamanı güncellemek, planların doğru kalmasını sağlar

Sonraki üç resim, aynı yineleme planının farklı görünümlerini göstermektedir. Görünümleri kullanmak, ekibin çalışmayı dengelemesine, etkili bir şekilde plan yapmasına ve değişime daha hızlı yanıt vermesine yardımcı olur.

Pirinç. 2. Planlanmış zaman görünümü, bazı ekip üyelerinin diğerlerinden daha fazla işi olduğunda gösterir

Pirinç. 3. Elektronik görev panosu görünümü, coğrafi olarak konumlanmış esnek ekipler tarafından kullanılabilir

Pirinç. 4. Geliştirme planı görünümü, görevlerin gün ve haftaya göre dağılımını daha geleneksel bir şekilde görüntüler

Aşağıdaki resim, Rational Team Concert'ta ilgili Ürün İş Listesi'ne bağlantılar, Rational Requirements Composer'daki gereksinim koleksiyonları ve Rational Quality Manager'da bir test planı ile bir Yayın Planını göstermektedir.

Pirinç. 5. Planlama ile ilgili gereksinimler ve test planları koleksiyonlarıdır.

IBM Rational işbirliğine dayalı yaşam döngüsü yönetimi çözümü, tam olarak bütünleştirilmiş, gerçek zamanlı planlama içerir.

Yaşam döngüsü izi

İzleme, yazılım geliştirme yaşam döngüsünde başka bir güzel "olması güzel" özellik değildir. İzleme, ekipteki diğer herkesin ne yaptığını anlamanıza yardımcı olur. Örneğin, bir gereksinim analisti hangi gereksinimleri yazdıklarını iyi bilir, ancak belirli bir gereksinimin belirli bir geliştirme yinelemesinde dikkate alınıp alınmayacağını ve eğer öyleyse hangisinde dikkate alınacağını da bilmesi gerekir. Veya bu şartın uygulanmasının test edilip edilmediğini ve sonucun ne olduğunu bilmek istiyor.

Yaşam döngüsü yapıtları arasında izlemeyi sağlayan bir PLC çözümü, ekiplerin projelerinin durumuyla ilgili zorlu soruları yanıtlamasına yardımcı olur. Yapıtlar arasında bağlantılar oluşturmak, ekiplerin "Kusurlardan hangi gereksinimler etkilenir?" gibi soruları yanıtlamasını kolaylaştırır. ve "Hangi iş öğeleri test için hazır?"

Pirinç. 6. LCA çözümü tarafından yanıtlanan önemli sorular

İzleme, her ekip üyesinin ekibin geri kalanının ne yaptığını ve bir bütün olarak işin kapsamını nasıl etkilediğini anlamasına yardımcı olur. Harici olarak kısıtlanmış bir ortamda çalışıyorsanız, izleme, denetçilerden gelen "Bu yapıya hangi değişiklikler dahildir, hangi testler yapıldı ve hangi sonuçla?" gibi soruları yanıtlamanıza yardımcı olur.

Aşağıdakiler, izlemeyle ilgili tipik yapılacaklar ve yapılmayacaklardır:

Aşağıdaki resim, gereksinimleri ve test senaryosu ilişkilerini içeren bir sürüm planının izleme görünümünü gösterir. Plan ayrıca, planın öğelerini etkileyen kusurları görüntülemek için bir sütuna sahiptir. Bu, izleme bilgisine sahip entegre bir plan örneğidir. Güncel olmayan, periyodik olarak oluşturulan izleme raporlarından farklı olarak, yerleşik bir izleme görünümüne sahip entegre bir plan kullanıldığında, yapıtların yokluğu belirgin hale gelir ve projede kolayca ortadan kaldırılır.

Pirinç. 7. Geliştirme, gereksinimler ve testleri kapsayan yayın planı

İzleme bağlantıları kurulduğunda, IBM Rational Collaborative Lifecycle Management, test sırasında belirlenen kusurlara dayalı olarak otomatik olarak izleme bağlantıları oluşturur. Aşağıdaki resim, onun için oluşturulan yönlendirme bağlantılarıyla kusuru göstermektedir. Test sırasında bir kusur eklediğinizde, kusurun test sonuçlarına, test senaryosuna, test planına, plan öğesine ve gereksinime yönelik izleme bağlantıları otomatik olarak oluşturulur.

Pirinç. 8. Bir kusur görüntüleme testi durumları, plan öğeleri ve bundan etkilenen gereksinimler için otomatik olarak oluşturulan yaşam döngüsü bağlantıları

Bağlamda etkileşim

Etkileşim, dostane ve çalışma ilişkilerini sürdürmekle sınırlı değildir. Etkileşim kaliteyi artırır ve paydaşlara değer katar, bu da etkileşimin inovasyon için önemli olduğu anlamına gelir. Bir LCA çözümünde işbirliği fırsatları, ekip üyelerinin birbirleriyle iletişim kurma, değişikliklere yanıt verme ve proje öngörülebilirliğine katkıda bulunma becerilerini geliştirebilir.

Ayrıca, işbirliği araçları ekiplerin önemli olan şeylere odaklanmasına yardımcı olur. Ekipler, manuel ve yaratıcı olmayan görevleri otomatikleştirmek için herhangi bir fırsat aramalı. İyi bir PLC çözümü, derlemeler ve test yürütme için otomasyon içerir, ancak durum raporlaması ve bilgi erişimi için otomasyon da içermelidir. Proje panoları ve kişisel panolar, ekibe ihtiyaç duydukları bilgileri otomatik olarak sağlamada, ekip görünürlüğü sağlamada ve ekip raporları ve sorguları aracılığıyla güncel verilere erişim sağlamada önemli bir rol oynar. İyi tasarlanmış bir kullanıcı arabirimi, farklı bir uygulamaya geçerek "bağlam değiştirmeye" zorlamadan bilgileri doğrudan kullanıcılara ileterek bilgiye erişimi otomatikleştirir. Bu formda, otomasyon doğrudan daha iyi etkileşime katkıda bulunur.

Aşağıdaki görüntü, Rational Team Concert, Rational Requirements Composer ve Rational Quality Manager'dan gelen bilgileri içeren pencere öğelerine sahip bir dizi gösterge panosunu göstermektedir. Panolardaki veriler, projenin mevcut durumunu gösterir.

Pirinç. 9. Çeşitli kaynaklardan gelen verileri içeren panolar, tüm işlevsel ekipler için iş şeffaflığı sağlar

Aşağıdaki resim, her zaman kullanıcı arayüzünün yanında bulunan ve sola veya sağa yerleştirilebilen bir mini gösterge panosunu göstermektedir. Kullanıcıyı LCA çözümü boyunca takip eden ve herhangi bir zamanda gizlenebilen veya gösterilebilen kişiselleştirilmiş bir mini gösterge panosu olarak işlev görür.

Pirinç. 10. Kullanıcı arayüzünde her yerden erişilebilen mini panel

Aşağıdaki resim Rational Team Konserindeki kişisel mini barı göstermektedir. Bu panelde Rational Requirements Composer'da gereksinimlerde yapılan değişiklikleri görüntüleyen bir pencere öğesi bulunur. Bu, çeşitli kaynaklardan bilgi içeren bir mini panel örneğidir. Bir gereksinimin üzerine geldiğinizde, Gereksinim Oluşturucu'da gereksinimin durumu hakkında bilgi içeren bir önizleme görünür. Bilgiye hızlı erişim ihtiyacı duyan kullanıcılar mini panellere kısa sürede alışacak.

Geliştirme için iş zekası

Başarı ölçütlerini tanımlamazsanız, bir şeyin daha iyiye gittiğini nasıl anlarsınız? Bir projenin herhangi bir noktasında ekibin başarılı bir sonuca doğru ilerleyip ilerlemediğini söyleyebilir misiniz? İyileştirilmesi gereken alanları belirlemek, hedefler belirlemek, bu hedeflere yönelik ilerlemeyi izlemek, gelişim için iş zekasının geliştirilmesine yardımcı olan şeydir.

Capers Jones 1'e göre, ölçüm uygulamalarını yaygın olarak kullanan projeler, kullanmayanlara göre çok daha başarılıdır.

Pirinç. 12. Ölçüm uygulamalarını kullanan projelerin başarılı olma olasılığı daha yüksektir

Örneğin, aşağıdaki üç ölçüm, Capers Jones araştırma kuruluşlarının %50'sinden daha azı tarafından kullanılmaktadır:

• Kalite Metrikleri %45
• Verimlilik Metrikleri %30
• Hazırlık Metrikleri %15

Aşağıdaki resim, proje panosundaki geliştirme ekibi için raporları göstermektedir. Bir iş öğesi güncellendiğinde, raporlar ekibin etkinliğini ve yönünü yansıtır. Ekibinizin planlanan çalışmanın tamamlanmasına yönelik ilerlemesini izlemek için ilerleme çizelgelerini kullanın. Veya alternatif olarak, "Açık", "Devam Ediyor" ve "Kapalı" durumlarındaki (ideal olarak, "Açık" ve "Devam Ediyor" durumlarındaki öğelerin sayısındaki) iş öğelerinin sayısındaki değişikliği gösteren çizelgeleri kullanın. " Kapalı" - büyürken azalmalıdır).

Pirinç. 13. İyileştirmeleri ölçmek için raporlar ve metrikler içeren gösterge tablosu

Gösterge tabloları ve raporlar, ekibin mevcut ilerlemesini ölçmekten ve bunlara yanıt vermekten sorumlu olan LCA çözümünün önemli bir bileşenidir.

Geliştirme sürecinin sürekli iyileştirilmesi

Bir süreç, belgelenmiş bir dizi faaliyetten daha fazlasıdır. Ekip iletişimini geliştirmenin ve ekibin başarı şansını artırmanın bir yolu olarak sektör deneyiminden alınan en iyi uygulamalara dayalı süreçler geliştiriyoruz. Davranış büyük ölçüde alışkanlık tarafından belirlenir. Bir süreci tanımladığınızda veya değiştirdiğinizde, etkili bir şekilde tüm ekipten alışkanlıklarını değiştirmelerini ve ilk bakışta anlamadıkları davranışları benimsemelerini istiyorsunuz. Bir kişinin alışkanlıklarını değiştirmek oldukça zordur. Bir süreci değiştirmek, genellikle insanların düşünme ve davranma şeklini değiştirmeyi gerektirir. İyi tasarlanmış bir LCM çözümü, süreci adım adım değiştirmenize, ekip dinamiklerini iyileştirmenize ve daha yüksek verimliliğe doğru ilerlemeye devam etmenize olanak tanır.

Geliştirme araçları pazarının son 10-15 yıldaki gelişimini analiz ederek, vurgunun fiilen program yazma teknolojilerinden (90'ların başından beri RAD araçları - "hızlı uygulama geliştirme") entegre bir gereksinime uygulamaların tüm yaşam döngüsünün yönetimi - ALM (Uygulama Yaşam Döngüsü Yönetimi) .

Yazılım projelerinin karmaşıklığı arttıkça, bunların uygulanmasının verimliliği için gereksinimler keskin bir şekilde artar. Bu, yazılım geliştiricilerin işletmelerin çalışmalarının neredeyse tüm yönlerine dahil olduğu ve bu tür uzmanların sayısının arttığı günümüzde daha da önemlidir. Aynı zamanda, bu alandaki araştırma verileri, "kurum içi" yazılım geliştirme projelerinin en az yarısının sonuçlarının, onlara duyulan umutları haklı çıkarmadığını göstermektedir. Bu koşullar altında, tüm katılımcılarını (tasarımcılar, geliştiriciler, testçiler, destek hizmetleri ve yöneticiler) kapsayan yazılım araçları oluşturma sürecinin tamamını optimize etme görevi özellikle acil hale geliyor. Uygulama Yaşam Döngüsü Yönetimi (ALM), yazılım yayın sürecini birbiriyle ilişkili aşamaların sürekli tekrarlanan bir döngüsü olarak görür:

gereksinimlerin tanımı (Gereksinimler);

tasarım ve analiz (Tasarım ve Analiz);

Geliştirme (Geliştirme);

test testleri);

dağıtım ve bakım (Dağıtım ve Operasyonlar).

Bu adımların her biri dikkatle izlenmeli ve kontrol edilmelidir. Düzgün organize edilmiş bir ALM sistemi şunları yapmanızı sağlar:

Ürünleri piyasaya sürmek için gereken süreyi azaltın (geliştiricilerin yalnızca programlarının formüle edilmiş gereksinimlere uygunluğuna dikkat etmesi gerekir);

uygulamanın kullanıcıların ihtiyaç ve beklentilerini karşılamasını sağlarken kaliteyi artırmak;

üretkenliği artırmak (geliştiriciler, geliştirme ve uygulamada en iyi uygulamaları paylaşma fırsatına sahip olur);

Araçların entegrasyonu yoluyla geliştirmeyi hızlandırın;

· uygulama ve tasarım belgeleri arasındaki tutarlılığı sürekli koruyarak bakım maliyetlerini azaltmak;

Becerilere, süreçlere ve teknolojiye yaptığınız yatırımdan en iyi şekilde yararlanın.

Açıkçası, ALM kavramı, elbette, temelde yeni bir şey değil - yazılım oluşturma sorunlarının böyle bir anlayışı, yaklaşık kırk yıl önce, endüstriyel geliştirme yöntemlerinin oluşumunun şafağında ortaya çıktı. Ancak, nispeten yakın zamana kadar, yazılım geliştirme görevlerini otomatikleştirmeye yönelik ana çabalar, en çok zaman alan aşama olarak doğrudan programlama için araçlar oluşturmaya yönelikti. Ve sadece 80'lerde, yazılım projelerinin karmaşıklığı nedeniyle durum önemli ölçüde değişmeye başladı. Aynı zamanda, geliştirme araçlarının işlevselliğini (terimin geniş anlamıyla) iki ana alanda genişletmenin önemi keskin bir şekilde arttı: 1) yazılım yaşam döngüsünün diğer tüm aşamalarının otomasyonu ve 2) araçların yazılımla entegrasyonu. herbiri.

Birçok şirket bu görevlerle uğraştı, ancak buradaki tartışmasız lider, kuruluşundan bu yana yirmi yıldan fazla bir süredir yazılım geliştirme süreçlerini otomatikleştirme konusunda uzmanlaşmış olan Rational'dı. Bir zamanlar, programları tasarlamak için görsel yöntemlerin yaygın kullanımında öncülerden biri olan (ve pratik olarak UML dilinin yazarı, bu alanda fiili bir standart olarak kabul edilen), ortak bir ALM metodolojisi yaratan ve karşılık gelen bir araç seti. Bu yüzyılın başında Rational'ın, cephaneliğinde ALM'yi destekleyen (iş tasarımından bakıma kadar) eksiksiz bir ürün yelpazesine sahip olan tek şirket olduğu söylenebilir. sıradan kodlama araçları. Ancak, Şubat 2003'te bağımsız bir kuruluş olarak varlığını sona erdirdi ve IBM Rational adlı IBM Corporation'ın bir bölümü haline geldi.

Yakın zamana kadar, yazılım geliştirmenin belirli aşamaları için diğer satıcılardan rakip araçlar olmasına ve olmasına rağmen, Rational, ALM sınıfının entegre geliştirme araçlarının neredeyse tek üreticisiydi. Bununla birlikte, birkaç yıl önce, aslında temel olan geleneksel uygulama geliştirme araçları (Delphi, JBuilder, vb.) alanında her zaman güçlü bir konuma sahip olan Borland Corporation, onunla rekabet etme niyetini kamuoyuna açıkladı. benzer ürünler üreten diğer şirketlerin satın alınması yoluyla genişletilen şirketin ALM kompleksi. Bu, gerçek rekabet için potansiyel fırsatlar yaratan iki şirketin iş modellerindeki temel farktır. Rational IBM'in bir parçası olduktan sonra, Borland kendisini bugün kapsamlı bir ALM platformunun tek bağımsız tedarikçisi olarak konumlandırıyor (yani kendi işletim sistemlerini, dillerini vb. tanıtmıyor). Buna karşılık, rakipler, Borland'ın sahip olduğu araçları birleştirmek için bir temel sağlayan net bir ALM metodolojisi formüle etmediğini belirtiyor.

Geliştirme araçları alanındaki bir diğer önemli oyuncu da Microsoft Corporation'dır. Kendi ALM platformunu oluşturmakla tehdit etmese de; bu yöndeki tanıtım, yalnızca aynı Rational ve Borland (her ikisi de Visual Studio Industry Partner programının ilk katılımcıları olan) diğer tedarikçilerle işbirliği çerçevesindedir. Aynı zamanda, Microsoft'un amiral gemisi Visual Studio .NET geliştirme aracı, Microsoft Visio ve Microsoft Project ile entegrasyon da dahil olmak üzere üst düzey modelleme ve proje yönetimi araçlarının kullanımı yoluyla işlevselliği sürekli olarak genişletiyor.

Bugün, teknoloji ve yazılım ürünleri geliştiren neredeyse tüm önde gelen şirketlerin (yukarıda listelenenler dışında, Oracle, Computer Associates vb. denilebilir), hem kendi başlarına hem de satın alma yoluyla oluşturulan gelişmiş yazılım geliştirme teknolojilerine sahip oldukları belirtilmelidir. küçük uzmanlaşmış şirketler tarafından yaratılan ürünler ve teknolojiler. Microsoft gibi, henüz kendi ALM platformlarını oluşturmayı planlamasalar da, bu şirketler tarafından yayınlanan CASE araçları, yazılım yaşam döngüsünün belirli aşamalarında yaygın olarak kullanılmaktadır.

ALM sistemleri, şeffaflık sağlamanıza, uygulama geliştirme sürecini net bir şekilde anlamanıza ve bunu iş süreçlerinden biri olarak sunmanıza olanak tanır. Ancak analistler, ALM'nin yalnızca uyumluluğu izleme ve kontrol etme aracı olarak görülmemesi gerektiği konusunda uyarıyor. Bu sistemler, geliştirme sürecini otomatikleştirmek ve çeşitli araçları entegre etmek için olduğu kadar kontrol için de tasarlanmamıştır.

ALM araçlarını uygulamadaki en büyük sorun, insanların geliştirme sürecini anlamamasıdır. Çoğu zaman yönetim, ALM'nin işleri iyi tanımlanmış bir şekilde halledebileceğini varsayar. Ancak, her şeyi önceden planlamak imkansızdır. Uygulama geliştirmede, genellikle her adımda birkaç yinelemeden geçmek, ara sürümleri yayınlamak ve uygulamanın işlevselliğini kademeli olarak artırmak gerekir. ALM sistemi, geliştiricilerin eylemlerini sınırlamamalı, süreci kolaylaştırmalıdır.

BT endüstrisi, BT ve iş arasındaki engeller hakkında konuşmayı sever, ancak BT organizasyonunun kendi içinde, dikkatsiz bir sistem entegratörünün önüne geçebilecek daha az görünür engeller vardır.

Örneğin, bugün BT'de en tartışmalı ve hararetle tartışılan konulardan biri olan DevOps metodolojisini ve onunla ilgili her şeyi düşünün. Geliştirilen uygulamanın gerçek operasyon için BT hizmetine aktarılmasıyla ilgili tüm eylemlerin kısa bir açıklaması olarak, bu sözler yeterince zararsız geliyor. Ancak genel olarak, kurumsal uygulama geliştiricileri ile kurumsal BT altyapısını yöneten uzmanlar arasında bir yanlış anlama duvarı vardır. Programcılar genellikle BT departmanını esneklik eksikliğinden ve günlük BT operasyonlarını yöneten kişiler, oluşturdukları uygulamaların üzerinde çalışması gereken üretim altyapısının kısıtlamalarını ve gereksinimlerini göz ardı etmekle suçlar.

Bu gerilim, programcılara ve BT personeline geliştirilmekte olan uygulama ve uygulamanın çalışması gereken altyapı hakkında daha net bir anlayış sağlamak için tasarlanmış bir dizi yönetim aracı olan Uygulama Yaşam Döngüsü Yönetimine (ALM) artan bir ilgiyi körüklüyor. Ana fikir, geliştiriciler ve BT uzmanları arasındaki işbirliğini kolaylaştırmanın, tüm kurumsal bilgi ortamının daha verimli çalışmasına yol açacağıdır. Sorun şu ki, projenin başarısı için gerekli olan işbirliğinin gerekli olduğu iki tarafın, ortaya çıkan zorlukların sorumluluğunu birbirlerine kaydırmaya başladığı bir durumda ALM'nin uygulanmasının şansı çok az.

ALM metodolojisini başarılı bir şekilde uygulamak için sistem entegratörünün BT departmanındaki suçlama seviyesinin üzerine çıkması gerekir. IBM Rational Software pazarlamadan sorumlu başkan yardımcısı Gina Pool'a göre bu, BT departmanının tüm hizmetlerinin koordineli çalışması nedeniyle müşterinin ne kadar para kaybettiğini anlayabilen bir BT direktörü veya CFO'su bulmak ve işe almak anlamına geliyor. Bir geliştirme projesinde geç bir uygulamadaki hataları düzeltmek, son derece yüksek maliyetler anlamına gelir. Böyle bir düzeltme ihtiyacı, geliştiricinin uygulamanın çalışacağı ortamla ilgili önceki varsayımlarından kaynaklanıyorsa ve bu varsayımlar sonunda yanlış çıkıyorsa, tüm projenin maliyeti birçok kez artar veya müşteri altyapısını buna göre yükseltmek zorunda kalacak.

Elbette, bir kuruluşun BT altyapısındaki bu tür çelişkileri çözmek maliyetli olabilir. Ancak, bu çalışmanın tek nihai amacı, programcıların ve BT operasyon uzmanlarının birbirlerinin çalışmalarına müdahale etmeyi bırakmalarına izin verecek bir dizi yönetim teknolojisi oluşturmak ve uygulamak olmalıdır. Programcılar BT ile işbirliğini tartışmak için ne kadar çok zaman harcarlarsa, gerçekten geliştirmek için o kadar az zamanları olur. Ne kadar çok uygulama oluşturulacaksa, o kadar gelişmiş altyapıya ihtiyaç duyulacak ve bu elbette bayiler için iyi bir haber.

Genel olarak, DevOps tartışması bayiler ve entegratörler için kesinlikle faydalıdır. Sorun, çok fazla BT projesini paralel olarak yürütmeyi istemekten kaynaklanan iç çatışmalara kapılmamaktır. Müşteri ALM kavramını kabul etmiyorsa, bu aslında BT yönetiminde olgunluk eksikliğinin ve zayıf yetkinliğinin çok iyi bir göstergesidir. Bu, kendi başına, satıcının böyle bir müşteriden uzak durmasının daha iyi olduğunu gösterir, çünkü böyle bir müşterinin kardan daha fazla sorun getirmesi çok muhtemeldir.