내 머리속 지우개

아키텍처 (Architecture)?혹시 아키텍처를 한글로 번역하는 고민을 해 보셨나요? 아쉽지만 아키텍처는 한글이 따로 없습니다.경우에 따라 어떤 사람은 아키텍처를 "구조" 라는 단어로 떠올릴 수 있는데, 구조는 Structure 라는 따로 용어가 있다는건 다 아시죠?  소프트웨어 개발에서 소프트웨어 아키텍처(Software Architecture)는 종종 논란의 중심에 서 있습니다. 일부 개발자는 정교하고 아름다운 시스템 아키텍처를 설계하고도, 소프트웨어 아키텍처 자체에 대해 거부감을 표하기도 합니다. 이들의 거부감은 때로는 관료적인 설계 과정, 비현실적인 아키텍트의 태도, 또는 실질적인 소프트웨어가 아닌 다이어그램을 만들며 시간을 낭비한 경험에서 비롯됩니다. 하지만 이러한 문제들은 소프트웨어 아키텍..

고수준 아키텍처(High-Level Architecture)에 관해 많은 사람들이 이런 이야기를 합니다. "고수준 아키텍처는 너무 추상적이고 실제 개발과 너무 동떨어져 있다"이번 포스팅에서는 이 이야기가 과연 진실인지, 오해인지에 대해 알아보고자 합니다.   고수준 소프트웨어 아키텍처(High-Level Architecture)는 시스템의 전체적인 구조와 주요 구성 요소를 설계하여 큰 그림을 제공하는 역할을 합니다. 그러나 많은 개발자와 이해관계자들은 이 아키텍처가 “추상적이고 실제 개발과 동떨어져 있다”라고 느끼는 경우가 많습니다. 이러한 인식은 주로 다음과 같은 이유로 발생합니다. 1. High Level Architecture - 추상적이라는 이유로 실용성을 의심받음고수준 아키텍처는 일반적으로 시스..

오늘은 애자일 개발 방법론과 폭포수 개발 방법론에 대한 비교를 해 보고자 합니다.어찌보면 너무 당연한 내용일 수도 있겠지만, 각 방법론들의 차이점을 관점별로 정리하여 간략히 정리 해 보는 것도 나름 의미가 있겠다 싶어 정리 해 봅니다. 1. 개발 프로세스 (Development Process) 관점개발 프로세스 관점에서 폭포수 개발 방법론은 순차적이고 선형적인 접근 방식을 따릅니다. 즉, 개발 프로세스는 활동(Activity)들에 대한 단계(Phase)를 구분하고, 각 단계별 활동들이 정의되며, 각 단계는 다음 단계로 넘어가기 전에 현재 단계의 모든 활동이 수행 완료되어야 한다는 점이 특징입니다. 이런 과정을 통해 단계별 완결성을 확인할 수 있으며, 각 단계별 활동을 통해 얻어지는 산출물들의 품질을 완성..

이 포스팅은 CMU(Carnegie Melon University)의 SEI (Software Engineering Institute) 블로그의 "Incorporating Agile Principles into Independent Verificaiton and Validation (Author: Justin Smith, June 24, 2024)"을 기반으로 작성되었습니다.  우주로 사람을 보내는 소프트웨어를 개발할 때는 예상대로 작동하는지 철저히 검증해야 합니다. 이처럼 안전이 중요한 시스템에서 독립적인 검증 및 확인(IV&V) 프로세스는 제품이 요구사항을 충족하고 의도대로 기능하는지 확인하기 위해 존재합니다. 대부분의 IV&V 방식은 프로젝트 관리의 폭포수 모델과 연관되어 있지만, 애자일 사고방식과..

소프트웨어 인스펙션은 동료 검토 방식 중 가장 엄격한 절차로 수행되는 리뷰 방법입니다.최근 여러 시스템들이 안전과 보안이 중요해 짐에 따라 가끔식 등장하는 용어인데요.이번 포스팅에서는 소프트웨어 인스펙션 절차에 대해 상세히 알아 보겠습니다. 1. 소프트웨어 인스펙션 개요1.1 소프트웨어 인스펙션의 정의와 목적소프트웨어 인스펙션은 코드, 설계 문서, 요구사항 명세서와 같은 소프트웨어 산출물을 체계적으로 검토하여 결함을 조기에 발견하고 품질을 높이는 검토 기법입니다. 개발자가 아닌 검토자가 결함을 찾아내고 개선 사항을 제안하는 정적 분석 기법으로, 주로 코드 실행 없이 문서와 코드 자체를 검토하는 방식으로 진행됩니다.결함의 조기 발견: 개발 단계에서 결함을 미리 발견해 수정 비용을 절감하고, 후반부 결함으로..

