정보처리기사 Note-Taking [1]
정보처리기사 요약 노트 정리 1편
정보처리기사 Note-Taking [1]
해당 포스트는 학습 목적으로 작성되었으며 «2025 시나공 정보처리기사 실기 기본서»을 참고하여 작성하였음을 알려드립니다.
1장 - 요구사항 확인
001 소프트웨어 생명 주기
폭포수 모형(Waterfall Model)
- 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후에 다음 단계를 진행
프로토타입 모형(Prototype Model)
- 실제 개발될 소프트웨어에 대한 견본품(prototype)을 만들어 최종 결과물을 예측하는 모형
나선형 모델(Spiral Model)
- 여러번의 개발과정을 거쳐 점진적으로 개발
계획수립->위험분석->개발 및 검증->고객평가
애자일 모형(Agile Model)
- 고객의 요구사항 변화에 유연하게 대응해도록 일정한 주기를 반복하면서 개발
- 대표적인 개발 모형
- 스크럼(Scrum)
- XP(eXtreme Programming)
- 칸반(Kanban)
- Lean
- 기능 중심 개발(FEE; Feature Driven Development)
애자일 개발 4가지 핵심 가치
- 프로세스와 도구보다는 개인과 상호작용에 더 가치를 둔다.
- 방대한 문서보다는 실행되는 SW에 더 가치를 둔다
- 계약 협상보디는 고객과의 협업에 더 가치를 둔다
- 계획을 따르기 보다 변화에 반응하는 것에 더 가치를 둔다.
002 스크럼(Scrum) 기법
스크럼 개발 프로세스
- 스프린트 : 2 ~ 4 주
- 매일 스크럼 회의 진행
003 XP(eXtreme Programming) 기법
XP(eXtreme Programming)
- XP의 5가지 핵심 가치
- 의사소통(Communication)
- 단순성(Simplicity)
- 용기(Courage)
- 존중(Respect)
- 피드백(Feedback)
XP 개발 프로세스
- 이터레이션 : 1 ~ 3 주 정도의 기간으로 진행
XP의 주요 실천 방법(Practice)
| 실천방법 | 내용 |
|---|---|
| Pair Programming (짝 프로그래밍) | - 다른 사람과 함깨 프로그래밍 - 개발에 대한 책임을 공동으로 나눠 갖는 환경 조성 |
| Collective Ownership (공동 코드 소유) | - 개발 코드에 대한 권한과 책임을 공동으로 소유 |
| Test-Driven Development (테스트 주도 개발) | - 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성 - 테스트가 지속적을로 진행되도록 자동화 된 테스팅 도구(구조, 프레임워크) 사용 |
| Whole Team (전체 팀) | - 모든 구성원(고객 포함) 각자 자신의 역할이 있고 그 역할에 대한 책음을 가짐 |
| Continuous Integration (지속적인 통합) | - 모듈 단위로 나눠서 개발된 코두둘울 하나의 작업이 마무리 될 때마다 지속적 으로 통합 |
| Refactoring (리팩토링) | - 기능의 변경 없이 시스템을 재구성 - 목적 : 프로그램을 쉽게 이해하고 쉽게 수정하여 빠르게 개발 할 수 있게 하기 위함 |
| Small Releases (소규모 릴리즈) | - 릴리즈 기간을 짧게 반복함으로서 고객의 요구 변화에 신속히 대응 |
006 요구사항 개발 프로세스
요구사항 개발 프로세스
도출(Elicitation)->분석(Analysis)->명세(Specification)->확인(Vaildation)
요구사항 도출
- 요구사항을 도출하는 주요 기법
- 브레인 스토밍
- 프로토타이핑
- 유스케이스
요구사항 분석
- 요구사항 분속에 사용되는 대표적인 도구
- 자료흐름도(DFD)
- 자료 사전(DD)
요구사항 명세
- 구체적인 명세를 위해 소단위 명세서(Mini-Spec) 가 사용될 수 있다
요구사항 명세 기법
| 구분 | 정형 명세 기법 | 비정형 명세 기법 |
|---|---|---|
| 기법 | 수학적 원리 기반, 모델 기반 | 상태 / 기능 / 객체 중심 |
| 작성방법 | 수학적 기호, 정형화된 표기법 | 일반 명사, 동사 등의 자연어를 기반으로 서술 또는 다이어그램으로 작성 |
| 특징 | - 요구사항을 정확하고 간결하게 표현 - 요구사항의 대한 결과가 일관성이 있으르로 완정성 검증 가능 - 사용자가 이해하기 어려움 | - 자연어의 사용으로 인해 일관성이 떨어짐, 해석이 달라질 수 있음 - 내용의 이해가 쉬워 의사소통이 용이함 |
010UML - 관계(Relationship)
관계(Relationships)
- 관계의 종류 : 연관, 집합, 포함, 일반화, 의존, 실제
연관(Association) 관계
- 2개 이상의 사물이 서로 관련되어 있는 관계
- 사물 사이를 실선으로 연결하여 표현
e.g. 사람이 집을 소유하는 관계. 사람은 자기가 소유하고 있는 집에 대해 알지만 집은 누구에 의해 자신이 소유되고 있는지 모름
집합(Aggregation) 관계
- 하나의 사물이 다른 사물에 포함되어 있는 관계
e.g. 프린터는 컴퓨터에 연결해서 사용할 수 있으며, 다른 컴퓨터에 연결해서 사용 할 수도 있다.
포함(Composition) 관계
- 포함하는 사물의 변화가 포함되는 사물에게 영향을 미치는 관계
e.g. 문을 열 수 있는 키는 하나이며, 해당 키로 다른 문을 열 수 없다. 문이 없어지면 키도 더 이상 필요 없다.
일반화(Generalization) 관계
- 하나의 사물이 다른 사물에 비해 더 일반적이거나 구체적인 관계
e.g. 아메리카노와 에스프레소는 커피이다. 다시 말하면, 커피에는 아메리카노와 에스프레소가 있다.
의존(Dependency) 관계
- 서로에게 영향을 주는 짧은 시간동안만 연관을 유지하는 관계
e.g. 등급이 높으면 할인율을 적용하고, 등급이 낮으면 할인율을 적용하지 않는다.
실체화(Realization) 관계
- 할 수 있거나 해야 하는 기능으로, 서로를 그룹화 할 수 있는 관계이다.
e.g. 비행기는 날 수 있고 새도 날 수 있다. 그러므로 비행기와 새는 날 수 있다는 행위로 그룹화를 할 수 있다.
011 UML - 다이어그램
다이어그램(Diagram)
- 정적 모델링 -> 구조적 다이어그램
- 동적 모델링 -> 행위 다이어그램
구조적(Structural) 다이어그램의 종류
| 종류 | 내용 |
|---|---|
| 클래스 다이어그램 (Class) | - 클래스와 클래스가 가지는 속성, 클래스 사이의 관계를 표현함 |
| 객체 다이어그램 (Object) | - 클래스에 속한 사물(객체) 즉 인스턴스(Instance)를 특정 시점의 객체와 객체 사이의 관계로 표현 - 럼바우(Rumbaugh) 객체지향 분석 기법에서 객체 모델링에 활용 |
| 컴포넌트 다이어그램 (Component) | - 실제 구현 모듈인 컴포넌트 간의 관계나 컴포넌트 간의 인터페이스를 표현 - 구현 단계에서 사용 |
| 배치 다이어그램 (Deployment) | - 결과물, 프로세스, 컴포넌트 등 물리적인 요소들의 위치를 표현 - 구현 단계에서 사용 |
| 복합체 다이어그램 (Composite Structure) | - 클래스나 컴포넌트가 복합 구조를 갖고 있는 경우 그 내부 구조를 표현 |
| 패키지 다이어그램 (Package) | - 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지 들의 관계를 표현 |
행위(Behavioral) 다이어그램의 종류
| 종류 | 내용 |
|---|---|
| 유스케이스 다이어그램 (Use Case) | - 사용자의 요구를 분석. 기능 모델링 작업에 사용 - 사용자(Actor)와 사용 사례(Use Case)로 구성 |
| 순차 다이어그램 (Sequence) | - 상호 작용하는 시스템이나 객체들이 주고받는 메세지를 표현 |
| 커뮤니케이션 다이어그램 (Comunication) | - 동작에 참여하는 객체들이 주고 받는 메세지와 객체들 간의 연관 관계를 표현 |
| 상태 다이어그램 (State) | - 하나의 객체가 자신이 속한 클래스의 상태 변화 혹은 다른 객체와의 상호작용에 따라 변화를 표현 - 럼바우(Rumbaugh) 객체지향 분석 기법에서 객체 모델링에 활용 |
| 활동 다이어그램 (Activity) | - 시스템이 어떤 기능을 수행하는지 객체의 처리 로직이나 조건에 따른 처리의 흐름을 순서에 따라 표현 |
| 상호작용 개요 다이어그램 (Interaction Overview) | - 상호작용 다이어그램 간의 제어 흐름을 표현 |
| 타이밍 다이어그램 (Timing) | - 객체의 상태 변화와 시간 제약을 명시적으로 표현 |
021 비용 산정 기법 - 하향식
하향식 비용 산정 기법
- 과거의 유사한 경험을 바탕으로 전문 지식이 많은 개발자들이 참여한 회의를 통해 비용을 산정하는 기법
- 하향식 비용 산정 기법
- 전문가 감정 기법
- 델파이 기법
델파이 기법
- 전문가 감정 기법의 준관적인 편견을 보완하기 위해 많은 전문가의 의견을 종합하여 산정하는 기법
022 비용 산정 기법 - 상향식
상향식 비용 산정 기법
- 새부적인 작업 단위별로 비용을 산정한 후 집계하여 전체 비용을 산정하는 방법
- 주요 상향식 비용 산정 기법
- LOC(원시 코드 라인 수) 기법
- 개발 단계별 인월수 기법
- 수학적 산정 기법
LOC(원시 코드 라인 수, source Line Of Code) 기법
- 각 기능의 원시 코드 라인 수의 비관치, 낙관치, 기대치 를 측정하여 예측치 를 구하고 이를 이용하여 비용을 산정하는 기법
- 측정이 용이하고 이해하기 쉬워 가장 많이 사용
개발 단계별 인월수(Effort Per Task) 기법
- 기능을 구현시키는 데 필요한 노력을 생명 주기의 각 단계별로 산정
023 수학적 산정 기법
수학적 산정 기법
- 주요 수학적 산정 기법
- COCOMO 모형
- Putnam 모형
- 기능 점수(FP) 모형
COCOMO(COnstructive COst MOdel) 기법
- LOC에 의한 비용 산정 기법
| 유형 | 특징 |
|---|---|
| 조직형 (Organic) | - 기관 내부에서 개발된 중/소 규모의 소프트웨어 - 5만(50KDSI)라인 이하의 소프트웨어를 개발하는 유형 |
| 반분리형 (Semi-Detached) | - 조직형과 내장형의 중간형 소프트웨어 - 30만(300KDSI)라인 이하의 소프트웨어를 개발하는 유형 |
| 내장형 (Embedded) | - 초대형 규모의 소프트웨어 - 30만(300KDSI)라인 이상의 소프트웨어를 개발하는 유형 |
Putnam 모형
- 소프트웨어 생명주기의 전 과정 동안에 사용될 노력의 분포를 예상하는 모형
- 생명주기 예측모형 이라고도 함
기능 점수(FP; Function Point) 모형
- 소프트웨어의 기능을 증대시키는 요인별로 가중치 부여. 기능 점수(FP) 구한 후 비용을 산정하는 기법
- 알브레히트(Albrecht)가 제안
Related Posts
References
This post is licensed under CC BY 4.0 by the author.