필기 - 1. 소프트웨어 설계_ch1. 요구사항 확인
1. 현행 시스템 분석
(1) 플랫폼 기능 분석
1️⃣ 플랫폼(Platform)의 개념
- 플랫폼은 애플리케이션을 구동시키는 데 필요한 소프트웨어의 환경
2️⃣ 플랫폼의 유형
- 플랫폼의 유형은 싱글 사이드(단방향), 투 사이드(양방향), 멀티 사이드(멀티) 플랫폼
3️⃣ 플랫폼의 기능
- 비용 감소 효울 상승
- 커뮤니티 형성
- 네트워크 효과
4️⃣ 플랫폼 기능 분석 절차
순차 | 절차 |
1 | 현행 플랫폼 자료 수집 |
2 | 수집 자료 분석 |
3 | 결과 산출물 작성 |
(2) 플랫폼 성능 특성 분석
1️⃣ 플랫폼 성능 특성 분석 이유
- 플랫폼 성능 분석을 통해 사용자의 서비스 이용 시 속도의 적정성 알 수 있음
- 사용자 요구사항 중 성능에 대한 개선요청 항목은 현재 시스템 플랫폼 성능이 느린 것으로 제기 될 가능성 높음
2️⃣ 플랫폼 성능 특성 분석 기법
기법 | 산출물 |
사용자 인터뷰 | 인터뷰 결과서 |
성능 테스트 | 성능 테스트, 부하 테스트 |
산출물 점검 | 벤치마킹 테스트 결과서 |
3️⃣ 플랫폼 성능 특정 측정 항목
측정 항목 | 설명 |
경과 시간(Turnaround Time) | 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간 |
시용률(Utilization) | 애플리케이션이 의뢰한 작업을 처리하는 동안 CPU, 메모리 등의 자원 사용률 |
응답시간(Response Time) | 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간 |
가용성(Availability) | 서버와 네트워크, 프로그램 등의 정보 시스템이 정상적으로 사용 가능한 정도 |
(3) 운영체제 분석
1️⃣ 운영체제(OS; Oerating System)의 개념
- 운영체제는 하드웨어 및 소프트웨어의 자원을 효율적으로 관리하며 공통된 기능을 제공하는 소프트웨어
- 사용자가 컴퓨터를 좀 더 쉽게 사용하기 위해 지원하는 소프트웨어
2️⃣ 운영체제 현행 시스템 분석
관점 | 고려사항 | 설명 |
품질 측면 | 신뢰도 | 장기간 시스템 운영 시 운영체제의 장애 발생 가능성 운영체제의 버그로 인한 재기동 여부 |
성능 | 대규모 및 대량 파일 작업(배치 작업) 처리 지원가능한 메모리 크기(32bit, 64bit) |
|
지원 측면 | 기술 지원 | 공급사들의 안정적인 기술 지원 오픈 소스 여부 |
주변 기기 | 설치 가능한 하드웨어 다수의 주변 기기 지원 여부 |
|
구축 비용 | 지원 가능한 하드웨어 비용 설치할 응용 프로그램의 라이선스 정책 및 비용 유지 및 관리 비용 |
3️⃣ 운영체제 종류 및 특징
구분 | 종류 | 저작자 | 특징 |
컴퓨터 | 윈도우 (Windows) |
Microsoft | 중/소규모 서버, 일반 PC등 유지, 관리 비용 장점 |
유닉스 (UNIX) |
IBM, HP, SUN | 대용량 처리, 안정성 높은 엔터프라이즈 급 서버 | |
리눅스 (Linux) |
Linus Torvalds | 중/대규모 서버 대상, 높은 보안성 제공 하드웨어 및 소프트웨어 소유 비용이 가장 적음 |
|
모바일 | 안드로이드 (Android) |
스마트폰, 태블릿PC, 다양한 기기의 호환성 제공 | |
iOS | Apple | 스마트폰, 태블릿PC, 높은 보안성과 고성능 제공 |
(4) 네트워크 분석
1️⃣ 네트워크(Network)의 개념
- 컴퓨터 장치들이 노드 간 연결(데이터 링크)을 사용하여 서로 데이터 교환하는 기술
- 데이터 링크들은 유선 매체(광케이블) 또는 무선 매체(와이파이)를 통해 성립
2️⃣ 네트워크 현행 시스템 분석
- 형행 시스템이 구성된 네트워크 구조를 네트워크 구성도를 통해 분석
- 백본망, 라우터, 스위치, 게이트웨이, 방화벽 등이 대상
- 네트워크 구성도 작성 > 서버 위치, 서버 간 연결 방식 파악
(5) DBMS 분석
1️⃣ DBMS(DataBase Management System)의 개념
- 데이터베이스라는 데이터 집합에 대해 생성, 저장, 관리할 수 있는 기능 제공하는 응용 프로그램
2️⃣ DBMS 기능
기능 | 설명 |
중복 제어 | 동일 데이터가 여러 위치에 중복으로 저장되는 현상 방지 |
접근 통제 | 권한에 따라 데이터에 대한 접근 제어 |
인터페이스 제공 | 사용자에게 SQL 및 CLI, GUI 등 다양한 인터페이스 제공 |
관계 표현 | 서로 다른 데이터 간의 다양한 관계를 표현할 수 있는 기능 제공 |
샤딩/파티셔닝 | 구조 최적화를 위해 작은 단위로 나누는 기능 제공 |
무결성 제약조건 | 무결성에 관한 제약조건을 정의/검사하는 기능 제공 |
백업 및 회복 | 데이텉베이스 장애 발생 시 데이터의 보존 기능 제공 |
3️⃣ DBMS 현행 시스템 분석
가성호기구
관점 | 고려사항 | 설명 |
성능 측면 | 가용성 | 장기간 시스템을 운영할 때 장애 발생 가능성 백업 및 복구 편의성 DBMS 이중화 및 복제 지원 |
성능 | 대규모 데이터 처리 성능 대량 거래 처리 성능 다양한 튜닝 옵션 지원 여부 비용 기반 최적화 지원 및 설정의 최소화 |
|
상호 호환성 | 설치 가능한 운영체제 종류 다양한 운영체제에서 지원되는 JDBC ODBC |
|
지원 측면 | 기술 지원 | 공급 업체들의 안정적인 기술 지원 다수의 사용자 간의 정보 공유 오픈 소스 여부 |
구축 비용 | 라이선스 정책 및 비용 유지 및 관리 비용 |
(6) 비즈니스 융합 분석
1️⃣ 비즈니스 융합 분석(Business Convergence)의 개념
- 융합 기술이 제공하는 기회나 융합의 원리를 적용해서 새로운 제품, 서비스, 산업을 창출하거나 기존 제품을 혁신하기 위한 기업 활동이다.
- 산업 또는 시장 간 경계를 허물어 정보통신 기술을 적용해 새로운 비지니스 모델로의 범위를 확대
2️⃣ 비즈니스 융합 유형
유형 | 설명 | 사례 |
고객 가치(Why) | 개인, 사회, 인류의 행복과 번영을 위한 가치 창출 | 신재생 에너지 개발, 친환경 농산물 생산 |
시장 유통(Whom) | 신시장 개척 또는 미래시장 선점 | 자율주행 자동차, 글로벌 통신망 |
가치 제안(What) | 시장/고객의 미충족 욕구 대응을 위한 신상품 개발 | 드론 배송, 협동 로봇, 소셜 로봇 |
공급 역량(Who) | 신기술, 신규역량을 활용한 상품생산 및 판매 | 스마트 밴드. 스마트 헬스케어 |
생산 방식(How) | 제품/서비스의 생산, 판매 프로세스 혁신 | 스마트 팩토리, 옴니채널 |
3️⃣ 비즈니스 융합 분석 절차
순서 | 절차 | 설명 |
1 | 기업전략 분석 | 기업환경과 그에 대응하기 위한 경쟁전략 분석 |
2 | 영역 및 방향 설정 | 기업전략을 고려한 영역에 대한 설정 |
3 | 포트폴리오 신청 | 부합성, 생존성, 경쟁, 성장성 등을 평가 |
4 | 융합모델 설계/평가 | 구체적으로 수행할 비즈니스 모델을 설계 융합모델 유효성 평가 및 시범 적용 |
5 | 비즈니스 융합 실행/개선 | 프로토타이핑(Prototyping), 사업화 타당성 확인 |
2. 요구사항 확인
(1) 요구분석 기법
1️⃣ 요구분석(Requirements Analysis)의 개념
- 요구분석은 사용자의 요구를 추출하여 목표를 정하고 어떤 방식으로 해결할 것인지 결정하는 단계
- 요구분석은 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
2️⃣ 요구분석의 특징
- 요구분석은 소프트웨어 개발의 설제적인 첫 단계
- 사용자의 요구에 대해 이해하는 단계
- 문서화를 통해 유지보수에 용이
- 구체적인 명세를 위해 소단위 명세서 사용가능
- 도메인 분석은 요구에 대한 정보를 수집하고 배경을 분석하여 이를 토대로 모델링을 하게 됌
3️⃣ 요구사항 분석 단계 절차
요구사항을 기술할 때에는 요구사항의 확인(Validation), 요구사항 구현의 검증(Verification), 비용 추정이 가능하도록 기술
순서 | 절차 | 설명 |
1 | 요구사항 분류 | 요구사항 유형(기능 요구사항,비기능 요구사항) 확인하는 단계 요구사항이 소프트웨어에 미치는 영향의 범위를 파악 요구사항이 소프트웨어 생명주기 동안 변경이 발생하는지를 확인 |
2 | 개념 모델링 생성 및 분석 | 요구사항을 더 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화, 개념적으로 표현한 것을 모델, 모델을 만드는 것이 모델링 객체 모델, 데이터 모델, 상태 모델 등 다양한 모델 작성 가능 모델링 표기를 위해 DFD(Data Flow Diagram), UML 다이어그램, E-R다이어그램 사용 |
3 | 요구사항 할당 | 요구사항을 만족시키기 위한 아키텍처 구성요소를 식별하는 단계 다른 구성요소와 어떻게 상호 작용하는지 분석을 통해 추가적인 요구사항을 발견 가능 |
4 | 요구사항 협상 | 두 명의 이해관계자가 서로 상충되는 내용을 요구하는 경우, 어느 한 쪽을 지지하기보다는 적절한 지저멩서 합의하기 위한 단계 요구사항이 서로 충돌되는 경우 각각 우선순위를 부여하면 무서이 더 중요한지를 인식할 수 있으므로 문제 해결에 도움이 됨 |
5 | 정형 분석 | 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현하는 단계 구문과 의미를 갖는 정형화된 언어를 사용하여 수학적 기호로 표현 |
4️⃣ 요구사항 분석 기술
분석 기술 | 설명 |
청취 기술 | 의견 듣는 기술 |
인터뷰와 질문 기술 | 정보를 수집하고 이야기를 나누는 기술 |
분석 기술 | 추출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 기술 |
중재 기술 | 상반된 요구에 대한 중재기술 |
관찰 기술 | 사용자가 작없하는 것을 관찰하면서 사용자가 언급하지 않은 미묘한 의미를 탐지할 수 있는 기술 |
작성 기술 | 문서 작성기술 |
조직 기술 | 수집된 방대한 정보를 일관성 있는 정보로 구조화하는 능력 |
모델 작성 기술 | 수집한 자료를 바탕으로 제어의 흐름, 기능 처리, 동작 행위, 정보 내용 등을 이해하기 쉽도록 모델로 작성하는 기술 |
5️⃣ 요구사항 분석에 사용하는 기능 모델리 기법
① 데이터 흐름도(DFD)
- 데이터 흐름도 개념
데이터가 각 프로세스를 따라 흐르면서 변환되는 모습을 나타낸 그림
자료 흐름 그래프 또는 버블 차트라고 함 - 데이터 흐름도 특징
구조적 분석 기법에 이용
데이터의 흐름에 중심을 둠
제어의 흐름은 중요하지 않음
시간 흐름을 명확하게 표현 X - 데이터 흐름도 구성요소
데이터 흐름도 구성요소에는 처리기, 데이터 흐름, 데이터 저장소, 단말이 있다.
② 자료 사전(DD; Data Dictionary)
- 자료 사전 개념
파일 혹은 데이터베이스에 있는 자료에 대한 자료 또는 각 자료 항목에 주어진 이름과 길이 서술과 같은 데이터를 포함하는 참조를 위한 작업 - 자료 사전의 작성 목적
자료 사전은 조직에 속해 있는 다른 사람들에게 특정한 자료 용어가 무엇을 의미하는지를 알려주기 위하여, 용어의 정의를 조정하고 취합하고 문서로 명확히 하는 목적 - 자료 사전 기호
기호 설명 = 자료의 정의로서 '~으로 구성되어 있다'는 것을 나타내는 기호 + 자료의 연결을 나타내는 기호 ( ) 자료 생략 가능함을 나타내는 기호 { } 자료의 반복을 나타내는 기호
좌측에는 최소, 우측에는 최대 반복 횟수를 기록[ ] 자료의 선택을 나타내는 기호 ** 주석 - 자료 사전의 작성 원칙
자료의 의미 기술, 자료 구성항목의 기술, 동의어 규정 준수, 자료 정의의 중복 제거
6️⃣ 요구사항 분석이 어려운 이유
- 개발자와 사용자 간의 지식이나 표현의 차이가 크다
- 사용자의 요구사항이 모호하고 불명확함
- 소프트웨어 개발 과정 중 요구사항이 계속 변할 수 있음
- 사용자의 요구는 예외가 많아 열거와 구조화가 어려움
(2) UML
1️⃣ UML(Unified Modeling Language) 개념
객체 지향 소프트웨어 개발 과정에서 산출물을 명세화, 시각화, 문서화할 때 사용되는 모델링 기술과 방법론을 통합해서 만든 표준화된 범용 모델링 언어이다.
2️⃣ UML 특징
가구명문
특징 | 설명 |
가시화 언어 | 개념 모델 작성 시 오류가 적고 의사소통이 용이 |
구축 언어 | 다양한 프로그래밍 언어로 실행 시스템의 예측 가능 |
명세화 언어 | 정확한 모델 제시, 완전한 모델 작성 기능 |
문서화 언어 | 시스템에 대한 평가 및 의사소통의 문서 |
3️⃣ UML 구성요소
UML은 사물,관계,다이어그램으로 구성
4️⃣ UML 다이어그램
① UML 다이어그램(UML Diagram) 개념
- UML 다이어그램은 사물과 관께를 모아 그림으로 표현한 형태
② UML 다이어그램 구분
- UML 다이어그램은 구분에 따라 구조적(정적) 다이어그램, 행위적(동적) 다이어그램으로 구분
- 정적 - 클객 컴배 복패 동적 - 유시커 상활타
구분 | 다이어그램 | 설명 |
정적 다이어그램 | 클래스 | 시스템 내 클래스의 정적 구조를 표현 |
객체 | 인스턴스를 특정 시점의 객체와 객체 사잉의 관계를 표현 | |
컴포넌트 | 코드 컴포넌트 기바의 물리적 구조 표현 | |
배치 | 컴포넌트 사이의 종속석을 표현 | |
복합체 구조 | 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현 | |
패키지 | 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현 | |
동적 다이어그램 | 유스케이스 | 사용자 관점에서 시스템의 활동을 표현 |
시퀀스 | 객체 간 상호 작용을 메시지 흐름으로 표현 | |
커뮤니케이션 | 객체들이 주고 받는 메시지 표현 | |
상태 | 모든 가능한 상태와 전이를 표현 | |
활동 | 활동의 순서대로 흐름을 표현 | |
타이밍 | 객체 상태 변화와 시간 제약을 명시적으로 표현 |
5️⃣ UML 상세
1. 클래스 다이어그램
① 개념
- 클래스와 클래스, 즉 클래스 속성 사이의 관계를 표현
② 클래스 다이어그램 구성요소
- 클래스 이름, 속성, 연산, 접근 제어자가 있다
2. 클래스 다이어그램
① 개념
- 시스템이 제공하고 있는 기능 및 그와 관련된 외부 요소를 사용자의 관점에서 표현하는 다이어그램
② 유스케이스 다이어그램 구성요소
- 유스케이스, 액터, 시스템이 있다
③ 유스케이스 다이어그램 구성요소 간의 관계
- 연관, 포함, 확장, 일반화(화살표) 관계가 있다.
3. 시퀀스 다이어그램
① 개념
- 객체 간 상호 작용을 메시지 흐름으로 표현한 다이어그램
② 시퀀스 다이어그램 구성요소
- 객체, 생명선, 실행, 메시지, 회귀 메시지가 있다.
4. 상태 다이어그램
① 개념
- 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지 표현하는 다이어그램
② 상 다이어그램 구성요소
- 상태, 시작 상태, 종료 상태, 전이, 이벤트, 전이조건이 있다.
6️⃣ UML 관계
연의일실포집
구분 | 설명 |
연관 관계 | 사물 사이를 실선으로 연결하며, 방향성은 화살표로 표현 |
의존 관계 | 영향을 주는 사물이 영향을 바는 사물 쪽으로 점선 화살표흘 연결하여 표현 |
일반화 관계 | 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표를 연결하여 표현 |
실체화 관계 | 사물에서 기능 쪽으로 속이 빈 점선 화살표를 연결하여 표현 |
포함 관계 | 포함되는 쪽(부분)에서 포함하는 쪽(전체)으로 속이 채우진 마름모를 연결하여 표혐 |
집합 관계 | 포함되는 쪽(부분)에서 포함하는 쪽(Whole)으로 속이 빈 마름모를 연결하여 표현 |
7️⃣ UML 확장 모델의 스테레오 타입
UML의 기본적 요소 이외의 새로운 요소를 만들어 내기 위한 확장 메커니즘
타입 | 설명 |
<< include >> | 하나의 유스케이스가 어떤 시점에 반드시 다른 유스케이스를 실행하는 포함 관계 |
<< extend >> | 하나의 유스케이스가 어떤 시점에 다른 유스케이스를 실행할 수도 있고, 안할 수도 있는 포함 관계 |
<< interface >> | 모든 메서드가 추상 메서드이며, 바로 인스턴스를 만들 수 없는 클래스로 추상 메서드와 상수만으로 구성된 클래스 |
<< entity >> | 일반적으로 정보 또는 오래 지속되는 연관된 행위를 형상화하는 클래스로 유스케이스 처리 흐름이 수행되는 과정에서 기억 장치에 저장되어야 할 정보를 표현하는 클래스 |
<< boundary >> | 시스템과 외부 액터와의 상호 작용을 담당하는 클래스 |
<< control >> | 시스템이 제공하는 기능의 로직 및 제어를 담당하는 클래스 |
(3) 애자일(Agile)
1️⃣ 애자일 방법론의 개념
- 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법
2️⃣ 애자일 방법론 등장 배경
- 기존 개발방법론은 문서 및 절차 위주로 변화에 신속하지 못함
3️⃣ 애자일 방법론 특징
- 프로젝트의 요구사항은 기능 중심으로 정의한다.
- 절차와 도구보다 개인과 소통을 중요하게 생각한다.
- 작업 계획을 짧게 세워 요구 변화에 유연하고 신속하게 대응할 수 있다.
- 소프트웨어가 잘 실행되는 데 가치를 둔다.
- 고객과의 피드백을 중요하게 생각한다.
4️⃣ 애자일 선언문
- 공정과 도구보다 개인과 상호작용
- 계획을 따르기보다 변화에 대응
- 포괄적인 문서보다 동작하는 소프트웨어
- 계약 협상보다 고객과의 협력
5️⃣ 애자일 방법론 유형
XP, 린(Lean), 스크럼(SCRUM)
① XP
의사소통 개선과 즉각적인 피드백으로 소프트웨어 품질을 높이기 위한 방법론
XP의 5가지 가치 - 용단의 피존
가치 | 설명 |
용기 | 용기를 가지고 자신감 있게 개발 |
단순성 | 필요한 것만 하고 그 이상의 것들은 하지 않음 |
의사소통 | 개발자, 관리자, 고객 간의 원활한 소통 |
피드백 | 의사소통에 대한 피드백 |
존중 | 팀원 간의 상호 존중 |
② 스크럼
매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
주요 용어 | 설명 |
제품 책임자 | 이해관계자의 의견을 종합하여 제품에 대한 요구사항을 작성하는 주체 |
제품 백로그 | 제품과 프로젝트에 대한 요구사항 |
스프린트 | 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상 |
스크럼 미팅 | 매일 15분 정도 미팅으로 To-Do List 계획수립 |
스크럼 마스터 | 프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람 |
스프린트 회고 | 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록 |
번 다운 차트 | 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트 |
③ 린
도요타의 린 시스템 품질기범을 소프트웨어 개발 프로세스에 적용한 방법론
낭비 요소 제거, 품질 향상
칸반 보드 사용
3. 분석 모델 확인
(1) 모델링 기법
1️⃣ 모델(Model) 개념
- 개발 대상을 추상화하고 기호나 그림 등으로 시각적으로 표현
- 모델을 통해 스프트웨어에 대한 이해도 향상
- 이해 당사자 간의 의사소통 향상
2️⃣ 모델링
- 모델을 만드는것
- 구조적 방법론에서는 DFD, DD
- 객체 지향 방법론에서는 UML
- 실세계 문제에 대한 모델링이 소프트웨어 요구사항 분석의 핵심
(2) 분석 자동화 도구
1️⃣ 분석 자동화 도구의 개념
분석 자동화 도구는 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 개발하도록 개발된 요구사항 분석을 위한 자동화 도구(CASE)이다.
설계를 도와주는 Tool
2️⃣ 분석 자동화 도구의 등장 배경
산업 측면 - 소프트웨어 위기의 극복 대응 방안으로 대두
관리 측면 - 시스템의 재상용성, 생산성 및 유지보수의 어려움 극복 필요
3️⃣ 분석 자동화 도구의 특징
- 표준화 적용과 문서화를 통한 보고를 통해 품질 개선이 가능
- 변경사항과 변경으로 인한 영향에 대한 추적
- 명세에 대한 유지보수 비용의 축소가 가능
- 자동화된 기법을 통해 소프트웨어 품질이 향상
4️⃣ 분석 자동화 도구의 분류
분류 | 섦여 |
상위 CASE | 계획수립, 요구분석, 기본설계 단계를 다이어그렘으로 표현 자료흐름도 프로토타이핑 작성 지원 및 UI 설계 지원 |
하위 CASE | 구문 중심 편집 및 정적, 동적 테스트 지원 시스템 명세서 생성 및 소스 코드 생성 지원 |
5️⃣ 분석 자동화 도구 주요기능(CASE 도구)
- 그래픽 지원
- 소프트웨어 생명주기의 전 단계를 연결
- 다양한 소프트웨어 개발 모형을 지원
- 표준화된 개발 환경 구축 및 문서 자동화 기능을 제공
- 작업 과정 및 데이터 공유를 통해 작업자 간의 커뮤니케이션을 증대
(3) 요구사항 관리 도구
1️⃣ 요구사항 관리 도구의 개념
- 요구사항 관리 도구는 요구사항을 기반으로 프로젝트 관리, 설계, 개발, 테스트 등을 수행할 수 있는 역할을 지원하는 도구
2️⃣ 요구사항 관리 도구의 필요성
- 비용 편익
- 변경 추적
- 영향 평가