[정보처리기사 필기 공부] 소프트웨어 공학

1. 모델링 언어

구조적 방법론

DFD (Data Flow Diagram)

• Terminator
  • 출원지, 목적지
  • 학생, 교수
• data flow
  • 자료의 흐름
  • 화살표
• data store
  • 자료가 저장되는 곳
  • 데이터베이스 테이블
• process
  • 자료를 입력 받아 처리하는 알고리즘
  • 성적 계산

DD (Data Dictionary)

자료 사전의 기호

• 프로세스 명세 (Process Specification)

정보공학 방법론

• 자료 구조 중심의 방법론으로 비교적 안정적이다.
• 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론이다.

ERD (Entity-Relationship Diagram)

• 데이터베이스에 저장할 데이터를 개체(entity)와 관계(relationship)를 중심으로 작성

객체지향 방법론

UML 표기법

• UML의 구성 요소에는 사물, 관계, 다이어그램이 있다

• 다이어그램은 사물과 사물 간의 관계를 용도에 맞게 표현한다

  사물 (Things)

  • 모델을 구성하는 가장 중요한 기본 요소
  • 관계가 형성될 수 있는 대상들

  구조 사물 (Structural Things)

  • 시스템의 개념적, 물리적 요소를 표현
  • Class, Use Case, Component, Node

  행동 사물 (Behavioral Things)

  • 시간과 공간에 따른 요소들의 행위를 표현
  • 상호작용(Interaction), 상태 머신(State Machine)

  그룹 사물 (Grouping Things)

  • 요소들을 그룹으로 묶어서 표현
  • 패키지(Package)

  주해 사물 (Annotation Things)

  • 부가적인 설명이나 제약조건 등을 표현
  • Note

  관계 (Relationships)

  • 사물과 사물 상의 연관성을 표현

  연관(Association) 관계

  • 2개 이상의 사물이 서로 관련되어 있음을 표현

  • 사물 사이를 실선으로 연결하여 표현

  • 방향성은 화살표로 표현

  • 양방향 관계는 화살표를 생략하고 실선으로만 연결

  • 연관에 참여하는 객체이 개수를 의미하는 다중도(Multiplicity)를 선 위에 표기

    

    

  집합(Aggregation) 관계

  • 하나의 사물이 다른 사물에 포함되어 있는 관계

  • 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적

  • 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 빈 마름모를 연결하여 표현

  • 부분-전체(Part-Whole), 부분(is-a-part-of)

    

  포함(Composition) 관계

  • 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계

  • 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적일 수 없고, 생명주기를 함께한다

  • 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 채워진 마름모를 연결하여 표현

    

  일반화(Generalization) 관계

  • 하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현

  • 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)

  • 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표를 연결하여 표현

  • is-a

    

  특수화(Specialization) 관계

  • 일반화와 개념이 같으나, 클래스를 보는 시점에 있어 상위의 클래스에서 하위의 클래스를 보는 관점
  • 하위 개념으로 내려 갈수록 인스턴스는 특수화
  • is-a

  의존(Dependency) 관계

  • 사물 사이에 서로 연관은 있으나, 필요에 의해 서로에게 영향을 주는 짧은 시간 동안만 연관을 유지하는 관계
  • 영향을 주는 사물(이용자)이 영향을 받는 사물(제공자) 쪽으로 점선 화살표를 연결하여 표현

  

  실체화(Realization) 관계

  • 사물이 할 수 있거나 해야 하는 기능(행위, 인터페이스)으로 서로를 그룹화 할 수 있는 관계를 표현

    

  다이어그램(Diagram)

  • 시스템을 가시화한 뷰(View)를 제공함으로써 의사소통에 도움을 준다

  정적 모델링 (Structural, 구조적)

  • 구조적 다이어그램을 사용

  클래스 다이어그램(Class Diagram)

  • 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현

  객체 다이어그램(Object Diagram)

  • 인스턴스(instance)를 특정 시점의 객체와 객체 사이의 관계로 표현

  컴포넌트 다이어그램(Component Diagram)

  • 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현
  • 구현 단계에서 사용

  배치 다이어그램(Deployment Diagram)

  • 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
  • 노드와 의사소통(통신) 경로로 표현
  • 구현 단계에서 사용

  복합체 구조 다이어그램(Composite Structure Diagram)

  • 클래스나 컴포넌트가 복합 구조를 갖는 경우 그 내부 구조를 표현

  패키지 다이어그램(Package Diagram)

  • 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계를 표현

  동적 모델링(Behavioral, 행위)

  • 행위 다이어그램을 사용

  유스케이스 다이어그램(Use Case Diagram)

  • 사용자의 요구를 분석하는 것
  • 사용자(Actor)와 사용 사례(Use Case)로 구성

  시퀀스 다이어그램(Sequence Diagram)

  • 상호 작용하는 시스템이나 객체들이 주고받는 메시지를 표현

    구성 항목

    • 액터
    • 활성 객체(object)
    • 라이프라인(생명선)
    • 메세지
    • 제어 삼각형

  커뮤니케이션 다이어그램(Communication Diagram)

  • 동작에 참여하는 객체들이 주고받는 메시지를 표현
  • 객체들 간의 연관까지 표현

  상태 다이어그램(State Diagram)

  • 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호 작용에 따라 상태가 어떻게 변화하는지를 표현

  활동 다이어그램(Activity Diagram)

  • 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현

  상호작용 개요 다이어그램(Interaction Overview Diagram)

  • 상호작용 다이어그램 간의 제어 흐름을 표현

  타이밍 다이어그램(Timing Diagram)

  • 객체 상태 변화와 시간 제약을 명시적으로 표현

MVC (Model-View-Controller) 패턴

• View → <<boundary>> 클래스
  • 시스템 내부와 시스템 외부의 연결을 담당하는 부분
• Controller → <<control>> 클래스
  • 시스템 내부의 비즈니스 로직과 연산을 담당하는 부분
• Model → <<entity>> 클래스
  • 데이터의 관리를 담당하는 부분

2. 소프트웨어 개발 방법

요구사항 분석(requirements annalysis)

• 비용과 일정에 대한 제약설정
• 타당성 조사
• 요구사항 정의 문서화

CASE

• 요구사항 분석을 위한 자동화 도구는 요구사항을 자동으로 분석하고, 요구사항 분석 명세서를 기술하도록 개발된 도구를 의미

• 상위, 하위, 통합 케이스로 분류된다.

