Cohe

1. 시스템 아키텍처에 대한 설명으로 옳지 않는 것은? 물리적 구성을 기반으로 정의되는 시스템의 상세 설계도이다. ② 이해당사자들과의 상호 이해, 협상, 동의 및 의사 교환을 위한 도구이다. ③ 프로젝트 초기의 설계 결정으로 시스템 개발 및 유지보수 전반에 걸쳐 지속적인 영향 력 을 갖는다 ④ 시스템에 관련 있는 이해당사자들의 요구사항을 고려하여 정의하여야 한다 2. 다음 중 스프트페어 아키텍처에서 설계에 필수적인 요소들로만 짝지워진 것은? 💡 소프트웨어 컴포넌트 클래스 다이어그램 소프트웨어 컴포넌트 사이의 관계를 나타내는 커넥터 E-R 다이어그램 1 ㄱㄴ 2 ㄱㄷ 3ㄱㄷ 4ㄷㄹ 3. 소프트웨어 아키텍처의 4+1 관점(View)에 대한 설명으로 옳지 않은 것은? 1 유스케이스 관점에서는 외부 행위자에 의..

6-1 시스템 아키텍처에 대한 설명으로 옳지 않는 것은? ① 물리적 구성을 기반으로 정의되는 시스템의 상세 설계도이다. 이해 당사자들과의 상호 이해, 협상 동의 및 의사 교환을 위한 도구이다. 프로젝트 초기의 설계 결정으로 시스템 개발 및 유지보수 전반에 걸쳐 지속적인 영향력을 갖는다. 시스템에 관련 있는 이해 당사자들의 요구사항을 고려하여 정의하여야 한다. 6-2 비기능적 요구사항을 고려한 아키텍쳐 설계로 가장 적합하지 않은 것은? 2. ④ 가용성이 중요한 요구사항일 경우 아키텍처에 여분의 구성요소들이 포함 되도록 설계하여 시스템을 중단 없이 구성요소를 대치하고 갱신 할 수 있게 한다. 보안성이 중요한 요구사항일 경우 계층구조의 아키텍쳐를 사용하여 가장 중요한 자산들을 가장 중요한 내부의 계층에서 보호..

5-1 다음은 모델링을 하는 이유를 나열한 것이다 옳은 것만 선택한 것은? ③ 👉 ㄱ 복잡함을 관리하기 위하여 ㄴ 형체가 없는 소프트웨어의 구조를 시각화하기 위하여 ㄷ 고객과 커뮤니케이션하기 위하여 ㄹ 구현하기 전에 잠재적 솔루션을 실험해보기 위하여 ㄱ ㄴ ㄱ ㄷ ㄱ ㄴ ㄷ ㄱ ㄴ ㄹ 5-2 시스템 뜨는 시스템을 구성하는 요소들의 동적인 행위를 표현하기 위한 UML 다이어그램이 아닌 것은? 2. ① 배치(deployment) 다이어그램 상태(state) 다이어그램 시퀀스(sequence) 다이어그램 타이밍(timmg) 다이어그램 5-3 UML 다이어그램의 설명이 옳지 않은 것은? 3. ① 상태(state) 다이어그램(diagram) - 클래스 사이의 메시지 교환을 시간의 흐름에 따라 표현 클래스 다이어그..

4-1 요구분석 단계를 순서대로 바르게 나열한 것은? ③ 👉 ㄱ 요구 사항 분석 ㄴ요구 사항 검증 ㄷ 요구 사항 명세 ㄹ 요구 사항 추출 ㄷ-ㄹ-ㄱ-ㄴ ㄷ-ㄹ-ㄴ-ㄱ ㄹ-ㄱ-ㄷ-ㄴ ㄹ-ㄷ-ㄴ-ㄱ 4-2 다음 중 소프트웨어 요구 분석에 대한 설명으로 옳지 않은 것은? ③ 각 요구 사항을 명확하고 구체적이며 정확하고 검증 가능하도록 정의하고 기술하여야 한다. 요구 사항은 고품질의 소프트웨어를 개발하고 검증 할 수 있는 기초를 제공한다. 고객과 개발자가 서로 당연하게 인정하는 요구 사항은 생략하여도 무방하다 요구 사항은 크게 기능적인 요구 사항과 성능, 신뢰성, 가용성, 보안성, 안전성 등의 비기능적 요구 사항으로 분류한다 4-3 다음 컴퓨터 실습실의 비디오 감시 시스템에 대한 요구 사항을 기술한 것이다. 비..

