Computer Science/Software Engineering

[CS][소프트웨어공학] SW 개발 프로세스, 전통적 프로세스 모델, SW 프로세스 개선

y-seo 2023. 10. 8. 03:05
 
 

[1] 소프트웨어 개발 프로세스

  • 소프트웨어 프로젝트란?
    • 수행할 작업을 조직화한 프로세스
    • 비용, 일정, 품질에 대한 목표를 성취하는 것
  • 사전적 프로세스의 정의란?
    • 어떤 일을 하기 위한 특별한 방법
    • 일반적으로 단계나 작업으로 구성
  • 소프트웨어 개발 프로세스란?
    • 순서 제약이 있는 작업의 집합
    • 높은 품질과 생산성이 목표
  • Code-and-Fix
    • 즉흥적 개발, 프로세스가 없는 개발
    • 프로그래밍 → 만족할 때까지 수정 → 개선을 위한 아이디어 짜내기 → 만족할 때까지 수정
    • 문제점
      • 요구, 설계 작업의 중요성을 깨닫지 못함
      • 즉흥적인 방법으로는 사용자의 높은 요구 수준에 도달하기 어려움
      • 계속 고치는 작업이 필요
      • 좋은 SW 구조를 만들 수 없음
  • 프로세스가 없는 개발
    • Code-and-Fix
      • 즉흥적 개발, 프로세스가 없는 개발
      • 프로그래밍 → 만족할 때까지 수정 → 개선을 위한 아이디어 짜내기 → 만족할 때까지 수정
    • 문제점
      • 요구, 설계 작업의 중요성을 깨닫지 못함
      • 즉흥적인 방법으로는 사용자의 높은 요구 수준에 도달하기 어려움
      • 계속 고치는 작업이 필요
      • 좋은 SW 구조를 만들 수 없음
      • 계획이 없기 때문에 작업의 목표가 없음
      • 잘한 부분은 유지하고 잘못된 부분은 계속 고쳐야 하는데 개선의 밑바탕이 없음
      • 공정이 없기 때문에 비용과 일정을 조절할 수 없음
      • 체계적인 테스트 작업이나 품질 보증 차원의 활동에 대한 인식이 없음
      • 결국 발견되지 않은 결함이 남아 계속 고쳐야 하므로 시스템이 더욱 악화

 

 
 

[2] 전통적인 프로세스 모델

1. 폭포수 (waterfall) 모델

  • 역사
    • 1970년대 소규모 프로그램에 적용하는 Code-and-Fix model의 문제 해결을 위해 탄생했다.
    • 처음으로 체계를 잡았다.
    • 현재 나와 있는 모든 모델의 기본이다.
  • 특징
    • 단계적이다.
    • 각 단계가 완전히 완료된 후 다음 단계로 진행된다.
    • 이전 단계로 돌아갈 수 없으므로 피드백이 없다.
    • 순차적으로 간 단계 사이에 중복이나 상호작용이 없다.
    • 각 단계의 결과는 다음 결과가 시작되기 전에 점검한다. 따라서 단계가 끝날 때마다 오랜 시간 길게 검토한다.
    • 결과물 정의가 중요하다. = 각 단계의 산출물 관리가 엄격하다. = 한 단계 안에서 여러 번 반복하여 산출물을 낸다.
    • 진행 과정을 세분화하여 관리하기에 용이하다.
    • 목표 시스템이 후반부에 가서야 구체화 한다. 따라서 중요한 문제점이 나중에 발견 되기도 한다. 그러나고치지도 못하여 축적된다.
  • 적용 시 고려사항
    • 관리가 상대적으로 쉬우나 요구 사항의 변경에 대한 대응력이 떨어진다.
    • 기술 위험이 낮고 유사한 프로젝트 경험이 있을 경우 적용한다.
    • 요구사항이 비교적 명확히 정의되어 있는 경우 적용한다.
  • 제일 안 좋은 점
    • 앞 단계에서 결과가 만족스럽지 못하면 다음 단계로 못 넘어간다.
    • 앞 단계에만 치중하다 보니 뒷 단계에서는 시간이 부족하다.

 