• 1980년대에 소개되었으며, 1990년대부터 자주 사용되었습니다.

  이점

  • 표준화와 보고를 통한 문서화 품질 개선
  • DB가 모두에게 이용 가능하다는 점에서 분석자들 간의 적절한 조정
  • 교차 참조도와 보고서를 통한 결함, 생략, 불일치 등의 발견 용이성
  • 변경이 주는 영향 추적의 용이성
  • 명세에 대한 유지보수 비용 축소
  • 그래픽 지원
  • 다양한 소프트웨어 개발 모형을 지원한다
  • 소프트웨어 생명주기 전 단계를 연결한다

  단점

  • 전문성을 갖추고 있는 고액의 프로그램이기 때문에 수요가 적다 → 호환성이 고려되지 않는다.

  종류

  • SADT (Structured Analaysis and Design Technique)

    • SoftTech 사에서 개발한 것으로 시스템 정의, 소프트웨어 요구사항 분석, 시스템/소프트웨어 설계를 위해 널리 이용되어 온 구조적 분석 및 설계 도구이다.
    • 구조적 요구 분석을 하기 위해 블록 다이어그램을 채택한 자동화 도구다.

  • SREM(Software Requirements Engineering Methodology) = RSL/REVS

    • TRW사가 우주 국방 시스템 그룹에 의해 실시간 처리 소프트웨어 시스템에서 요구사항을 명확히 기술하도록 할 목적으로 개발한 것으로, RSL과 REVS를 사용하는 자동화 도구이다.
    • RSL(Requirement Statement Language)
      • 요소, 속성, 관계, 구조들을 기술하는 요구사항 기술 언어
    • REVS(Requirement Engineering and Validation System)
      • RSL로 기술된 요구사항들을 자동으로 분석하여 요구사항 분석 명세서를 출력하는 요구사항 분석기

  • PSL/PSA

    미시간 대학에서 개발한 것으로 PSL과 PSA를 사용하는 자동화 도구이다.

    • PSL(Problem Statement Language)
      • 문제 기술언어
    • PSA(Problem Statement Analyzer)
      • PSL로 기술한 요구사항을 자동으로 분석하여 다양한 보고서를 출력하는 문제 분석기

  • TAGS(Technology for Automated Generation of Systems)

    시스템 공학 방법 응용에 대한 자동 접근 방법, 개발 주기의 전 과정에 이용할 수 있는 통합 자동화 도구다.

    • 구성 : IORL, 요구사항 분석과 IORL 처리를 위한 도구, 기초적인 TAGS 방법론
    • IORL : 요구사항 명세 언어

HIPO

• 시스템의 분석 및 설계나 문서화할 때 사용되는 기법, 시스템 실행 과정인 입력, 처리, 출력의 기능을 나타낸다

  설명

  • 기본 시스템 모델은 입력, 처리, 출력으로 구성되며, 하향식 소프트웨어 개발을 위한 문서화 도구다.
  • 체계적인 문서 관리 가능
  • 기호,도표 등을 사용해서 보기가 쉽고 이해도 쉽다.
  • 기능과 자료의 의존 관계를 동시에 표현할 수 있다.
  • 변경, 유지보수 용이
  • 시스템의 기능을 고유 모듈들로 분할하여 이들 간의 인터페이스를 계층구조로 표현한 것을 HIPO Chart라고 한다.

  종류

  • 가시적 도표(Visual Table of Contents)
    • 시스템의 전체적인 기능과 흐름을 보여주는 계층 구조도
  • 총체적 도표(Overview Diagram)
    • 프로그램을 구성하는 기능을 기술한 것으로 입력/처리/출력에 대한 전반적인 정보를 제공하는 도표
  • 세부적 도표(Detail Diagram)
    • 총체적 도표에 표시된 기능을 구성하는 기본 요소들을 상세히 기술하는 도표

3. 객체지향 분석의 방법론

Rumbaugh

• 가장 일반적으로 사용되는 방법으로 분석 활동을 객체/동적/기능 모델로 나누어 수행하는 방법

동적 모델링에 활용되는 다이어그램

• 상태 다이어그램(State Diagram)
  • 동적인 흐름 행위

객체 모델링에 활용되는 다이어그램

• 객체 다이어그램(Object Diagram)
  • 가장 중요시 선행

기능 모델링에 활용되는 다이어그램

• 자료 흐름도(Data Flow Diagram)
  • 자료의 흐름을 이용하여 프로세스간의 자료 흐름을 처리

Booch

• 미시적(Micro) 개발 프로세스와 거시적(Macro) 개발 프로세스를 모두 사용하는 분석방법

Jacobson

• Use Case를 강조하여 사용하는 분석방법

Coad와 Yourdon

• E-R다이어그램을 사용하여 개체의 활동들을 데이터 모델링하는데 초점을 둔 기법

Wirfs-Brock

• 분석과 설계간의 구분이 없고 고객 명세서를 평가해서 설계 작업까지 연속적으로 수행하는 기법

4. 품질 요구사항

ISO/IEC 9126 품질 특성

5. 소스코드 품질분석 도구

정적 분석 도구

• 소스 코드를 실행하지 않고 코딩 표준이나 코딩 스타일, 결함 등을 확인하는 코드 분석 도구

종류

• pmd
• cppcheck
• SonarQube
• checkstyle
• ccm
• cobertura

동적 분석 도구

• 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등을 분석하는 도구

종류

• Avalanche
• Valgrind

6. 비용 산정기법

전문가 감정 기법

• 조직 내에 있는 경험 많은 두 명 이상의 전문가에게 비용 산정을 의뢰하는 기법

델파이 기법

• 전문가 감정 기법의 주관적 편견을 보완하기 위해 많은 전문가의 의견을 종합

LOC 기법

• 원시 코드 라인 수 기법으로서 원시 코드 라인 수의 비관치 낙관치 기대치를 측정하여 산정하는 기법

LOC(Lines Of Code) 기법

• 노력(인/월 수 M/M) = (참여 인원/월)*개발 기간 = 추정 LOC/1인당 월 평균 생산 코드 라인 수
• 개발 비용 = (M/M) * 단위 비용(1인당 월 평균 인건비)
• 개발 기간 = (M/M) / 참여 인원
• 생산성 = LOC/(M/M)

비관치

• 가장 많이 측정된 코드의 라인 수

낙관치

• 가장 적게 측정된 코드의 라인 수

기대치

• 측정된 모든 코드 라인 수의 평균

예측치

• 경험을 통해 만들어진 식

$$예측치 = \frac{(a+4m+b)}{6}$$

• a
  • 낙관치
• b
  • 비관치
• m
  • 기대치(중간치)

개발 단계별 인월수 기법

• 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(기능점수) 기법

  • 기능 점수 모형으로 알브레히트가 제안 / 요인별 가중치를 합산하여 총 기능 점수를 산출하여 점수와 영향도를 이용 비용 산정

    비용산정에 이용되는 요소

    • 자료 입력(입력 양식)
    • 정보 출력(출력 보고서)
    • 명령어(사용자 질의수)
    • 데이터 파일
    • 필요한 외부 루틴과의 인터페이스

    자동화 추정 도구

    • ESTIMACS

7. 능력 성숙도 모델 (capability maturity model, CMM)

• 소프트웨어 개발 업체들의 업무능력평가 기준을 세우기 위한 평가 모형
• 소프트웨어 개발능력 측정 기준과 소프트웨어 개발 조직의 성숙도 수준을 평가
• CMM은 능력 성숙도 통합 모델(CMMI)로 발전

8. 테일러링(Tailoring) 개발 방법론

• 프로젝트 상황 특성에 맞게 정의된 소프트웨어 개발 방법론 절차, 사용기법 등을 수정 및 보완하는 작업
• 방법론에 표준이 없다
• 일관된 개발 방법을 극복하기 위한 방법

내부적 요건

• 목표환경
• 요구사항
• 프로젝트규모
• 보유기술

