[2022년 정보처리기사 필기] 1. 소프트웨어설계: Cp1. 요구사항 확인2

2022년 정보처리기사 필기

(수제비 2021년 필기책 보고 공부하며 요약한 내용입니다.)

http://www.yes24.com/Product/Goods/96051171

 

1. 소프트웨어 설계

Cp1. 요구사항 확인2

 

 

---

 

1. 요구분석이란?

: 요구사항 상충을 해결하고 소프트웨어의 범위 파악해 외부환경과의 상호작용을 분석하는 과정

: 요구사항중 불명확하거나 이해되지 않는 부분 발견하고 이를 걸러내기 위한 과정

: 문서화를 통해 향후 유지보수에 유용하게 활용할 수 있음

: 구체적 명세 위해 소단위 명세서가 활용될 수 있음

*소단위 명세서: 데이터 흐름도에 있는 처리 항목을 소규모 분량으로 요약하여 작성하는 논리적 명세서

 

1-1. 요구사항 분석 단계 

1) 요구사항 분류

: 요구사항이 기능인지 비기능인지 확인

: 요구사항이 소프트웨어에 미치는 영향 범위 파악

: 요구사항이 소프트웨어 생명주기 동안 변경이 발생하는지 확인

2) 개념모델링 생성 및 분석

: 현실세계를 단순화, 개념적으로 표현하여 모델을 만듦

 (객체모델, 데이터모델, 유스케이스다이어그램, 데이터흐름모델, 상태모델, 목표기반모델, 사용자인터렉션 등)

3) 요구사항 할당

: 아키텍처 구성요소 식별

: 다른 구성요소와의 상호작용 분석으로 추가적인 요구사항 발견 가능

4) 요구사항 협상

: 우선순위 부여해 문제 요구사항 상충 문제해결

5) 정형 분석

: 형식적으로 정의된 언어로 요구사항을 표현

: 구문(syntax)과 의미(semantics)를 갖는 정형화된 언어 사용하여 수학적 기호로 표현

 

1-2. 요구사항 분석 기술

분석 기술	설명
청취	이해관계자로부터 의견 듣기
인터뷰와 질문	이해관계자를 만나 정보수집하고 이야기 나누기
분석	요구사항 충돌, 중복, 누락 분석 통해 완전성, 일관성 확보
중재	상반된 요구 중재
관찰	작업을 관찰하며 사용자가 언급하지 않은 미묘한 의미 탐지
작성	문서 작성
조직	수집된 정보를 일관성 있는 정보로 구조화하는 능력
모델 작성	수집된 정보를 바탕으로 제어흐름, 기능처리, 동작행위, 정보내용 등을 이해하기 쉽도록 모델로 작성

 

1-3. 요구사항 분석에 사용하는 기능 모델링 기법

1) 데이터 흐름도(DFD)

: 데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타냄

: 시스템 분석 및 설계에서 매우 유용하게 사용되는 다이어그램

: 시스템 모델링 도구로서 가장 보편적으로 사용됨

: 자료 흐름 그래프 또는 버블차트라고도 함.

: 구조적 분석 기법에 이용됨

: 제어의 흐름은 중요하지 않으며, 데이터의 흐름에 중심을 두는 분석용 도구임.

: 시간 흐름을 명확하게 표현할 수 없음

- 데이터흐름도 구성요소

구성요소	설명
처리기(프로세스)	입력된 데이터를 원하는 형태로 변환하여 출력하기 위한 과정으로, DFD에서는 원(ㅇ)으로 표시
데이터흐름	DFD 구성요소(프로세스, 데이터저장소, 외부엔터티)들 간 주고받는 데이터 흐름을 나타내며, DFD에서 화살표(->)로 표시
데이터 저장소	평생선(=)으로 표시. 평행선 안에는 데이터 저장소의 이름을 넣음
단말(terminator)	프로세스 처리 과정에서 데이터가 발생하는 시작과 종료를 나타내고, 사각형으로 표시하며, 사각형 안에는 외부 엔터티의 이름을 넣음

 

2) 자료사전

: 자료요소, 자료요소들의 집합, 자료의 흐름, 자료 저장소의 의미, 관계 등을 구체적으로 명시하는 사전

: 파일 혹은 DB에 있는 자료에 대한 자료 또는 각 자료에 주어진 이름. 길이 등 포함하는 참조를 위한 작업임

: 용어의 정의를 조정하고 취합하고 문서로 명확히 하는 목적이 있음.

