활동:
|
목적
|
|
역할: 구현자 | |
빈도: 각 반복 동안에 반복됨(프로토타입이 필요하지 않은 경우 초기 반복의 가능한 예외와 함께) | |
단계 | |
입력물: | 결과물: |
툴 강좌: | |
자세한 정보: |
워크플로우 세부사항: |
구현 활동을 시작하기 전에 구현자는 작업 지정 및 반복 계획에 지정된 대로 범위에 대해 명확해야 합니다. 구현 타스크는 일부 특정 기능(예: 설계 유스 케이스 구현을 전이 또는 결함 수정)을 완수하는데 초점을 맞출 수 있으며 이러한 특정 기능은 해당 기능에 공헌하는 여러 설계 요소의 구현과 연관됩니다. 또는 구현 타스크가 특정 설계 요소(예: 설계 서브시스템 또는 설계 클래스)에 초점을 맞춰 현재 반복에 필요한 범위까지 구현할 수 있습니다.
이 활동으로 하나 이상의 파일(구현 요소)이 작성 또는 갱신되게 됩니다. 구현 준비의 일부로서, 구현자는 올바른 요소 버전을 사용할 수 있도록 개발 환경이 올바르게 구성되었는지 확인해야 합니다. 이 작업은 갱신할 요소와 컴파일 및 단위 테스트에 필요한 다른 모든 요소에 수행해야 합니다. 구현자는 프로젝트 구성을 이해하고 따르며 관리 프로시저를 변경해야 합니다. 이러한 프로시저는 변경사항의 제어 및 버전 지정 방법과 통합을 위해 전달되는 방법에 대해 설명합니다.
클래스를 구현하기 전에 재활용 또는 수정할 수 있는 기존의 코드가 있는지 고려하십시오. 나머지 시스템 설계 및 구조에 적합한 구현 위치를 이해함으로써 구현자가 재활용 기회를 식별하는 데 도움이 됩니다. 또한 나머지 시스템에도 구현이 적합한지 확인할 수 있습니다.
하루에 두 번 정도 회귀 테스트를 컴파일, 링크 및 실행하여 구현 횟수를 늘리도록 권장합니다. 모든 공용 조작, 속성 및 연관이 설계 중에 정의되지 않음을 인식하는 것이 중요합니다.
결함을 다루는 경우, 증상이 아닌 문제점을 수정했는지 확인하십시오. 코드의 근본적인 문제점을 수정하는 데 초점을 맞추어야 합니다. 오류 수정 자체가 오류를 발생시킬 수 있는 활동이므로 한 번에 하나씩 변경하십시오. 새 오류의 원인을 쉽게 찾을 수 있도록 수정을 더 구현해야 합니다.
구현자는 특정 프로그래밍 언어의 프로그래밍 가이드라인을 포함하여 모든 프로젝트 특정 구현 가이드라인을 알고 따라야 합니다.
설계를 구현으로 변환시키기 위해 다음과 같이 다양한 기술을 사용할 수 있습니다. 몇 가지 예가 나와 있습니다.
그러나 모든 경우에 있어 일부 설계 추상이 일부 자동화된 변환을 적용하거나 수동 방식으로 구현이 됩니다.
이전 단계에서 설명한 대로 구현으로 설계를 변환하는 경우 구현의 완성도는 매우 다양합니다. 완전하고 올바른 구현일 수도 있지만 일반적으로 구현을 완료하려면 상당한 노력이 필요합니다. 예를 들면, 다음과 같습니다.
구현이 목적에 적합한지 확인해야 하는 경우입니다. 일반적으로 테스트(다른 활동에서 설명) 외에도 다음과 같이 몇 가지 추가 확인 작업이 효과적입니다.
설계를 구현 및 테스트하는 과정에서 설계에 영향을 주는 오류가 반드시 발생합니다. 다음에 유지보수 노력이나 계약 또는 의사소통 이유로 설계 추상을 유지하는 경우, 설계를 갱신해야 합니다.
완료되는 방법은 프로젝트의 구성 및 변경 관리 프로세스에 따라 달라집니다. 일반적으로, 필요한 변경이 적고, 동일한 개인이 클래스를 설계 및 구현 중인 경우, 공적 변경 요청이 필요하지 않습니다. 개인이 설계 시 변경할 수 있습니다.
예를 들어, 공용 조작 변경과 같이 필수 변경이 광범위한 영향을 미치는 경우, 공식 변경 요청을 제출해야 합니다.
Rational Unified Process
|