PDF 다운로드

하드웨어 및 소프트웨어 개발을 디지털 제품 제공에 통합

1969년 아폴로 11호의 달 착륙에는 약 14만 5,000줄의 코드가 필요했습니다. 보잉 777에는 현재 260만 줄이 넘는 코드가 있습니다. 오늘날에는 최신 자동차를 출시하기까지 최대 1억 줄의 코드가 필요할 수 있습니다.

복잡한 제품에서 진화하는 소프트웨어의 역할

900X450

소프트웨어는 세상이 돌아가는 방식에 있어 날이 갈수록 중요해지고 있습니다. 제품에 포함된 소프트웨어가 많을수록 제품을 개발하는 과정이 더 복잡해지고 오류가 발생할 여지가 많아집니다. 한편, 복잡하면서도 품질이 높은 제품을 혁신하고 출시 기간을 단축해야 한다는 압박은 그 어느 때보다 큽니다. 여기에 하드웨어, 소프트웨어 및 서비스 혁신의 병렬 개발 스트림을 효율적으로 관리하고 투명성을 보장하며 이 모든 것을 하나의 제품에 통합해야 하는 과제도 있습니다.

복잡한 제품 개발을 최적화하기 위한 경쟁에서 뒤처지고 싶지 않은 제조업체는 프로세스, 시스템 및 팀 사고방식을 크게 발전시켜야 합니다. 그러지 않으면 처음부터 복잡한 제품을 염두에 두고 비즈니스를 설계한 경쟁업체에 뒤처집니다.

이러한 진화의 핵심:

  • 전체 시스템에 대한 체계적인 관점 확립
  • 시스템 엔지니어링 방법 사용
  • 분야를 넘나들어 사고하도록 개방적 조직 문화 조성
  • 올바른 PLM/ALM 도구 활용

소프트웨어 복잡성으로 인해 발생하는 과제

비즈니스 관점에서 이러한 발전은 제조업체에게 기회이자 과제입니다. 기회인 이유는 경쟁이 치열해지고 혁신에 대한 압박이 가중되는 상황에서 소프트웨어 중심 제품을 사용하면 개발 시간을 단축하고 완전히 새로운 비즈니스 모델을 위한 기반을 마련할 수 있기 때문입니다.

그러나 어떤 점에서 과제라고 할 수 있을까요?

분야가 서로 다른 팀

제품 개발자의 관점에서 볼 때, 기계적 측면에서 편차가 감소하더라도 모든 소프트웨어와 이러한 구성 요소 간의 긴밀한 상호 관계로 인해 전체 시스템의 복잡성은 증가합니다. 게다가 소프트웨어 뒤에는 각자의 방식과 속도로 혁신 주기를 관리하는 다양한 개발 팀이 있는 경우가 많습니다. 이들의 작업을 오케스트레이션하고 이러한 병렬 개발 스트림을 통합하기는 어렵습니다.

시스템 검증

제조업체는 특히 안전이 중요한 제품의 맥락에서 전체 시스템을 검증할 수 있는 방법도 고려해야 합니다. 해당 산업과 제품에 따라 표준은 모든 개발 단계와 변경을 원래 요구 사항까지 거슬러 추적할 수 있도록 요구합니다.

연결이 끊긴 툴체인

소프트웨어 개발에 사용되는 툴킷은 오늘날 우리가 알고 있는 응용 프로그램 라이프사이클 관리(ALM)로 발전했으며 해당 프로세스 모델은 최신 시스템 엔지니어링에 통합되었습니다. 그러나 많은 회사에서는 과거부터 지금까지도 많은 개별 구성 요소를 관리하는 데 중점을 두고 있습니다. 요구 사항 사양에서 완제품에 이르기까지 일관성을 보장하는 것은 회사 전체에 걸쳐 일관되게 확립된 제품 라이프사이클 관리(PLM) 개념(방법 및 툴링)에 의해 지원되지 않는 경우가 많습니다.

900X450

소프트웨어 기반 제품 개발을 위한 두 가지 일반적인 접근 방식

주로 기계 및 전기 기계 제품에 중점을 두고 성장한 회사에서 점점 더 많은 양의 소프트웨어를 통합하는 것과 관련하여 다음과 같은 경향을 관찰할 수 있습니다.

접근 방식 A: 소프트웨어를 하드웨어 부속물로 취급

이것은 소프트웨어가 하드웨어의 확장 프로그램 또는 추가 프로그램으로 간주되는 경우입니다('소프트웨어는 그저 또 다른 부품 번호'라는 인식). 소프트웨어 구성 요소는 전기 기계 구성 요소와 동일시되며 부품 번호가 할당됩니다. 제품 구조에서 최소한 ECU는 식별할 수 있을지 몰라도 플랫 BOM에서 모든 상호 종속성을 식별하는 것은 결과적으로 불가능합니다.

접근 방식 B: ALM과 PLM의 공존

경우에 따라 PLM 환경과 함께 독립적인 병렬 ALM 환경이 설정됩니다. 이것은 '나는 그들이 저기서 무엇을 하고 있는지 모르고 관심도 없다'라는 말로 가장 잘 묘사되는 상황입니다.