2. 프로토타이핑 모델

  • 정의
    • 프로토타입(임시)을 만드는 모델이다.
    • 사용자의 요구사항을 충분히 분석할 목적으로 시스템의 일부분을 일시적으로 간략히 구현한 다음 다시 요구 사항을 반영하는 과정을 반복한다.
  • 목적
    • 기능 목적이 아니라 시나리오 정도만 목표로 삼는다.
    • 요구 분석의 어려움 해결을 위해 사용자의 참여 유도한다.
    • 사용자와의 커뮤니케이션 수단으로 활용 가능하다. 따라서 요구사항 파악에 용이하여 요구사항이 분명하지 않을 때 유용하다. 이를 통해 요구사항 도출과 이해 가능하다.
    • 사용자 자신이 원하는 것이 무엇인지 구체적으로 잘 모르는 경우에 간단한 시제품으로 개발할 수 있다.
    • 개발 타당성를 검토한다.
    • 요구사항 검증을 위해 프로토 타입 개발한 후, 폭포수 모델에 따라 전체 시스템 개발하여 폭포수 모델의 단점을 보완할 수 있다.
  • 장점
    • 프로토타입을 통해 요구 사항 도출이 용이하다.
    • 실물화 덕분에 시스템 이해와 품질이 향상된다.
    • 개발자와 사용자 간의 의사소통이 용이하다.
  • 단점
    • 프로트타입 결과를 최종 결과물로 오해할 수 있다.
    • 잘못된 프로토타입 개발 시 폐기 처분에 따른 경제적인 손실이 발생한다. (시간/돈)
    • 계속 개선하기 때문에 프로토타입에 대한 산출물 관리가 어렵다.

 

3. 진화적 모델

  • 특징
    • 진화적 개발이다
    • 빠른 시간 안에 시장에 출시해야 유리하기 때문에 시스템을 나누어 release 할 때마다 기능의 완성도를 높인다.
    • 완성도가 좀 떨어져도 일단 시장에 내놓는 전략을 가진다.
    • 개발된 모듈을 upgrade 하는 방식으로 SW가 진화한다.
  • 장점
    • 사용자 요구를 빠르게 반영한다.
    • 새로운 기능의 SW에 대한 시장을 빨리 형성한다. (사용자는 생각보다 본인이 원래 사용하던 것을 잘 바꾸지 않기 때문에 시장 선점 가능하다.)
    • 가동 중인 시스템에서 일어나는 예상하지 못했던 문제를 신속하고 꾸준하게 고쳐나갈 수 있다.
  • 단점
    • 프로젝트 관리가 복잡하다.
    • 반복적인 프로세스로 끝이 안보일 수 있으므로 실패의 위험이 커진다.

 

4. 나선형(spiral) 모델

  • 특징
    • 폭포수 모델의 장점 + 프로토타입 모델의 장점
    • 위험 요소를 분석하고 해결할 수 있도록 지원하는 모델이다.
    • 위험 평가에 대한 대안 여부에 따라 진행을 결정한다.
    • 여러 번의 점증적인 릴리즈를 한다. ( ≠ 진화적 모델 )
      • 처음에는 적게 했다가 갈수록 커진다.
      • 여러 기능 중 우선 순위를 부여해 중요한 것부터 개발한다.
    • 단계적 구성을 가진다.
  • 장점
    • 대규모 시스템 개발에 적합하다.
    • 반복적인 개발과 테스트로 강인성(robustness)이 향상된다.
      • 점증적인 것들이 갖는 특성이기도 하다
      • 사이클을 돌수록 앞의 것들이 여러 번의 테스트를 거치며 견고해진다.
    • 한 사이클에 추가 못한 기능은 다음 단계에 추가한다.
  • 단점
    • 관리/위험 분석이 중요하며 난이도가 높다.
    • 개발기간이 장기화 될 수 있다.
  • 적용
    • 재정적/기술적 위험 부담이 큰 경우
    • 요구 사항/아키텍쳐 이해가 어려운 경우

 

