목적
오늘 배운 부분 정리하고 복습하기 위해서 나중에 내가 봤을때 기억할 수 있게 정리한다.
1과목 소프트웨어 설계
요구사항 확인
요구공학 개요
소프트웨어 개발의 기초가 되는 요구사항을 정의하고, 문서화하고, 관리하는 프로세스이다.
이해관계자들에게 효과적인 소통 수단을 제공하고 불필요한 비용을 절감시킨다.
구조화된 요구사항으로 요구사항 변경 추적이 가능하며 요구사항 손실이 최소화된다.
요구공학 프로세스
요구공학 프로세스는 도출(Elicitation), 분석(Analysis), 명세(Specification), 검증(Validation)의 단계를 가진다.
요구사항 도출 -> 요구사항 분석 -> 요구사항 명세 -> 요구사항 검증
요구사항 도출
요구사항 소스
요구사항 도출 기법
요구사항 분석
요구사항 분류
개념 모델링
요구사항 할당
요구사항 협상
요구사항 명세
시스템 정의서
요구사항 명세서
요구사항 검증
요구사항 검토
모델 검증
인수 테스트
요구사항 관리 도구
요구사항 관리 도구 주요 기능
요구사항 변경에 따른 영향도 및 비용 편익의 분석이 가능하다.
요구사항이 변경된 이력을 추적할 수 있다.
요구사항을 조직적으로 관리하며 우선순위나 리스크 관리가 가능하다.
요구사항 관리 환경 조성 및 외부 협동, 협업 환경을 제공한다.
요구사항 도출(Requirement Eliciation)
소프트웨어가 해결해야 할 문제를 이해하는 첫 번째 단계로 요구사함을 어디에서, 어떻게 수집할 것인지를 결정하는 단계이다.
요구사항을 도출하는 과정에서 이해관계자가 식별되고, 개발자와 고객사이의 관계가 생성된다.
정확한 요구사항 도출을 위해 다양한 이해관계자들 간의 효율적인 의사소통이 중요하다.
요구사항 도출 기법
사용자 요구사항은 불명확하고 변할 수 있기 때문에 다양한 도출 기법을 사용해야 한다.
인터뷰: 다양하고 많은 사용자의 의견을 듣기 위해 계획하고 진행
설문: 이해관계자들의 관심, 내부 정보, 개선 의견을 끌어낼 문항 준비
사용자 스토리: 사용자, 개발자와 함께 시스템에 바라는 기능을 이야기 형태로 기술
업무절차 조사: 기업의 내부 표준, 업무 매뉴얼 등을 조사하여 요구 및 제한 사항 도출
브레인 스토밍 회의: 인터뷰와 함께 수행하여 최대한 많은 요구사항 수집, 훈련된 인원이 스토밍 진행
프로토타이핑: 예상 기능 일부를 빠르게 구현(프로토타입)하여 피드백 진행
유스케이스: 사용자 요구사항을 시스템 이용자와 기능, 관계로 표현
유스케이스(Use Case) 다이어그램
사용자와 다른 외부 시스템들이 목표 시스템을 이용하여 수행하는 기능을 사용자의 관점에서 표현한 도표이다.
시스템의 범위를 파악할 수 있고 외부 요소와 시스템 간의 상호 작용을 파악할 수 있다.
유스케이스 다이어그램 구성 요소
시스템 범위(scope): 관련 유스케이스들을 사각형으로 묶어서 표현
사용자(주) 액터: 상호작용을 통해 이득을 얻는 대상(주로 사람이며 최대한 간단하게 표현)
시스템(부) 액터: 주 액터의 목적 달성을 위해 제공되는 외부 시스템(조직기관)
유스케이스: 사용자 관점의 제공 서비스나 기능을 단순하게 표현
관계: 유스케이스와 유스케이스, 액터와 유스케이스의 관계 표현
유스케이스 기술서
액터가 시스템과 상호작용하는 과정을 보다 구체적으로 서술한 문서이다.
유스케이스 다이어그램에 있는 각각의 유스케이스에 대해서 작성해야 한다.
유스케이스명: 액터가 달성하고자 하는 목적을 명확하게 표현
액터명: 실제 사람의 이름이 아닌 역할이나 그룹의 이름 사용
개요: 유스케이스 수행 시나리오를 간략하게 요약
사전조건: 유스케이스 수행을 위한 사전 조건 기술
사후조건: 유스케이스 수행 후에 만족해야 하는 조건 기술
기본흐름: 목적 달설을 위해 수행되는 완전한 상호작용 흐름 기술
트리거: 유스케이스가 시작되는 사건, 기본흐름의 첫 번째로 기술
대체흐름: 기본흐름을 벗어나 선택적, 예외적으로 처리되는 흐름을 기술
유스케이스 다이어그램의 관계
포함 관계(필수적)
공통으로 사용되는 기능을 별도로 추출하여 새로운 유스케이스를 생성하고 연결한 관계이다.
기존 유스케이스에서 새로운 유스케이스 방향으로 점선 화살표를 연결하고, <<include>>를 표기한다.
일반화 관계
유스케이스 간의 상위, 하위 관계를 표현한다.
하위 유스케이스에서 상위 유스케이스 방향으로 속이 빈 실선 화살표를 연결한다.
화장 관계(선택적)
특정 조건에서만 실행되는 유스케이스를 생성하고 연결한 관계이다.
선택적 유스케이스에서 원래의 유스케이스 방향으로 점선 화사표를 연결하고, <<extend>>를 표기한다.
요구사항 분석(Requirement Analysis)
요구사항 도출 단계에서 도출된 다양한 요구사항들을 분석하여 목표 시스템이 제공해야 하는 기능 및 특성을 조정해 나가는 활동이다.
도출된 요구사항 중 명확하지 않거나, 상충되는 요구사항 등을 분석하여 문제점을 해결한다.
요구사항 특징
소프트웨어의 정확한 범위 파악과 외부 환경과의 상호작용 분석이 가능하다.
요구사항 분석 단계에서의 문서 산출물은 유지보수에 유용하게 활용된다.
요구사항의 변경은 개발 전체에 영향을 끼치므로 정확한 분석이 필요하다.
기능과 비기능차이 알아됌
요구사항 분석 기법
요구사항 분류(Requirement Classification)
기능적 요구사항(기능,연산): 시스템의 기능, 제어 연산, 기술에 대한 요구사항
비기능적 요구사항(성능,품질,안전): 성능, 보안, 품질, 안전 등에 대한 요구사항
사용자(소프트웨어) 요구사항: 사용자에게 제공해야 하는 것, 친숙한 표현
시스템 요구사항: 시스템(개발자)에게 제공해야 하는 것, 기술적 표현
개념 모델링(Conceptual Modeling)
분석된 요구사항을 기반으로 업무 처리의 실제(Entity)들과 그들의 관계(Relation)를 모델링하는 것이다.
현실의 문제를 모델링하는 것으로 요구사항 분석의 핵심 단계라고 할 수 있다.
개념 모델은 문제가 발생하는 상황에 대한 공통의 이해와 해결책을 제시한다.
요구사항 할당(Requirement Allocation)
정리된 요구사항을 만족시키기 위한 구성 요소들을 식별하는 과정이다.
구성 요소들의 상호작용을 분석하여 추가적인 요구사항을 발견할 수 있다.
중요
요구사항 협상(Requirement Negotiation)
요구사항들이 서로 어긋나서(상층) 요구사항을 전부 만족시키지 못하는 경우에 이를 합의하는 과정이다.
두 명의 이해관계자가 요구하는 요구사항이 서로 충돌되는 경우
요구사항과 자원이 서로 충돌되는 경우
기능적 요구사항과 비기능적 요구사항이 서로 충돌되는 경우
정형 분석(Formal Analysis)
요구사항 분석 프로세스의 마지막 단계로, 요구사항을 정확하고 명확하게 표현한다.
구문(Syntax)과 의미(Semantices)를 갖는 정형화된 언어를 이용해 요구사항을 수학적 기호로 표현한 후 이를 분석하는 과정이다.
구조적 분석
정형화된 분석 절차에 따라 요구사항을 파악하고 도형 중심으로 표현한 도표이다.
구조적 분석의 기본 원리 4가지는 추상화 원칙, 정형화 원칙, 분할 정복, 계층화가 있다.
추상화(Abstract) 원칙: 객체들의 공통된 성질을 추출하여 중요한 특징만 간단하게 표현
정형화(Formality) 원칙: 문제 해결에 정형화된(공학적인) 접근 방법을 적용
분할 정복: 어려운 문제 해결을 위해 해결이 쉬운 작은 문제로 나누어 해결
계층화: 분할된 모듈을 트리 구조로 배열하여 관리의 난이도 감소
구조적 분석 도구는 자료 흐름도, 자료 사전, NS 차트, HIPO 등이 있다.
자료 흐름도(DFD: Data Flow Diagram)
기능에 의한 데이터의 흐름을 도형으로 표현한 도표이다.
제어의 흐름이 아닌 데이터의 흐름에 중심을 두고 있으며 작업 소요시간은 파악 불가능하다.
자료 흐름도(4가지)
단위 프로세스를 거친 데이터 흐름에는 새로운 이름 부여
데이터 출력을 위해서는 반드시 입력 필수
해당 프로세스와 하위 자료 흐름도의 데이터 흐름 일치
최하위 프로세스는 소단위 명세서를 가짐
자료 흐름도는 프로세스, 자료 흐름, 자료 저장소, 단말로 구성된다.
단말: 데이터 입출력 주체, 사각형으로 표기
프로세스: 데이터 처리 과정, 타원(원)으로 표기
자료 흐름: 데이터 흐름 방향, 화살표로 표기
자료 저장소: 데이터가 저장되는 곳, 상하 평행선으로 표기
자료 사전(DD: Data Dictionary)
자료 흐름도에 사용된 데이터의 이름과 속성을 표기한 자료(메타 데이터)이다.
정의: 등호(=)로 표현, 자료의 명명
연결: 더하기(+)로 표현, 서로 다른 두 데이터를 연결
선택: 대괄호([])와 파이프라인(|)으로 표현, 복수의 데이터 중 선택
반복: 중괄호({})로 표현, 반복되는 데이터
생략: 괄호(())로 표현, 생략 가능 데이터
주석: 에스터리스크(*)로 감싸서 표현, 데이터를 설명하는 주석
순차 이게 핵심
NS(Nassi-Schneiderman) 차트
문제 처리 프로세스를 도형을 통해 논리 중심으로 표현한 차트이다.
순차, 선택, 반복의 제어구조를 명확히 표현하여 프로그램 구현이 쉽다.
HIPO(Hierarchy Input Process Output)
기능과 데이터의 관계를 계층 구조로 표현하여 한눈에 이해하기 쉽도록 구성한 도표이다.
시스템의 기능을 여러 개의 고유 모듈로 분할하여 계층적으로 나타낸다.
기능과 자료의 의존서을 동시에 표현할 수 있으며 하향식 소프트웨어 개발에 유용하다.
HIPO(3가지)
가시적 도표(Visual Table of Contents): 시스템의 전체적 기능과 흐름을 트리 형태로 표현한 구조도
총제적 도표(Overview Diagram): 기능별 입력, 처리, 출력에 대한 전반적인 정보를 제공하는 도표
세부적 도표(Detail Diagram): 총체적 도표의 기능을 구성하는 기본 요소들을 상세히 기술하는 도표
요구사항 명세(Requirement Specification)
요구사항 명세 개요
분석된 요구사항의 체계적인 검토, 평가, 승인이 가능하도록 문서화하는 것이다.
요구사항 명세 방식에 따라 정형 명세 기법(딱딱한)과 비정형 기법(부드러운)으로 나뉜다.
정형 명세 기법
수학적 표현으로 사용자의 요구사항을 정확하게 표현하는 기법이다.
명세 과정의 오류나 모호성을 쉽게 파악할 수 있다.
비교적 어려운 표현으로 작성되므로 이해하는데 만흔 시간이 필요하다.
비정형 명세 기법
자연어 기반으로 사용자의 요구사항을 친숙하게 표현하는 기법이다.
사용자와 개발자 간의 의사전달이 용이하다.
다양한 표현으로 작성되므로 완전한 검증이 어렵다.
명세서 작성시 고려사항
정확성: 모든 요구사항이 소프트웨어에 반영
명벽성: 애매한 표현 없이 요구사항을 명확히 서술
완전성: 기능, 서능, 제약사항, 속성 등 필요한 정보를 모두 서술
일관성: 서술된 요구사항 간의 모순, 상층이 없음
중요도: 중요도 및 우선순위에 따라 요구사항 나열
수정 가능성: 다른 요구사항에 영향을 최소화하며 변경되도록 서술
추적성: 요구사항과 관련된 문서, 산출물 참조 가능
요구사항 검증(Requirement Validation)
요구사항 검증 기법
요구사항을 기반으로 생상된 산출물 대상으로 요구사항이 올바르게 반연되었는지 확인하는 방법이다.
중요, 핵심
잘못된 요구사항을 기반으로 개발된 소프트웨어를 수정하려면 엄청난 비용이 소모된다.
요구사항 검증단계
유효성: 요구사항을 만족하는 기능을 제공하는지 파악
일관성: 상충하는 요구사항이 존재하는지 파악
완결성: 모든 요구사항을 만족하는지 파악
현실성: 환경, 예산, 규제 등의 사유로 개발이 불가능한지 파악
검증 가능성: 완성된 소프트웨어를 통해 요구사항 검증이 가능한지 파악
단계별로 요구사항 검토, 프로토타이핑, 모델 검증, 인수 테스트 드이 있다.
요구사항 검증 기법 종류
요구사항 검토(Review)
요구사항 검토 담당자들이 직접 요구 사항 명세서를 검증하는 일반적인 방법이다.
검증 방식 종류
동료(Peer) 검토: 요구사항 명세서 작성자가 다수의 동료들(이해관계자)에게 내용을 직접 설명하면서 결함을 분석
위크스루(Walk Through): 미리 요구사항 명세서를 배포하여 사전 검토후 짧은 회의를 통해 결함을 분석
인스펙션(Inspection): 요구사항 명세서 작성 이외의 전문 검토 그룹이 상세히 결함을 분석
계획 -> 사전교육 -> 준비 -> 검토회의 -> 수정 -> 후속조치
수정 -> 계획
프로토타이필
요구사항 검증을 위한 시제품을 신속하고 간단하게 개발하여 요구사항을 거증하는 방법이다.
즉각적인 피드백이 가능하고 문제점의 사전 식별이 가능하며 새로운 요구사항이 도출될 수 있다.
단계가 반복될수록 비용이 증가하며 사용성이 과대평가될 수 있다.
모델 검증
요구사항 분석 단계에서 개발된 모델이 요구사항을 만족하는지 검증하는 방법이다.
각각의 모델이 분석된 요구사항을 정확히 도출하였고, 또 반영하였는지 검증한다.
실제 실행을 통해 검증(동적 분석)하는 것이 아닌, 모델의 구조 및 의사소통 경로 등을 검증(정적 분석)하는 것이다.
인수(Acceptance) 테스트
개발이 완료된 소프트웨어를 직접 인수받아 인수자가 직접 테스트하여 요구사항 만족여부를 검사하는 방법이다.
인수자는 해당 소프트웨어에 대한 개발 정보가 부족하므로 각 요구사항에 대한 테스트 계획을 세워서 만족 여부를 판단해야 한다.
마무리
오늘 하루종일 중국대학교 졸업관련되서 증명때문에 공자학원 갔다오고 스터디하고 하냐고 정리를 늦게했다. 오늘 정보기능사 접수도 했고 긴장되긴한다. 처음으로 보는 국가고시이다보니깐 잘해서 필기랑 실기시험에 합격했으면 좋겠다. 화이팅!
