정보박사 2023년 정보처리기사 필기 강의 제1과목 소프트웨어 설계 1.요구사항 확인

https://youtu.be/5DeWAkIdWbM?si=bwPdHJzB7aQI_6NL

1. 현행 시스템 분석을 통한 소프트웨어 설계

1-1. 현행 시스템 분석의 중요성과 목표
- 소프트웨어 설계의 첫 번째 단계인 현행 시스템 분석의 필요성에 대해 강조함
- 현행 시스템 분석을 통해 개발 범위와 향후 개발 시스템의 이용 방향성을 분석하는 것에 대해 설명함
- (중요) 운영 제약, 데이터베이스 관리 시스템 등 요구 사항을 식별하는 것이 중요함
- 향후 개발될 목표 시스템을 명확하고 구체적으로 기술하는 것이 핵심 목표임

1-2. 현행 시스템 파악 절차와 그 세부 내용
- (중요) 현행 시스템 파악 절차의 주요 단계와 각 단계의 세부 내용에 대해 설명함
- 하위 시스템 파악, 시스템 기능 파악, 시스템 인터페이스 현황 파악 등의 세부 내용을 파악해야 함
- 각 파악 단계에서 시스템 구성 현황, 기능 현황, 인터페이스 현황 등을 중점적으로 파악해야 함
- 아키텍처 및 소프트웨어 구성 파악 시, 시스템 아키텍처 구성도를 작성하는 것이 중요함

1-3. 현행 시스템 분석의 실제 적용 예시
- 전자 정보, 행정안전부 등 실제 기관에서 사용한 현행 시스템 아키텍처 구성도 예시를 제시함
- (중요) 소프트웨어 구성도를 작성할 때, 사용자 수와 같은 정보를 고려해야 함
- 네트워크 구성에 대한 파악 시, 네트워크 구조와 통신 규약 등을 명시해야 함
- 파악 과정에서 해당 기관의 업무, 기능, 인터페이스 등을 구체적으로 명시해야 함

2. 현행 시스템 파악

2-1. 시스템 구성도
- 시스템의 주요 사양, 수량, 종류, 이중화 여부 등을 포함한 시스템 구성도 작성이 중요함
- 서버의 용도, 제품명, CPU, 메모리, 하드디스크 용량 등 포함됨
- 시스템 구성도는 인프라 기술 구축 시 고려 사항과 인프라 기술 구축의 난이도 및 비용 가능성을 예측함
- (중요) 현행 시스템 파악 시, 서버와 네트워크의 물리적 위치 관계와 보안 취약성 분석, 네트워크 장애 발생 추적 및 대응 등을 포함함
- 한국전기안전공사와 국립어학원의 네트워크 구성도 예시에서 서버와 네트워크의 연결 방식을 확인할 수 있음

2-2. 개발 기술 환경 정의
- 개발 기술 환경 정의는 운영 체제, DBMS, 미디어웨어, 오픈 소스 등 고려 사항을 포함함
- 운영 체제는 하드웨어와 소프트웨어 리소스를 관리하고, 전 세계 사용자에게 공통 서비스를 제공하는 소프트웨어임
- 시스템 소프트웨어와 응용 소프트웨어로 나뉨
- 윈도우, 유닉스, 리눅스 등 주요 운영체제의 종류와 특징을 이해함
- 운영체제 선택 시, 라이선스 비용, 신뢰도, 성능, 지원 기능 등을 고려함

2-3. 시스템 구축 고려 사항
- 신뢰도는 운영체제의 장기화 시스템 운영에 영향을 미침
- 성능은 대규모 또는 대량 파일 처리와 응용 프로그램 다운로드 시 성능 저하나 재기동이 없는지 확인함
- 지원 기능은 운영체제가 제공하는 메모리 용량과 관련이 있음
- 운영체제의 버그나 팬츠 설치로 인한 제기 동작과 성능 저하를 고려함
- 정보 시스템 구축 시, 운영체제의 신뢰도, 성능, 지원 기능 등을 고려하여 선택해야 함

3. 오픈소스 사용의 장점

3-1. 소프트웨어 오픈소스 도입
- 소프트웨어 도입의 장점으로는 기술 혁신, 사용자 참여, 지원성이 있음
- (중요) 도입 시 기존 비용 대비 효과를 고려해야 함
- 오픈소스 도입으로 기존 개발과 유지보수 비용을 절감할 수 있음
- 오픈소스 사용 시 기술적 지원이 중요함
- (중요) 공급업체의 기술 지원 및 사용자 정보 공유가 필수적임

3-2. 소프트웨어 기능 고려
- 시스템 구축 시 OS 선택이 중요함
- 리눅스 기반 시스템은 하드웨어 및 소프트웨어에서 장점이 있음
- 윈도우 기반은 유지 및 관리 비용 측면에서 강점이 있음
- 유닉스 기반은 신뢰도가 높고, 32비트 4기가 메모리까지 액세스 가능함
- (중요) 시스템 성능과 사용 환경에 따라 적합한 OS 선택이 필요함

3-3. 데이터베이스 관리 시스템
- 데이터베이스 관리 시스템은 사용자 데이터를 저장하고 분석하기 위한 소프트웨어임
- 오라클, DB Q, IBM, 마이크로소프트, SQL 서버 등 다양한 시스템이 있음
- 시스템 선택 시 비용, 용도, 가용성 등을 고려해야 함
- (중요) 대규모 데이터 처리 및 안정적인 서비스 제공을 위해 오라클과 같은 시스템을 사용할 수 있음
- 동적 웹사이트를 구현하기 위한 우수한 라이브러리도 있음

4. 시스템 요구사항 분석

4-1. 요구사항 분석의 개요
- 소프트웨어 공학 기술의 요구사항 분석을 위해 요구공학이 중요함
- 요구공학은 요구사항을 정의하고 문서화, 관리하는 프로세스임
- 요구공학의 목적은 요구사항의 지속적인 중요성과 체계적 관리의 확보임
- 요구사항 분석의 과정은 요구사항 도출, 분석, 명세화, 확인 순으로 진행됨
- (중요) 요구사항 도출은 이해관계자 식별, 효율적 의사소통, 소프트웨어 범위 파악이 중요함

4-2. 요구사항 수집 및 분석
- 요구사항 수집은 기업, 행정, 이해관계자 등 다양한 이해관계자와의 협의를 통해 이루어짐
- 요구사항 분석은 수집된 요구사항을 분류, 모델링, 기술 구조 설계, 요구사항 할당 등을 포함함
- 시스템 요구사항을 정제하고 소프트웨어 요구사항을 도출함
- 소프트웨어 요구사항에 대한 체계적인 검토와 평가가 필요함
- 시스템 정의서, 시스템 요구사항, 소프트웨어 요구사항 정의서를 포함한 문서를 작성함

4-3. 요구사항 확인 및 평가
- 요구사항 확인은 시스템에 존재하는 다양한 요소를 검토하고 평가하는 과정임
- 시스템의 기능적, 안전성, 법적 요구 사항 등을 고려하여 요구사항을 확인함
- 소프트웨어 요구사항의 신뢰성과 타당성을 평가하고, 개발팀과 고객 사이의 의사소통을 강화함
- 시스템 요구사항의 개선 가능성과 새로운 요구사항을 도출함
- (중요) 요구사항을 개선하거나 신규 요구사항을 도출하기 위해서는 적절한 평가가 필요함

5. 소프트웨어 요구사항 분석 기법

5-1. 요구사항 분석의 필요성 및 종류
- 요구사항 분석은 소프트웨어 개발의 핵심 단계로 요구사항의 의미와 중요성을 이해함
- 요구사항 분석 기법은 요구사항의 정확성 검증, 이해관계자 검토, 문제 파악 등 다양한 분석 기법을 포함함
- 분석 기법에는 요구사항 분류, 개념 모델링, 요구사항 할당, 협상, 정형 분석 등이 있음
- 요구사항 분류 기법은 기능적, 비기능적 요구사항을 구분하며, 이는 제품 및 프로세스에 영향을 미침
- (중요) 개념 모델링 기법은 문제 상황에 대한 모델링을 통해 해결책을 설명하고 이해를 돕는 방법임

5-2. 요구사항 할당 및 협상
- 요구사항 할당은 요구사항을 만족시키기 위한 시스템적 필요 사항을 식별함
- 요구사항 협상은 서로 상충되는 요구사항을 조정하고, 협상점을 찾는 과정임
- (중요) 트레이오프 지점에서 합의를 수행하며, 중요한 요구사항을 필터링함
- 협상 과정에서는 요구사항 별 우선순위 부여를 통해 중요성과 효율성을 고려함

5-3. 정량 분석 및 요구사항 확인 기법
- 정량 분석은 요구사항을 명확하게 표현하여 오해를 최소화하는 방법임
- 요구사항 확인 기법은 고객 중심의 프로젝트에서 요구사항을 정확히 검토하는 데 사용됨
- 사용자 인터페이스 요구 사항의 경우, 템플러 예제를 사용하여 개괄적으로 검토함
- (중요) 프로토 타이핑은 새로운 요구 사항 구출에 필요한 수단으로, 분석자의 가정을 파악하고 피드백을 받을 수 있음

6. 요구사항 분석

6-1. 요구사항 도출과 분석
- 요구사항 도출은 시스템의 요구 사항을 정의하는 과정임
- 요구사항 분석 기법에는 요구사항 할당, 정의, 확인, 분류, 모델링 등이 있음
- 요구사항을 만족시키기 위한 아키텍처 구조 요소를 식별하는 요구사항 할당이 중요함
- (중요) 요구 사항을 만족시키기 위한 아키텍처 구조 요소를 식별하는 요구사항 할당은 요구사항 분석 기법의 핵심 중 하나임
- 요구 사항 분류 기법은 요구 사항을 체계적으로 분류하여 우선순위를 정하는 방법임

6-2. 요구사항 모델링과 검증
- 요구 사항을 만족시키기 위한 모델을 생성하고, 그 성능을 검증하는 과정이 필요함
- 프로토타입 생성은 사용자로부터 피드백을 받아 수정 사항을 찾는 과정임
- 프로토타입 생성 비용이 발생할 수 있고, 사용자의 관심이 모델 디자인이나 품질 문제로 이어질 수 있음
- 객체 모델은 객체 사이의 의사소통 경로를 검증하기 위해 정적 분석을 수행함
- 정적 분석은 상세 설계나 코딩을 진행하면서 소스 코드와 모델의 결함을 찾아내는 과정임

6-3. 요구사항 검증과 시스템화 타당성 분석
- 요구사항 확인은 요구 사항을 만족시키는지 확인하는 과정으로, 계획 수립이 필요함
- 요구 사항 정의에 대한 퀴즈를 통해 프로토타입의 장점과 단점을 파악할 수 있음
- 요구 사항의 기술적 타당성 분석은 기술적 적합성, 실현 가능성, 성능 및 용량 산정, 시스템 상호 운용성 등을 포함함
- 기술적 위험 분석은 적용 기술의 복잡성, 검증 여부, 의존성 등 위험 가능성을 파악하는 과정임
- 시스템화 타당성 분석은 요구 사항을 만족시키기 위한 시스템 구축의 타당성을 검토하는 과정임

7. 소프트웨어 설계와 요구사항 정의

7-1. 요구사항 정의와 개발 프로세스
- 요구사항 정의는 고객의 요구사항을 체계적으로 정립하는 과정임
- 요구사항 개발 프로세스는 요구사항 도출, 분석, 명세 확인의 단계로 이루어짐
- (중요) 요구사항 시스템화 타당성 분석에서는 요구사항의 기술적 타당성을 검토함
- 성능 및 용량 산정의 적정성, 시스템 간 상호 응용성, 시장 성취도 및 트렌드 부합성을 고려함

7-2. 소프트웨어 설계 및 분석 모델
- 소프트웨어 공학 기술의 분석 도출 기법 활용이 필요함
- 유스케이스 다이어그램을 통해 시스템 동작에 대한 시나리오 도출 가능함
- (중요) 클러스 다이어그램을 통해 소프트웨어의 정적 요소와 그간의 관계 파악 가능함
- 상호 운영에서 동일 기종 또는 이 기종의 정보 시스템 간의 원활한 통신이 가능함

