[Note] 2021 정보처리기사 실기 요약 정리 공유 | 01. 요구사항 확인

[Note]

정보처리기사 실기 요약 정리 공유

01. 요구사항 확인

---

01. 현행 시스템 분석

TCP & IP

• 인터넷 프로토콜인 IP(인터넷 프로토콜)와 전송 조절 프로토콜인 TCP(전송 제어 프로토콜)로 이루어져 있다.
• IP는 패킷 전달 여부를 보증하지 않고 패킷을 보낸 순서와 받는 순서가 다를 수 있다. TCP는 IP위에서 동작하는 프로토콜로, 데이터의 전달을 보증하고 보낸 순서대로 받게 해준다.

소프트웨어 아키텍쳐 (SCLP)

1. 개념
- 여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중에서 외부에 드러나는 특성, 그리고 구성요소 간의 관계를 표현하는 시스템의 구조나 구조체를 의미한다.
- 또한, 소프트웨어를 설계하고 전개하기 위한 지침이나 원칙이다.

2. 소프트웨어 아키텍쳐 4+1뷰 (유논프구배)
1) 유스케이스 뷰
- 아키텍쳐를 도출하고 설계하는 작업 주도
- 다른 뷰를 검증하는데 사용
💡 유스케이스(Use Case)
- 시스템이 액터에게 제공해야 하는 기능으로서 시스템 요구사항이자,
- 사용자 입장에서 바라본 시스템의 기능

2) 논리 뷰
- 설계 모델의 추상화, 주요 설계 패키지와 서브 시스템, 클래스를 식별하는 뷰
- 시스템의 기능적인 요구사항 지원
- 클래스 다이어그램으로 표현

3) 구현 뷰
- 정적인 소프트웨어 모듈(소스 코드, 데이터 파일, 컴포넌트, 실행 파일 등)의 구성을 표현하는 뷰
- 개발자 관점에서 소프트웨어 구현과 관리적인 측면을 컴포넌트 다이어그램으로 표현
- 컴포넌트 뷰라고 하기도 함

4) 프로세스 뷰
- 런타임 시의 시스템의 Task, Thread, Process와 이들 사이의 상호작용 등의 관계를 표현하는 뷰
- 비기능적인 요구사항을 고려

5) 배포 뷰
- 물리적인 노드의 구성과 상호 연결 관계를 배포 다이어그램으로 표현
- 다양한 실행 파일과 다른 런타임 컴포넌트가 해당 플랫폼 또는 컴퓨팅 노드에 어떻게 매핑되는가를 보여주며,
가용성, 신뢰성, 성능, 확장성 등의 시스템의 비기능적인 요구사항을 고려

런타임 (Runtime)

• 컴퓨터 프로그램이 실행되고 있는 동안의 동작 상태

인터페이스 (Interface)

• 관련이 없는 것들이 서로 연결되기 위한 디바이스나 시스템을 의미한다.

프로토콜 (Protocol)

• 서로 다른 시스템에 있는 두 개체간의 데이터 교환을 원활히 하기 위한 일련의 통신규약이다.

프레임워크 (Framework)

• 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 클래스들을 제공하는 틀이다.

OSI 7계층

---

1 계층 물리 계층(Physical Layer)

• 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환
• 실제 장비들을 연결하기 위한 연결 장치
• 전송단위 : Bit(비트)
• 장비 : 허브, 리피터

2 계층 데이터 링크 계층(Data Link Layer)

• 인접 시스템 간 데이터 전송, 전송오류 제어
• 동기화, 흐름 제어 등의 전송 기능 제공
• 오류와 흐름을 제거하여 신뢰성 있는 데이터를 전송
• 전송단위 : Packet(패킷)
• 프로토콜 : 이더넷
• 장비 : 브리지, 스위치

3 계층 네트워크 계층(Network Layer)

• 단말 간 데이터 전송을 위한 최적화된 경로 제공
• 다수의 중개 시스템 중 올바른 경로를 선택하도록 지원
• 전송단위 : Frame(프레임)
• 프로토콜 : IP, ICMP
• 장비 : 라우터, 게이트웨이, 유무선 인터넷 공유기, 망 스위칭 허브

4 계층 전송 계층(Transport Layer)

• 신뢰성 있는 통신 보장. 데이터 분할과 재조립, 흐름 제어, 오류 제어, 혼잡 제어 등을 담당함.
• 송신, 수신 프로세스 간의 연결
• 전송단위 : Segment(세그먼트)
• 프로토콜 : TCP, UDP
• 장비 : L4 스위치

5 계층 세션 계층(Session Layer)

• 연결 접속 및 동기 제어
• 송신, 수신 간의 논리적 연결
• 전송단위 : Data(데이터)
• 프로토콜 : SSH, TLS
• 장비 : 호스트 (PC 등)

6 계층 표현 계층(Presentation Layer)

