우리는 매우 유용하고 강력한 소프트웨어 모음을 보유한 작고 매우 전문화 된 혜택 관리 회사로, 일부는 COBOL로 작성되었지만 대부분은 BASIC으로 작성되었습니다. 두 명의 상근 컨설턴트가이 시스템을 30 년 이상 유지 관리하고 개선했습니다. 물론 곧 은퇴 할 것입니다. (그들 중 하나는 몇 년 동안 은퇴하기 위해 필사적이지만 결점에 충성하기 때문에 남편의 주장에도 불구하고 골프가 우선 순위를 갖습니다.)

우리는 우리가 사용하는 소프트웨어 유형을 제공하는 국가 3 곳 중 한 곳에서 개발 한 시스템으로 전환하는 과정을 시작했습니다. 우리는 비록이 회사가 이론적으로 변환 프로세스를 완료 할 수는 있지만, 적시에 할 자원이 없으며, 그들이 운영해야하는 서비스를 제공 할 수 없을 것이라고 믿게되었습니다. 우리 사업. (자신의 우선 순위를 정하고 자신의 자원을 적절하게 할당 할 권한을 갖는 것과 같은 것은 없습니다.)

하드웨어는 문제가되지 않습니다. 최신 서버에서 매우 효과적으로 에뮬레이션 할 수 있습니다. COBOL과 BASIC이 현대 언어라면 현재 컨설턴트의 대체물을 찾을 수있는 위험을 감수 할 것입니다.

이와 같은 레거시 플랫폼에 집중하고 우리와 같은 시스템을 지원할 수있는 프로그래밍 및 소프트웨어 개발 인재를 제공하는 IT 지원 회사의 비즈니스 모델이 있어야 할 것 같습니다. 젊은 프로그래머들에게 BASIC과 같은 오래되고 섹시하지 않은 언어로 생산적이고 보람있는 경력을 쌓을 수 있도록 설득하는 일.

요컨대, 비 IT 관리자로서이 전환을 어떻게 가장 잘 관리 할 수 ​​있습니까?

"이와 같은 레거시 플랫폼에 중점을 둔 IT 지원 회사의 비즈니스 모델이 있어야 할 것 같습니다." 떨어졌다.

오래된 환경에 갇혀있는 것은 앞으로 나아가는 길이 아닙니다. 그리고 나는 지금까지는 당신이 분명히 할 수없는 일을 기꺼이 할 회사를 찾는 것에 갇히지 않으려는 회사의 삶에 베팅하지 않을 것입니다.

따라서 실제로 요청한 질문에 대한 답은 아니지만 마이그레이션의 위험을 최소화하면서 앞으로 나아갈 수있는 방법에 대한 진지한 조언이 있습니다.

"신성함을 잃지 않은 채 재 작성하는 방법"

오랫동안 실제 결과가없는 긴 마이그레이션 프로젝트의 오류를 만들지 마십시오. 읽기 "어떻게 정신을 잃고 wihtout 지상 최대 재 작성을 살아 남기 위해"

나는 그 기사의 조언이 그런 종류의 프로젝트를 "오래된"방식으로 수행 한 후에 비슷한 문제를 해결 / 접근하는 데 어떻게 도움이되었는지 충분히 강조 할 수 없다.

자동 테스트 설정

아직 설치하지 않은 경우 (그렇지 않은 이유는 무엇입니까?) 현재 프로그래머에게 응용 프로그램에 대한 자동화 된 테스트 장치를 만들도록하십시오.

자동화 된 테스트 스위트는 애플리케이션의 모든 기능 영역을 포함해야합니다. 개별 테스트 사례의 "when_X_then_Y"규칙에 현재 작업 사양을 문서화해야합니다. 이를 통해 현재 코드의 변경 사항이 기존 기능을 중단하지 못하게하고 새로운 환경으로의 마이그레이션을 지원할 수 있습니다.

COBOL 및 BASIC을 처리 할 때 테스트 스위트는 통합 테스트 레벨에 있어야합니다. "고정 된"입력 파일 / 데이터베이스 세트를 작업하고 출력 파일 / 특정 프로그램 (COBOL)의 변경된 데이터베이스 내용을 확인하고 응용 프로그램. 소프트웨어의 기본 부분의 경우 이는 명령 줄 매개 변수를 추가하여 (G) UI 개입없이 특정 기능을 수행하거나 (G) UI 기반 자동 테스트 도구를 얻는 것을 의미 할 수 있습니다.

계산 및 기타 알고리즘 분리

Cobol조차도 메인 프로그램에서 호출 할 수있는 서브 프로그램의 개념을 지원합니다. 모든 가져 오기 계산 및 기타 알고리즘을 별도의 프로그램 또는 모듈로 분리하십시오. 목표는 입력을 수집하고 출력을 생성하는 모든 것으로부터 분리 된 거친 작업을 수행하는 프로그램 / 모듈 라이브러리를 만드는 것입니다.

테스트 하네스를 조정하여 이전 응용 프로그램과 격리 된 응용 프로그램을 통해 테스트 할 수 있습니다. 이렇게하면 새로운 환경으로 쉽게 마이그레이션 할 수 있도록 "이전"코드에서 수행하는 작업에 최대한 적은 오류가 발생합니다.

"현재"환경에서 새로운 애플리케이션 세트를 시작하십시오.

현재 코드를 변환하지 마십시오. 한 언어를 다른 언어로 변환한다는 것은 이전 환경의 제약 조건을 새로운 언어에 적용하는 것을 의미합니다. 종종 바람직하지 않은 경우 결과 (읽기 : 결과는 끔찍하고 유지하기가 어려울 것입니다). 이주하십시오. 새로운 환경에서 해당 환경에 가장 적합한 방법으로 응용 프로그램을 설정하십시오.

