용어 설명 glossary

이 용어집에서는 프로젝트 검사 목록.

비즈니스 이해 관계자의 수락 acceptance-from-business-stakeholders

비즈니스 이해 관계자의 수락은 주요 이해 당사자들이 솔루션에 맞춰 정렬되고 비즈니스 요구 사항이 비즈니스 사례를 충족하는 방법에 대한 승인을 받았음을 확인합니다.

수락 테스트 acceptance-tests

승인 테스트는 애플리케이션이 프로덕션 준비가 되었을 때 수행됩니다. 테스트는 실시간 시나리오를 사용하여 다양한 유형의 최종 사용자를 나타내는 그룹에 의해 수행됩니다.

수락 테스트는 이(가)

수락 테스트를 계획하고 디자인하면 최종 배포가 더 쉬워집니다. 고객 및 품질 보증 팀과 함께 정의해야 합니다.

프로젝트 시작 시 모든 세부 사항을 정의할 수는 없지만 초기 정의는 논의하고 동의해야 합니다. 수락 테스트는 아마도 기본적인 요구 사항(기능 및 성능)을 기반으로 할 것입니다.

테스트 시스템 통합 액세스 access-to-test-system-coordinated

모든 역할에 필요한 시스템 액세스 수준이 부여되었는지 확인합니다.

Adobe 보안 검사 목록 adobe-security-checklist

다음 Adobe 보안 검사 목록 는 AEM이 설치 시 안전한지 확인하기 위해 제공된 공식 확인 목록입니다. 인스턴스의 무결성을 유지하기 위해 수행해야 하는 보안 조치와 확인 단계가 포함되어 있습니다.

Adobe 지원 포털 프로젝트 설정 adobe-support-portal-project-set-up

Adobe 지원 포털을 통해 구현 파트너와 고객은 지원 포털에서 AEM 구현을 프로젝트로 설정할 수 있습니다.

세부 사항은 등록할 수 있습니다. 예를 들어 구현된 기술 및 버전에 대해 알아보십시오. 이는 고객과 Adobe 간의 투명성을 제공합니다.

AEM 관리자 교육 aem-administrator-training

솔루션 관리자 교육 자세한 내용은 Adobe 교육 서비스 추가 정보.

AEM 작성자 교육 aem-author-training

솔루션에 대한 컨텐츠를 제작(작성)할 직원을 위한 교육. 자세한 내용은 Adobe 교육 서비스 추가 정보.

AEM 인증 시험 aem-certification-exam

해당 가상 사용자를 등록하여 인증 시험.

AEM Certified aem-certified

해당 가상 사용자가 인증 시험.

AEM 기술 교육 aem-technical-training

해당 사용자에 대한 기술 교육 제공 예를 들어 개발자, 설계자, 엔지니어 및 비즈니스 실무 담당자들이 있습니다.

프로젝트 목표로 정의된 KPI에 대한 계약 agreement-on-kpis-defined-as-goals-for-the-project

KPI(주요 성과 지표)는 조직이 조직의 목표 및 목표에 대한 진행 상황을 정의하고 측정할 수 있도록 지원합니다. 한 조직이 그것의 임무를 분석하고 목표를 정의했으면, 그 목표들에 대한 진보를 측정할 필요가 있습니다. KPI는 측정을 위한 메커니즘을 제공합니다.

비즈니스 및 성능 KPI 정렬 align-business-and-performance-kpis

비즈니스 및 성과 조정 KPI(주요 성과 지표)는 조직 내에서 관련된 모든 인력과 프로세스를 결합하는 데 도움이 됩니다. 따라서 비즈니스 목표를 달성하고 제안된 목적을 달성하는 데 필요한 시간과 노력을 줄일 수 있습니다.

KPI를 사용하여 컨텐츠 아키텍처 정렬 alignment-of-content-architecture-with-kpis

제안된 컨텐츠 아키텍처가 관련 주요 성능 지표(KPI)와 일치하는지 확인합니다.

프로젝트 타임라인에 고객 로드맵 조정 alignment-of-the-customer-roadmap-with-project-timeline

고객 로드맵은 높은 수준의 이정표와 비즈니스 목표로 구성되어 있습니다. 프로젝트 타임라인은 이 전략을 준수하며 이에 부합해야 하므로 잠재적 위험 및/또는 가능한 편차를 강조 표시하고 추적해야 합니다.

애플리케이션 아키텍처 정의 application-architecture-definition

다음 애플리케이션 아키텍처 제안된 애플리케이션의 동작을 명확하게 정의해야 합니다.

핵심 사항:

정의된 응용 프로그램 특정 유지 관리 작업 application-specific-maintenance-tasks-defined

표준 Adobe Experience Manager(AEM) 유지 관리 작업 외에도 지속적인 솔루션 유지 관리를 위해 실행해야 하는 기타 작업 작업을 정의해야 합니다.

적절한 교육을 받은 직원 appropriately-trained-staff

적절한 교육을 통해 팀원이 구성되어 있는지 확인하십시오. 프로젝트 팀의 경우 다음을 모두 포함하는 것이 좋습니다.

아키텍처 다이어그램 architecture-diagram

아키텍처 다이어그램은 아키텍처의 그래픽 표현입니다. 여기에는 다음에 대한 표현이 포함됩니다.

아키텍처 초안 architecture-draft

이렇게 하면 시스템 및 솔루션 아키텍처에 대한 높은 수준의 보기가 제공됩니다. 이 단계에서 그것은 나중에 검토되고 정제될 초안입니다.

아키텍처 검토 보드 승인 architecture-review-board-sign-off

아키텍처 검토 위원회는 다음과 같은 조직 간 기구입니다.

검토 위원회는 아키텍처와 관련된 모든 주요 이해 당사자를 대표해야 합니다. 일반적으로 그들은 전체 아키텍처의 검토 및 유지 관리를 담당하는 일단의 경영자들로 구성될 것이다.

KPI와 비교하여 실제 컨텐츠 및 결과에 맞게 조정된 자동화된 테스트 세트 automated-test-suite-adapted-for-real-content-and-results-compared-to-kpis

자동화 스크립트 및 기본적인 자동화된 사용 사례:

자동화된 테스트 전략 automated-testing-strategy

이 전략은 QA(Quality Assurance) 팀이 계획하는 접근 방식과 함께 재사용 가능한 자동 스크립트에 대한 프레임워크를 정의합니다. 이 섹션에서는 다음을 보장할 수 있도록 자동화 테스트에 대한 전체 계획을 간략하게 설명합니다.

실제 및 예상 부하에 대해 검증된 자동화된 테스트 전략 automated-testing-strategy-validated-against-realistic-and-expected-load

자동화된 테스트 전략은 솔루션에 있을 컨텐츠 및 예상 로드에 따라 검증 및 조정되어야 합니다.

자동화 전략 automation-strategy

