SW공학_1
SW 공학
소프트웨어 공학은 인류의 이익을 위해서 소프트웨어와 관련된 원리, 지식, 도구등을 활용하여 새로운 제품, 도구등을 만드는 것
- 계획, 요구사항 분석, 설계, 구현, 시험, 및 유지보수과정(폭포수모델)
- 프로젝트 계획
- 문제 정의 (무엇을 개발할지)
- 법적, 경제적, 기술적 타당성 조사
- 일정 계획
- WBS(Work Breakdown Structure) 대표적
- 작업 분할 구조도
- 프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화하는 작업
- 수행사 및 담당자까지 지정
- 프로젝트 계획
- 사용자의 요구사항과 시스템의 기능이 문서화되어야 하는 단계
- 고객과 개발 회사의 계약서로서의 가치를 가짐
- 설계
- 시스템 아키텍쳐 설계
- 소프트웨어 아키텍쳐 설계
- 컴포넌트 설계
- 소프트웨어 아키텍쳐 설계
- 테스팅
- 요구사항과 설계에 맞는지 점검 과정으로서 전체 개발 기간의 40% 가까이 차지
- 테스트 유형
- 유닛테스트 -> 프로그램의 기본단위인 모듈에 대한 테스트를 수행하는 단위 시험
- 통합테스트 -> 단위 시험 후 모듈들을 통합하여 테스트를 수행하는 통합 시험
- 시스템테스트 -> 통합 시험 이후 소프트웨어와 다른 시스템 요소(하드웨어, 정보 등)들과 통합하여 시스템의 기능을 만족하는지 확인하는 시스템 시험
- 인수테스트 -> 고객이 참여하여 고객 요구사항 만족 여부를 검증하는 인수 시험
- 유지보수
- 사용중 발생하는 여러 변경사항에 대해 적응하는 활동이며 변화에 따른 프로그램 추가/수정을 하는 과정
- 폭포수모델 (waterfall)
- 계획, 요구사항 분석, 설계, 구현(프로그래밍), 시험, 유지보수의 순서로 시스템의 개발되는 전통적인 방법론
- 개념 정립에서 구현까지 하향식 접근방법을 사용하여 높은 추상화 단계에서 낮은 추상화 단계로 이동하는 모델
폭포수 방법론의 순차적이고 구조화된 접근 방식은 초기 단계에서의 광범위한 계획과 구조화된 개발프로세스가 중요한 대규모 모놀리식 시스템의 개발에 적합
- 장점
- 프로젝트 진행과정을 세분화하기 때문에 큰 프로젝트의 진척과 인력 관리가 용이
- 개발방법론의 초기 모델로서 많은 수행과 검증을 거쳐왔고, 대규모 시스템 구축에 있어 경험 축적
- man/month 기반의 비용산정과 일정산정의 용이함
- 단점
- 고객이 원하는 요구사항을 초기에 구체화 하기 어려움
- 오류발견과 수정이 순환적으로 발생하므로, 순차적 개발이 현실적으로 어려움
- 시스템 구축이 후반부에 가서야 완료되는 경우엔, 시스템 문제점 파악 어려움
- 설계한 아키텍쳐의 문제가 후반부에 가서야 발견되는ㄴ 경우가 많아, 수정의 어려움
- man/month 기반의 비용산정의 불합리성과 일정산정의 부정확함
- 애자일모델
- 기존 방법론은 프로젝트의 본질적인 목표보다 계획 수립, 문서화, 품질 관리 등 추가로 수행되는 작업을 위해 오버헤드비용(부수적인비용)을 과다하게 요구
- 개발자들이 좋은 것을 빠르고 낭비없이 만들기 위해 경량화된 가벼운 개발방법론이 애자일
- 애자일 방법론의 문제
- 분석, 설계, 구현, 시험이 끊임없이 진행되는 반복되는 순환적 개발과정
- 각 단계를 짧게 1-2주 짧은 스프린트를 잡고 특정 기능이 동작하는 데모, 즉 최소 기능 제품(Minumum Viable Product)를 통해 배포후에 고객에게 시연하고 피드백을 통해 다시 반복적으로 분석, 설계, 구현, 시험
- 요구사항의 변화가 자주 일어나거나 개발자가 소규모인 소형 또는 중간 사이즈의 비즈니스 시트템, 게임 소프트웨어 개발이 적합
애자일 방법론의 작은 단위의 기능개발, 팀별 자율성 등의 특징은 모놀리식 아키텍쳐가 아닌 msa 아키텍쳐와 적합한 구조
스크럼(SCRUM)
- 특정 이슈를 bottom up 방식을 통해 발생하여 문제를 공유하고 문제를 짧은 스탭을 통해 해결해 나가는 과정
- PO, PM(PL), 기획자, 개발자, 디자이너 등이 스크럼의 참여자
- 일반적으로 개발팀에서 SCRUM 회의라면 우선순위별로 발생된 이슈에 대해 논의하고, 스프린트 별로 진척 상황을 회고 하는 것
- 스크럼을 위한 툴로서 아틀라시안의 JIRA를 주로 사용
지라
- 스프린트 생성 -> 스토리 생성 -> 작업 생성등의 분류 과정을 통해 작업 생성
- 이때 작업 생성은 실무에서 이슈발행, 티켓발행, 백로그 생성등의 용어로 사용
- 만들어진 스프린트가 시작되면 보드에서 시각화되어 보여짐.
- TODO, IN PROGRESS, IN REVIEW, DONE 등의 단계를 거치면서 생명주기 관리
- 지라는 Github, Slack 등의 툴과 연계해 유기적으로 활용.
모놀리식 아키텍쳐
- 단일 대규모 애플래케이션
- 애플리케이션의 모든 기능이 하나의 큰 시스템으로 구축되는 방식
- 통합된 개발 접근
- 애플리케이션의 모든 구성 요소가 하나의 코드베이스에 통합되어 있으며, 이로 인해 소스코드가 서로 영향을 받고 배포 및 테스트가 복잡하고 어려워짐
- 관리 및 유지보수의 복잡성
- 상호 영향도
- 하나의 모듈을 수정할 떄, 이를 참조하거나 영향을 받는 모든 모듈들도 영향을 받을 수 밖에 없는 구조
- SW아키텍쳐의 복잡도와 배포의 어려움
- 소스코드의 영향도로 인해, 배포도 팀마다 불가능하고 전체배포 시간을 정하여 모든 소스코드를 한꺼번에 반영.
- 일반적으로 새벽시간이나 DB작업 등 복잡한 작업의 경우엔 새벽에 진행. 심지어 변경의 규모가 큰 작업일 경우 명절 등 공휴일을 정해 배포
- 시스템 구성의 복잡성
- 시스템이 복잡해 개발의 영향도 파악이 어려움
- 상호 영향도
MSA 아키텍쳐
- 모놀리식에서 문제의 원인이었던 서비스들간의 의존성이 약화되거나 제거돼 느슨한 결합상태로 구성
- 서비스는 저마다 데이터베이스를 가지며, 각 서비스마다 더 적합한 기술이 사용
- 서비스의 수정이 발생하여도 다른 서비스로의 영향이 없거나 적기 때문에, 독립적인 개발 및 배포가능
- 장애가 발생하더라도 장애 범위가 서비스에만 국한
- 특정 이벤트로 대량의 트래픽이 몰릴 경우, 해당 서비스에만 컴퓨팅 리소스를 더 투입하는 스케일 아웃(서버를 늘리기(구조)) 전략을 적용 + (스케일업은 컴퓨터 성능을 올림)
API 기반 통신
- 소프트웨어나 시스템 간의 상호작용을 가능하게 하는 규약 또는 인터페이스
- 즉, 소프트웨어 컴포넌트 간의 ‘연결고리’역할을 하며, 사용자들이 복잡한 코드를 직접 작성하지 않고도 특정 기능에 대한 정보를 받거나 구현하는데 도움 -> ex) 한국거래소API 통해 시세 받기 등
- API기반 통신은 주로 동기적 처리를 위한 용도
이벤트 기반 통신
- 비동기 또는 독립적 처리를 위한 용도
- 주문이 발생하면(신규주문) 주문 정보를 가진 메시지를 발행하고, 재고 서비스나 앱 푸시 서비스에서 해당 메시지를 구독하여 후속 처리
MSA의 컨테이너 환경구성
- MSA는 경량화된 아키텍쳐로서 분산 아키텍처로 구성
- 경량화된 서버인 도커 컨테이너와 같은 컨테이너 기반 아키텍쳐에 적합
- 확장가능성에 염두를 둔 msa 설계사상과 확장에 유연하고 용이한 이미지 기반의 컨테이너 서버구성은 상호 적합한 기술 선택지
- 쿠버네티스와 같은 컨테이너 오케스트레이션 기술 덕분에 대규모 컨테이너 시스템을 기존의 레거시보다 효율적으로 관리할 수 있는점이 큰 강점
- 쿠버네티스 활용
- 자동화된 배포와 롤아웃 관리를 통해 MSA환경에서의 빈번한 수정과 배포가능
- 자동 확장과 로드밸런싱
- 특정 서비스의 많은 트래픽 상황시 빠른 자동확장 서비스와 로드밸런싱
- 서비스 검색과 네트워킹을 통한 내부 통신 용이
- 내부 서비스간의 통신 용이와 확장성이 하게 함으로서 MSA컨테이너간의 통신에 최적화
- 자원 관리 및 최적화
- MSA는 경량화된 아키텍쳐로서 분산 아키텍처로 구성
This post is licensed under CC BY 4.0 by the author.