허접.강기사의 재미없는 놀이

Q1. 소프트웨어 프로세스는 소프트웨어를 만들기 위해 무엇을 어떻게 해야 하는지에 대한 가이드이다. 정답: 소프트웨어 프로세스는 소프트웨어를 만들기 위해 무엇을 해야 하는지에 대한 가이드이다. 어떻게에 대한 내용은 포함하지 않는다. 내 생각: 소프트웨어 + 프로세스, 프로세스를 What으로만 봐야하는 것일까? 프로세스는 가이드라인, 노하우를 포함할 수 있을텐데 너무 일반화된 접근에서 생각한 것은 아닌지 생각된다. 개인적으로는 무엇을 (what), 어떻게 (How) 그리고 When, Who, Why, (Where)를 충분히 포함할 수 있다고 생각한다. Q2. 비정상적인 상태나 환경에서 시스템이 제 기능을 수행할 수 있는 정도를 의미하는 품질 속성은? 정답: Robustness 비고: 난 Availabili..

1. 다양한 기술 특성 기계, 전기, 전자, 화학, 생명공학, 소프트웨어 등의 다양한 기술들이 통합되어 완성되는 시스템이기 때문에 요구사항이 중요함 자동차 분야는 비즈니스적인 이해와 더불어서 협력해야 하는 기술 도메인이 다양함 2. 시스템의 규모 자동차가 지능화 되어 가면서 시스템의 복잡도는 기하 급수적으로 증가 1억만 라인, 1억 5천만 라인.. 점점 늘어나는 규모와 복잡도 3. 협업 관계 업무의 세분화 및 분업화로 OEM과 Tier 간의 협업 관계 증가 자동차 메이커 (OEM)에서 시스템 레벨에서의 Tier1 그리고 Sub 시스템 (또는 컴포넌트, 엘리먼트)의 Tier 2 .. 등 다양한 이해관계로 구성되어 있음 4. 법, 규제 강화 자동차 시스템은 인간의 생명, 안전보장 그리고 환경 보호에 민감한 ..

수강하고 있는 UML 강의에서 무료 도구를 알려줘서 같이 참고하시면 좋을 것 같아서 공유 드립니다. 해당 글의 제목과 같은 Visual paradigm community edition 이란 도구 입니다. 구글에서 아래 그림과 같이 입력하시면 최상위에 표시되는 웹사이트를 통해서 해당 툴을 다운로드 하실 수 있습니다. 접속해 보시면, 접속한 기기의 환경에 따라 맞는 다운로드 파일을 자동으로 연결해줍니다. Windows, Mac 둘다 사용 가능합니다. 해당 툴은 상용도구로서 유료인 것으로 보여집니다만, 비상업용 (주로 개인)이 사용할 경우 무료로 활용 가능합니다. 작성하신 UML에 워터마크가 더해진다고 합니다. (뭐 그정도 쯤이겠죠? 무료로 UML 도구를 통해 학습할 수 있는데 전혀 문제가 되지 않습니다) 다..

단위 테스트 (Unit testing)은 설계된 모듈이 정확히 구현되었는지 확인하고, 모듈과 같은 하나의 소프트웨어 구성요소나 소프트웨어 구성요소의 집합이 프로그램의 요구사항에 맞는지 확인하는 테스팅 [IEEE 1012-1998 VVP] Testing conducted to verify the correct implementation of the design and compliance with program requirements for one software element (e.g., unit, module) or a collection of software elements. 단위 테스트 (Unit testing)에 한해서는 결함 발견의 목적 보다는 기능의 정상 동작을 확인하는 것이 더 중요합니다. 개..

프로그램에서 결함을 발견하는 것이 테스트를 수행하는 목적입니다. 즉 결함이 없음을 보이려는 것이 아닙니다. "프로그램 테스트는 결함이 있음을 보여줄 뿐, 결함이 없음을 증명할 수는 없다." [Dahi Djjkstra Hoare] 현실에서는 완전한/완벽한 테스트를 수행하는 것이 불가능합니다. 테스트를 수행하는 인원, 시간의 제약도 있지만 테스트 조건과 입력값 그리고 순서에 따라 테스트 케이스가 기하학적으로 늘어날 수 있기 때문입니다. 그렇기 때문에 효율적인 테스트 케이스를 만들어서 수행하는 것을 고려해야 합니다. 테스트를 수행하고 나온 결함은 디버깅을 수행하여 해결합니다. 그리고 재테스트(Re-test)를 통해서 결함이 해결되었음을 확인할 수 있습니다. 출처: https://twitter.com/Impac..