7-3. 분석 모델 검증과 분석 모델의 시스템화 타당성
- 분석 모델 검증은 유스케이스 모델 검증, 개념 수준 분석 및 클래스 검증으로 이루어짐
- 유스케이스 모델 검증에서는 도출된 유즈 케이스가 논리적으로 연결되어 있는지 확인함
- (중요) 개념 수준 분석 클래스 검증에서는 도출된 클래스의 역할과 관계 메시지의 흐름 등을 확인함
- 분석 클래스 검증에서는 하나의 유즈 케이스를 실현하기 위해 3개 이상의 클래스가 필요함

8. 시스템 클래스 분석

8-1. 경계, 엔터티, 제어 클래스
- 로그인 화면에서 아이디와 비밀번호 입력하는 구조의 예시임
- 아이디와 비밀번호를 입력하고 로그인 요청을 하면, 가입된 회원이 아니면 로그인 요청을 하지 말아야 함
- (중요) 경계 클래스는 화면, 엔터티 클래스는 데이터베이스 테이블, 제어 클래스는 로직 제어 담당 클래스임
- 경계, 엔터티, 제어 클래스의 도출 여부와 상세 정도 확인 필요함
- 유스케이스 명세서를 바탕으로 각 클래스와의 관계를 정의해야 함

8-2. 속성과 연산
- 속성은 데이터베이스에 저장되는 변수임
- 연산은 변수의 동작을 의미하며, 제어 클래스는 동작 중심적임
- 콘텐츠 클래스는 데이터 저장 중심이고, 연산의 매개변수명과 타입이 정의되어야 함
- 속성의 길이가 입력값보다 적게 설정되면 오류가 발생할 수 있음
- 속성과 연산의 일관성을 확인해야 함

8-3. 분석 클래스 다이어그램
- 분석 클래스 다이어그램을 통해 각 클래스의 역할과 기능을 이해할 수 있음
- 분석 클래스명, 스테레오타입 바운더리(화면), 컨트롤 클래스(로그인 제어), 엔터티 클래스(데이터 저장), 제어 클래스(로직 제어)로 구성됨
- 제어 클래스의 연산에 대응하는 엔터티 클래스가 있는지 확인해야 함
- 속성과 연산의 상세와 정도 확인으로 클래스 간 관계를 정의해야 함

9. 소프트웨어 설계의 분석 모델링

9-1. 분석 모델링 검증 절차
- 유즈 케이스 모델을 기반으로 분석 모델을 검증함
- 분석 모델링 검증 절차는 유즈 케이스 모델 개념 수준, 분석 클래스 검증 순서로 진행됨
- 분석 모델 클래스 도출에 필요한 분수 클래스 도출 확인이 포함됨
- 유즈 케이스 실행에 필요한 분수 클래스의 도출 여부 및 상세 상황 확인이 필요함
- 요구 기능 구현을 위해 필요한 유즈 케이스가 도출되었는지 확인함

9-2. 분석 모델 시스템화 타당성 검토
- 유스 케이스 모델의 개별 유스 케이스에 대한 분석 모델을 작성한 후 시스템 개발에 영향을 미치는지 검토함
- 분석 모델을 시스템화하여 시스템 간 상호 정보 및 서비스 교환 가능성 검토함
- 시스템 간 상호 운용성 분석을 통해 시스템 간 정보 교환 가능성과 서비스 제공 가능성 확인함
- 시장 성숙도 및 트렌드 부합성 분석을 통해 분석 모델이 과거 문제 해결에 효과적이었는지 확인함
- (중요) 시스템의 기술 구조, 프레임워크, 하드웨어, 소프트웨어 부합성을 검토하여 기술적 위험을 고려함

9-3. 소프트웨어 설계 요구 사항 확인
- 소프트웨어 설계 요구 사항을 확인하기 위해 분석 모델의 시스템화 타당성 검토 단계를 수행함
- 유즈 케이스 모델과 분석 클래스를 결합하여 시스템을 개발하고 필요한 자원을 식별함
- 불필요한 메모리 자원 요구와 처리 속도 저하를 방지하기 위해 필요한 속성만 포함시킴
- 시스템 간 상호 운용성 분석을 통해 서비스 교환 가능성과 정보 교환 가능성을 검토함
- 시장 성숙도 및 트렌드 부합성 분석을 통해 중요하고 빈번하게 사용되는 클래스의 프로토타입을 적용함

00:03
소프트웨어 설계의 첫 번째 챕터로 요구사항 확인 세부 ncs 능력 단위 요소 3가지가 있는데요. 그 3가지 중에 첫 번째 현행 시스템 분석에 대해 살펴보도록 하겠습니다. 현행 시스템 분석에 대한 학습 목표입니다. 개발하고자 하는 응용 소프트웨어에 대한 이해를 높이기 위해 현행 시스템의 적용 현황을 파악함으로써 개발 범위와 향후 개발될 시스템으로서의 이용 방향성을 분석할 수 있다. 두 번째 개발하고자 하는 응용 소프트웨어와 관련되어진 운영 제재와 데이터베이스 관리 시스템 그리고 미들웨어 등의 요구 사항을 식별할 수 있다. 그리고 현행 시스템을 분석하여 개발하고자 하는 응용 소프트웨어가 이후에 적용되어질 목표 시스템을 명확하고 구체적으로 기술할 수 있다.

01:03
이 세 가지 학습 목표를 갖고 내용 살펴보도록 하겠습니다. 세부 학습 내용은 똑같은데요. 현행 시스템 파악과 개발 기술 환경에 대한 정의 내용입니다. 먼저 용어 자세는 해당 이 챕터를 접할 때 네 꼭 알아야 될 어떤 용어적인 부분을 몇 가지만 좀 미리 추출해서 살펴보도록 하겠는데 하드웨어 구성도 하드웨어 구성도라는 부분은 서버의 주요 사양과 수량 이중화 이중화라고 하는 부분을 두 가지로 했다는 거죠. 저장적인 부분 자체를 하나 그리고 두 번째 백업적인 부분으로 이중화되어 있는지 여부를 명시하는 것을 하드웨어 구성도라고 하고요. 오픈소스 소스 코드를 공개해서 누구나 비용 없이 특별한 제한 없이 그 소스를 그대로 사용할 수 있는 소스 소프트웨어가 오픈 소스가 되겠습니다.

02:00
자 현행 시스템 파악에 있어서요 먼저 현행 시스템 파악에 대한 정의 내용입니다. 현행 시스템 파악이란 무엇인가 현행 시스템 파악은 하위 시스템 파악은 하위 시스템 구성 요소와 제공 기능 그리고 연계 요소를 파악하는 것을 뜻합니다. 어떠한 기술이 적용되어 있는지 적용 기술 요소와 그리고 소프트웨어 웨어 하드웨어 네트워크 구성 요소를 파악하는 것을 뜻합니다. 현행 시스템을 파악하는 주된 목적은요, 향후에 개발하고자 하는 개발 시스템의 개발 범위를 어느 범위까지를 개발 범위로 잡아야 되는가 그리고 어떻게 진행해 가야 되는지 이행 방향 설정에 도움을 얻을 수 있습니다. 현행 시스템 파악 절차입니다.

02:46
첫 번째 단계로서는 구성 기능 인터페이스 파악 세부 내용으로서는 시스템 구성 현황 파악과 시스템 기능 파악 그리고 시스템 인터페이스 현황을 파악을 합니다. 두 번째 단계인 아키텍처 및 소프트웨어 구성을 파악을 하는데요. 세부적으로는 아키텍처는 기본적인 틀입니다. 시스템 아키텍처 소프트웨어 아키텍처 이렇게 세부적으로 분류할 수 있는데, 아키텍처를 파악하고요. 그리고 어떠한 소프트웨어로 구성이 되어 있는지 소프트웨어 구성을 파악을 합니다. 세 번째 단계로서는 하드웨어 및 네트워크 구성에 대한 파악으로서 시스템 하류 현황을 파악하고 그리고 네트워크 구성을 파악합니다. 자 단계별 세부 내용 살펴보도록 하겠는데 첫 번째 단계 요소 구성 기능 및 케이스 파악입니다. 다시 하위로 대상이 현행 시스템 구성 현황 그리고 기능 현황 그리고 인터페이스 현황을 파악할 건데요.

03:44
세부 내용을 살펴보면 현행 시스템 구성 현황이라고 하는 부분은 조직의 주요 업무를 처리하는 기관적인 업무 가장 중요하고 중요 업무가 되겠죠. 기관 업무와 이를 지원하는 서포트 하는 업무로 구분하여 파악할 필요성이 있고 각 업무에 속하는 단위 업무 정보 시스템의 명칭과 주요 기능을 명시해야 합니다. 그리고 세 번째 조직 내에 존재하는 모든 정보 시스템 현황에 대한 파악이 필요합니다. 기본적인 파악이 아니라 전체적인 부분을 파악을 해야 됩니다. 다음 기능현황인데요.

04:23
기능현황은 정보 시스템 내에 하위 단위 업무 시스템별 현재 제공되고 있는 기능이 어떤 것들인지를 파악해서 기출하고 그리고 기능들을 주요 기능과 하부 기능으로 구분해서 결정적으로 표시하는 것이 좀 더 일목요연하게 파악할 수 있고 또 표시가 될 겁니다. 그리고 인터페이스 현황입니다. 인터페이스 현황은 단위 업무 시스템과 주고받는 데이터의 종류는 어떤 건가 그리고 데이터의 형식을 뭐고 통신을 할 때 지켜야 되는 프로토콜 통신 규약이라고 이야기를 합니다. 프로토콜들을 명시하고요. 포맷과 통신 규약 종류 그리고 연계 유형 약어들이 많이 좀 나오는데 ai라고 하는 부분 자체는 엔터프라이저 어플리케이션 인터페이스 약어입니다.

05:13
애플리케이션 응용 프로그램에 대한 인테그러레이션 통합 기업 응용 프로그램 통합 f ep라고 하는 부분은 프론트 앤드 프로세서 약어이거든요. 전이 단말기 이렇게 전이 처리기 이렇게 이야기가 되어지는데 어쨌든 어떤 파트에 해당되는 용언가 전개 유형이다. 각각 부분 자체를 이어준다는 말입니다. 뒷부분에 저희가 연계와 관련해서 통합 구현이라든지. 이러한 부분에 대해서 구체적으로 살펴볼 겁니다. 이상 현행 시스템 파악 절차 두 번째 단계로서 아키텍처 및 소프트웨어 구성 파악입니다. 현행 시스템 아키텍처 구성도를 저희가 다이어그램 그림으로요 그림으로 저희가 그리도록 할 건데 기관 업무 수행 기술 요소를 최상위 수준에서 그림으로 표현한 게 시스템 아키텍처 구성도가 되겠습니다.

06:10
그에 이제 정부 기관의 예라든지 이런 부분들 실제 그림을 보면 이 시스템 아키텍처 어떻게 표현하는지 이해가 되니까. 뒤에서 상세하게 설명드리도록 하겠고요. 단위 업무 시스템별 아키텍처가 상이하다 그 경우에는 어떤 걸 기준으로 하느냐 가장 핵심이 되는 기관 업무를 기준으로 작성을 한다. 그리고 소프트웨어 구성도를 작성하는데 소프트웨어 구성도는 단위 업무 시스템을 처리하는 데 있어서 설치가 되어진 소프트웨어의 제품명은 뭐고 어떤 용도이고 그리고 라이센스 적용 방식은 또 라이센스 수는 몇 카페를 우리가 구매를 했는지 이러한 것들을 명시를 하고요. 시스템 구축을 할 때 인프라 구축에서 하루웨어 비용뿐만 아니라 소프트웨어 비용이 또 차지하는 비중도가 적지 않습니다.

06:58
그렇기 때문에 상용 소프트웨어 경우는 구매를 한 소프트웨어들은 라이센스 적용 방식 기준인 사이트 단위 또는 서브 단위 또는 프로세스 코어 등 이러한 사용자 수와 같은 보유한 라이센스 수량 파악을 구체적으로 할 필요성이 있습니다. 네 아키텍처 및 소프트웨어 구성 파악에서 예시로 제시되어져 있는 부분이 전자 정보 모바일 공통 컴포넌트 적용한 아키텍처의 예시입니다. 보면은 프레젠테이션 타이어 이렇게 돼 있죠. 보여지는 화면적인 부분 그리고 프랜테이션 레이어 비즈니스 레이어 인티브레이션 레이어 또는 데이터 억세스 레이어 그리고 해당 여기 보여지는 부분에 대한 해당 구성적인 부분 시스템 아키텍처적인 부분입니다. 파운데이션 레이어는 이러한 것들이 있어요. 전자 정보 프레임워크 3.0 버전에서 제시한 예제이고요.