전기 기계 개발의 제약에서 벗어난 소프트웨어 개발자는 ALM 환경에서 동적 기능을 완전히 수용할 수 있습니다. 소프트웨어는 짧은 반복과 매우 민첩한 방식으로 현재 고객 요구사항을 충족하도록 최적화됩니다.

그러나 두 가지가 완전히 분리된 시나리오에서 일반적으로 간과되는 것은 PLM과 ALM 환경 간의 상호 동기화입니다. 안타깝게도 이것은 비일관성을 낳고 비일관성은 생산 및 완제품으로도 이어집니다.

안타깝게도 위에서 설명한 두 시나리오 모두 기계 공학, 전자 공학 및 복잡한 소프트웨어 간의 기능적 공생에 이상적이지 않습니다.

이 기사의 상세 버전에서 두 접근 방식의 장점과 단점을 읽어보세요.
페이지 오른쪽 상단에 있는 PDF 다운로드 버튼을 클릭하세요.

PLM과 ALM에 대한 새로운 생각

소프트웨어 중심 제품 개발 최적화의 '예술'은 모든 관련 당사자에게 투명성, 협업을 위한 효율적인 허브, 성공을 위해 필요한 모든 도구를 제공하는 프로세스, 방법 및 도구를 구축하는 데 있습니다.

그렇지만 최종 제품이 모든 요구 사항을 충족하고 단일 단위로 기능할 수 있도록 여전히 모든 개별 분야를 조정해야 합니다. 그러나 이것은 단순히 도구와 방법론의 문제가 아닙니다. 또한 광범위하고 심층적인 조직 변화가 필요하며, 이를 위한 의지가 매우 중요합니다. 변경 내용을 감독하는 데 적극적인 역할을 할 사람을 지정하고 조직의 조정을 위한 강력한 지침을 제공하는 것이 좋습니다.

다음으로, 기술 개발의 복잡한 환경 속에서 공동 개발 프로세스를 적극적으로 통제할 필요가 있습니다. 시스템 엔지니어링에 사용되는 방법은 적절한 기반을 제공합니다. 여기에는 제품 또는 시스템의 모든 구성 요소를 공통의 요구 사항에 맞게 조정하는 데 사용할 수 있는 매우 유용한 툴킷이 이미 포함되어 있습니다.

시스템 엔지니어링 표준 중 하나를 지정된 대로 정확하게 구현할지 아니면 단순히 지침으로 사용할지는 거의 선호도의 문제입니다. 물론, 고객 또는 기타 책임자에게 지정된 표준을 준수한다는 증거를 제공해야 하는 경우(일부 산업에서 요구됨) 표준 구현은 매우 중요합니다.

방법론적 토대

회사에서 적절한 절차 모델(예: V-모델)을 선택하고 나침반처럼 사용하는 것이 중요합니다.

소프트웨어 중심 제품의 맥락에서 이것은 무엇을 의미할까요? 처음부터 제품이 무엇을 할 수 있어야 하는지, 어떤 다른 요구 사항(예: 표준)을 충족해야 하는지 생각하는 것이 중요합니다. 특정 접근 방식을 염두에 두지 않고 가능한 한 공정하게 생각해야 합니다.

이어지는 단계는 다음과 같습니다.

  • 제품이 수행할 수 있는 기능 설명
  • 아키텍처 단계에서 시스템을 현명하게 분할
  • 상호 의존성에 대한 초기의 추상적 정의 제공
  • 동기화 메커니즘 생성

전체 백서에서 이러한 기본 단계에 대해 읽어보세요.
페이지 오른쪽 상단에 있는 PDF 다운로드 버튼을 클릭하세요.

토대를 올바르게 조합

일을 단순하게 유지하려는 모든 노력에도 불구하고 하드웨어 및 소프트웨어 하위 시스템 간의 상호 의존성은 빠르게 매우 다양해지고 복잡해질 수 있음을 명심하는 것이 중요합니다. 따라서 IT 환경에서 이러한 모든 상호 종속성을 최대한 추적할 수 있도록 지원하는 것이 중요합니다.

위에서 강조한 방법 모델 유형을 설정하면 개발 프로세스 전반에 걸쳐 소프트웨어 기반 제품을 안정적으로 개발해야 하는 과제를 해결할 수 있는 토대가 마련됩니다. 특히 엔드 투 엔드 시스템 엔지니어링은 중요한 지원을 제공합니다.

오늘날 대부분의 기업은 이미 어떤 식으로든 이러한 개념의 상당 부분을 실천하고 있습니다. 최적화되고 목표 지향적인 조정이 부족한 경우가 많은데, 이는 올바른 사고방식의 전환, 특정 책임자 배치, 노력을 지원하기 위한 적절한 도구 사용으로 해결할 수 있습니다.

[subject-name] 님, 안녕하세요? 돌아오신 것을 환영합니다.
본인이 아닙니까?
계속하려면 아래 버튼을 클릭하십시오.
PDF 다운로드
PDF 다운로드
로드 중...

제출해 주셔서 감사합니다. PDF가 자동으로 다운로드되지 않으면 여기에서 다운로드하시기 바랍니다.