[SW 요구사항 분석 및 설계_1]

소프트웨어 공학

소프트웨어 요구사항 분석 어필 및 기본 사항

• 소프트웨어 요구사항 분석 및 설계나 AUTOSAR, A-SPICE 등을 5일, 5일 배운다고 한 번에 프로젝트에 적용하고 숙련이 될 수는 없다. 적용을 못하거나 감이 안 오는 것이 사실 당연하다. “이 프로젝트에서는 이러한 부분을 신경 써야 했기에 이러이러하게 스탭을 나누었고, 이 스탭에서는 이러이러한 관점을 신경 써서 설계를 했습니다. 이처럼 이론적인 백 그라운드를 드러낼 수 있는 정도가 좋을 것 같다.” 교안을 짠 사람도 원하는 포인트가 범용적인 요구사항 분석 및 설계에 대한 백그라운드 습득 정도라고 생각한다.
  
• 에자일이 방법론이 아니라는 사실, 모든 개발에 사용되는 것이 아니라는 사실, 자동차 소프트웨어는 안전도 신경 써야 하기에 폭포수 모델과 같은 옛날 모델도 사용한다는 사실, 학부생에서는 AUTOSAR, A-SPICE 및 소프트웨어 요구사항 분석을 수강해서 이해했다 정도가 유의미하게 어필할 수 있는 부분이라고 생각한다. 그렇기 때문에, 이러한 소프트웨어 요구사항의 역사, 의미, AUTOSAR, A-SPICE, ISO 26262를 배워서 적용해보려고 노력했다는 사실 정도가 중요할 것 같다.
  ⇒ 에자일을 프로젝트에서 사용했다면 이러 이러한 이유로 에자일을 개발 방법으로 선정했다라고 하면 좋을 것 같다.
• 소프트웨어 요구사항 분석 및 설계는 현업에서 사용하던 방법론을 정리한 것이라 볼 수 있다. 에자일이나 스크럼도 마찬가지로 원래 있던 방법이 아닌, 어떠한 회사에서 사용한 개발 철학을 정리한 것이라 볼 수 있다. 방법으로 구체화한 것은 철칙을 구체화 시킨 것이다. 그렇기에, 최신 방법을 사용하는 것이 꼭 옳다고 할 수는 없다.
• 소프트웨어의 실패율은 어느 정도일까? 개발을 성공했다고 치면 33% 정도의 비율이 나온다. 미국은 창의적인 소프트웨어를 만드는 것에 포커스가 되어 있다. 우리나라는 창의적인 소프트웨어보다는 유지 보수 및 기존 내용의 발전에 포커스가 되어 있다. 미국 = 수평적 구조, 우리나라 = 피라미드 구조 ⇒ 창의 ↔ 유지보수 발전
  

자동차 개발 프로세스

• 자동차 도메인 = 시장, 소비자 ↔ 안전의 중간 단계 ⇒ 왜? 자동차는 소비자에게 팔기 위해 디자인 및 성능도 중요하지만, 마찬가지로 사람의 생명을 위한 안전 역시 중요하기 때문에 중간 부분에 속한다.
• 그렇기에 자동차의 개발은 무엇을 개발할지 정하고, 무슨 방법론을 사용할지 결정하는 것이다. 일반적인 소프트웨어이 개발에서는 안전을 고려할 이유가 없다. 하지만 자동차 소프트웨어 개발은 품질을 통한 안전을 중시하기에 조금 더 자세한 방법론이 필요하다. 그렇기에, 자동차에서도 편의 시설을 위한 소프트웨어를 설계한다고 하면 에자일이나 스크럼 같은 방법을 사용하지만, 엔진 파워트레인과 같이 안전에 유의미한 영향을 끼친다면 V-cycle, Water-fall 모델을 사용하는 것이 좋을 것이다.
• 현재 현대자동차는 소프트웨어 상으로의 발전은 외국 기업에 비해 뒤쳐지는 부분이 있다. 그렇기에, 네이버 카카오와 협업을 하게 되었다. ⇒ 앞으로 네이버카, 카카오 모빌리티가 더 발전할 가능성이 있다.

소프트웨어 설계 과정

요구사항 → 설계 → 개발 → 테스트

설계 과정 주요도 변천사