07:57
그리고 행정안전부의 국가 지도 db의 소프트웨어 구성도의 예시입니다. 보면요 시도에서는 lmis 서버 1에서부터 16이 있고 해당 그 서버는 다시 tcprp 유닉스 dbms 미들웨어로 구성돼 있다. 이렇게 보시면 될 것 같고, 통합 센터에서는 와스 서버가 네 was라고 하는 용어적인 부분은 뒷단에 저희 미디어 파트에서 저희가 다루도록 할 건데 웹 어플리케이션 서버를 뜻합니다. 해당 구성적인 부분 자체는 tcp ip 유닉스 이렇게 돼 있는데요. 네 이 부분 자체는 보면 이제 네트워크 구성 구조적인 측면에서 뒤에서도 저희가 좀 언급할 부분이 있습니다. 리눅스다 유닉스다라고 하는 부분은 서버 os가 되겠고요. dbms라고 하는 부분은 데이터베이스 매니지먼트 시스템 데이터베이스를 관리하는 시스템을 이야기를 합니다.

08:55
관리자 서버 db 서버 gi 서버는 지리적 정보 시스템 서버가 되겠죠. 개요적인 측면에서 소프트웨어 구성도는 이렇게 나타낸다 이렇게 이해하시면 될 것 같고, 다음 현행 시스템 파악의 3단계는 하류오 및 네트워크 구성에 대한 파악입니다. 하드웨어 구성도는 포함되어져야 될 내용이 서버의 주요 사양 수량 이중화 등에 대한 적용 여부 등이 표시가 되어지고 시스템 하드웨어의 현황 및 작성의 예시는 다음과 같이 구분은 기관 업무가 지원 업무가 그리고 시스템명은 어떤 업무를 단행한 수행하는 시스템이야 그리고 서버 용도는 ap 서버다 데이터베이스 서버다 이렇게 돼 있고 제품명은 어떤 제품명을 사용한다.

09:44
이 하드웨어 사양으로서 cpu 중앙 처리 네 시스템 중앙 처리 플라스틱 중앙 처리 시스템에 대한 종류는 코코아이고 메모리는 몇 기가구 하드디스크 용량은 얼마다 이렇게 수량은 몇 개고 이중화 여부를 포함한 도평태로 해서 정리를 해서 나타냅니다. 네 그리고 하드웨어 구성도 착상할 때 고려 사항인데요. 기관 업무의 서비스 기간 장애 대응 정책에 따라서 이중화가 필요하냐? 그 여부를 반드시 포함을 시켜야 되고 현행 시스템에서 이중화가 적용되어졌다 라고 하게 되면 향후 목표 시스템에서도 이중화가 적용될 필요성이 높겠죠. 그러한 부분들은 인프라 기술 구축 기술에 대한 난이도 및 비용 전가 가능성이 존재한다라고도 미리 파악해 볼 수 있겠습니다. 그리고 네트워크 구성도인데요.

10:39
네트워크 구성도는 업무 처리 시스템의 네트워크 구성 현황을 표현한 것을 이야기를 하고요. 고려 사항으로서는 네트워크 구성도의 작성을 통해서 서버가 어디에 위치해 있고 그리고 서버 간에는 어떠한 네트워크 연결 방식으로 연결되어 있는가라는 부분을 파악할 필요성이 있습니다. 그래서 조직 내의 서버들의 물리적 위치 관계 파악과 조직 내에 보안 취약성 분석 및 대응 그리고 네트워크 장애 발생 추적 및 대응 등 다양한 용도로 네트워크 정도로 활용될 수 있겠습니다. 한국전기안전공사의 시스템 구성도의 예시입니다. 사용자가요 네 해당 왓스가 웹 어플 켜진 서버구요. db가 데이터베이스입니다. 해당 제품은 이러한 것들로 구성돼 있다.

11:29
왓슨은 선타이어 880 모델로 돼 있고 cpu는 4개야 해당 db는 네 cpu가 8개야 이렇게 표시되어 있다라고 보시면 될 것 같고, 트랜잭션 허름도와 성능 데이터의 허름도 빨간색 파란색으로 이렇게 구분돼 있습니다. 국립어학원의 네트워크 구성도의 예시입니다. 해당 인터넷을 이용해서요. 내부망으로 들어갔을 때 스위치 연결돼 있고 검색 서버 그리고 방화벽이 구성돼 있고 네 해당 웹 서버 그리고 저장되어지는 데이터베이스 서버 이러한 것들 전체적인 망 구성입니다. 네트워크 망 구성 관련되어진 네트워크 장비들은 어떠한 것들이 연결되어 있는가라는 부분에 물리적인 어떠한 네트워크 정도를 파악해 볼 수 있겠습니다.

12:24
현행 시스템 파악과 관련되어진 퀴즈 간단하게 점검해 보도록 하겠는데요. 현행 시스템 파악할 때 작성하는 주요 시스템의 구성도로 특정을 하지 않은 것은 무엇일까? 정보 처리 기사는 사지선답형입니다. 객관식 4개 중에 하나 고르는 문제로 구성돼 있습니다. 자 작성 주요 시스템 구성도 적절하지 않은 겁니다. 소프트웨어 구성도 하드웨어 구성도 네트워크 구성도 저희가 각각 살펴봤고요. 인터페이스 구성도는 저희가 살펴보지 않았습니다. 해당 틀린 것은 인터페이스 구성도고 나머지 이 세 개는 현행 시스템 파악 시 파악하는 주요 시스템 구성도에 해당되었습니다. 두 번째 파트입니다. 네 개발 기술 환경 정의입니다.

13:10
세부 내용으로서 개발 기술 환경의 정의 요소 살펴보면 개발 기술 환경 정의할 때 고려 사항으로서는요 네 가지가 있는데, 첫 번째 운영 체제 두 번째 dbms는 데이터베이스 매니지먼트 시스템 데이터베이스 관리 시스템 그리고 미디어웨어 그리고 오픈 소스 단계별로 살펴보도록 하겠습니다. 먼저 운영체제 주요 특징 및 고려 사항인데요. 운영 체제는 무엇인가 운영 체제는 오퍼레이팅 시스템 즉 os 해당 컴퓨터가 어떠한 운영체제 설치돼 있어서 어떤 os야 윈도야 리눅스야 유닉스야 하드웨어와 이 운영체제의 정의 역할적인 부분을 보면 하드웨어 소프트웨어 리소스를 관리하고 컴퓨터 프로그램을 위한 공통 서비스를 제공하는 소프트웨어를 뜻한다.

14:02
소프트웨어 종류는 다시 크게 보면 시스템 소프트웨어 시스템 소프트웨어가 있고 그다음에 일반적인 어떤 작업을 컴퓨터를 이용해 가지고 보다 쉽게 작업할 수 있도록 도와주는 응용 소프트웨어가 있죠. 그중에서 운영 체제는 시스템 소프트웨어에 해당되는 대표입니다. 자 운영체제의 특징 및 종류입니다. 주요 운영체제는 제조사 대표적인 마이크로소프트웨어의 윈도우즈 운영체제가 있고 그리고 유닉스 리눅스 여기까지가 pc 컴퓨터 운영체제이고요. 그리고 근래에는 스마트폰도 많이 보편화돼 있잖아요. 스마트폰도 운영체제별로 종류를 나눌 수 있는데, ios 운영체제 애플에서 만든 네 애플에서 만든 운영체제 아이폰에 적재돼 있죠. 그리고 안드로이드 구글에서 무료로 배포하면서 전 세계적인 점유율은 안드로이드가 지금 60% 이상 점유를 하고 있습니다. 유료 배포를 하고 있죠.

15:02
유료가 아니라 시스템 용도에 따라서 최적화되어진 운영체제 선택해서 적용하면 되겠는데 운영체제의 종류 및 특징을 다시 세부적으로 좀 더 살펴보게 되면 윈도우 운영 체제는 마이크로소프트를 만들었고요. 전 세계 7억 이상의 사용자를 보유하고 있습니다. 네 그리고 라이센스 비용은 유료죠 유료입니다. 구매해야 되고 주요 용도는 중소 규모의 서버나 개인용 pc 등에 사용되어진다 유닉스 유닉스는 ibm hp sum 솔라리스나 이러한 종류들에 대해서 나눠집니다. 비용리 라이센스는 유료 다양한 라이센스 정책이 사용되어지고 대용량 처리 큰 어떤 이제 대규모 서버인 경우에는 주로 이제 안정성적인 측면에서는 유닉스에 대한 선호도가 높습니다. 그래서 안정성이 요구되는 서버 용도로 사용되어지고요.

16:00
리눅스 리눅스는 주 장점이 무료죠 네 무료 중대규모의 중소기업군에서는 리눅스에 대한 선호도가 높습니다. 그리고 ios 애플에서 만들었고요. 안드로이드 구글에서 만들었습니다. 스마트폰 및 해보드 피씨 필요한 용도로 사용되어진다 정보 시스템 구축할 때 os 운영 체제 고려 사항으로서요 5가지가 있는데, 신뢰도 성능 기술 지원 주변 기기 구축 비용이 있습니다. 신뢰도는요 네 장기화 시스템 운영을 할 때 운영체제 고유의 어떤 장애 발생 가능성이 높으냐 낮으냐 장애 발생이 낮아야겠죠.

16:41
네 그리고 특정 응용 프로그램에 대한 메모리 누수로 인한 성능 저하나 재기동 이러한 부분들이 혹시 생겨지지 않는가 운영체제 보완적인 측면에 대한 허점이 있지 않은가 운영체제 버그로 인한 팬츠 설치 등에 따른 제 기동이 있으면 신뢰도 낮은 운영체제일 겁니다. 그리고 성능입니다. 대규모의 경제 사용 요청 처리를 어느 정도 할 수 있느냐 대규모 또는 대량의 파일 처리 작업이 가능한가 그리고 지원 가능한 메모리가 32비트 용인가 64비트 용인가 자 윈도우 운영 체제용 어떤 응용 프로그램을 다운로드 받을 때 인터넷 상에서 보면은 버전별 맞는 걸 다운받으세요. 32비트인가요? 64비트인가요? 이렇게 묻죠 32비트인 경우에는 랩 메모리 4gb 이상을 지원을 못합니다. 근데 64비트 운영 체제는 4기가 이상 랜 메모리를 지원한다.

17:34
이런 특징도 있고 기술 지원적인 부분은 공급 벤더 공급자 업체들이 안정적인 기술 지원이 가능한가 그리고 다수의 사용자들에 대한 정보 공유와 오픈 소스 여부를 측정할 필요성이 있겠고 주변 기기는 설치 가능한 하드웨어 그리고 다수의 주변 기기 지원이 가능한지 구축 비용은요, 지원 가능한 하드웨어의 비용 설치할 응용 프로그램 라이싱 정책 및 비용 그리고 유지 관리 비용 전체 총 소요 비용을 따져볼 필요 등이 있겠다. 다음 운영 체제에 대한 주요 특징 및 고려 사항으로서 정보 시스템 구축할 때 os 고려 사항을 다시 한번 하나의 다이어그램 형태로 분류한 부분인데요. 구축 비용에서는 리눅스 기반 시스템이 하류웨어 및 소프트웨어에서 가장 장점은 소비 비용이 가장 적다라는 부분이고요.

18:24
그리고 윈도우 기반인 유지 및 관리 비용 측면에서의 강점이 있고 유닉스 기반은 반 정도 측면에서는요 가장 신뢰도가 높습니다. 그리고 성능적인 측면으로선 32비트 4기가 메모리까지 액세스 가능하고 32비트 64비트 오닉스드는 4기 이상의 메모리 액세스가 가능하다라는 부분으로 성능적인 측면에서 고려할 수 있겠다. 다음 개발 기술 환경 정리 세 번째 데이터베이스 매니지먼트 시스템 dbms에 대한 주요 기능 및 고려 사항에 대해 살펴보도록 하겠습니다. 데이터베이스 관리 시스템 dbms는 사용자 다른 애플리케이션 데이터베이스와 상호작용하여 데이터를 저장하고 분석하기 위한 컴퓨터 소프트웨어를 뜻합니다.

