개발노트

* 인터넷

: TCP / IP 프로토콜을 기반으로 하여 전 세계 수많은 컴퓨터와 네트워크들이 연결된 광범위한 컴퓨터 통신망

* IP주소

: 인터넷에 연결된 모든 컴퓨터 자원을 구분하기 위한 고유한 주소

* 서브네팅(Subnetting)

: 네트워크 주소를 여러 개의 작은 네트워크로 나누어 사용하는 것

* 네트워크

: 원하는 정보를 원하는 수신자 또는 기기에 정확히 전송하기 위한 기반 인프라

* 프로토콜 

: 서로 다른 시스템이나 기기들 간의 데이터 교환을 원활히 하기 위한 표준화된 통신규약.

데이터 처리 기능, 제어기능, 관리적 기능을 포함한다.

* TCP/IP(Transmission Control Protocol / Internet Protocol)

: 서로 다른 기종의 컴퓨터들이 데이터를 주고받을 수 있도록 하는 표준 프로토콜

* OSI 참조모델:

다른 시스템간의 원활한 통신을 위해 ISO(국제표준기구)에서 제안한 통신 규약.

* OSI 7계층:

1~3 계층을 하위계층, 4~7 계층을 상위 계층이라 한다.

* 계층별 네트워크 장비 및 프로토콜:

- 계층 1, 물리 계층

• 물리 계층 장비

• 물리계층 프로토콜

- 계층 2, 데이터 링크 계층

• 데이터 링크 계층 장비

• 데이터 링크 계층 프로토콜

- 계층 3, 네트워크 계층

• 네트워크 계층 장비

• 네트워크 계층 프로토콜

- 계층 4, 전송 계층

• 전송계층 프로토콜

- 계층 5, 세션 계층

• 세션계층 프로토콜

- 계층 6, 표현 계층

• 표현계층 프로토콜

- 계층 7, 응용 계층

• 응용계층 프로토콜

* 운영체제(OS; Operating System):

• 하드웨어를 쉽게 사용할 수 있도록 인터페이스를 제공해주는 소프트웨어
• 컴퓨터 시스템의 자원들을 효율적으로 관리, 편리하고 효과적으로 사용할 수 있도록 환경을 제공하는 프로그램의 모임

* 운영체제의 목적:

• 처리능력 : 일정 시간 내 시스템이 처리하는 일의 양
• 반환 시간: 시스템에 작업을 의뢰한 시간부터 처리가 완료될때까지 걸린 시간
• 사용 가능도: 시스템을 사용할 필요가 있을 때 즉시 사용 가능한 정도
• 신뢰도: 시스템이 주어진 문제를 정확하게 해결하는 정도

* 운영체제의 종류

1. Windows

• 1990년대 마이크로소프트 사가 개발한 운영체제

- Windows의 주요 특징

2. UNIX

• AT&T 벨 연구소,  MIT, General Electric이 공동 개발한 운영체제

- UNIX의 주요 특징

- UNIX의 시스템 구성

커널(Kernel) :

•  하드웨어 보호, 프로그램-하드웨어 간의 인터페이스 역할 담당.
• UNIX의 핵심 부분
• 프로세스 관리, 기억장치 관리, 파일 관리, 입/출력 관리, 프로세스간 통신, 데이터 전송 및 변환 등 수행

쉘(Shell): 

• 사용자의 명령어를 인식하여 프로그램을 호출, 명령 수행하는 명령어 해석기
• 시스템과 사용자 간의 인터페이스 담당
• 종류: Bourne Shell, C Shell, Korn Shell

유틸리티 프로그램 (Utility Program):

• 일반 사용자가 작성한 응용 프로그램을 처리하는 데 사용
• DOS애서의 외부 명령어에 해당됨
• 종류: 에디터, 컴파일러, 인터프리터, 디버거

3. LINUX

• 리누스 토발즈(Linus Torvalds)가 UNIX를 기반으로 개발한 운영체제

- 리눅스의 주요 특징

• 소스 코드가 공개된 오픈 소스 기반의 운영체제
• 다양한 플랫폼에 설치하여 사용이 가능하며 재배포가 가능
• UNIX와 호환가능하며 유닉스가 갖는 운영체제, 다중 작업 기능, 다중 사용자 기능, 이식성, 계층적 트리 구조 파일 시스템을 갖는다.

4. MacOS

• 1980년대 애플(Apple) 사가 UNIX를 기반으로 개발한 그래픽 사용자 인터페이스 기반 운영체제
• 드라이버 설치 및 인스톨, 언인스톨의 과정이 단순하다.
• 클라이언트 버전, 서버 제품 등으로 제품군을 확대 하였으며 지속적으로 업데이트를 하고있다.

5. 안드로이드(Android)

• 휴대전화를 비롯한 휴대용 장치를 위한 운영체제와 미들웨어, 사용자 인터페이스, 표준 응용 프로그램을 포함하는 운영체제
• Google사에서 개발한 모바일 운영체제

- 안드로이드 특징

* 운영체제 핵심 기능

- 기억장치 관리: 한정된 주기억장치의 공간을 효율적으로 사용

- 프로세스 관리: CPU와 데이터를 송수한 하는 상황에서 프로세스에 대한 종합적 관리 기법. 

ex) 동기화, 통신, 일시 중지 및 재실행, 교착상태 처리, 프로세스 생성 삭제

* 기억장치 관리의 종류

• 반입 Fetch 전략
• 배치 Placement 전략
• 교체 Replacement 전략

* 반입 전략: 프로그램이나 데이터를 언제 주기억장치로 적재할 것인지 결정 (When)

• 요구 반입(Demand Fetch): 실행중인 프로그램이 데이터 등의 참조를 요구할 때 적재하는 방법
• 예상 반입(Anticipatory Fetch): 실행중인 프로그램에 의해 참조될 프로그램이나 데이터를 미리 예상하여 적재

* 배치 전략: 프로그램이나 데이터를 주기억장치의 어디에 위치시킬것인지 결정 (Where)

• 최초 적합(First Fit): 프로그램이나 데이터가 들어갈 수 있는 크기의 빈 영역중 첫번째 분할 영역에 배치
• 최적 적합(Best Fit): 프로그램이나 데이터가 들어갈 수 있는 크기의 빈 영역중 단편화를 가장 작게 남기는 영역에 배치
• 최악 적합(Worst Fit): 프로그램이나 데이터가 들어갈 수 있는 크기의 빈 영역중 단편화를 가장 많이 남기는 영역에 배치

* 교체 전략: 이미 사용되고 있는 영역 중에서 어느 영역을 교체하여 사용할 것인지 결정 (Who)

• FIFO, OPT, LRU, LFU, NUR, SCR

* 주기억장치 할당: 프로그램이나 데이터를 실행시키기 위해 어떻게 할당할것인지에 대한 내용

* 주기억장치 할당 기법의 분류:

1. 연속 할당 기법: 프로그램을 주기억장치에 연속으로 할당하는 기법

- 단일 분할 할당 기법:

• 한순간에는 오직 한 명의 사용자만이 주기억장치의 사용자 영역을 사용
• 가장 단순한 기법으로 초기 운영체제에서 많이 사용
• 운영체제 보호를 위해 운영체제 영역, 사용자 영역을 구분하는 경계 레지스터 사용
• 프로그램의 크기가 작을수록 사용자 영역 낭비
• 종류:

• 오버레이 기법(Overlay): 주기억장치보다 큰 사용자 프로그램을 실행하기 위한 기법
• 스와핑 기법(Swapping): 하나의 프로그램 전체를 주기억장치에 할당하여 필요에 따라 다른 프로그램과 교체

- 다중 분할 할당 기법:

• 고정분할 할당 기법(정적 할당 기법): 프로그램을 할당하기 전에 운영체제가 주기억장치의 사용자 영역을 여러 개의 고정된 크기로 분할하고 준비상태 큐에서 준비중인 프로그램을 각 영역에 할당하여 수행
• 가변 분할 할당 기법(동적 할당 기법): 고정 분할 할당 기법의 단편화를 줄이기 위해 사용. 프로그램을 주기억장치에 적재하며 필요한 만틈의 크기로 영역 분할

2. 분산 할당 기법: 가상기억장치 관리 기법. 가상기억장치의 내용을 주기억장치에 할당하기 위한 기법. 프로그램을 특정 단위의 조각으로 나누어 주기억장치 내에 분산하여 할당

- 페이징(Paging)기법:

• 프로그램과 주기억장치의 영역을 동일한 크기로 나눈 후, 주기억장치의 영역에 적재시켜 실행
• 주소 변환을 위해 페이지의 위치 정보를 갖고있는 페이지 맵 테이블(Page Map Table)이 필요.
• 페이지 맵 테이블 사용으로 비용 증가, 처리 속도 감소.
• 외부 단편화는 없지만 내부 단편화 발생 가능.

- 세그먼테이션(Segmentation) 기법:

• 프로그램을 다양한 크기의 논리적인 단위로 나눈 후 주기억장치에 적재시켜 실행.
• 기억공간을 절약하기 위해 사용.
• 주소변환을 위해 세그먼트 존재 위치 정보를 갖고 있는 세그먼트 맵 테이블(Segment Map Table)이 필요.
• 내부 단편화는 없지만 외부 단편화 발생 가능.

* 가상기억장치(Virtual Memory):

• 보조기억장치의 일부를 주기억장치처럼 사용하는 것.
• 용량이 작은 주기억장치를 마치 큰 용량을 가진 것처럼 사용.
• 프로그램을 여러 개의 작은 블록 단위로 나누어서 가상기억장치에 보관 후, 프로그램 실행 시 요구되는 블록만 주기억장치에 불연속적으로 할당하여 처리.
• 주기억장치의 이용률과 다중 프로그래밍의 효율을 높일 수 있다.
• 블록 단위로 나누어 사용. 
• 연속 할당 방식에서 발생할 수 있는 단편화 해결.

* 주소변환:

• 주소 사상 / 주소 매핑(Mapping)
• 가상기억장치에 있는 프로그램이 주기억장치에 적재되어 실행될 때 논리적인 가상주소를 물리적인 실기억주소로 변환하는 것.
• 인위적 연속성: 연속적인 가장주소가 반드시 연속적인 실기억주소로 변환되지 않아도 됨

