소프트웨어 공학의 사실과 오해

 

---

소프트웨어 공학의 사실과 오해

저자

로버트 L. 글래스 지음

출판사

인사이트 | 2004-10-15 출간

카테고리

컴퓨터/IT

책소개

전통적인 제조업에서 사용하던 방법 그대로 소프트웨어 개발자들을 ...

글쓴이 평점  

---

이책은 우리가 간과하고 있거나 잘못생각하고 있는 55개의 사실과 10개의 오해를 담은 책입니다.

소프트웨어 공학의 모호성으로 인해서 수많은 사실들과 오해들은 많은 부분 논쟁을 가지고 있기도 한데요.

저자는 그러한 사실과 오해들 그리고 그에 대한 논쟁에 대해서 이야기를 하고 있습니다.

각 단락은 하나의 사실과 오해을 주제로 "토의", "논쟁", "출처"의 세부분이 작은 단락을 이루고 있는데요.

각 단락이 그리 길지 않게 구성되어 있어서 집중력을 잃지 않고 있을것 같습니다.

(제가 집중력을 잃지 않고 읽었다는 내용은 아닙니다ㅜㅜ)

많은 직장인들이 자신의 분야에서 몇년을 일하면 그분야에서 만큼은 자신만의 "사실"을 갖고 있게 마련입니다. 소프트웨어 분야도 그런 분들이 많이 계실겁니다.

그런 분들이 이 책을 읽는다면 저자와의 생각의 차이를 밝견하는 부분이 있을수도 있을 것 같습니다. 그렇다면 저자나 독자 중 누가 옳은지에 대해서 고민을 해보는 것도 좋을것 같네요.

저명한 학자라고 항상 맞는 것을 아닐테니까요.

그리고, 이 책에서는 이러한 사실/오해들의 소개하면서 출처가 되거나 같은 논지를 가진 논문이나 서적을 소개하기도 하는데요.

(저 같은 경우에 제가 좋아하는 내용의 서적을 많이 담고 있어서 괜히 기분이 좋았습니다.^^)

관심이 생기는 주제가 있다면 그에 대한 서적을 더 찾보는 것도 좋을것 같구요. 그러한 기회를 제공하는 것이 이책의 좋은 덕목 중 하나일것 같아요.

책의 내용은 차례로 대신해도 될듯하네요. 아래의 차례를 나열 하는 것만으로도 꽤 긴데요.

책을 구해서 읽지는 않더라도 아래 항목들을 한번 읽어보세요~. 도움이 되는 내용이 있을 겁니다.

 

55개 사실 

