Kontrol yaşam döngüsü uygulamalar (Uygulama Yaşam Döngüsü Yönetimi, ALM) hızla gelişiyor. Bu, yaratma sürecini iyileştirmeye yönelik umut verici bir yaklaşımdır. yazılım(İLE). Ancak "geleneksel" ALM süreci, kuruluş için değer yaratma konusunda tam potansiyeline ulaşamamaktadır. Neden? Çünkü satıcılar, müşterileri kapalı teknoloji platformlarına kilitlemeyi amaçlayan sınırlı uçtan uca ALM çözümlerini agresif bir şekilde pazara sürüyor. Müşteriler çok geçmeden bu çözümlerin mevcut geliştirme süreçleri, araçları ve platformlarıyla entegre olmadığını keşfederler. Ne yazık ki bu, geliştirme ekiplerinin ALM'nin farklı süreçleri ve veri karmaşasıyla sıkışıp kalmasına neden oluyor ve bu da onların ALM'nin tam potansiyelini fark etmelerini engelliyor.

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 sağlayacak bir yaklaşım. Borland'ın Açık ALM çözümleri ile kuruluşlar mevcut kaynaklarından ve geliştirme araçlarından yararlanabilirler. Bu, yazılım geliştirme döngüsü boyunca şeffaflığın, kontrolün ve disiplinin sağlanmasına yardımcı olacaktır. Müşteriler artık optimize edilmiş bir ALM platformundan ve birleşik, yönetilebilir ve ölçülebilir bir yazılım geliştirme sürecinden yararlanabilirler.

Tahmin edilebilir yazılım geliştirme: görev imkansız mı?

Yazılım geliştirme doğası gereği oldukça karmaşık bir iştir. Oldukça net bir şekilde tanımlanmış özelliklere sahip, kabul edilebilir kalitede tamamlanan, tahsis edilen bütçe dahilinde ve zamanında tamamlanan 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 (örneğin, offshore programlama veya geçici çalışanların ve alt yüklenicilerin kullanımı) kullanmaya karar verdiğinde, yazılım projelerini yönetme ve izlemenin karmaşıklığı artar. Sonuç olarak, projenin başarısızlığı veya terk edilmesi olağan hale geliyor. Maliyet aşımları, program kesintileri, düşük kalite ve zayıf güvenilirlik, yazılım endüstrisinde norm haline geldi. Buna göre, yazılım geliştirme organizasyonlarından giderek daha akıllı yaklaşımlar benimsemeleri isteniyor. Daha geleneksel mühendislik disiplinlerinin adımlarını takip eden, iyi yönetilen, sistematik ve süreç odaklı yaklaşımları benimsemelidirler. 1

Artan standardizasyon ve kurumsal geliştirme platformlarının kullanımı sayesinde sektörün karşılaştığı sorunlar, doğası gereği daha az teknik hale geldi. Yazılım geliştirmeden istikrarlı ve öngörülebilir kar elde etme yeteneği, bu alandaki birçok profesyonel için önemli bir öncelik haline geldi. Bilişim Teknolojileri(BT). Ekiplerinin yazılım oluşturma konusunda etkili olacağına dair güvene ihtiyaçları var. Borland, bu hususları göz önünde bulundurarak ALM için platformlar geliştirdi. Yazılım oluşturma 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 oluşturma ihtiyacına yanıt verirken, çabalarını bireysel geliştiricilerin işine yönelik araçlardan daha fazlasına odaklıyor. Üreticiler tekliflerini genişletti ve hem mevcut hem de yeni yetenekleri ürünlerine entegre etti. Artık çözümleri, yazılım oluşturma sürecindeki diğer rollerle ilişkili görevleri yerine getiriyor. Genellikle işbirliğine dayalı geliştirme platformları olarak pazarlanan ve satılan bu ürün paketleri, uygulama yaşam döngüsü yönetimi (ALM) teknolojisinin ortaya çıkışının habercisiydi. O geldi yeni kategori piyasada ve yazılım geliştirmede ayrı bir disiplin. ALM platformları, yazılım geliştirme sürecinin öngörülebilirliğini ve bütünlüğünü artırmanın getirdiği zorlukları çözmek için özel olarak tasarlanmıştır. Sürece dahil olan her önemli rol için entegrasyon ve otomasyon sağlayarak ve bir dizi işlevi otomatikleştirerek bu sorunları çözerler.

Ölçülebilirlik	Kaliteyi, üretkenliği, ilerlemeyi ve riski değerlendirmek için ölçüm sistemlerini tanımlayabilme.
	Proje süreci sırasında bu metrikleri analiz edin ve raporlar oluşturun.
Koordinasyon	İş uzmanlığı ile BT önceliklerinin uyumlaştırılması.
	Proje çıktılarının son kullanıcı beklentileriyle uyumlu hale getirilmesi.
Disiplin	Tanımı, dağıtımı ve izlemeyi yazılım süreçleriyle hizalayın.
	Yönetim değişikliği sürecinin titizliğini artırmak ve sonuçlarını tahmin etmek.

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

Varlık Yönetimi endüstrisi

Başlangıçta, ALM eğiliminin önemini anlayan ve bunu açıkça desteklemek için ürün stratejilerini değiştiren birkaç yenilikçiden bazıları Borland Ve IBM Rational. Bariz fırsatlara tepki gösteren diğer şirketler de 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 çözümü 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ştiricilere yönelik geleneksel üretkenlik araçlarının çok ötesine geçer. Yazılım oluşturmak için ekip çalışmasına odaklanan yöntemler ve araçlar sağlamayı amaçlamaktadırlar. Uygulanabilir bir ALM çözümü oluşturmak için satıcıların "genişletilmiş" yazılım geliştirme ekibinin ihtiyaçlarını karşılaması ve ürünlerine daha geniş sürece katkıda bulunacak roller dahil etmesi gerekir.

Yönetim ihtiyaçları için önemli proje ölçümlerini kapsayan portföy düzeyinde gösterge tabloları sağlanır: risk, ilerleme ve kalite.

Proje yöneticilerinin ihtiyaçlarını karşılamak için proje planlama ve kontrolü, olası alternatiflerin analizi ve kaynak tahsisi için araçlar sağlanır.

Analistlerin ihtiyaçları için, gereksinimleri tanımlamak, son kullanıcılar ve diğer proje paydaşlarıyla etkileşimde bulunmak için araçlar sağlanır. Bu seviye aynı zamanda sonraki değişiklikler de dahil olmak üzere proje yaşam döngüsü boyunca gereksinimlerin yönetilmesine yönelik araçlar sağlar.

Mimarların ihtiyaçları doğrultusunda, uygulamanın çeşitli yönlerini (bileşenler, veriler, süreç) görsel olarak modellemeye yönelik araçların yanı sıra tasarım modellerini ve kurumsal mimariyi açıklamaya yönelik araçlar sağlanmaktadır.

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

Kalite mühendislerinin ihtiyaçları için, testleri oluşturmaya ve yönetmeye, regresyon ve fonksiyonel testlere yönelik araçların yanı sıra otomatik performans testine yönelik araçlar sağlanmaktadır.

Tüm grubun ortak sorunlarının çözümü için kolektif bir altyapı kullanılmaktadır. İçin fon sağlıyor işbirliği, süreç yönetimi, değişiklik yönetimi ve sürüm kontrolü.

Yazılım oluşturma sürecindeki yöneticilerin ihtiyaçları için, bir dizi kurumsal teknoloji standardının modellenmesi ve uygulanmasına yönelik araçlar sağlanmaktadır.

Son kullanıcıların ve diğer kurumsal paydaşların ihtiyaçlarını karşılamak amacıyla gereksinim yönetimini otomatikleştirmek için araçlar sağlanır. Ayrıca gereksinimler hakkında bilgi alışverişinde bulunma, kusurları bildirme ve ortaya çıkan sorunların durumunu takip etme fırsatları da verilmektedir.

ALM teknolojisi genel olarak büyük adım uygulama geliştirme araçları endüstrisinin ve müşterilerinin geliştirilmesinde. İlginç bir şekilde Standish Group'un son Kaos raporu, yazılım projelerinin başarısızlık oranının son on yılda yarı yarıya azaldığını gösteriyor. Bu iyileşme kısmen ALM'ye bağlanabilir. Ancak müşteri ihtiyaçlarının daha derinlemesine incelenmesi, ALM'nin bariz faydalarına rağmen teknolojinin tam potansiyelini gerçekleştirmenin hala zor olduğunu ortaya koyuyor. 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'in iş potansiyeli büyük ölçüde kullanılmamış durumda

Mevcut çözümlerin iş için ALM'nin tam potansiyelinin farkına varılmasını neden 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 üretilip dağıtıldığını süreçler, geliştirme araçları ve üretim platformları açısından inceleyeceğiz. Sonuçta bu tartışma, yazılım üretiminin neden tutarlı ve öngörülebilir bir şekilde (otomatikleşme şöyle dursun) yürütülmeyen son iş süreçlerinden biri olarak kaldığını açıklıyor.

Kurumsal BT Ortamı: Heterojenlik Sorunu

İnternetin ortaya çıkışı ve önemli bir ticaret platformu olarak yükselişi, geleneksel BT organizasyonlarında önemli değişikliklere neden oldu. Bu aynı zamanda kaynak eksikliği ve yüksek esneklik gereksinimleri koşullarında zorunlu sürekli çalışmayla da kolaylaştırıldı. Bu değişikliklerdeki sorun mimari evrimle ilgilidir. Eski teknolojilerden yeni, modern uygulama platformlarına geçiş yaparak BT yanıt verme hızını, hizmet seviyelerini ve verimliliğini artırmak için tasarlanmıştır. İşte bu evrimin kilit alanları.

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

Eski mimariler üzerine kurulu paketlenmiş kurumsal uygulamalardan SAP NetWeaver ve Oracle Fusion gibi süreç ve bileşik uygulama çalışma zamanlarına geçiş yapın.

Özel ihtiyaçlar için özel platformların kullanılması. Bunlar, örneğin veritabanlarını (PHP, Ruby vb.) kullanan web uygulamaları için komut dosyası dilleri veya zengin İnternet ve multimedya yeteneklerine sahip uygulamalar geliştirmeye yönelik platformlar (örneğin, Adobe® Flash®/Flex™).

Bu teknolojilerin her biri belirli uygulama geliştirme araçlarıyla birlikte gelir (genellikle farklı satıcılar tarafından sunulur). 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 ölçekli şirketler için, öngörülebilir gelecekte her kurumsal BT ortamının aşağıdaki 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 iş otomasyonu sistem süreçleri (SAP veya Oracle). Ayrıca bazı kuruluşların hem J2EE hem de .NET platformlarına yazılım dağıttığı da görülüyor (ve giderek daha da netleşiyor). 2

Çakışan programlar

Bazı BT tedarikçilerinin, bariz nedenlerden ötürü, kurumsal BT ortamının heterojen doğasını mümkün olduğunca etkilemeye çalıştıklarını belirtmek ilginçtir. Bu satıcılar, pazara eksiksiz "ömür boyu" çözümler sunarak BT ortamının organizasyonuna tamamen "sahip olmayı" amaçlıyor. Yazılım geliştirme araçlarını, uygulamaları çalıştırmak için bir ortamı ve ağları ve sistemleri yönetmeye yönelik araçları içerirler. En büyük üreticiler çözümlerine bir işletim sistemini ve hatta donanımı da dahil ediyor. Bu tür kararların aynı zamanda önemli bir bileşeni de içerdiğini söylemeye gerek yok. profesyonel hizmetler.

Tek bir satıcının kapsamlı çözümlere yönelik bu büyük çabasına rağmen, gerçek şu ki birçok müşteri için bu yaklaşım işe yaramayacak. Bu tür organizasyonlar her düzeyde heterojenliği artı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ü en üst düzeye çıkarmak. En iyi ürünü veya hizmeti sunmaya çalışan kuruluşlar genellikle en iyi platformu ve geliştirme araçlarını tasarım perspektifinden seçerler. Bu yaklaşım, her platformun belirli son kullanıcılara sunduğu avantajlara ulaşmalarına yardımcı olur. Bu genellikle bireysel projelerde meydana gelir, ancak aynı zamanda tek bir proje içinde de gerçekleşebilir. Bu sonuçta birden fazla teknoloji alanını kapsayan "hibrit" uygulamalara yol açar. İşte bazı alakalı örnekler.

o Ana bilgisayar, paket uygulamalar ve şirket içi dağıtılmış uygulamaları içeren kompozit uygulamalar veya hizmetler.

o İstemci tarafında .NET'in yeteneklerinden ve kullanıcı arayüzünden yararlanan 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 performans için kullanılır ticaret platformlarıçünkü Wall Street'te Windows, masaüstü bilgisayarlar için fiili standarttır.

o Flash/J2EE hibritleri. 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 düzeyde ölçeklenebilirlik elde etmenize ve kapsamlı multimedya özelliklerine sahip bir arayüz uygulamanıza olanak tanır.

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

Ürünlerin pazara çıkış süresini kısaltmak. Kuruluşlar, sundukları spesifik iş faydaları nedeniyle belirli geliştirme araçlarını tercih edebilir. Bu, pazara sunma süresini önemli ölçüde azaltma potansiyeline sahiptir.

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

