소프트웨어 아키텍처와 관련한 설명으로 틀린 것은? (1)
① 파이프 필터 아키텍처에서 데이터는 파이프를 통해 양방향으로 흐르며, 필터 이동 시 오버헤드가 발생하지 않는다.
=> 오버헤드 발생 가능.
② 외부에서 인식할 수 있는.
③ 데이터 중심 아키텍처는 공유 데이터 저장소를 통해 접근자 간의 통신. 접근자의 수정과 확장이 용이.
④ 이해 관계자들의 품질 요구사항을 반영하여 품질 속성을 결정.
소프트웨어 아키텍처 모델 중 MVC(Model-View Controller)와 관련한 설명으로 틀린 것은?(2)
② 모델(Model)은 뷰(View)와 제어(Controller) 사이에서 전달자 역할을 하며, 뷰마다 모델 서브시스템이 각각 하나씩 연결된다.
=> 전달자 역할은 컨트롤러.
한개의 모델에 대해 여러개의 뷰를 만들 수 있음
MVC 패턴에서는 여러개의 뷰를 만들 수 있으므로 한 개의 모델에 대해 여러개의 뷰를 필요로 하는 대화형 어플리 케이션에 적합하다
③ 뷰(View)는 모델(Model)에 있는 데이터를 사용자 인터페이스에 보이는 역할을 담당한다.
④ 제어(Controller)는 모델(Model)에 명령을 보냄으로써 모델의 상태를 변경할 수 있다
8. 모듈의 독립성을 높이기 위한 결합도(Coupling)와 관련한 설명으로 틀린 것은?(3)
① 오류가 발생했을 때 전파되어 다른 오류의 원인이 되는 파문 효과(Ripple Effect)를 최소화해야 한다.
② 인터페이스가 정확히 설정되어 있지 않을 경우 불필요한 인터페이스가 나타나 모듈 사이의 의존도는 높아지고 결합도가 증가한다.(의존도 == 결합도 != 응집도)
③ 모듈들이 변수를 공유하여 사용하게 하거나 제어 정보를 교류하게 함으로써 결합도를 낮추어야 한다. => 결합도가 더 높아져
9. 요구사항 관리 도구의 필요성으로 틀린 것은? (2)
- 요구 사항 관리 도구는 요구 사항의 변경 사항을 관리, 추적 및 제어
① 요구사항 변경으로 인한 비용 편익 분석
② 기존 시스템과 신규 시스템의 성능 비교
=> 모니터링 도구, 프로파일링 도구, 로드 테스트 도구 등이 포함
③ 요구사항 변경의 추적
④ 요구사항 변경에 따른 영향 평가
--
10. Sequence Diagram(순차다이어그램)과 관련한 설명으로 틀린 것은?(3)
① 객체들의 상호 작용을 나타내기 위해 사용한다 => Sequence Diagram 또는 Collaboration/Communication Diagram.
② 시간의 흐름에 따라 객체들이 주고 받는 메시지의 전달 과정을 강조한다
③ 동적 다이어그램보다는 정적 다이어그램에 가깝다 =>동적
④ Interaction Diagram 의 한 종류로 볼 수 있다
12. 소프트웨어 설계에서 요구사항 분석에 대한 설명으로 틀린 것은?(3)
① 요구사항 명세를 작성하는 작업이다
② 사용자의 요구를 추출하여 목표를 정하고 어떤 방식으로 해결할 것인지
③ 소프트웨어 시스템이 사용되는 동안 발견되는 오류를 정리하는 단계이다
=> 구현된 소프트웨어 시스템의 오류를 정리하는 것이 아님.
④ 개발의 출발점 &첫 번째 단계
13. 소프트웨어 공학에서 워크스루(Walkthrough)에 대한 설명으로 틀린 것은?(3)
- 워크스루: 소프트웨어 또는 문서 작성자가 검토 프로세스를 가지고 제품을 팀에 설명하는 비공식 검토 프로세스
① Use Case 를 확장하여 명세하거나 설계 다이어그램, 원시코드, 테스트 케이스 등에 적용 가능
② 복잡한 알고리즘 또는 반복, 실시간 동작, 병행 처리와 같은 기능이나 동작 이해 유용.
③ 인스펙션(Inspection)과 동일한 의미를 가진다.
=> 검사는 공식적인. 특정 종류의 오류를 찾는.
④ 단순한 테스트 케이스를 이용하여 프로덕트를 수작업으로 수행해 보는 것이다. 작동 방식을 이해하고 잠재적인 문제를 찾기 위해.
14. 공학적으로 잘된 소프트웨어(Well Engineered Software)의 설명 중 틀린 것은?(3)
② 소프트웨어는 신뢰성이 높아야 한다. 일관되게 작동해야.
③ 소프트웨어는 사용자 수준에 무관하게 일관된 인터페이스를 제공해야 한다. = > 수준에 맞게
15. 소프트웨어 모델링과 관련한 설명으로 틀린 것은?(1)
① 모델링 작업의 결과물은 다른 모델링 작업에 영향을 줄 수 없다.
=> 모델링은 상호 연결된 프로세스.
② 구조적 방법론에서는 DFD(Data Flow Diagram), DD(Data Dictionary) 등을 사용하여 요구사항의 결과를 표현한다. => Class Diagrams,Object Diagrams,Deployment Diagrams 등
③ 객체지향 방법론에서는 UML 표기법을 사용한다.
16.UML(Unified Modeling Language)에 대한 설명 중 틀린 것은?(4)
① 기능적 모델은 사용자 측면에서 본 시스템 기능이며, Use case Diagram 을 사용
② 정적 모델은 객체, 속성, 연관 관계, 오퍼레이션의 시스템의 구조를 나타내며, UML 에서는 Class Diagram 을 사용.
③ 동적 모델은 시스템의 내부 동작을 말하며, UML 에서는 Sequence Diagram, State Diagram,Activity Diagram 을 사용한다.
④ State Diagram 은 객체들 사이의 메시지 교환을 나타내며, Sequence Diagram 은 하나의 객체가 가진 상태와 그 상태의 변화에 의한 동작 순서를 나타낸다
=> 상태 다이어그램은 시스템의 동작을 설명. 개체가 수명 동안 거치는 일련의 상태.
시퀀스 다이어그램은 개체 간의 상호 작용 및 메시지 교환.
17. 유스케이스 다이어그램(Use Case Diagram)에 관련된 내용으로 틀린 것은?(1)
① 시스템과 상호 작용하는 외부 시스템은 액터로 파악해서는 안된다.
=> 액터로 다 간주할 수 있음.
② 유스케이스는 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술한다.
③ 시스템 액터는 다른 프로젝트에서 이미 개발되어 사용되고 있으며, 본 시스템과 데이터를 주고받는 등 서로 연동되는 시스템을 말한다.
④ 액터가 인식할 수 없는 시스템 내부의 기능을 하나의 유스케이스로 파악해서는 안된다
18. 단위 테스트(Unit Test)와 관련한 설명으로 틀린 것은?(3)
① 구현 단계에서 각 모듈의 개발을 완료한 후 개발자가 명세서의 내용대로 정확히 구현되었는지 테스트한다.
② 모듈 내부의 구조를 구체적으로 볼 수 있는 구조적 테스트를 주로 시행한다.
③ 필요 데이터를 인자를 통해 넘겨주고, 테스트 완료 후 그 결과값을 받는 역할을 하는 가상의 모듈을 테스트 스텁(Stub)이라고 한다.
=>
스텁은 주로 하향식 통합 테스트에 사용되며, 여기서 상위 레벨 모듈이 먼저 테스트되고 종속되는 하위 레벨 모듈이 스텁으로 대체됩니다.
④ 테스트할 모듈을 호출하는 모듈도 있고, 테스트할 모듈이 호출하는 모듈도 있다
19. 소프트웨어 테스트와 관련한 설명으로 틀린 것은? (4)
② 블랙박스 테스트는 프로그램의 구조를 고려하지 않는다.입출력 기능에 초점
③ 테스트 케이스에는 일반적으로 시험 조건, 테스트 데이터, 예상 결과가 포함되어야 한다.
④ 화이트박스 테스트에서 기본 경로(Basis Path)란 흐름 그래프의 시작 노드에서 종료 노드까지의 서로 독립된 경로로 싸이클을 허용하지 않는 경로를 말한다.
=> 루프가 포함될 수 있음.
20. 테스트 드라이버(Test Driver)에 대한 설명으로 틀린 것은? (4)
- 테스트할 모듈을 "구동"하는 프로그램 또는 스크립트.
① 시험대상 모듈을 호출하는 간이 소프트웨어이다.
② 필요에 따라 매개 변수를 전달하고 모듈을 수행한 후의 결과를 보여줄 수 있다.
③ 상향식 통합 테스트에서 사용된다.
④ 테스트 대상 모듈이 호출하는 하위 모듈의 역할을 한다.
=> 스텁 : 하향식
21. 화이트박스 테스트와 관련한 설명으로 틀린 것은?(3)
① 화이트박스 테스트의 이해를 위해 논리 흐름도(Logic-Flow Diagram)를 이용할 수 있다.
② 테스트 데이터를 이용해 실제 프로그램을 실행함으로써 오류를 찾는 동적 테스트(Dynamic Test)에 해당한다.
③ 프로그램의 구조를 고려하지 않기 때문에 테스트 케이스는 프로그램 또는 모듈의 요구나 명세를 기초로 결정한다.
=> 구조를 고려.
④ 테스트 데이터를 선택하기 위하여 검증 기준(Test Coverage)을 정한다.
22. 소프트웨어 형상 관리(Configuration Management)에 관한 설명으로 틀린 것은? (3)
② 소프트웨어 개발의 전체 비용을 줄이고, 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 한다.
③ 형상 관리를 위하여 구성된 팀을 “Chief Programmer Team”이라고 한다.
=> Configuration Management Team" 또는 "Change Control Board".
④ 형상 관리의 기능 중 하나는 버전 제어 기술이다.
23. 제품 소프트웨어의 형상 관리 역할로 틀린 것은 (3)
③ 프로젝트 개발 비용을 효율적으로 관리
=> 직접적으로 개발 비용을 관리는 X. 무결성을 유지가 목표
24. 형상 관리의 개념과 절차에 대한 설명으로 틀린 것은?(3)
① 형상 식별은 형상 관리 계획을 근거로 형상 관리의 대상이 무엇인지 식별하는 과정이다.
③ 형상 통제 과정에서는 형상 목록의 변경 요구를 즉시 수용 및 반영해야 한다.
=> 모든 변경 사항은 공식 검토 프로세스를 거쳐 시스템에 미치는 영향을 평가
④ 형상 감사는 형상 관리 계획대로 형상 관리가 진행되고 있는지, 형상 항목의 변경이 요구사항에 맞도록 제대로 이뤄졌는지 등을 살펴보는 활동이다
1. Consider a simple program that gets an input of Date of Birth from the user and generates an output of its age. Define a set of test cases for applying Blackbox testing on this program.:
(사용자로부터 생년월일 입력을 받아 나이의 출력을 생성하는 간단한 프로그램을 생각해 보겠습니다.
나이. 이 프로그램에 블랙박스 테스트를 적용하기 위한 테스트 케이스 집합을 정의합니다.)
테스트 케이스 1:
입력: 생년월일 "2000-06-08"
예상 출력: 나이는 "23세"
테스트 사례 2:
입력: 생년월일 "1980-01-01"
예상 출력: 나이는 "43세"
테스트 케이스 3:
입력: "2023-07-01"로 생년월일(미래 날짜)
예상 출력: 생년월일이 미래일 수 없음을 나타내는 오류 메시지입니다.
테스트 사례 4:
입력: "1890-07-01"로 생년월일(매우 오래된 날짜)
예상 출력: 나이는 "133세"
테스트 사례 5:
입력: "2023-06-08"로 생년월일(오늘 날짜)
예상 출력: 나이를 "0세"로
테스트 사례 6:
입력: 잘못된 형식(예: "2000/06/08")
예상 출력: 날짜 형식이 잘못되었음을 나타내는 오류 메시지입니다.
What are the types of errors that are not found through Blackbox testing but found through Whitebox testing? Be specific. : 화이트 박스에서만 발견되는 오류.
논리 오류: 시스템 논리 또는 알고리즘의 잘못된 구현으로 인해 발생하는 오류.
제어 흐름 오류: 이 오류는 코드 실행의 작업 순서와 관련이 있습니다(예: 루프 또는 조건부 분기).
변수 또는 데이터 유형 오류: 변수 또는 데이터 유형이 잘못 정의되거나 사용된 경우
3. 오류지수(EI)
A. Interpret the following metric for computing Error Index: 오류 지수를 구하기 위한 해석
EI = Σ(i * PI(i)) / PS
:품질을 측정하는 데 사용되는 소프트웨어 메트릭. 높으면 안좋아!
PI(i): Phase Index, phase 'i'에서 발견된 결함의 총 개수
PS: 프로젝트 크기, 프로젝트의 전체 크기 또는 규모를 나타내는 지표.
낮은 EI는 대부분의 결함이 초기 단계에서 발견된다는 것을 의미합니다. 이는 결함이 더 저렴하고 초기 단계에서 수정하기 쉽기 때문에좋은 것 입니다. EI가 높을수록 결함이 후기 단계에서 발견되고 있음을 의미하며, 이는 수리 비용이 높을 수 있음을 의미합니다.
B. Explain how to compute the Phase Index(PI): 계산 방법 설명
위상 지수(PI(i))는 일반적으로 특정 위상 'i'에서 발견된 총 결함 수로 계산됩니다.
이는 소프트웨어 개발 프로세스의 각 단계에서 발견된 모든 결함을 추적하고 계산하여 수행됩니다. 이들은 수동으로 추적하거나 결함 추적 소프트웨어의 도움을 받아 추적할 수 있습니다.
PI는 일반적으로 개발 프로세스의 각 단계에서 발견되는 모든 결함을 주의 깊게 추적하고 기록합니다.
이상적인 시나리오에서는 결함이 도입된 동일한 단계에서 결함을 포착하고 수정하므로 단계 지수는 각 단계의 품질 관리 효율성을 반영할 수 있습니다.
결함을 조기에 발견하고 수정할수록 비용이 적게 드는 경향이 있으므로 일반적으로 초기 단계에서 결함이 더 많이 발견되는 분포가 선호됩니다.
(프로젝트 관리) 기능 포인트 기반 추정
A. 함수 포인트에 대한 다음 공식을 자세히 해석합니다.
FP = Count_Total [0.65+0.01 sum(Fi)], i=1 ~ 14
-
기능 점수 분석은 사용자 관점에서 소프트웨어 개발을 측정하기 위한 표준화된 방법.
주요 목표: 소프트웨어 개발을 위한 노력, 비용 및 일정을 추정하는 메트릭을 제공 -
FP는 계산하려는 기능 점수 측정값입니다.
Count_Total은 식별된 모든 사용자 기능(예: 입력, 출력, 조회 등)의 총 개수이며 복잡도에 따라 가중치가 적용됩니다.
Fi는 소프트웨어의 복잡성(예: 성능, 유용성, 보안 등)에 영향을 미치는 요소인 일반 시스템 특성(GSC)입니다. 각 Fi는 소프트웨어 시스템에 미치는 영향의 정도에 따라 0에서 5까지의 값을 갖습니다.
sum(Fi) 항은 이러한 14가지 시스템 특성의 점수를 더한 것입니다.
[0.65 + 0.01 * sum(Fi)]는 값 조정 계수(VAF)로 알려져 있습니다. 시스템의 복잡성에 따라 조정되지 않은 기능 포인트 수(Count_Total)를 조정하는 데 사용됩니다.
B. FP 기반 추정의 장단점은 무엇인가요?
장점:
-
사용자 중심: 기능 점수는 사용자 관점에서 기능을 측정하므로 비기술적 이해 관계자가 더 쉽게 이해할 수 있습니다.
-
언어 독립적: 기능 점수 분석은 프로그래밍 언어, 방법론 및 사용된 기술과 독립적이므로 다목적 방법입니다.
-
표준화: 소프트웨어 산업에서 널리 인정되고 사용되는 표준화된 방법입니다.
단점:
-
주관성: 사용자 기능의 분류 및 가중치는 주관적일 수 있으며 평가자마다 다를 수 있습니다.
-
교육 필요: 기능 점수 분석을 효과적으로 적용하려면 비용이 많이 드는 교육과 경험이 필요합니다.
-
복잡성: 기능 점수 계산 프로세스는 LOC(Lines of Code)와 같은 다른 방법에 비해 상대적으로 복잡합니다.
Use Case/Object/Dynamic Model 간의 Consistency 에 대해 설명하시오.
유스 케이스 모델: 사용자 관점에서 시스템의 기능적 요구 사항을 정의하는 모델입니다.
액터에게 측정 가능한 가치를 제공하는 목표를 달성하기 위해 변형을 포함한 일련의 작업 측면에서 시스템의 동작을 설명합니다. 사용 사례는 종종 시스템의 다른 측면 설계를 위한 기초로 사용됩니다.
개체 모델: 개체, 해당 속성 및 관계 측면에서 시스템의 정적 구조를 나타내는 모델입니다.
이 모델에서 식별된 클래스는 사용 사례에 관련된 엔터티와 상관관계가 있어야 합니다.
동적 모델: 이 모델은 시간 경과에 따른 시스템 동작을 나타냅니다. 시스템 상태의 변경 사항과 이러한 변경 사항을 유발하는 작업 순서를 캡처합니다.
이러한 모델 간에 일관성을 유지한다는 것은 모델이 정렬되고 서로 모순되지 않는다는 것을 의미합니다.
예를 들어 유스 케이스에 설명된 모든 액터와 액션은 객체 모델의 클래스와 메서드, 동적 모델의 상태 또는 전환에 해당해야 합니다.
이러한 일관성을 보장하면 시스템이 잘 정의되고 모든 요구 사항이 설명되며 시스템 동작이 여러 관점에서 이해되도록 하는 데 도움이 됩니다.
Cyclomatic Complexity(순환 복잡도)
- 제어흐름도를 계산
- 루프, if에는 두 가지 경로
- 'n'개의 경우가 있는 스위치의 경우 순환 복잡도는 n+1
CC = 조건문 개수 + 1
CC = 결정 포인트 수(if, while, for, case 등) + 1(직선)
