용어 설명 glossary

이 용어집에는 프로젝트 체크리스트의 모든 결과물 문서에 대한 세부 정보가 알파벳순으로 나열되어 있습니다.

비즈니스 이해 당사자의 수용 acceptance-from-business-stakeholders

비즈니스 이해 당사자의 수용은 주요 이해 당사자로서 솔루션에 동의하고 비즈니스 요구 사항이 비즈니스 사례를 충족하는 방식에 대해 승인했음을 확인합니다.

수용 테스트 acceptance-tests

수용 테스트는 애플리케이션이 프로덕션 환경에 투입될 준비가 되었을 때 수행됩니다. 다양한 유형의 최종 사용자를 대표하는 그룹이 실제 시나리오를 사용하여 테스트를 수행합니다.

수용 테스트는 다음 사항을 확인하는 데 사용됩니다.

수용 테스트를 일찍 계획하고 설계할수록 최종 배포가 더 쉬워집니다. 고객과 품질 보증 팀이 함께 수용 테스트를 정의해야 합니다.

프로젝트를 시작할 때 모든 세부 정보를 정의하는 것은 불가능할 수 있지만, 초기 정의에 대해서는 논의하고 합의해야 합니다. 수용 테스트는 기본 요구 사항(기능 및 성능)을 기반으로 이루어질 것입니다.

테스트 시스템에 대한 액세스가 조정됨 access-to-test-system-coordinated

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

Adobe 보안 체크리스트 adobe-security-checklist

Adobe 보안 체크리스트는 AEM(Adobe Experience Manager)이 설치 시 안전한지 확인하기 위해 제공되는 공식 체크리스트입니다. 여기에는 인스턴스의 무결성을 보장하기 위해 수행해야 하는 보안 조치와 확인 단계가 포함되어 있습니다.

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 인증 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

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

적절한 교육을 받은 직원 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) 팀이 계획한 접근 방식과 함께 재사용 가능한 자동화된 스크립트에 대한 프레임워크를 정의합니다. 해당 전략은 다음 사항을 보장하는 데 도움이 되는 자동화 테스트에 대한 전반적인 계획을 간략하게 설명합니다.

현실적이고 예상되는 부하에 대해 검증된 자동화된 테스트 전략 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-tested

백업 및 복원 개념을 기반으로 한 전체 엔드투엔드 테스트입니다.

비즈니스 사례 business-case-s

비즈니스 사례 문서는 조치를 취하는 것, 대체 조치를 취하는 것(가능한 경우), 아무런 조치도 취하지 않는 것과 관련된 논거를 제시합니다. 이 논거는 구체적 사실(가능하거나 관련성이 있는 경우)에 기반하여 균형을 이루어야 하며 모든 사례의 이점과 위험을 모두 강조해야 합니다.

비즈니스 사례 문서는 모든 옵션을 명확하게 정의하고 제안된 솔루션을 구현하기 위한 설득력 있는 논거로 마무리해야 합니다.

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

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

비즈니스 KPI business-kpis

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

비즈니스 KPI는 회사가 주요 비즈니스 목표를 얼마나 효과적으로 달성하고 있는지를 보여 주는 측정 가능한 값을 정의합니다. 비즈니스/시나리오에 적합한 KPI를 선택하는 것이 중요합니다. 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

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

외부 인터페이스 모형에 대한 개념 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) 기간 동안 고객이 품질 책임자에게 보고하는 보고서입니다.

업그레이드에 영향을 미치는 사용자 정의 및 핫픽스 문서화 customizations-and-hotfixes-that-affect-upgrades-documented

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

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

사용자 수용 테스트(UAT)로 인해 생성된 보고서 또는 회의이며, 다음 사항을 자세히 설명해야 합니다.

기본 보안이 활성화됨 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

경험 디자인 요구 사항의 세부 정보입니다.

외부 시스템 및 사용자 종속성/시스템 컨텍스트 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와 비교 측정하여 KPI를 충족할 수 있는지 확인해야 합니다.

최종 확정된 계약 finalized-contract

프로젝트를 진행하기 전에 최종 확정되고 서명이 완료된 계약이 필요합니다. 이 계약은 계약 초안을 기반으로 합니다.

이해 당사자가 수용한 솔루션 기능 functionality-of-the-solution-accepted-by-stakeholders

이해 당사자가 다음 사항을 완전히 수용했음을 확인합니다.

Go-Live 일정 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

비즈니스에 중요한 기능 목록입니다.

구현 - 침투 테스트 결과에 따른 변경 사항 implementation-changes-based-on-penetration-test-results

침투 테스트 결과를 기반으로 솔루션에 필요한 모든 변경 사항(승인된 변경 사항)을 구현합니다.

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