선택한 환경에 정통한 새로운 프로그래머를 확보하십시오. 모든 중요한 계산 및 알고리즘을 별도의 클래스 및 / 또는 패키지로 분리하여 인터페이스 뒤에 숨기려면 하루를 최우선으로해야합니다. 의존성 주입 (가장 저렴한 DIY 의존성 주입 방식)을 사용하여 계산을 수행하기 위해 인스턴스화 / 사용할 클래스를 새 응용 프로그램에 알리십시오.

이것은 어쨌든 작업을 수행하는 좋은 방법이며 귀하의 경우 중요한 부분을 사례별로 마이그레이션 할 수 있습니다. 또한 새로운 환경에서 호출 기능에서 기본 및 / 또는 코볼 프로그램 호출의 복잡성을 숨길 수 있습니다.

응용 프로그램을 설정하고 COBOL / BASIC "라이브러리"의 계산을 사용하는 가장 중요한 입력 / 출력 기능을 설정하는 것은 더 이상 진행하지 마십시오.

COBOL / BASIC "라이브러리"통합

새로운 환경에서 COBOL / BASIC "라이브러리"를 호출하는 방법을 알아보십시오. 여기에는 매개 변수 파일 또는 데이터베이스 테이블 설정, 이전에 설정 한 COBOL / BASIC 라이브러리를 랩핑하는 COBOL / BASIC 프로그램 실행이 포함될 수 있습니다. 운이 좋으면 BASIC 버전에서 직접 호출 할 수있는 DLL을 만들 수 있습니다.

COBOL / BASIC "라이브러리"라고하는 새 환경에서 클래스를 구현하고 이전 환경의 테스트 하니스와 동일한 테스트를 사용하여 새로운 환경에서 단위 테스트 형식으로 테스트합니다. .

그렇습니다. 이것은 테스트를 "복제"한다는 의미입니다. 그러나 이것이 없이는 원하지 않는 안전망입니다. 이러한 단위 테스트가 나중에 새 환경으로 마이그레이션 될 때 계산 및 알고리즘의 구현을 확인하는 테스트 역할을하기 때문입니다.

그러나 다시 : 이전 단계에서 가장 중요한 단일 단위에 사용 된 계산에 대한 단위 테스트를 추가하는 것 이상으로 진행하지 마십시오.

반복적으로 새로운 애플리케이션을 구현

이전 응용 프로그램의 모든 기능에 대해 이전 두 단계를 반복하여 새 응용 프로그램을 정리하십시오. 계산을 확인하는 단위 테스트를 새 애플리케이션의 테스트 하니스에 계속 추가하십시오. 통합 테스트 스위트를 사용하여 마이그레이션 된 기능이 이전 애플리케이션과 동일한 기능을 수행하는지 확인하십시오.

핵심 라이브러리를 반복적으로 마이그레이션

마지막으로 COBOL / BASIC "라이브러리"에서 계산 및 알고리즘을 마이그레이션하여 새 환경에서 다시 구현하십시오. 다시 말하지만, 정신 건강을 유지하기 위해 (단위) 테스트를 반복적으로 사용하십시오.

이 응용 프로그램이 귀하의 비즈니스에 "핵심"인 것 같습니다. 시스템이나 프로세스가 귀하의 비즈니스 인 경우, 사용자 정의 솔루션을 보유해야합니다.

당신은 이것을 암시했습니다. 불행히도 기술을 업데이트 한 후 오랜 시간이 걸린다면, 이는 매우 어려운 일입니다.

두 경로 중 하나를 추천합니다.

1. 위의 기술적 인 답변에 명시된대로 IT 개발자 / 프로젝트 관리자 / QE / 운영 팀을 구성하고 점진적으로 시스템을 구축하십시오. 그러나 이것은 매우 비쌀 것입니다.
2. 기성품 제공 업체가 아닌 자격을 갖춘 맞춤형 개발자 컨설턴트를 찾으십시오. 이 그룹은 새로운 시스템을 구축하기 위해 모든 리소스를 처리 한 다음 옵션 1보다 작은 직원을 통해 사내로 가져와 계속 진행할 수 있습니다. 이 옵션에는 다른 위험이 있지만, 비전문가에게는 좋은 공급자를 선택하는 것이 매우 어려울 수 있습니다. 또한 비용 초과 등으로 인해 위험이 매우 높아질 수 있습니다.이 경로를 완화하려면 기존 직원을 사용하여 입찰에 대한 매우 상세한 요구 사항을 설정하십시오 (사용자 관점에서). 그런 다음 고정 가격 입찰도 요청하십시오.

행운을 빕니다. 극복해야 할 유산은 약 20 년입니다. 싸거나, 쉬워 지거나, 깨끗하지 않을 것입니다.

레거시 소프트웨어를 유지할 회사를 찾거나 레거시 소프트웨어를 다시 작성할 회사를 찾는 대신 지속적인 혜택 관리 시스템 서비스를 제공 할 회사를 찾으십시오. 소프트웨어 재 작성 여부, 설정 일정, 사용할 언어 또는 도구를 결정하는 문제를 아웃소싱하십시오.

그렇습니다.이 접근법의 명백한 비용은 새로운 프로그래머를 고용하는 데 드는 명백한 비용을 초과 할 수 있습니다. 그러나 귀하의 입장에 따라 귀하는 비 IT 관리자이며 궁극적으로 회사보다 비용이 많이 드는 결정을 내리는 시나리오를 쉽게 예측할 수 있습니다. 아웃소싱의 명백한 비용.