IT 시스템의 정석 - 사례로 배우는 시스템 기획 개발 운용 유지보수

“IT 시스템 개발 및 운영을 전체상으로 제시”

IT 시스템 관리 부서의 프로젝트 관리 매니저를 핵심 대상으로 하여, IT팀의 전반적인 프로세스 과정을 하나하나 설명합니다. 시스템의 기획부터 개발, 테스트, 유지보수, 운영, 폐기까지 전체상을 도식화하여 보여줍니다. 또한 여러 실제 실패 사례를 바탕으로 여러 경우의 수를 짚어 줍니다. 프로젝트를 맡아 진행해야 하는 관리자나 개발자, IT 부서의 구성원이라면 꼭 봐야 합니다.

[목 차]

머리말
저자 소개
옮긴이의 글
옮긴이 소개
베타 추천사

제1장 IT팀이 가진 과제와 이 책의 역할
1.1 IT팀의 현재 상황
[현장 과제 ①] IT팀에 노하우가 축적되지 않는다
[현장 과제 ②] IT 인재 육성이 어렵다
[현장 과제 ③] 인재 부족(1인 IT팀이나 부서 겸업의 일상화)
[현장 과제 ④] 시스템의 복잡화

1.2 과제에 대한 이 책의 역할
1.2.1 이 책에서 얻을 수 있는 것
1.2.2 대상 독자
1.2.3 과제 해결을 위한 이 책의 ‘내용’

1.3 이 책의 구성
1.3.1 전체 구성
1.3.2 각 장의 구성
1.3.3 요인에 대해서
1.3.4 등장 인물에 대해서

제2장 기획
2.1 기획이란
2.1.1 조감도에서의 위치와 내용

2.2 서비스 기획
2.2.1 서비스 기획의 활동 내용
2.2.2 서비스 기획 작성 포인트
2.2.3 특히 중요한 사외 요인, 사내 요인
2.2.4 <실패 사례> 경영 전략과 방향성이 달라 기획에 좀처럼 승인이 나지 않는다

2.3 시스템 기획
2.3.1 시스템 기획의 활동 내용
2.3.2 시스템 기획 작성 포인트
2.3.3 특히 중요한 사외 요인, 사내 요인
2.3.4 <실패 사례> IT 자산을 효과적으로 활용하지 못해 운용 비용이 몇 배로!

2.4 RFP
2.4.1 RFP 작성의 활동 내용
2.4.2 RFP 작성 포인트
2.4.3 특히 중요한 사외 요인, 사내 요인
2.4.4 <실패 사례> RFP를 리뷰할 부서의 선정이 충분하지 않아 중요한 요구가 누락되어 큰 문제로 발전!

2.5 제안서 평가, 계약
2.5.1 제안서 평가, 계약의 활동 내용
2.5.2 제안서 평가, 계약 포인트
2.5.3 특히 중요한 사외 요인, 사내 요인
2.5.4 <실패 사례> 개발 벤더가 프로그램을 재이용, 판매했다!

2.6 서비스 평가
2.6.1 서비스 평가의 활동 내용
2.6.2 서비스 평가의 포인트
2.6.3 특히 중요한 사외 요인, 사내 요인
2.6.4 <실패 사례> 기존 시스템을 대체하고자 서비스 이용을 선택했으나 작업량이 많아 업무가 원만하게 이루어지지 않는다!

2.7 정리하기

제3장 시스템 개발
3.1 ‘시스템 개발’이란?
3.1.1 조감도에서의 위치와 내용

3.2 프로젝트 계획
3.2.1 프로젝트 계획 활동 내용
3.2.2 프로젝트 계획서 작성 포인트
3.2.3 특히 중요한 사외 요인, 사내 요인
3.2.4 <실패 사례> 릴리즈 시점을 너무 세분화한 나머지 비용은 오르고 품질은 내려갔다!

3.3 요건 정의
3.3.1 요건 정의 활동 내용
3.3.2 요건 정의 작성 및 리뷰 시의 포인트
3.3.3 특히 중요한 사외 요인, 사내 요인
3.3.4 <실패 사례> ‘지금처럼’이라면 ‘지금’을 알 수 없는 개발 벤더는 요건을 설계에 반영할 수 없다!
3.3.5 <실패 사례> 비기능 요건이 구체적으로 정의되지 않았다! 시스템 테스트에서 개발 벤더와 다투게 되는 사태 발생

3.4 설계(기본 설계, 상세 설계)
3.4.1 설계(기본 설계, 상세 설계) 활동 내용
3.4.2 설계(기본 설계, 상세 설계)의 리뷰 포인트
3.4.3 특히 중요한 사외 요인, 사내 요인
3.4.4 <실패 사례> 항목이 일치하지 않고 통일성이 없는 설계가 이루어졌다!

