개발 작업 구현

개발 작업은 요구 사항 기반의 개발 과정을 구성하는 작은 요소입니다. 개발 작업 구현에는 소프트웨어에 적절한 새 기능을 추가하는 작업이 포함됩니다. 개발 작업을 완료한 후에는 해당 작업에 대해 단위 테스트, 검토 및 코드 분석을 수행하고 이를 기존 코드베이스에 통합해야 합니다.

항목 내용

작업량 예상

디자인 문서

디자인 검토

단위 테스트

코드 분석

코드 검토 프로세스

리팩터링

변경 내용 통합

작업량 예상

개발 작업의 비용을 예상하면 기능 범위를 조정하고 개발 작업의 일정을 세우는 데 유용합니다. 반복 계획 회의 전에 모든 개발 작업의 예상 비용을 계산하고 모든 문제를 해결해야 합니다. 개발 작업의 총 비용이 반복에 허용되는 비용보다 많으면 작업을 연기하거나 다시 할당해야 합니다. 개발 작업을 선택한 후 작업 비용을 계산하는 것은 개발자의 업무입니다.

선택한 각 개발 작업에 대해 작업(task) 작업 항목을 만들어 해당 작업을 만드는 데 기초가 된 요구 사항에 연결합니다. 이 과정은 작업(task) 또는 요구 사항 작업 항목의 구현 탭에서 수행합니다. 과거에 비슷한 작업을 완료하는 데 필요했던 시간을 기초로 예상 작업량을 계산하고 단위 테스트 작성 비용을 계산에 포함하도록 합니다. 그런 다음 각 작업에 대한 작업(task) 작업 항목의 원래 예상 값 필드에 예상한 값을 입력합니다.

작업의 작업 항목 폼은 다음 그림에 나오는 필드와 탭에 데이터를 저장합니다.

작업을 만들고 예상 작업량을 계산한 후에는 작업 분할 구조 쿼리를 사용하여 모든 요구 사항 및 작업의 분할 구조를 확인합니다. 자세한 내용은 팀 쿼리(CMMI)를 참조하십시오.

디자인 문서

디자인 문서에는 제품에 요구 사항을 구현하기 위한 코드 작성 방법을 개발자에게 설명할 수 있도록 충분한 정보를 포함해야 합니다.

디자인 문서는 팀 프로세스에 따라 사양, 요구 사항 작업 항목 및 그 밖의 문서를 모은 컬렉션일 수 있습니다.

디자인 패턴, 개체 지향 디자인, 구조 모델, 모델링 언어, 엔터티 관계 모델, 그리고 팀에 대해 결정된 디자인 지침에 명시된 기타 기술을 사용하는 것이 좋습니다. 또한 결정된 주요 사항에 대한 이유를 문서화하는 것이 좋습니다. 예를 들어 비용, 일정 또는 기술 성능에 큰 영향이 있을 경우 이러한 영향의 이면에 있는 결정 사항에 대해 그 이유를 문서화하고 해당 정보를 디자인에 포함합니다.

필요한 디자인 문서를 만든 후에는 팀 멤버가 공유할 수 있는 위치에 저장합니다. 자세한 내용은 문서 및 문서 라이브러리 관리를 참조하십시오.

디자인 검토

디자인 검토를 통해 새로운 디자인이나 수정된 디자인이 기술적으로 정확하고 완전하고 테스트 가능하며 고품질인지를 확인하고 이 디자인이 요구 사항을 올바르게 구현하는지 확인할 수 있습니다. 디자인 검토는 코드에 문제가 나타나기 전에 이를 파악하여 초기에 품질을 보장하기 위한 주요 방법입니다. 또한 디자인 검토를 통해 다른 개발자의 디자인을 세밀하게 조사할 수 있습니다.

디자인을 만드는 책임이 있는 개발자는 검토자를 지정하고 검토 일정을 세우고 디자인을 모든 검토자에게 배포하여 디자인 검토 과정을 구성해야 합니다.

디자인에 관여하거나 디자인의 영향을 받는 모든 관련자가 검토에 참여해야 합니다. 일반적으로 프로젝트 관리자, 수석 개발자 및 해당 디자인 영역의 테스터가 이러한 관련자에 포함됩니다. 검토할 코드의 개발자와 같은 팀에 속하는 모든 개발자도 검토에 참여해야 합니다.

검토 회의의 일정을 세우고, 각 검토자에게 디자인 문서를 일찌감치 배포하여 문서를 검토할 수 있는 충분한 시간을 줍니다. 검토 회의 시간은 검토해야 하는 기술 정보의 양에 맞게 계획합니다.