* 페이지(Page):

• 프로그램을 일정한 크기로 나눈 단위

* 페이지 프레임(Page Frame):

• 페이지 크기로 일정하게 나누어진 주기억장치의 단위

* 세그먼트(Segment):

• 배열이나 함수 등과 같은 논리적인 크기로 나눈 단위.
• 각 세그먼트는 고유한 이름과 크기를 갖는다.

* 페이지 교체 알고리즘

:  페이지 부재(Page Fault)가 발생하면 어떤 페이지 프레임을 선택, 교체할것인지 결정하는 기법.

* 참조비트: 페이지가 호출되지 않았을때는 0, 호출되었을 때는 1로 지정됨

* 변형비트: 페이지 내용이 변경되지 않았을 때는 0, 변경되었을 때는 1로 지정됨

* 페이지 크기에 따른 영향

* Locality(국부성, 지역성, 구역성, 국소성):

• 프로세스가 실행되는 동안 주기억장치를 참조할 때 일부 페이지만 집중적으로 참조하는 성질.
• 스레싱을 방지하기 위한 워킹 셋 이론의 기반이 됨
• 가상기억장치 관리와 캐시 메모리 시스템의 이론적인 근거
• 데닝(Denning) 교수가 개념 증명

- Locality의 종류

• 시간 구역성(Temporal Locality): 한번 참조한 페이지는 가까운 시일 내에 계속 참조할 가능성이 높음
• 공간 구역성(Spatial Locality): 한 페이지를 참조하면 그 근처의 페이지를 계속 참조할 가능성이 높음

* 워킹 셋(Working Set)

• 프로세스가 일정 시간 동안 자주 참조하는 페이지들의 집합
• 데닝(Denning)이 제안한 프로그램의 움직임에 대한 모델
• 프로그램의 Locality 특징을 이용
• 자주 참조되는 워킹 셋을 주기억장치에 상주시킴으로써 페이지 부재 및 페이지 교체현상이 줄어들어 프로세스의 기억장치 사용이 안정됨

* 스레싱(Thrashing)

• 프로세스의 처리 시간보다 페이지 교체에 소요되는 시간이 더 많아지는 현상
• 시스템에서 하나의 프로세스 수행 과정 중 자주 페이지 부재(Page Fault)가 발생함으로써 나타남
• 전체 시스템의 성능 저하 야기
• 다중 프로그래밍의 정도가 높아짐에 따라 CPU 이용률은 높아지지만 특정 시점 이후 스래싱이 나타나면 CPU 이용률이 급격히 감소

* 페이지 부재(Page Fault)

: 프로세스 실행 시 참조할 페이지가 주기억장치에 없는 현상. 

*페이지 부재 빈도(Page Fault Frequency)

: 페이지 부재가 일어나는 횟수

*다중 프로그래밍의 정도

: 얼마나 많은 프로그램이 동시에 수행되는지의 정도.

* 프로세스(Process)

• PCB를 가진 프로그램
• 실기억장치에 저장된 프로그램
• 프로세서가 할당되는 실체로서 디스패치가 가능한 단위
• 프로시저가 활동중인 것
• 비동기적 행위를 일으키는 존재
• 목적 또는 결과에 따라 발생되는 사건들의 과정

* 프로시저: 부프로그램. 분할된 작은 프로그램

* 비동기적 행위: 다수의 프로세스가 서로 규칙적/연속적이지 않고 독립적으로 실행되는 것

* PCB(Process Control Block, 프로세스 제어 블록)

: 운영체제가 프로세스에 대한 중요한 정보를 저장해놓는 곳. 각 프로세스가 생성될 때 고유의 PCB이 생성되고 프로세스 완료시 제거됨.

- PCB에 저장되어 있는 정보

• 프로세스의 현재 상태
• 포인터
• 프로세스 고유 식별자
• 스케줄링 및 프로세스의 우선순위
• 주기억장치 관리 정보
• 입/출력 상태 정보
• 계정 정보

* 프로세스의 상태 전이

: 프로세스가 시스템 내 존재하는 동안 프로세스의 상태가 변하는 것

- 프로세스 상태:

• 제출 (Submit) - 작업을 처리하기 위해 시스템에 제출된 상태
• 접수 (Hold) - 제풀된 작업이 스풀 공간인 디스크의 할당 위치에 저장된 상태
• 준비 (Ready) - 프로세스가 프로세서를 할당받기 위해 기다리는 상태
• 실행 (Run) - 준비상태 큐에 있는 프로세스가 프로세서를 할당받아 실행되는 상태
• 대기 / 블록 (Wait/Block) - 프로세스에 입/출력 처리가 필요하면 현재 실행중인 프로세스 중단, 입/출력 처리가 완료될 때까지 대기하는 상태
• 종료 (Terminated,Exit) - 프로세스의 실행이 끝나고 프로세스 할당이 해제된 상태

- 프로세스 상태 전이 관련 용어:

• Dispatch : 준비상태의 프로세스가 프로세서를 할당받아 실행 상태로 전이되는 과정
• Wake Up: 입/출력 작업이 완료되어 프로세스가 대기 상태에서 준비상태로 전이 되는 과정
• Spooling: 입/출력 장치의 처리속도 보완, 다중 프로그래밍 시스템 성능 향상을 위해 디스크에 저장하는 과정
• Timer run out 타이머 런 아웃: CPU를 할당받은 프로세스는 시간 초과시 스케줄러에 의해 PCB저장, CPU반납 후 실행상태에서 준비상태로 전이
• Traffic Controller 교통량 제어기: 프로세스의 상태에 대한 조사와 통보 담당

* 스레드 (Thread)

• 경량 프로세스
• 시스템의 여러 자원을 할당받아 실행하는 프로그램의 단위
• 스레드 기반 시스템에서 독립적인 스케줄링의 최소 단위로서 프로세스의 역할을 담당
• 단일 스레드 : 하나의 프로세스에 하나의 스레드가 존재
• 다중 스레드 : 하나의 프로세스에 하나 이상의 스레드가 존재

* 스케줄링(Scheduling)

: 시스템의 여러 자원을 해당 프로세스에게 할당하는 작업

- 스케줄링의 종류

• 장기 스케줄링: 어떤 프로세스가 시스템의 자원을 차지할 수 있도록 할 것인지를 결정하여 준비상태 큐로 보내는 작업
• 중기 스케줄링: 어떤 프로세스들이 CPU를 할당받을 것인지 결정하는 작업
• 단기 스케줄링: 프로세스가 실행되기 위해 CPU를 할당받는 시기와 특정 프로세스를 지정하는 작업

- 스케줄링 주요 용어

- 프로세스 스케줄링 유형

1. 선점형 스케줄링

• 우선 순위가 높은 프로세스가 진행중인 프로세스를 중단시키고 CPU를 점유하는 스케줄링 방식 
• 빠른 응답 시간을 요구하는 대화식 시분할 시스템에 적합
• 실시간 응답환경 , Deadline 응답 환경에 적합
• 많은 오버헤드(Overhead) 초래
• 알고리즘:

2. 비선점형 스케줄링

• 한 프로세스에게 할당된 CPU는 작업 종료 후 CPU 반환 전 까지 다른 프로세스에게 점유가 불가능한 스케줄링 방식
• 프로세스 응답 시간의 예측이 용이
• 일괄 처리방식에 적합
• 처리시간 편차가 적은 특정 프로세스 환경에 적합
• 짧은 작업을 수행하는 프로세스가 긴 작업 종료시까지 대기함
• 알고리즘:  

* 시분할 시스템(Time Sharing System)

: 각 사용자들에게 컴퓨터 자원을 시간적으로 분할하여 사용할 수 있게 해주는 대화식 시스템

* 소프트웨어 개발 보안 설계:

요구사항 분석 - 설계 - 구현 - 테스트 - 유지보수

*소프트웨어 개발 보안 요소:

- 기밀성 Confidentiality :

• 정보가 전송 중 노출되더라도 데이터를 읽을 수 없음.
• 시스템 내의 자원은 인가된 사용자에게만 접근 허용

- 가용성 Availability:

• 권한을 가진 사용자나 애플리케이션의 원하는 서비스를 지속 사용할 수 있도록 보장하는 특성

- 무결성 Integrity:

• 정당한 방법을 따르지 않고선 데이터가 변경될 수 없음
• 데이터의 정확성 및 완전성, 고의/악의로 변경되거나 훼손 또는 파괴되지 않음

* SW 개발 보안 용어:

- 자산 Asset : 서버의 하드웨어, 기업의 중요 데이터.

- 위협 Threat : 해킹, 삭제, 자산의 불법적 유출, 위/변조, 파손

- 취약점 Vulnerability: 평문전송, 입력값 미검증, 비밀번호 공유

- 위험 Risk : 위협이 취약점을 이용하여 조직의 자산 손실 피해를 가져올 가능성

* 입력데이터 검증 및 표현: 입력데이터로 인해 발생하는 문제들을 예방하기 위해 구현 단계에서 검증해야 하는 보안 점검 항목들

* 공격기법 이해

1. DoS (Denial of Service) 서비스 거부 공격

: 대량의 데이터를 한 곳의 서버에 집중적으로 전송함으로써 서버의 정상적인 기능을 방해

 - Dos 공격의 종류: 

2. DDoS(Distributed DoS) 공격

: DoS 공격을 여러대의 공격자로 분산 배치하여 동시 동작하도록 특정 사이트 공격

- DDoS 공격 구성요소:

• 핸들러 Handler - 마스터 시스템의 역할을 수행하는 프로그램
• 에이전트 Agent - 공격 대상에 직접 공격을 가하는 시스템
• 마스터 Master - 공격자에게 직접 명령하는 시스템. 여러대의 에이전트를 관리.
• 공격자 Attacker - 공격을 주도하는 해커의 컴퓨터
• 데몬 프로그램 Daemon - 에이전트 시스템의 역할을 수행하는 프로그램

- DDoS 공격 도구:

