 |
제목 : 소프트웨어 공학의 사실과 오해 부제 : 우리가 미처 알지 못한 원제 : Facts and Fallacies of Software Engineering 지은이 : 로버트 글래스 옮긴이 : 윤성준, 조홍진 펴낸곳 : 인사이트 ISBN : 8991268021 펴낸날 : 2004년 10월 9일 |
| 장 | 설명 |
| 사실 1. 사람 | 소프트웨어 작업에서 가장 중요한 요소는 프로그래머가 사용하는 도구나 기술이 아니라, 프로그래머의 자질이다 |
| 사실 2. 사람 | 개인차에 대한 연구에 따르면, 최상의 프로그래머는 최악의 프로그래머보다 28배 더 뛰어나다. 여기에 비례해서 이들에게 임금을 28배 주는 것이 아니라면, 이들은 소프트웨어 분야에서 가장 값싸고 훌륭한 자원이다. |
| 사실 3. 사람 | 지체된 프로젝트에 사람을 추가 투입하면 프로젝트가 더 늦어진다. |
| 사실 4. 사람 | 작업 환경은 생산성과 품질에 지대한 영향을 미친다. |
| 사실 5. 도구와 기술 | 소프트웨어 업계에는 과대선전이 만연해 있다. 소프트웨어 도구와 기술의 진보로 인해 생산성과 품질이 5~35% 향상된다고 한다. 그러나 예전에도 이 정도의 향상은 10배 이상 뛰어난 사람이 있으면 가능한 일이었다. |
| 사실 6. 도구와 기술 | 새로운 도구나 기술을 배우는 것은 초기에는 프로그래머의 생산성과 제품의 품질을 저하시킨다. 궁극적인 이득은 학습곡선을 극복한 이후에야 얻을 수 있다. 따라서 새로운 도구와 기술을 채택하는 것은 (1)그 가치가 현실적으로 보일 때와, (2)이득을 얻을 때까지 기다릴 수 있는 인내가 있을 때만 가치가 있다 |
| 사실 7. 도구와 기술 | 소프트웨어 개발자들은 도구에 대해 많은 말을 하지만, 그 중 일부만을 평가해보고, 구입하는 것은 얼마되지 않으며, 실제로 사용하는 것은 거의 없다 |
| 사실 8. 추정 | 프로젝트가 폭주하는 가장 흔한 원인 두 가지 중 하나는 형편없는 추정이다. |
| 사실 9. 추정 | 대부분의 소프트웨어 추정은 생명주기의 초기에 수행된다. 요구사항을 정의하기 전에, 즉 문제를 이해하기 전에 추정을 한다는 사실을 깨닫기 전까지는 아무 문제가 없어 보인다. 따라서 추정은 보통 부적절한 시기에 수행된다. |
| 사실 10. 추정 | 대부분의 소프트웨어 추정은 소프트웨어를 구축할 사람 또는 그들의 관리자에 으해 수행되는 것이 아니라 경영진이나 마케팅에 의해 결정된다. 따라서 추정은 부적절한 사람들에 의해 수행된다. |
| 사실 11. 추정 | 소프트웨어 추정은 프로젝트가 진행되면서 거의 조정되지 않는다. 따라서 부적절한 시점에 부적절한 사람들이 산정한 잘못된 추정은 대개 교정되지 않는다. |
| 사실 12. 추정 | 추정은 매우 부적절하기 때문에 소프트웨어 프로젝트가 추정 목표를 충족시키지 못했다고 해서 문제될 이유는 거의 없다. 그러나 모든 사람들이 어떻게든 영향을 받는다. |
| 사실 13. 추정 | 경영진과 프로그래머 사이에는 단절이 있다. 한 연구 조사에 따르면, 추정에 맞추지 못해 경영진은 실패라고 생각하는 프로젝트에 대해, 거기 참여했던 기술자들은 그들이 작업한 것 중 가장 성공적인 프로젝트라 평가했다고 한다. |
| 사실 14. 추정 | 타당성 조사에 대한 대답은 항상 '타당하다'이다. |
| 사실 15. 재사용 | 소규모 재사용(서브루틴 라이브러리)은 거의 50년 전부터 시작되어 잘 해결된 문제다. |
| 사실 16. 재사용 | 모든 사람들이 대규모 재사용(컴포넌트)을 중요하고 바람직한 것이라 생각하지만, 거의 대부분의 문제가 해결되지 않은 채 남아 있다. |
| 사실 17. 재사용 | 대규모 재사용은 서로 관련되어 있는 시스템 사이에서 가장 잘 적용되고 따라서 도메인 종속적이다. 이는 대규모 재사용의 잠재적 적용성을 축소시킨다. |
| 사실 18. 재사용 | 재사용에 대한 두 가지 '3의 법칙'이 있다. (1) 재사용 가능 컴포넌트를 만드는 것은 단일 목적의 컴포넌트를 만드는 것보다 세배는 어렵다. (2)컴포넌트는 재사용 라이브러리로 인정할 만큼 일반적이라 생각하기 전에 서로 다른 세 가지 애플리케이션에 적용해봐야 한다. |
| 사실 19. 재사용 | 재사용된 코드를 수정할 경우에는 특히 오류를 범하기 쉽다. 만약 컴포넌트의 20-25% 이상을 수정하고자 한다면 차라리 처음부터 다시 작성하늑 서이 더 효율적/효과적이다. |
| 사실 20. 재사용 | 디자인 패턴 재사용은 코드 재사용의 본질적인 문제에 대한 해결책 중 하나다. |
| 사실 21. 복잡성 | 문제의 복잡성(complexity)이 25% 증가하면 소프트웨어 솔루션의 복잡성은 100% 증가한다. (복잡성을 줄이는 것이 바람직한 일이긴 하지만) 소프트웨어 솔루션의 본질이 원래 그렇기 때문에, 바꾸려 한다고 바꿀 수 있는 것이 아니다. |
| 사실 22. 복잡성 | 소프트웨어 작업의 80%가 지적인 작업이다. 그 중 상당부분이 창조적인 작업이다. 사무적인 일은 거의 없다. |
| 사실 23. 요구사항 | 폭주하는 프로젝트에서 가장 흔한 원인 두 가지 중 하나는 불안정한 요구사항이다. |
| 사실 24. 요구사항 | 쇼프트웨어 출시 후 발견된 요구사항 오류는 그 수정 비용이 매우 높지만, 초기에 발겨된다면 그 비용이 매우 낮아진다. |
| 사실 25. 요구사항 | 누락된 요구사항은 가장 수정하기 힘든 오류이다. |
| 사실 26. 설계 | 요구사항을 설계로 옮겨갈 때 솔루션 프로세스의 복잡성 때문에 '파생 요구사항'(특정 설계 솔루션에 대한 요구사항)이 급증한다. 이런 설계상의 요구사항은 종종 원래의 요구사항보다 50배 넘게 늘기도한다. |
| 사실 27. 설계 | 소프트웨어 문제에 있어서 최적의 솔루션이 하나 존재하는 경우는 거의 없다. |
| 사실 28. 설계 | 설계는 복잡하고 반복적인 프로세스다. 초기 설계 솔루션은 잘못됐을 가능성이 크고, 최적의 상태도 아니다. |
| 사실 29. 코딩 | 설계자가 숙지한 기본단위(primitive) 수준으로 문제가 분해됐을 때 설계에서 코딩으로 전환된다. 설계자와 코더(coder)가 동일한 사람이 아니라면, 설계자와 코더의 기본단위가 같지 않을 수 있고, 이는 문제를 초래할 수 있다. |
| 사실 30. 코딩 | COBOL은 별로 훌륭한 언어가 아니지만, (비즈니스 데이터 처리에 대해서는) 다른 언어도 마찬가지다. |
| 사실 31. 오류제거 | 오류 제거는 생명주기 중 가장 시간이 많이 소모되는 단계이다 |
| 사실 32. 테스트 | 프로그래머가 완전히 테스트했다고 믿는 소프트웨어도 보통은 로직 경로의 55-60%만 테스트된 경우가 많다. 커버리지 분석기와 같은 자동화 도구를 사용하면 이 비율을 대략 85~90%까지 높일 수 있다. 소프트웨어의 로직 경로를 100% 테스트하는 것은 거의 불가능하다. |
| 사실 33. 테스트 | 100%의 테스트 커버리지가 가능하다 하더라도, 이는 충분한 테스트 기준이 아니다. 대략 소프트웨어 결함의 35%는 누락된 로직 경로에서, 40%는 로직 경로의 특정 조합을 실행할 때 나타난다. 이런 것들은 100% 커버리지로도 잡히지 않을 것이다. |
| 사실 34. 테스트 | 도구를 사용하지 않고 오류 제거 작업을 제대로 하는 것은 거의 불가능하다. 디버거는 널리 사용되지만, 커버리지 분석기 같은 다른 도구는 많이 사용되지 않는다. |
| 사실 35. 테스트 | 특정 테스트 프로세스는 자동화할 수 있고, 또 자동화해야 한다. 그러나 자동화할 수 없는 테스트 작업도 많다. |
| 사실 36. 테스트 | 프로그래머가 작성한 디버그 코드는 컴파일러 파라미터에 의해 선택적으로 목적 코드에 포함될 수 있는데, 이는 테스트 도구에 대한 중요 보완 수단이다. |
| 사실 37. 검토와 검사 | 엄격한 검사는 첫 번째 테스트 케이스를 실행시키기도 전에 소프트웨어 제품에 포함된 오류의 90%까지 제거할 수 있다. |
| 사실 38. 검토와 검사 | 엄격한 검사(inspection)가 좋기는 하지만, 테스트를 대체할 수도 없고 대체해서도 안 된다. |
| 사실 39. 검토와 검사 | 고객 만족도 측정과 프로세스 개선 측면에서 봤을 때 출시 후 검토(회고라 부르는 사람도 있다)의 중요성은 인정되지만, 이를 시행하는 조직은 거의 없다. |
| 사실 40. 검토와 검사 | 동료 검토(peer review)는 기술적인 측면과 사회적인 측면을 모두 가진다. 한쪽을 무시하고 다른 한쪽에만 치우치면 큰 실패를 초래한다. |
| 사실 41. 유지보수 | 유지보수는 보통 소프트웨어비용의 40~80%(평균 60%)를 차지한다. 따라서 유지보수는 소프트웨어 생명주기 중 가장 중요한 단계일 것이다. |
| 사실 42. 유지보수 | 소프트웨어 유지보수 비용에서 약 60%는 개선 작업에 쓰이는 비용이다. 오류 정정은 약 17% 정도다. 따라서, 소프트웨어 유지보수는 기존 소프트웨어를 보수만 하는 것이 아니라 새로운 기능을 추가할 때도 많다. |
| 사실 43. 유지보수 | 유지보수는 문제가 아니라 해결책이다 |
| 사실 44. 유지보수 | 소프트웨어 개발과 유지보수 작업을 자세히 살펴보면, 유지보수에서는 기존 시스템을 이해해야 한다는 것을 제외한 대부분의 작업이 같다는 것을 알 수 있다. 기존 시스템을 이해하는 작업에 걸리는 시간은 전체 유지보수 시간의 대략 30% 정도고, 이는 유지보수에서 가장 중요한 활동이다. 따라서 유지보수가 개발보다 어려운 작업이라 주장하는 것도 가능하다. |
| 사실 45. 유지보수 | 더 좋은 소프트웨어 공학 기술로 개발하면 더 많은(더 적은 게 아니라) 유지보수가 필요하다 |
| 사실 46. 품질 | 품질은 속성의 집합이다. |
| 사실 47. 품질 | 품질은 사용자 만족, 요구사항 충족, 비용과 일정 목표 달성, 또는 신뢰성이 아니다 |
| 사실 48. 신뢰성 | 대부분의 프로그래머가 흔히 범하는 오류가 있다. |
| 사실 49. 신뢰성 | 오류는 뭉치는 경향이 있다. |
| 사실 50. 신뢰성 | 소프트웨어 오류 제거에 있어 단 하나의 최상의 방법은 없다 |
| 사실 51. 신뢰성 | 오류는 항상 남아있다. 심각한 오류를 제거하거나 최소화하는 것이 목표가 돼야 한다 |
| 사실 52. 효율 | 효율은 훌륭한 코딩보다는 훌륭한 설계에 더 많은 영향을 받는다. |
| 사실 53. 효율 | 컴파일러가 제대로(적절하게) 최적화 작업을 하면 고급언어 코드도 어셈블리어 코드의 90%에 가까운 효율을 낼 수 있다. 그리고 복잡한 현대적 아키텍처에서는 효율이 더 높을 수도 있다. |
| 사실 54. 효율 | 크기와 속도 사이에는 트레이드오프가 있다. 한쪽을 개선하면 대개 다른 쪽이 나빠진다. |
| 사실 55. 연구 | 많은 소프트웨어 연구자들이 연구보다 옹호에 치중한다. 그 결과 (1)몇몇 옹호되는 개념은 그 옹호자가 생각하는 것보다 훨씬 가치가 낮고, (2)이런 개념이 실제로 어떤 효용성을 가지는지 결정하는데 도움을 줄만한 평가적 연구도 부족하다. |
| 오해 1. 관리 | 측정할 수 없는 것은 관리할 수 없다 |
| 오해 2. 관리 | 소프트웨어 품질은 관리로 해결할 수 있다. |
| 오해 3. 사람 | 프로그래밍은 비자아적(egoless)이 될 수 있고, 또 되어야 한다. |
| 오해 4. 도구와 기술 | 도구와 기술: 한 가지로 모든 문제를 해결할 수 있다. |
| 오해 5. 도구와 기술 | 소프트웨어 분야에 더 많은 방법론이 필요하다 |
| 오해 6. 추정 | 비용과 일정을 추정하기 위해서는 먼저 LOC를 추정해야 한다. |
| 오해 7. 테스트 | 랜덤 테스트 입력은 테스트를 최적화하는 좋은 방법이다. |
| 오해 8. 검토 | "보는 눈이 많으면, 모든 버그는 그 깊이가 얕다." |
| 오해 9. 유지보수 | 과거의 비용 데이터를 살펴봄으로써 미래의 유지보수 비용을 예측할 수 있고 시스템교체 결정을 내릴 수 있다. |
| 오해 10. 교육 | 프로그래밍을 가르칠 때 프로그램을 어떻게 작성하는지를 보여주며 가르친다 |
