SW 공학 개요
SW 개념
SW 위기
SW 공학
SDLC
- Software Development Life Cycle.
폭포수모델
프로토타이핑
나선형모델
반복점증모델
반복적 개발 모델
- Iteration Model.
점증적 개발 모델
- Incremental Development Model.
진화모델
- Evolutionary Development Model.
클린룸공학
- Clean Room Process Model.
개발 방법론
구조적기법
정보공학
객체지향
컴포넌트기반
- CBD: Component Based Development
모델기반
MDA
- Model Driven Architenture.
서비스기반
SOA
데이터, 애플리케이션을 비즈니스 관점에서 표준 블록단위로 나눠 하나의 서비스로 구성한 뒤 웹 서비스 기술 등을 적용 각 서비스를 조합 또는 재사용함으로써 운영체계와 프로그래밍 언어 등에 무관하게 IT자우너을 통합 관리하는 아키텍쳐/모델링/설계패턴
- Service Oriented Architecture.
- 실패요인
- 조직 변화 수용의 실패
- ESB의 부하 중앙 집중 문제
MSA
하나의 어플리케이션을 여러 개의 서비스로 나누어 이 서비스들을 조합하여 본래의 서비스를 제공하는 것 업무 로직을 마이크로 서비스화 하고, 데이터 저장소를 서비스 단위로 분리하여 배치하고, 업무 단위의 독립성을 확보하여 개별적으로 업데이트하고 배포하고 스케일아웃 가능.
- Micro Service Architecture.
- Saga 패턴
- DB분산 트랜잭션 처리 기법인 2PC가 장애유발 위험이 커서 서비서별로 분리된 DB의 트랜잭션 처리방안이 별도로 필요
- Saga Execution Coordinator가 로컬 트랜잭션을 관리해주는 방식
- 하나의 로컬 트랜잭션 단위로 실행, 트랜잭션이 종료될 때 완료 이벤트를 수신하고 순차적으로 다음 로컬 트랜잭션을 실행
- 중앙 SEC노드가 다음에 실행할 로컬 트랜잭션을 결정
- 실패 발생시 원래 트랜잭션에 대한 로그를 남기고, 취소상태를 설정한 후 보상 트랜잭션을 실행, 실패시 일정횟수/일정기간동안 반복적으로 재시도.
- 각 MSA는 자신의 Local Atomic Transation에 만 집중하기 때문에 Pending 상태없음. 따라서 Long-Lived 트랜잭션에 적합.
- Enterprise Gateway: API G/W
- 다양한 API호출에 대한 첫 번째 관문 역할
- 전사 차원의 관리가 필요한 보안(IAM) 및 트래픽 관리
- Micro Gateway: 경량 API G/W
- 사용자/타 시스템 API 호출에 대한 종단 관문 역할 수행
- Service Mesh: 서비스망
- MSA간 직접 통신하지 않고, 애플리케이션 네트워크를 기능을 제공하는 서비스 메쉬를 통해 수행.
- MSA의 트래픽 문제 해결 대안
- 사이드카 패턴
- 모든 응용 프로그램 컨테이너에 사이드카 컨테이너를 추가하여 배포, 서비스의 모든 네트워크 트래픽을 처리.
- 서비스가 타 서비스를 직접 호출하는 것이 아닌 프록시를 통해 호출하므로 로깅, 모니터링, 보안, 트래픽 제어 가능.
Agile 방법론
- ASD: Agile Software Development.
XP
- eXtreme Programming
TDD
- Test Driven Development
Need --> Test --> Refactoring --> Code- Process
- 단위테스트 형식으로 스펙 작성
- 실패하는 테스트를 작성하고 확인
- 스펙을 만족하는 코드를 작성
- 테스트 확인
- 코드와 테스트코드 리팩토링
- 반복
Scrum
- Role
- Product Owner
- Scrum Master
- Scrum Team
- Process
- Product Backlog
- Sprint Backlog
- Burndown chart
- 개발 완료까지 남은 작업량을 보여주는 그래프
- 각 이터레이션 별로 남아있는 작업량을 스토리 포인트라는 것으로 나타낸 것
- Meeting
- Sprint Planning
- Daily Scrum
- Sprint Review
- 특징
- Transparency
- Time boxing: 일일 스크럼은 매일같이 15분이라는 짧은 시간에 진행해야함, 스프린트 리뷰는 매 이터레이션마다 주기적으로 진행.
- Communication: 플래닝포커, 각 사용자 스토리의 구현 난이도/시간을 토론, 협의하는 절차
- Inspect & Adapt model: 경험주의 모델, 개개인의 경험에 기반하므로 프로젝트마다 고유한 상황과 특징을 갖고 있음, 팀마다 달라지는 걸 허용함.
LEAN
- 도요타에서 시작, 파레토 법칙으로 정말 중요한 20%에 집중
- 원칙
- 낭비 제거하라
- 품질 내재화하라
- 지식 창출하라
- 확정을 늦춰라
- 전체를 최적화하라
- 사람을 존중하라
- 빨리 인도하라
DevOps
개발자와 비 개발자 사이의 대화와 협동, 통합을 강조하고 담당업무와 직급의 장벽을 허물고 상호 이해를 추구 소프트웨어 개발과 IT운영 간의 상호의존 관계를 개선하기 위해 등장, 소프트웨어 제품 및 서비스를 빠르게 생산하려는 조직을 돕는 것이 목적.