용어 설명

이 용어집에는 모든 제공 서비스 문서의 세부 정보가 알파벳순으로 나열됩니다. 프로젝트 체크리스트.

비즈니스 이해 당사자의 동의

비즈니스 이해 당사자의 동의를 통해 주요 이해 당사자로서 솔루션과 연계되어 비즈니스 요구 사항이 비즈니스 사례를 충족하는 방법에 대한 승인을 받았음을 확인할 수 있습니다.

승인 테스트

애플리케이션이 운영 준비가 되면 수락 테스트가 수행됩니다. 테스트는 실제 시나리오를 사용하여 다양한 유형의 최종 사용자를 나타내는 그룹에 의해 수행됩니다.

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

• 프로젝트는 고객의 요구 사항을 충족합니다.
• 솔루션은 목적에 부합합니다.
• 사용자는 솔루션을 수락하고 솔루션 작업을 예상할 수 있습니다.
• 고객이 프로젝트를 수락합니다.

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

프로젝트의 시작 시점에 모든 세부 정보를 정의하지는 못할 수 있지만 초기 정의에 대해 논의하고 동의해야 합니다. 수용 테스트는 아마도 기본 요구 사항(기능 및 성능)에 기반할 것입니다.

조정된 테스트 시스템 액세스

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

Adobe 보안 검사 목록

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

Adobe 지원 포털 프로젝트 설정

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

세부 사항(예: 구현된 기술 및 버전에 대한 정보)을 등록할 수 있습니다. 이를 통해 고객과 Adobe 간의 투명성을 확보할 수 있습니다.

AEM 관리자 교육

솔루션의 관리 직원을 위한 교육. 다음을 참조하십시오. Adobe 교육 서비스 추가 정보.

AEM 작성자 교육

솔루션에 대한 콘텐츠를 생산(작성)할 직원을 위한 교육. 다음을 참조하십시오. Adobe 교육 서비스 추가 정보.

AEM 인증 시험

적절한 담당자가 관련 정보를 얻기 위해 등록되었는지 확인합니다. 인증 시험.

AEM Certified

적절한 담당자가 적절한 담당자를 통과했는지 확인합니다. 인증 시험.

AEM 기술 교육

개발자, 설계자, 엔지니어, 비즈니스 실무자 등 해당 담당자를 위한 기술 교육을 제공합니다.

프로젝트의 목표로 정의된 KPI에 대한 계약

주요 성과 지표(KPI)는 조직이 조직 목표에 대한 진행률을 정의하고 측정하는 데 도움이 됩니다. 조직이 임무를 분석하고 목표를 정의하면 그 목표에 대한 진도를 측정해야 한다. KPI는 측정을 위한 메커니즘을 제공합니다.

비즈니스 및 성과 KPI 조정

비즈니스 및 성과 KPI(핵심 성과 지표)를 조정하면 조직 내에서 관련된 모든 사람과 프로세스를 통합하는 데 도움이 됩니다. 이는 결과적으로 비즈니스 목표를 달성하고 제안된 목적을 달성하는 데 필요한 시간과 노력을 줄이는 데 도움이 됩니다.

KPI를 사용한 컨텐츠 아키텍처 정렬

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

고객 로드맵과 프로젝트 타임라인 조정

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

응용 프로그램 아키텍처 정의

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

이는 다음 사항에 중점을 둡니다.

• 서로 및 사용자와 상호 작용하는 방법.
• 내부 구조가 아닌 애플리케이션에서 소비하고 생성할 데이터입니다.

정의된 애플리케이션별 유지 관리 작업

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

적절한 교육을 받은 직원

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

• 최소 한 명 이상의 AEM 인증 리드 개발자
• 최소 한 명 이상의 AEM Certified Architect
• 개발자의 75% 이상이 AEM 인증을 받았습니다. 이를 통해 인증된 개발자는 후배 개발자의 멘토가 되고 지식 공유와 투명성이 보장됩니다

아키텍처 다이어그램

아키텍처 다이어그램은 아키텍처를 그래픽으로 나타낸 것입니다. 여기에는 다음과 같은 표현이 포함됩니다.

• 개념
• 그들의 원칙
• 아키텍처의 일부인 요소 및 구성 요소

아키텍처 초안

이를 통해 시스템 및 솔루션 아키텍처를 전체적으로 파악할 수 있습니다. 이 단계에서 이후 단계에서 검토되고 다듬어질 초안이다.

아키텍처 검토 위원회 승인

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

• 일관된 전략의 구현을 감독한다.
• 시스템 규정 준수 보장

검토 위원회는 아키텍처와 관련된 모든 주요 이해 당사자를 대표해야 합니다. 일반적으로 이 팀은 전체 아키텍처를 검토하고 유지 관리하는 책임자의 그룹으로 구성됩니다.

KPI와 비교하여 실제 콘텐츠 및 결과에 맞게 조정된 자동화된 테스트 세트

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

• 프로덕션 콘텐츠에 맞게 조정
• kpi에 대해 선택됨

자동화된 테스트 전략

