기능목록>검색 : 육군3사관학교 도서관

IT 아키텍트가 하지 말아야 할 128가지 : 설계, 방법론, 구축·테스트, 운용, 보안

QR코드

미리보기 도서정보

도서 상세정보
자료유형 :	단행본
ISBN :	9788996659884
분류기호 :	004.21
단체저자명 :	니케이시스템즈
서명/저자사항 :	IT 아키텍트가 하지 말아야 할 128가지: 설계, 방법론, 구축·테스트, 운용, 보안/ 니케이시스템즈 엮음; 최석기 옮김.
기타표제 :	누구도 알려주지 않았던 시스템 개발 현장의 128가지 해결책
원서명 :	ITア?キテクトのやってはいけない: 設計、メソドロジ, ??·テスト, 運用, セキュリティのアンチパタ?ン
발행사항 :	서울: 로드북, 2012.
형태사항 :	390 p.: 삽화; 23 cm.
일반주기 :	니케이시스템즈의 한자명은 "日經SYSTEMS" 임
일반주기 :	집필진: 신쿠보 코지, APC 재팬 서비스 사업부 솔루션 엔지니어링부, APC 재팬 비지니스 개발부, 미즈구치 히로유키, 오가미 타카미쯔, 오다카 아츠유키, 코바타 야시치, 타카하시 모토노부, 니시노우에 미노루, 하라다 카즈키, 후지즈카 킨야, 오가오 유키오, 타케다 야스마, 스미세이 정보 시스템, 토우 켄, 야마구치 토오루, 미즈이 에츠코, 무라이시 타케시, 타케다 노리유키, 타시로 타이이치, 이세 코이치, 니시무라 아츠시
서지주기 :	찾아보기 수록
개인저자 :	신쿠보 코지, 저
개인저자 :	미즈구치 히로유키, 공저
개인저자 :	오가미 타카미쯔, 공저
개인저자 :	오다카 아츠유키, 공저
개인저자 :	코바타 야시치, 공저
개인저자 :	타카하시 모토노부, 공저
개인저자 :	니시노우에 미노루, 공저
개인저자 :	하라다 카즈키, 공저
개인저자 :	후지즈카 킨야, 공저
개인저자 :	오가오 유키오, 공저
개인저자 :	타케다 야스마, 공저
개인저자 :	토우 켄, 공저
개인저자 :	야마구치 토오루, 공저
개인저자 :	미즈이 에츠코, 공저
개인저자 :	무라이시 타케시, 공저
개인저자 :	타케다 노리유키, 공저
개인저자 :	타시로 타이이치, 공저
개인저자 :	이세 코이치, 공저
개인저자 :	니시무라 아츠시, 공저
개인저자 :	최석기, 역
단체저자명 :	스미세이정보시스템, 공저.
단체저자명 :	APC재팬. 비지니스개발부, 공저.
단체저자명 :	APC재팬. 서비스사업부. 솔루션엔지니어링부, 공저.
단체저자명 :	일경시스템즈, 편.
분류기호 :	004.21
언어	한국어

소장정보

육군3사관학교

예예약
인인쇄
SSMS
서서가부재
보보존서고
우우선정리예약
무무인예약대출

예약

1. 예약현황은 홈페이지 로그인 후 예약 페이지에 확인 가능합니다.
2. 도착 통보된 예약자료 대출을 원하지 않는 경우에는 예약 현황에서 취소할 수 있습니다.
3. 기타 문의사항은 도서관에 문의 바랍니다.

닫기

무인예약대출

1. 무인예약대출 현황은 홈페이지 로그인 후 무인예약대출 페이지에 확인 가능합니다.
2. 무인예약대출자료 대출을 원하지 않는 경우에는 무인예약대출 페이지에서 신청 또는 접수상태인 경우만 취소할 수 있습니다.
3. 희망대출일은 신청일로부터 최대 1주일 까지 가능합니다.
4. 희망대출일을 선택하지 않은 경우 대출대기 통보 후 1주일까지 기기에서 대출가능합니다.
5. 기타 문의사항은 도서관에 문의 바랍니다.

닫기