• Trin00: 가장 초기 형태 데몬으로 UDP Flooding 공격을 수행. 몇개의 마스터들과 많은 수의 데몬들로 구성.
• TFN (Tribe Flood Network): UDP Flooding, TCP SYN Flooding 공격, ICMP 응답요청, 스머핑 공격 등을 수행.
• Stacheldraht : 공격자, 마스터, 에이전트가 쉽게 노출되지 않도록 암호화된 통신 수행

- DDoS 공격 대응방안:

• 차단 정책 업데이트
• 좀비PC IP 확보 : IP 위변조 여부 확인
• 보안 솔루션 운영: 방화벽, 침입탐지 시스템 등
• 홈페이지 보안 관리: 모의해킹등을 수행하여 보안 유지
• 시스템 패치: 시스템 취약점 패치

3. DRDoS (Distributed Reflection DoS) 공격

: 공격자가 출발지 IP를 공격 대상 IP로 위조하여 다수의 반사 서버로 요청 정보를 전송하고 공격 대상자는 반사 서버로부터의 다량 응답을 받아 서비스 거부 상태가 되는 공격.

- DRDoS 대응방안

• ISP (인터넷 서비스 사업자)가 직접 차단
• 반사 서버에서 연결을 완료하지 않은 Syn 출처 IP를 조사하여 블랙리스트 운용
• 공격 대상 서버  IP와 Port를 변경, 필터링하여 운영

4. 애플리케이션 공격 종류

5. 네트워크 서비스 공격 종류

6. 시스템 보안 위협

7.  보안 공격 기법

* 보안 방어 기법

- 사이버 킬체인 (Cyber Kill Chain)

: 록히드 마틴의 사이버 킬체인은 7단계 프로세스별 공격분석 및 대응을 체계화한 APT 방어 분석 모델

- 난독화 (Obfuscation)

: 코드의 가독성을 낮춰 역공학에 대한 대비를 위해 코드 일부, 혹은 전체를 변경.

* 개발 보안을 위한 암호화 알고리즘

- 대칭 키 암호방식: 암호화와 복호화에 같은 암호키를 사용.

• 블록 암호 방식: 고정 길이의 블록을 암호화. ex) DES, AES, SEED
• 스트림 암호 방식: 긴 주기의 난수열을 발생시켜 평문과 더물어 암호문 생성. ex) RC4

- 비대칭 키 암호방식: 공개 키, 개인 키가 존재하며 공개키는 누구나 알 수 있지만 개인키는 소유자만 알 수 있어야함.

- 해시 방식: 단방향 알고리즘으로서 임의의 데이터를 고정된 길의의 데이터로 매핑하는 함수.

원본 데이터를 유추하기 어려운 것을 이용. 연산 시간이 빠르다.

ex) SHA, MD5

* 시큐어 코딩: 잼재적인 보안 취약점을 사전에 제거하고 보안 요소들을 고려하며 개발하는 기법

* 시큐어 코딩 가이드

- 입력 데이터 검증 및 표현

- 보안 기능

- 시간 및 상태

- 에러 처리

- 코드 오류

- 캡슐화

- API 오용

* 입력데이터 검증 및 표현

* 취약점 분석/평가:

- 취약점 분석/평가 계획 수립 - 취약점 분석/평가 대상 선별 - 취약점 분석 수행 - 취약점 평가 수행

* 보안 인증: 로그인을 요청한 사용자의 정보를 확인하고 접근 권한을 검증하는 보안 절차.

* 보안 인증의 유형

- 지식 기반 인증: password, Passphrase, 아이핀

- 소유 기반 인증: 신분증, 토큰, 스마트카드, OTP

- 생체 기반 인증: 지문, 얼굴, 음성, 홍채

- 위치 기반 인증: 콜백, GPS나 IP주소

- 특징(행위)기반 인증: 서명, 동작

* 접근 통제: 데이터가 저장된 객체와 사용하려는 주체 사이의 정보흐름 제한

* 접근 통제 기법

- 식별(Identification): 인증 서비스에 스스로를 확인시키기 위해 정보를 공급하는 주체활동

- 인증(Authentication): 주체의 신원을 검증하기 위함

- 인가(Authorization): 인증을 통해 식별된 주체에게 접근을 허용하는 활동

- 책임추적성(Accountability): 주체의 접근을 추적하고 행동을 기록하는 활동

* 접근 통제 유형:

- 임의적 접근통제 (DAC)

: 사용자/ 그룹 신분 기반으로 접근 제한. 정보의 소유자가 보안 레벨을 결정, 이에 대한 정보의 접근 제어를 설정. 

유연한 접근 제어 서비스 제공. 객체별로 세분된 접근제어 가능

- 강제적 접근통제 (MAC)

:  주체가 갖는 접근 허가 권한에 근거하여 접근 제한. 시스템 정보의 허용 등급을 기준으로 제한. 중앙에서 정보를 수집, 분류하여 보안레벨 결정. 정책적으로 접근 제어 수행. 

기밀성이 중요한 조직에서 사용.

- 역할 기반 접근 통제 (RBAC)

: 중앙 관리자가 조직 내 맡은 역할에 기초하여 접근 제한. 직책에 대해 권한을 부여해서 효율적인 권한 관리 가능

* 보안 솔루션: 외부로부터의 불법적인 침입을 막는 기술 및 시스템

- 방화벽 (Firewall): 내부의 네트워크와 인터넷 간에 전송되는 정보를 선별하여 수용/거부/수정하는 기능을 가진 침입 차단 시스템

- 침입 탐지 시스템(IDS; Intrusion Detection System): 컴퓨터 시스템의 비정상적인 사용, 오용, 남용 등을 실시간으로 탐지하는 시스템.

• 오용 탐지(Misuse Detection): 미리 입력해둔 공격 패턴이 감지되면 알려준다.
• 이상 탐지(Anomaly Detection): 비정상적인 행위나 자원의 사용이 감지되면 알려준다.

- 침입 방지 시스템(IPS; Intrusion Prevention System)

: 비정상적인 트래픽을 능동적으로 차단, 격리하는 보안 솔루션.

방화벽과 침입탐지 시스템을 결합한 것. 패킷을 하나씩 검사 후 비정상적인 패킷이 탐지되면 방화벽 기능으로 차단.

- 데이터 유출 방지(DLP; Data Leakage/Loss Prevention)

: 내부 정보의 외부 유출을 방지하는 보안 솔루션

PC와 네트워크상의 모든 정보를 검색하고 행위를 탐지,통제하여 유출을 사전 방지

- 웹 방화벽(Web Firewall)

: 웹 기반 공격을 방어할 목적으로 만들어진 특화된 방화벽. 웹 관련 공격을 감시하고 서버에 도달하기 전에 차단.

- VPN(Virtual Private Network, 가상 사설 통신망)

: 공중 네트워크와 암호화 기술을 이용하여 사용자가 자신의 전용 회선을 사용하는 것 처럼 도와주는 보안 솔루션.

비용 부담을 줄일 수 있으며 지역적 제한이 없다.

- NAC(Network Access Control)

: 네트워크에 접속하는 내부 PC의 일관된 보안 관리 기능을 제공하는 보안 솔루션

- EMS(Enterprise Security Management)

: 로그 및 보안 이벤트를 통합하여 관리하는 보안 솔루션. 보안 솔루션간 상호 연동을 통해 종합적 보안 관리 체계 수립 가능.

* 테스트 오라클 Test Oracle: 테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법.

* 테스트 오라클의 특징:

- 제한된 검증

- 수학적 기법

- 자동화 가능

* 테스트 오라클의 종류:

- 참True 오라클

- 샘플링Sampling 오라클

- 추정 Heuristic 오라클

- 일관성 검사 Consistent 오라클

* 테스트 자동화 도구: 테스트 도구를 활동하여 반복적인 테스트 작업을 스크립트 형태로 구현

* 테스트 자동화 도구 유형:

- 정적 분석 도구 Static Analysis Tools

• 프로그램을 실행하지 않고 분석하는 도구

- 테스트 실행 도구 Test Execution Tools

• 스크립트 언어를 사용하여 테스트를 실행하는 도구
• - 데이터 주도 접근방식
• - 키워드 주도 접근방식

- 성능 테스트 도구 Performance Test Tools

• 가상의 사용자를 만들어 테스트를 수행함으로써 성능의 목표 달성 여부를 확인하는 도구

- 테스트 통제 도구 Test Control Tools

• 테스트 계획 및 관리, 테스트 수행, 결함 관리 등을 수행하는 도구

* 테스트 하네스  Test Harness

• 테스트가 실행될 환경을 시뮬레이션 하여 컴포넌트 및 모듈이 정상적으로 테스트되도록 하는 도구

* 테스트 하네스의 구성요소:

- 테스트 드라이버 Test Driver: 테스트 대상의 하위 모듈 호출, 파라미터 전달, 모듈 테스트 후의 결과를 도출하는 도구

- 테스트 스텁 Test Stub: 제어 모듈이 호출하는 타 모듈의 기능을 단순히 수행하는 도구

- 테스트 슈트 Test Suites: 테스트 대상 컴포넌트, 모듈, 시스템에 사용되는 테스트 케이스의 집합

- 테스트 케이스 Test Case: 입력값, 실행 조건, 기대 결과 등의 집합

- 테스트 스크립트 Test Script: 자동화된 테스트 실행 절차에 대한 명세

- 목 오브젝트 Mock Object: 사용자의 행위를 조건부로 입력해 두면 그 상황에 맞는 예정된 행위를 수행하는 객체

* 테스트 리포팅:

 - 테스트 결과 정리 - 테스트 요약문서 - 품질 상태 - 테스트 결과서 - 테스트 실행 절차 및  평가

* 결함 관리

* 결함 Fault: 소프트웨어가 개발자가 설계한 것과 다르게 동작하거나 다른 결과가 발생되는 것

* 결함 관리 측정 지표:

- 결함 분포: 모듈, 컴포넌트의 특정 속성에 해당하는 결함 수 측정

- 결함 추세: 테스트 진행 시간에 따른 결함 수의 추이 분석

- 결함 에이징: 특정 결함 상태로 지속되는 시간 측정