소프트웨어 개발의 성공은 무엇보다도 사용자와 이해관계자의 요구를 명확히 이해하고 충족하는 데 달려 있습니다. 이를 위한 체계적인 접근 방식이 요구공학(Requirements Engineering)입니다. 요구공학은 소프트웨어 시스템이 충족해야 할 기능적 및 비기능적 요구사항을 정의하고 관리하는 과정을 포함합니다. 이번 글에서는 요구공학의 중요성, 과정, 기법을 살펴보겠습니다. 1. 요구공학의 중요성1-1 프로젝트 성공의 기초요구공학은 소프트웨어 개발 프로젝트의 성공적인 완료를 위한 기초를 다집니다. 명확하고 정확한 요구사항 정의는 프로젝트가 올바른 방향으로 진행될 수 있도록 합니다.명확한 목표 설정: 요구사항을 명확히 정의함으로써 프로젝트의 목표와 범위를 분명히 설정할 수 있습니다. 이는 프로젝트 팀이 ..

소프트웨어 통합 테스트에서 커버리지(Coverage)는 테스트가 시스템 내 다양한 요소와 경로를 얼마나 잘 검증했는지를 나타내는 지표입니다. 커버리지를 통해 통합 테스트가 얼마나 완벽하게 수행되었는지 측정할 수 있으며, 통합 과정에서 발생할 수 있는 오류나 문제를 사전에 발견하고 해결하는 데 중요한 역할을 합니다. 1. 인터페이스 커버리지 (Interface Coverage)인터페이스 커버리지는 모듈 간의 모든 인터페이스가 테스트되었는지 확인하는 커버리지 유형입니다. 소프트웨어 통합에서는 각 모듈이 데이터를 주고받기 위해 인터페이스를 사용하므로, 이들 인터페이스가 정확히 작동하는지 확인하는 것이 중요합니다.인터페이스 커버리지 측정을 위해서는 모듈 간 상호작용은 모델과 코드 모두에서 검증이 필요합니다. 모..

소프트웨어 통합 테스트는 모듈화된 소프트웨어가 모듈 통합과정에서 오류가 없는지를 확인하는 테스트입니다.그런데, 일부에서는 이 테스트를 모듈 통합이 완료된 상태에서 테스트하는 것으로 잘못 이해하는 경우가 있습니다.약간 우스꽝 스러운 상황이지만, 용어를 잘못 이해한 상황으로 생각해보면, 이에 대한 이해가 부족한 것으로 볼 수 있기 때문에, 이번 포스팅에서는 소프트웨어 통합 테스트 전략에 대해 알아보도록 하겠습니다.    자동차 소프트웨어 개발에서 AUTOSAR (AUTomotive Open System ARchitecture)는 모듈화, 표준화, 호환성을 보장하는 주요 소프트웨어 아키텍처입니다. AUTOSAR 기반 소프트웨어는 Software Component (SWC)로 작성되며, 이들이 결합하여 Comp..

소프트웨어 인스펙션을 수행하기에는 막연함이 있습니다.이번 포스팅에서는 인스펙션 가이드라인에 대해 살펴 보고,인스펙션 수행에 도움이 되는 계기가 되면 좋겠습니다.  소프트웨어 개발에서 인스펙션은 결함을 조기에 발견하고 코드 품질을 높이는 중요한 활동입니다. 하지만 인스펙션이 효과적으로 이루어지기 위해서는 명확한 가이드라인이 필요합니다. 인스펙션 가이드라인은 검토 과정에서 지켜야 할 원칙과 절차를 제시하여, 모든 참여자가 일관된 기준으로 검토할 수 있게 합니다. 이번 글에서는 인스펙션 가이드라인의 주요 원칙과 이를 효과적으로 수행하기 위한 팁을 알아보겠습니다. 1. 소프트웨어 인스펙션의 목적과 중요성인스펙션은 소프트웨어 개발 단계에서 결함을 조기에 발견하여, 후반부의 수정 비용을 줄이고 품질을 높이기 위해 ..

소프트웨어 인스펙션에서는 Moderator(모더레이터), Reader(리더), Author(작성자), Recorder(기록자), Inspector(검토자)의 다섯 가지 역할이 중요합니다. 각 역할이 고유의 책임을 가지고 효과적으로 수행될 때 인스펙션의 품질과 효율성이 극대화됩니다. 아래에서는 각 역할의 주요 업무와 역할 선정 및 수행 시의 주의 사항을 설명하겠습니다.소프트웨어 인스펙션 절차에 대해서는 다음 포스팅에 정리되어 있습니다.  소프트웨어 인스펙션(Software Inspection) - 개요와 절차소프트웨어 인스펙션은 동료 검토 방식 중 가장 엄격한 절차로 수행되는 리뷰 방법입니다.최근 여러 시스템들이 안전과 보안이 중요해 짐에 따라 가끔식 등장하는 용어인데요.이번 포스팅에서habana4.tis..