정보처리기사 실기 공부 day1, 요구사항 확인
중요한 것 정리
소프트웨어 생명주기, 개발방법론, 비용산정 모형, 일정관리 모델, 소프트웨어 아키텍처, 디자인 패턴, 요구공학 프로세스, 럼바우(객동기)
소프트웨어 생명주기
개념
시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차.
프로세스
분설구테유
요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수
종류
- 폭포수 모델(Waterfall Model)
- 단계 마무리 짓고 다음 단계로 넘어감.
- 선형 순차적 모형, 고전적 생명주기 모형. 가장 오래됨 => 성공사례 많음. but, 변경 어려움.
- 타당성 검토 -> 계획 -> 요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 유지보수.
- 프로토타이핑 모델(Prototyping Model)
- 프로토타입으로 구현해 피드백 받아가며 만들어감.
- 나선형 모델(Spiral Model)
- 위험 최소화. 점진적 개발.
- 계획 및 정의 -> 위험 분석 -> 개발 -> 고객 평가
- 반복적 모델(Iteration Model)
- 병렬개발 후 통합, 반복적 개발.
소프트웨어 개발방법론
개념
소프트웨어 개발 전체의 과정에 적용할 수 있는 방법론이다.
종류
- 구조적 방법론(Structured Development)
- 전체 시스템 기능에 따라 나누어 개발, 통합.
- 분할과 정복 방식.
- 프로세스 중심, 하향식 방법.
- 나씨-슈나이더만 차트(논리의 기술, 도형식 표현, 복합 조건 시각적 처리 명확) 사용.
- 정보공학 방법론(Information Engineering Development)
- 정보시스템 개발. 대형 프로젝트 체계적 수행 방법.
- 객체지향 방법론(Object-Oriented Development)
- 객체를 기본 단위로 하는 방법론.
- SOLID
- Single Responsibility Principle : 단일 책임 원칙, 객체는 단 하나의 책임만
- Open-Closed Principle : 개방 폐쇄 원칙, 기존 변경하지 않으면서 기능 추가
- Liskov Substitution Principle : 리스코프 치환 원칙, 하위가 상위를 대체할 수 있어야 됨
- Interface Segregation Principle : 인터페이스 분리 원칙, 클라이언트 친화적으로 인터페이스 분리
- Dependency Inversion Principle : 의존성 역전 원칙, 추상화된 것(변화 별로 없는 것)에 의존
- 컴포넌트 기반 방법론(Component-Based Development)
- 컴포넌트 조립으로 프로그램 만드는 방법.
- 생산성, 확장성, 재사용성
- 제품 계열 방법론(Product Line Development)
- 특정 제품, 공통 기능. 임베디드. 영역 공학과 응용 공학.
- 애자일 방법론(Agile Development)
- 절차보다 사람 중시.
- 신속하게 변화 적용. 폭포수 모델과 반대.
- XP(eXtreme Programming), 스크럼(SCRUM), 린(Lean)
애자일 방법론(Agile Developmnet)
XP(eXtreme Programming)
- 의사소통, 피드백.
- 1~3주의 개발 주기.
- 5 가치, 12 실천항목.
5가지 가치
용단의 피존 용기, 단순성, 의사소통, 피드백, 존중
12가지 기본원리
짝 프로그래밍, 공동 코드 소유, 지속적인 통합, 계획 세우기, 작은 릴리즈, 메타포어, 테스트 기반 개발, 리팩토링, 간단한 디자인, 40시간 작업, 고객 상주, 코드 표준
스크럼(SCRUM)
- 짧은 시간 개발
- 주요 개념 : 백로그(요구사항), 스프린트, 스프린트 회고, 스크럼 미팅, 스크럼 마스터, 번 다운 차트
린(Lean)
- 도요타 품질기법 적용. 낭비요소 최소화.
- 칸반(Kanban) 보드, Just In Time(JIT)
- 7가지 원칙 : 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화
비용산정 모형
개념
소프트웨어 규모를 파악해 개발 계획을 세우기 위해 비용을 산정하는 방법.
분류
- 하향식
- 전문가 기반
- 전문가 판단, 델파이 기법
- 상향식
- 시간, 규모 등으로 계산
- Loc(코드 라인 수), Man Month, COCOMO, Putnam, FP(기능 점수)
종류
델파이 기법
전문가의 경험적 지식 등을 활용해 비용 예측.
LoC(Lines of Code) 모형
코드 라인 수의 낙관치, 중간치, 비관치를 통해 예측치를 계산하는 방법.
예측치 = (낙관치 + (4 * 중간치) + 비관치) / 6
Man Month 모형
1개월 동안 한 사람이 할 수 있는 일의 양으로 비용 산정. 이를 통해 프로젝트 기간 도출 가능.
Man Month = (LoC) / (월간 생산성)
프로젝트 기간 = (Man Month) / (개발 인력)
COCOMO(COnstructive COst MOdel)
보헴이 제안, 프로그램 규모에 따라 비용 산정.
- 조직형(Organic Mode) : 5만 라인 이하
- 반 분리형(Semi-Detached Mode) : 30만 라인 이하
- 임베디드형(Embedded Mode) : 30만 라인 이상
Putnam 모형
푸트남이 제안, 인력의 분포 가정. 생명주기 예측 모형.
시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 함.
FP(Function Point) 모형 - 기능점수 모형
기능별 가중치 부여, 합산해 총 기능 점수 계산해 비용 산정.
단순, 보통, 복잡 정도로 가중치 부여.
FP = (총 기능점수) * [0.65 + (0.1 * 총 영향도)]
일정관리 모델
개념
기간 내에 프로젝트가 완료될 수 있도록 관리하는 모델.
종류
주 공정법(CPM, Critical Path Method)
- 여러 작업의 수행 순서 얽혀 있을 때 일정 계산하는 방법.
- 자원 제약사항 고려하지 않음.
- 시작 노드와 끝 노드간 연결에서 공정 계산.
- 임계 경로(Critical Path) : 가장 긴 시간이 걸리는 경로.
PERT(Program Evaluation and Review Technique)
- 비관치, 중간치, 낙관치의 3점 추정방식으로 관리.
- 순서 계획적 정리.
중요 연쇄 프로젝트 관리(CCPM, Critical Chain Project Management)
- 주 공정 연쇄법
- 자원 제약사항 고려함.
소프트웨어 아키텍처
현행 시스템 파악 절차
구성/기능/인터페이스 파악 -> 아키텍처 및 소프트웨어 구성 파악 -> 하드웨어 및 네트워크 구성 파악
소프트웨어 아키텍처
소프트웨어 구성요소와 외부에 드러나는 특성, 구성요소들 간의 관계를 표현하는 구조.
소프트웨어 아키텍처 프레임워크
아키텍처에서 표현해야 하는 내용과 관계를 제공하는 기술 표준.
아키텍처 명세서, 이해관계자, 관심사, 관점, 뷰, 근거, 목표, 환경, 시스템 등으로 구성되어 있다.
4 + 1 뷰
- 유스케이스 뷰(Usecase View)
- 다른 뷰를 검증.
- 사용자, 설계자, 개발자, 테스트 관점
- 논리 뷰(Logical View)
- 시스템의 기능적인 요구사항 어떻게 제공되는지 설명.
- 설계자, 개발자 관점.
- 프로세스 뷰(Process View)
- 비기능적인 속성 표현. 자원 사용, 병행 실행, 비동기, 이벤트 등.
- 개발자, 시스템 통합자 관점.
- 구현 뷰(Implementation View)
- 컴포넌트 구조, 의존성. 모듈의 구성 보여줌.
- 배포 뷰(Deployment View)
- 물리적으로 어떻게 배치되는가 보여줌.
소프트웨어 아키텍처 패턴
개념
설계시 참조할 수 있는 해결 방식.
유형
- 계층화 패턴(Layer Pattern)
- 계층으로 구분. 마주보는 두 개의 계층에서만 상호작용 함.
- 하위 모듈은 추상화 제공, 각 계층은 상위 계층에 서비스 제공.
- 클라이언트-서버 패턴(Client-Server Pattern)
- 사용자->클라이언트->서버->클라이언트->사용자 로 서비스 요청, 제공.
- 하나의 서버, 다수의 클라이언트.
- 파이프-필터 패턴(Pipe-Filter Pattern)
- 데이터 스트림.
- 파이프를 통해 데이터가 반복적으로 넘어감.
- 재사용성, 확장성
- 브로커 패턴(Broker Pattern)
- 사용자->클라이언트->브로커->서버->브로커->클라이언트->사용자
- 브로커가 컴포넌트 간의 역할과 통신 제어. 분산 시스템에서 사용.
- 모델-뷰-컨트롤러 패턴(MVC, Model-View-Controller Pattern)
- 모델(데이터 저장 등), 뷰(화면으로 표시), 컨트롤러(이벤트 처리 등) 세 개의 시스템으로 분리.
- 재사용성. 대화형 애플리케이션에 이용.
소프트웨어 아키텍처 비용 평가 모델
- SAAM(Software Architecture Analysis Method) : 변경 용이성. 기능성.
- ATAM(Architecture Trade-off Anaylsis Method) : SAAM 발전. 아키텍처 품질 속성 + 이해 상충관계
- CBAM(Cost Benefit Analysis Method) : ATAM 발전. 비용 평가 추가.
- ADR(Active Design Review) : 응집도 평가.
- ARID(Active Reviews for Intermediate Designs) : ATAM + ADR. 특정부분 품질 비용평가.
디자인 패턴
개념
소프트웨어 설계에서 발생하는 문제에 적용할 수 있는 설계 방법
유형
생구행
목적에 따라 생성, 구조, 행위로 나뉜다. 범위에 따라서는 클래스, 객체로 나뉜다.
종류
생성 패턴
빌프팩추싱
- 빌더(Builder)
- 복잡한 객체를 만들 때, 객체를 생성하는 방법과 구현하는 방법을 분리하는 디자인 패턴.
- 생성과 구현의 분리, 복잡한 인스턴스.
- 프로토타입(Prototype)
- 객체의 원형을 설정하고, 이를 통해 필요한 부분만 수정해서 인스턴스를 만드는 패턴.
- 기본 형태가 있는 객체 복사, 수정.
- 팩토리 메서드(Factory Method)
- 상위 클래스는 인터페이스 정의, 하위 클래스는 인스턴스 생성하도록 클래스 구분하는 패턴.
- 인터페이스와 생성 클래스를 나눔.
- 추상 팩토리(Abstract Factory)
- 관련된 객체들을 하나의 인터페이스로 제공하는 패턴.
- 주제가 같은 팩토리들을 하나로 묶음.
- 싱글톤(Singleton)
- 하나의 객체만 생성해 전체에서 참조할 수 있도록 하는 패턴.
- 전역 변수 없이 객체 하나만 생성.
구조 패턴
브어데 파플컴프
- 브리지(Bridge)
- 추상 계층과 구현층을 분리하여 독립적으로 확장할 수 있게 하는 패턴.
- 기능 계층과 구현 계층 연결.
- 어댑터(Adapter)
- 클래스 재사용을 위해 중간에서 맞춰줌. 상속과 위임을 사용하는 패턴.
- 인터페이스 호환되도록 덮어씀.
- 데코레이터(Decorator)
- 기존 구현된 것에 기능 추가하는 패턴.
- 객체 간 결합 동적으로 유연한 확장.
- 파사드(Facade)
- 복합 시스템, 단순 인터페이스, 결합도 낮추고 접근성 높이는 패턴.
- 인터페이스 식별 용이.
- 플라이웨이트(Flyweight)
- 클래스의 경량화를 목적으로 본질적인 요소를 클래스화하는 패턴.
- 가상 인스턴스를 통해 메모리 절약.
- 컴포지트(Composite)
- 트리 구조의 객체로, 단일 객체와 복합 객체를 동일하게 사용하는 패턴.
- 프록시(Proxy)
- 특정 객체를 은닉하고, 대리 객체를 통해 행동할 수 있게 만드는 패턴.
- 메모리 용량 줄이기, 정보 은닉.
행위 패턴
전메 인중 반상 커역 비옵템
- 전략(Strategy)
- 알고리즘을 클래스로 캡슐화해 필요할 때 사용, 교환할 수 있게 하는 패턴.
- 행위를 클래스로 캡슐화. 동적으로 행위 자유롭게 바꿈.
- 메멘토(Memento)
- Undo 기능이 필요할 때 사용하는 패턴.
- 인터프리터(Interpreter)
- 여러 형태의 언어 구문을 해석할 수 있게 만든 패턴.
- 중재자(Mediator)
- 중재자를 통해 객체지향적 프로그래밍을 하게 하는 패턴.
- 결합도 낮추기 위해 중재자 만듦.
- 반복자(Iterator)
- 내부 구현부를 노출하지 않고 모든 기능을 사용할 수 있게 하는 패턴.
- 상태(State)
- 객체 상태를 캡슐화해 참조하는 방식으로, 상태에 따라 행위를 변경할 수 있게 하는 패턴.
- 커맨드(Command)
- 기능을 클래스로 캡슐화해 여러 기능을 실행하게 만드는 패턴.
- 역할 사슬(Chain of Responsibility)
- 기능 연결이 하드코딩됐을 땐 연결을 수정할 수 없지만, 동적으로 연결된 경우엔 수정할 수 있게 하는 패턴.
- 비지터(Visitor)
- 데이터 구조에서 처리 기능을 분리해 구조는 유지하고 기능만 추가할 수 있도록 하는 패턴.
- 옵저버(Observer)
- 객체의 상태가 관련된 다른 객체를 업데이트하는 패턴.
- 일대 다의 의존성.
- 템플릿 메서드(Template Method)
- 구조는 바꾸지 않고 수행하는 내용을 바꾸는 패턴.
- 상위 클래스는 기능 골격 제공, 하위 클래스는 기능 구체화.
요구공학 프로세스
요구사항 개발 단계
도분명확
요구사항 도출 -> 요구사항 분석 -> 요구사항 명세 -> 요구사항 확인 및 검증
- 요구사항 도출 : 요구사항 식별, 수집 방법 결정, 요구사항 표현 등.
- 요구사항 분석 : 요구사항 정제, 타당성 조사, 이해 등을 통해 완전성, 일관성 확보.
- 요구사항 명세 : 요구사항 명세서 작성하는 단계.
- 요구사항 확인 및 검증 : 확인(Validation), 검증(Verification).
정형 기술 검토 기법
- 동료 검토(Peer Review) : 요구사항 명세서 작성자가 설명하고, 이해관계자가 들으며 오류 발견
- 워크 스루(Walk Through) : 회의 전 사전검토, 짧은 시간 회의, 오류 조기 발견
- 인스펙션(Inspection) : 다른 팀 혹은 전문가가 검사해 오류 발견
- 관리 리뷰(Management Review) : 진행 상황을 전반적으로 검토
- 기술 리뷰(Technical Review) : 계획 및 명세 준수하는지 검토
- 감사(Audit) : 제3자, 소비자, 제공자에 의해 가이드라인 등을 준수하는지 평가
PLUS
럼바우의 분석 기법 - 객동기
- 객체 모델링 - 시스템의 정적 구조 표현. 객체 다이어그램(ERD, ER-Diagram)으로 객체들 간의 관계 표시.
- 동적 모델링 - 객체 간 상호 반응, 제어 흐름 표현. 상태 다이어그램(상태도)으로 시간에 따른 객체들 간의 상호 반응, 제어 흐름 등 동적인 행위 표시.
- 기능 모델링 - 데이터 값의 변화 과정 표현. 자료 흐름도(DFD)를 통해 다수의 프로세스 간 자료 흐름을 중심으로 처리 과정을 표시.
참고
수제비 2021 정보처리기사 실기
댓글남기기