ASPICE 정복하기 - (2) SWE란?

지난번 ASPICE 용어에 대해 알아보았다. 이번엔 ASPICE 중 SWE라는 프로세스에 대해 알아볼 것이다. SWE는 Software Engineering processes의 약자로, 소프트웨어 관련된 프로세스를 의미한다. SWE.1-SWE.6을 통해 소프트웨어 개발 모델을 알아보자.

이전글: ASPICE 정복하기 - (1) ASPICE 용어 친해지기

 

SWE란?

SWE란 Software Engineering processes를 의미한다. SWE.1부터 SWE.6까지 총 6단계로 구성되어 있고 V-Cycle 형태를 띠고 있다. 각각의 단계를 살펴보면 다음과 같다.
 
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verifi cation and Integration Verification
SWE.6 Software Verification
 
V-Cycle 형태라고 했는데,  SWE.1은 SWE.6으로 검증하고, SWE.2는 SWE.5로 검증하고, SWE.3은 SWE.4로 검증되는 구조이다.

SWE.1-6

각 단계를 짧게 설명하면 다음과 같다.
SWE.1 Software Requirements Analysis

: 시스템 요구사항과 아키텍처에 적합한 소프트웨어 요구사항을 구성하는 것.

'소프트웨어 요구사항'이란 건 도대체 뭘까? 쉽게 얘기해서 SW가 제공해야하는 기능이라고 접근하면 쉽다.

 

예를 들어,

'SW를 구현하여 ADC 값을 읽어와야 되는 상황'이 있다고 하자.

1) 'ADC 드라이버는 AUTOSCAN을 통해 ADC값을 읽어온다.'라는 소프트웨어 요구사항을 작성(SWE.1)하고,

2) 이 요구 사항을 토대로 ADC라는 드라이버가 아키텍처에 생기고 (SWE.2)

2) 실제로 소스코드까지 구현(SWE.3)된다.

 

SWE.2 Software Architectural Design

: 소프트웨어 요구사항에 맞는 소프트웨어 아키텍처를 만드는 것. 아키텍처에서는 정적(static)과 동적(dynamic) 측면이 드러나야 한다.

 

아키텍처는 소프트웨어의 '구조'를 보여주는 작업이다. 흔히 System composer와 Enterprise Architect 툴을 이용해 작업하게 된다. 아래처럼 구조를 간단히 첨부한다. 아래와 같은 구조를 만드는 과정이다.

 

System Composer 예시

위는 System Composer 예시이다. 위와 같은 구조를 만드는 방식은 여러 방식이 있는데, 하나를 소개하면 bswmd를 이용하는 것이다. 

 

bswm는 autosar에서 사용되는 개념으로 arxml 형식(xml과 같다고 보면 됨.) 안에 모듈 간의 정보, 모듈의 정보를 넣어둔 다음 System Composer  툴을 통해 읽어온다. 그러면 위와 같은 아키텍처 구조가 보이게 된다. autosar 적용 프로젝트면 겸사겸사 만들어야 된다.

.

.

SWE.2에는 Memory 등 다른 내용도 많지만 크게는 이 작업이 주요한 작업 중 하나로 생각하고 넘어가 본다.

 

SWE.3 Software Detailed Design and Unit Construction

: 아키텍처에 맞는 소프트웨어 Detailed Design과, 소프트웨어 Detailed Design에 맞는 소프트웨어 단위를 구성하는 작업이다. 이때, 디자인은 동적인 측면과 정적인 측면 모두를 포함하고 있어야 한다.

 

SWE.3은 디자인과 유닛 구성이다. 디자인은 직관적으로 이해가 되지만, 유닛 구성이 무엇인지는 좀 의아하다. 유닛 구성은 소스 코드에서 모듈, 함수 등 독립적으로 테스트 가능한 단위를 의미한다. 개인적으로 편하게는 소스 코드 또는 그 일부를 지칭한다고 이해하고 있다.

 

Software Detailed Design의 정적 부분과 동적 부분은 무엇일까?

먼저 정적 부분은, 함수와 변수 등의 나열이라고 볼 수 있다. 어떤 기능을 하는 함수가 있고 어떤 기능을 하는 변수가 있는지 나열하는 것이다. 테이블 형식으로 함수 이름, 인자, 타입, 데이터 범위 등을 나타낼 수 있다.

 

그렇다면 동적 부분은? 보통 디자인을 표현하기 위해 UML(Unified Modeling Language)이라는 언어를 사용하여 디자인을 표현한다. 내용은, 시스템의 동작 묘사(Behavioral Desciption)가 필요하다. 아래 예시를 통해 알아보자.

 

