토론:소프트웨어 개발 방법론

문서 내용이 다른 언어로는 지원되지 않습니다.
위키백과, 우리 모두의 백과사전.

다소 주관적일 수도 있는 부분을 토론 부분에 옮겨옵니다. 그리고 왜 한국어에서 '방법론'과 '방법'에 대한 구분이 있어야하는지 모르겠습니다. 영어에서는 Methodology와 methodology의 차이가 말할 때 나지 않으므로 혼돈의 여지가 있다고 해도, 한국어에는 그러한 오해의 소지가 없습니다. --최종욱 2007년 11월 22일 (목) 14:08 (KST)[답변]

비평[편집]

프로그래머를 위한 알고리즘 1
많은 방법론은 프로그래머가 따르는 알고리즘을 정의하려는 시도같은 것이라고 생각되어진다.이것은 소프트웨어를 비인각적이고 할 가치가 적은 것으로 만든다.이것은 프로그래머의 의욕과 직업 만족도를 떨어뜨린다.프로그래머들은 대부분의 고정적 방법론들을 거부했다.

반론:대부분의 노동자들은 가능한 한 계약을 거부한다.계약을 수행하지 못했을때 자존심을 상할 수 있다.그럼에도 불구하고 그 계약이 새로운 일에 적합하지 않은 구태의연한 것일때 모든 계약내용을 지킬 필요는 없다는 것이 적절하다.이런 경우에 프로그래머는 주어진 방법이나 방법론에 변경을 제안할 수 있어야만 하고 그 변경이 받아들여질 수 없을 때는 적절한 설명을 받아야 한다.

프로그래머를 위한 알고리즘 2
방법론을 정확히 정의할 수 있다면 프로그램에서 구현되고 컴퓨터는 그것을 수행해야 한다.방법론이 프로그램으로서 작동하지 않는 이유는 유용하게 정의되기에는 너무 모호하다는 것이다.
모든 사람들이 이미 알고 있는 것
대부분의 방법론들은 객체 지향 언어의 사용, 구현하기 전의 사전 충족조건의 만족들 같은 널리 알려진 도구나 실행 방법으로 구성되어 있다.많은 방법론은 최신 기술을 명확히 나열하지만 널리 알려지지 않은 것들에 대해선 아무것도 없다.
더이상 방법론은 없다.
최근 Karl Weigers같은 이들은 더이상 방법론은 없다고 주장했다.방법론들은 최신 기술과 실행 방법을 나열하려는 경향이 있고 모두가 그것들을 사용해야 한다고 주장한다.이 주장은 새로운 시스템에서 작업하는 이들과 최신 기술과 실행 방법을 사용할 기회가 있는 이들에게는 소용이 있다.그러나 이 주장은 작업환경에 의해 기존 시스템을 유지하고 기존 도구를 사용하고 기존 기술과 실행 방법을 사용해야하는 이들에게는 소용이 없다.그러므로 방법론은 특정한 시기의 최신 기술을 나열한 것 이상으로서의 가치는 거의 없다.그리고 방법론은 기술과 실행 방법이 발전하면 계속 업데이트되어야 한다.

반론:기존 시스템의 관리자는 기존 방법론의 사용에 완전히 자유롭다.그리고 모든 프로젝트는 기본 법칙을 가지고 있는데 어떤 분야든지 절대 불변의 법칙은 없다는 것이다.이 법칙을 적용하면 도구나 어휘가 방법론을 만들고 있다는 것이다.모든 성공적인(그리고 많은 실패한) 대규모 팀들은 그렇게 하고 있다.

보강:방법과 방법론은 프로젝트에 적합한 창조적 방법으로 이용되어야 한다.기존 코드와 자료를 새로운 표준에 따라 고치는 비용을 고려하지 않고 기존 프로젝트를 변경하거나 새로운 프로젝트에 맹목적으로 사용되거나 하여서는 안된다.

전망
방법론은 그 자체만으로는 명확한 전망이 없다면 의미가 없다.전망은 용어,프로세스,프로시져 등을 포함할 수 있다.전망이 관리가 안되고 해답이 안나올 때는 문제가 어떻게 접근되는지는 의미가 없다.즉 방법론은 개개인의 스타일일 뿐만 아니라 가장 좋은 결과를 도출할 수 있냐의 문제이다.이런 맥락에서 방법론은 어느 정도 익숙할 필요는 있지만 개개인의 작업 스타일과 문제 해결 방법은 결국 개개인의 몫이다.그러면 창조성이 과학이라는 고정 관념에 의해 경직되지 않는다.
통신,합의,유지
우선 더 효율적이고 독창적인 프로그램은 소스 주석으로 설명되 있지 않으면 다른 프로그래머에게는 무척 어렵다는 것은 일반적인 상식이다.그러나 낭비되는 시간과 돈보다 중요한 것은 종종 모두가 알지는 못하거나 적어도 같은 것을 알지는 못한다는 것이다.최후의 테스트가 그것을 발견하는 가장 좋은 곳은 아니다.프로그래머의 프로그램의 목적과 다른 팀원들과 통신한 방법에 대한 자료가 가장 간단한 방법과 방법론이다.

불행히도 서로 교환한 말들이나 간결한 이메일들이 인간 노력에서 통신 오류의 주요한 원천이다.상술이 없다면 어느 일부의 소프트웨어 프로그래머는 잘못된 일을 정확히 할 지도 모른다.상세한 배경지식이 없는 같은 말이 서로 다른 프로그래머에게는 완전히 다른 말이 될 지도 모른다.추가적으로 법같은 외부적 고려나 입출력 데이타의 성질이나 폼같은 정보가 부족해 잘못 프로그램될 수도 있다. 또한 관리자가 프로그래머가 경험이 없는 분야에서 프로그램을 정확히 하기위한 확인을 원할 지도 모른다.