[요구사항 확인] 소프트웨어 개발 방법론

소프트웨어 생명주기 모델

소프트웨어 생명주기는 시스템의 요구분석부터 유지보수까지 전 공정을 체계화한 절차로

프로세스는 요구사항 분석, 설계, 구현, 테스트, 유지보수로 총 5가지로 분류된다.

 

대표적인 모델 종류로는 폭포수 모델, 프로토타이핑 모델, 나선형 모델, 반복적 모델이 있다.

폭포수 모델  - 선형 순차적 모형으로 개발 시 각 단계를 마무리 짓고 다음 단계로 넘어가는 모델이며

(타당성 검토 > 계획 > 요구사항 분석 > 설계 > 구현 > 테스트 > 유지보수)

 

프로토타이핑 모델 - 고객이 요구한 주요 기능을 프로토타입으로 구현하여, 고객의 피드백을 바탕으로 소프트웨어를 만들어가는 모델

(요구사항 분석 > 프로토타입 개발 > 프로토타입 평가 > 구현 > 테스트)

 

나선형 모델 - 개발을 여러 번의 반복적 사이클로 수행하며, 각 단계에서 위험 분석을 수행

(계획 및 정의 > 위험 분석 > 개발 > 고객 평가)

 

반복적 모델 -  구축대상을 병렬적으로 개발 후 통합하거나, 반복적으로 개발하여 완성

(개발대상 >> 분석 > 설계 > 구현)

 

소프트웨어 개발 방법론

소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법, 절차, 기법으로 소프트웨어를 효과적으로 개발하기 위한 체계적인 접근 방식

종류로는 구조적 방법론, 정보공학 방법론, 객체지향 방법론, 컴포넌트 기반 방법론, 애자일 방법론, 제품 계열 방법론이 있다.

 

구조적 방법론

시스템을 기능 중심으로 나누어 계층적으로 개발하는 방법론 (폭포수 모델, V 모델, 반복적 모델)

 

정보공학 방법론

정보시스템 개발에 필요한 관리 절차와 작업 기법을 체계화한 방법론 (계층적 정보공학 방법론, 데이터 중심 정보공학 방법론)

 

객체지향 방법론

객체를 기반으로 시스템을 분석 및 설계하는 방법론

 

컴포넌트 기반 방법론

기능 단위(컴포넌트)로 소프트웨어를 조립해서 하나의 새로운 소프트웨어를 만드는 방법론

 

애자일 방법론

빠른 개발과 지속적인 피드백을 통해 유연하게 개발하는 방법론

 

제품 계열 방법론

공통 기능과 차별화된 기능을 정리하여 여러 제품을 효율적으로 개발

 

애자일을 선호하는 곳이 많아 깊게 애자일에 대해서 적어보려고 한다.

 

애자일은 기본적으로 4가지 원칙을 준수해야하는데 

 

1. Individuals and interactions

2. Working software

3. Customer collaboration

4. Responding to change

 

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

 

위와 같은 내용이 애자일의 기본 4가지 원칙이다.

 

소프트웨어 개발의 초기 방식은 요구사항 변경이 어렵고 유연성이 부족하며, 개발 주기가 길어 요구사항 반영이 지연되는 등

다양한 문제가 존재했고, 이런 문제를 해결하기 위해 개발 전문가들이 발표한 방법론이다.

 

대표적으로 XP, 린, 스크럼 방식이 있는데 하나씩 살펴보자면

 

XP (Extreme Programming)

소프트웨어 품질과 생산성 극대화를 목표로 한다

 

1~3주의 반복 개발주기를 가지며 5가지 가치와 12개의 실천항목이 존재한다

 

5가지 가치

용기 (자신감 있게 개발, 빠른 피드백과 리팩토링), 단순성 (필요한 것만 함), 의사소통 (개발자, 관리자, 고객 간의 원할한 소통),

피드백 (의사소통에 대한 빠른 피드백), 존중 (팀원 간의 상호 존중)

 

12개의 실천 항목

짝 프로그래밍 (개발자 둘이서 짝으로 코딩), 공동 소유 코드 (시스템에 있는 코드는 누가 언제든지 수정 가능), 지속적인 통합 (매일 여러 번씩 통합하고 빌드), 계획 세우기 (고객이 요구하는 비즈니스 가치를 정의하고, 필요한 것 지연 사항을 알려야함), 작은 릴리즈 (작은 시스템을 먼저 만들고, 짧은 단위로 업데이트), 메타포어 (공통적인 이름 체계와 시스템 서술서로 고객과 개발자 간의 의사소통을 원할하게 해야함), 간단한 디자인 (요구사항에 적합한 가장 단순한 시스템 설계), 테스트 기반 개발 (테스트 먼저 수행하고 테스트를 통과할 수 있도록 코드 작성), 리팩토링 (기능 변경 없이 중복제거, 단순화 등을 통해 시스템 재구성), 40시간 작업 (개발자가 피곤해서 실수할 일이 없도록 주에 40시간 이상을 일하지 말아야 한다는 원리 가능한가..?), 고객 상주 (개발자들의 질문에 즉각 대답해 줄 수 있는 고객을 프로젝트에 풀타임으로 상주), 코드 표준 (모든 코드에 대한 코딩 표준을 정의 없으면 진짜 힘듦 이건 그냥 다해줬으면..)

 

스크럼 (Scrum)

제품 개발을 짧은 주기(스프린트, 일반적으로 1~4주)로 나누어 진행한다

백로그(제품과 프로젝트에 대한 요구사항)를 기반으로 우선순위가 높은 작업을 수행하며, 지속적인 피드백을 반영함

 

스크럼은 수행 중 매일 스크럼 미팅(주로 15분 To-Do List 계획 수립)을 진행하며 스프린트가 끝난 후에는

스프린트 회고를 수행(스프린트 주기를 되돌아보며 규칙 준수 여부 및 개선점을 확인 및 기록)

 

린 (Lean)

도요타의 린 시스템 품질기법을 소프트웨어 개발 프로세스에 적용

7가지 원칙이 있다 (낭비제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최적화)

 

스크럼 방식이 가장 널리 사용되는 방식이여서 Jira를 통해 스크럼으로 프로젝트를 진행했었는데,

짧은 기간에 성공적으로 소프트웨어 개발 및 PT까지 잘 마친 경험이 있다.

 

MVP를 만들 때 효과적인 방법론인 것 같다.