SWE.2

사실 SWE.2는 맥락적인 부분에서 SYS.3(시스템 아키텍처 설계)와 같다. 하지만 시스템 수준보단 좀 더 구체적이고 

기술적인 요소들을 다루는 부분이라는 점에 의해서 약간씩 차이가 있을 것이다.

[[[이를 위해 이번 글에서는 ASPICE 실무적 측면으로 설명을 먼저 할 것이다(이전 글들에서는 ASPICE 실무적 측면의 설명은 보통 글의 후반부에 설명하였었다..ㅎㅎ) 아!! 참고로 SYS.3 에서는 나의 주관적인 생각을 매우 많이 넣느라. ASPICE 실무적 측면의 설명을 하지 않았었는데 어차피 SWE.2와 내용이 많이 겹치므로 이번 글을 통해서 SYS.3의 ASPICE 실무적 측면도 함께 이해하길 바란다.]]]

 

예를 들어 두 프로세스(시스템, 소프트웨어) 모두 아키텍처를 개발하고 초기 활동으로 둘 다 기능 비기능으로 나누긴 하지만 (왜냐하면 기능 비기능은 상위 단계 부터 하위 단계까지 존재할 수 있는 개념인 것에 동시에 기능 비기능은 기름과 물처럼 섞이면 안되는 것이기 때문에 반드시 분리를 시켜주어야 하기 때문이다.) 그러나 이 활동 직후 시스템 아키텍처 설계의 경우에는 기능별 엘리먼트로 나누고 하드웨어 소프트웨어 분야로 분해를 하지만 소프트웨어 아키텍처 설계의 경우에는 컴포넌트 수준 및 유닛 수준으로 분해를 한다.

 

이렇게 시스템이든 소프트웨어든 아키텍처 설계를 위한 분해를 했으면 각 요구사항을 분해한 곳의 알맞은 곳에 할당을 한다. 이후에는 분해했던 엘리먼트 간의 인터페이스를 정의를 하는 것이다. (내가 이전에 적었던 글을 보면 아마 인터페이스에 대한 정의를 제품의 동적인 측면을 위해 존재하는 것이라는 식으로 설명했을 것이다.)

아무튼 이 후에는 뭘 하겠는가? 지금 여기까지 아키텍처의 정적인 부분(다양한 엘리먼트로 분해 및 요구사항 할당)과 인터페이스 정의(동적인 요소 정의)까지 했으니 그 동적 프로그램이 어떻게 움직일지 설명을 해야 하지 않겠는가?(내가 이것도 저번 글에서 설명을 했었는데 결국 제품의 동적이라는 것은 자동화의 의미를 내포하고 있고 그 때문에 반드시 인간에게 이로운 방향으로만 작동하게끔 절차들을 설정해 주어야 한다고 했다, 이 절차가 바로 아키텍처 설계에 있어서 동적 설계, 동적 메커니즘이라고 보면 된다.) 

근데 여기서 내가 동적 설계라는 것을 너무 추상적으로 말했기 때문에 자동차 제품에 있어서 동적 설계가 무엇인지 좀 구체적으로 말해주겠다. 동적 설계는 예를 들어, 당신이 자동차 내부의 에어컨 제품을 판다고 하자 이 떄 에어컨을 안 켜고 있을 때는 이 제품은 shut down mode 즉 휴면상태 모드라고 할 수 있고 만약에 에어컨을 작동시켰다면 이 에어컨 기능을 위한 mode는 start up 모드로 먼저 기능을 잠에서 깨우기 위한 것을 해야 한다. 그리고 normal mode라고 작동이 유지되고 있는 상태 이런 식으로 어떤 제품의 기능은 각 모드가 있다. 각 모드가 왜 있느냐? 생각해봐라 ! 만약에 당신이 애초에 잠자고 있는 에어컨을 켜지도 않았는데 온도 설정, 바람 세기 설정 아무리 눌러봐라 작동이 되나 안되나 게다가 님이 아직 에어컨 기능을 켜지도 않았는데 잘못하다가 바람 세기를 높여서 온도 설정은 하지도 않았는데 설정되지도 않은 온도로 갑자기 바람이 막 불어온다고 생각해봐라 얼마나 황당한지! 그러니까 모든 기능에는 모드라는 것이 있는 것이다. 마치 우리가 밥을 먹을 때는 손을 숟가락과 젓가락을 이용하는데 밥을 먹을 떄가 아닌데도 손을 숟가락 젓가락을 드는 것처럼 해봐라 예를 들어 농구를 해야 하는데 (그러기 위해 농구모드로 설정이 되어 두 손이 공을 잡는 모양으로 해야 하는데) 아직도 숟가락, 젓가락 집는 모드를 하면 그냥 개 노답인 것이다.

 

아무튼 근본적인 이해를 돕기 위한 부연 설명이 너무 길었는데, 여기 지금 동적 설계를 설명하는 단계에서 시스템 아키텍처 설계 떄와는 약간 추가적인 작업이 필요한 것이 소프트웨어 아키텍처 설계 단계에 있다. 위에서 언급했듯이 동적 설계를 위한 각 모드에 대한 정의를 하고 어떻게 작동하는지 설명하는 것은 둘 다 해야 하지만 소프트웨어는 실제 제품에 가까운 단계로 자원적 소모를 고려해야 한다. 그래서 뭐.. 잠재적인 부하 및 정확한 목표 설정(어떤 기능을 수행해야 하는데 걸리는 시간 등등)이 정의가 되어야 한다. 그니까 한 마디로 항상 그래왔던 것처럼 그리고 절대적 진리인 것처럼 시스템 단계에서는 추상적인 것이고 소프트웨어 단계에서는 구체적이기 때문에 약간 추가적인 활동들이 더 추가되어야 한다는 것이다.

 

ASPICE 실무적 측면에서 시스템 아키텍처 설계 때와 다른 소프트웨어 아키텍처 설계에 필요한 추가적인 활동은

위에서 살짝 언급했듯이, 자원 소모 목표량을 반드시 정의를 해야 한다. 이것을 설정하지 않으면 감당할 수 있는 한계를 넘어 갈 수 있기 때문에 고장이 발생하기 떄문이다. 아무튼 여기서 구체적으로 자원 소모량 목표를 정해야 하는 좀 Typical한 것들은 다음과 같다 Memory(ROM, RAM, external/ internal EEPROM or DATA Flash), CPU load, etc

 

이후에 필요한 활동들은 모든 엔지니어 개발 프로세스( = 엔지니어 프로세스의 V사이클의 왼쪽 프로세스들 ※ 참고로 엔지니어 프로세스의 V사이클의 오른쪽 프로세스들은 개발 프로세스가 아니라 Verification = 검증 프로세스이다.)

에서 활동하는 양방향 추적성, 일관성, 완성한 산출물에 대한 합의 활동들이다.