SW 개발 프로세스

하나의 Project는 여러 개의 activity로 이루어져 있고, 하나의 activity는 여러 개의 task로 이루어져 있다. 그리고 task는 resource를 소모해 work product를 만들어 낸다.

SW 개발 프로세스 용어

• Project = 여러 개의 Activity
• Activity = 여러 개의 Task
• Task = Resource를 소모해 Work product를 만듦
• Resource = 참여자(프로그래머 등), 시간, 자본, 장비 등
• Work product = 시스템, 모델, 문서, 앱, 사이트 등

SW 개발 프로세스의 예

순서	Activity	Work Product
1	요구사항 분석	클래스 UML, Use Case
2	프로젝트 디자인	아키텍쳐 설정
3	상세 디자인	클래스 필드/메소드 설정
4	구현	소스 코드
5	테스트	테스트 케이스

SW 개발 Process 필요성

요리 레시피에도 순서가 있는 것처럼 SW를 개발하는 일반적인 과정을 알면 개발을 효율적으로 할 수 있다. 물론 순서 상관없이 마구잡이로 진행해도 되지만 그럼 자본과 시간이 많이 소모되기 때문이다.

SW 개발 프로세스를 다른 말로 SW Development Lift Cycle(SDLC)라고도 한다. 그리고 이 SW 개발 프로세스를 일반화한 것이 SW Development Process Model이다.

SW 개발 프로세스 종류

개발 프로세스에는 일을 순서대로 진행하는 Sequential Model과, 일에 일정한 순서가 없는 Iterative Model로 나뉜다.

Sequential Model은 프로젝트 진행 단계를 나누고 이를 순서대로 처리한다. 역순으로 진행하는 것은 권장하지 않는다.

Iterative Model은 프로젝트 진행 단계를 나누지만 따로 순서를 정해놓지 않고 상황에 맞춰 프로젝트를 진행한다. 만약 프로젝트의 구현할 기능이 여러 개라면 먼저 가장 핵심적이면서 리스크가 높은 기능부터 구현한다. 그리고 한 기능 구현이 끝나면 그 결과물에 다른 기능을 추가하는 방식으로 차근차근 구현한다.

Iterative Model 장점

리스크를 줄일 수 있다.
프로젝트 조정에 유연하다.
피드백을 상대적으로 빠르게 받을 수 있다.

Iterative Model 단점

프로젝트 구조가 효율적이지 않을 수 있다. (성능 저하)
시간과 자본이 상대적으로 많이 투입된다.

구분

• Sequential Model
  • Waterfall model
  • V-Model
• Iterative Model
  • Spiral Model
  • Unified process

Waterfall Model

5단계

요구사항 분석 ➞ 프로젝트 디자인 ➞ 구현 ➞ 테스트 ➞ 유지보수

특징

사전에 프로젝트의 모든 계획을 세우고 진행한다. Plan-driven
단계가 끝나면 리뷰와 문서 작성를 통해 현 단계를 평가한다. Documentation
현 단계가 끝나야 다음 단계로 진행하고 역순으로 진행하는 것을 지양한다. Sequential
처음에 제시된 직관적이면서 전통적인 방식이다.

장점

관리자가 프로젝트를 관리하기 편하다.
시간을 효율적으로 사용하면서 프로젝트를 진행할 수 있다.

단점

상황변화에 유연하게 대응하기 어렵다.
중간에 사용자의 요구사항이 새로 추가됐을 때 프로젝트에 반영하기 어렵다.
마지막 단계에서 프로젝트 설계 결함, 버그 등 오류가 발생하면 수정하기 어렵다.

적용

프로잭트가 거대하고, 참여하는 사람도 많을 때 목표를 통일하고 문서로 의사소통을 원활히 하기 위해 이 모델로 SW를 개발한다.

동일한 SW를 2번째 개발할 때와 같이, 개발 스택(플랫폼) 결정이 쉽고 프로젝트의 계획이 명확하면서 모든 상황을 통제할 수 있다고 확신할 때 이 모델을 적용한다.

V-Model

7단계

요구사항 분석 ➞ 프로젝트 디자인 ➞ 모듈 디자인 ➞ 구현 ➞ 단위 테스트 ➞ 통합 테스트 ➞ 요구사항 테스트