외부적 요건

• 법적 제약사항
• 표준 품질 기준

프레임워크

• CMMI 모델, SPICE 등

9. 테스트 오라클 (Test Oracle)

• 테스트의 결과가 참인지 거짓인지를 판단하기 위해서 사전에 정의된 참값을 입력하여 비교하는 기법 및 활동

특징

제한된 검증

• 테스트 오라클을 모든 테스트 케이스에 적용할 수 없음

수학적 기법

• 테스트 오라클의 값을 수학적 기법을 이용하여 구할 수 있음

자동화 가능

• 테스트 대상 프로그램의 실행, 결과 비교, 커버리지 측정 등을 자동화 할 수 있음

종류

• 참(True) 오라클
  • 모든 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하는 오라클
  • 발생된 모든 오류를 검출할 수 있다
• 샘플링(Sampling) 오라클
  • 특정한 몇몇 테스트 케이스의 입력 값들에 대해서만 기대하는 결과를 제공하는 오라클
• 추정(Heuristic) 오라클
  • 특정 테스트 케이스의 입력 값에 대해 기대하는 결과를 제공하고, 나머지 입력 값들에 대해서는 추정으로 처리하는 오라클
• 일관성 검사(Consistent) 오라클
  • 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클

10. 테스트 케이스 (Test Case)

• 테스트 항목에 대한 명세서
• 명세 기반 테스트의 설계 산출물에 해당
• 시스템 설계 시 작성해야 한다

작성 순서

1. 테스트 계획 검토 및 자료 확보
2. 위험 평가 및 우선순위 결정
3. 테스트 요구사항 정의
4. 테스트 구조 설계 및 테스트 방법 결정
5. 테스트 케이스 정의
6. 테스트 케이스 타당성 확인 및 유지 보수

11. 테스트 시나리오 (Test Scenario)

• 테스트 케이스를 적용하는 순서에 따라 여러 개의 테스트 케이스들을 묶은 집합
• 테스트 케이스들을 적용하는 구체적인 절차를 명세한 문서
• 테스트 순서에 대한 구체적인 절차, 사전 조건, 입력 데이터 등이 설정

12. 일정 계획

1. 일정 계획의 이업 순서 결정, 소작업의 개발 기간, 순서, 필요한 자원 등의 일정 계획

2. 일정 계획의 시작 : 작업 분할 구조도(WBS)

• WBS(Work Breakdown Structure)

  • 프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화하는 작업
  • 프로젝트 구성 요소들을 계층 구조로 분류
  • 프로젝트의 전체 범위 정의
  • 프로젝트 작업을 세분화

  작업 패키지(work package)

  • 계층 구조에서 최하위에 있는 항목

    

  WBS의 목적과 용도

  • 사용자와 개발자 간의 의사소통 도구로 사용함
  • 프로젝트 업무 내역을 가시화할 수 있어 관리가 용이함
  • 프로젝트 팀원의 책임과 역할이 분명함
  • 필요 인력과 일정 계획을 세우는 데 기초로 활용함
  • 개발비 산정 시 기초로 활용함
  • 성과 측정 및 조정 시 기준선으로 활용할 수 있음

3. 일정 계획 기법 1 : 네트워크 차트 PERT/CPM

• WBS의 작업 순서, 소요 기간 등을 네트워크 형태의 그래프로 표현한 후 어떤 작업이 중요한지, 또 일정에 여유가 있는 작업은 어떤 것인지 찾아내 중점 관리를 해야 하는 작업을 명확히 하는데 사용

  • 프로젝트를 완료할 수 있는 최소 기간은 얼마인지,
  • 완료 기간을 맞추기 위해서는 각 작업을 언제 시작하고 완료해야 하는지,
  • 지연되지 않으려면 어떤 작업에 특히 주의를 기울여야 하는지
  • 또 전체 프로젝트 완료 기간을 단축하기 위해서는 어떤 작업들을 단축하는 것이 가장 경제적인지 등

    • 관리자의 고민에 답을 주기 위해 필요한 도구

      

  CPM 네트워크를 그린다

  • 노드(node)와 간선(edge)을 이용해 표 3-17에 대한 초기의 CPM 네트워크를 그린다

  • 노드

    • 작업

  • 간선들

    • 작업들 간의 선후 의존관계
    • 화살표 뒤의 작업은 화살표 전의 작업이 끝나야 시작할 수 있다

    

  ES(Earliest Start Time) 값을 구한다

  • 가능한 빨리 시작할 수 있는 시간으로,

    • 즉, 선행 작업이 완료되었을 때 해당작업을 시작할 수 있는 가장 빠른 시점

  • ES 값을 구할 때는 맨 앞(작업 A)에서 끝 방향으로 가며 계산

    

  EF(Earliest Finish time) 값을 구한다

  • 가장 빠른 시작 시간(ES)으로 시작했을 때의 가장 빠른 완료 시간

    • 즉, 가능한 빨리 끝낼 수 있는 시간으로 'ES + 작업 소요 시간'

    

  LS(Latest Start Time) 값을 구한다

  • 어떤 작업이 늦어도 시작해야 하는 시간

    • 즉, 가장 늦게 시작할 수 있는 시간

  • 이 시간에 시작하지 않으면(이 시간보다 늦게 시작하면) 총 일정이 지연

    

    

  LF(Latest Finish Time) 값을 구한다

  • 가장 늦게 시작할 수 있는 시간(LS)에 시작해 작업을 완료한 시간

    • 즉, 작업을 가장 늦게 끝낼 수 있는 시간으로 'LS + 작업 소요 시간'

    

  ST(Slack Time) 값을 구한다

  • Slack
    • 느슨한, 여유 있는
  • Slack Time
    • 느슨한 시간, 여유 있는 시간
  • 가장 늦게 시작하는 시간 - 가장 빨리 시작하는 시간

    • LS - ES

      

  임계 경로(Critical Path)를 구한다

  • 임계 경로

    • A지점에서 B지점으로 가는데 가장 오래 걸리는 경로를 의미

  • 임계경로에 있는 작업 하나가 1일 지연되면 전체 일정이 1일 지연

    

4. 일정 계획 기법 2 : 간트 차트를 이용한 일정표 작성

• 프로젝트 일정 관리를 위한 바bar 형태의 도구

  

5. Project 일정 계획 순서

• 프로젝트 추산 → 필요한 작업 분리(WBS) → CPM → Gantt Chart

13. NS (Nassi-Schneiderman) 차트

NS차트는 어떻게 원하는 결과를 얻을 수 있는지를 정리해 볼 수 있는 도구이다.

관점

1. 무엇을 해야 하는지 생각해보기

• 컴퓨터에게 시킬일이 무엇이며 어떤 결과를 받아 보고 싶은지 정리

2. 어떻게 해야 하는지 생각해보기

• 사용자로부터 입력이 되는것과 입력없이 알 수 있는것들 가지고 어떤 처리를 어떤 순서로 진행해서 결과를 만들지

구성요소

• 처리, 반복, 선택의 일반적인 프로그래밍 언어의 구성요소를 표현할 수 있다

  

• 먼저 순차처리 네모 박스에 입력, 출력, 연산을 기록한다

