개발방법론은 품질을 상향 평준화하고, 효율적으로 정보시스템을 분석, 설계, 구축, 테스트할 수 있도록 하는 절차, 산출물, 가이드, 기법, 도구들의 집합이다. 개발방법론에 일정과 담당자를 추가하면 WBS가 되므로, 개발방법론은 일하는 방법을 의미한다. 주 52시간 근무제도 도입에 따른 효율적 업무수행 방안(비효율 및 재작업 최소화)을 정하는데도 기준이 된다.

다수의 이해관계자가 참여하는 대형 차세대구축사업에서 개발방법론 중요성은 아무리 강조해도 지나치지 않다. 차세대구축사업을 수행하며, 개발방법론 측면에서 발생하는 위험 요인을 사전에 통제할 수 있는 7가지 노하우를 공유하고자 한다.

 

1. 개발 단계별 목표와 최종 Output정의 선행

분석, 설계, 구현, 테스트, 이행, 안정화 단계별 목표와 최종 Output을 정립하고, 해당 단계별 작성할 핵심 산출물을 정의한다. 

분석단계는 요구사항 정의, As-Is 업무와 시스템 이해를 목적으로 하며, 설계 모수가 도출되어야 한다. 분석단계에 설계 모수가 도출되지 않으면, 필요한 설계자수를 사전에 파악하기 어려워 공정 지연과 특정 설계자에 업무부하가 과중될 수 있다.

장기적으로 수행되는 대형 차세대구축사업의 특성상, 설계/개발자가 설계단계 중반에 과중한 업무에 지쳐 생산성이 떨어지고, 업무량 불평등에 따른 불만 증가로 프로젝트에서 조기 이탈이 발생할 수 있다.

설계단계는 요구사항을 충족하는 To-Be 화면, 데이터, 인터페이스, 어플리케이션 설계를 목적으로 하며, 개발모수를 산정할 수 있어야 한다.

개발자는 개발도중 단위테스트를 병행 수행하므로, 설계단계 단위테스트케이스가 정립되어 발주기관의 충분한 검토를 거쳐야 개발 품질을 확보할 수 있다.

개발단계는 설계에 따른 구현과 단위테스트를 목적으로 하며, 통합테스트시나리오가 작성 완료되어야 한다.

통합테스트 단계는 업무프로세스, 데이터 유형별 테스트를 통한 오류 검출을 목적으로 하며, 이를 통해 품질 향상을 도모한다.

2. 개발방법론 수행사에 선제적 제시

발주기관 자체 개발방법론이 존재함에도 불구하고, 좀 더 나은 개발방법론의 도입, 수행사에 익숙한 개발방법론 사용을 통한 생산성 향상 등의 이유로 대부분의 차세대구축사업에서 수행사의 방법론을 선택한다.

IT시장에서 개발방법론의 수준은 평준화되어 있고, 해당 사업의 특성을 발주기관에 더 잘 알기에 발주기관의 개발방법론이 더 효과적일 수 있다.
수행사 제시 개발방법론에는 응용시스템 특성 미반영, 사업 추진에 필요한 양식 누락, 산출물 양식별 중요 필드가 누락되는 경우가 자주 발생한다.

산출물 양식을 추가하거나, 양식에 필드를 추가하려고 하면, 설계자 및 개발자의 반대로 무산되거나 인고의 협의과정을 거쳐야 한다.

규모, 기간 등의 제약으로 인해 사업 초기에 개발방법론 전체 산출물, 양식, 가이드를 정립하지 못하고, 각 단계 시작전 정련할 수 밖에 없는데, 단계가 경과할수록 양식 및 양식에 필드 추가는 더욱 어려워 진다.

또한 해당 사업에 맞도록 수행사 기본 개발방법론 산출물을 테일러링하므로, 익숙함에 따른 설계자/개발자의 생산성 향상과도 거리가 있다.

설계자/개발자가 해당 산출물 작성전 산출물 양식, 가이드, Sample등이 정립되어 교육까지 완료되어야 하나, 해당 기간을 경과후 산출물 양식을 제공하여 공정지연을 초래하는 경우가 자주 발생한다.

효율적인 개발방법론 수립에는 공감하지만, 수행사 자체적으로 정리하는데 한계가 있다. 의도와 무관하게 업무량을 줄이려고 하는 것으로 비추어 질 수 있으며, 내부 감사, 외부 감리에 어필하기 어렵기 때문이다.

선행 컨설팅 사업(BPR/PI, ISP)의 결과물을 적극적으로 활용하여 효율적으로 분석 및 설계를 진행해야 한다. 선행 컨설팅 사업의 To-Be 업무프로세스설계서를 기반으로 기능 분류체계 및 통합테스트시나리오 작성에 활용하고, 선행컨설팅 사업에서 정의한 아키텍처를 기반으로 기본 아키텍처를 수립하도록 한다.

화면정의서 작성→화면설계서 작성 등 여러 번에 걸쳐 작업하는 공정은 분할 효과가 미흡하고, 산출물별 품질검토 기준도 모호하므로, 한번에 집중해서 작업해야 한다. 불필요하거나 필요 이상으로 많은 노력이 수반되는 산출물은 방법론에서 제거하거나 대체한다. 예를 들어, 유즈케이스정의서는 분석단계 가장 많은 시간과 노력을 수반하나, 소스코드 생성과 무관하고, 노력대비 효익이 미흡하므로, 화면설계서내 화면 사용법 필드를 추가하여 유즈케이스정의서의 기본흐름, 대안흐름을 기술하는 것을 권고한다.

