소프트웨어 개발 프로세스

소프트웨어 개발 프로세스와 SDLC(Software Development LifeCycle)

프로세스 모델 정의 장점

• 소프트웨어 개발에 일관된 구조 제공
• 프로젝트 관리를 위한 하부 구조 제공
• 프로세스 개선 및 자동화 가능
• 용어 표준화

다양한 생명주기 모델

– 폭포수, 병행, 프로토타입, 반복/점증, 나선형, 재사용, V

코드 수정 모델

• 과거 초기에 사용되 었다
• 단지 코드 작성 고객 만족할 때까지 수정
• 짧은 시간, 단순 문제 해결에 적합하다.
• 프로세스가 구체적으로 정의되지 않으므로 관리 어렵다
• 문서화 생략
• 현대 프로젝트에 적용 어려움
• 유지보수 비용이 많이 든다.

 

 

 

 

 

 

 

 

폭포수 모델

순차(sequential) 모델

• 1970년 Royce 제안후 폭포수 모델을 수정/확 장한 다양한 모델 출현
• 역으로 흐르지 않고 다음 단계로 순차적 진행
• 과거에 적용된 고전 모델
• 대부분 프로젝트에 기본 적용 모델
• 다른 모델들의 기본 구조 모델
• 엄격한 문서 중심 모델
• 전 단계 피드백에 의한 수정 가능
• 문제 영역을 잘 알거나 이해하여 초기에 사용자 요구를 명확하게 파악할 수 있는 프로젝트 적용
• 시간이 지나면 사용자 요구를 정확히 정의하는 것이 어렵다
• 반복적인 특직을 적용이 어렵다.

병행 모델

• 병행 개발 강조
• 분석후 설계에서 병행 수 행 가능한 서브 프로젝트 로 분리
• 폭포수에 비해 개발 기간 단축 가능
• 독립적인 서브 프로젝트 로 분리 어려운 경우 적용 어려움
• 통합 비용이 매우 비쌀 수 있다.

 

 

 

 

 

 

 

 

 

프로토타임 모델

간단하게 시제품 제작, 피드백 통해 사용자 요구 명확하게 파악 후 빠른 시간 시제품 개발

모델 분류

• 폐기 프로토타입 모델
• 짧은 시간에 사용자 요구 파악 후 프로토 타입 버린다.

진화 프로토타입 모델

• 사용자 요구 파악을 위해 빠른 제작
• 핵심 기능 포함
• 계속 정제되어 최종 제품으로 진화
• 품질 고려

단점

• 분석 결과인 요구 명세서의 중요성을 등한시할 수 있다.
• 필요 이상의 기대 심리를 유발 할 수 있다.

반복/점증 모델

폭포수 모델의 단점 극복을 위해 나왔다.

현대 프로젝트의 특징

• 반복적
  • 사용자 요구 변화에 대응하여 반복적으로 개발
• 점증적
  • 중요 기능을 먼저 개발 후 다른 기능들을 점증적으로 개발한다.

단점

• 통합 테스트 비용이 비쌀 수 있다.
• 점증의 적당한 크리를 결정하는 것이 어렵다
• 요구 분석을 개발 후반부 까지 수행하지 않기 때문에 재사용할 수 있는 컴포넌트를 파악하는 것이 어렵다.

점증 과정에서 활동에서 소요되는 비용

초기에는 요구분석이 많이 소요된다

후반부로 갈수록 테스트 비용이 급격히 증가한다.

• Barry Boehm이 제안했다.
• 폭포수 특징 + 반복/점증 특징 + 위험분석
• 반복적인 나성형
• 각 나선의 주기 별로 위험분석 활동을 강조하여 위험 요인을 분석하고 최소화하여 위험 부담을 줄이기  위한 모델이다. -> 품질 향상
• 위험에 대한 대책 수립이 가능하여 프로젝트가 실패로 끝날수 있는 위험에 대응할 수 있는 모델
• 대규모 프로 젝트에 적용

단점

완변하게 일치하는 재사용 컴포넌트가 없는 경우, 최종 사용자 요구를 만족하지 않는 결과를 보일 수 있다.

라이브러리를 생성하고 관리하는 것은 어렵다

재사용 모델

=CBD 모델

사용자 요구 변화에 신속하고 유연한 대처 가능하다.

• CD 모델
  • 컴포넌트 자체 개발
• CBSD 모델
  • 컴포넌트 기반 시스템 개발