자료사전 기호	의미
=	자료의 정의로서, '~으로 구성되어있다'를 나타냄 정의는 주석을 사용하여 의미를 기술하며, 자료 흐름과 자료저장소에 대한 구성내역을 설명하고, 자료 원소에 대해 값이나 단위를 나타냄
+	자료의 연결을 나타냄
()	자료의 생략 가능함을 나타냄
{}	자료의 반복을 나타냄 좌측에 최소반복횟수, 우측에 최대 반복횟수 기록 반복횟수 기록하지 않을 때는 디폴트로 최소0, 최대 무한대
[]	자료의 선택을 나타냄 택일 기호 [ | ]는 |로 분리된 항목 중 하나가 선택됨
**	자료의 설명(의미)을 나타냄 (주석)

- 자료 사전 작성 원칙

 (1) 자료 의미 기술

   : 자료 의미는 주석을 통해 기술

   : 자료 의미 기술 시 그 자료가 대상 시스템에서 사용되는 적합한 뜻을 표현해야 함

   : 중복되는 기술을 회피하는 것은 간결하고 이해 쉬운 자료 사전을 작성하는 데 중요함

 (2) 자료 구성항목의 기술

   : 구성항목들을 그룹으로 묶음

   : 각 그룹에 대해 의미 있는 이름을 부여

   : 이름이 붙여진 각 그룹을 다시 정의

(3) 동의어 규정 준수

   : 사용자마다 동일한 문서나 자료에 대해 서로 다른 이름을 갖고 있을 수 있으며,

    사용자들의 용어를 통일 시키는 것 보다는 사용하는 용어를 이용하여 자료를 정의하는 것이 간단함

   : 분석가가 자료를 하향식 분할하는 과정에서 부주의하게 동의어를 사용할 수 있음

(4) 자료 정의의 중복 제거

   : 동일한 자료에 대해 여러 명의 분석가가 독립적으로 분석을 시행한다면,

     서로 다른 이름을 사용할 수 있기 때문에 자료 정의 중복 제거 필요

 

2. UML (Unified Modeling Language)

: 객체지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어.

: 방법론을 통합한 것으로, 표준화된 모델링 기법을 제공

UML의 특징	설명
가시화 언어	개념 모델 작성 시 오류가 적고 의사소통이 용이
구축 언어	다양한 프로그래밍언어로 실행 시스템의 예측 가능 UML을 소스코드로 변환하여 구축 가능, 역변환하여 역공학 가능
명세화 언어	정확한 모델 제시, 완전한 모델 작성 가능
문서화 언어	시스템에 대한 평가 및 의사소통의 문서

 

2-1. UML 구성요소

1) 사물(Things): 추상적 개념으로 주제를 나타내는 요소.

2) 관계(Relationships): 사물의 의미를 확장하고 명확히하는 요소. 사물과 사물을 연결하여 관계를 표현

3) 다이어그램: 사물과 관계를 모아 그림으로 표현하며, 형식과 목적에 따라 9가지로 정의.

 

2-2. UML 다이어그램

: 구분에 따라 구조적(정적) 다이어그램, 행위적(동적) 다이어그램으로 구분됨.

UML 다이어그램 구분	다이어그램	설명
구조적 다이어그램/정적 다이어그램	클래스	속성과 동작으로 구성 시스템 구조 파악하고 구조상 문제점 도출가능
	객체	클래스에 속한 객체들, 즉 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현 객체 인스턴스를 나타내는 대신 실제 클래스를 사용 연관된 모든 인스턴스를 표현
	컴포넌트	코드 컴포넌트 기반의 물리적 구조 표현 실질적 프로그래밍 작업에 사용
	배치(deployment)	컴포넌트 사이의 종속성을 표현 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
	복합체 구조(composite structure)	클래스, 컴포넌트가 복합구조를 갖는 경우 그 내부 구조를 표현
	패키지	유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현
행위적 다이어그램/동적 다이어그램	유스케이스	사용자 관점에서 시스템의 활동을 표현 시스템 기능적 요구 정의에 활용
	시퀀스	객체 간 상호작용을 메시지 흐름으로 표현 객체사이 메시지를 보내는 시간을 표현
	커뮤니케이션	시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고 받는 메시지를 표현하는데, 메시지 뿐만 아니라 객체 간의 연관까지 표현
	상태(state)	객체가 자신이 속한 클래스의 변화 혹은 타 객체와의 상호작용에 따른 상태변화를 표현. 모든 가능한 상태와 전이를 표현 진입조건, 탈출조건, 상태전이 등 기술
	활동(activity)	시스템이 어떤 기능을 수행하는지 객체의 처리로직, 조건처리흐름으로 순서대로 표현 활동의 순서대로 흐름을 표현
	타이밍	객체 상태변화와 시간 제약을 명시적으로 표현

 

2-3. UML 상세

1) 클래스 다이어그램

객체지향 모델링 시 클래스의 속성 및 연산과 클래스 간 정적인 관계를 표현한 다이어그램