• 선택 구조는 IF문이나 CASE문을 사용하여 처리 흐름을 기록한다

• 반복구조는 While문이나 For문을 사용하여 조건에 따른 반복처리를 기술한다

  

  • 1에서 100까지 합을 구하는 ns차트

NS차트의 특징

• 논리의 기술에 중점을 둔 도형을 이용한 표현 방법이다.
• 그리기가 어렵다.(전문성이 있어야 잘 그린다)
• 순차, 선택, 반복으로 표현한다.
• 임의의 제어 이동이 어렵다.
  • goto구조가 어렵다.
• 그래픽 설계 도구이다.
• 상자 도표라고도 한다
• 프로그램으로 구현이 쉽다.
• 조건이 복합되어 있는 곳의 처리를 명확히 식별하기에 적합하다.
  • if문이 여러개일 때 가능

14. 공통 모듈

정확성(Correctness)

• 정확히 작성한다

명확성(Clarity)

• 명확히 작성한다

완전성(Completeness)

• 필요한 모든 것을 기술한다

일관성(Consistency)

• 상호 충돌이 발생하지 않도록 작성한다

추적성(Traceability)

• 요구사항의 출처, 관련 시스템 등의 관계를 파악할 수 있도록 작성한다

15. 다형성 (Polymorphism)

메소드 오버로딩 (overloading)

• 중복정의
• 한 클래스에 이름이 동일한 메서드가 중복 정의되어 있는 경우

메소드 오버라이딩 (overriding)

• 재정의
• 상위 클래스에서 정의한 일반 메서드의 구현을 하위 클래스에서 모두 무시하고 다시 재정의해서 사용

16. 코드

A. 종류

순차 코드 (Sequence Code)

• 일정 기준에 따라 최초의 자료부터 차례로 일련번호를 부여하는 방법
• 일련 번호 코드

블록 코드 (Block Code)

• 공통성이 있는 것끼리 블록으로 구분, 각 블록 내에서 일련번호를 부여하는 방법
• 구분 코드

10진 코드 (Decimal Code)

• 코드화 대상 항목을 0~9까지 10진 분할, 다시 그 각각에 대하여 10진 분할하는 방법을 필요한 만큼 반복하는 방법
• 도서 분류식 코드

그룹 분류 코드 (Group Classification Code)

• 일정 기준에 따라 대분류, 중분류, 소분류 등으로 구분
• 각 그룹 안에서 일련번호를 부여

연상 코드 (Mnemonic Code)

• 명칭이나 약호와 관계있는 숫자, 문자, 기호를 이용하여 코드를 부여
• TV-40 → 40인치 TV

표의 숫자 코드 (Significant Digit Code)

• 대상 항목의 성질, 즉 길이, 넓이, 부피 등의 물리적 수치를 그대로 코드에 적용시키는 방법
• 유효 숫자 코드

합성 코드 (Combined Code)

• 2개 이상의 코드를 조합하여 만드는 방법
• 연상 코드 + 순차 코드
  • KE-711 → 대한한공 711기

B. 주요 기능

식별 기능

• 데이터 간의 성격에 따라 구분이 가능함

분류 기능

• 특정 기준이나 동일한 유형에 해당하느 데이터를 그룹화 할 수 있음

배열 기능

• 의미를 부여하여 나열할 수 있음

17. 기본 경로 테스트

순환 복잡도(CC, Cyclomatic Complexity)

• 매케이브가 정의한 메트릭으로 원시 코드의 복잡도를 정량적으로 평가하는 방법

18. 동적 테스트

화이트박스 테스트

• 모듈의 원시 코드를 오픈시킨 논리적인 모든 경로를 테스트하여 테스트 케이스를 설계하는 방법

• 모든 문장을 한 번 이상 실행함

  종류

  조건 검사 (Condition Testing)

  • 논리적 조건을 테스트

  루프 검사 (Loop Testing)

  • 반복 구조에 초점

  데이터 흐름 검사 (Data Flow Testing)

  • 변수의 정의와 변수 사용의 위치에 초점

  검증 기준

  문장 검증 기준 (Statement Coverage)

  • 모든 구문이 한 번 이상 수행

  분기 검증 기준 (Branch Coverage)

  • 모든 조건문이 한 번 이상 수행

  조건 검증 기준 (Condition Coverage)

  • 모든 조건문에 대해 조건이 True인 경우와 False인 경우가 한 번 이상 수행

  분기/조건 기준 (Branch/Condition Coverage)

  • 모든 조건문과 각 조건문에 포함된 개별 조건식의 결과가 True인 경우와 False인 경우가 한 번 이상 수행

블랙박스 테스트

• 기능 테스트

• 요구사항 명세를 보면서 테스트

• 구현된 기능을 테스트

  종류

  동치 분할 검사 (Equivalence Partitioning Testing)

  • 입력 조건에 타당한 입력 자료와 타당하지 않은 입력 자료의 개수를 균등하게 하여 테스트 케이스를 정함

  경계값 분석 (Boundary Value Analysis)

  • 입력 조건의 경계값을 테스트 케이스로 선정하여 검사

  원인-효과 그래프 검사 (Cause-Effect Graphing Testing)

  • 효용성이 높은 테스트 케이스를 선정하여 검사하는 기법

  오류 예측 검사 (Error Guessing)

  • 과거의 경험이나 확인자의 감각으로 테스트하는 기법

  비교 검사 (Comparison Testing)

  • 여러 버전의 프로그램에 동일한 테스트 자료를 제공하여 동일한 결과가 출력되는지 테스트

19. 디자인 패턴

1. 생성 패턴

Factory method 패턴

• Factory : 공장, 물건을 만드는 곳(물건-인스턴스)
  • 인스턴스
    • 실예화
• 상위 클래스에서 객체를 생성하는 인터페이스를 정의하고, 하위 클래스에서 인스턴스를 생성하도록 하는 방식
• 객체를 생성하는 시점은 알지만 어떤 객체를 생성해야 할지 알 수 없을 때, 객체 생성을 하위 클래스에 위임하여 해결

Singleton 패턴

• Singleton : 단독 개체, 독신자라는 뜻 말고도 정확히 하나의 요소만 갖는 집합
• 특정 클래스의 객체가 오직 한 개만 존재하도록 보장, 즉 클래스의 객체를 하나로 제한
• 동일한 자원이나 데이터를 처리하는 객체가 불필요하게 여러 개 만들어질 필요가 없는 경우에 주로 사용

Prototype 패턴

• new Object()보다 clone()을 이용해 기존의 것을 복사하여 일부만 바꿔 인스턴스 생성
• 일반적인 prototype(원형)을 만들어놓고, 그것을 복사한 후 필요한 부분만 수정하여 사용
• 인스턴스를 복제하여 사용하는 구조
• 생성할 객체의 원형을 제공하는 프로토타입 인스턴스로부터 생성할 객체들의 타입 결정
• 객체를 생성할 때 갖추어야 할 기본 형태가 있을 때 사용
• 객체를 직접 생성하지 않고 기존의 객체를 복사해서 사용하는 방법

Builder 패턴

