타스크: 프로젝트 가이드라인 준비
이 타스크는 프로젝트 가이드라인을 준비하는 방법을 설명합니다.
목적

이 타스크의 목적은 다음과 같습니다.

  • 프로젝트에서 사용할 기존 가이드라인을 고르거나 새 가이드라인을 개발합니다.
  • 필요한 경우 프로젝트 구성원이 기존 가이드라인에 액세스할 수 있도록 합니다.
  • 이용자의 피드백을 바탕으로 주제별 전문가와 함께 작업하여 이 가이드라인을 갱신합니다.
관계
역할기본: 추가: 지원:
입력필수:
  • 없음
선택사항: 외부:
  • 없음
출력
단계
프로젝트의 가이드라인 필요성 식별
목적: 프로젝트에서 필요로 하는 가이드라인 식별

생성해야 하는 중간 산출물 및 각각의 중간 산출물에 필요한 형식성 레벨을 기준으로 제품에서 필요로 하는 가이드라인 세트를 식별합니다. 가이드라인을 준비하는 것은 프로젝트의 프로세스를 사용자 조정하는 작업의 일부로 간주되므로 프로세스 엔지니어는 팀에게 제공해야 하는 가이드라인의 유형을 결정하기 위해 프로젝트 관리자와 오랜 시간 동안 논의합니다.

프로젝트 가이드라인의 목적은 다음과 같습니다.

  • 특정 중간 산출물의 프로덕션에 대한 규정적인 안내 제공
  • 중간 산출물이 일관성 있게 개발되고 정의된 규약 및 스타일을 따르는지 확인
  • 프로젝트에서 지켜야 하는 특정 표준에 대한 설명
  • 프로젝트 인력이 중간 산출물의 품질 및 완전성을 검토하기 위한 예비 지침 제공

아래 표에서는 소프트웨어 프로젝트에서 가장 일반적으로 고려해야 하는 몇 가지 사항에 대해 설명합니다. RUP는 프로젝트 사용자 조정의 시작점이 될 수 있는 몇 가지 예제를 제공합니다.

가이드라인 유형
관련 역할
제작자
이용자
비즈니스 모델링 가이드라인
비즈니스 유스 케이스, 비즈니스 작업자 및 비즈니스 엔티티의 모델을 어떻게 만들 것인지 설명합니다. 이 가이드라인은 프로젝트에서 새 시스템을 만들기 위해 비즈니스를 공식적으로 모델링할 때 고려되어야 합니다. 비즈니스 프로세스를 다시 디자인하는 정도 또는 비즈니스 프로세스의 복잡도에 따라 얼마나 상세히 기술되어야 하는지가 결정됩니다.

비즈니스 프로세스 분석가 비즈니스 프로세스 분석가, 비즈니스 디자이너, 전문 기술 검토자
유스 케이스 모델링 가이드라인
유스 케이스가 시스템의 동작을 캡처하는 데 중요한 역할을 할 때마다 필요합니다. 사용할 관계, 텍스트 설명을 위해 지켜야 하는 스타일 등의 모델링 규칙이 포함되어야 합니다.

시스템 분석가 시스템 분석가, 요구사항 지정자, 디자이너

디자인 가이드라인
아키텍처 정의의 제품입니다. 디자인, 아키텍처 디자인 및 구현 시에 지켜야 하는 가이드라인을 설명합니다.

소프트웨어 설계자 디자이너, 구현자, 전문 기술 검토자

프로그래밍 가이드라인
프로젝트에 대해 선택된 실제 구현 언어 및 클래스 라이브러리에 따라 달라집니다. 가이드라인에서는 코드 레이아웃 및 주석을 표시하는 방법, 이름 지정 규칙 사용 방법, 언어 기능 사용 방법을 지정해야 합니다. 특정 언어 기능에 대한 예방 조치도 설명해야 합니다.

소프트웨어 설계자(핵심 구현자의 지원을 받음) 구현자, 테스터
사용자 인터페이스 가이드라인
사용자 인터페이스를 빌드하기 위한 프로젝트 규칙 및 권장사항을 제공해야 합니다. Windows Interface Guidelines for Software Design(Microsoft® Corporation 저)과 같은 외부 자료를 주로 참조합니다.

사용자 인터페이스 디자이너 사용자 인터페이스 디자이너, 디자이너, 구현자

도구 가이드라인
프로젝트에서 선택한 도구 세트를 최대한 활용하는 방법을 설명합니다. 도구당 하나의 가이드라인을 제공할 수 있습니다. 도구 가이드라인에 주로 포함되는 내용은 다음과 같습니다.

  • 버전, 구성 매개변수 등의 설치 정보
  • 기능 제한사항 및 프로젝트에서 사용하지 않기로 결정한 기능
  • 해결책
  • 수행 프로시저, 사용할 소프트웨어 및 적용할 원칙을 비롯하여, 다른 도구와의 통합
도구 전문가 도구 전문가, 테스터, 시스템 관리자, 도구 사용자
테스트 가이드라인
주어진 프로젝트에서 테스트 프로세스를 규정하는 방법에 대한 조정(주로 전술적인 면)을 기록하고 테스트 프로세스의 동적 규정 과정에서 발견된 프로젝트 사례를 캡처하는 데 사용됩니다. 테스트 가이드라인의 예는 테스트 완료 기준 및 결함 관리 가이드라인입니다.

 
테스트 디자이너 테스트 디자이너, 테스터, 테스트 분석가

참고: 모든 가이드라인 세트를 미리 결정할 필요는 없습니다. 가이드라인 및 구체적인 예에 대한 필요성이 반복을 위한 환경을 준비하는 과정에서 발견되기도 합니다.

