협업을 통한 안드로이드 서비스 개발 프로젝트 수행 사례1) 프로젝트배경 2) 해결해야할과제설명 3) 과제해결을위한기술적어려움 II. 기술적어려움해결을위한노력

협업을 통한

안드로이드 서비스 개발

프로젝트 수행 사례

2014/02/06

차량융합신기술센터

선행신기술팀, 오세종 수석

© All rights reserved including industrial property rights and all rights of disposal such as copying and passing on to third parties.

목차

I. 배경 상황과 기술적 어려움

1) 프로젝트 개요

2) 해결해야 할 과제 설명

3) 과제 해결을 위한 기술적 어려움

II. 기술적 어려움 해결을 위한 노력

1) 솔루션 개요 및 필요성

2) 차량 IT 특화 툴 체인 적용

3) 차량 IT 특화 방법론 적용

4) 테스트 결과를 통한 사양 업데이트

III. Samples

IV. 결론

IBM과 산업계간 협력에 대한 제안

3


Autron/BCDC


▣▣▣▣ 과제 해결을 위한 기술적 어려움

■ 확정되지 않은 사양

� 선행 개발의 특성 상, OEM의 요청에 따라 사양이 계속 추가 또는 변경

� 선행 개발 중, 가능한 많은 가능성을 검증해 보려는 OEM의 요구

� 촉박한 개발 기간 중, 계속 변하는 사양과 다양한 가능성을 모두 검증해야

하는 어려움

■ 다수의 협력사와 공동 작업

� AVN 이라는 대규모 프로젝트 특성 상, 10개 이상의 협력사와 공

동 작업

� 하나의 sub-project에서도 적어도 4~5개의 협력사가 관여 됨

� 초기 Interface 설계를 통해 각 사 별 명확한 기능과 R&R 정의가

필요했음

� 검증 시, 문제 발생 포인트를 명확히 분석하여 담당사간 조율해야

함.

4


Autron/BCDC


목차


1) 프로젝트 배경








III. Samples

IV. 결론


© All rights reserved including intellectual property rights and all rights of disposal such as copying and passing on to third parties.

솔루션 개요 및 필요성

� 방법론 : 원하는 품질의 결과물을 얻기 위해 어떤 Action을 수행해야 하는 지를 정의

� Tool chain : 결과물의 문제 발견 시, 관련된 사양을 정확히 찾아서 업그레이드 하기 위함.

① ~ ⑦ : 선행 개발 Action[1] ~ [5] : 선행 개발 결과물

① 설계

[2] 사양 모델

③ 사양 선택

④ 모델 추출

⑤” 테스트케이스 도출

⑤’ 모델 기반코드 개발

⑦ 테스트 Feedback을 통한 사양 업데이트

⑥ 검증

[3] 선택 사양

[5] 테스트 코드

[4] 프로토타입 제품

[1] 차량 IT 사양 DB

② 설계 검증

기술

개요

기술

개요

기술

범위

기술

범위

필요성

대두

필요성

대두

� 빈번한 사양 변경을 개발 도중에도 신속히 반영할 수 개발 환경

� Interface 설계와 검증을 참여 업체와 공동으로 진행할 수 있는 협력 체계


차량 IT 특화 툴 체인 적용

� 툴 간 연동성 부족 :

� 요구 사항에서 테스트까지 결과물들간 추적성을 연결해 주기

어려움

� 사용의 복잡함으로 실무자들의 외면

기존

툴체인

문제

기존

툴체인

문제

� 툴 간 연동성 확보와 쉬운 사용성을 위하여:

� 쉬운 툴 사용을 위한 툴 profile 제공 � 구현 � 효과 분석

� 사양 기반 자동 테스트 케이스 개발 � 구현 � 효과 분석

� 사양��설계��검증 툴간 연동 모듈 개발 � 구현 � 효

과 분석

기존

툴체인

문제

극복

기존

툴체인

문제

극복

기능 흐름도를 통한 사양

분석

기능

기능

흐름도를

흐름도를

통한

통한

사양

사양

분석

분석

상태천이도를 통한 사양

설계

상태천이도를

상태천이도를

통한

통한

사양

사양

설계

설계

일정 및 이슈 관리

일정

일정

및

및

이슈

이슈

관리

관리

차량 IT 특화 요구사항 관

리

차량

차량

IT

IT

특화

특화

요구사항

요구사항

관

관

리

리

IBM DOORS IBM Rhapsody Modeler(FreeWare)

IBM Rhapsody DeveloperRedmine

타겟 보드 반영 후 검증

타겟

타겟

보드

보드

반영

반영

후

후

검증

검증

TestExpress


차량 IT 특화 방법론 적용

� 결과물간 추적성(또는 연계성) 결여 :

� 사양에서 바로 구현(코딩) 수행. 즉, 설계 과정의 생략으로 사양 변경시 구현 변경점 찾기

어려움

� 같은 이유로, 제품 결함 시 문제의 구현 부분을 찾아 개선하기 어려움

기존

방법론

문제

기존

방법론

문제

� 결과물간 추적성(또는 연계성) 부여를 위하여 :

� 요구 사항 관리를 위한 DB 스키마 제안 � 구현 � 효과 분석

� 요구 사항 기반 객체 지향 설계 방법론 제안 � 적용 � 효과 분석

� 설계 기반 테스트 케이스 도출 방법론 제안 � 적용 � 효과 분석

기존

방법론

문제

극복

기존

방법론

문제

극복

과거 모습 변화된 모습

MS Office오로지 문서화작업이 목적

검증되지

못한 사양OEM

(사양 제공자)

Suppliers

(양산 개발자)

사양과 개발간 추적성 결

여

Class Diag.

Sequence Diag.

Statechart Diag.

Automatic Test

요구사항 DB & UML 설계

사양 검증

목적

검증된 사양OEM

(사양 제공자)

Suppliers

(양산 개발자)

사양과 개발간 추적성 부

여


테스트 결과를 통한 사양 업데이트

OEM

(사양 제공

자)

오트론

(Architect)

협력사

(Developers)

오트론

(Testers)

①지속적인 신규 사양 반영 요청 (MS Office)

②DOORS로 사양 변경/추가 관리

③사양 별 Test case 작성 후 DOORS에 등록

④사양 검토 후 개발 계획 수립 (Redmine)

⑤Interface 설계 협력 (Rhapsody)

⑥Interface 구현 및 Unit 검증

(Rhapsody, ADT)

⑦기능 통합 후 연동성 검증 (ADT, adb)

⑧테스트 결과 및 이슈 등록

(DOORS, Redmine)

⑨시스템 검증 시나리오를

Test Express 에 기록

Test case update !!

테스트 결과를 통한 사양 update !!


목차










III. Samples

IV. 결론



▣ 고객의 요청을 명확하게 이해하라

■ 초기 요구 사항 분석


▣ 고객의 요청을 명확하게 이해하라

■ 고객과 지속적인 Interview를 통하여 요구사항을 구체화 하기

12

Linux Kernel

Application

Java

Framework

Native

Framework

H/W layer

Voice Handler

ModeService

Audio Driver

LibrariesAudioFlinger

JNI Interface

타 manager(Audio, CD 등)

MICPTT Speaker

DIRANAADC DAC

Automotive Lib.

ALSA

Micom Key Interface

LP (언어팩) LP (시나리오)

ASR TTS

Micom Manager

Voice Service

▣ 시스템의 기초 구조와 Interface를 설계하라

13

MediaRecorder MediaPlayer AudioService

AudioManager

AudioSystem

MediaPlayer/MediaRecorder Native

AudioTrackAudioRecord

AudioFlinger

/dev/eac

AudioHardwareInterface AudioStreamIn AudioStreamOut

AudioMixerAudioResampl

er

iBinder iBinder iBinder

JNIJNIJNI

AIDL

NAVI

JNI

ModeService

AIDL

AIDL

JNI

AF_Adapter

iBinder

MicomManager

AIDL

▣ 시스템의 기초 구조와 Interface를 설계하라

14▣ 시스템 동작을 기획하고 검증 시나리오를 준비하라




18

Interface type Interface name operations operation 설명 return type arguments

argument

설명

담당자 검증 일정

Provided

IMediaToMM cdEjected XXX XXX XXX XXX XXX XXX

cdInserted XXX XXX XXX XXX XXX XXX

notiMediaAction XXX XXX XXX XXX XXX XXX

IMicomToMM keyPressed XXX XXX XXX XXX XXX XXX

restoreStateData XXX XXX XXX XXX XXX XXX

sensorDataArrived XXX XXX XXX XXX XXX XXX

INaviToMM onStatusChanged XXX XXX XXX XXX XXX XXX

IVoiceToMM notiAVAction XXX XXX XXX XXX XXX XXX

Required

IMMtoAndroid clearAudioTrack XXX XXX XXX XXX XXX XXX

IMMtoMedia pauseMediaPlay XXX XXX XXX XXX XXX XXX

startMediaPlay XXX XXX XXX XXX XXX XXX

IMMtoMicom backupStateData XXX XXX XXX XXX XXX XXX

controlNaviAndMedia XXX XXX XXX XXX XXX XXX

requestStateData XXX XXX XXX XXX XXX XXX

IMMtoNavi getNaviLastMode XXX XXX XXX XXX XXX XXX

IMMtoVoice pauseVoiceHandler XXX XXX XXX XXX XXX XXX

readyVoiceHandler XXX XXX XXX XXX XXX XXX

� Interface 구현 : � Main logic 역할의 StateControler 와 주변 Manager를 de-coupling 하기 위함

� aidl synchronous call 방식을 사용하기 때문에, call 지연을 최소화 함

▣ Interface 별 담당사를 할당하고 R&R 결정하라

▣ 개발 범위와 Software 패키징 결정 19

▣ 개발 범위의 Software 구조 설계 20

▣ 동작 모델링과 Fast prototyping을 통한 검증 21


목차






1) 사양 분석과 검증을 위한 방법론 적용

2) 설계 기반 검증 툴 도입

3) 사양 기반 테스트 케이스 도출과 자동 테스트


III. Samples

IV. 결론



▣▣▣▣ IBM과 산업계간 협력에 대한 제안

■ IBM에게 바라는 모습

� 국내 기업의 문제점과 고민 사항을 먼저 자세히 이해하고,

� 해외 성공 사례를 국내 기업에 맞게 최적화 하여 전달하려는 노력

� 지식을 공유하고 키워 나갈 수 있는 생태계를 조성하고 있는가?

■ 산업계에 바라는 모습

� 기술 융합을 통한 새로운 가치 창조 �� 다양한 분야의 협력이 더 중요해 짐.

� 이기종 분야간 협력을 위해 가장 효율적인 방법을 고민해야 함.

� 오랜 관행과 경험만을 고수하며, 현실에 안주하려는 경향은 없는지 ?

� 해외 성공 사례 면밀히 검토하고, 그들이 왜 그런 방식으로 접근하는 지를 고민해 볼 것

Documents

협업을 통한 안드로이드 서비스 개발 프로젝트 수행 사례1) 프로젝트배경 2) 해결해야할과제설명 3) 과제해결을위한기술적어려움 II. 기술적어려움해결을위한노력