아래는 Enterprise Architect를 제작하는 Sprax Systems에 설명된 내용이다.

The Dynamic Model - UML Tutorial | Sparx Systems

 

Sequence Diagram:

시스템 내에 유저와 오브젝트 등의 관계를 기술하고 보여준다. 여러 시나리오를 보여주기 위한 Use Case 모델로도 사용된다.

Sequence Diagram

Activity Diagram:

시스템 내에 각 구성 요소들이 어떻게 구성되어있는지 보여준다. 이를 통해 실행 구조를 알 수 있다.

Activty Diagram

위와 같이 동적 측면을 묘사해야 한다.

이러한 동작 묘사 측면 외에도, 인터럽트 핸들링(interrupt handling)이나 선점형 프로세싱(preemptive processing), 멀티스레딩(multi-threading)에 대한 측면도 포함될 수 있다.

 

SWE.4 Software Unit Verification

앞선 SWE.1-SWE.3이 소프트웨어 개발과 관련되었다면 SWE.4-SWE.6은 검증이다. SWE.1-SWE.3을 검증하는 것이다.

V사이클과 같이 SWE.1-SWE.6, SWE.2-SWE.5, SWE.3-SWE.4가 쌍을 이룬다. 

 

이 프로세스의 목적은 Software detailed design에 맞게 설계된 Software unit을 검증하는 것이다.

 

SWE.4는 작성된 소프트웨어에 대한 검증이다. 대표적으로 사용되는 방법은 정적 검증과 동적 검증이다.

주된 정적 방식은 코드 리뷰가 있고 툴로는 Axivion, Lint이 있다. 동적 검증 툴은 Tessy가 있다.

해당 결과물들(리뷰 결과 comment, 툴에서 나온 리포트 등)을 첨부하면 된다.

 

SWE.5 Software Component Verification and Integration Verification

이 프로세스는...

- Software Component가 Software Architectural design에 맞게 설계되었는지 검증한다.

- Software Element가 Software Architecture와 Software detailed design에 적합한지 검증한다.

 

이 부분은 아직 고민 중인 부분이다. 검증해야 되는 부분은 두 부분이다. 1) Software Component와 2) Software Element에 대한 테스트이다. Software Component와 Software Element가 무엇인지 정확히 알아야 검증도 될 것 같다.

 

Software Component: ASPICE에서는 이 용어를 하나를 가리키면서 한정하고 있지 않다. Software Architecture 레벨에서 더 쪼개져 나온 것들을 통틀어 얘기하고 있다.

1) 설계 관점 Software Component:  Software Architecture를 계층적으로 더 쪼갠 것. 모듈, 클래스, 함수 등등

2) 구현 관점 Software Component(Software Element): 소스 코드, 오브젝트 파일 (실행 가능한 형태)

로 볼 수 있다.

 

그렇다면 둘을 만족시키기 위해서는 어떤 테스트가 수행되어야 할까?

설계 관점 Software Component 검증은 모듈, 클래스, 함수 등에 대한 검증이 필요하고, 호출을 통해 정상적으로 호출되는지 볼 수 있다.

구현 관점 Software Component(Software Element) 검증은, 대상이 되는 Software Component의 동작을 평가하면 된다. 대표적인 동작을 보면 된다. 예를 들어 reset handling 하는 드라이버라면, reset을 발생시켰을 때 동작이 예상한 대로 동작하는 테스트 케이스들을 만들어 검증할 수 있다.

 

SWE.6 Software Verification

SWE.6은 Software가 SWE.1 Software Requirement에 맞게 구성되어 있는가를 검증하는 것이다. 요구 사항 기반으로 테스트 케이스를 작성하고 수행한다. 예를 들어 Analog 값을 Digital로 변환한다.라는 ADC Driver를 위한 Software Requirement가 있다면, 특정 ADC에 0, 2.5V, 5V를 흘려보고 ADC Driver가 정상적으로 값을 변환하는지 볼 수 있다.

 

SWE 정리 요약

크게 SWE에 대해 알아보았다. V Cycle 형태로 SWE.1-SWE.6, SWE.2-SWE.5, SWE.3-SWE.4로 연결되며 구현과 검증에 대한 구조로 이루어져있다. 여기까지 개요를 살펴보고, 다음 장에서부터 SWE.1-SWE.6에 대해 SWE 단계마다 포스팅을 해보려고 한다. 구체적인 Base Practice와 연결 관계를 각 프로세스마다 살펴볼 예정이다.

다음글: ASPICE 정복하기 - (3) SWE.1 완벽 정리