내 머리속 지우개

CBSE의 중요한 개념은 컴포지션입니다.컴포지션을 통해 또 다른 새로운 컴포넌트를 생성할 수 있어요.이번 포스팅에서는 컴포지션의 개념에 대해 살펴 보도록 할게요.  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다.  컴포넌트 컴포지션은 컴포넌트와 특별히 작성된 ’글루 코드(glue code)’를 서로 통합하여 시스템이나 다른 컴포넌트를 만드는 과정입니다. 컴포넌트 컴포지션 방법에는 여러 가지가 있으며, 다음 17.10에서 그 예를 보여주고 있습니다. 왼쪽에서 오른쪽으로 차례로 순차적 컴포지션, 계층적 컴포지션, 그리고 부가적 컴포지션성을 나타냅니다. 아래의 논의에서는 두 개의 컴포넌트(A와 B)를 결합하여 새로운 컴포넌트를 ..

컴포넌트 기반 소프트웨어 개발 방법론은소프트웨어 재사용이란 주제에서 출발한 개념인걸 아셨나요?이번 포스팅에서는 컴포넌트 기반 소프트웨어 공학, CBSE 개념에 대해 알아 보겠습니다.  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다. 1. 컴포넌트 기반 소프트웨어 공학 (Component-based Software Engineering)컴포넌트 기반 소프트웨어 공학(CBSE)은 1990년대 후반에 소프트웨어 컴포넌트의 재사용을 기반으로 한 소프트웨어 시스템 개발 접근 방식으로 등장했습니다. CBSE의 탄생은 객체 지향 개발이 처음 제안되었을 때 예상했던 광범위한 재사용으로 이어지지 않았다는 디자이너들의 좌절에서 비롯되었습니다...

소프트웨어 신뢰성에 대한 정의는 정의를 내리는 사람 또는 기관에 따라 약간씩 다르게 정의되고 있습니다.먼저 1992년 미국의 AIAA (American Institute of Aeronautics and Astronautics)의 정의에 따르면,"The ability of a system or component to perform its required functions under stated conditions for a specified period of time." (특정 시간 동안 정해진 환경 조건하에서 요구되는 기능을 수행하기 위한 시스템 또는 컴포넌트들의 능력) (by ANS/AIAA R-013-1992) 로 되어 있습니다. 최근 새롭게 정의된 개념은 소프트웨어 시험(테스팅)에 보다 중점을 둔..

목차  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다.재사용 기반 소프트웨어 공학(Reuse-based software engineering)은 기존 소프트웨어를 재사용하는 것에 중점을 둔 소프트웨어 개발 전략입니다. 비록 재사용이 개발 전략으로 제안된 것은 40년 이상 전이었지만(McIlroy, 1968), 실제로 2000년 이후에야 ‘재사용을 통한 개발’이 새로운 비즈니스 시스템의 표준이 되었습니다. 재사용 기반 개발로의 전환은 소프트웨어 생산 및 유지보수 비용을 줄이고, 시스템을 더 빠르게 제공하며, 소프트웨어 품질을 향상시키려는 요구에 대응하기 위해 이루어졌습니다.  재사용 가능한 소프트웨어의 가용성은 과거에 비해 많..

요구사항을 추출하고 분석하는 것도 매우 어려운 일이지만,요구사항을 검증하고 관리하는 것 역시 쉽지 않습니다.이미 잘 알려진 내용이지만, 가볍게 한번 살펴 보겠습니다.  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다.  요구사항 확인 (Requirements Validation)요구사항 확인은 요구사항이 실제로 고객이 원하는 시스템을 정의하고 있는지 확인하는 과정입니다. 이 과정은 요구사항 분석과 겹치는 부분이 있으며, 요구사항의 문제를 찾는 데 중점을 둡니다. 요구사항 문서에 오류가 있는 경우, 개발 중이나 시스템이 서비스에 들어간 후 문제가 발견되면 광범위한 재작업 비용이 발생할 수 있기 때문에 요구사항 검증은 매우 중요합..

