02 ProcessPermalink

프로세스Permalink

• 정의
  • 어떤 일을 하기 위한 특별한 방법으로 일반적으로 단계나 작업으로 구성됨
• 소프트웨어를 개발하는 과정, 즉 작업 순서
  • 순서 제약이 있는 작업의 집합
  • 높은 품질과 생산성이 목표
• 프로세스가 없는 개발 = Code-and-fix
  • 문제점
    • 요구나 설계 작업의 중요성을 깨닫지 못함
    • 신중하게 잘 설계하지 않으면 소프트웨어 구조가 나빠짐
    • 계획이 없어 작업의 목표가 없음
    • 체계적인 테스트 작업이나 품질 보증 차원의 활동에 대한 인식이 없음

프로세스와 방법론의 비교Permalink

소프트웨어 프로세스Permalink

• 소프트웨어 프로젝트
  • 수행할 작업을 조직화한 프로세스를 이용
• 프로세스 명세
  • 프로젝트에서 수행하여야 하는 작업과 이들의 수행 순서를 정의
• 프로세스 모델
  • 일반적인 프로세스를 기술한 것
  • 작업의 단계와 순서

프로세스의 종류

• 작업 결과와 검증 조건을 명확히 정의하여야 함

옳바른 프로세스의 특징Permalink

1. 예측 가능성
2. 테스팅과 유지보수 지원
3. 변경을 쉽게 다룰 수 있는 프로세스
4. 결함 제거

소프트웨어 개발 프로세스Permalink

• 프로세스 모델
  • 일반적인 모델이 될만한 프로세스를 기술한 것
• 대표적인 프로세스 모델
  • 폭포수 모델
  • 프로토타이핑 모델
  • V 모형
  • 애자일 모델

요구 분석

• 요구 – 시스템이 가져야 할 능력$_{capability}$과 조건$_{condition}$
• What 의 단계
• 응용 분야(도메인)에 집중
• 결과물: 요구분석서$_{SRS}$

설계

• How의 단계
• 솔루션에 집중
• 아키텍처 설계
• 상세 설계

구현

• Do it 단계
• 코딩과 단위 테스트

통합과 테스트

• 모듈의 통합으로 시작
• 테스트는 개발자가 아닌 제3자가 담당

설치와 유지 보수

• 시스템의 타입에 따라 다른 설치 방법
• 이전$_{Migration}$ 정책
• 설치는 개발 프로젝트의 일부, 유지 보수는 별개
  • 설치까지 해야지 개발의 끝

폭포수 모델Permalink

• 각 단계가 다음 단계 시작 전에 끝나야 함
  • 순서적 - 각 단계 사이에 중복이나 상호작용이 없음
  • 각 단계의 결과는 다음 단계가 시작 되기 전에 점검
  • 바로 전 단계로 피드백
• 단순하거나 응용 분야를 잘 알고 있는 경우 적합
  • 한 번의 과정, 비전문가가 사용할 시스템 개발에 적합
• 결과물 정의가 중요
• 장점
  • 프로세스가 단순하여 초보자가 쉽게 적용 가능
  • 중간 산출물이 명확, 관리하기 좋음
  • 코드 생성 전 충분한 연구와 분석 단계
• 단점
  • 처음 단계의 지나치게 강조하면 코딩, 테스트가 지연
  • 각 단계의 전환에 많은 노력
• 적용
  • 이미 잘 알고 있는 문제나 연구 중심 문제에 적합
  • 변화가 적은 프로젝트에 적합

프로토타이핑 모델Permalink

• 프로토타입(시범 시스템)의 적용
  • 사용자의 요구를 더 정확히 추출
  • 알고리즘의 타당성, 운영체제와의 조화, 인터페이스의 시험 제작
• 공동의 참조 모델
  • 사용자와 개발자의 의사소통을 도와주는 좋은 매개체
• 프로토타입의 목적
  • 단순한 요구 추출 – 만들고 버림
• 장점
  • 사용자가 더 관심을 가지고 참여할 수 있고 개발자는 요구를 더 정확히 도출할 수 있음