테스트의 목적은 '결함을 발견하는 것' 입니다. 그리고 기능이 정상적으로 동작하는 것을 확인하는 것입니다. 그리고 소프트웨어를 실행하지 않고 결함을 찾아내는 것이 정적 테스트의 목적입니다. 여러 참여자들이 모여 소프트웨어를 검토하면서 결함을 찾아내거나, 정적 검증 도구를 이용하여 수행하는 것을 즉, 문서 또는 소스코드를 보면서 검토하는 것 소프트웨어 개발 중에 생성되는 모든 산출물들에 대해서 적용이 가능합니다. 동적 테스트의 경우, 구현 또는 테스트 단계까지 가야 결함을 찾을 수 있지만, 정적 테스트는 명세하는 활동/산출물(명세서) 부터 결함을 찾을 수 있습니다. 즉 제품 개발에서 초기에 결함을 찾음으로서 소프트웨어 품질을 향상시킬 수 있습니다. 동력 검토 (Peer Review): 인스펙션 (Inspe..

SPICE 모델을 기반으로 자동차 산업에서는 기본 전장프로세스로 ASPICE, Automotive SPICE 를 많이들 고려해서 진행하고 있습니다. 아래 그림처럼 레벨은 0단계에서 5단계로 프로세스 성숙도를 평가하고 있습니다. 레벨 0은 프로세스 기반으로 일하지 않는다 이며, 레벨 5는 가장 높은 수준으로 프로세스 기반의 개발을 하고 있다. 라고 이해하시면 됩니다. 레벨0. Incomplete 불완전한 프로세스 프로세스가 이행되지 않거나 프로세스 목적을 달성하지 못함 요구사항 작성하지 않고 개발 요구사항 작성하였으나 내용 부족하고, 요구사항 기반으로 개발을 전개하기 어려운 경우 레벨1. Performed 프로세스를 수행하면 레벨 1, 수행되었다라는 의미가 관리되고 있다는 의미가 아님 (결과물은 작성하지만..

요구사항(Requirements)을 알기 위해서 아래를 먼저 얘기해본다. Want는 구체적으로 원하는 것, 필요(Need)를 만족시킬 수 있는 어떤 제품이나 서비스 Need는 기본적으로, 근본적으로 어떤 결핍을 느끼는 것, 그리고 사람에게서 공통적으로 나타나는 현상 출처: https://keydifferences.com/difference-between-needs-and-wants.html 수많은 문제를 해결하는 과정으로 생각하면, 문제는 Wants, Needs를 말하는 것이고 문제를 해결하는 해결책 Solution은 Requirements 인 것이다. Wants --> Needs --> Requirements 출처: https://blogs.managementconcepts.com/2020/09/16/..

※ 해당 글은 "SW 요구사항 개발" 강의를 들으면서 메모하고 싶은 내용을 기록하고 공유하기 위함입니다. 저작권 및 위배가 되는 경우 해당 글은 별도의 공지 없이 삭제될 수 있습니다. 가급적 위배가 되지 않는 내용에서 글을 작성합니다. 검증(테스트)이 어려운 이유는? 이유는 요구사항을 기반으로 해야 하기 때문이다. 즉, 요구사항이 불명확거나, 요구사항이 모호하거나, 요구사항이 일치하지 않거나 충돌이 발생하는 등 모두를 포함해서 검증(테스트)가 어려운 이유이다. 위 ASPICE PAM3.1 그림에서의 V 사이클 그림을 보면 요구사항을 분석하면서 System Qualification Test 단계가 수행된다. 즉 검증(테스트)의 수행이 개발 초기에도 이뤄져야 하고 할 수 있다는 것이다. 그런데 요구사항이 실..

CMMI: Capability Maturity Model Integration 카네기 멜론 대학의 연구센터 SEI가 미국 국방성의 후원으로 만든 표준 모델 라이센스 비용이 발생하며, CMMI를 산업에서 이용하면서 변경 시 미 국방성 승인이 필요함 SPICE: Software Process Improvement and Capability Evaluation 영국군의 주도로 ISO 15504 TR(기술 보고서) 제정 자동차 산업의 평가 모델을 반영하여 특화된 Automotive SPICE, 즉 ASPICE를 구성함. 주로 미국 지역에서는 CMMI 위주로 사용하려고 하나, GM, FORD와 같은 OEM에서는 ASPICE를 채택하여 사용하고 있음. 결과적으로, 자동차 산업에서 보다 적합하다고 할 수 있음 ASP..