※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※
1. RAD
정의
- Rapid Application Development의 약자로, 앱(프로젝트)의 빠른 개발을 위한 모델로, 사용자의 지속적 참여하에 빠르게 프로그램을 개발하기 위한 개발 라이프 사이클 모델.
- waterfall 모델과는 정반대로 사용자(고객)의 지속적 참여하에 빠르게 application을 개발하는것이 목표
- 사용자가 지속해서 참여하기 때문에 사용자는 개발 과정에서 지속적인 피드백을 전달하고, 개발자는 이러한 피드백을 개발과정에서 반영하여 지속적으로 개선
- 개발자는 빠른 개발을 위해 app의 자동 생성 도구를 사용하여 개발
특징
- 고객 참여: 고객의 요구사항 정의, 분석, 설계
- 신속개발: 기술위험 적음
- 짧은 개발주기: 코드 재사용 및 자동 생성 도구
RAD vs Waterfall
| RAD | Waterfall | |
| waiting time | short | long |
| Risk | low | high |
| Budget | not fixed | fixed |
| approach to change | anytime | not welcome |
| quality control | throughout the development process | at the end of the development process |
| high techical application | Not appropriate | Appropriate |
| not for end user | no | yes |
자동화 툴의 예시
• https://www.zoho.com/creator/apps/seat-booking.html
2. Lean Startup
정의
- 2011년, 미국 실리콘밸리의 벤처기업가 에릭 리스가 소개한 개념
- 고객이 원하지 않는 제품을 만드는 것이 스타트업의 가장 큰 위험
특성
- 아이디어를 빠르게 제품화시킨 후 고객의 피드백을 반영하여 개선
- 아이디어의 제품화 → 완벽한 제품 X, 제품화 시키는 과정에서 피드백 지속 반영, 결과적으로 시장이 원하는 제품을 만드는 전략
- startup : 불확실성 환경 시장에서 신규 서비스, 제품을 만들고자 하는 조직
프로세스
- MVP (Minimun Viable Product, 최소 기능 제품) : 아이디어를 빠르게 제품화시키긴 위해선, 처음부터 완벽한 제품을 만드는 것이 아닌, 고객의 반응이나 피드백이 가능할 만큼의 아이디어의 핵심을 구현하는 제품
- MVP
- 반드시 기능적으로 실제 동작하는 제품일 필요는 없다
- ex) DropBox의 MVP는 2~3분짜리의 제품 설명 동영상이었다. 앞으로 개발할 제품에 담길 기능을 설명(https://www.youtube.com/watch?v=xy9nSnalvPc)
지속적 프로세스
- 가설을 실험, 학습, 검증하는 것은 지속적인 과정
- ex) 가설 예시: 호텔 예약 사이트에 방의 세부 사진을 볼 수 있게 하는 것은 예약율을 30% 높일 수 있다
- 경우에 따라 학습한 내용을 바탕으로 완전히 새로운 제품으로 방향전환(pivot)도 가능
3. Agile
개요
- 점진적 개발: 이전 시스템에 새로운 요구사항 추가하여 개발
- 반복적 개발: 이전 시스템을 한번에 완전하게 개발하는 것이 아닌, 반복적으로 개선 및 수정
- 불확실성
- 프로젝트 초기에 불확실성을 제거하는 것은 불가능. 불확실성을 줄이는 좋은 방법은 제품을 고객에게 보여주고, 피드백을 받아 이를 다음 제품에 반영하는 것
- 이를 통해 어떻게 제품을 만드는 것이 좋은 방법인지 학습할 수 있다.
폭포수 모델(전통적 모델) vs Agile
- 폭포수 모델
- value delivered: 결과물이 프로젝트가 끝나는 단계에서만 나온다. 따라서 맨 마지막에만 높게 나온다.
- risk: 초기에 요구사항을 완벽히 분석하고, 이후 어떠한 요구사항 변화도 개입되지 않기 때문에(힘들기 때문에) 시간이 지날수록 변화하거나 새로운 요구사항이 쌓일 것이고, 이는 risk의 증가로 나타난다
- Agile
- value delivered: 이터레이션을 통해 점진적/반복적 개발을 수행하기 때문에, 여러번, 그리고 점점 증가하는 추세를 보인다
- risk: 초기에 요구사항을 모두 제거하는 것은 불가능하다. 하지만 지속적인 피드백을 수렴하면서 점점 사용자가 원하는 제품을 만들기 때문에, risk는 점점 감소한다.
Agile의 종류
- XP (익스트림 프로그래밍)
- 익스트림 모델링
- Scrum
- 크리스털 패밀리
- Feature-driven Development
- Adative software Development
애자일 프로세스
- IID (iterative and incremental development)
- 반복적 + 점진적 개발
- 소프트웨어 개발 주기를 여러개의 반복(iteration) 주기로 구분
- 각 반복 주기에서는 요구 분석, 설계, 구현, 테스트같은 활동으로 구성되는 소규모 프로젝트.
- 각 반복주기가 종료되면 부분적으로 완성된 시스템 산출
- 부분 산출된 시스템은 내부 개발자가 관리. 사용자에게 외부적으로 배포하는 산출물은 최종 반복주기의 산출물
- 개발 주기 : 1~4주. 각 반복마다 새로운 요구사항 추가, 개발
- 각 반복주기에서 요구사항은 고객이 각 반복 주기 시작 전에 요구. 더 높은 비즈니스 가치를 지닌 요구사항에 우선순위 부여
- 따라서 자주 바뀔 수 있는 요구사항을 탄력적으로 처리할 수 있음
- iteration 진행시에는 요구사항 변경 받아들이지 않음
애자일 원칙
https://agilemanifesto.org/iso/ko/principles.html
애자일 선언 이면의 원칙
우리는 다음 원칙을 따른다: 우리의 최우선 순위는, 가치 있는 소프트웨어를일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다. 비록 개발의 후반부일지라도 요구사항 변경을 환영하
agilemanifesto.org
4. DevOps
개요
- Development & Operations
- Patrick Debois는 2009년 개발과 운영의 단절로 인한 문제를 해결하고자 'DevOpsDays'라는 컨퍼런스를 주최하면서 'DevOps' 단어가 등장
- 개발 팀과 운용 팀이 긴밀히 협업 + 연계 → 비즈니스 요구에 신속히 대응하여 소프트웨어 개발 및 배포
- 배포된 소프트웨어가 운영환경에서 안정적으로 동작하도록 하여 비즈니스 가치 실현ro
개발 vs 운영
- 개발: 비즈니스 요구에 맞춰 새로운 기능 추가, 개선, 수정등 요구에 신속한 대응
- 운영: 변화보단 시스템의 안정성
- 개발, 운영 모두 공통의 목적의식(비즈니스 요구에 신속 대응, 안정적 서비스 제공)을 가지고 상호 존중하며 협업하는 문화 형성
DevOps 프로세스
- plan : 요구사항 정의 (무엇을 개발할지 결정)
- code : 구현 & 구현 코드를 commit
- build : commit된 코드가 문제가 없는지 검사한 후, 기존 코드와 통합
- test : 운영환경에 배포할 상태가 되어있는지 테스트(사용자 인수 테스팅, 성능 테스팅 등)
- release : 최종 산출물(binary) 관리
- deploy : 최종 산출물을 실제 운영 환경에 배포
- operate / monitor : 로깅등을 통해 운영 현황 데이터 수집, 분석 후 결과 통지, 다음 개발 계획을 위해 피드백
Waterfall vs Agile vs DevOps
현황
아마존의 경우, 하루에 2.3만번의 배포가 이루어짐(... ㅁㅊ)
CI (Continous Integration)
- 코드의 통합이 프로젝트 종료시점에서 일어남
- 뒤늦은 결함 발견(결함은 빨리 발견할 수록 비용의 감소)
- 오류의 원인 파악 어려움
- 배포 가능한 소프트웨어 부재
- 제품에 대한 자신감 결여
- 여러 개발자가 공통으로 작업하는 경우, 각 개발자의 작업을 개발 초기부터 빈번하게 검증 및 통합이 이루어지도록 하는 방법
- 결함의 조기 발견으로 인한 비용 감소(1:10:100)
- 위험 감소
- 품질에 대한 자신감
※ 데브옵스에선 브랜치를 따로 파는걸 추천하지 않는다. merge가 느리게 일어나게 되고, 이는 데브옵스 이념에 맞지 않기 때문
- 1.개발자가 새로운 기능을 추가하거나 오류를 수정하는 등의 작업 내용을 저장소에 반영하기 위해 커밋하는 단계
- 2.통합 서버는 저장소에 코드가 커밋 되었음을 감지하고 빌드 환경에 코드를 다운로드
- 3.코드를 컴파일하고 통합
- 4.단위 테스트 및 코드 리뷰 수행
- 5.테스트 결과를 여러 수단(SMS, Slack, Email 등)을 통해 통지
- 이 모든 과정은 적절한 tool chain으로 자동화됨
CD (Continous Delivery)
- 시스템이 실제 운영 환경에 릴리스 준비가 되어 있는지를 확인
- 이를 위해 다양한 테스트 환경에서 다양한 테스트 수행
테스팅 환경
- (QA) Testing Environment : QA 팀이 테스트하기 위해 사용하는 환경. 복잡하고 시간이 걸리는 테스트를 수행
- Staging Environment : 실제 운영 환경과 동일한 환경. 실제 운영 데이터를 사용하여 (통합된) 시스템을 대상으로 사용자 인수 테스트(UAT)를 포함한 다양한 비기능적 테스트 수행(부하 테스팅, 성능 테스팅, 보안 및 장애 테스트) 등
- Production Environment : 실제 운영 환경이며 Blue-green deployment나 Canary deployment 등의 배포 전략을 사용하여 배포가 이루어진다.
Testing Pyramid
Mike Cohn이 제안
- Unit testing
- 각 컴포넌트가 의도대로 동작하는가?
- 컴포넌트가 의존하는 다른 컴포넌트는 가짜로 대체
- Integration testing
- 일반적으로 컴포넌트와 컴포넌트를 통합하여 실시하는 테스트
- 여기선 시스템이 외부 환경(DB, 파일 시스템, 외부 시스템)과의 통합에 문제가 없는지 의존성 테스트
- E2E testing
- End-to-End testing
- UAT(User Acceptance Test)에 같은 의미로 사용
- 전체 시스템이 통합된 상태에서 사용자 관점에서 테스트
Continous Deployment
Continous Delivery는 실제 운영 환경에 배포할때 사람의 승인이 필요하지만, Continous Deployment는 자동 배포
배포 전략
- Production env로 배포할 때 서비스가 중단되는 시간이 없도록 하는 무중단(zero down time) 배포가 중요
- 배포시 문제가 발생할 때 rollback(예전 버전으로 돌아감) 필요
- 배포전략
- Rolling Update
- Blue green 배포
- Canary
Rolling Update
- 기존 인프라에 구 서비스를 제공하는 서버를 하나씩 순차적으로 대체
- 단점
- 구/신 서비스 혼재
- 새버전 배포시 서버 과부하 가능성
Blue - Green
- 2개의 동일한 운영 환경을 준비하여 동시에 교체
- 여분의 인프라 필요
- Rolling Update와 달리 구/신버전의 혼재(구/신버전이 동시에 서비스)가 없음.
- 배포에 문제 발생시 Roll Back 용이
Canary
- 구버전 서버들중에서 일부 서버에 새 버전 배포. 이 서버의 일부 사용자들의 트래픽을 분산시킴
- 별 문제 없으면 나머지 교체, 사용자 비율 증가
- 소수의 사용자에게만 배포하기 때문에 Blue - Green방식보다 상대적으로 영향 적음
- Capacity test 수행
- canary: 새의 이름으로, 과거 광산에서 이 새를 보내어 안전한지 확인해봤다고 한다. 여기서 따온 이름
'대학교 > 소프트웨어공학론' 카테고리의 다른 글
| 5. 요구사항 개발 프로세스 (1) | 2023.04.24 |
|---|---|
| 4. 요구사항 (0) | 2023.04.24 |
| 3. scrum (0) | 2023.04.24 |
| 1. 소프트웨어 공학의 태동, 유지보수, waterfall, Iron triangle (0) | 2023.03.13 |
