 |
제목 : 소프트웨어 장인정신 원제 : Software Craftsmanship 지은이 : Pete McBreen 옮긴이 : 강경인 펴낸곳 : 피어슨에듀케이션코리아 ISBN : 8945071415 펴낸날 : 2002년 12월 31일 |
소프트웨어 엔지니어링을 대학에서 배웠다. 왜 소프트웨어 공학이 언제 시작되었는지 제대로 알지 못했다. 이 책을 통해서 소프트웨어 공학의 시작이 어디이며, 왜 탄생했는지를 알게되었다.
머리말 - V
소프트웨어 엔지니어링이란 말은 1967년 "소프트웨어 문제"의 논의를 위해 회의를 열자고 했던 한 NATO 연구그룹에 의해 만들어 졌다. 이후 1968년 회의로부터 보고서는 소프트웨어 엔지니어링이란 제목을 갖게 되었다. 이 보고서에서 Peter Naur와 Brian Randell 은 "소프트웨어 엔지니어링이란 말은 뭔가 자극을 주기 위한 선택이었고, 그것을 공학이란 전통적인 의미를 통해 소프트웨어 제조가 이론적인 토대와 실제적인 훈련의 형태에 기초해 있다는 것을 암시했다"
와우.. 빙고다. 소프트웨어 공학은 공학이 아니고 명칭으로써 공학임을 암시하려고 했었다는 것이다. 전자공학처럼 공학이 되기 위해서는 적어도 수학적인 명확성과 반복 가능성을 제시해야 하는데, 소프트웨어 공학은 그렇지 못하다. 소프트웨어 공학 교재들을 보면 이래야 한다는 원론만 난무한다.
머리말 VI
소프트웨어 엔지니어링은 소프트웨어 개발에 대한 "인간 물결(human wave)" 접근 방식을 장려한다. 소프트웨어 엔지니어링은, 고도의 숙련된 개발자를 만드는 방법의 문제를 해결한다기보다는 오히려, 더 많은 사람을 투입함으로써 문제가 풀릴 수 있음을 제시함으로써 소프트웨어 개발의 기술을 없애려고 한다.
소프트웨어공학은 항상 투입 가능한 사람의 문제로 개발을 바라본다. 모든 것들을 사람의 총량으로써 계산하다보니, 문제가 있을 때 마다 사람을 더 투입하려고 한다. 그런데 소프트웨어공학은 개발이란 과정에서 항상 사람이란 요소를 없애려고 노력해왔다. 그 결과 사람이 더 필요하게 되는 역설을 입증하고 있다.
전통적인 노동의 분할은 소프트웨어 개발에는 맞지 않는다.
노동의 분할은 분석가, 디자이너, 프로그래머, 테스터, 사용자 인터페이스 전문가, 문서 작성자, 그리고 지원 담당자들 사이의 업무 분담을 가져온다. 새로운 정보가 개발의 연결 단계들 사이로 전달됨에 따라, 변경은 혼란을 초래하고, 프로젝트는 끝없이 진행된다. 그래서 소프트웨어는 '레거시 애플리케이션" 즉 아무도 진정으로 그것이 어떻게 작동되는지를 알지 못하는 애플리케이션이 된다.
폭 좁은 기술의 인공적인 전문성을 만드는 것에 의해, 소프트웨어 엔지니어링은 한 사람이 전체 애플리케이션을 이해하는 것을 불가능하게 한다. 소프트웨어 엔지니어링에서는, 개발자들이 서로 상대방 분야에 관해서 훈련받지 못한다. 오히려 거기서 장려되는 믿음은, 훌륭한 문서화가 필요의 전부라는 것이다.
