이 워크플로우 세부사항의 목적은 요구사항에서 제공된 작동의 설명을 설계가 기반을 둘 수 있는 요소 세트로 변환하는 것입니다.

주제


      소프트웨어 요구사항
소프트웨어 요구사항
  탐색 맵
탐색 맵
 
         
 
사용자 인터페이스 설계자
사용자 인터페이스
설계자

 

 
사용자 인터페이스 설계
사용자 인터페이스
설계

 
사용자 인터페이스 프로토타입
사용자 인터페이스
프로토타입

 
         
      탐색 맵
탐색 맵
  사용자 인터페이스 프로토타입
사용자 인터페이스
프로토타입
 

      분석 클래스
분석 클래스
 
       
 
소프트웨어 아키텍트
소프트웨어 아키텍트
 

 
설계 요소 식별
설계 요소 식별

 
       
      설계 서브시스템
설계 서브시스템
설계 모델
설계 모델
 
      설계 패키지
설계 패키지
신호
신호
 
      이벤트
이벤트
설계 클래스
설계 클래스
 
      EJB
EJB
인터페이스
인터페이스
 

      탐색 맵
탐색 맵
설계 모델
설계 모델
 
       
 
기술 검토자
기술 검토자
 

 
설계 검토
설계 검토

 
       
      검토 레코드
검토 레코드
 

      유스 케이스
유스 케이스
 
       
 
설계자
설계자
 

 
유스케이스 분석
유스케이스 분석

 
       
      분석 클래스
분석 클래스
유스 케이스 구현
유스 케이스 구현
 
      분석 모델
분석 모델
 


설명 페이지 맨 위

이 워크플로우 세부사항은 분석되고 설계될 작동 요구사항이 있는 각 반복에서 발생합니다.

작동 요구사항의 분석에는 다음이 포함됩니다.

  • 필요한 작동을 만족시키는 분석 클래스 식별
  • 분석 클래스가 시스템의 논리적 구조(주요 서브시스템 및 클래스)에 조화되는 방법 판별. 분석 클래스는 기존 서브시스템에 속한 것으로 판별되거나 새 서브시스템 작성을 필요로 할 수 있습니다. 또한 분석 클래스로 인해 기존 서브시스템 및 인터페이스가 재정의될 수 있습니다.

이 워크플로우 세부사항은 사용자 인터페이스의 모델링 및 프로토타입을 포함할 수도 있습니다.

관련 정보 To top of page

이 섹션에서는 이 워크플로우 세부사항과 관련된 추가 정보의 링크를 제공합니다.

시기 페이지 맨 위

구현화 단계에서 시작하여 구축 및 이행 단계에서 반복됩니다.

선택성 To top of page

필수사항.

인력 지정 방법 페이지 맨 위

특히 대형 프로젝트에서 사용자 인터페이스 설계 및 프로토타입은 별도 그룹에서 수행되며 시스템 및 사용자 인터페이스의 사용성에만 중점을 둡니다. 그러나 이 그룹은 사용자 인터페이스가 사용자가 기대하는 것인지, 비즈니스 논리가 사용자 인터페이스에서 요구하는 것을 제공하는지(내용 및 사용자 조치에 관해) 확인하기 위해 개발 팀의 다른 구성원(특히, 요구사항 및 비즈니스 논리를 책임지는)과 밀접하게 작업해야 합니다.

활동: 유스 케이스 분석은 혼합된 기술을 가진 소규모 그룹에서 가장 잘 수행됩니다. 인력 가이드라인은 가이드라인: 유스 케이스 분석 워크샵에 표시됩니다. 활동: 설계 요소 식별은 다른 유스 케이스 분석 워크샵의 구조 및 결과에 대한 광범위한 견해를 필요로 하고 프로젝트에서 사용되는 구현 기술 및 프레임워크에 대한 약간을 경험을 필요로 합니다. 문제점 도메인에 대한 이해뿐 아니라 구현 기술에 대한 깊은 지식을 가지고 있는 사람이 검토를 담당해야 합니다.

