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