요구공학 원칙
38. 요구사항이 불명확할수록 비용예측은 어렵다.
39. 요구사항을 기록하기 전에 문제를 확실하게 결정한다.
40. 지금 요구사항을 결정한다.
41. 요구명세상의 오류는 즉시 수정해야 한다.
42. 시제품으로 사용자 인터페이스 선정의 위험을 줄인다.
43. 요구사항 항목의 선정근거를 기록한다.
44. 최소 요구사항을 식별한다.
45. 요구사항을 검토한다.
46. 요구분석단계에서 설계하지 않는다.
47. 올바른 기법을 사용한다.
48. 여러 관점으로 요구사항을 분석한다.
49. 요구사항을 현명하게 조직화한다.
50. 요구사항의 우선순위를 정한다.
51. 간결하게 기록한다.
52. 모든 요구사항에 유일한 식별번호를 부여한다.
53. 요구사항의 모호성을 줄인다.
54. 자연어는 정형모델로 보완만 하고 대체하지는 말라.
55. 먼저 자연어로 기록하고 정형모델을 작성하라.
56. 요구명세서는 읽기 쉬워야 한다.
57. 신뢰성에 대하여 구체적으로 명시한다.
58. “수용 불가능한” 환경조건을 명시한다.
59. 미결정항목은 각주와 함께 작성한다.
60. 요구명세서를 데이터베이스에 저장한다.

설계 원칙
61. 요구사항에서 설계로의 전환은 어렵다.
62. 설계산출물에서 요구사항을 추적한다.
63. 대안을 평가한다.
64. 문서가 없는 설계는 설계가 아니다.
65. 캡슐화 한다.
66. 가능하면 재사용한다.
67. 단순하게 개발한다.
68. 특수한 경우를 많이 만들지 않는다.
69. 지적인 거리를 최소화 한다.
70. 설계를 지적 통제하에 둔다.
71. 개념적 무결성을 유지한다.
72. 개념적 오류는 문법적 오류보다 심각하다.
73. 결합도는 낮추고 응집도는 높인다.
74. 변경이 쉽게 설계한다.
75. 유지보수를 고려하여 설계한다.
76. 오류수정이 쉽게 설계한다.
77. 일반성을 띄게 소프트웨어를 개발한다.
78. 유연성 있게 소프트웨어를 개발한다.
79. 효율적인 알고리즘을 사용한다.
80. 사용자가 필요로 하는 모든 정보는 모듈명세서에 있다.
81. 설계는 다차원적이다.
82. 뛰어난 설계는 뛰어난 설계자가 한다.
83. 어플리케이션에 대해서 숙지한다.
84. 큰 투자 없이도 재사용할 수 있다.
85. 무효한 값을 입력하면 적절한 오류 메세지를 출력하도록 한다.
86. 소프트웨어 신뢰성은 중복성을 통해 얻을 수 있다.

코딩원칙
87. 트릭을 사용하지 않는다.
88. 광역변수를 사용하지 않는다.
89. 하향식으로 읽을 수 있도록 작성한다.
90. 부작용을 제거한다.
91. 의미 있는 명칭을 사용한다.
92. 사람을 위한 프로그램을 작성한다.
93. 최적의 자료구조를 사용한다.
94. 빨리 하기 보다는 올바르게 한다.
95. 코드를 완성하기 전에 주석을 작성한다.
96. 코딩을 시작하기 전에 문서화한다.
97. 모든 구성요소를 책상 위에서 실행시켜 본다.
98. 코드 검사를 실시한다.
99. 비구조적 언어도 사용할 수 있다.
100. 구조화된 코드가 반드시 좋은 코드는 아니다.
101. 너무 깊이 중첩 시키지 않는다.
102. 적절한 언어를 사용한다.
103. 프로그래밍 언어를 핑계 삼아서는 안된다.
104. 언어에 대한 지식은 중요하지 않다.
105. 프로그램의 체계를 정비한다.
106. 코딩을 너무 빨리 시작하지 말아라.

시험원칙
107. 시험에서 요구사항을 추적한다.
108. 시험하기 훨씬 이전에 시험을 계획한다.
109. 자신이 개발한 소프트웨어를 자신이 시험하지 않는다.
110. 자신이 개발한 소프트웨어의 시험계획은 남이 세운다.
111. 시험은 결함을 드러나게 할 뿐이다.
112. 오류의 많고 적음과 소프트웨어의 가치는 무관하다.
113. 오류를 찾아야 성공적인 시험이다.
114. 15% 모듈에서 50%의 오류가 발견된다.
115. 블랙박스시험과 화이트박스시험을 실시한다.
116. 시험사례에는 예상결과를 포함시킨다.
117. 무효한 값으로 시험한다.
118. 항상 스트레스 시험을 한다.
119. 빅뱅설을 적용하면 안된다.
120. McCabe의 복잡도 척도를 사용한다.
121. 효과적인 시험종료 척도를 사용한다.
122. 시험 적용범위를 효과적으로 활용한다.
123. 단위시험이 끝나기 전에 통합하지 않는다.
124. 소프트웨어에 특정한 시험용 코드를 내장시킨다.
125. 오류의 원인을 분석한다.
126. 오류를 개인적인 차원으로 생각하지 않는다.

