내가 보려고 정리한 것
▶ 나선형 = 폭포수 + 프로토타입 + 위험 분석 기능 추가
▶ 애자일(Agile) = 일정한 짧은 주기 반복하며 개발 진행
Ex, XP(eXtreme Programming), Scrum, FDD(기능중심), 린(LEAN), DSDM(Dynamic System. Development Method)
1. 프로젝트 계획
▶ 하향식 비용산정 기법
- 전문가 감정 기법 : 외부 전문가에게 비용 산정 의뢰 (객관적)
- 델파이 기법: 한 명의 조정자와 여러 전문가의 의견을 종합하여 산정
▶ 상향식 비용 산정 기법
- LOC 기법 : a + 4c + b / 6 (낙관치 a, 비관치 b, 기대치c)
▶ 수학적 비용 산정
- COCOMO(Constructive Cost Model) : 보헴이 제안 / 원시코드 라인수 기반
| 유형 | 조직형(Organic) | 중,소규모 SW용 / 5만 라인(50KDSI) 이하 |
| 반분리형(Semi-detached) | 30만 라인 (300KDSI) 이하의 트랜잭션 처리 시스템 | |
| 내장형(Embedded) | 30만 라인 (300KDSI) 이상의 최대형 규모 SW관리 |
- PUTNAM: Rayleigh Norden 곡선의 노력 분포도를 기초로 한다.
(★SLIM: Rayleigh-Norden 곡선 / Putnam 모형 기초로 개발된 자동화 추정 도구)
- Function Point(FP): SW 기능 증대 요인에 가중치 부여 후 합산하여 기능점수 산출
(★ESTIMACS: FP모형을 기반으로 하여 개발된 자동화 추정 도구)
▶ 네트워크 차트
| PERT (Program Evaluation and Review Technique) |
- 프로젝트 작업 상호관계를 네트워크로 표현 - 원 노드(작업)과 간선(화살표)로 구성(@불확실한 내용) → 간선에는 작업별 낙관치/기대치/비관치 기재 |
| CPM (Critical Path method) |
- 미국 Dupont 회사에서 화학공장 유지/관리 위해 개발 - 노드(작업) / 간선(작업 전후 의존 관계) / 박스(이정표) 구성 - 간선(화살표)의 흐름에 따라 작업 진행(@확실한 상황) |
⭐ CPM은 임계경로 구하는 문제 단골임
▶ 간트 차트
- 각 작업의 시작 / 종료 일정을 막대 바(Bar) 도표를 이용하여 표현
- 시간선(Time-line) 차트 (수평 막대 길이 = 작업기간)
- 작업 경로는 표현 불가 / 계획 변화에 대한 적응성이 낮음
2. 요구사항 분석
| 기능적 요구사항 | 실제 시스템 수행에 필요한 기능 관련 요구사항 ex) 금융 시스템은 조회/인출/입금/송금 기능이 있어야 한다. |
| 비기능적 요구사항 | 성능, 보안, 품질, 안정성 등 실제 수행에 보조적인 요구사항 ⭐성능은 비기능적 요구사항이다. ex) 모든 화면이 3초 이내에 사용자에게 보여야 한다. |
▶ 요구사항 개발 프로세스
| ① 도출/추출 | 이해관계자들이 모여 요구사항 정의(식별하고 이해하는 과정) Ex. 인터뷰, 설문, 브레인스토밍, 청취, 프로토타이핑, 유스케이스 |
| ② 분석 | 사용자 요구사항에 타당성 조사 / 비용 및 일정에 대한 젲약 설정 Ex. 관찰, 개념 모델링, 정형 분석, 요구사항 정의 문서화 |
| ③ 명세 | 요구사항 체계적 분석 후 승인가능하도록 문서화 |
| ④ 확인/검증 | 요 구사항 명세서가 정확하고 완전하게 작성되었는지 검토 |
▶ 요구사항 분석 도구
| 요구사항 분석 CASE (Computer Aided SW Engineering) |
- SADT : SoftTech 사에서 개발 / 구조적 분석 및 설계분석 - SREM : 실시간 처리 SW 시스템에서 요구사항 명확한 기술 목적 - PSL / PSA: 문제 기술언어 및 요구사항 문석 보고서 출력 - TAGS : 시스템 공학 방법 응용에 대한 자동 접근 방법 |
| ⭐ HIPO (Hierarchy Inpupt Process Output) |
- 하향식 설계 방식 / 가시적, 총체적, 세부적 다이어그램으로 구성 기능과 자료의 의존 관계 동시 표현 / 이해쉽고 유지보수 간단 |
▶ 구조적 분석 모델
- 데이터 자료 흐름도(DFD, Data flow diagram)
- 자료 사전 (DD, Data Dictionary)
▶ 객체지향 분석 모델
- Booch(부치): 미시적, 거시적 개발 프로세스를 모두 사용 (클래스/객체 분석 및 식별)
- Jacobson(제이콥슨): Use case를 사용 (사용자, 외부 시스템이 시스템과 상호 작용)
- Coad-Yourdon: E-R다이어그램 사용 / 객체의 행위 모델링
- Wrifs-Brock: 분석과 설계 구분이 없으며 고객 명세서 평가 후 설계 작업까지 연속 수행
- Rumbaugh(럼바우): 가장 일반적으로 사용, ⭐ 객체/동기/기능 모델로 구분
▶ 럼바우
- 객체 모델링(Object) → 객체 다이어그램 / 객체들 간의 관계 규정/정의
- 동적 모델링(Dynamic) → 상태 다이어그램 / 시스템 동적인 행위 기술
- 기능 모델링(Function) → 자료 흐름도(DFD) / 다수의 프로세스들 간의 처리 과정 표현
▶ 요구사항 명세
| 정형 명세 | 수학적 원리 VDM, Z, Petri-net, CSP |
| 비정형 명세 | 자연어, 그림 중심 FSM, Decision Table, E-R모델, State Chart |
3. 소프트웨어 설계
⭐ 아키텍쳐 패턴
■ Layer
시스템을 계층으로 구분하는 고전적 방식(OSI 참조 모델)
■ Client-server
하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성
클라이언트와 서버는 요청/응답 제외 시 서로 독립적
* 컴포넌트(Component): 독립적 업무/기능 수행 위한 실행 코드 기반 모듈
■ Pipe-Filter
데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화 후
데이터 전송 / 재사용 및 확장 용이 / 필터 컴포넌트 재배치 가능
단방향으로 흐르며, 필터 이동 시 오버헤드 발생
변환, 버퍼링, 동기화 적용 ( ex. UNIX 쉘 - Shell)
■ Model-View-Controller
모델(Model): 서브 시스템의 핵심 기능 및 데이터 보관
뷰(View): 사용자에게 정보 표시
컨트롤러(Controller): 사용자로부터 받은 입력 처리
→ 각 부분은 개별 컴포넌트로 분리되어 서로 영향 X
■ Master-slave
마스터에서 슬레이브 컴포넌트로 작업 분할/분리/배포 후 슬레이브에서 처리도니 결과물을 다시 돌려 받음 (병렬 컴퓨팅)
■ Broker
컴포넌트와 사용자를 연결 (분산 환경 시스템)
■ Peer-to-Peer
피어를 한 컴포넌트로 산정 후 각 피어는 클라이언트가 될 수도, 서버가 될 수도 있음 (멀티스레딩)
■ Event-bus
소스가 특정 채널에 이벤트 메시지를 발행 시 해당 채널을 구독한 리스너들이 메세지를 받아 이벤트를 처리함
■ Blackboard
컴포넌트들이 검색을 통해 블랙보드에서 원하는 데이터 전송
■ Interpreter
특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트 설계
⭐ UML (Unified Modeling Launguage)
- 구성요소 : 사물, 관계, 다이어그램- Rumbaugh, Booch, Jacobson 등 객체지향 방법론의 장점 통합* 인터페이스: 클래스/컴포넌트가 구현해야 하는 오퍼레이션 세트를 정의하는 모델 요소
▶ 사물 (Things) : 구조(개념, 물리적 요소) / 행동 /그룹 / 주해(부가적 설명, 제약조건)
▶ 관계(Relationship)
UML의 관계는 사물과 사물 사이의 연관성을 표현하는 것이다. ★2024년 3차에 나와서 안 나올 것 같지만 굳이 정리합니다.
1) 연관 관계(Association)
2개 이상의 사물이 서로 관련되어 있는 관계 이다. 사물 사이의 다중도를 표현할 수 있음.
학생은 한 학교에 다니는 관계이며 학생은 1명 이상이다.
선생은 학생을 가르치고 학생은 선생에게 가르침 받는 관계이다.
학생은 한 명 이상의 선생으로부터 가르침을 받고, 선생은 한 명이상의 학생을 가르친다.
2) 집합(Aggregation)
하나의 사물이 다른 사물에 포함되어있는 관계인 것을 나타내고 서로 독립적이다.
프린터는 컴퓨터에 연결해서 사용할 수 있으며, 다른 컴퓨터에 연결해서 사용할 수도 있다.
다른 컴퓨터에 연결이 가능하므로 독립적이라고 할 수 있다.
3) 포함(Composition)
집합과 비슷한 포함관계이지만 다른점은 서로 독립될 수 없다.
(포함하는쪽이 사라지면 포함된 쪽은 사라짐)
문을 열 수 있는 열쇠는 하나이며 해당 열쇠로는 다른 문을 열 수 없다.
그리고 문이 없어지면 열쇠도 더 이상 필요없다.
4) 일반화(Generalization)
상속관계라고 할 수 있다. 일반화라는 말 그대로 하나의 사물로 묶어서 나타내는 것이다.
사자(자식)와 코끼리(자식)는 동물(부모)이다.
5. 의존(Dependency)
서로 연관은 있으나 필요할 때만 관계가 형성되는 것을 나타낸다.
등급이 높으면 할인율을 적용하고 등급이 낮으면 할인율을 적용하지 않는다.
6. 실체화(Realization)
어떠한 관계로 사물을 그룹화 할 수 있는 것을 나타낸다.
비행기와 새는 날 수 있는 행동으로 그룹지을 수 있다.
⭐ 다이어그램 (Diagram)
| 구조, 정적 다이어그램 |
클래스(Class) | 클래스 사이의 관계 및 속성 표현 |
| 객체(Object) | 인스턴스를 객체와 객체 사이의 관계로 표현 | |
| 컴포넌트(Component) | 구현 모델인 컴포넌트 간의 관계 표현 | |
| 배치(Deployment) | 물리적 요소(HW/SW)의 윛기/구조 표현 | |
| 복합체구조 (Composite Structure) |
클래스 및 컴포넌트의 복합체 내부 구조 표현 | |
| 패키지(Package) | UML의 다양한 모델요소를 그룹화하여 묶음 | |
| 행위, 동적 다이어그램 |
유스케이스(use case) | 사용자의 요구를 분석 (사용자 관점) → 사용자(Actor) + 사용 사례(Use Case) |
| 시퀀스(Sequence) | 시스템/객체들이 주고받는 메시지 표현 → 구성 항목: 액터 / 객체 / 생명선 / 메시지 제어 삼각형 |
|
| 커뮤니케이션(Communication) | 객체들이 주고 받는 메세지와 객체 간의 연관관계까지 표현 | |
| 상태(State) | 다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는지 표현 | |
| 활동(Activity) | 객체의 처리 로직 및 조건에 따른 처리의 흐름을 순서에 따라 표현 | |
| 타이밍(Timing) | 객체 상태 변화와 시간 제 약 명시적으로 표현 | |
| 상호작용 개요 (Interaction Overview) |
상호작용 다이어그램 간 제어 흐름 표현 |
▶ UI 설계
- 직관성, 유효성, 학습성, 유연성
- CLI(Command Line) : 텍스트
- GUI(Graphical) : 그래픽
- NUI(Natural): 말/행동
- VUI(Voice): 음성
- OUI(Organic): 사물과 사용자 상호작용
▶ UI 설계 도구
- Wireframe : 기획 초기 단계에 대략적인 레이아웃 설계
- StoryBoard: 최종적인 산출 문서
- Prototype: 와이어프레임 / 스토리보드에 인터랙션 적용, 실제 구현된 것처럼 테스트가 가능한 동적인 형태 모형
- Mockup: 실제 화면과 유사한 정적인 형태 모형
- Use case: 사용자 측면 요구사항 및 목표를 다이어그램으로 표현
4. 소프트웨어 구현
▶ 소프트웨어 개발 프레임워크
- Spring 프레임워크 : JAVA 플랫폼을 위한 오픈 소스 경량형 프레임워크 (동적 웹사이트 개발)
- 전자정부 프레임워크 : 우리나라 공공부문 정보화 사업시 효율적인 정보 시스템, 구축 지원을 위해 필요한 기능/아키텍쳐 제공
- 닷넷 프레임워크: MS에서 개발한 Windows 프로그램 개발, 공통언어 런타임(CLR) 이라는 가상 머신상에서 작동
▶ API (Application Programming Interface)
- 소프트웨어 간 인터페이스 (서로 다른 소프트웨어/서비스 간 상호 작용 용이)
- 운영체제 및 프로그래밍 언어의 기능을 프로그램에서 사용 가능하도록 구현
⭐ 응집도 (Cohesion)
- 개별 모듈이 독립적인 기능으로 정의되어 있는 정도
- 응집도 ▲ → 품질 ▼
- 외우는법 : 우는시절 교순가
높은 응집도부터 (아래로 갈수록 낮은 응집도)
| 기능적 (Function) | 모듈 내부의 모든 기능 요소가 단일 문제와 연관되어 수행 |
| 순차적 (Sequential) | 모듈 내 출력 데이터를 다음 활동의 입력 데이터로 사용 |
| 통신적 (Communication) = 교환적 |
동일한 입/출력을 사용하여 서로 다른 기능을 수행 |
| 절차적 (Procedural) | 모듈 내 구성 요소들이 다수 관련 기능을 순차적으로 수행 |
| 시간적 (Temporal) | 특정 시간 내 처리되는 기능을 모아 하나의 모듈로 작성 |
| 논리적 (Logical) | 유사한 성격의 처리 요소들로 하나의 모듈이 형성 |
| 우연적 (Coincidental) | 각 구성 요소들이 서로 관련없는 요소로만 구성 |
⭐ 결합도 (Coupling)
- 개별 모듈 간 상호 의존하는 정도
- 결합도 ▼ → 품질 ▲
- 외우는 법: 내 공부 내가 할게요. 제가 스트레스 받자나요
높은 결합도부터 (아래로 갈수록 낮은 결합도)
| 내용 (Content) | 한 모듈이 다른 모듈의 내부 기능 및 자료를 직접 참조/수정 |
| 공통/공유 (Common) | 공유되는 공통 데이터를 여러 모듈이 사용 (전역 변수 참조) |
| 외부 (External) | 한 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조 |
| 제어 (Control) | - 한 모듈이 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나 처리 기능이 두 모듈에 분리되어 설계. - 처리 대상 값 뿐만 아니라 처리 방식의 제어 요소도 전달 |
| 스탬프 (Stamp) | - 두 모듈이 동일한 자료 구조(배열, 오브젝트)를 조회 - 자료 구조 및 포맷 변화 시 조회하고 있는 모든 모듈에 영향 |
| 자료 (Data) | 모듈 간의 인터페이스가 자료 요소로만 구성 |
⭐ 객체지향 (Object-Oriented)
- 객체와 속성, 클래스와 멤버, 전체와 부분으로 나눠 분석
| 객체 (Object) |
고유 식별자 / 하나의 독립된 존재 / 일정한 기억장소 보유 상태(state) = 객체아 가질 수 있는 조건, 속성 값에 의해 정의 행위(연산, method) = 객체가 반응할 수 있는 메시지 집합 |
| 클래스 (Class) |
공통 속성과 연산(행위)을 갖는 객체들의 집합 / 데이터 추상화 단위 * 인스턴스(Instance): 클래스에 속한 각각의 객체 * Operation: 클래스의 동작 / 객체에 대해 적용될 메서드 정의 |
| 캡슐화 (Encapsulation) |
데이터와 데이터 처리 함수를 하나로 묶음 세부 내용 은폐(정보 은닉) → 외부 접근 제한 결합도 낮음 / 재사용 용이 / 인터페이스 단순 / 오류 파급 효과 낮음 |
| 상속 (Inheritance) |
상위 클래스의 속성과 연산을 하위 클래스가 물려 받는 것 * 다중 상속: 단일 클래스가 두 개 이상의 상위 클래스로부터 상속 |
| 다형성 (Polymorphism) |
하나의 메세지에 각 객체 별 고유 특성에 따라 여러 형태의 응답 |
* 오버라이딩(Overriding): 재정의 (단, 메서드 이름 / 매개변수 / 반환 타입은 동일해야 함 - 어노테이션 )
* 오버로딩(Overroading): 메서드 중복정의 (메서드 이름은 동일하나 매개변수의 개수나 타입을 다르게 지정 - 계산기)
⭐ 객체 지향 설계 5대 원칙(SOLID)
- 단일 책임 원칙 (SRP, Single Responsibility Principle) → 모든 클래스&객체는 하나의 책임만 / 완전한 캡슐화
- 개방 폐쇄의 원칙 (OCP, Open Closed Principle) → 확장에는 Open 하고, 수정에는 Close되어야 한다.
- 리스코프 교체 원칙 (LSP, Liskov Substitution Principle) → 상위 클래스의 행동 규약을 하위 클래스가 위반하면 안 된다.
- 인터페이스 분리 원칙 (ISP, Interface Segregation Principle) →클라이언트가 비사용 메서드에 의존하지 않아야 한다.
- 의존성 역전 원칙 (DIP, Dependency Inversion Principle) → 의존 관계 수립 시 변화하기 어려운 것(추상성이 높은 상위 클래스) 에 의존해야 한다.
⭐ GoF(Gang of Four) 디자인 패턴
- 서브 시스템에 속하는 컴포넌트들과 그 관계르 설계하기 위한 참조 모델
- 객체 지향 프로그래밍 설계 시 자주 발생하는 문제에 대한 반복적 해결 방법
cf) 아키텍처 패터니 전체 시스템의 구조를 설계
[생성 패턴]
| Abstract Factory | 구체적인 클래스에 의존하지 않고, 서로 연고나되거나 의존적인 객체들이 조합된 인터페이스 제공 |
| Builder | 객체 생성 단계를 캡슐화/분리하여 객체를 조립하여 생성 → 동일한 객체 생성 절차에서 서로 다른 표현 결과를 제공 |
| Factory Method | 상위 클래스에서 객체 생성 인터페이스를 정의하지만, 인스턴스를 만드는 클래스는 서브 클래스에서 결정하도록 분리 |
| Prototype | 원형/원본 객체를 복제하는 방식으로 객체를 생성 |
| Singleton | 클래스에서 하나의 객체만 생성 가능하며, 해당 객체를 어디서든 참조할 수 있지만 여러 프로세스가 동시에 참조는 불가 |
[구조 패턴]
| Adaptor | 비호환 인터페이스세 호환성 부여하도록 반환 |
| Bridge | 구현부에서 추상층을 분리 후 각자 독립적으로 변형/확장 가능 |
| Composite | 트리 구조로 부분/전체 계층 표현, 복합/단일 객체를 구분 없이 사용 |
| Decorator | 상속 사용 없이 객체 간 결합을 통해 객체 기능을 동적으로 추가/확장 |
| Facade | 상위에 인터페이스 구성하여 서브 클래스의 기능을 복잡하게 표현하지 않고 단순한 인터페이스로 구현 |
| Flyweight | 인스턴스를 공유하여 메모리 절약 (클래스 경량화) |
| Proxy | 접근이 힘든 객체를 연결하는 인터페이스 역할(대리 객체 수행) |
[행위 패턴]
| Chain of Responsibility | 처리 가능한 객체가 둘 이상 존재하여 한 객체 내 처리 불가 시 다음 객체로 이관 |
| command | 요청 명령어들을 추상/구체 클래스로 분리한 후 단순화/캡슐화 |
| Interpreter | 언어에 문법 표현 정의 |
| Iterator | 접근이 빈번한 객체에 대해 동일 인터페이스 사용 |
| Mediator | 객체들간 복잡한 상호작용을 캡슐화하여 객체로 정의 후 중재 |
| Memento | 객체를 이전의 특정 시점의 상태로 저장하고 복원 (캡슐화 유지) |
| Observer | 한 객체 상태 변화 시 상속되어 있는 객체들에 변화 전달 |
| State | 객체의 상태에 따라 동일한 동작을 다르게 처리 |
| Strategy | 동일 계열 알고리즘을 개별적으로 캡슐화하여 상호 교환 |
| Template Method | 여러 클래스에서 공통 사용 메서드를 상위 클래스에서 정의하고, 하위 클래스마다 다르게 구현해야 하는 세부 사항을 개별 구현 |
| Visitor | 각 클래스 데이터 구조로부 터 처리/연산 기능을 분리하여 별도의 클래스를 만들고, 해당 클래스 메서드가 각 클래스를 돌아다니며 특정 작업을 수행 → 객체 구조 변경 X / 새로운 연산기능만 추가 |
5. 소프트웨어 테스트
▶ 애플리케이션 테스트 기본 원리
: 테스트는 기본적으로 결함이 존재함을 밝히는 것 (무결함을 증명할 수는 없음)
→ 완벽한 테스트는 근원적으로 불가능 (무한 경로, 무한 입력 불가)
- 결함 집중 : 파레토(Pareto)의 법칙 - 20%의 모듈에서 전체 결함 80% 발생
- 살충제 패러독스 : 동일한 테스트 케이스에 의한 반복 테스트는 새로운 버그 발견 X
- 오류-부재의 궤변 : 결함이 없다 하여도 사용자의 요구사항 미충족 시 품질 저하
- Brooks의 법칙 : 지연되는 프로젝트에 인력 추가 투입 시 더 지연
▶ 애플리케이션 테스트 분류
① 프로그램 실행 여부
| 정적 테스트 | 프로그램 실행 X / 명세서, 소스 코드만 분석 ex) 동료 검토, 워크 스루, 인스펙션, 코드 검사 |
| 동적 테스트 | 프로그램 실행 후 오류 검사 ex) 화이트/블랙박스 테스트 |
② 테스트 기반 테스트
| 명세 기반 | 사용자의 요구사항에 대한 명세를 빠짐 없이 테스트 케이스로 구현하는지 확인 ex) 동등 분할 / 경계값 분석 (블랙박스) |
| 구조 기반 | SW 내부 논리 흘므에 따라 테스트 케이스 작성/확인 ex) 구문 기반 / 결정 기반 / 조건 기반 (화이트박스) |
| 경험 기반 | 테스터의 경험을 기반으로 수행 ex) 에러 추정, 체크리스트, 탐색적 테스팅 |
③ 목적 기반 테스트
| 회복 (Recovery) | 시스템에 인위적 결함 부여 후 정상으로 회복되는 과정 확인 |
| 안전 (Security) | 외부 불법 침입으로부터 시스템을 보호할 수 있는지 확인 |
| 강도 (Stress) | 과부하 시 SW 정상 구동 여부 확인 |
| 성능 (Performance) | 실시간 성능 및 전체적인 효율성 진단 (응답시간, 업무 처리량) |
| 구조 (Structure) | SW 내부 논리적 경로 및 소스 코드 복잡도 평가 |
| 회귀 (Regression) | SW 내 변경 또는 수정된 코드에 새로운 결함이 없음을 확인 |
| 병행 (Parallel) | 변경 및 기존 SW에 동일한 데이터 입력 후 결과 비교 |
④ 시각(관점) 기반 테스트
| 검증 (Verification) |
개발자의 시각에서 제품의 생산 과정 테스트 ex) 단위/통합/시스템 테스트 |
| 확인 (Validation) |
사용자의 시각에서 생산된 제품의 결과 테스트 ex) 인수 테스트 (알파/베타) |
⭐ 화이트박스 테스트 (White Box Test)
- 모듈 안의 내용(작동) 직접 볼 수 있으며, 내부의 논리적인 모든 경로를 테스트
- 소스 코드의 모든 문장을 한 번 이상 수행 / 논리적 경로 점검 (선택, 반복 수행)
- 테스트 데이터 선택하기 위해 검증 기준 커버리지(Coverage) 정합
[화이트 박스 테스트 검증 기준]
| 구문 커버리지 (Statement Coverage) |
프로그램 내 모든 명령문을 적어도 한 번 수행 |
| 결정(분기) 커버리지 (Branch Coverage) |
프로그램 내 전체 결정문이 적어도 한 번은 참/거짓 결과 수행 |
| 조건 커버리지 (Condition Coverage) |
결정 명령문 내의 각 개별 조건식이 적어도 한 번은 참/거짓 결과 수행 |
| 조건/결정 커버리지 (Condition / Branch) |
전체 조건식 뿐만 아니라 개별 조건식도 참 한 번 이상, 거짓 한 번 이상 결과 수행 |
[화이트박스 테스트 종류]
| 기초 경로 검사 (Base Path Testing) |
대표적 화이트박스 테스트 기법 (동적 테스트) 테스트 케이스 설계자가 절차적 설꼐의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법 측정 결과는 실행 경로의 기초를 정의하는 지침으로 사용 |
| 제어 구조 검사 (Control Structure Testing) |
조건 검사 : 프로그램 모듈 내 논리적 조건 테스트 루프 검사 : 프로그램 반복(Loop) 구조 테스트 자료 흐름 검사 : 변수의 정의와 변수 사용의 위치 테스트 |
⭐ 블랙박스 테스트 (Black Box Test)
- 모듈 내부의 내용 알 수 없음
- 소프트웨어 인터페이스에서 실시되는 테스트
- SW 각 기능이 완전히 작동되는 것을 입증하는 테스트로 '기능 테스트'라고 함
[블랙박스 테스트 종류]
| 동치 분할 검사 (Equivalence Partition) |
프로그램 입력 조건에 타당한 입력 자료와 타당하지 안은 입력 자료의 개수를 균등하게 진행 |
| 경계값 분석 (Boundary Value) |
입력 조건의 경계값을 테스트 케이스로 선정 ex) 범위 구간 양 끝 : ~이상 / 이하 / 초과 / 미만 |
| 원인-효과 그래프 검사 (Cause-Effect Graphing) |
입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석 후 효용성이 높은 테스트 케이스 선정 |
| 오류 예측 검사 (Error Guessing) |
과거의 경험이나 확인자의 감각으로 테스트 진행 |
| 비교 검사 (Comparison) |
여러 버전의 프로그램에 동일한 결과가 출력되는지 확인 |
▶ 요구사항 검증 (Requirements Validation)
- 동료 검토 (Peer Review) : 작성자가 내용 설명 후 동료들이 결함 검토
- 워크 스루 (Walk Through) : 요구사항 명세서 미리 배포 후 짧은 검토 회의 진행
- 인스펙션 (Inspection) : 작성자 제외한 다른 전문가들이 결함 검토
▶ 소프트웨어 생명 주기 (V-모델)
▶ 개발단계에 따른 애플리케이션 테스트
① 단위테스트 (Unit Test)
- 최소 단위(모듈/컴포넌트) 기반 테스트, 즈로 구조 기반 테스트 진행 / 기능성 테스트 최우선
- 소프트웨어를 이루는 기본 단위(독립적 기능 ) 테스트
② 통합 테스트 (Integration test)
- 인터페이스 간 시스템이 정상 실행되는 지 확인
- 단위 테스트 후 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법
| 하향식 (Top-down) |
- 상위 모듈에서 하위 모듈 방향으로 통합 - 깊이 우선(Depth first) 통합법 / 넓이 우선 (Breadth first) 통합법 - 초기부터 사용자에게 시스템 구조 보여줌 - 스텁(Stub) : 모듈의 기능을 단순히 수행하는 도구 (시험용 모듈) |
| 상향식 (Bottom-up) |
- 하위 모듈에서 상위 모듈 방향으로 통합 - 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터(Cluster) 와 드라이버(Driver) 사용 / 스텁(Stub) 미사용 |
③ 시스템 테스트 (System test)
- 개발된 SW의 컴퓨터 시스템 내 작용 여부 점검
- 실제 사용 환경과 유사한 테스트 환경 → 기능적(블랙박스) 및 비기능적(화이트박스) 테스트 구분
④ 인수 테스트 (Acceptance test)
- 사용자의 요구 사항 충족 여부 확인
- 알파 테스트 : 통제된 환경에서 사용자가 개발자와 함께 확인
- 베타 테스트 : 통제되지 않은 환경에서 개발자 없이 여러 명의 사용자가 검증
■ 테스트 관련 기타 용어
| 테스트 시나리오 (Test Scenario) |
테스트 케이스 적용/동작 순서에 따라 여러 테스트 케이스를 묶은 집합 |
| 테스트 오라클 (Test Oracle) |
테스트 결과의 참/거짓 판단 위해 사전에 정의된 참 값을 대입 |
- 참 오라클 (True) : 모든 테스트 케이스의 입력값에 기대 결과 제공
- 샘플링 오라클 (Sampling) : 특정 테스트 케이스 입력값에 기대 결과 제공
- 오라클 (Heuristci) : 특정 테스트 케이스 입력값에 기대 결과 제공 + 나머지 입력값에 대해선 추정 결과 제공
- 일관성 오라클 (Consistent) : 테스트 케이스의 수행 전/후의 결과값 동일 여부 확인
■ 테스트 관련 기타 용어
| 테스트 드라이버 (Test Driver) |
시험 대상의 하위 모듈 호출 / 모듈 테스트 수행 후의 결과 도출 → 상향식 통합 테스트에서 사용 |
| 테스트 스텁 (Test Stub) |
제어 모듈이 호출하는 하위 모듈의 역할 단순 수행 → 하향식 테스트에 사용 |
| 테스트 슈트 (Test Suites) |
시스템에 사용되는 테스트 케이스의 집합 (컴포넌트 / 모듈) |
| 테스트 케이스 (Test Case) |
사용자의 요구사항 준수 여부 확인 위해 설계된 테스트 항목 명세서 (입력값, 실행 조건, 기대 결과 등) |
| 테스트 스크립트 (Test Script) |
자동화된 테스트 실행 절차에 대한 명세서 |
| 목 오브젝트 (Mock Object) |
사용자의 행위 조건부 입력 시 계획된 행위를 수행하는 객체 |
6. 소프트웨어 유지 보수
▶ 소스 코드 품질 분석 도구
| 정적 분석 도구 (Static Analysis) |
프로그램 실행 없이 코딩 표준/스타일/결함 등을 분석 → PMD, Checkstyle, SonarQube, Cppcheck, Ccm, Cobertura |
| 동적 분석 도구 (Dynamic Analysis) |
프로그램 실행하여 코드 내 메모리 누수 및 스레드 결함 발견 → Avalanche, Valgrind, Valance |
▶ 소프트웨어 형상 관리 (SCM: Software Configuration Management)
- 개발 과정에서 SW 변경 사항을 관리하기 위한 일련의 활동 / 개발 전체 단계 적용
- 중요성 : 변경사항 추적 / 통제, 무절제한 변경 방지, 개발진행 이력 확인
- 형상 관리 역할 : 배포본 고나리 용이 / 불필요한 소스 수정 제한 / 여러 개발자 동시 개발
▶ 소프트웨어 버전 관리 도구
| 공유 폴더 | 클라이언트/서버 | 분산저장소 |
| 공유 폴더에 복사 | 서버에서 버전 일괄 관리 | 원격 → 지역 저장소 |
| RCS, SCCS, PVCS, QVCS | CVS, SVN, CVSNT, CMBC | Git, GNU arch, DCVS, Bitkeeper, Bazaar |
▶ 형상 관리 도구
| CVS | 서버/클라이언트 구성, 다수의 인원이 동시 버전 관리 가능 |
| SVN (Subversion) |
CVS 개선 툴 / 모든 개발은 trunk 디렉터리에서 수행 Commit 수행 시 revision 1씩 증가 |
| Git | 서버(원격( 저장소와 개발자(지역) 저장소가 독립적 → Commit 실수 발생해도 서버에 영향 없음 (분산된 P2P모델) |
▶ SPICE(ISO 15504) vs CMMI(Capability Maturity Model Integration)
'정보처리기사' 카테고리의 다른 글
| [정보처리기사] 데이터베이스 정리 (2) (1) | 2025.04.03 |
|---|---|
| [정보처리기사] 데이터베이스 정리 (1) (1) | 2025.04.03 |
| [정보처리기사] 정보 보안 관련 IT 용어 총정리 (9) | 2025.03.29 |
| [정보처리기사] 페이지 교체 알고리즘 (FIFO, LRU, LFU) (3) | 2025.03.29 |
| [정보처리기사] 트리순회 전위, 중위, 후위 표현식 & 정렬 알고리즘 정리 (7) | 2025.03.26 |
내가 보려고 정리한 것
▶ 나선형 = 폭포수 + 프로토타입 + 위험 분석 기능 추가
▶ 애자일(Agile) = 일정한 짧은 주기 반복하며 개발 진행
Ex, XP(eXtreme Programming), Scrum, FDD(기능중심), 린(LEAN), DSDM(Dynamic System. Development Method)
1. 프로젝트 계획
▶ 하향식 비용산정 기법
- 전문가 감정 기법 : 외부 전문가에게 비용 산정 의뢰 (객관적)
- 델파이 기법: 한 명의 조정자와 여러 전문가의 의견을 종합하여 산정
▶ 상향식 비용 산정 기법
- LOC 기법 : a + 4c + b / 6 (낙관치 a, 비관치 b, 기대치c)
▶ 수학적 비용 산정
- COCOMO(Constructive Cost Model) : 보헴이 제안 / 원시코드 라인수 기반
| 유형 | 조직형(Organic) | 중,소규모 SW용 / 5만 라인(50KDSI) 이하 |
| 반분리형(Semi-detached) | 30만 라인 (300KDSI) 이하의 트랜잭션 처리 시스템 | |
| 내장형(Embedded) | 30만 라인 (300KDSI) 이상의 최대형 규모 SW관리 |
- PUTNAM: Rayleigh Norden 곡선의 노력 분포도를 기초로 한다.
(★SLIM: Rayleigh-Norden 곡선 / Putnam 모형 기초로 개발된 자동화 추정 도구)
- Function Point(FP): SW 기능 증대 요인에 가중치 부여 후 합산하여 기능점수 산출
(★ESTIMACS: FP모형을 기반으로 하여 개발된 자동화 추정 도구)
▶ 네트워크 차트
| PERT (Program Evaluation and Review Technique) |
- 프로젝트 작업 상호관계를 네트워크로 표현 - 원 노드(작업)과 간선(화살표)로 구성(@불확실한 내용) → 간선에는 작업별 낙관치/기대치/비관치 기재 |
| CPM (Critical Path method) |
- 미국 Dupont 회사에서 화학공장 유지/관리 위해 개발 - 노드(작업) / 간선(작업 전후 의존 관계) / 박스(이정표) 구성 - 간선(화살표)의 흐름에 따라 작업 진행(@확실한 상황) |
⭐ CPM은 임계경로 구하는 문제 단골임
▶ 간트 차트
- 각 작업의 시작 / 종료 일정을 막대 바(Bar) 도표를 이용하여 표현
- 시간선(Time-line) 차트 (수평 막대 길이 = 작업기간)
- 작업 경로는 표현 불가 / 계획 변화에 대한 적응성이 낮음
2. 요구사항 분석
| 기능적 요구사항 | 실제 시스템 수행에 필요한 기능 관련 요구사항 ex) 금융 시스템은 조회/인출/입금/송금 기능이 있어야 한다. |
| 비기능적 요구사항 | 성능, 보안, 품질, 안정성 등 실제 수행에 보조적인 요구사항 ⭐성능은 비기능적 요구사항이다. ex) 모든 화면이 3초 이내에 사용자에게 보여야 한다. |
▶ 요구사항 개발 프로세스
| ① 도출/추출 | 이해관계자들이 모여 요구사항 정의(식별하고 이해하는 과정) Ex. 인터뷰, 설문, 브레인스토밍, 청취, 프로토타이핑, 유스케이스 |
| ② 분석 | 사용자 요구사항에 타당성 조사 / 비용 및 일정에 대한 젲약 설정 Ex. 관찰, 개념 모델링, 정형 분석, 요구사항 정의 문서화 |
| ③ 명세 | 요구사항 체계적 분석 후 승인가능하도록 문서화 |
| ④ 확인/검증 | 요 구사항 명세서가 정확하고 완전하게 작성되었는지 검토 |
▶ 요구사항 분석 도구
| 요구사항 분석 CASE (Computer Aided SW Engineering) |
- SADT : SoftTech 사에서 개발 / 구조적 분석 및 설계분석 - SREM : 실시간 처리 SW 시스템에서 요구사항 명확한 기술 목적 - PSL / PSA: 문제 기술언어 및 요구사항 문석 보고서 출력 - TAGS : 시스템 공학 방법 응용에 대한 자동 접근 방법 |
| ⭐ HIPO (Hierarchy Inpupt Process Output) |
- 하향식 설계 방식 / 가시적, 총체적, 세부적 다이어그램으로 구성 기능과 자료의 의존 관계 동시 표현 / 이해쉽고 유지보수 간단 |
▶ 구조적 분석 모델
- 데이터 자료 흐름도(DFD, Data flow diagram)
- 자료 사전 (DD, Data Dictionary)
▶ 객체지향 분석 모델
- Booch(부치): 미시적, 거시적 개발 프로세스를 모두 사용 (클래스/객체 분석 및 식별)
- Jacobson(제이콥슨): Use case를 사용 (사용자, 외부 시스템이 시스템과 상호 작용)
- Coad-Yourdon: E-R다이어그램 사용 / 객체의 행위 모델링
- Wrifs-Brock: 분석과 설계 구분이 없으며 고객 명세서 평가 후 설계 작업까지 연속 수행
- Rumbaugh(럼바우): 가장 일반적으로 사용, ⭐ 객체/동기/기능 모델로 구분
▶ 럼바우
- 객체 모델링(Object) → 객체 다이어그램 / 객체들 간의 관계 규정/정의
- 동적 모델링(Dynamic) → 상태 다이어그램 / 시스템 동적인 행위 기술
- 기능 모델링(Function) → 자료 흐름도(DFD) / 다수의 프로세스들 간의 처리 과정 표현
▶ 요구사항 명세
| 정형 명세 | 수학적 원리 VDM, Z, Petri-net, CSP |
| 비정형 명세 | 자연어, 그림 중심 FSM, Decision Table, E-R모델, State Chart |
3. 소프트웨어 설계
⭐ 아키텍쳐 패턴
■ Layer
시스템을 계층으로 구분하는 고전적 방식(OSI 참조 모델)
■ Client-server
하나의 서버 컴포넌트와 다수의 클라이언트 컴포넌트로 구성
클라이언트와 서버는 요청/응답 제외 시 서로 독립적
* 컴포넌트(Component): 독립적 업무/기능 수행 위한 실행 코드 기반 모듈
■ Pipe-Filter
데이터 스트림 절차의 각 단계를 필터 컴포넌트로 캡슐화 후
데이터 전송 / 재사용 및 확장 용이 / 필터 컴포넌트 재배치 가능
단방향으로 흐르며, 필터 이동 시 오버헤드 발생
변환, 버퍼링, 동기화 적용 ( ex. UNIX 쉘 - Shell)
■ Model-View-Controller
모델(Model): 서브 시스템의 핵심 기능 및 데이터 보관
뷰(View): 사용자에게 정보 표시
컨트롤러(Controller): 사용자로부터 받은 입력 처리
→ 각 부분은 개별 컴포넌트로 분리되어 서로 영향 X
■ Master-slave
마스터에서 슬레이브 컴포넌트로 작업 분할/분리/배포 후 슬레이브에서 처리도니 결과물을 다시 돌려 받음 (병렬 컴퓨팅)
■ Broker
컴포넌트와 사용자를 연결 (분산 환경 시스템)
■ Peer-to-Peer
피어를 한 컴포넌트로 산정 후 각 피어는 클라이언트가 될 수도, 서버가 될 수도 있음 (멀티스레딩)
■ Event-bus
소스가 특정 채널에 이벤트 메시지를 발행 시 해당 채널을 구독한 리스너들이 메세지를 받아 이벤트를 처리함
■ Blackboard
컴포넌트들이 검색을 통해 블랙보드에서 원하는 데이터 전송
■ Interpreter
특정 언어로 작성된 프로그램 코드를 해석하는 컴포넌트 설계
⭐ UML (Unified Modeling Launguage)
- 구성요소 : 사물, 관계, 다이어그램- Rumbaugh, Booch, Jacobson 등 객체지향 방법론의 장점 통합* 인터페이스: 클래스/컴포넌트가 구현해야 하는 오퍼레이션 세트를 정의하는 모델 요소
▶ 사물 (Things) : 구조(개념, 물리적 요소) / 행동 /그룹 / 주해(부가적 설명, 제약조건)
▶ 관계(Relationship)
UML의 관계는 사물과 사물 사이의 연관성을 표현하는 것이다. ★2024년 3차에 나와서 안 나올 것 같지만 굳이 정리합니다.
1) 연관 관계(Association)
2개 이상의 사물이 서로 관련되어 있는 관계 이다. 사물 사이의 다중도를 표현할 수 있음.
학생은 한 학교에 다니는 관계이며 학생은 1명 이상이다.
선생은 학생을 가르치고 학생은 선생에게 가르침 받는 관계이다.
학생은 한 명 이상의 선생으로부터 가르침을 받고, 선생은 한 명이상의 학생을 가르친다.
2) 집합(Aggregation)
하나의 사물이 다른 사물에 포함되어있는 관계인 것을 나타내고 서로 독립적이다.
프린터는 컴퓨터에 연결해서 사용할 수 있으며, 다른 컴퓨터에 연결해서 사용할 수도 있다.
다른 컴퓨터에 연결이 가능하므로 독립적이라고 할 수 있다.
3) 포함(Composition)
집합과 비슷한 포함관계이지만 다른점은 서로 독립될 수 없다.
(포함하는쪽이 사라지면 포함된 쪽은 사라짐)
문을 열 수 있는 열쇠는 하나이며 해당 열쇠로는 다른 문을 열 수 없다.
그리고 문이 없어지면 열쇠도 더 이상 필요없다.
4) 일반화(Generalization)
상속관계라고 할 수 있다. 일반화라는 말 그대로 하나의 사물로 묶어서 나타내는 것이다.
사자(자식)와 코끼리(자식)는 동물(부모)이다.
5. 의존(Dependency)
서로 연관은 있으나 필요할 때만 관계가 형성되는 것을 나타낸다.
등급이 높으면 할인율을 적용하고 등급이 낮으면 할인율을 적용하지 않는다.
6. 실체화(Realization)
어떠한 관계로 사물을 그룹화 할 수 있는 것을 나타낸다.
비행기와 새는 날 수 있는 행동으로 그룹지을 수 있다.
⭐ 다이어그램 (Diagram)
| 구조, 정적 다이어그램 |
클래스(Class) | 클래스 사이의 관계 및 속성 표현 |
| 객체(Object) | 인스턴스를 객체와 객체 사이의 관계로 표현 | |
| 컴포넌트(Component) | 구현 모델인 컴포넌트 간의 관계 표현 | |
| 배치(Deployment) | 물리적 요소(HW/SW)의 윛기/구조 표현 | |
| 복합체구조 (Composite Structure) |
클래스 및 컴포넌트의 복합체 내부 구조 표현 | |
| 패키지(Package) | UML의 다양한 모델요소를 그룹화하여 묶음 | |
| 행위, 동적 다이어그램 |
유스케이스(use case) | 사용자의 요구를 분석 (사용자 관점) → 사용자(Actor) + 사용 사례(Use Case) |
| 시퀀스(Sequence) | 시스템/객체들이 주고받는 메시지 표현 → 구성 항목: 액터 / 객체 / 생명선 / 메시지 제어 삼각형 |
|
| 커뮤니케이션(Communication) | 객체들이 주고 받는 메세지와 객체 간의 연관관계까지 표현 | |
| 상태(State) | 다른 객체와의 상호작용에 따라 상태가 어떻게 변화하는지 표현 | |
| 활동(Activity) | 객체의 처리 로직 및 조건에 따른 처리의 흐름을 순서에 따라 표현 | |
| 타이밍(Timing) | 객체 상태 변화와 시간 제 약 명시적으로 표현 | |
| 상호작용 개요 (Interaction Overview) |
상호작용 다이어그램 간 제어 흐름 표현 |
▶ UI 설계
- 직관성, 유효성, 학습성, 유연성
- CLI(Command Line) : 텍스트
- GUI(Graphical) : 그래픽
- NUI(Natural): 말/행동
- VUI(Voice): 음성
- OUI(Organic): 사물과 사용자 상호작용
▶ UI 설계 도구
- Wireframe : 기획 초기 단계에 대략적인 레이아웃 설계
- StoryBoard: 최종적인 산출 문서
- Prototype: 와이어프레임 / 스토리보드에 인터랙션 적용, 실제 구현된 것처럼 테스트가 가능한 동적인 형태 모형
- Mockup: 실제 화면과 유사한 정적인 형태 모형
- Use case: 사용자 측면 요구사항 및 목표를 다이어그램으로 표현
4. 소프트웨어 구현
▶ 소프트웨어 개발 프레임워크
- Spring 프레임워크 : JAVA 플랫폼을 위한 오픈 소스 경량형 프레임워크 (동적 웹사이트 개발)
- 전자정부 프레임워크 : 우리나라 공공부문 정보화 사업시 효율적인 정보 시스템, 구축 지원을 위해 필요한 기능/아키텍쳐 제공
- 닷넷 프레임워크: MS에서 개발한 Windows 프로그램 개발, 공통언어 런타임(CLR) 이라는 가상 머신상에서 작동
▶ API (Application Programming Interface)
- 소프트웨어 간 인터페이스 (서로 다른 소프트웨어/서비스 간 상호 작용 용이)
- 운영체제 및 프로그래밍 언어의 기능을 프로그램에서 사용 가능하도록 구현
⭐ 응집도 (Cohesion)
- 개별 모듈이 독립적인 기능으로 정의되어 있는 정도
- 응집도 ▲ → 품질 ▼
- 외우는법 : 우는시절 교순가
높은 응집도부터 (아래로 갈수록 낮은 응집도)
| 기능적 (Function) | 모듈 내부의 모든 기능 요소가 단일 문제와 연관되어 수행 |
| 순차적 (Sequential) | 모듈 내 출력 데이터를 다음 활동의 입력 데이터로 사용 |
| 통신적 (Communication) = 교환적 |
동일한 입/출력을 사용하여 서로 다른 기능을 수행 |
| 절차적 (Procedural) | 모듈 내 구성 요소들이 다수 관련 기능을 순차적으로 수행 |
| 시간적 (Temporal) | 특정 시간 내 처리되는 기능을 모아 하나의 모듈로 작성 |
| 논리적 (Logical) | 유사한 성격의 처리 요소들로 하나의 모듈이 형성 |
| 우연적 (Coincidental) | 각 구성 요소들이 서로 관련없는 요소로만 구성 |
⭐ 결합도 (Coupling)
- 개별 모듈 간 상호 의존하는 정도
- 결합도 ▼ → 품질 ▲
- 외우는 법: 내 공부 내가 할게요. 제가 스트레스 받자나요
높은 결합도부터 (아래로 갈수록 낮은 결합도)
| 내용 (Content) | 한 모듈이 다른 모듈의 내부 기능 및 자료를 직접 참조/수정 |
| 공통/공유 (Common) | 공유되는 공통 데이터를 여러 모듈이 사용 (전역 변수 참조) |
| 외부 (External) | 한 모듈에서 선언한 데이터를 외부의 다른 모듈에서 참조 |
| 제어 (Control) | - 한 모듈이 다른 모듈의 상세한 처리 절차를 알고 있어 이를 통제하는 경우나 처리 기능이 두 모듈에 분리되어 설계. - 처리 대상 값 뿐만 아니라 처리 방식의 제어 요소도 전달 |
| 스탬프 (Stamp) | - 두 모듈이 동일한 자료 구조(배열, 오브젝트)를 조회 - 자료 구조 및 포맷 변화 시 조회하고 있는 모든 모듈에 영향 |
| 자료 (Data) | 모듈 간의 인터페이스가 자료 요소로만 구성 |
⭐ 객체지향 (Object-Oriented)
- 객체와 속성, 클래스와 멤버, 전체와 부분으로 나눠 분석
| 객체 (Object) |
고유 식별자 / 하나의 독립된 존재 / 일정한 기억장소 보유 상태(state) = 객체아 가질 수 있는 조건, 속성 값에 의해 정의 행위(연산, method) = 객체가 반응할 수 있는 메시지 집합 |
| 클래스 (Class) |
공통 속성과 연산(행위)을 갖는 객체들의 집합 / 데이터 추상화 단위 * 인스턴스(Instance): 클래스에 속한 각각의 객체 * Operation: 클래스의 동작 / 객체에 대해 적용될 메서드 정의 |
| 캡슐화 (Encapsulation) |
데이터와 데이터 처리 함수를 하나로 묶음 세부 내용 은폐(정보 은닉) → 외부 접근 제한 결합도 낮음 / 재사용 용이 / 인터페이스 단순 / 오류 파급 효과 낮음 |
| 상속 (Inheritance) |
상위 클래스의 속성과 연산을 하위 클래스가 물려 받는 것 * 다중 상속: 단일 클래스가 두 개 이상의 상위 클래스로부터 상속 |
| 다형성 (Polymorphism) |
하나의 메세지에 각 객체 별 고유 특성에 따라 여러 형태의 응답 |
* 오버라이딩(Overriding): 재정의 (단, 메서드 이름 / 매개변수 / 반환 타입은 동일해야 함 - 어노테이션 )
* 오버로딩(Overroading): 메서드 중복정의 (메서드 이름은 동일하나 매개변수의 개수나 타입을 다르게 지정 - 계산기)
⭐ 객체 지향 설계 5대 원칙(SOLID)
- 단일 책임 원칙 (SRP, Single Responsibility Principle) → 모든 클래스&객체는 하나의 책임만 / 완전한 캡슐화
- 개방 폐쇄의 원칙 (OCP, Open Closed Principle) → 확장에는 Open 하고, 수정에는 Close되어야 한다.
- 리스코프 교체 원칙 (LSP, Liskov Substitution Principle) → 상위 클래스의 행동 규약을 하위 클래스가 위반하면 안 된다.
- 인터페이스 분리 원칙 (ISP, Interface Segregation Principle) →클라이언트가 비사용 메서드에 의존하지 않아야 한다.
- 의존성 역전 원칙 (DIP, Dependency Inversion Principle) → 의존 관계 수립 시 변화하기 어려운 것(추상성이 높은 상위 클래스) 에 의존해야 한다.
⭐ GoF(Gang of Four) 디자인 패턴
- 서브 시스템에 속하는 컴포넌트들과 그 관계르 설계하기 위한 참조 모델
- 객체 지향 프로그래밍 설계 시 자주 발생하는 문제에 대한 반복적 해결 방법
cf) 아키텍처 패터니 전체 시스템의 구조를 설계
[생성 패턴]
| Abstract Factory | 구체적인 클래스에 의존하지 않고, 서로 연고나되거나 의존적인 객체들이 조합된 인터페이스 제공 |
| Builder | 객체 생성 단계를 캡슐화/분리하여 객체를 조립하여 생성 → 동일한 객체 생성 절차에서 서로 다른 표현 결과를 제공 |
| Factory Method | 상위 클래스에서 객체 생성 인터페이스를 정의하지만, 인스턴스를 만드는 클래스는 서브 클래스에서 결정하도록 분리 |
| Prototype | 원형/원본 객체를 복제하는 방식으로 객체를 생성 |
| Singleton | 클래스에서 하나의 객체만 생성 가능하며, 해당 객체를 어디서든 참조할 수 있지만 여러 프로세스가 동시에 참조는 불가 |
[구조 패턴]
| Adaptor | 비호환 인터페이스세 호환성 부여하도록 반환 |
| Bridge | 구현부에서 추상층을 분리 후 각자 독립적으로 변형/확장 가능 |
| Composite | 트리 구조로 부분/전체 계층 표현, 복합/단일 객체를 구분 없이 사용 |
| Decorator | 상속 사용 없이 객체 간 결합을 통해 객체 기능을 동적으로 추가/확장 |
| Facade | 상위에 인터페이스 구성하여 서브 클래스의 기능을 복잡하게 표현하지 않고 단순한 인터페이스로 구현 |
| Flyweight | 인스턴스를 공유하여 메모리 절약 (클래스 경량화) |
| Proxy | 접근이 힘든 객체를 연결하는 인터페이스 역할(대리 객체 수행) |
[행위 패턴]
| Chain of Responsibility | 처리 가능한 객체가 둘 이상 존재하여 한 객체 내 처리 불가 시 다음 객체로 이관 |
| command | 요청 명령어들을 추상/구체 클래스로 분리한 후 단순화/캡슐화 |
| Interpreter | 언어에 문법 표현 정의 |
| Iterator | 접근이 빈번한 객체에 대해 동일 인터페이스 사용 |
| Mediator | 객체들간 복잡한 상호작용을 캡슐화하여 객체로 정의 후 중재 |
| Memento | 객체를 이전의 특정 시점의 상태로 저장하고 복원 (캡슐화 유지) |
| Observer | 한 객체 상태 변화 시 상속되어 있는 객체들에 변화 전달 |
| State | 객체의 상태에 따라 동일한 동작을 다르게 처리 |
| Strategy | 동일 계열 알고리즘을 개별적으로 캡슐화하여 상호 교환 |
| Template Method | 여러 클래스에서 공통 사용 메서드를 상위 클래스에서 정의하고, 하위 클래스마다 다르게 구현해야 하는 세부 사항을 개별 구현 |
| Visitor | 각 클래스 데이터 구조로부 터 처리/연산 기능을 분리하여 별도의 클래스를 만들고, 해당 클래스 메서드가 각 클래스를 돌아다니며 특정 작업을 수행 → 객체 구조 변경 X / 새로운 연산기능만 추가 |
5. 소프트웨어 테스트
▶ 애플리케이션 테스트 기본 원리
: 테스트는 기본적으로 결함이 존재함을 밝히는 것 (무결함을 증명할 수는 없음)
→ 완벽한 테스트는 근원적으로 불가능 (무한 경로, 무한 입력 불가)
- 결함 집중 : 파레토(Pareto)의 법칙 - 20%의 모듈에서 전체 결함 80% 발생
- 살충제 패러독스 : 동일한 테스트 케이스에 의한 반복 테스트는 새로운 버그 발견 X
- 오류-부재의 궤변 : 결함이 없다 하여도 사용자의 요구사항 미충족 시 품질 저하
- Brooks의 법칙 : 지연되는 프로젝트에 인력 추가 투입 시 더 지연
▶ 애플리케이션 테스트 분류
① 프로그램 실행 여부
| 정적 테스트 | 프로그램 실행 X / 명세서, 소스 코드만 분석 ex) 동료 검토, 워크 스루, 인스펙션, 코드 검사 |
| 동적 테스트 | 프로그램 실행 후 오류 검사 ex) 화이트/블랙박스 테스트 |
② 테스트 기반 테스트
| 명세 기반 | 사용자의 요구사항에 대한 명세를 빠짐 없이 테스트 케이스로 구현하는지 확인 ex) 동등 분할 / 경계값 분석 (블랙박스) |
| 구조 기반 | SW 내부 논리 흘므에 따라 테스트 케이스 작성/확인 ex) 구문 기반 / 결정 기반 / 조건 기반 (화이트박스) |
| 경험 기반 | 테스터의 경험을 기반으로 수행 ex) 에러 추정, 체크리스트, 탐색적 테스팅 |
③ 목적 기반 테스트
| 회복 (Recovery) | 시스템에 인위적 결함 부여 후 정상으로 회복되는 과정 확인 |
| 안전 (Security) | 외부 불법 침입으로부터 시스템을 보호할 수 있는지 확인 |
| 강도 (Stress) | 과부하 시 SW 정상 구동 여부 확인 |
| 성능 (Performance) | 실시간 성능 및 전체적인 효율성 진단 (응답시간, 업무 처리량) |
| 구조 (Structure) | SW 내부 논리적 경로 및 소스 코드 복잡도 평가 |
| 회귀 (Regression) | SW 내 변경 또는 수정된 코드에 새로운 결함이 없음을 확인 |
| 병행 (Parallel) | 변경 및 기존 SW에 동일한 데이터 입력 후 결과 비교 |
④ 시각(관점) 기반 테스트
| 검증 (Verification) |
개발자의 시각에서 제품의 생산 과정 테스트 ex) 단위/통합/시스템 테스트 |
| 확인 (Validation) |
사용자의 시각에서 생산된 제품의 결과 테스트 ex) 인수 테스트 (알파/베타) |
⭐ 화이트박스 테스트 (White Box Test)
- 모듈 안의 내용(작동) 직접 볼 수 있으며, 내부의 논리적인 모든 경로를 테스트
- 소스 코드의 모든 문장을 한 번 이상 수행 / 논리적 경로 점검 (선택, 반복 수행)
- 테스트 데이터 선택하기 위해 검증 기준 커버리지(Coverage) 정합
[화이트 박스 테스트 검증 기준]
| 구문 커버리지 (Statement Coverage) |
프로그램 내 모든 명령문을 적어도 한 번 수행 |
| 결정(분기) 커버리지 (Branch Coverage) |
프로그램 내 전체 결정문이 적어도 한 번은 참/거짓 결과 수행 |
| 조건 커버리지 (Condition Coverage) |
결정 명령문 내의 각 개별 조건식이 적어도 한 번은 참/거짓 결과 수행 |
| 조건/결정 커버리지 (Condition / Branch) |
전체 조건식 뿐만 아니라 개별 조건식도 참 한 번 이상, 거짓 한 번 이상 결과 수행 |
[화이트박스 테스트 종류]
| 기초 경로 검사 (Base Path Testing) |
대표적 화이트박스 테스트 기법 (동적 테스트) 테스트 케이스 설계자가 절차적 설꼐의 논리적 복잡성을 측정할 수 있게 해주는 테스트 기법 측정 결과는 실행 경로의 기초를 정의하는 지침으로 사용 |
| 제어 구조 검사 (Control Structure Testing) |
조건 검사 : 프로그램 모듈 내 논리적 조건 테스트 루프 검사 : 프로그램 반복(Loop) 구조 테스트 자료 흐름 검사 : 변수의 정의와 변수 사용의 위치 테스트 |
⭐ 블랙박스 테스트 (Black Box Test)
- 모듈 내부의 내용 알 수 없음
- 소프트웨어 인터페이스에서 실시되는 테스트
- SW 각 기능이 완전히 작동되는 것을 입증하는 테스트로 '기능 테스트'라고 함
[블랙박스 테스트 종류]
| 동치 분할 검사 (Equivalence Partition) |
프로그램 입력 조건에 타당한 입력 자료와 타당하지 안은 입력 자료의 개수를 균등하게 진행 |
| 경계값 분석 (Boundary Value) |
입력 조건의 경계값을 테스트 케이스로 선정 ex) 범위 구간 양 끝 : ~이상 / 이하 / 초과 / 미만 |
| 원인-효과 그래프 검사 (Cause-Effect Graphing) |
입력 데이터 간의 관계와 출력에 영향을 미치는 상황을 체계적으로 분석 후 효용성이 높은 테스트 케이스 선정 |
| 오류 예측 검사 (Error Guessing) |
과거의 경험이나 확인자의 감각으로 테스트 진행 |
| 비교 검사 (Comparison) |
여러 버전의 프로그램에 동일한 결과가 출력되는지 확인 |
▶ 요구사항 검증 (Requirements Validation)
- 동료 검토 (Peer Review) : 작성자가 내용 설명 후 동료들이 결함 검토
- 워크 스루 (Walk Through) : 요구사항 명세서 미리 배포 후 짧은 검토 회의 진행
- 인스펙션 (Inspection) : 작성자 제외한 다른 전문가들이 결함 검토
▶ 소프트웨어 생명 주기 (V-모델)
▶ 개발단계에 따른 애플리케이션 테스트
① 단위테스트 (Unit Test)
- 최소 단위(모듈/컴포넌트) 기반 테스트, 즈로 구조 기반 테스트 진행 / 기능성 테스트 최우선
- 소프트웨어를 이루는 기본 단위(독립적 기능 ) 테스트
② 통합 테스트 (Integration test)
- 인터페이스 간 시스템이 정상 실행되는 지 확인
- 단위 테스트 후 모듈을 통합하는 과정에서 발생하는 오류 및 결함을 찾는 테스트 기법
| 하향식 (Top-down) |
- 상위 모듈에서 하위 모듈 방향으로 통합 - 깊이 우선(Depth first) 통합법 / 넓이 우선 (Breadth first) 통합법 - 초기부터 사용자에게 시스템 구조 보여줌 - 스텁(Stub) : 모듈의 기능을 단순히 수행하는 도구 (시험용 모듈) |
| 상향식 (Bottom-up) |
- 하위 모듈에서 상위 모듈 방향으로 통합 - 하나의 주요 제어 모듈과 관련된 종속 모듈의 그룹인 클러스터(Cluster) 와 드라이버(Driver) 사용 / 스텁(Stub) 미사용 |
③ 시스템 테스트 (System test)
- 개발된 SW의 컴퓨터 시스템 내 작용 여부 점검
- 실제 사용 환경과 유사한 테스트 환경 → 기능적(블랙박스) 및 비기능적(화이트박스) 테스트 구분
④ 인수 테스트 (Acceptance test)
- 사용자의 요구 사항 충족 여부 확인
- 알파 테스트 : 통제된 환경에서 사용자가 개발자와 함께 확인
- 베타 테스트 : 통제되지 않은 환경에서 개발자 없이 여러 명의 사용자가 검증
■ 테스트 관련 기타 용어
| 테스트 시나리오 (Test Scenario) |
테스트 케이스 적용/동작 순서에 따라 여러 테스트 케이스를 묶은 집합 |
| 테스트 오라클 (Test Oracle) |
테스트 결과의 참/거짓 판단 위해 사전에 정의된 참 값을 대입 |
- 참 오라클 (True) : 모든 테스트 케이스의 입력값에 기대 결과 제공
- 샘플링 오라클 (Sampling) : 특정 테스트 케이스 입력값에 기대 결과 제공
- 오라클 (Heuristci) : 특정 테스트 케이스 입력값에 기대 결과 제공 + 나머지 입력값에 대해선 추정 결과 제공
- 일관성 오라클 (Consistent) : 테스트 케이스의 수행 전/후의 결과값 동일 여부 확인
■ 테스트 관련 기타 용어
| 테스트 드라이버 (Test Driver) |
시험 대상의 하위 모듈 호출 / 모듈 테스트 수행 후의 결과 도출 → 상향식 통합 테스트에서 사용 |
| 테스트 스텁 (Test Stub) |
제어 모듈이 호출하는 하위 모듈의 역할 단순 수행 → 하향식 테스트에 사용 |
| 테스트 슈트 (Test Suites) |
시스템에 사용되는 테스트 케이스의 집합 (컴포넌트 / 모듈) |
| 테스트 케이스 (Test Case) |
사용자의 요구사항 준수 여부 확인 위해 설계된 테스트 항목 명세서 (입력값, 실행 조건, 기대 결과 등) |
| 테스트 스크립트 (Test Script) |
자동화된 테스트 실행 절차에 대한 명세서 |
| 목 오브젝트 (Mock Object) |
사용자의 행위 조건부 입력 시 계획된 행위를 수행하는 객체 |
6. 소프트웨어 유지 보수
▶ 소스 코드 품질 분석 도구
| 정적 분석 도구 (Static Analysis) |
프로그램 실행 없이 코딩 표준/스타일/결함 등을 분석 → PMD, Checkstyle, SonarQube, Cppcheck, Ccm, Cobertura |
| 동적 분석 도구 (Dynamic Analysis) |
프로그램 실행하여 코드 내 메모리 누수 및 스레드 결함 발견 → Avalanche, Valgrind, Valance |
▶ 소프트웨어 형상 관리 (SCM: Software Configuration Management)
- 개발 과정에서 SW 변경 사항을 관리하기 위한 일련의 활동 / 개발 전체 단계 적용
- 중요성 : 변경사항 추적 / 통제, 무절제한 변경 방지, 개발진행 이력 확인
- 형상 관리 역할 : 배포본 고나리 용이 / 불필요한 소스 수정 제한 / 여러 개발자 동시 개발
▶ 소프트웨어 버전 관리 도구
| 공유 폴더 | 클라이언트/서버 | 분산저장소 |
| 공유 폴더에 복사 | 서버에서 버전 일괄 관리 | 원격 → 지역 저장소 |
| RCS, SCCS, PVCS, QVCS | CVS, SVN, CVSNT, CMBC | Git, GNU arch, DCVS, Bitkeeper, Bazaar |
▶ 형상 관리 도구
| CVS | 서버/클라이언트 구성, 다수의 인원이 동시 버전 관리 가능 |
| SVN (Subversion) |
CVS 개선 툴 / 모든 개발은 trunk 디렉터리에서 수행 Commit 수행 시 revision 1씩 증가 |
| Git | 서버(원격( 저장소와 개발자(지역) 저장소가 독립적 → Commit 실수 발생해도 서버에 영향 없음 (분산된 P2P모델) |
▶ SPICE(ISO 15504) vs CMMI(Capability Maturity Model Integration)
'정보처리기사' 카테고리의 다른 글
| [정보처리기사] 데이터베이스 정리 (2) (1) | 2025.04.03 |
|---|---|
| [정보처리기사] 데이터베이스 정리 (1) (1) | 2025.04.03 |
| [정보처리기사] 정보 보안 관련 IT 용어 총정리 (9) | 2025.03.29 |
| [정보처리기사] 페이지 교체 알고리즘 (FIFO, LRU, LFU) (3) | 2025.03.29 |
| [정보처리기사] 트리순회 전위, 중위, 후위 표현식 & 정렬 알고리즘 정리 (7) | 2025.03.26 |