• 복잡한 인스턴스를 조립하여 만드는 구조
• 복잡 객체를 생성할 때 객체를 생성하는 방법(과정)과 객체를 구현(표현)하는 방법을 분리
• 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있다

Abstract factory 패턴

• abstract factory : 추상적인 공장
• 여러 개의 concrete Product를 추상화시킨 것
• 구체적인 구현은 concrete Product 클래스에서 이루어짐
• 사용자에게 API를 제공하고, 인터페이스만 사용해서 부품을 조립하여 만든다.
  • 즉, 추상적인 부품을 조합해서 추상적인 제품을 만든다
• 스타일에 맞는 객체를 리턴하는 메소드를 객체가 갖도록 함

2. 구조 패턴

Composite 패턴

• composite : 합성물, 혼합 양식
• composite object : 부분-전체의 상속 구조로 표현되는 조립 객체
• 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 한 것
• 재귀적 구조
  • 디렉토리 안에 파일 또는 다른 디렉토리(서브 디렉토리)가 존재할 수 있는 것
• 그릇(디렉토리)과 내용물(파일)을 동일시해서 재귀적인 구조를 만들기 위한 설계 패턴

Adapter 패턴

• adapter : 접속 소켓, 확장 카드, (물건을 다른 것에) 맞추어 붙이다, 맞추다
• 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할
• 호환성이 없는 기존 클래스의 인터페이스를 변환해 재사용할 수 있도록 해준다
  • 클래스 adapter 패턴
    • 상속을 이용한 어댑터 패턴
  • 인스턴스 adapter 패턴
    • 위임을 이용한 어댑터 패턴
• 기존에 작성된 클래스가 있는 경우 새로 필요한 것은 기존 내용을 이용하면서 다른 기능 등 혹은 API가 필요한 경우에 사용
  • 예
    • Circle, DrawableCircle Class)

Bridge 패턴

• bridge : 무엇인가를 연결한다
• 두 장소를 연결하는 역할
• 기능의 클래스 계층과 구현의 클래스 계층을 연결하고, 구현부에서 추상계층을 분리하여 각자 독립적으로 변형할 수 있게 해준다
• 구현과 인터페이스(추상화된 부분)를 분리할 수 있고, 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있다

Decorator 패턴

• Decoration : 장식(포장)
• 기존에 구현되어 있는 클래스(둥근 모양의 빵)에 그때그때 필요한 기능(초콜릿, 치즈, 생크림)을 추가(장식, 포장)해나가는 설계 패턴
• 기능확장이 필요할 때 상속의 대안으로 사용
• 기본적인 기능 이외에 부가적인 기능이 필요할 때 부가기능이 많고 서로 결합되어서 사용될 수 있는 경우 데코레이터 패턴 사용

Facade 패턴

• Facade : 건물의 앞쪽 정면(전면)
• 몇 개의 클라이언트 클래스와 서브시스템의 클라이언트 사이에 Facade라는 객체를 세워놓음으로써 복잡한 관계를 정리(구조화)한 것
• 모든 관계가 전면에 세워진 Facade 객체를 통해서만 이루어질 수 있게 단순한 인터페이스를 제공(단순한 창구 역할)하는 것
• 대규모 클래스를 포함하는 소프트웨어 아키텍처 관리, 서브시스템의 내부가 복잡하여 클라이언트 코드가 사용하기 힘들 경우 사용

Flyweight 패턴

• Flyweight : (권투, 레슬링 등의) 플라이급 선수(보통 체중 48~51kg 사이), 즉 가벼운 것
• 메모리를 가볍게 해준다고 짐작할 수 있다
• 메모리 사용량을 줄이기 위한 방법으로, 인스턴스를 필요한 대로 다 만들어 쓰지 말고, 동일한 것은 가능하면 공유해서 객체 생성을 줄이자는 것

Proxy 패턴

• Proxy : 대리인, 즉 뭔가를 대신해서 처리하는 것
• 그림과 텍스트가 섞여있는 경우 텍스트가 먼저 나오고 나중에 그림이 나올 수 있도록 하기 위해 텍스트 처리용 프로세스, 그림 처리용 프로세스를 별도로 두고 운영하는 것 같은 설계
• 일부 메소드가 실행될 때 많은 자원(시간, 공간)이 필요하며 리모트로 동작하게 함, 자주 실행될 필요가 없는 것

3. 행위패턴

iterator 패턴

• iterate : 반복하다
• iterator : 반복자
• 반복이 필요한 자료구조를 모두 동일한 인터페이스를 통해 접근할 수 있도록 아래 그림처럼 iterator 객체 속에 넣은 다음, iterator 객체의 메소드를 이용해 자료구조를 활용할 수 있도록 해준다

• 데이터들의 집합체를 모두 동일한 인터페이스를 사용하여 조작함으로써 데이터들의 집합체를 쉽게 사용할 수 있게 해준다.

observer 패턴

• observer : 관찰하는 사람, 관찰자
• 어떤 클래스에 변화가 일어났을 때, 이를 감지하여 다른 클래스에 통보해주는 것
• 여러 객체가 한 객체에 의존하여 이것이 변경될 때 영향을 받아 작업을 수행하는 것

strategy 패턴

• strategy : 전략, 전술
• 소프트웨어 개발에서 전략이나 전술은 알고리즘으로 구현

• 알고리즘 군을 정의하고(strategySort 추상클래스) 같은 알고리즘(버블 정렬, 퀵 정렬, 선택 정렬 등)을 각각 하나의 클래스로 캡슐화한(quickSort 클래스, selectSort 클래스, bubbleSort 클래스) 다음, 필요할 때 서로 교환해서 사용할 수 있게 해준다.
• 클라이언트와 무관하게 독립적으로 알고리즘 변경 가능(quickSort → bubbleSort), 클라이언트는 독립적으로 원하는 알고리즘 사용 가능
• 클라이언트에게 알고리즘이 사용하는 데이터나 그 구조를 숨겨주는 역할
• 알고리즘을 사용하는 곳과, 알고리즘을 제공하는 곳을 분리시킨 구조로 알고리즘을 동적으로 교체 가능

template method 패턴

• Template : 하나의 틀
• 이런 틀 기능을 구현할 때 template method 패턴을 이용
• 상위 클래스에서는 추상적으로 표현하고 그 구체적인 내용은 하위 클래스에서 결정되는 디자인 패턴
  • abstract class
    • 선언부만 있음

Visitor 패턴

• visitor : 방문자

• 각 클래스의 데이터 구조로부터 처리 기능을 분리하여 별도의 visitor 클래스로 만들어놓고 해당 클래스의 메소드(visitElement A, visitElement B)가 각 클래스를 돌아다니며 특정 작업을 수행하도록 하는 것

• 객체의 구조와 기능을 분리

• 객체의 구조는 변경하지 않으면서 기능만 따로 추가하거나 확장할 때 많이 사용

  장점

  • 클래스의 데이터 구조 변경 없이 기존 작업(기능) 외에 다른 작업을 추가하기가 수월

chain of responsibility 패턴