* 결함 분류:

- 시스템 결함: 애플리케이션 환경이나 데이터베이스 처리에서 발생된 결함

- 기능 결함: 애플리케이션의 기획, 설계, 업무 시나리오 등의 단계에서 유입된 결함

- GUI 결함: 사용자 화면 설계에서 발생된 결함

- 문서 결함: 기획자, 사용자, 개발자 간의 의사소통 및 기록이 원활하지 않아 발생된 결함

* 결함 관리 도구:

- Mantis

- Trac

- Redmine

- Bugzilla

* 테스트 커버리지 Test Coverage

: 테스트 범위를 측정하는 테스트 춤질 측정 기준

* 테스트 커버리지 유형:

- 기능 기반 커버리지: 실제 테스트가 수행된 기능의 수를 측정. 100% 달성을 목표

- 라인 커버리지: 소스 코드의 라인 수를 모수로 테스트 시나리오가 수행한 소스 코드의 라인 수 측정

- 코드 커버리지: 코드 자체가 얼마나 테스트되었는지를 측정

* 코드 커버리지 유형:

- 구문 커버리지

- 결정 커버리지

- 조건 커버리지

- 조건/결정 커버리지

- 변경 조건/결정 커버리지

- 다중 조건/결정 커버리지

* 애플리케이션 성능 분석

* 애플리케이션 성능: 최소한의 자원을 사용하여 최대한 많은 기능을 신속하게 처리하는 정도

* 애플리케이션 성능 측정 지표:

- 처리량 Throughput: 일정 시간 내에 애플리케이션이 처리하는 일의 양

- 응답 시간 Response Time: 애플리케이션에 요청을 전달한 시간부터 응답이 도착할 때까지 걸린 시간

- 경과 시간 Turn Around Time: 애플리케이션에 작업을 의뢰한 시간부터 처리가 완료될 때까지 걸린 시간

- 자원 사용률 Resource Usage: 애플리켜이션이 의뢰한 작업을 처리하는 동안의 CPU 사용량, 메모리 사용량, 네트워크 사용량 등 자원 사용률

* 성능 테스트 도구: 애플리케이션에 부하나 스트레스를 가하면서 애플리케이션의 성능 측정 지표를 점검

* 성능 테스트 도구 종류:

- JMeter: HTTP, FTP 등 다양한 프로토콜 지원

- LoadUI: UI를 통해 HTTP, JDBC등 주로 웹 서비스를 대상으로 서버 모니터링을 지원

- OpenSTA: HTTP, HTTPS 지원하는 부하 테스트 및 생산품 모니터링 도구

* 시스템 모니터링 도구: 애플리케이션이 실행 되었을 때 시스템 자원의 사용량을 확인하고 분석하는 도구.

* 시스템 모니터링 도구 종류:

- Scouter: 단일 뷰 통합/ 실시간 모니터링, 튜닝에 최적화된 인프라 통합 모니터링 도구

- Zabbix : 웹기반 서버, 서비스, 애플리케이션 등의 모니터링 도구

* 복잡도 Complexity :

- 시스템이나 시스템 구성 요소 또는 소프트웨어의 복잡한 정도를 나타내는 말.

- 소프트웨어를 어느 정도의 수준까지 테스트해야 하는지 또는 개발하는 데 어느 정도의 자원이 소요되는지 예측하는 데 사용

* 시간 복잡도:

- 알고리즘을 수행하기 위해 프로세스가 수행하는 연산 횟수를 수치화 한것

- 시간 복잡도가 낮을수록 알고리즘의 실행시간이 짧고, 높을수록 실행 시간이 길어진다.

* 점근 표기법의 종류:

- 빅오 표기법 Big-O : 알고리즘 실행시간이 최악인 경우 표기

- 세타 표기법 Big-θ : 알고리즘 실행시간이 평균일 때를 표기

- 오메가 표기법 Big-Ω : 알고리즘 실행시간이 최상을 때 표기

* 빅오 표기법으로 표현한 최악의 알고리즘 시간복잡도:

• O(1) : 입력값에 관계없이 일정하게 하나의 단계만을 거침. ex) 스택의 삽입 Push, 삭제 Pop 
• O(log n) : 문제해결에 필요한 단계가 입력값 또는 조건에 의해 감소 ex) 이진트리 Binary Tree, 이진 검색 Binary Search
• O(n) : 문제 해결에 필요한 단계가 입력값과 1:1의 관계를 가짐. ex) for문
• O(n log n): 문제 해결에 필요한 단계가 n(logn)번만큼 수행 ex) 힙정렬, 2-way 합병 정렬 (Merge Sort)
• O(n^2): 문제 해결에 필요한 단계가 입력값의 제곱만큼 수행 ex) 삽입정렬, 쉘정렬, 선택 정렬, 버블 정렬, 퀵 정렬
• O(2^n): 문제 해결에 필요한 단계가 2의 입력값 제곱만큼 수행 ex) 피보나치 수열

* 순환 복잡도 Cyclomatic Complexity:

- 논리적인 복잡도를 측정하기 위한 소프트웨어의 척도

- 맥케이브 순환도 또는 맥케이브 복잡도 매트릭 으로도 표기.

- 순환 복잡도 = 화살표의 수 - 노드의 수 + 2

* 애플리케이션 성능 개선: 나쁜 코드를 배제하고 클린 코드로 작성하는 것.

* 클린코드: 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순 명료한 코드.

* 나쁜코드: 프로그램의 로직이 복잡하고 이해하기 어려운코드

- 스파게티 코드: 로직이 서로 복잡하게 얽혀있는 코드

- 외계인 코드: 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드

* 클린 코드 작성 원칙:

- 가독성

- 단순성

- 의존성 배제

- 중복성 최소화

- 추상화 

* 소스코드 최적화 유형:

- 클래스 분할 배치: 하나의 클래스는 하나의 역할만 수행하도록 응집도를 높이고 크기를 작게 작성.

- 느슨한 결합 Loosely Coupled: 인터페이스 클래스를 이용하여 추상화된 자료구조와 메소드를 구현함으로써 클래스간의 의존성을 최소화함

* 소스 코드 품질 분석 도구:

- 정적 분석 도구: 작성한 코드를 실행하지 않고 코등 표준, 코딩 스타일, 결함등을 확인하는 코드 분석 도구

- 동적 분석 도구: 작성한 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구

* 소스 코드 품질분석 도구:

- 정적 분석 도구

• pmd
• cppcheck
• SonarQube
• checkstyle
• ccm 
• coberura

- 동적 분석 도구

• Avalanche
• Valgrind

* 애플리케이션 테스트: 개발된 응용 애플리케이션이나 시스템이 사용자가 요구하는 기능, 성능, 사용성, 안정성 등을 만족하는지 확인하고 소프트웨어의 잠재된 결함을 찾아내는 것.

* 애플리케이션 테스트의 기본 원리:

- 완벽한 테스트는 불가능: 완벽하게 테스팅 하려는 시도는 불필요한 시간과 자원낭비. 잠재적 결함은 줄일 수 있지만 결함이 없다고 증명할 수 없음.

- 파레토 법칙: 결함집중. 20%의 모듈에서 80%의 결함이 발견됨

- 살충제 패러독스: 동일한 테스트 케이스를 방복하면 결함이 발견되지 않기 때문에 테스트 케이스의 정기적 개선이 필요.

- 테스팅은 정황에 의존: 소프트웨어의 성격에 맞게 테스트해야함. 소프트웨어의 특징, 테스트 환경, 테스터의 역량 등 정황에 따라 테스트 결과가 달라질 수 있으므로 고려하여 테스트 실시.

- 오류-부재의 궤변: 소프트웨어의 결함을 모두 제거해도 사용자의 요구사항을 만족시키지 못하면 결함이 없어도 품질이 높다고 할 수 없다.

- 테스트와 위험은 반비례: 테스트를 많이 할수록 미래의 위험을 줄일 수 있다.

- 테스트의 점진적 확대: 테스트는 작은 부분에서 시작하여 점점 확대하며 진행.

- 테스트의 별도 팀 수행: 테스트는 개발자와 관계없는 별도의 팀에서 수행해야 함

* 소프트웨어 테스트 프로세스:

- 테스트 계획 - 테스트 분석 및 디자인 - 테스트 케이스 및 시나리오 작성 - 테스트 수행 - 테스트 결과 평가 및 리포팅

* 소프트웨어 테스트 산출물:

- 테스트 계획서:

테스트 목적과 범위 정의, 대상 시스템 구조 파악, 테스트 수행절차, 테스트 일정, 종료 조건 정의 등 테스트 수행을 계획한 문서

- 테스트 케이스:

테스트를 위한 설계 산출물로 응용 소프트웨어가 사용자의 요구사항을 준수하는지 확인하기 위해 설계된 입력값, 실행조건, 기대 결과로 구성된 테스트 항목의 명세서.

- 테스트 시나리오:

테스트 수행을 위한 여러 개의 테스트 케이스의 집합으로 테스트 케이스의 동작 순서를 기술한 문서이며 테스트 절차를 명세한 문서

- 테스트 결과서:

테스트 결과를 정리한 문서로 테스트 프로세스를 리뷰, 결과 평가, 리포팅 하는 문서

* 프로그램 실행 여부에 따른 테스트

- 정적 테스트: 프로그램을 실행하지 않고 명세서, 소스코드를 대상으로 분석.

• 워크스루 Walk Through: 회의 전 검토 자료를 배포하여 짧은 시간동안 회의를 진행. 리뷰를 통해 오류를 검출, 문서화하는 기법.
• 인스펙션 Inspection: 개발자 외 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적인 기법.
• 동료 검토 Peer Review: 2~3녕이 진행하는 리뷰 형태. 이해관계자들이 설명을 들으면서 결함을 발견하는 방식.

- 동적 테스트: 프로그램을 실행하여 오류를 찾는 테스트. 개발의 모든 단계에서 사용.

* 테스트 종류에 따른 분류:

- 명세 기반 테스트: 프로그램 요구사항 명세서를 기반으로 테스트

- 구조 기반 테스트: 소프트웨어 내부 논리 흐름에 따라 테스트