이 전략은 품질 보증(QA) 팀에서 계획한 접근 방식과 함께 재사용 가능한 자동화된 스크립트에 대한 프레임워크를 정의합니다. 자동화 테스트에 대한 전반적인 계획을 간략하게 소개하여 다음과 같은 이점을 제공합니다.

• 더 높은 투자 수익률(ROI)
• 추가 테스트 범위
• 품질 반복을 통해 테스트 신뢰성 향상

현실적이고 예상되는 로드에 대해 검증된 자동화된 테스트 전략

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

자동화 전략

배포 자동화를 통해 빠르고 일관된 배포를 보장합니다. 자동화 전략은 다음과 같은 자동화 메커니즘의 구성을 간략하게 설명합니다.

• 빈도
• 사용할 도구
• 배포할 환경

커뮤니케이션 계획 인식

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

• 보고 구조
• 보고의 케이던스
• 통신 채널

성공 정의 및 기준 인식

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

• 성공의 정의
• 성공 기준

백업 및 복원 개념

백업 및 복원 개념은 솔루션에 구현될 기술 기능에 대해 간략하게 설명합니다. 회사 백업 및 복원 정책에 필요합니다.

백업 및 복원 테스트

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

비즈니스 사례

비즈니스 사례 문서에는 작업 수행, 대체 작업 수행(가능한 경우) 또는 작업 수행과 관련된 인수가 나와 있습니다. 구체적인 사실(가능한/관련이 있는 경우)에 기초하여 주장의 균형을 맞추고 모든 경우에 대한 이익과 위험을 모두 강조해야 한다.

비즈니스 사례 문서는 모든 옵션에 대한 명확한 정의여야 하며, 제안된 솔루션의 구현을 위한 강력한 주장으로 마무리되어야 합니다.

비즈니스 분석가는 프로젝트 범위 및 기대치를 이해합니다.

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

• 프로젝트의 범위
• 모든 고객 기대치
• 이는 프로젝트의 단계별로 담당자별로 이루어진 모든 의사 결정의 기준이 됩니다

비즈니스 KPI

조직은 주요 성과 지표(KPI)를 사용하여 목표 달성 성공을 평가합니다.

비즈니스 KPI는 기업이 주요 비즈니스 목표를 얼마나 효과적으로 달성하고 있는지를 입증하는 측정 가능한 값을 정의합니다. 비즈니스/시나리오에 적합한 KPI를 선택하는 것이 중요합니다. KPI의 정의, 측정 방법, 사용 방법 및 사용자를 명확히 정의하십시오.

비즈니스 요구 사항 설명서

BRD(비즈니스 요구 사항 문서)는 프로젝트에 대한 비즈니스 솔루션을 자세히 설명하므로 고객의 비즈니스 요구 사항과 기대치에 대한 명확한 사양을 제공합니다. BRD는 비즈니스 솔루션과 기술적 솔루션을 구분하기도 한다.

비즈니스 솔루션을 검토할 때 BRD는 "비즈니스가 무엇을 하기를 원하는가?"라는 질문에 답해야 합니다.

ROI 및 KPI 기대치에 맞게 파악 및 조정된 솔루션 또는 아키텍처에 대한 필수 조정 사항에 대해 비즈니스 승인

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

이러한 프로세스로 인해 발생하는 모든 조정은 비즈니스에서 검토 및 승인되어야 하며 전반적인 목표에 따라 평가되어야 합니다.

캐싱 전략

캐싱 전략은 최종 사용자에게 캐시되는 내용을 간략하게 설명합니다. 성과 KPI를 준수해야 합니다.

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

코딩 지침

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

• 이름 지정 규칙
• 서비스 사용
• 라이브러리 사용

커뮤니케이션 작업 설명서

모든 적절한 담당자/역할이 작업 설명서를 받았는지 확인합니다.

성능 테스트 보고서 전달

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

릴리스 정보 전달

모든 적절한 담당자/역할이 릴리스 정보를 수신했는지 확인하십시오.

팀에 범위 및 기대치 전달

프로젝트 팀이 프로젝트 범위 및 게재 기대치를 완전히 인식하고 이에 부합하는지 확인합니다.

교육 자료 및 사용 안내서 전달

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

고객 보안 요구 사항 준수

고객의 모든 보안 요구 사항이 제대로 갖추어져 있는지 확인합니다.

보안 개념 준수

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

구성 요소 및 템플릿 관계 개념

새 애플리케이션에서 사용되는 템플릿 및 구성 요소의 개요입니다. 상속 규칙, 권한 및 관계 등 세부 사항을 포함합니다.

구성 요소 및 템플릿 관계 사양

구성 요소 및 템플릿 관계 개념에 대한 세부 정보.

구성 요소 사양

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

외부 인터페이스의 Mock-up 개념

개발 또는 테스트 환경에서 공개/사용할 수 없는 모든 외부 인터페이스에 대해 개발하고 테스트하는 방법에 대한 개념입니다.

이러한 인터페이스의 mock-up을 계획/구현하여 테스트가 최대한 프로덕션과 유사한 동작에 가깝도록 합니다.