19:20
주 기능으로서는요 데이터베이스를 생성하거나 조회하거나 변경할 수가 있겠습니다. 데이터베이스 매니지먼트 시스템의 종류로서는요 오라클이나 제품명 오라클사에서 만든 오라클 그리고 dbq나 ibm에서 만든 데이터베이스 매니지먼트 시스템 마이크로소프트를 만든 sql 서버나 그리고 isqm 몽고 db 등이 있습니다. 각각의 특장점에 따라서 비용적인 측면에 대한 유료다 무료다 그리고 사용 용도적인 부분을 대규모에 적합하다 중소 규모에 적합하다 이러한 것들을 고려해서 선택할 수가 있겠는데요. 대규모 데이터의 안정적 처리를 필요로 하는 데이터베이스 관리 시스템으로 예로서는 오라클 은행권의 전산실에서는 주로 오라클을 많이 씁니다. 그리고 ibm의 db2 등이 있겠고 오픈 소스로 비용적인 부분에 대한 단점을 갖고 있는 무료로 이용할 수 있는 isql이라든지. 몽고 db 등을 비용적인 측면에서는 채택을 많이 합니다.

20:19
세부적으로 데이터베이스 관리 시스템의 종류 및 특징 정리한 표인데요. 오라클 ibm의 db2 쭉 참고해 보시면 될 것 같고요. 해당 네 주요 용도적인 부분들 대규모 대규모에 적합하다 중소 규모에 적합하다 해서 분류해 놓은 거니까 오라클은 주로 쌍용이고 오라클 db2 마이크로 소프트웨어 sql 서버는 쌍용 마이에스큐엘은 무료 또는 상용으로 돼 있어요. 마이에스큐엘을 오라클이 인수를 했습니다. 인수를 해서 우선은 무료로 해줄게 라고 되어있는데, 네 어쨌든 이제 유료 버전들도 나올 예정이기는 하고요. 그다음에 에스큘라이트 저작권 완료되어서 퍼블릭 그룹을 이용할 수 있다. 이렇게 돼 있고 몽고 db 그다음에 bsd 네 슬라이 어 레디스라고 해서요.

21:12
얘는 오픈 소스 및 메모리 키 값 뭐 데이터베이스 이러한 용도로 사용이 되어진다 그래서 일반적으로 대기업 같은 경우에는 오라클 많이 쓰구요. 네 그다음 중소기업부는 마이너스크를 많이 쓰는 편입니다. 공급 시스템 구축할 때 데이터베이스의 고려 사항입니다. 가용성 성능 기술 지원 상호 호환성 구축 비용 따져볼 필요성이 있겠고 가용성이라고 하는 분은 장기간 시스템을 운영할 때 장애 발생의 가능성이 낮아야겠죠. dbms의 버그 등으로 인한 재귀동이나 백업 등 복구의 편의성 데이터베이스의 이중화 및 복제 지원이 가용성에 해당되어지고 성능적인 측면 자체는 대규모 데이터 처리 성능이 가능한가 대량의 거래 처리 그리고 다양한 튜닝 옵션 지원 비용 기반의 최적화 및 설정의 최소화가 성능에 해당되어지고요.

22:02
기술 재원은 공급하는 밴드들이 안정적으로 이 기술을 계속적으로 지원해 줄 수 있는가라는 부분을 따져볼 필요성이 있겠고 상호 호환성은 설치 가능한 운영 체제 종류 해당 이제 일례로 마이크로소프트의 스크린 서버는 마이크로소프트 운영체제를 베이스로 해서 지원을 합니다. 리눅스나 유닉스에는 동작이 안 돼요. 그렇기 때문에 해당 설치 가능한 운영체제 종류 다양한 운영 체제에서 지원 가능한지라는 것을 상호 호환성적인 측면에서 따져볼 필요성이 있고 구축 비용으로서는 무료냐 또는 유료냐 유지 관리 어떤 비용적인 부분에 대한 총 소비 비용을 체크해 볼 필요성이 있겠습니다. 자 네 번째 미들웨어 주요 특성 및 고려 사항인데요. 미디오웨어는 뭔지 미들웨어라고 하는 부분은 웨어가 장치잖아요.

23:00
소프트웨어 부드러운 장치 눈으로 만질 수 없는 하드웨어 장치 딱딱한 장치 눈으로 만질 수 있는 장치 미드웨어는 중간이라고 볼 수 있겠는데 운영 체제와 소프트웨어 애플리케이션 사이에 위치하는 미드웨어는 소프트웨어 애플리케이션에서 소프트웨어 애플리케이션에게 운영 체제가 제공하는 서비스를 추가 및 확장해서 제공하는 컴퓨터 소프트웨어입니다. 하드웨어가 아니라 소프트웨어입니다. 주요 사례로서는요 저희가 미디어의 사례로서는 웹 애플리케이션 서버 w as 웹 애플리케이션 서버를 주로 다루도록 할 겁니다.

23:40
ws는 뭔데 동적인 웹사이트 반대는 정적인 웹사이트죠 동적이라고 하는 부분 자체는 사용자와 서버가 상호 작용할 수 있는 정적인 웹사이트는 html로 단순하게 내용만 보여주고 끝이고 동적인 웹사이트라고 하는 부분은 홈페이지 방문한 방문자가 게시판에 뭔가 글을 남긴다든지 이렇게 해서 서버 단으로 전달해서 상호 이제 다이내믹하게 운영되어지는 게 동적 웹사이트입니다. 동적인 웹사이트를 구현하는 언어로서는 php나 jsp나 asp나 이러한 서버 사이드 스크립트 언어들이 있고요. 동적인 웹사이트 웹 애플리케이션 웹 서비스 개발을 지원하기 위해 설계된 소프트웨어를 뜻한다. 데이터에 대한 접근과 세션 관리는 접속하고 난 다음에 일정 시간 동안만 접속을 유지하고 일정 시간이 경과되면 끊어요.

24:37
로그인하고 난 다음에 무한대로 로그인을 유지하게 되면 보완적인 측면이나 이런 것들이 문제가 생길 수도 있겠죠. 세션 관리나 트랜잭션 처리 관리 이러한 것들을 위한 라이브러리를 제공을 합니다. 웹 애플리케이션 서버의 종류 및 특징 제시되어지는 교 참고해 보시면 종류 글래스 피시 제이보스 제티 제우스 레진 웹로직 웹스피어 이러한 부분 부분들이 있고 해당 제공되어지는 밴더의 종류 그리고 비용 및 라이센스적인 측면 주요 용도적인 부분으로 정리를 해 놓았는데 대량의 안정적인 어떤 서비스를 제공하는 경우에는 오라클의 웹 로직이나 ibm의 웹 스페어 많이 사용하는 편이고요. 그다음에 저희 국내 제품인데 제우스 같은 경우에는 티맥 소프트웨어라고 국내인데 대량이 안정적인 거래처를 요구하는 적시에 기술 지원이 필요한 경우에도 추천되어집니다.

25:38
정보 시스템 구축을 할 때 왓스에 대한 고려 사항입니다. 가용성 성능 기술 지원 구축 비용 4가지 검토할 필요 중이 있겠다. 가용성은 장애 없이 잘 이용할 수 있느냐 이 측면이고요. 장기간 시스템 운영할 때 장애 발생에 대한 가능성 안정적인 트렌즈 정책 처리가 가능한가 기준화 지원 여부 성능적인 측면은 대규모의 거리 처리가 가능한가 그리고 기술 지원적인 측면에서 안정된 기술 지원을 공급 밴드로부터 받을 수 있는가 그리고 구축 비용 비용에 대한 부분을 따질 필요가 있겠다. 자 개발환경 정의 다섯 번째 오픈 소스 사용에 대한 고려사항입니다. 오픈소스라고 하는 부분 자체는 소스를 공개를 해서요.

26:23
누구나 제한사항 없이 해당 그 소스를 또 가공 처리해서 새롭게 뚝딱 이렇게 만들 수도 있게끔 네 오픈한 소스 소프트웨어가 오픈소스이고 oss라고 하는 약어는 오픈소스 소프트웨어의 약어입니다. 자유로운 사용이 가능하다 시스템 구축할 때 적용 의무를 단 신중하게 결정할 필요성은 있다. 어떤 부분이냐면은 이제 저작권의 범위나 이러한 것들 네 뒤에 보도록 하겠습니다. 콘서스 사용할 때 고려사항으로서는요 라이센스의 종류 사용자 수 기술의 지속 가능성 그리고 라이센스 문제에 대한 판단이 어렵다면 전자 정부의 표준 프레임 oss 사이트를 참조해서요. 조회해 볼 수 있겠습니다.

27:19
개발 기술 환경 정의와 관련되어진 퀴즈 한 문제 예시로 한번 보도록 하겠습니다. 데이터베이스 관리 시스템 dbms 관련되어진 요구사항 식별 시 고려 사항으로 적절하지 않은 거 틀린 거 골라라 첫 번째 장기간 시스템을 장애 없이 사용 가능한지 가용성을 고려해야 한다. 맞죠. 그다음 대규모 데이터 처리가 가능한지 성능을 고려해야 되겠다. 네 성능 따져야 되죠. 데이터베이스 매니지먼트 시스템 dbms에 설치 가능한 운영체제는 고려하지 않아도 돼 자 앞서서 dbms 종류 중에 운영 체제의 윈도우에서만 지원된다라고 말씀드렸던 게 마이크로소프트의 sql 서버는 리눅스나 유닉스는 지원을 안 합니다. 그리고 이런 걸 고려해야겠죠.

28:10
틀린 것은 3번이고 4번 라이센스 및 유지 보조 비용 등에 대한 구축 비용도 고려할 필요성이 있겠습니다. 자 해당 이 ncs 모듈 현행 시스템 분석을 총괄 정리하면서요 두 파트로 저희가 나눠서 살펴봤는데 모의평가 세 문제 한번 정리 문제로 살펴보도록 하겠습니다. 첫 번째 서버의 주요 사항 수량 이중화 등이 적용 요구와 명시되어진 정도는 뭔가 저희 한 4가지 정도 구성도라는 명칭으로 살펴봤었는데 하드웨어 구성도 네트워크 정도 아키텍트 구성도 업무 구성도 해서 서버의 주요 사용 수요량 이중하는 하드웨어 구성도입니다. 그래서 정답은 1번입니다. 맞는 걸 골라라는 거죠.

29:02
다음 두 번째 다음 정의에 대한 기술 요소는 무엇인가 소프트웨어 애플리케이션에게 운영 체제가 제공하는 서비스를 추가 및 확장하여 제공하는 컴퓨터 소프트웨어 살펴봤던 내용 중에서요 해당 정의 문구는 미들웨어에 해당되었습니다. 정답은 2번입니다. 미들웨어 네 3번입니다. 하드웨어와 스페어 리소스를 관리를 하고 컴퓨터 프로그램을 위한 공통 서비스를 제공하는 것은 무엇인가 정의 문구 해당되어지는 정답은 운영체제가 되겠습니다. 오퍼레이팅 시스템 하드웨어와 소피어 리소스 관리 와슨은 웹 애플리케이션 서버였고 데이터베이스 매니지먼트 시스템 tbms 해당 차부터 정리하도록 하겠습니다. 핵심 정리인데요.

29:54
현행 시스템 파악 부분에서는요 다뤘던 내용이 응용 소프트웨어 엔지니어링의 현행 시스템 파악 절차 및 세부 시스템의 구성 요소를 저희가 도출해 봤고요. 구성 요소로서는 쉐어링 시스템 아키텍처 구성도 소프트웨어 구성도 하드웨어 구성도 네트워크 구성도가 있었습니다. 그리고 두 번째로, 개발 기술 환경 정의 부분으로 살펴봤던 주요 내용으로서는 기술 개발 환경에 대한 정의 및 기술 요소별 특징 그리고 오류 사항을 저희가 살펴봤었고요. 기술 환경 요소 4가지 운영 체제 오프레인딩 시스템 os 그리고 dbms 데이터베이스 관리 시스템 그리고 미디어웨어 세부 종류는 왓스에 대해서 살펴봤습니다. 웹 애플리케이션 서버 그리고 오픈 소스 소프트웨어까지 살펴봤습니다. 이상으로 현행 시스템 분석에 대한 내용 마치도록 하겠습니다.