Risk azaltma. BT sektöründeki bazı satıcılar, platformları için özel yerel destek sağlar. Müşterilerin gözünde bu bir risk olarak görülüyor. Belirli bir BT tedarikçisinin platformuna kilitlenmek, özellikle de tedarikçinin bir rakip olması (veya rakip haline gelmesi durumunda) ciddi iş riskine yol açabilir.

2 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 trendleri, yazılım geliştirme endüstrisindeki bu belirgin dönüşümle yakından ilişkilidir. Steve McClure'un J2EE ve .NET kullanımına ilişkin IDC Insight raporunda aşağıdakiler belirtiliyor. Mevcut .NET kullanıcılarının %10,4'ü önümüzdeki 12 ay içinde hem J2EE/J2ME'yi 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 Sorunu

Kısacası, BT sektöründeki pek çok kuruluş, heterojenliği, beraberinde getirdiği birçok ticari fayda nedeniyle tek alternatif olarak görüyor. 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 satıcı yoktur. Üstelik üç ana alanı tam olarak karşılayabilecek tek bir tedarikçi yok: eski sistemlerin desteklenmesi ve modernizasyonu, paket 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 zorluk, geliştirme araçlarının heterojenliğidir. ALM'nin, otomatik ölçülebilirlik, hizalama ve disiplin yoluyla yazılım üretim sürecinde öngörülebilirlik ve bütünlüğe ulaşmaya çalıştığını hatırlayın. Ancak heterojenliğin yüksek olduğu ortamlarda yazılım üretim sürecinin bu niteliklerine ulaşmak çok daha zordur.

Ölçülebilirlik, çeşitli uygulama geliştirme araçlarından ve veri havuzlarından metrik bilgilerin toplanmasını gerektirdiğinden, bu tür veri toplamaya yönelik genel kabul görmüş bir standart yoktur. Sürece dahil olan tüm araçlar için ortak bir bilgi şeması bulunmadığından, toplanan metrikleri “normalleştirmek” ve bunları bir şekilde belirli projeler bağlamında karşılaştırmak da gerekli hale geliyor.

Uyumlama, BT stratejilerinden dağıtılan modüllere kadar süreç boyunca etkinliklerin ve teslimatların izlenmesini gerektirir. Süreç kaynakları ve faaliyetleri farklı araçlara ve depolara dağıldığında bu derecede operasyonel kontrolü başarmak çok zordur. Denetim bilgilerini otomatik olarak tanımlayan, toplayan, yöneten ve kullanan standart bir araç yoktur.

Disiplin, çeşitli önlemlerin uygulanmasını, kabul edilmesini ve kontrolünü gerektirir. genel süreçler yazılım üretim yönetimi için. Alt süreçler çeşitli süreç araçları arasında "süreç adaları" olarak çalıştırıldığında bu durum çok daha karmaşık hale gelir. Bu tür alt süreçlerin koreografisini sağlamaya (daha üst düzey bir süreçle tutarlı olarak) veya bu araçlar için süreç bileşenlerini dağıtmaya yönelik standart bir mekanizma yoktur. Farklı araçların bulunduğu bir ortamda süreçleri tanımlamak için tek tip bir terminoloji de yoktur. Hepsi kendi "unsurları", "yapıları", "projeleri" vb. dillerini kullanıyor. Disiplinin bir başka yönü de yönetim ve etki analizinde önemli değişiklikler gerektirmektedir. Ancak bu yetenekler, uçtan uca operasyonel kontrolün doğru şekilde uygulanmasını gerektirir. Tartışıldığı gibi, heterojen bir geliştirme ortamında uçtan uca kontrolü başarmak çok daha zordur.

Bu sorunları çözmek için, ALM uygulayan kuruluşlar genellikle kullandıkları çeşitli geliştirme araçları arasındaki teknoloji boşluklarını kapatan birçok özel noktadan noktaya entegrasyonları geliştirmeyi bırakırlar. Bu tür entegrasyonlar güvenilmezdir. 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, kontrol edilemeyen veya yönetilemeyen yazılım süreçlerine de neden olurlar. Açıkçası, bu yaklaşım kabul edilemez ve kârsızdır.

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

İş platformlarının bir karışımını iş hedeflerine en uygun şekilde kullanma yeteneği.

Dağıtım ihtiyaçlarına göre optimize edilmiş çeşitli ticari ve açık kaynaklı uygulama geliştirme araçlarını kullanmaktan çekinmeyin.

Kuruluşun kültürü, proje türleri ve temel teknolojisi için optimize edilmiş çeşitli ticari veya özel yazılım geliştirme süreçlerinin akıcı kullanımı.

Bu karmaşık gereksinimlerin karşılanması, ALM'ye yeni bir yaklaşım gerektirir. Müşterilerin heterojen bir BT ortamında ALM yeteneklerinden tam olarak yararlanmasına olanak tanıyan bir yaklaşım. Borland yakın zamanda 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 yazılımı kendi zaman çizelgelerinde öngörülebilir şekilde teslim etmelerini 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 ürün vizyonunu ve stratejisini uygular. Bu yaklaşım, ticari ALM pazarında benzersiz olan önemli bir mimari değişimi temsil ediyor. Aslında, Borland Open ALM platformu ve ilgili uygulamalar, tam olarak uygulandığı takdirde, herhangi bir Borland uygulama geliştirme aracını hiç kullanmayan müşterilere bile önemli faydalar sağlayabilir. Borland'ın alet işini hayati önemde gördüğüne şüphe yok. Şirket bunları geliştirmeye ve genişletilmiş yazılım geliştirme ekibine sınıfının en iyisi araçları sunmaya devam edecek. Borland araçları, Açık ALM stratejisini destekleyecek şekilde yavaş yavaş gelişecektir. Bu, Açık ALM'ye dayalı yazılım üretiminin orkestrasyonuna katılmalarına olanak tanıyacak ancak müşterilerin uygun görmesi halinde Borland araçları, geliştirme gereksinimlerini destekleyen herhangi bir ürünle değiştirilebilir. Bu bir üçüncü taraf veya açık kaynaklı ürün olabilir. Bu düzeydeki modülerlik ve esneklik, Borland'ın ürün stratejisini, çoğu yazılım tedarik zincirinin tamamını ele geçirmeye çalışan diğer ALM satıcılarından farklı kılmaktadır.

Açık ALM'nin Faydaları

Open ALM, ALM'nin işlevsel değerini sunarken süreç, araç ve platform düzeylerinde benzersiz bir esneklik sağlar. Açık ALM kullanıcıları özellikle aşağıdaki yeteneklere sahip olur:

Bir yazılım projesi bağlamında veya birkaç farklı proje için aynı anda herhangi bir platform ve çalışma alanı kombinasyonunu seçme özgürlüğü. Bu durumda seçim iş önceliklerine veya projeye uygunluğuna göre yapılır.

Seçme özgürlüğü en iyi yol ekonomi, performans ve teknik uygunluğa dayalı olarak seçilmiş platformlar için geliştirme.

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 çıkış süresi gereksinimleri.

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

Proje yönetimini ve süreç iyileştirme girişimlerini desteklemek için proje ve portföy ilerlemesine, kalite ve risk ölçümlerine ilişkin üstün, çok boyutlu ve özelleştirilebilir görünümler sağlayın.

"Kase": tamamlandı operasyonel kontrol ve yaşam döngüsü takibi. Bu, iş hedefleri ile geliştirme faaliyetleri arasında gerçek bir uyum yaratacak, 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 proje yönetimine daha iyi olanak sağlayacaktır.

Yaşam döngüsünde yer alan uzmanların ve araçların eylemlerinin otomatik süreç bazlı koordinasyonu yoluyla yazılım oluşturma sürecinin yeni bir yönetim düzeyi.

Bu yetenekler üstün ekip performansı sağlar, kalite iyileştirme girişimlerini destekler ve iç ve dış düzenlemelere uyum yükünü hafifletir. Bunlar, altyapı düzeyinde bileşenler ve kurumsal ALM kontrolleri seti olarak teslim edilecek. Ayrıca müşteriler uygulama geliştirme ve proje yönetimi için Borland'ın sınıfının en iyisi entegre araçlarından da yararlanabilirler. Bu onların dört temel süreç alanında değer kazanmalarını sağlayacaktır.

Proje Portföy Yönetimi (PPM). Araçlar ve otomatik süreçler tüm yazılım stratejisinin geliştirilmesini yönetmek ve ayrıca bir yazılım geliştirme projeleri portföyünün yürütülmesini yönetmek.

Gereksinim Tanımı ve Yönetimi (RDM). Proje gereksinimlerinin doğru ve eksiksiz olmasını, iş hedeflerine kadar verimli bir şekilde izlenebilmesini ve yazılım testleri tarafından en iyi şekilde kapsanmasını sağlayan bir dizi araç ve en iyi uygulamalar.

Yaşam Döngüsü Kalite Yönetimi (LQM). Yazılım oluşturmanın tüm aşamalarında kalitenin tanımlanmasını ve ölçülmesini yönetmeye yönelik prosedür ve araçlar. Bu araçlar, kalite sorunlarını, düzeltme maliyetinin nispeten düşük olduğu bir projenin erken safhalarında tespit etmek ve önlemek için tasarlanmıştır. Kalite Güvence ekiplerinin ayrıca testlerinin eksiksiz olduğundan ve son kullanıcı gereksinimlerine dayalı olduğundan emin olmaları gerekir.

Değişim Yönetimi (CM). Değişimin sonuçlarını tahmin etmeye yardımcı olan altyapı ve araçlar. Ayrıca hem çok düğümlü hem de tek düğümlü modellerde yaşam döngüsü değişiklikleriyle ilişkili kaynakların ve etkinliklerin yönetilmesine de 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 kontrollü bir yazılım geliştirme sürecine ulaşmaktır. Heterojen bir uygulama geliştirme ortamında ALM'nin üç boyutunun her birinin başarılmasının çok daha zor hale geldiğini ve bu nedenle ALM kullanıcıları için bir takım benzersiz zorluklar sunduğunu gördük. Borland Açık ALM platformu mimarisi, her biri temel ALM alanlarından birindeki sorunları çözmek için özel olarak tasarlanmış üç çözüm alanından oluşur. Open ALM çözümünün her alanı oldukça modüler ve genişletilebilir bir altyapı katmanını temel alır ve bir dizi özel uygulamayı temsil eder. Altyapı katmanının amacı, Açık ALM platformunun, satıcıdan veya beklenen işletim ortamı teknolojisinden bağımsız olarak ticari veya açık kaynaklı araçların ve geliştirme süreçlerinin herhangi bir kombinasyonuyla çalışmasını sağlamaktır. Bir sonraki sayfadaki diyagram Borland ALM çözümünün kavramsal diyagramını göstermektedir.

Borland Açık 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 ilerlemenin, iş kalitesinin veya diğer herhangi bir özel ölçümün ölçülebilirliğini artırmak için standart altyapı ve uygulamalar üzerine kuruludur. OBI4ALM, kesintisiz, dağıtılmış veri toplamanın yanı sıra kendisi için kayıtlı herhangi bir uygulama geliştirme aracından metriklerin korelasyonu ve analizi için altyapı sağlar. OBI4ALM çerçevesi, veri kaynaklarından önceden tanımlanmış metrikleri çıkararak, yazılım geliştirme yaşam döngüsü boyunca dağılmış farklı bilgileri birleştirir. 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 ambarı kullanır. Bu depo, yazılım oluşturma 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, buna dayalı olarak karar vermek için kullanılabilecek bilgilere dönüştürebilir. Bu, karar verme ve sorunların erken bildirimi konusunda destek sağlar.

Gerçek zamanlı veri kontrol panelleri - zaman içindeki eğilimleri gösteren temel performans göstergelerinin özelleştirilebilir görünümleri.

Metrik tabanlı uyarılar - aşağıdaki durumlarda tetiklenen özelleştirilebilir bildirimler: belirli koşullar(örneğin, bir trendin belirli bir sınırı geçmesi). Uyarılar çeşitli proje sorunlarına yönelik yönetim esnekliğini artırmaya yardımcı olur: yavaş ilerleme, Düşük kalite verimlilik eksikliği veya metrikler kullanılarak sayısal olarak gösterilebilecek herhangi bir sorun.

Karar araçları, proje yönetimi kararlarını kolaylaştırmak için bir proje (veya birden fazla proje) hakkındaki geçmiş bilgileri kullanan analitik araçlardır.

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

Son tahlilde süreç, yazılımın yaşam döngüsünün tamamına nüfuz eden en önemli kavram haline gelir. Süreç, bilgi yapılarının kullanılan araçlarla paylaşılmasından daha fazlasıdır farklı roller veya kullanıcı arayüzü düzeyinde yeteneklerin entegrasyonunu sağlamak. Süreç var gerçek potansiyel yazılım oluşturma sürecine katılan kişilerin ve sistemlerin eylemlerini koordine etmek. Süreç aynı zamanda belirlenen politikalara uyumu ve uygulamanın kalite kontrolünü de sağlar.

