활동:
|
목적
|
|
역할: 기술 검토자 | |
빈도: 특히 구현화 단계 중에 반복당 적어도 한 번. | |
단계 | |
입력물: | 결과물: |
툴 강좌: | |
자세한 정보: |
워크플로우 세부사항: |
목적 | 각 검토에 대한 일반 권장사항. |
20,000 피트에서 보면 임의의 기타 평가 또는 검토에서 소프트웨어 구조 평가를 구별하는 것이 그리 많지 않습니다.
그러나 소프트웨어 구조의 한 가지 중요한 특성은 여러 구조적 품질 속성에 대한 특정 측정치 결여입니다. 오직 소수의 구조적 품질이 객관적으로 측정될 수 있습니다. 성능은 측정이 가능한 한 예입니다. 기타 품질은 보다 질적이며 주관적입니다(예: 개념적 무결성). 더우기, 비교할 기타 데이터나 참조가 없는 경우에 메트릭의 의미를 판별하는 것은 어렵습니다. 대상 관객이 참조 시스템을 사용하고 이해할 수 있는 경우, 이 참조 시스템과 비교한 일부 검토 결과를 표현하는 것이 종종 편리합니다. 설계 중인 시스템이 초기 설계와 비교될 수 있는 상황에서 발생할 수 있습니다.
라이프사이클에서 이 평가가 발생하는 시기 또한 이 목적 또는 유용성에 영향을 줍니다.
"피어" 검토자에는 비록 보다 제한되게 기술적 문제점에 중점을 둔
프로파일이지만 역할: 소프트웨어 아키텍트의
프로파일과 동일한 인력 프로파일이 있습니다. 리더쉽, 완성도, 실용주의
및 결과 지향은 덜 중요하지만 다음과 같은 경우에 여전히 중요합니다.
검토자가 그다지 흔치 않은 구조 결함이 프로젝트 스케줄에 문제를 일으키는지
알아낼 수 있습니다. 또한 중요한 문제점은 초기에 제기하는 것이 좋습니다.
이 때, 프로젝트 팀을 잘못된 경로로 이끄는 스케줄을 무작정 따르는 대신 문제점을
해결할 수 있습니다. 구조 검토자는 비용에 대해 위험의 밸런스를 맞추어야 하며, 이는 프로젝트 성공의 보다 광범위한
문제점에 여전히 민감한 사안으로 남습니다. 구조
검토자는 또한 민감한 문제점을 제기하고 의논할 수 있는 설득력있는 의사소통자여야 합니다.
목적 | 검토 범위 및 목표를 정의합니다. 각 특정 범위/목표 조합에 사용되는 방법을 정의합니다. |
다음과 같이 다양한 접근법을 사용하여 검토를 수행할 수 있습니다.
구조의 표시를 획득(또는 빌드)한 다음 질문을 하고 이 표시를 기반으로 추론하십시오.
여기에는 구조에 대한 대단한 지식이 있어 일부 알기 쉬운 설명을 제공하여 이로써 시작할 수 있게 하는 조직에서 소프트웨어 아키텍트(일부 다른 이름으로 숨겨지기가지 함)를 식별하여 해당 아키텍트로부터 정보를 추출하는 조직 및 소프트웨어 구조가 완전히 알려지지 않은 개념인 조직까지 광범위한 상황이 있습니다. 그런 다음, 이 프로세스는 "구조 마이닝"이라고 호명되며 실제로 문자 그대로 다음과 같습니다. 곡괭이로 소프트웨어 및 문서에서 파 내어 소스 코드, 인터페이스, 구성 데이터 등을 보기.
표시를 구성하는데 사용할 수 있는 한 모델은 소프트웨어 구조 문서에 표시된 구조 보기의 형식입니다. 논리적 보기가 기본 클래스(객체 모델)를 체계화하며 프로세스 보기가 제어의 기본 스레드와 해당 스레드 간 의사소통 방법을 설명합니다. 개발 보기가 다양한 서브시스템 및 해당 종속성을 표시하며 실제 보기가 기타 보기의 요소를 하나 또는 여러 실제 구성에 맵핑을 설명합니다. 여러 보기와 함께 문제점을 구성하십시오.
정보 데이터와 추론에 필요한 측정값의 목록을 설정하고 정보를 얻은 다음 이 정보를 요구사항 또는 일부 승인된 참조 표준과 비교하십시오. 이는 특정 품질 속성(예: 성능 또는 견고성)을 조사하는데 제대로 적용됩니다.
이는 조직적인 "가정" 접근법입니다. 질문되는 일반 질문사항을 시스템이 이행해야 하는 시나리오 세트로 변형하고 시나리오를 기반으로 질문을 하십시오. 이러한 시나리오의 예는 다음과 같습니다.
이러한 접근법의 이점은 타스크를 매우 구체적인 Perspective로 모든 조직이 이해 가능한 상태로 둔다는 것입니다. 또한 특히 요구사항이 비공식적이거나 글로 작성되지 않았거나 매우 일반적이며 간결한 경우에 요구사항의 누락사항 또는 결함을 자세히 조사하게 합니다. 불리한 점은 구조 자체를 검토 중인 객체로서 여기지 않고 시스템을 일부 조사 사항을 전송 중인 블랙 박스로 간주합니다.
실제로, 이러한 사항은 그다지 명확히 분리되지 않으며 세 가지 접근법 모두의 일부를 수행하게 됩니다.
잠재적 문제점을 밝히는 것은 대부분 지식과 경험을 기반으로 한 휴먼 판단에 의해 수행됩니다. 특정 실패 패턴이 프로젝트 간 및 조직 간에 반복됩니다. 특정 발견적 방법을 사용하여 문제점 영역을 밝힐 수도 있습니다. 이전 검토에서의 결과뿐 아니라(있는 경우) 체크리스트가 유용할 수 있습니다(일부 매우 일반적인 사항은 나중에 제안됨).
잠재적 문제점이 표시되는 대로 캡처하여 중립적인 어조로 설명하십시오(정확하게 지시 또는 "비극주의' 아님). AT&T 검토자와 같이 작은 마분지 카드를 사용하거나 우리와 같이 CRC 카드를 사용하여 우선순위 지정,체계화, 제거에 도움을 줄 수 있습니다.
나중에, 감소하는 범위 또는 영향별로 후보 문제점을 정렬하고 여러 개가 있는 경우, 가장 가까운 질문과 직접 관련된 문제점을 우선 다루고 시간이 허용하는 경우 "기타 제안사항"은 다음으로 남겨 두십시오. 그런 다음, 문제점의 실체를 주장하십시오. 매우 종종 문제점을 이해하지만 그 실체가 역설되지는 않습니다. 적당한 사람과 이야기를 하지 못했거나 정보의 적당한 부분을 살펴보지 않았을 뿐입니다. 다시 정렬하십시오. 문제점의 실체를 확인하도록 여러 데이터 지점을 확인하십시오(경험이 없는 주장자는 너무나 단일 스레드적인 경향이 있음).
문제점이 확인되면 시스템의 재설계를 연속적으로 수행할 필요없이 문제점을 제거할 수 있는 사항을 빠르게 검사하십시오. 잠재적 단순화 사항, 재사용 및 대안을 기록하십시오(예를 들어, 구매 대 빌드).
목적 | 식별된 결함에서 조치를 수행하기 위함입니다. |
검토 후에 각 식별된 보기에 책임을 할당하십시오. 이 경우, "책임"은 결함을 수정하는 것이 아닐 수 있지만 대안의 추가 조사를 조정하거나 결함의 해결책이 원대하거나 광범위한 경우 이를 조정합니다.
Rational Unified Process
|