IT 시스템의 정석

제목 IT 시스템의 정석

부제 사례로 배우는 시스템 기획ㆍ개발ㆍ운용ㆍ유지보수

저자 이시구로 나오키, 게게

역자 이민성

출판사 비제이퍼블릭(BJ퍼블릭)

출간/배본가능일 2023년 9월 27일

정가 24,000원

페이지 360쪽

판형 152*225

ISBN 979-11-6592-244-3 (93000)

 

관련분류 – 카테고리 분류

국내도서 > IT 모바일 > 컴퓨터 공학 > 소프트웨어 공학

국내도서 > IT 모바일 > 컴퓨터 공학 > 개발방법론

국내도서 > IT 모바일 > 컴퓨터 공학 > 컴퓨터 교육

 

이 상품의 태그

#IT프로젝트 #IT프로세스 #IT프로젝트진행 #프로젝트관리 #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 정리하기

 

부록 도움이 되는 프레임워크

참고문헌

맺음말

찾아보기

 

저자 소개

이시구로 나오키

1981년 교토에서 태어났으며 현재 주식회사 글로리아 대표이사다. 대학 졸업 후에 일본을 대표하는 시스템 인터그레이터(SI) 회사인 노무라 종합연구소에 입사했다. 주로 금융시스템을 담당했고 대규모 프로젝트 개발, 유지 보수, 운용 등 정보시스템에 관한 다양한 경험이 있으며, 15년간 근무 후 독립하여 현재 현업에서 활동하고 있다. 주로 중소기업, 개인 사업자의 사업 전개를 IT를 주축으로 지원 중이다. 기업 이념은 ‘여러분과 함께 미래를 만든다’다. 보유 자격증으로는 정보처리안전확보지원사(#019126), 정보처리기술자(IT 전략가) 프로젝트관리자 등이 있다.

 

게게

신입 사원으로 시스템 개발 회사에 입사하여 애플리케이션 설계와 개발 업무에 종사했으며, 대규모 개발 프로젝트의 리더와 관리직을 맡았다. 현재는 시스템 기획 부문에 소속되어 시스템 그랜드 디자인의 검토, 시스템 기획, 도입 시의 프로젝트 관리 등을 맡고 있다. 보유 자격증으로는 PMP, 정보처리기술자시험(프로젝트 관리자, 데이터베이스 전문가) 등이 있다.

 

역자 소개

이민성

현재 네트워크 엔지니어로 일하고 있으며, 풀스택 인프라 엔지니어를 목표로 하고 있다. 목표를 위해 지속적으로 공부하면서도 여러분에게 좋은 책을 소개하려고 한다.

 

출판사 리뷰

“IT 현장에서 마주할 수 있는 다양한 문제를 어떻게 해결해야 할까요?”

 

크고 작은 다양한 규모를 가진 기업과 일을 하면서 ‘시스템을 잘 모르겠다’라는 분위기를 종종 느낍니다. 이는 정보 시스템을 담당하는 입장에 있더라도 마찬가지입니다. 확실히 시스템은 개별 상황에 따라 실시해야 할 일도 천차만별입니다. 전체상을 알지 못하면 어떤 행동을 해야 하는지도 모르고, 새로운 기술이 계속 나오기 때문에 따라가지 못하는 것이 실정일지도 모릅니다.

 

이에 도움이 되고자 이 책을 만들게 되었습니다. 책의 3가지 특징은 다음과 같습니다.

1) 전체상을 제시하였습니다. 전체상을 잡아야 무엇을 해야 하는지 보이기 때문입니다. 각 행동을 취해야 할 프로세스 위치를 명확하게 표현하므로 현업에 계신 분들에게 도움이 될 것입니다.

2) IT팀이 해야 할 일을 제시하였습니다. 시스템의 수명주기인 기획, 개발, 도입, 유지보수, 운용, 폐기 등을 중심으로 IT팀 활동을 구체적으로 알 수 있습니다.

3) 현장에서 활용할 수 있습니다. 직접 경험한 바에서 얻은 노하우를 바탕으로 정석을 제시하면서 독자 개개인의 상황에서는 어떻게 해야 할지 연상하기 쉽도록 설명하였습니다.

 

많은 분이 이 책을 활용하여 다양한 문제를 해결하는 데 도움을 받으셨으면 좋겠습니다.

 

이 책을 추천합니다.

-      IT 시스템 관리 부서와 시스템을 구매하는 사업회사, 발주처

-      SI 회사의 개발자, 기획자, 프로젝트 관리 매니저

-      예비 프로젝트 관리자

 

책 보러 가기

- 예스24: https://www.yes24.com/Product/Goods/122692895

- 알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=325434323 

- 교보문고: https://product.kyobobook.co.kr/detail/S000209621261

 

[도서 오탈자 제보 & 질의응답 게시판 바로가기]