Waterfall 소프트웨어 개발 방법론은 여전히 ​​유효합니까?

필자의 경험에 따르면, 폭포수 모델 은 소프트웨어 개발의 현대 세계에서 실행 가능한 방법으로 간주 될 수 있도록 요구 사항 변경에 너무 융통성이없고 반응이없는 것으로 입증되었습니다. 보다 민첩하고 반복적 인 방법에 대한 성장과 입증 된 실적은 누구나 프로젝트 시작에서 제품 제공에 이르기까지 거의 또는 전혀 변화가없는 견고한 블록 프로세스를 따라야하는 이유가 없음을 나타내는 것으로 보입니다.

워터 폴 개발 방법론은 시간, 비용 및 품질과 관련하여 소프트웨어 시스템을 제공하기 위해 여전히 실행 가능한가?

언급 한 폭포수 모델은 실제 프로젝트에서 사용 된 프로세스 모델이 아닙니다. 대신, 그것은 밀짚 꾼입니다. 소프트웨어 프로젝트에 존재하는 주요 단계 및 활동과 이들 간의 가장 기본적인 흐름을 식별합니다. 소프트웨어를 개발하는 방법에 대한 이러한 단순화는 결함이 있으며, 심지어 그러한 방식으로 제시되었습니다.

Wikipedia 기사에서 :

폭포 모델에 대한 최초의 공식적인 설명은 종종 Winston W. Royce에 의해 1970 년 기사로 인용되었지만 Royce는이 기사에서 "폭포"라는 용어를 사용하지 않았습니다. Royce는이 모델을 결함이있는 비 작동 모델의 예로 제시했습니다.

논의 된 논문의 제목 은 대규모 소프트웨어 시스템 개발입니다 . 로이스는 두 번째 페이지에 해당 모델을 제시합니다. 그러나 그림 표현 바로 아래의 텍스트는 계속 읽습니다.

나는이 개념을 믿지만 위에서 설명한 구현은 위험하고 실패를 불러 일으킨다.

그는 개발 단계의 "완료"에 따른 테스트 문제와 여기서 실패로 인해 주요 재 설계 및 코드 변경이 발생할 수있는 방법과 비용 및 일정의 주요 오버런으로 이어지는 방법에 대해 설명합니다. 논문 전체에서 그는 원래 모델을 실제로 프로젝트에서 실행 가능한 모델로 세분화합니다. 결국, 그는 프로토 타이핑, 고객 상호 작용 및 인공물 개선을 소개하는 모델로 끝납니다. 결국 아이디어는 결국 1990 년대 후반과 2000 년대 초에 시작된 민첩한 움직임에 결정적인 결과가됩니다.

귀하의 질문에 대답하기 위해 : 당신이 요구하는 워터 폴은 시간과 예산에 대해 합리적인 품질의 소프트웨어 프로젝트를 제공 할 수있는 실용적인 방법이 아니며 결코 그런 적이 없습니다. 그러나 프로젝트를 수행하고 수행 할 수있는 민첩성과 반대되는 다른 계획 중심 방법론이 있습니다.

사람들은 교과서 폭포 모델을 사용하지 않으며 아마도 가지고 있지 않을 것입니다.

시스템 개발 단계에 대해 생각하게하는 이상적인 이론적 구조입니다. 중요한 점은 코드가 많이 만들어지면 큰 변화를 만들 시간이나 돈이 없기 때문에 가능한 한 빨리 더 큰 변화가 일어나기를 원한다는 것입니다.

프로세스보다는 생각의 방식이라는 사실에도 불구하고 여전히 많은 조직이 소프트웨어 (또는 주택, 잠수함 등)를 만드는 방법에 대해 많은 생각을합니다.

실제로는 단계간에 완전히 엄격한 컷오프가 없으며 소규모 하위 프로젝트의 경우 이전 단계로 되돌아 가기도합니다. 방법론이 말하는 것은 "이것들은 허용되지 않는다"는 것이 아닙니다. 그것이 당신에게 말하는 것은 "이것들은 돈과 시간이 든다는 것"입니다. 그러므로 앞으로 그것을 피하십시오.