• 책임들이 연결되어 있어 내가 책임을 못 질 것 같으면 다음 책임자에게 자동으로 넘어가는 구조
• 소프트웨어 개발에서도 이렇게 자동으로 연결되는 구조로 프로그램을 만들면 매우 유용한데 이 개념을 적용할 수 있는 것이 chain of responsibility 패턴

command 패턴

• command : 명령어

  • 문서편집기의 복사, 붙여넣기, 잘라내기 등

• 위 명령어를 각각 구현하는 것보다는 위 그림처럼 하나의 추상 클래스에 execute() 메소드를 하나 만들고 각 명령이 들어오면 그에 맞는 서브 클래스(copy_command)가 선택되어 실행하는 것이 효율적

• 단순히 명령어를 추상 클래스와 구체 클래스로 분리하여 단순화한 것을 끝나지 않고, 명령어에 따른 취소(undo) 기능까지 포함

  이유

  • 사용자 입장에서는 해당 명령어를 실행했다가 취소(undo)하기도 하기 때문

• 이렇게 프로그램의 명령어를 구현할 때 command 패턴을 활용

• 대규모 클래스를 포함하는 아키텍처를 관리

• 이미 수행한 4개의 결정을 언제든지 취소하게 함(undo)

mediator 패턴

• Mediator : 중재자, 조정자, 중개인
• 부동산 중개사, 비행기의 이착륙을 통제하는 관제탑, 중고물건을 사고파는 사이트처럼 중간에서 연결하고 통제하는 역할
• 서로 지칭하지 않고 객체 사이의 인터랙션을 모아 중재, 클라이언트 코드에서 객체들에 분산된 기능을 사용하게 함

state 패턴

• State : 상태
• 동일한 동작을 객체 상태에 따라 다르게 처리해야 할 때 사용
• 아래 그림처럼 객체 상태를 캡슐화하여 클래스화함으로써 그것을 참조하게 하는 방식으로 상태에 따라 다르게 처리(upState, stopState, downState)할 수 있도록 한 것
• 변경 시(신규 상태 추가) 원시 코드의 수정을 최소화할 수 있고, 유지보수를 쉽게 할 수 있다

memento 패턴

• Memento : (사람, 장소를 기억하기 위한) 기념품
• undo 기능을 개발할 때 유용
• 클래스 설계 관점에서 객체의 정보를 저장할 필요가 있을 때 적용

interpreter 패턴

• interpreter : 통역자
• 단어의 의미처럼 무언가를 번역하는 데 사용
• 간단한 언어의 문법을 정의하고 해석하는 데 사용
• 문법 규칙을 클래스화한 구조를 갖는 SQL 언어나 통신 프로토콜 같은 것을 개발할 때 사용

20. 컴포넌트 설계

협약에 의한 설계 (Design by Contract)

• 클래스에 대한 여러 가정을 공유하도록 명세한 것
• 소프트웨어 컴포넌트에 대한 정확한 인터페이스 명세를 위하여 선행조건, 결과조건, 불변조건을 나타내는 설계 방법

협약에 의한 설계의 세 가지 타입

• 선행조건 (precondition)
  • 오퍼레이션이 호출되기 전에 참이 되어야 할 조건
• 결과 조건 (postcondition)
  • 오퍼레이션이 수행된 후 만족하여야 하는 조건
• 불변조건 (invariant)
  • 클래스 내부가 실행되는 동안 항상 만족하여야 하는 조건

21. 물리데이터 저장소의 파티션 설계

파티션 유형

• 범위 분할 (Range Partitioning)
  • 지정한 열의 값을 기준으로 분할
• 해시 분할 (Hash Partitioning)
  • 해시 함수를 적용한 결과 값에 따라 데이터 분할
• 조합 분할 (Composite Partitioning)
  • 범위 분할 후 해시 함수를 적용하여 다시 분할

22. 소프트웨어 재사용 방법

합성 중심 (Composition-Based)

• 전자 칩과 같은 소프트웨어 부품 (블록(모듈))을 만들어서 끼워 맞추어 소프트웨어를 완성시키는 방법
• 블록 구성 방법이라고도 한다.

23. 프로젝트 관리

일정 관리

• 활동 순서, 활동 기간 산정, 일정 개발, 일정 통제

인력 관리

• 프로젝트팀 편성, 프로젝트 조직 정의, 프로젝트팀 개발, 프로젝트팀 관리, 자원 산정, 자원 통제

24. DBMS 분석 시 고려사항

• 가용성, 성능, 기술 지원, 주변 기기, 구축 비용

25. 린(Lean) 개발 방법론

• TPS (Toyota Production System)을 재정립한 경영방법론인 린 시스템의 품질 기법을 소프트웨어 개발에 적용한 개발 방법론

1. 특징

품질 기법

• 린 공학 품질 기법을 SW 개발 프로세스에 적용

낭비 요소 제거

• 낭비요소 제거하고 7가지 재발원칙 준수
  • 낭비의 제거를 통해서 지속적인 개선 및 수명 속도를 높이거 효과적으로 품질을 개선

2. 7가지 개발원칙

Eliminate waste (낭비의 제거)

• 불필요한 코드나 기능, 불분명한 요구사항,
• 느린 커뮤니케이션 이나 프로세스,
• 관료적 습관 등 상품의 가치에 영향을 미치지 않는 모든 것을 제거

Amplify Learning (배움 증폭)

• 프로젝트가 진행간 학습할 필요가 있음, 고객의 학습도 필요

Defer Commitment (늦은 결정)

• 중요한 문제에 대한 의사 결정을 최대한 미룸
• 요구사항 면경에 적응적으로 대응 할 수 있게 함

Empower th Team (팀에 권한 위임)

• 직원들의 동기부여 및 자기의사결정권으로 잠재력 극대화

Deliver Fast (빠른 인도)

• 최대한 빨리 결과물을 제공할 것, 고객이 요구사항을 변경할 시간을 주지 않음, 또한 결점을 발견할 수 있는 시간 제공
• 고객의 불확실성 감소 -> 사실에 기반한 결정
• 불필요한 개발로 인한 낭비 감소로 비용 우위

Build Integrity in (통합성 구축)

• 개발 초기부터 품질을 향상 시키도록 하는 것, 작은 개발 단계마다 오류를 발견하고 수정하는 작업