콘텐츠 아키텍처 문서

제안된 콘텐츠 아키텍처 문서입니다. 세부 사항에는 다음과 같은 내용이 포함되어야 합니다.

• 콘텐츠 트리
• 태깅 개념
• 콘텐츠 재사용 전략

마이그레이션에 대해 검증된 컨텐츠

기존 시스템 콘텐츠를 검토하고 선택한 콘텐츠를 새 솔루션으로 마이그레이션할 수 있는지 확인합니다.

계약 초안

법적 계약의 초기 초안입니다.

현재 콘텐츠 구조 및 형식

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

고객 백업 및 복원 정책

다음에 대한 고객의 정책:

• 데이터와 솔루션 모두에 대한 백업 프로세스
• 백업 스토리지
• 백업이 예상대로 작동하는지 확인
• 복원이 실패하는 경우 복원

고객 코딩 지침

개발 방법에 대한 고객의 지침/요구 사항.

고객 배포/릴리스 정책

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

여기에는 종종 타임라인, 예약 및 승인 요구 사항이 포함됩니다.

고객 모니터링 정책 또는 요구 사항

모니터링해야 하는 사항에 대한 고객 정책 및 요구 사항. 이는 모니터링 개념에 지정된 모든 권장 사항에 추가됩니다.

고객 프로덕션 릴리스 일정

고객이 프로덕션 환경에 대한 릴리스에 대해 정의한 일정.

고객 보고 정책 및 요구 사항

보고와 관련하여 고객이 가진 모든 정책, 요구 사항 또는 둘 다. 여기에는 다음이 포함될 수 있습니다.

• 구체적인 보고서 전달 주기
• 특정 보고서의 형식
• 특별 요구 사항

고객 로드맵

기술 및 비즈니스 측면에서 구현할 주요 이정표의 로드맵을 수립합니다. 이 로드맵은 고객에게 전달됩니다.

고객 보안 정책

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

• 위험 평가 통과를 위한 요건.
• 침투 테스트 통과 요구 사항.
• 모든 입력 필드 이스케이프 처리, 암호화 사용(SSL), 인증서, 인증 및 세션과 같은 특정 보안 요구 사항.

고객 사양 지침

사양 형식, 배송 및 승인과 관련된 모든 가이드라인.

고객 테스트 보고서

UAT(User Acceptance Test) 기간 동안 고객이 품질 리드에 보고하는 것입니다.

업그레이드에 영향을 주는 사용자 정의 및 핫픽스 문서화됨

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

• AEM은 비즈니스 요구에 맞게 크게 사용자 지정할 수 있습니다. 업그레이드에 영향을 줄 수 있는 모든 사용자 지정 사항을 완전히 문서화해야 합니다. 예를 들어 AEM의 UI(사용자 인터페이스)에 대한 모든 주요 변경 사항.

• 현재 솔루션에 필요한 모든 업데이트는 완전히 문서화해야 합니다. 여기에는 다음이 포함될 수 있습니다.

  • CFP(누적 수정 팩)
  • 서비스 팩(SP)
  • 핫픽스
  • 업그레이드

일별 사용자 수락 테스트 보고서

UAT(사용자 수락 테스트)로 인한 보고서 또는 회의입니다. 자세한 내용은 다음을 참조하십시오.

• 보고된 문제
• 이러한 문제의 우선 순위 지정

기본 보안 활성화됨

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

배포/릴리스 정책 및 프로세스

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

• 릴리스 시간
• 휴일 계획
• 빈도
• 및 은(는) 해당 환경에 따라 달라질 수 있습니다

배포 케이던스 설정됨

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

개발 방법론

소프트웨어 개발 방법론에는 소프트웨어 개발 작업의 전체 프로세스를 개별 단계(또는 단계)로 세분화하는 작업이 포함됩니다. 각 단계에는 개별 활동이 포함됩니다. 목표는 계획과 관리를 개선하는 것입니다.

방법론을 정의할 때는 응용 프로그램을 개발하거나 유지 관리하기 위해 프로젝트 팀이 만들고 완료한 특정 결과물과 아티팩트를 미리 정의해야 합니다.

개발 역할 정의

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

개발 환경 준비 완료

배포 자동화에 필요한 통합 도구로 개발 환경이 구성되었는지 확인합니다.

개발 팀이 프로젝트 범위 및 기대치를 이해함

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

• 프로젝트의 범위
• 모든 고객 기대치
• 프로젝트의 사용자별, 단계별로 결정된 모든 결정의 기초

대화 상자 사양

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

문서 개발 환경 설정

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

문서 프로덕션 환경 설정

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

문서 테스트 환경 설정

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

내구성 시험

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

내구성 테스트 실행됨

내구성 테스트 실행.

오류 처리 개념

오류 처리란 프로그래밍, 응용 프로그램 및 통신 오류에 대한 예상, 감지 및 해결 방법을 의미합니다.

오류 처리 설명서

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

에스컬레이션 프로세스

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

• 프로젝트 팀
• 고객
• Adobe

정기적인 품질 검토 세션 설정