- 경험 기반 테스트: 유사 소프트웨어나 유사 기술 평가에서 테스터의 경험을 토대로한 직관, 기술 능력을 기반으로 테스트

* 테스트 시각에 따른 분류:

- Verification 검증:

• 개발자의 시각에서 명세서대로 완성됐는지 테스트.
• 생산 과정을 테스트. 

- Validation 확인:

• 사용자의 시각에서 제품이 제대로 동작하는지 테스트
• 결과를 테스트.

* 테스트 기법에 따른 분류:

1. 화이트박스 테스트

: 논리적인 모든 경로를 테스트하여 테스트 케이스 설계. 원시코드(모듈)의 모든 문장을 한 번 이상 수행. 구조 기반 테스트.

- 화이트박스 테스트의 종류:

• 기초 경로 검사 Base Path Testing: 테스트 케이스 설계자가 절차적 설계의 논리적 복잡성을 측정할 수 있게 해주는 테스트.
• 제어 구조 검사 Control Structure Testing: 
• - 조건 검사 : 프로그램 모듈 내에 있는 논리적 조건을 테스트
• - 루프 검사: 프로그램의 반복 구조에 초점을 맞춰 실시하는 테스트
• - 데이터 흐름 검사: 프로그램에서 변수의 정의와 변수 사용의 위치에 초점을 맞춰 실시하는 테스트 케이스 설계 기법

- 화이트박스 테스트의 검증 기준:

• 문장 검증 기준 Statement Coverage: 소스 코드의 모든 구문이 한 번 이상 수행되도록 테스트 케이스 설계.
• 분기 검증 기준 Branch Coverage : 결정 검증 기준 Decision Coverage. 소스 코드의 모든 조건문에 대해 조건식의 결과가 true / false 의 경우가 한번 이상 수행되도록 설계
• 조건 검증 기준 Condition Coverage: 소스 코드의 조건문에 포함된 개별 조건식의 결과가 True / False 경우가 한 번 이상 수행되도록 설계
• 분기/조건 기준 Branch/Condition Coverage: 분기 검증 기준, 조건 검증 기준 모두 충족. 조건문이 True / False 경우에 따라 조건 검증 기준의 입력 데이터를 구분하는 테스트 케이스를 설계

2. 블랙박스 테스트

: 각 기능이 작동되는 것을 입증하는 테스트. 기능 테스트. 명세 기반 테스트.

- 블랙박스 테스트의 종류:

• 동치(동등) 분할 테스트 Equivalence Partitioning Testing: 데이터를 그룹핑하여 대표값 테스트 케이스를 도출하여 테스트. 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 나눠 테스트.
• 경계값 분석 테스트 Boundary Value Analusis: 등가 분할 후, 경계값 부분에서 오류 발생 확률이 높기에 경계값을 포함하여 테스트 케이스 설계.
• 결정 테이블 테스트 Decision Table Testing: 요구사항의 논리와 발생조건을 테이블 형태로 나열하여 조건과 행위를 모두 조합하여 테스트하는 기법
• 상태 전이 테스트 State Transition Testing: 테스트 대상,시스템이나 객체의 상태를 구분하여 이벤트에 의해 어떤 상태에서 다른 상태로 전이되는 경우의 수를 수행하는 테스트 기법
• 유스케이스 테스트 Use Case Testing: 시스템이 실제 사용되는 유스케이스로 모델링되어 있을 때 프로세스 흐름을 기반으로 테스트 케이스를 명세화하여 수행
• 분류 트리 테스트 Classification Tree Method Testing: SW의 일부 또는 전체를 트리 구조로 분석 및 표현하여 수행
• 페어와이즈 테스트 Pairwise Testing: 테스트 데이터값 간에 최소한 한 번씩을 조합하는 방식. 기능적 범위를 모든 조합에 비해 상대적으로 적은 양의 테스트 세트를 구성하기 위한 기법
• 원인-효과(결과) 그래프 검사 Cause-Effect Graphing Testing: 입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 분석, 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법
• 비교 테스트 Comparison Testing: 여러 버전의 프로그램에 동일한 테스트 자료를 제공, 같은 결과가 출력되는지 테스트.
• 오류 예측 테스트 Error Guessing: 과거의 경험이나 확인자의 감각으로 테스트

* 개발 단계에 따른 애플리케이션 테스트: 애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현한 것을 V-모델 이라고 한다.

- 소프트웨어 생명 주기의 V-모델:

 요구사항 - 분석 - 설계 - 구현 - 단위테스트 - 통합 테스트 - 시스템 테스트 - 인수 테스트

* 테스트 레벨 종류:

- 단위 테스트 Unit Test: 모듈이나 컴포넌트에 초점을 맞춰 테스트. 주로 구조기반 테스트 시행.

- 통합 테스트 Integraion Test: 단위 테스트가 완료된 모듈들을 통합하여 테스트

- 시스템 테스트 System Test: 통합된 단위 시스템의 기능이 완벽하게 수행되는지 확인

- 인수 테스트 Acceptance Test: 요구사항을 만족시키는지 확인 테스트

• 알파 테스트: 개발자의 장소에서 사용자가 개발자 앞에서 행하는 테스트 기법. 통제된 환경.
• 베타 테스트: 선정된 사용자가 여러명의 사용자 앞에서 행하는 테스트. 실업무를 갖고 사용자가 직접 테스트.

* 통합 테스트 Integration Test: 단위 테스트가 끝난 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트

- 비점진적 통합 방식: 단계적 절차 없이 모든 컴포넌트 통합. ex) 빅뱅 통합 테스트

- 점진적 통합 방식: 모듈 단위로 단계적으로 통합하며 테스트. ex) 상향식 통합, 하향식 통합

* 점진적 통합 방식의 종류:

1. 하향식 통합 테스트 Top Down Integration Test: 상위 모듈에서 하위모듈 방향으로 통합 테스트.

- 주요 제어 모듈의 종속 모듈들은 스텁Stub으로 대체한다.

- 깊이 우선방식 또는 넓이 우선 방식에 따라 하위 모듈인 스텁들이 한번씩 실제 모듈로 교체된다.

- 모듈이 통합될때마다 테스트 실시.

- 새 오류가 발생하지 않음을 보증하기 위한 회귀 테스트 실시.

• 스텁Stub: 제어 모듈이 호출하는 더미 모듈. 일시적으로 필요한 조건만을 갖고 있는 시험용 모듈.

2. 상향식 통합 테스트 Bottom Up Integration Test: 하위 모듈에서 상위 모듈 방향으로 통합.

- 하위 모듈들을 클러스터로 결합.

- 상위 모듈에서 데이터 입출력을 확인하기 위한 드라이버 작성

- 통합된 클러스터 단위로 테스트

- 테스트 완료시 클러스터는 프로그램 구조의 상위로 이동하여 결합하고 드라이버는 실제 모듈로 대체

• 클러스터 Cluster: 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹
• 테스트 드라이버 Test Driver: 테스트 대상의 하위 모듈 호출, 파라미터 전달, 모듈 테스트 수행 후 결과를 도출하는 도구.

* 애플리케이션 테스트 프로세스:

- 테스트 계획 - 테스트 분석 빛 디자인 - 테스트 케이스 및 시나리오 작성 - 테스트 수행 - 테스트 결과 평가 및 리포팅 - 결함 추적 및 관리

* 결함 관리 프로세스:

- 에러 발견 - 에러 등록 - 에러 분석 - 결함 확정 - 결함 할당 - 결함 조치 - 결함 조치 검토 및 승인

* 사용자 인터페이스 (UI, User Interface): 사용자와 시스템 간의 상호작용이 원활하게 이뤄지도록 도와주는 장치나 소프트웨어.

* 사용자 인터페이스의 구분:

- CLI (Command Line Interface): 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스

- GUI (Graphical User Interface): 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경의 인터페이스

- NUI (Natural User Interface): 사용자의 말이나 행동으로 기기를 조작하는 인터페이스

* 사용자 인터페이스의 기본원칙:

- 직관성: 누구나 쉽게 이해하고 사용할 수 있어야함

- 유효성: 사용자의 목적을 정확하고 완벽하게 전달해야함

- 학습성: 초보자, 숙련자 모두 누구나 쉽게 배우고 익힐 수 있어야함

- 유연성: 사용자의 요구사항을 최대한 숭용하고 실수를 최소화해야함

* UI 설계 도구:

- 와이어 프레임: 페이지에 대한 개략적인 레이아웃, 뼈대를 설계하는 도구

- 목업(Mockup): 실제 화면과 유사하게 만든 정적인 형태의 모형

- 스토리보드: 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서

- 프로토타입: 실제 구현된 것처럼 텍스트가 가능한 동적인 형태의 모형. 페이퍼 프로토타입 / 디지털 프로토타입

- 유스케이스: 사용자의 요구사항을 기능 단위로 표현한 것

* UI 요구사항 확인:

- 목표정의 - 활동 사항 정의 - UI 요구사항 작성

* 요구사항 요소:

- 데이터요구

- 기능 요구

- 제품/서비스의 품질

- 제약 사항

* 품질 요구사항

- ISO/IEC 9126: 소프트웨어의 품질 특성과 평가를 위한 국제 표준

- ISO/IEC 25010: ISO/IEC9126에 호환성과 보안성을 강화하여 개정한 소프트웨어 제품에 대한 국제 표준

- ISO/IEC 12119: 패키지 소프트웨어의 일반적인 제품 품질 요구사항 및 테스트를 위한 국제 표준

- ISO/IEC 14598: 소프트웨어 품질의 측정과 평가에 필요 절차를 규정한 표준

* ISO/IEC 9126의 소프트웨어 품질 특성:

- 기능성 Functionality

• 소프트웨어가 사용자의 요구사항을 정확하게 만족하는 기능을 제공하는지 여부
• 하위특성: 적절성/적합성, 정밀성/정확성, 상호 운용성, 보안성, 준수성

- 신뢰성 Reliability

• 주어진 시간동안 주어진 기능을 오류 없이 수행할 수 있는 정도를 나타냄
• 하위 특성: 성숙성, 고장 허용성, 회복성

