D-65 SW 공학

 

 

1. 정보시스템 감리와 PMO 비교, 수행과 기대효과 측면

정보시스템 감리와 PMO(Project Management Office)는 모두 프로젝트 관리와 품질 향상을 위한 중요한 역할을 수행하지만, 그 수행 방식과 기대효과에 있어 차이점이 있습니다. ## 수행 측면 **정보시스템 감리** - 외부 전문가에 의해 독립적으로 수행됩니다. - 주로 프로젝트의 주요 단계별로 실시됩니다. - 법적 근거에 따라 수행되며, 일정 규모 이상의 공공 정보화 사업에서는 의무적으로 실시됩니다. - 감리 결과를 발주자에게 보고하고 시정 조치를 요구할 수 있습니다. **PMO** - 내부 조직이나 외부 전문가로 구성되어 프로젝트 전반에 걸쳐 지속적으로 관여합니다. - 프로젝트 계획 수립부터 종료까지 전 과정에 걸쳐 지원 및 관리 업무를 수행합니다. - 프로젝트 관리 방법론, 도구, 기법 등을 제공하고 표준화합니다. - 프로젝트 팀과 긴밀히 협력하여 문제 해결 및 의사결정을 지원합니다. ## 기대효과 측면 **정보시스템 감리** - 객관적인 제3자의 시각에서 프로젝트의 품질, 진행 상황, 위험 요소 등을 평가합니다. - 법규 및 표준 준수 여부를 확인하여 프로젝트의 적법성을 보장합니다. - 주요 단계별 검토를 통해 중대한 오류나 문제점을 조기에 발견하고 시정할 수 있습니다. - 발주자의 이익을 보호하고 프로젝트의 성공 가능성을 높입니다. **PMO** - 프로젝트 관리 역량을 강화하고 일관된 프로세스를 적용하여 효율성을 높입니다. - 다양한 프로젝트 간의 조정과 자원 관리를 통해 조직 전체의 프로젝트 포트폴리오를 최적화합니다. - 지속적인 모니터링과 지원을 통해 프로젝트 위험을 사전에 식별하고 대응합니다. - 프로젝트 관리 지식과 경험을 축적하여 조직의 프로젝트 수행 능력을 향상시킵니다. 정보시스템 감리와 PMO는 각각의 특성에 따라 프로젝트의 성공적인 수행과 품질 향상에 기여합니다. 감리는 객관적이고 독립적인 평가를 통해 프로젝트의 적절성을 검증하는 반면, PMO는 지속적인 관리와 지원을 통해 프로젝트의 효율성과 효과성을 높이는 데 중점을 둡니다. 따라서 두 방식을 상호 보완적으로 활용하면 프로젝트의 성공 가능성을 더욱 높일 수 있습니다. Citations: [1] https://www.semanticscholar.org/paper/f4af0fc840c2641f6667098c128ab745e0a9685c [2] https://www.semanticscholar.org/paper/6a7f508f344fe41d9104616ab1a6ad1dc4c3cf91

 

2. SW 테스트로 화이트박스 테스트와 블랙박스 테스트의 정의 및 유형과 수행 시기

소프트웨어 테스트는 크게 화이트박스 테스트와 블랙박스 테스트로 나눌 수 있습니다. 각각의 정의, 유형, 그리고 수행 시기에 대해 알아보겠습니다. ## 화이트박스 테스트 **정의** 화이트박스 테스트는 소프트웨어의 내부 구조와 동작을 검사하는 테스트 방법입니다. 프로그램의 소스 코드를 직접 분석하여 테스트를 수행합니다[1]. **유형** 1. 제어 흐름 테스트 2. 데이터 흐름 테스트 3. 분기 테스트 4. 경로 테스트 **수행 시기** 화이트박스 테스트는 주로 단위 테스트 단계에서 수행됩니다. 개발자가 코드를 작성한 직후에 실시하며, 프로그램의 내부 로직을 검증하는 데 사용됩니다[1]. ## 블랙박스 테스트 **정의** 블랙박스 테스트는 소프트웨어의 내부 구조나 동작 원리를 모르는 상태에서 외부 인터페이스를 통해 기능을 검증하는 테스트 방법입니다[2]. **유형** 1. 동등 분할 테스트 2. 경계값 분석 3. 결정 테이블 테스트 4. 상태 전이 테스트 5. 유스케이스 테스트 **수행 시기** 블랙박스 테스트는 주로 통합 테스트와 시스템 테스트 단계에서 수행됩니다. 소프트웨어의 기능적 요구사항을 검증하는 데 사용되며, 개발 후반부에 실시됩니다[2][4]. ## 비교 화이트박스 테스트는 코드의 내부 구조를 기반으로 테스트 케이스를 설계하고 실행하는 반면, 블랙박스 테스트는 소프트웨어의 외부 동작과 출력을 검증합니다. 화이트박스 테스트는 주로 개발자에 의해 수행되며, 블랙박스 테스트는 테스터나 품질 보증 팀에 의해 수행되는 경우가 많습니다[4]. 두 테스트 방법은 상호 보완적이며, 효과적인 소프트웨어 테스트를 위해서는 두 방법을 적절히 조합하여 사용하는 것이 중요합니다. 이를 통해 소프트웨어의 내부 로직과 외부 기능을 모두 철저히 검증할 수 있습니다[3]. Citations: [1] https://www.semanticscholar.org/paper/6dc2f476391ba0eda53fee589bcb87f4a0103b79 [2] https://www.semanticscholar.org/paper/e3d34dd76c5205c0511d6c6ff8906a1792dd7048 [3] https://www.semanticscholar.org/paper/1d68a3e7d8488922339f36bfdc3cad9e180ba063 [4] https://www.semanticscholar.org/paper/14e2a966a4bc61c62357ddc3a83b4eac2f4f71af [5] https://www.semanticscholar.org/paper/16c5124869d7f0dd4d8832d7dc66fd4fb152a35f

 