30:55
세척 설계의 세척 요구 사항 확인 두 번째 요구 사항 확인하기에 대해 살펴보도록 하겠습니다. 학습 목표입니다. 세 가지 학습 목표인데요. 소프트웨어 공학 기술의 요구사항 분석 기법을 활용을 하여 업무 분석가가 정의한 공용 소프트웨어의 요구 사항을 확인할 수 있다. 두 번째 업무 분석가가 분석한 요구 사항에 대해 정의되어진 검증 기준과 절차에 따라서 요구 사항을 확인할 수 있다. 세 번째 업무 분석가가 수집하고 분석한 요구 사항을 개발하고자 하는 공용 속도에 미칠 영향에 대해서 검토하고 확인할 수 있다. 학습 내용은 똑같습니다.

31:41
요구사항 정의 그리고 두 번째 요구사항의 시스템화 타당성 분석 용어 사전으로서요 먼저 요구공학이라는 용어 살펴보면 요구 공학 요구사항을 정의하고 문서화하고 관리하는 프로세스를 이야기합니다. 요구에도 뒤에 공학이 있네요. 공학은 뭔데요. 공학은 과학적 경제학적 사회적 원리와 실용적 지식을 활용하여 새로운 제품과 도구를 만드는 것을 이야기합니다.

32:13
이 요구 공학이 중요하게 된 이유는 내용상에서 저희가 살펴보도록 하겠는데 요구적인 부분 자체를 제대로 확인하지 않으면 나중에 완성된 결과가 다시 피드백해서 다시 만들어질 때 시간 비용 이러한 부분들이 훨씬 더 많이 요구될 수 있기 때문에 적인 측면에 대한 처리가 굉장히 중요해졌죠 통합 모델링 워너 세 번째 용어인데요. 유니파이드 모델링 랭귀지라고 해서요. uml unifid modeling language uml을 이야기합니다. 소프트웨어 공학에서 사용되는 표준화되어진 범용 모델링 언어로 소프트웨어 집약 시스템의 시각적 모델을 만들기 위한 도안 표기법을 포함한다. 객제지향 모델링 언어다 라고도 이야기를 합니다. 객제지향모델링언어 라고도 합니다. 자 세부 내용 살펴보도록 하겠습니다. 첫 번째 요구사항 정의에서 요구공학의 출현입니다.

33:11
요구공학이라고 하는 부분은 요구사항을 정의 문서와 관리하는 프로세스인데 요구사항의 지속적인 중요성이 증대하면서 요구사항에 대한 체계적 관리에 대한 필요성이 궤도에서 출연한 게 요고공학이다. 요구사항 개발 프로세스입니다.

33:32
요구사항 프로세스는 4단계로 도출 분석 명세 확인 도출에서는 요구사항 소스 그리고 요구사항 도출 기법을 저희가 세부적으로 살펴보겠고 분석 버날로시스에서는 요구사항에 대한 분류 개념 모델링 기술 구조 설계 및 요구사항 할당 그리고 요구사항 협상에 대해 살펴보도록 하겠고 그리고 명세에서는 시스템 정의서 시스템 요구사항 명세서 그리고 소프트웨어 요구사항 명세서와 같은 분석화 결과치가 만들어지겠고 확인해서는 검토 프로토타이핑 실험적 원형 모형을 만들어내겠고요. 모델 검정 인수 테스트가 되겠고 해당 이 개발 프로세스는 속도공학 지식 체계 출처로 정리한 내용이 되겠습니다. 자 요구사항 개별 프로세스를 세부적으로 살펴보겠습니다.

34:28
첫 번째 요구사항 도출 요구사항이 어디에 있고 어떻게 요구사항을 수집할 건가와 관련된 내용으로서 이해관계자가 식별되어져야 됩니다. 이해관계자라고 하는 부분 자체는 기업이나 행정 등에 직 간접적인 이해를 갖는 개인도 되고 그룹도 되고 주주 고객 노동자 하청업체 등을 통칭하여 뜻하는 게 이해관계자이구요. 개발팀과 고객 사이의 관계 형성이 중요하고요. 요구사항을 도출할 때 그리고 다양한 이해관계자와 효율적인 의사소통이 중요합니다. 그래서 일반적으로 해당 팀장의 주요 역할도 보면 커뮤니케이션 능력 기술적인 부분뿐만 아니라 네 요구사항을 해당 업무 분석가에 따라서 요구사항을 잘 뽑아내는 케이스가 있고 그렇지 못한 경우도 있거든요.

35:21
그런 이제 이해관계적인 부분에 대한 커뮤니케이션 의사소통 능력도 굉장히 중요하다 네 두 번째 요구 사항 분석입니다. 요구 사항 분석은 뽑아진 요구 사항들 간에 상충 충돌이 발생하는 것들이 있는지라는 부분을 보고 그걸 또 조율을 할 수 있어야 되겠고 그다음에 소프트웨어의 범위 파악 그리고 소프트웨어가 환경과 상호 작용하는지를 이해하고요. 시스템 요구 사항을 정제한 후에 소프트웨어 요구 사항들을 도출을 합니다. 그리고 소프트웨어 요구 사항에 대한 명세입니다. 체계적으로 검토 평가 승인될 수 있는 문서를 작성하는데 그 예시가 되어지는 문서가 시스템 정의서 시스템 요구 사항 그리고 소프트웨어 요구 사항 정의서가 되겠습니다. 마지막으로, 요구사항 확인입니다. validation이요.

36:16
분석가가 요구사항을 이해했는지를 확인할 필요성이 있는데, 요구사항 문서가 일관성 있고 완전한지를 검증하고요. 그리고 이해관계자들이 문서 검토 및 형상 관리를 수행할 수가 있겠습니다. 실제 내용을 아는 사람한테 어 우리가 이렇게 요구사항 뽑았는데 다시 한번 컨펌해 달라 맞는지 그 실제 담당자가 그 내용을 잘 알겠죠. 그리고 리소스가 요구사항이 할당되기 전에 문제 파악을 위한 검증을 수행을 합니다. 다음으로, 요구사항 분석 기법입니다. 요구사항 분석 기법이라는 부분은 요구사항에 대해서 정확한 분석을 위한 다양한 기법 적용이 되는데 요구사항에 대한 명확화가 가능합니다. 분석기법의 종류는 요구사항 분류 개념 모델링 요구사항 할당 요구사항 협상 정형 분석이 있습니다.

37:10
세부 내용으로서요 요구사항 분석 기법 첫 번째 요구사항 분류라고 하는 부분은 자 요구사항이 기능적이냐 비기능적인가 라는 부분으로 나눕니다. 기능적인 부분에 대한 거는 이제 기술적인 측면으로 구현을 하면 되는데 비기능적이라는 부분 자체는 어떤 조직적인 측면에서의 어떤 네 제한들이 제약들이 있어요. 어 우리는 우리 기업은 이러한 제품은 특정 기업하고는 거래해 이런 것도 있겠구요. 또는 제도적 측면에 대한 내용도 있겠고 뭐 경제적 측면에 대한 내용도 있겠고 요구 사항이 하나의 사항이 고수준 요구 사항으로부터 도출된 건지 또는 이해관계자나 다른 원천으로부터 발생한 건지로 나누겠고 그리고 요구 사항이 제품 및 프로세스에 관한 것인지 분류합니다. 우선순위를 부여를 해서요. 우선순위별로 요구사항들을 분류할 필요성이 있겠고요.

38:09
그리고 소프트웨어에 미치는 영향 범위에 따라서도 분류할 수 있겠고 요구사항이 소프트웨어 생명 주기 동안에 변경이 발생하는지 여부도 체킹할 필요성이 있습니다. 소프트웨어 생명주기라고 하는 부분 자체는요 소프트웨어 라이프 사이클을요 소프트웨어 개발 sdlc라고 소프트웨어 디벨먼트 라이프 사이클 계획 분석 설계 구현 테스트 유지 보수 이렇게 자 비계정적 우수상에 대한 분류 예시입니다. 비계정적인 부분은 네 제품에 대한 사용성이나 효율성이나 신뢰성이나 이식승 또는 조직적인 측면에서의 어떤 나쁜 구현 표준 외부적인 측면에 대한 상호 운용성이나 윤리 준법 법적인 측면에 대한 이러한 것들도 네 고려하는데 이게 이 기능적 요구사항에 해당되어집니다. 다음 요구사항 분석의 두 번째 개념 모델링에 대한 내용인데요.

39:07
자 이해관계자와 철저한 검증을 위한 상호 이해가 필요한데 개념 모델의 역할은 실 세계 문제에 대한 모델링이 소프트웨어 요구사항 분석에 대한 핵심이 됩니다. 그래서 모델은요, 문제가 발생하는 상황에 대한 이해를 정지시키고 해결책을 설명하기가 좋다. 무슨 말이냐 해당 이 내용을 요구사항들을 쭉 파악을 했어요. 파악을 했는데 해당 그 실 담당자하고 커뮤니케이션 할려면 전문적인 용어로 구성되어져 있는 문서를 제시하고 우리가 파악한 거 이것도 검토해 주세요. 잘 몰라요. 네 이해가 잘 안 되니까. 그래서 쉽게 이해할 수 있도록 모델링 언어들을 이용을 하는데 대표적인 게 통합 모델링 언어인 uml입니다. 뒤에 나오는 내용인데요.

40:00
문제 도메인의 액티비티와 그의 관계 및 종속성을 반영한다. 이렇게 돼 있고 개념 모델의 종류 표기법입니다. 개념 모델의 종류와 종류 및 표기법으로서는 종류는 다양한데요. 유스케이스 다이어그램 데이터 호름 모델 상태 모델 목표 기반 모델 사용자 인트랙션 모델 백제 모델 데이터 모델 등이 있는데, 주로 많이 사용하는 표기법은 통합 모델링 블랭귀지인 uml을 많이 사용한다 그러면 통합 모델링 랭귀지인 이 uml은 뭔데 소프트웨어 공학에서 사용되는 표준화되어진 범용 모델링 언어입니다. 이건 프로그래밍 언어가 아니고 표현 언어라고 보시면 돼요. 네 해당 um에는 다양한 다이어그램들이 있는데요. 총 세부적으로 15개가 있습니다.

40:53
15개 있는데, 저희 정보 처리 기사 파트에서는 한 5개 정도만 실습적인 측면에서는 저희가 살펴보도록 할 겁니다. 실기 파트에서요 자 크게 양분하해서요. uml은 구조 다이어그램과 행위 다이어그램으로 나눠지는데 구조 다이어그램이라고 하는 부분은 시스템의 정적인 구조를 표현을 하고 있는데, 또는 시스템의 구성 요소나 구성 요소들 간의 관계를 나타내는 것으로서 다이어그램의 종류는 클래스 다이어그램 오브젝트 다이어그램 객체 그리고 컴포넌트 다이어그램 컴파지 다이어그린 디플로잉먼트 배포 다이어그램 이러한 것들이 해당되어지고 대표가 뭐다 클래스 다이어그램 그다음 행위 다이어그램은 어떤 시간적 흐름에 따라서요 우리가요 부정적이지 않고 바뀌는 걸 이야기합니다.

41:42
그래서 시스템 내 객체들이 동적인 행위 표현이 해당되어지고 행위 다이어그램에 해당되어지는 다이어그램 종류는 유즈 케이스 다이어그램 시퀀스 다이어그램 액티비티 다이어그램 커뮤니케이션 다이어그램 인트랙션 다이어그램 등이 있습니다. 문제 내기 쉽겠죠. 객관식 문제대로 그다음에 uml의 다이어그램의 종류가 다른 거 하나 골라 이런 형태로 다음 요구사항 할당입니다. 요구사항 할당은 요구사항을 만족시키기 위한 악색적 구성요소를 식별하는 것이다. 요구사항을 만족시키기 위한 타 시스템적인 필요 사항도 확인합니다. 다른 구성 요소와 어떻게 상호 작용하는지도 분석하고요. 이러한 분석을 통해서 추가적인 요구 사항을 발견할 수도 있겠죠. 네 번째로는 요구사항 협상입니다. 자 2명 이상의 이해관계자가 서로 요구사항이 상충돼요. 이렇게 해줬으면 좋겠다.