Optimize the whole (전체를 최적화

• 요구사항 수집부터 제품을 릴리즈하는 시점까지 모든 프로세스를 최적화 해야 함
• 가치 흐름에 초점을 맞추고, 완전한 제품을 인도해라

26. CMMI (Capability Maturity Model Integration)

• CMM을 발전시킨 것
• 소프트웨어와 시스템 공학의 역량 성숙도를 평가하는 모델

1. 프로세스 영역

• 프로세스 관리 (Process Management)
• 프로젝트 관리 (Project Management)
• 공학 (Engineering)
• 지원 (Support)

2. 조직 성숙도 레벨 5단계

레벨 1(Initial)

• 개인의 역량에 따라 프로젝트의 성공과 실패가 좌우된다. 소프트웨어 개발 프로세스는 거의 없는 상태를 의미한다.

레벨 2(Managed)

• 프로세스 하에서 프로젝트가 통제되는 수준으로 조직은 프로세스에 대한 어느 정도의 훈련이 되었다고 볼 수는 있지만, 일정이나 비용과 같은 관리 프로세스 중심이다. 기존 유사 성공사례를 응용하여 반복적으로 사용한다.
• 기본적인 프로세스 구축에 의해 프로젝트가 관리되고 있는 조직

레벨 3(Defined)

• 레벨 2에서는 프로젝트를 위한 프로세스가 존재한다면 레벨 3에서는 조직을 위한 표준 프로세스가 존재한다. 모든 프로젝트는 조직의 프로세스를 가져다 상황에 맞게 조정하여 승인받아 사용한다.
• 세부 표준 프로세스가 있어 프로젝트가 통제되는 조직

레벨 4(Quantitatively Managed)

• 소프트웨어 프로세스와 소프트웨어 품질에 대한 정량적인 측정이 가능해진다. 조직은 프로세스 데이터베이스를 구축하여 각 프로젝트에서 측정된 결과를 일괄적으로 수집하고 분석하여 품질평가를 위한 기준으로 삼는다.
• 프로젝트 활동이 정략적으로 관리․통제되고 성과 예측이 가능한 조직

레벨 5(Optimizing)

• 이 레벨에서는 지속적인 개선에 치중한다. 조직적으로 최적화된 프로세스를 적용하여 다시 피드백을 받아 개선하는 상위 단계이다.
• 지속적인 개선활동이 정착화 되고 최적의 관리로 프로젝트가 수행되는 조직

27. SPICE 모델 (ISO/IEC 15504)

• 여러 프로세스 개선모형을 국제표준으로 통합한 ISO의 SW 프로세스 모델

28. SDLC (소프트웨어 개발 생명 주기)

1. 프로토타입 모형 (Prototype Model, 원형 모형)

• 사용자의 요구사항을 정확히 파악하기 위해 실제 개발될 소프트웨어에 대한 견본품(Prototype)을 만들어 최종 결과물을 예측하는 모형

2. 나선형 모형 (Spiral Model)

• 보헴(Boehm)이 제안한 것으로, 폭포수 모형과 프로토타입 모형의 장점에 위험 분석 기능을 추가한 모형
• 점진적으로 완벽한 최종 소프트웨어를 개발함

29. 스크럼 (Scrum)

1. 스크럼 개발 프로세스

제품 백로그 (Product Backlog)

• 제품 개발에 필요한 모든 요구사항(User Story)을 우선순위에 따라 나열한 목록

스프린트 계획 회의 (Sprint Planning Meeting)

• 제품 백로그 중 이번 스프린트에서 수행할 작업을 대상으로 단기 일정을 수립하는 회의

스프린트 (Sprint)

• 실제 개발 작업을 진행하는 과정으로, 보통 2~4주 정도의 기간 내에서 진행

일일 스크럼 회의 (Daily Scrum Meeting)

• 모든 팀원이 매일 약속된 시간에 약 15분 정도의 짧은 시간동안 진행 상황을 점검하는 회의

스프린트 검토 회의 (Sprint Review)

• 부분 또는 전체 완성 제품이 요구사항에 잘 부합되는지 사용자가 포함된 참석자 앞에서 테스팅을 수행하는 회의

스프린트 회고 (Sprint Retrospective)

• 스프린트 주기를 되돌아보며 정해놓은 규칙을 잘 준수했는지, 개선할 점은 없는지 등을 확인하고 기록하는 것

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

1. 추상화 (Abstraction)

• 추상화는 문제의 전체적이고 포괄적인 개념을 설계한 후 차례로 세분화하여 구체화시켜 나가는 것
• 인간이 복잡한 문제를 다룰 때 가장 기본적으로 사용하는 방법으로, 완전한 시스템을 구축하기 전에 그 시스템과 유사한 모델을 만들어서 여러 가지 요인들을 테스트할 수 있다
• 추상화는 최소의 비용으로 실제 상황에 대처할 수 있고, 시스템의 구조 및 구성을 대략적으로 파악할 수 있게 해준다.

추상화의 유형

• 과정 추상화
  • 자세한 수행 과정을 정의하지 않고, 전반적인 흐름만 파악할 수 있게 설계하는 방법
• 데이터 추상화
  • 데이터의 세부적인 속성이나 용도를 정의하지 않고, 데이터 구조를 대표할 수 있는 표현으로 대체하는 방법
• 제어 추상화
  • 이벤트 발생의 정확한 절차나 방법을 정의하지 않고, 대표할 수 있는 표현으로 대체하는 방법

31. 성능 테스트 도구

• 애플리케이션의 성능을 테스트하기 위해 애플리케이션에 부하나 스트레스를 가하면서 애플리케이션의 성능 측정 지표를 점검하는 도구

부하(Load) 테스트

• 애플리케이션에 일정 시간 동안 부하를 가하면서 반응을 측정하는 테스트

스트레스(Stress) 테스트

• 부하 테스트를 확장한 테스트로, 애플리케이션이 과부하 상태에서 어떻게 작동하는지 테스트

종류

• JMeter
  • HTTP, FTP 등 다양한 프로토콜을 지원하는 부하 테스트 도구
• LoadUI
  • 서버 모니터링, Drag&Drop 등 사용자의 관리성이 강화된 부하 테스트 도구
• OpenSTA
  • HTTP, HTTPS 프로토콜에 대한 부하 테스트 및 생산품 모니터링 도구

32. 객체지향 방법론

• 현실 세계의 개체(Entity)를 기계의 부품처럼 하나의 객체(Object)로 만들어, 소프트웨어를 개발할 때 기계의 부품을 조립하듯이 객체들을 조립해서 필요한 소프트웨어를 구현하는 방법론
• 구조적 기법의 문제점으로 인한 소프트웨어 위기의 해결책으로 채택되었다.
• 객체지향 방법론의 구성 요소에는 객체(Object), 클래스(Class), 메시지(Message) 등이 있다
• 객체지향 방법론의 기본 원칙에는 캡슐화(Encapsulation), 정보 은닉(Information Hiding), 추상화(Abstraction), 상속성(Inheritance), 다형성(Polymorphism) 등이 있다.

객체지향 방법론의 절차

• 요구 분석 단계 → 설계 단계 → 구현 단계 → 테스트 및 검증 단계 → 인도 단계

33. 소프트웨어 비용 산정

• 소프트웨어의 개발 규모를 소요되는 인원, 자원, 기간 등으로 확인하여 실행 가능한 계획을 수립하기 위해 필요한 비용을 산정하는 것이다
• 소프트웨어 비용 산정을 너무 높게 산정할 경우 예산 낭비와 일의 효율성 저하를 초래할 수 있고, 너무 낮게 산정할 경우 개발자의 부담이 가중되고 품질문제가 발생할 수 있다.
• 소프트웨어 비용 산정 기법에는 하향식 비용 산정 기법과 상향식 비용 산정 기법이 있다.

34. Secure SDLC의 단계별 주요 보안 활동

요구사항 분석 단계

• 보안 항목에 해당하는 요구사항을 식별하는 작업을 수행
• 전산화되는 정보가 가지고 있는 보안 수준을 보안 요소별로 등급을 구분하여 분류
• 조직의 정보보호 관련 보안 정책을 참고하여 소프트웨어 개발에 적용할 수 있는 보안 정책 항목들의 출처, 요구 수준, 세부 내용 등을 문서화

설계 단계

• 식별된 보안 요구사항들을 소프트웨어 설계서에 반영하고, 보안 설계서를 작성
• 소프트웨어에서 발생할 수 있는 위협을 식별하여 보안대책, 소요예산, 사고 발생 시 영향 범위와 대응책 등을 수립
• 네트워크, 서버, 물리적 보안, 개발 프로그램 등 환경에 대한 보안통제 기준을 수립하여 설계에 반영

구현 단계

• 표준 코딩 정의서 및 소프트웨어 개발 보안 가이드를 준수하며, 설계서에 따라 보안 요구사항들을 구현
• 개발 과정 중에는 지속적인 단위 테스트를 통해 소프트웨어에 발생할 수 있는 보안 취약점을 최소화
• 코드 점검 및 소스 코드 진단 작업을 통해 소스 코드의 안정성을 확보

테스트 단계

• 설계 단계에서 작성한 보안 설계서를 바탕으로 보안 사항들이 정확히 반영되고 동작되는지 점검
• 동적 분석 도구 또는 모의 침투테스트를 통해 설계 단계에서 식별된 위협들의 해결여부를 검증
• 설계 단위에서 식별된 위협들 외에도 구현 단계에서 추가로 제시된 위협들과 취약점들을 점검할 수 있도록 테스트 계획을 수립하고 시행

유지보수 단계

• 이전 과정을 모두 수행하였음에도 발생할 수 있는 보안 사고들을 식별하고, 사고 발생 시 이를 해결하고 보안 패치를 실시

35. 요구공학 (Requirements Engineering)

• 무엇을 개발해야 하는지 요구사항을 정의하고, 분석 및 관리하는 프로세스를 연구하는 학문
• 점점 복잡하고 대형화되어가는 소프트웨어 개발 환경에 따라 사용자 요구사항도 더욱 복잡해지고 잦은 변경이 발생하는 데, 이는 요구사항에 문제가 발생할 가능성을 높이며 요구사항 관리가 잘못될 수 있는 원인이 된다.
• 요구공학은 요구사항 변경의 원인과 처리 방법을 이해하고 요구사항 관리 프로세스의 품질을 개선하여 소프트웨어 프로젝트 실패를 최소화하는 것을 목표로 한다.

36. 요구사항 분석 (Requirement Analysis)

• 개발 대상에 대한 사용자의 요구사항 중 명확하지 않거나 모호하여 이해되지 않는 부분을 발견하고 이를 걸러내기 위한 과정
• 사용자 요구사항의 타당성을 조사하고 비용과 일정에 대한 제약을 설정한다
• 내용이 중복되거나 하나로 통합되어야 하는 등 서로 상충되는 요구사항이 있으면 이를 해결한다
• 도출된 요구사항들을 토대로 소프트웨어의 범위를 파악한다
• 도출된 요구사항들을 토대로 소프트웨어와 주변 환경이 상호 작용하는 방법을 이해한다.

37. IPC (프로세스간 통신)

A. 대표 메소드

Shared Memory

• 다수의 프로세스가 공유 가능한 메모리를 구성하여 프로세스 간 통신을 수행함

Socket

• 네트워크 소켓을 이용하여 네트워크를 경유하는 프로세스들 간 통신을 수행함

Semaphores

• 공유 자원에 대한 접근 제어를 통해 프로세스 간 통신을 수행함

Pipes & named Pipes

• 'Pipe'라고 불리는 선입선출 형태로 구성된 메모리를 여러 프로세스가 공유하여 통신을 수행함

Message Queueing

• 메시지가 발생하면 이를 전달하는 형태로 프로세스 간 통신을 수행함

38. ISO/IEC/IEEE 29119-3 표준의 케이스 구성 요소

식별자(Identifier)

• 항목 식별자, 일련번호

테스트 항목(Test Item)

• 테스트 대상(모듈 또는 기능)

입력 명세(Input Specification)

• 입력 데이터 또는 테스트 조건

출력 명세(Output Specification)

• 테스트 케이스 수행 시 예상되는 출력 결과

환경 설정(Environmental Needs)

• 필요한 하드웨어나 소프트웨어의 환경

특수 절차 요구(Special Procedure Requirement)

• 테스트 케이스 수행 시 특별히 요구되는 절차

의존성 기술(Inter-case Dependencies)

• 테스트 케이스간의 의존성

39. 형상 관리 기능의 종류

형상 식별

• 형상 관리 대상에 이름과 관리 번호를 부여하고, 계층(Tree) 구조로 구분하여 수정 및 추적이 용이하도록 하는 작업

버전 제어

• 소프트웨어 업그레이드나 유지 보수 과정에서 생성된 다른 버전의 형상 항목을 관리하고, 이를 위해 특정 절차와 도구(Tool)를 결합시키는 작업

형상 통제(변경 관리)

• 식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선(Base Line)이 잘 반영될 수 있도록 조정하는 작업

형상 감사

• 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업

형상 기록(상태 보고)

• 형상의 식별, 통제, 감사 작업의 결과를 기록, 관리하고 보고서를 작성하는 작업

40. 장애 허용 시스템(FTS, Fault Tolerance System)

A. 마스터-슬레이브 패턴(Master-Slave Pattern)

• 마스터 컴포넌트에서 슬레이브 컴포넌트로 작업을 분할한후, 슬레이브 컴포넌트에서 처리된 결과물을 다시 돌려받는 방식으로 작업을 수행하는 패턴이다.
• 마스터 컴포넌트는 모든 작업의 주체이고, 슬레이브 컴포넌트는 마스터 컴포넌트의 지시에 따라 작업을 수행하여 결과를 반환한다
• 장애 허용 시스템과 병렬 컴퓨팅 시스템에서 주로 활용된다.

41. 소프트웨어 품질 표준

A. ISO/IEC 9126

• 소프트웨어의 품질 특성과 평가를 위한 표준 지침

B. ISO/IEC 12119

• ISO/IEC 9126을 준수한 품질 표준으로 테스트 절차도 규정함

C. ISO/IEC 14598

• 소프트웨어 품질의 측정, 평가에 필요 절차를 규정한 표준으로, 개발자, 구매자, 평가자 별로 제품 평가 활동을 규정함

D. ISO/IEC 25010

• ISO/IEC 9126을 개정하여 만든 소프트웨어 제품에 대한 국제 표준으로 호환성과 보안성이 강화됨

42. APM(Application Performance Management/Monitoring)

• 애플리케이션의 성능 관리를 위해 접속자, 자원 현황, 트랜잭션 수행 내역, 장애 진단 등 다양한 모니터링 기능을 제공하는 도구를 의미한다

A. 리소스 방식

• Nagios, Zabbix, Cacti 등

B. 엔드투엔드 방식

• VisualVM, 제니퍼, 스카우터 등

43. 어플리케이션 성능 측정 항목

• 응답시간
• 처리량
• 자원 사용률
• 경과 시간

Notion 정리본

https://www.notion.so/mildsalmon/3-ebe48c15bc2f4ac28464e5db1570c6e2