• 데이터 형식 설정과 부호교환, 암/복호화
• 코드 문자 등을 번역하여 일관되게 전송하고 압축, 해제, 보안 기능도 담당
• 전송단위 : Data(데이터)
• 프로토콜 : JPEG, MPEG
• 장비 : 호스트 (PC 등)

7 계층 응용 계층(Application Layer)

• 사용자와 네트워크 간 응용서비스 연결
• 사용자 친화 환경 제공(이메일, 웹 등)
• 전송단위 : Data(데이터)
• 프로토콜 : HTTP, FTP
• 장비 : 호스트 (PC 등)

네트워크 (Network)

• 컴퓨터 장치들의 노드 간 연결(데이터 링크)을 사용하여 서로에게 데이터를 교환할 수 있도록 하는 기술이다.
• 데이터 링크들은 광케이블과 같은 유선 매체 또는 와이파이(Wi-Fi)와 같은 무선 매체를 통해 확립된다.

허브 (Hub)

• 여러 대의 컴퓨터를 연결하여 네트워크로 보내거나, 하나의 네트워크로 수신된 정보를 여러 대의 컴퓨터로 송신하기 위한 장비

브리지

• 두 개의 근거리통신망(LAN)을 서로 연결해주는 통신망 연결 장치

라우터 (Router)

• OSI 3계층에서 사용하는 네트워크 장비로 스위치를 서로 연결하여 네트워크 간 비용소모가 최적화된 라우팅 경로를 설정하고, 결정된 경로를 따라 트래픽을 전달하는 역할을 하는 장비이다.
• LAN과 LAN을 연결하거나 LAN과 WAN을 연결하기 위한 인터넷 네트워킹 장비
• 패킷의 위치를 추출하여, 그 위치에 대한 최적의 경로를 지정하며, 이 경로를 따라 데이터 패킷을 다음 장치로 전송시키는 장비
• 라우팅 프로토콜은 경로 설정을 하여 원하는 목적지까지 지정된 데이터가 안전하게 전달되도록 함.

스위치 (Switch)

• L2 스위치 : 2계층 장비로써, 동일 네트워크 내에서 출발지에 들어온 데이터 프레임을 목적지 MAC 주소 기반으로 빠르게 전달하는 네트워크 장비이다.
• L3 스위치 : 프로토콜을 서로 다른 통신망에 접속할 수 있게 해주는 장치. LAN에서 다른 네트워크로 보내거나 다른 네트워크로부터 데이터를 받아들이는 출입구 역할
• L4 스위치 : 네트워크 단위들을 연결하는 통신 장비. TCP/UDP 등의 스위칭 수행. 로드밸런싱 기능(정교한 로드 밸런싱 수행 불가). 포트포워딩 결정.

방화벽 (Firewall)

• 외부로부터 불법 침입과 내부의 불법 정보 유출을 방지하고, 내/외부 네트워크의 상호간 영향을 차단하기 위한 보안 시스템이다.

백본망 (Backbone Network)

• 다양한 네트워크를 상호 연결하는 컴퓨터 네트워크의 일부로서, 각기 다른 LAN이나 부분망 간에 정보를 교환하기 위한 경로를 제공하는 망이다.

게이트웨이 (Gateway)

• 컴퓨터 네트워크에서 서로 다른 통신망, 프로토콜을 사용하는 네트워크 간의 통신을 가능하게 하는 네트워크 장비이다.
• LAN에서 다른 네트워크에 데이터를 보내거나 다른 네트워크로부터 데이터를 받아들이는 출입구 역할

미들웨어 (Middleware)

• 미들웨어는 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간에 원만한 통신이 이루어질 수 있도록 제어해주는 소프트웨어이다.
• 운영체제와 소프트웨어 애플리케이션 사이에 위치하고 있다.
• 대표적인 미들웨어로는 WAS가 있다.

WAS (Web Application Server)

• 서버계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜젝션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 서버다.

가비지 컬렉션 (GC : Garbage Collection)

• 메모리 관리 기법의 하나로, 프로그램이 동적으로 할당했던 메모리 영역 중에서 필요 없게 된 영역을 해제하는 기능이다.

02. 요구사항 확인

기능적 요구사항

• 시스템이 제공하는 기능, 서비스에 대한 요구사항
• 특징 : 기능성 / 완전성 / 일관성 (기완일)

비기능적 요구사항

• 시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항
• 특징 : 신뢰성 / 사용성 / 효율성 / 유지보수성 / 이식성 (신사효유이)

요구사항 개발 프로세스 (도분명확)

1. 요구사항 도출
   • 요구사항이 어디에 있고, 어떻게 수집할 것인지를 파악하는 단계
   • 이해관계자가 요구사항을 식별, 개발팀과 고객 사이의 관계가 형성
   • 다양한 이해관계자와 효율적인 의사소통 중요
2. 요구사항 분석
   • 상충되는 요구사항을 해결하고, 소프트웨어의 범위 파악, 소프트웨어가 환경과 어떻게 상호 작용하는지 이해하는 단계