배포 자동화를 통해 빠르고 일관된 배포를 보장합니다. 자동화 전략에서는 이러한 자동화 메커니즘의 구성을 간략하게 설명합니다. 다음을 포함합니다.

통신 계획 인식 aware-of-communication-plan

전체 프로젝트 팀과 모든 이해 관계자는 다음 사항을 알고 있는지 확인해야 합니다.

성공 정의 및 기준 인식 aware-of-success-definitions-and-criteria

전체 프로젝트 팀과 모든 이해 관계자는 다음 사항을 알고 있는지 확인해야 합니다.

백업 및 복원 개념 backup-and-restore-concept

Backup and Restore Concept는 솔루션에 구현될 기술 기능을 간략하게 설명합니다. 회사 백업 및 복원 정책에 필요합니다.

백업 및 복원 테스트 backup-and-restore-tested

백업 및 복원 개념을 기반으로 하는 전체 엔드 투 엔드 테스트.

비즈니스 사례 business-case-s

비즈니스 사례 문서는 작업 수행, 대체 작업 수행(가능한 경우) 또는 작업을 수행하지 않는 것과 관련된 인수를 제공합니다. 논거는 구체적인 사실(가능한/관련성이 있는 곳)에 기초하여 균형 있게 조정되어야 하며 모든 사건에 대한 장점과 위험을 강조해야 한다.

비즈니스 사례 문서는 제안된 솔루션의 구현을 위한 강력한 인수로 결론을 내리면서 모든 옵션의 명확한 정의가 되어야 합니다.

비즈니스 분석가가 프로젝트 및 기대 범위 이해 business-analyst-understands-scope-of-project-and-expectations

비즈니스 분석가는 다음을 완전히 이해했음을 확인해야 합니다.

비즈니스 KPI business-kpis

조직에서는 주요 성과 지표(KPI)를 사용하여 목표에 도달하는 동안 성과를 평가합니다.

비즈니스 KPI는 기업이 주요 비즈니스 목표를 얼마나 효과적으로 달성하는지 보여주는 측정 가능한 가치를 정의합니다. 비즈니스/시나리오에 적합한 KPI를 정의, 측정 방법, 사용 방법 및 누구에 따라 정확하게 선택하는 것이 중요합니다.

비즈니스 요구 사항 설명서 business-requirements-documentation

비즈니스 요구 사항 문서(BRD)는 프로젝트에 대한 비즈니스 솔루션을 자세히 설명하며 고객의 비즈니스 요구 사항과 기대치를 명확하게 설명합니다. BRD는 또한 비즈니스 솔루션과 기술 솔루션을 구별한다.

비즈니스 솔루션을 검토할 때 BRD는 다음 질문에 답해야 합니다. "기업이 원하는 것은 무엇입니까?"

ROI 및 KPI 기대치에 따라 파악되고 조정된 솔루션 또는 아키텍처에 대한 요구 사항에 대한 비즈니스 승인 business-sign-off-on-any-required-adjustments-to-the-solution-or-architecture-identified-and-aligned-against-roi-and-kpi-expectations

위험 평가 및 침투 테스트 프로세스는 솔루션의 아키텍처 또는 개발에서 해결해야 하는 문제와 결과를 생성할 수 있습니다.

이러한 프로세스에서 발생하는 모든 조정 사항은 기업이 검토 및 승인하고 전체 목표에 대해 조정해야 합니다.

캐싱 전략 caching-strategy

캐싱 전략에서는 최종 사용자에 대해 캐시되는 내용을 간략하게 설명합니다. 성능 KPI와 호환되어야 합니다.

예를 들어 이미지, Javascript 및 기타 서버 파일과 같은 요소를 캐시하여 솔루션의 성능을 향상시킬 수 있습니다.

코딩 지침 coding-guidelines

코딩 지침은 솔루션을 개발할 때 개발자가 따라야 하는 기본 원칙을 정의합니다. 여기에는 다음과 같은 것들이 포함될 수 있습니다.

통신 작업 설명서 communicate-operations-manual

모든 적절한 성향/역할이 작업 설명서를 수신했는지 확인합니다.

성과 테스트 보고서 전달 communicate-performance-test-report

모든 적절한 성향/역할이 성능 테스트 보고서를 받았는지 확인합니다.

릴리스 노트 전달 communicate-release-notes

모든 적절한 성향/역할이 릴리스 노트를 수신했는지 확인합니다.

팀에 범위 및 기대 전달 communicate-scope-and-expectations-to-team

프로젝트 팀이 프로젝트 범위 및 제공 기대치를 충분히 인식하고 그에 맞게 조정하는지 확인합니다.

교육 자료 및 사용 안내서 전달 communicate-training-materials-and-user-guides

모든 적절한 성향/역할이 교육 자료 및 사용 안내서를 수신하는지 확인합니다.

고객 보안 요구 사항 준수 compliance-with-customer-security-requirements

고객의 보안 요구 사항이 모두 적용되어 있는지 확인합니다.

보안 개념 준수 compliance-with-security-concept

보안 개념이 적용되어 있는지 확인합니다.

구성 요소 및 템플릿 관계 개념 components-and-templates-relationship-concept

새 응용 프로그램에서 사용할 템플릿 및 구성 요소의 개요입니다. 상속 규칙, 권한 및 관계와 같은 세부 사항을 포함합니다.

구성 요소 및 템플릿 관계 사양 components-and-templates-relationship-specification

구성 요소 및 템플릿 관계 개념에 대한 세부 사항입니다.

구성 요소 사양 components-specification

구현할 각 구성 요소에 대한 사양 세부 정보입니다.

외부 인터페이스 Mock-up 개념 concept-for-mock-ups-of-external-interfaces

개발 또는 테스트 환경에 열기/사용할 수 없는 외부 인터페이스를 개발 및 테스트하는 방법에 대한 개념입니다.

이러한 인터페이스의 샘플 구성을 계획/구현하여 테스트가 가능한 한 프로덕션과 유사한 동작에 근접하도록 합니다.

컨텐츠 아키텍처 문서 content-architecture-document

컨텐츠의 제안된 아키텍처에 대한 설명서입니다. 세부 사항에는 (그 외) 다음 사항이 포함되어야 합니다.

마이그레이션에 대해 검증된 콘텐츠 content-validated-for-migration

기존 시스템 컨텐츠가 검토되고 선택한 컨텐츠가 새 솔루션으로의 마이그레이션을 위해 검증됩니다.

계약 초안 contract-draft

법률 계약의 초기 초안.

현재 컨텐츠 구조 및 형식 current-content-structure-and-format

현재 컨텐츠 아키텍처 및 형식에 대한 문서 향후 컨텐츠 아키텍처를 생성하는 데 사용됩니다. 마이그레이션 개념에도 사용됩니다.

고객 백업 및 복원 정책 customer-backup-and-restore-policy

