영향 분석 문서에 넣은 내용은 무엇입니까?

따라서 버그를 수정 한 후 소프트웨어 제품의 다른 모듈에 영향을 줄 수있는 버그가 발생했습니다. 귀하의 데이터는 수정의 영향에 대한 귀하의 주장을 뒷받침하기에 충분하지 않으며 영향 분석 문서를 작성하라는 요청을 받았습니다.

1. 이를 수행하는 방법에 대한 정의 된 프로세스가 있습니까?
2. 필요한 주요 정보는 무엇입니까?
3. 이 문서에 알려진 형식 / 템플릿이 있습니까?

내가 일하는 회사 내부에서 만든 영향 분석을 위해 본 템플릿. 우리는 변경 요청을 평가하고 작업하기 전에 (그리고 일부를 거부하기 위해) 사용합니다. 다음과 같은 섹션이 있습니다.

• 요구 사항에 대한 영향 :이 섹션에서는 분석가가 요청 된 변경을 지원하기 위해 사용 사례에서 변경해야 할 사항을 작성합니다.
• 설계 및 아키텍처에 미치는 영향 :이 섹션에서는 설계자와 설계자가 변경을 지원하기 위해 모델의 어떤 부분을 수정하거나 다시 실행해야하는지 언급합니다.
• 테스트에 대한 영향 : QC는 테스트 케이스를 업데이트해야한다고 기록합니다.
• 일정에 대한 추정 및 영향 : 프로젝트 관리자는 필요한 노력과 변경 비용 및 프로젝트 일정에 대한 영향을 추정합니다.

가능한 모든 영향을 다루려면 종속성을 따라야합니다. 양방향 추적 성 매트릭스가 있으면 더 쉬워집니다.

설계자가 변경에 대한 더 나은 통찰력을 얻으려면 분석가의 영향을 알아야하고, 테스터가 분석가와 건축가의 의견을 알아야하기 때문에 위의 순서를 사용했습니다. 마찬가지로 PM은 비용과 일정을 알기 위해 모든 정보가 필요합니다.

우리는 이것을 CR과 함께 사용했지만 같은 방식으로 버그와 함께 사용할 수 있습니다. 또한 버그를 해결하기 위해 여러 수정 솔루션 중에서 선택하기 위해이 작업을 수행해야하는 경우 가능한 모든 솔루션에 대한 영향 분석을 반복하고 모든 데이터를 하나의 DAR (Decision Analysis and Resolution) 양식으로 통합하여 어떤 솔루션인지 확인해야합니다. 최고. DAR 양식에서는 향후 유지 관리 가능성과 같은 일부 평가 요소 또는 영향 분석에 암시 적으로 포함되지 않은 기타 요소를 추가해야합니다. 그런 다음 각 요인 가중치를 부여하고 각 요인의 모든 솔루션 점수를 제공하십시오. 마지막으로 곱하고 점수 * 무게를 합하고 가장 좋은 것을 선택하십시오. 비용은 요인에 포함되거나 PM은 다른 의견을 가질 수 있습니다.

민첩한 접근 방식이 좋은 문서라고 생각합니다. 이제 민첩성이 "문서 화나 분석이 전혀 없음"을 의미한다는 오해가 있지만 사실은 그렇지 않습니다. 내가 애자일에 대해 읽은 것은 "작동하는 것을 사용하십시오"라고 말합니다. 나는 문서가 작업에 비례하여 길이가 길고 상세해야 함을 의미합니다.

템플릿은 체크리스트로 도움이 될 수 있지만 위험이 적거나 적은 변경에 대해서는 모든 섹션을 작성하지 않아도됩니다. 한 줄 변경의 경우 문서가 전혀 필요하지 않을 수도 있습니다. 영향 분석 문서에 템플릿을 사용한 적이 없지만 비즈니스 요구 사항이나 기술 사양을 정기적으로 다루고 있습니다. 템플릿은 너무 제한적일 수 있습니다. 좋은 가이드 라인은 청중이 누구인지를 고려하는 것입니다. 기술이 아닌 관리자의 경우 변경에 대한 비즈니스 정당성에 중점을 둡니다. 기술 담당자를위한 것이라면 팀의 새로운 직원이 길을 잃지 않도록 약간의 배경 지식을 제공하고 변경을 지원해야하는 경우 직원이 갈 수 있도록 충분히 제공하십시오. 또한 마찰이 적고 가벼운 것을 원한다면 문서를 전혀 사용하지 말고 위키에 넣으십시오.

포함 할 정보 :

• 문제에 대한 간단한 설명
• 결함이 어떻게 고장 및 / 또는 비 효율성을 유발하는지 설명하거나 보여줍니다
• 복잡성 추정 포함
• 수정 비용 및 시간 추정치 포함

괜찮은 수준입니다. 다른 포스트는 IBM의 꽤 무거운 CMMi 자료를 강조했다. 시간과 자원이 있다면 (그리고 인간이 위험에 처한 NASA를위한 시스템을 구축 할 때 사람들이 더 진지하게 생각한다면) 훌륭하지만 소규모 팀의 경우에는 그렇게 무겁지 않아도됩니다. . 항상 그렇듯이 추정에주의하십시오. 관리자는 추정치가 실제라고 가정하기 쉽습니다.

민첩한 접근 방식에는 위험이 있습니다. 일부 개발자는 "문서가 필요없고 해킹을 시작하기 만하면된다"는 의미라고 생각합니다 (일부 상황에서는 문제가 없을 수 있음). 또한 다른 사람들은 작업을 수행하면 위도를 파악하고 실제로 도움이되지 않는 정말 엉뚱한 문서를 작성합니다 (대부분의 상황에서 반드시 OK는 아닙니다). 문제의 일부는 잘 쓰는 데 약간의 노력과 기술, 시간이 걸린다는 것입니다. 우리 대부분은 적어도 두 가지에 부족합니다.)

나는 적어도 당신이 계획을 가지고 있다고 생각하기에 충분한 생각을 가지고 있음을 증명하기 때문에 항상 문서에 큰 도움이되었습니다. 그러나 노년기에는 너무 많은 문서 자체가 유지 관리 번거 로움이 될 수 있으며 문서를 업데이트하는 데 충분한 사람들이 신경 쓰지 않는다는 것을 알게되었습니다.

프로그래머가 지리적으로 다른 위치에서 작업하는 대규모 프로젝트에는 영향 분석 문서가 필요합니다.

영향 분석 문서는 변경 사항이 프로덕션에서 제대로 작동하는 다른 구성 요소에 영향을 미치지 않도록 리드의 승인을 받아야합니다.

요구 사항을 완전히 이해하고 재 작업을 피하기 위해 변경해야 할 모든 구성 요소를 식별하기 위해 영향 분석이 필요합니다.

고객 이해 관계자의 책임도 영향 분석에 필요합니다. 그렇지 않으면 배포 후 문제가 발생하면 개발자가 희생양이됩니다.

영향 분석은 추정의 기초입니다. 그것 없이는 추정에는 아무런 입장이 없습니다. 너무 높거나 너무 낮을 수 있습니다. 실제 노력이 초과하는 경우 영향 분석을 사용하면 설명하기도 쉽습니다.

다음은 영향 분석 보고서를위한 표준 템플릿입니다. 특정 산업 분야에 맞게 사용자 정의되었지만 그럼에도 불구하고 자신의 문서를 작성하는 데 영감을 줄 수있는 유용한 섹션이 있습니다.

링크 : http://www.itu.int/en/itu-d/projects/documents/templateimpactanalysis.pdf

건배