적절한 팀원과 정기적인 품질 검토 회의를 수립합니다.

기존 권한 구조

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

기존 시스템 맵

기존 시스템 및 종속성에 대한 다이어그램(또는 다이어그램 세트)입니다.

예상 성공 정의 및 기준

프로젝트 스폰서는 프로젝트의 성공과 관련된 비즈니스 기대치를 수집합니다. 프로젝트 시작 시 모든 기대 사항이 구현 전반에 걸쳐 이루어지는 모든 의사 결정에 영향을 미칠 수 있으므로 모든 기대 사항을 사용할 수 있도록 하는 것이 중요합니다.

기대치는 다음과 같습니다.

• 제공된 페이지의 백분율 증가 등 특정 KPI
• 콘텐츠 게시 시간 단축
• 사용하기 쉬운 인터페이스와 같은 높은 수준의 목표

경험 디자인 요구 사항

솔루션의 전체 경험을 위한 요구 사항입니다. 여기에는 개인화, 교차 장치 지속성 및 사용자 경험과 같은 요소가 포함됩니다.

경험 사양

경험 디자인 요구 사항에 대한 세부 사항입니다.

외부 시스템 및 사용자 종속성/시스템 컨텍스트

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

대체 시스템 및 절차

대체 시스템의 정의:

• 중대한 장애가 발생해도 운영 상태를 유지해야 하는 비즈니스 크리티컬 기능
• 대체 항목이 있는 경우 필요한 프로세스

예비(fallback) 시스템 및 절차 테스트

대체 시스템의 전체 테스트입니다.

비즈니스 이해 당사자의 대체 시스템 승인

비즈니스 이해 당사자로부터 대체 시스템 및 관련 절차를 통해 중요한 비즈니스 기능을 보장한다는 것을 확인합니다.

KPI에 대한 실현가능성 확인

AEM과 높은 수준의 솔루션 설계 모두에 대한 타당성 조사 결과. 이를 충족하기 위해 KPI에 대해 측정해야 합니다.

완료된 계약

프로젝트를 진행하기 전에 확정되고 서명된 계약서가 필요합니다. 다음을 기반으로 합니다. 계약 초안.

이해 당사자가 수락하는 솔루션의 기능

이해 당사자가 다음을 전적으로 동의한다는 확인:

• 솔루션 기능
• 솔루션의 알려진 문제

Go-Live 예약

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

• go-live 준비
• 실제 실행

정의된 행복 경로

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

하드웨어 예상

초기 예상:

• 기본 AEM 설치에 필요한 하드웨어
• 높은 수준의 솔루션 설계를 기반으로 하는 추가 요구 사항

요구 사항을 충족하기 위해 하드웨어를 사용할 수 있습니다.

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

높은 수준의 요구 사항

높은 수준의 요구 사항에 대한 정의는 다음과 같은 측면을 포괄하는 시스템에 대한 요구 사항의 일반화된 분석을 제공합니다.

• 비즈니스 프로세스
• 주요 시스템 기능

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

높은 수준의 솔루션 설계

높은 수준의 솔루션 설계는 솔루션 개발에 사용되는 아키텍처를 설명합니다. 아키텍처 다이어그램은 전체 시스템의 개요를 제공하며, 제품에 맞게 개발된 주요 구성 요소와 해당 인터페이스를 식별합니다.

높은 수준 시스템 맵

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

내역 콘텐츠 구조

레거시 시스템의 콘텐츠 구조 정의. 참조용으로 사용되고 마이그레이션 전략을 준비할 때도 사용됩니다.

과거 성과 및 과거 성과 KPI

기존 시스템에서 성능 통계 및 성능 KPI를 수집하고 문서화합니다. 그런 다음 참조점으로 사용하여 새 솔루션을 벤치마킹합니다.

주요 솔루션/기능 파악

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

구현 - 침투 테스트 결과에 따른 변경

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

구현 - 자동화된 테스트 전략

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

구현 - 자동화 전략

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

구현 - 콘텐츠 아키텍처

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

구현 - 경험 디자인

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

구현 - 대체 시스템 및 절차

폴백 시스템 구현 및 관련 절차.

구현 - 통합

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

구현 - 마이그레이션 전략

새로운 솔루션에 대한 콘텐츠 및 기타 아티팩트의 유효성 검사와 함께 마이그레이션.

구현 - 역할 및 권한

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

구현 - 보안 개념

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

구현 - 보안 소프트웨어

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

구현 - 시스템 아키텍처 보안 개념

시스템 보안 구현.

구현 - URL 처리

URL 처리 개념의 구현입니다.

구현 - 워크플로

설계된 워크플로의 구현.

구현 개념

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

• 작업
• 유지 관리
• 호환성
• 재사용 가능성
• 보안
• 확장성

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

Go-Live 일정에 대해 Adobe 지원 센터에 알림

Go-Live 중에 필요한 모든 지원을 활성화할 수 있도록 하려면 Adobe 지원 센터에 문의하십시오.

초기 경험 디자인

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

통합 테스트

