📌 소프트웨어공학
인류의 이익을 위해서 소프트웨어와 관련된 원리, 지식, 도구 등을 활용하여 새로운 제품, 도구 등을 만드는 것
✅ 전통적인 소프트웨어 공학의 개발 과정
- 요구사항 정의
- 사용자의 요구사항과 시스템의 기능이 문서화되어야 하는 단계
- 고객과 개발 회사의 계약사로서의 가치를 가짐
- 설계
- 시스템 아키텍처 설계
- 소프트웨어 아키텍처 설계
- 컴포넌트 설계
- 클래스 관계 설계
- 데이트 베이스 설계
- 구현
- 실질적인 프로그래밍 단계
- 일반적으로 전체 개발 기간의 20% 정도를 차지
- 테스팅
- 요구사항과 설계에 맞는지 점검 과정으로서 전체 개발 기간의 40% 가까이 차지
- 테스트 유형
- 유닛 테스트(Unit Testing)
- 프로그램의 기본단위인 모듈에 대한 테스트를 수행하는 단위 시험
- 통합테스트(Integration Testing)
- 단위 시험 후 모듈들을 통합하여 테스트를 수행하는 통합 시험
- 시스템 테스트(System Testing)
- 통합 시험 이후 소프트웨어와 다른 시스템 요소(하드웨어, 정보 등)들과 통합하여 시스템의 기능을 만족하는지 확인
- 인수테스트(Acceptance Testing)
- 고객이 참여하여 고객 요구사항 만족 여부를 검증하는 인수 시험
- 유닛 테스트(Unit Testing)
- 유지보수
- 사용중 발생하는 여러 변경사항에 대해 적응하는 활동이며 변화에 따른 프로그램 추가/수정을 하는 과정
✅ 소프트웨어 개발 방법론
💡 폭포수 모델
- 계획, 요구사항 분석, 설계, 구현, 시험, 유지보수의 순서로 시스템이 개발되는 전통적인 방법론
- 개념 정립에서 구현까지 하향식 접근방법을 사용하여 높은 추상화 단계에서 낮은 추상화 단계로 이동하는 모델
- 폭포수 방법론의 순차적이고 구조화된 접근 방식은 초기 단계에서의 광범위한 계획과 구조화된 개발 프로세스가 중요한 대규모 모놀리식 시스템의 개발에 적합
- 프로젝트 계획
- 문제정의
- 법적, 경제적, 기술적 타당성 조사
- 일정 계획
- WBS(Work Breakdown Structure)가 대표적
- 프로젝트 목표를 달성하기 위해 필요한 활동과 업무를 세분화하는 작업
- 수행사 및 담당자까지 지정
- 작업 분할 구조도
- 설계 - 시스템 설계, DB설계, SW설계
- 폭포수 모델의 장점
- 프로젝트 진행과정을 세분화하기 때문에 큰 프로젝트의 진척과 인력 관리가 용이
- 개발방법론의 초기 모델로서 많은 수행과 검증을 거쳐왔고, 대규모 시스템 구축에 있어 경험 축적
- man/month 기반의 비용산정과 일정산정의 용이
- 폭포수 모델의 단점
- 고객이 원하는 요구사항을 초기에 구체화 하기 어려움
- 오류발견과 수정이 순환적으로 발생하므로, 순차적 개발이 현실적으로 어려움
- 시스템 구축이 후반부에 가서야 완료 되는 경우엔, 시스템 문제점 파악 어려움
- 설계한 아키텍처의 문제가 후반부에 가서야 발견되는 경우가 많아, 수정의 어려움
- man/month 기반의 비용산정의 불합리성과 일정산정의 부정확함
💡 애자일
- 기존 방법론은 프로젝트의 본질적인 목표보다 계획 수립, 문서화, 품질 관리 등 추가로 수행되는 작업을 위해 오버헤드 비용을 과다하게 요구
- 개발자들이 좋은 것을 빠르고 낭비없이 만들기 위해 경량화된 가벼운 개발방법론
- 애자일 방법론의 단계
- 분석, 설계, 구현, 시험이 끊임없이 반복되는 순환적 개발과정
- 각 단계를 짧게 1-2주 정도의 짧은 기간(Sprint)을 잡고 특정 기능이 동작하는 데모, 즉 최소 기능 제품(MVP:Minimun Viable Product)를 통해 배포후에 고객에게 시연하고 피드백을 통해 다시 반복적으로 분석, 설계, 구현, 시험
- 요구사항의 변화가 자주 일어나거나 개발자가 소규모인 소형 또는 중간 사이즈의 비즈니스 시스템, 게임 소프트웨어 개발이 적합
- 애자일 방법론 중 하나로 스크럼(SCRUM) 방식이 널리 사용
- 애자일 방법론의 작은 단위의 기능 개발, 팀별 자율성 등의 특징은 모놀리식 아키텍처가 아닌 MSA 아키텍처와 적합한 구조
✅ 애자일 방법론 종류
1. 스크럼(SCRUM) ⭐
- 특정 이슈를 bottom up방식을 통해 발행하여 문제를 공유하고, 문제를 짧은 스탭을 통해 해결해 나가는 과정
- PO, PM(PL), 기획자, 개발자, 디자이너 등이 스크럼의 참여자
- 일반적으로 개발팀에서 scrum회의라 하면, 우선순위별로 발행된 이슈에 대해 논의하고, 스프린트 별로 진척 상황을 회고 하는 것
- 제품 백로그 -> 스프린트 -> 스프린트 계획회의 -> 스프린트 백로그 -> 일일 스크럼 회의 -> 실행 가능한 제품 개발
- 스크럼을 위한 툴로서 아틀라시안사의 JIRA라는 툴을 많이 사용
- 스크럼 용어 개념
- 제품 백로그 : 개발한 제품에 대한 요구 사항 목록이다.
- 스프린트 : 반복적인 개발 주기, 2~4주 정도의 짧은 개발기간으로 개발 품질을 향상한다.
- 일일 스크럼 회의 : 매일 15분 정도 진행되는 스크럼 회의
- 스크럼 마스터 : 스크럼 프로젝트의 리더, 스크럼 진행 중 문제들을 인지하고 해결하는 역할
- 스프린트 회고 : 스프린트 주기를 되돌아보며 정해 놓은 규칙을 잘 지켰는지 확인하고 개선점을 확인 및 기록하는 것을 말한다. 스프린트가 끝난 시점이나 일정 주기로 시행한다.
- 번 다운 차트 : 남아 있는 백로그 대비 시간을 그래픽적으로 표현한 차트이다.
2. XP(eXtreme Programming)
- 수시로 발생하는 고객의 요구사항에 유연하게 대응하기 위해 고객의 참여와 개발 과정의 반복을 극대화하여 개발 생산성을 향상시키는 방법
- 개발자 - 관리자 - 클라이언트 가 한 팀이 된 것처럼 움직이는 것이 특징
- XP 12가지 실천사항(기본원리)
- 짝 프로그래밍 : 개발자 둘이서 짝으로 코딩을 한다.
- 공동코드 소유 : 모든 코드는 개발자들이 공동으로 소유하며 누구든지 수정할 수 있다.
- 지속적인 통합 : 매번 여러 번씩 소프트웨어를 통합하고 빌드한다.
- 작은 릴리즈 : 작은 시스템을 먼저 만들고, 짧은 단위로 업데이트한다.
- 메타포어 : 공통적인 이름이 체계를 갖고 공통적인 시스템 서술서를 통하여, 개발자와 고객간의 의사소통을 돕는다.
- 계획 세우기 : 고객이 원하는 비즈니스 가치를 정의하고 개발자가 필요한 것은 무엇이며 어떤부분에서 지연될 수 있는지를 알려주어야 한다.
- 간단한 디자인 : 요구상항에 적합하고 가장 단순화한 시스템을 설계해야 한다.
- 리펙토링 : 프로그램의 기능을 바꾸지 않으면서 중복제거, 단순화 등을 위해 시스템을 재구성한다.
- 코드 표준 : 효과적인 공동 작업을 위해서는 모든 코드에 대한 코딩 표준을 정의해야 한다.
- 고객 상주 : 의사소통을 향상하기 위하여 개발자들의 질문에 즉각 대답 가능한 고객을 프로젝트에 풀타임으로 상주시켜야 한다.
- 40시간 작업: 주 40시간 이상을 일하지 말아야한다. (효율성을 위하여)
Agile 개발 방법론을 지원하며, 백로그를 작성하고 스프린트 계획, 칸반 보드, 버전 관리, 릴리즈 관리를 수행하는 SW
- 스프린트 생성 ➡ 스토리 생성 ➡ 작업 생성 등의 분류 과정을 통해 작업 생성
- 이때 작업 생성은 실무에서 이슈발행, 작업 단위인 티켓(TIcket)발행, 백로그 생성 등의 용어로 사용
- 만들어진 스프린트가 시작되면 보드에서 시각화되어 보여짐
- TO DO, IN PROGRESS, IN REVIEW, DONE 등의 단계를 거치면서 생명주기 관리
- JIRA는 GITHUB, SLACK 등의 툴과 연계하여 유기적으로 활용
✅ 모놀리식 아키텍처가 아닌 MSA 아키텍처
https://rookie-programmer.tistory.com/164
-references
'Back-End 공부 > SW공학' 카테고리의 다른 글
모놀리식 아키텍처 VS 마이크로서비스 아키텍처(MSA) (1) | 2023.11.29 |
---|---|
GitHub 기본 명령어(add, commit, push), 커밋취소, 충돌해결 (0) | 2023.11.28 |