Post

교착상태, IPv6,4, TCP/IP, 프로세스의 상태 종류, Thread, 비용 산정

Posted
By 박예성
23 min read
교착상태, IPv6,4, TCP/IP, 프로세스의 상태 종류, Thread, 비용 산정

교착상태 필요충분 조건

상_호배제 (mutual exclusion) 점_유와대기 (hold and wait) 완(환)_형대기 (circular wait) 비_선점

IPv6, IPv4

  • IPv6
    1. 128비트 주소 체계
    2. 유니캐스트(unicast) 멀티캐스트(multicast) 애니캐스트(anycast)
    3. 여덟 개의 16진수 블록
    4. IPsec(인터넷 프로토콜 보안)이 필수적으로 포함되어 있어 보안이 향상
  • IPv4 :
    1. 32비트 주소 체계 2.유니캐스트(unicast) 멀티캐스트(multicast) 브로드캐스트(Broadcast)
    2. 네 개의 10진수로 구성되며, 각각이 0부터 255 사이의 값
    3. 네트워크 주소 변환(Network Address Translation)을 사용하여 여러 기기가 하나의 공용 IP 주소를 공유

TCP/IP

  • UDP : 비연결형 서비스 제공 / 실시간 전송 네트워크에서 사용 ARP : IP 주소를 MAC Address로 변환 (논리 주소 → 물리 주소)
  • TCP : 양방향 연결형 서비스 제공 / 가상 회선 연결 형태의 서비스 제공 / 스트릿 위주 패킷 전달
  • ICMP : IP와 조합하여 통신 중에 발생하는 오류처리와 전송 경로 변경 등을 위한 제어 메시지를 관리
  • IGMP : 멀티캐스트를 지원하는 호스트나 라우터 사이에서 멀티캐스트 그룹 유지를 위해 사용

프로세스의 상태 종류

  • 보류 (pending)
  • 준비 (ready)
  • 실행 (running)
  • 대기 (blocked)
  • 교착 (deadlock)
  • 완료 (terminated)

Thread

  • 프로세스 내에서의 작업단위로 여러 자원을 할당받아 실행하는 프로그램 단위
  • 한 개의 프로세스에는 하나 이상의 스레드가 존재
  • 커널 스레드 : 운영체제 커널에 의해 스레드 운영 / 구현 쉬움 / 속도 느림
  • 사용자 스레드 : 사용자가 만든 라이브러리를 사용해 스레드 운용 / 속도 빠름 / 구현 어렵
  • 하드웨어 운용체제 성능과 처리율을 향상 가능
  • 응용프로그램 응답시간 단축 가능
  • 실행 환경을 공유시켜 기억장소 낭비 줄어듬

비용 산정 기법

  • 전문가 감정 기법 : 조직 내에 있는 경험 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법
  • 델파이 기법 : 전문가 감정 기법의 주관적 편견을 보완하기 위해 많은 전문가의 의견을 종합
  • LOC 기법 : 원시 코드 라인 수 기법으로서 원시 코드 라인 수의 비관치 낙관치 기대치를 측정하여 산정하는 기법
  • 개발 단계별 인월수 기법 : LOC를 보완하기 위한 기법, 필요 노력을 생명 주기의 각 단계별로 선정
  • COCOMO : 보헴이 제안한 것으로 LOC에 의한 비용 산정 기법

유형별 COCOMO

  • Organic : 조직형 / 소규모 소프트웨어 일괄 자료 처리 /5만 라인 이하
  • Semi-detached : 반분리형 / 트랜잭션 처리 시스템이나 운영체제, DB / 30만 라인 이하
  • Embedded : 내장형 / 최대형 규모 트랜잭션 처리 시스템이나 운영체제 / 30만 라인 이상