모든 통합의 테스트 및 그 결과 확인(내부 및 외부 모두).

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

문제 추적 프로세스

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

문제 추적 시스템 및 프로세스

모든 문제를 기록하고 모든 문제가 해결되도록 하기 위한 목적으로 진행 중인 활동을 추적하는 시스템 및 필수 프로세스.

모든 프로젝트 이해 당사자는 프로젝트 상태의 투명성을 용이하게 하기 위해 액세스 권한이 있어야 합니다.

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

문제 추적 시스템 프로세스 설정 및 통합

선택한 도구는 완전히 통합되고 모든 필수 역할에 액세스 권한이 부여됩니다.

레거시 시스템

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

기존 시스템의 세부 정보를 수집하여 폐기될 수 있는 사항, 폐기 시기 및 다른 시스템에 미치는 영향을 파악해야 합니다.

사용할 개발 도구 목록

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

• 설명서 도구
• 문제 추적 도구
• 배포 도구
• 빌드 도구

Adobe 지원 포털에 대한 액세스 권한이 필요한 사용자 목록

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

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

로그 파일 분석

결과 권장 사항과 함께 솔루션을 모니터링하기 위해 기록해야 하는 항목을 정의하는 분석입니다.

• 기록할 활동
• 세부기간 수준
• 각 활동에 대해 기록된 정보

유지 관리 작업(AEM별) 테스트 및 활성화됨

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

• 압축
• 시스템 청소
• 워크플로 삭제

마이그레이션 계획

마이그레이션 문서화, 포함

• 마이그레이션 타임라인
• 마이그레이션 전략에 따른 콘텐츠 유지 관리 계획

마이그레이션 전략

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

• 가능한 경우 자동화된 마이그레이션에 대한 기술 세부 정보
• 마이그레이션 후 수행할 smoke 테스트와 마이그레이션된 콘텐츠의 유효성 검사

또한 마이그레이션과 새 시스템의 실제 실행 사이에 콘텐츠를 최신 상태로(또는 가능한 최신 상태로) 유지하는 방법을 권장해야 합니다. 이는 콘텐츠 동결, 이중 게시 또는 알파 시스템 유지 관리를 의미할 수 있습니다.

모니터링 - CPU

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

• 평균
• 봉우리

모니터링 - 디스크 I/O

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

• 평균
• 봉우리

모니터링 - 디스크 공간

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

• 평균
• 시간에 따른 성장

다음 방법으로 사용을 모니터링해야 합니다.

• 저장소
• 로그 파일

모니터링 - 외부 시스템

솔루션과 외부 시스템 간의 연결을 모니터링합니다.

• 트래픽 비율
• 봉우리
• 안정성

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

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

• 평균 트래픽 비율
• 봉우리
• 안정성

모니터링 - 요청

솔루션에 대한 요청 모니터링

모니터링 - 보안 지점

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

모니터링 - 시스템

전체 시스템을 모니터링합니다. 예를 들면 다음과 같습니다.

• 사용 가능
• 평균 성과
• 최대 성능
• 경고

모니터링 - 임계값 및 개입

부하를 줄이기 위한 중재 단계 구현과 함께 솔루션의 정의된 임계값 모니터링.

모니터링 개념

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

• AEM 표준 모니터링
• 시스템 모니터링
• 고객별 모니터링 요구 사항

잠재적 취약점 모니터링

장애에 취약할 수 있는 특정 지점을 식별하고 정의해야 합니다. 이와 관련된 모든 모니터링 작업도 정의해야 합니다.

그 예는 다음과 같습니다(그 중에서도).

• 주요 워크플로우
• 트랜잭션 처리
• 통합 지점

시스템 엔지니어에게 전달된 모니터링 정책

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

보고서 모니터링 - 적소 구조

다음을 정의합니다.

• 모니터링 보고서를 생성해야 하는 경우
• 전달해야 하는 대상

운영 작업 설명서

모든 운영 작업이 문서화되고 빈도가 정의됩니다.

작업 설명서

솔루션의 성공적인 운영 및 유지 관리에 필요한 모든 정보를 수동으로 제공:

• 모든 운영 작업
• 주요 연락처
• 배포 계획
• 배포 전/후 확인 목록
• 기타 중요한 작업

또한 구현 개념을 자세히 설명해야 합니다.

• 성과 KPI 충족
• 해당 KPI를 계속 충족하도록 솔루션 확장

패키지 준비됨

배포 준비가 완료된 상태로 빌드 및 제공되는 소프트웨어 패키지

침투 시험

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

침투 테스트 - 합격

모든 필수 기준이 통과됩니다.

침투 테스트 - 결과

침투 테스트 결과를 설명하는 비즈니스를 위해 생성된 보고서.

성능 및 확장성 개념

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

성능 벤치마크

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

성과 KPI

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

성능 테스트 - 보고서

비즈니스를 위해 생성된 보고서로, 성능 테스트 결과를 자세히 설명합니다.

성능 테스트 - 결과 일치 성능 KPI

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

사용자 기반 테스트 개념