다음과 관련된 고객의 정책:

고객 코딩 지침 customer-coding-guidelines

개발 수행 방법에 대한 고객의 모든 지침/요구 사항입니다.

고객 배포/릴리스 정책 customer-deployment-release-policies

배포/릴리스를 수행할 수 있는 방법과 시기를 정의하는 고객의 정책입니다.

이러한 요구 사항에는 대개 일정, 일정 및 승인 요구 사항이 포함됩니다.

고객 모니터링 정책 또는 요구 사항 customer-monitoring-policies-or-requirements

모니터링해야 하는 사항에 대한 고객 정책 및 요구 사항입니다. 이는 모니터링 개념에 지정된 권장 사항 외에 있습니다.

고객 프로덕션 릴리스 일정 customer-production-release-schedule

프로덕션 환경에 대한 릴리스에 대해 고객이 정의하는 예약입니다.

고객 보고 정책 및 요구 사항 customer-reporting-policies-and-requirements

고객이 보고와 관련된 모든 정책 및/또는 요구 사항입니다. 여기에는 다음이 포함될 수 있습니다.

고객 로드맵 customer-roadmap

기술 및 비즈니스 모두 구현할 주요 이정표에 대한 로드맵을 마련합니다. 이 로드맵은 고객에게 전달됩니다.

고객 보안 정책 customer-security-policies

고객(비즈니스 및 IT)에게는 솔루션에 필요한 보안 수준을 정의하는 정책이 있습니다. 여기에는 다음이 포함될 수 있습니다.

고객 사양 지침 customer-specification-guidelines

고객이 사양에 대한 형식, 납품 및 로그오프와 관련된 모든 지침입니다.

고객 테스트 보고서 customer-test-reports

UAT(User Acception Test) 기간 동안 고객에서 Quality Lead로 보고합니다.

업그레이드에 영향을 주는 사용자 지정 및 핫픽스가 문서화되었습니다. customizations-and-hotfixes-that-affect-upgrades-documented

적용된 모든 사용자 지정 및/또는 적용된 핫픽스는 향후 업그레이드에 영향을 줄 수 있으므로 문서화해야 합니다.

일별 사용자 수락 테스트 보고서 daily-user-acceptance-test-report

UAT(User Acception Testing)로 인한 보고서 또는 회의. 자세한 내용은

기본 보안 사용 default-security-enabled

AEM에 대한 기본 보안 설정이 활성화/구현되었는지 확인합니다.

배포/릴리스 정책 및 프로세스 deployment-release-policies-and-processes

프로젝트의 배포 및 릴리스를 모두 다루는 공식 정책. 여기에는 다음이 포함될 수 있습니다.

배포 케이던스 설정 deployment-cadence-established

환경 간에 필요한 배포 빈도를 정의합니다.

개발 방법론 development-methodology

소프트웨어 개발 방법론에는 소프트웨어 개발 작업의 전체 프로세스를 개별 단계(또는 단계)로 세분화하는 작업이 포함되며 각각 고유한 활동이 있습니다. 그 목적은 계획과 관리를 향상시키는 것이다.

방법론을 정의할 때는 애플리케이션을 개발하거나 유지 관리하기 위해 프로젝트 팀이 만들고 완료한 특정 결과물과 객체를 미리 정의해야 합니다.

개발 역할 정의 development-role-definition

솔루션 내에서 IT(성능 또는 기타) 및/또는 단위 테스트를 실행하는 개발자 및/또는 역할을 정의합니다.

개발 환경 준비 development-environment-ready

배포 자동화에 필요한 통합 도구 기능을 사용하여 개발 환경이 구성되어 있는지 확인합니다.

개발 팀이 프로젝트 및 기대 범위 이해 development-team-understands-scope-of-project-and-expectations

개발 팀은 다음을 완전히 이해했는지 확인해야 합니다.

대화 상자 사양 dialogs-specification

솔루션에 필요한 대화 상자에 대한 세부 정보입니다.

문서 개발 환경 설정 document-development-environment-setup

개발 환경에 대한 설명서입니다.

문서 프로덕션 환경 설정 document-production-environment-setup

프로덕션 환경에 대한 설명서입니다.

문서 테스트 환경 설정 document-test-environment-setup

테스트 환경 설명서입니다.

내구성 테스트 durability-test

내구성 테스트에서는 특정 로드에서 솔루션의 성능을 보여줍니다. 테스트는 솔루션이 임계값 로드에 제출할 때 지속되는 시간과 성능 수준을 측정합니다.

내구성 테스트 실행 durability-test-executed

내구성 테스트 실행.

오류 처리 개념 error-handling-concept

오류 처리란 프로그래밍, 응용 프로그램 및 통신 오류의 예상, 감지 및 해결을 나타냅니다.

오류 처리 설명서 error-handling-documentation

오류 처리 개념을 기반으로 제안된 오류 처리에 대한 자세한 설명서입니다.

에스컬레이션 프로세스 escalation-processes

모든 에스컬레이션 프로세스의 정의 각 프로젝트 수준에 대해 별도의 프로세스가 있습니다.

정규 품질 검토 세션 설정 establish-regular-quality-review-sessions

적절한 팀 구성원과 정기적인 품질 검토 회의를 만듭니다.

기존 권한 구조 existing-permissions-structure

기존 솔루션 또는 조직 내에 정의된 기존 권한 및 그룹 세트에 대한 설명서입니다.

기존 시스템 맵 existing-systems-map

기존 시스템 및 종속성의 다이어그램(또는 다이어그램 세트)

예상 성공 정의 및 기준 expected-success-definitions-and-criteria

프로젝트 후원사는 프로젝트의 성공에 관련된 비즈니스 기대치를 수집합니다. 프로젝트 시작 시 전체 예상 세트를 사용할 수 있어야 합니다. 이러한 예상 집합은 구현 전체에서 수행한 모든 결정에 영향을 주므로

확장에는 다음이 포함될 수 있습니다.

경험 디자인 요구 사항 experience-designs-requirements

솔루션의 전체 경험에 대한 요구 사항입니다. 개인화, 교차 장치 지속성 및 사용자 경험과 같은 요소에 대해 다룹니다.

경험 사양 experience-specifications

Experience Design 요구 사항에 대한 세부 사항입니다.

외부 시스템 및 사용자 종속성/시스템 컨텍스트 external-system-and-user-dependencies-system-context

솔루션의 전체 에코시스템을 요약하는 다이어그램(또는 다이어그램 세트)입니다. 여기에는 외부 통합, 인터페이스, 종속성 및 네트워크와 같은 요소가 포함되어야 합니다.

대체 시스템 및 절차 fallback-system-and-procedure

대체 시스템의 정의:

테스트 대상 시스템 및 절차 fallback-system-and-procedure-tested

대체 시스템의 엔드 투 엔드 테스트.