- 사용성 Usability

• 사용자와 컴퓨터 사이에 발생하는 어떠한 행위에 대하여 사용자가 정확하게 이해하고 사용하며, 향후 다시 사용하고 싶은 정도를 나타냄
• 하위 특성: 이해성, 학습성, 운용성, 친밀성

- 효율성 Efficiency

• 사용자가 요구하는 기능을 얼마나 빠르게 처리할 수 있는지 정도를 나타냄
• 하위 특성: 시간 효율성, 자원 효율성

- 유지 보수성 Maintainability

• 환경의 변화 또는 새로운 요구사항이 발생했을 때 소프트웨어를 개선하거나 확장할 수 있는 정도를 나타냄
• 하위 특성: 분석성, 변경성, 안정성, 시험성

- 이식성 Portability

• 소프트웨어가 다른 환경에서도 얼마나 쉽게 적용할 수 있는지 정도를 나타냄
• 하위 특성: 적용성, 설치성, 대체성, 공존성

* UI설계서: 사용자의 요구사항을 바탕으로 UI설계를 구체화하여 작성하는 문서. 기획자, 개발자, 디자이너 등과의 원활한 의사소통을 위해 작성한다.

* UI 설계서 작성 순서:

- UI 설계서 표지 작성

- UI 설계서 개정 이력 작성

- UI 요구사항 정의서 작성

- 시스템 구조 작성

- 사이트 맵 작성

- 프로세스 정의서 작성

- 화면 설계

* UI 흐름 설계

- 기능 작성

- 입력 요소 확인

- 유스케이스 설계

- 기능 및 양식 확인

* UI 상세 설계

- 요구사항 확인

- UI설계서 표지 및 개정 이력 작성

- UI 구조 설계

- 메뉴 구조 설계

- 화면 설계

* UI 시나리오 문서: 사용자 인터페이스의 기능 구조, 대표화면, 화면 간 인터랙션의 흐름, 다양한 상황에서의 예외처리 등을 정리한 문서

* UI 시나리오 문서의 요건

- 완전성 Complete: 누락되지 않도록 최대한 상세히 기술

- 일관성 Consistent: 서비스 목표, 시스템 및 사용자의 요구사항, UI 스타일 등 모두 일관성을 유지해야함

- 이해성 Understandable: 누구나 쉽게 이해할 수 있도록 설명

- 가독성 Readable: 표준화된 템플릿 등을 활용하여 문서를 쉽게 읽을 수 있도록 해야함

- 수정 용이성 Modifiable: 시나리오의 수정, 개선이 쉬워야함

- 추적 용이성 Traceable: 변경 사항은 언제, 어떤 부분, 어째서 발생했는지 추적이 쉬워야함

* HCI (Human Computer Interaction or Interface): 사람이 시스템을 편리하고 안전하게 사용할 수 있도록 연구하고 개발하는 학문. 최종 목표는 최적의 사용자 경험을 만드는 것.

* 사용자 경험 (UX, User Experience): 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하게 되는 총체적인 경험.

* UX의 특징:

- 주관성 Subjectivity

- 정황성 Contextuality

- 총체성 Holistic

* 감성공학: 제품이나 작업환경을 사용자의 감성에 맞게 설계 및 제작하는 기술

* 인터페이스 요구사항: 개발할 시스템과 외부 시스템을 연동하는데 필요한 시스템 인터페이스에 대한 요구사항 기술

* 시스템 인터페이스 요구사항 명세서의 구성요소:

- 인터페이스 이름

- 연계 대상 시스템

- 연계 범위 및 내용

- 연계방식

- 송신 데이터

- 인터페이스 주기

- 기타 고려사항

* 인터페이스 요구사항 검증 방법:

- 동료 검토 Pear Review

- 워크스루 Walk Through

- 인스펙션 Inspection

* 인터페이스 요구사항 검증의 주요항목:

- 완전성

- 일관성

- 명확성

- 기능성

- 검증 가능성

- 추적 가능성

- 변경 용이성

* 인터페이스 방법 명세화: 내/외부 시스템이 연계하여 작동할 때 인터페이스별 송/수신 방법, 송/수신 데이터, 오류 식별 및 처리 방안에 대한 내용을 문서로 정리

* 미들웨어: 운영체제와 응용 프로그램, 또는 서버와 클라이언트 사이에서 다양한 서비스를 제공하는 소프트웨어.

* 미들웨어의 종류:

- DB (Data Base)

- RPC (Remote Procedure Call)

- MOM (Message Oriented Middleware)

- TP-Monitor(Transaction Processing Monitor)

- ORB(Object Request Broker)

- WAS (Web Application Server)

* 내/외부 모듈 연계 방법:

- EAI: 기업 내 이기종 플랫폼간의 상호 연동이 가능하게 해주는 솔루션

• Point-to-Point
• Hub & Spoke
• Message Bus
• Hybrid

- EBS: 애플리케이션 간 표준 기반의 인터페이스를 제공하는 솔루션

- 웹서비스: 네트워크의 정보를 표준화된 서비스 형태로 만들어 공유하는 기술

• UDDI: WSDL를 등록하여 서비스, 서비스 제공자를 검색하고 접근하는 데 사용
• WSDL: XML로 구성되어있는 웹 서비스 관련 서식, 프로토콜 등을 표준적인 방법으로 기술, 게시하기 위한 언어
• SOAP: XML기반의 메시지를 네트워크 상에서 교환하는 프로토콜

* 인터페이스 구현: 송/수신 시스템 간의 데이터 교환 및 처리를 실현해 주는 작업 의미

*인터페이스 구현 방법:

- 데이터 통신을 이용한 인터페이스 구현

- 인터페이스 엔티티를 이용한 인터페이스 구현

* 데이터 통신을 이용한 인터페이스 구현: 애플리케이션 영역에서 데이터 포맷을 인터페이스 대상으로 전송하면 이를 수신 측에서 파싱하여 해석하는 방식이다. 주로 JSON, XML 형식의 데이터 포맷을 이용하여 인터페이스 구현

* 인터페이스 엔티티를 이용한 인터페이스 구현: 인터페이스가 필요한 시스템 사이에 별도의 인터페이스 엔티티를 두어 상호 연계하는 것. 인터페이스 테이블을 엔티티로 활용.

* 인터페이스 보안:

- 네트워크 영역

- 애플리케이션 영역

- 데이터베이스 영역

* 인터페이스 구현 검증:

- xUnit

: 자바, C++, .Net 등 다양한 언어를 지우너하는 단위테스트 프레임워크. 소프트웨어의 함수나 클래스 같은 서로 다른 구성 단위를 테스트할 수 있게 해주는 도구

- STAF

: 서비스 호출, 컴포넌트 재사용 등 다양한 환경을 지원하는 테스트 프레임워크. 각 테스트 대상 분산 환경에 데몬을 사용하여 테스트 대상 프로그램을 통해 테스트를 수행, 통합하며 자동화하는 검증도구

- FitNesses

: 웹 기반 테스트 케이스 설계/실행/결과 확인 등을 지원하는 테스트 프레임워크. 사용자가 테스트 케이스 테이블을 작성하면 빠르고 편하게 자동으로 원하는 값에 대해 테스트를 할 수 있음

- Selenium

: 다양한 브라우저 지원 및 개발언어를 지원하는 웹 애플리케이션 테스트 프레임워크. 테스트 스크립트 언어를 학습할 필요 없이 기능 테스트를 만들기 위한 도구를 제공

- Watir

: 루비 기반 웹 애플리케이션 테스트 프레임워크. 모든 언어 기반의 웹 애플리케이션 테스트와 브라우저 호환성 테스트 기능

* 인터페이스 구현 감시 도구: 인터페이스 동작 상태는 APM(어플리케이션 성능 관리)를 사용하여 감시할 수 있다. 

* 인터페이스 APM:

- 스카우터 Scouter : OS 자원에 대한 모니터링 기능 제공

- 제니퍼 Jennifer : 애플리케이션의 개발부터 테스트, 오픈, 운영, 안정화 까지 전 단계에 걸쳐 성능을 모니터링하고 분석해주는 소프트웨어

* APM (Application Performance Management/Monitoring): 애플리케이션의 성능 관리를 위해 다양한 모니터링 기능을 제공하는 도구.

- 리소스 방식: Nagios, Zabbix, Cacti 등

- 엔드투엔드 방식: VisualVM, 스카우터, 제니퍼 등

* 개발환경 구축:

- 개발환경 구성시 구현될 시스템 요구사항의 명확한 이해가 필요

- 개발 프로젝트를 이해하고 소프트웨어 및 하드웨어 장비를 구축하는 것

* 개발 도구 분류:

- 구현도구

- 테스트 도구

- 형상관리 도구

- 빌드 도구

* 개발환경 구성요소

- 하드웨어 개발환경:

• 클라이언트: 사용자와의 인터페이스 역할. ex) PC, 스마트폰 등
• 서버: 웹서버 / 웹 애플리케이션 서버 WAS / 데이터베이스 서버 / 파일서버

- 클라이언트 하드웨어 개발환경

• 클라이언트 프로그램
• 웹 브라우저
• 모바일 앱
• 모바일 웹

- 소프트웨어 개발환경

• 운영체제
• 미들웨어
• DBMS

- 형상관리

• Git
• SVN

* 소프트웨어 아키텍처: 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체.

* 소프트웨어 아키텍처 설계의 기본원리:

- 모듈화

- 추상화

- 단계적 분해

- 정보은닉

* 소프트웨어 개발의 설계 단계:

- 상위설계/ 아키텍처 설계/ 예비설계: 시스템의 전체적인 구조. ex) 구조, DB, 인터페이스

- 하위설계/ 모듈설계/ 상세설계: 시스템의 내부 구조 및 행위. ex) 컴포넌트, 자료구조, 알고리즘

* 공통 모듈: 여러 프로그램에서 공통으로 사용할 수 있는 모듈

* 공통 모듈 명세 기법의 종류:

- 정확성

- 명확성

- 완전성

- 일관성

- 추적성