사용자 기반 테스트는 경험 디자인에 설명된 다양한 사용자를 기반으로 하는 방법입니다. 또한 계정 및 관련 권한 수준을 테스트합니다.

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

요구 사항 설명서에 대해 테스트 및 확인된 POC

POC(Proof of Concept)는 요구 사항과 비교하여 둘 다 일치하는지 확인합니다.

배포 후 검사 목록

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

배포 전 검사 목록

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

프로덕션 환경 기본 성능 테스트

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

프로덕션 환경 준비

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

비즈니스 이해 당사자로부터 생산 승인

프로덕션 환경으로 Go-Live하기 전에 프로덕션 승인(PSO)을 부여해야 합니다. 이는 알려진 문제와 함께 프로덕션에 포함될 릴리스를 검토한 결과입니다. 로그오프는 Go Live 예약의 일부로 제공됩니다.

프로덕션 승인 프로세스 및 정책

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

프로젝트 커뮤니케이션 계획

비즈니스 이해 당사자와 프로젝트 팀 모두에 대한 커뮤니케이션 계획을 정의합니다.

프로젝트 노력 - 최종 예상

다음 초기 예상 값 높은 수준이었으며 구현에 대한 높은 수준의 요구 사항에 따라 만들어졌습니다.

이제 이를 검토, 정제 및 확대하여 최종 추정치를 제공한다. 추정치는 프로젝트 관리, 컨설팅, 아키텍처, 테스트 및 개발 등 각 프로젝트 책임자가 제공해야 합니다.

이러한 예상 값은 리소스 조달 및 예산 편성에 사용됩니다.

프로젝트 노력 - 초기 예상

초기 추정은 높은 수준이며 구현에 대한 높은 수준의 요구 사항에 따라 수행됩니다. 이에 대해서는 이후 단계에서 검토 및 개선할 것이다.

프로젝트 조직

프로젝트 및 팀의 조직 및 보고 구조를 개략적으로 설명하는 필수 설명서입니다.

종종 차트에서 타임라인 및 책임에 대한 시각적 개요를 보여주거나 차트를 사용합니다. 이 작업에 도움이 되는 다양한 도구가 있습니다.

프로젝트 범위 문서

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

• 특정 프로젝트 목표
• 결과물
• 기능
• 함수
• 작업
• 기한
• 계획된 노력

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

정의된 케이던스 내의 프로젝트 상태 보고서

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

POC(개념 증명)

POC(Proof of Concept)는 솔루션에 대해 제한된 범위의 함수를 구현합니다.

해결의 타당성을 입증하는 것을 목표로 해야 하며, 필요한 목적을 달성할 수 있는지 검증하고 활용 가능성이 있음을 증명해야 한다.

규칙 제거

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

품질 보고서 형식 및 케이던스

품질 보고서의 필수 콘텐츠 및 형식과 배달 빈도를 정의합니다.

릴리스 조정

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

릴리스 정보

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

• 전제 조건
• 요구 사항 포함
• 문제 해결됨
• 릴리스의 알려진 문제

Runbook과 함께 사용하여 설치 전/후 단계 및 검사를 실행합니다.

프로덕션 환경에서 실행되는 릴리스

최종 릴리스가 실행 중이며 프로덕션에서 활성 상태입니다.

관련 계약 조건

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

보고 케이던스

고객과 함께 고객에게 전달되는 보고서의 빈도를 정의합니다.

저장소 최적화

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

저장소 크기가 점점 커지는 것에 대응하기 위해 오래된 데이터를 제거하는 최적화 전략을 마련했습니다.

Adobe 지원 포털의 프로젝트 섹션 설정 요청

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

요구 사항 설명서

이 설명서 세트에서는 추정된 노력과 함께 기능 및 비기능 요구 사항을 다룹니다.

Go-Live를 지원하는 데 사용할 수 있는 리소스

Go-Live에 필요한 모든 역할을 담당하며 사용할 수 있는지 확인합니다.

위험 평가

위험 평가는 고객의 IT 부서나 보안 부서 또는 둘 다에서 수행합니다.

프로젝트의 기술적 및 비즈니스 위험을 평가합니다. 보안 정책 준수를 보장하기 위해 이 솔루션에 대한 평가가 필요합니다.

위험 완화 계획

위험 완화 계획에는 위험 평가가 포함됩니다. 이들은 다음을 다룹니다.

• 확인된 위험
• 이러한 위험이 구현에서 발생할 경우 이에 대한 가능한 해결 방법

ROI 예상

솔루션에 수반되는 ROI( 투자 수익률 ) 기대치를 정의합니다.

이들은 추정된 투자와 관련하여 기대되는 이익/이익을 규정함으로써 해결의 효율성을 경제적 측면에서 나타내는 것을 목적으로 한다.

역할 및 권한 개념

새 애플리케이션에 필요한 역할 및 액세스 권한과 관련된 개념에 대한 자세한 사양입니다. 여기에는 다음에 대한 높은 수준의 개요가 포함됩니다.

• 역할
• 그룹
• 사용자
• 권한
• 및 사용자 관리 및 프로비저닝

