크레마클럽

옮긴이 머리말 xi추천사 xvi감사의 글 xxi베타리더 후기 xiii추천 서문 xixCHAPTER 1 고통스러운 경험을 통한 학습 1나의 관점 2이 책에 관하여 3용어 특기사항 5기회 활용 5CHAPTER 2 요구사항에 관한 레슨 7요구사항 개요 7다양한 유형의 요구사항 7 / 요구사항 엔지니어링의 하위 도메인 9비즈니스 분석가의 역할 10 / 요구사항은 프로젝트의 기반이다 10레슨 1 | 요구사항을 정확하게 알아내지 못하면 프로젝트의 나머지 부분을 잘해도 소용없다 12정확한 요구사항, 그러나 언제? 13 / 정확한 요구사항, 그러나 어떻게? 13레슨 2 | 요구사항 개발에 따른 핵심 결과물은 공유된 비전과 이해다 14레슨 3 | 요구사항에는 모든 프로젝트 이해 당사자의 관심사가 있다 17이해 당사자 분석 18 / 누가 결정하는가? 20 / 우리는 모두 같은 편이다 21레슨 4 | 요구사항 관련해서는 용도 중심의 접근법이 기능 중심의 접근법보다 더 좋게 고객의 요구를 충족한다 21왜 과잉 기능을? 21 / 용도를 우선하기 22사용자 스토리의 우려 사항 23 / 용도가 지배한다! 25레슨 5 | 요구사항 개발은 반복을 필요로 한다 25점진적인 세부 사항 개선 26 / 새로 부각된 기능적 요구사항 27새로 부각된 비기능적 요구사항 28레슨 6 | 애자일 요구사항은 그 밖의 요구사항과 다르지 않다 28역할과 책임 29 / 용어 29 / 문서의 상세함 29 / 활동 시기 30결과물의 형태 31 / 우선순위 결정 시기 31 / 실제로 차이가 있을까? 32레슨 7 | 지식을 기록하는 데 따르는 비용은 지식을 습득하는 비용에 비해 적다 33기록에 대한 두려움 33 / 문서로 기록된 의사소통의 장점 34 / 올바른 균형 36레슨 8 | 요구사항 개발의 가장 중요한 목적은 명확하고 효율적인 의사소통이다 37다수의 독자, 다수의 요구 38 / 표현 기법 선택하기 39 / 대화할 수 있을까? 41레슨 9 | 요구사항 품질은 보는 사람의 관점에 따라 다르다 41많은 요구사항 독자들 42 / 요구사항 품질 체크리스트 43레슨 10 | 요구사항은 허용 가능한 위험 수준 범위에서 구축이 진행되는 데 충분한 것이어야 한다 44세부 사항의 관점 44 / 어느 정도면 충분할까? 45레슨 11 | 요구사항은 단순히 수집하는 것이 아니다 46수집하기 vs. 도출하기 46 / 요구사항 도출 시기 47 / 도출 컨텍스트 48도출 방법 48 / 기반 만들기 50레슨 12 | 요구사항 도출은 고객의 음성이 개발자의 귀에 잘 들릴 정도로 가까운 거리에서 해야 한다 50의사소통 경로 51 / 제품 대변인 52 / 요구사항 의사소통의 다른 경로 52괴리 해소하기 53레슨 13 | 흔히 사용되는 두 가지 요구사항 도출 관례가 텔레파시와 투시력이다. 이 방법들은 효과가 없다 54요구사항을 알아내자! 54 / 명시적인 표현 55 / 텔레파시가 실패하다 56레슨 14 | 많은 사람들이 모이면 요구사항을 정확히 어떻게 표현할지 합의하기는커녕 방에 불이 나서 탈출하는 데도 동의할 수 없다 57주목하세요! 57 / 구조에 나서는 진행자 58 / 집중, 집중, 집중 59그룹 외부에서 도움받기 60레슨 15 | 포함될 기능을 결정할 때 데시벨 우선순위를 정하지 말자 61우선순위 지정 방법 61 / 우선순위 지정 기준 62 / 목소리 크기를 넘어서는 분석 63레슨 16 | 문서화되고 합의된 프로젝트 범위 없이 어떻게 범위 증가를 알 수 있을까? 63유령 같은 범위 증가 64 / 범위를 기록하는 방법 65이것은 범위 내에 있나요? 66 / 모호한 요구사항 = 모호한 범위 66CHAPTER 3 설계에 관한 레슨 69설계 개요 69설계의 다른 측면들 70 / 좋은 설계 72레슨 17 | 설계에는 반복이 필요하다 74프로토타입의 위력 75 / 개념-증명 75 / 실물 모형 76레슨 18 | 더 높은 추상화 수준에서 반복하는 것이 더 저렴하다 77상세한 것으로부터 한 걸음 물러나기 78 / 빠른 시각적 반복 79 / 쉬운 반복 81레슨 19 | 올바르게 사용하기는 쉽지만 잘못 사용하기는 어렵게 제품을 만들자 82사용자가 실수할 수 없도록 만들자 83 / 사용자가 실수하기 어렵게 하자 84오류를 쉽게 복구하게 하자 84 / 그런 일이 생기게 내버려 두자 84레슨 20 | 모든 바람직한 품질 속성을 최적화할 수는 없다 85품질의 관점 85 / 품질 속성 명시하기 87품질을 위한 설계 88 / 아키텍처 속성과 품질 속성 89레슨 21 | 힘들게 재코딩하는 것보다 조금이라도 설계하는 것이 가치가 있다 89기술 부채와 리팩토링 90 / 아키텍처 결함 91레슨 22 | 대부분의 시스템 문제는 인터페이스에서 생긴다 92기술적인 인터페이스 문제들 93 / 입력 데이터 검증 95사용자 인터페이스 문제들 96 / 인터페이스 전쟁 97CHAPTER 4 프로젝트 관리에 관한 레슨 98프로젝트 관리 개요 98인력 관리 99 / 요구사항 관리 99 / 기대 관리 99 / 작업 관리 100약속 관리 100 / 위험 관리 100 / 의사소통 관리 100 / 변경 관리 101자원 관리 101 / 의존성 관리 101 / 계약 관리 101 / 공급자 관리 102장벽 제거 관리하기 102레슨 23 | 작업 계획은 마찰을 고려해야 한다 103작업 전환과 몰입 104 / 유효 시간 106프로젝트 마찰의 다른 원인 107 / 암시적 영향을 예상하기 107레슨 24 | 다른 사람에게 섣불리 추정치를 제시하지 말자 108성급한 예측 109 / 불확실성에 대한 두려움 110레슨 25 | 빙산은 항상 처음 보이는 것보다 더 크다 110컨틴전시 버퍼 111 / 위험한 가정 113 / 빙산 계약 115 / 버퍼의 묘미 115레슨 26 | 자신의 주장을 뒷받침할 데이터가 있으면 협상에서 유리한 위치에 설 수 있다 116그 수치는 어디서 구했어요? 116 / 원칙적 협상 118레슨 27 | 추정치를 기록하고 실제 발생한 것과 비교하지 않으면 추정이 아닌 추측에 그칠 수밖에 없다 118과거 데이터의 여러 출처 119 / 소프트웨어 메트릭 120레슨 28 | 받는 사람이 듣고 싶어 하는 말을 근거로 견적을 변경하지 말자 122목표 대 추정치 122 / 조정 시기 123레슨 29 | 임계 경로를 피하자 124임계 경로 정의 124 / 방해되지 않게 하기 125레슨 30 | 작업은 전체적으로 완료 또는 완료되지 않음 중 하나다. 부분적인 완료는 없다 126‘완료’는 무엇을 의미할까? 126 / 부분 점수는 없다 128요구사항 상태별 추적 129 / 완성도가 가치로 이어진다 130레슨 31 | 프로젝트 팀은 범위, 일정, 예산, 인원, 그리고 품질의 다섯 가지 관점 중 하나 이상에 대해 유연성이 필요하다 130다섯 가지 프로젝트 관점 130 / 우선순위 협상하기 132유연성 다이어그램 133 / 다섯 가지 관점 적용하기 134레슨 32 | 프로젝트의 위험을 통제하지 못하면, 위험이 우리를 통제할 것이다 134위험 관리란 무엇인가? 135 / 소프트웨어 위험 식별하기 135위험 관리 활동 137 / 항상 걱정해야 할 것이 있다 139레슨 33 | 고객이 항상 옳은 것은 아니다 139‘옳지 않다’는 것 140 / 견해 존중하기 142레슨 34 | 우리는 소프트웨어에서 너무 많은 가식 행위를 한다 143상상의 나라에 살기 143 / 비이성적 기대감 144 / 사람들이 하는 게임 145CHAPTER 5 문화와 팀워크에 관한 레슨 146문화와 팀워크 개요 146믿음 지키기 147 / 문화적 일치 148 / 문화의 구체화 149 / 성장하는 그룹 150레슨 35 | 지식은 제로섬이 아니다 152지식 독점 152 / 무지를 바로잡기 153 / 지식 전수 확대 154건강한 정보 문화 156레슨 36 | 다른 사람들이 아무리 많은 압력을 가하더라도, 우리가 이행할 수 없는 약속은 절대 하지 말자 156약속, 약속 157 / 살다 보면 그럴 수 있지 158레슨 37 | 교육과 더 나은 실무 사례가 없다면 생산성 향상은 꿈도 꾸지 말자 159무엇이 문제인가? 160 / 몇 가지 가능한 해결책 160도구 및 교육 162 / 개별 개발자의 성과 차이 162레슨 38 | 사람들은 그들의 권리에 관해 많이 얘기하지만, 모든 권리의 이면에는 책임이 따른다 164고객 권리 및 책임 예 165 / 개발자 권리 및 책임 예 165프로젝트 관리자 또는 스폰서 권리 및 책임 예 166자율 팀 권리 및 책임 예 166 / 위기 전의 우려 166레슨 39 | 물리적 분리로 인해 의사소통과 협업이 저해되지는 않는다 167공간과 시간의 장벽 167 / 가상 팀: 분리의 극치 169문, 문, 문을 위한 나의 왕국! 169레슨 40 | 소규모 공동 작업 팀에 적합한 비공식적인 접근 방식은 잘 확장되지 않는다 171처리 체계와 도구 172 / 전문화의 필요성 172 / 의사소통 충돌 173레슨 41 | 새로운 업무 방식으로 전환할 때 조직의 문화를 바꾸는 어려움을 과소평가하지 말자 174가치, 행동, 그리고 실무 사례 174 / 애자일과 문화의 변화 176 / 내면화 177레슨 42 | 비합리적인 사람들을 대할 때는 어떤 공학이나 관리 기법도 소용이 없다 178약간의 가르침을 시도해보자 179 / 누가 선을 넘었나요? 179유연성을 위하여 180CHAPTER 6 품질에 관한 레슨 182품질 개요 182품질의 정의 182 / 품질 계획 183 / 품질의 다양한 관점 185 / 품질을 내재하기 185레슨 43 | 소프트웨어 품질에 대해서라면 지금 지불하거나 또는 나중에 더 지불할 수 있다 187수리 비용 증가 곡선 188 / 발견이 더 어렵다 190 / 초기 품질 조치 190레슨 44 | 고품질은 자연스럽게 생산성 향상으로 이어진다 193두 프로젝트 이야기 193 / 재작업의 재앙 195 / 품질 비용 196레슨 45 | 조직은 소프트웨어를 제대로 구축할 시간이 없지만 나중에 그것을 해결할 수 있는 자원을 찾는다 197왜 처음이 아닐까? 198 / 1억 달러 신드롬 199 / 균형 잡기 199레슨 46 | 크랩 갭을 조심하자 200크랩 갭 예 200 / 소프트웨어의 크랩 갭 시나리오 201레슨 47 | 상사나 고객이 나쁜 일을 하도록 부추기지 말자 202권력 행사 203 / 조급한 코드 작성 203 / 지식 부족 203그늘진 윤리 205 / 절차 회피 205레슨 48 | 고객이 아닌 동료가 결함을 찾도록 노력하자 206동료 검토의 이점 206 / 다양한 소프트웨어 검토 207 / 검토의 문화적 영향 209레슨 49 | 소프트웨어 사람들은 도구를 좋아하지만, 도구를 가진 바보가 더 큰 바보다 210도구는 가치를 추가해야 한다 211 / 도구는 현명하게 사용해야 한다 212도구는 프로세스가 아니다 213레슨 50 | 오늘의 ‘당장 출시해야 하는’ 개발 프로젝트는 내일의 유지보수 악몽이다 214기술 부채와 예방 유지보수 215 / 의식적인 기술 부채 215현재 또는 미래의 품질을 위한 설계 216CHAPTER 7 프로세스 개선에 관한 레슨 218프로세스 개선 개요 218소프트웨어 프로세스 개선이란? 218 / 프로세스를 두려워하지 말자 219SPI를 정착시키기 220레슨 51 | ‘비즈니스위크를 추종하는 경영’을 주의하자 221먼저 문제, 그 다음에 해결책 222 / 근본 원인 분석 예 223진단이 치료로 이어진다 225레슨 52 | “내게 무슨 득이 되지?”라고 묻지 말고, “우리에게 어떤 이득이 있지?”라고 묻자 226팀 이득 226 / 개인적 이득 228 / 팀을 위한 희생 229레슨 53 | 사람들이 일하는 방식을 바꾸는 데가장 좋은 동기가 되는 것은 고통이다 229고통은 아프다! 230 / 보이지 않는 고통 231레슨 54 | 조직을 새로운 작업 방식으로 이끌 때는 부드럽게 압박하되 끊임없이 가하자 232변화로 이끌기 232 / 상향 관리 234레슨 55 | 이전의 모든 전문가가 이미 저지른 실수를 일일이 되풀이할 시간은 없다 235학습 곡선 236 / 모범 실무 사례 237레슨 56 | 올바른 판단과 경험은 때때로 정해진 프로세스보다 우선한다 238프로세스와 리듬 239 / 독단주의에 빠지지 않기 240레슨 57 | 문서 템플릿에 줄여-맞추기 철학을 쓰자 242레슨 58 | 시간을 들여 배우고 개선하지 않는 한, 다음 프로젝트가 지난 프로젝트보다 더 잘 될 것이라고 기대하지 말자 246되돌아보기 246 / 회고 구조 248 / 회고 이후 249레슨 59 | 소프트웨어 업계에서 가장 눈에 띄는 반복성은 비효율적인 일을 반복해서 하는 것이다 250학습의 장점 251 / 사고의 장점 252CHAPTER 8 다음에 할 일 254레슨 60 | 모든 것을 한 번에 바꿀 수는 없다 255변화 우선순위 지정 256현실 점검 257실행 계획 258나만의 레슨 260부록: 레슨 요약 261요구사항 261 / 설계 262 / 프로젝트 관리 262문화와 팀워크 262 / 품질 263 / 프로세스 개선 263다음에 할 일 264찾아보기 266