그러므로 발주기관 주도로 적용할 개발방법론을 사전에 정립하여 수행사에 전달하고, 수행사 개발방법론 특성을 반영하여 최종 확정하는 방식이 좀 더 효과적이다. 객관성과 전문성이 염려된다면, PMO 도입을 통해 사업 착수전 개발방법론을 정립하는 방안도 고려할 수 있다.

정립된 개발방법론은 수행사에 전달하여 착수전 준비할 수 있도록 한다.

 

3. 산출물 양식내 산출물 검토 체크리스트를 포함하여 품질강화

수행사내 품질조직이 운영되고 있는 경우에도, 품질검토 활동이 미흡한 경우가 자주 발생한다. 품질검토를 수행하더라도, 산출물 양식 사용여부만 검토하여 실질적인 품질 향상 기여에는 미흡한 경우도 자주 있다.

따라서, 산출물 양식별 산출물 검토 체크리스트를 추가하여 작성자가 참고하도록 하고, 수행사 품질조직에서 품질 자정(自淨) 활동을 수행하도록 한다.

4. 산출물 양식내 산출물간 연관관계를 정의하여 일관성 및 연관성 확보

정보시스템은 화면→비즈니스모듈→DB까지 일련의 과정을 거치도록 구성되어 있으나, 설계서에 각 단위 관점(화면, 데이터, 인터페이스, 배치프로그램, 온라인프로그램)만 반영하여 산출물간 연관성이 정의되지 않으면, 설계자의 바톤(baton)을 이어받은 개발자가 응용시스템을 개발하기 어렵게 된다.

화면, 데이터, 인터페이스, 배치프로그램, 온라인프로그램 목록과 상세 설계서간 ID 일관성을 점검하고, SW아키텍처 Layer별 관련 설계서간 일관성 및 연관성 측면에서 검토할 수 있도록 양식을 구성하여 품질을 향상시켜야 한다.

단계말 검토시 산출물간 일관성이 유지되는지 집중 검토해야 한다.
 

5. 화면부터 설계하여 요구사항 조기 확정

전문 기법을 사용하는 UML모델, 데이터모델을 발주기관이 검토하는데 한계가 존재하며, 발주기관의 Feedback이 없으면 구현시 재설계가 발생하게 된다. 발주기관에게 익숙하고, 품질을 직관적으로 파악할 수 있는 영역은 화면이며, 화면설계서의 화면 Layout 정의시, 필요한 입/출력 데이터, 버튼 클릭시 호출하는 온라인프로그램의 오퍼레이션 등이 정의되므로, 화면부터 설계하면, UML모델, 데이터모델의 재작업을 줄일 수 있다.

정보시스템 구축 과정에서 현업을 배제하고 IT부서 주도로 추진하는 경우, 신규 구축된 시스템에 대한 사용자 만족도가 떨어지고, 사용에 익숙해지는데 많은 시간이 소요된다.

화면 설계시 현업을 참여시켜 UI 구성에 대해 Feedback을 받아 설계를 완료하고, UI 정립을 통해 기능 및 요구사항을 조기에 확정하여 설계 재작업을 최소화해야 한다.
 

6. 설계, 개발도구에서 산출물을 추출하여 실시간 산출물 현행화 체계 구축

발주기관은 운영단계 설계문서 현행화가 안되어, 관리/운영 담당자의 교체, 유지보수 업체 변경시, 정보시스템의 구조를 파악하기 어려운 애로사항을 공통적으로 가지고 있다.

품질을 강화한 개발방법론을 정의하고, 구축사업에서 준수하여도 정보시스템 운영시 현행화가 안되면 해당 산출물은 무용지물이 된다. 따라서, 설계, 개발도구에서 산출물을 직접 추출하여 산출물과 소스간 일원화 체계를 구축해야 한다.

UI 설계는 도입할 UI 개발도구를 활용하여 정립하고, 화면 주석으로 처리절차, 입출력 정보 등을 기술하여 화면에서 설계서를 추출할 수 있도록 한다. 시장 점유율이 높은 UML모델링, 데이터모델링, UI 도구들에는 이미 해당 기능이 포함되어 있으므로, 해당 제품을 고려하여 도입하고, 그외 산출물은 제안요청서에 관련 도구의 커스터마이징 요건을 제시하여 산출물을 자동 추출할 수 있도록 체계를 구축한다.

설계시 활용할 수 있으면 금상첨화지만, 사후 산출물 추출만 가능해도 운영시 효과가 높다. 

7. 현황분석시 개선유형 및 개선방향을 포함하여 설계 누락 방지

재구축 사업에서 현황분석은 화면, 데이터, 인터페이스, 배치프로그램, 온라인프로그램 별 현행유지, 개선, 폐기 대상을 선별하여 To-Be 설계에 반영되어야 한다. 하지만, 개별 목록만 정의하여 설계 방향을 못잡는 경우가 다수 발생한다.

현황분석 시 화면, 데이터, 인터페이스, 배치프로그램, 온라인프로그램별 개선유형과 개선방향을 기술할 수 있도록 산출물 양식을 정립한다. 화면은 UI측면의 개선유형과 기능측면의 개선유형을 구분하여 정의하고, UI측면의 개선유형만으로 To-Be 화면Layout을 빠르게 설계할 수 있도록 한다.

As-Is 현황시스템분석서의 개선유형중 유지, 개선이 To-Be 설계서(화면, 데이터, 인터페이스, 배치프로그램, 온라인프로그램)에 누락없이 반영되었음을 확인하기 위해 As-Is ID를 포함하여 품질을 강화해야 한다.