가이드라인: 프로세스 차별
주제
소프트웨어 개발 프로세스는 다음 요소의 영향을 받습니다.
- 어플리케이션 도메인, 지원하는 비즈니스 프로세스, 사용자
커뮤니티, 경쟁사에서 사용 가능한 제품과 같은 도메인 요소.
- 시장 진입 시점, 소프트웨어의 예상 수명 및 계획된 향후
릴리즈와 같은 라이프사이클 요소.
- 프로그래밍 언어, 개발 툴, 데이터베이스, 컴포넌트 프레임워크
및 기존 소프트웨어 시스템과 같은 기술적인 요소.
- 조직적인 요소.
이러한 요소의 중요성은 서로 다릅니다. 다음 섹션에서는 개발
케이스의 전체적인 형태에 영향을 가장 많이 미치는 일부 기본 요소 및
개발 조직에서 프로세스 및 툴을 구현하는 방법을 설명합니다.
최상의 프로세스 구성 방법에 영향을 미치는 비즈니스 컨텍스트
유형은 다양합니다. 다음은 비즈니스 컨텍스트의 예입니다.
- 개발자가 지정된 고객 스펙 및 이 고객 전용의 소프트웨어를
생성하는 계약 작업.
- 개발자가 소프트웨어를 시장에 출시하는 비용을 생성 및
보상하는 투기적 또는 상업적 개발.
- 고객과 개발자가 동일한 조직에 있는 내부 프로젝트.
많은 중간 상황이 있습니다. 예를 들어 소프트웨어 개발의 일부만
하청 계약을 맺을 때 지리적인 분산이 추가 요소가 되는 경우가 이에
해당합니다. 서로 다른 이해 당사자의 총 수는 비즈니스 컨텍스트의
좋은 지표가 됩니다.
비즈니스 컨텍스트는 격식 및 형식 레벨과 프로세스의 경직도에
영향을 미칩니다. 이해 당사자(구매자, 고객, 하청 계약자,
규제 기구 등)가 많을 수록 프로젝트가 주요 프로젝트 이정표에서
문서, 보고서 및 프로토타입과 같은 형식적인 증거를 생성해야 할
가능성이 높습니다.
SLOC(Source Lines of Code), DSI(Delivered Source Instructions)
또는 Functions Point, 직원-달 수 또는 비용과 같은 특정 메트릭에서
정의하는 소프트웨어 개발 노력의 크기입니다.
노력의 크기는 격식 및 형식의 레벨과 프로세스의 경직도에 영향을
미칩니다. 프로젝트 규모가 커질수록 비즈니스 컨텍스트와는 상관없이
개발 팀 크기가 커지고 요구사항, 인터페이스 및 진행 표시기의 형식
및 가시성이 다양한 팀과 관리에서 더 많이 필요해집니다. 대형
프로젝트에서 발생하는 의사소통 문제점은 지리적으로 분산된 팀의
경우 더 악화됩니다.
혁신의 정도는 개발 조직에 관하여 이 소프트웨어 개발 노력보다
우선하고 특히, 개발이 두 번째 또는 다음 주기인지에 따라 다릅니다. 여기에는
조직 및 조직 프로세스의 완성도, 조직의 자산, 현재 기술 세트 및 팀
구성과 훈련, 툴 및 기타 자원 확보와 같은 문제점이 포함됩니다.
프로젝트의 혁신 정도는 완전히 다른 방식으로 프로세스에
영향을 미칩니다. 해당 프로젝트로는 첫 번째인 새 프로젝트는
동적인 형상에 큰 영향을 미칩니다. 초기 및 구현화 단계가 더 길어지고
여러 반복과 관련될 수 있습니다. 추출 및 캡처 요구사항, 유스
케이스 모델화, 구조 및 완화 위험을 더 많이 강조합니다. 이전
시스템의 전개 주기 프로젝트의 경우 변경 관리가 더 중요하며
레거시 코드를 통합하면 일부 기술상의 위험이 나타납니다.
혁신은 개발 중인 시스템 및 수행 조직의 완성도와도 관련되어
있습니다. 새 기술이나 툴을 도입하는 것이 프로세스에 영향을
미치기 때문입니다. 특히 Rational Unified Process(RUP)를 조직에
도입하는 것은 신중히 실행해야 합니다. 조직에서는 새 프로세스를
채택하는 일부 타성에 젖은 태도를 보여주며 개발 케이스에서는
기존 방법에서 새 방법으로 원만하게 변경하는 것을 고려해야 합니다.
다양한 어플리케이션 유형이 있습니다. 예를 들어 임베드된
실시간 시스템, 분산된 정보 시스템, 텔레콤 시스템, CASE(Computer-Aided
Software Engineering) 툴 등이 있습니다. 어플리케이션 유형은
프로세스에 영향을 미칩니다. 특히 도메인이 개발시 부과할 수 있는
보안, 성능, 국제화, 메모리 제한조건 등과 같은 특정 제한조건과
관련하여 영향을 미칩니다.
어플리케이션이 업무에 중요한 경우(예: 항공기의 비행 제어
시스템) 어플리케이션 유형이 프로세스에 영향을 미칠 수 있습니다. 일반적으로
요구사항을 추적하고 제품의 품질을 보장하려면 업무에 중요한 시스템의
격식 레벨이 높아야 합니다. 또한 업무에 중요한 어플리케이션은
테스트할 때 더 많은 자원을 소비해야 합니다.
개발 유형 또는 대상 도메인에서 다음의 프로세스가 실행됩니다.
- 특정 활동을 지원하는 기술 및 툴(예: 유한 상태 시스템의
자동 코드 생성).
- 인증 프로시저(예: 의료 기구 사용).
- 표준 준수(예: 회계 또는 재무 및 원격 통신 장비용).
다음과 같이 다양한 개발 유형이 있습니다.
- 특정 고객이 사용할 제품을 개발하는 계약 작업. 계약
작업을 수행할 때 관리 및 협상해야 할 이해 당사자가 많습니다. 종종
공식적인 외부 결과물이 필요한 경우가 있습니다. 고객 또는
담당자가 진행을 모니터하고 이에 관한 내용을 알고 싶어하기
때문입니다. 고객이 검토할 결과물을 쉽게 이해할 수 있는지
확인하십시오. 종종 해당 프로젝트가 나머지 프로젝트에서 고정
가격을 제공할 수 있는 이정표가 필요한 경우가 있습니다. 이
경우 새 이정표를 추가하거나 기존 이정표를 조정해야 합니다. 다른
경우 고객이 다른 이정표 및 단계와 함께 사용하는 라이프사이클
모델을 조정해야 할 수도 있습니다.
- 대중 시장에 출시할 제품을 개발하는 투기적
개발. 투기적 개발에서는 조직 자체 내 마케팅(제품) 관리자가
고객 역할을 수행합니다. 시장 진입 시점은 투기적 개발의 기능보다
더 중요하고 형식적인 검토의 필요성도 더 낮습니다.
- 회사의 다른 부서에 제공되는 제품을 개발하는 내부
개발. RUP를 사용하지 않는 다른 제품을 제공하는 경우 다른
라이프사이클 모델로 조정해야 합니다. 대부분의 결과물을 동료가
검토하므로 결과물을 설명할 때 보다 기술적으로 받아들일 수 있습니다.
- 보통 제품을 개발하지 않는 사전 연구. 사전 연구
프로젝트의 목적은 프로젝트의 빌드가 가능한지를 확인하는
것입니다. 사전 연구 프로젝트에는 정규 프로젝트와 동일한
이정표가 없습니다.
대부분의 경우 먼저 보다 중요한 영역에 초점을 맞추어 단계별로
새 개발 프로세스를 구현하기 때문에 현재 조직에서 실행 중인
소프트웨어 개발 프로세스가 대체되지는 않습니다. 현재 소프트웨어
개발 프로세스 중 일부는 당분간, 아마도 영원히 계속 존재할 수도
있습니다.
소프트웨어 개발 조직을 이해할 때 기존 소프트웨어 개발
프로세스의 문제점을 파악하는 것이 중요합니다. 이는 프로세스
구현 초기에 집중되는 프로세스의 해당 영역에 영향을 미칩니다. 조직에
확립된 작업 방법이 없는 경우 문제점을 찾아도 소용이 없음을
이해하는 것이 중요합니다. 개념:
프로젝트에서 프로세스 구현을 참조하십시오. 대신 문제점의
근본적인 원인을 식별해야 합니다. 문제점을 제거하려면 해당
프로세스를 개선하고 프로세스를 자동화하는 툴을 도입하여 직원을
훈련시켜 근본적인 원인을 해결합니다.
공통 문제점의 예
다음은 몇 가지 공통 문제점의 예입니다.
- 범위를 관리할 수 없습니다. 조직이 마지막에 실제로 관리하는
것보다 더 많이 정기적으로 관리합니다.
- 요구사항을 캡처할 수 없습니다. 요구 사항을 지정하는 데 어려움이 있습니다.
- 요구사항 변경을 관리할 수 없습니다.
- 요구사항을 관리할 수 없습니다. 요구사항이 최종 제품까지 도달하지 않습니다.
- 추정할 수 없습니다. 보통 스케줄 대로 납품할 수 있다는 능력에 대해 지나치게 낙관적입니다.
- 설계 결함이 나타납니다. 요구사항은 충족하지만 시스템
설계 능력이 부족합니다. 어떤 설계 문제점을 갖고 있습니까? 시스템을
유지보수 및 향상시키는 데 어려움이 있습니까? 성능 문제점,
사용성 문제점, 용량 문제점 등이 있습니까?
- 우수한 품질의 제품을 생산할 수 없습니다. 테스트 부족으로
제품 결함이 많습니다. 하지만 보통 설계 결함 뿐만 아니라
요구사항을 제대로 캡처 및 관리할 수 없는 능력과도 관련되어 있습니다.
- 허용할 수 없는 소프트웨어 성능.
- 낮은 사용성.
- 개발자와 충돌합니다. 소유권과 형상 관리에 대한
규제가 부족하므로 개발자는 충돌하는 변경사항을 개발하고 작업이
손실됩니다.
- 문제점을 늦게 발견합니다.
- 유스 케이스에서 설계까지의 문제점.
근본적인 원인에 관한 예
문제점은 종종 뭔가 잘못되었다는 증상을 보입니다. 문제점의
근본적인 원인을 식별해야 합니다. 다음은 몇 가지 근본적인 공통 원인의
예입니다.
- 충분하지 않은 요구사항 관리
- 애매하고 부정확한 의사소통
- 불안정한 구조
- 매우 높은 복잡도
- 요구사항, 설계 및 구현 사이의 불일치를 발견하지 못함
- 충분하지 않은 테스트
- 주관적인 프로젝트 상태 평가
- 워터폴 개발로 인한 지연된 위험 감소
- 제어되지 않는 변경사항 전파
- 충분하지 않은 자동화
- 사용자 인터페이스를 빌드하는 체계적인 방법이 없음
- 유스 케이스에서 설계까지 이어지는 방법이 없음
조직에서 프로세스를 구현할 때 조직 구조, 프로젝트 조직 및
관리의 방식, 사용 가능한 능력 및 기술, 이전 경험 및 현재 태도와
같은 조직적인 요소에 의존합니다.
조직적인 요소는 프로세스 구성 방법에도 영향을 미칩니다. 예를
들어 조직의 직원이 이전에 소프트웨어 개발 프로세스 설명을 사용한
경우 더 쉽게 RUP 사용을 시작할 수 있습니다. 한편 직원이 소프트웨어
개발 프로세스 설명을 사용하지 않은 경우 프로세스 설명 범위를 제한하도록
할 수 있습니다. 최고의 가치를 제공하는 RUP의 해당 파트를 정확히
지정하게 하면서 개발 케이스를 더 쉽게 이해하고 사용할 수 있도록
추가 노력을 제공할 수도 있습니다.
대부분의 직원에게 새로운 일부 영역이 있는 경우 가능한 최상의
가이드라인을 개발하는 것이 더 쉽게 변경할 수 있는 방법입니다. 예를 들어
프로그래밍 언어가 대부분 직원에게 생소한 경우 직원의 학습을 지원하는
훌륭한 프로그래밍 가이드라인 및 설계 가이드 라인이 필요할 수 있습니다.
새 기술, 새 프로세스 또는 새 툴에 대한 직원 사이의 부정적인
태도가 프로세스 및 툴을 제대로 구현하는 데 가장 큰 위협이 될 수
있습니다. 프로세스에 대한 지나친 열정도 직원이 해당
프로세스에 집중하게 만들기 때문에 문제점이 될 수 있습니다.
새 기술, 프로세스 및 툴에 대한 직원의 태도를 평가할 때
다음을 질문하십시오.
- 새 기술의 장점은 무엇이라고 생각합니까? 새 기술이 현재의
문제점을 해결할 수 있습니까? 새 기술의 문제점은 무엇이라고 생각합니까?
- 새 프로세스의 장점은 무엇이라고 생각합니까? 새 프로세스가 현재의
문제점을 해결할 수 있습니까? 새 프로세스의 문제점은 무엇이라고 생각합니까?
- 새 툴의 장점은 무엇이라고 생각합니까? 새 툴이 현재의
문제점을 해결할 수 있습니까? 새 툴의 문제점은 무엇이라고 생각합니까?
직원의 동기를 평가할 때 다음 질문에 대한 응답을 찾으십시오.
- 모든 직원이 변화가 필요한 이유를 알고 있습니까?
- 모든 직원이 자신의 경쟁자가 하고 있는 일과 이것이
비즈니스에 미치는 영향을 알고 있습니까?
- 모든 직원이 산업의 기술 변화와 이러한 변화가 비즈니스에 미치는
영향을 알고 있습니까?
태도가 부정적임을 나타내는 신호로 다음 상황이 포함될 수 있습니다.
- "프로세스가 도움이 되지 않고 방해가 됩니다."
- "프로세스는 많은 문서를 작성한다는 것을 의미합니다."
- "프로세스가 너무 많습니다."
다음은 부정적인 태도를 처리하는 몇 가지 방법입니다.
- 오늘날의 문제점을 지적하여 직원에게 동기를 부여합니다.
- 프로세스가 직원이 해야할 일을 지시하지 않는다는 점을
설명합니다. 프로세스는 기본적으로 안내, 정의 등을 찾을 수 있는
"도움말 시스템"으로 간주해야 합니다.
- 프로세스의 작은 파트만 사용한다는 점을 설명합니다. 아무도
전체 프로세스에 전문가가 될 수 없으며 전문가가 되는 것이 목표가
아닙니다. 프로세스를 해당 정보가 필요하여 읽을 책이 있는 책장과
비교하십시오.
- 새 프로세스와 툴의 작동 방법을 보여주는 안내 프로젝트를
실행하십시오. 안내 프로젝트에 한두 명의 회의론자를 포함시키십시오.
열정이 지나침을 나타내는 신호로 다음이 있습니다.
- 직원이 프로세스에 전적으로 의존하고 프로세스가 자신의
문제점을 모두 해결할 것이라고 생각합니다.
- 프로세스가 비장의 무기 또는 마법의 공식이므로
프로세스를 따르면 성공을 보장합니다.
- 프로젝트 팀이 해결책이 필요한 프로세스 관련 문제점을 먼저
평가하지 않고 프로세스를 조정하는 데 많은 시간과 노력을 들입니다.
다음은 과도한 열정을 처리하는 몇 가지 방법입니다.
- 기대치를 설정합니다. 프로세스가 도움은 되지만 문제점을
해결하지는 않습니다. 직원이 문제점을 해결합니다.
- 프로세스를 조정하는 데 많은 시간을 소비된다는 점을 직원에게 알립니다.
- 직원을 소프트웨어 제품 개발에 초점을 맞추게 합니다.
다른
유형의 시스템 및 해당 프로젝트를 시스템의 기술상의 복잡도 및
관리상의 복잡도의 관점에서 분류할 수 있습니다. 다음 그림에서는
다른 시스템을 분류할 수 있는 방법에 관한 개념을 설명합니다. 예를
들어 전형적인 소규모 비즈니스 스프레드시트 어플리케이션은 기술상의
복잡도가 낮아서 쉽게 관리할 수 있습니다. 대조적으로 전형적인 무기
시스템 프로젝트는 기술 및 관리상의 복잡도가 높습니다.
보통 시스템 크기가 커지면 프로젝트 지속 기간이나 비즈니스
컨텍스트의 관리상 복잡도가 증가합니다. 문제점 도메인이나
솔루션 영역에서 혁신이 증가하면 기술상의 복잡도가 증가합니다. 대부분의
대규모 프로젝트는 기술적으로 복잡하므로 기술 및 관리상의 복잡도
사이에 상호 작용이 발생합니다. 결과는 다음과 같습니다.
- 관리상의 복잡도가 증가하여 더 많은 형식적인 검토와
이정표 및 결과물을 포함하여 더 많은 격식을 유도합니다.
- 특정 기술, 역할 및 툴을 유도하는 기술상의 복잡도가 증가하여
활동이 증가합니다.

기술 및 관리상의 복잡도 관점에서 시스템을 분류합니다.
|