임베디드 스터디 - 소프트웨어 공학, SDLC 모델

소프트웨어 공학이란?

• 1968년 NATO 컨퍼런스에서 Fritz Bauer가 정의한 것이 출발점

“The establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines.”

• 핵심 키워드 3개 : reliable(신뢰성), works efficiently(효율성), real machines(실제 기계)
• 여기에 economically도 중요함 : SW 공학은 단순히 좋은 SW를 만드는 게 아니라 비용과 일정 제약 안에서 만드는 공학임을 원래 정의부터 명시한다.
• 한 줄 요약 : SW의 제작부터 운영까지 생산성을 높이기 위해 기술적·인간적 방법론을 제공하는 학문

소프트웨어 위기(Software Crisis)

• 1960~70년대, SW 개발 현장에서 일정 지연·관리 부재·품질 미흡이 반복
• 하드웨어가 단순하던 시절에도 위기가 발생한 이유는 SW 자체의 본질적 특성 때문임

특성	결과
눈에 안 보임(Invisibility)	진척도 파악 어려움 → 관리 부재
요구사항 검증 어려움	완성 후에야 오류 발견 → 일정 지연·품질 미흡
복잡도 비선형 증가	모듈 수↑ → 연결점 기하급수적↑ → 예측 불가

SDLC 4대 모델

폭포수 모델 (Waterfall)

요구사항 분석 → 시스템 설계 → 구현 → 테스트 → 유지보수

• 각 단계가 완전히 끝나야 다음 단계로 진행한다.
  • 강점 : 단계별 문서화 우수, 진척도 관리 용이
  • 약점 : 요구사항이 중간에 바뀌면 대응 불가, 테스트 단계까지 오류 발견이 늦어짐

V-Model (검증 강화 폭포수)

요구사항 분석  ←————————————→  인수 테스트
  시스템 설계  ←——————————→  시스템 테스트
아키텍처 설계  ←————————→  통합 테스트
    상세 설계  ←——————→  단위 테스트
                  구현

• 폭포수의 각 설계 단계가 대응하는 테스트 단계와 직접 연결되어 요구사항 추적성(Traceability)을 확보
• 실무 적용 : DO-178C 기반 항공우주 SW 개발의 표준 프로세스
• 설계 산출물이 곧 테스트 기준이 되기 때문에, 개발 완료 후 “이게 맞나?” 문제가 사전에 차단됨

프로토타이핑 모델 (Prototyping)

요구사항 → 프로토타입 개발 → 고객 평가 → 요구사항 구체화 → (반복)

• 고객이 프로토타입을 직접 써보며 요구사항을 구체화한다. 프로토타입이 요구사항을 끌어내는 도구 역할을 한다.
  • 강점 : 요구사항 불명확 상황에서 유리, 발주자·개발자 모두 공동 참조 모델 공유
  • 강점 : 반복 과정에서 수정·개선이 이미 일어나므로 출시 후 유지보수 부담 감소
  • 약점 : 프로토타입에 과도하게 의존하면 완성도 낮은 제품이 그대로 출시될 위험

나선형 모델 (Spiral, Boehm 1986)

[계획] → [위험 분석] → [개발 및 테스트] → [고객 평가] → (다음 사이클)

• 4단계 사이클을 반복하며, 위험 분석(Risk Analysis)이 핵심이다.
  • 강점 : 대규모·고위험 프로젝트에 적합, 위험 요소를 초기에 식별하고 대응
  • 약점 : 관리 복잡도 증가, 비용 상승
• 예제 시나리오 — 위성 자세제어 SW 개발

[사이클 1] 계획: 자세제어 루프 요구사항 정의
           위험 분석: RTOS에서 모든 태스크 타이밍 동시 만족 시
                     MCU 성능 부족 가능성 → 치명적 위험으로 분류
           개발: 타이밍 시뮬레이션 프로토타입 구현
           평가: 최악 조건 타이밍 여유 확인 → 진행 가능
 
[사이클 2] 계획: 센서 퓨전 알고리즘 추가
           위험 분석: 부동소수점 연산량 → 실시간성 영향 분석
           개발: FPU 활용 최적화 구현
           평가: 고객(시스템팀) 검토 → 승인
 
[사이클 3] 계획: 페일세이프 로직 추가
           위험 분석: 단일 센서 고장 시 폴백 동작 정의
           개발: 이중화 처리 로직 구현
           평가: 최종 통합 검증

• 개발 초기에 가장 위험한 요소를 먼저 검증하기 때문에, 후반부에 치명적 결함이 발견되는 상황을 방지한다.

애자일 / Scrum

Product Backlog → Sprint Planning → Sprint(1~4주) → Review/Retrospective → (반복)

• 2001년 Agile Manifesto 핵심 가치:
  • 개인과 상호작용 > 프로세스와 도구
  • 동작하는 SW > 포괄적인 문서
  • 고객과의 협력 > 계약 협상
  • 변화에 대응 > 계획 준수
• 강점 : 요구사항 유동적 환경에서 빠른 대응
• 임베디드에서의 한계 :
  1. HW 연동 의존성 — 타깃 보드 없이 Sprint 완료 불가 (Hardware Availability)
  2. 검증 사이클 장기화 — SW 수정 1시간, 검증 하루 (Long Verification Cycle)
  3. 디바이스 성능 고정 — 타깃 MCU/SoC 변경 불가 (Fixed Resource Constraint)
  4. 인증 규격 요구 — DO-178C는 모든 변경에 영향분석 + 재검증 요구 (Regulatory Compliance)
• 예제 시나리오 — 사내 위성 운용 모니터링 대시보드 개발

[Sprint 1 - 2주]
  목표: 텔레메트리 수신 데이터 실시간 표시
  결과: 기본 데이터 파싱 + 화면 출력 동작
  피드백: "배터리 전압 트렌드 그래프도 필요해"
 
[Sprint 2 - 2주]
  목표: 배터리/전력 트렌드 시각화
  결과: 시계열 그래프 추가
  피드백: "알람 임계값 설정 기능 추가해줘"
 
[Sprint 3 - 2주]
  목표: 알람 설정 및 이메일 알림
  결과: 임계값 초과 시 자동 알림 동작
  피드백: 승인 → 출시

• 비행 소프트웨어(FSW)가 아닌 지상 운용 도구처럼, 하드웨어 의존성과 인증 요구가 낮은 영역에는 Agile이 효과적
• 임베디드 프로젝트 내에서도 criticality에 따라 프로세스를 분리 적용하는 것이 현실적

모델 선택 기준

상황	적합한 모델
요구사항 확정 + 인증 필수	V-Model
요구사항 불명확 + 고객 피드백 필요	프로토타이핑
고위험 + 요구사항 일부 불명확	나선형
요구사항 유동적 + 빠른 대응	애자일(Scrum)

실무 혼합 패턴

교과서적 모델을 단독으로 쓰는 경우는 드물다. 현대 임베디드·항공우주 SW 개발에서는 아래와 같은 계층적 혼합이 실제로 쓰인다.

전체 프로젝트  →  Spiral    (초기 위험 분석 및 사이클 관리)
각 사이클 내부  →  V-Model   (시스템↔SW 요구사항 추적성 확보)
구현 단계 내부  →  Agile     (빠른 반복 개발)

인증 규격(DO-178C)은 특정 모델을 강제하지 않는다. “어떤 모델을 쓰든 추적성과 검증을 보장하라”는 원칙만 요구한다.