목차
1장. 설계
No.001. EC 사이트에서는 Sorry 화면 방식을 채택해서는 안 된다[아키텍처] = 15
No.002. 어플리케이션 개발자가 설계서대로 개발해 줄 것이라고 생각해서는 안 된다[아키텍처] = 20
No.003. 사용자가 성능 요건을 정해줄 것이라고 생각해서는 안 된다[아키텍처] = 24
No.004. 동일 서버 내의 웹 서비스를 호출해서는 안 된다[아키텍처] = 30
No.005. 24시간 가동 시스템이라고 모든 것을 24시간 동작시키려고 해서는 안 된다[아키텍처] = 35
No.006. 클라이언트／서버형 시스템을 가볍게 보아서는 안 된다[아키텍처] = 39
No.007. 데이터 구조의 품질／성능이 나빠지는 것을 고려해야 한다[데이터베이스] = 41
No.008. 백업 설계를 먼저 해서는 안 된다[데이터베이스] = 44
No.009. 레코드 길이×건수로 데이터 용량을 결정해서는 안 된다[데이터베이스] = 46
No.010. 참조 정합성 제약 기능을 여러 번 사용해서는 안 된다[데이터베이스] = 48
No.011. 테스트 데이터로 성능 평가를 해서는 안 된다[데이터베이스] = 51
No.012. 파티션 분할을 가볍게 해서는 안 된다[데이터베이스] = 54
No.013. 오랜 시간 종료하지 않은 트랜잭션을 사용해서는 안 된다[데이터베이스] = 57
No.014. 기술 영역만 고려해서는 안 된다[네트워크] = 60
No.015. 기기의 스펙(명세서)을 bps만으로 판단해서는 안 된다[네트워크] = 64
No.016. 가상 네트워크를 물리 네트워크와 똑같이 생각해서는 안 된다[네트워크] = 68
No.017. QoS라는 말로 숨겨서는 안 된다[네트워크] = 72
No.018. QoS를 과신해서는 안 된다[네트워크] = 75
No.019. 구축 멤버의 시선만으로 로그 출력을 설계해서는 안 된다[아키텍처] = 79
No.020. GC를 정하지 않고 자바 어플리케이션을 설계해서는 안 된다[아키텍처] = 81
No.021. 실물 모형과 프로토 타입을 혼동해서는 안 된다[리치 클라이언트] = 84
No.022. 어플리케이션을 함부로 리치화해서는 안 된다[리치 클라이언트] = 85
No.023. 화면 디자인이나 화면 이동의 변경에 "이것이 최선"이라고 생각해서는 안 된다[리치 클라이언트] = 86
No.024. 사용자 경험을 무조건 포함시키려 해서는 안 된다[리치 클라이언트] = 88
No.025. 사용자에게 사용하기 어려운 점을 물어서는 안 된다[리치 클라이언트] = 90
No.026. 신 클라이언트용 어플리케이션이라고 해도 안심해서는 안 된다[신 클라이언트] = 92
No.027. 산출해 보지 않고 TCO를 줄일 수 있다고 생각해서는 안 된다[신 클라이언트] = 94
No.028. 신 클라이언트의 도입으로 가용성이 좋아졌다고 트러블이 없다고 생각해서는 안 된다[신 클라이언트] = 96
No.029. 가상 PC형으로 이행을 하더라도 검증을 게을리해서는 안 된다[신 클라이언트] = 98
Column 1. IT 아키텍트로서 가장 재미있게 느끼는 부분 = 100
2장. 방법론
No.030. 유스 케이스를 상세하게 작성해서는 안 된다[개발 프로세스] = 105
No.031. 납품 문서만 남겨 두면 된다고 생각해서는 안 된다[개발 프로세스] = 107
No.032. 패키지를 도입할 때 부가 기능 개발을 선행해서는 안 된다[개발 프로세스] = 109
No.033. 패키지를 도입하면 납기를 단축할 수 있다고 생각해서는 안 된다[개발 프로세스] = 111
No.034. 협력사나 고객사와 실데이터 파일을 주고 받아서는 안 된다[개발 프로세스] = 114
No.035. WBS 하나의 작업 항목에 여러 담당자를 선정해서는 안 된다[개발 프로세스] = 115
No.036. 특정 프로세스나 패턴에 집착해서는 안 된다[개발 프로세스] = 117
No.037. "UP＝반복 개발"이라고 생각해서는 안 된다[개발 프로세스] = 118
No.038. ERP와 현행 기능을 비교해서는 안 된다[ERP] = 121
No.039. 다짜고짜 프로토타입부터 시작해서는 안 된다[ERP] = 124
No.040. 고객이 말하는 패키지의 갭 판단을 그대로 받아들여서는 안 된다[ERP] = 129
No.041. 보고서 검토를 뒤로 미뤄서는 안 된다[ERP] = 134
No.042. "고객이 주체가 되어 해야 할 작업"이라고 해서 고객에게 그대로 주어서는 안 된다[ERP] = 138
No.043. 요건 정의를 하기 위한 계획을 게을리 해서는 안 된다[요건 정의] = 142
No.044. 비즈니스 요건과 시스템 요건을 혼동해서는 안 된다[요건 정의] = 145
No.045. 비즈니스 요건을 문장만으로 표현해서는 안 된다[요건 정의] = 148
No.046. 현행 업무, 현행 시스템의 조사를 회피해서는 안 된다[요건 정의] = 151
No.047. 성과물의 선정과 표준화를 뒤로 미뤄서는 안 된다[요건 정의] = 154
No.048. 모든 요건을 사용자가 알고 있다고 생각해서는 안 된다[요건 정의] = 157
No.049. 후속 공정에 들어가고 나서 테스트를 시작해서는 안 된다[요건 정의] = 161
No.050. 사용자의 오해를 초래하기 쉬운 요건 정의서를 만들어서는 안 된다[요건 정의] = 163
No.051. 유스 케이스를 기능 요건이라고 착각해서는 안 된다[요건 정의] = 166
No.052. 사각지대에 있는 요건을 놓쳐서는 안 된다[요건 정의] = 170
No.053. 비용과 기간의 밸런스를 무시해서는 안 된다[요건 정의] = 174
No.054. 요건 정의가 충분하다고 요건 변경이 발생하지 않는다고 생각해서는 안 된다[요건 정의] = 177
No.055. 프로젝트 특성을 생각하지 않고 모두 동일하게 진행해서는 안 된다[요건 정의] = 180
Column 2. "풍림화산"과 IT 아키텍트 = 185
3장. 구축 및 테스트
No.056. 64비트 OS가 32비트 OS보다 우수하다고 생각해서는 안 된다[플랫폼] = 191
No.057. 기호 링크를 조심성 없이 이용해서는 안 된다[소스코드] = 194
No.058. 여러 가지의 OS를 이용할 때는 개행 코드를 무시해서는 안 된다[소스코드] = 198
No.059. 정의된 것 이외의 것을 가볍게 보아서는 안 된다[소스코드] = 202
No.060. 공개 기능 클래스의 인스턴스를 직접 생성해서는 안 된다[소스코드] = 204
No.061. 거대한 정수 클래스를 만들어서는 안 된다[소스코드] = 207
No.062. 분량이 많은 코딩 규칙을 만들어서는 안 된다[소스코드] = 210
No.063. 오픈소스는 무료라고 생각해서는 안 된다[오픈소스] = 212
No.064. 직접 빌드한 바이너리를 실제 환경에서 이용해서는 안 된다[오픈소스] = 215
No.065. 독자적으로 구축해서는 안 된다[오픈소스] = 219
No.066. 소스 코드에 HTML 생성 코드를 포함해서는 안 된다[오픈소스] = 222
No.067. 글로벌 변수나 순환 참조를 사용해서는 안 된다[오픈소스] = 224
No.068. 스레드 세이프로 하는 것을 잊어서는 안 된다[소스코드] = 227
No.069. 소스코드를 유용해서는 안 된다[소스코드] = 230
No.070. 메모리 관리를 처리계에 맡겨서는 안 된다[플랫폼] = 232
No.071. 매직 넘버를 이용해서는 안 된다[소스코드] = 235
No.072. 실 환경에서 갑자기 테스트를 해서는 안 된다[테스트방법] = 236
No.073. 모든 결합 테스트를 자동화해서는 안 된다[테스트방법] = 239
No.074. 테스트를 개발자에게만 맡겨서는 안 된다[테스트방법] = 242
No.075. 자동식별 모드와 전이중 모드를 혼재시켜서는 안 된다[네트워크] = 244
No.076. 랜(LAN) 스위치로 루프 구조를 만들어서는 안 된다[네트워크] = 245
No.077. 뷰, 트리거를 많이 사용해서는 안 된다[데이터베이스] = 248
No.078. 현상만 보고 튜닝을 서둘러서는 안 된다[데이터베이스] = 251
Column 3. 왜 IT 아키텍트가 중요한가? = 254
4장. 운용
No.079. 가상화 환경의 게스트 OS에서 취득한 CPU 사용률을 믿어서는 안 된다[플랫폼] = 259
No.080. SLA를 뒤로 연기해서는 안 된다[운용 설계] = 262
No.081. 운용 비용 절감만을 목표로 해서는 안 된다[운용 설계] = 265
No.082. 운용 절차 없이 운용해서는 안 된다[운용 설계] = 268
No.083. 운용을 아웃소싱하고 나서 안심해서는 안 된다[운용 설계] = 271
No.084. 개발과 운용 커뮤니케이션을 소홀히 해서는 안 된다[운용 설계] = 275
No.085. 1rack(랙) 60A(암페어) 이상 사용해서는 안 된다[서버 운용] = 278
No.086. 이중 구성을 믿어서는 안 된다[서버 운용] = 282
No.087. 자동 백업 툴에 의지해서는 안 된다[서버 운용] = 286
No.088. 환경 설정을 복사 & 붙여넣기해서는 안 된다[서버 운용] = 289
No.089. 커널 튜닝을 해서는 안 된다[서버 운용] = 292
No.090. 출시 직전의 완성형 제품에 갑자기 패치를 해서는 안 된다[플랫폼] = 296
No.091. 스냅샷으로 백업을 대신해서는 안 된다[플랫폼] = 298
No.092. RAID라고 안심해서는 안 된다[플랫폼] = 300
No.093. 서버 사이에 틈을 남겨두어서는 안 된다[데이터센터] = 303
No.094. 서버 뒷면에 케이블을 늘어뜨려서는 안 된다[데이터센터] = 305
No.095. 랙과 서버 사이에 공간을 두어서는 안 된다[데이터센터] = 307
No.096. 냉통로와 온통로만으로 만족해서는 안 된다[데이터센터] = 309
No.097. 서버 수만큼만 UPS를 준비해서는 안 된다[데이터센터] = 311
No.098. 전체를 생각하지 않고 이중 전원으로 해서는 안 된다[데이터센터] = 314
No.099. 랙이 사용하고 있는 전류 값을 간과해서는 안 된다[데이터센터] = 317
No.100. UPS를 설치하는 것만으로 안심해서는 안 된다[데이터센터] = 319
No.101. 파손된 HDD를 계속 사용해서는 안 된다[기록미디어] = 321
No.102. 젖은 디스크를 말려서는 안 된다[기록미디어] = 323
No.103. 젖은 USB 메모리에 전기가 흐르게 해서는 안 된다[기록미디어] = 325
No.104. 테이프를 적셔서는 안 된다[기록미디어] = 326
No.105. 테이프의 압축률을 그대로 받아들여서는 안 된다[기록미디어] = 328
No.106. 공유 폴더를 새로운 서버에 이행해서는 안 된다[기록미디어] = 330
No.107. 리눅스의 free값(빈 메모리)은 메모리의 빈 영역이 아니다[기록미디어] = 332
Column 4. IT 아키텍트에게 요구되는 세가지 힘 = 334
5장. 보안
No.108. IPS를 도입해도 안심해서는 안 된다[네트워크] = 339
No.109. 접근의 증거가 될 만한 흔적을 과잉으로 추출해서는 안 된다[네트워크] = 343
No.110. 패스워드 정책을 너무 엄격하게 해서는 안 된다[네트워크] = 345
No.111. 바이러스 체크는 과잉도 과소도 안 된다[네트워크] = 348
No.112. 패스워드를 프로그램에 하드 코딩해서는 안 된다[소스코드] = 351
No.113. 방화벽으로 너무 많은 규칙을 설정해서는 안 된다[네트워크] = 354
No.114. 운용이나 성능을 고려하지 않고 암호화해서는 안 된다[네트워크] = 356
No.115. 모든 통신을 암호화해서는 안 된다[네트워크] = 359
No.116. 운용 관리에 텔넷을 사용해서는 안 된다[네트워크] = 362
No.117. 관리자 권한을 공유해서는 안 된다[네트워크] = 365
No.118. DBMS의 감사 기능에 의지해서는 안 된다[데이터베이스] = 368
No.119. DBMS 기능으로 데이터를 암호화해서는 안 된다[데이터베이스] = 371
No.120. 신 클라이언트의 보안 대책을 게을리 해서는 안 된다[신 클라이언트] = 373
No.121. 로그온／로그아웃의 이력을 로그에서 빼서는 안 된다[윈도우즈] = 375
No.122. 로그를 수작업으로 수집해서는 안 된다[윈도우즈] = 377
No.123. 일시적이더라도 UAC를 무효로 해서는 안 된다[윈도우즈] = 379
No.124. 사용자 계정을 바로 삭제해서는 안 된다[윈도우즈] = 381
No.125. 루트 계정을 사용해서는 안 된다[리눅스] = 383
No.126. 임시 파일을 안이하게 작성해서는 안 된다[리눅스] = 385
No.127. 사용자 이름을 숫자만으로 구성해서는 안 된다[리눅스] = 387
No.128. 다운로드 받은 파일이 올바르다고 믿어서는 안 된다[오픈소스] = 389
찾아보기 = 391