품질 확인

디자인은 테스트 가능해야 합니다. 해당 디자인으로 빌드되는 코드를 적절한 방식으로 확인하거나 유효성을 검사할 수 없다면 코드의 품질을 보장할 수 없으므로 디자인을 수정해야 합니다. 디자인 문서에 코드 오류를 초래하는 문제가 있는지 조사하고 올바르지 않은 인터페이스 설명, 디자인 오류 또는 이름 충돌이 있는지 확인합니다. 또한 운영자 인터페이스 표준, 안전성 표준, 프로덕션 제약 조건, 디자인 오차 또는 부품 표준 같은 기존 기준과 디자인 문서를 비교해야 합니다. 디자인 문서에서 결함이 발견되면 이를 설명하는 버그 작업 항목을 만들어 책임 개발자에게 할당합니다.

디자인에 대한 검토 작업 항목 작성

검토 작업 항목을 만들어 디자인 검토 결과를 문서화할 수 있습니다. 검토 팀에서는 디자인에 대한 다음 단계를 결정해야 하는데 이러한 단계는 필요한 변경 작업의 규모에 따라 달라집니다. 변경이 필요하지 않으면 작업 항목의 상태를 "닫힘"으로 설정하고, 이유를 "승인됨(현재 상태로)"으로 설정한 다음, 해당 디자인에 대해 코딩을 시작할 수 있다고 기록합니다. 사소한 변경이 필요한 경우에는 작업 항목의 상태를 "해결됨"으로 설정하고, 이유를 "승인됨(사소한 변경 포함)"으로 설정합니다. 이는 디자인에 사소한 변경을 구현한 후 코딩을 시작할 수 있음을 나타냅니다. 중요한 변경이 필요한 경우에는 작업 항목의 상태를 "해결됨"으로 설정하고, 이유를 "승인됨(중요한 변경 포함)"으로 설정합니다. 이 경우 디자인에 대해 코딩을 시작하기 전에 디자인을 수정하고 디자인 검토를 한 번 더 수행해야 합니다.

단위 테스트

단위 테스트에서는 코드 단위가 올바르게 구현되었는지 확인합니다. 단위 테스트를 작성하고 수행하면 테스트가 시작되기 전에 버그를 식별할 수 있으며 그에 따라 품질 제어 비용을 줄일 수 있습니다. 개발자는 개발 작업 또는 버그 수정 구현의 일부로 작성할 모든 코드에 대해 단위 테스트를 작성해야 합니다. 자세한 내용은 단위 테스트를 사용하여 코드 확인을 참조하십시오.

코드 분석

코드 분석 과정에서는 개발 지침을 적용하는 데 유용한 규칙 집합을 기준으로 코드를 검사합니다. 코드 분석의 목적은 코드 분석 위반 또는 경고가 발생하지 않도록 하는 것입니다. 코드 분석 과정을 통해 코드에서 명명 규칙, 라이브러리 디자인, 지역화, 보안 및 성능과 관련된 200가지 이상의 잠재적 문제를 검사할 수 있습니다.

개발 주기의 초기에 코드 분석을 실행하기 시작하면 위반 및 경고를 지속적으로 최소화할 수 있습니다.

그러나 이전에 검사한 적이 없는 기존 코드에 대해 코드 분석을 실행할 경우에는 많은 규칙 위반이 발견될 수 있습니다. 이 경우 코드가 반드시 통과해야 하는 중요한 규칙으로 기준 집합을 만든 다음 이 규칙 집합을 확장해 가면서 점점 더 많은 주요 문제를 해결할 수 있습니다. 팀에서는 이 방법으로 새 기능을 처리하면서 동시에 기존 코드베이스를 개선할 수 있습니다.

자세한 내용은 코드 분석 도구를 사용하여 응용 프로그램 품질 분석 및 팀 프로젝트 체크 인 정책을 사용하여 코드 품질 향상을 참조하십시오.

코드 검토 프로세스

수석 개발자는 검토자를 지정하고 코드 검토 일정을 세우고 검토를 위해 해당 코드를 모든 검토자에게 보내 코드 검토 과정을 구성해야 합니다. 코드 검토를 준비하려면 다음 단계를 따릅니다.