ALM için Açık Süreç Yönetimi (Açık Süreç yönetimi ALM için 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şenlerini ve bir dizi uygulamayı sağlar. OPM4ALM, süreç katılımcılarına rehberlik sağlamaktan ve görevler atamaktan çok daha ileri gider. Bu yöntem aynı zamanda süreç modellerinde yakalanan kurallara göre istemci tarafı, sunucu tarafı ve metodolojiyi entegre etmek için ana "tutkal" görevi gören bir düzeyde süreç otomasyonu 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, temel temel haline gelir verimli çalışma takım.

OPM4ALM altyapısı dağıtılmış bir süreç çekirdeği üzerine kurulmuştur. Heterojen bir geliştirme ortamında birden fazla yazılım oluşturma sürecinin modellenmesine, uyarlanmasına, konuşlandırılmasına, orkestrasyonuna ve koreografisine olanak tanır. OPM4ALM altyapısının önemli bir kısmı süreç olaylarının yönetimi ve tespitidir. Açık ALM araçları bu olaylara abone olabilir, onları "dinleyebilir" ve meydana geldiğinde bildirim alabilir. Süreç motoru aynı zamanda kuralların esnek bir şekilde tanımlanmasını ve değerlendirilmesini sağlar. Uygulama geliştirme politikalarının tanımlanmasına ve uygulanmasına yardımcı olur.

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

Süreçleri modellemeye, ayarlamaya, özelleştirmeye ve yeniden kullanmaya yönelik araçlar. İşlevler arası bir yazılım geliştirme modeli kullanarak ticari veya özel yazılım süreçlerinin verimli şekilde tasarlanmasını sağlarlar.

Birleştirilmiş kuş bakışı görünüm sağlayan kurumsal bir yazılım süreç konsolu. Bu görünüm, farklı geliştirme araçlarını içeren farklı projelere dağıtılan tüm yazılım süreçlerini içerir.

Süreç uyumluluğunu değerlendirmek için kontrol paneli. Süreç sapmalarını ve bunların potansiyel sonuçlarını gösterir ve uyumluluk girişimleri için faydalı raporlama yetenekleri sağlar.

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

ALM için açık kontrol

Uçtan uca süreç kontrolü, ALM'nin birçok önemli avantajını destekler. İşte bunlardan bazıları: İş gereksinimlerine dayalı geliştirmeyi, gereksinimlere dayalı geliştirmeyi ve test etmeyi ve değişikliklerin etkisinin doğru analizini uygulamak için önemli bir araçtır. ALM için Açık İzlenebilirlik (OT4ALM), yazılım oluşturma sürecinde oluşturulan kaynaklar arasındaki ilişkilerin oluşturulması ve sınıflandırılması için bir altyapı sağlar. Ayrıca oluşturuldu Esnek zamanlama ilgili kaynakların bağlantıları. Bu kaynakların hangi araçlarda bulunduğu önemli değildir. Bu teknoloji aynı zamanda kaynaklar arasındaki ilişkiler diyagramında gezinmenin yanı sıra en uygun sorguları oluşturmak ve bu diyagramın içerdiği verileri almak için de araçlar sağlar.

OT4ALM, toplanan kontrol verilerini karar verme bilgilerine dönüştüren uygulamalar sağlar.

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

Sınır kontrolü - belirlenen sınırlardan sapmalar (örneğin, gereksinimleri karşılamayan kaynaklar) ve karşılanmayan gereksinimler konusunda erken uyarı.

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

TraceView - çeşitli projelere ilişkin izlenebilirlik bilgilerini görüntülemek için etkileşimli araçlar. Tüm süreç kaynaklarının bulunmasına ve bunların diğer kaynaklarla karşılaştırılmasına yardımcı olur.

Ortak platform altyapısı

Open ALM altyapısı, çözümün tüm alanlarında kullanılan iki bileşeni içermektedir.

ALM meta modeli. Yazılım süreçlerini, süreç kaynakları (kontrol edilebilirlik) ve ölçüm birimleri (metrikler) arasındaki ilişkileri tanımlamak için ortak bir dil. ALM metamodeli, 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ığını tanımlamak için gereklidir. Bu anlayış sağlanacak etkili etkileşim Açık ALM platformunda.

ALM entegrasyon düzeyi. Genişletilebilir ve yerleştirilebilir entegrasyon motoru ve SDK. ALM araçlarını çalıştırmanın, ALM ölçümlerini toplamanın ve kaynakları izlemek için grafikler oluşturmanın standart bir yolunu tanımlar. ALM platformunu desteklemek ve buna katılmak için aracın standart Open ALM API'sini karşılayan bir platform eklentisi sağlaması gerekir. Aracı, Open ALM platformu tarafından düzenlenen süreçler aracılığıyla diğer uygulama geliştirme ortamlarına bağlayan özel bir adaptör de kullanabilirsiniz.

ALM'yi Açmanın Yolu

Önümüzdeki 24 ay boyunca Borland, Open ALM platformunu oluşturan altyapıyı, uygulamaları ve araçları giderek genişletecek. Borland ayrıca bu ürünü, dağıtımı hızlandırmak ve kurumsal Açık ALM uygulamalarının başarısını sağlamak için tasarlanmış geniş bir yelpazedeki profesyonel hizmet programlarıyla tamamlamayı planlıyor. Müşteriler bugün Open ALM'nin bazı avantajlarından yararlanabilirler. Kaliteyi artırmak, değişim ve proje yönetimi süreçlerini geliştirmek isteyen kuruluşlar Borland'ın mevcut çözümünü çok çekici bulacaktır. Bu çözüm, uygulama geliştirme süreçlerinin dört kritik alanı için yüksek düzeyde otomatik 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 araçları arasındaki sıkı entegrasyon yoluyla sağlanmaktadır. üçüncü taraf üreticiler. Bu, müşterilere ihtiyaç duydukları esnekliği sağlar ve günümüzde yazılım projelerini yönetme becerilerini önemli ölçüde artırır.

Neden Borland?

Uzun geçmişi boyunca Borland, müşterileriyle en uygun şekilde yazılım geliştirebilmelerini sağlamak için sürekli olarak işbirliği yaptı. Borland kendini standartlara dayalı geliştirme ve platformlar arası desteğe adamıştır. BT kuruluşlarına ihtiyaç duydukları esnekliği ve seçim özgürlüğünü sundu. Borland, Open ALM ile geleneksel değerlerini bir sonraki seviyeye taşıyor. yeni seviye. Bu, şirketi diğer ALM tedarikçilerinden ve kar amacı gütmeyen ALM girişimlerinden açıkça ayırıyor.

Büyük ALM satıcıları, IBM Rational ve Microsoft söz konusu olduğunda, müşteri hizmetlerinin birinci önceliği olması pek olası değildir. Bu şirketlerin her ikisi de müşterilerini ara yazılım çözümlerine ve sistem yönetimi platformlarına kilitlemek için sürekli olarak geliştirme araçlarından yararlanmaya çalışıyor.

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

Açık kaynağa doğru yönelme aynı zamanda heterojenliğin ALM için yarattığı zorluklardan da kaynaklanmaktadır. Çeşitli Eclipse girişimlerinin hedefi (Uygulama Yaşam Döngüsü Çerçevesi (ALF), Corona ve Eclipse Süreç Çerçevesi (EPF)) Borland Open ALM'ninkine benzer. Borland bu projelerin ardındaki motivasyonları anlasa da şirket yaklaşımlarının yetersiz olduğuna inanıyor. Hem ALF hem de Corona, yalnızca Açık ALM altyapısının bileşenlerini sağlamaya çalışır. Ancak Açık ALM daha fazlasıdır bütüncül yaklaşım. Bu yaklaşım aynı zamanda müşterilerin bir dizi tamamlayıcı uygulama aracılığıyla önceden oluşturulmuş altyapılardan iş değeri elde etmelerine de olanak tanır. Açık ALM'ye doğru ilerlerken Borland diğer ALM sağlayıcılarından daha ileri gidiyor. Şirket yakın zamanda ufkunu genişletti ve ek uygulama geliştirme alanlarını kapsamak istiyor. 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'ı benzersiz kılan şey, şirketin ALM kullanıcılarının kendi zaman çizelgelerine göre yazılım geliştirmelerine yardımcı olmasıdır. Borland'ın Açık ALM yaklaşımı ve ürün stratejisi, Borland'ı diğer ALM sağlayıcılarından ve açık kaynak girişimlerinden açıkça ayırıyor. Borland, BT heterojenliği gerçeğini doğası gereği tanıyan tek ana akım ALM çözüm sağlayıcısıdır. Bu şirket, ALM kullanıcılarının etkili bir şekilde kullanmalarına yardımcı olmaya çalışıyor mevcut araçlar süreçlerde, çalışma ortamlarında ve geliştirme araçlarında. Borland'ın süreç bazlı entegrasyon yaklaşımı, şirketi rakiplerinden daha da farklı kılıyor. Bu, Borland'ın ALM stratejisi boyunca şeffaflık, kontrol ve düzen sağlamasına olanak tanır.

Borland, Açık ALM için altyapı, uygulamalar ve ilgili geliştirme araçları oluşturmaya başlıyor. Böylece müşteriler ilk defa ALM'nin yeteneklerinden tam anlamıyla yararlanabilecek. Tamamen kesintisiz, yönetilebilir ve ölçülebilir bir yazılım geliştirme sürecinden yararlanacaklar.

Carolyn Pampino, IBM
Uygulamalara dayalı: Rational Team Concert Beta 3, Rational Quality Manager Beta 3, Beta 3

Gözden geçirmek

Şiddetli rekabet, birçok kuruluşu daha fazlası için ürünler yaratmaya zorluyor kısa zaman, onları daha da yenilikçi hale getirirken. Yazılım geliştirmenin kendisi karmaşık bir iştir, dolayısıyla geliştirme organizasyonları tarafından oluşturulan sistemler de son derece karmaşıktır. bilgi sistemi ve cihazlar. Teslim tarihi baskısı altındaki takımlar bunu kaliteden ödün vermeden veya bütçeyi artırmadan yapmalıdır. Bunu yapmak için stratejileri yazılım geliştirme verimliliğini artırmak olmalıdır. Bu ikilemin çözümü, uygulama yaşam döngüsü yönetimi (ALM) yoluyla yaşam döngüsü iletişimini 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 konfigürasyon yönetimi, montaj ve devreye alma gibi ilgili faaliyetleri içeren yinelemeli bir yazılım geliştirme döngüsünde insanları, süreçleri ve araçları düzenler. otomasyon, kalite yönetimi. LCA çözümleri, temel yeteneklere ek olarak yaşam döngüsü eserleri arasında izlemeyi, süreç tanımlamasını ve güvencesini ve raporlamayı içerir.

Bir LCM çözümünün en önemli faydası, bir projede yer alan kişileri, süreçleri, bilgileri ve araçları koordine etme yeteneğidir. Yenilikçi ürünler proje paydaşları için. Herkese uygun tek bir çözüm olmadığından, müşterilerimize odaklanmalarını tavsiye ediyoruz. aşağıdaki ilkeler Kuruluşlarının kültürüne ve ortamına en uygun yaşam döngüsü yönetimini uygularken:

• Gerçek zamanlı planlamayı kullanın;
• İlgili yapılar için yaşam döngüsü takibi sağlayın;
• Bağlamda etkileşim fırsatları sağlayın;
• Geliştirme için iş analitiğini uygulayın;
• Geliştirme sürecinin sürekli iyileştirilmesini sağlayın.

Gerçek zamanlı planlama

Plan yapıyoruz çünkü belirli bir hedefe ulaşmak istiyoruz ve ona ne zaman ulaşılacağını bilmek istiyoruz. Bir işin ne zaman tamamlandığını bilmenin tek bir yolu vardır. Bunu yapabilmek için planların proje yürütmeyle tamamen entegre olmasını ve her zaman güncel olmasını sağlamak gerekir. Aşağıdaki tablo, yapmanız veya yapmamanız gereken birkaç genel planlama faaliyetini listelemektedir.

Gereksinimlerin, modellerin, geliştirme ve test planlarının birbirinden kopuk olduğu, ayrı ayrı yönetildiği veya hiç yönetilmediği bir ortam yaratmayın.	Tüm ekibin çalışmasını izleyen, gereksinimlere göre otomatik olarak geliştirme ve test planları oluşturan ve bireysel gereksinimleri, iş öğelerini ve test senaryolarını birbirine bağlayan planlama çözümlerini seçin. Birden çok görünümü kullanarak tüm işlevsel ekiplerdeki işlerin yaşam döngüsünü izleyen planları kullanın. Planların sıralı liste, iş kırılım yapısı, yol haritası veya görev panosu görünümleri gibi aynı verilerin birden çok görünümünü görüntüleme yeteneği, işi tahmin etmenize ve tüm ekip üyelerine dağıtmanıza yardımcı olur, bu da daha hızlı yayınlanma süresi sağlar.
Yaşam döngüsü yönetimi ortamınızla ilgili olmayan ve ekibin faaliyetleri ve hedefleriyle bağlantısı olmayan planları kullanmaktan kaçının.	Proje yürütmeyle tamamen entegre olan planları kullanın. Tüm planların erişilebilir ve proje ekibindeki herkese açık olduğundan emin olun. Planların doğru olmasını sağlamak için her göreve harcanan zamanı belirtebildiğinizden emin olun. Ekip üyeleri, değişikliklerin proje tamamlanma tarihleri ​​üzerindeki etkisini görebilir ve kritik yolları ve proje tamamlama gecikmelerini ortadan kaldırmak için iş yükünü buna göre dağıtabilir.
Manuel güncellemeleri kullanmayın çünkü bu hatalara neden olabilir.	Teşvik etmek Aktif katılım Planlama ekipleri, bilgiye erişimi kolaylaştıran planlar ve eldeki iş bağlamında plan verilerini güncellemeyi kolaylaştıran bir kullanıcı arayüzü kullanır.
Planların projenin başında oluşturulduğu ve bir daha asla kullanılmadığı durumlardan kaçının.	Harici veya ekip değişikliklerine hızlı bir şekilde yanıt vermek için gerçek zamanlı planları, yaşam döngüsü sorgularını ve proje kontrol panellerini kullanarak sürekli planlama yapın.

Aşağıdaki resimde, harcanan zamanın doğrudan bir iş öğesinden güncellenmesinin, doğru planların sürdürülmesini ne kadar kolaylaştırdığı gösterilmektedir.

Pirinç. 1. Bir iş öğ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ümlerin kullanılması ekibin çalışmayı dengelemesine, etkili bir şekilde plan yapmasına ve değişikliklere daha hızlı yanıt vermesine yardımcı olur.

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

Pirinç. 3. Elektronik görev panosu sunumu coğrafi olarak konumlanmış esnek ekipler tarafından kullanılabilir

Pirinç. 4. Kalkınma planı görünümü, görevlerin güne ve haftaya göre dağılımını daha geleneksel bir şekilde gösterir

Aşağıdaki resim, Rational Team Concert'teki ilgili Ürün İş Listesine, Rational Requirements Composer'daki gereksinim koleksiyonlarına ve Rational Quality Manager'daki bir test planına bağlantılar içeren bir Sürüm Planını göstermektedir.

Pirinç. 5. İhtiyaçların toplanması ve test planları planlamayla ilgilidir.

IBM Rational'ın işbirliğine dayalı yaşam döngüsü yönetimi çözümü, tamamen entegre, gerçek zamanlı planlamayı içerir.

Yaşam döngüsü izleme

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

Yaşam döngüsü yapıları arasında izlenebilirliğe olanak tanıyan bir LCI çözümü, ekiplerin projelerinin durumuyla ilgili karmaşık soruları yanıtlamasına yardımcı olur. Yapılar arasında bağlantı oluşturmak, ekiplerin şu tür soruları daha kolay yanıtlamasına olanak tanır: "Kusurlardan hangi gereksinimler etkileniyor?" ve "Hangi iş öğeleri teste hazır?"

Pirinç. 6. LCA çözümünün yanıtladığı önemli sorular

İzleme, her ekip üyesinin diğer herkesin ne yaptığını ve bunun genel iş yükünü nasıl etkilediğini anlamasına yardımcı olur. Dışarıdan denetlenen bir ortamda çalışıyorsanız izleme, denetçilerin "Bu yapıya hangi değişiklikler dahil edildi, hangi testler yapıldı ve hangi sonuçlarla sonuçlandı?" gibi soruları yanıtlamanıza yardımcı olabilir.

Konu takip olduğunda yapılması ve yapılmaması gerekenler aşağıda verilmiştir:

Kaçınılması gereken aktiviteler
Kullanıcıların yapılar arasında bağlantı kurmasını engelleyen karmaşık arayüze sahip çözümlerden kaçının. Yönlendirme bağlantıları oluşturarak veya yalnızca yönlendirme amacıyla yönlendirme yaparak aşırıya kaçmayın.	Basit, birleşik bir kullanıcı arayüzü aracılığıyla izleme ilişkileri oluşturmayı ve sürdürmeyi kolaylaştıran bir çözüm kullanın; böylece kimse yalnızca iki yapıyı birbirine bağlamak için başka araçlara geçmek zorunda kalmaz. Cevaplamak istediğiniz birkaç anlamlı soruyu belirleyin ve bağlantı kurmaya yönelik ilgili stratejileri belirleyin. Birini deneyin ve bir sonrakine geçmeden önce başarılı olduğunuzdan emin olun.
Hızla güncelliğini yitiren raporlar oluşturmaktan ve projenin tamamlandığının anlaşılmasına katkıda bulunmayan çözümleri takip etmekten kaçının.	Projenin tamamlandığını değerlendirmenize ve yapılar arasındaki ilişkilere dayalı olarak tamamen bilinçli kararlar vermenize olanak tanıyan sorgular, raporlar ve görünümler sağlayan bir sistem kullanın. Ayrıca yönlendirme bağlantılarını doğrudan plandan görebilmeniz gerekir. Boşlukların tespit edilmesine yardımcı olan sorgulara örnek olarak "gereksinimleri olmayan öğeleri planlayın" ve "test senaryoları olmayan öğeleri planlayın" verilebilir. Tamlığın değerlendirilmesine yardımcı olan sorgular arasında "başarısız testlere sahip öğeleri planlayın", "test engelleme kusurları" ve "açık kusurlara sahip gereksinimler" yer alır.
Dış düzenleyici gereklilikleri ve denetimleri dikkate almayan çözümleri kullanmaktan kaçının.	Bakımı ve raporlaması kolay izleme ilişkileri oluşturma yeteneğini içeren bir çözüme yatırım yapın.
Entegre olmayan tasarım veritabanlarını kullanmaktan, özel API'lere dayalı olarak kendi entegrasyonlarınızı geliştirmekten ve ilgisiz araç setini birleştirmeye çalışmaktan kaçının. Bağlantılı veriler oluşturmak için açık arayüzler sağlamayan çözümleri kullanmayın. Tescilli entegrasyonlara sahip LCI depolarını seçmeyin.	Tüm yaşam döngüsü boyunca verileri birbirine bağlamak için açık hizmetlere sahip bir çözüm seçerek işlevler arası ekiplerinizi entegre edin. kullanarak açık arayüzleri uygulayan bir çözüm seçin. açık hizmetler(OSLC) yaşam döngüsündeki veriler arasında ilişkiler kurmak. Yaşam döngüsü yönetimi entegrasyonu zorluklarının karmaşıklığını anlayan ve destekleyen bir ürün sağlayıcısı seçin. Uzun vadeli entegrasyon planlarına sahip araçlara yatırım yapın; çünkü bu, proje ilerledikçe bağlantı ve izleme oluşturmayı kolaylaştıracaktır. Gelecekte ihtiyaçlarınızı karşılamanıza yardımcı olacak açık ve esnek entegrasyonlara sahip ölçeklenebilir bir çözüm seçin. Zaman değişiyor, yeni ürünler ortaya çıkıyor ve LCI çözümünüzün daha da gelişmesi gerekecek.

Aşağıdaki resimde gereksinimlere ve test senaryolarına bağlantılar içeren bir yayın planının izleme görünümü gösterilmektedir. Planda ayrıca plan öğelerini etkileyen kusurları gösteren bir sütun da bulunur. Bu, izleme bilgileri içeren entegre bir plan örneğidir. Eski, periyodik olarak oluşturulan izleme raporlarının aksine, yerleşik izleme görünümüne sahip entegre bir plan kullanıldığında, yapaylıkların eksikliği açıkça ortaya çıkar ve projede kolayca düzeltilir.

Pirinç. 7. Geliştirmeyi, gereksinimleri ve testleri kapsayan yayın planı

İzleme bağlantıları oluşturulduktan sonra IBM Rational Collaborative Lifecycle Management, test sırasında belirlenen kusurlara yönelik izleme bağlantılarını otomatik olarak oluşturur. Aşağıdaki resim, kendisi için oluşturulan izleme bağlantılarıyla birlikte bir kusuru göstermektedir. Test sırasında bir hata eklediğinizde, hata ile test sonuçları arasındaki izleme bağlantıları, test senaryosu, test planı, plan öğesi ve gereksinim otomatik olarak oluşturulur.

Pirinç. 8. Kusur görüntüleme test senaryoları, plan öğeleri ve bundan etkilenen gereksinimler için otomatik olarak oluşturulan yaşam döngüsü ilişkileri

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şlar için ürün değerini artırır; bu da etkileşimin inovasyon için önemli olduğu anlamına gelir. Bir LCM çözümündeki işbirliği fırsatları, ekip üyelerinin birbirleriyle iletişim kurma, değişime yanıt verme ve projenin öngörülebilirliğine katkıda bulunma becerilerini geliştirebilir.

İşbirliği araçları aynı zamanda ekiplerin önemli olana odaklanmasına da yardımcı olur. Ekipler, manuel ve yaratıcı olmayan görevleri otomatikleştirmek için her fırsatı bulmalıdır. İyi bir LCI çözümü, derlemeler ve test yürütme için otomasyonu içerir, ancak aynı zamanda durum raporlaması ve bilgi erişimi için de otomasyon içermelidir. Proje kontrol panelleri ve kişisel kontrol panelleri, ekibin otomatik olarak tedarik edilmesinde önemli bir rol oynar gerekli bilgi Ekip çalışmasına ilişkin görünürlük ve ekip raporları ve sorguları aracılığıyla güncel verilere erişim sağlar. İyi tasarlanmış bir kullanıcı arayüzü bilgiye erişimi otomatikleştirir ve kullanıcıları başka bir uygulamaya geçerek "bağlamı değiştirmeye" zorlamadan bilgiyi doğrudan kullanıcılara iletir. Bu haliyle otomasyon, daha iyi etkileşimlere doğrudan katkıda bulunur.

Kaçınılması gereken aktiviteler
İnsanların birlikte çalışmasına güvenmeyin e-posta, anlık mesajlaşma programları, elektronik tablolar ve sözlü iletişim.	Bilgilerin tüm ekip üyelerinin çalışmaları kapsamında anında erişilebildiği bir sistem kullanın. Tüm iş öğesi tartışmalarını plana entegre ederek LCM ortamınızı proje geçmişini anlamak için gereken tek bilgi kaynağı haline getirin; bu, gelecekteki ürün iyileştirmelerinin geliştirilmesini hızlandıracaktır. Ekipteki herkesin bağlantılı verileri kullanabilmesini sağlayarak ekibinizi birbirine bağlayın. Farenizi bir bağlantının üzerine getirdiğinizde, bağlantının diğer ucundaki yapıyla ilgili bilgiler görüntülenmelidir.
Paydaşlarınızın fikirlerini göz ardı etmeyin veya onların ne istediğini zaten bildiğinizi varsaymayın.	Gereksinimleri açıklığa kavuşturmak ve paydaş girdilerine erken ve sıklıkla yanıt vermek için çevrimiçi incelemeleri, onayları ve tartışma tartışmalarını kullanın.

Aşağıdaki resimde Rational Team Concert, Rational Requirements Composer ve Rational Quality Manager'dan gelen bilgileri içeren widget'ları içeren bir dizi gösterge tablosu gösterilmektedir. Kontrol panellerindeki veriler projenin mevcut durumunu görüntüler.

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

Aşağıdaki resimde her zaman kullanıcı arayüzünün yanında bulunan ve sola veya sağa yerleştirilebilen mini bir kontrol paneli gösterilmektedir. Kullanıcıyı LCM çözümü boyunca takip eden kişisel bir mini kontrol paneli olarak işlev görür ve istenildiği zaman gizlenebilir veya gösterilebilir.

Pirinç. 10. Mini panele kullanıcı arayüzünün herhangi bir yerinden erişilebilir

Aşağıdaki resim Rational Team Concert'taki kişisel bir mini kontrol panelini göstermektedir. Bu panel, Rational Requirements Composer'daki gereksinim değişikliklerini görüntüleyen bir pencere öğesi içerir. Bu, çeşitli kaynaklardan gelen bilgileri içeren bir mini kontrol paneli örneğidir. Farenizi bir gereksinimin üzerine getirdiğ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 hızla alışacaklardır.

Geliştirme için iş analitiği

Başarı ölçütlerini tanımlamazsanız bir şeyin iyiye gittiğini nasıl anlarsınız? Bir projenin herhangi bir anında ekibin başarılı bir sonuca doğru ilerleyip ilerlemediğini söyleyebilir misiniz? İyileştirilmesi gereken alanların belirlenmesi, hedeflerin belirlenmesi ve bu hedeflere ulaşma yönündeki ilerlemenin izlenmesi, gelişim için iş analitiğinin geliştirilmesine yardımcı olan unsurlardır.

Capers Jones 1'e göre ölçüm uygulamalarını yoğun olarak kullanan projeler, kullanmayanlara göre çok daha başarılı oluyor.

Pirinç. 12. Ölçme uygulamalarını kullanan projelerin başarı şansı daha yüksektir.

Örneğin Capers Jones araştırmasına göre kuruluşların %50'sinden azında aşağıdaki üç ölçüm kullanılıyor:

• Kalite ölçütleri %45
• Verimlilik ölçümleri %30
• Hazırlık metrikleri %15

Kaçınılması gereken aktiviteler
Başka kuruluşlara veya herhangi bir kuruluşa ait performans ölçümlerini kullanmayın. dış kaynaklar projenize.	Kuruluşunuza uygun performans ölçümlerini ayarlayın.
Durum güncellemeleri için ekibe anket yapmak veya e-tabloları sabit diskinizde depolamak gibi manuel olarak toplanan bilgilere güvenmeyin.	Ekibinizin faaliyetlerinden elde edilen bilgilere göre otomatik olarak oluşturulan canlı kontrol panellerine ve raporlara güvenerek gerçeğe dayalı kararlar alın.
Tüm proje metriklerini aynı anda belirlemeye çalışmayın.	Bir metrik tanımlarken küçük başlayın. Sorunlu noktayı bulun, karar verin ve bir iyileştirme yöntemi seçin; Bu iyileştirme için ilerlemeyi nasıl ölçeceğinizi belirleyin. Ekibinizi istenen sonuca doğru yönlendirmek için ekibinizin faaliyetleri hakkında bilgi toplayan bir araç kullanın.

Aşağıdaki resimde proje panosundaki geliştirme ekibine ait raporlar gösterilmektedir. Bir iş öğesini güncellerken raporlar ekibin faaliyetlerini ve ilerleme yönünü yansıtır. Ekibinizin planlanan çalışmayı tamamlama yönündeki ilerlemesini takip etmek için ilerleme çizelgelerini kullanın. Veya alternatif olarak, Açık, Devam Ediyor ve Kapalı durumlarındaki iş öğelerinin sayısındaki değişiklikleri gösteren grafikleri kullanın (ideal olarak, Açık ve Devam Ediyor durumlarındaki öğelerin sayısı azalmalıdır ve "Açık" ve " Devam Ediyor" ifadesi. Kapalı" - büyüyün).

Pirinç. 13. İyileştirmeleri ölçmek için raporlar ve ölçümler içeren kontrol paneli

Kontrol panelleri ve raporlar, ekibin devam eden ilerlemesinin ölçülmesinden ve yanıt verilmesinden sorumlu olan LCI çözümünün önemli bir bileşenidir.

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

Bir süreç, belgelenmiş bir dizi eylemden daha fazlasıdır. Ekip iletişimini iyileştirmenin ve ekibin başarı şansını artırmanın bir yolu olarak sektördeki en iyi uygulamaları temel alan 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, esasen tüm ekibin alışkanlıklarını değiştirmesini ve ilk başta onlara açık olmayabilecek davranışları benimsemesini istiyorsunuz. Bir kişinin alışkanlıklarını değiştirmek oldukça zordur. Bir süreci değiştirmek çoğu zaman birçok insanın düşünme ve davranış biçimini değiştirmeyi gerektirir. İyi tasarlanmış bir LCM çözümü, sürecinizi aşamalı olarak değiştirmenize, ekip dinamiklerini geliştirmenize ve daha yüksek verimliliğe doğru ilerlemeye devam etmenize olanak tanır.

Kaçınılması gereken aktiviteler
Sürecin kalitesini ihmal etmeyin veya ekstra bir yük olarak görmeyin.	Sürekli iyileştirmenin ekibinizin benimsemesine yardımcı olacağının farkına varın en iyi uygulamalar, bir çalışma ritmi yaratın ve beklenmedik sorunları azaltın.
Her şeyi bir anda iyileştirme dürtüsüne karşı koyun. Süreci tek seferde çok kesin bir şekilde tanımlamaya çalışmayın.	Projenin mevcut durumuna göre ekibin endişelerini gidermek için planları ve kontrol panellerini sürekli değiştirerek artan iyileştirmelerden yararlanın. Mevcut durumunuzu iyileştirmeye başlamanıza yardımcı olacak bir yaklaşım kullanın.
Bir işlemin tanımlandıktan sonra sabit sürücüye yazıldığı ve bir daha asla görüntülenmediği bir durumdan kaçının.	Birden fazla ekibin tek bir araçta kullanabileceği süreç spesifikasyonları, şablonlar ve otomasyon biçimindeki en iyi uygulamaları benimseyerek çığır açan iyileştirmeler sağlayın.
Süreci çok sıkı kontrol etmekten kaçının.	Sürekli iyileştirmeyi kolaylaştıran ve herkesin kullandığı bir araçla yapılabilecek bir sistemi seçerek ekip üyelerini süreç iyileştirmeye katılmaya teşvik edin.
Nihai sonucu görmeden süreç iyileştirmelerini tanımlamayın.	Süreç iyileştirmelerini belirledikçe iyileştirmelerin sonuçlarını gösterge tablolarında görüntüleyin.
İlk seferde her şeyin doğru olmasını beklemeyin.	Her zaman daha fazla iyileştirmeye yer olduğu anlaşılmalıdır. Bu nedenle iyileştirmelerin sürekli olarak gözden geçirilmesi ve bir sonraki iyileştirme grubunun belirlenmesi gerekmektedir. Kalite hedeflerine ulaşma becerilerini geliştirmek isteyen ekipler, Rational Team Concert ve Rational Requirements Composer ile yerleşik entegrasyonlara sahip olan Rational Quality Manager'ı kullanıyor. IBM Rational Quality Manager, hemen hemen her hedef platform ve test türü için entegre yaşam döngüsü desteği sağlayan tek bir test yönetimi merkezi sağlayarak kuruluşların proje kalitesini optimize etmesine yardımcı olur. Test planlama, test oluşturma ve yürütmenin yanı sıra iş akışı kontrolü, yönetim ve uçtan uca izleme için özelleştirilebilir rol tabanlı bir çözüm uygular. Bu ürünleri birlikte kullanmak, ekibin bu makalede tartışılan 5 yaşam döngüsü yönetimi ilkesini uygulamasına olanak tanır. Bu ilkeler araçlara yerleştirilmiştir ve yüksek kaliteli yazılım yeniliği yaratma yeteneğinizi geliştirmenize yardımcı olmaya hazırdır. İşin iyi yanı, en iyi sonuçları elde etmek için üç aracı da kullanmanıza gerek olmamasıdır; bunlar çiftler halinde veya hep birlikte kullanılabilir. ___________________________________________________________________________________________________________

Yazılım geliştirmeden bahsederken birçok kullanıcının (ve dürüst olmak gerekirse bazı BT uzmanlarının) öncelikle uygulama kodunun oluşturulması ve hata ayıklamasını kastettiği bilinmektedir. Bu tür fikirlerin gerçeğe oldukça yakın olduğu bir dönem vardı. Ancak modern uygulama geliştirme yalnızca kod yazmaktan ibaret değildir, aynı zamanda programlamanın kendisinden önceki ve sonraki diğer süreçlerden de oluşur. Aslında onlar hakkında daha fazla konuşacağız.

Uygulama geliştirme yaşam döngüsü: hayaller ve gerçeklik

Hem Rusya'da hem de yurt dışında ticari açıdan başarılı birçok ürünün yalnızca uygulama geliştirme araçları kullanılarak hayata geçirildiği ve hatta verilerin çoğu zaman kağıt üzerinde tasarlandığı bir sır değil. Rusya'da (ve birçok Avrupa ülkesinde) yazılım oluşturmaya yönelik tüm olası araçlar arasında uygulama geliştirme araçlarının ve biraz daha az ölçüde veri tasarım araçlarının artık popüler olduğunu söylemek abartı olmaz (bu öncelikle projeler için geçerlidir) küçük bir bütçe ve sıkıştırılmış uygulama son tarihleri ​​ile). Teknik spesifikasyonlardan kullanıcı talimatlarına kadar tüm proje dokümantasyonu metin editörleri kullanılarak oluşturulur ve bunların bir kısmının programcı için yalnızca başlangıç ​​bilgisi olması, onu basitçe okuduğu anlamına gelir. Ve bu, bir yandan gereksinim yönetimi araçları, iş süreci modelleme, uygulama test araçları, proje yönetimi araçları ve hatta üretim araçları olmasına rağmen Proje belgeleri Uzun zamandır var olan bir projedir ve diğer taraftan her proje yöneticisi doğal olarak hem kendisinin hem de diğer icracıların hayatını kolaylaştırmak ister.

Pek çok proje yöneticisinin, liderlik ettikleri ekiplerin çalışmalarının birçok aşamasını otomatikleştirmesine olanak tanıyan araçlara olan güvensizliğinin nedeni nedir? Bana göre bunun birkaç nedeni var. Bunlardan ilki firmanın sıklıkla kullandığı araçların birbirleriyle iyi entegre olmamasıdır. Tipik bir örneği ele alalım: Modelleme için Rational Rose, kodlama için Delphi Professional, veri tasarımı için CA AllFusion Modeling Suite kullanılıyor; bu ürünlere yönelik entegrasyon araçları ya sürümlerinin belirli bir kombinasyonu için mevcut değil ya da Rusça ile düzgün çalışmıyor ya da satın alınmamış. Sonuç olarak Rose ile oluşturulan kullanım senaryosu diyagramları ve diğer modeller, tasarım belgelerindeki resimlerden başka bir şey değil ve veri modeli esas olarak şu tür soruların yanıt kaynağı olarak hizmet ediyor: "Bu tabloda bu alana neden ihtiyaç duyuldu?" Ve uygulamanın veritabanı alan adlarının Rusça eşdeğerleri gibi basit bölümleri bile proje katılımcıları tarafından en az üç kez yazılır: bir kez veri modeli veya uygulamayı belgelendirirken, ikinci kez kullanıcı arayüzü kodunu yazarken ve üçüncü kez oluştururken bir yardım dosyası ve kullanım kılavuzları.

Yazılım yaşam döngüsü destek araçlarına duyulan güvensizliğin daha az ciddi olmayan ikinci nedeni, yine bu tür ürünler için entegrasyon araçlarının eksikliği veya zayıf işlevselliği nedeniyle, çoğu durumda projenin tüm bölümlerini sürekli olarak senkronize etmenin mümkün olmayabilmesidir. birbirleriyle: süreç modelleri, veri modelleri, uygulama kodu, veritabanı yapısı. Projenin uygulandığı açıkça görülüyor. klasik şema gereksinimlerin ilk olarak formüle edildiği, ardından modelleme ve tasarımın gerçekleştirildiği, ardından geliştirme ve son olarak uygulamanın yapıldığı şelale (Şekil 1) (bu şema ve diğer proje uygulama metodolojileri hakkında Lilia Hough'un bir dizi incelemesinde okuyabilirsiniz, Dergimizde yayınlanan) gerçeklikten çok bir hayal var; kod yazılırken müşterinin bazı süreçlerini değiştirme veya ek işlevsellik isteme zamanı olacak. Bir projenin sonucu genellikle yukarıda açıklanandan çok uzak bir uygulamadır. başvuru şartları ve orijinal modelle çok az ortak noktası olan bir veritabanı ve tüm bunları belgelemek ve müşteriye aktarmak amacıyla birbirleriyle senkronize etmek oldukça emek yoğun bir göreve dönüşüyor.

Yazılım yaşam döngüsü destek araçlarının yararlı olabilecekleri her yerde kullanılmamasının üçüncü nedeni, seçeneklerinin son derece sınırlı olmasıdır. Açık Rusya pazarı Aktif olarak tanıtılan başlıca iki ürün grubu vardır: IBM/Rational araçları ve Computer Associates araçları (esas olarak AllFusion Modeling Suite ürün grubu), şu anda devam eden kod, veritabanı senkronizasyon sürecinden ziyade büyük ölçüde belirli modelleme türlerine odaklanmıştır. ve modeller.

Psikolojik faktörler olarak sınıflandırılabilecek bir neden daha var: Uygulamalarının tam olarak resmileştirilmesi ve belgelenmesi için hiç çaba göstermeyen geliştiriciler var - sonuçta bu durumda vazgeçilmez hale geliyorlar ve değerli çalışanlar ve böyle bir geliştiricinin görevden alınmasının ardından kodunu veya sadece ona eşlik eden ürünü anlamak zorunda kalan bir kişi, çok uzun bir süre kendini tam bir aptal gibi hissedecektir. Bu tür geliştiriciler elbette çoğunlukta değil, ancak en az beş tane biliyorum şirket yöneticileri, bu tür eski çalışanların kendisi için çok fazla kan döktüğü.

Elbette birçok proje yöneticisi, özellikle de küçük bütçeli ve sınırlı teslim tarihlerine sahip projeler, geliştirilmekte olan yazılım ürününün gereksinimlerini formüle edebilecekleri bir araca sahip olmak ve bunun sonucunda hazır bir dağıtım almak ister. çalışan bir uygulama. Bu elbette şimdilik ancak hayalini kurabileceğimiz bir ideal. Ancak dünyaya inerseniz, daha spesifik dileklerinizi formüle edebilirsiniz:

1. Gereksinim yönetimi araçları, uygulama modelinin ve veri modelinin oluşturulmasını kolaylaştırmalıdır.

2. Bu modellere dayanarak kodun önemli bir kısmı oluşturulmalıdır (tercihen sadece istemci değil aynı zamanda sunucu).

3. Dokümantasyonun önemli bir kısmı otomatik olarak ve bu başvurunun amaçlandığı ülkenin dilinde oluşturulmalıdır.

4. Uygulama kodu oluşturulurken modellerde otomatik değişiklikler meydana gelmeli, model değiştiğinde kod da otomatik olarak üretilmelidir.

5. Modelde değişiklik yapıldığında elle yazılan kod kaybolmamalıdır.

6. Yeni bir müşteri gereksiniminin ortaya çıkması, modellerde, kodda, veritabanında ve belgelerde yapılan değişikliklerle ilgili ciddi sorunlara neden olmamalıdır; bu durumda tüm değişikliklerin eşzamanlı olarak yapılması gerekir.

7. Yukarıdakilerin hepsine yönelik sürüm kontrol araçları, değişiklikleri arama ve takip etme açısından kullanışlı olmalıdır.

8. Ve son olarak, tüm bu veriler (gereksinimler, kod, modeller, belgeler), proje katılımcılarının sorumluluklarını yerine getirebilmeleri için tam olarak ihtiyaç duydukları ölçüde mevcut olmalıdır - ne fazla ne eksik.

Başka bir deyişle, uygulama geliştirme döngüsü, müşteri gereksinimlerindeki veya bunların uygulanma şeklindeki değişikliklerle ilişkili ek maliyetler olmaksızın yinelemeli, işbirliğine dayalı geliştirmeye izin vermelidir.

Tüm bu isteklerin IBM/Rational veya CA araçlarını kullanarak uygulanmasının kesinlikle imkansız olduğu konusunda sizi temin edemem; teknolojiler gelişiyor, yeni ürünler ortaya çıkıyor ve bugün imkansız olan şey yarın mümkün olacak. Ancak uygulamanın gösterdiği gibi, bu araçların en popüler geliştirme araçlarıyla entegrasyonu ne yazık ki hala ilk bakışta göründüğü kadar ideal olmaktan uzaktır.

Bir proje yöneticisinin bakış açısından Borland ürünleri

Borland, geliştirme araçlarının en popüler üreticilerinden biridir: ürünleri yirmi yıldır geliştiriciler tarafından haklı olarak sevilmektedir. Yakın zamana kadar, bu şirket esas olarak doğrudan uygulama kodu yaratıcılarına yönelik geniş bir araç yelpazesi sunuyordu - Delphi, JBuilder, C++Builder, Kylix (tüm bu ürünler hakkında dergimizde birkaç kez yazdık). Ancak bir şirketin pazardaki başarısı büyük ölçüde onun gelişim trendlerini ne ölçüde takip ettiği ve ürünlerinin tüketicisi olanların (bu durumda uygulama geliştirmede uzmanlaşmış şirketler ve departmanlar) ihtiyaçlarını ne kadar anladığıyla belirlenir.

Bu nedenle Borland'ın geliştirme araçlarına yönelik mevcut geliştirme stratejisi, gereksinim tanımı, tasarım, geliştirme, test etme, uygulama ve uygulama bakımı da dahil olmak üzere tüm uygulama yaşam döngüsünün (Uygulama Yaşam Döngüsü Yönetimi, ALM) desteklenmesini içerir. Bu, geçen yıl Borland'ın bir dizi şirketi satın almasıyla kanıtlanmıştır - BoldSoft MDE Aktiebolag (önde gelen bir tedarikçi) son teknoloji Model Odaklı Mimari uygulama geliştirme), Starbase (yazılım projeleri için konfigürasyon yönetimi araçları sağlayıcısı), TogetherSoft Corporation (yazılım tasarım çözümleri sağlayıcısı). Bu şirketlerin satın alınmasından bu yana bu ürünlerin birbirleriyle entegrasyonu konusunda birçok çalışma yapıldı. Sonuç olarak bu ürünler, proje yöneticilerinin yinelemeli ekip gelişimini organize etme becerisine ilişkin ihtiyaçlarını zaten karşılamaktadır. Aşağıda Borland'ın şu anda yöneticilere ve yazılım geliştirme projelerindeki diğer katılımcılara tam olarak neler sunduğunu tartışacağız (aşağıda açıklanan ürünlerin ve entegrasyon teknolojilerinin çoğu şirket tarafından Kasım ayında San Jose, Amsterdam ve Moskova'daki geliştirici konferanslarında sunuldu).