작업 가이드라인 페이지 맨 위

활동: 사용자 인터페이스 설계활동: 사용자 인터페이스 프로토타입은 구현화 반복 전체에서 반복적으로 수행됩니다. 각 반복은 주요 사용자 인터페이스 요소의 식별 및 설계, 이들 간의 탐색 경로를 포함하는 초기 사용자 인터페이스 설계에 중점을 둡니다. ../../workguid/wg_stbd.htm -- This hyperlink in not present in this generated website스토리보드 작성은 사용자 인터페이스가 작동되는 방법에 대해 보다 나은 이해를 얻기 위해 사용자 인터페이스 설계 중에 사용될 수 있는 효율적인 기술입니다. 초기 사용자 인터페이스 설계에 대한 합의에 도달하면 실행 가능한 사용자 인터페이스 프로토타입의 개발이 시작됩니다. 프로토타입에 대한 피드백이 사용자 인터페이스 설계에 피드백됩니다(가능한 경우 요구사항도). 일반적으로 초기 프로토타입은 시스템 기능의 서브세트만을 지원합니다. 후속 반복에서 점차적으로 시스템 기능에 대한 보다 광범위한 적용 범위를 추가하여 프로토타입이 확장됩니다. 사용자 인터페이스 설계 중에 비기능적 버전의 사용자 인터페이스를 생성하는 주요 장점은 전체 사용자 인터페이스 설계에 대한 합의가 있을 때까지 보다 복잡하고 비용이 많이 드는 기능적 사용자 인터페이스 프로토타입의 투자를 연기하는 것입니다. 시스템의 사용성을 확인하고 검증하기 위해 사용자 인터페이스를 설계하고 프로토타입할 때 시스템의 사용자 및 잠재적인 사용자와 긴밀히 작업하는 것이 중요합니다.

많은 유스 케이스 분석 워크샵이 사용 가능한 자원 풀과 참여자의 기술에만 제한되어 병렬로 조직될 수 있습니다. 각 유스 케이스 분석 워크샵 이후 가능한 빠르게 일부 워크샵 구성원과 일부 구조 팀 구성원이 활동: 설계 요소 식별에서 워크샵의 결과를 병합하는 작업을 수행해야 합니다. 두 팀의 구성원은 필수적입니다. 유스 케이스 분석 팀 구성원은 분석 클래스가 식별되는 컨텍스트를 이해합니다. 반면에 구조 팀은 이미 식별된 기타 유스 케이스뿐 아니라 보다 큰 컨텍스트를 이해합니다.

설계 작업이 완성되고 안정화됨에 따라 점차적으로 더 큰 설계 파트가 검토될 수 있고 검토되어야 합니다. 보다 소규모의, 보다 집중된 검토가 모든 것을 포함하는 대규모 검토보다 더 좋습니다. 매우 특정한 측면에 집중된 16개의 2시간 분량의 검토가 2일 분량의 단일 검토보다 상당히 좋습니다. 집중된 검토에서 검토 초점의 범위를 정하고 적절한 검토 기술을 가지는 소규모 검토 팀에서 검토를 수행할 수 있는지 확인하기 위해 목적을 정의하십시오. 초기 검토는 우선적으로 설계에서의 계층화 및 패키지 무결성, 인터페이스의 안정성 및 품질, 유스 케이스 작동의 적용 범위 완전성에 중점을 두어야 합니다. 이후 검토는 컨텐츠가 정의된 인터페이스를 완전하고 정확하게 구현하는지와 설계 요소 사이의 종속성 및 연관이 필요한지, 충분하지, 올바른지 확인하기 위해 패키지 및 서브시스템으로 드릴 다운해야 합니다. 특정 검토 지점은 각 설계 결과물에 대한 체크포인트를 참조하십시오.



Rational Unified Process   2003.06.15