* 재사용: 이미 개발된 기능들을 새로운 시스템이나 기능 개발에 사용하기 적합하도록 최적화 하는 작업

* 재사용 규모에 따른 분류:

- 함수와 객체

- 컴포넌트

- 애플리케이션

* 모듈: 크게 독립된 하나의 소프트웨어 또는 하드웨어 단위를 지칭하는 용어.

* 모듈의 특징:

- 상대적으로 독립성을 가지고있다.

- 모듈 내부에는 수많은 조합이 존재

- 단독으로 컴파일 할 수 있으며, 재사용 가능

- 모듈의 독립성은 결합도와 응집도에 의해 측정됨. 결합도는 약하게, 응집도는 높게 해야 독립성이 높아진다.

* 결합도: 모듈간 상호 의존하는 강도.

• 내용결합도 Content Coupling: 한 모듈이 다른 모듈 내부에 있는 변수나 기능을 직접 참조하거나 수정
• 공통 결합도 Common Coupling: 전역 변수를 참고하거나 갱신하는 식으로 상호작용 하는 경우
• 외부 결합도 External Coupling: 어떤 모듈에서 선언한 데이터 포맷, 통신 프로토콜, 또는 디바이스 인터페이스를 공유할 경우
• 제어 결합도 Control Coupling: 처리할 대상인 값만 전달되는 것이 아닌 제어 신호나 요소를 이동, 전달하는 결합도.
• 스탬프 결합도 Stamp Coupling: 모듈간의 인터페이스로 배열, 레코드 등의 자료구조가 전달되는 경우
• 자료 결합도 Data Coupling: 모듈간의 인터페이스로 자료 요소로만 구성될 경우의 결합도. 모듈간 인터페이스로 전달되는 파라미터를 통해서만 모듈 간의 상호작용이 일어나는 경우.

- 내용 결합도가 가장 결합도가 높으며 자료 결합도가 가장 결합도가 낮다.

* 응집도: 

• 우연적 응집도 Coincidental Cohesion: 모듈 내부의 구성요소가 연관이 없을 경우
• 논리적 응집도 Logical Cohesion: 유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 하나의 모듈 형성
• 시간적 응집도 Temporal Cohesion: 특정 시간에 처리되어야하는 기능을 한 모듈에서 처리할 경우
• 절차적 응집도 Procedural Cohesion: 모듈 안의 구성요소들이 순차적으로 수행할 경우
• 통신적 응집도 Communication Cohesion: 동일한 입/출력을 사용하여 서로 다른 기능을 수행하는 구성요소들이 모였을 경우
• 순차적 응집도 Sequential Cohesion: 모듈 내 하나의 활동으로부터 나온 출력 데이터를 그 다음 활동이 사용할 경우
• 기능적 응집도 Functional Cohesion: 모듈 내부의 모든 기능이 단일 목적을 위해 수행되는 경우

- 우연적 응집도가 가장 낮으며, 기능적 응집도가 가장 높다.

* 단위모듈: 소프트웨어 구현에 필요한 여러 동작 중 한 가지 동작을 수행하는 기능을 모듈로 구현한 것

* 단위모듈의 구현 과정:

- 단위 기능 명세서 작성

- 입/출력 기능 구현

- 알고리즘 구현

* IPC Inter-Process Communication

: 모듈 간 통신 방식을 구현하기 위해 사용되는 대표적인 프로그래밍 인터페이스 집합

* 단위 모듈 테스트: 모듈이 정해진 기능을 정확히 수행하는지 검증하는 것

* 테스트 케이스: 소프트웨어가 사용자의 요구사항을 정확히 준수했는지 확인을 위한 테스트 항목에 대한 명세서

- ISO/IEC/IEEE 29119-3 표준에 따른 테스트 케이스 구성요소:

• 식별자
• 테스트 항목
• 입력 명세
• 출력 명세
• 환경 설정
• 특수 절차 요구
• 의존성 기술

* 디자인 패턴: 모듈간의 관계 및 인터페이스를 설계할 때 참조할 수 있는 전형적인 해결 방식 또는 예제.

* GOF 디자인패턴:

- 생성 패턴

- 구조 패턴

- 행위 패턴

* 생성 패턴: 클래스나 객체의 생성과 참조 과정을 정의하는 패턴

- 추상 팩토리

- 빌더

- 팩토리 메소드

- 프로토타입

- 싱글톤

* 구조 패턴: 구조가 복잡한 시스템을 개발하기 쉽도록 클래스나 객체들을 조합하여 더 큰 구조로 만드는 패턴

- 어댑터 Adapter

- 브리지 Bridge

- 컴포지트 Composite

- 데코레이터 Decorator

- 퍼싸드 Facade

- 플라이웨이트 Flyweight

- 프록시 Proxy

* 행위 패턴: 클래스나 객체들이 서로 상호작용 하는 방법이나 책임 분배 방법을 정의하는 패턴

- 책임 연쇄 Chain of Responsibility

- 커맨드 Command

- 인터프리터 Interpreter

- 반복자 Iterator

- 중재자 Mediator

- 메멘토 Memento

- 옵저버 Observer

- 상태 Sate

- 전략 Strategy

- 템플릿 메소드 Template Method

- 방문자 Visitor

* 소프트웨어 개발 보안: 보안 취약점을 최소화하여 보안 위협으로부터 안전한 소프트웨어를 개발하기 위한 일련의 보안 활동

- 기밀성

- 무결성

- 가용성

보안요소 충족을 목표로 한다.

* 배치 프로그램 Batch Program: 여러 작업들을 미리 정해진 일련의 순서에 따라 일괄적으로 처리하도록 만든 프로그램

* 배치 프로그램의 필수 요소:

- 대용량 데이터

- 자동화

- 견고성

- 안정성/신뢰성

- 성능

* 배치 스케줄러: 일괄 처리 작업이 설정된 주기에 맞춰 자동으로 수행되도록 지원해주는 도구

- 스프링 배치

- Quartz

- Cron

* 통합구현:

- 송/수신 모듈과 중계 모듈 간의 연계를 구현하는 것.

- 송/수신 방식이나 시스템 아키텍처 구성, 송/수신 모듈 구현 방법 등에 따라 다르므로 사용자의 요구사항과 구축 환경에 적합한 방식 설계

* 구성요소:

- 송신 시스템과 모듈

- 수신 시스템과 모듈

- 중계 시스템

- 연계 데이터

- 네트워크

* 연계 매커니즘: 응용 소프트웨어와 연계 대상 모듈 간의 데이터 연계시 요구사항을 고려한 연계방법과 주기를 설계하기 위한 매커니즘.

* 연계 매커니즘 수행 절차:

- 연계 데이터 생성 및 추출

- 코드 매핑 및 데이터 변환

- 인터페이스 테이블 또는 파일 생성

- 연계 서버 또는 송신 어댑터

-> 실패시 로그 기록

* 로그 기록: 송/수신 시스템에서 수행되는 모든 과정에 관한 결과 및 오류에 대한 정보를 로그 테이블이나 파일에 기록하는 과정

* 연계 방식:

- 직접연계

• DB 링크(DB Link)
• DB 연결(DB Connection)
• API/Open API
• JDBC
• 하이퍼 링크

- 간접연계

• 연계 솔루션(EAI)
• Web Service/ESB
• 소켓(Socket)

* 연계 모듈 구현 환경 구성 및 개발:

- EAI(Enterprise Application Integration)방식은 기업에서 운영되는 이기종간의 정보전달, 연계, 통합을 갖능하게 해주는 솔루션. 각 비즈니스간 통합 및 연계성을 증대시켜 시스템간의 확장성 향상.

- ESB(Enterprise Service Bus)방식은 서로 다른 플랫폼 및 애플리케이션들을 하나의 시스템으로 관리 운영할 수 있도록 서비스 중심의 통합을 지향하는 아키텍처 또는 기술. ESB는 버스를 중심으로 각각 프로토콜이 호환 가능하도록 애플리케이션간의 통합을 느슨한 결합 방식으로 지원하는 방식.

* EAI/ESB 방식 연계 모듈 환경 및 구축 절차:

- 연계 DB 또는 계정 생성

- 연계를 위한 테이블 생성

- 연계 응용 프로그램 구현

* 웹서비스 방식: 네트워크에 분산된 정보를 서비스 형태로 개방하여 표준화된 방식으로 공유하는 기술로써 서비스 지향 하키텍처 개념을 실현하는 대표적인 기술.

* 웹서비스 방식의 유형:

- SOAP 방식

- UDDI 방식

- WSDL 방식

SOAP(Simple Object Access Protocol)은 일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 사용하여 XML 기반의 메시지를 네트워크 상태에서 교환하는 프로토콜.

UDDI(Universal Description ,Discovery and Integration)는 웹 서비스를 등록하고 검색하기 위한 저장소로 웹 서비스를 공개적으로 접근, 검색이 가능하도록 공개된 레지스트리.

WSDL(Web Services Description Language)은 웹 서비스가 제공하는 서비스에 대한 정보를 기술한 파일로 XML로 기술

REST 프로토콜: HTTP메소드(POST, GET, PUT, DELETE)를 통해 자원에 대한 생성, 조회, 갱신, 삭제 명령을 적용하는 프로토콜. SOAP 대체가능 

- RESTful 웹 서비스란 REST(Representational State Transfer, 2000년, Roy Fielding) 기반의 웹 서비스를 의미하며 HTTP의 기본 기능만으로 원격 정보에 접근하는 웹 응용 기술.

* 데이터 모델:

- 현실 세계의 정보들을 컴퓨터에 표현하기 위해 단순화, 추상화 하여 체계적으로 표현한 개념적 모형.

- 데이터 모델은 데이터, 데이터의 관계, 데이터의 의미 및 일관성, 제약조건 등을 기술하기 위한 개념적 도구들의 모임.

- 데이터베이스 설계 과정에서 데이터의 구조(Schema)를 논리적으로  표현하기 위해 지능적 도구로 사용.

* 데이터 모델에 표시해야할 요소:

- 구조 Structure : 논리적으로 표현된 개체 타입들 간의 관계로서 데이터 구조 및 정적 성질 표현

