15주차 [ETC] 폭포수 방법론과 애자일 방법론

ETC/CI, CD란.md

@@ -0,0 +1,62 @@
+# CI/CD란
+
+## 요약
+
+> 애플리케이션의 개발 단계를 자동화하여 짧은 주기로 고객에게 애플리케이션을 제공하는 방법
+
+## CI/CD가 나온 배경
+
+- 모든 개발이 끝난 이후에 코드 품질을 관리하는 고전적 방식의 단점을 해소하기위해 나타난 개념
+- 분업과 협업의 과정에서 코드의 Merge 과정은 까다롭고, 테스트하는데 큰 자원을 소비되게 된다. 이 문제를 해결하기 위해 도입
+- 개발 브랜치가 일정 기간 이상 이용되면, 통합의 어려움은 커지고 충돌 해결에 들어가는 시간이 길어지고 오류 발생 위험이 커진다.<br/>이러한 단점을 극복하고자 변동 내용의 반영 빈도를 늘리는 **자동화**가 등장
+
+## CI의 정의
+
+- **지속적인 통합(Continuous Integration)**
+- 어플리케이션의 **새로운 코드 변경 사항**이 정기적으로 **빌드 및 자동 테스트** 되어 공유 레포지토리에 **통합(병합)**하는 것
+- 개발자를 위한 자동화 프로세스(여러명의 개발자간의 코드 충돌을 방지하기 위한 목적)
+- 자동화된 테스트에서 **동작을 확인**하고 변경으로 인해 문제가 생기는 부분이 발견되면 CI를 통해 빠르게 수정 가능
+- 버그를 신속히 찾아 해결하고 소프트웨어 품질 개선, 새로운 업데이트의 검증 및 릴리즈 시간 단축시키는 것이 핵심 목표
+
+### CI를 만드는 데 필요한 4가지 규칙
+
+- 모든 소스 코드가 있고 누구나 현재 소스(및 이전 버전)를 얻을 수 있는 단일 장소 유지할 것
+- 누구나 단일 명령을 사용하여 소스에서 시스템을 빌드할 수 있도록 빌드 프로세스를 자동화 할 것
+
+- 단일 명령으로 언제든지 시스템에서 우수한 테스트 모음을 실행할 수 있도록 테스트 자동화할 것
+- 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것
+
+> 이 중 가장 중요한 것이 **테스팅 자동화**!!<br/>지속적인 통합을 하기 위해서는 무엇보다 이 프로젝트가 완전한 상태임을 보장하기 위해 테스트 코드가 구현되어 있어야만 한다.
+
+## CD의 정의
+
+- **지속적인 서비스제공(Continuous Delivery)** or **지속적인 배포(Continuous Deployment)**
+  - **지속적인 서비스제공(Continuous Delivery)**
+    - 공유 레포지토리로 자동으로 Release 하는 것
+    - 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포 가능 (**수동적 배포**)
+    - 프로덕션 환경으로 배포할 준비가 되어 있는 **코드베이스를 확보**하는 것이 목표
+  - **지속적인 배포(Continuous Deployment)**
+    - 프로덱션 레벨까지 자동으로 deploy 하는 것
+    - 애플리케이션을 프로덕션으로 릴리스하는 작업을 **자동화**
+    - 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 애플리케이션을 **자동으로 실행**할 수 있는 것을 의미
+- 간단히 말하면 **배포 자동화 과정**
+- 서버가 많을 경우 개발자가 일일이 배포를 진행하지 않아도 되므로, 리소스가 낭비되지 않는다.
+
+![CI/CD flow](https://www.redhat.com/cms/managed-files/styles/wysiwyg_full_width/s3/ci-cd-flow-desktop_edited_0.png?itok=TzgJwj6p)
+
+## CI/CD 종류
+
+- Jenkins
+- CircleCI
+- TravisCI
+- Github Actions
+
+등..
+
+## 참고
+
+- https://www.youtube.com/watch?v=0Emq5FypiMM&t=10s
+
+- https://www.redhat.com/ko/topics/devops/what-is-ci-cd
+- https://devuna.tistory.com/56
+- https://www.martinfowler.com/articles/originalContinuousIntegration.html

ETC/폭포수 방법론과 애자일 방법론.md

@@ -0,0 +1,150 @@
+# 폭포수 방법론과 애자일 방법론
+
+## 소프트웨어 개발 방법론이란?
+
+소프트웨어를 개발하는데 있어 필요한 <u>프로그래밍 개발 과정</u>들을 정리하고 표준화하여 프로그래머들이 프로그래밍 개발과정에서 각 개인이 개발과정에서 <u>일관성을 유지</u>하여 프로젝트의 분야별 **프로그래머들간의 효과적인 협업**이 이루어 질 수 있도록 돕는 방법론을 말한다.
+
+소프트웨어 개발 방법론에서 가장 중요한 내용은 **프로그래머들간의 효과적인 협업**이라고 볼 수 있으며 대표적으로 **WaterFall 방법론, Agile 방법론**이 있다. 
+
+## 1️⃣ 폭포수(Waterfall) 방법론이란?
+
+### 정의
+
+- 마치 폭포수처럼 물이 위에서 아래로 흐르는 것을 빗대어 표현한 방법론
+- **각 단계별 순차적인 진행을 강조하는 방법론**
+- 여러 단계가 병행적으로 진행되거나 **거꾸로 진행되는 경우는 거의 없다.**
+
+### 진행 과정
+
+![폭포수_진행과정](https://upload.wikimedia.org/wikipedia/commons/thumb/e/e2/Waterfall_model.svg/1280px-Waterfall_model.svg.png)
+
+> 그림 출처 : 위키백과
+
+```
+📌 요구사항 분석 → 설계 → 구현 → 검증(테스트) → 운영/유지보수
+```
+
+- **요구사항 분석**<br/>: 고객의 요구조건, 시스템 환경 등 사용자가 원하는 task 이해 및 타당성을 조사하고 SW 기능과 제약조건을 정의하는 명세서 작성하는 단계
+
+- **설계** <br/>: 요구사항 명세서를 바탕으로 이를 세분화함으로써 구현될 수 있는 형태로 전환 (S/W 전체 구조, 구조간 관계, 상세 알고리즘 등)
+
+- **구현** <br/>: 설계단계에서 만들어진 설계서를 바탕으로 직접 코딩하여 S/W를 개발하는 단계
+- **검증(테스트)** <br/>: 완성된 프로그램을 테스트하는 단계(통합테스트, 인수테스트, 시스템테스트 등)
+- **운영/유지보수** <br/>: 시스템의 사용 중 발생하는 여러 변경사항에 대해 적응하고 변화에 대비하는 과정
+
+### 장점
+
+```
+📌 사용 및 관리 용이, 이해하기 쉬움
+```
+
+- 고전적인 방법론으로써 **적용 사례가 풍부**하다.
+- 단계별로 진행되기 때문에 현재 단계에 대한 **이해가 빠르고 쉽다.**
+- 각 진행 단계별 **문서를 작성**하기 때문에 진행 중 및 진행 이후에도 **전체 과정에 대한 이해와 관리가 쉽다.**
+- 단계별로 정형화된 접근방식을 이용하기 때문에 **기술적인 위험요소가 적다.**
+- 폭포수의 모든 단계에는 시작과 끝이 존재한다. 이해 관계자 및 고객과 진행 상황을 쉽게 공유할 수 있다.
+
+### 단점
+
+```
+📌 하향식 접근, 피드백에 대한 빠른 대응 어려움
+```
+
+- 전 단계의 작업이 모두 완료되어야 다음 진행이 가능하다.
+- 요구사항을 완벽하게 작성해야 한다.
+
+- 고객요구 사항은 프로젝트가 진행됨에 따라 변경될 수 있는데, 이에 맞춰서 즉각적인 수정이 어렵고 큰 비용이 든다.
+- 테스트 단계에 발견된 중요 결함에 대한 대응이 어렵다.
+
+### 언제 사용하면 좋을까?
+
+- 고객의 요구상이 단순하고 변경 가능성이 높지 않을 때
+- 프로젝트의 규모와 난이도가 높지 않을 때
+- 요구사항이 비교적 명확하게 정의되어 있을 때
+
+## 2️⃣ 애자일(Agile) 방법론이란?
+
+### 배경
+
+90년대 이후 트렌드가 급격하게 빨리 변화하는 시대가 되면서, 비즈니스 사이클(제품 수명)이 짧아지고 SW 개발의 불확실성이 높아지게 되었다. 개발의 불확실성이 높아짐에 따라, 전통적 방법론이 더이상 맞지 않다는 것을 느낀 사람들은 새로운 자신만의 SW 개발 방법을 구축해 사용하게 된다. 
+
+즉, **경량 방법론 주의자**들은 일단 해보고 고쳐나가자는 방식으로 개발하게 되었다. 이런 경량 방법론 주의자들이 모여 자신들이 사용하는 개발 방법론을 공유하고, 공통점을 추려서 애자일이라는 용어에 의미가 담기게 된 것이다.
+
+> 경량 방법론 : 규칙이 적고 가볍게 대응을 잘하는 방법
+
+그리고 2001년 경량 방법론 주의자 17명이 만나면서 서로 간에 추구하는 관점의 공통점을 추려서 '**애자일 SW 개발 선언문**'을 만들게 되었다. 이때부터 애자일이라는 용어에 의미가 담기게 되었다.
+
+> [애자일 소프트웨어 개발 선언](https://agilemanifesto.org/iso/ko/manifesto.html)
+
+### 정의
+
+- 폭포수 방법론과 다르게 소프트웨어 개발 단계를 **명확하게 구분하지 않고 각 단계를 반복적으로 수행**하면서 진행
+- 이때 요구사항을 추가하거나 제외하면서 소프트웨어 개발 진행
+- 즉, **변화하는 상황에 맞게 유연하게 대응하는 방법론**
+- 특히 애자일 방법론 종류는 현재 40여 가지가 넘지만 애자일 기업 중 73%가 **스크럼(Scrum) 방식**을 사용하고 있다. (ex. Spotify, Riot, Amazon 등)
+
+### 특징
+
+- 절차와 도구보다 **개인과 소통을 중요**하게 생각한다.
+- 문서화보다는 **소프트웨어가 잘 실행**되는데 가치를 둔다.
+- 계획보다는 **효과적인 변경 대응에 중점**을 둔다.
+- 고객과의 **피드백을 중요**하게 생각한다.
+
+### 스크럼(Scrum)
+
+![img](https://upload.wikimedia.org/wikipedia/commons/thumb/5/58/Scrum_process.svg/1920px-Scrum_process.svg.png)
+
+> 그림 출처 : 위키백과
+
+- **제품 백로그(Product Backlog)** <br/>: 개발할 제품에 대한 요구 사항 목록. 우선순위로 관리
+- **스프린트 백로그(Sprint Backlog)**<br/>: 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록
+- **스프린트(Sprint)**<br/>: 계획, 개발, 리뷰 작업 등 최소 단위의 반복적 개발 주기. 보통 1~4주 단위에서 선택
+- **일일 스크럼 회의(Daily Scrum Meeting)**<br/>: 매일 15분 정도 진행되는 미팅 (어제 한일, 오늘 할일, 오류 등을 공유)
+- **스프린트 회고(Sprint Retrospective)**<br/>: 스프린트 마지막날 좋았던 점, 개선할 점 도출하고 더 나은 방향으로 개선
+
+### 장점
+
+```
+📌 협력, 빠른 피드백 반영
+```
+
+- 스프린트마다 생산되는 실행 가능한 제품을 통해 **사용자와 의견을 나눌 수 있음**
+- 회의를 통해 **팀원들간 신속한 협조와 조율**이 가능
+- 자신의 일정을 직접 발표함으로써 업무 집중 환경 조성
+- 프로젝트 진행 현황을 통해 신속하게 목표와 결과 추정이 가능하며 **변화 시도가 용이함**
+- 개발하면서 지속적으로 테스트 되기 때문에 개발 초기에 해결 가능
+
+### 단점
+
+```
+📌 체계화된 문서가 적음
+```
+
+- 추가 작업 시간이 필요하다. (스프린트마다 테스트 제품을 만들어야하기 때문)
+- 빈번한 수정으로 개발시 인력들이 느끼는 피로도가 높다
+- 스크럼은 프로젝트 관리에 무게중심을 두기 때문에 프로세스 품질 평에는 미약하다. 
+
+### 언제 사용하면 좋을까?
+
+- 잦은 요구사항 변경이 있을 때
+- 프로젝트의 규모가 커서 요구사항 분석 및 설계를 완벽하게 하기 어려울 때
+
+## 📌 폭포수 vs 애자일
+
+|                     | 폭포수                      | 애자일                                    |
+| ------------------- | --------------------------- | ----------------------------------------- |
+| **요구사항**        | 한 번에 정의                | 지속해서 반영                             |
+| 지향                | 계획 중심                   | 학습 중심                                 |
+| 수직/수평           | 수평적 단계별 개발          | 기능별 수직 개발                          |
+| **고객과 의사소통** | 적음                        | 많음                                      |
+| 진단방법            | 문서화된 진행 사항 진단     | 개발하고 있는 소프트웨어로 진행 사항 진단 |
+| **통합/테스트**     | 마지막 단계에서 통합/테스트 | 지속적인 통합/테스트                      |
+| 릴리즈              | 빅뱅 릴리즈 (자주하지 않음) | 빠른 릴리즈                               |
+
+## 참고
+
+- [폭포수_방법론](http://www.incodom.kr/%ED%8F%AD%ED%8F%AC%EC%88%98_%EB%B0%A9%EB%B2%95%EB%A1%A0)
+- [폭모수 모델 VS 애자일 모델](https://universitytomorrow.com/19)
+- [애자일이란?](https://gmlwjd9405.github.io/2018/05/26/what-is-agile.html)
+- [애자일 스크럼 이해하기](https://medium.com/dtevangelist/scrum-dfc6523a3604)
+- [폭포수와 애자일 주요 10가지 차이점](https://blog.naver.com/p1ngp1ng/120165638207)