COCOMO 종류

  • Basic (기본): 소프트웨어 크기 및 개발 유형만 이용
  • Intermediate(중간) : 기본형의 공식 토대로 사용하나 4가지 특성 및 15가지 요인에 의해 비용 산정
  • 제품 특성 : 신뢰도 / DB크기 / 복잡도 컴퓨터 특성 : 수행시간제한 / 기억장소제한 / - 가상 기계의 안정성 / Turn Around Time
  • 개발 요원의 특성 : 분석가 능력 / 개발 분야 경험 / 가상 기계 경험 / 프로그래머 능력 및 언어 경험
  • 프로젝트 특성 : 소프트웨어 도구 이용 / 프로젝트 개발 일정 / 최신 프로그래밍 기법 이용
  • Detailed(발전) : 중간형 COCOMO 보완하여 만들어진 방법으로 개발 공정별보다 자세하고 정확하게 비용 산정
  • Putnam 기법 : 소프트웨어 생명 주기의 전 과정 동안에 사용될 곡선의 노력의 분포를 가정해주는 모형 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다.
  • FP 기법 : 기능 점수 모형으로 알브레히트가 제안 / 요인별 가중치를 합산하여 총 기능 점수를 산출하여 점수와 영향도를 이용 비용 산정

LOC 기법

  • 소프트웨어 각 기능의 LOC의 비관치, 낙관치, 기대치를 측정 하여 예측치를 구한 후 이것으로 비용을 산정하는 방법이다.
  • 예측치는 {낙관치+(4×기대치)+비관치}÷6으로 구할 수 있다

애자일

: 애자일(Agile) 기법은 소프트웨어 개발의 유연성과 속도를 높이기 위해 고안된 방법론입니다. 애자일 기법은 변화에 유연하게 대응하고, 고객과의 소통을 강조하며, 작은 단위로 작업을 나누어 개발합니다. 여기서 몇 가지 대표적인 애자일 기법을 소개할게요.

  1. 익스트림 프로그래밍(XP, Extreme Programming) 익스트림 프로그래밍은 애자일 기법 중 하나로, 소프트웨어 개발의 생산성과 품질을 향상시키기 위해 고안되었습니다. XP의 주요 특징은 다음과 같습니다:

용기, 단순성, 의사소통, 피트백, 존중

짧은 개발 주기: 주로 1~2주의 짧은 반복 주기를 가집니다.

테스트 주도 개발(TDD): 코드를 작성하기 전에 테스트 코드를 작성하고, 그 테스트를 통과하는 코드를 작성합니다.

짝 프로그래밍: 두 명의 개발자가 한 컴퓨터로 함께 코딩합니다. 한 명이 코드를 작성하고 다른 한 명은 그 과정을 리뷰합니다.

지속적인 통합: 코드를 자주 통합하고, 통합 시마다 자동으로 테스트를 실행하여 문제를 빠르게 발견하고 수정합니다.

  1. 스크럼(Scrum) 스크럼은 팀 간의 협력과 소통을 강조하는 애자일 프레임워크입니다. 스크럼의 주요 요소는 다음과 같습니다:

확약, 전념, 정직, 존중, 용기

xp와 달리 진행 체계 수립, 역할, 정의에 중심

스프린트: 2~4주 동안 일정한 반복 주기를 가지며, 각 주기마다 목표를 설정하고 그 목표를 달성하기 위해 작업합니다. “짧은 기간”

Product Owner : 제품 책임자, 제품에 대한 요구사항 즉 백로그를 작성하는 주체

Scrum Master : 팀의 애자일 프로세스를 지원하고 장애물을 제거해주는 역할을 합니다.

일일 스크럼 미팅: 매일 짧은 회의를 통해 팀원들이 진행 상황을 공유하고, 장애물을 논의합니다.

백로그: 요구사항 리스트(목록)

속도(Velocity): 한번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치

이 외에도 칸반(Kanban), 린(Lean) 등 다양한 애자일 기법이 존재합니다.

CASE의 원천 기술

  • 구조적 기법
  • 프로토타이핑 기술
  • 자동 프로그래밍 기술
  • 정보 저장소 기술
  • 분산 처리 기술

HIPO

HIPO 다이어그램(Hierarchy plus Input-Process-Output)은 시스템의 기능적 구조를 시각적으로 표현하는 도구입니다. 각 기능은 입력, 처리, 출력이라는 구성 요소로 나뉘어져 있어 시스템의 흐름을 쉽게 파악할 수 있습니다. 다음은 HIPO 다이어그램의 구성 요소와 종류에 대한 설명입니다.

HIPO 다이어그램 구성 요소

  1. 계층도(Hierarchy Chart)

시스템의 전체 기능을 계층 구조로 나열합니다.

상위 레벨에서 하위 레벨로 세부 기능이 점차적으로 분해됩니다.

  1. 총괄 다이어그램(Overview Diagram)