클래스이름 person

속성 age: int

연산 getAge: int

구성요소: 클래스이름, 속성, 연산, 접근 제어자

*접근제어자: 클래스에 접근할 수 있는 정도를 표현

    - : 클래스 내부접근만 허용(private)

    +: 클래스 외부접근을 허용(public)

    #: 동일 패키지, 파생 클래스에서 접근 가능(protected)

    ~: 동일 패키지 클래스에서 접근 가능(default)

 

2) 유스케이스 다이어그램

:시스템이 제공하는 있는 기능 및 관련 외부요소를 사용자 관점에서 표현

유스케이스 다이어그램 구성요소	설명
유스케이스	시스템이 재공하는 서비스 액터가 시스템을 통해 수행하는 행위
액터	사용자가 시스템에 대해 수행하는 역할 시스템과 상호작용하는 사람 또는 사물
시스템	전체 시스템의 영역을 표현

3) 시퀀스 다이어그램

: 객체 간 상호작용을 메시지 흐름으로 표현한 다이어그램

https://ko.wikipedia.org/wiki/%EC%8B%9C%ED%80%80%EC%8A%A4_%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8

시퀀스 다이어그램 구성요소	설명
객체	객체 위쪽에 표시. 아래로 생명선을 가짐
생명선	객체로부터 뻗어나가는 점선 시간이 흐름에 따라 객체 생명주기 동안 발생하는 이벤트를 명시
실행	직사각형은 오퍼레이션(함수)이 실행되는 시간 직사각형이 길어질수록 수행시간이 긺
메시지	객체간 상호작용은 메시지 교환으로 이루어짐 한객체에서 다른 객체로의 메시지 전달하여 전달받은 객체의 오퍼레이션을 수행

- UML의 관계

: 사물과 사이 연관성 표현

: 연관관계, 집합관계, 포함관계, 일반화관계, 의존관계, 실체화 관계 등이 있음.

(1) 연관관계(association)

  : 2개 이상의 사물이 서로 관련된 상태를 표현

  : 사물 사이를 실선으로 연결하여 표현하며, 방향성은 화살표로 표현

  : 서로 영향을 주는 양방향관계인 경우 화살표 생략하고 실선으로만 연결

(2) 집합관계(aggregation)

  : 한 사물이 다른 사물에 포함된 관계 표현

  : 포함한 부모쪽에 속이 빈 마름모를, 포함된 자식쪽으로 화살표를 연결하여 표현

(3) 포함관계(composition)

   : 집합관계의 특수형태. 포함하는 사물의 변화가 포함되는 사물에 영향을 미침

   : 포함한 부모쪽에 속이 채워진 마름모를, 포함된 자식쪽으로 화살표를 연결

(4) 일반화관계

   : 한 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현

   : 일반적인 개념=부모(상위), 구체적인 개념=자식(하위). 자식에서 부모쪽으로 속이빈 화살표를 연결

(5) 의존관계

   : 사물 사이 서로 연관은 있으나 필요에 따라 서로 영향 주는 짧은 시간동안만 연관을 유지하는 관계를 표현

   : 사물 변화가 다른 서물에도 영향을 줌

   : 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결하여 표현

(6) 실체화관계(realization)

   : 사물이 할수있거나, 해야하는 기능(행위, 인터페이스)으로 서로를 그룹화할 수 있는 관계를 표현

   : 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현

 

2-4. UML 확장 모델의 스테레오 타입

: UML의 기본 요소 이외 새로운 요소를 만들어 내기 위한 확장 메커니즘

: 형태는 기존 UML 요소를 그대로 사용하나, 내부 의미는 다른 목적으로 사용함.

: 스테레오 타입은 '<<>>' (길러멧) 기호를 사용하여 표현함

(1) <<include>> : 한 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계

    ex) 고객이 제품 주문시 --> 사용자를 확인

(2) <<extend>> : 한 유스케이스가 어떤 시점에 다른 유스케이스를 실행할수도, 안할수도 있는 확장 관계

    ex) 고객이 제품 주문시 --> 고객 등록

(3) <<interface>> : 모든 메소드가 추상메소드이며, 바로 인스턴스를 만들지못함. 추상메소드와 상수로 구성된 클래스

(4) <<entity>> : 정보 또는 오래 지속되는 연관된 행위를 형상화하는 클래스로 유스케이스 처리 흐름이 수행되는 과정에서 기억 장치에 저장되어야 할 정보를 표현하는 클래스 

(5) <<boundary>> : 시스템과 외부 액터와의 상호작용을 담당하는 클래스

(6) <<control>> : 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스

 

https://stackoverflow.com/questions/683825/in-uml-class-diagrams-what-are-boundary-classes-control-classes-and-entity-cl

 

 