Agile Snobs (TM)가 "구식"개발자와 기이하고 작동 할 수없는 폭포수 방법론에 대해 코를 내려다 보는 것은 모두 훌륭하고 좋은 일이지만, 문제는 Agile도 만병 통치약이 아니라는 것입니다. 일부 프로젝트는 애자일을 사용하여 구축 할 수 없으며, 애자일이라고 생각하는 많은 팀은 실제로 부주의하고 조직화되지 않은 것입니다.

방법론은 요점이 아닙니다. 요점은 자신이하는 일과 왜 그렇게 하는지를 생각 하고 합리적인 시간 안에 고객에게 최대한의 가치를 부여하는 것입니다.

민첩성과 가장 자주 비교되는 신화적인 폭포 과정은 존재하지 않았으므로 죽은 것으로 간주 될 수 없습니다. 실제 폭포수 프로세스는 여전히 살아 있고 잘 작동하며 사용자의 기대에 부응하는 예산 소프트웨어를 제 시간에 제공하는 데 탁월합니다.

아마도 당신이 얻는 것을 묻는 더 좋은 방법은 "반복이 적고 공식적인 것이 더 좋을 때"일 것입니다.

이런 경우가 있습니다 :

• 요구 사항이 변경되지 않는 경우

• 새로운 요구 사항을 충족시키는 것이 원래 요구 사항을 100 % 달성하는 것보다 덜 중요합니다.

• 모든 기술 구성 요소가 성숙하고 잘 이해 될 때

어떤 의미에서는 민첩하게 행동 할 수있는 것과 반대되는 견해를 취할 수 있습니다.

거의 모든 기술이 적용 가능합니다. 아무 소용이 없습니다.

그렇습니다. 오늘날에는 더 일반적 으로 사용되는 " V 모델 " 이지만 매우 생생 합니다.

어쨌든 Agile의 문제점은 솔루션이 거의 끝나지 않고 고객이 계속 변경을 요청할 수 있으며 개발이 계속해서이를 해결한다는 것입니다. 시간 및 자재 원가 계산을 기반으로하는 프로젝트의 경우 매우 효과적입니다. 고정 비용이 드는 프로젝트는 그렇지 않습니다.

이러한 고정 비용 프로젝트의 경우 고객은 거의 항상 사전 정의 된 이정표가 진행 상황을 보여줄 것으로 기대하지만, 이는 작업 코드가 아닌 공식적으로 작성된 다양한 형태입니다. 이와 같은 고객의 경우 서면 사양은 프로젝트가되며, 소프트웨어 개발이 2 차 고려 사항입니다 (잘 정의 된 프로젝트가있는 경우 소프트웨어를 쉽게 개발할 수 있다고 가정). 이 회사들은 또한 저렴한 아웃소싱 개발 리소스를 많이 사용하는 회사들입니다.

따라서 고정 된 돈이나 시간을 가지고 있거나 요구 사항이 변경되지 않거나 요구 사항을 변경할 수 없으며 강력한 서면 문서를 제공 할 것으로 예상되는 경우 폭포 모델은 유일한 모델입니다. 이해합니다.

이러한 프로젝트 중간에 애자일을 도입하여 개발을 수행 할 수 있지만, 요구 사항에서 사양이 생성되는 램프 업 단계와 소프트웨어가 현장에서 설치 및 테스트되는 램프 다운 단계가 여전히 남아 있습니다. 애자일은 이러한 경우에 잘 반응하지 않습니다.

누구에게? 내가 처리 한 대부분의 관리자는 여전히 Waterfall 소프트웨어 개발 프로세스를 사용하여 일정을 계획하고 있으며, 상위 수준에서는 일정을 쉽게 계획하는 것처럼 보입니다.

실제로 내가 아는 개발자는 거의 없거나 작동한다고 생각합니다.