소프트웨어 개발 프로세스 모델의 종류와 단계

소프트웨어 프로세스는 소프트웨어 시스템을 개발하기 위해 필요한 일련의 구조화된 활동들을 의미합니다. 이러한 프로세스는 소프트웨어 개발의 효율성과 품질을 높이기 위해 체계적으로 관리되고 수행됩니다. 아래에서 소프트웨어 프로세스의 주요 구성 요소와 다양한 소프트웨어 프로세스 모델에 대해 자세히 설명하겠습니다.

 

소프트웨어 프로세스들의 기본 4가지 활동

 

1. 명세 (Specification)

정의: 시스템이 수행해야 할 기능과 요구사항을 명확히 정의하는 단계입니다.
목적: 고객의 요구를 정확히 이해하고, 개발할 시스템이 어떤 기능을 제공해야 하는지 명확히 합니다.
활동 예시: 요구사항 수집, 요구사항 분석, 요구사항 문서화

 

2. 설계 및 구현 (Design & Implementation)

정의: 시스템의 구조를 설계하고, 실제로 소프트웨어를 개발하는 단계입니다.
목적: 시스템의 아키텍처를 정의하고, 설계를 바탕으로 코드를 작성하여 소프트웨어를 구현합니다.
활동 예시: 시스템 아키텍처 설계, 모듈 설계, 코딩, 단위 테스트.

 

3. 검증 (Validation)

정의: 개발된 소프트웨어가 고객의 요구사항을 충족하는지 확인하는 단계입니다.
목적: 소프트웨어가 기대한 대로 작동하며, 버그나 오류가 없는지 검증합니다.
활동 예시: 통합 테스트, 시스템 테스트, 사용자 수용 테스트, 품질 보증.

 

4. 진화 (Evolution)

정의: 고객의 요구나 환경 변화에 따라 소프트웨어를 수정하고 개선하는 단계입니다.
목적: 소프트웨어의 수명을 연장하고, 변화하는 요구에 유연하게 대응합니다.
활동 예시: 유지보수, 기능 추가, 성능 개선, 버그 수정.

 

---

소프트웨어 프로세스 모델

소프트웨어 프로세스 모델은 소프트웨어 개발 프로세스를 추상적으로 표현한 것으로, 소프트웨어 개발 프로세스는 프로세스 모델의 상속 관계로 볼 수 있습니다.

 

소프트웨어 개발 생명 주기(SDLC, Software Development Life-Cycle) 모델은 소프트웨어 개발 과정에서 수행되는 단계별 접근 방식을 나타내는데, 크게 Waterfall 모델과 Iterative 모델로 나눌 수 있습니다.

 

 

1. Waterfall Model

• 특징: 체계적이고 순차적인 개발 프로세스로, 원칙적으로 한 단계가 완료돼야 다음 단계로 갈 수 있습니다.
• 단계: 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수.
• 장점: 요구사항이 일찍 고정되거나 대규모 시스템 등에 개발할때 용이하고 선형적으로 개발할수 있다는 점이 있습니다.
• 단점: 유연성이 없어서 요구사항의 변경에 대응하기 어렵습니다.

---

 

2. 점진적, 진화적 모델 (Incremental & Evolutionary Model)

• 특징: 여러 개의 increment으로 나누어 점진적으로 개발되고 나중에 통합되는것이 점진적 개발이라고 합니다.
• 마지막 버전이 최종적으로 제공되는 형태로 된다면 진화적 개발이라고 합니다.
• 주기적인 피드백과 조정작업을 통한 시스템의 점진적인 성장, 명세 및 설계의 진화를 목적으로 함
• 장점: 초기 제품을 빠르게 제공할 수 있으며, 변경에 유연하게 대응 가능.
• 단점: 프로세스가 가시적이지 않고 여러 increments가 동시에 개발돼서 진행상황을 확인하기 어렵고 문서화가 쉽지 않습니다.
• 또한 새로운 increments가 추가됨에 따라 시스템 구조가 저하되거나 손상되고, 변경을 통합하는 것도 비용이 많이 들 수 있습니다.

---

3. 스파이럴 모델 (Spiral)

 

 

 