42:37
이렇게 해주게 되면 b라는 사람은 이렇게 해줬으면 좋겠다라고 하는데 그렇게 하게 되면 b라는 사항이 충족되지 못하는 반하는 급 케이스 같은 경우에는 2명의 이해관계자가 서로 상충되는 내용을 요구하거나 또는 요구사항과 있을 수 또는 기능과 비기능 요구 사항들이 서로 상충될 때 적절하게 협상할 수 있어야 됩니다. 네 협상점을 찾아야 돼요. 트레이오프 지점에서 합의를 수행한다. 그리고 요구사항별 우선순위 부여로 중요한 요구사항은 필터링할 수 있도록 하고 요구사항들 간에 상충되는 문제를 해결하는 게 요구사항 협상 과정이 되겠습니다. 네 마지막으로, 정량 분석입니다. funal aleacyis 형식적으로 정의되어진 시멘틱을 지닌 언어로 요구 사항을 표현한다.

43:25
정확하고 명확하게 표현해서 오해를 최소화시키고 그리고 이 정량 분석은 요구 사항 분석의 마지막 단계에 수행이 되어지고요. 요구사항 확인 기법입니다. 네 요구사항 확인 기법 첫 번째 요구사항 검토입니다. 요구사항 검토는요 요구사항 검증이 가장 일반적인 방법이고요. 에러나 잘못되어진 가정이나 불명확한 불명확성 표준과의 차이 등에서 찾아내서 작업을 수행할 수 있고 이 요구사항 검토에서는요 고객 중심의 프로젝트인 경우에는 반드시 검토자 그룹에 고객 대표자가 한 명 이상 포함이 되어야 정확한 요구 사항을 뽑아낼 수 있겠죠.

44:14
또 피드백 받을 수도 있겠고 요구사항 검토는 시스템 정의서나 시스템 사양서 요구사항 소프트웨어 요구사항 명세서가 완성된 시점에서요 진행을 합니다. 뽑아진 요구사항에 대해서 확인해 달라는 거죠. 검토 i 트리플 e ie2 st 스탠더드 80 830-1998의 사용자 클래스 기준으로 조직화되어진 소프트웨어 리카인먼트 스페시피테이션의 템플리스 예제입니다. 상세 요구 사항에는 외부 인터페이스 요구 사항과 기능 요구 사항이 있는데, 외부 인터페이스 요구 사항에서 체킹해야 될 사항으로서는 사용자 인터페이스 하드웨어 인터페이스 소프트웨어 인터페이스 등 견본 템플러 예제이니까. 개괄적으로 살펴보고 스킵하겠습니다. 요구 사항 확인 분포 두 번째는 프로토 타이핑입니다.

45:09
뽑아진 요구 사항이 제대로 됐는지를 검토하는 측면에서요 프로토 타이핑은 새로운 요구 사항 구출에 대한 수단 및 소프트 엔지니어의 해당 내용이 맞는지를 확인하는 수단이 되겠고요. 장점은 분석자의 가정을 파악하고 잘못된 경우에 이거 잘못됐어요라고 피드백을 받을 수가 있겠고 사용자 인터페이스에 대한 동적인 행위에 대한 용이성을 제공합니다. 프로트라이케어라는 부분 자체는 예시로 만들어 보는 만들어서 맞느냐라고 결과치가 있다 보니까 눈으로 보이는 결과치가 있거든요. 네, 그러다 보니까 그냥 사용자로부터 피드백 받기가 용이해요. 그리고 용상의 가변성이 프로토타임핑 이후에 급격히 감소할 수 있다. 네 요구 사항에 대해서 프로토타이핑 베이스로 해서 파악을 하니까 수정 사항 이런 이런 부분은 수정 사항이 있고 이거는 괜찮아요.

46:07
근데 단점은요, 사용자의 관심이 해당 프로토타입 디자인이나 또는 품질 문제로 측정될 수 있고 네 프로토타이핑을 만드는 데 수행하는 비용이 발생할 수 있다. 요구사항 확인법 세 번째 모델 검증입니다. 분석 단계에서 개발되어진 모델에 대한 품질을 검증할 필요성이 있는데, 객체 모델의 경우는 객체 사이에 존재하는 의사소통 경로 검증을 위한 정적 분석을 수행을 합니다. 이 정적 분석이라고 하는 부분 자체는요 상세한 세부 설계나 코딩을 진행하면서 프로그램을 수행하지 않는 상태에서요 상세 설계나 코딩을 진행하면서 저희는 지금 현재 단계가 코딩까지는 아니죠. 설계 단계인데 상세 설계에서요 실제 프로그램을 실행하지 않은 상태에서 소스 코드와 모델에 대한 결함을 찾아내는 방법이 정적 분석입니다.

47:07
그래서 비교적 초기에 개발 초기에 결함을 찾아내면 전체적인 개발 수명 주기의 효율성을 높여서 개발 비용을 낮출 수 있는 도움을 얻을 수가 있겠습니다. 네 esc 테스트입니다. es는 요구 사항의 중요 속성으로서 제품 최종 제품이 요구 사항을 만족시키는지 확인이 가능하고요. 각각의 요구 사항이 어떻게 확인할 것인가에 대한 계획 수립이 필요합니다. 자 요구사항 정의에 대한 퀴즈입니다. 프로토타이핑이 가지고 있는 장점이 아닌 걸 골라라 첫 번째 잘못된 요구사항 사전에 도출 및 향후 발생 장비 낭비를 제거할 수 있어 맞죠. 프로타이밍은 그냥 얘를 실험적으로 만들어 가지고 보여주는 거예요.

48:02
요구사항을 제대로 반영했는지 분석 간의 과정을 파악하여 두 번째 잘못된 경우는 유용한 피드백을 제공할 수 있어 사용자로부터 잘못된 거 이거 잘못됐다라는 부분을 명확하게 제공받을 수 있다. 세 번째 사용자 인테이스에 동적인 행위 용이성을 제공한다. 네 번째 프로토타입 수행 비용이 발생할 수 있어 장점이 아닌 걸 골라라 얘는 단점이죠. 그래서 4번이 장점이 아닙니다. 비용 발생 다음 두 번째 파트로서요 네 요구사항의 시스템화 타당성 분석입니다. 요구사항 확인하기에 두 번째 파트입니다.

48:36
첫 번째 내용으로서요 요구사항의 기술적 타당성 검토 자 타당성이라고 하는 부분 자체는 해당 이게 제대로 될 건가 라는 부분에 대한 내용인데 분석인데 타당성 분석의 종류는 기술적 타당성 분석 조직적 타당성 분석 경제적 타당성 분석 법률적 타당성 분석 다양하게 있습니다. 그중에서 이제 저희 이 ncs 능력 단위에서는 기술적 타당성 분석에 포커스가 맞춰져 있습니다. 기술적 타당성 분석에서는 적용 기술의 적합 그리고 실현 기술 실현의 가능성 이 분석의 핵심 내용이 되겠고요. 성능 및 용량 산정이 제대로 되느냐 시스템 간의 상호 운용성에 문제는 없느냐 it 시장의 성숙도 및 트렌드에 부합하냐?

49:28
기술적인 위험 분석 기술적으로 너무 위험하지 않느냐 장애물 볼게요 성능 및 용량 산정의 적정성에서는 목표 시스템에 대한 용량 산정이 과거의 유사 프로젝트 경험치를 적용해서 필요하면 재조정할 필요성이 있고요. 그리고 성능과 관련한 비기능적 사항과 비교해서 또 적정한지 여부를 또 판단을 합니다. 시스템 간 상호 운용성 이 시스템 간 상호 운용성이란 건 뭔데 다른 목적을 지닌 2개 이상의 시스템들이 상호 간에 해당 연결을 할 때 상호 간 정보 및 서비스를 교환하면서 효율적으로 운영될 수 있는 시스템의 능력이 상호 운용성입니다.

50:19
요구 사항 중에 목표 시스템이 조직 내외의 타 시스템과 연동을 요구하는 경우에 상호 운영성이 가능한지 여부를 중점적으로 파악해 볼 필요성이 있습니다. 세 번째 it 성숙도 및 트렌드 부합 속도 영역별로 정보 기술의 시장 성숙도 및 발전 방향을 파악을 해서요. 요구 사항에 부합한지 여부를 판단하고 시장 성숙도가 미약하다든지 트렌드에 미부합한 기술들은 나중에 사용되지 않을 가능성이 높으니까 시스템 유지 보조가 어려운 상황이 발생할 수 있다. 그렇기 때문에 해당 기술적인 측면에 대해서 이 해당 이 기술이 it 시장 성숙도가 트렌드 오브에 부합한가라는 부분을 파악할 필요성이 있습니다. 기술적인 위험 분석인데요.

51:10
요구 사항을 만족시키기 위해서 적용하는 기술에 대한 복잡성이나 검증 여부 그리고 의존성 등에 대한 위험 발생 가능성 영향도를 파악하는 것을 뜻합니다. 기술적 위험 분석의 기술 특성과 내용 3가지 기술 특성으로서 복잡성은 기술의 안정성이나 시장성 개방성을 저해하는 낮추는 모든 요소 그리고 하료 요소케어 솔루션 적용이 앞으로 불일치한다든지 이러한 것들을 복잡성 부분에서 따져볼 필요성이 있고 그리고 검증 여부는 적용 기술에 대한 조직 내에 어 이 기술은 우리가 전혀 사용 안 해본 건데요. 어디 그런 경우 이제 그다음 경험하지 않았던 기술이냐 외부 지원이 혹시 불가능한 거 아니냐 그런 경우에는 적용할 수가 없잖아요.

52:02
그렇기 때문에 검증 여부 기술적 위험 분석에서 따질 필요가 있고 의존성은 특허나 라이센스에 따른 문제가 발생하는 경우 또는 특정 업체 기술에 너무 의존적이지 않느냐 이런 것들을 따지는 것을 이야기합니다. 네 해당 내용 정리하면서 모의평가 세 문제 한번 풀어보도록 하겠습니다. 첫 번째 다음 중 요구공학 개발 프로세스를 순서대로 나열한 것은 올바른 거 도출 분석 명세 확인 1번이 정답이죠. 요구사항 도출 분석 문서 작성하는 스페시피테이션 명제 그리고 확인하는 밸러데이션 정답은 1번 두 번째 요구 사항을 만족시키기 위한 아키텍처 구성 요소를 식별하는 것을 요구사항 할당이라고 하는데 요구사항 개발 언어 분석 기법에 해당되어지는가?

53:02
요구 사항 분석 기법 요구 사항 분류 개념 모델링 요구사항 할당 정형 분석 다 요구사항 분석 기법인데 문제에서 답이 있어요. 네 요구사항 할당이라고 합니다. 네 요구사항 할당입니다. 요구 사항을 만족시키기 위한 아피틱 구조 요소를 식별하는 거 다음 기술적 타당성 검토할 때 유의사항으로 적절하지 않은 겁니다. 틀린 거 골라라 첫 번째 요구되는 성능과 용량이 시스템 용량 산정 결과 비교해서 적합하냐? 네 맞죠. 차 시스템 연계 및 인터넷에 대한 요구 사항 확인의 경우에는 상호 운용이 가능한지 검토한다. 맞죠. 기술이 시장 성숙도 및 트렌드와 무관하게 무조건 기술적 난이도가 높고 특별한 기술을 선택을 하여 시스템을 구축하는지 확인하고 검토한다. 1가 틀린 보기 항목입니다.

54:03
네 번째 시스템을 구축하기 위한 인력 자원 및 기간이 계획을 초과하여 추가적 비용이 발생하지 않는지 여부도 검토해야겠죠. 자 핵심 내용 정리하고 마무리하도록 하겠습니다. 첫 번째 요구사항 정의 섹션에서 저희가 살펴봤던 내용 중에 중요 내용은 요구사항에 대한 개념을 정확하게 파악하고 이를 기반으로 고객의 요구사항을 체계적으로 정립할 필요성이 있더라 요구사항 개발 프로세스 단계는 요구사항 도출 분석 명세 확인 단계였습니다. 두 번째 요구사항 시스템화 타당성 분석 섹션에서 살펴봤던 내용 중에 요구사항이 시스템으로 구축되어졌을 때 타당하냐? 제대로 되겠냐 기술적 타당성을 위주로 저희가 살펴봤었죠.