3.5 개발, 벤더 테스트
3.5.1 개발, 벤더 테스트의 활동 내용
3.5.2 개발, 벤더 테스트의 리뷰 포인트
3.5.3 특히 중요한 사외 요인, 사내 요인
3.5.4 <실패 사례> 코드 규약을 따르지 않고 구축해서 유지 보수 단계에서 대혼란이 발생했다!
3.5.5 <실패 사례> 단위 테스트에서 발견해야 할 버그가 통합 테스트에서 대량으로 발생하여 일정이 대폭 지연되었다

3.6 사용자 수용 테스트
3.6.1 사용자 수용 테스트의 활동 내용
3.6.2 사용자 수용 테스트의 포인트
3.6.3 특히 중요한 사외 요인, 사내 요인
3.6.4 <실패 사례> 중요 기능 확인을 나중으로 미룬 결과, 버그를 제때에 개선하지 못했다

3.7 업무 훈련
3.7.1 업무 훈련의 활동 내용
3.7.2 업무 훈련 포인트
3.7.3 특히 중요한 사외 요인, 사내 요인
3.7.4 <실패 사례> 설명할 순서나 내용에 미비점이 있어 사내 설명회가 혼란에 빠졌다!

3.8 이행 리허설, 실제 이행
3.8.1 이행 리허설, 실제 이행의 활동 내용
3.8.2 이행 리허설, 실제 이행의 포인트
3.8.3 특히 중요한 사외 요인, 사내 요인
3.8.4 <실패 사례> 지속 가능한 계획이 없다! 장애 복구에 시간이 걸려 업무에 영향을 미쳤다

3.9 정리하기

제4장 서비스 도입
4.1 ‘서비스 도입’이란
4.1.1 조감도에서의 위치와 내용

4.2 프로젝트 계획

4.3 서비스 도입 설계
4.3.1 서비스 도입 설계 시 활동 내용
4.3.2 서비스 도입 설계의 포인트
4.3.3 특히 중요한 사외 요인, 사내 요인
4.3.4 <실패 사례> 백업 수준이 사내 규칙에 미달하여 추가적인 시스템 개발을 해야 한다!

4.4 서비스 설정, 확인
4.4.1 서비스 설정, 확인 시 활동 내용
4.4.2 서비스 설정 시 포인트
4.4.3 특히 중요한 사외 요인, 사내 요인
4.4.4 <실패 사례> 계산 방법이 달라서 산출 결과가 이전과 달라졌다!

4.5 업무 훈련
4.5.1 업무 훈련 시 활동 내용
4.5.2 업무 훈련 시 포인트
4.5.3 특히 중요한 사외 요인, 사내 요인
4.5.4 <실패 사례> 많은 인원으로 업무 훈련을 시작했는데 서비스에 접속하지 못하게 됐다!

4.6 이행 리허설, 실제 이행
4.6.1 이행 리허설, 실제 이행의 활동 내용
4.6.2 이행 리허설, 실제 이행 시 포인트
4.6.3 특히 중요한 사외 요인, 사내 요인
4.6.4 <실패 사례> 데이터 클리닝 범위에 누락이 있어 테스트 데이터가 남은 상태로 업무를 시작했다!
4.6.5 <실패 사례> 데이터 이행이 끝나지 않아, 일정 기간 업무가 복잡해졌다!

4.7 정리하기

제5장 유지 보수
5.1 ‘유지 보수’란?
5.1.1 조감도에서의 위치와 내용

5.2 유지 보수의 전체 설계
5.2.1 유지 보수 전체 설계 시 활동 내용
5.2.2 유지 보수 전체 설계 시 포인트
5.2.3 특히 중요한 사외 요인, 사내 요인
5.2.4 <실패 사례> 갱신해야 할 문서가 명확하지 않다!

5.3 유지 보수 계약 체결
5.3.1 유지 보수 계약 체결 시 활동 내용
5.3.2 유지 보수 계약 체결 시 포인트
5.3.3 특히 중요한 사외 요인, 사내 요인
5.3.4 <실패 사례> 영업일에 대한 정의가 애매하여 장애 대응을 받지 못했다

5.4 우선 순위 두기, 안건 실시
5.4.1 우선 순위 두기, 안건 실시 활동 내용
5.4.2 우선 순위 두기, 안건 실시의 포인트
5.4.3 특히 중요한 사외 요인, 사내 요인
5.4.4 <실패 사례> 안건 관리 부족으로 인해 병행 개발에 실패했다! 결국 장애가 다발하는 사태로 이어졌다
5.4.5 <실패 사례> 갈라파고스화1된 독자적인 유지 보수 개발 때문에 후임에게 민폐를 끼쳤다!

5.5 평가, 개선
5.5.1 평가, 개선의 활동 내용
5.5.2 평가, 개선 포인트
5.5.3 특히 중요한 사외 요인, 사내 요인
5.5.4 <실패 사례> 인력 부족으로 유지 보수 품질이 악화되어 장애가 다발했다

