개념:
|
라이프사이클에서의 활동: |
개념:백서: |
e-business 어플리케이션을 빌드하는 것은 인터넷 솔루션을 빌드하여 비즈니스 프로세스를 구현하는 것을 의미합니다. 여기에는 e-commerce가 포함되며 조직 전체의 모든 비즈니스 프로세스로 확장됩니다.
E-business 시스템은 다음과 같이 나눌 수 있습니다.
시스템이 생성에서 더 진행할수록 개발은 더 복잡해 집니다.
초기화 단계에 대한 기본 워크플로우는 다음과 같은 확장 또는 변형과 함께 적용됩니다.
이는 중요성이 덜합니다.
이는 덜 강조해도 됩니다. 대부분의 스테이크홀더 요구사항은 비즈니스 모델링 동안 찾아야 합니다. 그러나 시스템의 비기능 요구사항을 찾는 데 초점을 두는 연습을 해야 합니다.
이는 덜 강조해도 됩니다. 일반 어플리케이션에서 보다 시스템이 비즈니스를 더 밀접하게 반영하므로 시스템 경계는 비즈니스 경계에 의해 정의됩니다(어떤 면에서는 시스템이 비즈니스 자체임).
활동: 사용자 인터페이스 설계는 탐색 맵을 생성합니다. 탐색 맵은 사이트 사용자가 탐색하는 방법을 표시하는 웹 솔루션 보기이며 계층 구조 "트리" 다이어그램에 표시될 수 있습니다. 다이어그램의 각 레벨은 해당 화면 또는 페이지에 도달하도록 수행하는 누르기 횟수를 표시합니다. 일반적으로 보통 "홈 페이지"로 알려진 첫번째 페이지에서 한 번만 누르는 가장 중요한 웹 사이트 영역을 차지하려 합니다. 탐색 맵은 각 유스 케이스에 대한 주요 창 또는 웹 페이지를 식별하여 시작되고 사용자가 해당 요소에서 탐색하는 방법을 고려하는 스토리보드의 효과적인 요약입니다.
The basic workflow for the 구현화 단계에 대한 기본 워크플로우는 다음과 같은 확장 또는 변형과 함께 적용됩니다.
활동: 구조 분석은 잘 정의된 메커니즘(웹 브라우저, Java 애플릿 및 servlet, ASP, JSP 및 기타 같은 종류의 것) 세트를 포함하여 비교적 잘 정의된 구조가 웹 어플리케이션에 있다는 지식을 이용합니다. 웹 어플리케이션 개발 프레임워크가 더 구체적이 아닌 경우 일반적으로 개념: 계층화에 설명된 단순한 구조 계층화로 충분합니다. 많은 경우 이전 웹 개발 프로젝트에서 다시 사용하거나 획득할 수 있는 사전 정의된 상용 구조가 있을 수 있습니다. 웹 어플리케이션 프레임워크(예: IBM WebSphere 또는 Microsoft Windows DNA)는 이러한 종류의 구조 템플리트만을 제공합니다.
웹 어플리케이션에는 일반적으로 계획된 정지 시간이 없습니다. 구조는 기본 서버 장애 동안 또는 유지보수나 서버 업그레이드 발생시 대기 서버로 전환 및 실행하는 동안 시스템 업그레이드를 제공해야 하기도 합니다(일반적으로 제공). 일부 웹 어플리케이션 프레임워크는 제작 지원에 필요한 툴을 제공합니다. 그럼에도 불구하고, 어플리케이션에 고급 가용성 요구사항이 있는 경우 이 요구사항을 지원하는 데 필요한 인프라스트럭처를 구매하거나 빌드하고 이러한 성능 지원을 구조에 통합하도록 계획해야 합니다.
활동: 사용자 인터페이스 설계는 구현화 반복에서 반복적으로 수행됩니다. 이 활동의 초기 실행에서는 사이트의 주요 웹 페이지 설계를 모형화하여 표시한 '창조적인 설계 구성' 작성에 초점을 둡니다. 이러한 '컴프'는 일반적으로 브라우저 창을 관찰하기 위한 브라우저 창 그래픽을 사용한 "평면" 그림 틀입니다. '컴프'의 주요 장점은 사이트에 대해 특정 그래픽 방향에서 일치할 때까지 더 정교하고 값비싼 HTML 프로토타입 투자를 지연시키는 것입니다.
'창조적인 설계 구성'은 가장 중요한 유스 케이스의 인터페이스 요구사항을 관찰하고 룩앤필에 대한 많은 대체 설계(10개 이상)를 개발하여 작성합니다 . 스테이크홀더에 표시하도록 이 세트에서 가장 유망한 세 개의 옵션을 선택합니다. 이는 스토리보드 및 탐색 맵 세트를 발생시키는 최종 웹 설계에 합의할 때까지 반복적으로 수행됩니다.
합의하여 서명한 후 창조적인 설계 구성은 기능적 활동: 사용자 인터페이스 프로토타입의 반복을 통해 사용자 인터페이스 프로토타입으로 전개됩니다. 초기 웹 UI 프로토타입은 일반적으로 가장 중요하며 구조적으로 중요한 유스 케이스인 시스템 부분만을 지원합니다. 기능성이 사용자 인터페이스 레이아웃을 작동하며 역행하지 않는지 확인하기 위한 프로토타입을 개발하기 전에 유스 케이스 이벤트 플로우에 좋은 구조를 보유하는 것이 중요합니다.
차후 반복에서 차츰 더 넓은 유스 케이스 범위 및 더 심도있는 구조 연습을 추가하여 웹 프로토타입이 확장됩니다.
활동: 유스 케이스 분석은 GUI 작동뿐만 아니라 일반적으로 웹 서버 또는 어플리케이션 서버에서 실행할 파트인 기초 비즈니스 논리 또한 초점을 두는 것이 중요한 것을 제외하면 비교적 변경되지 않습니다. 이를 잊는 경우 가장 중요한 시스템 작동 부분이 간과될 수 있습니다. 웹 페이지 자체는 '경계' 클래스로 표시되고 데이터 요소는 '엔티티' 클래스로 표시되며 서버측 작동(예: 활성 서버 페이지, servlet 등)은 '제어' 객체를 통해 표시됩니다.
다음 유스 케이스 분석, 활동: 설계 요소 식별은 즉시 웹 개발 프레임워크에 있는 기존 메커니즘으로 맵핑하고 가능하면 반복 또는 이전 프로젝트의 기존 설계 요소를 재사용하여 결과물: 분석 클래스을 정제합니다. 이는 종종 요구된 재사용 정도를 달성하기 위해 식별된 분석 클래스의 정의 및 범위를 재조정할 필요가 있습니다.
웹 어플리케이션을 설명하는 UML 사용에 대한 자세한 설명은 UML을 사용하여 웹 어플리케이션 구조 모델링에 설명되어 있습니다.
사용자 인터페이스 가이드라인 개발 이외에도 사이트 웹 페이지를 빌드하도록 조합되는 그래픽 이미지인 웹 설계 요소가 작성됩니다. 웹 사이트 간 사용자 인터페이스의 일관성은 사용성에 필수입니다. 웹 사이트에서는 일관적인 사용자 인터페이스를 제공해야 합니다. 이를 위해 프로젝트는 전체 사이트에서 일관적으로 표준 그래픽 요소 세트를 사용해야 합니다.
이러한 요소 개발 사용에 필요한 가이드라인 작성이 포함됩니다. 이러한 요소를 사용하는 시기 및 방법을 팀 구성원 모두가 알아야 합니다. 웹 설계 요소의 예로는 탐색 장치 및 페이지 배경과 같은 그래픽 요소가 포함됩니다. 고급, 표준, 그래픽 요소를 사이트 전체에서 재사용하는 일관성은 판매까지 소요되는 시간을 단축하고 더 작은 고급 요소 세트를 전개하여 품질을 향상할 뿐 아니라 개발 비용을 줄여 줍니다.
가이드라인 준비는 사이트에 대한 스타일 가이드를 작성하는 초기 웹 사용자 인터페이스 프로토타입 개발과 함께 완료됩니다. 스타일 가이드에서는 다른 것들 사이에서 웹 설계 요소를 사용해야 하는 방법 및 시기, 색상 설계, 글꼴, 계단식 양식 시트 및 탐색 요소가 기능하고 위치 지정되는 방법에 대한 세부사항을 지정합니다.
활동: 설계 메커니즘 식별은 시스템의 비기능 요구사항을 웹 개발 프레임워크에서 제공하는 메커니즘에 맵핑하는 데 더 중점을 두게 됩니다. 프레임워크에서 제공하지 않는 메커니즘이 있으면 이를 식별해야 하며 대체 솔루션이 있어야 합니다.
활동: 런타임 구조 설명은 대부분 웹 서버 및 어플리케이션 서버 계층에 중점을 두게 되며(개념: 분배 패턴 참조), 프로세스 및 스레드를 사용하여 어플리케이션에서 동시성을 관리합니다. 일반적으로 클라이언트측 시스템에서의 처리에 대한 제어는 거의 없습니다.
활동: 분배 설명에서는 '보유할 서버 노드의 종류'에서 '보유할 서버 노드의 모든 종류 수'에 대한 설명으로 초점이 변경됩니다. 일반적으로 웹 개발 프레임워크에서는 비교적 잘 정의된 기능 경계가 있는 고정된 수의 서버 유형을 제공합니다(예: 웹 서버, 어플리케이션서버, 메일 서버, 의사소통 게이트웨이서버). 결과적으로, 소프트웨어 아키텍트 기술은 보통 필요한 모든 종류의 서버 수를 결정하여 사용 가능한 서버 유형을 사용하는 확장성 및 결함 허용치 요구사항을 처리하는 방법을 결정하는 데 중점을 두게 됩니다. 또한 추가 서버가 필요한 시기를 알 수 있는 방법을 결정하도록 평가 계획을 작성해야 합니다.
계획은 웹 어플리케이션에서 동시 사용자 수를 상당히 늘리도록
지원할 수 있는지 확인하는 성능 테스트에 크게 중점을 둡니다.
결과적으로 테스트 워크플로우 세부사항
테스트 및 평가
,
수용 가능한 임무 달성
또한 구조가 배율 가능한지 확인하는 성능 테스트에 더 많은 비중을 둡니다.
기타 주요 테스트 유형
은 사용성 테스트
및
구조 테스트
입니다. 이는 웹 어플리케이션 구조가 사용자에게 적절한지
확인하는 사용자 인터페이스를 테스트하는 데 필요합니다. 일부 경우, 사용자가
어플리케이션을 사용하는 방법을 모니터할 수 있도록 인터넷에서 어플리케이션을 유지하는 데
초점을 두게 됩니다.
많은 시간을 소모하는 또다른 유형의 테스트는 브라우저 테스트로, 브라우저 및 브라우저 버전 간의 호환성이 종종 사용자 인터페이스의 설계 옵션을 제한하기 때문입니다.
지금까지 프로젝트에서 결정한 구조의 유효성을 확인하기 위해 워크플로우 세부사항: 컴포넌트 구현, 워크플로우 세부사항: 각 서브시스템 통합 및 워크플로우 세부사항: 시스템 통합 실행을 완료하는 하나 이상의 구조 프로토타입이 개발되고 테스트됩니다. 위에서 언급한 대로 테스트는 예기치 못하게 시스템 로드를 증가시키는 어플리케이션의 확장성에 특히 중점을 두어야 합니다.
구축 단계에 대한 기본 워크플로우는 다음과 같은 확장 또는 변형과 함께 적용됩니다.
활동: 서브시스템 통합 계획 및 활동: 시스템 통합 계획은 구축 단계에서 작성된 다양한 종류의 구현 요소를 처리할 필요가 있습니다.
활동: 설계 요소 구현은 몇 가지 다른 종류의 요소에 집중합니다.
- 브라우저 환경에서 "실행되는" 웹 페이지, 애플릿, 스크립트, 그래픽 및 기타 요소
- 웹 서버 환경에서 "실행되는" 서버측 페이지, 스크립트, servlet 및 기타 요소
- 레가시 어플리케이션에 대한 실행 가능 코드 개선사항
- 데이터베이스 관리 시스템에서 실행되는 데이터베이스 테이블, 트리거, 저장된 프로시저 및 기타 요소
다른 종류의 요소에 있는 툴 및 전개 기술이 서로 다르므로 활동: 설계 요소 구현에 대한 유사한 변형이 많아지게 됩니다. 워크플로우 세부사항: 모든 서브시스템 통합 및 워크플로우 세부사항 시스템 통합에 유사한 개조가 있습니다.
테스트 계획은 성능 테스트에 계속 중점을 두지만 점점 기능 테스트에 중점을
두게 됩니다. 웹 어플리케이션으로 구성되는 다른 종류의 요소 각각에 대해 조금씩
다른 테스트 방법이 필요합니다.
테스트 워크플로우 세부사항
테스트 및 평가,
수용 가능한 임무 달성
에서
유사하게 적응되며, 초점은 구조 성능 중심 테스트에서 구조 테스트로 점점 이동하여
시스템 작동의 세부사항이 올바른지 확인합니다.
이 페이지 부분은 컨텍스트 통합과 협력하여 개발됩니다. | ![]() |
Rational Unified Process
|