54:54
요구사항 기술적 타당성 검토 요소로서는 성능 및 용량 산정의 적정성 시스템 간 상호 응용성 it 시장 성취도 및 트렌드 부합성 그리고 기술적 유형 분석 내용에 대해 살펴봤습니다. 네 이상으로 요구사항 확인에 대해 마치도록 하겠습니다. 네 소프트웨어 설계 첫 번째 요구사항 확인에 대한 세부 내용 중에 세 번째 분석 모델 확인하기 살펴보도록 하겠습니다. 학습 목표 3가지 소프트웨어 공학 기술의 영상 도출 기법을 활용하여 업무 분석가가 제시한 분석 모드에 대해서 확인할 수 있다. 두 번째 업무 분석가가 제시한 분석 모델에 대하여 응용 소프트웨어를 개발하기 위한 추가적 의견을 제시할 수 있다.

55:48
세 번째 업무 분석가가 제시한 분석 모델이 개발할 응용 소프트웨어에 미칠 영향을 검토하여 기술적 타당성 조사를 할 수 있다. 학습 내용은 두 카트로 분석 모델 검증과 분석 모델의 시스템화 타당성 분석으로 나눠서 살펴보도록 하겠습니다. 연구 사정에서는 첫 번째 유스케이트 다이어그램은 사용자 입장에서 시스템의 동작에 대한 시나리오다 즉 해당 시스템에서 제공하는 기능이라고 보시면 됩니다. 두 번째 클러스 다이어그램 소프트웨어의 정적 요소 클러스들 간의 관계를 보여주는 구조적 다이어그램이 되겠고요. 상호 운영상은 앞 챕터에서 저희가 살펴봤었는데 동일 기종 또는 이 기종의 정보 시스템 기기 및 서비스 간 상호 원활한 통신이 가능하고 정보 교환이나 일련의 처리를 정확하게 실행할 수 있는 특성을 뜻합니다.

56:48
분석 모델 검정 세부 내용으로서요 분석 모델링 검증 순차적으로는 유스 케이스 모델 검증 개념 수준 분석 클래스 검증 그리고 분석 클래스 검증 세부 유스케이스 모델 검증은 액터 도출 유스케이스 도출 유스케이스 명세서 작성이 되겠고 개념 수준 분석 및 개념 수준 분석 클래스 검정은 클래스 도출 클래스 이론과 속성 부여 클래스 간의 관계 설정 분석 클래스 검증은 스테레오 타입 부여 경계 및 제어 클래스 도출 관계 및 상세화 정도가 되겠는데 해당 이 체계는 한국정보화진흥원 정보 시스템 감리 지침을 베이스로 정리한 내용입니다. 유스케이스 모델 검증부터 살펴보면 첫 번째 액터 행위자죠 네 이 행위자는 사람이 될 수도 있고요. 다른 시스템이 될 수도 있습니다.

57:48
자 액터를 제대로 뽑았는가라는 네 검토사항으로 저는요 기능 구형에 관계되는 액터가 모두 노출됐는가라는 부분을 고려해야 되겠고 액터 목록에서 액터 이름이 어떻게 중심으로 부여가 되어졌느냐 요구사항 정의서 요구사항 기술서에 외부 및 내부 액터가 모두 뽑아졌는가 그리고 액터 목록과 액터 명세서에 기록되어진 액터가 타당한지를 확인합니다. 뮤직 케이스와 관련해서요. 도출되어진 고려 사항 도출 고려 사항으로는요 요구 기능 구현에 필요로 하는 뮤직 케이스가 모두 다 뽑아졌는가 그리고 도출되어진 유즈 케이스를 논리적으로 연결하여 누락된 기능이 있는지 여부를 파악하고요.

58:38
도출되어진 유즈 케이스가 유즈 케이스 명세서에 잘 반영되어 있는지 확인하고 도출된 유즈 케이스의 논리적인 합이 과업 범위와 일치하는지를 비교합니다. 그리고 도출된 유지 케이스들이 논리적으로 그룹화되어 있는지 이 그룹화는 팩터 기준 연관 관계 기준 동지성 기준으로 체킹해 볼 수 있겠고요. 마지막으로, 유지 케이스 기능 범위와 중복되지는 않는지 확인합니다.

59:12
세 번째로, 유스케이스트 명세서 작성과 관련되어진 고려 사항인데 유스케이션 명세서 형식이 중요 항목이 누락되지 않았는지 확인하는데 유즈 케이스 명세서의 양식 내에 포함되어지는 구성 요소로서는 사전 조건 사후 조건 주요 정상적인 포멀 흐름과 그다음에 어떤 객체 흐름 올터너티브 또는 예외 흐름 이러한 것들이 포함되어집니다. 실기 파트에서요 저희가 유스 케이스 명세서 작성 살펴보도록 할 겁니다. 유스 케이스의 주요 이벤트 흐름이 모두 도출되고 논리적으로 타당한지를 확인합니다. 유스 케이스를 구현하기 위해 필요로 하는 입력 및 출력 항목이 모두 도출됐는지 확인합니다.

1:00:00
다음으로, 개념 수준의 분석 클래스 검정으로서요 분석 클래스 검정은 뭔데 분석 클래스 검정은 시스템의 주요 도메인 개념을 분석 클래스로 도출해서 유직 베이스 분석에 활용할 수가 있습니다. 개념 수준의 주요 분석 클래스를 적절히 도출했는지 그리고 관련 정보가 명확한지 점검합니다. 분석 클래스 검증이 주요 점검 항목 세부적으로 살펴보면 개별 유스케이스 단위로 작성하지 않고요. 시스템 전체적인 측면을 대상으로 작성이 되어 있는지를 체킹하고 그리고 중요도가 높은 요구사항 또는 유스 케이스가 필요로 하는 엔터티 클래스가 도출되었는지를 체킹합니다. 이 클래스의 종류는 뒷단에 저희가 살펴보도록 하겠는데 엔터티 클래스가 있고요. 그리고 바운드리 클래스가 있고요. 그리고 제어 클래스가 있습니다.

1:00:54
기능적인 부분에 뒤에서 살펴보도록 할게요 자 도출되어진 클래스 이름이 클래스명과 클래스 이름과 설명이 이해관계자 간의 의견이 발생하지 않도록 명확한가 그리고 클래스의 속성 클래스는 클래스 속성 자 uml 다이어그램 저희가 뒤에 예제로 나오는데 이렇게 세 등분으로 사각형으로 클래스를 표출합니다. 클래스 이름이 들어가고요. 중간 단위 클래스 속성 그다음에 마지막 단위 operation operation이 들어갑니다.

1:01:36
세파트로 돼 있는데, 해당 이 두 번째 속성이 도출됐는가 제대로 그리고 도출되어진 속성의 이름과 설명이 명확한가 그리고 클래스 간에 순환적 관계가 불필요하게 정해져 있지는 않는가 그리고 클래스와 클래스 간의 관계 설정이 이렇게 되는데 해당 그 관계 다중성이 정의가 제대로 됐는지 다중성에 대한 부분은 저희가 바로 살펴보는데 클래스 간의 다중성이라는 부분은 클래스 간의 관계에서 연관관계를 표현한 걸 나타내고요. 이 연관관계를 그냥 실선으로 띄어주면 돼요. 자 클래스를 나타내는 예인데 고객 클래스가 있고요. 주문 클래스가 있어요. 이렇게 그리고 서로 경관 관계를 가집니다. 고객 클래스의 속성으로서는 이름 성별 주소가 있구요. 그리고 주문 클래스에서 속성은 일시 일련번호 수량 가격이 있네요. 각 클래스는 네 해당 연관 관계가 고객은 한 사람이 주문을 안 할 수도 있어요.

1:02:33
해당 물건 이 주문 테이블 나중에 저희가 9년에 내년 테이블 단위로 구현이 되어질 건데 이 클래스는 엔터티 클래스가 됩니다. 엔터티 클래스는 데이터베이스 내에 테이블로 구현이 되어집니다. 구현 파트에서 주문 테이블 내에 언제 그리고 해당 부분 네 주문 번호 그리고 몇 개 그다음에 뭐 가격 이러한 정보가 저장이 되어질 건데 고객은 해당 그 상품을 주문할 수도 있고 안 할 수도 있는데, 안 하는 경우엔 영업이구요. 하는 경우에는 여러 건을 할 수도 있죠. 그래서 용돈은 무한대로 표시한 네 해당 다중성의 예이고 요 다중성의 표기법은 0.1은 0 또는 1개 발생할 수 있다. 이 말입니다. 안 할 수도 있고 하는 경우에는 하나 0.0 별표 또는 별표는 0을 포함한 모형계 인스턴스 발생할 수 있다.

1:03:30
그다음에 1은 1개 1.0 별표는 1개 이상 다중성 표기법 방법입니다. 분석 클래스 검증입니다. 이 분석 클래스에 대한 검증은 분석 클래스가 적절하게 도출되었었는가 그리고 제어 클래스의 도출 등이 충분하고 상세하게 도출되어서 클래스의 역할과 클래스의 관계 메시지 흐름 등을 확인할 수 있는지를 검토합니다. 분석 클래스 검증에서요 유즈 케이스 실행에 실현에 필요한 분석 클래스 검증 세부 내용에서는 하나의 유즈 케이스를 실현하기 위해서는 3개 이상의 클래스가 역할 기준으로 도출되어 주면 좋다. 유스 케이스별로 실현에 필요한 클래스가 추적 가능해야 하고 클래스의 누락 여부를 확인할 수 있어야 합니다.

1:04:31
유스케이스별로 도출되어진 분수 클래스의 역할 기준으로는 세 가지가 있다. 첫 번째 경계 이 경계 바운더리는요 실제 사용자가 화면으로 보는 구분이 됩니다. 그래서 이제 화면이 있죠. 로그인을 한다라고 하게 되면 로그인 화면이 있죠. 네 아이디 비밀번호 입력하세요. 로그인 버튼 있죠. 그다음에 엔터티 클래스가 있는데, 이 엔터티 클래스는 로그인을 수행하기 전에 선행적으로 그 사용자는 해당 홈페이지라고 가정하면 홈페이지에 회원 가입이 먼저 돼야 됩니다. 그렇지 않으면 로그인 아이디 비밀번호를 입력하고 로그인 요청을 하게 되면 가입되지 않은 사용자 아이디다 이런 메시지가 뜨겠죠. 그래서 선행적으로 회원 가입 폼 양식을 통해서 입력한 개인 정보 값들이 어디에 저장되어지느냐 데이터베이스 매니지먼트 시스템 내에 테이블로 저장되어지는데 그 테이블이 엔터피 클래스가 됩니다.

1:05:30
그다음에 제어 클래스라고 하는 부분 자체는 로그인 페이지에서 아이디하고 비밀번호를 입력을 하고 로그인 버튼을 눌렀을 때 처리가 진행되어지는 네, 뭐 jsp든 bhp든 asp든 서브 단에서 입력한 아이디와 비밀번호를 받고 그다음에 데이터베이스하고 연결을 해요. 회원 가입한 테이블인 멤버 테이블 내에 해당 이 아이디 사용자가 있느냐를 따져서 있어 그러면 두 번째는 비밀번호가 맞느냐 맞아 그러면 로그인 시켜주고 그렇지 않으면 에러 메시지를 띄워주는 거죠. 그와 관련해서 세 가지 클래스 경계 클래스는 화면 엔트 클래스는 데이터베이 스테이블 제어 클래스는 해당 컨트롤하는 네 웹페이지 서버 페이지가 되겠습니다. 그리고 스테레오 타입으로 표시를 한다. 이렇게 돼 있는데요. 양쪽 끝에 이렇게 껍새껍새 이렇게 묶어 가지고 표현하는 것을 스테레오타입이라고 이야기를 합니다. 분석 클래스의 스테로타입 표현 방식은 두 가지가 있는데, 일단 클래스 필름에 꺾쇠 꺾쇠 바운더리 이렇게 해도 되구요.

