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

- Author: @mildsalmon
- Published: 2021-03-28
- Updated: 2021-04-12
- Source: http://blex.me/@mildsalmon/%ED%95%84%EA%B8%B0-%EA%B3%B5%EB%B6%80-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EA%B3%B5%ED%95%99
- Tags: 정보처리기사, 필기, 소프트웨어공학

---

# 1. 모델링 언어

### 구조적 방법론

##### DFD (Data Flow Diagram)

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

    
![](https://static.blex.me/images/content/2021/3/28/13_1LUcjdobVmecbnyYwarR.png)

##### DD (Data Dictionary)

[자료 사전의 기호](https://www.notion.so/eb962e412f844a86b4491f73dca5eec4)

- 프로세스 명세 (Process Specification)

### 정보공학 방법론

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

##### ERD (Entity-Relationship Diagram)

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

![](https://static.blex.me/images/content/2021/3/28/13_iaLE0TOuiJPjvd6X7HF5.png)

### 객체지향 방법론

##### 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)를 선 위에 표기

      ![](https://static.blex.me/images/content/2021/3/28/13_8vduMwB0UIpQaQz1Bya7.png)

      ![](https://static.blex.me/images/content/2021/3/28/13_lhEKrNuotmME2R9K2xAV.png)

    ##### 집합(Aggregation) 관계

    - `하나의 사물이 다른 사물에 포함되어 있는 관계`
    - 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적
    - 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 빈 마름모를 연결하여 표현
    - `부분-전체(Part-Whole)`, `부분(is-a-part-of)`

      ![](https://static.blex.me/images/content/2021/3/28/13_sL6QWa2W9owmViQdLEXA.png)

    ##### 포함(Composition) 관계

    - `포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계`
    - 포함하는 쪽(전체, Whole)과 포함되는 쪽(부분, Part)은 서로 독립적일 수 없고, 생명주기를 함께한다
    - 포함되는 쪽(부분, Part)에서 포함하는 쪽(전체, Whole)으로 속이 채워진 마름모를 연결하여 표현

      ![](https://static.blex.me/images/content/2021/3/28/13_DgqOAmBaEH6SvSh56PaA.png)

    ##### 일반화(Generalization) 관계

    - `하나의 사물이 다른 사물에 비해 더 일반적인지 구체적인지를 표현`
    - 일반적인 개념을 상위(부모), 보다 구체적인 개념을 하위(자식)
    - 구체적(하위)인 사물에서 일반적(상위)인 사물 쪽으로 속이 빈 화살표를 연결하여 표현
    - `is-a`

      ![](https://static.blex.me/images/content/2021/3/28/13_O72ezYszlDnmgL8m5EjE.png)

    ##### 특수화(Specialization) 관계

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

    ##### 의존(Dependency) 관계

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

     ![](https://static.blex.me/images/content/2021/3/28/13_mFOXmDZW8t5HMTfLXD7U.png)

    ##### 실체화(Realization) 관계

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

      ![](https://static.blex.me/images/content/2021/3/28/13_1VIw00MIU77Q5cmqt20b.png)

    # 다이어그램(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>> 클래스
    - 데이터의 관리를 담당하는 부분

![](https://static.blex.me/images/content/2021/3/28/13_dYKmvJHmGJe6e7ZnAmGI.png)

# 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 품질 특성](https://www.notion.so/7cfef1f5831142bca28a56453597889c)

# 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)로 발전

![](https://static.blex.me/images/content/2021/3/28/13_jAso1utlxpSTK1ZUxBc7.png)

![](https://static.blex.me/images/content/2021/3/28/13_WdSBTSBjnLGRnaOpTk2k.png)

# 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. 일정 계획의 이업 순서 결정, 소작업의 개발 기간, 순서, 필요한 자원 등의 일정 계획

![](https://static.blex.me/images/content/2021/3/28/13_WdSBTSBjnLGRnaOpTk2k.png)

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

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

    ##### 작업 패키지(work package)

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

      ![](https://static.blex.me/images/content/2021/3/28/13_8yWTXULr9UZH4pAA3xr6.png)

    ##### WBS의 목적과 용도

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

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

- WBS의 작업 순서, 소요 기간 등을 네트워크 형태의 그래프로 표현한 후 어떤 작업이 중요한지, 또 일정에 여유가 있는 작업은 어떤 것인지 찾아내 중점 관리를 해야 하는 작업을 명확히 하는데 사용
    - 프로젝트를 완료할 수 있는 최소 기간은 얼마인지,
    - 완료 기간을 맞추기 위해서는 각 작업을 언제 시작하고 완료해야 하는지,
    - 지연되지 않으려면 어떤 작업에 특히 주의를 기울여야 하는지
    - 또 전체 프로젝트 완료 기간을 단축하기 위해서는 어떤 작업들을 단축하는 것이 가장 경제적인지 등
        - 관리자의 고민에 답을 주기 위해 필요한 도구

          ![](https://static.blex.me/images/content/2021/3/28/13_qgseeZ7pSDxbbpSHa4U3.png)

    ##### CPM 네트워크를 그린다

    - 노드(node)와 간선(edge)을 이용해 표 3-17에 대한 초기의 CPM 네트워크를 그린다
    - 노드
        - 작업
    - 간선들
        - 작업들 간의 선후 의존관계
        - 화살표 뒤의 작업은 화살표 전의 작업이 끝나야 시작할 수 있다

         ![](https://static.blex.me/images/content/2021/3/28/13_LBtjBG6COM5vATmwmqhi.png)

    ##### ES(Earliest Start Time) 값을 구한다

    - 가능한 빨리 시작할 수 있는 시간으로,
        - 즉, 선행 작업이 완료되었을 때 해당작업을 시작할 수 있는 가장 빠른 시점
    - ES 값을 구할 때는 맨 앞(작업 A)에서 끝 방향으로 가며 계산

      ![](https://static.blex.me/images/content/2021/3/28/13_cVWEAvKdRIA8Uyp6puGx.png)

    ##### EF(Earliest Finish time) 값을 구한다

    - 가장 빠른 시작 시간(ES)으로 시작했을 때의 가장 빠른 완료 시간
        - 즉, 가능한 빨리 끝낼 수 있는 시간으로 'ES + 작업 소요 시간'

         ![](https://static.blex.me/images/content/2021/3/28/13_xLRBURIeLxrCZXiGQnt8.png)

    ##### LS(Latest Start Time) 값을 구한다

    - 어떤 작업이 늦어도 시작해야 하는 시간
        - 즉, 가장 늦게 시작할 수 있는 시간
    - 이 시간에 시작하지 않으면(이 시간보다 늦게 시작하면) 총 일정이 지연

      ![](https://static.blex.me/images/content/2021/3/28/13_Ij5nml3JFhuYzW7WqoTu.png)

      ![](https://static.blex.me/images/content/2021/3/28/13_CFMhzj0ZR6EhDlrRQBxd.png)

    ##### LF(Latest Finish Time) 값을 구한다

    - 가장 늦게 시작할 수 있는 시간(LS)에 시작해 작업을 완료한 시간
        - 즉, 작업을 가장 늦게 끝낼 수 있는 시간으로 'LS + 작업 소요 시간'

         ![](https://static.blex.me/images/content/2021/3/28/13_jPFArpQfdCjJWQu079iL.png)

    ##### ST(Slack Time) 값을 구한다

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

          ![](https://static.blex.me/images/content/2021/3/28/13_71ZSnOtVzn0tDgGYNeLg.png)

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

    - 임계 경로
        - A지점에서 B지점으로 가는데 가장 오래 걸리는 경로를 의미
    - 임계경로에 있는 작업 하나가 1일 지연되면 전체 일정이 1일 지연

      ![](https://static.blex.me/images/content/2021/3/28/13_cU6SUGKnBYEVKMUeFUDC.png)

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

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

    ![](https://static.blex.me/images/content/2021/3/28/13_qimnzD5jSisP1cvGs5UI.png)

### 5. Project 일정 계획 순서

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

# 13. NS (Nassi-Schneiderman) 차트

  ![](https://static.blex.me/images/content/2021/3/28/13_D3h2nHWj6TyQvtakXrSj.png)

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

### 관점

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

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

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

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

### 구성요소

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

  ![](https://static.blex.me/images/content/2021/3/28/13_vN7Nc92jr7d9PXROxXfT.png)

- 먼저 순차처리 네모 박스에 입력, 출력, 연산을 기록한다
- 선택 구조는 IF문이나 CASE문을 사용하여 처리 흐름을 기록한다
- 반복구조는 While문이나 For문을 사용하여 조건에 따른 반복처리를 기술한다

    ![](https://static.blex.me/images/content/2021/3/28/13_C9lE3JpWwCTSHvsBVqCK.png)

    - 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)

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

![](https://static.blex.me/images/content/2021/3/28/13_x18GrbREbLxFMe9SBiCm.png)

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

![](https://static.blex.me/images/content/2021/3/28/13_zWj7Sh8dZl5CT95S38FA.png)

##### Singleton 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_QOViYhFWWib8RvuKyDzE.png)

##### Prototype 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_IjAOYTvzZ3c1paYq8GY6.png)

##### Builder 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_cJDX5lILMP2YuZDNyAxy.png)

##### Abstract factory 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_FaMhda1r53MEuX7X3SC5.png)

### 2. 구조 패턴

##### Composite 패턴

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

##### Adapter 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_2VxjIy0Tb3qv8VdKnanQ.png)

##### Bridge 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_EEEcWmCuF8cXdvvS55yE.png)

##### Decorator 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_0iNmhEs2nqfN0jt0HrlL.png)

##### Facade 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_bj4AjBC0dH6TcObMRMth.png)

##### Flyweight 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_T9vG0ytG7SMhKXabK8Z1.png)

##### Proxy 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_5xE7H3TLbeLC1HspqguJ.png)

### 3. 행위패턴

##### iterator 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_dhEt30oLmub71Pa6WtX7.png)

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

![](https://static.blex.me/images/content/2021/3/28/13_Kb4H7VftgpHEW3ZI4aOM.png)

##### observer 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_eOgU7HUzuQNjoXv71xBg.png)

##### strategy 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_eR2GgUpUMR9BMftZZxa7.png)

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

##### template method 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_YWMQZ099BbyLvWyGMMkG.png)

##### Visitor 패턴

- visitor : 방문자
- 각 클래스의 데이터 구조로부터 처리 기능을 분리하여 별도의 visitor 클래스로 만들어놓고 해당 클래스의 메소드(visitElement A, visitElement B)가 각 클래스를 돌아다니며 특정 작업을 수행하도록 하는 것
- 객체의 구조와 기능을 분리
- 객체의 구조는 변경하지 않으면서 기능만 따로 추가하거나 확장할 때 많이 사용

    ##### 장점

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

![](https://static.blex.me/images/content/2021/3/28/13_xMDkUHzcUaX1ooXX4A8b.png)

![](https://static.blex.me/images/content/2021/3/28/13_kCnL92QKMrRbSDwBlIrH.png)

##### chain of responsibility 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_8MIif5BWGhMhRz28aGUB.png)

![](https://static.blex.me/images/content/2021/3/28/13_Hau8CnSRlolElCRk7vDI.png)

##### command 패턴

- command : 명령어
    - 문서편집기의 복사, 붙여넣기, 잘라내기 등
- 위 명령어를 각각 구현하는 것보다는 위 그림처럼 하나의 추상 클래스에 execute() 메소드를 하나 만들고 각 명령이 들어오면 그에 맞는 서브 클래스(copy_command)가 선택되어 실행하는 것이 효율적
- 단순히 명령어를 추상 클래스와 구체 클래스로 분리하여 단순화한 것을 끝나지 않고, 명령어에 따른 취소(undo) 기능까지 포함

    ##### 이유

    - 사용자 입장에서는 해당 명령어를 실행했다가 취소(undo)하기도 하기 때문
- 이렇게 프로그램의 명령어를 구현할 때 command 패턴을 활용
- 대규모 클래스를 포함하는 아키텍처를 관리
- 이미 수행한 4개의 결정을 언제든지 취소하게 함(undo)

![](https://static.blex.me/images/content/2021/3/28/13_2DbrzlelAF53ZeQWFcO4.png)

##### mediator 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_hy8R7t4OfKVsK0zdsj1Y.png)

![](https://static.blex.me/images/content/2021/3/28/13_YJyaArwPFwmUFB79qSXT.png)

##### state 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_a7u2VCP2Q7aQ1DcIBbUV.png)

##### memento 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_OoA1GiTnoM7teQwKE4xu.png)

##### interpreter 패턴

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

![](https://static.blex.me/images/content/2021/3/28/13_6Z3HVLCBCqaYPrXwyRwL.png)

# 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 프로세스 모델

![](https://static.blex.me/images/content/2021/3/28/13_IqgCGhQtf0JhXQ6PXuMi.png)

# 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](https://www.notion.so/mildsalmon/3-ebe48c15bc2f4ac28464e5db1570c6e2)