소프트웨어 크리에이티비티 2.0
1.규율 대 유연성
1.1 소프트웨어 분야의 진정한 헨리 포드를 찾습니다!
1.2 소프트웨어 자동화, 가능할까 사기일까?
1.3 프로그래머는 정말로 '통제불능'일까?
1.4 체계는 나쁜 말일까? 소프트웨어 생명주기 이야기
1.5 소프트웨어 설계 위조하기
1.6 애자일 프로그래밍, 유연성이 무르익다
1.7 교정원 연필에 얽힌 황당한 사건
1.8 파루틴 지수
1.9 체계와 창의력이라는 기묘한 단짝
2.정형 기법 대 경험 기법
2.1 논쟁을 명백히 밝혀보자
2.2 죄책감 없이 소프트웨어 개발하기
2.3 정형 기법: 극적인 (성공, 실패) 이야기 하나
2.4 정형 기법을 넘어서
2.5 정형 기법에 대해서 독자들이 보낸 의견
3.최적화와 만족화
3.1 BIEGE 원칙으로 문제를 해결하라
3.2 충분한 소프트웨어
3.3 땜빵을 옹호하며
3.4 미하일 고르바초프와 소프트웨어 생산성 (!?)
4.정량 추론 대 정성 추론
4.1 측정하지 못하면 관리하지 못한다. 정말?
4.2 수학과 전산학자
4.3 의사결정에서 직관의 역할
4.4 숫자도 숫자 나름이다
5.프로세스 대 제품
5.1 좋은 프로세스가 좋은 제품을 내놓을까?
5.2 좋은 프로세스가 좋은 제품을 내놓을까? 두 번째 의견
5.3 위대할 뻔한 이야기
5.4 소프트웨어 프로세스, 잡다한 생각 몇 가지
5.5 프로세스 대 사람, 좋은 제품 만들기
5.6 CMM을 적용한 결과 둘러보기
5.7 제품 대 프로세스, 언제 무엇에 집중할까?
6.지적인 업무 대 사무적인 업무
6.1 소프트웨어 만들기, 쉬울까? 어려울까?
6.2 소프트웨어 업무, 지적일까 사무적일까...... 아니면 창의적일까?
6.3 아주 그릇된 이유로 혁신 개념 사들이기
7.이론 대 실무
7.1 이론이 먼저일까? 실무가 먼저일까?
7.2 다시 생각하는 이론 대 실무
7.3 이론과 실무, 심난한 예제
7.4 뒝벌의 비상
7.5 이론 대 실무, 다양한 유감
7.6 소프트웨어 실무가 소프트웨어 이론을 앞서는 부문 정리
8.업계 대 학계
8.1 흥미 대 유용성
8.2 개인 대 팀
8.3 유행어 둘
8.4 이해와 인정과……정형 기법
8.5 구조적 연구라고?
8.6 말하기 대 듣기
8.7 미적미적 위원회
8.8 엄밀성 대 실용성
9.재미 대 진지
9.1 재미와 권태
9.2 오픈소스, 돌아온 재미
9.3 특이한 프로젝트
9.4 잃어버린 재미를 찾습니다
10.소프트웨어 조직과 창의력
10.1 그리스 대 로마, 판이한 소프트웨어 문화
10.2 통제와 기업 문화
10.3 혁신과 관리
10.4 창의력과 전략 정보 시스템
10.5 창의력 대 법
11.창의력과 소프트웨어 기술
11.1 정보 시스템을 구현하는 창의적인 기법
11.2 창의력과 소프트웨어 설계, 빠진 고리
11.3 사례 연구, 창의력이 현실을 만나다
12.소프트웨어 역사와 기념비적인 사건
12.1 첫 번째 기념비적인 사건
12.2 이후 '은총알' 사건
12.3 창의력 대 절차화
13.조직적인 창의력
14.창의적인 사람
15.컴퓨터와 창의력
16.창의력 모순
17.항상 그랬다
18.상승적 결론
19.기타 결론
A.특별 부록(로버트 L. 글래스 대담 기사)
B.특별 부록(성공/실패 조건)
C.베타리더 한마디
소프트웨어 컨플릭트 2.0
1부 논쟁의 저장(場)
·이론이 먼저냐, 실제가 먼저냐?
·'위험하며 오도(誤導)하다'- 파나스 논문을 통해 본 소프트웨어 연구 상황
·'은총알은 없다'- 프레드 브룩스를 통해 본 소프트웨어 연구 실정
·가장 뛰어나고 명석한 두뇌들이 내놓은 보고서
2부 기술 진영에서
·인지적 견해: 소프트웨어 설계를 보는 다른 시각
·소프트웨어 오류에 대한 단상
·소프트웨어 오류 제거에 대한 실험적 관점
·다양한 테스트 종류
·소프트웨어 품질과 소프트웨어 유지보수 사이의 관계
·소프트웨어 유지보수는 해결책이지 골칫거리가 아니다
·단일지점 제어
·사용자 편의 - 유행어인가, 도약인가
3부 최신 무기 정보
- 방법론
·재사용: 소프트웨어 부품 - 노스텔지어와 데쟈뷰
·자동 프로그래밍: 칵테일 파티 미신?
·프로토타이핑에 대한 단상
·표준과 표준준수: 정말 소프트웨어 품질을 높이는 데 도움이 되나?
- 도구
·권장 사항: 소프트웨어 도구 모음의 최소 권장 기준
·잔소리: 소프트웨어 분야에서 최신의 '비약적 발전' 살펴보기
·CASE와 4GL: 이익은 얼마인가?
·컴파일러 개발, 무엇이 문제인가?
- 언어
·고차원 언어: 어느 정도가 적당한가?
·4GL의 미래를 준비해야 할까?
·코볼, 도대체 무엇이 문제인가?
·회고: 최신 무기 정보
4부 지휘 본부에서
- 관리
·소프트웨어 세계에서 업적 달성하기
·소프트웨어 생산성을 바라보는 새로운 방법
·생산성과 G 이론
·베리 뵘이 제시하는 소프트웨어 프로젝트 관리 원칙, 'W' 이론
·소프트웨어 생산성 향상: 누가 무엇을 하고 있는가?
·소프트웨어 측정 기준: 피뢰침과 팽배한 긴장
·품질 관리: 허울 벗기
·소프트웨어 제품에서 '품질'을 관리할 수 있을까?
·실패한 소프트웨어 프로젝트에 관한 전설
- 마케팅
·당신이라면 루드비히 2세에게서 중고차를 사겠는가?
·컨설팅
·컨설팅의 진정한 비밀
·미래학자의 과거 들춰보기
·사용자 지원: 눈 맞추기만으로는 부족하다
5부 연구실에서
- 연구
·구조적 연구라고?
·[해결된/해결되지 않은] 문헌 연구 문제
·작은 논쟁 하나: 참고 문헌의 장단점
- 기술 이전
·내년에 뜰까? 기술 성숙도 연구에 관한 고찰
·허점이 많은 소프트웨어 기술 이전 [생산성 높이는 길은 험하다]
·기술 이전에 관한 미신
- 교육
·소프트웨어 교육: 새로운 정보 제공처
·전산학과 교수에게 보내는 공개 편지
6부 전장 사후 분석
·전산학이 진짜 과학이 되며, 소프트웨어 공학이 진짜 공학이 되려면
·'문제 해결'에 대한 당연한/기발한 생각
·소프트웨어 실패: 왜 실패할까?
·응용 분야의 중요성
·사라진 즐거움을 찾아주시겠습니까?
·뜨거운 열정을 지닌 소프트웨어 개발자에게 바치는 헌정시