Chapter #2: 프로세스와 방법론

프로세스

- 어떤 일을 하기 위한 특별한 방법, 일반적으로 단계나 작업으로 구성

SW 개발 과정 -> 순서제약이 있는 작업의 집합, 높은 품질과 생산성이 목표

 

Code-and-fix

프로세스가 없는 개발

문제점

분석이나 설계의 중요성을 모름

신중하지 않으면 SW 구조가 나빠짐

계획 X -> 작업 목표 X

품질 보증 차원의 활동에 대한 인식 X

 

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

 

2.1 소프트웨어 프로세스

SW 프로세스

SW 시스템을 구축하기 위해 수행되는 작업의 단계

각 단계는 결과물 생성, 결과물은 다른 단계의 입력, 각 단계는 진입조건, 종료조건 있음

프로세스와 프로세스 모델

SW 프로젝트, SW 명세, SW 모델

 

프로세스 종류

프로세스 중심 프로세스 - 개발 프로세스, 관리 프로세스

기타 프로세스 - 형상 관리 프로세스, 프로세스 관리 프로세스

 

프로세스 정의

작업 결과, 검증 조건 명확히 정의

작업 방법

진입 조건, 출구 조건(결과물)

 

2.2 바람직한 프로세스의 특징

예측 가능성: 비용, 품질

테스팅과 유지보수 지원

변경 용이성 지원

결함 제거 용이성

 

2.3 소프트웨어 개발 프로세스 모델

프로세스 모델 - 일반적인 모델이 될만한 프로세스를 기술한 것

계획 - 요구사항 분석 - 설계 - 구현 - 통합, 테스팅 - 설치, 유지보수

대표적인 프로세스 모델 (폭포수, 프로토타이핑, 점증적, 진화적 출시, 애자일 등의 모델 + V 모형)

계획

비용, 기간, 인원, 수정할 점에 대한 대답을 찾는 단계

범위 정하기, 산정, 리스트 분석, 일정 계획, 관리 전략 수립

요구사항 분석 (What의 단계)

요구 - 시스템이 가져야 할 능력, 조건

What의 단계

응용 분야(도메인)에 집중

가장 중요, 어려운 단계

결과물: 요구분석서(SRS)

설계 (How의 단계)

솔루션에 집중

아키텍처, DB, UI, 상세 등의 설계 -> 결과물:설계서

구현 (Do it의 단계)

코딩과 단위 테스트

설계나 통합 단계와 겹치기도 함

특징 - 압력 증가, 최고의 인력 투입

이슈 - 하청 관리

통합과 테스트

병행 - 통합해 나가면서 테스트 시작

모듈의 통합-> 모듈 완성 -> 개발자가 통합 -> QA 팀이 테스트 담당

단계적 테스트 - 단위, 통합, 시스템

목적 중심 테스트 - 스트레스, 성능, 베타 등의 테스트

설치와 유지보수

시스템의 타입에 따라 다른 설치 방법

이전(Migration) 정책

시스템의 사용을 시작

설치와 유지보수(결함 수정, 기능 및 성능 추가)는 별개

 

(1) 폭폭수(waterfall) 모델

각 단계가 다음 단계 시작 전에 끝나야 함

단순하거나 응용 분야를 잘 알고 있는 경우 적합

한 번의 과정

결과물 정의가 중요

장점 - 프로세스가 단순, 중간 산출물이 명확, 코드 생성 전 충분한 연구와 분석 단계

단점 - 처음 단계에 지나치게 강조, 각 단계 전환에 많은 노력, 프로토타입과 재사용 기회 줄어듦, 다종 문서 생산 가능성 있음

적용 - 이미 잘 알고 있는 문제, 연구 중심 문제, 변화 적은 프로젝트에 적합

(2) 프로토타이핑 모델

프로토타입의 적용 - 사용자 요구 정확히 추출

공동의 참조 모델

프로토타입의 목적 - 단순한 요구 추출(만들고 버림), 제작 가능성 타진(개발 단계에서 유지보수 이뤄짐)

장점 - 사용자 의견 반영 잘 됨, 개발자는 요구 더 정확히 도출

단점 - 오해와 기대심리 유발, 관리 어려움(중간 산출물 정의 난해)

적용 - 개발 착수 시점에 요구가 불투명, 실현 가능성 타진, 혁신적 기술 사용 등을 해보고 싶을 때

(3) 진화적 모델

개발 사이클이 짧은 환경

빠른 시간 안에 시장에 출시하여야 이윤에 직결

개발 시간 줄이는 법 - 시스템을 나눠 릴리스

릴리스 구성 방법

점증적 방법 - 기능별로 릴리스

반복적 방법 - 릴리스 할 때마다 기능 완성도 높임

 

