IT 프로젝트 이해 관리 4

< 오픈 및 검수 단계 관리 >

오픈 및 검수 단계 개념

→ 오픈은 IT 시스템 개발 완료 단계에서 최종적으로 시스템을 고객에게 열어주고 관리하는 단계

-      오픈

n  시스템을 고객이 사용할 수 있도록 만드는 것

-      안정화

n  서비스 오픈 이후, 발생하는 다양한 문제에 대해서 대응 - 오류 수정, 성능 보완, 기능 개선

-      검수

n  고객사의 시스템 구축 시, 시스템 구축 완료를 확인 받는 것

n  검수 확인서에 도장을 찍음으로 완료

n  검수 개념

- 검수 확인서 작성

      ▪ 구축된 시스템의 기능이 정리된 검수 확인서 작성 - 별도 설명

- 검수 진행

                       ▪ 검수 확인서 기준 고객이 실제 기능이 완료된 부분 최종 점검

- 최종 검수 확인

      ▪ 고객의 기능 점검이 완료되면, 검수 확인서에 날인을 함으로 완료

▪ 검수 확인 의미 - 시스템 구축팀의 철수 가능 및 잔금 청구 기준

-      유지보수

n  시스템 구축 완료 이후 사후 관리

n  다양한 계약 방식 존재

ex1) 구축비 15%, 안전한 운영

ex2) 인력 계약, 운영 + 추가 개발

n  오픈 유지 보수 방법

-      배포 진행

n  서버 배포: 운영 서버에 실제 프로그램 최종 결과물을 설치하는 것

- 즉시 서비스 운영이 가능함

- 네트워크 상의 문제가 없도록 사전 체크 필요

n  APP 배포: 안드로이드 & iOS 앱스토어에 앱을 등록하고, 등록된 앱을 오픈 하는 것

- 앱스토어 등록 심사/승인은 사전에 받아야 함            # 2주정도 여유 가져야함

- 오픈 일에 맞춰, 승인이 완료된 앱을 오픈 해줄 수 있음

 

오픈 및 안정화 방법

→ 최종 개발 준비가 된 시스템을 사용자가 이용할 수 있도록 열기 위한(Open) 준비 및 오픈 이후 안정화

1.    전환 계획

▪ 기존 시스템의 정보를 신규시스템으로 전환 (신규 오픈이 아닌 경우에만 해당)

- 기존의 시스템을 중지

- 신규시스템으로 데이터 전환 이관

- 이관 데이터 검증

           - 데이터 전환 3단계: 리뉴얼이나 차세대와 같은 오픈 과정에서 반드시 필요

1.     1차 전환

▪ 최초 데이터 전환을 진행

▪ 이 과정에서 데이터 전환의 방법을 정리하고 데이터 전환 과정에 발생하는 많은 문제점을 해결

▪ 이와 함께 데이터 전환에 걸리는 시간을 확인

▪ 전환에 대한 시나리오를 작성

2.     2차 전환

▪ 1차 전환에서 작성된 시나리오를 기반으로 전환 시작

▪ 2차 전환 시 발생하는 새로운 문제에 대해 해결 및 매뉴얼화

▪ 전환된 데이터의 정밀한 검증

▪ 오픈 전환을 위한 시나리오 작성

3.     오픈 전환

▪ 2차 전환까지 진행을 통해 준비된 시나리오에 따라 최종 전환 작업 진행

▪ 데이터 검증에 대한 철저한 확인 및 시스템 오픈

2.    오픈 전개 계획

▪ 시스템 오픈을 위한 계획

- H/W 및 네트워크 점검

- 시스템 설치: DB 초기화, S/W 설치 등

- 설치 결과 점검: 최종 테스트 점검

- 시스템 초기화: 테스트 데이터를 지우고 초기화 상태

3.    오픈 및 안정화

▪ 오픈: 오픈 전개 계획에 따른 수행

▪ 안정화: 오픈 후 1주일 ~ 한달까지 (상황에 따라 다름)

→ 오류수정, 급한 요청 사항 반영 등

           - 오픈 및 안정화 방법

1.     클로징

▪ 기존 운영된 시스템 서비스 종료

- 사전에 서비스 이용자에게 전환 공지 및 관리 (언제 서비스 중단되고, 언제 신규 전환 오픈 하는지)

2.     데이터 전환

▪ 기존 운영 시스템 데이터 백업

▪ 백업된 데이터를 신규 시스템에 마이그레이션

▪ 마이그레이션 데이터 정합성 검증

3.     전환 점검

▪ 전환된 데이터 기준 신규 시스템 동작 점검

- 점검 과정에 테스트 데이터 등 데이터 유입, 변형

4.     데이터 초기화

▪ 최초 마이그레이션 상태로 데이터 초기화

- 기존 시스템 백업데이터 마이그레이션 상태로 복원

 

 

< IT 프로젝트 관리 기본 지식 >

Project 관리 기본 지식

1.    필수 용어

PM은 프로젝트 관리의 총괄로서 만나는 다양한 사람들과 소통에서 기본적인 신뢰 갖춰야함

A.     시스템 개선 관련 용어

                       i.        개비: 현재 운영중인 시스템을 유지하면서 일부만 고치는 것

                      ii.        고도화: 현재 운영중인 시스템을 더 좋게 만드는 것

                     iii.        리뉴얼: 기존 시스템을 새롭게 만드는 것. 사이즈 적을 때

(보통 B2C 기반 소규모 홈페이지 등에 사용)

                     iv.        차세대: 기존 시스템을 새롭게 만드는 것. 사이즈 클 때 표현

