2020 기출 ' '
2021 기출 ' '
수제비 데일리 ' '
2. 요구사항 확인
(1) 요구분석 기법
요구분석이란?
- 요구분석은 도출된 요구사항 간 상충을 해결하고 소프트웨어의 범위를 파악하여 외부환경과의 상호작용을 분석하는 과정 *외부환경 : 시스템(소프트웨어)과 상호작용을 분석하는 과정
- 요구분석은 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
요구분석 기법
| 순서 | 절차 | 설명 |
| 1 | 요구사항 분류 | 기능 / 비기능 |
| 미치는 영향의 범위 | ||
| 상위 요구사항에서 유도된 것인지 또는 이해관계자나 다른 원천으로부터 직접 발생한 것인지 | ||
| 2 | 개념 모델링 생성 및 분석 |
모델 - 요구사항을 더 쉽게 이해할 수 있도록 현실 세계 상황을 단순화, 개념적으로 표현한 것 |
| 3 | 요구사항 할당 | 요구사항을 만족시키기 위한 아키텍처 구성요소를 식별하는 활동 |
| 4 | 요구사항 협상 | 적절한 지점에서 합의하기 위한 기법 |
| 요구사항이 충돌되는 경우 각각 우선순위를 부여하면 문제 해결에 도움이 됨 | ||
| 5 | 정형 분석 | 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현 |
| 구문(Syntax)과 의미(Semantics)를 갖는 정형화된 언어를 사용하여 수학적 기호로 표현 |
요구사항 분석 기술
청취 기술 / 인터뷰와 질문 기술 / 분석 기술 / 중재 기술 / 관찰 기술 / 작성 기술 / 조직 기술 / 모델 작성 기술
요구사항 분석에 사용하는 기능 모델링 기법
데이터 흐름도 (Data Flow Diagram; DFD)
- 데이터 흐름도는 데이터가 각 프로세스를 따라 흐르면서 변화되는 모습을 나타낸 그림
- 자료 흐름 그래프 또는 버블(Bubble) 차트라고도 함
데이터 흐름도 특징
- 구조적 분석 기법에 이용
- 데이터(Data)의 흐름에 중심을 둠, 제어(Control)의 흐름은 중요하지 않음
- 시간 흐름을 명확하게 표현할 수는 없다.
데이터 흐름도 구성요소
| 용어 | 설명 |
| 처리기 (Process) | 입력된 데이터를 원하는 형태로 출력하기 위한 과정, 원(O)으로 표시 |
| 데이터 흐름 (Data Flow) | DFD의 구성요소(프로세스, 데이터 저장소, 외부 엔터티)들 간의 주고받는 데이터 흐름, 화살표(→)로 표시 |
| 데이터 저장소 (Data Store) | 데이터가 저장된 장소이고, 평행선(=)으로 표시하며, 평행선 안에는 데이터 저장소의 이름을 넣음 |
| 단말 (Terminator) | 프로세스 처리과정에서 데이터가 발생하는 시작과 종료를 나타내고, 사각형(□)으로 표시하며, 사각형 안에는 외부 엔터티의 이름을 넣음 |
자료 사전(Data Dictionary; DD)
자료 사전은 자료 요소, 자료 요소들의 집합, 자료의 흐름, 자료 저장소의 의미와 그들 간의 관계, 관계 값, 범위, 단위들을 구체적으로 명시하는 사전
자료 사전의 작성 목적
조직에 속해 있는 다름 사람들에게 특정한 자료 용어가 무엇을 의미하는 지를 알려주기 위하여, 용어의 정의를 조정하고 취합하고 문서로 명확히 한다.
자료 사전 기호
| 기호 | 의미 |
| = | '~으로 구성되어 있다'는 것을 나타냄 (is Composed of) |
| + | 자료의 연결을 나타냄 (and, along with) |
| ( ) | 자료 생략 가능함을 나타냄 |
| { } | 자료의 반복을 나타냄 |
| [ ] | 자료의 선택을 나타냄 |
| ** | 자료의 설명을 나타냄, 주석(Comment) |
자료 사전의 작성 원칙
| 작성 원칙 | 설명 |
| 자료의 의미 기술 | 주석을 통해 기술 |
| 자료 구성항목의 기술 | 구성항목들을 의미 있는 이름을 부여하여 그룹으로 묶음 |
| 동의어 규정 준수 | 서로 다른 이름들을 갖고 있을 수 있음 용어 통일보다 자료 정의가 간단 |
| 자료 정의의 중복 제거 | 자료 정의 중복 제거 필요 |
(2) UML
UML (Unified Modeling Language) 개념
객체지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어
UML 특징 (가구명문)
| 특징 | 설명 |
| 가시화 언어 | 개념 모델 작성 시 오류가 적고 의사소통이 용이 |
| 구축언어 | 다양한 프로그래밍 언어로 실행 시스템의 예측 가능 |
| UML을 소스 코드로 변환하여 구축 가능, 역 변환하여 역공학 가능 | |
| 명세화 언어 | 정확한 모델 제시, 완전한 모델 작성 가능 |
| 문서화 언어 | 시스템에 대한 평가 및 의사소통의 문서 |
UML 구성 요소
- 사물 Things
- 관계 Relationships
- 다이어그램 Diagrams
UML 다이어그램 유형
UML 다이어그램은 구분에 따라 구조적(정적) 다이어그램, 행위적(동적) 다이어그램으로 구분된다.
구조적 다이어그램 (클객 컴배 복패) (=정적 다이어그램)
| 종류 | 설명 |
| 클래스 (Class) | 클래스, 클래스가 가지는 속성, 클래스 사이 관계 표현 |
| 객체 (Object) | 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현 |
| 컴포넌트 (Component) | 구현 단계에서 사용되며 컴포넌트 간의 관계나 인터페이스를 표현 |
| 배치 (Deployment) | 구현 단계에서 사용되며 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치 표현 |
| 복합체 구조 (Composite Structure) | 복잡한 구조를 가지는 클래스 혹은 컴포넌트의 내부 구조 표현 |
| 패키지 (Package) | 유스케이스나 클래스 등의 모델요소들을 그룹화한 패키지들의 관계 표현 |
클래스 다이어그램
객체 지향 모델링 시 클래스의 속성 및 연산과 클래스 간 정적인 관계를 표현한 다이어그램
클래스 다이어그램 구성요소
- 클래스 이름 (Class Name)
- 속성 (Attribute)
- 연산 (Operation)
- 접근 제어자 (접근 제한자)
클래스 다이어그램 접근 제어자
| - | 클래스 내부 접근만 허용 (private) |
| + | 클래스 외부 접근을 허용 (public) |
| # | 동일 패키지, 파생 클래스에서 접근 가능 (protected) |
| ~ | 동일 패키지 클래스에서 접근 가능 (default) |
행위적 다이어그램 (유시커 상활타) (=동적 다이어그램)
| 종류 | 설명 |
| 유스케이스 (Usecase) | 사용자의 요구를 분석하여 기능 모델링 작업에 사용 |
| 시퀀스 (Sequence) | 상호작용하는 시스템이나 객체들이 주고받는 메시지 표현 |
| 커뮤니케이션 (Communication) | 시퀀스 다이어그램과 같이 동작에 참여하는 객체들이 주고 받는 메시지를 표현하는데, 메시지 뿐만 아니라 객체 간의 연관까지 표현 |
| 상태 (State) | 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호작용에 따라 어떻게 변화하는지 표현 |
| 활동 (Activity) | 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현 |
| 타이밍 (Timing) | 객체 상태 변화와 시간 제약을 명시적으로 표현 |
유스케이스 다이어그램
시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자의 관점에서 표현하는 다이어그램
유스케이스 다이어그램 구성요소
- 유스케이스 (Usecase) : 시스템이 액터에게 제공해야 하는 기능으로, 시스템의 요구사항이자 기능을 의미
- 액터 (Actor) : 대상 시스템과 상호 작용하는 사람이나 다른 시스템에 의한 역할이다.
- 사용자 액터 : 기능을 요구하는 대상이나 시스템의 수행결과를 통보받는 사용자 혹은 기능을 사용하게 될 대상으로 시스템이 제공해야하는 기능인 유스케이스의 권한을 가지는 대상, 역할
- 시스템 액터 : 사용자 액터가 유스케이스를 처리해주는 외부 시스템, 시스템의 기능 수행을 위해서 연동이 되는 또다른 시스템 액터를 의미
- 시스템 (System)
시퀀스 다이어그램 구성 항목 (OLAM? 어람)
- 객체 (Object)
- 생명선 (Lifeline)
- 실행 (Activation)
- 메시지 (Message)
UML의 관계
| 구분 | 설명 | 예시 |
| 연관 관계 (Association) |
• 2개 이상의 사물이 서로 관련된 상태를 화살표 실선으로 연결하여 표현 • 양방향 관계의 경우 화살표를 생략하고 실선으로만 연결 |
 |