프로젝트 사용을 위해 가이드라인 준비
목적: 식별된 가이드라인을 프로젝트 구성원에게 제공하기 위해 준비

식별된 가이드라인의 결과 세트를 분석할 때 내려야 하는 중요한 결정 하나는 "구매 또는 빌드"할 것인지 결정하는 것입니다. 필요한 가이드라인을 "공짜로" 얻을 수도 있겠지만 가이드라인 세트를 프로젝트 컨텍스트에서 유용한 가이드라인으로 변환하는 비용과 특정 필요에 맞게 가이드라인을 개발하는 또는 전체 가이드라인을 생략하는 비용을 비교하면서 고려해야 합니다.

하위 주제:

기존 가이드라인 얻기페이지 맨 위로 이동

프로젝트 프로세스를 책임지는 프로세스 엔지니어는 유용한 기존 가이드라인이나 프로젝트 구성원이 고품질의 소프트웨어를 보다 효율적으로 생성하는 데 도움이 되는 예를 지속적으로 찾습니다. 회사의 자산 저장소에 일부 가이드라인이 보관되어 있을 수도 있으며 "조직별 사례"로 편집되어 있을 수 있습니다. "공용 표준" 범주에 속하는 가이드라인도 있을 수 있으며 기존 문헌이나 인터넷을 통해 찾아볼 수도 있습니다.

새 가이드라인 개발 페이지 맨 위로 이동

대부분의 가이드라인은 처음에는 프로젝트 내부의 마이크로 프로세스에 대한 문서 등과 같은 프로젝트 중간 산출물로 생성되며, 대부분의 다른 자산과 마찬가지로 가이드라인의 가치를 프로젝트 범주 밖에 속하는 것으로 보고 재사용가능한 후보로 테스트하는 사람도 있습니다.

새 가이드라인을 프로젝트 내에서 생성하기로 결정한 경우 여기에 주의를 기울이고 내부 프로젝트 중간 산출물로 간주해야 합니다. 이를 위해 자원을 할당하여 가이드라인을 생성 및 확인하고 적절한 반복 계획에 포함시켜야 합니다.

처음에는 되도록 프로젝트의 특정 컨텍스트에 대한 가이드라인을 개발하는 것이 좋습니다. 현재의 특정 목적에 맞게 개발하는 대신 향후 재사용할 수 있도록 중간 산출물을 일반화하는 데 초점을 맞추다가 프로젝트가 궤도를 벗어나는 경우가 많습니다. 조직의 프로세스 개선 노력의 일환으로, 생성된 가이드라인을 향후 프로젝트에서 재사용할 것을 고려하십시오. 가이드라인 또는 프로젝트 중간 산출물을 재사용가능한 자산으로 변환하는 작업은 이상적인 경우 단일 프로젝트 예산 밖의 일로 간주되어야 합니다.

새 가이드라인은 프로젝트 라이프사이클의 어느 시기에서나 개발될 수 있습니다. 다른 중간 산출물을 생성하기 위한 성공적인 접근 방식을 문서화하는 타스크로, 또는 "적시"에 주로 개발됩니다.

가이드라인 사용자 조정 페이지 맨 위로 이동

가이드라인 및 예는 프로젝트의 컨텍스트에 맞아야 합니다. 그렇지 않다면 나중에 사용되지 않을 것입니다. 프로젝트에 맞게 가이드라인을 사용자 조정하는 것은 프로제스 엔지니어 및 주요 이용자 대표의 책임입니다. 다른 프로젝트에서 선별한 가이드라인은 약간 다른 컨텍스트에서 개발된 것이므로 이를 사용자 조정하는 것이 특히 중요합니다.

사용자 조정된 결정을 캡처해야 합니다. 이 결정은 동일한 가이드라인을 재사용하게 될 향후 프로젝트에서 유용할 수도 있습니다.

액세스할 수 있도록 가이드라인 제공페이지 맨 위로 이동

가이드라인을 사용자 조정하는 것이 중요한 만큼 준비된 가이드라인을 액세스할 수 있도록 제공하는 것도 중요합니다. 가이드라인이나 예를 어디에서 찾을 수 있는지 누구에게 피드백을 제공해야 하는지에 대해 이용자에게 명확하게 알려줘야 합니다.

RUP 플러그인 기술을 사용하는 공개된 프로세스 웹 사이트를 통해 가이드라인이 제공됩니다. 이 사이트에서 가이드라인을 관련된 중간 산출물 및 타스크와 연관지을 수 있습니다. 자세한 정보는 개념: RUP 사용자 조정을 참조하십시오.  

가이드라인 유지보수
목적: 이용자의 사용 경험을 바탕으로 가이드라인 개선

재사용을 원하는 조직에서는 프로젝트에서 자산 사용에 대한 피드백을 제공하는 것이 프로세스 개선 노력에 아주 중요합니다. 대부분의 우수 사례는 많이 사용되고 조정 및 개선되는 시간을 거쳤기 때문에 우수 사례가 될 수 있었다는 점을 기억해야 합니다.

가이드라인과 관련된 문제를 발견하고 잠재적인 개선사항을 찾으려면 가이드라인을 수정하고 프로젝트 외부에서 처리되도록 변경 요청을 제기하는 옵션이 프로젝트에 있어야 합니다. 어떤 옵션을 선택할 것인지는 조직의 프로세스 노력의 공식성 및 문제의 복잡도에 따라 달라집니다. 프로젝트 관리자는 필요한 경우 가이드라인을 개정하고 추가로 개발하기 위해 반복할 때마다 시간 슬롯을 정의할 것을 고려해야 합니다. 팀 구성원에게 사용이 편리한 포럼을 제공하여 발견된 개선사항을 즉시 기록하도록 하는 것도 좋은 방법입니다.

특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보