시스템의 주요 기능을 간략하게 요약한 다이어그램입니다.

각 기능에 대한 간단한 설명과 흐름을 포함합니다.

  1. 세부 다이어그램(Detail Diagram)

특정 기능에 대해 입력(Input), 처리(Process), 출력(Output)을 상세하게 표현한 다이어그램입니다.

기능 간의 상호 작용과 데이터 흐름을 구체적으로 설명합니다.

동적계획

작은 문제의 풀이를 활용

분할 정복

문제를 작게 나누는 것

해시 함수 기법 정리

1. 제산(Division)법

  • 방식: 레코드 키를 해시표 크기보다 큰 수 중 가장 작은 소수로 나눈 나머지를 홈 주소로 사용
  • 공식: h(k) = k % p (p는 소수)
  • 특징: 간단하고 빠르며, 충돌 발생 가능성 존재

2. 제곱(Mid-square)법

  • 방식: 레코드 키 값을 제곱한 후 중간 부분의 값을 홈 주소로 사용
  • 공식: h(k) = mid(k²)
  • 특징: 키 값 분포가 고르지 않을 경우 충돌 가능성 높음

3. 폴딩(Folding)법

  • 방식: 레코드 키 값을 여러 부분으로 나눈 후 각 부분의 값을 더하거나 XOR 연산한 값을 홈 주소로 사용
  • 공식:
    • Shift Folding: h(k) = sum(parts)
    • Boundary Folding: h(k) = XOR(parts)
  • 특징: 키 길이가 긴 경우 유용

4. 기수(Radix)변환법

  • 방식: 키 숫자의 진수를 다른 진수로 변환 후, 주소 크기를 초과한 높은 자릿수는 절단하고 주소 범위에 맞게 조정
  • 공식: h(k) = trunc(convert(k, base))
  • 특징: 키 값의 분포를 균일하게 만드는 데 효과적

5. 대수적 코딩(Algebraic Coding)법

  • 방식: 키 값을 다항식의 계수로 간주하고, 해시표 크기에 의해 정의된 다항식으로 나눈 나머지 다항식의 계수를 홈 주소로 사용
  • 공식: h(k) = coefficients(k(x) % p(x))
  • 특징: 수학적 복잡성 높으나 충돌 최소화 가능

6. 계수분석법(숫자분석법)

  • 방식: 키 값을 이루는 숫자의 분포를 분석하여 고른 자리를 선택해 홈 주소로 사용
  • 공식: h(k) = select_uniform_digits(k)
  • 특징: 키 값의 특정 부분만 사용하므로 간단

7. 무작위법

  • 방식: 난수를 발생시켜 나온 값을 홈 주소로 사용
  • 공식: h(k) = random()
  • 특징: 충돌 가능성 낮으나 재현성 없음

인터페이스 구현 검증 도구의 종류

  • xUnit : Java(Junit), C++(Cppunit), .Net(Nunit)와 같이 다양한 언어를 지원하는 단위 테스트 프레임워크
  • STAF : 서비스 호출 및 컴포넌트 재사용 등 다양한 환경을 지원하는 테스트 프레임워크
  • FitNesse : 웹 기반 테스트 케이스 설계, 실행, 결과 확인 등을 지원하는 테스트 프레임워크
  • NTAF : FitNesse의 장점인 협업과 STAF의 장점인 재 사용 및 확장성을 통합한 NHN(Naver)의 테스트 자동화 프레임워크
  • Selenium : 다양한 브라우저 및 개발 언어를 지원하는 웹 어플리케이션 테스트 프레임워크
  • watir : Ruby를 사용하는 애플리케이션 테스트 프레임워크

단위 테스트 도구

  • CppUnit : C++ 프로그래밍 언어용 단위 테스트 도구
  • JUnit Java : 프로그래밍 언어용 단위 테스트 도구
  • HttpUnit : 웹 브라우저 없이 웹 사이트 테스트를 수행하기 위해 사용되는 오픈소스 테스트 프레임워크

테스트

  • 테스트 케이스(Test Case)
    구현된 SW가 사용자 요구사항을 정확하게 준수했는지 확인하기 위해 설계된 입력값, 실행 조건, 기대 결과 등으로 구성된 테스트 항목에 대한 명세서이다.

