엣지 컴퓨팅 제품 개발 및 시스템 개발에서의 PoC-위험 회피 개념

제품 개발 및 시스템 개발에서의 PoC-위험 회피 개념

엣지 컴퓨팅은 여전히 새로운 개념이며, 많은 사용자가 PoC를 통해 채택하는 것을 고려하고 있다고 생각합니다. 그건 그렇고, PoC라는 단어를 들어 본 적이 있습니까? 인터넷에서 검색하면 나오겠지만 일반 대중에게는 익숙하지 않은 단어일 수 있습니다. 그러나 제품 개발 및 시스템 개발 분야에서는 향후 사용 기회가 증가 할 것으로 예상됩니다. 이 섹션에서는 PoC의 정의, PoC와 프로토타입의 차이점, PoC의 필요성과 장점, PoC 검증 작업의 흐름에 대해 설명합니다.

PoC 란 무엇입니까?

PoC는 개념 증명의 약자이며 일본어로 “개념 증명”으로 번역됩니다. 신제품 또는 시스템 프로젝트를 시작하기 전에 제품 또는 시스템의 효율성 확인. 예를 들어, 신제품을 개발할 때 본격적인 판매 전에 판매를 테스트하고 고객을 모니터링하여 고객이 실제로 판매되는지 여부를 확인합니다. 또는 시스템 개발에서 최소 구현 및 테스트 작업을 의미합니다.

지금까지 PoC와 검증 작업의 차이점

POC의 아이디어 중 실제로 만들고 사용한다는 아이디어에는 오랫동안 사용되어 온 제품 개발의 “시험 생산”과 시스템 개발의 “프로토 타입”이 포함됩니다. 이 “프로토 타입”을 통해 우리는 프로젝트의 진행 상황과 개발의 결함을 확인하고 있습니다. 개발 프로젝트의 흐름은 “개념 → 계획→ 개발→ 테스트→ 운영 및 판매”의 흐름으로 수행되지만 “프로토 타이핑”및 “프로토 타입”은 개발 단계 또는 테스트 단계에서 언제든지 수행되었습니다. 。

반면에 PoC는 종종 구상 단계 옆에 있습니다 : 구상 단계와 계획 단계 사이. 또한 프로토 타입은 PoC의 결과에 따라 개발 솜씨의 확인 위치이지만 개발 정책이 크게 변경 될 수 있으며 경우에 따라 개발이 포기 될 수 있습니다. 즉, 본격적인 개발 프로젝트가 진행되기 전에 개념 설계가 적절한지 확인하는 것입니다.

PoC의 요구와 이점

최근 몇 년 동안 고객의 요구가 다양 화되고 제품 수명주기가 단축됨에 따라 개발의 불확실성이 증가했습니다. 또한 시스템 개발에는 IoT 및 인공 지능과 같은 새로운 분야에는 많은 과제가 있으며 여기에서도 불확실성이 증가 할 것이라고 말할 수 있습니다. 이해하기 쉬운 방식으로, 이러한 불확실성으로 인해 개발 목표가 상실 될 위험이 높습니다.

지금까지의 개발 과정에서 이러한 위험은 개념 단계에서 예측되었으며 사전에 개발에 통합되었습니다. 이 경우 개념적 단계에서 위험을 예측하는 것이 매우 중요합니다. 그러나 위에서 언급 한 변경 사항은 점점 더 예측할 수없는 위험을 초래하고 있습니다. 개발이 진행된 후에 이 위험이 구체화되면 해당 시점까지의 모든 개발 프로세스가 낭비될 수 있습니다.

이것은 위험을 더 일찍 이해함으로써 피할 수 있습니다. 따라서 개념 당시에는 소규모로 제품이나 시스템을 만들고 고객이 실제로 사용하도록 할 수 있습니다. 판매 및 결함을 통합하고 개념을 수정 한 다음 본격적인 개발을 수행하면 모든 것이 잘못 될 위험이 줄어 듭니다.

또한 이러한 PoC는 개념을 구체화하므로 개발 정책이 명확 해지고 프로젝트가 원활하게 진행됩니다. 즉, POC는 본격적인 개발 전에 사용자의 요구를보다 잘 충족시키고 소규모 테스트 판매 및 테스트 작업을 통해 사용자의 요구를 사전에 포착하기 위해 개념을 수정하는 데 사용할 수 있습니다.

PoC의 한 예는 인공 지능의 개발입니다. 여기서, 당분간 가장 중요한 인공지능의 엔진 부분만을 완성하고 사용자와 협력하여 학습에 닦을 수 있다. 이러한 방식으로 PoC는 본격적인 시스템 개발 전에 사용자와 협력하면서 중요한 부분만 닦는다고 말할 수 있습니다.

그러나 제품이나 시스템의 개념이 외부 세계로 유출되는 등의 단점이 있으며 최악의 경우 사용자가 개념 단계에서 정보를 사용하도록 하기 위해 해당 정보를 얻는 데 충돌이 있다는 점에 유의해야 합니다.

PoC 검증 흐름

PoC는 다양한 장점을 가지고 있지만 맹목적으로 사용하더라도 효과적이지 않습니다. 효과적인 검증 흐름을 살펴 보겠습니다.

  1. 효과/유용성 확인
    먼저 대상 제품 또는 시스템이 달성하려는 내용이 사용자의 요구와 일치하는지 확인합니다. 즉, 원하는 효과를 얻고 있는지 판단하십시오. 예를 들어, 신약의 임상 시험에서, 안전한 신약 후보는 의도 된 효과가 있는지 확인하기 위해 실제로 피험자에게 투여됩니다. PoC는 판매된 경우보다 판매되기 전에 훨씬 적은 수의 피험자로 테스트되기 때문입니다.
  2. 기술적 타당성 검증
    다음으로, 우리는 그 개념이 이론적 이론이 아니라 실제로 실현 가능한지 여부를 확인할 것입니다. 약간 놀라운 예는 단편 영화입니다. 이것의 목적은 장편 영화를 만들기 전에 작은 작품을 만들어 필요한 기술적 인 도전을 달성 할 수 있는지 확인하는 것입니다. PoC에서는 기술적 타당성 검증이 효과/유용성의 검증보다 우선하는 경우가 많습니다. 즉, 기술이 우선이지만 결과적으로 목표 요구 사항이 충족되는지 확인하기 위해 충분한 검증없이 개발이 진행될 가능성이 있습니다. PoC는 원하는 효과와 이점을 달성하기위한 방법이라는 것을 알고 있어야합니다.
  3. 특이성 확인
    그런 다음 개념에 의해 요구되는 사양과 문제를 확인하고 구체적인지 여부를 확인하기 위해 검증이 수행됩니다. 즉, 시장 조사 결과와 실제로 사용하고 개발에 활용 한 사용자의 목소리를 수집합니다.

위의 확인 후, 우리는 수정 된 개념을 기반으로 개념, 프로토 타입 제품 및 시스템을 수정하고, 사용자가 그것을 사용하도록 한 다음 다시 확인합니다. 이를 반복함으로써 “효과 / 유용성”, “기술적 타당성”및 “구체성”을 달성 할 수있는 개념을 닦을 수 있습니다. 브러시 업이 완전히 완료되면 다음 계획 단계로 넘어갑니다.

중요한 것은 사용자가 실제로 사용하도록 유도하는 것입니다. 이렇게하면 완성 된 제품이 사용자가 원하는 것과 거리가 멀어 질 위험을 피할 수 있습니다. 검증을 너무 많이 확장하지 않는 것도 중요합니다. 이것은 개념을 수립하는 데 필요한 작업 비용을 줄일뿐만 아니라 개발 개념이 가능한 한 외부로 누출되는 것을 방지하는 위험 헤징으로 이어집니다.

PoC는 큰 장점을 가진 방법입니다.

개념 단계에서 사용자의 의견을 경청하는 PoC를 수행하면 개념을 파악하고 개발 위험을 줄이며 프로젝트를 원활하게 진행하는 등의 이점을 얻을 수 있습니다. 그러나 검증 규모와 횟수가 너무 많이 증가하면 비용이 증가하고 개념이 외부로 유출 될 위험이 있습니다.

부차적 인 이점으로 PoC의 결과로 개발을 포기하더라도 실제로 사용자 의견을 데이터로 수집 할 수 있으므로 PoC 프로세스에서 얻은 지식이 낭비되지 않습니다. 다음 개발에 사용할 수 있습니다. 그런 의미에서 PoC는 큰 장점을 가진 방법이라고 할 수 있습니다.

관련 게시물