1:06:30
네 모양적인 측면에서 요렇게 또 다이어그램 형태로 해가지고 이렇게 표시를 해도 됩니다. 두 가지 표기 방법이 있습니다. 경계 다이어그램은 시스템과 외부 액터의 상호작용을 담당하는 클래스라 즉 화면이라고 보면 되겠구요. 네 화면 네 그다음에 엔터티는 데이터가 저장되어지는 테이블이라고 보면 되겠고 제어는 해당 로직 제어를 담당하는 클래스가 되겠습니다. 네 동그라미의 꺾쇠 이렇게 화살표 모양 또는 동그라미 밑에 네 선음 표기 엔터티 바운더리는 화면 이렇게 돼 있습니다. 세부적으로는 경계와 제어 클래스의 도출 여부 및 상세한 정도 확인으로서 경계 클래스는 유지 클래스와 연결되어진 액터가 있고 이 유드 케이스가 해당 시스템에 제공하는 기능이라고요.

1:07:25
이 기능을 이용하는 액터 행위자가 있고 액체의 유형이 시스템 또는 장비인 경우는 해당 액체를 위한 경계 클래스가 도출되었는지 확인한다. 이렇게 돼 있습니다. 해당 액터가 꼭 사람만이 아니다라고 말씀드렸죠 다른 시스템이나 다른 장비가 될 수도 있어요. 네 그런 경우에 해당 액터를 위한 경계 클래스도 주셨는지 확인 뉴스 케이스 명세서에 이벤트 흐름을 확인을 하여 조직 케이스에서 필요로 하는 ui는 유저 인터페이스예요. 사용자 인터페이스 두 아이를 위한 경계 클래스가 도출되는지 확인한다. 다음 ui를 위한 경계 클래스인 경우는 사용 벤트페이스 화면이라는 말입니다. 화면의 경우는 사용자에게 제공할 항목이 속정으로 노출되었는지 확인하고 화명 보고서장의 데이터 타입 길이가 경계 클래스 속성 동의와 일치하는지 확인합니다.

1:08:26
제어 클래스입니다. 제어 클래스는 유즈 케이스별로 제어 클래스가 1개 이상 노출했는지 확인하고 제어 클래스의 연산에 대응하는 엔터틱 클래스가 있는지 확인한다. 제어 클래스에서 로그인이라고 말씀을 드렸잖아요. 아까 예제로 아이디 비밀번호를 입력하고 로그인 버튼 눌렀을 때 철회하는 게 제어 클래스인데 얘가요 해당 회원 가입한 정보값을 가지고 와야 돼요. 가지고 오는 대상은 데이터베이스 테이블인데 그게 엔터티 클래스입니다. 유스케이스 명세에서 기술되어진 이벤트 흐름을 처리하기 위한 연산이 제어 클래스에 정의되어 있는지 확인합니다. 클래스 간의 관계입니다.

1:09:08
클래스 간 관계 클래스 정보의 상세와 정도 확인으로서요 먼저 관계는 유스케이스 명세서를 기반으로 각 클래스와의 관계를 정의하는지 확인하는데 관계의 다중성이 정확하고 모순이 없는지 확인하자 그리고 2개의 클래스 간에 1개 이상의 관계가 존재하며 그 관계 이름 또는 역할이 정의되어 있는지 확인합니다. 연산 및 속성의 상세와 뉴스 케이스 명세서를 바탕으로 해서요. 클래스의 속성 클래스가 가지는 변수라고 보면 돼요. 회원 가입 테이블이야 이름 연락처 주소 이런 것들이 속성입니다. 속성과 연산이 도출되느냐 연산은 동작입니다. 동작 배출되어진 그러니까 연산 같은 경우에는 핸터티 클래스는 연산이 없어요. 제어 클래스는 연산 중심적입니다. 제어 클래스는 동작 중심적이죠.

1:10:06
콘텐츠 클래스는 데이터 저장 중심도이고 도출되어진 연산의 매개변수명 매개변수 타입 매개변수 길이와 return 타입이 정의되어 있는지 확인합니다. 도출되어진 클래스의 속성평과 속성의 타입 속성의 길이가 이해관계자 간에 이견이 없도록 명확하게 정의되어 있는지 확인합니다. 자 속성의 길이라고 하는 부분은 해당 어 회원가입 테이블에 입력하는 입력값 중에 데이터베이스에 저장되어질 때 이 길이 있죠. 네 고정적인 문자열을 가지는 것들도 있지만 가변적인 것들도 있잖아요. 어쨌든 최대 크기 값이 입력한 값보다 적게 설정됐으면 입력을 못하는 오류가 발생할 수 있거든요. 정규 클래스의 속성과 화면 보고의 항목 엔터티 클래스의 속성 정보가 일관성을 가지는지 확인합니다. 분석 클래스 다이어그램의 예시입니다. 여기서는 이제 이게 분석 클래스의 이름이고요.

1:11:05
분석 클래스명이고 그 위에 해당 스테레오 타입으로 바운더리라고 돼 있으면 얘는 화면이에요. 공인 인증서로 로그인한 화면이야 해당 속성은 공인 인증 성공 여부고 해당 오퍼레이션은 로그인이다. 이렇게 돼 있고요. 컨트롤 클래스 같은 경우에는 로그인 제어를 한 뒤 입력한 값을 받아가지고, 여기서는 이제 오퍼레이션이 컨트롤은 지금 보면 밑에 세 번째 네 갈록 꼬르미를 가지는 오퍼레이션만 가져요 근데 엔터티는 3개의 구분값 중에 마지막 건 안 가지고 중간에 속성만 가져요 네 엔터티 이름과 다 서로 간에 연결되어 있다. 이 부분도 있고 로그인 과정을 예로 하고 있습니다.

1:11:51
여기서는 이제 공인인증서를 통해서 로그인하는 부분을 해놨는데 네 어 로그인 제어에서는 네 회원 테이블에서 이 사람이 회원 가입한 사람이 마저 혹시 아니면 비회원인 경우에는 비회원에 대한 로그인할 때 뭐 이러한 것들을 저장할 거야. 네 그와 관련되어서 필요한 해당 클래스가 정의돼 있고 연관되어 있습니다. 자 분석 모델 검정 퀴즈입니다. 유스 케이스 모델 검증 수행할 때 적절하지 않은 건 뭐야? 유즈 케이스 모델 검증입니다. 유즈 케이스 모델에서는 팩터 도출 유즈 케이스 도출 유스 케이스 명세서 uml의 스테레오타입은 클래스 클래스 다이어그램과 관련된 부분입니다. 그래서 4번이 틀렸어요. 자 두 번째 섹션으로서 분석 모델의 시스템화 타당성 분석에 대해 살펴보도록 하겠는데요.

1:12:45
먼저 분석 모델의 기술적 타당성 검토로서 분석 모델의 기술 타당성 검토는 성능 및 용량 산정의 적정성 시스템 간 상호 운용성 시장 성숙도 및 트렌드 부합성 마지막으로, 기술적 위험 분석 순으로 살펴보도록 하겠는데 구축 타당성 여부를 최종적으로 검토하는 단계에서 수행을 합니다. 성능 및 용량은 요구 사항을 만족시키기 위한 분석 모델에 따라서 시스템을 구현할 때 요구되는 시스템 자원을 식별할 수 있겠고 분석 클래스에서 불필요하고 지나치게 많은 속성을 포함시키게 되면 오히려 객체를 생성할 때 시스템 내에 메모리 자원을 너무 많이 요구를 하고 해당 처리 속도가 높아지는 게 아니라 떨어질 수 있다.

1:13:39
이로 인해서 jvm 자바 보트롤 머신에서 아도한 가비즈 쓰레기 컬렉션 가비즈 컬렉션이 발생해서 전체 시스템 성능 저하가 발생할 수 있기 때문에 필요로 한 꼭 필요로 한 클래스 내의 속성들만 포함시켜라 이 말입니다. 두 번째 시스템 간 상호 운용성 분석 모델을 이용을 해서 보다 구체적으로 시스템 간의 상호 정보 및 서비스를 교환 가능한지 검토하고요. 분석 모델에서 정의한 구체적 정보의 존재 여부 생성 가능성 교환 방식 지원 등에 대해서 확인하는 단계입니다.

1:14:22
시장 성숙도 및 트렌드 부합성 분석 모델이 과거의 문제를 해결하고 많이 사용되는 트렌드에 부합한지 확인하자 시스템에 중요하고 빈번하게 사용되는 클래스는 해당 프로토타입 빈으로 적용을 해서 이용하는 게 효과적이다. 네 번째 기술적 위험 분석입니다. 분석 모델이 시스템의 기술 구조와 프레임워크 그리고 하드웨어 및 소프트웨어와 부합한지 여부를 확인하는 과정이고요. 분석 모델이 검증되지 않은 기술을 사용한다 라고 할 때는 추가적으로 비용 발생이 가능하겠다라는 부분을 고려해야 되겠고 분석 모델을 구현하기 위해서 특정 업체 기술이나 토커 라이센스에 너무 의존하는 건 아닌지 토 체킹할 필요성이 있겠습니다.

1:15:15
분석 모델 시스템화 타당성에 대한 퀴즈 한 문제 풀어보면 분석 모델의 기술적인 부합성 검토 사항이 아닌 것은 무엇일까? 첫 번째 성능 및 용량 두 번째 시장 성취도 및 트렌드 부합성 그리고 세 번째 시스템과 상호 운용성 네 번째 분석 클래스 검정 네 번째가 아니죠. 성능 및 용량 시장 성적 및 트렌드 부합성 실생과 상호 운용성 그리고 기술 위험성 자 해당 이 챕터를 정리하면서요 네 평가 문제 세 문제 풀어보고 정리하도록 하겠습니다. 첫 번째 분석 모델링 검증 절차가 맞게 나열되어진 것은 첫번째 유지캐스트 모델 검증 개념 수준 분석 클래스 검증 분석 클래스 검증 첫 번째가 정답입니다.

1:16:10
네 분석 모델링 검증 절차는 유스케이스 모델 개념 수준 분석 클래스 분석 클래스 검증 순으로 검증합니다. 두 번째 분석 클래스 검증을 위한 요소로서 거리가 먼 것은 첫 번째 유즈 케이스 실행에 필요한 분수 클래스의 도출 확인 두 번째 경계 클래스의 도출 여부 및 상세와 정도 확인 세 번째 제어 클래스의 도출 여부 및 상세와 정도 확인 네 번째 요구 기능 구현을 필요로 하는 유즈 케이스가 모두 도출되어졌는지를 확인한다. 분석 클래스 검증을 위한 요소입니다. 네 정답은 네 번째 요구 기능 구현을 위한 뉴스 케이스가 뭐 들렸는지 확인한다. 앞부분에 저희가 분수 클래스 검정에서 단계별로 살펴봤던 것 중에 아닌 걸 고르면 되겠습니다.

1:17:10
세 번째 분석 모델의 기술적 검토 요소 중에 분석 모델을 통한 시스템 간 상호 정보 및 서비스 교환 가능성을 검토하는 것은 어떤 검토 요소인가 시스템 간 상호 정보 및 서비스 교환 가능성 검토는 시스템 간 상호 운영성에 해당되어지겠죠. 정답은 2번이 되겠습니다. 핵심 내용으로 첫 번째 섹션 살펴봤던 분석 모델 검증에서 중요 사항은 분석 모델링 검증은 도출되어진 요구 사항에 대해서 분석 모델을 확인하고 이에 대한 추가적 필요 의견을 제시하는 단계다 분석모델검증은 유스캐스모델검증 개념 수준의 분석 클래스 검증 마지막으로, 분석 클래스 검증 순으로 진행이 되어졌었습니다.

1:18:02
두 번째 섹션인 분석 모델 시스템화 타당성 분석은 유스케이스 모델의 개별 유스케이스에 대한 분석 모델을 작성한 이후에 해당 분석 모델로 시스템을 개발하는 경우 어떠한 영향을 미치는지 성능 및 용량 등 필요 자원에 대한 적정성과 상호 운용성 시장 성숙도 및 트렌드 보합도 기술적 위험 분석 측면에서 타당성을 조사했습니다. 분석 모델의 시스템으로서의 구축 타당성 여부를 최종적으로 검토하는 단계에서 진행이 됐죠 네 이상으로 소프트웨어 설계 요구 사항 확인의 세 번째 섹션이었던 분석 모델 확인하기에 대해 살펴봤습니다.