İhtiyaç Yönetimi

Gereksinim yönetimi geliştirme sürecinin en önemli parçalarından biridir. Kural olarak formüle edilmiş gereksinimler olmadan, proje üzerinde çalışmayı normal şekilde organize etmek veya müşterinin gerçekten uygulananı tam olarak almak isteyip istemediğini anlamak neredeyse imkansızdır.

Analistlere göre proje bütçesinin en az %30'u uygulamanın yeniden işlenmesi olarak adlandırılan şeye harcanıyor (ve kişisel olarak bu rakamın büyük ölçüde hafife alındığını düşünüyorum). Üstelik bu çalışmanın %80'inden fazlası yanlış veya yanlış formüle edilmiş gereksinimlerle ilişkilidir ve bu tür kusurların düzeltilmesi genellikle oldukça pahalıdır. Ve müşterilerin, uygulama neredeyse hazır olduğunda gereksinimleri değiştirmeyi ne kadar sevdikleri muhtemelen tüm proje yöneticileri tarafından bilinmektedir... Bu nedenle gereksinim yönetimine azami dikkat gösterilmelidir.

Gereksinim yönetimi için Borland, esas olarak gereksinim yönetimi sürecini otomatikleştiren ve değişiklik izleme araçları sağlayan bir platform olan Borland CaliberRM ürününe sahiptir (Şekil 2).

