[소프트웨어공학] 02. 프로세스와 방법론(1)

• 프로세스: 어떤 일을 하기 위한 특별한 방법으로 단계나 작업으로 구성됨
• 방법론(methodology): 정의된 작업들을 어떤 순서로 어떤 방법으로 하는가를 다루는 것

  구분	프로세스	방법론
  특징	단계적인 작업의 틀을 정의한 것 무엇을 하는가에 중점 결과물의 표현에 대해 언급 없음 패러다임에 독립적 각 단계가 다른 방법론으로도 실현 가능	프로세스의 구체적인 구현에 이름 어떻게 하는가에 중점 결과물을 어떻게 표현하는지 표시 패러다임에 종속적 각 단계의 절차, 기술, 가이드라인 제시
  사례	폭포수 프로세스 나선형 프로세스 프로토타이핑 프로세스 Unified 프로세스 애자일 프로세스	구조적 분석, 설계 방법론 객체지향 방법론 컴포넌트 애자일 방법론

---

2.1 소프트웨어 생명주기(Software Life Cycle)

• 요구분석 ➡︎ 설계 ➡︎ 구현 ➡︎ 테스팅 ➡︎ 유지보수

 

2.2 프로세스

• 소프트웨어 개발에 대한 기술적, 관리적 이슈를 다루는 작업
• 여러 컴포넌트 프로세스( = 부프로세스)들이 모여서 이룸

2.2.1 프로세스 종류

• 개발 프로세스: 가장 핵심
• 프로젝트 관리 프로세스: 작업 계획 및 모니터링
• 소프트웨어 형상관리 프로세스: 변경을 관리하여 제품의 일관성 유지
• 프로덕트 엔지니어링 프로세스: 개발 프로세스 + 프로젝트 관리 프로세스 + 소프트웨어 형상관리 프로세스
• 프로세스 관리 프로세스: 소프트웨어 프로세스는 동적인 요소로 새로운 기술과 도구를 도입함으로써 수정되어야 하며 이를 관리

2.2.2 프로세스 정의

• 입력(진입 조건) ➡︎ 프로세스 단계 / 검토와 검증 ➡︎ 출력(출구 조건), 프로세스 관리를 위한 정보

2.2.3 좋은 프로세스의 특성

• 예측 가능성(Predictability)
  • 어떤 프로젝트 안의 프로세스의 결과가 프로젝트를 완성하기 전에 얼마나 정확히 예측될 수 있는가
  • 품질 관리는 과거에 개발한 제품의 품질을 따져보면 예측 가능 
• 테스팅과 유지보수 용이성
• 변경 용이성
  • 고객의 요구는 끊임없이 변할 수 있기 때문에 변경을 쉽게 다룰 수 있는 프로세스 요망
• 결함 제거 용이성
  • 개발 단계가 진행될수록 수정 비용이 증가함
  • 개발 각 단계에서 발생한 오류는 그 단계에서 수정되어야 함

 

2.3 프로세스 모델

2.3.1 폭포수 모델

• 가장 오래되고 널리 사용된 프로세스 모델
• 계획부터 유지보수까지 위에서부터 순서대로 수행
• 직능 중심의 프로젝트 조직 가능, 파이프라인 형태 작업 가능
• 크고 복잡한 오래 지속되는 프로젝트에 적합
• 검증을 강화하는 관점에서 V(Verification) 모델로 확장
• 장점
  • 단순하여 이해하기 좋음, 단계가 명확하여 프로세스 진행 상황 관리 쉬움
  • 요구 사항이 명확한 대규모 시스템을 장기간 개발할 때 적합
• 단점
  • 이전의 문제가 발견되지 않고 넘어가는 경우 단점이 됨
  • 순차적으로 진행되는 만큼 돌아가서 재작업을 할 수 없고 마무리 단계에서 큰 비용을 부담하며 작업

2.3.2 프로토타이핑 모델

• 요구 사항에 대한 피드백을 받기 위해 시스템을 실험적으로 만들고 사용자에게 보여주고 평가하게 하는 방법
• 일회용: 한번 쓰고 버림 / 진화형: 계속 발전시켜 나감
• 장점
  • 문제점을 빨리 파악하여 요구 사항에 반영 가능
  • 설계에서 기술적인 문제가 있을 때 프로토타입을  만들어 타당성 확인 가능
  • 의사소통이 원활해지며 요구사항 빨리 수용 가능
• 단점
  • 프로토타입 개발에 많은 비용이 듦
  • 고객이 프로토타입을 완성에 가까운 제품으로 오인하여 불필요하고 과도한 요구를 할 수도 있음

2.3.3 나선형 모델

1. 네가지 단계를 반복순환하며 시스템 확대
   • 목표, 방법, 제약 조건 결정
   • 위험 요소 분석 및 해결
   • 개발과 평가
   • 다음 단계의 계획
2. 장점
   • 소프트웨어 품질 향상 가능
   • 오류 수정과 앞 주기에서 이루어지는 변경에 유연한 대처 가능
3. 단점
   • 초기 위험 분석을 잘못하면 실패로 끝날 수 있음
   • 재정적 혹은 기술적으로 위험 부담이 크거나 요구사항이나 아키텍처 이해가 어렵거나 성능에 문제가 있거나 중심 되는 기술에 문제가 있는 경우에 적합

2.3.4 진화적 모델

• 시스템의 핵심 부분에 대해 기능이 명확한 부분을 우선적으로 개발하고 개선하여 진화시키는 방법
• 객체지향 패러다임에 적합한 Unified 프로세스 모델로 제안
• 점증적인 발전: 서브시스템 릴리스 ➡︎ 새로운 기능 추가
• 반복적인 발전: 처음부터 전체 기능을 대상, 릴리스 할 때마다 더 완벽히 개발
• 장점
  • 몇 가지 기능이 부족해도 초기에 사용 교육 가능
  • 이전에는 없었던 기능을 가진 소프트웨어에 대한 시장 선점 가능
  • 예상치 못한 문제 신속한 수정 가능
  • 개발자들이 릴리스마다 다른 영역에 초점을 둘 수 있음
• 단점
  • 프로젝트 관리가 복잡하여 소규모 프로젝트와는 맞지 않음
  • 반복적인 프로세스로 끝이 안보일 수 있으며 이는 실패의 위험이 높아짐
  • 위험 분석에 크게 의존

2.3.5 Unified Process

• 여러개의 싸이클로 구성
• 도입(Inception)
  • 간단한 유스케이스 모델과 소프트웨어 구조, 프로젝트 계획 작성
• 정련(Elaboration)
  • 대부분의 유스케이스를 작성하며 아키텍처 설계를 나타내는 UML 다이어그램 그림
• 구축(Construction)
  • 남아 있는 유스케이스에 대해 구현하고 시스템에 통합
• 전환(Transition)
  • 시스템 배치 작업
  • 사용자 교육 및 베타 테스팅을 통해 결함 수정, 기능 개선
• 장점
  • 방법론과 프로세스가 잘 문서화되어 있고 쉽게 접할 수 있어 교육받기 좋음
  • 고객 요구 변경 관련 리스크 적극적 해결 가능
  • 반복적인 개발 싸이클로 통합하여 노력과 시간을 줄일 수 있음
  • 쉽고 빠른 코드 재사용 가능
• 단점
  • 프로세스가 너무 복잡하여 전문가가 아니면 이해 및 적용이 어려움
  • 협동 및 의사소통의 자세한 가이드가 없음
  • 조직화되지 않은  개발로 알려지지 않은 형태의 소프트웨어 개발로 이어질 수 있음