펼쳐보기접어보기

상세 이미지

저자 소개 (2명)

저 : 칼 위거스 (Karl Wiegers)

관심작가 알림신청

Process Impact의 수석 컨설턴트로서 150여 개의 조직을 대상으로 소프트웨어 개발 및 요구사항 엔지니어링에 대한 교육과 컨설팅에 50년 이상 몸담아왔다. 저서로는 캔디스 호캔슨과 함께 쓴 『소프트웨어 요구사항의 정수』(제이펍, 2024)가 있고, 조이 비티와 함께 쓴 『소프트웨어 요구사항(제3판)』(위키북스, 2017)으로는 미국 기술커뮤니케이션학회로부터 우수상을 수상했다. Process Impact의 수석 컨설턴트로서 150여 개의 조직을 대상으로 소프트웨어 개발 및 요구사항 엔지니어링에 대한 교육과 컨설팅에 50년 이상 몸담아왔다. 저서로는 캔디스 호캔슨과 함께 쓴 『소프트웨어 요구사항의 정수』(제이펍, 2024)가 있고, 조이 비티와 함께 쓴 『소프트웨어 요구사항(제3판)』(위키북스, 2017)으로는 미국 기술커뮤니케이션학회로부터 우수상을 수상했다.

크레마클럽에서 볼 수 있는 작가의 다른 책