개발 → 옛날에는 개발 인원들이 별로 없어서 중요

테스트 → 개발된게 이상한 경우가 많아지니 테스트 중요

설계 → 비슷한 제품의 개발로 코드를 수정해야 하는데 스파게티 코드로 인해 코드를 바꾸는 것이 어려웠기에 설계 중요

요구사항 → 최근에는 요구사항이 잘 되어 있는게 과정에서 가장 도움이 된다 보기에 중요해짐

시장 분석 & 고객 분석 → 가장 최근에는 시장 분석 후 요구사항 설계가 개발 후 성공에 도움이 된다 생각하게 됨, 필요 없는 건 만들어도 쓸모가 없다 ⇒ 코디네이터 : 고객의 요구사항과 개발자가 만들 수 있는 수준 그 갭을 매꾸고 조절하는 역할 ⇒ 개발자의 중요한 역량이기도 하다. ⇒ 나중에 어필할 때 쓸 수 있을만한 내용

점진적 개발이 대세 : 1에서 100을 한 번에 만들지 않는다. 1에서 10 주요 기능 만들어서 출시 후 release하여 사람들 반응을 보고 점진 개발, pivot(고객 요구사항 반영) 중에 하나를 선택한다.

요구사항의 정의

요구사항은 고객이 실제로 원하는 것이다.

user : 사용자(고객 외에도 이 서비스를 사용하는 사람까지 포함, customer를 포함하는 개념 ex) 보험설계사)

customer : 고객(실제로 이 서비스를 위해 비용이나 시간을 지불하는 사람)

stakeholder : 이해관계자(소프트웨어 관련된 모든 사람들 : 기획, 고객, 보험설계자, 투자자 … )

problem description(고객) : 고객 언어로 표현된 해결할 문제(구체적이지는 않을 수 있음), 고객 SW에 대한 승인 조건(이러이러한 기능을 추가해주세요)

solution specification(설계자) : 제약 조건하에 고객 니즈 충족 방법 고려, 제품/서비스 만족을 위한 특성 고려

요구사항은 시간이 지날 수록 바뀌게 된다.

문제와 해결점 간의 갭이 있다.(고객들의 요구사항 및 이상치와 실제 제약 조건 간 차이가 존재)

⇒ 그렇기에, 요구사항은 이상치와 실제 제약 조건 간 갭을 최소화하는 것이 중요하다고 한다.

⇒ 최근에는, 새로운 기능보다 품질이 중요하다고 한다. 낮은 품질의 신기능은 오히려 기업 이미지에 손상

요구사항 관리

• 시장이 원하는 적기에 적합한 제품을 출시하는 것이 목적 - 더 낫고, 싸고, 빠른
• “좋은 상품”은 요구사항에 기반한다. 단, 좋은 상품이 잘 팔린다는 것을 보장하지는 않는다.
• 품질, 산정, 가치, 구현 기반 요구사항 등이 있을텐데 이 요구사항들 간 우선순위는 프로젝트의 목적에 따라 갈린다.

요구사항 관리의 문제는 무엇인가?

• 가장 어려운 부분은 어떤 걸 구축할지 구축 대상을 결정하는 것이다. 여러 요구사항 중 기간 및 비용에 따라 어떤 걸 선택할지 결정한다.
• 현재는 요구사항이 바뀌지 않을 수가 없다는 것을 받아들이고, 변경되는 요구사항을 잘 관리하는 것이 더 중요하다고 생각된다. ⇒ 프로젝트의 진행 중 어떤 단계가 제일 힘들었냐는 질문이 들어온다면 시작 계획을 수립하는 것이 힘들었다는 것보다는, 요구사항은 잘 수립했는데 중간중간 프로젝트의 진행에 따라 요구사항이 계속 변경되어 이를 관리하는 것이 힘들었다고 하는 것이 더 인상 깊을 것 같다.
• 우리나라의 중소 기업이 해외 진출 및 해외 회사와 협업하기 힘든 이유 중에 하나가 소프트웨어 제작에 사용되는 문서가 존재하지 않기도 하고, 이걸 잘하면 애초에 다른 회사로 간다.

요구사항 관리의 목적