3. 요구사항 명세
   • 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계
   • 요구사항 명세에서는 시스템 정의, 시스템 요구사항, 소프트웨어 요구사항을 작성
4. 요구사항 확인
   • 요구사항 문서가 표준에 적합하고 이해 가능하며, 일관성이 있고, 완전한지 검증하는 단계

요구사항 검증 기법

• 동료 검토
  • 2~3명이 진행하는 리뷰의 형태
  • 요구사항 명세서 작성자가 요구사항 명세서를 설명하고 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행.
• 워크 스루
  • 오류를 조기에 검출하는 데 목적
  • 검토 자료를 회의 전에 배포해서 사전검토한 후 짧은 시간동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서화.
• 인스펙션
  • 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법.

유스케이스 다이어그램 (Usecase Diagram)

• 요구사항들 가운데서 기능적인 요구사항을 유스케이스란 단위로 표현하고 액터와 시스템의 관계를 표현한 다이어그램이다.

UML (Unified Modeling Language)

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

요구사항 확인 기법 (요프모인)

• 요구사항 검토
  • 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이를 검토
  • 고객 중심 프로젝트에서는 검토자 그룹에 고객 대표자 1명 이상 포함 필요
  • 시스템 정의서, 시스템 사양서, 소프트웨어 요구사항 명세서를 완성한 시점에서 검토
• 프로토타이핑
  • 새로운 요구사항을 도출하기 위한 수단 및 소프트웨어 요구사항에 대해 소프트웨어 엔지니어가 해석한 것을 확인하기 위한 수단으로 사용
  • 요구사항이 잘못된 경우 유용한 피드백 제공, 사용자 인터페이스의 동적인 행위가 문서나 그래픽 모델보다 이해 용이
  • 사용자가 요구한 주요 기능을 프로토타입으로 구현하여, 사용자의 피드백을 통해 개선, 보완하여 완성 소프트웨어를 만들어가는 기법.
• 모델 검증
  • 분석단계에서 개발된 모델의 품질 검증 필요
  • 객체 모델의 경우 객체들 사이의 존재하는 의사소통 경로를 검증하기 위한 정적 분석 수행에 유용
• 인수 테스트
  • 요구사항의 중요한 속성은 최종 제품을 기준으로 요구사항을 만족시키는지 확인이 가능해야 함.
  • 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획 수립 후, 요구사항을 확인하는 테스트.

비용 산정 모델

1. 하향식 산정방법
   1. 전문가 판단
      • 조직 내에 있는 경험이 많은 두 명 이상의 전문가에게 비용산정을 의뢰하는 기법.
   2. 델파이 기법 (전문가 합의법)
      • 전문가의 경험적 지식을 통한 문제해결 및 미래 예측을 위한 기법
      • 전문가들의 편견이나 분위기에 지배되지 않도록 한 명의 조정자와 여러 전문가로 구성
        < 키워드 : 전문가 경험, 비용산정 모델 >

2. 상향식 산정방법
   1. 코드 라인 수 (LoC : Line of Code)
      • 소프트웨어 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 중간치를 측정하여 예측치를 구하고
        이를 이용하여 비용을 산정. 측정이 쉽고 이해하기 쉬워 많이 사용.
      • 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정
   2. Man Month
      • 한 사람이 1개월 동안 할 수 있는 일의 양을 기으로 프로젝트 비용을 산정하는 기법
        ** Man Month = LoC / 프로그래머의 월간 생산성
        ** 프로젝트 기간 = Man Month / 프로젝트 인력
   3. COCOMO 모형
      • 보헴(Bohem)이 제안한 모형으로 프로그램 규모에 따라 비용을 산정. 개발 노력 승수를 결정.
      • 규모에 따라 단순형, 중간형, 임베디드형으로 나뉨.
   4. Putnam 모형
      • 소프트웨어 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 모형.
      • 자동화 추정 도구로 SLIM이 있음.
   5. FP (Function Point : 기능 점수) 모형
      • 요구 기능을 증가시키는 인자별로 가중치를 부여하여 기능 점수를 계산하여 비용을 산정하는 방식.
      • 입력, 출력, 질의, 파일, 인터페이스의 개수로 소프트웨어의 규모를 표현
      • 원시 코드의 구현에 이용되는 프로그래밍 언어에 독립적
      • 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치를 부여
      • 프로젝트의 영향도와 가중치의 합을 이용하여 기능점수를 계산
      • SW의 규모를 측정 및 예측하는 기법으로써 1979년 미국 IBM의 Allen J. Albrecht에 의해 제안되었다.
      • 최초 SW 개발 프로젝트의 규모측정 (SIZING)을 위해 고안되었으나, 현재는 SW 공학적 접근을 통한 다양한 방법으로 활용되고 있다.

---

틀린 내용이 있거나 문제가 있을시 알려주세요. 같이 공부해요 😊
이 글이 도움이 되셨다면 공감, 댓글 부탁드려요 👍🏻