• 특징: risk analysis를 중심으로 한 반복적인 개발 모델로, 각 반복 주기마다 계획, 위험 분석, 공학, 평가 단계를 거칩니다.
• 장점: 위험 관리에 효과적이며, 복잡한 프로젝트에 적합합니다.
• 단점: 비용이 높고, 관리가 복잡할 수 있습니다.

---

4. 컴포넌트 기반 개발 (Component-Based Development, CBD)

• 특징: 소프트웨어 재사용 기반 모델로 기존 구성요소나 시스템을 통합해서 시스템을 구성합니다
• COTS (Commercial-off-the-shelf, 상용SW) 시스템/구성 요소를 사용합니다
• 장점: 개발 속도가 빠르고, 유지보수가 용이함.
• 단점: 적절한 컴포넌트를 찾는 것이 어려울 수 있음.

---

5. 애자일 (Iterative - Agile)

• 특징: 짧은 반복 주기(스프린트)로 개발을 진행하며, 지속적인 피드백과 협업을 중시합니다.
• 특성: iterative(반복적), Incremental(점진적), Evolutionary(진화적)이다.
• 장점: 변화에 빠르게 대응할 수 있으며, 고객의 요구를 지속적으로 반영.
• 단점: 프로젝트 관리가 어려울 수 있으며, 팀 간의 협력이 필수적.

 

애자일의 기본가치 vs waterfall 모델

1. Individuals and Interaction(개인간 상호소통) vs Process and Tools(도구와 프로세스에 의존)
   • 개인 능력이 뛰어난 경우가 대부분이라 개인의 역량으로 해결과 상호 소통합니다.
2. Working Software(코드와 리팩토링 중심) vs Documentation(문서 중심)
   • 빠르게 바뀌고 반복하므로 문서가 그렇게 중요하지 않습니다.
3. Customer collaboration(고객과 소통) vs Contract negotiation(SRS 계약서 등)
   • Requirement에 user를 많이 개입시킨다
4. Responding to change vs Following a plan(waterfall pm의 중요 역량)
   • 계획적보단 진화적 모델이므로 빠르게 변화한다.

---

6. UP (Rational Unified Process)

 

 

 

• 특징: 이터레이션을 기반으로 한 구조화된 프레임워크로, Risk-Driven, Client-Driven, Use-Case-Driven, 아키텍쳐 중심 프로세스
• 9가지 원칙이랑 4가지 단계가 있습니다.
  • business modeling, requirements capture, Analysis & Design, implementaiton, test, deployment, configuration, PM, environment
  • Inception, Elaboration, Construction, Transition
• 장점: 명확한 단계와 역할 분담으로 체계적인 개발이 가능.
• 단점: 복잡성이 높고, 초기 설정에 많은 시간이 소요될 수 있습니다.

객체 지향(OO, Object-Oriented) 소프트웨어를 개발하는 데 있어 사실상 업계 표준으로 자리 잡은 방법론입니다.

---

UP의 Phase

1. Inception : AS-IS 모델에서 process reengineering으로 TO-BE 모델을 만들어서 비즈니스 모델을 산출합니다. 비즈니스 요구사항 식별을 통해 시스템의 비전과 스코프를 파악합니다. (SRS가 fixed됩니다.)
2. Elaboration : 분석과 디자인을 통해서 베이스라인 아키텍쳐를 만듭니다.
3. Construction : 실행 가능한 시스템(Initial Capability)을 구현합니다.
4. Transition : 사용자에게 인도합니다.(Product Release)

---

UP의 마일스톤

milestone은 각 페이즈의 산출물로, milestone이 나와야지 다음 페이즈로 넘어갑니다.

그 중에서 가장 노력을 많이 기울이는 Phase가 Elaboration(분석과 설계)인데, 이 부분에서 최종 시스템의 이른 버전인 Baseline Architecture가 나옵니다.

베이스라인 아키텍쳐는 전체 시스템의 부분 집합이므로 skeleton System이라고도 불리웁니다.

 

Stable한 베이스라인 아키텍쳐는 잘만들어진 시스템이 됐을때, 구조와 행위에 대해서 약간의 차이만 일어났을때 안정적이라고 합니다.