내서재에 추가 삭제

소프트웨어 요구사항의 정수

역 : 심재철

관심작가 알림신청

현재 프리랜서로, 데이터베이스/모바일 시스템 관련 컨설팅과 번역을 하고 있다. 또한, 20년 넘게 데이터베이스와 객체지향 시스템 설계 및 개발 프로젝트와 건설/금융 분야 애플리케이션 개발 등에 참여했다. 새로운 테크놀로지와 다양한 프로그래밍 언어를 사용해서 실무에 활용하고 가르치는 것을 좋아한다. 저서로는 『핵심만 골라 배우는 코틀린 프로그래밍』이 있으며, 번역서로는 『실무에 바로 적용하는 안드로이드 프로그래밍(제4판)』, 『스프링 인 액션(제5판)』, 『카프카 핵심 가이드(제1판)』, 『핵심만 골라 배우는 안드로이드 스튜디오 Arctic Fox & 프로그래밍』, 『실무에 적용하... 현재 프리랜서로, 데이터베이스/모바일 시스템 관련 컨설팅과 번역을 하고 있다. 또한, 20년 넘게 데이터베이스와 객체지향 시스템 설계 및 개발 프로젝트와 건설/금융 분야 애플리케이션 개발 등에 참여했다. 새로운 테크놀로지와 다양한 프로그래밍 언어를 사용해서 실무에 활용하고 가르치는 것을 좋아한다. 저서로는 『핵심만 골라 배우는 코틀린 프로그래밍』이 있으며, 번역서로는 『실무에 바로 적용하는 안드로이드 프로그래밍(제4판)』, 『스프링 인 액션(제5판)』, 『카프카 핵심 가이드(제1판)』, 『핵심만 골라 배우는 안드로이드 스튜디오 Arctic Fox & 프로그래밍』, 『실무에 적용하는 안드로이드 프로그래밍(제2판)』, 『Learn Android Studio』, 『SQLite 마스터북(제2판)』, 『프로 오브젝티브-C 디자인 패턴』, 『세븐 데이터베이스: 만들면서 파악하는 NoSQL』, 『UML 사용자 지침서』, 『Thinking in JAVA(제4판)』, 『이펙티브 자바』 등이 있다.

펼쳐보기접어보기

크레마클럽에서 볼 수 있는 작가의 다른 책