요구사항 추출 및 분석은 소프트웨어 공학에서 아주 중요한 활동입니다.하지만 요구사항 추출 및 분석에 어떤 방법이 사용되는지 정리된 내용이 많이 부족합니다.이번 포스팅에서는 요구사항 추출 및 분석 방법에 대해 살펴 보겠습니다.  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다. 요구사항 추출 및 분석 (Requirements Elicitation and Analysis)요구 사항 추출 및 분석은 소프트웨어 엔지니어들이 고객 및 시스템 최종 사용자와 협력하여 애플리케이션 도메인, 시스템이 제공해야 하는 서비스, 시스템의 요구 성능, 하드웨어 제약 조건 등을 파악하는 활동입니다. 요구 사항 추출 및 분석에는 조직 내에서 다양한 사람..

이번 포스팅에서는 요구사항 문서화에 대해 알아 보려고 합니다.요구사항 문서화는 자연어, 다이어그램, 그리고 수학식과 같은 다양한 방법이 사용됩니다.결과적으로 문서화 역시 쉽지 않은 분야이며, 많은 노력이 요구되는 분야입니다.자세한 내용을 살펴 보도록 하겠습니다.  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다. 소프트웨어 요구사항 문서 (Software Requirements Document)소프트웨어 요구 사항 문서(종종 소프트웨어 요구 사항 명세서 또는 SRS(Software Requirements Specification)라고 불림)는 시스템 개발자가 구현해야 할 내용을 공식적으로 명시하는 문서입니다. 이 문서에는 시스..

대학 시절 배웠던 "소프트웨어 공학" 교재를 다시 한번 읽어보기로 했어요.천천히 정리하면서 중간중간 경험적 내용을 추가하면 아주 좋은 기록이 될거 같네요.이번 포스팅에서는 요구공학과 소프트웨어 요구사항에 대해 알아 볼게요.  이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다.   1. 사용자 요구사항과 시스템 요구사항소프트웨어 시스템 요구 사항은 시스템이 수행해야 하는 작업, 제공해야 하는 서비스, 그리고 운영에 대한 제약 조건을 설명합니다.이러한 소프트웨어  시스템 요구 사항은 특정 목적을 수행하는 시스템을 원하는 고객의 요구를 반영합니다. 또한 요구공학(Requirements Engieering, RE)이란 이러한 서비스와 ..

소프트웨어 개발에서 성과측정은 정말 쉽지 않습니다.그럼에도 불구하고, 성과측정은 매우 중요한데요.이번 포스팅에서는 성과측정을 위해 필요한 사항이 어떤것들이 있는지 알아 보겠습니다.   소프트웨어 공학에서 조직 구성원의 성과를 측정하는 것은 생각보다 복잡한 문제입니다. 성과를 객관적으로 평가하려면 명확한 조직 목표가 필수적이지만, 현실적으로 모든 목표를 수치화하는 것은 쉽지 않습니다. 그 결과, 많은 기업에서는 코드 품질, 시스템 안정성, 버그 수와 같은 ‘Hard’ 지표에만 의존하는 경향이 있습니다. 하지만 이러한 접근은 단기적으로는 프로젝트 성공을 가져올 수 있을지 몰라도, 장기적으로는 유지보수성이 떨어지고, 기술 부채가 쌓여 전체 시스템의 안정성을 위협할 수 있습니다. 하드 지표와 소프트 지표의 균형..

태풍이란 자연의 거대한 힘이 모인 대기 현상으로, 우리에게 많은 영향을 미칩니다. 매년 수많은 태풍이 발생하며, 그 강력함은 인명과 재산에 큰 피해를 줄 수 있습니다. 태풍을 사전에 감시하고 예측하는 것은 매우 중요한 일이죠. 개인적으로도 태풍이 다가올 때마다 날씨 변화에 더욱 민감해지고, 자연의 힘을 다시 한번 실감하게 됩니다. 이번 포스칭에서는 태풍 감시에 사용되는 주요 요소들과 그것들이 날씨와 환경에 미치는 영향을 알아보겠습니다.아! 혹시 몰라 태풍 이름을 어떻게 짓는지에 대해서는 따로 정리해 두었습니다. 9호 태풍 "종다리", 태풍 이름은 어떻게 결정되나?연일 열대야로 잠못이루는 터에 좀 입추도 지난 마당에 언제쯤 시원해 질까 고대하던 중에 제9호 태풍 종다리가 북상하는 소식을 접했습니다. 그런데..