이 skeleton 시스템이 전체 코드의 15퍼센트만 포함한다고 해도 Key decisions를 Validate하기에 충분합니다.

---

베이스라인 아키텍쳐의 정제

아래 그림을 보면 Elaboration 완료 시점(베이스라인 아키텍쳐가 구축됐을때) 산출물 작성시점이랑, Construction(베이스라인 아케텍쳐는 살짝만 변경되고 코드 작성에 집중하는 Phase)의 산출물 작성 시점을 비교해서 볼수 있습니다.

 

Elaboration 완료 시점을 보면 오른쪽과 비교했을때 10퍼센트만 이루어진것으로 보이는데, 핵심 로직만 작성하고 넘어가는 단계이기 때문에 기술적으로 중요하거나 비즈니스 적으로 중요한 Primary Fuction들만 정의해서 시작을 하는 것을 볼수 있습니다.

 

분석 설계 모델은 유스케이스에 대해서 분석하고, 구현 모델은 유스케이스에 대해서만 구현하고, 테스트 케이스도 유스케이스만 테스트하도록 작성합니다.

그러므로 유스케이스에서 시작하는 것으로 볼수 있고 유스케이스가 정말로 중요합니다.

배치모델만 아키텍쳐 부분에서 다 하는것으로 볼수 있고, 코드를 작성하면서 나머지 부분도 다 정제(Refine)되는것을 볼수 있습니다.

아키텍쳐 기술서의 작성 수준을 보면 Elaboration에서 Construction을 마칠때 더 자세해 지고 Refined되는것 말고는 큰 차이가 보이지 않습니다.

---

주요 UP Disciplines(원칙들)

---

7. RUP (Rational Unified Process) - UP의 구현(상속)체

정의: RUP는 UP의 변형된 방법론으로, IBM Rational에서 제안하고 지원하는 구체적인 소프트웨어 개발 프로세스입니다. UP의 원칙을 기반으로 하여 보다 구체적으로 정의된 방법론입니다.

특징:

RUP는 IBM의 Rational Software가 지원하는 상업적인 프로세스로, UP의 개념을 구체화하고, 실무에서 사용할 수 있도록 구체적인 가이드라인, 템플릿, 툴 지원을 제공합니다.

UP가 일반적인 프레임워크라면, RUP는 UP의 원칙을 실제로 적용할 수 있도록 세부적으로 정의된 버전입니다.

 

소프트웨어 프로세스 모델 선택 시 고려 사항

적절한 소프트웨어 프로세스 모델을 선택하기 위해서는 다음과 같은 요소들을 고려해야 합니다:

• 프로젝트의 규모와 복잡성: 대규모 프로젝트는 스파이럴 모델이나 RUP와 같은 구조화된 모델이 적합할 수 있습니다.
• 요구사항의 명확성: 요구사항이 명확하지 않거나 자주 변경될 경우, 애자일 모델이 더 유연하게 대응할 수 있습니다.
• 개발 팀의 경험과 역량: 팀이 특정 프로세스 모델에 익숙한지 여부도 중요한 고려 사항입니다.
• 고객의 참여 수준: 고객의 지속적인 피드백이 필요한 경우, 애자일 모델이 효과적일 수 있습니다.
• 시간과 예산: 제한된 시간과 예산 내에서 개발을 완료해야 하는 경우, 인크리멘탈 모델이나 컴포넌트 기반 개발이 유리할 수 있습니다.

 

결론

소프트웨어 프로세스는 소프트웨어 개발의 성공을 좌우하는 중요한 요소입니다. 다양한 소프트웨어 프로세스 모델 중에서 프로젝트의 특성과 요구사항에 맞는 적절한 모델을 선택하는 것이 중요합니다. 각 모델은 고유한 장점과 단점을 가지고 있으며, 상황에 따라 유연하게 적용하는 것이 성공적인 소프트웨어 개발의 열쇠입니다.

 

다음 포스트에서는 소프트웨어 프로세스의 4가지 기본 활동에 대해서 더욱 자세히 알아보겠습니다!