• 단점
  • 오해, 기대심리 유발
  • 관리가 어려움(중간 산출물 정의가 난해)
• 적용
  • 개발 착수 시점에 요구가 불투명할 때

나선형 모델Permalink

• 소프트웨어의 기능을 나누어 점증적(+반복적)으로 개발
  • 실패의 위험을 줄임
  • 테스트 용이
  • 피드백
• Boehm이 제안
• 진화 단계
  • 계획 수립$_{planning}$: 목표, 기능 선택, 제약 조건의 결정
  • 위험 분석$_{risk} \ _{analysis}$: 기능 선택의 우선순위, 위험요소의 분석 → 얘를 반드시 함
  • 개발$_{engineering}$: 선택된 기능의 개발
  • 평가$_{evaluation}$: 개발 결과의 평가

$risk \ management(analysis)$: 위험 관리(분석) → 나선형 모델을 말함

• 장점
  • 대규모 시스템 개발에 적합
  • 반복적인 개발 및 테스트 - 강인성 향상
  • 한 사이클에 추가 못한 기능은 다음 단계에 추가 가능

1
2
3
    → 병행이 가능하다!
    
    (폭포수 모형 같은 애들은 순차적, 순서적이기 때문에 병행이 불가능함)

• 단점
  • 관리가 중요
  • 위험 분석$_{risk \ management}$이 중요
• 적용
  • 재정적 또는 기술적으로 위험 부담이 큰 경우(실시간 시스템, 뱅킹 시스템 등)

V 모델Permalink

• 폭포수 모형의 변형
  • 코딩을 중심으로 접음
  • 작업과 결과의 검증$_{validation}$에 초점
• 장점
  • 오류를 줄일 수 있음
• 단점
  • 반복이 없어 변경을 다루기가 쉽지 않음
    • 반복이 생길 수는 있음
• 적용
  • 신뢰성이 높이 요구되는 분야

애자일 프로세스Permalink

• 폭포수 프로세스의 단점을 해결
• 절차와 도구보다 개인과 소통을 중요시 함
• 잘 쓴 문서보다는 실행되는 소프트웨어에 더 가치를 둠
• 계약 절충보다는 고객 협력을 더 중요하게 여김
• 계획을 따라 하는 것보다 변경에 잘 대응하는 것을 중요하게 여김

지원 프로세스Permalink

형상 관리 프로세스

• 개발 중에 발생하는 변경을 체계적으로 컨트롤하는 것
• 개발작업과 독립적인 작업

1. 형상 관리 기능

   • 프로그램의 최신 버전 유지

     → 형상 관리 = 버전 유지

   • 지정된 버전으로 되돌아갈 수 있는 기능
   • 무허가 변경이나 삭제를 방지
   • 현 시스템에 대한 모든 정보, 문서 등의 정보를 모아 보관
2. 형상관리 메커니즘

   • 프로젝트에서 변경이 발생되었을 때 처리하는 시나리오를 다루는 메커니즘을 제공

     → 흔적을 남겨야 함

방법론Permalink

• 방법론
  • 소프트웨어 프로세스의 각 작업을 어떻게 수행하느냐를 정의
• 프로세스
  • 일반적으로 개발할 때 해야 하는 작업만을 명시
  • 어떤 관계가 있는지 나태내지 않음

구조적 방법론Permalink

• 분리와 정복$_{divide \ and \ conquer}$ 원리 적용
• 자료 흐름도를 구조도로 변경하는 과정
  • 구조도: 모듈 사이의 관계를 나태내는 그래프

객체지향 방법론Permalink

• 자료와 함수를 가까운 곳에 정의하여 객체로 묶어두고 객체 사이에 메시지를 호출하여 원하는 기능을 담당하게 하는 것

• 클래스 간의 관계는 메시지간의 교환을 통해 생성됨

  → 클래스 간의 관계는 객체들간의 메서드 호출을 통해 알 수 있다.

애자일 방법론Permalink

• 점증적인 프로세스를 채택
• 짧은 반복 주기를 반복하며 점증적으로 자주 출시
• 특징: 빨리빨리