A-Spice 의 개요

자동차 임베디드 SW 개발에서 A-Spice라는 것이 있다.

 

A-Spice의 모든것에 대해 아주 완벽하고 정확하게 알아가기보다, 대강 어떤 느낌인지 파악하는 글을 써보겠다.

 

A-SPICE는 Automovie Software Process Improvement and Capability dEtermination 의 약자인데.

 

간략히 말하면  '차량SW 개발 프로세스 가이드라인' 정도로 말 할 수 있을것 같다.

 

 

핵심단어는 '프로세스' 이다.

 

사실 SW라고 하는것은 누가 '어떻게' 만들었는지와 상관없이 원하는 기능만 잘 구현되면 장땡이다.

 

예를들어 똑같은 기능을 하는 sw인데 누구는 함수 5개로 나눠서 짜고, 누구는 함수 1개에 전부 다넣어서 짤 수도 있다.

 

또한 누구는 전역변수를 왕창 사용해서 코딩을 하고, 누구는 전역변수를 최대한 사용하지 않을 수도 있다.

 

그런데 이렇게 통일되고 체계화된 '프로세스' 없이 그냥 SW를 짜놓으면, 당장은 문제가 없을지 몰라도 추후에 문제가 발생할 여지가 있다.

예를 들어 담당자가 퇴사하고나면 해당 SW를 추후에 수정이 힘들 것이고.. 분석도 힘들 것이다.

또한 규칙없이 막 짜놨기 때문에 아무래도 SW에 결함이 있을 가능성이 높다.

 

이러한 것을 방지 하기 위해서,

차량 SW를 만들때 아무나 그냥 구현만 하면 장땡. 이 아니라,

 

차량 SW개발 순서를 여러개의 단계로 나누고, 각 단게별로 계획을 세우고, 그리고 그 계획대로 SW 구현을 실시하고, SW를 구현한 후에는 정말로 계획대로 잘 구현되었는지 체크해라. 

또한 혹시 세웠던 계획 자체에 문제는 없었는지 계획에 대한 Review도 해야한다.

 

이런 내용을 담고 있는게 A-Spice 이다. 쉽게 말하면,

아무 규칙없이 막 개발하지 말고, 계획을 세우고 계획대로 실천하라는게

A-Spice가 강조하는 주요한 내용이다. 또 개발이 끝나고나면 실제로 계획을 잘 준수해서 구현한건지 Reivew가 필요하며, 또한 혹시 계획 자체는 잘못된 부분이 없는지 계획에 대한 Reivew도 필요하다.

또한 개발 중에 변경사항이 생길 경우, 변경을 아무렇게나 막하지 말고 어떤 것이변경됐는지를 꼼꼼히 기록해두고, 변경도 막 하지말고 규칙을 정해놓고 규칙대로 변경을 해야한다.

 

 

각 단게별로 계획을 세운다고 했는데 계획의 예시를 들어보면,

이 SW를 개발하기 위해서 대략 몇명의 SW 엔지니어가 필요하며, 개발해야하는 범위는 어디부터 어디까지이며,

예상되는 일정은 언제까지이며, SW를 구현하고 나서 테스트는 누가 할 것이며.. 이런것들이 계획이다.

또한, 개발 도중에 요구사항이 변경되어 기능을 변경해야 할 경우, 이것도 그냥 아무렇게나 막 변경하는게 아니라

누구에게 보고를 하고, 현재 SW에서 어떤 사항이 변경되야하는지를 검토하고. 변경내용을 기록해두고.. 그리고 나서 변경해라. 이런식으로 규칙을 정해놓고 해야한다.

 

위의 것들은 모두 예시인데, 중요한건 SW 개발에 관련된 모든 것을 개인적으로 아무나 맘대로 하지말고 미리 규칙을 세워두고 모두가 그 규칙을 준수해서 규칙대로 하라.  이게 A-SPice에서 강조하는 부분이다.

 

그리고 SW 구현을 하기 전에, 어떤 기능을 구현할 것인지 먼저 명확하게 목표를 정해놓고, 그 목표를 달성하기 위해서 세부 목표를 정해놓고 SW를 구현하는 것을 강조한다.

  비유하자면 대강 이런 느낌이다.

 

고객의 요구사항 : 맛있는 김치찌개를 만들어라.

  -> 고객의 이러한 요구사항을 만족하기 위해서, A-SPICE에서는 이 요구사항을 좀 더 상세한 레벨로 분류해서

세부 요구사항을 먼저 써야한다. 

큰 요구사항으로부터 작은 (상세한 ) 요구사항을 끌어내서 적어야 한다.

 

예를 들자면..

 

김치 1kg 준비한다. -> 김치는 xx업체에 전화해서 1kg를 주문한다.

돼지고기 1kg을 준비한다. -> 돼지고기는 철수네 정육점에서 구입한다.

                                  -> 구입한 돼지고기는 10cm 크기로 잘라놓는다.

 

다진 마늘 500g을 준비한다 ->  마늘을 영희네 채소가게에서 구입한다.

                                    ->  마늘의 껍질을 까서 깨끗하게 씻는다.

                                    ->  마늘을 다진다.

 

