수제비 2022 정보처리기사 실기 수험서를 보고 공부한 기록입니다.
1. 소프트웨어 개발 방법론
(1) 소프트웨어 생명주기 모델
소프트웨어 생명주기(SDLC; Software Development Life Cycle) 모델 개념
- 소프트웨어 생명주기는 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차이다
- 시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지 어떠한 순서를 밟는지에 대한 작업 프로세스를 모델화한 것이다
소프트웨어 생명주기 모델 프로세스
- 요구사항 분석
- 다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계
- 개발할 소프트웨어의 기능과 제약 조건, 목표 등을 소프트웨어 사용자와 함께 명확히 정의하는 단계
- ex) 기능 요구사항, 비기능 요구사항
- 설계
- 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계
- ex) 시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계
- 구현
- 설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계
- 프로그래밍 언어 선택, 기법, 스타일, 순서 등을 결정하는 단계
- ex) 인터페이스 개발, 자료 구조 개발, 오류 처리
- 테스트
- 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계
- ex) 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트
- 유지보수
- 시스템이 인수되고 설치된 후 일어나는 모든 활동
- ex) 예방, 완전, 교정, 적응 유지보수
소프트웨어 생명주기 모델 종류
- 폭포수 모델(Waterfall Model)
- 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델
- 가장 오래된 모델
- 선형 순차적 모형으로 고전적 생명주기 모형이라고도 함
- 모형의 적용 경험과 성공 사례가 많음
- 단계벌 정의와 산출물이 명확
- 요구사항 변경이 어려움
- 타당성 검토->계획->요구사항 분석->설계->구현->테스트->유지보수
- 프로토타이핑 모델(Prototyping Model)
- 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델
- 프로토타입은 발주자나 개발자 모두에게 공동의 참조 모델을 제공
- 프로토타입은 구현 단계의 구현 골격
- 나선형 모델(Spiral Model)
- 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델
- 계획 및 정의->위험 분석->개발->고객 평가
- 반복적 모델(Iteration Model)
- 구축대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델
- 사용자의 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델
| 구분 | 폭포수 모델 | 프로토타이핑 모델 | 나선형 모델 | 반복적 모델 |
|---|
| 특징 | 순차적 접근 | 프로토타입 개발 | 위험분석, 반복개발 | 증분방식으로 병행 개발 |
| 장점 | 이해가 용이 관리가 편이 | 요구분석 용이 타당성 검증 가능 | 위험성 감소와 변경에 유연한 대처 | 병행 개발로 인한 일정 단축 가능 |
| 단점 | 요구사항 변경이 어려움 | 프로토타입 폐기에 따른 비용 증가 | 단계 반복에 따른 관리 어려움 | 병행 개발에 따른 관리 비용 증가 |
(2) 소프트웨어 개발 방법론
소프트웨어 개발 방법론(Software Development Methodology) 개념
- 소프트웨어 개발 방법론은 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법이다
- 소프트웨어를 하나의 생명체로 간주하고 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론이다
소프트웨어 개발 방법론 종류
- 구조적 방법론(Structured Development)
- 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론
- 프로세스 중심의 하향식 방법론
- 구조적 프로그래밍 표현을 위해 나씨-슈나이더만(Nassi-Shneiderman) 차트 사용
- 논리의 기술에 중점을 둔 도형식 표현 방법
- 연속, 선택, 및 다중 선택, 반복 등의 제어 논리 구조로 표현
- 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합
- 정보공학 방법론(Information Engineering Development)
- 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론
- 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론
- 객체지향 방법론(Object-Oriented Development)
- '객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론
- 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론
- 객체, 클래스, 메시지를 사용
- 컴포넌트 기반 방법론(CBD; Component Based Development)
- 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램을 작성하는 방법론
- 개발 기간 단축으로 인한 생산성 향상
- 새로운 기능 추가 쉬움(확장성)
- 소프트웨어 재사용이 가능
- 애자일 방법론(Agile Development)
- 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
- 애자일은 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론
- 제품 계열 방법론(Product Line Development)
- 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론
- 임베디드 소프트웨어를 작성하는 데 유용한 방법론
- 영역 공학과 응용 공학으로 구분
- 영역 공학: 영역 분석, 영역 설계, 핵심 자산을 구현하는 영역
- 응용 공학: 제품 요구분석, 제품 설계, 제품을 구현하는 영역
애자일(Agile)
- 애자일(Agile) 방법론의 개념
- 애자일 방법론은 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론이다
- 개발 기간이 짧고 신속하며, 폭포수 모형에 대비되는 방법론으로 개발과 함께 즉시 피드백을 받아서 유동적으로 개발할 수 있다
- 애자일 방법론 등장 배경
- 기존 개발 방법론의 한계를 극복하기 위해 등장했다
- 소프트웨어 개발 환경의 변화
- 소프트웨어 개발 트렌드가 모바일 환경으로 변화
- 시장 적시성과 잦은 배포의 중요성 부각
- 기존 개발 방법론의 한계
- 전통적 방법론은 문서 및 절차 위주로 변화에 신속한 대응이 어려움
- 빠르게 적용하고 효율적으로 개발할 수 있는 방법론의 필요성 증가
- 애자일 방법론의 유형
- XP(eXtreme Programming)
- 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
- 1~3주의 반복(Iteration) 개발주기
- XP의 5가지 가치
- 용기(Courage): 용기를 가지고 자신감 있게 개발(코드를 작성하기 전에 테스트, 빠르게 피드백, 테스트에 부합하지 못하는 코드를 리팩토링할 수 있는 용기)
- 단순성(Simplicity): 필요한 것만 하고 그 이상의 것들은 하지 않음
- 의사소통(Communication): 개발자, 관리자, 고객 간의 원활한 소통
- 피드백(Feedback): 의사소통에 대한 빠른 피드백
- 존중(Respect): 팀원 간의 상호 존중
- XP의 12가지 기본원리
- 짝 프로그래밍(Pair Programming): 개발자 둘이서 짝으로 코딩하는 원리
- 공동 코드 소유(Collective Ownership): 시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리
- 지속적인 통합(CI; Continuous Integration): 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리
- 계획 세우기(Planning Process): 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리
- 작은 릴리즈(Small Release): 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리
- 메타포어(Metaphor): 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 한다는 원리
- 간단한 디자인(Simple Desing): 현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리
- 테스트 기반 개발(TDD; Test Driven Develop): 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리
- 리팩토링(Refactoring): 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템 재구성한다는 원리
- 40시간 작업(40-Hour Work): 개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상을 일하지 말아야 한다는 원리
- 고객 상주(On Site Customer): 개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리
- 코드 표준(Coding Standard): 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리
- 스크럼(Scrum)
- 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론
- 백로그(Backlog)
- 스프린트(Sprint)
- 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상
- 스크럼 미팅(Scrum Meeting)
- 매일 15분 정도 미팅으로 To-Do List 계획수립
- 데일리 미팅(Daily Meeting)이라고도 함
- 스크럼 마스터(Scrum Master)
- 프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람
- 스프린트 회고(Sprint Retrospective)
- 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록
- 해당 스프린트가 끝난 시점이나 일정 주기로 시행
- 번 다운 차트(Burn Down Chart)
- 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트
- 백로그는 보통 수직축에 위치하며 시간은 수평축에 위치
- 린(LEAN)
- 도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론
- JIT(Just In Time), 칸반(Kanban) 보드 사용
- 7가지 원칙: 낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화
- 애자일과 전통적 방법론 비교
| 비교 대상 | 애자일 방법론 | 전통적 방법론 |
|---|
| 계획수립 | 유동적 범위 설정 | 확정적 범위 설정 |
| 업무수행 | 팀 중심 업무 수행 | 관리자 주도적 명령과 통제 개인 단위로 업무 수행 |
| 개발/검증 | 반복 주기 단위로 소프트웨어를 개발/검증 | 분석/설계/구현/테스트를 순차적으로 수행 |
| 팀관리 | 업무 돌입, 팀 평가 | 경쟁, 개별 평가 |
| 문서화 | 문서화보다는 코드를 강조 | 상세한 문서화를 강조 |
| 성공요소 | 고객 가치 전달 | 계획/일정 준수 |
| 유형 | XP, 스크럼, 린 | 폭포수, 프로토타입 나선형 |
(3) 객체 지향 분석 방법론
객체 지향 분석의 개념
- 객체 지향 분석(OOA; Object Oriented Analysis)은 사용자의 요구사항을 분석하여 요구된 문제와 관련된 모든 클래스(객체), 속성과 연산, 관계를 정의하여 모델링하는 기법이다
객체 지향 분석 방법론 종류
- OOSE(Object Oriented Software Engineering)-야콥슨(Jacobson)
- 유스케이스에 의한 접근 방법으로 유스케이스를 모든 모델의 근간으로 활용되는 방법론
- 분석, 설계, 구현 단계로 구성
- 기능적 요구사항 중심의 시스템
- OMT(Object Modeling Technology)-럼바우(Rumbaugh)
- 그래픽 표기법을 이용하여 소프트웨어 구성요소를 모델링하는 방법론
- 분석 절차는 객체 모델링->동적 모델링->기능 모델링 순서로 진행
- 객체 모델링(Object Modeling)
- 정보 모델링(Information Modeling)이라고도 함
- 시스템에서 요구하는 객체를 찾고 객체들 간의 관계를 정의하여 ER 다이어그램을 만드는 과정까지의 모델링
- 객체 다이어그램을 활용하여 표현
- 동적 모델링(Dynamic Modeling)
- 시간의 흐름에 따라 객체들 사이의 제어 흐름, 동작 순서 등의 동적인 행위를 표현하는 모델링
- 상태 다이어그램을 활용하여 표현
- 기능 모델링(Functional Modeling)
- 프로세스들의 자료 흐름을 중심으로 처리 과정 표현하는 모델링
- 자료 흐름도(DFD)를 활용하여 표현
- OOD(Object Oriented Design)-부치(Booch)
- 설계 문서화를 강조하여 다이어그램 중심으로 개발하는 방법론
- 분석과 설계의 분리가 불가능
- 분석하는 데 이용된 객체 모델의 설계 시 적용
2. 비용산정, 일정관리 모형
(1) 비용산정 모형
비용산정 모형 개념
- 비용산정 모형은 소프트웨어 규모파악을 통한 투입자원, 소요시간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 방식이다
비용산정 모형 분류
| 분류 | 설명 | 종류 |
|---|
| 하향식 선정방법 | 경험이 많은 전문가에게 비용 산정을 의뢰하거나 여러 전문가와 조정자를 통해 산정하는 방식 | 전문가 판단 델파이 기법 |
| 상향식 산정방법 | 세부적인 요구사항과 기능에 따라 필요한 비용을 계산하는 방식 | 코드 라인 수(Loc) Man Month COCOMO 모형 푸트남 모형 기능점수(FP) 모형 |
비용산정 모형 종류
- LoC(Lines of Code) 모형
- LoC 모형은 소프트웨어 각 기능의 원시 코드 라인 수의 낙관치, 중간치, 비관치를 측정하여 예측치를 구하고 이를 이용하여 비용을 산정하는 방식이다
- 측정이 쉽고 이해하기 쉬워 많이 사용한다
- 예측치를 이용하여 생산성, 노력, 개발 기간 등의 비용을 산정한다
- Man Month 모형
- Man Month 모형은 한 사람이 1개월 동안 할 수 있는 일의 양을 기준으로 프로젝트 비용을 산정하는 방식이다
- COCOMO(COnstructive COst MOdel) 모형
- COCOMO 모형은 보헴(Bohem)이 제안한 모형으로 프로그램 규모에 따라 비용을 산정하는 방식이다
- 비용산정 결과는 프로젝트를 완성하는 데 필요한 노력(Man-Month)으로 산정한다
- 비용 견적의 강도 분석 및 비용 견적의 유연성이 높아 소프트웨어 개발비 견적에 널리 통용된다
- 규모에 따라 유형이 조직형(=기본형, 단순형), 반 분리형, 임베디드형으로 나뉜다
- 조직형(Organic Mode)
- 기관 내부에서 개발된 중소규모의 소프트웨어로 일괄 자료 처리나 과학 기술 계산용, 비즈니스 자료 처리 개발에 적용
- 5만(50KDSI)라인 이하의 소프트웨어를 개발하는 유형
- 반분리형(Semi-Detached Mode)
- 단순형과 임베디드형의 중간형
- 트랜잭션 처리 시스템이나, 데이터베이스 관리 시스템, 컴파일러, 인터프리터와 같은 유틸 개발에 적용
- 30만(300KDSI) 라인 이하의 소프트웨어를 개발하는 유형
- 임베디드형(Embedded Mode)
- 초대형 규모의 트랜잭션 처리 시스템이나 운영체제, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적용
- 30만(300KDSI) 라인 이상의 소프트웨어를 개발하는 유형
- 푸트남(Putnam) 모형
- 푸트남 모형은 소프트웨어 개발주기의 단계별로 요구할 인력의 분포를 가정하는 방식이다
- 푸트남이 제안한 것으로 생명주기 예측 모형이라고 한다
- 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 한다
- 기능점수(FP; Function Point) 모형
- 기능점수 모형은 요구 기능을 증가시키는 인자별로 가중치를 부여하고, 요인별 가중치를 합산하여 총 기능의 점수를 계산하여 비용을 산정하는 방식이다
- 경험을 바탕으로 단순, 보통, 복잡한 정도에 따라 가중치를 부여한다
(2) 일정관리 모델
일정관리 모델 개념
- 일정관리 모델은 프로젝트가 일정 기한 내에 적절하게 완료될 수 있도록 관리하는 모델이다
일정관리 모델 종류
- 주 공정법(CPM; Critical Path Method)
- 여러 작업의 수행 순서가 얽혀 있는 프로젝트의 일정을 계산하는 기법
- 모든 자원 제약사항을 배제한 상태로 프로젝트의 시작과 끝을 나타내는 노드(Node)와 노드 간을 연결을 통해 공정을 계산하기 위한 액티비티(Activity) 표기법
- PERT(Program Evaluation and Review Technique)
- 일의 순서를 계획적으로 정리하기 위한 수렴 기법으로 비관치, 중간치, 낙관치의 3점 추정방식을 통해 일정을 관리하는 기법
- 중요 연쇄 프로젝트 관리(CCPM; Critical Chain Project Management)
- 주 공정 연쇄법으로 자원제약사항을 고려하여 일정을 작성하는 기법