가장 비용이 많이 나온다.
많은 사람들이 공통적으로 사용하는 도매인이 무엇인지 뽑아내는 것이 어렵다.

UP 모델

UP(RUP) 방법론

• 1990 년대 객체지향 방법들의 통합 노력의 결과물
• UP(RUP) 프로세스 + UML

UP 프로세스

• 반복 점증 개발과 사용자 상호작용 강조하며 시간 경과에 따라 시스템이 어떻게 진화하는지 묘사
• 4 단계 (phase)+ 10 작업흐름 (workflow)
• 2 차원 프로세스

phase(단계)

시작(Inception)

폭포수 모델의 계획 활동에 해당한다.

비즈니스 모델링과 요구 추출 작업을 수행한다.

시스템 개발이 가능한지, 개발 가치가 있는지 출분히 조사하여 결정한다.

대부분의 분석은 정제 단계에서 수행

정제(Elaboration)

개발 방법과 관련이 깊다

시작 단계의 결과물을 계속해서 정제하여 구체화된다.

시작 단계의 기본 요구들을 반복 정제

요구들을 안정화 시키는 단계이다.

분석, 설계를 위한 모델링 작업을 수행한다.

구축(Construction)

구현단계

전이(Transition)

테스트와 배치 작업은 전이 단계에서 주로 수행된다.

작업 흐름(workflow)

공학 작업흐름

시스템 개발과 기술적인 작업

비즈니스 모델링, 요구, 분석, 설계, 구현, 테스트, 배치 작업을 포함한다.

지원 작업흐름

시스템 개발을 지원하는 작업들을 포함

• 프로젝트 관리
• 형상과 변경 관리
• 환경

Agile 모델

가볍고, 적응 가능한 프로세스

XP, Scrum 유명한 것이 있다.

애자일 선언문

• 프로세스나 도구 보다 개인 능력(특성)과 상호작용이 더욱 중요하다.
• 동작하는 실행 소프트웨어가 더욱 중요하다
• 지속적인 상호 협력이 중요하다.
• 변경에 대응하는 것이 더욱 중요하다.
• 개발 과정 동안 발생하는 변화를 수용하는 것이 더둑 중요하다.
• 직접 마주보는 대화가 효과적이다.
• 실행 소프트웨어는 주요 측정 방법이다.
• 지속 가능한 개발을 장려한다.
• 지속적으로 노력하는 것은 시스템의 유연성을 높인다.
• 단순함이 근본이므로 불필요한 작업은 하지 않는다.
• 자주(율)적 팀으로부터 생산된다.

자주적 팀

• 주어진 환경에 따라 수행 작업 , 개발 프로세스 자체 구성 가능 유연성
• 결과물 인도 작업이나 일정 자체 수립 가능
• 자체 관리에 의한 책임감 , 팀원 사이의 협력 증진

UP 는 반복 , 점증 , 적응 , 진화 특징을 갖지만 애자일과 다르게 분석 설계 모델링 중시

애자일 방법 문제점

• 사용자의 지속적인 참여 어려움
• 코드 중심에 의한 유지보수 어려움
• 사용자의 지속적인 참여에 의한 비용 증가

XP 모델

게획

• 청취 작업부터 시작한다.
• 우선 순위 정한다.
• 요구에 대한 개발 비용을 추정
• 더욱 짧은 기간에 완수할 수 있을 정도로 요구를 분리한다.
• 이야기를 검증하기 위해 인수 테스트 기준을 정의한다.
• 사용자 이야기를 추가하거나 제거할 수 있다.
• 진행 상황을 고려하여 계획을 수정한다.

설계

• 단순 설계 원리에 따라 현재 반복 주기에서 선택된 사용자 이야기에 대해서만 간단하게 설계한다.
• 개발자가 스스로 생각하는 추가 기능에 대한 설계를 금지한다.
• 상세한 문서 생성을 최소화 한다.

코딩

• 요구 기능을 확인하기 위한 단위 테스트 케이스를 개발한다.
• 두 명이 한 조가 되는 짝 프로그래밍에 의해 코드를 생성한다.
• 한사람은 코드 오류에 대한 교차,다른 한 사람은 코드 표준의 준수 여부 검사한다.
• 스파케티 코드 구조를 개선하기 위해 리팩토링을 수행한다.
• 이것을 수행후 코드 실행 결과는 동일해야 한다.