목표 지향 소프트웨어 개발 프로세스

Goal-Driven Software Development Process

GDP(Goal-Driven Software Development Process)는 반복적이고 증분적인 소프트웨어 개발 기법입니다.다른 현대 프로세스 모델과 비슷하지만 GDP는 주로 요건을 설정하기 전에 목표를 식별하고 상향식 설계 접근방식을 명시적으로 활용하는 데 초점을 맞추고 있다.

다음 섹션은 GDP 개념이 소개된 문서인 목표 지향 소프트웨어 개발에 기초하고 있습니다.

정당성

GDP 원칙을 수용하는 첫 번째 주장은 요구사항의 측면이다.소프트웨어를 개발할 때 요건(예: 폭포형 모델의 경우)에 대한 강한 집중은 주로 다음과 같은 [1]이유로 인해 과도한 비용과 결과의 품질 저하를 초래한다.

  • 기술적 가능성과 그 비용에 대한 저자의 제한된 지식으로 인해 요건은 비즈니스 목표와 동일하지 않습니다.이러한 요건은 상당한 이점을 제공하는 기술적으로 단순한 기능을 제외하고 불필요한 고가의 요망을 포함하는 경향이 있습니다.
  • 개발 중에 지원되는 비즈니스 프로세스를 공식화하면 프로세스 자체 또는 소프트웨어 시스템의 역할 변경으로 보완해야 하는 프로세스 내의 불일치 및 갭이 드러납니다.

이러한 두 가지 효과의 결과는 보통 개발 중 및 개발 후에 많은 변경 요청(경과 시간 및 비용 초과)이 발생하기 때문에 사용자 참여는 중요한 프로젝트 성공 [2]요인으로 간주됩니다.

둘째, 확립된 소프트웨어 프로세스가 요건을 구현까지 개선하지만 목표 지향 개발 프로세스는 비즈니스 목표와 기술 플랫폼 기능 간의 최적의 매핑을 반복 프로세스에서 찾고 비즈니스 목표와 기술적 측면을 동등하게 고려 및 조정할 것을 권장합니다.최적의 컨버전스 솔루션을 제공합니다.

목표 지향 개발 프로세스를 통해 이해관계자는 다음을 수행할 [3]수 있습니다.

  • 비즈니스 목표에 따라 요건에 맞는 사용 사례 검색
  • 목표와 IT 아키텍처 간의 가교 구축

주요 원칙

목표 지향 소프트웨어 개발 프로세스

공동 목표 식별

목표-질문-메트릭 패러다임과 밀접하게 관련되어 있는 최상위 목표는 이해관계자가 비즈니스 환경에서 무엇을 변경하거나 개선하고자 하는지에 대한 비공식적인 설명으로 정의되며, 보다 구체적인 하위 목표로 분해됩니다.또한 일련의 질문이 모든 목표와 연계되어 있으며, 이는 각 반복 후 정의된 목표에 대해 소프트웨어를 테스트하는 방법을 특징짓습니다.

이것이 GDP의 중요한 원칙이기 때문에 목표를 공동으로 특정하는 것은 사용자와 소프트웨어 개발자의 지식을 하나로 모읍니다.목표 정의는 하향식이지만 목표가 실현 가능한지 여부를 결정하는 것은 상향식입니다.

하향식 및 상향식 컨버전스

자세한 내용은 하향식 및 상향식 설계를 참조하십시오.

하향식 오리엔테이션은 수평적인 팀 조직을 지원하지만 상향식 어프로치에서는 일반적인 컴포넌트 또는 서비스를 제공하므로 [4]사용자 만족도가 향상됩니다.GDP에 의해 도입된 목표의 공동 식별에 의해, 톱 다운과 보텀 업의 양상(「톱 다운 사고와 보텀 업 행동」)을 조합해, 아티팩트의 일관성을 서포트해, 수직적인 팀 구성을 가능하게 합니다.

수직적 팀 구성

프로그래머가 모델링 팀에 의해 지정된 솔루션을 구현하는 수평적인 프로젝트 팀과 달리, GDP에 의해 암시되는 수직적 조직에는 숙련된 일반 기술자가 필요합니다.IBM Rational Unified Process에서 언급한 바와 같이, 개별 개발자는 불필요한 커뮤니케이션 오버헤드와 충돌을 방지하기 위해 프로젝트에서 여러 역할을 수행할 수 있으며, 해야 합니다.