단계적 개발

기능 부족하더라도 초기에 사용 교육 가능

처음 시장에 내놓는 SW는 시장을 빨리 형성

자주 릴리스 -> 예상치 못한 문제 신속 꾸준히 고쳐나감

개발 팀이 릴리스마다 다른 전문 영역에 초점

(4) 나선형 모델

SW 기능을 나누어 점증적으로 개발 - 실패 위험 줄임, 테스트 용이, 피드백

여러 번의 점증적인 릴리스

진화 단계: 계획 수립 -> 위험 분석 -> 개발 -> 평가

장점 - 대규모 시스템 개발에 적합, 반복적인 개발 및 테스트, 한 사이클에 추가 못하면 다음 단계에 추가 가능

단점 - 관리와 위험 분석 중요, 신중한 적용 필요

적용 - 재정적/기술적으로 위험 부담이 크거나, 요구 사항/아키텍처 이해가 어려운 경우

(5) V 모델

폭포수 모형의 변형 - 감춰진 반복/재작업 드러냄, 작업의 결과/검증에 초점

장점 - 오류 줄일 수 있음

단점 - 반복 X -> 다루기가 쉽지 않음

적용 - 신뢰성이 높이 요구됨

(6) Unified 프로세스

도입 - 사용 사례(use-case), SW 구조, 프로젝트 계획

정련 - 주요 use-case 구현

구축 - 나머지 use-case 구현

전환 - 시스템 배치, 교육, 결함수정, 기능개선

사용 사례(use-case) 중심의 프로세스

시스템 개발 초기에 아키텍처, 전체적 구조 확정

아키텍처 중심

반복적, 점증적

(7) 애자일(agile) 프로세스

폭포수 프로세스 단점 해결

절차와 도구 < 개인과 소통 "중요시"

잘 쓴 문서 < 실행되는 소프트웨어 "큰 가치"

계약 절충 < 고객 협력 "중요시"

계획 따라 하는 것 < 변경에 잘 대응 "중요시"

 

 

2.4 지원 프로세스

ISO / IEC 1220 7에서의 프로세스 그룹

엔지니어링 시각, 계약 시각, 운영 시각, 지원 시각, 관리 시각

 

관리 프로세스

비용, 품질 목표를 달성하기 위해 프로젝트를 관리하는 데 필요한 모든 작업 (계획, 모니터링/제어, 분석)

프로젝트 모니터링과 제어는 개발 프로세스의 모든 단계를 포함하여 가장 긴 기간동안 이루어짐

품질 보증 프로세스

프로세스와 프로덕트에 대한 품질을 관리, 향상시키는 것

 

인스펙션 프로세스 - 개발 결과에서 결함을 찾거나 방지하기 위한 노력 /정의된 프로세스에 따라 동료 그룹이 작업 결과를 검사

프로세스 관리 프로세스 - 프로세스 개선

형상 관리 프로세스

개발 중에 발생하는 변경을 체계적으로 컨트롤하는 것

개발작업과 독립적인 작업

(1) 형상 관리 기능

프로그램 최신 버전 유지

지정된 버전으로 되돌아 갈 수 있는 기능

무허가 변경, 삭제 방지

현 시스템에 대한 모든 정보, 문서 등의 정보 모아 보관

(2) 형상 관리 매커니즘

프로젝트에서 변경 발생 시 처리하는 시나리오 다루는 메커니즘 제공

- 형상 관리 대상 파악과 베이스라인 지정, 버전 관리, 접근 제어

형상 관리 아이템의 생명 주기

 

 

2.5 방법론

방법론 - sw 프로세스의 각 작업을 어떻게 수향하느냐를 정의

프로세스 - 개발할 때 하여야 할 작업만을 명시

 

구조적 방법론

분리와 정복 원리 적용 / 분석 / 설계

자료 흐름도 -> 구조도 변경 과정

구조도: 모듈 사이의 관계를 나타내는 그래프

객체지향 방법론

자료와 함수를 가까운 곳에 정의 -> 객체로 묶어둠 -> 객체 사이에 메시지 호출 -> 원하는 기능 담당

객체지향 패러다임

애자일 방법론

점증적 프로세스 채택

짧은 반복 주기 반복

익스트림 프로그래밍 (탐구 -> 계획 -> 반복 -> 제품화 -> 유지보수 -> 종료)

스크럼: SW 개발팀이 개발을 연습하고 능력을 향상시킬 수 있는 프레임워크

기능 중심 개발 (전체 모델 개발 -> 기능 리스트 구축 -> 기능 단위 계획 -> 기능 단위 설계 -> 구축 -> 설치)

--> 처음 세 단계 한 번 / 나중 세 단계 반복