기출문제가 출제된 부분은 배경색으로 표시해 두었습니다.
목차
1. 소프트웨어 개발방법론
2. 현행 시스템 분석
3. 요구사항 확인
소프트웨어 개발방법론
소프트웨어 생명주기
시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차
용어 | 설명 |
폭포수 모델 | 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어감 |
프로토타이핑 모델 | 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영 |
나선형 모델 | 위험을 최소화하기 위해 점진적으로 완벽한 시스템을 개발 |
반복적 모델 | 구축대상을 나누어 병렬적, 반복적으로 개발 후 통합 |
소프트웨어 개발방법론
소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차
용어 | 설명 |
구조적 방법론 | 전체를 기능에 따라 나누어 개발 + 통합 (하향식 접근, 나씨-슈나이더만 차트) |
정보공학 방법론 | 정보시스템 개발에 필요한 관리절차와 작업 기법 체계화 (대형 프로젝트) |
객체지향 방법론 | '객체'라는 기본 단위로 시스템 분석 및 설계 (객체, 클래스, 메시지) |
컴포넌트 기반 방법론 | 소프트웨어를 구성하는 컴포넌트를 조립해서 SW 개발 (확장성, 재사용) |
애자일 방법론 | 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응 (효율, 신속) |
제품 계열 방법론 | 특정 제품에 적용하고 싶은 공통된 기능 정의하여 개발 (임베디드 SW) |
- 나씨-슈나이더만 차트: 논리의 기술에 중점을 둔 도형식 표현 방법
- 컴포넌트: DB와 SW의 개발된 모듈 단위
애자일(Agile) 방법론
절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응, 개발 기간이 짧고 신속
용어 | 설명 |
XP(eXtreme Programming) | 의사소통 개선과 즉각적 피드백으로 SW 품질을 높임 |
스크럼(SCRUM) | 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 프로젝트 관리 중심 |
린(LEAN) | 토요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용 |
스크럼 용어 정리
- 백로그(Backlog): 제품과 프로젝트에 대한 요구사항
- 스프린트(Sprint): 2~4주의 짧은 개발 기간의 반복적 수행으로 품질 향상
- 스크럼 미팅: 매일 15분 정도의 미팅으로 To-Do List 계획 수립
- 번 다운 차트(Burn Down Chart): 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트
비용산정 모형
소프트웨어 규모파악을 통한 투입자원, 소요시간을 파악하여 계획의 비용을 산정
용어 | 설명 |
델파이 기법 | 전문가의 경험적 지식을 통한 문제 해결 기법 |
LoC(Lines of Code) 모형 | 각 기능의 원시 코드 라인의 낙관치, 중간치, 비관치를 통해 예측 |
Man Month 모형 | 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 비용 산정 |
COCOMO 모형 | 프로그램 규모에 따라 비용 산정 |
푸트남(Putnam) 모형 | 개발주기의 단계별로 요구할 인력의 분포를 가정 |
기능점수(FP) 모형 | 요구 기능을 증가시키는 인자별로 가중치 부여, 총합으로 비용 산정 |
Man Month 모형 정리
- Man Month = LoC / 프로그래머의 월간 생산성
- 프로젝트 기간 = Man Month / 프로젝트 인력
COCOMO 모형 정리
- 조직형: 기관 내부에서 개발된 중/소규모의 SW (5만 라인 이하)
- 반 분리형: 조직형과 임베디드형의 중간 (30만 라인 이하)
- 임베디드형: 초대형 규모 시스템 프로그램 개발에 적용 (30만 라인 이상)
일정관리 모델
프로젝트가 일정 기한 내에 적절하게 완료될 수 있도록 관리하는 모델
용어 | 설명 |
주 공정법(CPM) | 시작과 끝을 나타내는 노드의 연결 중, 가장 긴 경로를 계산 |
PERT | 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정 관리 |
중요 연쇄프로젝트 관리(CCPM) | 자원제약사항을 고려하여 일정 작성 |
주 공정법(CPM) 정리
- 아래의 경우, 프로젝트 기간은 14일이 된다.
현행 시스템 분석
현행 시스템 파악
현행 시스템이 어떤 하위 시스템으로 구성되어 있고, 제공 기능 및 기술 요소 등을 파악하는 활동
- 시스템 구성/기능/인터페이스 파악
- 아키텍처 및 SW 구성 파악
- HW 및 네트워크 구성 파악
소프트웨어 아키텍처
여러 가지 소프트웨어 구성요소와 특성, 관계를 표현하는 시스템 구조 또는 구조체
소프트웨어 아키텍처 4+1 뷰
고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 소프트웨어적 접근 방법
4개의 분리된 구조로 개념을 제시하고, 이들 구조가 서로 충돌되는지 등을 유스케이스로 검증한다.
- 유스케이스: 시스템이 액터(사용자)에게 제공해야 하는 기능
용어 | 설명 |
유스케이스 뷰 | 유스케이스, 아키텍처 도출 및 다른 뷰 검증 |
논리 뷰 | 시스템의 기능적 요구사항이 어떻게 제공되는지 설명 |
프로세스 뷰 |
시스템의 비기능적인 속성을 표현 (자원의 사용, 이벤트 처리 등) |
구현 뷰 | 개발 환경 안에서 SW 모듈의 구성을 설명 |
배포 뷰 | 컴포넌트가 물리적인 아키텍처에 어떻게 배치되는가를 설명 |
소프트웨어 아키텍처 패턴
SW를 설계할 때 참조할 수 있는 전형적인 해결방식 (일반화, 재사용 솔루션)
용어 | 설명 |
계층화 패턴 | 시스템을 계층으로 구분하여 구성 |
클라이언트-서버 패턴 | 하나의 서버와 다수의 클라이언트로 구성 |
파이프-필터 패턴 |
데이터 스트림을 생성하고 처리하는 시스템에서 사용 (시스템 → 시스템) |
브로커 패턴 | 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용 (원격 서비스 실행) |
모델-뷰-컨트롤러(MVC) 패턴 | 모델, 뷰, 컨트롤러 3개의 서브 시스템으로 구조화 |
모델-뷰-컨트롤러 패턴 정리
- 모델: 핵심 기능과 데이터 보관 (≒ DB)
- 뷰: 사용자에게 정보 표시 (≒ 프론트엔드)
- 컨트롤러: 사용자의 요청 입력받아 처리 (≒ 백엔드)
디자인 패턴(Design Pattern)
SW 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴
효율성과 유지보수성, 운용성이 높아지며 최적화에 도움이 된다.
디자인 패턴 유형
구분 - 유형 | 설명 |
목적 - 생성 | 클래스 정의 및 객체 인스턴스 생성 |
목적 - 구조 | 더 큰 구조 형성을 목적으로 클래스나 객체의 조합을 다룸 |
목적 - 행위 | 클래스나 객체의 상호작용 및 역할 분담을 다룸 |
범위 - 클래스 | 클래스 간 관련성, 컴파일 타임에 정적으로 결정 |
범위 - 객체 | 객체 간 관련성, 런타임에 동적으로 결정 |
관련 용어 정리
- 컴파일 타임: 소스코드가 컴파일을 통해 기계어로 전환 (정적 메모리 할당)
- 런타임: 컴파일을 마친 프로그램(바이너리)가 실행되어 동작 (동적 메모리 할당)
디자인 패턴 종류
생성패턴
용어 | 설명 |
Builder | 복잡한 인스턴스를 조립하여 만드는 구조 (생성과 표기를 분리) |
Prototype | 일반적인 원형을 만들어 놓고, 이를 복사해 필요한 부분만 수정 |
Factory Method | 상위 클래스에서 객체 생성 인터페이스 정의, 하위 클래스에서 인스턴스 생성 |
Abstract Factory | 구체적인 클래스에 의존 X, 연관되거나 의존적인 객체들의 조합 |
Singleton | 전역 변수를 사용 X, 객체를 하나만 생성 |
구조패턴
용어 | 설명 |
Bridge | 기능 클래스 계층과 구현 클래스 계층을 연결 |
Decorator | 기존에 구현되어 있는 클래스에 필요한 기능을 추가 |
Facade | 복잡한 시스템에 대하여 단순한 인터페이스 제공 |
Flyweight | 모두가 갖는 본질적 요소를 클래스화 하여 공유 (클래스의 경량화) |
Proxy | 실제 객체에 대한 대리 객체 |
Composite | 객체들의 관계를 트리 구조로 표현 |
Adapter | 기존 클래스를 재사용할 수 있도록 중간에서 맞춰주는 역할의 인터페이스 |
행위패턴
용어 | 설명 |
Mediator | 객체 수가 너무 많아지면 결합이 강해질 수 있기에, 중재자를 두는 방식 |
Interpreter | 언어의 다양한 해석, 구문을 나누고 이를 해석하는 클래스를 각각 작성 |
Iterator | 내부구조를 노출하지 않고 집합체 안에 들어있는 모든 항목에 접근 |
Template Method | 상위 작업 구조를 바꾸지 않으면서, 서브 클래스로 일부분 수행 |
Observer | 한 객체의 상태가 바뀌면 이를 의존하는 다른 객체에게 연락 |
State | 객체 상태를 캡슐화 |
Visitor | 클래스에서 처리 기능을 분리하여, 메소드가 클래스를 돌아다니며 작업 |
Command | 실행될 기능을 캡슐화 |
Strategy | 알고리즘 군을 정의 |
Memento | 객체를 이전 상태로 복구시켜야 하는 경우, 작업취소(Undo) 가능 |
Chain of Responsibility | 한 요청을 2개 이상의 객체에서 처리 |
운영체제
컴퓨터 시스템이 제공하는 모든 HW, SW를 사용할 수 있도록 해주며 사용자와 HW간의 인터페이스를 담당
종류: 윈도우, 유닉스, 리눅스, 안드로이드, iOS
OSI 7계층
네트워크 통신에서 생긴 여러 가지 문제를 완화하기 위해 국제 표준화 기구(ISO)에서 제시한 네트워크 기본 모델
계층 | 설명 | 프로토콜 |
응용 계층(Application) | 사용자와 네트워크 간 응용 서비스 연결, 데이터 생성 | HTTP, FTP |
표현 계층(Presentation) | 데이터 형식 설정과 부호 교환, 암/복호화 | JPEG, MPEG |
세션 계층(Session) | 연결 접속 및 동기 제어 | SSH, TLS |
전송 계층(Transport) | 신뢰성 있는 통신 보장 | TCP, UDP |
네트워크 계층(Network) | 단말 간 데이터 전송을 위한 경로 제어 | IP, ICMP |
데이터 링크 계층(Data Link) | 인접 시스템 간 데이터 전송 | ETHERNET |
물리 계층(Physical) | 0과 1의 비트 정보를 회선에 보내기 위한 전기적 신호 변환 | RS-232C |
미들웨어(Middleware)
분산 컴퓨팅 환경에서 응용 프로그램 ↔ 환경(시스템) 간에 원만한 통신이 이루어질 수 있도록 제어해주는 SW
대표적인 미들웨어로는 WAS(Web Application Server)가 있다.
요구사항 확인
요구공학(Requirements Engineering)
사용자의 요구가 반영된 시스템을 개발하기 위해 요구사항에 대한 도출, 분석, 명세, 확인 및 검증을 하는 활동
용어 | 설명 |
기능적 요구사항 | 시스템이 제공하는 기능, 서비스에 대한 요구사항 |
비기능적 요구사항 | 기능 이외의 사항, 시스템 구축에 대한 제약사항에 대한 요구사항 |
요구사항 도출 기법
용어 | 설명 |
인터뷰 | 이해관계자와 직접 대화 |
브레인스토밍 | 회의 참석자들이 내놓은 아이디어를 비판 없이 수용 |
델파이 기법 | 전문가의 경험적 지식을 통한 해결 |
롤 플레잉 | 현실 장면을 설정하고 사람들이 각자 맡은 역을 연기 |
워크숍 | 단기간의 집중적인 노력을 통해 정보 획득 및 공유 |
설문 조사 | 설문지 또는 여론조사를 통해 간접적으로 정보 수집 |
정형 기술 검토를 활용한 요구사항 검증
용어 | 설명 |
동료 검토(Peer Review) | 명세서 작성자가 설명, 이해 관계자들이 설명을 들으며 진행 (2~3명) |
워크 스루(Walk Through) | 검토 자료를 회의 전에 배포하여 사전 검토 후 짧은 시간 동안 회의 |
인스펙션(Inspection) | 저작자 외의 다른 전문가 또는 팀이 검사하여 오류를 검사 |
'IT > 정보처리기사' 카테고리의 다른 글
정보처리기사 5단원(인터페이스 구현) 요약 (0) | 2021.07.01 |
---|---|
정보처리기사 4단원(통합 구현) 요약 (0) | 2021.06.30 |
정보처리기사 3단원(데이터 입출력 구현) 요약 (0) | 2021.06.29 |
정보처리기사 2단원(화면 설계) 요약 (2) | 2021.06.26 |
정보처리기사 실기 요약 정리 모음집 (3) | 2021.06.25 |
댓글