역할과 사람

수직적인 조직으로 인해 GDP는 프로세스의 많은 역할을 수행할 수 있는 숙련된 일반 기술자를 필요로 합니다.

  • 프로그래머(상하향 및 상하향 컨버전스 담당)
  • 비즈니스 분석가(목표 특정 시 프로그래머와 협업하고 테스트 시 나중에 실행)
  • 소프트웨어 설계자(프로젝트 전체를 감시)
  • 프로젝트 매니저(리소스 할당, 시간과 노력 추적, 생산적인 환경 구축)
  • 요건 엔지니어

프로젝트 규모 최소화

GDP에 따르면 대규모 프로젝트에서 성공을 거두기 위한 또 다른 열쇠는 모든 면에서 프로젝트 규모를 최소화하는 것입니다. 즉, 문서, 요구 사양, 모델 등의 목표 및 소프트웨어 아티팩트의 수를 제한할 뿐만 아니라 프로젝트 구성원의 수를 제한하여 상호 대기 및 코드 크기를 피하는 것입니다.

크기를 최소화하면 시스템의 유지보수성과 비즈니스 프로세스에 대한 변경 가능성이 높아집니다.이러한 변경은 미래에 [5]가장 큰 영향을 미칠 가능성이 있기 때문입니다.

활동.

모든 반복은 비즈니스 목표와 그 우선순위를 식별하는 것으로 시작하여 선택된 목표에 대응하는 소프트웨어 시스템의 실행 버전으로 끝납니다.

소프트웨어 시스템의 점진적 개발은 다른 소프트웨어 프로세스에서도 이루어지지만, GDP의 반복 범위는 비즈니스 목표 자체가 사용 가능한 [1]구현의 가용성과 함께 성숙된다고 생각되므로 각 반복 후에 비즈니스 목표에 대한 논의를 포함하도록 확장된다.

주요 액티비티는 다음과 같습니다.

  1. 목표의 특정과 우선순위 부여(이해당사자 및/또는 비즈니스 분석가 및 프로그래머로 구성된 최대 5명의 소규모 그룹)
  2. 태스크의 수직 분배(선택한 목표는 최대 4명의 프로그래머 그룹에 할당됨)
  3. 구현 및 테스트(구현 시 구현 기반 테스트, 각 반복 종료 시 목표 기반 테스트)

이러한 액티비티는 6개의 주요 [3]단계로 나눌 수도 있습니다.

  1. 비즈니스 요건을 목표별로 그룹화
  2. 프로세스 내에서 목표 지향적인 시스템 동작을 공식화합니다.
  3. 목표 달성을 위한 진척 상황 감시(옵션)
  4. 프로세스 참가자에게 책임을 할당하다
  5. 목표 지향 아키텍처 백본에 동작을 삽입하여 실행
  6. 관계자의 애플리케이션 제약 조건 통합

레퍼런스

  1. ^ a b c d Schnabel, I.; Pizka, M (2006). "Goal-Driven Software Development". 2006 30th Annual IEEE/NASA Software Engineering Workshop. SEW. 2006. IEEE Computer Society. pp. 59–65. doi:10.1109/SEW.2006.21. ISBN 0-7695-2624-1. S2CID 2964715. Retrieved 2008-12-30.
  2. ^ 혼돈 보고서요기술 보고서, 스탠디시 그룹, 1994.
  3. ^ a b Berkem, Birol (March–April 2006). "How to align IT with the Changes using UML and according to BMM". Journal of Object Technology. 5 (2): 85–102. doi:10.5381/jot.2006.5.2.c9. Retrieved 2008-12-30.
  4. ^ Pizka, M.; Bauer, A. "A brief top-down and bottom-up philosophy on software evolution". IPWSE. 2004. IEEE Computer Society. Retrieved 2008-12-30.
  5. ^ 파나스, 뢰베, 아스만리버스 엔지니어링을 위한 유니파이드 복구 아키텍처를 지향합니다.인턴의 대리인.소프트웨어 엔지니어링 및 프랙티스 SERP'03, 제1권, 854-860페이지, 라스베이거스, NV, 2003년 6월CSREA 프레스

외부 링크