관리원칙
127. 뛰어난 관리는 뛰어난 기술보다 중요하다.
128. 적절한 해결책을 이용한다.
129. 읽은 것을 모두 믿지 않는다.
130. 고객의 우선순위를 알아야 한다.
131. 사람이 성공의 열쇠이다.
132. 많은 사람보다는 소수정예요원이 더 낫다.
133. 부하 직원의 말을 경청한다.
134. 부하 직원을 신뢰해야 한다.
135. 항상 기대치를 높이 가진다.
136. 능숙한 의사소통 기술은 필수적이다.
137. 진심으로 부하직원을 위해준다.
138. 사람은 의외의 것으로 동기부여 받는다.
139. 사무실 분위기를 조용히 유지한다.
140. 인력과 시간은 대체할 수 없다.
141. 소프트웨어 개발자의 능력차이는 크다.
142. 원하는 목표로 최적화 할 수 있다.
143. 자료수집을 강요하면 안된다.
144. 코드 1줄 당 비용은 무시한다.
145. 완벽한 생산성 측정방법은 없다.
146. 비용산정 모델을 조정한다.
147. 일정은 현실적으로 계획한다.
148. 불가능한 것은 피한다.
149. 측정하기 전에 무엇을 측정할 지 알아야 한다.
150. 생산성 자료를 수집한다.
151. 팀의 생산성을 잊지 않는다.
152. 인월 당 행수(LOC/PM)은 언어와 관계없다.
153. 일정을 믿는다.
154. 정확하게 산정한 비용견적이라도 완전히 맞지는 않는다.
155. 일정을 정기적으로 재조정한다.
156. 약간 적은 견적을 항상 나쁘다고 할 수는 없다.
157. 자원을 적절히 할당한다.
158. 프로젝트를 치밀하게 계획한다.
159. 계획을 최신 버전으로 유지한다.
160. 잦은 계획변경의 파급효과에 주의한다.
161. 최상위 10개의 위험항목을 알아야 한다.
162. 직면한 위험을 이해한다.
163. 적절한 프로세스 모델을 사용한다.
164. 방법론이 당신을 구해주지는 못한다.
165. 기적적인 생산성 향상 비법은 없다.
166. 진척도의 의미를 정확히 알아야 한다.
167. 계획과의 차이만 관리한다.
168. 하드웨어에 과중한 부하를 주지 않는다.
169. 하드웨어의 발전에는 낙천적으로 대응한다.
170. 소프트웨어의 발전에는 비관적으로 대응한다.
171. 예상치 못한 사고로 인해 대혼란이 자주 초래된다.
172. 프로젝트의 사후 검토회를 실시한다.

제품보증 원칙
173. 제품보증 수준은 프로젝트에 맞게 조정한다.
174. 형상관리 절차를 조기에 확립한다.
175. 소프트웨어 프로세스에 SCM을 적용한다.
176. SCM은 프로젝트 관리에 독립적으로 조직화한다.
177. 개발과 제품보증업무 사이를 순환보직화 한다.
178. 모든 중간산출물에 명칭과 버전 번호를 부여한다.
179. 기준선을 통제한다.
180. 모든 것을 보존한다.
181. 모든 변경을 계속 추적한다.
182. 변경관리를 해야 한다.
183. 변경요청에 우선순위를 부여하고 일정계획을 세운다.
184. 대규모 개발에는 검증과 확인(V&V)을 적용한다.

진화원칙
185. 소프트웨어는 계속 변화한다.
186. 소프트웨어의 엔트로피는 증가한다.
187. 고장나지 않았으면 고치지 않는다.
188. 증상이 아닌 근본적인 문제를 수정한다.
189. 요구사항을 먼저 변경한다.
190. 릴리즈 전의 오류는 릴리즈 후의 오류의 원인이 된다.
191. 프로그램은 오래되면 될수록 유지보수하기 어려워진다.
192. 언어는 유지보수성에 영향을 미친다.
193. 때로는 처음부터 수정하는 방법이 좋다.
194. 최악의 구성요소는 처음부터 다시 개발한다.
195. 유지보수는 개발보다 많은 오류를 발생시킨다.
196. 변경한 후에는 반드시 회기 시험을 실시한다.
197. 변경사항이 간단하다고 방심하면 잘못 변경하게 된다.
198. 비구조적인 코드는 구조화해도 개선되지 않는다.
199. 최적화하기 전에 프로파일러를 사용한다.
200. 시스템에 친밀감을 갖는다.
201. 시스템은 환경변화에 따라 계속 변화한다.

출처 : ‘201가지 소프트웨어 개발원칙’ 목차