비즈니스 이해 관계자의 대체 시스템 로그오프 fallback-system-sign-off-from-business-stakeholders

대체 시스템 및 관련 절차가 중요한 비즈니스 기능을 보장할 수 있도록 비즈니스 이해 당사자로부터 로그오프하십시오.

KPI에 대한 실행 가능성 확인 feasibility-confirmation-on-kpis

AEM과 고수준 솔루션 설계를 위한 타당성 조사 결과. KPI에 대해 이러한 매개 변수를 측정하여 충족해야 합니다.

최종 계약 finalized-contract

그 프로젝트를 진행하기 전에 확정되고 서명된 계약이 필요하다. 이것은 계약 초안.

이해 관계자가 수락한 솔루션의 기능 functionality-of-the-solution-accepted-by-stakeholders

이해 관계자가 다음을 완전히 수락하는지 확인:

Go Live Schedule go-live-schedule

다음에 필요한 활동의 타임라인 및 일정:

정의된 행복한 경로 happy-paths-defined

행복한 경로는 예외적인 또는 오류 조건이 없는 기본 시나리오입니다. 모든 것이 예상대로 진행될 때 실행되는 활동의 시퀀스로 구성됩니다.

하드웨어 예상 hardware-estimates

초기 예상:

요구 사항을 충족하기 위한 하드웨어 사용 가능 hardware-will-be-available-to-fulfill-requirements

모든 환경에 필요한 최소 하드웨어가 적소에 있는지 확인합니다.

높은 수준 요구 사항 high-level-requirements

상기 고수준 요구사항의 정의는 다음과 같은 측면을 포함하는, 시스템에 대한 일반화된 요구사항의 분류를 제공한다.

이러한 기능에 대한 기본 세부 사항은 일반적으로 알려져 있으므로 이 문서는 추적이 아니어야 합니다.

높은 수준의 솔루션 설계 high-level-solution-design

고급 솔루션 설계에서는 솔루션 개발에 사용될 아키텍처에 대해 설명합니다. 아키텍처 다이어그램은 제품 및 인터페이스에 대해 개발될 주요 구성 요소를 식별하여 전체 시스템에 대한 개요를 제공합니다.

높은 수준 시스템 맵 high-level-system-map

이 시스템 맵은 시스템의 매우 높은 수준 다이어그램을 제공해야 합니다. 관련된 모든 시스템의 일반화된 맵이라는 점에서 솔루션 컨텍스트와 다릅니다. 이 다이어그램에는 인터페이스가 없습니다.

이전 컨텐츠 구조 historical-content-structure

레거시 시스템의 콘텐츠 구조에 대한 정의입니다. 이것은 참조 및 마이그레이션 전략을 준비할 때도 사용됩니다.

이전 성과 및 이전 성과 KPI historical-performance-and-historical-performance-kpis

레거시 시스템에서 성능 통계 및 성능 KPI를 수집하고 문서화해야 합니다. 이러한 매개 변수는 참조 포인트로 사용되고 새로운 솔루션을 벤치마킹하기 위해 사용됩니다.

주요 솔루션/기능 확인 identify-critical-key-solutions-functionalities

비즈니스 크리티컬 기능 목록

구현 - Penetration Test Results에 따른 변경 사항 implementation-changes-based-on-penetration-test-results

Penetration 테스트의 결과를 기반으로 솔루션에 필요한 모든 변경 사항(로그오프됨)을 구현합니다.

구현 - 자동화된 테스트 전략 implementation-automated-testing-strategy

자동화된 테스트를 지원하는 데 필요한 도구 및 프로세스 설정

구현 - 자동화 전략 implementation-automation-strategy

자동화를 지원하는 데 필요한 도구 집합 및 프로세스 설정

구현 - 컨텐츠 아키텍처 implementation-content-architecture

컨텐츠 아키텍처 구현, 개념 태깅 및 컨텐츠 재사용

구현 - Experience Design implementation-experience-design

Experience Design을 지원하기 위한 요구 사항 구현.

구현 - 대체 시스템 및 절차 implementation-fallback-system-and-procedures

대체 시스템 및 관련 절차 구현

구현 - 통합 implementation-integration

모든 필수 외부 시스템과의 통합 구현.

구현 - 마이그레이션 전략 implementation-migration-strategy

새 솔루션에 대한 컨텐츠 및 기타 객체의 유효성 검사와 함께 마이그레이션합니다.

구현 - 역할 및 권한 implementation-roles-and-rights

역할 및 권한, 사용자 및 그룹 구현

구현 - 보안 개념 implementation-security-concept

AEM 기본값을 포함한 모든 보안 조치의 구현입니다.

구현 - 보안 소프트웨어 implementation-security-software

소프트웨어 애플리케이션 보안 구현

구현 - 시스템 아키텍처 보안 개념 implementation-system-architecture-security-concept

시스템 보안 구현.

구현 - URL 처리 implementation-url-handling

URL 처리 개념 구현.

구현 - 워크플로우 implementation-workflows

디자인된 워크플로우의 구현.

구현 개념 implementation-concept

구현 개념은 전체 구현에 대한 안내 원칙을 제공합니다. 다음 사항을 고려해야 합니다.

이 개념은 솔루션에서 사용되는 프레임워크, 라이브러리 및 기타 아티팩트를 참조할 수도 있습니다.

Go Live 일정에 대해 Adobe 지원 팀에 알림 inform-adobe-support-about-the-go-live-schedule

Adobe 지원 센터에 문의하여 필요한 모든 지원이 실행 중에 활성화되도록 하십시오.

초기 경험 디자인 initial-experience-designs

경험 디자인을 위한 사전 개념.

통합 테스트 integration-testing

내부 및 외부 모든 통합의 테스트 및 결과 확인

시스템 안정성을 보장하려면 이 작업을 자동화하고 자주 실행해야 합니다.

문제 추적 프로세스 issue-tracking-process

지우기 프로세스는 모든 문제가 해결되도록 하기 위해 발생한 모든 문제를 기록하고 진행 중인 활동을 추적합니다.

문제 추적 시스템 및 프로세스 issue-tracking-system-and-processes

모든 문제가 해결되도록 하기 위해 필요한 프로세스와 함께 발생한 모든 문제를 기록하고 진행 중인 활동을 추적하는 추적 시스템입니다.

모든 프로젝트 이해 관계자는 프로젝트 상태의 투명성을 높이기 위해 액세스 권한을 가져야 합니다.

Atlassian JIRA 및 HP Quality Center를 예로 들 수 있습니다.

문제 추적 시스템 프로세스가 설정 및 통합되었습니다. issue-tracking-system-process-is-set-up-and-integrated

선택한 툴링이 완전히 통합되고 모든 필수 역할에 액세스가 부여됩니다.

레거시 시스템 legacy-system

프로젝트의 경우 기존 시스템은 새 솔루션으로 대체되는 기존 기술, 컴퓨터 시스템 또는 응용 프로그램 프로그램입니다.

