728x90
반응형

소프트웨어개발 10

명확한 요구사항 작성 (모호성 제거) - 시각적 요구사항 정의, 모델기반 요구사항 명세서 (Model-Based Requirements Specification, MBRS)

모델 기반 요구사항 명세(MBRS)는 시스템 및 소프트웨어 엔지니어링에서 자연어의 모호성을 줄이기 위해공식적이거나 반공식적인 모델링 언어를 활용하는 접근 방식입니다.통합 모델링 언어(UML) 또는 시스템 모델링 언어(SysML)와 같은 표준화된 모델링 언어를 사용하여요구사항을 명확하고 간결하게 정의하며, 이는 건축 설계 도면처럼 시스템 설계를 위한 청사진 역할을 합니다.   MBSE (Model Based System/Software Engineering) 관련 글OMG SysML 다이어그램 마스터하기::모델링 가이드MBSE Example #1: 차량 가속도 vs. 연비 - 트레이드오프 분석 (with SysML)SPL: 도메인 요구공학 (Domain Requirements Engineering)소프트웨..

소프트웨어 공학: 소프트웨어 품질과 개발 생산성 - 오해에서 진실로

소프트웨어 개발 현장에서 종종 품질 관리 활동이 개발 생산성을 저하시킨다는 오해가 있습니다.예를 들어, 테스트 자동화 도입, 코드 리뷰 강화와 같은 품질 활동이 개발 속도를 늦추고비용을 증가시킨다고 생각하는 사람들이 많습니다.그러나 이는 잘못된 생각입니다. 장기적인 관점에서 품질 관리 활동은 오히려 생산성을 향상하고,더 나아가 조직의 성공을 보장합니다.   소프트웨어 품질은 개발 생산성에 중대한 영향을 미치는 요소로, 조직과 개발자 모두에게 중요합니다. 품질은 단순히 결함이 없는 상태를 넘어, 유지보수성, 가독성, 시스템 신뢰성 등 다양한 측면에서 측정됩니다. 실제로 구글(Google)은 개발 생산성과 품질의 관계를 심층적으로 분석하며, 프로세스 품질과 코드 품질의 상호작용이 생산성에 미치는 영향을 연구..

소프트웨어공학: 소프트웨어 생산성 측정과 개선 - 생산성 측정 프로세스

소프트웨어 개발에 있어 개발자들을 대상으로 한 생산성을 측정하고 관리하는 것은매우 어려운 주제 중 하나입니다. 생산성 측정에는 마법같은 해결책이 있는 것도 아니고요.이번 포스팅에서는 소프트웨어 생산성을 측정하고 개선하기 위한 실무적 접근법에 대해 살펴 보겠습니다.  이 포스팅은 Cristof Ebert의 "Measure and Improve Software Productivity" (IEEE Software, DOI Bookmark: 10.1109/MS.2023.3324466)의 내용을 기반으로 작성되었습니다. 소프트웨어 공학 전체글 바로가기 소프트웨어 생산성 측정과 개선소프트웨어공학: 소프트웨어 생산성 측정과 개선 - 생산성 측정 프로세스소프트웨어공학: 소프트웨어 생산성 측정과 개선 - 생산성 개선 절..

Software API (Application Programming Interface)란 무엇인가?

최근 개인적인 일로 Software API 관련 비즈니스 기획을 진행한 적이 있습니다. 대학을 다닐때부터 전공이 컴퓨터공학이었던터라 API를 실제로 많이 사용하기도 했었고, 석사와 박사과정을 거치며 수많은 책이나 논문을 통해서도 이 API란 용어를 많이 사용했었지만, 이에 대한 체계적인 정리를 해 본적이 없다는 생각이 들더라구요.그래서 오늘은 Software API 라는 주제에 대해 정리를 해 보고자 합니다. 1. 소프트웨어 API 란 무엇인가요?API (Application Programming Interface)는 소프트웨어 어플리케이션 간의 상호작용을 가능하게 하는 인터페이스 입니다. API는 소프트웨어간 데이터를 주고 받거나 기능을 사용할 수 있도록 정의된 규칙과 프로토콜을 제공하게 됩니다.따라서..

System Engineering 2024.07.27

인공지능과 소프트웨어 공학: 융합의 시대

인공지능(AI, Artificial Intelligence)과 소프트웨어 공학(Software Engineering)은 현대 소프트웨어 기술 발전에 절대적 기여를 하고 있는 분야로서, 이 두 분야의 융합은 다양한 산업에 혁신을 가져올 수 있다고 생각합니다. 하지만 두 분야의 융합을 위해 필요한 개념 정리와 고려사항들이 체계적으로 정리되지 못한 듯하여, 이번 블로그에서는 이런 내용을 다뤄보고자 합니다. 1. 인공지능(AI)란 무엇인가?인공지능은 컴퓨터 시스템이 인간의 지능적 작업을 수행할 수 있도록 만드는 기술입니다. AI는 머신 러닝(ML, Machine Learning), 자연어 처리(NLP, Natual Language Processing), 컴퓨터 비전(CV, Computer Vision) 등 다양..

소프트웨어 형상관리와 소프트웨어 개발

