Waterfall 프로젝트 관리를 위해 nTask를 사용하는 방법 – 초보자를 위한 실용 가이드

우리는 폭포수 프로젝트 관리에 영향을 미치는 다양한 요소를 광범위하게 분석했습니다. 이는 nTask 프로젝트 관리 소프트웨어를 사용하여 이러한 문제를 해결하는 방법을 단순화하는 데 도움이 되었습니다. Waterfall은 인기 있는 SDLC 프로젝트 관리 모델입니다.

그러나 그것은 여러 가지 점에서 복잡한 것이다. 이 글은 nTask를 사용하여 모든 워터폴 지향 비즈니스 모델과 관련하여 최대 생산성을 달성하는 방법에 대해 자세히 설명합니다. 우리는 폭포수가 구현된 다양한 실제 사용 사례와 예를 설명하고 nTask를 사용하여 해당 프로세스를 더욱 단순화하는 방법 등을 설명하기 위해 더 많은 노력을 기울였습니다.

폭포 프로젝트 관리에 대해 알아야 할 사항은 무엇입니까?

Waterfall 방법론은 프로젝트 관리에 사용되는 전통적이고 가장 일반적인 방법론입니다. 이는 순차적이고 선형적인 프로세스를 따르기 때문에 종종 "선형-순차적 수명 주기 모델"로 설명됩니다. 이름에서 알 수 있듯이 Waterfall은 프로젝트를 고유하고 별도의 독점적인 부분으로 나누어 프로젝트의 수명 주기 계획에 중점을 둡니다. Waterfall 모델에서는 다음 단계가 시작되기 전에 각 단계를 완료해야 합니다.

Waterfall 방법론의 각 단계를 완료하면 실제 폭포처럼 프로젝트의 다음 단계로 이어집니다. 프로젝트의 한 부분이 완료되면 다른 부분을 변경할 수 없으며 다음 작업을 완료하기 위해 단계를 건너뛸 수도 없습니다. 따라서 각 단계는 이전 단계 또는 수준의 완료에 따라 달라집니다. 따라서 폭포 모델은 요구 사항이 잘 정의되고 불확실성이 적은 소규모 프로젝트에 가장 유용합니다. 단순성과 구현 용이성으로 인해 소프트웨어 엔지니어링 및 IT 프로젝트를 위한 시스템 개발 수명 주기(SDLC)의 가장 인기 있는 버전이 되었습니다.

폭포수 모델을 사용할 때는 개발의 나중 단계로 넘어가기 전에 요구 사항과 디자인이 프로젝트의 요구 사항에 맞는지 확인하는 데 중점을 둡니다.

폭포수 프로젝트 관리의 배경

출처 – Codeacademy.com

폭포 모델의 기원은 종종 제조 및 건설 산업에 기인합니다. Waterfall 방법론은 고도로 구조화된 생산 프로세스를 따르기 때문에 이러한 산업에 이상적이었습니다. 요구 사항은 프로세스의 초기 단계에서 명확하게 명시되고 설명되고 나머지 단계는 요구 사항을 기반으로 고안되었습니다. Waterfall 방법론과 마찬가지로 프로젝트 관리 주기의 모든 단계에서 나중에 변경하는 것은 비용이 너무 많이 들 뿐만 아니라 어떤 경우에는 불가능합니다.

Dr. Winston W. Royce는 종종 실수로 "폭포의 아버지"라고 불리며 1970년에 쓴 기사에서 프로세스에 대한 공식적인 첫 번째 설명으로 인정받았습니다. Royce 박사가 설명한 것은 소프트웨어 개발을 위한 결함이 있는 모델이었습니다. 여러 반복 또는 실행이 있는 모델에 대해 주장했습니다. 그는 프로젝트를 여러 번 반복하지 않고 첫 번째 프로토타입을 만들지 않으면 프로젝트가 너무 위험하고 실패할 수도 있다고 주장했습니다. 그의 의견으로는 프로토타입 반복은 프로젝트와 관련된 요구 사항과 기술을 더 잘 이해하고 최종 제품이 고객이 요구하는 것을 제공하는지 확인하는 데 필수적이었습니다.

추가 읽기:

무료 프로젝트 관리 도구에서 찾아야 할 7가지 주요 기능