레거시 시스템의 세부 사항을 수집하여 사용 중단될 수 있는 항목, 사용 중지 시기 및 다른 시스템에 미치는 영향을 알고 있어야 합니다.

사용할 개발 도구 목록 list-of-development-tools-to-be-used

구현에 사용할 도구의 개요. 도구에는 다음이 포함되어야 합니다.

Adobe 지원 포털에 액세스해야 하는 사용자 목록 list-of-users-that-require-access-to-adobe-support-portal

Adobe 지원 포털에 액세스해야 하는 모든 사용자 및 역할 목록입니다.

이 목록은 일반적으로 솔루션 설계자 및/또는 고객 IT 직원으로 구성됩니다.

로그 파일 분석 log-file-analysis

솔루션을 모니터링하기 위해 로그인해야 하는 항목을 정의하는 결과 권장 사항과 함께 분석:

유지 관리 작업(AEM 특정) 테스트 및 사용 maintenance-tasks-aem-specific-tested-and-enabled

다음과 같은 AEM 유지 관리 작업을 테스트 및 활성화합니다.

마이그레이션 계획 migration-plan

마이그레이션을 문서화합니다. 포함

마이그레이션 전략 migration-strategy

새 솔루션에 매핑된 기존 콘텐츠, 콘텐츠 아키텍처 및 형식에 대한 전체 설명입니다. 다음을 다룹니다.

또한 마이그레이션 및 새 시스템의 실제 가동 기간 동안 컨텐츠를 최신 상태로 유지하는 방법(또는 가능한 한 최신)을 추천해야 합니다. 이는 컨텐츠 고정, 이중 게시 또는 알파 시스템의 유지 관리를 의미할 수 있습니다.

모니터링 - CPU monitoring-cpu

솔루션의 시스템 CPU 사용 모니터링:

모니터링 - 디스크 I/O monitoring-disk-i-o

솔루션의 디스크 입출력 속도 모니터링:

모니터링 - 디스크 공간 monitoring-disk-space

솔루션의 디스크 공간 사용 모니터링:

다음을 통해 사용을 모니터링해야 합니다.

모니터링 - 외부 시스템 monitoring-external-system-s

솔루션과 외부 시스템 간의 모든 연결 모니터링:

모니터링 - 네트워크 대역폭 monitoring-network-bandwidth

솔루션의 네트워크 대역폭 사용 모니터링:

모니터링 - 요청 monitoring-requests

솔루션에 대한 요청을 모니터링합니다.

모니터링 - 보안 지점 monitoring-security-points

정의된 보안 지점에서 모니터링합니다.

모니터링 - 시스템 monitoring-system

전체 시스템 모니터링 예:

모니터링 - 임계값 및 개입 monitoring-threshold-and-intervention

로드를 줄이기 위한 개입 단계 구현과 함께 솔루션의 정의된 임계값을 모니터링합니다.

모니터링 개념 monitoring-concept

솔루션에 적용할 모니터링 개념 통합:

잠재적 약점 모니터링 monitoring-potential-weak-points

실패의 위험이 있는 특정 지점을 식별하고 정의해야 합니다. 이와 관련된 모니터링 작업도 정의해야 합니다.

해당 예는 다음과 같습니다.

시스템 엔지니어와 통신되는 모니터링 정책 monitoring-policy-communicated-to-system-engineer

시스템 엔지니어와 운영 담당자가 모든 모니터링 정책을 알고 이해하는지 확인합니다.

보고서 모니터링 - 적합한 구조 monitoring-reports-structure-in-place

다음을 정의합니다.

작업 설명서 operational-tasks-documentation

모든 운영 작업이 문서화되어 있으며 해당 빈도를 정의합니다.

작업 설명서 operations-manual

성공적인 작업 및 솔루션 유지 관리에 필요한 모든 정보를 수동 제공:

다음에에 대한 구현 개념도 자세히 설명합니다.

패키지 준비 package-prepared

구축 및 배포 준비가 완료된 소프트웨어 패키지

Penetration Tests penetration-tests

침투 테스트(비공식적으로 펜 테스트라고 함)는 보안 단점을 찾는 컴퓨터 시스템에 대한 공격이며, 컴퓨터의 기능과 데이터에 액세스할 수 있습니다.

Penetration Tests - 통과 penetration-tests-passed

필요한 모든 기준이 전달됩니다.

Penetration Tests - 결과 penetration-tests-results

Penetration 테스트 결과를 설명하는 비즈니스를 위해 작성된 보고서입니다.

성능 및 확장성 개념 performance-and-scalability-concept

구현이 성능 KPI를 충족하는지 확인하는 방법과 이러한 KPI를 계속 충족하도록 솔루션의 크기를 조정하는 방법에 대한 개념적 문서입니다.

성능 벤치마크 performance-benchmark

성능 벤치마크는 성능 테스트, 내구성 테스트 및 모니터링을 정의하는 데 사용됩니다. 솔루션 및 시스템 하드웨어의 성능 특성을 평가하여 이러한 작업을 수행합니다.

성능 KPI performance-kpis

시스템 성능을 측정하는 데 필요한 주요 성과 지표(KPI)를 정의합니다. 페이지 로드 시간, 서버 응답 시간 및 데이터베이스 쿼리 성능이 일부 예제에 해당됩니다.

성과 테스트 - 보고서 performance-tests-report

성능 테스트 결과를 자세히 설명하는 비즈니스용으로 생성된 보고서입니다.

성과 테스트 - 결과 일치 성과 KPI performance-tests-results-match-performance-kpis

결과는 정의된 KPI 및 성능에 대한 기대치와 일치해야 합니다.

성향 기반 테스트 개념 persona-based-testing-concept

성향 기반 테스트는 Experience Design에 요약된 서로 다른 가상 사용자를 기반으로 하는 방법입니다. 또한 계정 및 관련 권한 수준도 테스트합니다.

UAT(사용자 수락 테스트)에서 사용되는 경우가 많습니다.

요구 사항 설명서에 대해 테스트 및 검증된 POC poc-tested-and-verified-against-requirement-documentation

POC(Proof Concept)는 두 요구 사항이 모두 일치하는지 확인하는 데 도움이 됩니다.

배포 후 검사 목록 post-deployment-checklist

각 배포 후 수행할 일련의 확인 및 작업을 정의하는 체크리스트입니다.

배포 전 검사 목록 pre-deployment-checklist

각 배포 전에 수행할 일련의 확인 및 작업을 정의하는 체크리스트입니다.

프로덕션 환경 기준 성능 테스트 production-environment-baseline-performance-tests

AEM의 표준 설치에서 기준 테스트를 실행하는 것이 일반적입니다. 그런 다음 구현과 하드웨어를 테스트할 벤치마크로 사용됩니다.

프로덕션 환경 지원 production-environment-ready