• 요구사항 문서가 있다고 해서 요구사항이 잘 관리되어 있는 것은 아니다.
• 요구사항 관리는 인지한 순간부터 계속해서 해나가는 것이 좋다.
• 요구사항 툴이 있다고 해서 요구사항이 잘 관리되어 있는 것은 아니다.

정의된 기능의 절반은 사용하지 않는다. ⇒ 요구사항을 잘 수행했다면 이렇게 버리는 기능을 줄이고 잘 작동할 수 있었을 것이다.

SW 개발과 요구사항 관리

소프트웨어 개발 성공 기준

• 기존 자원(Budget) 중심 개발 성공에서 가치 기준(Valuable) 개발 성공으로 바뀌었다.
• SW 프로젝트의 30% 정도만 성공한다 ⇒ 프로젝트 실패 원인으로는 프로젝트의 size가 점점 커지고, 복잡도가 증가하고 있기 때문이다. ⇒ 프로젝트를 한 번 만들고 끝내는 것이 아닌, 유지 보수 및 발전이 중요한데 이러한 부분들을 좀 신경 쓸 수 있으면 좋을 것 같다. 우리도 분석하고 왜 만들어야 하는지 고민하고, 구현하고 시장과 고객들의 반응을 보고, 그대로 갈지 피벗할지 묻고 새로 할지 이러한 부분들을 선택하는 것 자체가 개발의 과정이다.
  
• 실질적으로 소프트웨어 개발 성공과 실패 원인은 동일하다

성공 원인

1. 이해관계자 능동 참여
2. 명확한 요구사항 제공
3. 적정한 계획과 현실적인 기대와 목표 제공

실패 원인

1. 이해관계자 참여 부족
2. 비효율적 의사소통
3. 자원 부족 및 비현실적 기대

⇒ 시간적 완충 지대의 추가가 있으면 좋겠다. 일정을 70% 정도로 잡으면, 뭔가 문제가 생길 때 해결할 여유가 생기고, 새로운 시도도 가능

소프트웨어 재작업 : 초기 잘못된 구현이나 요구사항 변경으로 프로세스 또는 활동 다시 수행하는데 드는 노력
⇒ 처음에 요구사항 수정할 때는 글 줄 하나지만, 나중에 수정할 하면 처음부터 다시 바꿔야할 필요가 있다.

⇒ 개발 비용의 40~50% 차지함

⇒ 1 : 10 : 100 = 예방 비용 : 수정 비용 : 실패 비용 ⇒ 스마트 헬스 케어 같은 경우가 기존 치료 비용을 예방 비용으로 예방할 수 있는 차원에서 기존 의료 패러다임의 전환이 가능하다 ⇒ 근데 의사 권한이 너무 세긴하다. 그럼 앞으로 스마트 헬스 케어와 같은 경우 의사를 거치지 않는다는 법안이 발의된다면 스마트 헬스 케어 주식이 폭발적으로 성장할 가능성도 있겠네

• 헬스 케어와 같은 패러다임의 전환은 자동차에서도 일어날 것이다. 자율주행 차량이 도입된다면 저번에 봤던데로 엔터테인먼트와 같은 분야가 더 발전할 것이다. 근데 확실히 자율주행 차량은 책임 소재로 인해 완전 자율주행은 좀 애매한 거 같긴하다.

• 기존 프로젝트 진행한 것도 계획을 수립할 당시에 했던 내용들을 이렇게 엮어서 설명하면 좋지 않을까?

  ⇒ 저걸로 돈을 벌 수 있을까?라는 생각이 들게 만드는 것이 좋지 않을까
  

• 요즘 개발자 트렌드 : 고객의 요구사항을 액면 그대로 받아들이는 걸 넘어서, 이런 상황에서 이런 게 더 있으면 좋지 않을까?라고 추가적인 정보를 이끌어낼 수 있어야 한다. 단순 코더를 넘어서 이런 역량을 어필할 수 있다면 좋을 것 같다. ⇒ 팔팔토이와 진행한 자동화 장치 제어 직무에서 했던 내용을 바탕으로 쓸 수 있지 않을까? ⇒ 팔팔토이 관련 자소서를 작성할 때 항상 기대효과로 연간 2106만원의 원가 절감을 이끌어낼 수 있다고 했는데, 초기 설치 비용 및 제품 비용으로 어느 정도가 드는 지에 대한 정보가 없었던 것 같다. 얼마 들었었지?