특징

프로젝트 기획 단계에서 테스트 케이스를 생각하면서 진행한다.

장점

여러 번의 테스트를 거쳐 SW의 질이 높아진다.

단점

Waterfall Model과 비슷하게 상황 변화에 유연하게 대처하기 어렵다.

적용

결과물의 성능과 신뢰도가 중요할 때 이 모델을 적용한다.
주로 HW/SW 접목 프로젝트에서 이 모델을 많이 적용한다.

Prototype

프로젝트 진행 도중 사용자의 요구사항이 계속 바뀌고, 사용자와 개발자의 의사소통이 어렵기 때문에 등장했다.

특징

성능, 코드의 가독성, 예외처리 등은 고려하지 않고 기능 위주로 빠르게 구현한다.

장점

중간 결과물을 눈으로 볼 수 있어 원활한 의사소통이 가능하다.
이를 통해 사용자의 활발한 피드백을 얻을 수 있다.

단점

굳이 꼽자면, 프로토타입을 따로 만드는 것도 일이라는 것이다.

적용

사용자의 이해와 피드백이 중요할 때 프로토타입을 만들어 반응을 살핀다.
사실 거의 모든 프로젝트에서 적용해야 한다.

Spiral Model

단계가 고정되어 있지 않고 중간에 위험요소 탐지 단계가 있다.

4단계 반복

목표 설정, 대안 탐색, 제약조건 파악
➞ 위험요소 식별, 위험요소 대응, 프로토타입 제작
➞ 프로토타입 테스트, 앱 기능 구현, 성능 테스트
➞ 리뷰 및 피드백, 앞으로의 계획 수립

장점

특정한 액티비티를 유연하게 반복하여 SW를 개발할 수 있다.

Unified Process (UP)

한번에 개발을 진행하지 않고, 여러 단계 여러 차례에 걸쳐 개발한다.

프로젝트의 아키텍처(전체 구조)를 확립하는 것을 목표로 Use case를 중심으로 프로젝트 요구사항을 이해한다.

UML의 표현방식에 근거해 개발하는 방식이다. Rational Unified Process(RUP)는 Rational 회사에서 자체적으로 개발한 UP의 일종이다.

UP는 Waterfall 모델에 비해 요구사항 변화에 유연하게 대처할 수 있고, 프로젝트 진행 도중 발생한 리스크를 해결하는데 드는 비용이 낮다.

4단계

Inception ➞ Elaboration ➞ Construction ➞ Transition

Inception

비즈니스 모델을 세워 이 프로젝트가 얼마나 가치있는지, 우리의 능력으로 진행 가능한지, 프로젝트의 요구사항은 어디까지 개발해야 하는지 파악해서 프로젝트를 시작할지 결정한다.

이 단계에선 프로젝트를 시작할지 그만둘지 결정하는 것이 주요 목표다.

Elaboration

비즈니스 모델링을 계속 진행하면서 프로젝트 요구사항의 주요 리스크를 확인한다. 그런 리스크를 줄일 수 있는 아키텍처를 선정하기 위해 여러 아키텍처를 구현하고 테스트해본다.

이 단계에선 리스크를 줄이고 안정적인 아키텍쳐를 구축하는 것이 주요 목표다.

Construction

아키텍처가 정해지고 프로젝트의 상세한 디자인을 결정하는 단계이다. 그러한 것들을 구현하고 테스트하면서 프로젝트 세부 디자인을 결정한다.

Transition

산출물이 나오면 그것을 테스트하면서 버그를 수정한다. 수정이 끝나면 사용자에게 배포한다.

SW 개발 프로세스 비교

SW 개발 프로세스	요약
Waterfall Model	계획을 세워 효율적으로 진행할 때
V-Model	HW/SW 결합 프로젝트 등 안정성과 성능을 우선할 때
Prototype	사용자의 피드백을 빠르고 효과적으로 반영하고 싶을 때
Spiral Model	위험을 초기에 인지하고 관리해야 할 때
UP Model	아키텍처 확립을 우선하고, 유스케이스로 요구사항 파악할 수 있을 때