자동화된 배포를 통해 프로덕션 환경이 준비되었는지 확인합니다.

비즈니스 이해 당사자로부터 생산 승인 production-sign-off-from-business-stakeholders

프로덕션 환경으로 이동하기 전에 PSO(Production Sign off)가 부여되어야 합니다. 이는 알려진 모든 문제와 함께 프로덕션에 들어갈 릴리스를 검토한 결과입니다. 로그오프는 Go Live 예약의 일부로 제공됩니다.

프로덕션 승인 프로세스 및 정책 production-sign-off-process-and-policy

패키지를 프로덕션 환경으로 이동하기 전에 프로덕션 서명을 받는 데 필요한 정책 및 프로세스입니다.

프로젝트 통신 계획 project-communication-plan

비즈니스 이해 관계자와 프로젝트 팀의 커뮤니케이션 계획을 정의합니다.

프로젝트 작업 - 최종 예상 project-efforts-final-estimates

다음 초기 예상 는 구현에 대한 높은 수준의 요구 사항에 따라 높은 수준으로 제작되었습니다.

이제 최종 예측을 제공하기 위해 검토, 조정 및 확장됩니다. 프로젝트 관리, 컨설팅, 아키텍처, 테스트 및 개발 등 적절한 각 프로젝트 리드 별로 추정이 전달되어야 합니다.

이러한 추정은 리소스 및 예산 관리에 사용됩니다.

프로젝트 작업 - 초기 예상 project-efforts-initial-estimates

초기 추정은 높은 수준이며 구현을 위한 높은 수준의 요구 사항에 따라 수행됩니다. 이 작업은 이후 단계에서 검토 및 구체화됩니다.

프로젝트 조직 project-organization

프로젝트 및 팀의 조직 및 보고 구조를 전체적으로 설명하는 데 필요한 설명서입니다.

타임라인과 책임에 대한 시각적 개요를 제공하기 위해 종종 양식을 작성하거나 차트를 포함합니다. 이 작업을 지원하는 데 사용할 수 있는 많은 도구가 있습니다.

프로젝트 범위 문서 project-scope-document

프로젝트 범위 문서를 사용하려면 다음 목록을 식별하고 문서화해야 합니다.

프로젝트를 게재하기 위해 수행해야 하는 작업과 함께 달성해야 하는 사항을 다룹니다

정의된 대상 내의 프로젝트 상태 보고서 project-status-reports-within-a-defined-cadence

프로젝트 상태 보고서는 합의된 일정에 따라 배달되며 필요한 형식으로 제공됩니다.

개념 증명(POC) proof-of-concept-poc

POC(개념 증명)는 솔루션에 대한 제한된 범위의 함수를 구현합니다.

그 목적이 솔루션의 가능성을 입증하고, 그 목적을 달성할 수 있는지 검증하고, 그 잠재력이 입증되어야 한다.

규칙 제거 purge-rules

AEM은 여러 버전의 자산 및 컨텐츠를 유지 관리합니다. 제거 규칙은 저장소 상태 및 크기를 유지하기 위해 이전 버전을 주기적으로 제거하도록 설계되고 구성됩니다.

품질 보고서 형식 및 대상 quality-report-format-and-cadence

품질 보고서를 배달해야 하는 빈도와 함께 필요한 컨텐츠 및 형식을 정의합니다.

조정 릴리스 release-coordinated

프로젝트 관리자는 프로덕션에 릴리스에 필요한 모든 역할을 조정합니다.

릴리스 정보 release-notes

릴리스 노트는 릴리스에 대한 설명서의 일부입니다. 릴리스 노트는 다음 내용을 다룹니다.

Runbook과 함께 사용하여 설치 전 단계 및 후 단계 및 확인을 실행합니다.

프로덕션 환경에서 실행되는 릴리스 release-running-on-production-environment

프로덕션에서 실행 및 활성 중인 최종 릴리스.

관련 계약 조건 relevant-contract-terms

프로젝트 구현과 관련된 특정 계약 조건을 강조 표시해야 합니다. 계약 이정표, 송장 기간 또는 직원 요구 사항과 같은.

보고 대상 reporting-cadence

고객과 함께 제공된 보고서의 빈도를 정의합니다.

저장소 최적화 repository-optimization

tar 파일에서 데이터를 덮어쓰는 일은 없으므로 기존 데이터만 업데이트할 때에도 디스크 사용량이 증가합니다.

갈수록 증가하는 저장소 크기에 대응하기 위해 오래된 데이터를 제거하기 위해 최적화 전략이 적용됩니다.

Adobe 지원 포털에서 프로젝트 섹션 설정 요청 request-for-setting-up-project-section-in-adobe-support-portal

Adobe 지원 포털에서 프로젝트를 설정하라는 공식 요청입니다.

요구 사항 설명서 requirements-documentation

이 설명서에서는 예상 작업과 함께 기능 및 비기능 요구 사항을 다룹니다.

Go Live를 지원하기 위한 리소스 resources-available-to-support-go-live

실시간으로 활동에 필요한 모든 역할이 구성되고 사용 가능한지 확인하십시오.

위험 평가 risk-assessment

위험 측정은 고객의 IT 및/또는 보안 부서에 의해 실행됩니다.

이 회사는 그 프로젝트의 기술적 위험 및 사업상의 위험을 평가한다. 보안 정책을 준수하기 위해서는 솔루션에 대한 평가가 필요합니다.

위험 완화 계획 risk-mitigation-plan

위험 완화 계획은 위험 평가를 포함합니다. 이들은 함께 다음을 다룹니다.

ROI 기대치 roi-expectations

솔루션에 첨부된 ROI(투자 수익률) 기대치를 정의합니다.

그들은 예상 투자 비용과 관련하여 예상되는 이익/이익을 규정함으로써 솔루션의 효율성을 경제적인 측면에서 나타내고자 한다.

역할 및 권한 개념 roles-and-rights-concept

다음 개요 개요를 포함하여 새 응용 프로그램에 필요한 역할 및 액세스 권한과 관련된 개념에 대한 자세한 설명:

역할 및 권한 개념이 보안 지침을 충족함 roles-and-rights-concept-meets-security-guidelines

역할 및 권한 개념을 검토하여 보안 정책을 충족하는지 확인합니다.

역할 및 권한 사양 roles-and-rights-specification

역할 및 권한 개념을 기반으로 한 세부 사양입니다.

보안 아키텍처 Recommendations security-architecture-recommendations

소프트웨어 및 하드웨어 아키텍처의 보안과 관련된 Recommendations.

보안 기반 코딩 지침 security-based-coding-guidelines

다음 지침은 다음과 같은 보안 요구 사항을 기반으로 개발 코딩을 수행하는 방법을 정의합니다.

Security 검사 목록 security-checklist

Security Concept를 기반으로 솔루션 준수에 필요한 추가 정책과 함께 항목의 프로젝트 특정 검사 목록