명세 기반 테스트의 설계 산출물에 해당된다.

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

  • 테스트 스위트(Test Suites) : 시스템에 사용되는 테스트 케이스의 집합

  • 테스트 드라이버(Test Driver) : 테스트 대상의 하위 모듈을 호출하고 모듈 테스트 수행 후의 결과를 도출하는 도구

v-모델 테스트

요구사항 분석 → 시스템 설계 → 아키텍처 설계 → 모듈 설계 → 코딩 ↓ ↓ ↓ ↓ 인수 테스트 ← 시스템 테스트 ← 통합 테스트 ← 단위 테스트

▶ 왼쪽 축: 개발 단계

  1. 요구사항 분석
    • 목적: 사용자 요구사항 명확화
    • 산출물: 요구사항 명세서(SRS)
  2. 시스템 설계
    • 목적: 전체 시스템 구조 설계
    • 산출물: 시스템 설계 문서
  3. 아키텍처 설계
    • 목적: 하위 시스템 및 모듈 설계
    • 산출물: 아키텍처 설계 문서
  4. 모듈 설계
    • 목적: 개별 모듈의 상세 설계
    • 산출물: 모듈 설계 문서
  5. 코딩
    • 목적: 실제 코드 구현
    • 산출물: 소스 코드

▶ 오른쪽 축: 테스트 단계

  1. 단위 테스트(Unit Test)
    • 목적: 개별 모듈의 기능 검증
    • 대상: 소스 코드
    • 테스트 기법: 화이트박스 테스트
    • 산출물: 단위 테스트 결과 보고서
  2. 통합 테스트(Integration Test)
    • 목적: 모듈 간 상호작용 검증
    • 대상: 모듈 간 인터페이스
    • 테스트 기법: 블랙박스 테스트
    • 산출물: 통합 테스트 결과 보고서
  3. 시스템 테스트(System Test)
    • 목적: 전체 시스템의 기능 및 비기능 요구사항 검증
    • 대상: 전체 시스템
    • 테스트 기법: 블랙박스 테스트
    • 산출물: 시스템 테스트 결과 보고서
  4. 인수 테스트(Acceptance Test)
    • 목적: 사용자 요구사항 충족 여부 검증
    • 대상: 최종 제품
    • 테스트 기법: 블랙박스 테스트
    • 산출물: 인수 테스트 결과 보고서

분석 도구

  • 정적 분석 도구 : pmd, cppcheck, SonarQube, checkstyle, ccm, cobertura 등
  • 동적 분석 도구 : Avalanche, Valgrind 등

소프트웨어 테스트 원칙

  • 테스팅은결함이 존재함을 밝히는 활동 : 테스트에서 결함을 찾지 못하더라고 그 SW에 결함이 없다고 할 수는 없음
  • 완벽한 테스팅은 불가능 : 모든 가능성에 대해 테스팅하는 것은 불가능함
  • 개발 초기에 시작 : 개발 초기 단계에서 테스트를 하면 초기에 결함을 발견할 수 있음
  • 결함에 집중 : 대다수의 결함은 소수 특정 모듈에 집중되어 결함이 발생되는 경우가 많음
  • 살충제 패러독스 (Pesticide Paradox) : 테스트 케이스로 동일한 절차를 반복 수행하면 새로운 결함을 찾을 수 없음
  • 정확(Context)에 의존적 : 테스팅은 정황에 따라 진행되므로, SW에 따라 테스팅도 달라짐
  • 오류 부재의 궤변 : 갤발된 시스템이 사용자의 요구사항을 만족하지 못하거나 사용성이 낮다면 오류를 발견하고 제거해도 품질이 높다고 말할 수 없음

검증-확인

  • 검증(Verification) : 기능을 제대로 수행하고 명세서에 맞게 만들 어졌는지 개발자의 입장에서 점검하는 것
  • 리팩토링(Refactoring) : 결과를 유지하면서 내부의 코드 구조를 재조정하는 것
  • 디버깅(Debugging) : 프로그램에서 발견되는 버그를 찾아 수정하는 것
  • 확인(Validation) : 개발된 소프트웨어가 요구사항을 만족시키는지 사용자의 입장에서 확인하는 것
정보처리기사, 필기
정보처리기사 필기 이론
This post is licensed under CC BY 4.0 by the author.