2. rad, lean startup, agile, DevOps

대학교/소프트웨어공학론

2. rad, lean startup, agile, DevOps

CodeJin 2023. 3. 28. 02:41

※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※

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)도 가능

https://hrbulletin.net/organizational-culture/애자일-방법론-②-린스타트업lean-startup/

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가 느리게 일어나게 되고, 이는 데브옵스 이념에 맞지 않기 때문

그림 출처: https://towardsdatascience.com/continuous-integration-continuous-delivery-myths-pitfall-and-practical-approach-aaec22edacc5

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 등의 배포 전략을 사용하여 배포가 이루어진다.