종종 이 작업은 Runbook에서 배포 후 단계의 일부로 포함됩니다.

보안 개념 security-concept

애플리케이션, 아키텍처 및 인프라에 필요한 보안 구성에 대한 세부 사항을 정의하고 문서화합니다.

보안 개념 초안 security-concept-draft

의 보안 설정을 다루는 높은 수준의 개요:

목록에 추가된 보안 문제 및 평가 security-issues-listed-and-assessed

나열된 솔루션 및 평가된 솔루션의 모든 보안 문제 작업 예상 포함

비즈니스 이해 당사자로부터 보안 로그오프 security-sign-off-from-business-stakeholders

보안 구현이 정책 및 기대에 부합하는지 확인하려면 이해 관계자와 로그오프하십시오.

지원 프로세스 설정 set-up-support-processes

필요한 지원 프로세스를 적절히 설정합니다.

타사 시스템의 SLA slas-for-third-party-systems

구현 및 지원 중에 사용할 SLA(Service Level Agreement)를 개발 및 운영 팀에 모두 사용하고 전달하도록 하십시오.

연기 테스트 개념 smoke-test-concept

연기 테스트는 솔루션의 기본 운영 및 기능을 보장하기 위해 솔루션의 주요 기능을 테스트하는 정의된 단계 집합으로 구성됩니다.

설치 또는 배포 후 모든 환경에서 실행됩니다.

시스템 유효성 검사를 위해 실행된 연기 테스트 smoke-tests-executed-for-system-validation

모든 시스템에 대해 연기 테스트를 실행하여 모든 환경에 설치 또는 배포할 때 솔루션의 기본 기능을 올바르게 작동해야 합니다.

소프트웨어 아키텍처 전략 software-architecture-strategy

소프트웨어 아키텍처를 위한 높은 수준의 전략 서비스, 서블릿, 프레임워크 및 기타 구현 결정을 포함합니다.

솔루션 검토 위원회 설치 및 회의 대상 집합 solution-review-board-established-and-meeting-cadence-set

솔루션 검토 위원회는 일반적으로 고객 이해 관계자로 구성됩니다.

이사회는 정기적으로 회의를 개최하여 현재 범위가 지정된 요구 사항과 관련 사양을 지속적으로 검토합니다. 목표는 성공 정의 및 기준에 맞게 정렬하고 요구 사항 개발에 입력을 제공하는 것입니다.

솔루션 Runbook solution-runbook

설치 시 실행할 기본 작업 작업과 함께 솔루션에 대한 설치 지침입니다.

솔루션 승인 및 수락 프로세스 solution-sign-off-and-acceptance-process

승인 및 수락 프로세스는 솔루션을 생산적인 환경으로 출시하기 전에 충족해야 하는 기준을 간략하게 설명합니다.

이것은 또한 계약상의 이정표가 될 수 있습니다.

특수 기능 개념 special-functionality-concept

AEM 플랫폼에서의 일반적인 개발 범위를 벗어나는 것으로 간주되는 모든 특수 기능에 대한 초기 개념입니다.

특수 기능 사양 special-functionality-specification

AEM 플랫폼에서의 일반적인 개발 범위를 벗어나는 것으로 간주되는 모든 특수 기능의 세부 사항입니다.

사양 지침 specification-guidelines

사양을 수행하는 방법에 대한 고객의 모든 지침

정의 및 전달된 사양 검토 및 승인 프로세스 specification-review-and-approval-process-defined-and-communicated

고객 사양의 서명을 위한 명확한 절차가 필요하다. 이 프로세스는 요구 사항에 대해 범위가 명확하고 견고합니다.

AEM 관리자 교육을 위해 선택한 직원 staff-selected-for-aem-administrator-training

솔루션 관리를 위한 교육이 필요한 내부 직원입니다.

작성자 및 최종 사용자 교육을 위해 선택한 직원 staff-selected-for-author-and-end-user-training

솔루션 작성에 필요한 내부 직원입니다.

이해 관계자 stakeholders

이해 관계자는 프로젝트에서 중요한 이해관계가 있는 주요 사람 및/또는 역할입니다. 일부는 프로젝트 예산에 기여하게 될 것이다.

이해 관계자는 내부 및/또는 외부일 수 있습니다.

이해 관계자는 성공 정의 및 기준을 알고 있습니다 stakeholders-are-aware-of-success-definitions-and-criteria

실제 구현 팀 외부의 모든 이해 관계자가 다음을 알고 있는지 확인합니다.

이해 관계자 프로젝트 및 기대 이해 stakeholders-understand-project-and-expectations

실제 구현 팀 외부의 모든 이해 관계자가 프로젝트 팀 내부와 고객 모두의 전반적인 프로젝트 및 기대에 부합하는지 확인합니다.

상태 보고서 형식 정의 status-report-format-definition

상태 보고서는 커뮤니케이션의 주요 도구입니다. 이 형식은 고객의 모든 보고 요구 사항과 일치해야 합니다.

성공 기준 및 정의 success-criteria-and-definition

고객, 프로젝트 스폰서, 프로젝트 관리자 또는 컨설턴트는 다음을 지정해야 합니다.

성공 기준이 충족되도록 하는 데 사용됩니다.

보고된 문제 유효성 검사 지원 support-in-validation-of-reported-issues

품질 리드의 책임 중 일부는 테스트 시 모든 사용자를 지원할 수 있는 리소스가 있는지 확인하는 것입니다. 예를 들어, 테스트 시 문제를 보고할 때 사용자를 돕고 테스트 환경에 대해 문제를 확인하는 데 도움이 됩니다.

지원 프로세스 및 Adobe 지원 포털에 대한 액세스 support-processes-and-access-to-adobe-support-portal

Adobe 지원 포털에 액세스하는 것은 구현 중에 발생할 수 있는 모든 제품 기반 문제에 대한 티켓을 제출하는 데 중요합니다.

액세스 권한은 팀의 주요 구성원에게 할당되어야 합니다.

시스템 아키텍처 정의 system-architecture-definition

솔루션의 모든 환경을 위한 아키텍처에 대한 초기 제안 및 정의입니다.

시스템 아키텍처 설명서 system-architecture-documentation

시스템 아키텍처를 설명하는 문서 다른 정보 중에서 모든 환경을 위한 인터페이스, 네트워크 위치 및 통합을 포함합니다.

시스템 아키텍처 보안 개념 system-architecture-security-concept

시스템 아키텍처를 모든 보안 정책을 준수하도록 하는 방법에 대한 높은 수준의 개요입니다. 다음을 다룰 수 있습니다.

시스템 위험 요소 확인 및 확인 system-risk-factors-identified-and-verified

위험 평가(또는 기타 검토)에서 발견되는 모든 위험 요소를 식별하고 평가합니다.