소프트웨어 형상관리 (Software Configuration Management)의 의미소프트웨어 형상관리는 다양한 소프트웨어 개발 표준에서 중요하게 언급되며, 각 표준은 형상관리의 정의와 목적을 명확히 하고 있습니다. 다음은 대표적인 소프트웨어 관련 표준에서 언급한 소프트웨어 형상관리의 정의입니다.더보기 ISO/IEC/IEEE 12207ISO/IEC/IEEE 12207은 소프트웨어 생명 주기 프로세스를 정의하는 국제 표준으로 소프트웨어의 일관성, 무결성, 추적성을 유지하고, 변경사항을 효과적으로 관리하여 소프트웨어 품질을 보장하기 위한 방안으로 소프트웨어 형상관리를 다음과 같이 정의하고 있습니다."형상관리는 소프트웨어 제품의 구성 요소와 관련 문서의 상태를 식별하고, 변경을 제어하며, 상태와 변경 이..

자동차 산업에서 소프트웨어와 E/E 아키텍처

자동차 산업은 하드웨어 중심에서 소프트웨어 중심으로 급격하게 변화하고 있습니다. 이는 자율 주행, 연결성, 전동화, 스마트 모빌리티(ACES) 분야에서 소프트웨어가 주요 혁신을 주도하며 차별화 요소로 작용하고 있기 때문입니다. 이로 인해 OEM(Original Equipment Manufacturer)들은 새로운 전기/전자(E/E) 아키텍처를 구축하고 효율적인 소프트웨어 개발을 지원하기 위한 새로운 프로세스와 모범 사례를 도입해야 하는 과제에 직면해 있습니다. 아래 그림은 자동차 E/E 시스템의 세대별 아키텍처와 주요 특징들을 설명하고 있다. 전략 및 기술:기존 하드웨어와 소프트웨어의 긴밀한 통합 아키텍처는 복잡성과 유연성 부족 등의 문제를 초래합니다.OEM은 하드웨어와 소프트웨어를 분리하고, 주기적인 ..

Automotive 2024.06.28

소프트웨어 개발자 생산성에 관하여

이 글은 2023년 IEEE Software Magazine에 등재된 "A Human-Centered Approach to Developer Productivity"를 기반으로 작성되었습니다.  소프트웨어를 개발하는 사람을 흔히 "개발자"라고 부릅니다.소프트웨어 공학적 관점에서 보았을 때, 소프트웨어 개발에 관여하는 수많은 이해관계자들이 있고, 이들은 각기 다른 역할(Role)을 부여하고 있음에도 불구하고, 우리나라에서는 "개발자"라는 말로 모두 "퉁"쳐서 지칭하고 있으며, 실제 업무에서도 이들 "개발자"에게 모든 책임(Responsibility)을 전가하여 과중한 업무로 내몰고 있는게 현실이라고 생각됩니다.  이는 소프트웨어 개발에 대한 생산성과 직접적인 연관성이 있을 것이며, 개발자 생산성은 IT 산..

소프트웨어 진화와 아키텍처 트레이드 오프 (Software Evolution and Architecture Trade-Off)

소프트웨어 아키텍처는 인생처럼 불완전한 정보와 시간 압박 속에서 수많은 상황과 제약에 따른 트레이드 오프 결정을 내리는 과정입니다. 완벽한 소프트웨어 아키텍처를 찾으려는 팀은 실망할 가능성이 높지만, 완벽하지 않더라도 다른 대안이 없다면, 어쩔수 없는 트레이드 오프 결정을 내려야 할 때가 많습니다. 예를 들어, 진화할 수 없고 유지 보수가 어려운 취약하고 비용이 많이 드는 시스템이 그렇습니다. 또한 여러 이해관계자들의 다양한 니즈를 충족시켜야 한다는 점에서도 트레이드 오프 결정이 필요한 경우가 많습니다. 특히, 소프트웨어 아키텍처 결정 시점에 수많은 품질 속성 요구사항이 존재하지만, 모든 품질 속성 요구사항을 만족시킨다는 것은 현실적으로 불가능하기 때문에 역시 트레이드 오프가 필요합니다. 그외에도 트레이..

Software Isolation During the Software Refactoring

최근 3~4년간 시간들을 돌이켜보면 소프트웨어 관련 기술들을 실무에 적용하기 위해 상당한 시간을 들였던 것으로 기억합니다. 소프트웨어를 개발하는 조직에서 소프트웨어 엔지니어로 살기 위해 여러 케이스를 고려한 나름의 노력이었는데, 안타깝지만 성과는 크지 않았던 것이 현실이었습니다.이런 무성과? 저성과?의 이유를 생각해 보면, 결국 조직적 이슈였던거 같은데 지속적으로 소프트웨어를 개발하고 유지보수하는 업무를 단순화 그리고 효율화하기 위한 노력이 왜 조직적 이슈로 인해 무산(?) 되었을까.. 그리고 무엇이 이러한 조직적 이슈를 야기시키고 있는 것일까 생각해 봅니다. 결국 생각해보면, "소프트웨어에 새로운 기능이 요구되고, 시간이 지남에 따라 복잡해지고 (예를 들어 불필요한 종속성, 중복되거나 강하게 결합된 기..

728x90
반응형