차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

--- a.plan_build_run [2015/09/15 17:40]
wikiadmin 만듦
+++ a.plan_build_run [2015/09/17 09:17] (현재)
wikiadmin
@@ 줄 1: / 줄 1: @@
-==== a. Plan/Build/Run ====
-물론 IoT 솔루션의 계획, 구축 및 실행은 솔루션마다 다르다. 그러나, 우리는IoT 솔루션 사이에 공통점이 있다고 믿으며, 이는 우리가 일반적인 방법론적 접근 방식이 어떠해야 하는지에 관해서 특정 가정을 할 수 있게 한다. 우리는 구체적으로 우리의 접근 방식을 논의하기 전에 우선 이러한 가정의 일부를 설명할 것이다.
-==== 가정 ====
-우리는 이미 이 책의 첫 부분에서 자산과 관련 백엔드 서비스 등에 초점을 맞춘 IoT 솔루션의 핵심 요소에 대한 기본 가정 중 일부를 논의했다 (서론의 “Enterprise IoT” 부분 참조). 우리가 만들고 있는 또 다른 핵심 가정은 IoT 솔루션 프로젝트가 초기 계획 단계를 포함하는 다른 프로젝트와 거의 비슷할 것이라는 점이다. 이러한 단계는 초기 출시 버전이 구축되는 단계와 솔루션이 작동, 관리, 향상되는 단계, 즉 계획/구축/실행 단계이다.
-프로젝트 팀은 주어진 상황에 따라 프로젝트 관리 방법을 선택할 것이다. 프로젝트 실행이 고정 가격에 기반하여 아웃소싱 될 경우, 기회는 더 전통적인 폭포수 모형에 적용될 것이다. 이 경우, RFI (정보 요청)가 "계획" 단계의 일부로 발부되며, 법적 구속력이 있는 RFP (제안 요청)이 뒤따른다. 또 다른 팀은 예를 들어 방법론으로 SCRUM을 활용하여, 민첩한 접근법을 적용하기로 결정할지도 모른다. 이 경우, 프로젝트의 자세한 사항은 사용자 스토리에 기초하며, 이는 빠른 실행을 위한 주요 투입을 구성하고 중앙 제품 백로그에서 관리된다. 이러한 사용자 스토리는 대개 상대적으로 상세하며 이상적으로 필요에 따라 생성된다. 그러나, 대부분의 민첩한 접근법은 또한 기능적, 구조적 관점에서 전체적인 솔루션을 설명하는 더 높은 수준의 설명서를 사용한다. 그래서, 어떤 의미에서, 민첩한 프로젝트는 “계획” 단계 (때로는 "스프린트 제로"로 알려진)를 포함한다. 선택된 민첩한 접근법의 종류에 따라, 프로젝트의 "구축" 및 "실행" 단계는 달라질 수 있다. 예를 들어, 일부 민첩한 프로젝트는 주요 발표에 집중하고 긴 테스트 단계를 포함하는 전통적인 접근법에 가깝다. 또한 이는 때때로 폭포수 모형(waterfall)과 민첩함(agile)의 조합인 "wagile"방식이라고 불린다. 다른 민첩한 프로젝트들은 빠른 결과가 지속적으로 배열되는 접근법을 매우 신중하게 채택하려고 시도한다.
-프로젝트 관리에의 또 다른 일반적인 접근법은 V-Model이다. 예를 들어 이것은 중부 유럽의 정부 운영 프로젝트에서 일반적으로 사용된다. PRINCE 2에서 합리적 통합 프로세스 (RUP)까지 다른 많은 접근법이 있다. 그러나, 우리는 보통 일반적인 계획/구축/실행의 관점이 서로 다른 접근법 모두에 적용될 수 있다고 말하는 것이 타당하다고 믿는다.
-{{ :파트2_12번그림.png?300 |}}
-                          Ignite and different project approaches
-==== 취한 접근법 ====
-프로젝트 관리를 위해 이러한 서로 다른 접근법을 모두 지원해야 할 필요성을 감안할 때, 다음 Ignite 방법론은 IoT 솔루션에 특화된 것에 초점을 맞추며, 프로젝트 관리자가 프로젝트 관리 모델을 선택해 솔루션과 결합시킬 수 있도록 한다.
-프로젝트 구조의 측면에서, Ignite 접근법은 아래 그림에서 보여지는 높은 수준의 구조를 기반으로 한다. 첫 번째로 우리가 볼 수 있는 것은 자산 자체와 IoT 프로젝트 사이에 차이가 있다는 점이다. 자산의 설계 및 제조는 IoT 솔루션 프로젝트의 범위 내에서 일반적이지 않다. 그러나, 자산과 IoT 솔루션 프로젝트에 대한 책임이 있는 조직 간의 인터페이스를 인식하는 것은 필수적이다. 하나 이상의 IoT 솔루션을 지원하도록 자산이 처음부터 설계되는 상황뿐만 아니라, IoT 솔루션이 자산의 초기 설계 ("개조") 이후 자산과 통합되는 상황에서도 이는 적용된다. 어느 경우에도, IoT 솔루션은 솔루션의 백엔드 서비스 인터페이스를 정의하는 특정 "자산 상의" 하드웨어 및 소프트웨어에 의존할 가능성이 높다.
-{{ :파트2_13번그림.png?300 |}}
-                                 Ignite project structure
-Ignite | IoT 솔루션 전수의 또 다른 핵심 요소는 전형적인 프로젝트가 착수 단계와 주요 실행 단계를 가지고 있다는 가정이다. 사업 사례가 승인되고 조직이 원칙적으로 프로젝트를 진행하라는 명령을 내리면 착수 단계는 시작된다. 이 단계에서, 즉 자원의 증가 이전에, 보통 상대적으로 작은 팀이 프로젝트에 참여한다.
-다음은 주요 실행 단계이다. 이 단계에서의 Ignite 접근법은 우리가 “작업 흐름”이라고 부르는 개념을 기반으로 한다. 이는 주요 프로젝트에 걸쳐 적용되는 최고 수준의 구조이다. PMI의 측면에서, 작업 흐름은 작업 분류 체계 (WBS)의 최상위 작업 항목이 될 것이다. 우리의 경험에서, 용어 "작업 흐름”은 다른 모든 이해 관계자 및 종속성과 함께 IoT 프로젝트 관리의 매우 역동적인 특성을 더 잘 반영한다.
-==== i. IoT 프로젝트 착수 ====
-Ignite | IoT 프로젝트 착수 단계의 중요한 측면은 요건 분석이며, 이는 사업 모델 생성 단계에서 수행된 분석보다 더 면밀하다. 비교하자면, 요건 분석은 초기 솔루션 설계를 지원할 수 있는 수준의 세부 사항에 도달하기 위한 목적으로, 특정 사용자 요건을 깊게 살펴 본다. 프로젝트 착수는 일반적으로 각 분야의 전문가로 이루어진 작은 팀에 의해 수행된다. 특히, 팀은 전용 솔루션 설계를 가지고 있어야 한다 (사업 모델 생성 단계에 깊이 관여되지 않았을 수 있다). 또한, 팀은 광범위한 영역의 지식과 솔루션의 기능적인 측면에 대한 명확한 비전을 가진 사업 분석가를 포함해야 한다.
-우리가 "두 세계의 충돌"에 대한 이전 논의를 기억한다면, 적합한 사업 분석가 및 솔루션 설계자를 찾는 것이 중대하지만 어렵다는 것을 알 것이다. 예를 들어, 사업 분석가가 일반적으로 자산에 대한 책임이 있는 사업 부문에서 올 경우, 서비스 관점에서 생각하기 어려울 지도 모른다. 반면, 서비스 중심의 사람이 이 역할에 선택될 경우, 그들은 자산 영역에서의 오랜 경험으로부터 비롯된 심층적인 영역 지식이 부족할지도 모른다. 어떤 경우에는, 따라서 상호보완적 배경을 가진 여러 전문가를 선택하여 IoT 프로젝트 착수 단계 팀을 구성하는 것이 유용할 수 있다.
-프로젝트 착수 팀은 이 단계에서 이해 관계자 분석, 환경 분석, 요건 분석, 위험 및 자원 평가 등 일반적인 많은 작업을 수행해야 한다. 다음에서, 우리는 어떠한 추가적인 IoT 고유의 측면이 이러한 표준 프로젝트 작업에 추가될지에 대해 설명할 것이다. Ignite | IoT 프로젝트 착수 단계의 최종 결과는 이전에 설명된 작업 흐름 구조를 기반으로 한 초기 솔루션 설계 및 프로젝트 구조이다.
-{{ :파트2_14번_그림.png?300 |}}
-                                 Project initiation
-==== 1. 초기 솔루션 디자인 ====
-Ignite | IoT 솔루션 전수는 아래 그림에 표시된 초기 솔루션 설계를 위한 주요 아티팩트를 정의한다. 우리는 분석, 예측, 계획, 기능 설계 아티팩트 및 기술 설계 아티팩트를 포함하는 아티팩트들의 차이를 논한다. 그들은 병렬로 생성될 수 있지만, 이 부분에 기술된 바와 같이, 종종 그룹화하는 것이 합리적이다.
-Ignite | IoT 솔루션 전수가 제안하는 일부 아티팩트, 예를 들어 이정표 계획은 항상 IoT에 특화된 것은 아니다. 일부 아티팩트는 IoT 솔루션을 위한 제안된 수량 구조 또는 SOA 랜드스케이프 등 IoT에 특화된 확장자를 가지고 있다. 그리고 일부 아티팩트는 IoT 프로젝트 차원, IoT 솔루션 스케치, 또는 자산 통합 아키텍처 등 IoT 솔루션 설계를 위해 특별히 만들어졌다. 책의 이 부분에서는 우리는 어떻게 프로젝트 팀이 설계 단계에서 이러한 아티팩트로 작업할 수 있는지에 더 집중할 것이다. 이러한 이유로, 우리는 여기에서 사례를 먼저 제공하고, 다음 "빌딩 블록" 부분에서 더 공식적인 정의를 제공할 것이다.
-전문화된 설계 아티팩트는 소프트웨어 설계에서 긴 이력을 가지고 있다. 특히, 합리적인 통합 프로세스 (RUP)는 소프트웨어 프로젝트의 서로 다른 관점과 단계에 대한 전문 소프트웨어 설계 아티팩트의 완전한 집합을 기반으로 한다. RUP는 과거에 너무 많은 아티팩트를 기반으로 하여 일부 비판을 받았다. SCRUM같은 민첩한 접근법은 종종 아키텍쳐 아티팩트보다는 사용자 스토리 같은 아주 기본적인 아티팩트에 의존하고 있다. 민첩한 관점에서 "코드는 진리이다". Ignite | IoT 솔루션 전수는 두 극단 사이에서 균형을 유지하려고 한다. 우리의 경험에 의하면, 이는 특정 표준화된 아키텍처와 설계 아티팩트에 의존하는 데 매우 도움이 될 수 있으며, 다른 프로젝트 이해관계자들이 이해를 같이하도록 보장한다. 이를 위해, Ignite | IoT 솔루션 전수는 아티팩트가 충분히 가벼우면서도 충분히 표현 가능하다는 것과 다른 유형의 아티팩트들이 중복을 최소화하면서 서로 잘 통합된다는 것을 보장해야 한다.
-{{ :파트2_15번그림.png?300 |}}
-                              Initial IoT Solution Design
 ==== I. 분석, 예측, 계획 ====