1. 검토를 통해 결정한 사항을 추적하기 위한 검토 작업 항목을 만듭니다. 변경이 필요하지 않으면 작업 항목의 상태를 "닫힘"으로 설정하고, 이유를 "승인됨(현재 상태로)"으로 설정한 다음, 해당 디자인에 대해 코딩을 시작할 수 있다고 기록합니다. 사소한 변경이 필요한 경우에는 작업 항목의 상태를 "해결됨"으로 설정하고, 이유를 "승인됨(사소한 변경 포함)"으로 설정합니다. 이는 사소한 변경을 구현한 후 코딩을 시작할 수 있음을 나타냅니다. 중요한 변경이 필요한 경우에는 작업 항목의 상태를 "해결됨"으로 설정하고, 이유를 "승인됨(중요한 변경 포함)"으로 설정합니다. 이 경우 디자인에 대해 코딩을 시작하기 전에 디자인을 수정하고 디자인 검토를 한 번 더 수행해야 합니다.

2. 코드 검토에 참여할 사람을 결정합니다. 일반적으로 수석 개발자와 코드 영역의 책임 설계자는 검토에 반드시 참여해야 합니다.

3. 검토자와의 검토 회의 일정을 세우고, 회의 전에 각 검토자에게 코드를 읽고 이해하기 위한 충분한 시간을 줍니다. 검토 회의 시간은 검토해야 하는 코드의 양에 맞게 계획합니다.

코드 검토

코드 검토는 코드를 매일 작성하는 빌드에 통합하기 전에 새 코드나 변경된 코드가 설정된 품질 목표를 충족하는지 확인하는 데 사용됩니다. 품질과 관련하여 고려해야 하는 사항은 코딩 표준, 아키텍처 및 디자인 준수 여부, 성능, 안정성, 보안 등입니다. 코드 검토를 통해 다른 개발자로부터 코드 작성 방법에 대한 유용한 정보를 얻을 수도 있습니다.

코드 관련성 확인	검토하려는 코드는 해당 코드가 작성된 작업과 관련이 있어야 합니다. 구현되거나 수정되는 기능을 처리하지 않는 코드 변경 작업은 허용되지 않습니다.
확장성 확인	코드는 확장 가능하거나(확장성을 염두에 둔 코드일 경우) 시스템의 다른 영역에서 재사용 가능하도록 작성합니다. 코드에 사용되는 문자열 상수는 국제화할 수 있는 리소스에 올바르게 추가합니다.
최소 코드 복잡성 확인	반복되는 코드는 공용 함수로 단순화할 수 있습니다. 유사한 기능은 공용 프로시저 또는 함수에 포함합니다.
알고리즘 복잡성 확인	검토되는 코드의 실행 경로 수를 최소화해야 합니다.
코드 보안 확인	코드의 자산 보호 기능, 권한 수준 및 진입점에서의 데이터 사용 여부를 검사합니다.

코드 리팩터링

코드 검토를 통해 코드 품질, 성능 또는 아키텍처 문제를 해결하기 위한 변경이 필요하다고 판단된 경우 코드를 리팩터링합니다.

코드 검토 작업 항목의 메모를 읽고 코드 리팩터링 방법을 확인합니다.

리팩터링은 한 번에 하나씩, 증분식으로 적용합니다. 코드를 변경하고 필요한 경우 수정된 영역에 대한 모든 참조도 변경합니다.

리팩터링 후 영역에 의미가 동일한 코드가 남아 있지 않도록 단위 테스트를 수행합니다. 단위 테스트가 작동하지 않으면 수정합니다. 그런 다음 코드 분석을 수행하여 경고를 수정하고, 코드 분석 결과 코드에 변경된 내용이 있을 경우 단위 테스트를 다시 수행합니다.

변경 내용 통합

마지막 단계에서는 코드를 버전 제어에 체크 인하여 변경 내용을 통합합니다. 코드를 체크 인하기 전에 프로세스에 필요한 모든 테스트를 수행해야 합니다. 코드를 체크 인하기 전에 코드에 문제가 있는지 확인하는 방법에 대한 자세한 내용은 팀 프로젝트 체크 인 정책을 사용하여 코드 품질 향상을 참조하십시오.

변경 내용과 연결된 작업 항목이 사용자 소유가 아닌 시나리오 또는 서비스 품질 요구 사항일 경우 변경이 완료되었음을 소유자에게 알립니다. 작업(task) 작업 항목을 "해결됨"으로 설정하고, 이를 해당 작업 항목에 대한 테스트 사례를 만든 테스터 중 한 명에게 할당합니다.

변경 내용과 연결된 작업 항목이 버그이면 버그 작업 항목을 "해결됨"으로 설정하고, 이를 원래 해당 작업을 만든 사람에게 할당합니다.