사실 1. 소프트웨어 작업에서 가장 중요한 요소는 프로그래머의 자질이다.
사실 2. 최고의 프로그래머는 최하의 프로그래머보다 28배 더 뛰어나다.
사실 3. 지체된 프로젝트에 사람을 추가 투입하면 프로젝트가 더 늦어진다.
사실 4. 작업 환경은 생산성과 품질에 지대한 영향을 미친다.
사실 5. 소프트웨어 업계에는 과대선전(도구와 기술에 대한)이 만연해 있다.
사실 6. 새로운 도구와 기술은 도입 초기에 생산성/품질저하를 초래한다.
사실 7. 소프트웨어 개발자는 도구에 대해 많은 말을 하지만, 별로 사용하지는 않는다.
사실 8. 폭주하는 프로젝트의 가장 흔한 원인 두 가지 중 하나는 부정확한 추정이다.
사실 9. 소프트웨어 추정은 보통 부적절한 시기에 수행된다.
사실 10. 소프트웨어 추정은 보통 부적절한 사람들에 의해 수행된다.
사실 11. 프로젝트가 진행되면서 소프트웨어 추정을 수정하는 경우는 거의 없다.
사실 12. 소프트웨어 추정이 부정확한 것은 별로 놀라운 일이 아니다. 그러나 우리는 추정에 죽고 산다!
사실 13. 경영진과 프로그래머 사이에는 단절이 있다.
사실 14. 타당성 조사에 대한 대답은 항상 "타당하다" 이다.
사실 15. 소규모 재사용은 잘 해결된 문제다.
사실 16. 대규모 재사용은 여전히 해결되지 않은 어려운 문제다.
사실 17. 대규모 재사용은 서로 관련 있는 시스템 사이에서 가장 잘 적용된다.
사실 18. 재사용 가능 컴포넌트는 만들기가 3배 어렵고, 3곳에 적용해봐야 한다.
사실 19. 재사용된 코드를 수정하는 것은 특히 오류를 범하기 쉽다.
사실 20. 디자인 패턴 재사용은 코드 재사용 문제에 대한 해결책이다.
사실 21. 문제의 복잡성이 25% 증가하면 솔루션의 복잡성은 100% 증가한다.
사실 22. 소프트웨어 작업의 80%가 지적인 작업이다. 그 중 상당부분이 창조적인 작업이다. 사무적인 일은 거의 없다.
사실 23. 폭주하는 프로젝트에서 가장 흔한 원인 두 가지 중 하나는 불안정한 요구사항이다.
사실 24. 요구사항의 오류는 생산 단계에서 수정하는데 가장 비용이 많이 든다.
사실 25. 누락된 요구사항은 가장 수정하기 힘든 오류이다.
사실 26. 명시적 요구사항을 설계로 옮겨갈 때 "파생 요구사항"이 폭발적으로 증가한다.
사실 27. 소프트웨어 문제에 있어서 최적의 솔루션이 하나 존재하는 경우는 거의 없다.
사실 28. 설계는 복잡하고 반복적인 과정이다. 초기 설계 솔루션은 보통 잘못 되었거나, 최적이 아닌 경우가 많다.
사실 29. 설계자의 기본단위(primitive)와 프로그래머의 기본단위가 일치하는 경우는 거의 없다.
사실 30. COBOL은 별로 훌륭한 언어가 아니지만, (비즈니스 데이터 처리에 대해서는) 다른 언어도 마찬가지다.
사실 31. 오류 제거는 생명주기 중 가장 시간이 많이 소모되는 단계이다.
사실 32. 프로그래머가 완전하게 테스트했다고 믿는 소프트웨어도 보통은 로직 경로의55~60%만 테스트된 경우가 많다.
사실 33. 100% 테스트 커버리지도 결코 충분하지 않다.
사실 34. 테스트 도구는 꼭 필요하지만, 많은 경우 거의 사용되지 않는다.
사실 35. 특정 테스트 프로세스는 자동화할 수 있고, 또 자동화해야 한다. 그러나 자동화할 수 없는 테스트 작업도 많다.
사실 36. 프로그래머가 작성한 디버그 코드는 테스트 도구에 대한 중요 보완 수단이다.
사실 37. 엄격한 검사는 첫 번째 테스트 케이스를 실행시키기도 전에 소프트웨어 제품에 포함된 오류의 90%까지 제거할 수 있다.
사실 38. 엄격한 검사도 테스트를 대체할 수는 없다.
사실 39. 출시 후 검토(회고라 부르는 사람들도 있다)는 중요하지만, 거의 실행되지 않는다.
사실 40. 검토는 기술적 측면과 사회학적 측면을 모두 가지는데, 어느 쪽도 무시하면 안 된다.
사실 41. 유지보수는 보통 소프트웨어 비용의 40~80%를 차지한다. 따라서, 유지보수는 아마도 소프트웨어 생명주기중 가장 중요한 단계일 것이다.
사실 42. 유지보수 비용의 60%는 개선 작업에 소요되는 비용이다.
사실 43. 유지보수는 문제가 아니라 해결책이다.
사실 44. 유지보수에서 가장 어려운 작업은 기존 시스템을 이해하는 것이다.
사실 45. 더 좋은 소프트웨어 공학 기술로 개발하면 더 많은(더 적은 게 아니라) 유지보수가 필요하다.
사실 46. 품질은 속성의 집합이다.
사실 47. 품질은 사용자 만족, 요구사항 충족, 비용과 일정 목표 달성, 또는 신뢰성이 아니다.
사실 48. 대부분의 프로그래머가 흔히 범하는 오류가 있다.
사실 49. 오류는 뭉치는 경향이 있다.
사실 50. 소프트웨어 오류 제거에 있어 단 하나의 최상의 방법은 없다.
사실 51. 오류는 항상 남아있다. 심각한 오류를 제거하거나 최소화하는 것이 목표가 돼야 한다.
사실 52. 효율은 훌륭한 코딩보다는 훌륭한 설계에 더 많은 영향을 받는다.
사실 53. 고급 언어 코드도 어셈블리어 코드의 90%에 가까운 효율을 낼 수 있다.
사실 54. 크기와 속도 사이에는 트레이드오프가 있다.
사실 55. 많은 연구자들이 연구보다는 옹호에 치중한다.

오해
오해 1. 측정할 수 없는 것은 관리할 수 없다.
오해 2. 소프트웨어 품질은 관리로 해결할 수 있다.
오해 3. 프로그래밍은 비자아적이 될 수 있고, 또 되어야 한다.
오해 4. 도구와 기술: 한 가지로 모든 문제를 해결할 수 있다.
오해 5. 소프트웨어 분야에는 더 많은 방법론이 필요하다.
오해 6. 비용과 일정을 추정하기 위해서는 먼저 LOC를 추정해야 한다.
오해 7. 랜덤 테스트 입력은 테스트를 최적화하는 좋은 방법이다.
오해 8. "보는 눈이 많으면, 모든 버그는 그 깊이가 얕다."
오해 9. 과거의 비용 데이터를 살펴봄으로써 미래의 유지보수 비용을 예측할 수 있고 시스템교체 결정을 내릴 수 있다.
오해 10. 프로그래밍을 가르칠 때 프로그램을 어떻게 작성하는지를 보여주며 가르친다.