5.6 정리하기

제6장 운용
6.1 ‘운용’이란?
6.1.1 조감도에서의 위치와 내용

6.2 운용 계획
6.2.1 운용 계획 시 활동 내용
6.2.2 운용 계획 작성 포인트
6.2.3 특히 중요한 사외 요인, 사내 요인
6.2.4 <실패 사례> 운용 수용에 대한 설명을 하지 않아 다툰 끝에 매일같이 잔업을 하게 됐다

6.3 이벤트 관리
6.3.1 이벤트 관리의 대표적인 관리 대상
6.3.2 이벤트 관리 시 포인트
6.3.3 특히 중요한 사외 요인, 사내 요인
6.3.4 <실패 사례> 외부 서비스 중단을 파악하지 못해 시스템 오류가 다발했다!

6.4 시스템 관리
6.4.1 시스템 관리 시 대표적인 관리 대상
6.4.2 시스템 관리 시 포인트
6.4.3 특히 중요한 사외 요인, 사내 요인
6.4.4 <실패 사례> 하드웨어의 연장 보증을 파악하지 않아 비용이 부족해졌다!

6.5 장애 대응
6.5.1 장애 대응 시 활동 내용
6.5.2 장애 대응 시 포인트
6.5.3 특히 중요한 사외 요인, 사내 요인
6.5.4 <실패 사례> 안이하게 재실행한 결과, 데이터 불일치로 인해 2차 장애가 발생했다!

6.6 평가, 개선
6.6.1 평가, 개선 시 활동 내용
6.6.2 평가, 개선 시 포인트
6.6.3 특히 중요한 사외 요인, 사내 요인
6.6.4 <실패 사례> 평가에 사용하지 못하는 자료만 존재하기에, 자료를 수집하기 위한 개선점이 발생했다

6.7 정리하기

제7장 폐기
7.1 ‘폐기’란?
7.1.1 조감도에서의 위치와 내용

7.2 프로젝트 계획

7.3 폐기 설계
7.3.1 폐기 설계 시 활동 내용
7.3.2 폐기 설계 시 포인트
7.3.3 특히 중요한 사외 요인, 사내 요인
7.3.4 <실패 사례> 어느새 누군가가 데이터를 이용함으로써 시스템 폐기와 동시에 트러블이 발생했다

7.4 폐기 실시
7.4.1 폐기 실시의 활동 내용
7.4.2 폐기 실시의 포인트
7.4.3 특히 중요한 사외 요인, 사내 요인
7.4.4 <실패 사례> 외부 서비스에 한 의뢰가 거절당해 관계없는 타사에 영향이 발생했다

7.5 정리하기

제8장 매니지먼트
8.1 ‘매니지먼트’란?
8.1.1 조감도에서의 위치와 내용

8.2 매니지먼트의 기본
8.2.1 매니지먼트의 기본이란?

8.3 각 단계의 ‘계획 시’에 검토해야 할 것 [Plan]
8.3.1 검토해야 할 것은 무엇인가?
8.3.2 각 단계의 ‘계획 시’에 주의해야 할 포인트
8.3.3 특히 중요한 사외 요인, 사내 요인
8.3.4 실패 사례 끝냈다고 생각한 과제가 다시 발생했다!

8.4 각 단계의 ‘실행 시’에 확인해야 할 것 [Do]
8.4.1 확인해야 할 것은 무엇인가?
8.4.2 각 단계의 ‘실행 시’에 주의해야 할 포인트
8.4.3 특히 중요한 사외 요인, 사내 요인
8.4.4 <실패 사례> 개발 벤더를 너무 나무랐더니 최소한의 대응만 해주다가 품질이 나쁜 시스템이 탄생했다

8.5 각 단계의 ‘평가 시’에 확인해야 할 것 [Check]
8.5.1 평가해야 할 것은 무엇인가?
8.5.2 각 단계의 ‘평가 시’에 주의해야 할 포인트
8.5.3 특히 중요한 사외 요인, 사내 요인
8.5.4 <실패 사례> 이전 단계에서 좋지 않은 부분이 개선되지 않아서 다음 단계에까지 이어졌다!

8.6 각 단계의 ‘개선 시’에 검토해야 할 것 [Action]
8.6.1 개선해야 할 것은 무엇인가?
8.6.2 각 단계의 ‘개선 시’에 주의해야 할 포인트
8.6.3 특히 중요한 사외 요인, 사내 요인
8.6.4 <실패 사례> 다른 안건의 개선점이 공유되지 않아 유지 보수 안건에서 같은 실수가 발생했다!

8.7 정리하기

부록 도움이 되는 프레임워크
참고문헌
맺음말
찾아보기