본문 바로가기

Computer Science/Software Engineering23

[Software Engineering] Configuration Management Introduction1. 개요소프트웨어 형상 관리(SCM, Software Configuration Management)는 소프트웨어 개발 및 유지보수 과정에서 변경을 효과적으로 관리하는 기술 및 절차의 집합이다. 이는 소프트웨어 제품이 개발 및 배포되는 동안 일관성과 품질을 유지하기 위해 필요한 관리 기법을 포함한다. 2. 소프트웨어 형상 관리(SCM) 개념정의: 소프트웨어 엔지니어링 프로세스 내에서 특정 기준선을 설정하고 변경 사항을 평가 및 통제하는 관리 기법. 3. CMMI 내에서의 형상 관리CMMI(Capability Maturity Model Integration) 모델에서는 소프트웨어 구성 관리가 핵심 프로세스로 간주되며, 다음의 성숙도 수준으로 나뉜다:Level 1 - 초기(Initial.. 2025. 2. 23.
[Software Engineering] Software Maintenance and Evolution Software Maintenance and Evolution소프트웨어 변경 (Software Change)소프트웨어 변경은 불가피함소프트웨어 사용 중 새로운 요구사항이 발생비즈니스 환경 변화오류 수정 필요새로운 하드웨어 및 장비 도입성능 및 신뢰성 개선 필요기존 소프트웨어 시스템의 변경을 관리하는 것이 조직의 주요 과제소프트웨어 유지보수 및 발전 (Software Maintenance and Evolution)유지보수(Maintenance): 소프트웨어가 배포된 후 수정하는 작업유지보수, 발전(Evolution), 리엔지니어링(Reengineering)은 종종 같은 의미로 사용됨유지보수의 유형소프트웨어 결함 수정 유지보수시스템의 요구사항 충족을 위한 문제 해결운영 환경 변화에 따른 적응 유지보수새로운 .. 2025. 2. 23.
[Software Engineering] Debugging What is Debugging디버깅(Debugging)은 테스트 과정에서 발견된 오류를 수정하는 과정이다.디버깅 절차는 다음과 같이 진행된다:테스트 케이스 실행 → 오류 발생 → 원인 추정 → 원인 확인 → 수정 → 회귀 테스트(Regression Test) → 새로운 테스트 케이스 실행 디버깅 과정에서 오류의 증상과 실제 원인은 반드시 동일한 위치에 있거나 직접적으로 연결되지 않을 수도 있다. 다음과 같은 상황이 발생할 수 있다:증상과 원인이 지리적으로 분리될 수 있음 (Symptom and cause may be geographically separated)프로그램의 한 부분에서 문제가 발생했지만, 실제 원인은 다른 모듈이나 시스템에 있을 수 있다.예: 클라이언트 애플리케이션에서 UI가 깨지는 문제.. 2025. 2. 22.
[Software Engineering] Mutation Analysis, Automated Testing Mutation AnalysisMutation Analysis(돌연변이 분석)는 프로그램의 소스 코드나 바이트 코드에 의도적으로 변형(돌연변이)을 가하고 테스트를 실행하여, 테스트가 얼마나 효과적인지 평가하는 기법이다.목적테스트가 올바르게 작성되었는지 확인테스트가 소프트웨어 요구사항을 충분히 반영하고 있는지 검증개요Mutation Operators(변이 연산자)를 선택하여 원본 코드에 적용코드의 일부를 변형하여 Mutant(돌연변이 코드) 생성테스트 실행 후, 변경된 코드가 감지되면 Mutant는 "killed(사멸)" 되었다고 판단감지되지 않으면 해당 테스트가 충분히 강력하지 않다는 의미Weak and Strong Mutation Testing Mutation Operators (변이 연산자)문장 삭제.. 2025. 2. 21.
[Software Engineering] RBT, TDD, Test Coverage Risk-based Testing (RBT)1. What is Risk? 미래에 부정적인 결과를 초래할 수 있는 요소로, 일반적으로 영향(Impact)과 발생 가능성(Likelihood)으로 표현됨.2. Risk-based Testing 위험 식별 (Identify Risks)시스템의 어떤 부분에 위험이 있는지 식별위험 요소: 시스템 복잡도, 새로운 기술 사용, 부족한 비즈니스 지식, 코드 품질 등브레인스토밍 기법을 활용하여 최대 35개의 위험 요소 식별 가능위험 분석 (Analyze Risks)위험 점수 계산: 위험 = 영향(Impact) × 발생 가능성(Likelihood)발생 가능성을 결정하는 요소:복잡성, 재사용성, 인터페이스 개수, 크기, 기술, 개발팀의 경험 수준영향도를 결정하는 요소:사용자 .. 2025. 2. 20.
[Software Engineering] Testing Techniques White Box Testing화이트 박스 테스트는 소프트웨어의 내부 구조와 동작을 이해한 상태에서 수행하는 테스트 방법으로, 코드 기반 테스트라고도 한다. 내부 구현을 확인하면서 모든 논리 경로가 실행되도록 설계된다. 1. Basis Path Testing프로그램 내 모든 실행 경로를 검사하는 것이 목표.프로그램의 제어 흐름 그래프(Flow Graph)를 생성하여 노드와 간선(조건문)을 분석.독립적인 프로그램 경로(Independent Program Path)를 정의하여, 최소한의 경로만 테스트.사이클로매틱 복잡도(Cyclomatic Complexity)를 활용하여 테스트 경로의 개수를 산출.경로 계산 방법영역(region)의 수를 이용: V(G) = 영역의 개수간선(E)과 노드(N)을 이용: V(G).. 2025. 2. 19.
[Software Engineering] Software Testing 소프트웨어 테스트의 목표와 원칙(1) 테스트의 목표소프트웨어 테스트는 오류(결함, 버그)를 찾는 과정이다.성공적인 테스트란 아직 발견되지 않은 오류를 찾아내는 것이다.테스트는 버그가 없음을 증명하는 것이 아니라, 버그의 존재를 증명하는 것이다.(2) 소프트웨어 테스트의 원칙모든 테스트는 고객 요구 사항과 연계되어야 함→ 테스트는 고객의 요구 사항을 검증하는 방향으로 진행되어야 한다.테스트 계획은 가능한 빨리 수립해야 함→ 분석 모델이 완성되는 즉시 테스트 계획을 시작할 수 있다.파레토 법칙(80-20 법칙)이 적용됨→ 대부분의 오류(80%)는 코드의 일부(20%)에서 발생하는 경향이 있다.테스트는 작은 단위에서 큰 단위로 진행됨→ 개별 모듈부터 시작하여 전체 시스템까지 확장하는 방식이다.완벽한 테스트(모.. 2025. 2. 18.
[Software Engineering] Verification and Validation Verification and ValidationVerification (검증):"우리가 올바른 방식으로 제품을 만들고 있는가?'소프트웨어가 명세에 맞게 구현되었는지를 확인Validation (확인):"우리는 올바른 제품을 만들고 있는가?"소프트웨어가 사용자의 요구사항을 충족하는지를 확인차이점:Verification은 제품이 명세를 따르고 있는지 점검하는 과정Validation은 제품이 실제 사용자 요구를 충족하는지 평가하는 과정두 과정 모두 소프트웨어가 목적에 적합한지 확신을 가지게 하는 것이 목적 Two Complementary ApproachesSoftware Inspection (Static Verification)요구사항 문서, 설계 다이어그램, 소스 코드 등을 분석하여 문제를 발견Softwar.. 2025. 2. 17.
[Software Engineering] People Management Team Organization(1) 프로그래밍 팀 조직의 문제점프로젝트 완수를 위해 1년치 프로그래밍이 필요하지만, 3개월 내 완료해야 하는 경우 해결책으로 4명의 프로그래머를 배치한다고 가정.그러나 현실적으로 4명이 동시에 작업한다고 해서 시간이 1/4로 둘어들지 않으며, 품질 저하 가능성 존재.프로그래밍 팀은 서로 유기적으로 협력해야 하므로 복잡성이 증가.(2) 팀원 간의 협업 문제개발자가 모듈을 나누어 개발할 때, 인터페이스나 매개변수의 불일치 문제가 발생할 가능성이 큼.이는 기술적 능력 부족의 문제가 아니라 관리의 문제.(3) 커뮤니케이션 문제3명의 개발자가 있을 경우, 커뮤니케이션 채널은 3개.개발 마감이 다가와도 코드가 완성되지 않으면, 추가 개발자를 투입하는 것이 일반적인 해결책처럼 보이지.. 2025. 2. 16.
[Software Engineering] Agile Software Development Agile Software Development전통적인 Waterfall 모델의 한계를 극복하기 위해 등장한 소프트웨어 개발 방법론이다. 이는 팀 협업, 빠른 응답, 고객 중심 개발, 지속적인 개선을 중시하며, 변화하는 요구사항에 유연하게 대응할 수 있는 반복적(iterative)이고 증분적(incremental)인 개발 방식을 사용한다. 12 Principles of Agility1. 고객에게 가치 있는 소프트웨어를 조기에 지속적으로 전달함으로써 고객을 만족시킨다.2. 변화하는 요구사항을 환영한다. 개발의 후반부에서도 고객의 경쟁 우위를 높이기 위해 변경 사항을 수용한다.3. 짧은 주기로 동작하는 소프트웨어를 자주 전달한다.4. 비즈니스 담당자와 개발자는 프로젝트 전반에 걸쳐 긴밀하게 협력한다.5. 신.. 2025. 2. 14.
[Software Engineering] Process Improvement: CMMI Misconceptions and Symptoms of Process Failure다음과 같은 이유로 Process 자체에 너무 집착할 필요는 없다.1. 창의성을 방해한다.2. 관료주의 + 규제3. 프로토타입이 필요가 없을 수 있다.4. 대규모 프로젝트에만 유용하다.5. 빠르게 움직이는 시장에서 민첩성을 방해한다.6. 비용이 너무 많이 든다. 그리고 Process 실패에 대한 영향이 다음과 같이 존재한다.1. 지속적인 지연2. 진행 상황에 대한 관리 가시성 부재3. 품질 문제4. 팀원 사기 저하 Capability Maturity Model Integration: CMMICMMI는 카네기멜론대학교에서 개발한 Process 개선 교육 및 평가 프로그램이다. 기업은 Maturity level 등급 또는 Ca.. 2025. 2. 12.
[Software Engineering] Project Management The Four P's for ManagementProject Management: 제품을 현실로 만드는 데 필요한 모든 작업 관리Process Management: 작업을 완료하기 위한 프레임워크 활동 및 소프트웨어 엔지니어링 작업 세트 관리People Management: 성공적인 프로젝트의 가장 중요한 요소인 인간 관리Product Management: 구축할 소프트웨어의 형상관리 및 품질관리 Management Activities- Proposal Writing계약을 따거나 작업을 수행하기 위한 제안서를 작성해야하는데 제안서에는 무엇을 어떻게 할 예정인지도 중요하지만, 왜 해야하는지에 대한 정당성도 중요하다. - Personnel Selection and Evaluation프로젝트에 적합한 인력을.. 2025. 2. 8.
[Software Engineering] Usability and User Interface Design User Interface글꼴, 색상, 로고, 메뉴, 버튼 등과 같이 화면에 나타나는 모습과 사용자가 실제로 조작하는 것들UsabilityEffectiveness: 전체 시스템의 의도된 목표가 달성되는 정도로 측정Efficiency: 의도한 목표를 달성하기 위해 지출해야 하는 자원으로 측정Satisfaction: 사용자가 전체 시스템을 수용할 수 있다고 생각하는 정도로 측정Requirements ans AnalysisEnd user로부터 요구사항을 수집하는 과정- 사용자는 시스템이 무엇을 하기를 원하는가- 이 시스템은 사용자의 일반적인 업무 흐름이나 일상 활동에 어떻게 적용될 수 있는가- 사용자는 기술에 얼마나 능숙하며, 사용자가 이미 사용하고 있는 유사한 시스템은 무엇인가- 어떤 인터페이스 모양과 스타.. 2025. 2. 6.
[Software Engineering] Object-Oriented Design Concepts The 5 Basic Design Priciple for Object-Oriented Design (aka SOLID)1. SRP: Single-Responsibility Principle2. OCP: Open-Closed Principle3. LSP: Liskov Substitution Principle4. ISP: Interface Segregation Principle5. DIP: Dependency Inversion Principle The Single-Responsibility Principle (SRP)클래스는 하나의 책임만 가져야하며, 이를 변경하는 이유도 하나뿐이어야 한다.The Open-Closed Principle (OCP)소프트웨어 요소는 확장에는 열려있고, 변경에는 닫혀있어야 한다... 2025. 2. 4.
[Software Engineering] Component-Level Design & Fundamental Design Concepts Component-Level DesignComponent-level design은 Architecture design이 완료된 후에 수행되는데, 이것은 각 소프트웨어 Component에 할당된 자료 구조, 처리 로직, 인터페이스 특성 및 통신 메커니즘을 정의하는 것이다. Component란 프로그램의 기능적 요소이다. 이는 "module"이라고도 불린다. UML에서는 component를 "a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces"으로 정의한다.  Step 1: Identify All Design Components1. 문제 도메인에.. 2025. 2. 2.

티스토리툴바