@@ 줄 355: / 줄 305: @@
 {{ :파트2_28번그림.png?300 |}}
                                  Technical infrastructure
+==== 2. 예시 – 센서 선택과 통합 ====
+Stefan Schuster와 Julian Bartholomeyczik는 모두 Bosch Connected Devices and Solutions (BCDS)에서 일한다. BCDS는 혁신적인 연결 장치와 IoT 맞춤형 솔루션을 개발하고 판매하는 Bosch의 사업부이다. 다음의 설명은 IoT 센서 네트워크에 대한 솔루션 스케치 작성의 예시를 제공한다.
+**Dirk Slama**: IoT 센서 네트워크에 대한 샘플 솔루션 스케치에 대해 우리에게 설명해주실 수 있을까요?
+**Stefan Schuster and Julian Bartholomeyczik**: 물론이죠. 솔루션 스케치는 문제 공간 (프로젝트 작업 집합)과 솔루션 공간 (이 작업을 해결하는 기술 솔루션) 모두를 포함합니다. 솔루션 스케치를 작성하기 위한 두 가지 접근 방법으로, 하향식과 상향식 방법이 있습니다.
+용어와 일반적인 접근 방법에 대해 간단히 살펴 봅시다. 예를 들어 우리는 어떻게 초기 단계에서 기계의 마모를 확인할 수 있는가? 와 같은 질문의 형태로 작업이 정해져 있는 경우, 하향식 절차라고 말합니다. 이 작업을 완수하는 기술 솔루션이 만들어지며, 구성 요소들은 그에 맞춰 설계되고 만들어 집니다.
+상향식 절차에서 기술 솔루션의 구성 요소는 예를 들어 기존의 플랫폼, 센서, 또는 알고리즘의 형태로 이미 존재하고 있습니다. 이 프로젝트는 사실상 탐험입니다. 이 경우 전형적인 미결 문제는 다음과 같습니다. "우리가 이 데이터/센서를 이용하여 기계에서 감지할 수 있는 것은 무엇인가?"
+프로젝트를 가속화하기 위해, BCDS는 센서 네트워크 개발 키트를 포함하는 플랫폼 구성 키트를 만들었습니다. 이 키트는 모든 종류의 다른 어플리케이션에 대한 광범위 센서를 포함하고 있습니다.
+실제로, 프로젝트는 이러한 두 절차의 조합을 이용하여 만들어집니다. 예를 들어 플랫폼은 양 방향에서 접근할 수 있습니다. 플랫폼은 어플리케이션 프로젝트의 상위 집합으로서 위에서 아래로 설계되거나, 기존 기술 구성 요소의 집합으로서 아래에서 위로 설계될 수도 있습니다. 어플리케이션 프로젝트는 전부 하향식으로 솔루션을 정의하지 않습니다. 대신, 그들은 기존 구성 요소, 예를 들어 플랫폼을 사용합니다.
+//구체적인 예시를 들어봅시다. 우리가 효율적으로 유지 보수 기간을 계획하기 위해, 기계 회전 부분의 마모를 초기에 발견할 수 있도록 하고 싶다고 합시다.//
+첫째, 이 프로젝트는 가능한 한 독립적으로 정확하게 실행되도록 정의되어야 합니다. 하나의 실행 가능성을 너무 빨리 결정하는 것은 너무 이른 시기에 솔루션 공간을 좁혀버릴 수 있으므로 피해야 합니다.
+기능적 요건 외에도, 솔루션 체계를 정의하는 시스템 요건도 지켜져야 합니다. 이는 비용 제한, 시스템 작동 환경, 기존 시스템의 인터페이스 설정을 포함합니다.
+**Dirk Slama**: 그렇다면 좋은 요건은 무엇입니까?
+**Stefan Schuster and Julian Bartholomeyczik**: 핵심 질문은 다음과 같습니다. 사용자가 시스템으로부터 배우고 싶어하는 것은 무엇인가? 시스템이 수행해야 하는 작업은 무엇이며, 언제 그리고 어떤 조건에서 수행해야 하는가? 기본적인 경제 조건은 무엇이며, 어떤 환경에서 시스템이 작동해야 하는가?
+이 예시에서, 사용자는 시스템이 적시에 기계 마모에 대해 알려주길 원합니다. 기계는 산업 환경에서 작동됩니다. 우리는 처리 통제 시스템이 이미 존재하며, TCP/IP를 통해 접속될 수 있다고 가정합니다. 우리는 잠재 고객이 기계 모니터링에 기꺼이 지불하고자 하는 가격을 설정하며, 그 결과 센서 노드 제조 목표 가격이 €30가 됩니다. 시스템은 케이블을 사용하지 않고 연결되어야 하며, 배터리 수명은 1 년이 되어야 합니다.
+기능 부품의 경우, 우리가 작업을 수행하기 위해 시스템에 필요한 데이터를 유도할 수 있는 이론이 정립된다. 이 예에서, 기계의 마모 및 눈물 이론 상태는 기계 침대에서 증가 진동을 통해 확인할 수 있다. 이론적으로 이런 종류의 보통 (기계 익숙한 즉 엔지니어) 도메인 전문가에 의해 정의된다.
+이 예시에서, 이론은 기계의 마모가 기계판에서의 증가된 진동을 통해 확인될 수 있다고 말한다. 이런 종류의 이론은 보통 영역 전문가 (즉, 기계에 친숙한 엔지니어)에 의해 정의된다.
+이상적으로, 이론이 먼저 입증되어야 합니다. 이 예시에서, 이는 두 기계를 측정함으로써 이루어집니다. 하나는 적절한 작업 조건에 있는 기계이고, 하나는 당신이 시스템을 확인해야 하는 조건 (부품이 마모되는지)에 있는 기계입니다. 이러한 유형의 입증 절차는 이론을 확인하고 (부품이 마모될 때 진동이 증가한다) 적절한 센서를 선택하기 위해 (센서를 이용하여 테스트 시행) 사용될 수 있습니다. 또한 장착 위치 또는 일련의 적절한 장착 위치가 이 단계에서 결정되도록 합니다. 이러한 위치로부터 다른 변수들은 액체 및 온도에 이용 가능한 공간과 저항 등으로 결정될 수 있습니다.
+이론이 검증되면, 디지털 모델로 변환됩니다. 이 예에서 취해진 측정은 진동, 주파수, 마모 정도에 따른 파라미터 변화 정도에 대한 정보를 제공합니다. 이상적으로, 측정은 기계 간 변화를 알아내기 위해 여러 기계에서 취해집니다.
+센서는 디지털 모델, 비기능 요건, 검증 프로세스로부터 얻은 경험에 근거하여 선택됩니다. 기존의 데이터 또한 활용될 수 있습니다 (예를 들어, 처리 통제 시스템은 이미 엔진의 회전 속도를 알고 있는가?). 따라서 데이터 수집 지점은 정확하게 명시됩니다. 그리고 최종 단계에서, 시스템은 이제 "솔루션 스케치"에 해당됩니다. 우리의 중점이 백엔드가 아닌, 여기 센서 관점에 있다는 것에 주목해 주십시오.
+이 예에서 설계된 센서 시스템은 기계의 축 베어링 지점 가까이에 장착됩니다. 그것은 배터리에 의해 전원이 공급되며 무선으로 데이터를 전송합니다. 여기서 중요한 결정은 디지털 모델이 실행되는 장소와 관련된 것입니다. 다음은 두 가지 가능한 시나리오입니다. 첫 번째 시나리오에서, 모델은 센서 노드에서 실행됩니다. 이는 기계가 일정 마모 수준에 도달 할 때 간단한 메시지가 상위 시스템으로 전송된다는 것을 의미합니다. 두 번째 시나리오에서, 디지털 모델은 중앙 통제 시스템에서 실행되며, 이는 센서 데이터가 전송되고 마모가 상위 시스템에서 계산된다는 것을 의미합니다.
+이 결정은 특히 다음 고려 사항에 의해 일어납니다:
+•	센서 노드의 에너지 요건: 데이터를 전송하는 것은 많은 에너지를 필요로 한다. 센서 노드를 미리 처리하는 것은 데이터 전송 요구를 감소시킨다.
+•	이용 가능한 처리 능력 및 데이터: 데이터 처리가 지정된 경제적 한계 내 센서 노드에 실현 불가능한 처리 능력을 필요로 할 수 있다. 다른 소스로부터 추가적인 데이터가 정확한 계산을 보장하기 위해 필요한 경우, 필요한 모든 데이터가 이용 가능한 곳에서 계산은 수행될 수 있다.
+•	노하우 보호 및 공급 부문: 알고리즘이 보호될 필요가 있으며, 그것이 센서 제조자에 의해 만들어졌다면, 그 다음 노드에서의 실행이 일어날 수 있다.
+이 예에서, 알고리즘은 모든 필요한 데이터가 이용 가능하고, 처리 능력이 낮으며 전지 수명이 필수적일 때, 센서 노드에서 실행됩니다.
+**Dirk Slama**: 감사합니다. 마지막으로, 솔루션 스케치의 핵심 구성 요소들에 대해 간단하게 이야기해봅시다.
+**Stefan Schuster and Julian Bartholomeyczik**: 주요 구성 요소는 실제 센서 요소인 마이크로프로세서와 무선 통신을 위한 요소입니다. 마이크 및 가속도 센서 테스트에 이어, 주파수 범위와 진폭을 결정한 후, 가속도 센서가 선택됩니다. 마이크로프로세서는 제조업체의 구성 키트 (플랫폼 전략, 상향식 절차 참조)로부터 선택됩니다. 그리고 그 차원은 알고리즘을 실행할 수 있고 일부 개선을 위한 공간이 여전히 존재하는 것입니다. 무선 연결은 범위 요건 및 배터리 사용 요건에 기초하여 선택됩니다. 블루투스 LE (BLE) 연결이 선택됩니다. 게이트웨이는 구현되어 BLE 통해 데이터를 수신하고 처리 통제 시스템과의 연결을 가능하게 하는 와이파이로 변환된다.
+==== 3. 생산 또는 구매 의사결정 ====
+초기 솔루션 설계의 결과에 기초하여, 프로젝트 팀은 중요한 ‘생산 또는 구매’ 의사결정을 내려야 한다. 이 결정은 프로젝트에 큰 영향을 미칠 것이다. 한 가지 중요한 요인은 기업 가이드라인 및 정책에 관한 것이다. 또 다른 요인은 전략적인 프로젝트 목표 및 필요한 솔루션 구성 요소의 이용 가능성에 관한 것이다. 일반적인 IoT 프로젝트의 생산 또는 구매 질문들은 다음을 포함한다.
+•	공통 규격품 (COTS) 솔루션: COTS 솔루션은 차량 관리, 차량 추적, 스마트 미터링 등의 측면에 이용 가능한가?
+•	자산 상 하드웨어: 맞춤형 하드웨어 또는 표준 하드웨어가 사용되어야 하는가?
+•	자산 상 소프트웨어: 우리는 사전에 통합된 운영 체제, 펌웨어, 어플리케이션 컨테이너 및 개발 도구를 사용해야 하는가? 아니면 맞춤형 솔루션을 선택해야 하는가?
+•	IoT 클라우드/M2M 미들웨어: 완전히 발달한 상업적 IoT 클라우드/M2M 미들웨어에 비해 가벼운 오픈 소스 체제를 사용하는 것의 장점은 무엇입니까?
+•	무선 통신: 우리는 더 나은 글로벌 커버리지를 보장하기 위해 하나의 통신 사업자에 의존하거나 MVNO (모바일 가상 네트워크 운영자)와 일해야 하는가?
+결과에 따라, 또 다른 관련 질문은 일반 계약자의 역할을 해야 하는 주체에 관한 것이다. 예를 들어, 기업 자체, 시스템 총괄자, 또는 통신 회사의 M2M 사업부가 될 수 있다.

a.plan_build_run.1442306406.txt.gz · 마지막으로 수정됨: 2015/09/15 17:40 저자 wikiadmin

문서 보기 이전 판 역링크

뒤로 미디어 관리자 맨 위로