3. 애자일(Agile) 방법론

: 소프트웨어 개발방법론의 하나로, 개발과 함께 즉시 피드백을 받아 유동적으로 개발하는 방법

http://fpost.co.kr/board/bbs/board.php?wr_id=122&amp;bo_table=special

 

: Discover -> Design -> Develop -> Test -> .... 연속

 

3-1. 애자일 방법론 등장 배경

: 기존 개발방법론의 한계 극복 위함

등장배경	설명
소프트웨어 개발 환경 변화	소프트웨어 개발 트렌드가 모바일 환경으로 변화 시장 적시성과 잦은 배포의 중요성 부각
기존 개발방법론의 한계	전통적 방법론은 문서와 절차 위주로, 변화에 신속한 대응이 어려움 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성 증가

 

3-2. 애자일 방법론의 특징

: 요구사항은 기능 중심으로 정의함

: 절차와 도구보다 개인소통을 중요하게 생각함

: 작업 계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응

: 소프트웨어가 잘 실행되는데에 가치를 둠

: 고객과의 피드백을 중요시 생각함

 

3-3. 애자일 방법론 유형

애자일 방법론의 유형	내용
XP (eXtreme Programming)	의사소통 개선과 즉각 피드백으로 소프트웨어 품질을 높이기 위한 방법론 1~3주의 반복 개발 주기 5가지 가치와 12개의 실천항목이 존재 *XP 5가지 가치 1. 용기: 용기갖고 자신감있게 개발 2. 단순성: 필요한것만하고 그이상의 것은 하지 않음 3. 의사소통 4. 피드백: 의사소통에 대한 빠른 피드백 5. 존중: 팀원간 존중 *XP 12가지 기본원리 1. pair programming : 개발자 둘이서 짝으로 코딩 2. 공동코드소유(collective ownership) : 시스템에 있는 코드는 누구든지 언제라도 수정 가능 3. 지속적인통합(CI: continuous integration) : 매일 여러번씩 소프트웨어를 통합하고 빌드 4. 계획 세우기(planning process) : 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 함 5. 작은릴리즈 : 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트 6. 메타포어 : 공통적 이름 체계와 시스템 서술서를 통해 고객과 개발자 간 의사소통을 원할하게 함 7. 간단한 디자인 : 현재 요구사항에 적합한 가장 단순한 시스템을 설계 8. 테스트기반개발(TDD) : 테스트를 먼저 수행하고 통과할 수 있도록 코드작성 9. 리팩토링 : 프로그램 기능 안바꾸고, 중복제거, 단순화 등 시스템 재구성 10. 40시간 작업 : 피곤으로 실수하지 않도록 1주에 40시간 이상 일하지않음 11. 고객상주 : 개발자 질문에 즉각 대답하는 고객을 풀타임으로 상주 12. 코드표준 : 효과적인 공동작업 위해 모든 코드에 대한 코딩 표준을 정의
스크럼(SCRUM)	매일 정해진 시간, 같은 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론 *주요 개념 1. 백로그: 제품과 프로젝트에 대한 요구사항 2. 스프린트: 2~4주의 짧은 개발 기간으로 반복수행으로 개발품질 향상 3. 스크럼 미팅: 매일 15분 정도 미팅으로 투두리스트 계획수립 = 데일리미팅 4. 스크럼마스터: 프로젝트 리더, 스크럼 수행 시 문제 인지 및 해결자 5. 스프린트 회고(retrospective): 스프린트 주기를 되돌아보며 규칙 준수 여부, 개선점 등 확인 및 기록.  6. 번다운 차트: 백로그 대비 시간을 그래픽적으로 표현 보통 수직축에 위치하며 시간은 수평축에 위치
린(LEAN)	도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비요소를 제거하여 품질을 향상시킨 방법론 JIT(just in time), 칸반 보드 사용 *7가지 원칙 1. 낭비제거 2. 품질 내재화 3. 지식 창출 4. 늦은 확정 5. 빠른 인도 6. 사람 존중 7. 전체 최적화

 

3-4. 애자일과 전통적 방법론 비교

비교 대상	애자일 방법론	전통적 방법론
계획수립	유동적 범위 설정	확정적 범위 설정
업무수행	팀 중심	관리자 주도적 명령과 통제 개인 단위로 업무 수행
개발/검증	반복 주기 단위로 SW 개발, 검증	분석/설계/구현/테스트를 순차적 수행
팀관리	업무 몰입, 팀 평가	경쟁, 개별 평가
문서화	문서화보다 코드 강조	상세한 문서화 강조
성공요소	고객 가치 전달	계획/일정 준수
유형	XP, 스크럼, 린	폭포수, 프로토타입, 나선형