역할 및 권한 개념이 보안 지침을 충족함

역할 및 권한 개념을 검토하여 보안 정책을 충족하는지 확인하십시오.

역할 및 권한 사양

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

보안 아키텍처 Recommendations

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

보안 기반 코딩 지침

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

• 이름 지정 규칙
• 라이브러리
• 프레임워크 지침
• API 사용

보안 검사 목록

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

또한 Runbook에서 배포 후 단계의 일부로 포함되는 경우가 많습니다.

보안 개념

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

보안 개념 초안

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

• 애플리케이션
• 아키텍처
• 인프라

나열된 보안 문제 및 평가된 문제

수고 예상치를 포함하여 솔루션의 모든 보안 문제가 나열되고 평가됩니다.

비즈니스 이해 당사자로부터 보안 승인

보안 구현이 정책 및 기대치를 준수하는지 확인하려면 이해 당사자로부터 승인을 얻으십시오.

지원 프로세스 설정

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

서드파티 시스템의 SLA

SLA(서비스 수준 계약)를 구현하고 지원하는 동안 개발 및 운영 팀에 모두 사용할 수 있고 전달할 수 있는지 확인합니다.

스모크 테스트 개념

Smoke 테스트는 솔루션의 기본 작동 및 기능을 보장하기 위해 솔루션의 주요 기능을 테스트하는 일련의 정의된 단계로 구성됩니다.

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

시스템 유효성 검사를 위해 실행된 연기 테스트

모든 환경에 대한 설치 또는 배포에 대한 솔루션의 기본 기능이 올바르게 작동하도록 모든 시스템에서 Smoke 테스트를 실행해야 합니다.

소프트웨어 아키텍처 전략

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

솔루션 검토 위원회 설치 및 회의 케이던스 세트

솔루션 검토 위원회는 고객 이해 당사자로 구성됩니다.

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

솔루션 Runbook

설치 시 실행할 기본 운영 작업과 함께 솔루션에 대한 설치 지침

솔루션 승인 및 수락 프로세스

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

계약상의 이정표 역할을 할 수도 있다.

특수 기능 개념

AEM 플랫폼의 일반적인 개발 범위 밖에 있는 것으로 간주되는 특별한 기능에 대한 초기 개념입니다.

특수 기능 사양

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

사양 지침

세부 항목을 작성하는 방법에 대한 고객의 모든 지침

정의 및 전달된 사양 검토 및 승인 프로세스

고객이 사양을 승인할 수 있도록 명확한 절차를 마련해야 합니다. 이 프로세스는 요구 사항에 대한 범위의 명확성과 견고성을 보장합니다.

AEM 관리자 교육을 위해 선택된 직원

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

작성자 및 최종 사용자 교육을 위해 선택된 직원

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

이해 당사자

이해 당사자는 프로젝트에 중요한 관심을 갖는 주요 사람 및/또는 역할입니다. 일부는 프로젝트 예산에 기여할 것이다.

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

이해 당사자는 성공 정의 및 기준에 대해 알고 있습니다.

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

• 성공의 정의
• 성공 기준

이해 당사자 프로젝트 및 기대 사항 이해

실제 구현 팀 외부의 모든 이해 당사자가 프로젝트 팀과 고객 내부 모두에서 전체 프로젝트 및 기대치와 일치하는지 확인합니다.

상태 보고서 형식 정의

상태 보고서는 의사 소통의 주요 도구입니다. 고객의 보고 요구 사항에 맞게 포맷을 조정해야 합니다.

성공 기준 및 정의

고객, 프로젝트 스폰서, 프로젝트 관리자 또는 컨설턴트가 지정해야 하는 사항은 다음과 같습니다.

• 프로젝트의 성공적인 결과를 정의하는 것은 무엇입니까?
• 성공에 대한 해당 정의를 충족하는 데 필요한 특정 기준.

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

• KPI의 기반으로 사용됩니다.
• 구현 전반에 걸쳐 의사 결정을 내릴 때

보고된 문제의 유효성 검사 지원

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

지원 프로세스 및 Adobe 지원 포털에 액세스

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

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

시스템 아키텍처 정의

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

시스템 아키텍처 설명서

인터페이스, 네트워크 위치 및 모든 환경에 대한 통합 등 시스템 아키텍처를 자세히 설명하는 문서입니다.

시스템 아키텍처 보안 개념

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

• 방화벽 및 방화벽 규칙
• 보안 영역
• 로컬 및 일반 트래픽 관리자
• 웹 서버
• 프록시 및 역방향 프록시

시스템 위험 요소 파악 및 검증

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

• 각 위험 요소에 내포된 위험 수준
• 구현을 변경하는 데 필요한 예상 노력과 함께.

팀은 성공 정의 및 기준을 알고 있습니다.

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

팀은 커뮤니케이션 계획을 알고 있습니다.

팀의 모든 구성원이 고객과 커뮤니케이션해야 하는 사용자를 알고 있는지 확인하는 동시에 자세한 방법 및 시기를 확인합니다.

팀이 프로젝트 및 기대치 파악