B.     IT 입찰 방식 용어

                       i.        수의 계약: 개발을 맡길 업체를 사전에 정하고, 협상을 통해서 계약 진행

                      ii.        경쟁 입찰: 개발 맡길 업체를 미리 정하지 않고, 제안과 견적(비용)을 심사하여 업체 선정 후 계약

                     iii.        우선 협상: 경쟁입찰 방식이지만, 후보 업체들을 미리 선정해서 그 중에서 경쟁(경쟁입찰과 수의 계약 중간쯤?)

                     iv.        투입 공수: 투입될 개발 인력의 양(숫자).

# 투입 공수를 산정하라 = 이 개발하는데 들어갈 사람 숫자 세라

                      v.        M/M(맨먼스): 투입 공수의 단위

# 1명이 1개월 일하는 게 1M/M

                     vi.        턴키 방식: 계약을 수주한 수행사가 처음부터 끝까지 책임을 지는 계약 방식

                    vii.        용역계약 방식: 이거 개발하는데 몇 명을 얼마 기간 동안 투입시키는 형식

C.     고객사 시스템 용어

                       i.        레거시: 단순하고 정확한 표현은, 오래된 시스템   # 혼동 주의

                      ii.        기간계 시스템: 회사의 사업과 관련된 업무 시스템

(ex 판매/구매 시스템, 재고관리 시스템 등)

                     iii.        그룹웨어: 여러 명이 협동하여 일을 하도록 만든 S/W. 통상 회사 직원들의 업무 소통을 위한 시스템 (ex, 직원관리, 사내메일, 메신저, 결제 등)

                     iv.        ERP: 전사적 자원 관리 시스템. 회사에서 쓰는 모든 시스템을 통합한 거

(MIS+자재관리, 물류관리, 판매관리 등)

D.    평가 용어

                       i.        정량 평가: 수치로 표현 가능한 것

                      ii.        정성 평가: 수치로 표현 불가능한 것

                     iii.        KPI: 평가를 위한 지표

                     iv.        ROI: 투자수익률

 

2.    문서 관리

PM은 문서 관리의 기본 개념을 알고 작업자들을 가이드 할 수 있어야 함

A.     문서 표지

                       i.        상단: 사업명, 문서명

                      ii.        좌측 하단: 고객사 CI

                     iii.        우측 하단: 구축사 CI

B.     개정 이력

                       i.        모든 문서의 두번째 장에 문서의 변경 이력을 볼 수 있는 [제, 개정, 이력]장을 만들고 관리해야 함

C.     버전 관리

                       i.        최초 작성은 v0.1

                      ii.        문서의 초안 확정은 v1.0             # 검토 필요

                     iii.        0.1, 0.2, 0.3 ~ 0.9 는 적은 변경 시

                     iv.        보통 1.대 즉 1.0, 2.0 등 큰 변화시는 가능한 고객에게 공유

D.    문서 관리 ID 부여 방식

                       i.        가능한 산출물은 ID를 관리하는 것이 좋음

ex) 요구사항 정의서(X) -> KOR-SI-AN-10-요구사항 정의서(O)

(사업명)-(구분:개발/관리)-(진행단계)-(단계 순번)-(파일명)

                      ii.        좋은 점은 문서의 이름만 봐도, 어떤 업무의 어떤 위치에 문서가 있고 관리되는지 알 수 있음

 

3.    데이터 표준화 및 품질관리

A.     데이터 표준화: DB의 [컬럼]을 표준에 맞게 관리하는 것

                       i.        명명 규칙: 모든 DB 컬럼의 용어가 일관성 있게 작명 되도록 규칙을 관리

                      ii.        표준화 사전: 중복제거, 동의어 단일화, 동음어 구분 등

                     iii.        이 부분은 제대로 안되면 개발 진행 당시보다, 운영 중 큰 불편함을 주는 것

B.     데이터 품질 관리: DB의 [컬럼 값]을 일관적으로 관리하는 것

                       i.        일관성 유지: 해당 형식 정의에 맞게 실제 TABLE 컬럼 타입이 만들어 졌는지 확인. 이를 통해 일관성 확보

                      ii.        오류 값 입력 방지: 표준화에 따라 TABLE이 만들어 져도, 프로그램에서 오류 값을 만들 수 있음. 이에 대한 점검

                     iii.        품질 관리가 제대로 되지 않으면, 향후 프로그램 확장이나 다양한 정보 관리에 문제

 

< IT 사업기획과 IT 프로젝트 관리 관계 >

IT 프로젝트를 하면서 알게 되는 것

: IT 프로젝트를 진해면 고객사에 대해서 상세히 알 수 있다. 이것을 기회로 만들어야 함

- 고객사 구조

▪ IT Project를 진행 시, 고객사의 내부 조직 구조 및 다양한 체계 정보를 알 수 있음

- 고객사 핵심 BM

▪ 고객사가 가지고 있는 핵심 BM 확인 가능

▪ 고객사가 중요하게 여기는 방향 확인 가능

- 고객사 Pain Point

▪ 고객사에서 해결하고 싶어 하는 다양한 문제에 대한 정보 확인 가능

- 고객사 의사결정 과정

▪ 고객사가 시스템 개발을 위해 필요로 하는 다양한 의사 결정 과정에 대한 이해 가능

 

IT 사업기획의 사업 기회

: DX컨설턴트가 고객사의 내부 정보를 잘 알게 되면, 해당 사업에 제안할 수 있는 기회를 찾을 수 있다.

 

IT 사업기획과 프로젝트 관계

-      실제 IT현장에서 상황에 따라 DX컨설턴트에게 프로젝트에 대한 PM으로 직접 관리 혹은 간접적 관리를 요구하기도 함

-      IT Project 관리를 단순한 프로젝트 관리로 보지 말고 고객사에 대해서 가장 깊게 이해할 수 있는 기회

-      새로운 제안 모델을 상상하고 고객에게 제안하여 기회를 창출하자!