재료가 준비되고나면 물 1L를 끓인다. -> 2L 크기의 냄비를준비하고 물은 1.2L 받아놓는다.

                                                 -> 가스렌지를 켜서 물의 온도가 100도씨 될 떄까지 가열한다. 

 

 

위 예시처럼, 고객의 요구사항은 최종적인 요구사항이고, 그 요구사항을 달성하기 위해서 필요한

세부 요구사항을 적고 , 또 그 세부사항 보다 더 세부적인 사항을 적어야 한다.

 

그리고 실제로 SW 구현을 할 때는, 그 세부 요구사항대로 SW 구현을 하는 것이다.

 

예를 들어서,

만약 당신이 5명의 팀원과 일을 하는데, 맛있는 김치찌개를 만들라는 요구를 받았다.

그런데 김치찌개 래시피가 5명이 전부 제각각이면 개판이 될 것이다.

또한 당신이 김치를 샀는데 옆에 동료도 김치를 또 사면 김치가 낭비된다.

또한, 당신은 돼지고기를 철수네 정육점에 전화해서 구매하려고했는데 옆에 동료는 뒷산에가서 멧돼지를 사냥해왔다.

이것 또한 문제가 될 것이다.

위와 같이 좌충우돌 의 상황을 겪지 않으려면,  다섯명이 다같이 김치찌개를 제 맘대로 만드는 것이 아니라,

일단 김치찌개를 만들기 위한 공통의 레시피를 만들고. 필요한 재료가 무엇인지를 선정하고.

필요한 재료를 어떻게 공급할 것인지 구체적인 계획을 정하고..

그리고 그러한 구체적인 각각의 계획을 누가할 것인지 할당해서 해야한다.

 

이것이 바로 김치찌개를 막 만드는게 아니라, 정해진 프로세스에 맞게 만드는 것이다.

그리고 이것이 A-SPICE의 개념과 거의 비슷하다.

 

 

 

 

그런데, A-Spice를 적용하려고하면 SW 개발 외에 문서 작업이 많아지는데, 예시를 들어보겠다.

 

당장 앞에서 얘기했듯이, 모든 개발과정에 계획을 세워야한다.

근데 계획을 말로만 세울수는 없을것이다. 계획을 세웠다면 그 계획이 문서화되서 남아있어야 한다.

따라서 계획 문서가 필요하다. 

그리고 SW를 구현하고 난 뒤에는, SW가 실제로 계획을 준수해서 구현됐는지 Review를 해야한다고 했다.  Review를 했다면, Review를 했다는 증거가 있어야되지않겠는가? 따라서 Review문서도 작성이 필요하다.

 

한편, 위 김치찌개의 예시처럼, 고객의 최종 요구사항으로 부터 좀 더 상세한 요구사항을 이끌어내고,

또 그 상세 요구사항에서 더욱 상세한 요구사항을 이끌어내고.. 그런식으로 해서 더 이상 쪼갤 수 없는 수준으로 요구사항을 이끌어내서 문서화 한후,

실제 SW 구현은 그 요구사항들을 만족시킬 수 있게 SW를 구현한다.

그리고나서, 실제 그 요구사항이 만족되었는지 테스트 작업이 필요하다.

 

따라서, 요구사항 -> 세부요구사항 ->세부세부 요구사항.. 으로 요구사항을 적는 문서작업이 또한 필요하다.

 

 

이와 같이. SW를 개발함에 있어 문서작업이 상당히 증가하는 문제점이 있다. 물론 이상적으로 생각했을 때 체계적으로 문서를 모두 작업하고 나면, 문서에 작성된 내용 그대로 SW를 구현만하면되기 때문에 실제 SW 개발 시간은 그리 오래 걸리지 않을 것이다. 또한 모든게 문서로 남아있기 때문에 나중에 문제가 생기거나 변경이 필요할 떄, 혹은 모르는 사람이 새로 와서 SW를 담당 할 때 내용 파악이 쉬울 것이다.

 

이렇게 장점이 많긴하지만, 현업에서 SW 구현을 하다보면 바쁜 일정에 쫓기게 되고, 요구사항이 수시로 변하는 경우가 빈번하다. 그러다보니 A-SPICE가 말하는 것처럼 진짜 규칙 다 지켜서 문서화 체계적으로 하고, 그 문서내용 대로 SW 구현하기가 굉장히 힘들다.

 

그러다보니, 현업에서는 약간 문서화작업 따로, SW 개발 따로 약간 이렇게 흘러가는경우가 제법 있다.

문서화라는게 사실 필요없고 귀찮은 숙제가 아니라, 체계적으로 SW를 개발하기 위해서 필요한 작업인건데.. 현실에서는 그렇게 문서 따로 구현 따로 할 시간도 없고 아무래도 실제로 그 작업이 귀찮기 때문에... 현실에서 지키기가 힘들다.

 

그래서 어떤 경우에는 SW를 먼저 개발해놓고, 그 뒤에 끼워맞춤식으로 문서를 작성하는 안타까운 경우도 생긴다..

 

SW를 안전하게 만들기 위해서 생긴 표준인데.. 안전과는 별개로 개발자를 귀찮게하고 괴롭히는 도구? 처럼 받아들여지는 경향이 있어서 안타깝다,,

 

아무튼 이 정도면 대강 A-SPICE가 뭐하는건지 대강 감은 올 거라고 본다.