소프트웨어 개발 방법론에 대해서

버전관리 하시나요?
자동 테스트 하시나요?
리팩터링(요즘 남용되는 경향이 있어 이 단어 별로 좋아하지 않습니다만) 하시나요?

셋 중에 하나라도 아니라면 당장 "실용주의 프로그래머" 구해서 보세요.

소프트웨어 개발의 심오한 방법론들이 있는 것은 사실입니다만 기본 없이 그런 것을 해봐야 소용도 없고 기본을 잘 갖추는 것보다 더 큰 향상을 가져오지도 않습니다.

방법론(software development methodology) 보다는
소프트웨어 설계와 개발 계획에 대한 지식이 더 필요하다고 봅니다.

방법론이 중요하긴 하지만 중대형에서나 그렇고
머릿수가 셋 이하에다가 방법론에 익숙치도 않다면 적용해봤자 시간만 날립니다.

그리고 방법론이라는게 어차피 [기획-설계-디자인-이식]의 4단계 무한반복입니다.
차이가 있다면 주요 이벤트(demonstration, regression testing 등)의 배치라던지
구성원간의 커뮤니케이션, 피드백과 요구조건의 수용/처리 방법 등등의
자원(시간,인력,문서 등) 관리 방법 정도가 되겠네요.
그러니까 대학생이 아무리 으쌰으쌰 붙잡아도 어지간해선 의미가 없습니다.
필드에서 한번 뛰는게 가장 좋은 학습 방법이죠 - _-)

전 얼마전에 소프트웨어 공학과 객체지향 설계라는 과목을 들어서 대충 답변을 드릴 수 있을 것 같습니다.

1. 실제 계획한 것과 코딩한 것이 달라지는 경향
바로 코딩을 짜는 경우에만 이런 문제가 생깁니다.
아마 개발 방법론의 모든 베이스가 되는 것이 폭포수 모델인데요
계획서->정의서->분석서->설계서->구현->테스팅->유지보수
순으로 되는 것이 보통입니다.
요구서항 정의서에서 어떤식으로 정의를 해놓았는가? 에따른 부분이 문제가 될것 같은데요.
첫번째로 문제가 되는 것은 정확하게 기억이 나진 않지만, Actor부터 잡고, Actor가 어떤식으로 행동을 해야되는가? 부터 정의를 내리면, 요구사항이 달라지지 않는 이상 절대로 소스를 고칠일이 없습니다.
예를 들자면, queue의 push를 예로 들겠습니다.

요구사항정의서
1. Push
사용자 : 1.1 사용자 입력기능 : 사용자는 시스템에게 값을 입력한다.
시스템 : 1.2 판별기능 : 시스템은 사용자의 값이 숫자인지 판별해야 한다.
1.3 판별확인기능 : 시스템은 1.2의 기능에 대해 숫자가 아니면 숫자가 아니라는 에러메세지를 출력한다.
1.4 시스템 입력기능 :시스템은 현재가지고 있는 큐의 끝에 입력된 값을 추가한다.

정말 간단하게 적은건데요, 이 내용 말고도, 메모리 관련이나, 이런것들의 세세한 내용들을 적어 주어야 나중에 코딩할때 한번에 하고, 쉽게 할 수 있습니다. 지금은 매우 세부적으로 작성하였지만, 회사나 연구소 같은 경우에 세부내용에 대해서는 이미 지침이 있기 때문에 이렇게 까지 세부적으로는 안들어간다고 알고 있습니다.
제가 잘못아는 것이면, 지적질좀 부탁드립니다 선배님들~~~

-시간이 더 걸리는 경우
요구사항 정의하면서 High로 우선순위 정한걸 먼저 해야겠죠...
근데 이렇게 해도 시간이 모자란다는 것은 능력부족이라고 밖에는 할말이... 결론적으로 따지면 그렇다는 겁니다.
시간이 촉박한 상황에서 프로그래밍을 한다면, 일단 되는 부분까지만이라도 구현을 하는것이 옳다고 생각합니다.
과제용이라면, 못한것 보다는 낳을 것이고, 교수님에 따라서 첫번째 레포트 받고 추가보완분에 대해서 안받으시는 분은 거의 없기 때문이니까요..
단, 점수는 어느정도 감점되겠죠... 누군가는 완벽하게 해서 과제를 냈을 테니까요...
결론적으로 시간이 안된다 싶으면, 핵심코어만 짜시는게 어떨까요??

주제 넘게 떠들어 봤습니다.
죄송합니다.