Biz, bazıları COBOL'da yazılan, ancak çoğu BASIC'de olan, son derece kullanışlı, sağlam bir yazılım koleksiyonuna sahip, küçük, çok uzmanlaşmış bir fayda yönetim firmasıyız. İki tam zamanlı danışman, bu sistemi 30 yıldan fazla bir süredir ustalıkla sürdürdü ve geliştirdi. Tabii ki yakında emekli olacaklar. (Biri birkaç yıldır emekli olmak için umutsuzdu, ancak bir hataya sadık ve kocasının golfün öncelik alması gerektiğine dair ısrar ediyor.

Ülkede kullandığımız yazılım türünü sunan sadece üç firmadan biri tarafından geliştirilen bir sisteme geçme yolunu başlattık. Artık bu firma teorik olarak dönüşüm sürecini tamamlayabilmesine rağmen, zamanında yapacak kaynaklara sahip olmadıklarını ve yürütmemiz gereken türde bir hizmet sunamayacaklarına inanmaya başladıklarını düşünüyoruz. işimiz. (Kişinin kendi önceliklerini belirleyebilmesi ve kaynaklarını uygun gördüğü şekilde tahsis etme yetkisine sahip olması gibi bir şey yoktur.)

Donanım bir sorun değil - modern sunucularda çok etkili bir şekilde taklit edebiliyoruz. COBOL ve BASIC modern diller olsaydı, ileriye dönük mevcut danışmanlarımızın yerini alabileceğimiz riskini almaya istekli olurduk.

Bu gibi eski platformlara odaklanan ve bizimki gibi bir sistemi desteklemek için programlama ve yazılım geliştirme yeteneği sağlayan, doğru programlama yeteneğini bulma risklerini ortadan kaldıran bir BT destek firması için bir iş modeli olmalı gibi görünüyor. genç programcıları, kısmen BASIC gibi eski, seksi olmayan bir dilde üretken, ödüllendirici bir kariyere sahip olabileceklerine ikna etme işi.

Kısacası, BT dışı yöneticiler olarak, bu geçişi en iyi nasıl yönetebiliriz?

Görünüşe göre "böyle eski platformlara yoğunlaşan bir BT destek firması için bir iş modeli olmalı", ama kişisel olarak bunun, karşılaştığınız zorlukları bir arada çözeceği için sizin tarafınızdan düşünmek olduğunu düşünüyorum. düştü.

Eski ortamlarda takılı kalmak, ilerlemenin yolu değildir. Ve ben hiç kimse için, görünüşe göre yapamayacağınız şeyi yapmaya istekli olacak bir firma bularak sıkışıp kalmaya çalışırken hiçbir şirketin hayatına bahse girmeyeceğim.

Öyleyse sorduğunuz asıl soruya bir cevap değil, bir göç riskini en aza indirirken nasıl ilerleyebileceğiniz konusunda samimi tavsiyeler.

"Akıl sağlığınızı kaybetmeden sıfırdan nasıl yeniden yazılır?"

Uzun süredir gerçek sonuçları olmayan uzun bir göç projesinin hatasını yapmayın. Oku "Nasıl akıl sağlığını kaybetme wihtout yerden yukarıya doğru yeniden yazmak hayatta"

Bu makaledeki tavsiyenin, bu tür projeleri "eski" şekilde yaparken kendimi yaktıktan sonra benzer sorunlarla başa çıkma / yaklaşma konusunda bana nasıl yardımcı olduğunu yeterince vurgulayamıyorum.

Otomatik testler ayarlama

Henüz yerleştirmediyseniz (neden hiç olmadı?), Mevcut programcılarınızın uygulamalarınız için otomatik bir test takımı oluşturmasını sağlayın.

Otomatik test paketi, uygulamalarınızın tüm işlevsel alanlarını kapsamalıdır. Mevcut çalışma şartnamelerini ayrı ayrı test senaryolarının "when_X_then_Y" kurallarında belgeleyecektir. Bu, hem mevcut kodunuzdaki değişikliklerin mevcut işlevselliği bozmasını önlemeye hem de yeni bir ortama geçişi desteklemeye yardımcı olacaktır.

COBOL ve BASIC ile uğraşırken, test paketi muhtemelen entegrasyon testleri düzeyinde olmalıdır: "sabit" girdi dosyaları / veritabanları kümesi üzerinde çalışmak ve belirli programların çıktı dosyalarını / değiştirilmiş veritabanı içeriğini (COBOL) kontrol etmek ve / veya uygulamalar. Yazılımınızın BASIC bölümleri için bu, (G) UI müdahalesi olmadan belirli işlevleri kullanmalarını sağlamak için komut satırı parametreleri eklemek veya (G) UI tabanlı otomatik test aracı almak anlamına gelebilir.

Hesaplamaları ve diğer algoritmaları ayırın

Cobol bile ana programdan çağrılan alt programlar kavramını destekler. Tüm içe aktarma hesaplamalarını ve diğer algoritmaları ayrı programlarda veya modüllerde ayırın. Amaç, girişleri toplayan ve çıktı yaratan her şeyden izole edilen homurdanma işi yapan her türlü program / modül / kütüphane oluşturmaktır.

Test kayışını hem eski uygulamalarınızda hem de izolasyonda test etmek için uyarlayın. Bu, daha yeni bir ortama geçişi kolaylaştırmak için "eski" kod üzerinde yaptığınız çalışmanın mümkün olduğunca az hata getirmesini sağlayacaktır.

"Geçerli" bir ortamda yeni bir uygulama grubu başlatın

Mevcut kodunuzu dönüştürmeyin. Bir dili başka bir dile çevirmek, eski çevrenin kısıtlarını yeniye dayatmak anlamına gelir. Sonuç genellikle istenenden azsa (okuyun: sonuç korkunç olacak ve sürdürülmesi gereken bir acı olacaktır). Göç. Uygulamalarınızı yeni ortamda, o ortam için en iyi uygulama olarak kabul edilecek şekilde ayarlamak için zaman ayırın.

Seçtiğiniz ortamda çok deneyimli yeni programcılar edinin. Ayrı sınıflarda ve / veya paketlerdeki tüm önemli hesaplamaları ve algoritmaları ayırmayı ve bunları arayüzlerin arkasına gizlemeyi ilk günden itibaren bir öncelik haline getirin. Yeni uygulamanıza hesaplamaları yapmak için hangi sınıfların örnekleneceğini / kullanılacağını söylemek için bağımlılık enjeksiyonu kullanın (en ucuz DIY bağımlılık enjeksiyonu yapılacaktır).

Bu zaten her şeyi yapmanın iyi bir yoludur ve sizin durumunuzda bu önemli kısımları her duruma göre taşımanıza izin verecektir. Ayrıca, temel ve / veya kobol programlarının çağrılmasının karmaşıklığını yeni ortamdaki çağrı işlevlerinden gizleyecektir.

Uygulamaları kurmaya ve belki de COBOL / BASIC "kütüphanenizden" bir hesaplama kullanan en önemli giriş / çıkış işlevini ayarlamaya devam etmeyin.

COBOL / BASIC "kütüphanenizi" entegre edin

Yeni ortamınızdan COBOL / BASIC "kütüphanenizi" nasıl arayacağınızı öğrenin. Bu, daha önce ayarladığınız COBOL / BASIC kütüphanesini saran bir COBOL / BASIC programının yürütülmesini, parametre dosyalarının veya veritabanı tablolarının ayarlanmasını içerebilir. Şanslıysanız, BASIC sürümünüz doğrudan çağrılabilen DLL'lerin oluşturulmasına izin verebilir.

Sınıfı COBOL / BASIC "kütüphane" olarak adlandıracak yeni ortamınıza uygulayın ve eski ortamın test koşumundaki aynı testleri kullanarak, ancak şimdi yeni ortamdaki birim testleri biçiminde halkı test edin. .

Evet bu, testleri "çoğaltmak" anlamına gelir, ancak onsuz yapmak istemediğiniz bir güvenlik ağıdır. Sadece bu birim testleri daha sonra yeni ortamınıza taşınırken hesaplamalarınızın ve algoritmalarınızın uygulanmasını kontrol etmek için testler olarak işlev görecektir.

Ama yine: bir önceki adımdan en önemlisi tarafından kullanılan hesaplama (lar) için birim testleri eklemekten başka bir şey yapmayın.

Yinelemedeki yeni uygulamaları ortaya çıkarın

Eski uygulamalarınızdaki tüm işlevler için önceki iki adımı tekrarlayarak yeni uygulamaları silin. Hesaplamaları kontrol eden birim testlerini yeni uygulamalarınızın test kayışına eklemeye devam edin. Taşınan işlevlerin eski uygulamalarınızla aynı şekilde çalışıp çalışmadığını kontrol etmek için entegrasyon test paketini kullanın.

Çekirdek kütüphaneyi yinelemelerde taşıma

Son olarak, COBOL / BASIC "kitaplığınızdaki" hesaplamaları ve algoritmaları taşıyarak yeni ortamınıza yeniden uygulayın. Yine, bunu (birim) testlerini akıl sağlığınızı korumanın bir yolu olarak tekrarlayarak yapın.

Bu uygulama işinize "çekirdek" gibi geliyor. Bir sistemin veya sürecin işiniz IS olduğu durumlarda, kendi özel çözümünüz için bir durum söz konusudur.

Bunu ima ettin. Maalesef, teknolojilerinizi güncelledikten bu yana uzun zaman geçirdiyseniz, bu son derece zor bir girişim olacaktır.

İki rotadan birini tavsiye ederim.

1. Yukarıdaki teknik cevapta belirtildiği gibi, bir BT geliştirici grubu / proje yöneticisi / QE / operasyonları oluşturun ve sisteminizi kademeli olarak oluşturun. Ancak bu son derece pahalı olacaktır.
2. Hazır bir sağlayıcıdan ziyade, kalifiye bir özel geliştirici danışmanı arayın. Bu grup, yeni sisteminizi oluşturmak için tüm kaynakları kullanacak, daha sonra devam etmek için seçenek 1'den küçük bir kadroyla evinize getirebilirsiniz. Bu seçeneğin farklı bir risk grubu vardır, ancak iyi bir sağlayıcı seçmek teknik olmayanlar için çok zor olabilir. Ayrıca maliyet aşımları vb. İle çok yüksek risk altında olabilirler. Bu rotayı hafifletmek için, mevcut personelinizi teklifiniz için çok detaylı bir gereksinim kümesi (kullanıcı perspektifinden) oluşturmak için kullanın. Ardından sabit fiyat teklifleri isteyin.

İyi şanslar, üstesinden gelmek için yaklaşık 20 yıllık mirasınız var. Ucuz, kolay veya temiz olmayacak.

Eski yazılımınızı koruyacak bir firma veya eski yazılımınızı yeniden yazacak bir firma aramak yerine, sürekli fayda yönetim sistemi hizmeti sağlayacak bir firma arayın. Yazılımın yeniden yazılıp yazılmayacağına, hangi programın ayarlanacağına, hangi dillerin veya araçların kullanılacağına karar verme sorunlarını dış kaynaklardan yararlanın.

Evet, bu yaklaşımın bariz maliyetleri, yeni programcıları işe almanın bariz maliyetlerini aşabilir, ancak kendi girişinizle BT yöneticisi olmayan bir kişisiniz ve şirketinize nihayetinde maliyetten daha fazla karar verdiğiniz senaryoları öngörmek kolaydır. dış kaynak kullanımının bariz maliyetleri.