| 집합 관계 (Aggregation) |
• 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 속이 빈 마름모를 연결하여 표현 |  |
| 포함 관계 (Composition) |
• 집합 관계의 특수한 형태로, 포함하는 사물의 변화가 포함되는 사물의 영향에 미치는 관계를 표현 • 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 속이 채워진 마름모를 연결하여 표현 |
 |
| 일반화 관계 (Generalization) |
• 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현 • 일반적인 개념을 부모(상위)라고 하고, 구체적인 개념을 자식(하위)라고 함 • 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표를 연결하여 표현 |
 |
| 의존 관계 (Dependency) |
• 사물 사이에 서로 연관이 있으나 필요에 따라 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계를 표현 • 사물의 변화가 다른 사물에도 영향을 미치는 관계 • 영향을 주는 사물이 영향을 받는 사물 쪽으로 점선 화살표를 연결하여 표현 |
 |
| 실체화 관계 (Realization) |
• 사물이 할 수 있거나, 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현 • 한 객체가 다른 객체에게 오퍼레이션을 수행하도록 지정하는 의미적 관계 • 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현 |
 |
UML 확장 모델의 스테레오 타입 (Stereotype)
- UML의 기본적 요소 이외에 새로운 요소를 만들어 내기 위한 확장 메커니즘이다.
- 형태는 기존의 UML의 요소를 그대로 사용하지만 내부 의미는 다른 목적으로 사용하도록 확장한다.
- UML의 스테레오 타입은 '<<>>'(길러멧; Guillemet) 기호를 사용하여 표현한다.
| 타입 | 설명 | 예시 |
| <<include>> | 하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계 |  |
| <<extend>> | 하나의 유스케이스가 어떤 시점에 다른 유스케이스를 실행할 수도 있고, 그렇지 않을 수도 있는 확장 단계 |  |
| <<interface>> | 모든 메소드가 추상 메소드이며, 바로 인스턴스를 만들 수 없는 클래스로 추상 메소드와 상수만으로 구성된 클래스 |  |
| <<entity>> | 일반적으로 정보 또는 오래 지속되는 연관된 행위를 형상화하는 클래스로 유스케이스 처리 흐름이 수행되는 과정에서 기억 장치에 저장되어야 할 정보를 표현하는 클래스 |  |
| <<boundary>> | 시스템과 외부 엑터와의 상호작용을 담당하는 클래스 |  |
| <control>> | 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스 |  |
(3) 애자일 (Agile)
애자일 (Agile) 방법론은 소프트웨어 개발방법론의 하나로서 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법이다.
애자일 방법론 등장 배경
- 소프트웨어 개발 환경의 변화
- 기존 개발방법론의 한계
애자일 방법론 특징
- 프로젝트의 요구 사항은 기능 중심으로 정의한다.
- 절차와 도구보다 개인과 소통을 중요하게 생각한다.
- 작업 계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응할 수 있다.
- 소프트웨어가 잘 실행되는 데 가치를 둔다.
- 고객과의 피드백을 중요하게 생각한다.
애자일 선언문 (개변동고)
애자일 방법론을 실천하기 위한 주요 원칙이다.
- 공정과 도구보다 개인과 상호작용
- 계획을 따르기보다 변화에 대응하기
- 포괄적인 문서보다 동작하는 소프트웨어
- 계약 협상보다 고객과의 협력
애자일 방법론 유형
애자일 방법론은 대표적으로 XP, 린(Lean), 스크럼(SCRUM) 등이 있다.
| 종류 | 내용 | 개념 |
| XP (eXtreme Programming) |
의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
|
XP의 5가지 가치 (용단의 피존) 용기 / 단순성 / 의사소통 / 피드백 / 존중 XP의 12가지 기본원리 1. 짝 프로그래밍 (Pair Programming) 2. 공통 코드 소유 (Collective Ownership) 3. 지속적인 통합 (CI; Continuous Integration) 4. 계획 세우기 (Planning Process) 5. 작은 릴리즈 (Small Release) (작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리) 6. 메타포어 (Metaphor) (공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리) 7. 간단한 디자인 (Simple Design) 8. 테스트 기반 개발 (TDD; Test Driven Develop) 9. 리팩토링 (Refactoring) (프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리) 10. 40시간 작업 (40-Hour Work) (개발자가 일주일에 40시간 이상 일하지 말아야 한다는 원리) 11. 고객 상주 (On Site Customer) 12. 코드 표준 (Coding Standard) |
| 린 (Lean) |
도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
|
린의 7가지 원칙 (낭품지 확인사전) 낭비제거 / 품질 내재화 / 지식 창출 / 늦은 확정 / 빠른 인도 / 사람 존중 / 전체 최적화 |
| 스크럼 (SCRUM) |
매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론 | 백로그 (Backlog) : 제품과 프로젝트에 대한 요구사항 스프린트 (Sprint) : 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상 주요개념 백로그 / 스프린트 / 스크럼 미팅 / 스크럼 마스터 / 스프린트 회고 / 번 다운 차트 |
애자일과 전통적 방법론 비교
| 비교 대상 | 애자일 방법론 | 전통적 방법론 |
| 계획 수립 | 유동적 범위 설정 | 확정적 범위 설정 |
| 업무 수행 | 팀 중심 업무 수행 | 관리자 주도적 명령과 통제 개인 단위로 업무 수행 |
| 개발 / 검증 | 반복 주기 단위로 소프트웨어를 개발 / 검증 | 분석/ 설계/ 구현/ 테스트를 순차적으로 수행 |
| 팀관리 | 업무 몰입, 팀 평가 | 경쟁, 개발 평가 |
| 문서화 | 문서화보다는 코드를 강조 | 상세한 문서화를 강조 |
| 성공요소 | 고객 가치 전달 | 계획/ 일정 준수 |
| 유형 | XP, 스크럼, 린 | 폭포수, 프로토 타입, 나선형 |
3. 분석 모델 확인
(1) 모델링 기법
모델링(Modeling)이란?
모델링은 실세계의 물리 현상을 특정한 목적에 대응하여 이용하기 쉬운 형식으로 표현하는 기법
모델링의 역할
- 실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심
- 모델은 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명한다.
- 개념 모델은 문제 도메인의 엔터티(Entity)들과 관계 및 종속성을 반영한다.
모델링 절차 (요개논물)
| 순서 | 절차 | 설명 |
| 1 | 요구사항 분석 | 현행 데이터의 문제점과 개선해야 할 점을 확인하고 향후 개선점을 도출하는 활동 |
| 2 | 개념 모델링 | 업무 중심의 포괄적인 모델링으로 추상화하는 활동 ex) 엔터티 추출, 속성 및 관계 정의, ERD 작성 등 |
| 3 | 논리 모델링 | 관계, 속성, 키 등을 도출하는 활동 ex) 식별자 확정, 정규화 수행 등 |
| 4 | 물리 모델링 | 사용 DBMS 특성에 맞게 물리적 스키마를 만드는 활동 ex) 컬럼 데이터 타입, 제약 조건, 인덱스 정의 등 |
(2) 분석 자동화 도구
분석 자동화 도구의 개념
요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 요구사항 분석을 위한 자동화 도구
(CASE; Coputer Aided Software Engineering)이다.
특징
- 표준화 적용과 문서화를 통한 보고를 통해 품질 개선이 가능하다.
- 변경 사항과 변경으로 인한 영향에 대한 추적이 쉽다.
- 명세에 대한 유지보수 비용의 축소가 가능하다.
| 분석 자동화 도구 | 설명 |
| 상위 CASE (Upper CASE) | 계획 수립, 요구 분석, 기본 설계 단계를 다이어그램으로 표현 |
| 모델들 사이의 모순 검사 기능 | |
| 모델의 오류 검증 기능 | |
| 자료흐름도 작성 기능 | |
| 하위 CASE (Lower CASE) | 구문 중심 편집 지원 |
| 정적, 동적 테스트 지원 | |
| 시스템 명세서 생성 지원 | |
| 소스 코드 생성 지원 | |
| 통합 CASE (Integrated CASE) | SW 개발 주기 전체를 지원 |
분석 자동화 도구 주요 기능 (CASE 도구)
- 그래픽을 지원한다.
- 소프트웨어 생명주기의 전 단계를 지원한다.
- 다양한 소프트웨어 개발 모형을 지원한다.
- 표준화된 개발 환경 구축 및 문서 자동화 기능을 제공한다.
- 작업 과정 및 데이터 공유를 통해 작업자 간의 커뮤니케이션을 증대한다.
(3) 요구사항 관리 도구
요구사항 관리 도구의 개념
요구사항 관리 도구는 요구사항을 기반으로 프로젝트 관리, 설계, 개발, 테스트 등을 수행할 수 있는 역할을 지원하는 도구이다.
요구사항 관리 도구의 기능
| 구분 | 기능 | 설명 |
| 기본 기능 | 프로젝트 생성 | 프로젝트 타입 및 기본 모듈 템플릿 프로젝트 생성 및 재사용 가능 |
| 요구사항 작성 | 요구사항별 고유 ID, 식별자 사용 구분 | |
| 요구사항 불러오기/내보내기 | .doc .xls .html 등 다양한 확장자 제공 | |
| 핵심 기능 | 요구사항 이력 관리 | 요구사항별 변경 이력 관리 기능 제공 |
| 요구사항 베이스라인 | 요구사항 확정을 위한 베이스라인 제공 | |
| 요구사항 추적성 | 요구사항 이력 추적 가능 | |
| 부가 기능 | 협업 환경 | 요구사항 산출물의 동시편집 기능 제공 |
| 외부 인터페이스 | 형상 관리 도구(SVN, Git)와의 연동 지원 | |
| 확장성 | API 등을 통한 타 시스템 연동 제공 |
요구사항 관리 도구의 필요성
- 요구사항 변경으로 인한 비용 편익 분석
- 요구사항 변경의 추적
- 요구사항 변경에 따른 영향 평가
요구사항 관리 도구
| 구분 | 관리 도구 | 설명 |
| 상용 제품 | 헬릭스 RM | |
| 지라 (Jira) |
|
|
| 오르카노스 (Orcanos) | ||
| 리큐테스트 (ReQtest) | ||
| 오픈 소스 | 레드마인 (Redmine) |
|
| 테스트링크(Testlink) |
'정보처리기사 필기 > 소프트웨어 설계' 카테고리의 다른 글
| 1-4. 인터페이스 설계 (0) | 2021.07.22 |
|---|---|
| 1-3. 애플리케이션 설계 (0) | 2021.07.20 |
| 1-2. 화면 설계 (0) | 2021.07.15 |
| 1-1. 요구사항 확인 (1) (0) | 2021.07.08 |
댓글