CaliberRM, geliştirme ortamına bir gereksinimler listesi yerleştirmeye ve gereksinim simgesini fareyle kod düzenleyiciye sürüklerken kod şablonları oluşturmaya kadar hem Borland hem de diğer üreticilerin (örneğin Microsoft) birçok geliştirme aracıyla bütünleşir. Ek olarak, buna dayanarak kendi çözümlerinizi oluşturabilirsiniz - bunun için özel bir CaliberRM SDK araçları seti vardır.

Bu ürünün yalnızca yazılıma yönelik değil aynı zamanda diğer ürünlere yönelik gereksinimleri yönetmek için kullanıldığını unutmayın. Bu nedenle, başarılı kullanımının bilinen örnekleri vardır. Otomotiv endüstrisi Arabaların çeşitli bileşenlerinin (Jaguar arabaları dahil) gereksinimlerini yönetmek. Ayrıca JBuilder ürün grubundan sorumlu yönetici Jon Harrison'a göre Borland JBuilderX'i oluşturmak için CaliberRM'yi kullanmak bu ürünün geliştirme sürecini önemli ölçüde basitleştirdi.

Ve son olarak, uygun bir gereksinim yönetimi aracına sahip olmak, proje belgelerinin oluşturulmasını yalnızca ilk aşamalarda değil, büyük ölçüde basitleştirir. projenin aşamaları, ama aynı zamanda sonrakilerin hepsinde.

