1. 소프트웨어 개발 방법론
| 중분류 | 소분류 | 키워드 |
| 소프트웨어 생명 주기 모델 (SDLC, Software Development Life Cycle) |
SDLC 종류 | - 폭포수 모델 (Waterfall Model) - 프로토타이핑 모델 (Prototyping Model) - 나선형 모델 (Spiral Model) - 반복적 모델 (Iteration Model) |
| SDLC 프로세스 | - 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수 | |
| 소프트웨어 개발 방법론 | SW 개발 방법론 종류 | - 구조적 방법론 - 정보 공학 방법론 - 객체 지향 방법론 - 컴포넌트 기반 방법론 - 애자일 방법론 - 제품 계열 방법론 |
| 애자일 방법론 (Agile Development) |
애자일 방법론의 개념 | - 절차보다는 사람 중심 - 개발 기간이 짧고 신속 - 개발과 함께 즉시 피드백 |
| 애자일 방법론의 유형 | - XP - SCRUM - LEAN |
|
| XP의 5가지 가치 (용단의 피존) |
- 용기 - 단순성 - 의사소통 - 피드백 - 존중 |
|
| XP의 12가지 기본 원리 | - 짝 프로그래밍짝 프로그래밍(Pair Programming) - 공동 코드 소유(Collective Ownership) - 지속적인 통합(CI; Continous Integration) - 계획 세우기(Planning Process) - 작은 릴리즈(Small Release) - 메타포어(Metaphor) - 간단한 디자인(Simple Design) - 테스트 기반 개발(TDD; Test Driven Develop) - 리팩토링(Refactoring) - 40시간 작업(40-Hour Work) - 고객 상주(On Stie Customer) - 코드 표준(Coding Standard) |
|
| 스크럼 구성 요소 | - 백로그 - 스프린트 - 스크럼 미팅 - 스크럼 마스터 - 스프린트 회고 - 번 다운 차트 |
|
| 객체 지향 분석 방법론 | 객체 지향 분석 방법론 종류 | - OOSE (Object Oriented Software Engineering) - 야콥슨 - OMT (Object Modeling Technology) - 럼바우 - OOD (Object Oriented Design) - 부치 |
| 럼바우 객체 지향 분석 기법 (객동기) |
- 객체 모델링 : 객체 다이어그램 - 동적 모델링 : 상태 다이어그램 - 기능 모델링 : 자료 흐름도 |
|
| 객체 지향 구성 요소 | - 클래스 - 객체 - 메소드 - 메시지 - 인스턴스 - 속성 |
|
| 객체 지향 기법 | - 캡슐화 (Encapulation) - 상속성 (Inheritance) - 다형성 (Polymorphism) - 추상화 (Abstraction) - 정보 은닉 (Information Hiding) - 관계성 (Relationship) |
|
| 객체 지향 설계 원칙 (SOLID) |
- 단일 책임 원칙 (SRP) - 개방 폐쇄 원칙 (OCP) - 리스코프 치환의 원칙 (LSP) - 인터페이스 분리의 원칙 (ISP) - 의존성 역전의 원칙 (DIP) |
|
| 비용 산정 기법 | 하향식 산정 기법 | - 델파이 기법 |
| 상향식 산정 기법 | - LOC - Man Month - COCOMO 모형 - 푸트남 (Putnam) 모형 - 기능점수(FP) 모형 |
|
| 일정 관리 기법 | 일정 관리 모델 | - 주 공정법(CPM; Critical Path Method) - PERT (Program Evaluation and Review Technique) - 중요 연쇄 프로젝트 관리 (CCPM; Critical Chain Project Management) |
1.1 소프트웨어 생명 주기 모델
🤔 소프트웨어 생명주기(SDLC, Software Development Life Cycle)란?
시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차로,
개발될 때부터 운용과 유지보수를 걸쳐 생애를 마칠 때까지 어떠한 순서를 밟는지에 대한 작업 과정을 모델화한 것이다.
(1) SDLC 종류
| 종류 | 설명 |
| 폭포수 모델 (Waterfall Model) |
- 고전적 생명 주기 모형 - 개발 시 단계를 확실히 마무리 지은 후 다음 단계로 넘어가는 모델 - 요구사항 변경이 어려움 |
| 프로토타이핑 모델 (Prototyping Model) |
- 고객이 요구한 주요 기능을 프로토타입으로 구현 |
| 나선형 모델 (Spiral Model) |
- 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발 |
| 반복적 모델 (Iteration Model) |
- 구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발 |
(2) SDLC 프로세스
: 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수
1.2 소프트웨어 개발 방법론
🤔 소프트웨어 개발 방법론이란?
소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론
(1) 소프트웨어 개발 방법론 종류
| 종류 | 설명 |
| 구조적 방법론 (Structured Development) |
- 시스템을 기능 단위로 분할(divide)하고, 정복 방식(conquer)으로 각 기능을 개발 후 통합한 방법론 - 나씨 - 슈나이더만 차트 사용 : 논리의 기술에 중점을 둔 도형식 표현 방법 |
| 정보공학 방법론 (Information Engineering Development) |
- 정보 시스템 개발을 위해 관리 절차와 작업 기반을 체계화한 방법론 |
| 객체 지향 방법론 (Object-Oriented Development) |
- 객체를 기반으로 시스템을 분석하고 설계하는 방법론 |
| 컴포넌트 기반 방법론 (CBD; Component Based Development) |
- 재사용 가능한 컴포넌트를 조립하여 새로운 응용프로그램을 구성하는 방법론 |
| 애자일 방법론 (Agile Development) |
- 절차보다 사람 중심, 변화에 유연하고 신속하게 대응하여 시스템을 개발하는 방법론 |
| 제품 계열 방법론 (Product Line Development) |
- 공통기능을 정의하여 여러 제품군에서 재사용 가능하도록 설계하는 방법론 |
1.3 애자일 방법론
(1) 애자일 방법론의 개념
- 절차보다는 사람 중심이며, 개발 기간이 짧고 신속하다.
- 폭포수 모형에 대비되는 방법론으로 개발과 함께 즉시 피드백을 한다.
(2) 애자일 방법론의 유형
| 구분 | 설명 |
| XP (eXtreme Programming) |
- 정의 : 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이는 방법론 - XP의 5가지 가치 (용단의 피존) - XP의 12가지 기본원리 |
| SCRUM | - 정의 : 매일 정해진 시간, 장소에서 짧은 시간의 개발 하는 팀을 위한 프로젝트 관리 중심 방법론 |
| LEAN | - 정의 : 도요타의 린 시스템 품질 기법을 소프트웨어 개발 프로세스에 적용하여 낭비 요소를 제거하여 품질을 향상시킨 방법론 |
(3) XP의 5가지 가치
| 종류 (용단의 피존) | 설명 |
| 용기 (Courage) |
- 고객의 요구사항 변화에 능동적으로 대처 |
| 단순성 (Simplicity) |
- 불필요한 기능 구현을 배제 |
| 의사소통 (Communication) |
- 개발자와 고객 간 활발한 의사소통 |
| 피드백 (Feedback) |
- 빠른 피드백 원칙 |
| 존중 (Respect) |
- 팀원 간 상호 존중 |
(4) XP의 12가지 기본 원리
| 구분 | 종류 | 설명 |
| 개발 | 짝 프로그래밍 (Pair Programming) |
- 두명의 개발자가 짝으로 코딩하는 원리 |
| 공동 코드 소유 (Collective Ownership) |
- 코드는 누구든지 수정 가능하다는 원리 | |
| 지속적인 통합 (CI; Continous Integration) |
- 지속적으로 CI/CD를 해야 한다는 원리 | |
| 관리 | 계획 세우기 (Planning Process) |
- 고객이 요구하는 비즈니스 가치를 정의하고 |
| 작은 릴리즈 (Small Release) |
- 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리 | |
| 메타포어 (Metaphor) |
- 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리 | |
| 구현 | 간단한 디자인 (Simple Design) |
- 요구사항에 맞는 가능한 단순한 시스템을 설계해야 한다는 원리 |
| 테스트 기반 개발 (TDD; Test Driven Develop) |
- 프로그램에 대한 테스트 코드를 먼저 작성한 후 프로그램 코드를 작성해야 한다는 원리 | |
| 리팩토링 (Refactoring) |
- 프로그램의 기능을 바꾸지 않으면서 중복 제거, 단순화 등을 위해 시스템을 재구성해야 한다는 원리 | |
| 환경 | 40시간 작업 (40-Hour Work) |
- 일주일에 40시간 이상 일하지 말아야 한다는 원리 |
| 고객 상주 (On Stie Customer) |
- 개발자의 질문에 대답할 수 있는 고객을 항상 상주시켜야 한다는 원리 | |
| 기타 | 코드 표준 (Coding Standard) |
- 효과적인 공동 작업을 위해 모든 코드에 대해 코딩 표준을 정의해야 한다는 원리 |
(5) 스크럼의 구성요소
| 종류 | 설명 |
| 스프린트 (Sprint) |
- 스크럼에서 사용되는 일정 기간 - 주로 2 ~ 4주에 짧은 개발 기간으로 반복적으로 수행 |
| 스프린트 백로그 (Sprint Backlog) |
- 스프린트에서 완료해야 할 작업을 우선순위에 따라 정리한 목록 |
| 제품 백로그 (Product Backlog) |
- 제품의 요구사항을 우선순위에 따라 정리한 목록 |
| 스크럼 이벤트 (Scrum events) |
- 스크럼 프로세스에서 일어나는 이벤트 - 스프린트 계획 회의, 데일리 스크럼 회의, 스프린트 리뷰 미팅, 스프린트 회고 미팅 등 |
| 스프린트 계획 회의 (Sprint Planning Meeting) |
- 스프린트 진행 전, 해당 스프린트에서 완료해야 할 작업을 선정하는 회의 |
| 데일리 스크럼 회의 (Daily Scrum Meeting) |
- 매일 진행되는 짧은 회의 - 진행 상황과 문제를 공유 |
| 스프린트 리뷰 미팅 (Sprint Review Meeting) |
- 해당 스프린트에서 개발한 제품의 작동 여부를 검증하는 회의 |
| 스프린트 회고 미팅 (Sprint Retrospective Meeting) |
- 해당 스프린트에서 진행한 프로세스와 문제점을 검토하고 개선점을 도출하는 회의 |
1.4 객체 지향 분석 방법론
(1) 객체 지향 분석 방법론 종류
| 종류 | 설명 |
| OOSE (Object Oriented Software Engineering) |
- 유스케이스에 의한 접근 방법 - 분석, 설계, 구현 단계로 구성 - 기능적 요구사항 중심의 시스템 |
| OMT (Object Modeling Technology) |
- 그래픽 표기법 - 럼바우 객체 모델링 : 객체 모델링, 동적 모델링, 기능 모델링 |
| OOD (Object Oriented Design) |
- 객체 지향 설계 |
(2) 럼바우 객체지향 분석 기법 (OMT)
| 종류 (객동기) | 설명 |
| 객체 모델링 (Object, Information Modeling) |
- 객체 다이어그램 - 시스템에서 요구하는 객체를 찾고 객체들 간의 관계를 정의, 가장 중요하며 선행되어야 함 |
| 동적 모델링 (Dynamic Modeling) |
- 상태 다이어그램 - 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현 |
| 기능 모델링 (Functional Modeling) |
- 자료 흐름도 (DFD) - 프로세스들의 자료 흐름을 중심으로 처리 과정 표현 |
(3) 객체 지향 구성요소
| 구성요소 | 설명 |
| 클래스 (Class) |
- 특정 객체 내에 있는 변수와 메소드를 정의하는 일종의 틀 - 객체 지향 프로그래밍에서 데이터를 추상화하는 단위 - 하나 이상의 유사한 객체들을 묶어서 하나의 공통된 특성을 표현 |
| 객체 (Object) |
- 물리적, 추상적으로 자신과 다른 것을 식별 가능한 대상 - 클래스에서 정의한 것을 토대로 메리로에 할당 - 객체마다 각각의 상태와 식별성을 가짐 |
| 메서드 (Method) |
- 클래스로부터 생성되 객체를 사용하는 방법 - 객체가 메시지를 받아 실행해야할 객체의 구체적인 연산 |
| 메시지 (Message) |
- 객체간 상호 작용을 하기 위한 수단 - 객체에서 어떤 행위를 하도록 지시하는 방법 - 메시지는 객체에서 객체로 전달 |
| 인스턴스 (Instance) |
- 객체 지향 기법에서 클래스를 통해 만든 실제의 실형 객체 - 클래스에 속한 각각의 객체 - 실제로 메모리상에 할당 |
| 속성 (Property) |
- 한 클래스 내에 속한 객체들이 가지고 있는 데이터 값들을 단위별로 정의 - 성질, 분류, 식별, 수량, 현재 상태 등에 대한 표현 값 |
(4) 객체지향 기법
| 기법 | 설명 |
| 캡슐화 (Encapulation) |
- 서로 연관된 데이터와 함수를 함께 묶어 외부와 경계를 만들고 필요한 인터페이스를 밖으로 드러내는 기법 - 결합도가 낮아지고 재사용에 용이하다 - 인터페이스 단순화 |
| 상속성 (Inheritance) |
- 상위클래스의 속성과 메소드를 하위 클래스에서 재정의 없이 물려받아 사용하는 기법 |
| 다형성 (Polymorphism) |
- 하나의 메시지에 대해 각 객체가 가지고 있는 고유한 방법으로 응답할 수 있는 능력 - 상속받은 여러 개의 하위 객체들이 다른 형태의 특성을 갖는 객체로 이용될 수 있다 오버로딩 (Overloading) : 매개변수 유형과 개수를 다르게 하여 같은 이름의 메소드를 여러개 갖는 기법 오버라이딩 (Overriding) : 상위 클래스에서 정의한 메소드를 하위클래스에서 재정의하는 기법 |
| 추상화 (Abstraction) |
- 공통 성질을 추출하여 추상 클래스를 설정 - 과정 추상화, 자료 추상화, 제어 추상화 |
| 정보 은닉 (Information Hiding) |
- 코드 내부 데이터와 메소드를 숨기고 인터페이스를 통해서만 접근하도록 하는 코드 보안 기술 - 모듈 사이의 독립성을 유지하는데 도움이 된다 |
| 관계성 (Relationship) |
- 두 개 이상의 엔티티에서 데이터를 참조하는 관계를 나타내는 기법 연관화 (is member of ) : 클래스와 객체의 참조 및 이용 관계 집단화 (is part of, part-whole) : 서로 관련 있는 여러 객체를 묶어 한 개의 상위 객체를 만듦 분류화 (is instacne of) : 공통된 속성에 의해 정의된 객체 구성원들의 인스턴스 일반화 (is a) : 클래스들 간의 개념적인 포함 관계 (상위 클래스 특성을 하위클래스가 받음) 특수화 (is a) : 상위 클래스의 특성을 상속 받으며 하위 클래스가 이를 수정하여 고유한 특성을 갖는 관계 |
(5) 객체 지향 설계 원칙
| 구분 | 설명 | |
| 단일 책임의 원칙 | SRP, Single Responsibility Principle | - 모든 클래스는 하나의 책임만 가져야 한다 |
| 개방-폐쇄의 원칙 | OCP, Open Closed Priciple | - 확장에 개방, 수정에는 폐쇄적이어야 한다 |
| 리스코프치환 원칙 | LSP, Liskov Substitution Principle | - 부모 클래스를 자식 클래스로 대체 가능해야 한다 |
| 인터페이스 분리 원칙 | ISP, Interface Segregation Principle | - 클라이언트는 사용하지 인터페이스에 영향을 받으면 안된다 |
| 의존 역전 원칙 | DIP, Dependency Inversion Principle | - 변하기 어렵고 변화 빈도가 낮은 것에 의존한다 |
1.5 비용 산정 기법
(1) 하향식 산정 기법
| 종류 | 설명 |
| 델파이 기법 | - 전문가의 경험적 지식을 통한 문제 해결 및 미래 예측을 위한 기법 |
(2) 상향식 산정 기법
| 종류 | 설명 |
| LOC (Lines of Code) |
- 정의 : 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구해서 비용 산정 예측치 = (낙관치 + 4*기대치 + 비관치) / 6 노력(월) = 예측치 / (개발자 1인당 월 생산성) 개발 기간(월) = 노력 / 투입 인원 비용 = 노력 * 인건비 단가 생산성 = LOC / 노력 |
| Man Month | - 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 비용산정 |
| COCOMO 모형 | - 프로그램의 규모에 따라 비용산정 조직형 (Organic Mode) : 5만(50KDSI)라인 이하 반 분리형 (Semi-Detached Mode) : 30만(300KDSI)라인 이하 임베디드형 (Embedded Mode) : 30만(300KDSI)라인 이상 |
| 푸트남 (Putnam) 모형 | - 개발 주기의 단계별로 요구할 인력의 분포를 가정하는 방식 |
| 기능 점수(FP) 모형 | - 소프트웨어 기능을 증대시키는 요인별로 가중치를 부여하여 비용산정 기능점수(FP) = 총 기능점수 [0.65 + (0.1 총 영향도)] |
1.6 일정 관리 기법
(1) 일정 관리 모델
🤔 일정 관리 모델이란?
프로젝트가 일정 기간 내에 완료될 수 있도록 관리하는 모델
| 종류 | 설명 |
| 주 공정법 (CPM; Critical Path Method) |
- 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법 - 노드와 노드간 연결 - 주 공정 (Critical Path, 임계 경로) : 프로젝트 시작에서 종료까지 가장 긴 시간이 걸리는 경로 |
| PERT (Program Evaluation and Review Technique) |
- 일의 순서를 계획적으로 정리하기 위한 비관치, 중간치, 낙관치의 3점 추첨 방식 |
| 중요 연쇄 프로젝트 관리 (CCPM; Critical Chain Project Management) |
- 주 공정 연쇄법으로 자원 제약사항을 고려하여 일정을 작성하는 기법 |
2. 현행 시스템 분석
| 중분류 | 소분류 | 키워드 |
| 현행 시스템 파악 | 분석 대상 | - 소프트웨어, 하드웨어, 네트워크 구성 파악 |
| 파악 절차 | - 구성/기능/인터페이스 파악 - 아키텍처 및 소프트웨어 구성 파악 - 하드웨어 및 네트워크 구성 파악 |
|
| 소프트웨어 아키텍처 | SW 아키텍처 4 + 1 뷰 | - 유즈케이스 뷰 - 논리 뷰 - 프로세스 뷰 - 구현 뷰 - 배포 뷰 |
| SW 아키텍처 패턴 유형 | - 계층화 패턴 (Layered Pattern) - 클라이언트-서버 패턴 (Client-Server Pattern) - 파이프 - 필터 패턴 (Pipe-Filter Pattern) - 브로커 패턴 (Broker Pattern) - 모델 - 뷰 컨트롤러 패턴 (MVC; Model-View-Controller Pattern) |
|
| SW 아키텍처 비용 평가 모델 종류 | - SAAM - ATAM - CBAM - ADR - ARID |
|
| 디자인 패턴 | 디자인 패턴 유형 (생구행) |
- 생성 패턴 - 구조 패턴 - 행위 패턴 |
| 생성 패턴 (추빌팩프싱) |
- 추상팩토리 (Abstract Factory) - 빌더 (Builder) - 팩토리 메서드 (Factory Method) - 프로토타입 (Prototype) - 싱글톤 (Singleton) |
|
| 구조 패턴 (어브컴데 퍼플프) |
- 어댑터 (Adaptor) - 브리지 (Bridge) - 컴포지트 (Composite) - 데코레이터 (Decorator) - 퍼사드 (Facade) - 플라이웨이트 (Flyweight) - 프록시 (Proxy) |
|
| 행위 패턴 | - Mediator - Interpreter - Iterator - Template Method - Observer - State - Visitor - Command -Startegy - Memento - Chain of Responsibility |
|
| 미들웨어 | 종류 | - WAS(Web Application Server) |
2.1 현행 시스템 파악
🤔현행 시스템 파악이란?
현행 시스템의 어떤 기술 요소를 사용하는 파악하는 활동
(1) 분석 대상
: 소프트웨어, 하드웨어, 네트워크 구성 파악
(2) 파악 절차
1. 구성/기능/인터페이스 파악
2. 아키텍처 및 소프트웨어 구성 파악
3. 하드웨어 및 네트워크 구성 파악
2.2 소프트웨어 아키텍처
🤔 소프트웨어 아키텍처(Software Architecture)란?
여러가지 소프트웨어 구성 요소와 그 구성 요소가 가진 특성 중에서 외부에 드러나는 특성으로,
구성 요소 간의 관계를 표현하는 시스템의 구조나 구조체
(1) 소프트웨어 아키텍처 4+1 뷰
🤔 4+1 뷰 란?
고객의 요구사항에 정리해놓은 시나리오를 4개의 관점으로 바라본 것
| 분류 | 설명 | |
| 4 | 논리 뷰 | - 시스템의 기능적인 요구사항이 어떻게 제공되는지 설명해주는 뷰 |
| 프로세스 뷰 | - 시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰 | |
| 구현 뷰 | - 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰 - 컴포넌트 구조와 의존성을 보여주고 부가적인 정보 정의 |
|
| 배포 뷰 | - 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 매핑해서 보여주는 뷰 | |
| 1 | 유스케이스 뷰 | - 유스케이스 또는 아키텍처를 도출하고 설계하며 다른 뷰를 검증하는데 사용되는 뷰 |
(2) 소프트웨어 아키텍처 패턴 유형
| 종류 | 설명 |
| 계층화 패턴 (Layered Pattern) |
- 시스템을 계층으로 구분하여 구성하는 패턴 |
| 클라이언트-서버 패턴 (Client-Server Pattern) |
- 하나의 서버와 다수의 클라이언트로 구성된 패턴 |
| 파이프 - 필터 패턴 (Pipe-Filter Pattern) |
- 데이터 스트림을 생성하고 처리하는 시스템에서 사용 가능한 패턴 - 재사용성이 좋고 추가가 쉬워 확장에 용이함 |
| 브로커 패턴 (Broker Pattern) |
- 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용 - 각 컴포넌트들로 원격 서비스 실행을 통해 상호작용이 가능 |
| 모델 - 뷰 컨트롤러 패턴 (MVC; Model-View-Controller Pattern) |
- 대형 어플리케이션을 3개의 시스템으로 구조화한 패턴 - 컴포넌트들로 분리되어있어 서로 영향을 받지 않고 개발 작업 수행 가능 모델 (Model) : 핵심 기능과 데이터 보관 뷰 (View) : 사용자에게 정보 표시 컨트롤러 (Controller) : 사용자로부터 요청을 입력받아 처리 |
(3) 소프트웨어 아키텍처 비용 평가 모델 종류
| 종류 | 설명 |
| SAAM | - 변경 용이성과 기능성에 집중, 경험이 없는 조직에서도 활용 가능한 비용 평가 모델 |
| ATAM | - 아키텍처 품질 속성을 만족시키는지 판단 및 품질 속성들의 이해 상충관계까지 평가하는 모델 |
| CBAM | - ATAM 바탕의 시스템으로 경제적 의사결정에 대한 요구를 충족하는 비용 평가 모델 |
| ADR | - 소프트웨어 아키텍처 구성요소 간 응집도 평가 모델 |
| ARID | - 전체 아키텍처가 아닌 특정 부분에 대한 품질 요소에 집중하여 비용 평가 모델 |
2.3 디자인 패턴
🤔 디자인 패턴이란?
소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
(1) 디자인 패턴 유형
| 구분 | 설명 |
| 생성 패턴 | - 객체 인스턴스 생성에 관여하고, 클래스 정의와 객체 생성 방식을 구조화, 캡슐화를 수행하는 패턴 |
| 구조 패턴 | - 클래스나 객체의 조합을 다루는 패턴 |
| 행위 패턴 | - 클래스나 객체들이 상호작용하는 방법과 역할 분담을 다루는 패턴 |
(2) 생성 패턴
| 종류 (추빌 팩프싱) | 설명 |
| 추상팩토리 (Abstract Factory) |
- 관련있는 객체들을 그룹으로 생성하여 추상적으로 표현 - 연관성이 있는 객체 군이 여러개 있을 경우 이들을 묶어 추상화하고, 어떤 구체적인 상황이 주어지면 팩토리 객체에서 집합으로 묶은 객체 군을 구현화하는 생성 패턴 |
| 빌더 (Builder) |
- 객체의 생성 과정과 표현 방법을 분리하여 다양한 객체를 생성할 수 있다 |
| 팩토리 메소드 (Factory Method) |
- 객체 생성 책임을 하위 클래스에게 위임하여, 어떤 클래스의 인스턴스를 생성할지 서브클레스가 결정하도록 하는 것 |
| 프로토타입 (Prototype) |
- 원본 객체(프로토타입)을 복제하여 새로운 객체로 생성하는 것 |
| 싱글톤 (Singleton) |
- 하나의 인스턴스만 생성되고, 하나의 객체를 여러 프로세스가 동시에 참조할 수 없다 |
(3) 구조 패턴
| 종류 (어브컴데 퍼플프) | 설명 |
| 어댑터 (Adaptor) |
- 불일치하는 인터페이스끼리 호환되도록 연결해주는 중간자 역할을 수행 |
| 브리지 (Bridge) |
- 추상화와 구현을 분리하여 독립적으로 변화 가능하도록 구조를 분리 |
| 컴포지트 (Composite) |
- 여러 객체를 가진 복합, 단일 객체를 구분 없이 다룰 때 사용 |
| 데코레이터 (Decorator) |
- 객체에 기능을 동적으로 확장해주는 패턴 |
| 퍼싸드 (Facade) |
- 서브 클래스들의 기능을 간편하게 사용할 수 있도록하는 패턴 |
| 플라이웨이트 (Flyweight) |
- 공유가능한 상태를 객체 간에 공유하여 메모리를 절약하는 구조 |
| 프록시 (Proxy) |
- 객체에 대한 접근을 제어하거나 대리 역할을 수행하는 대리인 객체를 제공 |
(4) 행위 패턴
| 종류 | 설명 |
| 책임 연쇄 (Chain of Responsibility) |
- 요청을 여러 핸들러에 순차적으로 전달하며, 적절한 핸들러가 처리하도록 한다 |
| 커맨드 (Command) |
- 요청에 각종 명령어들을 추상, 구체 클래스로 분리하여 단순화함 |
| 인터프리터 (Interpreter) |
- 언어의 문법 표현을 정의하는 패턴 |
| 반복자 (Iterator) |
- 동일한 인터페이스를 사용하도록하는 패턴 - 반복 프로세스를 캡슐화하여 클라이언트 코드에서는 컬렉션의 구체적인 구현에 종속되지 않도록 한다 |
| 중재자 (Mediator) |
- 서로의 존재를 모르는 상태에서도 협력할 수 있게 하는 패턴 |
| 매멘토 (Mementor) |
- 객체의 내부 상태를 외부에 저장하여 필요시 해당 상태로 복원할 수 있는 패턴 |
| 옵저버 (Observer) |
- 관찰대상의 변화를 탐지하는 패턴 - 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 연락이 가서 자동으로 내용이 갱신되는 방식 |
| 상태 (State) |
- 객체의 상태에 따라 동일한 요청에 대해 다른 행동을 수행하도록 상태별로 동작을 분리하는 패턴 |
| 전략 (Starategy) |
- 알고리즘을 캡슐화하여 클라이언트에 영향 받지 않는 독립적인 알고리즘을 선택하는 패턴 |
| 템플릿 메소드 (Template Method) |
- 알고리즘의 기본 뼈대는 슈퍼클래스에서 정의하고 세부 단계는 서브클래스가 구현 |
| 방문자 (Visitor) |
- 필요할 때마다 해당 클래스에 방문하여 처리하는 패턴 |
2.4 미들웨어
(1) 종류
| 구분 | 설명 |
| WAS (Web Application Server) |
- 서버 계층에서 애플리케이션이 동작할 수 있는 환경을 제공하고 안정적인 트랜잭션 처리와 관리, 다른 이기종 시스템과의 애플리케이션 연동을 지원하는 서버 |
3. 요구사항 확인
| 중분류 | 소분류 | 키워드 |
| 요구사항 분류 | 분류 | - 기능적 요구사항 - 비기능적 요구사항 |
| 요구 공학 | 요구사항 개발 프로세스 (도분명확) |
도출 - 분석 - 명세 - 확인 및 검증 |
| 도출 단계 기법 | - 인터뷰브레인 스토밍 - 워크숍 - 설문조사 - 델파이 기법 - 롤플레잉 |
|
| 분석 단계 기법 | - 자료 흐름 지향 분석 - 객체 지향 분석 |
|
| 명세 단계 기법 | - 비정형 명세 기법 : 자연어 기반 - 정형 명세 기법 : 수학적 원리와 표기법 |
|
| 확인 및 검증 단계 기법 | - 요구사항 검토 - 정형 기술 검토 활용 : 동료 검토, 워크 스루, 인스펙션 - 프로토타이핑 - 모델 검증 - 테스트 케이스 및 테스트를 통한 확인 - CASE 도구 활용 검증 - 베이스 라인을 통한 검증 - 요구사항 추적표를 통한 검증 |
3.1 요구사항 분류
| 분류 | 설명 |
| 기능적 요구사항 | - 시스템이 제공하는 기능, 서비스에 대한 요구사항 - 특정 상황에 대해 시스템이 어떻게 동작해야하는지에 대한 기술 - 특성 : 기능성, 완전성, 일관성 |
| 비기능적 요구사항 | - 시스템 구축에 대한 제약사항에 대한 요구사항 - 품질 속성에 관해 시스템이 갖춰야 할 기술, 시스템이 준수해야할 제한 조건 등 - 특성 : 신뢰성, 사용성, 효율성, 유지 보수성, 이식성, 보안성 및 품질 관련 요구사항, 제약 사항 |
3.2 요구공학
🤔 요구공학(Requirements Engineering) 이란?
사용자의 요구가 반영된 시스템을 개발하기 위해 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동
(1) 요구사항 개발 프로세스
요구사항 도출 → 분석 → 명세 → 확인 및 검증 (도분명확)
(2) 요구사항 도출 단계 기법
| 종류 | 설명 |
| 인터뷰 | |
| 브레인 스토밍 | |
| 워크숍 | |
| 설문조사 | |
| 델파이 기법 | - 전문가의 경험적 지식을 통한 문제 해결 및 미래 예측을 위한 방법 |
| 롤플레잉 |
(3) 요구사항 분석 단계 기법
| 종류 | 설명 |
| 자료 흐름 지향 분석 | |
| 객체 지향 분석 |
(4) 요구사항 명세 단계 기법
| 종류 | 설명 |
| 비정형 명세 기법 | - 자연어 기반 |
| 정형 명세 기법 | - 수학적원리와 표기법 - Z스키마, Patri Nets |
(5) 요구사항 확인 및 검증 단계 기법
| 종류 | 설명 |
| 요구사항 검토 | - 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 검토 |
| 정형 기술 검토 활용 | - 동료 검토 : 2~3명 리뷰 진행, 요구사항 명세서를 설명하고 이해 관계자들이 들으며 결함을 발견하는 형태로 진행 - 워크 스루 : 검토 자료를 회의 전에 배포하여 짧은 시간 동안 회의를 진행하여 리뷰를 통해 오류를 검출하고 문서화 - 인스펙션 : 다른 전문가 또는 팀이 검사하여 오류를 찾아내는 공식적 검토 방법 |
| 프로토타이핑 활용 | - 프로토 타입을 통해 효과적으로 요구 분석을 수행하여 명세서를 산출 |
| 모델 검증 | - 분석 단계에서 개발된 모델의 품질 검증 필요 |
| 테스트 케이스 및 테스트를 통한 확인 |
- 각각의 요구사항을 어떻게 확인할 지에 대한 계획을 수립하고 테스트 케이스 작성 |
| CASE 도구 활용 검증 | - 자동화된 일관적 분석을 제공하는 CASE 도구 활용 |
| 베이스라인을 통한 검증 |
- 요구사항을 추적하고 통제하는 시점인 베이스라인을 통해 요구사항에 대한 지속적 검증 수행 |
| 요구사항 추적표(RTM)을 통한 검증 |
- RTM : 요구사항 정의서를 기준으로 개발 단계별 최종 산출물이 어떻게 반영되고, 변경되었는지 확인 가능한 문서 |
728x90