Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
Tags
- redis
- StringBuilder
- AOP
- VUE
- SQL
- 조합
- hashcode
- 바이너리 카운팅
- equals
- jpa
- 열 속성
- DI
- lambda
- static
- DDL
- stream
- select_type
- 테스트 코드
- KEVISS
- docker
- Spring
- 재정의
- cache
- jwt
- 인덱스
- 필드 주입
- java
- 생성자 주입
- Test
- MSA
Archives
- Today
- Total
백엔드 개발자 블로그
소프트웨어 생명 주기 본문
소프트웨어를 개발하기 위해 정의하고 운용 유지보수 등의 과정을 각 단계별로 나눈것
종류
폭포수 모델
한 단계가 끝나야 다음 단계로 넘어갈 수 있는 선형 순차적 모형
타당성 > 검토 > 계획 > 요구분석 > 설계 > 구현 > 테스트
프로토타입 모델
소프트웨어의 시제품을 만들어 최종 결과물을 예측하는 모형
▶▶ 프로토타입 모형 진행 과정 ▶▶ |
|||||
요구사항 수집 | 빠른 설계 | 프로토타입 구축 | 고객 평가 | 프로토타입 조정 | 구현 |
◀◀ 구현 이후, 고객의 피드백을 받은 다음 다시 1번 단계인 요구사항 수집단계로 돌아간다 ◀◀ |
나선형 모델
나선을 따라 돌듯이 여러번의 개발 과정을 거쳐 점진적으로 최종 소프트웨어를 개발
▶▶ 나선형 모델 ▶▶ |
|||
계획 및 정의 | 위험 분석 | 공학적 개발 | 고객 평가 |
◀◀ 고객 평가를 바탕으로 다시 1번 단계인 계획 및 정의 단계로 돌아간다 ◀◀ |
에자일 모델
고객의 요구사항 변화에 유연하게 대응할 수 있도록 일정한 주기를 반복하면서 진행하는 모형
반복되는 주기마다 결과물에 대한 평가와 요구사항 수용
ex) 스크럼, XP, 칸반, Lean, 크리스탈, ASD, FDD, DSDM 등
스크럼
- 팀원 스스로 팀을 구성하고 개발에 대한 모든것을 스스로 해결할 수 있어야 함
- 구성요소
책임자- 개발될 제품에 대한 이해도가 높고 요구사항을 책임짐 (의사결정자) - 개발의뢰자나 사용자가 담당함 - 이해관계자들의 의견을 종합하여 제품에 대한 요구사항 작성 - 백로그 작성 - 팀원들이 백로그에 스토리를 추가하면 제품 책임자는 우선순위를 지정함 - 테스트를 수행하면서 주기적으로 요구사항의 우선순위 갱신
스크럼 마스터 | - 팀이 잘 수행할 수 있도록 객관적인 시각에서 조언함 (가이드 역할) - 일일 스크럼 회의 주관 (진행사항 점검, 개발시 장애요소 공론화 및 처리) |
개발팀 | - 제품 개발에 참여하는 모든 인원 (개발자, 디자이너, 테스터 등) - 보통 최대인원은 7~8명이 적당함 |
제품 백로그 (Product Backlog) | 개발에 필요한 요구사항을 우선순위에 따라 나열한 목록 - 새롭게 도출되는 요구사항에 따라 지속적인 업데이트 - 작성된 사용자 스토리를 기반으로 릴리즈 계획 수립 |
스프린트 계획 회의 (Sprint Planning Meeting) | 스프린트에서 수행할 작업을 대상으로 단기 일정 수입 - 요구사항을 '태스크'라는 작업단위로 나누어 개발자들이 작업할 수 있도록 구분한 다음, 스프린트 백로그 작성 |
일일 스크럼 회의 (Daily Scrum Meeting) | - 모든 팀원이 매일 약속된 시간에 진행상황 점검 (짧은 회의시간) - 스크럼 마스터는 발견된 장애 요소를 해결할 수 있도록 도와줌 - 남은 작업 시간은 소멸 차트에 표시 |
스프린트 검토 회의 (Sprint Review) | - 부분 or 완성된 제품이 요구사항에 부합하는지 확인하는 절차 - 사용자가 포함된 상태로 테스트 수행 |
스프린트 회고 (Srpint Retrospective) | - 스프린트가 완료된 후 리뷰/점검하는 절차 - 정해놓은 규칙을 잘 준수했는지, 개선사항은 없는지 등 점검 |
XP 개발 프로세스
애자일 모델 기법 설명 2 - XP
XP 개요 (eXtrem Programming) | - 목적1 : 수시로 발생하는 고객 요구사항에 유연하게 대응 - 목적2 : 고객 참여와 개발 과정 반복을 극대화 > 개발 생산성 향상 - 릴리즈 기간을 짧게 반복하면서 요구사항 반영에 대한 가시성이 높음 - XP의 5가지 핵심 가치 : 의사소통, 단순성, 용기, 존중, 피드백 |
XP 개발 프로세스
사용자 스토리 (User Story)- 고객 요구사항을 간단한 시나리오로 표현
배포 계획 수립 (Realsase Planning) | - 여러 스토리가 개발되어 부분적으로 기능이 완료된 제품을 배포하는 것에 대한 계획 수립 |
스파이크 (Spike) | - 요구사항의 신뢰성을 높이고 기술문제의 위험을 감소시키기 위해 별도로 만드는 프로그램 |
이터레이션 (Iteration) | - 하나의 배포를 세분화한 단위 |
승인검사 (Acceptance Tests) | - 하나의 이터레이션 안에서 계획된 배포 단위의 개발이 완료되면 수행하는 테스트 (배포 전 검사) - 사용자 스토리 작성시 함께 기재한 테스트 사항에 대해서 고객이 직접 수행 |
소규모 배포 (Small Release) | - 테스트에 대한 고객의 반응을 기능별로 확인하고 고객 요구사항에 유연하게 대응 - 진행된 이터레이션이 모두 완료되면, 고객의 최종 테스트 수행 후 최종결과물을 고객에게 전달 |
XP의 주요 실천 방법
- Pair Programming : 다른사람과 함께 프로그래밍 수행
- Test-Driven Development : 실제 코드 작성 전 테스트케이스를 먼저 작성하여 무엇을 해야할지 파악
- Whole Team : 개발에 참여하는 모든 구성원은 각기 역할에 책임을 다해야 함
- Continuous Intergration : 모듈 단위로 나누어 개발한 코드는 하나의 작업이 마무리되면 지속적으로 통합
- Design Improvement / Refactoring : 프로그램 기능의 변경없이 시스템 재구성
- Small Release : 배포 기간을 짧게하여 고객 요구사항 변화에 신속하게 대응
'Programming > 요구사항 분석' 카테고리의 다른 글
UML (0) | 2024.05.09 |
---|---|
요구사항 분석 (0) | 2023.08.22 |