[SE] 소프트웨어 프로세스

이 글은 충남대학교 김현수 교수님의 소프트웨어 공학 수업을 듣고 작성한 글입니다.

 

이번 시간엔 소프트웨어 개발 프로세스와 이때 사용하는 모델에 대해 알아보자

 

1. 소프트웨어 개발 프로세스

- 프로젝트를 소규모 작업으로 구성하는 일반적인 접근 방법
- 관리자와 팀원들이 다음 사항을 결정하는데 도움(무엇을 어떤 순서로 할 것인가)
- 모델은 작업 방식을 엄격하게 규정하기 보다는 생각하는데 도움을 주어야 함
- 각 프로젝트는 고유의 계획을 가지고 진행되어야 함.

 

즉흥적으로 프로세스를 개발할 수도 있다. 그러면 어떤 문제가 발생할까?

 

1. 구현하기 전에 요구나 설계 등의 중요성을 인식하지 못함
2. 설계가 잘 되지 않으면 소프트웨어의 질이 떨어질 수 있음
3. 목표 없이 일하게 됨
4. 테스트나 품질 보증 같은 작업의 필요성 간과
5. 개발과 유지보수 비용이 증가

---

2. 대표적인 소프트웨어 개발 프로세스 모델

 

6가지 모델이 있다. 먼저 폭포수 모델부터 차근차근 알아보자

 

# 폭포수 모델

1. 도입
  - 1970년대 항공 방위 소프트웨어 개발 경험을 통해...

2. 특징
  - 각 단계가 다음 단계 시작 전에 끝나야 함
  - 순서적 : 각 단계 사이에 중복이나 상호작용이 없음
  - 각 단계의 결과는 다음 단계가 시작되기 전에 점검
  - 바로 전단계로 피드백 

3. 적용
  - 요구사항을 잘 이해하고 있거나 요구사항의 변경이 한정적인 상황에 적합
  - 대규모 시스템 공학 프로젝트에 주로 사용

4. 결과물 정의가 중요

5. 단점
  - 프로세스 진행 후 변경 수용하기 어려움
  - 초기 단계를 지나치게 강조하면 코딩, 테스트가 지연
  - 각 단계의 전환에 많은 노력
  - 프로토타입과 재사용의 기회가 줄어듦
  - 소용없는 다수의 문서를 생산할 가능성 존재

6. 대표적 표준
  - MIL-STD-2167 (ex. general system life cycle, software development cycle)
  - ISO/IEC 12207

 

# 프로토타입 모델

1. 인간 - 관계 상호작용 프로토타입
2. working 프로토타입 : 소프트웨어 기능의 일부분 실현
3. throw-away prototyping : 시스템 요구사항을 이해하기 위한 목적
4. 개선을 목표로 요구되는 기능의 일부 또는 전체 수행

 

# 점증적 모델(Incremental Model)

1. 개발 사이클이 짧은 환경
  - 빠른 시간 안에 출시하여야 하는 경우, 시스템을 나누어 release

2. 릴리스 구성 방법
  - 점증적 방법 : 기능 별로 release
  - 반복적 방법 : release할 때마다 기능의 완성도를 높임

3. 단계적 개발
  - 기능이 부족해도 초기에 사용 가능
  - 처음 출시된 소프트웨어는 시장을 빨리 형성할 수 있음
  -  자주 release하면 예상 못했던 문제를 신속하고 꾸준히 고칠 수 있음
  - 개발 팀이 release마다 다른 전문 영역에 초점을 둘 수 있음

 

# 나선형 모델(Spiral Model)

1. 소프트웨어의 기능을 점증적올 개발
  - 실패의 위험을 줄임
  - 테스트 용이 및 자연스런 피드백

2. 여러 번의 점증적인 릴리스 

3. 진화 단계
  - 계획 수립(목표, 기능 선택, 제약 조건 결정) => 위험 분석(기능 선택의 우선순위, 위험요소 분석) => 개발(선택 기능 개발) => 평가

4. 적용
  - 대규모 시스템 개발에 적합(risk reduction mechanism)

5. 특징
  - 반복적인 개발 및 테스트
  - 강인성 향상

6. 단점
  - 관리, 위험 분석이 중요!

 

# 진화적 모델

1. 반복적이며 점증적인 방법
  - 초기에 사용자가 요구사항을 파악하기 힘들고 구현이 어려운 경우 
  - 요구사항 분석을 한 번 이상 반복한다.

2. UP(Unified Process)
  - 도입 단계 : 프로젝트의 범위를 설정하고 목표를 명확
  - 정련 단계 : 시스템의 중요한 요구를 찾아내어 기본이 되는 설계 완성
  - 구축 단계 : 제조 단계, 원시 코드가 완성되고 모든 중요한 요구의 테스트가 마무리
  - 전환 단계 : 사용자에게 release

 