3. SAD 정의 및 작성절차, 작성가이드, 목차를 설명

SAD(Software Architecture Document)는 소프트웨어 시스템의 아키텍처를 문서화하는 중요한 산출물입니다. SAD의 정의, 작성 절차, 작성 가이드, 그리고 목차에 대해 설명하겠습니다. ## SAD 정의 SAD는 소프트웨어 시스템의 아키텍처를 설명하는 포괄적인 문서입니다. 이 문서는 시스템의 주요 설계 결정사항, 구조적 요소, 인터페이스, 그리고 이들 간의 관계를 상세히 기술합니다[1][2]. SAD는 개발 팀, 이해관계자, 그리고 평가자들이 시스템의 아키텍처를 이해하고 평가하는 데 필수적인 자료입니다. ## 작성 절차 1. **요구사항 분석**: 시스템의 기능적, 비기능적 요구사항을 파악합니다. 2. **아키텍처 설계**: 요구사항을 바탕으로 시스템의 전체적인 구조를 설계합니다. 3. **문서화**: 설계된 아키텍처를 SAD 템플릿에 맞춰 문서화합니다. 4. **검토 및 수정**: 이해관계자들의 피드백을 받아 문서를 보완합니다. 5. **최종 승인**: 문서의 완성도를 확인하고 최종 승인을 받습니다. ## 작성 가이드 1. **명확성**: 아키텍처 설계 결정사항을 명확하게 설명합니다. 2. **일관성**: 문서 전체에 걸쳐 일관된 용어와 표기법을 사용합니다. 3. **완전성**: 모든 중요한 아키텍처 요소와 관계를 포함합니다. 4. **추적성**: 요구사항과 아키텍처 설계 간의 연관성을 명시합니다. 5. **모델링 도구 활용**: Sparx Enterprise Architect와 같은 모델링 도구를 사용하여 문서화 효율성을 높입니다[1]. ## SAD 목차 1. **소개**    - 목적    - 범위    - 정의 및 약어    - 참조 문서 2. **아키텍처 개요**    - 시스템 컨텍스트    - 주요 설계 결정사항    - 아키텍처 원칙 3. **시스템 구조**    - 논리적 뷰    - 프로세스 뷰    - 개발 뷰    - 물리적 뷰 4. **컴포넌트 설명**    - 주요 컴포넌트 식별    - 컴포넌트 간 인터페이스 5. **동적 행위**    - 주요 시나리오    - 상태 다이어그램 6. **품질 속성**    - 성능    - 보안    - 확장성    - 유지보수성 7. **외부 인터페이스**    - 사용자 인터페이스    - 하드웨어 인터페이스    - 소프트웨어 인터페이스 8. **아키텍처 평가**    - 평가 기준    - 평가 결과 9. **부록**    - 용어집    - 참조 문헌 SAD는 소프트웨어 개발 프로세스에서 핵심적인 역할을 합니다. 특히 안전 중심적인 시스템 개발에서는 ISO 26262와 같은 표준을 준수하며 SAD를 작성하는 것이 중요합니다[1]. 또한, 국방 분야에서는 SAD가 계약적 의무사항으로 요구되며, 소프트웨어 아키텍처 평가의 기초 자료로 활용됩니다[2]. Citations: [1] https://www.semanticscholar.org/paper/4994974d039afc39762184502da3c75ed870b874 [2] https://www.semanticscholar.org/paper/be130f2460aa903a8ed3a9a0870b8edd6ee9880e