Uygulama ve Veri Tasarımı

Tasarım, bir uygulama oluşturmanın eşit derecede önemli bir parçasıdır ve belirtilen gereksinimlere dayanmalıdır. Tasarımın sonucu programcıların kod oluşturma aşamasında kullandıkları modellerdir.

Uygulama ve veri tasarımı için Borland, hem Borland hem de diğer üreticilerin (özellikle Microsoft) çeşitli geliştirme araçlarıyla entegre olan bir uygulama analizi ve tasarımı platformu olan Borland Together ürününü (Şekil 3) sunmaktadır. Bu ürün, uygulamaları ve verileri modellemenize ve tasarlamanıza olanak tanır; Dahası, şu anda geliştirme araçlarıyla entegrasyon derecesi öyledir ki, tıpkı koddaki değişikliklerin modellerde değişikliklere yol açması gibi, veri modelindeki değişiklikler de uygulama kodunda otomatik değişikliklere yol açar (bu teknoloji, modelleme araçlarını ve geliştirmeyi entegre etmek için kullanılır). araçlara LiveSource denir).

Borland Together, ürün gereksinimlerinin nasıl uygulanması gerektiğine dair fikir sağlamak için gereksinim yönetimi ve modelleme görevlerini geliştirme ve test görevleriyle birleştiren bir araç olarak kullanılabilir.

Uygulama kodu oluşturuluyor

Uygulama kodlama, Borland'ın varlığının son 20 yılı boyunca uzmanlaştığı bir alandır. Bugün Borland, Windows, Linux, Solaris, Microsoft .NET platformlarının yanı sıra çeşitli mobil platformlar için geliştirme araçları üretmektedir. Bu şirketin geliştirme araçları hakkında zaten birkaç kez yazdık ve bu yazıda kendimizi tekrar etmeyeceğiz. Yalnızca bu şirketin geliştirme araçlarının en son sürümlerinin (Borland C#Builder, Borland C++BuilderX, Borland JBuilderX) yanı sıra yakında piyasaya sürüleceğini not ediyoruz. yeni bir versiyonÜlkemizin en popüler geliştirme araçlarından biri olan Microsoft .NET Framework için Borland Delphi 8, Together modelleme araçları ve CaliberRM gereksinim yönetimi araçlarının geliştirme ortamlarıyla sıkı entegrasyonuna olanak sağlar. Dergimizin bir sonraki sayısında mutlaka ayrı bir yazımızda Delphi 8'den bahsedeceğiz.

Test ve optimizasyon

Test, kaliteli yazılım oluşturmanın kesinlikle gerekli bir bileşenidir. Bu aşamada, uygulamanın kendisi için formüle edilmiş gereksinimleri karşılayıp karşılamadığı kontrol edilir ve uygulama kodunda (ve çoğunlukla modellerde ve veritabanlarında) uygun değişiklikler yapılır. Test aşaması genellikle uygulama performans analizi ve optimizasyon araçlarının kullanılmasını gerektirir ve bu amaçla Borland Optimizeit Profiler kullanılır. Bugün bu ürün aynı zamanda Borland geliştirme araçlarının en son sürümlerinin geliştirme ortamlarına ve Microsoft Visual Studio .NET ortamına da entegre edilmiştir (Şekil 4).

Uygulama

Yazılım uygulaması proje başarısının en önemli bileşenlerinden biridir. Ürünün deneme çalıştırması aşamasında ciddi maliyet ve kayıplar olmadan üzerinde değişiklik yapılması ve güvenilirliği azaltmadan kullanıcı sayısını kolayca artırmanın mümkün olacağı şekilde yapılmalıdır. Günümüzün uygulama dağıtımları, farklı teknolojiler ve platformlar kullanan ve çok sayıda mevcut uygulamayı çalıştıran şirketleri içerdiğinden, yeni bir uygulamayı eski sistemlerle entegre etme yeteneği, uygulama sırasında önemli olabilir. Bu amaçla Borland, bir dizi platformlar arası entegrasyon teknolojisi sunmaktadır (örneğin, .NET uygulamalarının CORBA ve J2EE teknolojilerini temel alan uygulamalarla entegrasyonuna olanak tanıyan Borland Janeva).

Yönetimi değiştir

Uygulama oluşturmanın tüm aşamalarında değişiklik yönetimi gerçekleştirilir. Borland'ın bakış açısına göre bu, projenin en önemli bileşenidir; sonuçta gereksinimlerde, kodlarda ve modellerde değişiklikler meydana gelebilir. Değişiklikleri takip etmeden bir projeyi yönetmek zordur - proje yöneticisi bu aşamada tam olarak ne olup bittiğinin ve projede halihazırda neyin uygulandığının farkında olmalıdır, aksi takdirde projeyi zamanında tamamlayamama riskiyle karşı karşıya kalır.

Bu sorunu çözmek için, gerekli tüm verileri merkezi bir depoda saklayan ve uygulamadan sorumlu çalışanların etkileşimini optimize eden ölçeklenebilir bir yazılım konfigürasyon yönetimi aracı olan Borland StarTeam'i (Şekil 5) kullanabilirsiniz. çeşitli görevler. Bu ürün, proje katılımcılarından oluşan bir ekibe gereksinimleri yayınlamak, görevleri yönetmek, planlamak, çalışmak, değişiklikleri tartışmak, sürüm kontrolü ve belge akışını düzenlemek için çeşitli araçlar sağlar.

Bu ürünün özellikleri arasında diğer Borland ürünleriyle yakın entegrasyon, İnternet üzerinden etkileşim kuran dağıtılmış geliştirme ekiplerine destek, çeşitli türde istemci arayüzlerinin varlığı (Web arayüzü ve Windows arayüzü dahil), birçok platform desteği ve işletim sistemleri StarTeam'e dayalı çözümler oluşturmaya yönelik uygulama programı arayüzleri olan StarTeam Yazılım Geliştirme Kitinin (SDK), istemci ve sunucu tarafında veri koruma araçlarının, Merant PVCS Sürüm Yöneticisine ve Microsoft Visual SourceSafe depolarına erişim araçlarının varlığı, entegrasyon olan araçlar Microsoft Projesi, verileri görselleştirmeye, raporlar oluşturmaya ve karar almayı desteklemeye yönelik araçlar.

Bir sonuç yerine

