Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
Tags
- Shell
- 공부
- Review
- 기록
- 보안용어
- 워게임
- 드림핵
- 자격증공부
- keyword
- 복습
- 클라우드
- 케이쉴드주니어
- webhacking
- 보안
- IT
- 정보처리기사
- study
- reivew
- 웹해킹
- wargame
- 리눅스
- it자격증
- Linux
- Security
- 정리
- 리눅스마스터2급
- 위험관리
- 자격증
- DreamHack
- 취약점진단
Archives
- Today
- Total
IT Memory Note
[정보처리기사] 요구사항 확인 : 소프트웨어 개발 방법론(1) 본문
1️⃣ 소프트웨어 개발 방법론
☆☆☆
(1) 소프트웨어 생명주기 모델
1. 소프트웨어 생명주기(SDLC, Software Development Life Cycle) 모델 개념
- 시스템의 요구분석부터 유지보수까지 전 공정을 계획한 절차
- 시스템이 개발될 때부터 운용과 유지보수를 거쳐 생애를 마칠 때까지 어떠한 순서를 밟는지에 대한 작업 프로세스를 모델화한 것
2. 소프트웨어 생명주기 모델 프로세스
순서 | 프로세스 | 설명 | 활동 |
1 | 요구사항 분석 | • 다양한 분석 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계 • 개발할 소프트웨어의 기능과 제약 조건, 목표 등을 소프트웨어 사용자와 함께 명확히 정의하는 단계 |
• 기능 요구사항 • 비기능 요구사항 |
2 | 설계 | 시스템 명세 단계에서 정의한 기능을 실제 수행할 수 있도록 수행 방법을 논리적으로 결정하는 단계 |
• 시스템 구조 설계 • 프로그램 설계 • 사용자 인터페이스 설계 |
3 | 구현 | • 설계 단계에서 논리적으로 결정한 문제 해결 방법을 특정 프로그래밍 언어를 사용하여 실제 프로그램을 작성하는 단계 • 프로그래밍 언어 선택, 기법, 스타일, 순서 등을 결정하는 단계 |
• 인터페이스 개발 자료 • 자료 구조 개발 • 오류 처리 |
4 | 테스트 | 시스템이 정해진 요구를 만족하는지, 예상과 실제 결과가 어떤 차이를 보이는지 검사하고 평가하는 단계 | • 단위 테스트 • 통합 테스트 • 시스템 테스트 • 인수 테스트 |
5 | 유지보수 | 시스템이 인수되고 설치된 후 일어나는 모든 활동 | 예방, 완전, 교정, 적용 유지보수 |
3. 소프트웨어 생명주기 모델 종류
종류 | 설명 |
폭포수 모델 (Waterfall Model) |
• 소프트웨어 개발 시 각 단계를 확실히 마무리 지은 후에 다음 단계로 넘어가는 모델 • 모형의 적용 경험과 성공 사례가 많음 • 단계별 정의와 산출물이 명확 • 가장 오래된 모델로, 선형 순차적 모형이며 고전적 생명주기 모형이라고도 함 • 절차 : 타당성 검토 → 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수 |
프로토타이핑 모델 (Prototyping Model) |
고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 반영하여 소프트웨어를 만들어가는 모델 |
나선형 모델 (Spiral Model) |
• 시스템 개발 시 위험을 최소화하기 위해 점진적으로 완벽한 시스템으로 개발해 나가는 모델 • 절차 : 계획 및 정의 → 위험 분석 → 개발 → 고객 평가 |
반복(점진)적 모델 (Iteration Model) |
• 구축 대상을 나누어 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 점증 완성시키는 SDLC 모델 • 사용자 요구사항 일부분 혹은 제품 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델 |
< 소프트웨어 생명주기 모델 간 비교 >
구분 | 폭포수 모델 | 프로토타이핑 모델 | 나선형 모델 | 반복(점진)적 모델 |
절차도 | 요구사항 분석 ↓ 설계 ↓ 구현 ↓ 테스트 |
요구사항 분석 ← ↓ ⎟ 프로토타입 개발 ⎟ ↓ ⎟ 프로토타입 평가 ⏌ ↓ 구현 ↓ 테스트 |
계획 및 정의 ← ↓ ⎟ 위험 분석 ⎟ ↓ ⎟ 개발 ⎟ ↓ ⎟ 고객평가 ⏌ |
▶︎ 분석 → 설계 → 구현 개발대상 ▶︎ 분석 → 설계 → 구현 ▶︎ 분석 → 설계 → 구현 |
특징 | 순차적 접근 | 프로토타입 개발 | 위험분석, 반복 개발 | 증분방식으로 병행 개발 |
장점 | 이해하기 쉬움, 관리가 편함 | 요구분석 용이, 타당성 검증 가능 | 위험성 감소와 변경에 유연한 대처 | 병행 개발로 인한 일정 단축 가능 |
단점 | 요구사항 변경이 어려움 | 프로토타입 폐기에 따른 비용 증가 | 단계 반복에 따른 관리가 어려움 | 병행 개발에 따른 관리 비용 증가 |
(2) 소프트웨어 개발 방법론
1. 소프트웨어 개발 방법론(Software Development Methodology) 개념
- 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법
- 소프트웨어를 하나의 생명체로 간주하고 소프트웨어 개발의 시작부터 시스템을 사용하지 않는 과정까지의 전 과정을 형상화한 방법론
2. 소프트웨어 개발 방법론 종류
종류 | 설명 |
구조적 방법론 (Structured Development) |
• 전체 시스템을 기능에 따라 나누어 개발하고, 이를 통합하는 분할과 정복 접근 방식의 방법론 • 프로세스 중심의 하향식 방법론 • 구조적 프로그래밍 표현을 위해 나씨-슈나이더만(Nassi-Shneiderman) 차트 • 나씨-슈나이더만 차트의 특징 - 논리의 기술에 중점을 둔 도형식 표현법 - 연속, 선택 및 다중 선택, 반복 등의 제어 논리 구조로 표현 - 조건이 복합되어 있는 곳의 처리를 시각적으로 명확히 식별하는 데 적합 |
정보공학 방법론 (Information Engineering Development) |
• 정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론 • 개발주기를 이용해 대형 프로젝트를 수행하는 체계적인 방법론 |
객체 지향 방법론 (Object-Oriented Development) |
• '객체'라는 기본 단위로 시스템을 분석 및 설계하는 방법론 • 복잡한 현실 세계를 사람이 이해하는 방식으로 시스템에 적용하는 방법론 • 객체, 클래스, 메시지를 사용 |
컴포넌트 기반 방법론 (CBD, Component Based Development) |
• 소프트웨어를 구성하는 컴포넌트를 조립해서 하나의 새로운 응용 프로그램으로 작성하는 방법론 • 개발 기간 단축으로 인한 생산성 향상 • 새로운 기능 추가 쉬움(확장성) • 소프트웨어 재사용이 가능 |
애자일 방법론 (Agile Development) |
• 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응함녀서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론 • 애자일은 개발 과정의 어려움을 극복하기 위해 적극적으로 모색한 방법론 |
제품 계열 방법론 (Product Line Development) |
• 특정 제품에 적용하고 싶은 공통된 기능을 정의하여 개발하는 방법론 • 임베디드 소프트웨어를 작성하는 데 유용한 방법론 |
※ 컴포넌트(Component) : 모듈화된 소프트웨어 시스템의 구성 요소
3. 애자일(Agile)
⓵ 애자일 방법론의 개념
- 절차보다는 사람이 중심이 되어 변화에 유연하고 신속하게 적응하면서 효율적으로 시스템을 개발할 수 있는 신속 적응적 경량 개발 방법론
- 개발 기간이 짧고 신속하며, 폭포수 모형에 대비되는 방법론으로 개발과 함께 즉시 피드백을 받아서 유동적으로 개발할 수 있음
⓶ 애자일 방법론 등장 배경
등장 배경 | 설명 |
소프트웨어 개발 환경의 변화 | • 소프트웨어 개발 트렌드가 모바일 환경으로 변화 • 시장 적시성과 잦은 배포의 중요성 부각 |
기존 개발 방법론의 한계 | • 전통적 방법론은 문서 및 절차 위주로 변화에 신속한 대응이 어려움 • 빠르게 적응하고 효율적으로 개발할 수 있는 방법론의 필요성 증가 |
⓷ 애자일 방법론의 유형
종류 | 내용 |
XP (eXtreme Programming) |
• 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론 • 1~3주의 반복(Iteration) 개발주기 • 5가지 가치와 12개의 실천 항목이 존재 < XP의 5가지 가치 > - 용기(Courage) : 용기를 가지고 자신감 있게 개발(코드를 작성하기 전에 테스트, 빠르게 피드백, 테스트에 부합하지 못하는 코드를 리팩토링할 수 있는 용기) - 단순성(Simplicity) : 필요한 것만 하고 그 이상의 것들은 하지 않음 - 의사소통(Communication) : 개발자, 관리자, 고객 간의 원활한 소통 - 피드백(Feedback) : 의사소통에 대한 빠른 피드백 - 존중(Respect) : 팀원 간의 상호 존중 < XP의 12가지 기본원리 > - 짝 프로그래밍(Pair Programming) : 개발자 둘이서 짝으로 코딩하는 원리 - 공동 코드 소유(Collective Ownership) : 시스템에 있는 코드는 누구든지 언제라도 수정 가능하다는 원리 - 지속적인 통합(CI, Continuous Integration) : 매일 여러 번씩 소프트웨어를 통합하고 빌드해야 한다는 원리 - 계획 세우기(Planning Process) : 고객이 요구하는 비즈니스 가치를 정의하고, 개발자가 필요한 것은 무엇이며 어떤 부분에서 지연될 수 있는지를 알려주어야 한다는 원리 - 작은 릴리즈(Small Release) : 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다는 원리 - 메타포어(Metaphor) : 공통적인 이름 체계와 시스템 서술서를 통해 고객과 개발자 간의 의사소통을 원활하게 하는 원리 - 간단한 디자인(Simple Design) : 현재의 요구사항에 적합한 가장 단순한 시스템을 설계한다는 원리 - 테스트 기반 개발(TDD, Test Driven Development) : 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리 - 리팩토링(Refactoring) : 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 통해 시스템을 재구성한다는 원리 - 40시간 작업(40Hour Work) : 개발자가 피곤으로 인해 실수하지 않도록 일주일에 40시간 이상을 일하지 말아야 한다는 원리 - 고객 상주(On Site Customer) : 개발자들의 질문에 즉각 대답해 줄 있는 고객을 프로젝트에 풀타임으로 상주시켜야 한다는 원리 - 코드 표준(Coding Standard) : 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다는 원리 |
스크럼 (Scrum) |
• 매일 정해진 시간, 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심 방법론 < 스크럼의 구성 > - 백로그(Backlog) : 제품과 프로젝트에 대한 요구사항 - 스프린트(Sprint) : 2~4주의 짧은 개발 기간으로 반복적 수행으로 개발품질 향상 - 스크럼 미팅(Scrum Meeting) : 매일 15분 정도 미팅으로 To-Do List 계획을 수립하며, 데일리 미팅이라고도 함 - 스크럼 마스터(Scrum Master) : 프로젝트 리더, 스크럼 수행 시 문제를 인지 및 해결하는 사람 - 스프린트 회고(Sprint Retrospective) : 스프린트 주기를 되돌아보며 정해놓은 규칙 준수 여부, 개선점 등을 확인 및 기록하며, 해당 스프린트가 끝난 시점이나 일정 주기로 시행함 - 번 다운 차트(Burn Down Chart) : 남아있는 백로그 대비 시간을 그래픽적으로 표현한 차트이며, 백로그는 보통 수직축에 위치하고 시간은 수평축에 위치함 |
린 (Lean) |
• 도요타의 린 시스템 품질 기법을 소프트웨어 개발 프로세스에 적용해서 낭비 요소를 제거하여 품질을 향상시킨 방법론 • JIT(Just In Time), 칸반(Kanban) 보드 사용 |
※ 스크럼의 프로세스 : 백로그를 나눈 후에 스크럼 팀을 구성하고, 스프린트 회의를 거쳐 2~4주 단위의 스프린트를 수행함 수행 중 매일 스크럼 미팅을 수행하고, 스프린트가 끝난 후에는 스프린트 회고를 수행함
⓸ 애자일과 전통적 방법론 비교
비교 대상 | 애자일 방법론 | 전통적 방법론 |
계획 수립 | 유동적 범위 설정 | 확장적 범위 설정 |
업무 수행 | 팀 중심 업무 수행 | 관리자 주도적 명령과 통제 개인 단위로 업무 수행 |
개발/검증 | 반복 주기 단위로 소프트웨어를 개발/검증 | 분석/설계/구현/테스트를 순차적으로 수행 |
팀 관리 | 업무 몰입, 팀 평가 | 경쟁, 개별 평가 |
문서화 | 문서화보다는 코드를 강조 | 상세한 문서화를 강조 |
성공요소 | 고객 가치 전달 | 계획/일정 준수 |
유형 | XP, 스크럼, 린 | 폭포수, 프로토타입, 나선형 |
'자격증 > 정보처리기사' 카테고리의 다른 글
[정보처리기사] 화면 설계 : UI 요구사항 확인(1) (1) | 2024.01.30 |
---|---|
[정보처리기사] 요구사항 확인 : 현행 시스템 분석(2) (0) | 2024.01.30 |
[정보처리기사] 요구사항 확인 : 현행 시스템 분석(1) (0) | 2024.01.29 |
[정보처리기사] 요구사항 확인 : 소프트웨어 개발 방법론(3) (1) | 2024.01.27 |
[정보처리기사] 요구사항 확인 : 소프트웨어 개발 방법론(2) (0) | 2024.01.26 |