- 연산 Operation: 데이터베이스에 저장된 실제 데이터를 처리하는 작업에 대한 명세로서 데이터베이스를 조작하는 기본 도구

- 제약 조건 Constraint: 데이터베이스에 저장될 수 있는 실제 데이터의 논리적인 제약조건

* 데이터 모델의 종류:

- 개념적 데이터 모델

- 논리적 데이터 모델

- 물리적 데이터 모델

* 데이터 모델링 속성:

- Entity 개체: 관리 대상이 되는 실체. 개념이나 정보 단위 같은 현실 세계의 대상체

- Attribute 속성: 관리할 정보의 구체적 항목. 데이터베이스를 구성하는 가장 작은 논리적 단위

- Relationship 관계: 개체 간의 대응 관계. 개체와 개체 사이의 논리적인 연결

* 논리 데이터 모델링: 데이터베이스 설계 프로세스의 기초 설계 단계. 개념 모델로부터 업무 영역의 업무 데이터 및 규칙을 구체적으로 표현한 모델

* 논리 데이터 모델링 특성:

- 정규화

- 포용성

- 완전성

- 독립성

* 개체-관계(E-R) 모델:

- 현실 세계의 데이터와 그 관계를 사람이 이해할 수 있는 형태로 표현하기 위한 모델.

- 모든 이해당사자와 의사소통의 보조 자료로 활용.

- 요구사항으로부터 얻어낸 정보들을 개체, 속성, 관계로 기술한 모델.

* 정규화(Normalization): 관계형 데이터베이스의 설계에서 중복을 최소화하여 데이터를 구조화하는 프로세스

* 이상현상(Abnomaly): 데이터의 중복성으로 인해 릴레이션을 조작할 때 발생하는 비합리적 현상.

- 삽입이상: 정보 저장시 해당 정보의 불필요한 세부정보를 입력해야하는 경우

- 삭제이상: 정보 삭제시 원치 않는 다른 정보가 같이 삭제되는 경우

- 갱신이상: 중복 데이터 중에서 특정 부분만 수정되어 중복된 값이 모순을 일으키는 경우

*정규화의 단계

- 1정규형(1NF): 원자값으로 구성

- 2정규형(2NF): 부분 함수 종속 제거

- 3정규형(3NF): 이행함수 종속 제거

- 보이스-코드 정규형(BCNF): 결정자 함수이면서 후보키가 아닌 것 제거

- 4정규형(4NF): 다치 종속성 제거

- 5정규형(5NF): 조인 종속성 제거

소프트웨어 생명주기

* 소프트웨어 생명주기: 소프트웨어를 개발하기 위한 설계, 운용, 유지보수 등의 과정을 각 단계별로 나눈 것.

생명주기 모형의 종류:

- 폭포수 모형

- 프로토타입 모형

- 나선형 모형

- 애자일 모형

요구사항 확인

* 요구사항: 문제의 해결 또는 목적 달성을 위해 고객의 요구사항, 혹은 표준이나 명세를 충족시키기 위해 시스템이 가져야하는 서비스 혹은 제약사항.

* 요구사항 분류:

- 기능적 요구사항: 

 특성: 기능성, 완전성, 일관성

 ex) 온라인 쇼핑을 구현했을 경우 장바구니에서 아이템 삭제가 가능해야함

- 비기능적 요구사항: 

 특성: 신뢰성, 사용성, 효율성, 유지보수성, 이식성

 ex) 시스템은 하루 24시간 가동되어야함

- 사용자 요구사항: 사용자 관점에서 본 시스템이 제공해야할 요구사항

- 시스템 요구사항: 소프트웨어 요구사항. 개발자 관점에서 본 시스템 전체가 제공해야할 요구사항

* 요구사항 개발 프로세스:

요구사항 도출 Elication - 분석 Analysis - 명세 Specification - 확인 Validation

* 요구사항 분석 기법:

- 요구사항 분류

- 개념 모델링

- 요구사항 할당

- 요구사항 협상

- 정형 분석

* 요구사항 분석: 개발 대상에 대한 사용자의 요구사항을 이해하고 문서화 하는 활동

* 구조적 분석 기법: 자료의 흐름, 처리를 바탕으로 요구사항을 분석 하는 방법. 하향식 방법을 통해 시스템을 세분화 할 수 있다.

* 구조적 분석 기법 도구:

 - 자료흐름도(DFD)

 - 자료 사전(DD)

 - 소단위 명세서(Mini-Spec.)

 - 개체 관계도(ERD)

 - 상태 전이도(STD)

 - 제어 명세서

* 요구사항 분석용 CASE(자동화 도구)

: 요구사항을 자동으로 분석하고 요구사항 분석 명세서를 기술하도록 개발된 도구

*요구사항 분석용 CASE

 - ASDT

 - SREM = RSL/REVS

 - PSL/PSA

 - TAGS

* HIPO (Hierarchy Input Process Output)

: 시스템 실행 과정인 입력, 처리, 출력의 기능을 표현한 것으로 시스템의 분석,설계, 문서화에 사용되는 기법

* UML (Unified Modeling Language)

: 시스템 개발 과정에서 시스템 개발자와 고객, 협업 개발자들 등 상호간의 의사소통이 원할히 이뤄지도록 표준화한 대표적인 객체지향 모델링 언어.

*  UML의 구성요소

- Things 사물

- Relationships 관계

- Diagram 다이어그램

* UML - 다이어그램 : 사물과 관계를 도형으로 표현한 것.

- Structural Diagram (구조적 다이어그램): 정적 모델링에서 주로 사용.

종류:

• Calss Diagram 클래스 다이어그램
• Object Diagram 객체 다이어그램
• Component Diagram 컴포넌트 다이어그램
• Deplyment Diagram 배치 다이어그램
• Composite Structure Diagram 복합체 구조 다이어그램
• Package Diagram 패키지 다이어그램

- Behavioral Diagram (행위 다이어그램): 동적 모델링에서 주로 사용.

종류:

• Use Case Diagram 유스케이스 다이어그램
• Sequence Diagram 시퀀스 다이어그램
• Communication Diagram 커뮤니케이션 다이어그램
• State Diagram 상태 다이어그램
• Activity Diagram 활동 다이어그램
• Interaction Overview Diagram 상호작용 개요 다이어그램
• Timing Diagram 타이밍 다이어그램

* 비용산정 모델: 소프트웨어 규모 파악을 통한 투입 자원과 소요 시간을 통해 실행 가능한 계획을 수립하기 위해 비용을 산정하는 모델

* 비용산정 모델 분류:

- 하향식 산정방법: 전문가 판단, 델파이 기법

- 상향식 산정방법: LoC, Man Month, COCOMO 모형, Putnam 모형, FP(Function Point)모형

* COCOMO 모형의 소프트웨어 개발 유형

 - Organic Mode 조직형: 5만(50KDSI) 라인 이하의 소프트웨어 개발 유형

 - Semi-Detached Mode 반분리형: 30만(300KDSI) 라인 이하의 소프트웨어 개발 유형

 - Embedded Mode 내장형: 30만(300KDSI)라인 이상의 소프트웨어 개발 유형

* Putnam(푸트남) 모형:

소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 예상.

Rayleigh-Norden 곡선의 노력 분포도를 기초로 함.

* 비용 산정 자동화 추정 도구

- SLIM: Rayleigh-Norden 곡선과 Putnam 예측 모델을 기초로 개발된 자동화 추정 도구

- ESTIMACS: FP모형을 기초로 개발된 자동화 추정 도구

* 프로젝트 일정 계획: 프로젝트의 프로세스를 이루는 소작업을 파악하고 예측된 노력을 각 소작업에 분배하여 순서와 일정 정리.

- PERT (Program Evaluation and Review Technique, 프로그램 평가 및 검토 기술)

: 전체 작업의 상호 관계를 표시하는 네트워크

- CPM (Critical Path Method, 임계 경로 기법)

: 프로젝트 완성에 필요한 작업을 나열, 필요한 소요기간을 예측하는데 사용하는 기법.

- 간트 차트 / Time-Line 차트

: 프로젝트의 작업 시작, 종료에 대한 작업일정을 막대 도표로 표시하는 프로젝트 일정표.

현행 시스템 분석

* 현행 시스템 파악: 현행 시스템이 어떤 하위 시스템으로 구성되어있고, 제공 기능 및 연계 정보는 무엇이며 어떤 기술 요소를 사용하는지 파악하는 활동.

* 현행 시스템 파악 절차:

1. 구성/ 기능/ 인터페이스 파악 - 시스템 구성 현황, 시스템 기능, 시스템 인터페이스 파악

2. 아키텍처 및 소프트웨어 구성 파악  - 아키텍처, 소프트웨어 구성 파악

3. 하드웨어 및 네트워크 구성 파악 - 시스템 하드웨어 현황, 네트워크 구성 파악

* 개발 기술 환경 파악

- OS (Operation System) 운영체제: 컴퓨터 시스템이 제공하는 하드웨어, 소프트웨어를 효율적으로 관리하며 편리하게 사용할 수 있도록 지원하는 소프트웨어.

고려사항:

• 품질측면 : 신뢰도, 성능
• 지원측면 : 기술지원, 주변 기기, 구축비용

- DBMS (Data Base Management System) 데이터베이스 관리 시스템: 사용자가 데이터베이스를 생성, 저장, 관리 기능을 도와주는 응용 프로그램.

고려사항:

• 품질측면 : 가용성, 성능, 상호 호환성
• 지원측면 : 기술지원, 주변 기기, 구축비용

- Middleware 미들웨어: 분산 컴퓨팅 환경에서 응용 프로그램과 프로그램이 운영되는 환경 간 통신을 제어해주는 소프트웨어. 대표적인 미들웨어로 WAS가 있다.

고려사항:

• 성능 측면: 가용성, 성능

   * WAS (Web Application Server) 웹 애플리케이션 서버:  서버 계층에서 app이 동작할 수 있도록 환경 제공. 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 서버.

- Open Source 오픈소스: 누구나 제한없이 사용할 수 있도록 소스를 공개한 소프트웨어.

• 라이선스의 종류, 사용자 수, 기술의 지속 가능성