Geliştirme araçları çok çeşitli projelerde yaygın olarak kullanılan tanınmış bir üreticinin yukarıdaki ürün grubunun Rusya pazarında görünmesi ne anlama geliyor? En azından, bugün yalnızca çeşitli proje katılımcıları için bir dizi araç değil, aynı zamanda gereksinimlerin tanımlanmasından uygulama ve bakıma kadar tüm geliştirme yaşam döngüsünün uygulanması için entegre bir platform elde edebileceğiz (Şekil 6). Aynı zamanda, bu platform, rakip ürün setlerinden farklı olarak, en popüler geliştirme araçlarının tümü için desteği garanti edecek ve bileşenlerini, kodun modeller, gereksinimler ve değişikliklerle tam senkronizasyonu düzeyinde bunlara entegre etmenize olanak sağlayacaktır. Ve umarız proje yöneticileri kendilerini ve çalışanlarını birçok sıkıcı ve rutin görevden kurtararak rahat bir nefes alırlar...

Yazılım geliştirme oldukça karmaşık bir iştir. Oldukça net bir şekilde tanımlanmış özelliklere sahip, kabul edilebilir kalitede tamamlanan, tahsis edilen bütçe dahilinde ve zamanında tamamlanan 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 geliştirme tam teşekküllü bir endüstri haline geldi; bunda tamamen belgelenmemiş olana yer yok. bireysel yaklaşım Bu nedenle, uygulama yaşam döngüsü yönetimi metodolojisinin ortaya çıkmasıyla dikkat çekici bir trendin ortaya çıkması doğaldır.

Tabii ki, yazılım geliştirme sürecinde yetenekli programcıların sanatına ve bir yazılım ürünü oluşturma süreçlerindeki diğer katılımcıların mesleki becerilerine yer vardır, ancak bugün bu aktivitenin bu aktivitede olduğu gerçeğini fark etmek önemli hale geldi. tutarsızlığa, belge eksikliğine ve bireyin isteklerine yer yoktur. Yazılım sistemleri endüstrisinde bu yüzyılın ilk on yılının en dikkat çekici trendlerinden biri ALM'nin (Uygulama Yaşam Döngüsü Yönetimi, ALM) ortaya çıkışıydı - uygulama yaşam döngüsü yönetimi .

Bu yaklaşım, bir yazılım ürününün oluşturulmasını bir iş süreci olarak görmeli ve döngüsel doğasını dikkate alarak, yönetim disiplinini geliştirmeye dahil etmelidir. ALM fikrine uygun olarak, herhangi bir yazılım çözümü üzerindeki çalışma, devreye alma aşamasında bitmez: sistem modernize edilir ve geliştirilir, yeni sürümleri yayınlanır ve bu sürümler, her seferinde uygulama yaşam döngüsünün bir sonraki turunu başlatır.

Forrester Research analistleri yazılım endüstrisi için ALM'yi ERP ile 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 hâlâ sınırlı kullanımda olduğunu ve pazarlarının hâlâ parçalanmış durumda olduğunu kabul ediyor. Piyasa gözlemcileri, bugün mevcut ALM tekliflerinden hiçbirinin, uygulama yaşam döngüsü yönetimi otomasyonunun tüm potansiyel faydalarını ve yeteneklerini tam olarak gerçekleştiremediğine inanıyor. Ancak güvenilir ve kaliteli yazılım oluşturmaya yönelik kontrollü, öngörülebilir, verimli süreçlere yönelik geliştirmelerin geliştirilmesine, bu süreçlerin otomatikleştirilmesi için uygun platformların ortaya çıkması eşlik edemez.

ALM çözümü 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ştiricilere yönelik geleneksel üretkenlik araçlarının çok ötesine geçer. Yazılım oluşturmak için ekip çalışmasına odaklanan yöntemler ve araçlar sağlamayı amaçlamaktadırlar. Uygulanabilir bir ALM çözümü oluşturmak için satıcıların "genişletilmiş" yazılım geliştirme ekibinin ihtiyaçlarını karşılaması ve ürünlerine daha geniş sürece katkıda bulunacak roller dahil etmesi gerekir.

BT uzmanı D. Chappell, ALM'nin genellikle yalnızca Yazılım Geliştirme Yaşam Döngüsü (SDLC) ile tanımlanan basit bir bakış açısına karşı uyarıda bulunuyor: başlatma, yinelemeli geliştirme döngüsü, ürün sürümü ve uygulama. ALM disiplini, uygulamalar gibi kurumsal bir kaynağın varlığının tüm yönlerini dikkate alarak daha geniş bir görev yelpazesini kapsar. D. Chappel'in tanımına göre, uygulama yaşam döngüsü, bir kuruluşun bu kaynağa şu ya da 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ü sonu 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

ABM, uygulamanın 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 gereksiz olduğuna dair 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ışmasını genişletmeyi ve bunun sonucunda temelde yeni yazılım ürünlerinin satın alınması veya oluşturulmasına ilişkin maliyetlerin azaltılmasını sağlamayı amaçlamaktadır.

İş ihtiyaç analizi

Öncelik ve yatırım

Wardlenne ShShDoiSh „Program izleme

Gelişim

Planlama

Yol gösterici kararlar

Düzeltme

hatalar

İzleme

ayar

uygulama yaşam döngüsü

Uygulamalar

Yazışma

Gereksinimler

Tekrarlandı

Islopkyvanis

Başlatma

geliştirme yinelemeleri

Teslimat

Hizmetten çıkarma

Serbest bırakmak

yatırım

Pirinç. 3.14. ALM modeli

D. Chappel, yaşam döngüsü resmini doğrusal bir resme genişletiyor ve ALM'nin üç ana alanını vurguluyor: yönetişim, geliştirme ve operasyonlar. Bu alanlara karşılık gelen süreçler, yeni bir uygulama fikrinin ortaya çıkmasından veya mevcut bir uygulamanın modernizasyonuna, yayılma aşamasına ve operasyonun tamamen tamamlanmasına kadar örtüşerek akar.

ALM'de yönetişim, uygulama yaşam döngüsü boyunca gerçekleşir ve karar verme ve proje yönetimiyle ilgili tüm süreç ve prosedürleri içerir. Buradaki asıl görev, uygulamanın belirli iş hedeflerini karşılamasını sağlamaktır ki bu da bu ALM bileşeninin önemini belirler. Yönetim süreçleri arasında, D. Chappel, geliştirme aşamasından önce gelen ayrıntılı bir yatırım teklifinin (gelecekteki bir uygulamayla ilişkili maliyetlerin, faydaların ve risklerin analizini içeren bir iş senaryosu) geliştirilmesini içerir; proje ve portföy yönetimine yönelik yöntem ve araçları kullanarak geliştirme yönetimi (Proje Portföy Yönetimi, PPM); kurumsal uygulama portföy yönetiminin bir parçası olarak çalışan bir uygulamanın yönetimi (Uygulama Portföy Yönetimi, AWS).

Uygulama geliştirme, bir fikrin tasarlanması ile bitmiş çözümün devreye alınması arasında gerçekleşir. Geliştirme süreçleri, uygulamanın modernleştirilmesi veya yeni sürümlerin yayınlanması gerektiğinde dağıtımdan sonra da uygulanır. Geliştirme, gereksinimlerin tanımlanmasını, tasarımını, kodlamasını ve test edilmesini içerir ve bunların tümü genellikle birden fazla yinelemede gerçekleşir.

Operasyon, çalışan bir uygulamanın, geliştirme bitiminden kısa bir süre önce planlanıp başlatılan ve imha edilene kadar devam eden izleme ve yönetme süreçlerini içerir. Operasyonel süreçlerin yazılım yaşam döngüsüne dahil edilmesi çok önemlidir: geliştirme ve operasyon ekipleri arasındaki silolar, kurumsal uygulamalardaki en acil sorunlardan biri olarak kabul edilir ve bunların ALM kullanılarak entegrasyonu, iş yazılımı kullanımının verimliliğini önemli ölçüde artırmayı vaat eder. Tek sorun, ALM ortamlarında bu tür bir entegrasyonun hala iyi bir hedef olarak kalması ve gerçek bir uygulama olmamasıdır.

ALM'nin pratikte anlatılan 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üşmüştür. İdeal bir ALM ortamı, tüm katılımcıları uygulama yaşam döngüsüne entegre eder, onlara ilgili kaynaklara ve görevlere tutarlı erişim sağlarken, her bir rolün bağlamını anlayıp onlara doğru araçları sağlar.

Uygun araçlarla desteklenmesi gereken ALM süreci katılımcısı rollerinin ve görevlerinin genişletilmiş listesi şunları içerir:

• üst düzey yöneticiler - proje portföylerini yönetin ve gösterge tablolarını kullanarak riskler ve ürün kalitesi dahil olmak üzere yazılım yaşam döngüsünün temel ölçümlerini kontrol edin;
• proje yöneticileri - projenin uygulanmasını planlayın ve kontrol edin, analiz edin olası riskler ve kaynak tahsisinden sorumludurlar;
• analistler - iş kullanıcılarıyla etkileşimde bulunur, bir yazılım ürünü için gereksinimleri belirler, gereksinimleri ve proje boyunca bunların değişikliklerini yönetir;
• mimarlar - model mimarisi yazılım sistemi işlevsel bileşenleri, verileri ve süreçleri de dahil olmak üzere;
• 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 yazın;
• Kalite departmanı mühendisleri - otomatik test araçlarının kullanılması da dahil olmak üzere testleri oluşturur ve yönetir, işlevsel, regresyon testlerini, performans testlerini gerçekleştirir;
• Operasyon personeli - uygulamayı izler, yönetir ve uygular geri bildirim ortaya çıkan sorunlarla ilgili olarak geliştirme ekibiyle;
• iş kullanıcıları - özel araçlar kullanarak gereksinimleri formüle edebilir, uygulama kusurlarını rapor edebilir ve yapılan değişikliklerin durumunu izleyebilir.

Ancak “geleneksel” ALM süreci, kuruluş için değer yaratma konusunda tam potansiyeline ulaşamamaktadır. Gerçek şu ki, birçok satıcı, müşterileri kapalı teknoloji platformlarına bağlamayı amaçlayan sınırlı uçtan uca ALM çözümlerini agresif bir şekilde pazara sürüyor. Müşteriler çok geçmeden bu çözümlerin mevcut geliştirme süreçleri, araçları ve platformlarıyla entegre olmadığını keşfederler. Ne yazık ki bu, geliştirme ekiplerinin ALM'nin farklı süreçleri ve veri karmaşasıyla sıkışıp kalmasına neden oluyor ve bu da onların ALM'nin tam potansiyelini fark etmelerini engelliyor.

Birleşik ALM yazılım ortamı, konfigürasyon ve değişiklik yönetimi ile yazılım sürümü kontrolüne dayalı olarak süreçlerin çalıştırılması ve yönetilmesi için 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 bunlara uyumu izlemenize, sıkı 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, kalite, üretkenlik ve geliştirme riskleri için bir ölçüm sistemi oluşturur, bu ölçümleri yaşam döngüleri boyunca takip edip analiz eder ve sonuçta oluşturdukları uygulamaların iş hedeflerini gerçekten karşıladığından emin olurlar.

Başlangıçta, ALM'nin önemini anlayan ve ürün stratejilerini açıkça destekleyecek şekilde değiştiren birkaç yenilikçiden bazıları Borland ve IBM Rational'dı. Bariz fırsatlara tepki gösteren diğer şirketler de 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 çözümü 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ştiricilere yönelik geleneksel üretkenlik araçlarının çok ötesine geçer. Yazılım oluşturmak için ekip çalışmasına odaklanan yöntemler ve araçlar sağlamayı amaçlamaktadırlar. Uygulanabilir bir ALM çözümü oluşturmak için satıcıların daha geniş yazılım geliştirme ekibinin ihtiyaçlarını karşılaması ve ürünlerine daha geniş sürece katkıda bulunacak roller dahil etmesi gerekir.

İlk ALM sistemlerinin ortak dezavantajı, hem tek bir üreticinin platformunda hem de çözümler içerisinde yaşam döngüsünün farklı aşamalarına yönelik modüllerin zayıf entegrasyonuydu. farklı tedarikçiler. Kapsamlı bir ALM platformundan yararlanamayan müşteriler, onları uçtan uca yaşam döngüsü süreç yönetimini manuel olarak uygulamaya zorlayan parça parça bir platform oluşturdular ve böylece ALM otomasyonunun büyük potansiyel faydasını boşa çıkardılar. Bu nedenle, ALM ortamlarını iyileştirmenin ana yönü olarak, dört yıl önce Forrester analistleri, yaşam döngüsündeki farklı rolleri desteklemek için ortak hizmetler sağlayacak, geliştirme eserlerinin tek bir fiziksel veya sanal deposunu kullanacak entegre ALM 2.0 platformlarının ortaya çıkacağını öngördü. mikro ve makro yaşam döngüsü süreçlerini yönetmiş, farklı rollere yönelik araçların tek ortamda entegrasyonunu sağlamış, yaşam döngüsünün farklı aşamaları için uçtan uca raporlama yeteneklerini desteklemiştir.