설계 기본 개념 설계 요구 분석: '무엇을 만들 것인가를 다루는 작업 설계는 '어떻게 실현할 것인가'를 구체적으로 결정하는 활동 아키텍처 설계 - 기본 구조 설계로 각 모듈의 역할과 인터페이스를 정의 상세 설계 - 모듈 내부의 알고리즘, 데이터를 명세화 설계는 개발자의 창의성이 발휘되는 창조적인 과정 설계 원리 복잡한 시스템을 분할하고 하나씩 해결하는 분할 정복의 원리를 적용하면 복잡함을 잘 다룰 수 있음 우리가 인지할 수 있는 개념부터 작업 세분화 하면서 나눌 수 있다. 기본 개념 설계 높은 수준의 의사 결정 과정의 연속 설계 원리가 중요 전통적 설계 방법 분할 정복, 추상화, 합성 등의 원리를 적용 최근의 방법 아키텍처 기반의 설계 방법 아키텍처 이해 서브시스템, 모듈의 개념과 설계 작업의 관점, 설..

3-1 다음 중 계획에 대한 설명으로 바르지 않은 것은?④ 계획은 제한된 자원과 제한원 일정으로 결과를 생성하기 위한 방법을 모색하는 것이다. 계획은 노동 집약적인 개발을 지원하기 위하여 새로운 인력 자원을 찾는 것이다 계획은 보이지 않는 것을 찾고 조정하는 것이다. 계획은 많은 사람의 노력을 융합하여 제품을 만들고 이를 통하여 고객의 요구를 만족 시키는 것이다. 3-2 다음 중 소프트웨어 계획 단계에서 이루어지는 일이 아닌 것은? 2.③ 소프트웨어 개발의 범위에 대한 정의 소프트웨어 개발을 위해 필요한 자원들의 예측 소프트웨어 모듈 및 자료구조의 정의 소프트웨어 개발을 위한 비용과 일정의 수정 3-3 다음 중 계획 단계에 사용되는 기법에 대한 설명이 옳지 않은 것은? 3.② COCOMO 모델은 규모를 ..

2-1 프로세스를 정의하지 않고 즉흥적인 개발을 할 경우의 발생하는 문제점이 아닌 것은? ③ 시스템을 구현하기 전에 요구를 알아본다든지 설계하는 작업의 중요성을 깨닫지 못하게 된다. 소프트웨어는 신중하게 잘 설계하지 않으면 그 구조가 나빠진다 장황한 문서가 없지만 시행착오를 덜 겪게 된다. 체계적인 테스트 작업이나 품질 보증 차원의 활동에 대한 필요성의 인식이 없다 2-2 다음은 프로세스와 관련된 용어를 설명한 것이다 옳지 않은 것은? ③ 프로세스 명세 - 프로젝트에서 수행하여야 하는 작업과 이들의 수행 순서를 정의한 것 프로세스 모델 - 일반적인 프로세스를 기술한 것 실행 프로세스 - 작업을 실행하였을 때 나오는 결과 프로세스 - 프로세스 명세와 실행 프로세스 두 가지 개념을 편의 상 부르는 용어 2-..

워터폴vs 애자일 워터폴 폭포수 모델은 순차적인 소프트웨어 개발 프로세스(소프트웨어를 만들기 위한 프로세스)로 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 것처럼 보이는 데서 이름이 붙여졌다. 워터폴이란? 요구사항 수집과 분석 프로젝트에 사용될 기능적, 시스템적 또는 기술적 사양 정보를 클라이언트와 주요 이해관계자로부터 수집한다. 설계 사용자 경험 전문가는 고객 제품팀 및 기타 주요 이해관계자와 함께 제품의 모양새와 여타 요소들을 결정한다. 구현 테스트 성능, 시스템 및 사용자 승인 테스팅을 수행하여 제품이 요구사항을 충족하는지 확인한다. 만약 결함이나 버그가 발견되면 제품이 전달되기 전에 해결된다. 프로젝트 최종 결과물 전달 프로젝트를 착수할 때 확정했던 사양을 제품이 충족하면 클라이언트에게..

1-1 소프트웨어에 대한 올바른 상식은? 4 소프트웨어 프로젝트의 요구 사항은 지속적으로 변경되지만 소프트웨어는 유연하기 때문에 변경을 반영하는 것이 쉽다. 프로그램을 실제 작동해 보기 전까지는 소프트웨어의 품질을 평가하는 것은 불가능하다. 소프트웨어 공학은 별로 필요 없는 많은 문서를 생성하게 하여 개발을 지연시킨다. 지체된 프로젝트에 인력을 뒤늦게 투입하는 것은 오히려 프로젝트의 일정을 더욱 지연 시킬 수 있다. 프로그램을 실제 작동해 보기 전까지는 소프트웨어의 품질을 평가하는 것은 불가능하다.지체된 프로젝트에 인력을 뒤늦게 투입하는 것은 오히려 프로젝트의 일정을 더욱 지연 시킬 수 있다. → 지연 됨. 소프트웨어 공학은 별로 필요 없는 많은 문서를 생성하게 하여 개발을 지연시킨다. 소프트웨어 프로젝..