개발 작업

개발 작업 방식을 도입할 때 일반적인 과제는 다음과 같습니다.

사일로화된 팀 - 공동의 프로세스와 목표가 없는 팀은 서로 다른 작업을 우선시할 가능성이 크기 때문에 제공이 느리고 오류가 많을 수 있습니다. 따라서 많은 조직에서 개발과 테스트, 운영 엔지니어를 하나의 개발 작업 팀으로 병합하고 있습니다. 팀들이 기존의 조직 구조를 유지하면서도 공동의 프로세스와 목표를 가지고 일할 수도 있습니다. 하나의 공동 대시보드를 보는 것은 성공의 공통적인 정의를 기준으로 팀을 통합하는 데 필수입니다.

자동화 부족 - 잦은 소프트웨어 제공에서는 빌드, 테스트, 배포 주기 전체에 자동화가 이루어져야 합니다. 그렇지 않으면 수동 작업으로 인해 팀의 부담이 큽니다. 통합된 도구 체인은 개발 작업의 품질을 높이면서 제공을 가속화합니다.

추적 가능성 부족 - 라이프 사이클 추적 가능성은 조직이 통제하에 정밀하게 개발 작업 방식을 도입하는 데 도움이 됩니다. 고객 요청 제공의 우선순위를 지정하거나, 성능 문제를 유발하는 기능 롤백하거나, 각기 다른 기능을 고객 또는 지역별로 제공하려면 세밀한 개발 및 릴리즈 주기 통제가 필요합니다. 이런 수준의 릴리즈 통제는 개발 작업 방식이 다른 라이프 사이클 영역과 통합되어야만 가능합니다.

개발 작업 방식은 자동차, 휴대폰, 의료 기기 등에 포함된 소프트웨어에 확장할 수 있지만 몇 가지 차이가 있습니다.

제공 타이밍 - 스마트 제품은 일반적으로 더 통제되고 세밀한 제공 방식이 필요합니다. 예를 들면 자동차 소프트웨어 업데이트를 배치로 묶어 정기적인 자동차 서비스 간격과 타이밍을 맞춰야 합니다. 일반적으로 중단을 최소화하고 안전을 보장하도록 제공 타이밍이 결정됩니다.

안전 및 보안 - 많은 스마트 제품은 안전이 중요하며 개발 작업 방식에까지 규제 감독이 확장됩니다. 이런 제품은 추적 가능성 및 감사 표준을 준수하고 소프트웨어 업데이트 관리 연속성에 대한 보안을 충족해야 합니다.

제공 방법 - 포함된 소프트웨어는 OTA 업데이트, 이전의 웹, CD 또는 기타 유선 제공 방법을 사용할 수 있습니다.

이질적 환경 - 전통적인 개발 작업 환경에서 팀들은 컴퓨팅 환경을 높은 수준으로 통제할 수 있습니다. 물리적인 하드웨어 기기를 소유하지 않는 운영 팀과는 달리 특정 소프트웨어의 포함 또는 배제를 결정하고 모든 소프트웨어 유지보스 작업이 수행되었는지 확인할 수 있습니다. 업데이트가 실제 조건과 구성에서 작동하도록 하기 위해 포함된 소프트웨어 업데이트에는 일반적으로 더 많은 가설 구성에 대해 더 복잡한 테스팅이 필요합니다.