정보처리기사- 1과목 소프트웨어 설계 . 1. 요구사항 확인-2. 요구사항 확인

목차

 

1. 요구분석기법

<요구사항>

소프트웨어가 어떤 문제를 해결하기 위해 제공하는 서비스에 대한 설명 & 정상적으로 운영되는데 필요한 제약조건

유형	기능적 요구사항	비기능적 요구사항
내용	- 기능 - 입출력, 연산	- 시스템 장비 구성 - 성능 (처리속도, 처리시간, 처리량, 동적정적 적용량, 가용성) - 인터페이스 -데이터 -테스트 -보안 -품질 -제약사항 -프로젝트 관리 프로젝트 지원

 

<요구공학>

개발 대상에 대한 요구사항을 체계적으로 도출하고 이를 분석한 후 분석 결과를 명세서)에 정리한 다음 마지막으로 이를 확인 및 검증하는 총체적인 접근 체계

 

도출(Elicitation) >> 분석(Analysis) >> 명세(Specification) >> 확인(Validation)

 

<요구공학의 필요성>

1. 요구사항 분석의 어려움

   개발자와 사용자 간의 지식이나 표현의 차이가 커서 상호 이해가 쉽지 않음.

  사용자의 요구사항이 모호하고 불명확.

2. 요구사항과 기대의 차이

  3.  요구사항 변화 관리의 어려움

    소프트웨어 개발 중에 요구사항이 계속 변할 수 있다(요구사항 변경과 추적문제)

 

<요구사항 개발 프로세스/ 요구공학 프로세스>

	내용	기법
1. 도출(Elicitation)	서로 의견교환 >> 요구사항 식별 및 이, 분류, 우선순위 설정	청취와 인터뷰, 설문, 브레인스토밍, 워크샵, 프로토타이핑, 유스케이스
2. 분석(Analysis)	- 요구사항 분석 및 문서화 - 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 걸러내는 과정	자료 흐름도(DFD), 자료 사전(DD)
3. 명세(Specification)	분석된 요구사항을 바탕으로 모델을 작성, 문서화.	구체적 명세 >> 소단위명세서(Mini-Spec)
4. 확인(Validation)	요구사항 명세서 검토 밒 평가

 

<요구사항 분석>

- 소프트웨어 개발의 실질적(실제적)인 첫 단계

- 사용자의 요구사항을 이해하고 문서화하는 활동

-사용자 요구의 타당성을 조사하고 비용과 일정에 대한 제약을 설정.
• 사용자의 요구를 정확하게 추출하여 목표 설정 >> 어떠한 방식으로 해결할 것인지 결정.

 

<요구사항 명세 기법>

	정형 명세	비정형 명세
개념	수학적 기호 이용	자연어 기반
기법	수학적 원리, 모델 기	상태/기능/객체 중심
장점	정확하고 간결함 일관적인 표현	이해하기 쉬움 다양하게 전달 가능
단점	표기의 어려움	해석의 모호성 일관성이 떨어지고 불충분한 명세
종류	- VDM  ( 모델) - Z (집합,논리, 모델) - Petri-net (끄래프 표기) - CSP CCS.. (대수적)	FSM, Decision Table,  ER모델링,  State Chart(SADT) 유스케이

<기출문제>

