소프트웨어 개발 방법론이 포함 된 작은 연구 논문을 작성하고 있습니다. 사용 가능한 모든 방법론을 조사하고 있었으며 모든 방법론에서 다른 방법론의 기초를 제공 한 것이 있는지 궁금했습니다.
예를 들어,
애자일, 프로토 타이핑, 클린 룸, 반복, RAD, RUP, 나선형, 워터 폴, XP, 린, 스크럼, V- 모델, TDD 와 같은 방법론을 살펴 봅니다.
: 우리는 말할 수
프로토 타이핑, 반복, 나선형과 폭포가있는 사람들을위한 "기초"인가?
아니면 "기초"와 같은 것이없고 각 방법론마다 고유 한 역사가 있습니까?
물론 연구 논문에 모든 방법론을 설명하고 싶지만 그렇게 할 시간이 없기 때문에 어떤 방법론을 대표자로 볼 수 있는지 알고 싶습니다.
답변:
목록의 이름은 모든 방법론이 아니며 다른 수준으로 확장됩니다.
기초가되는 구별은 어려운 일입니다. 역사적 선을 분명히 그릴 수는 있지만 방법론이 다른 것을 기반으로하는 경우는 거의 없습니다. 그것들은 오히려 겹치고 서로 빌리 며 때로는 서로 반응합니다 ... 명백하게 정의 된 분류를 볼 수는 없지만 몇 가지 큰 가족을 요약 할 수는 있습니다.
그것을 보는 또 다른 방법은 세대 관점에서입니다. 엔터프라이즈 소프트웨어 측면에서 우리는 2 세대 방법론을 알고 있다고 말할 것입니다. Waterfall과 V-Model 중 첫 번째는 대부분 다른 공학 분야의 소프트웨어에 적용된 기존 프로세스였습니다. 사람들이 소프트웨어가 완전히 다른 동물이라는 것을 깨닫기 시작했을 때 1 세대 프로세스의 무거움에 반응하여 2 세대 (애자일이라고 불릴 수도 있지만 민첩이라는 용어가 만들어지기 훨씬 전에 시작된)가 시작되었습니다. 소프트웨어와 이러한 기준을 보장 할 수있는 단계는 실제로 구체적이었으며 여전히 탐색해야했습니다.
마지막으로 소프트웨어에서는 다른 분야보다 훨씬 많은 방법이 있지만 방법론은 일을 작동시키기 위해 적용 할 수있는 레시피가 아닙니다. 소프트웨어 개발에는 기술적 측면만큼 많은 인간 측면이 있으며 팀이나 관리자는은 총알 방법론과 맹목적으로 적용해야 할 사항에 대한 점검 목록을 통해 약간의 놀라움을 기대할 수 있습니다. 매년 카오스 보고서와 같은 소프트웨어 프로젝트 성공률에 대한 연구를 살펴보면, 소프트웨어 방법론의 역사는 견고하고 과학적으로 확립 된 반복 가능한 프로세스의 규칙보다 일련의 실패한 시도와 더 관련이 있습니다.
세 가지가 있습니다 :
나머지는 이들의 변형 및 조합입니다.
폭포의 인공물 (시작, 요구 사항, 기능 사양, 디자인 사양, 테스트 사양, 품질 관리 사양 등)은 모두 프로젝트에 중요한 사항을 포함하며 대부분은 다른 방법론에 의해 다루지는 않지만 매우 다른 방법. 예를 들어, TDD에서 기능, 사용자 스토리 및 테스트 설명에는 폭포수의 요구 사항, 기능 사양 및 테스트 사양이 포함됩니다. RUP에는 폭포 사양 (예 : 이해 관계자 문서는 시작 문서의 일부)을 분리하는 더 많은 아티팩트가 추가되지만 나선형으로 진행됩니다.
완료되면 결과에 대한 링크를 게시하십시오. 재미있는 종이처럼 들립니다!
어쩌면 다음과 같은 골동품 방법론 ( '방법론'이 아닌)을 언급하고 싶을 수도 있습니다.
일괄 처리 : 한 벌의 카드를 제출하고 다음날 다시 출력물을 가져옵니다. 단점 : 제출 사이에 너무 많은 시간; 디버깅을 위해 코어 덤프를 연구하십시오.
cli 메소드-vi 또는 emacs를 사용한 다음 컴파일하십시오. 커맨드 라인에서 모든 것은 오늘날까지도 리눅스 쉘에서 수행됩니다. 단점 : 디버그하기가 어렵고 (gdb? 당신은 나를 놀리는가?) 40 세의 쉘 명령을 모호하게합니다.
그냥 생각이야
프로토 타입, 나선형 및 폭포의 세 가지 기본 접근 방식을 언급 할 수 있습니다. Lean, TDD 또는 Cleanroom을 방법론으로 간주하지 않고 방법론의 일부가 될 수있는 프로세스입니다.