5. 점증적(Incremental) 모델

  • 특징
    • "사용자 요구사항의 일부분, 제품의 일부분을 반복적으로 개발 → 대상 범위 확대 → 최종 제품 완성" 순서로 진행한다.
    • 증분들 생성하고  따로따로 개발하여 통합한다.
    • 반복적이긴 하지만, 각 증분마다 실행 가능한 제품을 내놓는다.
    • 폭포수 모델의 변형이다.
    • 나선형 모델을 포함한다.
    • 진화적 모델은 완성도는 떨어지더라도 10개 기능 모두 만들어 내보내지만, 점증적 모델은 10개 중 5개 먼저 만들고 이후 2개 추가하여 만든다고 볼 수 있다.
    • 규모가 큰 개발인 조직인 경우 병행 개발 가능하기 때문에 증분을 동시에 개발하기도 한다.
  • 릴리즈 과정
    • "일부를 만들어 내놓고 → 더하여 내놓고 → 더하여 내놓고" 를 반복한다.
    • 증분 계획을 정확히 해야 한다. 정확하지 않으면 끝나지 않는 진화적 모델의 단점을 닮아 갈 수도 있다.
  • 장점
    • 앞선 release 버전은 반복된 테스트를 거치기 때문에 강인성이 향상된다. ( = 나선형 모델 )
  • 단점
    • 여러 번 개발 해야 하는 것들(반복적인 모델)은 관리가 어렵다. ( = 진화적 모델 )

 

6. V 모델

  • 특징
    • 폭포수 모델 확장
    • 감추어진 반복과 재작업이 이루어진다.
    • 작업 결과 검증에 초점이 맞춰져 있다.
    • 모든 과정에서 하는 일들로 이루어져 있지만 단계별로 test에 대한 기준이 엄격하여 따로 뺀 모델이다.
    • 미리 분석 단계에서 테스트 기준을 미리 만들어 둔다.
  • 장점
    • 오류 ↓
    • 안정성 ↑
  • 단점
    • 폭포수 모델을 적용하여 되돌아 가지 않는다. 따라서 변경 다루기 어렵다.
  • 적용
    • 요구사항이 정확히 이해되는 작은 규모 개발 시 유용하다.
    • 대규모 개발 시 테스트에 많은 시간 소비하여 적합하지 않다.
    • 신뢰성이 높이 요구되는 분야에 사용된다. ( 예시 : 국방, 의료 시스템 )

 

 
 

[3] 소프트웨어 프로세스 개선

  • Humphrey(1995)는 "소프트웨어 제품의 품질은 소프트웨어 제품을 개발하고 유지보수 하는 데에 사용하는 프로세스의 품질에 의해 결정된다"라고 이야기 하셨다. 
  • SW 개발의 문제점
    • 낮은 생산성과 품질 저하가 문제점이다.
    • SW 프로젝트의 납기 지연과 비용 초과가 일어나고 있다.
    • DoD 소프트웨어 프로젝트 중 품질/납기/비용 충족이 16%, 납기지연 및 비용초과가 53%, 실패가 31%를 차지한다. (F-22의 80%, B-2의 65%가 소프트웨어) [2015년 보고서]
  • 프로세스 개선의 필요성
    • 좋은 프로세스가 없으면 품질을 계획하거나 관리할 수 없다.
    • 좋은 품질을 얻었더라도 그 이유가 무엇인지, 다시 또 반복적으로 좋은 품질을 얻을 수 있을 것인가에 대한 확신이 없다.
  • 문제 해결 방향
    • 하드웨어 개발 접근 방법의 도입하여 제도 및 생상 공정과 철저한 품질 관리 및 지속적인 공정 개선이 필요하다.
  • 방법
    • 국제 표준 인증제도들이 있다.
      • CMM : 프로세스를 얼마나 잘했는지 5단계로 구성되어 있다.
      • CMMI
      • SPICE
    • 6 시그마 (6σ) : 기업에서 전략적으로 완벽에 가까운 제품이나 서비스를 개발하고 제공하려는 목적으로 정립된 품질 경영 기법 또는 철학
    • 기타 프로세스 표준 : ISO 12207, ISO 29110, ISO 15288 등
    • 국내 프로세스 개선 : 정보통신산업진흥원의 SW 프로세스 품질인증제도
      • SP인증 : 프로세스에 대한 것
      • GS 인증 : 좋은 SW에 대한 것으로 필수이다.
      •  
저작자표시