Günümüzde ALM için yeni gereksinimler ortaya çıkıyor ve bunda çevik geliştirme yöntemlerinin yaygın olarak benimsenmesi belirleyici rol oynuyor. Birkaç yıl önce, en ünlü hızlı Scrum yöntemlerinden birinin yaratıcısı D. Sutherland, hızlı geliştirme fikirlerinin yakında tamamen uyarlanacağını duyurdu. Bu abartı gibi görünse de tahminin doğru olduğu ortaya çıktı. Capgemini Group analistleri ve HP Software&Solutions tarafından 2010 yılında yapılan ortak bir araştırmaya göre, şirketlerin %60'ından fazlası halihazırda çevik geliştirme kullanıyor veya kullanmayı planlıyor ve Forrester anketi katılımcılarının yalnızca %6'sı hâlâ hızlı yöntemler aradıklarını itiraf etti. geri kalanların tümü bunları farklı derecelerde kullanıyor; %39'u uygulamalarının oldukça olgun olduğunu düşünüyor.

Geliştiriciler kısayollar kullanır ve ürünü üretime bırakır; bu, hızlı gelişimin gerçeklerini hesaba katmaz; bu, çalışan uygulamaların iş gereksinimlerindeki değişikliklere yanıt verme hızının ve bunun sonucunda işin esnekliğinin önünde ciddi engeller oluşturur. kendisi. Operasyon personelinin uygulama ortamında geliştiriciler tarafından yapılan değişikliklere yanıt vermedeki yetersizliği 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şamadan aşamaya aktarılan belgelerdeki eksikliklerle ilişkilidir ve daha genel olarak, geliştiriciler ve operasyon personeli arasında güvenilir ve otomatik bir iletişim kanalının bulunmaması. Bu sorun, veri merkezi yönetimine yönelik modern 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şımların yaygınlaşmasıyla birlikte daha da kötüleşiyor. Yüksek düzeyde otomatikleştirilmiş ve uygulamaları olabildiğince hızlı dağıtmak üzere tasarlanmış olan bu tür ortamlar, otomatikleştirilmiş bir iletişim kanalı olmadan ve geliştirme ile operasyon aşamaları arasında uçtan uca süreçler uygulanmadan değişikliklere yanıt veremeyecek.

Sorunun ciddiyetinin farkındalığı ve çözüm arama eğilimi, geliştirme ve operasyonlar arasındaki etkileşimi iyileştirmeye yönelik kavram ve teknolojileri ifade etmek için kullanılan yeni DevOps teriminin bile ortaya çıkmasına neden oldu. Analistler, bu fikirlerin uygulanmasına yönelik temel umutlarını, uygulama yaşam döngüsünün önemli aşamalarının entegrasyonunu teoride değil pratikte sağlayacak yeni nesil ALM ortamlarına bağlamaktadır. Bugün oluşturulan uygulamalar, çoğu durumda, farklı platformlar için farklı programlama dillerinde uygulanan bileşenlerin yanı sıra, hizmet ilkelerine dayalı olarak harici sistemlerin kodları ve eski çözümlerin birleştirilmesi ve entegre edilmesidir. Yaşam döngülerini yönetmek için ALM ortamının birden fazla geliştirme ortamını ve çalışma zamanı platformunu (NET ve J2EE gibi) desteklemesi ve ayrıca harici uygulama bileşenlerinin kaynak kodu, lisanslaması ve geliştirme durumu üzerinde kontrol sağlaması gerekir.

Analistler, Çevik süreçlerin yaygın olarak benimsenmesinin işaretleri arasında kuruluşların bu yöntemlere ilişkin ortodoksluktan uzaklaştıklarını belirtiyor. 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 etme ve operasyona kadar uçtan uca kalite yönetimi süreçlerinin otomasyonu, en önemli yöntemlerden biri haline gelebilir. güçlü kapsamlı ALM platformu.

Yazılım yaşam döngüsünün çeşitli aşamalarını destekleyen Rational ürün serisi her zaman genişliği ve modüllerin birbiriyle entegrasyonuna odaklanmasıyla öne çıkmıştır. Butler Group analistleri, IBM Rational Software and Systems Delivery çözüm paketini, uygulanan ALM bileşenlerinin çeşitliliği açısından pazardaki en eksiksiz çözüm olarak değerlendirdi. Bu paket, proje portföy yönetimi, model odaklı tasarım ve geliştirme, gereksinim yönetimi, konfigürasyon ve değişiklik yönetimi, kalite yönetimi, yapım ve yayın 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 Telclogic'in satın alınmasından sonra ortaya çıktı. IBM'in ALM ortamına dahil edilmeleri, yazılım ve sistem geliştirme süreçlerinin yakınsamasına ve bunlar için birleşik bir yaşam döngüsü yönetimi ortamının oluşturulmasına yönelik bir eğilimi yansıtıyor.

Ancak IBM'in ALM teknolojilerinin geliştirilmesine yaptığı en önemli katkı, entegre bir kurumsal uygulama yaşam döngüsü yönetimi platformunun uygulanmasına yönelik altyapıyı oluşturmaya yönelik uzun vadeli Jazz projesidir. Şu anda, Rational ailesinin bir dizi ürünü zaten Jazz platformuna entegre edilmiş durumda, başlangıçta Jazz temelinde çalışacak şekilde oluşturulan birkaç yeni çözüm piyasaya sürüldü ve gelecekte Jazz altyapısına destek sağlanacak. Rational serisinin tüm bileşenlerinde.

Jazz'ın özü, Jazz Team Server'ı ve bir dizi ek entegrasyon modülünü birleştiren Jazz Foundation platformudur. Jazz Team Server, ALM'nin yaşam döngüsünün farklı aşamalarına yönelik bileşenleri entegre etmesine yönelik yeni bir yaklaşım sergiliyor (Şekil 3.15). Geleneksel olarak böyle bir entegrasyon, bireysel ürünler arasında noktadan noktaya iletişime dayalıysa, Jazz, enstrümantal bileşenlerin birbirleriyle basit etkileşimini sağlayan (bir tür ALM Web) REST standardını temel alan açık bir dağıtılmış hizmet mimarisi uygular. RESTful arayüzü, çeşitli modüllerin verilerini ve işlevlerini hizmet olarak sunmanıza olanak tanır. Web standartlarına dayalı bir yaklaşım kullanmak, Jazz'ı yüksek düzeyde ölçeklenebilir hale getirerek platformu daha da kolaylaştırıyor evrensel çözüm Küçük ekiplerde ve büyük geliştirme ekiplerinde ALM görevlerini destekleyebilir.

Proje ve Ekip Yapısı

Olay bildirimi

Caz Takım Sunucusu

J * ;

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

" vakalarını kullanın ...... Öğe geçmişi eğilimleri

Kaynak kodunu oluşturur. Test senaryoları Test sonuçları

				Görsel stüdyo
Müşteri Platformu		Müşteri Platformu		Müşteri Platformu

Güvenlik ve Erişim

Pirinç. 3.15. Entegre kurumsal uygulama yaşam döngüsü yönetimi 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 hizmetler sağlar. Bunlar örneğin çözüm sürecinde çeşitli ekip üyelerinin etkileşimini sağlayan işbirliği hizmetleridir. ortak görevler Her bir özel ALM rolünün bağlamını dikkate alırken farklı yaşam döngüsü aşamaları arasındaki ilişkileri desteklemek. Caz tabanlı işbirliği araçları anlık mesajlaşmadan, uzun vadeli tartışma araçlarından, wiki'lerden ve diğer popüler Web 2.0 özelliklerinden yararlanır. Bu durumda, ekip üyeleri arasındaki tüm etkileşimler, bu etkileşimlerin kaynağı olarak hizmet veren yapıtlarla (örneğin kusurlar veya test senaryoları) bağlantılı olarak depolanan tasarım kaynakları olarak kabul edilir.

Jazz Foundation hizmetleri aynı zamanda Rational Unified Process ve çeşitli hızlı geliştirme seçenekleri de dahil olmak üzere çeşitli metodolojilere göre süreçleri tanımlamanıza ve yürütmenize olanak tanır. Bunu yapmak için, olayların bildirilmesi, belirli iş akışlarının yürütülmesinde ekip üyeleri arasındaki iletişimin desteklenmesi, kuralların belirlenmesi ve uygulanmasının kontrol edilmesi, temel görevlerin otomasyonu, işin farklı aşamalarına yönelik araçlar kullanılarak iş akışlarının organizasyonu için araçlar sağlıyoruz. yaşam döngüsü. Projenin durumu, sorunları ve riskleri hakkında kesin süreç ölçümlerinin sunulduğu ve bunların gerçek zamanlı da dahil olmak üzere 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 büyük önem verilmektedir. çeşitli seviyeler Bireysel süreç katılımcılarından ekip ve portföy yönetimi düzeyine kadar. 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 depo yer alır.

Jazz platformu, çeşitli görüş ve bakış açıları sunarak Eclipse geliştirme ortamıyla entegrasyon sağlar. Bazı Jazz bileşenleri aynı zamanda web istemcilerini de destekler. Jazz platformu Eclipse için iki önemli görünüm sunuyor: Team Central ve Team Artifacts. Her iki görünüm de bilgi toplamaya hizmet eder ve Jazz platformunun bileşenleri tarafından genişletilebilir. Eclipse tarafından geliştirilen Jazz platformunun bazı bileşenleri, kullanıcıların Jazz sunucusuna doğrudan bir web tarayıcısından erişmesine olanak tanıyor.

Jazz web kullanıcı arayüzü bu yeteneği sağlar. Bu arayüz, istemci bilgisayara herhangi bir özel yazılımın kurulmasını gerektirmediğinden, entegre geliştirme ortamından ziyade geçici veya ara sıra kullanıcılar için daha uygundur; tek ihtiyacınız olan bir web tarayıcısıdır. Her Jazz sunucusunun, kullanıcının bir proje alanı seçip oturum açabileceği bir ana web sayfası vardır. Kullanıcı oturum açtıktan sonra 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 ailesinin en dikkat çekici yeni ürünlerinden biri, Jazz temelinde çalışmak üzere özel olarak yaratılan, işbirliğini organize etmek ve yazılım yaşam döngüsü süreçlerini otomatikleştirmek için tamamen inşa edilmiş bir ürün seti olan Rational Team Conceit (RTC) sistemidir. Caz mimarisinde. IBM Rational Team Concert, birçok geliştiricinin üzerinde çalıştığı ç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, etkili etkileşimlerini düzenlemenize ve tasarruf etmenize olanak tanır en yüksek seviye Proje boyunca tüm proje faaliyetleri üzerinde kontrol.

RTC, yazılım konfigürasyon yönetimi, görev ve yapı yönetimi ile yineleme planlaması ve proje raporlaması sağlar, çeşitli türdeki geliştirme süreçlerini tanımlar ve yazılım yaşam döngüsünün tamamını desteklemek için diğer Rational ürünleriyle entegre olur. 2009 yılında IBM ayrıca, Jazz tabanlı bir test yönetimi portalı olan Rational Quality Manager'ı ve geliştirme projesi portföylerinin üst düzey yönetimi için tasarlanmış, Cognos analitik teknolojilerini kullanan Jazz platformu için 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ılmaktadır. Mevcut entegrasyonlar arasında aşağıdakilere dikkat edilmelidir.

• 1. İş emirlerini bu işlerden oluşturulan veya değiştirilen gereksinimlerle ve tam tersi gereksinimleri, bu gereksinimleri uygulamaya yönelik iş planlaması için oluşturulan işlerle ilişkilendirmenize olanak tanıyan İşbirlikçi uygulama yaşam döngüsü yönetiminin (CALM) bir parçası olarak IBM Rational Requirements Composer ile bütünleştirme .
• 2. İşbirlikçi uygulama yaşam döngüsü yönetiminin bir parçası olarak IBM Rational Quality Manager ile bütünleştirme; buna dayanarak, piyasaya sürülen yazılım ürünlerinin testleri sırasında gerçekleştirilen testlerin sonuçlarına dayalı olarak kusur izlemenin organize edilmesi mümkün hale gelir.
• 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. Belirtilen iki araç arasında sürüm oluşturma ve yapılandırma yönetimi yapıtlarını senkronize etmek için IBM Rational ClearCase ile bütünleştirme.

IBM Rational Team Concert'in temelini oluşturan açık Caz Entegrasyon Mimarisi, kuruluşta devreye alınabilecek ve aktif olarak kullanılabilecek 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 iş emirlerinin önceden tanımlanmış bir formattaki e-posta mesajlarına uygun olarak senkronize edilmesini sağlayan Fineco Soft şirketinin RTC Email Reader ürününün kullanılması olabilir. Aynı zamanda IBM Rational Team Concert'in yerleşik bildirim alt sistemi sayesinde ters senkronizasyon da mümkün oluyor.

Ayrıca, geliştirme ortamının (IDE) bu araçla doğrudan entegrasyonu olmasa bile, IBM Rational Team Concert'i temel alan sürüm oluşturma ve konfigürasyon yönetiminin hemen hemen her projede düzenlenebileceğini de belirtmek gerekir. Bu, sayesinde mümkün oldu paylaşım"kalın istemci" IBM Rational Team Concert ve entegre olmayan IDE. 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; büyük zorluklar ortaya çıkar.