• CAN통신 기반 IDS 제작을 할 때 공격 대상은 B-CAN 중에서도 헤드라이트, 시트, 방향 지시등, 와이어 등으로 선정한 이유는 뭐라 해야할까? ⇒ 실제 차량을 대상으로 실험을 진행했기에 안전을 위해 정차 상태에서 진행을 했습니다. 정차 상태였기에 P-CAN을 통한 엔진이나 steering과 관련된 부분은 할 수 없었던 부분이 있습니다. 하지만, 그 중에서도 헤드라이트, 시트 ,방향 지시등, 와이어를 공격 대상으로 선정한 이유는 이러한 장치들이 운전 중 갑작스럽게 조작되었을 때 사고로 이어질 확률이 높다고 판단했기 때문입니다.

요구공학 프레임워크

요구공학의 정의

• 사용자 요구와 시스템 제약사항을 “추출(Elicitation),분석(Analysis),명세(Specification),검증(Vertification)”하여 정의하고 요구사항 변경관리 수행

• 정확한 명세 작성하여 실제 문제 해결

• 최근 stakeholder에 애완견, 애완묘도 추가되는 경향이 있다.

요구공학의 특징

• human-based activity : 사람이 기반이 되는 활동이기에 이해관계자의 비공식적 니즈를 정확히 파악해야 하고, 에러가 날 수 밖에 없다

• 참고) 데이터 분석 직무가 하는 일 : 크롤링이 어떻게 진행되는지 들을 수 있었다. 위쪽에서 광고로 이 모델은 “젊고, 우아하고, 단아한 느낌”이 났으면 좋겠다고 한다면, 데이터 크롤링을 통해서 사람들이 어떤 연예인을 젊고, 우아하고 ,단아하게 생각하는지 파악한 후 이 교집합을 바탕으로 광고 모델을 선택한다고 한다.

• HIL, SIL와 같은 방법론을 배운 것을 자소서에 담을 수 있다면 좋을 것 같다 ⇒ 이 내용 어디 과목에서 배웠더라? ⇒ 일단, ISO26262를 차량소프트웨어엔지니어링 수업에서 배웠고, 자율주행컴퓨팅플랫폼에서 RTOS, 9.MBD에서 HIL에 대해 배웠다. ⇒ HIL은 어디서 진행한다?
  Modeling and Design → Rapid Prototyping → Targeting → *Hardware-in-the-loop-Simulation → System Testing
  ⇒ 집에 가서 해당 내용 노트보고 복습한 다음 1번 문항에 적을 수 있다면 좋지 않을까

• 2번 문항의 마지막에서도 경청의 태도를 바탕으로 고객의 요구사항을 받아들이고, 이를 넘어 고객이 무의식적으로 바라지만 말하지 못한 정보들도 캐치할 수 있도록 하겠다 ⇒ 이렇게 바뀌면 좋을 것 같다.

RE Framework

• 3요소 : Process, Tool , Human

Requirement Development Process

Elicitation : 정보를 수집하고 요구사항 분석을 위한 준비

Analysis : 어떤 요구사항이 필요한지 분석

Specification : 정한 요구사항을 적는다. 정형화된 기법으로, 비정형(글,그림 자연어 ⇒ 쓰기는 쉽지만 알아듣기 힘들 수 있다), Semi(반정형)(주석 정도), 정형(코드 ⇒ 적는 건 어렵지만 오해는 없다) 방식으로 나눠서

Vertification : 요구사항 검증, 요구사항 baseline(여기까지만 하겠다고 마무리 하는 느낌)

학문적으로는 Vertification 단계가 끝나야 요구사항이라는 말을 사용한다. 그전까지는 Requirements development라고 생각하면 된다.

SW는 언제 죽거나 없어질까? → 서비스를 사용하는 사람이 없어질 때

실제로는 기대하는 만큼 활동이 이루어지고 있지 않다

요구사항의 세대별 핵심 토픽

최초에는 function 기능을 중시하였다

⇒ 이후에는 고객 요구사항을 중시하였다

⇒ 이해관계자

⇒ 현재는 품질 자체가 중요하다. 제대로 작동하지 않는 기능은 오히려 마이너스

• 고객이 만족하는 품질의 수준을 찾아내는 것이 중요하다.