자동화된 테스트를 지원하는 데 필요한 도구와 프로세스를 설정합니다.

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

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

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

콘텐츠 아키텍처, 태그 지정 개념 및 콘텐츠 재사용을 구현합니다.

구현 - 경험 디자인 implementation-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

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

이 개념은 또한 솔루션에 사용되는 프레임워크, 라이브러리 및 기타 아티팩트를 간략하게 설명합니다.

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

Adobe 지원에 문의하여 Go-Live 기간 동안 필요한 지원을 받을 수 있는지 확인합니다.

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

경험 디자인을 위한 예비 개념입니다.

통합 테스트 integration-testing

내부 및 외부의 모든 통합을 테스트하고 그 결과를 확인합니다.

시스템 안정성을 보장하기 위해 이 작업은 자동화되어야 하며 자주 실행되어야 합니다.

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

명확한 프로세스를 통해 발생한 모든 문제를 기록하고 진행 중인 활동을 추적하여 모든 문제가 해결되도록 보장합니다.

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

발생한 모든 문제를 기록하고 진행 중인 활동을 추적하여 모든 문제가 해결되도록 보장하기 위한 추적 시스템과 필수 프로세스입니다.

프로젝트 상태의 투명성을 확보하기 위해 모든 프로젝트 이해 당사자가 액세스할 수 있어야 합니다.

예를 들어 Atlassian, JIRA 및 HP 품질 센터가 있습니다.

문제 추적 시스템 프로세스가 설정 및 통합됨 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

새로운 솔루션에 매핑된 기존 콘텐츠, 콘텐츠 아키텍처 및 형식에 대한 전체 설명입니다. 다음 사항을 포함해야 합니다.

또한 마이그레이션부터 새 시스템의 실제 Go-Live까지의 기간 동안 콘텐츠를 최신 상태로(또는 가능한 한 최신 상태로) 유지하는 방법을 권장해야 합니다. 이러한 방법은 콘텐츠 동결, 이중 게시 또는 알파 시스템 유지 관리를 의미할 수 있습니다.

모니터링 - 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-passed

모든 필수 기준을 통과했습니다.

침투 테스트 - 결과 penetration-tests-results

기업을 대상으로 침투 테스트 결과를 설명하기 위해 만든 보고서입니다.

성능 및 확장성 개념 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

페르소나 기반 테스트는 경험 디자인에 간략하게 설명된 다양한 페르소나를 기반으로 하는 방법입니다. 계정과 관련 권한 수준도 테스트합니다.

이 테스트는 종종 사용자 수용 테스트(UAT)에 사용됩니다.

요구 사항 설명서에 따라 POC가 테스트되고 확인됨 poc-tested-and-verified-against-requirement-documentation

개념 증명(POC)은 요구 사항을 기준으로 평가되어 두 가지가 모두 일치하는지 확인합니다.

배포 후 체크리스트 post-deployment-checklist

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

배포 전 체크리스트 pre-deployment-checklist

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

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

AEM의 표준 설치 환경에서 기준 테스트를 실행하는 것이 일반적입니다. 이 테스트 결과는 구현 및 하드웨어를 테스트하기 위한 벤치마크로 사용됩니다.

프로덕션 환경 준비됨 production-environment-ready

자동화된 배포가 구현되어 프로덕션 환경이 준비되었는지 확인합니다.

비즈니스 이해 당사자의 프로덕션 승인 production-sign-off-from-business-stakeholders

프로덕션 환경으로 Go-Live하기 전에 프로덕션 승인(PSO)을 받아야 합니다. 이러한 승인은 알려진 문제를 비롯하여 프로덕션 환경에 들어갈 릴리스를 검토한 결과입니다. 승인은 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

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

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

보안 아키텍처 권장 사항 security-architecture-recommendations

소프트웨어 및 하드웨어 아키텍처의 보안과 관련된 권장 사항입니다.

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

이 지침은 다음과 같은 보안 요구 사항에 따라 개발 코딩을 수행하는 방법을 정의합니다.

Security 검사 목록 security-checklist

솔루션 준수를 보장하는 데 필요한 추가 정책과 함께 보안 개념을 기반으로 생성된 프로젝트별 항목 체크리스트입니다.

이 체크리스트는 종종 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)을 제공하고 이를 구현 및 지원 과정에서 사용할 수 있도록 개발 팀과 운영 팀 모두에게 전달합니다.

스모크 테스트 개념 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

모든 팀원이 고객과 커뮤니케이션해야 할 사람이 누구인지, 어떻게, 언제 커뮤니케이션해야 하는지에 대한 세부 정보를 알고 있는지 확인합니다.

팀이 프로젝트와 기대 사항을 이해함 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 활동을 자동화할 수 있습니다. 워크플로 개념은 다음 사항을 간략하게 설명합니다.