목 차 >>> 1. 서 론
2. 전장 소프트웨어 개발의 특징 3. 협업 개발의 이슈들
4. 품질 관리 방안 5. 결 론
1. 서 론
자동차 완성차 업체는 더욱 치열해 지고 있는 경쟁에서 살아남기 위해 보다 혁신적인 기능을 적은 비용으로 제공할 수 있는 전자장치의 개발 을 가속화 하고 있으며, 이 중 많은 부분을 소프 트웨어로 구현한 전장제품을 탑재하고 있다. 이 에 따라 자동차 생산원가에서 차지하는 IT부문의 비중은 2000년 20% 수준에서 2010년 32%까지 높아졌고, 전기자동차의 경우 그 비중이 70%에 달하고 있다[1].
차량을 제어하거나 운전자 안전 및 편의를 제 공하는 전장제품을 개발하는 부품업체의 경우 기 존에는 탑재되는 소프트웨어의 규모가 작았기 때 문에 모든 소프트웨어를 내부에서 개발하고, 또 한 소프트웨어 개발 특성을 고려한 추가적인 관 리 노력을 들이지 않더라도 제품을 개발하는데 큰 문제가 없었다. 하지만, 전장제품에 탑재되는 소프트웨어의 규모가 커지고, 복잡성이 증가하고,
품질에 대한 기대가 높아지고, 그리고 IT융합이 늘어나면서 협업 개발을 고려한 전장제품 소프트 웨어 개발 프로세스에 대한 요구가 많아지고 있 는 상황이다[2-4].
하지만, 전장제품 소프트웨어 개발에 참여하는 국내 기업들의 수준을 보면 대표적인 Tier 1 부품 업체인 현대모비스나 만도 등 일부를 제외하고 는, 소프트웨어 개발자 수 측면에서 10명도 안 되 는 영세한 중소/벤처 기업이 대부분을 차지하고 있다. 이러한 작은 규모의 중소/벤처 기업의 경우 에는 가지고 있는 소프트웨어 개발 역량이나 기 술에 비해 품질 관리에 대한 인식이 부족하고, 또 한 소프트웨어 품질관리를 수행하기 위한 추가적 인 비용과 자원을 계획하고 운영하기 어렵다.
따라서 다수의 중소/벤처 기업들이 참여해서 협업 개발을 수행해야 하는 경우 Tier 1 업체의 역할이 중요해지고 있으나, 국내 Tier 1 업체의 경우에는 협업 개발에 대한 경험이 거의 없고 내 부의 소프트웨어 개발 프로세스도 최근에 구축한 박상우 ․ 허 정 ․ 이남희 ((주)솔루션링크), 홍장의 (충북대학교)
국내 전장 소프트웨어 협업 개발의 이슈 및
품질관리 방안
(그림 1) 전장제품개발 프로세스와 SW개발 프로세스 매핑 기업이 대부분이라서 프로젝트 관리에 많은 어려
움을 겪고 있다. 반면 보쉬나 컨티넨탈 같은 대표 적인 해외 Tier 1 업체 등은 협업 개발에 대한 풍 부한 경험과 역량을 바탕으로 업계 표준을 작성 하여 정기적인 감사 등을 실시하여 품질을 확보 하고 있다[5-7].
본 논문에서는 다수의 기업들이 참여하여 하나 의 전장제품 소프트웨어를 개발할 때 발생할 수 있는 다양한 이슈들을 살펴보고, 이를 사전에 방 지할 수 있는 프로젝트 관리 및 개발 체계를 제시 하도록 한다. 2장에서는 일반적인 소프트웨어 개 발과 전장 소프트웨어 개발의 특징을 간략하게 비교하도록 하고, 3장에서는 국내 환경에서의 전 장 소프트웨어 협업 개발 시의 이슈들을 살펴보 고, 이를 통해 품질관리에서 중점적으로 고려해 야 할 점들을 도출하도록 한다. 그리고 4장에서 는 이러한 이슈들을 방지하기 위한 품질관리 방 안을 사례를 통해 제시하도록 한다.
2. 전장 소프트웨어 개발의 특징
국내 자동차 OEM의 일반적인 제품 개발 절차 는 (그림 1)에서 보는 것과 Proto, Master Car, P1, P2 단계를 거쳐 양산을 시작하는 (SOP, Start of Production) 제품 개발 주기를 가지고 있다. 여기 에, 각 단계의 목표 달성 여부를 점검하기 위한 다수의 Gate 심의(G1 .. G7)를 두고 있으며 이를 통과해야 다음 단계를 진행할 수 있다. 차량에서
의 핵심적인 서비스 기능을 담당하게 되는 전장 제품도 이와 같은 단계를 함께 진행하여 개발되 어야 한다.
제품 개발 주기는 일종의 폭포수 모델과 같다 고 볼 수 있는 반면에, 전장 소프트웨어는 제품 개발 주기를 준수하면서도 내부적으로는 여러 번 의 반복 개발이 이루어지는 형태로 진행된다[8]. 대부분의 소프트웨어 기능 요구사양은 Proto 단 계에서 구현이 완료되고, Master 단계에서는 성 능과 같은 비기능 요구사양을 확보하는 것이 목 표이나[9], 국내 환경에서는 많은 경우 요구사양이 Proto 단계에서 확정되지 않기 때문에, P1이나 P2 단계까지도 계속해서 변경이 이루어지고 있다.
따라서 하드웨어나 기구의 경우에는 제품 개발 주기에 따라 태스크나 일정이 예측 가능하기 때 문에 한번 설정된 WBS (Work Breakdown Structure)를 변경하는 경우가 거의 없고, 관리하 는 태스크의 크기가 크더라도 문제가 되지 않는 다. 반면에, 소프트웨어의 경우에는 매 반복 마다 계속해서 태스크를 재정의 하는 것이 필요하며, 몇 번의 반복이 발생할 지도 프로젝트 초기에는 예측이 불가능하다. 또한, 태스크의 크기가 하드 웨어나 기구에 비해 매우 작기 때문에 함께 관리 하기가 매우 어렵다.
또한, 전장 소프트웨어 개발을 위한 소프트웨 어 요구사양은 제품에 대한 시스템 요구사양을 기반으로 정의되어야 한다[10]. 하지만, 많은 경우 에 국내 자동차 완성차 업체 (OEM)가 제품 개발
을 위한 시스템 요구사양을 주지 못하고 있기 때 문에, OEM으로부터 시스템 요구사양을 받지 않 고 선행 개발을 시작하는 경우가 많이 발생하게 된다. 이러한 경우 Tier 1 업체에서는 임시 시스 템 요구사양을 정의하여 개발을 먼저 진행하고 이후에 OEM과 협의해서 사양을 확정해야 하지 만, 최근에는 대부분의 기술 지식을 협력 개발사 가 소유하고 있는 경우가 많아 시스템 요구사양 개발 시 부터 밀접한 협력을 수행해야 한다. 따라 서 요구사양을 정의하는 단계부터 협업체계를 구 성할 필요가 있으며, 이때 기술 공유에 대한 계약 형태, 개발기간 및 비용, 유지보수 방법 및 역할 등에 대해 고려해야 한다.
3. 협업 개발의 이슈들
본 장에서는 하나의 주관 업체와 다수의 협업 업체가 참여하여 전장 소프트웨어를 개발할 때 발생할 수 있는 이슈들을 주관 업체와 협업 업체 의 개발 및 프로젝트 관리 관점에서 정리하고, 이 를 통합하여 품질 관리 측면에서 고려해야 할 사 항들을 정리하도록 한다.
3.1 주관 업체의 개발 이슈들
3.1.1 개발 및 품질 관리 성숙도가 상이한 협업 업체의 통합 관리
개발 및 품질 관리 역량 수준이 상이한 다수의 중소업체와 함께 소프트웨어 개발을 진행하게 되 는 경우 주관 업체에서 이를 통합 조정해 주어야 한다. 주관 업체를 맡는 대부분의 대기업 부품업 체의 경우에는 소프트웨어 개발을 위한 조직의 표준 프로세스와 산출물이 정의되어 있고, 프로 젝트 관리 및 개발 인프라도 잘 갖추어져 있다.
따라서 독자적으로 전장 소프트웨어를 개발할 때
에는 정의되어 있는 프로세스와 인프라를 이용하 여 개발을 진행하면 된다. 하지만, 많은 경우 비 용 또는 보안상의 이유로 이를 협업 업체와 같이 사용할 수 없기 때문에, 프로젝트를 위한 별도의 프로세스와 인프라에 대한 정의가 필요하다. 이 때, 개발 및 품질관리 성숙도가 낮은 협업 업체의 경우에는 자체적으로 프로세스를 정의하고 인프 라를 구축하기 어렵기 때문에, 주관 업체에서는 이러한 상황을 고려해서 프로젝트 계획을 수립해 야 하며 추가적인 관리 노력도 충분히 고려해야 한다.
3.1.2 협업 업체 간 요구사양 및 개발 산출물 공유
다수의 업체가 협업을 하게 되는 경우 각 업체 의 노하우와 기술에 대해 공유가 어렵기 때문에 이에 대한 중재자의 역할을 주관 업체에서 적극 적으로 수행해야 한다. 많은 소프트웨어 개발 프 로젝트가 실패하게 되는 원인 중의 하나가 프로 젝트 이해당사자 간의 커뮤니케이션 부족이다
[11,12]. 소프트웨어 기술 자산에 대한 보호 때문에
협업 업체 간의 원활한 커뮤니케이션이 이루어지 지 않으면, 개발 일정이 지연되는 것은 물론이고 제품 품질에 치명적인 문제가 발생하게 된다. 따 라서 프로젝트 주관 업체에서 모든 참여 업체가 동의할 수 있는 원활한 커뮤니케이션 방법을 정 의해 주어야 하고, 경우에 따라서는 주관 업체를 통한 지식 공유가 일어나도록 해야 한다.
3.2 협업 업체의 개발 이슈들
3.2.1 생소한 개발 프로세스 준수
전체적인 소프트웨어 개발 프로세스에 대한 이 해 및 성숙도가 상대적으로 낮은 협업 업체의 경 우에는 주관 업체의 프로세스를 따르는 것이 매
(그림 2) 협업 개발 이슈 방지를 위한 품질 관리 고려사항 우 형식적이고 관리적인 활동으로 받아들일 수
있다. 특히 품질관리에 대한 성숙도가 낮은 기업 일수록 개발 프로세스나 관련 산출물을 이해하고 익숙해지기 위해 추가적인 노력이 많이 발생할 수 있다. 따라서 주관 업체에서는 협업 업체 별로 프로세스 및 산출물에 대한 교육과 개발 방법론 에 대한 교육을 수행할 필요가 있다.
3.2.2 수시로 변경되는 사양
2장에서 언급한 바와 같이 국내 전장 소프트웨 어 개발 환경의 특성 상 요구사양이 추가되거나 변경되는 경우가 수시로 발생한다. 많은 협업 업 체들은 IT융합 요구에 따라 자동차 도메인이 아 닌 타 산업영역에서 소프트웨어를 개발해 오다가 최근에 자동차로 사업 영역을 넓히고 있다. 이러 한 협업 업체의 경우 국내 전장제품 개발의 특성 에 대한 이해 부족으로 전장 소프트웨어 개발을 위한 초기계획 수립 시 변경 발생 가능성에 대한 고려를 충분히 하지 못하는 경우가 많다. 따라서 협업 업체는 주관 업체와의 요구사양 정의 시 적 극적으로 참여하여 변경을 사전에 방지할 수 있 도록 하고, 또한 체계적인 요구사양 관리로 변경
에 의한 부작용 (side-effect)을 최소화할 필요가 있다.
3.3 품질 관리 고려사항
(그림 2)는 지금까지 제시한 주관 업체 및 협업 업체 측면에서의 협업 개발의 이슈들을 방지하기 위해 품질 관리 관점에서 고려해야 할 사항들을 도출한 것이다.
3.3.1 프로젝트 프로세스 및 개발 인프라 정의 정해진 품질 목표를 달성하기 위해 주관 업체 와 협업 업체 간 입장 차이를 최소화할 수 있는 프로젝트 고유의 개발 프로세스와 산출물 정의가 필요하며, 또한 이런 활동들을 지원하기 위한 도 구들을 표준화하여 산출물과 데이터의 재사용과 호환성을 높일 필요가 있다[13].
3.3.2 프로젝트 이슈 및 위험의 효과적인 관리 프로젝트 진행 중 프로젝트 협업 관계상에 발 생할 수 있는 다양한 이슈 및 위험을 효과적으로 관리하고 커뮤니케이션 할 수 있는 방법이 필요
하다. 무조건적으로 이슈와 위험을 줄이는 방향 으로 관리하게 되면, 협업 관계 상 프로젝트의 문제들을 숨기게 할 뿐이다. 따라서 발생되는 이 슈 및 위험을 조기에 발견하게 하고 발생된 문제 들을 빨리 해결하게 하여 프로젝트에 미치는 영 향을 최소화하는 방향으로 프로젝트 관리가 필요 하다.
4. 품질 관리 방안
본 장에서는 3장에서 도출된 협업 개발 이슈 방지를 위한 두 가지 품질 관리 고려사항에 대 해서 실제 프로젝트에서 접근한 방법을 소개하 도록 한다. 대상 프로젝트는 서로 다른 알고리 즘 기술을 가지고 있는 영상 인식 소프트웨어 개발 업체들과 협업하여 하나의 통합 영상 인식 전장 제품을 개발하고자 하는 부품업체의 프로 젝트이다.
4.1 프로젝트 프로세스 및 개발 인프라 정의 방안
4.1.1 객관적 기준에 따른 협업 업체 수준 파악
CMMI (Capability Maturity Model Integration) 중 조직 관련 영역을 제외한 ML2 (Maturity Level 2)와 ML3의 13개 프로세스 영역[14]에 대해 만족 여부를 평가하여 협업 업체 간 수준을 분석 하고, 공통 적용이 필요한 프로세스와 업체별로 변경 또는 특화 적용이 필요한 프로세스를 파악 한다. 이를 통해 업체들이 실질적으로 수행 가능 한 개발 절차를 수립할 수 있게 되어 개발 실무자 의 오버헤드가 최소화 되면서 균등한 품질 관리 를 수행할 수 있는 기반을 마련할 수 있다.
협업 업체의 수준 파악은 일반적으로 소프트웨
어 개발 조직에 대한 현황 진단을 통해 이루어지 며, 현황 진단을 위해서는 CMMI ML2, ML3에 해당되는 프로세스 영역에 대한 체크리스트를 이 용하여 개발자 인터뷰나 산출물 점검을 통해 수 행한다.
4.1.2 협업 업체 수준에 따른 프로젝트 프로세스의 업체별 테일러링
협업 업체별 수준 파악 결과를 기반으로 프로 젝트에 적용 가능한 수준으로 프로세스를 정의하 고, 업체 간 정보공유가 필요한 산출물과 프로젝 트 관리에 필요한 산출물을 정의한다. 개발 인프 라는 문서 산출물과 소스 코드에 대한 재사용을 고려하여 모든 업체가 사용할 수 있는 인프라로 결정해야 한다. 이는 모든 업체와 협의를 통해 결 정되어야 한다.
업체별로 특화된 활동으로 별도의 프로세스와 산출물, 인프라 정의가 필요한 경우 해당 업체와 의 협의를 통해 이를 정의한다. 특히 협업 업체 간 정보 공유가 원활히 이루어 질 수 있게 하면 서, 정보 자산을 보호할 수 있도록 프로세스 및 개발 산출물 양식을 설계하여야 한다. (그림 3)
프로젝트 프로세스에 대한 테일러링의 전략중 의 하나로 주관 업체가 정의한 표준 프로세스를 기반으로 프로세스 활동의 일관성 및 산출물의 연계성을 보장하는 전제하여 몇 가지 유형의 프 로젝트 프로세스를 사전 정의한다. 이렇게 사전 정의된 유형화된 프로젝트 프로세스를 협업 업체 의 프로세스 수준이나 개발 소프트웨어 또는 프 로젝트 특성에 적합하도록 선택하게 하는 것이 다. 이러한 전략의 장점은 긴급하게 또는 적절치 못한 프로세스 테일러링이 소프트웨어 개발의 실 행 상에서 발생할 수 있는 개발 활동 간의 연계성 부족이나 산출물의 활용도 저하와 같은 문제를 예방할 수 있다.
(그림 3) 성숙도 수준을 고려한 프로젝트 프로세스 정의
4.1.3 지속적이고 일관된 품질 보증 활동 수행 수립된 프로세스와 산출물, 인프라가 협업 업 체 간에 정의한 내용대로 사용되고 있는지 검토 하고, 확인을 해주는 활동이 필수적으로 필요하 다. 하지만, 점검을 수행하기 전에 이를 적용할 수 있도록 충분한 프로세스 교육과 산출물 작성 가 이드, 인프라 활용 점검 활동이 선행되어야 한다.
또한, 협업 업체 간의 균등한 품질 확보를 위해 서는 품질 담당자의 지속적인 역할 수행으로 일 관된 품질 보증 업무가 이루어질 수 있도록 해야 한다. 품질 보증 활동 보고는 보고체계 상의 보고 시점에서 정보를 공유하여 프로젝트 진행상에 발 생되는 품질 보증 이슈 및 위험이 관리될 수 있도 록 한다.
지속적인 품질 보증 활동을 수행하기 위해서는 잘 짜여진, 정리된 품질보증 활동 계획서가 필수 적으로 요구된다. 누가 어떤 활동을 개발 일정상 에서 언제 수행할 것인가를 구체적으로 정의하 고, 이들이 적합하게 이루어지고 있는지를 점검 해야 한다.
4.2 프로젝트 이슈 및 위험의 효과적인 관리 방안
4.2.1 WBS 작성 세분화
이슈와 위험을 효과적으로 그리고 객관적으로 관리하기 위해서는 관리 대상이 되는 활동과 수 행 주체, 수행 일정이 WBS에 명확하게 정의가 되어 있어야 한다. WBS는 모든 협업 업체가 공 동으로 사용할 수 있는 인프라를 활용하여 구성 하도록 하고, 효과적인 관리를 위핸 개발 총괄 WBS와 협업개발 WBS로 구분하여 정의한다.
개발 총괄 WBS는 협업 개발을 위한 주요 태 스크와 주요 개발 일정을 표현한 WBS로 이를 통 해 협업 개발의 전체적인 흐름을 파악하고, 업무 별, 기간별, 업체별 Critical Path를 관리하는데 사 용한다. 협업개발 WBS는 협업 업체 별로 주기를 설정하여 (예, 매 분기별) 지속적으로 세분화하여 작성하도록 하여, 과제 진행에 대한 이슈와 위험 이 바로 발견될 수 있도록 한다. 협업개발 WBS 에서의 업무 태스크의 대상과 단위는 업무수행
(그림 4) 협업 업체별 WBS 분리작성 및 세분화 체계
(그림 5) WBS를 통한 이슈/위험 관리 체계 시 보고되어야 하는 최소 단위이거나 태스크 수
행 시 산출물이 나오는 단위로 태스크를 정의하 고, 태스크 수행 기한은 프로젝트의 보고 주기와 맞추도록 한다. (그림 4)
4.2.2 실질적인 WBS 관리를 통한 이슈, 위험 식별 및 관리
세분화된 협업개발 WBS를 이용함으로써 WBS 관리가 실질적으로 수행될 수 있고, 또한 이를 통해 프로젝트 진행상의 이슈 및 위험들이 WBS를 통한 진척 관리만으로 바로 발견되고 관 리될 수 있다. 여러 업체가 협업을 하는 과정에서
는 서로 간의 업무가 중첩되어 진행되기 때문에 어느 한 업체의 업무 지연은 다른 업체의 업무 지 연으로 연결되기 때문에, 그 즉시 이슈 및 위험으 로 발견되는 것은 매우 중요하다. 이렇게 발견된 이슈와 위험은 업체별로 Action Item화하여 놓치 지 않고 해결할 수 있도록 한다. (그림 5)
(그림 6)은 다수의 협업 업체가 참여하는 전장 소프트웨어 개발 프로젝트에서 개발 총괄 WBS 와 협업개발 WBS를 이용하여 작성한 프로젝트 대쉬보드의 사례이다. 이를 통해 프로젝트 전체 의 건강 상태는 물론 협업 업체별 건강 상태를 한 눈에 파악할 수 있으며, 프로젝트 진척율, 이슈,
(그림 6) 협업 개발 프로젝트의 대쉬보드 사례
위험에 대한 진행 현황이 각 협업 업체 별로 일목 요연하게 표현됨으로써 효과적인 프로젝트 관리 를 수행할 수 있다. 이를 위해서는 WBS가 주관 업체 프로젝트 관리자 한 명 만을 위한 것이 아니 라, 협업 업체 전체가 실질적으로 사용될 수 있는 WBS로 작성되고 지속적으로 관리되어야 한다.
5. 결 론
현재는 국내 주요 전장제품 업체들이 현대자동 차와 같은 완성차 업체의 요구에 의해 강제적인
방법으로 CMMI와 같은 프로세스 체계를 갖추고 있다. 하지만, 이러한 Tier 1 업체들이 아직까지 는 실질적인 프로세스 내재화가 되고 있지 않아 서, 독자적으로 체계적인 전장 소프트웨어 프로 젝트 관리를 수행하기에는 역량이 부족한 상황이 다. 그럼에도 불구하고, 본 논문에서 소개한 것과 같은 다수의 협업 업체가 참여하여 하나의 전장 소프트웨어를 개발하는 프로젝트는 점점 더 많이 발생할 것으로 예상된다. 이를 대응하기 위한 최 선의 방법은 주관 업체와 협업 업체의 소프트웨 어 개발 프로세스 실행 역량이 빨리 내재화되어
본 논문에서 소개한 품질관리를 스스로 수행하는 것이다. 이러한 역량의 내재화가 짧은 시간에 달 성될 수 있는 것은 아니다. 따라서 조직의 현황 분석을 통하여 쉽고 빠르게, 그리고 중요한 품질 관리 활동 분야가 무엇인지를 우선적으로 식별하 여 적용하고, 점진적으로 전체 프로세스 영역으 로 확대하는 것이 필요할 것이다.
참 고 문 헌
[ 1 ] 송복구, “자동차의 스마트화 동향과 전망”, 한국 자동차산업학회 춘계 워크숍, 4월, 2011.
[ 2 ] Arthur D Little, Increasing the Efficiency of your Automotive Software Development, Trend Study, 2005.
[ 3 ] Klaus Grimm, “Software Technology in an Automotive Company - Major Challenges,“
The Proceedings of ICSE’03, 2003, pp.498- 503.
[ 4 ] M. Broy, “Challenges in Automotive Software Engineering,” The Proceedings of ICSE’06, 2006, pp.33-42.
[ 5 ] VDA, Quality Management in the Automotive Industry, 1998.
[ 6 ] Herbsleb, J.D., Mockus, A., “An empirical study of speed and communication in globally distributed software development,”
IEEE Transactions on Software Engineering, Vol.29 Issue 6, pp.481-494, June, 2003.
[ 7 ] Broy, M., Kruger, I.H., Pretschner, A., Salzmann, C., “Engineering Automotive Software,” Proceedings of the IEEE, Vol. 95 Issue 2, pp.356-373, Feb., 2007.
[ 8 ] Jorg Schauffele, Automotive Software Engineering: Principles, Processes, Methods, and Tools, SAE International, June, 2005.
[ 9 ] F. Caffery, M. Pikkarainen, and I. Richardson,
“AHAA –Agile, Hybrid Assessment Method for Automotive, Safety Critical SMEs,” The Proceedings of ICSE’08 2008, pp.551-560
[10] A. Pretschner, M. Broy, I. H. Krugr, T.
Stauner, “Software Engineering for Automotive Systems: A Roadmap,” The Proceedings of FOSE’07, 2007, pp.55-71.
[11] A. Lewandowski and G. Bourguin, “Supporting Collaboration in Software Development Activities,”
The Proceedings of ICCSCW 2006, pp.1-7.
[12] Imed Boughzala1 and Gert-Jan de Vreede,
“A Collaboration Maturity Model: Development and Exploratory Application,” 45th Hawaii International Conference on System Sciences, 2012, pp.306-315.
[13] B.M. Hwong and X. Song. “Tailoring the Process for Automotive Software Requirements Engineering,” The Proceedings of AuRE’06, 2006, pp.2-3.
[14] D.M. Ahern, A. Clouse, and R. Turner, CMMI Distilled, Pearson Education, 2008.
저 자 약 력
박 상 우
․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
이메일 : [email protected]
∙ 2001년 광운대학교 제어계측공학과(학사).
∙ 2001년~2009년 (주)삼성전자 DVS사업부 책임연구원.
∙ 2010년 (주)삼성테크윈 Security Solution사업부 책임연 구원.
∙ 2011년~현재 (주)솔루션링크 책임컨설턴트.
∙ 관심분야 : 소프트웨어 공학, 임베디드 소프트웨어 테 스팅, 소프트웨어 프로세스 개선, 소프트웨어 요구공학
허 정
․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
이메일 : [email protected]
∙ 2002년 중앙대학교 산업정보(학사).
∙ 2004년 고려대학교 산업시스템정보공학(석사).
∙ 2004년~2007년 (구)한국소프트웨어진흥원 소프트웨어 공학센터/책임.
∙ 2007년~현재 솔루션링크 수석 컨설턴트, 제품센터장.
∙ 관심분야 : 소프트웨어 공학, CMMI, Automotive-SPICE, 소 프트웨어 안전성, Concurrent Engineering 등
이 남 희
․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
이메일 : [email protected]
∙ 1991년 한국과학기술원 전산학과(학사).
∙ 1998년 한국과학기술원 전산학과(석사).
∙ 2003년 한국과학기술원 전산학과(박사).
∙ 1994년~1995년 (주)LG전자 미디어통신연구소/연구원.
∙ 2003년~2006년 (주)삼성SDS 첨단소프트웨어공학센터 SW Quality팀 책임연구원.
∙ 2006년~2007년 (주)삼성전자 CS경영센터 개발품질보 증팀 과장.
∙ 2007년~현재 (주)솔루션링크 사업본부장.
∙ 관심분야 : 소프트웨어 공학, 임베디드 소프트웨어 테스 팅, 기능 안전성 (ISO 26262, DO-178B), 정형 기법, 소프 트웨어 프로세스 개선 (CMMI, SPICE, TMMi, TPI 등)
홍 장 의
․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․․
이메일 : [email protected]
∙ 1998년 충북대학교 전산학과(학사).
∙ 1990년 중앙대학교 컴퓨터공학과(석사).
∙ 2001년 한국과학기술원 전산학과(박사).
∙ 1990년~1995년 한국국방과학연구원 선임연구원.
∙ 2001년~국방과학연구소 선임연구원.
∙ 2002년~2004년 (주) 솔루션링크 연구소장.
∙ 2004년~현재 충북대학교 소프트웨어학과 부교수.
∙ 관심분야 : 소프트웨어공학, 임베디드 소프트웨어, 모델 기반 소프트웨어 개발, 소프트웨어 품질공학, 소프트웨 어 프로세스 개선