팀은 성공 정의 및 기준을 알고 있습니다 team-is-aware-of-success-definitions-and-criteria

전체 팀이 성공 정의 및 기준을 알고 있는지 확인합니다.

팀이 통신 계획을 알고 있음 team-is-aware-of-the-communication-plan

Dell의 모든 팀원이 고객과 소통할 사용자를 알고 있으며 방법 및 시기에 대한 세부 사항을 제공합니다.

팀, 프로젝트 및 기대 이해 team-understands-project-and-expectations

프로젝트 팀 내부와 고객 모두에 대한 전체 프로젝트 및 기대에 부합합니다.

기술 요구 사항 technical-requirements

이러한 요구 사항은 솔루션을 지원하는 서비스의 기술 구현에 따라 다릅니다.

기술 위험 요소 검증 technical-risk-factors-verified

잠재적인 기술적 위험 파악 및 확인 기술적 위험 요소는 다음과 같습니다.

기술 사양 technical-specification

기술 사양은 다음과 같은 내용을 다룹니다.

템플릿 사양 template-specification

필요한 템플릿에 대한 사양입니다. 여기에는 parsys, 블루프린트 및 상속 매핑 등의 세부 사항이 포함되어야 합니다.

이 사양은 비즈니스 요구 사항 및 경험 요구 사항을 기반으로 합니다.

테스트 사례 test-cases

테스트 사례 는 솔루션의 기능 테스트를 실행하는 데 필요한 세부 단계에 대해 설명합니다.

컨텐츠 테스트 test-content

테스트 콘텐츠는 가능한 한 프로덕션 콘텐츠와 일치해야 합니다. 모든 시나리오를 테스트할 수 있도록 선택할 수 있을 만큼 다양해야 합니다.

테스트 환경 준비 test-environment-ready

모든 릴리스 후보 코드가 최신 테스트 코드를 사용할 수 있도록 자동화된 배포를 준비하여 테스트 환경이 준비되었는지 확인합니다.

테스트 보고서 test-reports

테스트 결과를 자세히 설명하는 보고서 다음을 포함합니다.

다음과 같이 명시해야 합니다.

테스트 세트 test-suite

자동화 세트 및 도구 선택. 사용 사례를 비롯하여 테스트를 자동화하는 데 사용됩니다.

선택한 테스트 도구 세트 test-tooling-suite-selected

사용 사례 자동화 및 기타 테스트 실행 작업을 위해 선택된 자동화 세트 및 도구.

테스트 개념 testing-concept

테스트 개념은 프로젝트에 대한 테스트의 매우 높은 수준의 개요입니다. QA, UAT, 성능, 보안 및 통합 테스트를 포함합니다.

테스트 계획 testing-plans

이러한 계획은 개발 단계별로 테스트 실행을 보다 자세히 설명하고 테스트 전략.

테스트 범위 testing-scope

이러한 요구 사항은 솔루션을 지원하는 서비스의 기술 구현에 따라 다릅니다.

테스트 전략 testing-strategy

테스트 전략에서는 품질 보증 및 사용자 수락 테스트를 위한 높은 수준의 전략을 간략하게 설명합니다. 여기에는 타임라인, 보고 캐듀션 및 실행이 포함됩니다.

타사 통합 개념 third-party-integration-concept

타사 시스템과의 통합을 위한 아키텍처 및 시스템 수준 개념.

타사 통합 사양 third-party-integration-specification

타사 시스템의 지원 기능 및 통합에 대한 요구 사항(기능 및 비기능)의 세부 정보입니다.

타사 보안 개념 third-party-security-concept

타사 통합의 보안을 보장하는 개념입니다. 적절한 보안 정책을 준수해야 합니다.

통합을 위한 타사 시스템 third-party-system-for-integration

통합 구현을 위해 적절한 설명서와 함께 모든 타사 시스템을 사용할 수 있는지 확인하십시오.

타사 시스템 액세스 사용 third-party-systems-access-enabled

타사 시스템과 함께 사용되는 각 역할에 부여된 필수 액세스 권한.

타사 테스트 개념 third-party-testing-concept

정의:

임계값 정의 threshold-definition

시스템에서 모니터링 포인트에 대한 키 값을 정의합니다.

예:

타임라인 및 이정표 timeline-and-milestones

이에 사용할 프로젝트 타임라인과 계약 이정표를 정의해야 합니다.

총 프로젝트 작업 total-project-efforts

프로젝트의 각 리드에서 모든 노력은 통합되어야 합니다. 또한, 오버헤드, 개발, 시스템 엔지니어링, 건축 및 테스트 작업을 포함합니다.

계약에 지원 수준이 포함되어 있는 경우 지원 및 운영 작업도 포함되어야 합니다.

교육 자료 training-materials

교육 세션에 사용할 자료. 이 자료는 솔루션에 맞게 특별히 제작되어야 하며 사용 안내서와 함께 사용하도록 설계되었습니다.

프로젝트 및 기대 범위 이해 understands-scope-of-project-and-expectations

적절한 모습은 그들이 완전히 이해했음을 확인해야 합니다.

URL 처리 개념 url-handling-concept

URL 처리 개념은 다음을 포함한 AEM 특정 URL 기능을 다룹니다.

개념 또한 다음을 다룹니다.

사용 사례 use-cases

사용 사례는 목표를 달성하는 데 필요한 작업 또는 이벤트 단계 목록입니다. 일반적으로 역할과 솔루션 간의 상호 작용을 정의합니다. 역할은 사용자 또는 외부 시스템일 수 있습니다.

테스트 시나리오로 변환된 사용 사례 use-cases-converted-into-test-scenarios

테스트 시나리오는 기술 및 비즈니스 사용 사례를 기반으로 합니다. 솔루션 동작이 예상대로 작동하는지 테스트하는 데 사용됩니다.

사용 안내서 user-guides

사용 안내서에서는 솔루션 사용자를 위한 정보 및 지원을 제공합니다.

검증된 예산 계획 validated-budget-plan

예산 계획은 모든 이해 관계자가 검토하고 검증해야 합니다. 송장 발행, 금액 및 방법/예산 보고 시기 등의 상세내역을 확인해야 합니다.

화이트 박스 테스트 결과 white-box-test-results

화이트 박스 테스트는 애플리케이션의 내부 구조나 작업을 기능과는 반대로 테스트하는 방법입니다. 소프트웨어 테스트 프로세스의 장치, 통합 및 시스템 수준에서 백박스 테스트를 적용할 수 있습니다.

워크플로우 사양 workflow-specifications

워크플로우 개념을 기반으로 이러한 사양은 전체 워크플로우를 만드는 단계를 자세히 정의해야 합니다.

각 워크플로우의 사양은 다음을 포함해야 합니다(최소).

워크플로우 개념 workflows-concept

워크플로우를 통해 AEM 활동을 자동화할 수 있습니다. 워크플로우 개념 설명: