- 흘러가는 말씀으로...
Best US Software Companies의 임베디드 코드에서 1000줄 당 8 ~ 12개꼴로 코드 에러가 발생한다.
이슈는 이미 발생한 문제, 리스크는 발생할 수도 있는 문제 (아직 발생 안 함.) -> 계획 수립의 관점에선 리스크가 더 중요하다!
자동차 소프트웨어 개발 프로세스 개요
- 강의 목표
기본적인 프로세스 개념을 정확하게 이해하는 것.
자동차의 전장화와 소프트웨어 시스템의 증가
-
자동차의 전장화
자동차 제조원가 중 전기,전자 부품의 비중이 2020년 50%를 달성. -
자동차 내 소프트웨어의 대형화
현재는 자동차 하나에 2 ~ 3억 line 정도의 소스코드가 들어간다.
현재는 70 ~ 100여개의 ECU. 요즘은 통합제어기들이 나오고 있다. -> ENE 아키텍쳐.
글로벌 자동차 OEM 업체들의 품질 요구사항
- 품질(Quality란?)
- 명시적, 묵시적 요구를 만족시키는 제품 또는 서비스의 능력에 관한 특성 -> 항상 품질은 사용자와 고객 관점에서 바라보아야 한다.
- 품질의 두 가지 관점
- 프로세스 품질 (Process Quality)
PDCA: plan -> do -> check -> act(프로세스 개선)
대부분의 기업들이 do에만 집중한다.
- 프로세스 품질 (Process Quality)
- 제품 품질 (Product Quality)
- 추적성 관점: 개발 단계별 산출물(work product)들이 이전 단계 산출물에 기반하여 만들어졌는가?
- 일관성 관점: 개발 단계별 산출물(work product)들이 이전 단계 산출물과 일관성을 유지하고 있는가?
- 최종 산출물이 고객 요구사항을 만족하는가?
소프트웨어의 정의와 특징
- 소프트웨어의 정의
코딩 이전과 이후에 나오는 모든 산출물들과 데이터들을 포함한 것이 소프트웨어이다.
- 소프트웨어의 특징
- 구조가 눈에 보이지 않음(비가시성(Invisibility))
클래스 하나에 다 때려 넣을 수도 있고, 모듈화 해놓았을 수도 있고.
프로그램의 동작원리가 눈에 보이지 않는다.
최대한 가시화 시키기 위한 노력을 해야한다. - 비 선형(Non Linearity)의 복잡한 구조
예측이 힘들다. - Does not wear out but changes
마모되지 않는다. - 사람 중심(Human Intensive) 작업
사람이 직접 개발하기 때문에 -> human error를 줄이기 위한 노력을 해야한다. => 명세서
개발 이후에 코드리뷰, 테스팅이 중요한 이유.
- 구조가 눈에 보이지 않음(비가시성(Invisibility))
소프트웨어 공학 개요
- 소프트웨어 공학을 다루고 있는 표준
- 모든 산업 분야
SWEBOK, ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15504 - 자동차
- Automotive SPICE
유럽쪽 표준
전반적인 품질 관련 - CMMI(얘도 사실 자동차 이외 분야에서도 널리 쓰임.)
미국쪽 표준
과거에 많이 쓰였다. - ISO 26262
안전에 포커스를 둔 것. 오동작으로 인한 안전에 포커스를 둠. - ISO 21448
성능적인 한계로 인한 안전 문제에 포커스를 둠. - ISO/SAE 21434
사이버 보안 특화
- Automotive SPICE
- 자동차는 요즘 모듈에 따라 Automotive SPICE에 ISO 26262, ISO 21448을 더해 쓰거나 ISO/SAE 21434를 더해 쓴다.
- 모든 산업 분야
소프트웨어 개발 프로세스와 생명주기
-
프로세스의 정의
고객의 요구사항을 만족하는 제품을 만들기 위한 절차/방법, 도구/장비, 인력의 통합 -
계획 = 프로세스 정의
계획 != 스케쥴
스케쥴은 계획에 포함되는 개념이다. -
소프트웨어 개발 프로세스의 정의
소프트웨어 개발에 필요한 절차/방법만이 아니라, 그와 관련된 도구/장비, 인력의 통합 -
소프트웨어 개발 생명주기의 정의
소프트웨어를 어떻게 개발할 것인가에 대해 정의한 최상위 수준의 프로세스 -> 마치 로드맵 같은 것 -
소프트웨어 개발 생명주기의 접근 방식
"Big Bang" Approach: 한 사이클에 한방에 만들자.
"Evolutionary" Approach: 잘게잘게 쪼개서 만들자. -
소프트웨어 개발 생명주기의 유형
주먹구구식 개발 모델(Build & Fix Model)
폭포수 모델(Waterfall Model)
원형 모델(Prototyping Model)
나선형 모델(Spiral Model)
-> v-model도 여기 같은 선상에 놓일 수 있다. -
주먹구구식 개발 모델
운영해보면서 계속 수정 -
폭포수 모델(빅뱅)
마지막에 비로소 소프트웨어가 출현 -
원형 모델(Evolutionary)
진화적, 단계별로 만들어나간다.
프로토타입을 만들어서 그것을 개선해나가는 것.
고객 평가를 거친다. -
나선형 모델(Evolutionary)
폭포수 및 원형 모델의 장점을 수용하고 위험 분석을 추가한 모델 -> 리스크 분석 단계가 명시적으로 포함되어있다.
V-Model 프로세스
- V-Model 생명주기 프로세스
수없이 많은 커뮤니케이션이 진행됨. 현실에선 어느정도 오버랩도 진행됨.
궁극적 목표
-> 프로세스의 퀄리티를 높여서 소프트웨어 제품에 대한 품질을 높이자.
세부적으로는 waterfall 방식으로 되어있다.
v & v (verification and validation) => 검증과 확인
인수 테스팅 계획 수립을 고객/사용자 요구 사항 활동 시에 같이 진행. 각 설계와 그에 맞는 테스팅을 대응시켜 놓았다. => 왼쪽을 기반 자료로 테스팅 시행 = 시프트 레프트. 각 단계들은 PDCA(plan, do, check, act) 방식으로 수행하자.
세부적인 단위 부터 점차적으로 테스팅을 진행
상세 설계를 진짜 잘해야 테스팅의 퀄리티도 높아지겠구나..
-> 문서에 대한 리뷰도 빼놓을 수 없겠다.