Royce 박사는 프로세스에 대한 최초의 알려진 설명에 기인한 반면, 최초의 알려진 프레젠테이션은 Herbert D. Benington에 기인합니다. 1956년 6월 29일 Herbert D. Benington은 Symposium에서 디지털 컴퓨터를 위한 고급 프로그래밍 방법에 대한 SAGE용 소프트웨어 개발에 대한 프레젠테이션을 했습니다. 그의 프레젠테이션에서 그는 소프트웨어 엔지니어링에서 이러한 단계의 사용을 설명했습니다. 여전히 "폭포"라는 용어는 프로세스를 설명하는 데 사용되지 않았습니다.

Wikipedia에 따르면 Bell과 Thayer는 1976년 논문에서 "Waterfall"이라는 용어를 처음으로 사용했습니다.

1980년대에 폭포 모델은 그 경직성 때문에 심한 비판을 받았습니다.

소프트웨어 개발 산업의 변화하는 요구와 조기 피드백을 제공하는 폭포 모델의 선형성 실패로 인해 폭포 모델의 많은 버전이 등장했습니다. 이러한 버전을 집합적으로 수정된 폭포 모델이라고 합니다.

보다 현대적인 폭포 모델에는 수정을 허용하기 위해 이전 단계에 대한 피드백 루프가 있습니다. 폭포 모델의 다른 버전은 Peter DeGrace의 "사시미 모델"(겹치는 단계의 폭포), V-모델 또는 벤트 폭포 모델 등입니다.

폭포수 방법론과 그 진화 – 전통적인 폭포수 모델

1970년대부터 기업과 프로젝트는 프로젝트 관리를 위해 Waterfall 방법론을 사용했습니다. A 지점에서 시작하여 끝 부분에 도달하기 위해 순차적인 단계를 따르는 간단한 흐름도를 활용하는 것은 이해하기 쉬웠을 뿐만 아니라 구현하기도 했습니다. Waterfall 방법론의 단계는 프로젝트 개발 주기의 후반부에 비용이 많이 드는 수정을 방지하기 위한 목적으로 Dr. Royce에 의해 개발되었습니다. Royce 박사는 자신의 경험에 비추어 볼 때 폭포 모형이 실패의 위험과 함께 어떻게 나타나는지 설명하려고 했습니다.

Royce의 원래 폭포수 모델에서 그는 크고 복잡한 소프트웨어 개발 프로젝트에서 이러한 단계의 중요성을 강조하기 위해 이러한 단계를 설명했습니다. 그는 또한 단계가 다르게 계획되고 실행되기 때문에 리소스를 최대한 활용하려면 팀에 이러한 단계를 가장 잘 수행할 수 있는 사람들이 포함되어야 한다고 지적하고 싶었습니다.

폭포 모델의 일반적인 단계

폭포 모델의 다양한 단계는 프로젝트 프레임워크 및 요구 사항에 따라 수정, 제거 또는 증대될 수 있습니다.

일반적인 폭포수 모델의 순차적 단계는 다음과 같습니다.

1. 구상 : 이 단계는 프로젝트에 대한 아이디어가 발아되는 단계입니다. 이 단계에는 프로세스에 대한 대략적인 평가가 포함됩니다(예: 프로젝트에 유익한지, 관련 비용 등).
2. 착수( Initiation) : 개념화 후, 프로젝트 팀을 고용하고 목표, 범위, 목적 및 결과물을 정의함으로써 프로젝트가 시작됩니다. Waterfall Model은 요구 사항과 디자인이 프로젝트의 요구 사항에 맞는지 확인하는 것을 강조하므로 이 단계는 중요합니다.
3. 요구사항 수집 및 분석 : 가능한 모든 프로젝트 요구사항을 팀에서 수집하고 분석하여 프로젝트의 타당성을 확인합니다. 이를 위해서는 팀이 클라이언트의 비즈니스 모델을 이해하고 프로젝트와 관련된 잠재적 위험을 분석해야 할 수도 있습니다. 이 단계에서 생성된 모든 정보는 요구 사항 사양 문서에 문서화됩니다.
4. 설계 : 이 단계에서는 요구 사양을 연구, 평가하고 프로젝트 완료를 위한 시스템 설계를 준비합니다. 하드웨어 및 소프트웨어 요구 사항이 식별되고 전체 시스템 아키텍처가 정의됩니다. 이 단계에서 만들어진 설계 사양은 코딩 단계에서 사용됩니다.
5. 구현/코딩 : 설계 사양에 따라 실제로 개발/코딩이 시작되는 단계입니다. 프로젝트 관리자는 컴파일러, 디버거, 인터프리터 및 미디어 편집기와 같은 도구를 사용하여 일반적으로 프로그래머, 인터페이스 디자이너 및 기타 전문가로 구성된 팀 구성원 간에 작업을 위임합니다. 프로젝트의 성격과 팀 규모에 따라 팀은 더 작은 단위로 나뉩니다.
6. 대부분의 경우 시스템은 먼저 단위라고 하는 작은 프로그램으로 개발되고 다음 단계로 통합됩니다. 각 단위가 개발됨에 따라 단위 테스트라고 하는 기능에 대해 테스트됩니다. 이 단계의 최종 출력은 미리 정의된 코딩 표준에 따라 구축되고 시스템 아키텍처 요구 사항을 충족하기 위해 디버깅, 테스트 및 통합되는 하나 이상의 제품 구성 요소일 수 있습니다. 팀 규모에 관계없이 모든 요구 사항이 충족되도록 하려면 협업과 조정이 중요합니다.
7. 테스트 : 개발된 모든 단위가 통합되면 개발된 전체 시스템에 오류가 있는지 테스트합니다. 이 단계에서 클라이언트의 기대치에 대한 준수도 확인됩니다.
8. 배치 : 모든 테스트가 완료되면 제품 또는 프로세스가 고객에게 전달되거나 시장에 출시되거나 구현됩니다. 이 과정에서 널리 퍼진 모든 산업별 지침, 규정 및/또는 조직 지침을 엄격하게 준수해야 합니다. 또한 최종 구현의 성공 여부를 확인하기 위해 구현 후 검증 및 테스트를 수행해야 합니다.
9. 유지 관리 : 최종 사용자가 문제를 식별한 경우 개발 팀은 제품의 효율성을 보장하기 위해 제품을 해결, 변경 또는 수정해야 합니다. 유지 관리 기간은 일반적으로 사전에 동의한 지정된 기간 동안입니다.

다이어그램 2: 소프트웨어 개발을 위한 일반적인 폭포수 모델의 기본 표현

폭포 PM 모델의 인기

로이스 박사가 사람들에게 모델의 함정에 대해 경고하려고 시도했음에도 불구하고 폭포 모델이 유비쿼터스 인기를 얻은 이유는 무엇입니까?

Waterfall 방법론은 프로젝트 관리에 사용되는 가장 일반적인 방법론입니다. 이 모델은 "폭포"라는 이름이 붙기 전부터 다양한 산업 분야에서 사용되었습니다. 폭포 모델의 인기와 널리 사용되는 주요 이유는 다음과 같습니다.

• 이해, 사용 및 관리 용이

대부분의 프로젝트 관리자는 폭포 모델의 구조가 프로젝트의 수명 주기를 따르므로 이해하고 구현하기 쉽다는 것을 알게 됩니다. 또한 팀을 교육하고 Waterfall 방법론에 익숙해질 필요가 없습니다. 전체 프로세스의 경직성으로 구현 및 제어가 간단할 뿐만 아니라 프로젝트 관리 부담도 줄어듭니다.

• 규율

Waterfall Model의 명확하게 구조화된 접근 방식은 모니터링하기 쉽고 각 단계가 완료될 때 프로젝트 관리자와 클라이언트가 가시적인 진행 상황을 볼 수 있습니다. 요구 사항 및 설계 단계에 최대한 많은 시간을 할애하기 때문에 팀이 기한을 놓칠 가능성이 크게 줄어듭니다.

• 품질 및 상세 문서

문서는 초기 단계부터 유지 관리되고 업데이트됩니다. 문서가 업데이트되는 엄격한 방식을 통해 팀과 고객 간에 전달될 내용에 대해 완전히 이해하게 됩니다. 이는 계획 및 설계를 보다 간단하게 만들 뿐만 아니라 이해 관계자가 특정 단계에 대해 더 자세한 정보를 확인해야 하는 경우 도움이 됩니다.

• 최소한의 고객 참여

폭포수 모델은 요구 사항이 명확하게 정의되고 이해되면 고객의 존재가 엄격하게 요구되지 않는 방식으로 설계되었습니다. 이는 팀의 추가 부담을 제거하고 프로젝트의 후반 단계에서 새로운 변경 사항이 도입되는 것을 방지하여 프로젝트를 적시에 완료할 수 있도록 합니다.

• 세분화

Waterfall Model의 유연성은 프로젝트가 어느 단계에 있는지에 따라 팀의 다양한 구성원이 다른 프로젝트에 참여하거나 계속 작업할 수 있도록 합니다. 각 개발 단계에 대해 예정된 마감일을 설정하면 프로젝트가 개발 프로세스를 통해 자원을 순차적으로 확보할 수 있습니다. .

• 품질 보험

이 모델은 요구 사항이 명확하고 엄격하게 정의되어 있고 나중에 요구 사항을 변경할 수 없는 프로젝트에 이상적입니다. 또한 Waterfall 모델은 시간이나 비용 문제보다 제품 품질이 우선시되는 프로젝트에 이상적입니다.

더 많은 프로젝트에서 Waterfall 프로젝트 관리 모델을 사용하지 않는 이유는 무엇입니까?

폭포수 모델의 가장 큰 장점 중 일부는 프로젝트의 성격에 따라 단점으로 바뀝니다.

소프트웨어 개발 프로젝트에 대한 Waterfall 방법론의 가장 큰 한계는 장기 또는 대규모 프로젝트에 적합하지 않다는 것입니다. 기타 단점은 다음과 같습니다. (6)

• 변경 또는 수정이 거의 또는 전혀 없음:

명확하고 잘 정의된 요구 사항에 대한 폭포 모델의 강조는 일단 완료되면 요구 사항의 변경이 어려울 뿐만 아니라 비용도 많이 든다는 것을 의미합니다. 따라서 폭포 모델은 요구 사항이 모호한 프로젝트에는 적합하지 않습니다. 이는 또한 장기 프로젝트에서 소프트웨어 및 하드웨어의 변경 사항을 해결하기 어려울 수 있음을 의미합니다. 이것은 또한 예상치 못한 프로젝트 발생이 이 방법을 사용하여 해결할 수 없음을 의미합니다.

• 제품 배송 지연:

모델의 초기 단계는 요구 사항을 이해하는 데 전념하므로 소프트웨어 개발은 ​​프로젝트 수명 주기의 후반부에 시작됩니다. 이는 이해 관계자가 프로젝트 수명 주기 후반까지 소프트웨어를 볼 수 없음을 의미합니다.

• 정확하고 완전한 요구 사항 수집의 비현실성 :

초기 단계에서 명확하고 잘 정의된 완전한 요구 사항을 수집하는 것은 어려울 뿐만 아니라 일부 프로젝트의 경우 비현실적일 수도 있습니다. 종종 고객은 프로젝트 수명 주기 초기에 모든 요구 사항을 명확하게 파악하지 못하고 프로젝트가 진행됨에 따라 요구 사항을 배우고 명확히 합니다.

폭포 모델의 현대적 묘사

다양한 단점에도 불구하고 최신 폭포 모델은 가장 일반적인 소프트웨어 개발 수명 주기(SDLC) 모델 중 하나입니다. Waterfall Model의 최신 버전에는 납품 후 유지 관리를 포함하여 프로젝트 수명 주기 전반에 걸쳐 피드백 루프가 포함되어 있습니다.

이 모델에서 테스팅은 별도의 단계가 아니라 소프트웨어 프로세스 전반에 걸쳐 지속적으로 수행됩니다. 이는 소프트웨어가 필요에 따라 작동할 뿐만 아니라 추가 요구 사항도 설계에 통합되도록 유지 관리 단계에서 특히 중요합니다.

Modern Waterfall Model은 소프트웨어가 폐기될 때까지 개발 및 유지 관리 중에 취해야 할 경로를 명확하게 보여줍니다. Modern Waterfall Model은 전통적인 Waterfall 모델의 많은 문제를 제거하지만 자체 문제가 있습니다. 예를 들어, 각 단계의 완료에는 해당 단계에 대한 완전한 품질 문서화와 소프트웨어 품질 보증(SQA) 그룹의 승인이 포함되며 이는 수정 사항이 있는 경우에도 수행되어야 합니다. 완전한 문서를 유지해야 한다고 주장하면 지연과 불필요한 서류 작업이 발생할 수 있습니다.

현금 인출을 위한 ACME Super ATM 사용 사례 모델

간단한 설명:

이 사용 사례는 은행 고객이 ATM을 사용하여 은행 계좌에서 돈을 인출하는 방법을 설명합니다.

배우:

아래 그림은 ACME Super ATM 사용 사례 모델의 모든 행위자를 보여줍니다.

행위자는 고객, 은행 시스템, 서비스 관리자 및 보안 관리자를 포함합니다.

전제 조건:

• 은행 고객은 은행 카드를 소지해야 합니다.
• 은행 시스템에 대한 네트워크 연결이 활성화되어 있어야 합니다.
• 시스템에는 분배할 수 있는 최소한의 현금이 있어야 합니다.
• 현금 인출 서비스 옵션을 사용할 수 있어야 합니다.

참조:

전문가처럼 해결하기 위한 5가지 일반적인 프로젝트 관리 과제 및 솔루션

기본 흐름:

• 카드 삽입
• 카드 읽기
• 고객 인증
• 출금 선택
• 시스템은 현재 컴퓨터에서 사용할 수 있는 다양한 서비스 옵션을 표시합니다.
• 금액 선택
• 시스템은 표준 출금 금액 목록을 표시하여 출금 금액을 묻습니다.
• 출금 확인
• 수중에 있는 자금 평가 수행
• 행위 거래 수행
• 카드 꺼내기
• 고객이 기계에서 은행 카드를 가져옵니다.
• 현금 지급
• 시스템이 고객에게 요청한 금액을 분배합니다.
• 시스템은 출금에 대한 거래 로그 항목을 기록합니다.
• 사용 사례 종료

대체 흐름:

대체 흐름에는 다음 시나리오에 대한 흐름이 포함됩니다.

• 비표준 금액의 출금 처리
• 읽을 수 없는 은행 카드 처리
• 영수증 처리
• 오류 처리
• 은행 시스템 응답 중지 처리

예외 흐름:

예외 흐름에는 다음 시나리오에 대한 흐름이 포함됩니다.

• 보유 자금 평가
• 철회 수행
• 서비스 종료
• 거래 조정 처리

포스트 조건:

• ATM이 카드를 반환하고 고객에게 현금을 지급하고 고객의 계좌에 출금이 등록됩니다.
• ATM이 고객에게 카드를 반환했으며 고객의 계정에 출금이 등록되지 않았습니다.
• ATM이 카드를 반환했지만 고객의 계좌에서 인출된 것으로 등록된 현금 금액을 제공하지 않은 경우 불일치는 ATM의 로그에 등록됩니다.
• ATM에 카드가 보관되어 있고 고객의 계정에 출금이 등록되지 않았으며 고객에게 자세한 정보를 문의할 수 있는 곳이 안내되어 있습니다.

공공 확장 지점:

없음

특별 요구 사항

• 안정적인 현금 지급

현금 인출을 위한 ACME Super ATM 사용 사례 모델에서는 모든 요구 사항이 고정되어 있고 명확하게 정의되어 있으므로 Waterfall 모델이 이 예에 이상적입니다. 요구 사항이 기록되면 고객의 피드백이 거의 필요하지 않으며 라이너 순차 패턴에 따라 개발 및 설계 단계를 완료할 수 있습니다. nTask와 같은 프로젝트 관리 소프트웨어의 도움으로 프로젝트를 쉽게 관리할 수 있으며 각 단계는 요구 사항에 따라 명확하게 정의되고 분류됩니다.

고객 인증을 위한 ACME Super ATM 사용 사례 모델

간단한 설명:

이 사용 사례는 ATM을 사용하는 개인(고객)이 삽입된 은행 카드를 사용할 권한이 있고 은행 카드와 연결된 계정이 활성 상태인지 인증하는 데 사용됩니다.

배우:

행위자는 고객, 은행 시스템, 서비스 관리자 및 보안 관리자를 포함합니다.

전제 조건:

• 은행 카드가 ATM에 삽입되었습니다.
• 은행 카드 정보를 성공적으로 읽었습니다.
• 고객이 포함된 사용 사례와 대화 중입니다.
• ATM 세션 ID가 생성되었습니다.

기본 흐름

• 카드 정보 확인
• 시스템은 은행 시스템에 은행 카드 정보를 보냅니다.
• 시스템은 또한 ATM ID와 ATM 세션 식별자를 은행 시스템으로 보냅니다.
• 은행 시스템은 은행 카드 정보가 유효하고 카드를 사용할 수 있음을 인정합니다.
• 사용자 신원 확인
• 시스템에서 고객에게 PIN을 묻는 메시지를 표시합니다.
• 고객이 PIN을 입력합니다.
• 시스템에서 입력한 PIN이 은행 카드에서 읽은 PIN과 동일한지 확인합니다.
• PIN 확인됨
• 사용 사례 종료

대체 흐름:

대체 흐름에는 다음 시나리오에 대한 흐름이 포함됩니다.

• 은행 시스템과의 통신 없음 처리
• 고객의 은행과 통신 금지
• 비활성 카드 또는 계정 처리
• 도난당한 은행 카드 처리
• 잘못된 은행 카드 정보 처리
• 올바른 PIN이 입력되지 않은 경우 처리
• 오류 처리
• 은행 시스템 응답 중지 처리

예외 흐름:

예외 흐름에는 다음 시나리오에 대한 흐름이 포함됩니다.

• 보유 자금 평가
• 철회 수행
• 서비스 종료
• 거래 조정 처리

포스트 조건:

• 고객은 카드를 사용할 권한이 있습니다.
• 고객은 카드 사용이 금지되었으며 카드는 압수되었습니다.
• 고객은 카드 사용이 금지되었으며 카드는 압수되지 않았습니다.

공공 확장 지점

없음

특별 요구 사항

없음

ACME Super ATM Use-Case Model to Authenticate Customer에서는 모든 요구 사항이 고정되어 있고 명확하게 정의되어 있습니다. 프로젝트 크기가 작고 엄격한 프로세스를 통해 쉽게 완료할 수 있습니다. 요구 사항이 확인되면 개발 및 설계 단계를 선형 프로세스로 완료할 수 있습니다. nTask와 같은 프로젝트 관리 소프트웨어의 도움으로 프로젝트를 쉽게 관리할 수 있으며 각 단계는 요구 사항에 따라 명확하게 정의되고 분류됩니다.

산업 응용 – 미국 국방부

Waterfall 방법론의 사용에 대해 널리 참조되는 예는 미국 국방부의 사례입니다. 1985년에 미 국방부는 소프트웨어 개발 계약자와 협력하기 위한 표준인 DOD-STD-2167A에서 Waterfall 접근 방식을 사용했습니다. 방법론을 "폭포"로 지정하지 않았지만 미국 국방부(DOD)는 여전히 폭포 모델의 기본 원칙을 사용합니다.

미국 정부는 폭포 모델의 장점이 요구 사항을 완벽하게 충족했기 때문에 폭포 모델로 결정했습니다. 연방 정부는 최종 제품에 대한 큰 통제를 유지하면서 엔지니어링 엄격함과 우수한 품질의 제품을 주장했습니다. 이는 6단계(예비 설계, 세부 설계, 코딩 및 단위 테스트, 통합 및 테스트)를 포함하는 것과 함께 광범위한 문서, 단일 패스, 순차적 개발 방법에 대한 강한 선호도 및 과도한 감독과 함께 DOD를 만듭니다. -STD-2167 폭포수법의 가장 좋은 예.

1986년에 하향식 설계에 대한 강조를 제거하고 폭포수에 대한 대안으로 신속한 프로토타이핑의 사용을 제안한 MIL-STD 2167에 대한 개정판 A의 초안 사본이 나타났습니다. 당시 폭포수 모형에 대한 비판이 거셌기 때문이다. DOD가 Waterfall 방법론과 거리를 두고 있음에도 불구하고 미국 연방 소프트웨어 개발 및 인수는 여전히 강력한 하드웨어 지향 및 폭포 접근 방식을 유지했습니다.

National Research Council의 2010년 보고서는 엔지니어링 및 제조 개발 단계를 설명하는 데 사용되는 용어 중 얼마나 많은 용어가 예비 설계 검토 및 중요한 설계 검토와 같은 폭포 모델의 요소에 초점을 맞추고 있는지 강조했습니다. Waterfall 프로젝트 관리 방법론에 대한 이러한 강조는 품질과 기밀성에 대한 강조가 증가했기 때문일 수 있습니다. 폭포수 모델의 개별 단계에서는 팀의 모든 구성원이 전체 프로젝트에 참여하는 것은 아닙니다.

2000년에 DODI(DOD Instruction) 5000.2는 진화적 획득을 선호하는 획득 접근 방식으로 식별했습니다. 그러나 5000 시리즈 규정은 폭포수 모델에 특정한 용어가 지배적입니다. Waterfall Model의 상표인 PDR(Preliminary Design Review)과 CDR(Critical Design Review)은 모든 프로그램에 대해 규정되어 있습니다.

Waterfall 프로젝트 관리 모델이 당신에게 적합합니까?

많은 단점과 제한 사항에도 불구하고 폭포 모델은 오늘날에도 여전히 사용됩니다. 그러나 하나의 프로젝트 관리 방법이 모든 비즈니스의 요구 사항에 맞는 것은 아니며 동일한 비즈니스에서 처리하는 모든 프로젝트도 마찬가지입니다. 따라서 프로젝트 요구 사항에 이상적인 모델인지 여부는 다양한 요인에 따라 다릅니다.

비즈니스는 유형, 규모, 산업 및 기타 여러 요인에 따라 다르므로 프로젝트도 마찬가지입니다. 기업은 최상의 방법론을 찾기보다 이러한 방법론, 용도 및 응용 프로그램을 학습하고 다음 변수에 따라 최적의 방법론을 결정해야 합니다.

• 조직 목표
• 핵심 가치
• 프로젝트 제약
• 프로젝트 이해 관계자
• 프로젝트 규모
• 프로젝트 비용
• 위험을 감수하는 능력
• 유연성 필요

Waterfall Model은 최종 제품의 요구 사항은 고정되어 있지만 시간과 비용은 가변적인 기업에서 사용합니다. 폭포 모델을 사용하면 프로젝트 관리자가 원하는 결과에 도달할 때까지 동일한 프로젝트를 여러 번 시작할 수 있습니다. 많은 기업이 최적의 결과에 도달할 때까지 접근 방식을 조정하고 재고하는 것이 바람직하다고 생각하는 Waterfall 방법론의 기본 제공 메커니즘을 찾지 못할 것입니다.

Waterfall 방법론은 명확하게 이해되고 고정되고 문서화된 요구 사항, 잘 이해된 기술 도구, 아키텍처 및 인프라, 필요한 전문 지식을 갖춘 충분한 리소스에 대한 액세스, 안정적으로 잘 정의된 제품 및 짧은 수명 주기가 있는 프로젝트에 이상적입니다. 폭포수 모델의 선형 접근 방식은 초기 제품 요구 사항에 대한 발견 또는 변경을 허용하지 않습니다. 요구 사항이 변경되면 프로젝트가 1단계로 돌아가고 전체 프로세스가 처음부터 다시 시작되어야 합니다. 이것은 대부분의 산업이 엄격한 일정에 따라 작업하는 많은 산업에서 심각한 문제가 될 수 있습니다.

다음 표는 꽤 도움이 됩니다. 구경하다.

표 1: 폭포수 모델 요구 사항

프로젝트 관리 방법론은 오늘날의 비즈니스에 매우 중요합니다. 비즈니스에 적합한 스타일을 사용하여 팀이 협업하고, 작업을 수행하고, 프로젝트 이정표를 달성하는 방식을 혁신할 수 있습니다.

소프트웨어 산업에서의 응용

Waterfall Model은 소프트웨어 산업에서 제품의 요구 사항이 명확하게 정의되어 있을 때 널리 사용됩니다. Royce에 따르면 가장 간단한 프로그램은 분석과 코딩의 두 단계로 완료할 수 있습니다. 그러나 더 복잡한 프로그램의 경우 더 많은 계획이 필요할 수 있습니다.

모든 소프트웨어 개발의 첫 번째 단계는 기능 사양을 만드는 것입니다. 폭포수 모델이 효과적이려면 이러한 사양을 잘 계획하고 명확하게 정의하는 것이 중요합니다. 여기에는 비즈니스 전문가와 대화하고 비즈니스 프로세스를 더 잘 이해하기 위해 현재 수동 또는 레거시 컴퓨터 시스템으로 처리되는 비즈니스 프로세스를 검토하는 것이 포함됩니다.

또한 참조하십시오 : JIRA는 오늘날 시장에서 비생산적인 프로젝트 관리 소프트웨어입니까?

요구 사항이 기록되면 비즈니스 전문가와 고객이 확인해야 합니다. 기능 사양이 완성되면 요구 사항의 최종 사본이 작성되고 잠겨 있습니다.

그 다음에는 사용자 인터페이스와 함께 작동하지 않는 프로토타입 애플리케이션이 생성됩니다. 이는 클라이언트와 개발자가 제품이 어떻게 작동하는지 이해하는 데 도움이 됩니다. 이 단계가 완료되면 소프트웨어 개발이 시작됩니다.

애플리케이션이 완료되고 테스트되면 베타 릴리스가 게시되고 테스트를 위해 제공됩니다. 발견된 모든 버그는 신속하게 복구됩니다. 심각한 버그가 남아 있지 않으면 애플리케이션이 릴리스 버전 1.0으로 출시될 수 있습니다.

자동차 산업 신청

건설 및 제조와 같은 산업에서는 Royce 박사가 1970년에 논문을 발표하기 전부터 폭포 모델을 사용하고 있습니다. 자동차 산업의 조립 및 제조 프로세스는 엄격하고 공장이 설정되면 약간의 조정이 필요합니다. 따라서 공장이 설정되기 전에 주요 요구 사항을 논의하고 결정하고 요구 사항을 염두에두고 설계 및 생산 프로세스를 설정합니다.

조립 프로세스 자체는 그대로 수행해야 하는 일련의 작업을 따릅니다. 그렇지 않으면 전체 프로세스가 붕괴됩니다. 한 단계가 완료되어야만 프로세스가 다음 단계로 넘어갈 수 있습니다. 요구 사항을 변경하려면 프로세스를 완전히 점검해야 하고 추가 시간과 비용이 필요할 수 있습니다.

nTask 대 SDLC의 폭포

Waterfall Model이 귀하의 요구에 가장 적합한 모델이라고 결정했으면 nTask와 같은 클라우드 기반 협업 프로젝트 관리 시스템의 사용을 고려해야 합니다. nTask와 같은 협업 도구는 사용하는 프로젝트 관리 방법에 관계없이 팀의 생산성과 효율성을 높이도록 특별히 설계되었습니다.

nTask를 사용하면 다양한 크기의 프로젝트를 쉽게 관리하고, 작업을 할당 및 위임하고, 파일과 정보를 실시간으로 공유하고, 모든 프로젝트 관리 요구 사항을 충족할 수 있습니다.

폭포수 방법론을 시도하기로 결정했습니까? 이 방법 내에서 문서화의 중요성을 보았으므로 첫 번째 단계는 필요한 모든 작업을 추적하고 이를 팀과 공유할 플랫폼을 찾는 것입니다.

nTask는 요구 사항을 수집하는 순간부터 테스트 단계까지 도움이 될 수 있습니다.

• 각 단계의 기간 및 관련 이해 관계자를 관리하고 명확하게 설명합니다.
• 모든 관련 이해 관계자와 실시간으로 모든 요구 사항을 수집, 논의 및 문서화합니다. nTask를 사용하면 다음 단계는 이전 단계가 완료될 때만 시작되며 완전한 문서화 및 승인이 뒤따를 것입니다.
• 최종 요구 사항에 따라 팀을 위한 워크플로를 만듭니다. nTask를 사용하면 프로젝트 진행 상황을 명확하게 볼 수 있으며 폭포 모델의 각 단계에서 각 작업에 대한 피드백을 제공할 수 있습니다.
• nTask를 사용하면 전체 팀 또는 팀의 일부와 쉽게 협업하고 의사 소통할 수 있습니다.
• nTask를 사용하면 폭포 모델의 각 단계에 대한 완전한 문서를 작성, 유지 관리 및 공유하는 것이 쉽습니다. 문서를 볼 수 있는 사람을 제어하여 관련 정보만 팀 구성원과 공유할 수 있습니다.

이 시점에서 우리는 끊기는 것을 싫어하지만 이것은 두 부분으로 된 게시물입니다. 추가 업데이트를 위해 이 페이지를 북마크하고 1~2주 후에 후속 조치를 잊지 마십시오. 지금까지 공유할 내용이 있으면 아래 댓글 섹션을 통해 공유할 수 있습니다. 또는 [email protected]으로 이메일을 보낼 수 있습니다. 다시 연락드리겠습니다.

또한 읽기:

• 2022년 최고의 무료 생산성 앱 21개
• 개인 작업 관리를 위한 2022년 최고의 할 일 목록 앱 23개
• 2022년 프로젝트 관리자를 위한 10가지 필수 프로젝트 관리 기술
• GTD(작업 완료) 방법 및 14가지 최고의 GTD 앱 및 도구
• 팀 생산성 향상을 위한 19가지 시간 추적 소프트웨어
• 2022년 스타트업을 위한 27가지 최고의 작업 관리 소프트웨어
• 2022년 최고의 무료 생산성 앱 36개
• 개인 작업 관리를 위한 2022년 최고의 할 일 목록 앱 30개
• 2022년 애자일 팀을 위한 22가지 최고의 무료 프로젝트 관리 도구
• 가상 팀 관리: 과제, 팁 및 가상 팀 관리 도구
• 협업 및 동기 부여를 기념하는 47가지 최고의 팀 작업 인용문