Q. 요구사항 개발 프로세스의 순서로 옳은 것은? (2021.05.15 기출 #3)  

   ① ㉠ - ㉡ - ㉢ - ㉣  ② ㉠ - ㉢ - ㉡ - ㉣

   ③ ㉠ - ㉣ - ㉡ - ㉢  ④ ㉠ - ㉡ - ㉣ - ㉢

 

Q. 요구사항 분석에서 비기능적(Nonfunctional) 요구에 대한 설명으로 옳은 것은? (2022.04.24 기출 #5)

   ① 시스템의 처리량(Throughput), 반응 시간 등의 성능 요구나 품질 요구는 비기능적 요구에 해당하지 않는다.

   ② '차량 대여 시스템이 제공하는 모든 화면이 3초 이내에 사용자에게 보여야 한다'는 비기능적 요구이다.

   ③ 시스템 구축과 관련된 안전, 보안에 대한 요구사항들은 비기능적 요구에 해당하지 않는다.

   ④ '금융 시스템은 조회, 인출, 입금, 송금의 기능이 있어야 한다'는 비기능적 요구이다.

 

Q. 요구 사항 명세기법에 대한 설명으로 틀린 것은? (2020.09.26 기출 #15)

    ① 비정형 명세기법은 사용자의 요구를 표현할 때 자연어를 기반으로 서술한다.

    ② 비정형 명세기법은 사용자의 요구를 표현할 때 Z 비정형 명세기법을 사용한다.

    ③ 정형 명세기법은 사용자의 요구를 표현할 때 수학적인 원리와 표기법을 이용한다.

    ④ 정형 명세기법은 비정형 명세기법에 비해 표현이 간결하다.

 

Q. 요구사항 분석이 어려운 이유가 아닌 것은? (2021.05.15 기출 #7)

   ① 개발자와 사용자 간의 지식이나 표현의 차이가 커서 상호 이해가 쉽지 않다.

   ② 사용자의 요구는 예외가 거의 없어 열거와 구조화가 어렵지 않다.

   ③ 사용자의 요구사항이 모호하고 불명확하다.

   ④ 소프트웨어 개발 과정 중에 요구사항이 계속 변할 수 있다.

 

Q. 요구사항 분석 시에 필요한 기술로 가장 거리가 먼 것은? (2020.08.22 기출 #1)

   ① 청취와 인터뷰 질문 기술 ② 분석과 중재기술

   ③ 설계 및 코딩 기술 ④ 관찰 및 모델 작성 기술

 

Q. 소프트웨어 개발 방법 중 요구사항 분석(requirements annalysis)과 거리가 먼 것은? (2020.06.06 기출 #13)

    ① 비용과 일정에 대한 제약설정 ② 타당성 조사

    ③ 요구사항 정의 문서화     ④ 설계 명세서 작성

 

Q. 소프트웨어 설계에서 요구사항 분석에 대한 설명으로 틀린 것은? (2022.03.15 기출 #3)

   ① 소프트웨어가 무엇을 해야하는가를 추적하여 요구사항 명세를 작성하는 작업이다.

   ② 사용자의 요구를 추출하여 목표를 정하고 어떤 방식으로 해결할 것인지 결정하는 단계이다.

   ③ 소프트웨어 시스템이 사용되는 동안 발견되는 오류를 정리하는 단계이다.

   ④ 소프트웨어 개발의 출발점이면서 실질적인 첫 번째 단계이다.

 

Q. 요구 분석(Requirement Analysis)에 대한 설명으로 틀린 것은? (2021.08.14 기출 #7)

   ① 요구 분석은 소프트웨어 개발의 실제적인 첫 단계로 사용자의 요구에 대해 이해하는 단계라 할 수 있다.

   ② 요구 추출(Requirement Elicitation)은 프로젝트 계획 단계에 정의한 문제의 범위 안에 있는 사용자의 요구를 찾는 단계이다.

   ③ 도메인 분석(Domain Analysis)은 요구에 대한 정보를 수집하고 배경을 분석하여 이를 토대로 모델링을 하게 된다.

   ④ 기능적(Functional) 요구에서 시스템 구축에 대한 성능, 보안, 품질, 안정 등에 대한 요구사항을 도출한다.

 

Q. 소프트웨어 개발 단계에서 요구 분석 과정에 대한 설명으로 거리가 먼 것은? (2020.09.26 기출 #16)

    ① 분석 결과의 문서화를 통해 향후 유지보수에 유용하게 활용 할 수 있다.

    ② 개발 비용이 가장 많이 소요되는 단계이다.

    ③ 자료흐름도, 자료 사전 등이 효과적으로 이용될 수 있다.

    ④ 보다 구체적인 명세를 위해 소단위 명세서(Mini-Spec)가 활용될 수 있다.

 

Q. 요구사항 검증(Requirements Validation)과 관련한 설명으로 틀린 것은? (2021.08.14 기출 #1)

   ① 요구사항이 고객이 정말 원하는 시스템을 제대로 정의하고 있는지 점검하는 과정이다.

   ② 개발완료 이후에 문제점이 발견될 경우 막대한 재작업 비용이 들 수 있기 때문에 요구사항 검증은 매우 중요하다.

   ③ 요구사항이 실제 요구를 반영하는지, 문서상의 요구사항은 서로 상충되지 않는지 등을 점검한다.

   ④ 요구사항 검증 과정을 통해 모든 요구사항 문제를 발견할 수 있다.

 

Q. 요구사항 관리 도구의 필요성으로 틀린 것은? (2021.05.15 기출 #17)

    ① 요구사항 변경으로 인한 비용 편익 분석

    ② 기존 시스템과 신규 시스템의 성능 비교

    ③ 요구사항 변경의 추적

    ④ 요구사항 변경에 따른 영향 평가

2. UML

<UML (Unified Modeling Language)>

시스템 개발 과정에서 의사소통이 원활하게 이루어지도록 표준화한 대표적 객체지향 모델링 언어

- Rumbaugh(OMT), Booch, Jacobson 등의 객체지향 방법론의 장점을 통합

- 구성요소 : UML의 구성 요소에는 사물(Things), 관계(Relationships), 다이어그램(Diagram)

 

사물 (Things)
관계 (Relationships)	연관(Association)	사물이 서로 관련
	집합(Aggregation)	하나의 사물이 다른 사물에 포함
	포함(Composition)	포함하는 사물의 변화가 포함되는 사물에게 영향을 주는 관계
	일반화(Generalization)	일반적/구체적인지
	의존(Dependency)	한 사물의 명세가 바뀌면 다른사물에 영향을 주며, 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우에 나타나는 관계
	실체화(Realization)	사물 - 해야 하는 기능 - 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계
다이어그램 (Diagram)	구조적(Structural)  다이어그램 (6개)	클래스 다이어그램 (Class Diagram)	-구성 1. 클래스:      이름-속성(상태,정보)-오퍼레이션(수행동작) 2. 제약조건 3. 관계
		객체 다이어그램 (Object Diagram)
		컴포넌트 다이어그램 (Component Diagram)
		배치 다이어그램 (Deployment Diagram)
		복합체 구조 다이어그램 (Composite Structure Diagram)
		패키지 다이어그램 (Package Diagram)
	행위(Behavioral) 다이어그램 (7개)	유스케이스 다이어그램 (Use Case Diagram)	- 구성요소:    1.사용자(Actor) : 상호작용을 하는 모든 외부 요소 (사람 or 외부시스템)    2. 사용 사례(Use Case) :시스템이 액터에게 제공하는 서비스 또는 기능    3. 관계( 연관, 포함, 확장, 일반화)    4. 시스템
		순차 다이어그램 (시퀀스 다이어그램) (Sequence Diagram)	시스템이나 객체들이 주고받는 메시지를 표현 -구성요소: 행위자, 객체, 생명선, 메시지, 실행
		커뮤니케이션 다이어그램 (Communication Diagram)	작에 참여하는 객체들이 주고받는 메시지를 표현 메시지 + 객체들 간의 연관까지 표현
		상태 다이어그램 (State Diagram)
		활동 다이어그램 (Activity Diagram)
		상호작용 개요 다이어그램 (Interaction Overview Diagram)
		타이밍 다이어그램 (Timing Diagram)

 

 

<UML 확장 - 스테레오 타입(Stereotype)>

 

-겹화살괄호(⟪⟫) 사용

- 표기

<<include>> 연결된 다른 UML 요소에 대해 포함 관계
<<extend>> 연결된 다른 UML 요소에 대해 확장 관계
<<interface>> 인터페이스를 정의
<<exception>> 예외를 정의
<<constructor>> 생성자 역할을 수행

 

 

 

<기출문제>

1. UML 다이어그램 중 순차 다이어그램에 대한 설명으로 틀린 것은? (2022.04.24 기출 #1)

   ① 객체 간의 동적 상호작용을 시간 개념을 중심으로 모델링 하는 것이다.

   ② 주로 시스템의 정적 측면을 모델링하기 위해 사용한다.

   ③ 일반적으로 다이어그램의 수직 방향이 시간의 흐름을 나타낸다.

   ④ 회귀 메시지(Self-Message), 제어블록(Statement block) 등으로 구성된다.

 

8. 다음의 설명에 해당하는 언어는? (2022.03.15 기출 #8)

  

   ① JAVA ② C

   ③ UML ④ Python

 

2. UML 모델에서 한 사물의 명세가 바뀌면 다른사물에 영향을 주며, 일반적으로 한 클래스가 다른 클래스를 오퍼레이션의 매개변수로 사용하는 경우에 나타나는 관계는? (2021.08.14 기출 #2)

   ① Association  ② Dependency  ③ Realization  ④ Generalization

 

15. UML 모델에서 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계로 옳은 것은? (2021.05.15 기출 #15)

    ① Dependency ② Realization

    ③ Generalization ④ Association

 

14. 아래의 UML 모델에서 '차' 클래스와 각 클래스의 관계로 옳은 것은? (2020.08.22 기출 #14)

    

    ① 추상화 관계 ② 의존 관계

    ③ 일반화 관계 ④ 그룹 관계

--

 

Q . UML 다이어그램 중 정적 다이어그램이 아닌 것은? (2022.03.15 기출 #11)

    ① 컴포넌트 다이어그램 ② 배치 다이어그램

    ③ 순차 다이어그램 ④ 패키지 다이어그램

 

Q . UML 모델에서 사용하는 Structural Diagram 에 속하지 않은 것은? (2020.06.06 기출 #12)

    ① Class Diagram ② Object Diagram

    ③ Component Diagram ④ Activity Diagram

 

Q. UML에서 활용되는 다이어그램 중, 시스템의 동작을 표현하는 행위(Behavioral) 다이어그램에 해당하지 않는 것은? (2020.08.22 기출 #12)

    ① 유스케이스 다이어그램(Use Case Diagram)

    ② 시퀀스 다이어그램(Sequence Diagram)

    ③ 활동 다이어그램(Activity Diagram)

    ④ 배치 다이어그램(Deployment Diagram)

 

Q . UML 다이어그램이 아닌 것은? (2021.05.15 기출 #14)

    ① 액티비티 다이어그램(Activity diagram)

    ② 절차 다이어그램(Procedural diagram)

    ③ 클래스 다이어그램(Class diagram)

    ④ 시퀀스 다이어그램(Sequence diagram)

 

 

Q . UML(Unified Modeling Language)에 대한 설명 중 틀린 것은? (2021.03.07 기출 #12)

    ① 기능적 모델은 사용자 측면에서 본 시스템 기능이며, UML에서는 Use case Diagram을 사용한다.

    ② 정적 모델은 객체, 속성, 연관관계, 오퍼레이션의 시스템의 구조를 나타내며, UML에서는 Class Diagram을 사용한다.

    ③ 동적 모델은 시스템의 내부 동작을 말하며, UML에서는 Sequence Diagram, State Diagram, Activity Diagram을 사용한다.

    ④ State Diagram은 객체들 사이의 메시지 교환을 나타내며, Sequence Diagram은 하나의 객체가 가진 상태와 그 상태의 변화에 의한 동작순서를 나타낸다.

 

 

Q . UML 다이어그램 중 시스템 내 클래스의 정적 구조를 표현하고 클래스와 클래스, 클래스의 속성 사이의 관계를 나타내는 것은? (2021.03.07 기출 #19)

    ① Activity Diagram ② Model Diagram

    ③ State Diagram ④ Class Diagram

 

Q . UML의 기본 구성요소가 아닌 것은? (2020.09.26 기출 #11)

    ① Things ② Terminal

    ③ Relationship ④ Diagram

 

Q . UML에서 시퀀스 다이어그램의 구성 항목에 해당하지 않는 것은? (2020.08.22 기출 #6)

   ① 생명선 ② 실행

   ③ 확장 ④ 메시지

 

 

 

Q . UML 확장 모델에서 스테레오 타입 객체를 표현할 때 사용하는 기호로 맞는 것은? (2020.06.06 기출 #6)

   ① 《 》 ② (( ))

   ③ {{ }} ④ [[ ]]

 

 

 

----------------

Q . 유스케이스(Use Case)의 구성 요소 간의 관계에 포함되지 않는 것은? (2022.04.24 기출 #4)

   ① 연관 ② 확장

   ③ 구체화 ④ 일반화

 

Q . 유스케이스(Usecase)에 대한 설명 중 옳은 것은? (2021.05.15 기출 #2)

   ① 유스케이스 다이어그램은 개발자의 요구를 추출하고 분석하기 위해 주로 사용한다.

   ② 액터는 대상 시스템과 상호 작용하는 사람이나 다른 시스템에 의한 역할이다.

   ③ 사용자 액터는 본 시스템과 데이터를 주고받는 연동 시스템을 의미한다.

   ④ 연동의 개념은 일방적으로 데이터를 파일이나 정해진 형식으로 넘겨주는 것을 의미한다.

 

Q . 기본 유스케이스 수행 시 특별한 조건을 만족할 때 수행하는 유스케이스는? (2021.03.07 기출 #13)

    ① 연관 ② 확장

    ③ 선택 ④ 특화

 

Q . 유스케이스 다이어그램(Use Case Diagram)에 관련된 내용으로 틀린 것은? (2022.04.24 기출 #19)

    ① 시스템과 상호작용하는 외부시스템은 액터로 파악해서는 안된다.

    ② 유스케이스는 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술한다.

    ③ 시스템 액터는 다른 프로젝트에서 이미 개발되어 사용되고 있으며, 본 시스템과 데이터를 주고받는 등 서로 연동되는 시스템을 말한다.

    ④ 액터가 인식할 수 없는 시스템 내부의 기능을 하나의 유스케이스로 파악해서는 안된다.

 

--------------

Q . 클래스 다이어그램의 요소로 다음 설명에 해당하는 용어는? (2021.08.14 기출 #8)

   

   ① Instance ② Operation    ③ Item ④ Hiding

 

Q . 순차 다이어그램(Sequence Diagram)과 관련한 설명으로 틀린 것은? (2021.08.14 기출 #16)

    ① 객체들의 상호 작용을 나타내기 위해 사용한다.

    ② 시간의 흐름에 따라 객체들이 주고 받는 메시지의 전달 과정을 강조한다.

    ③ 동적 다이어그램보다는 정적 다이어그램에 가깝다.

    ④ 교류 다이어그램(Interaction Diagram)의 한 종류로 볼 수 있다.

3. 애자일(Agile)

< 애자일 방법론(Agile development)>

 절차보다 '사람' 중심
     - 프로세스 < 개인과의 상호작용
     - 문서 < 실행 소프트웨어
     - 계약 < 협업
     - 계획 < 변화에 반응
- 변화에 유연, 신속적응 경량개발, 효율적, 즉각적 피드백가능
- 폭포수모형과 대비됨

- 1) XP   2) 린(LEAN)   3) 스크럼(SCRUM)

 

 

XP (eXtreme Programmong)	-  요구사항에 유연하게 대응. 고객의 참여와 개발과정의 반복을 극대화 - 짧고 반복적인 개발 주기, 단순한 설계, 고객의 적극적인 참여. 빠른 개발 - XP의 5가지 핵심 가치 : 의사소통(Communication), 단순성(Simplicity), 용기(Courage), 존중(Respect), 피드백(Feedback) - XP의 12가지 기본원리 짝 프로그래밍 (Pair Programming) : 개발자 둘이서 짝으로 코딩 공동 코드 소유(Collective Ownership) : 시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리 지속적인 통합(CI; Continuous Integration) 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다 계획 세우기(Planning Process) :고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요 한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려 주어야 한다는 원리 작은 릴리즈(Small Release) :작은 시스템 먼저 만들고, 짧은 단위로 업데이트 메타포어(Metaphor) 공통적인 이름 체계와 시스템 서술서 >> 고객과 개발자 간의 의사소통을 원활 간단한 디자인(Simple Design) 현재의 요구사항에 적합한 가장 단순한 시스템을 설계 테스트 기반 개발(TDD; Test Driven Development) :프로그램 테스트를 먼저 수행 >> 이 테스트를 통과할 수 있도록 실제 프로그램의 코드 작성 리팩토링(Refactoring) :프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리 40시간 작업(40-Hour Work) :일주일에 40시간 이상을 일하지 않기 고객 상주 (On Site Customer) :개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리 코드 표준(Coding Standard) :코딩 표준을 정의
린(LEAN)
스크럼 (SCRUM)	- 팀 중심으로 개발 효율성을 높임 - 스크럼팀     1) 제품 책임자 (Product Owner / PO) . 요구사항을 책임지고 의사결정. 요구사항이 담긴 백로그(Back log)를 작성 및 우선순위 지정 .     2) 스크럼 마스터 (Scrum Master / SM) . 객관적 시각으로 조언 및 가이드 제시. 진행사항 점검 및 장애요소 논의 후 해결    3) 개발팀 (Development Team / DT) . PO와 SM을 제외한 모든 팀원 . - 스크럼 개발 프로세스 제품 백로그(요구사항 우선순위목록) →  스프린트 계획 회의 → 스프린트(2~4주) → 일일 스크럼 회의(매일 약 15분) → 스프린트 검토 회의 → 스프린트 회고

 

 

<기출문제>

 

Q. 애자일(Agile) 프로세스 모델에 대한 설명으로 틀린 것은? (2022.04.24 기출 #13)

    ① 변화에 대한 대응보다는 자세한 계획을 중심으로 소프트웨어를 개발한다.

    ② 프로세스와 도구 중심이 아닌 개개인과의 상호소통을 통해 의견을 수렴한다.

    ③ 협상과 계약보다는 고객과의 협력을 중시한다.

    ④ 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시한다.

 

Q . 다음 중 애자일(Agile) 소프트웨어 개발에 대한 설명으로 틀린 것은? (2022.03.15 기출 #2)

   ① 공정과 도구보다 개인과의 상호작용을 더 가치 있게 여긴다.

   ② 동작하는 소프트웨어보다는 포괄적인 문서를 가치 있게 여긴다.

   ③ 계약 협상보다는 고객과의 협력을 가치 있게 여긴다.

   ④ 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.

 

Q . 애자일(Agile) 기법 중 스크럼(Scrum)과 관련된 용어에 대한 설명이 틀린 것은? (2022.03.15 기출 #10)

    ① 스크럼 마스터(Scrum Master)는 스크럼 프로세스를 따르고, 팀이 스크럼을 효과적으로 활용할 수 있도록 보장하는 역할 등을 맡는다.

    ② 제품 백로그(Product Backlog)는 스크럼 팀이 해결해야 하는 목록으로 소프트웨어 요구사항, 아키텍처 정의 등이 포함될 수 있다.

    ③ 스프린트(Sprint)는 하나의 완성된 최종 결과물을 만들기 위한 주기로 3달 이상의 장기간으로 결정된다.

    ④ 속도(Velocity)는 한 번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치로 볼 수 있다.

 

Q . 애자일 개발 방법론과 관련한 설명으로 틀린 것은? (2021.08.14 기출 #14)

    ① 빠른 릴리즈를 통해 문제점을 빠르게 파악할 수 있다.

    ② 정확한 결과 도출을 위해 계획 수립과 문서화에 중점을 둔다.

    ③ 고객과의 의사소통을 중요하게 생각한다.

    ④ 진화하는 요구사항을 수용하는데 적합하다.

 

Q . 애자일 개발 방법론이 아닌 것은? (2021.05.15 기출 #18)

    ① 스크럼(Scrum)

    ② 익스트림 프로그래밍(XP, eXtreme Programming)

    ③ 기능 주도 개발(FDD, Feature Driven Development)

    ④ 하둡(Hadoop)

 

Q . 애자일 소프트웨어 개발 기법의 가치가 아닌 것은? (2021.03.07 기출 #18)

    ① 프로세스의 도구보다는 개인과 상호작용에 더 가치를 둔다.

    ② 계약 협상보다는 고객과의 협업에 더 가치를 둔다.

    ③ 실제 작동하는 소프트웨어보다는 이해하기 좋은 문서에 더 가치를 둔다.

    ④ 계획을 따르기보다는 변화에 대응하는 것에 더 가치를 둔다.

 

Q . 애자일 방법론에 해당하지 않는 것은? (2020.09.26 기출 #17)

    ① 기능중심 개발 ② 스크럼

    ③ 익스트림 프로그래밍 ④ 모듈중심 개발

 

Q . 애자일 기법에 대한 설명으로 맞지 않은 것은? (2020.08.22 기출 17 )

   ① 절차와 도구보다 개인과 소통을 중요하게 생각한다.

   ② 계획에 중점을 두어 변경 대응이 난해하다.

   ③ 소프트웨어가 잘 실행되는데 가치를 둔다.

   ④ 고객과의 피드백을 중요하게 생각한다.

 

Q . 익스트림 프로그래밍에 대한 설명으로 틀린 것은? (2022.04.24 기출 3 )

   ① 대표적인 구조적 방법론 중 하나이다.

   ② 소규모 개발 조직이 불확실하고 변경이 많은 요구를 접하였을 때 적절한 방법이다.

   ③ 익스트림 프로그래밍을 구동시키는 원리는 상식적인 원리와 경험을 최대한 끌어 올리는 것이다.

   ④ 구체적인 실천 방법을 정의하고 있으며, 개발 문서 보다는 소스코드에 중점을 둔다.

 

Q . 익스트림 프로그래밍 (XP)에 대한 설명으로 틀린 것은? (2021.08.14 기출 3 )

   ① 빠른 개발을 위해 테스트를 수행하지 않는다.

   ② 사용자의 요구사항은 언제든지 변할 수있다.

   ③ 고객과 직접 대면하며 요구사항을 이야기하기 위해 사용자 스토리(User Story)를 활용할 수 있다.

   ④ 기존의 방법론에 비해 실용성(Pragmatism)을 강조한 것이라고 볼 수있다.

 

Q . XP(eXtreme Programming)의 기본원리로 볼 수 없는 것은? (2020.09.26 기출 1)

   ① Linear Sequential Method ② Pair Programming

   ③ Collective Ownership ④ Continuous Integration

 

Q. XP(eXtreme Programming)의 5가지 가치로 거리가 먼 것은? (2020.06.06 기출 11)

    ① 용기 ② 의사소통

    ③ 정형분석 ④ 피드백