이 책에 담긴 내용은 소프트웨어 개발 프로젝트에 직접적으로 참여하는 사람들뿐만 아니라 소프트웨어 회사의 경영자, 프로젝트관리자, 개발자, 상위관리자 등 모든 사람들이 알아야 할 내용 모두를 포함한다. 여기서 말하는 소프트웨어 회사는 소프트웨어 제품만을 개발하는 회사를 지칭하지 않는다. 팩키지 소프트웨어를 만드는 회사나 SI회사는 물론, 장비에 탑재되는 임베디드 소프트웨어를 만드는 휴대전화 개발사나 복사기 제조사, 방대한 전산 시스템을 가지고 있는 은행이나 증권사 등 소프트웨어를 개발하고 유지보수하는 모든 회사가 여기에 해당하며 구체적으로 예를 들면 다음과 같다.
■ 모바일 플랫폼, 프레임워크, 스마트폰 어플리케이션 개발회사
■ 팩키지 소프트웨어 회사
■ SI(System Integration) 회사
■ 게임 개발 회사
■ 웹 포탈 회사
■ 비즈니스 솔루션 개발회사
■ 그래픽 라이브러리 개발회사
■ 공학용 계산 소프트웨어 개발회사
■ 휴대전화, 셋톱박스, 에어컨, 냉장고, TV 등 전자제품 제조회사
■ Firewall, IPS, IDS 등 보안 장비 개발회사
■ 은행, 증권사 등 금융회사
■ 피자회사 등 주문 시스템 보유 회사 ---p.10

소프트웨어 프로젝트는 그저 열심히 수행한다고 해서 성공할 수 있는 것이 아니다. 회사와 직원들 모두에게 기초가 갖춰져 있지 않은 상태로 진행하는 프로젝트는 모래 위에 쌓아 올린 탑과 같다. 아무리 훌륭한 프로젝트관리자라 하더라도 소스코드관리시스템이나 버그관리시스템도 없고, 테스터도 없고, 개발자들이 서로 리뷰를 해본 적도 없다면, 이들을 이끌고 프로젝트를 성공시키기란 기적이나 다름없다. 반면 기초를 잘 갖추고 진행하는 프로젝트는 튼튼한 탑과 같이 견고하다. ---p. 26

시중에는 수많은 소프트웨어 개발방법론이 넘쳐난다. 지금까지 알려진 방법론만 100가지가 넘는다. 인터넷에서 이에 대한 설명만 보고 Template을 복사해 와서 회사에 적용한다는 것은 기적에 가깝다. Template과 Sample만 보면 방법론을 적용하여 선진 개발 방식을 따라 할 수 있을 것 같지만, 착각이다. 책을 보며 피겨스케이팅을 배우겠다는 것과 다르지 않다. 제대로 된 방법론을 잘못 오해하여 적용하거나 특정 부분에 집착하여 전체를 놓치는 경우가 많다.
한 가족이 살기 위한 집을 짓는데 고층 빌딩을 만드는 방법을 적용하면 안 되고, 그렇다고 개집을 만들 때처럼 대충 지어서도 안 된다. 개집을 만들 때는 대충 만들어도 되고, 안되면 다시 만들면 된다. 그러나 빌딩을 만들 때는 한 치의 오차도 없이 정확하고 정교한 방법을 사용해야 한다. ---p. 128

SRS는 이 책 전체에서 소개하는 많은 문서 중에서 가장 중요하다. 프로젝트를 성공으로 이끄는데 가장 중요한 핵심이기 때문이다. 만약 소프트웨어 프로젝트에서 문서를 딱 하나밖에 만들 시간이 없다고 하면 SRS를 만드는 것이 좋을 것이다. SRS는 IEEE에서 만든 가이드와 표준 Template이 있다. 회사들마다 사용하는 Template이 약간씩 다르지만 문서이름, 목적, 취지는 전세계적으로 표준이라고 보면 된다. 소프트웨어 개발 회사라면 회사에 맞게 각자 커스트마이즈 된 Template을 가지고 있어야 한다. ---p. 230

개발자들은 가장 먼저
● SRS를 작성해야 한다고 생각하고,
● SRS를 작성하면서 모든 관련자와 철저히 리뷰를 하고,
● 프로젝트관리자는 개발자들과 함께 1, 2일 단위의 상세 일정을 작성하고,
● 테스트팀은 SRS를 보고 테스트 Suite를 만들기 시작하고,
● 개발 리더들은 화이트보드나 종이를 펼쳐놓고 아키텍처에 대해 토론을 하며,
● 구현 시 모든 소스코드는 당연히 리뷰를 하고,
● 개발자는 매일 스스로 일정을 업데이트 하고,
● 소스코드 작성은 일일빌드가 깨지지 않으면서 이루어지며,
● 소스코드관리시스템과 버그관리시스템을 효과적으로 사용하며,
● 알파, 베타 단계 별로 모든 프로젝트 관련자들이 유기적으로 움직이며,
● 일정에 맞춰 완성도 있는 품질의 제품을 출시한다.
위와 같은 활동들이 당연하다고 생각되고 몸에 배어야 한다. 이러한 것들을 규칙만으로 통제를 해서는 달성하기 어렵고 한꺼번에 모두 다 습득하기도 어렵다. 하나씩 익혀서 몸에 배었을 때 소프트웨어 프로젝트를 성공하는 원리가 보이기 시작하고 좋은 제품을 만들 수 있을 것이다.