# 애자일(Agile) 프로세스

1. 특징
  - 짧게 반복하면서 개발 ==> 설계가 변경되어도 잘 수용
  - 짧은 release와 반복 : 작업을 작은 조각으로 나누어 되도록 자주 release
  - 점증적 설계 : 설계에 대한 결정을 미루고 더 많은 지식이 쌓였을 때 설계를 개선
  - 사용자 참여 : 사용자를 참여시켜 계속 피드백 제공 ==> 처음부터 완벽하게 구현하는게 아님!
  - 문서 최소화 : 필요한 문서만 최소로 작성, 원시 코드가 실체
  - 비공식적 커뮤니케이션 : 형식적인 문서보다 지속적인 대화
  - 변화 : 요구와 환경의 변경을 가정

2. Extreme Programming
  - 최초의 애자일 프로세스
  - 계획 : 비즈니스 우선순위와 기술적인 예측을 토대로 기능 결정
  - 짧은 릴리스 : 2~4주
  - 메타포 : 정형화된 아키텍쳐 사용X, 메타포 사용
  - 간결한 설계
  - 테스트 중심 개발 : 실제 코드를 쓰기 전 테스트 코드를 작성
  - 리팩토링 : 동작의 변경 없이 시스템을 재구성하고 설계를 개선
  - 페어 프로그래밍 : 컴퓨터를 공유하며 개발과 testing 역할 분리
  - 지속적 통합 : 항상 실행되는 시스템을 유지하도록 여러번 통합하고 빌드
  - 적정 속도 : 주당 40시간
  - 고객 참여 : 팀에 고객이 합류하여 항상 질문에 답할 수 있도록
  - 코딩 표준 : 코딩 과정에 동일한 규칙 적용 
  - Planning(쪼개기, 시간 및 자원 계획) => Analysis(예산 책정, 반복 시간 정의) => Design(각 과업별 테스트 시나리오 준비)  => Execution(코딩, testing) => Wrapping(조금 release, 데모와 리뷰) => closure 

 

# 스크럼(Scrum)

 팀원들이 스크럼을 짜듯이 조직적으로 애자일 방법론을 적용한다!
1. 구성요소
  - 백로그(할 일 목록, SRS 해당 목록)
  - 스프린트(=Iteration, 1~4주 정도, 스토리 개발 및 설치)
  - 스크럼 회의(매일 15분간 진도 확인)
  - 리뷰(스프린트 종료 후 산출물 리뷰)
  - 스프린트 회고(방법론 자체에 대한 리뷰 수행)

 

언제 어떤 모델을 선정해야 하는지 아래에 정리된 표를 보자

 

---

2. Process Activities

다음으로 어떤 프로세스 액티비티가 있는지 알아보자

 

# Software specification

정의 : 어떤 서비스가 필요한지, 시스템의 운용 및 개발에 대한 제약 사항이 무엇인지 확립

1. 공학 프로세스의 요구사항
   - 타당성 조사
   - 요구사항 도출 및 분석
   - 요구사항 명세
   - 요구사항 검증

 

# Software design and implementaion

정의 : 시스템 명세를 실행 가능한 시스템으로 변환하는 프로세스

1. Software design
  - 명세를 실현하는 소프트웨어 구조 설계

2. Implementation
  - 이런 구조를 실행 가능한 프로그램으로 변환

3. Design process activities
  - 아키텍쳐 디자인
  - 인터페이스 디자인
  - 컴포넌트 디자인
  - 자료구조 및 알고리즘 디자인

4. Programming and debugging
  -  설계를 프로그램으로 변환하고 오류를 제거하는 프로세스
  - 디버깅 프로세스에서 결함을 제거하기 위해 프로그램 테스트 수행 

 

# Software validation

정의 : 시스템이 명세에 부합하고 시스템 고객의 요구사항을 충족한다는 것을 보여주기 위한 활동

1. Verification and validation
  - Component or unit testing(개별 컴포넌트를 독립적으로 테스트, 컴포넌트는 기능이나 객체 또는 이런 기능/객체의 연관성 있는 그룹)

2. System testing
  - 시스템 전체 테스트
  - 명세에서 유도된 테스트 케이스를 가지고 시스템을 실행하는 테스트

3. Acceptance testing
  - 시스템이 고객의 요구를 충족하는지 확인하기 위해 고객의 데이터를 이용해 테스트

 

# Software evolution

- 소프트웨어는 본질적으로 유연하고 변경될 수 있음
- 변화하는 비즈니스 환경에 따라 요구사항이 변화 => 비즈니스를 지원하는 소프트웨어도 진화하고 변화해야함