프로젝트 팀과 고객 내부 전체 프로젝트 및 기대치에 맞게 조정.

기술 요구 사항

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

기술적 위험 요소 확인

잠재적인 기술 위험을 식별하고 확인합니다. 기술적 위험에는 다음이 포함될 수 있습니다.

• 크로스 사이트 스크립팅
• 입력 필드를 마주보는 최종 사용자
• 인프라
• 기술 시대
• 통합 수
• 및 종속성

기술 사양

기술 사양은 (다른 정보 중에서도) 다음을 다룹니다.

• 인터페이스
• 구성
• API
• 솔루션의 요구 사항을 지원하는 서비스

템플릿 사양

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

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

테스트 사례

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

테스트 콘텐츠

테스트 콘텐츠는 가능한 프로덕션 콘텐츠에 가깝어야 합니다. 모든 시나리오를 테스트할 수 있을 만큼 충분히 광범위한 선택 사항이어야 합니다.

테스트 환경 준비 완료

모든 릴리스 후보 코드가 테스트를 위해 최신 버전인지 확인하기 위해 자동화된 배포가 배치되어 테스트 환경이 준비되었는지 확인합니다.

테스트 보고서

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

• 결함 발생
• 실행된 테스트 사례 상태
• 기타 품질 관련 항목

주의해야 할 사항은 다음과 같습니다.

• 모든 테스트 팀은 중립을 유지하고 테스트 결과를 제공할 수 있어야 합니다.
• 결과의 영향을 평가하고 적절한 조치를 결정하는 것은 프로젝트 관리자의 책임입니다.

테스트 세트

자동화 제품군 및 도구 선택. 사용 사례에 대한 테스트를 포함하여 테스트를 자동화하는 데 사용됩니다.

테스트 도구 세트 선택됨

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

테스트 개념

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

테스트 계획

이러한 계획은 각 개발 단계에 대한 테스트 실행을 자세히 설명하며 다음을 기반으로 합니다. 테스트 전략.

테스트 범위

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

테스트 전략

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

타사 통합 개념

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

타사 통합 사양

서드파티 시스템의 지원 기능 및 통합에 대한 요구 사항(기능 및 비기능 모두)에 대한 세부 정보.

서드파티 보안 개념

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

통합을 위한 서드파티 시스템

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

서드파티 시스템 액세스 사용

서드파티 시스템에서 사용되는 각 역할에 부여된 필수 액세스 권한.

타사 테스트 개념

다음을 정의합니다.

• 통합 테스트를 위한 사용 사례
• 모든 타사 응용 프로그램과 관련된 기능

임계값 정의

시스템의 모니터링 지점에 대한 키 값을 정의합니다.

예:

• 주 서버 인스턴스에 경고를 생성하는 전송되지 않은 로그 크기(KB)입니다
• 주 서버에서 경고가 생성되기 전에 허용되는 트랜잭션당 평균 지연 시간(밀리초)

타임라인 및 마일스톤

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

• 송장발행.
• 성공 정의, 성공 기준 및 KPI에 따라 정렬합니다.

총 프로젝트 노력

오버헤드, 개발, 시스템 엔지니어링, 건축 및 테스트 등 프로젝트의 각 리드에 대한 모든 작업 예상치를 통합해야 합니다.

협약에 포함된 지원 수준이 있다면 지원과 운영 노력도 포함돼야 한다.

교육 자료

교육 세션에서 사용할 자료입니다. 자료는 솔루션용으로 특별히 제작해야 하며 사용 안내서와 함께 사용할 수 있도록 설계되어야 합니다.

프로젝트 범위 및 기대치 파악

적절한 담당자는 다음을 완전히 이해하고 있는지 확인해야 합니다.

• 프로젝트의 범위
• 모든 고객 기대치
• 이는 프로젝트의 단계별로 담당자별로 이루어진 모든 의사 결정의 기준이 됩니다

URL 처리 개념

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

• 별칭 URL
• 링크 외부화
• 오류 페이지
• 매핑

이 개념에는 다음도 포함되어야 합니다.

• 모든 재작성 규칙
• 웹 서버의 가상 호스트
• robots.txt와 같은 SEO 고려 사항
• 사이트 맵

사용 사례

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

테스트 시나리오로 전환된 사용 사례

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

사용 안내서

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

• 작성자
• 고급 사용자
• 관리자

검증된 예산 계획

예산안은 모든 관련자들에 의해 검토되고 타당성이 입증되어야 한다. 송장발행, 금액, 예산 보고의 방법/시기 등 세부 사항을 확인해야 합니다.

화이트 박스 테스트 결과

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

워크플로 사양

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

각 워크플로우의 사양에는 최소한 다음이 포함되어야 합니다.

• 사용 사례
• 역할
• 단계
• 결과
• 오류 처리

워크플로우 개념

워크플로우를 사용하면 AEM 활동을 자동화할 수 있습니다. 워크플로 개념은 다음과 같습니다.

• 자동화가 필요한 프로세스
• 영향을 받는 AEM의 서비스 및 역할