용어 설명

이 용어에는 프로젝트 체크리스트의 모든 결과물 문서의 세부 정보가 표시됩니다(알파).

비즈니스 이해 관계자의 수락

비즈니스 이해 관계자의 동의를 통해 주요 이해 관계자로서 솔루션을 연계하여 비즈니스 요구 사항이 비즈니스 조건에 어떻게 부합하는지 승인을 받았음을 확인할 수 있습니다.

수락 테스트

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

수락 테스트는

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

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

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

테스트 시스템에 대한 액세스 조정

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

Adobe 보안 검사 목록

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

Adobe 지원 포털 프로젝트 설정

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

자세한 내용은 등록하십시오.예를 들어 구현된 기술 및 버전에 대해 설명합니다. 이는 고객과 Adobe 간의 투명성을 제공합니다.

AEM 관리자 교육

솔루션 관리 직원을 위한 트레이닝 자세한 내용은 Adobe 교육 서비스를 참조하십시오.

AEM 작성자 교육

솔루션용 컨텐츠를 작성(작성)할 직원을 위한 트레이닝 자세한 내용은 Adobe 교육 서비스를 참조하십시오.

AEM 인증 시험

관련 인증 시험을(를) 수강하기 위해 적절한 사람이 등록되었는지 확인합니다.

AEM 인증

적절한 사람이 관련 인증 시험에 합격했는지 확인합니다.

AEM 기술 교육

적합한 인물을 위한 기술 교육 제공예를 들어 개발자, 건축가, 엔지니어 및 비즈니스 전문가를 소개합니다.

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

KPI(Key Performance Indicator)를 사용하면 조직에서 조직 목표 및 목표에 대한 진행 상황을 정의하고 측정할 수 있습니다. 한 조직이 그것의 임무를 분석해서 그것의 목표를 정하면, 그것은 그 목표에 대한 진전을 측정해야 합니다. KPI는 측정 메커니즘을 제공합니다.

비즈니스 및 성과 KPI 정렬

비즈니스 및 성과 조정 KPI(Key Performance Indicator)를 사용하면 조직 내에서 관련된 모든 사람과 프로세스를 통합할 수 있습니다. 따라서 비즈니스 목표를 달성하고 제안된 목적을 달성하는 데 필요한 시간과 노력을 줄일 수 있습니다.

KPI에 콘텐츠 아키텍처 정렬

제안된 콘텐츠 아키텍처가 관련 KPI(Key Performance Indicator)와 일치하는지 확인합니다.

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

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

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

응용 프로그램 아키텍처는 제안된 응용 프로그램의 동작을 명확하게 정의해야 합니다.

주요:

  • 사용자와 상호 작용하는 방법
  • 내부 구조가 아닌 애플리케이션에서 사용하고 생성하는 데이터

응용 프로그램 특정 유지 관리 작업 정의

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

적절한 교육을 받은 직원

해당 트레이닝을 통해 팀원이 구성되어 있는지 확인합니다. 프로젝트 팀의 경우 권장 사항은 다음 항목 모두를 가져야 합니다.

  • aem 공인 리드 개발자 최소 1명
  • aem 공인 아키텍트 1명 이상
  • 개발자 중 최소 75%가 AEM 인증을 받았습니다.
    따라서 인증된 개발자는 준전문가 개발자에게 멘토할 수 있고 지식 공유와 투명성을 보장할 수 있습니다

아키텍처 다이어그램

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

  • 개념
  • 그들의 원칙
  • 아키텍처에 포함된 요소 및 구성 요소

아키텍처 초안

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

아키텍처 검토 보드 승인

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

  • 일관성 있는 전략 이행 관리
  • 시스템 규정 준수 보장

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

실제 컨텐츠와 결과에 맞게 조정된 자동화된 테스트 세트를 KPI과 비교

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

  • 프로덕션 컨텐츠에 맞게 조정
  • KPI에 대해 체크됨

자동화된 테스트 전략

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

  • 높은 투자 수익(ROI)
  • 더 많은 테스트 범위
  • 품질 반복을 통한 테스트 안정성 향상

실제 로드와 예상 부하(a0/>)에 대해 검증된 자동화된 테스트 전략

자동화된 테스트 전략은 솔루션에 표시될 컨텐츠 및 예상 부하에 따라 검증되고 조정되어야 합니다.

자동화 전략

배포 자동화를 통해 배포 시간을 단축하고 일관되게 유지할 수 있습니다. 자동화 전략은 이러한 자동화 메커니즘의 구성을 간략히 설명합니다.포함:

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

통신 계획 인식

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

  • 보고 구조
  • 보고의 관점
  • 통신 채널

성공 정의 및 기준 인식

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

  • 성공의 정의
  • 성공 기준

백업 및 복원 개념

백업 및 복원 개념은 솔루션에서 구현할 기술 기능에 대해 설명합니다. 회사 백업 및 복원 정책에 따라 필요합니다.

백업 및 복원 테스트됨

백업 및 복원 개념에 기반한 완벽한 엔드 투 엔드 테스트

비즈니스 사례

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

비즈니스 사례 문서는 제안된 솔루션의 구현에 대한 매력적인 인수를 통해 모든 옵션의 명확한 정의가 되어야 합니다.

비즈니스 분석가는 프로젝트의 범위와 기대 이해

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

  • 프로젝트의 범위
  • 모든 고객의 기대치
  • 이는 프로젝트의 단계별로 개인별 모든 의사 결정의 기본이 됩니다.

비즈니스 KPI

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

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

비즈니스 요구 사항 설명서

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

비즈니스 솔루션을 검토할 때 BRD는 다음 질문에 답해야 합니다.
"기업에서 원하는 작업

ROI 및 KPI 기대치에 맞게 조정되는 솔루션 또는 아키텍처에 대한 필요한 조정 사항에 대한 비즈니스 서명:

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

이러한 프로세스에서 발생하는 모든 조정은 기업이 검토 및 승인하고 전체적인 목표에 맞게 조정되어야 합니다.

캐싱 전략

캐싱 전략은 최종 사용자에 대해 캐시될 대상에 대해 대략적으로 설명합니다. 성능 KPI와 호환되어야 합니다.

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

코딩 지침

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

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

통신 작업 설명서

해당 모든 페르소나/역할이 작업 매뉴얼을 수신했는지 확인합니다.

통신 성능 테스트 보고서

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

알림 릴리스 노트

해당 모든 페르소나/역할이 릴리스 노트를 수신했는지 확인합니다.

팀에 범위 및 기대치 전달

프로젝트 팀이 프로젝트 범위와 전달에 대한 기대치를 충분히 인식하고 그에 부합하는지 확인합니다.

교육 자료 및 사용자 안내서 통신

모든 적절한 페르소나/역할이 교육 자료와 사용자 안내서를 수신하도록 하십시오.

고객 보안 요구 사항 준수

고객의 보안 요구 사항이 모두 충족되는지 확인하십시오.

보안 개념 준수

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

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

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

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

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

구성 요소 사양

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

외부 인터페이스 시안을 위한 개념

개발 또는 테스트 환경에 개방되거나 사용할 수 없는 외부 인터페이스를 개발 및 테스트하는 방법의 개념.

이러한 인터페이스의 초안을 계획/구현하여 테스트가 프로덕션과 유사한 비헤이비어에 최대한 가깝게 실행되도록 합니다.

콘텐츠 아키텍처 문서

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

  • 컨텐츠 트리
  • 태그 개념
  • 컨텐츠 재사용 전략

마이그레이션에 대해 유효성 검사된 콘텐트

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

계약 초안

법률 계약의 초기 초안.

현재 콘텐츠 구조 및 형식

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

고객 백업 및 복원 정책

고객의 정책 관련 사항:

  • 데이터와 솔루션 모두를 위한 백업 프로세스
  • 백업 저장소
  • 백업이 예상대로 작동하는지 확인
  • 복구가 실패할 경우

고객 코딩 지침

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

고객 배포/릴리스 정책

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

이러한 요구 사항에는 타임라인과 일정 관리 및 로그오프가 포함됩니다.

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

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

고객 프로덕션 릴리스 일정

생산 환경에 대한 릴리스에 대해 고객이 정의하는 일정입니다.

고객 보고 정책 및 요구 사항

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

  • 특정 보고서를 배달하는 빈도
  • 특정 보고서의 형식
  • 특별 요구 사항

고객 로드맵

기술 및 비즈니스 모두 구현할 주요 이정표의 로드맵을 만듭니다. 이 로드맵은 고객에게 전달됩니다.

고객 보안 정책

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

  • 위험 평가를 통과하기 위한 요구 사항.
  • 보급률 테스트를 통과하기 위한 요구 사항
  • 특정 보안 요구 사항;모든 입력 필드 이스케이프 처리, 암호화 사용(SSL), 인증서, 인증 및 세션 이스케이프 지정 등의 작업을 수행합니다.

고객 사양 지침

규격의 형식, 전달 및 로그오프와 관련하여 고객이 갖는 모든 지침

고객 테스트 보고서

UAT(사용자 수락 테스트) 기간 동안 고객으로부터 품질 리드에 대한 보고서.

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

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

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

  • 현재 솔루션에 필요한 모든 업데이트는 완전하게 문서화되어야 합니다.이러한 작업에는 다음이 포함될 수 있습니다.

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

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

UAT(사용자 수락 테스트)로 인해 발생한 보고서 또는 회의. 자세한 내용은

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

기본 보안 사용

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

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

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

  • 릴리스 시간
  • 휴가 계획
  • 빈도
  • 그리고 문제의 환경에 따라

배포 대상 설정됨

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

개발 방법론

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

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

개발 역할 정의

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

개발 환경 준비

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

개발 팀은 프로젝트의 범위와 기대치를 파악합니다

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

  • 프로젝트의 범위
  • 모든 고객의 기대치
  • 이는 프로젝트의 단계별로 개인별 모든 의사 결정의 기본이 됩니다.

대화 상자 사양

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

문서 개발 환경 설정

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

문서 제작 환경 설정

제작 환경 설명서

문서 테스트 환경 설정

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

내구성 테스트

내구성 테스트는 특정 로드 하의 솔루션 성능을 보여줍니다. 테스트는 솔루션이 임계값 로드에 제출될 때 생존하는 시간 및 성능 수준에서 측정합니다.

내구성 테스트 실행

내구성 테스트 실행

개념 처리 오류

오류 처리에서는 프로그래밍, 응용 프로그램 및 통신 오류의 예상, 감지 및 해결 방법을 참조합니다.

문서 처리 오류

오류 처리 개념을 기반으로 제안된 오류 처리에 대한 자세한 설명서를 참조하십시오.

문제 제기 프로세스

모든 문제 제기 프로세스의 정의. 각 프로젝트 수준에 대해 별도의 프로세스가 있습니다.

  • 프로젝트 팀
  • 고객
  • Adobe

일반 품질 검토 세션 설정

적절한 팀원과 정기적인 품질 검토 회의를 설정할 수 있습니다.

기존 권한 구조

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

기존 시스템 맵

기존 시스템 및 종속성을 나타낸 다이어그램(또는 다이어그램 집합).

예상 성공 정의 및 기준

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

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

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

경험 디자인 요구 사항

솔루션 전체 경험에 대한 요구 사항 개인화, 크로스 디바이스 지속성 및 사용자 경험과 같은 요소를 다룹니다.

경험 사양

경험 디자인 요구 사항에 대한 자세한 내용을 살펴보십시오.

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

솔루션의 전체 에코시스템을 대략적으로 나타내는 다이어그램(또는 다이어그램 집합). 외부 통합, 인터페이스, 종속성 및 네트워크와 같은 요소를 포함해야 합니다.

대체 시스템 및 절차

폴백 시스템의 정의:

  • 중요한 장애 발생 시 계속 작동해야 하는 비즈니스 중요한 기능
  • 폴백 시 필요한 프로세스

폴백 시스템 및 절차가 테스트됨

폴백 시스템의 엔드 투 엔드 테스트

비즈니스 이해 관계자로부터 시스템 로그오프 폴백

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

KPI에 대한 실행 가능성 확인

AEM과 고품질의 솔루션 디자인을 위한 타당성 조사 결과. KPI에 대해 측정해야 이러한 기준이 충족됩니다.

계약 완료

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

이해 관계자가 허용하는 솔루션의 기능

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

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

Go Live 일정

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

  • 실시간 준비
  • 실제 생방송

정의된 행복한 경로

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

하드웨어 예상:

초기 예측:

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

하드웨어를 요구 사항 충족에 사용할 수 있음

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

높은 수준 요구 사항

높은 수준 요구 사항의 정의는 다음과 같은 측면을 포함하는 시스템의 요구 사항을 일반화하여 분류합니다.

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

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

수준 높은 솔루션 디자인

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

높은 수준 시스템 맵

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

내역 콘텐츠 구조

기존 시스템의 컨텐츠 구조에 대한 정의입니다. 참조용으로 사용되며 마이그레이션 전략을 준비할 때도 사용됩니다.

이전 성과 및 이전 성과 KPI

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

중요한 주요 솔루션/기능 식별

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

구현 - 보급률 테스트 결과에 따른 변경 사항

보급률 테스트 결과를 기반으로 솔루션에 필요한 모든 변경 사항(서명됨)의 구현

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

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

구현 - 자동화 전략

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

구현 - 컨텐트 아키텍처

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

구현 - 경험 디자인

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

구현 - 대체 시스템 및 절차

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

구현 - 통합

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

구현 - 마이그레이션 전략

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

구현 - 역할 및 권한

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

구현 - 보안 개념

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

구현 - 보안 소프트웨어

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

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

시스템 보안 구현.

구현 - URL 처리

URL 처리 개념 구현.

구현 - 워크플로

설계된 워크플로우의 구현.

구현 개념

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

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

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

이동 실시간 일정에 대해 Adobe 지원에 알림

Adobe 지원 센터에 문의하여 필요한 지원을 이동 중에 활성화할 수 있는지 확인하십시오.

초기 경험 디자인

경험 디자인에 대한 예비 개념.

통합 테스트

내부 및 외부 모든 통합에 대한 테스트 및 결과 확인

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

문제 추적 프로세스

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

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

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

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

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

문제 추적 시스템 프로세스가 설정되고 통합되었습니다.

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

기존 시스템

프로젝트의 경우 기존 시스템은 새로운 솔루션으로 대체될 기존 기술, 컴퓨터 시스템 또는 애플리케이션 프로그램입니다.

어떤 작업을 중단할 수 있는지, 언제 다른 시스템에 미치는 영향을 알 수 있도록 기존 시스템의 세부 사항을 수집해야 합니다.

사용할 개발 도구 목록

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

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

Adobe 지원 포털에 액세스해야 하는 사용자 목록

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

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

로그 파일 분석

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

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

유지 관리 작업(AEM 특정) 테스트되고 활성화된

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

  • 합성
  • 시스템 정리
  • 워크플로 제거

마이그레이션 계획

마이그레이션 문서화;including

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

마이그레이션 전략

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

  • 가능한 경우 자동 마이그레이션 기술 세부 정보
  • 마이그레이션된 컨텐츠의 유효성을 확인하기 위해 마이그레이션 후 수행하는 연기 테스트

또한 마이그레이션 및 새 시스템의 실제 진행 중에 컨텐츠를 최신 상태로 유지하는 방법을 권장해야 합니다. 이는 컨텐츠 중단, 이중 게시 또는 알파 시스템 유지 관리를 의미합니다.

모니터링 - CPU

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

  • 평균
  • 봉우리

모니터링 - 디스크 I/O

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

  • 평균
  • 봉우리

모니터링 - 디스크 공간

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

  • 평균
  • 시간에 따른 성장

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

  • 저장소
  • 로그 파일

모니터링 - 외부 시스템

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

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

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

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

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

모니터링 - 요청

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

모니터링 - 보안 포인트

정의된 보안 지점을 모니터링할 수 있습니다.

모니터링 - 시스템

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

  • 가용성
  • 평균 성능
  • 성능 최고점
  • 경고

모니터링 - 임계값 및 개입

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

모니터링 개념

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

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

잠재적 취약점 모니터링

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

예: (다른 사람 중):

  • 주요 워크플로우
  • 거래 처리
  • 통합 지점

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

시스템 엔지니어 및 운영 직원이 모니터링 정책을 알고 이해하는지 확인합니다.

모니터링 보고서 - 제자리에 구조

정의:

  • 모니터링 보고서가 생성되어야 하는 시기
  • 그들이

운영 작업 설명서

빈도로 정의된 모든 운영 작업을 문서화합니다.

작업 설명서

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

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

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

  • 성과 KPI 미팅
  • 이러한 KPI를 지속적으로 충족하기 위한 솔루션 확장

패키지 준비

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

통과 테스트

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

통과 테스트 - 통과됨

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

침투 테스트 - 결과

보급률 테스트 결과를 설명하는 비즈니스용으로 작성된 보고서입니다.

성능 및 확장성 개념

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

성능 벤치마크

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

성과 KPI

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

성능 테스트 - 보고서

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

성과 테스트 - 성과 일치 KPI

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

페르소나 기반 테스트 개념

페르소나 기반 테스트는 경험 디자인에 설명된 서로 다른 성향에 기반한 방법입니다. 계정 및 관련 권한 수준도 테스트합니다.

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

POC 요구 사항 문서에 대해 테스트되고 확인됨

POC(Proof of of Concept)는 두 제품이 모두 정렬되도록 하기 위한 요구 사항에 맞게 평가됩니다.

배포 후 검사 목록

각 배포 후 수행할 일련의 검사 및 작업을 정의하는 검사 목록입니다.

배포 전 검사 목록

각 배포 전에 수행할 일련의 검사 및 작업을 정의하는 검사 목록.

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

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

프로덕션 환경 준비

자동화된 배포 기능을 통해 제작 환경이 준비되었는지 확인합니다.

비즈니스 이해 관계자로부터 프로덕션 서명

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

프로덕션 서명 해제 프로세스 및 정책

제작 환경으로 패키지를 옮기기 전에 Production Sign 오프를 가져오는 데 필요한 정책과 프로세스

프로젝트 통신 계획

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

프로젝트 노력 - 최종 예상

초기 예측은 높은 수준이었으며 구현을 위한 높은 수준의 요구 사항에 따라 수행됩니다.

이것들은 이제 최종 추정을 제공하기 위해 검토, 수정 및 확장됩니다. 견적서는 프로젝트 관리, 컨설팅, 건축, 테스트 및 개발을 포함하여 각 해당 프로젝트 리더로 전달되어야 한다.

이러한 예상치는 리소스 및 예산 관리에 사용됩니다.

프로젝트 노력 - 초기 예상

초기 추정은 높은 수준이며 구현을 위한 높은 수준의 요구 사항에 따라 수행됩니다. 이것은 나중에 검토하고 정제될 것이다.

프로젝트 조직

프로젝트 및 팀의 조직 및 보고 구조에 대한 개요를 설명하는 데 필요한 문서입니다.

타임라인과 책임을 시각적으로 소개하는 도표를 포함하거나 양식을 작성하는 경우가 많습니다. 이 작업에 도움이 되는 다양한 도구가 있습니다.

프로젝트 범위 문서

프로젝트 범위 문서는 다음 목록을 식별하고 문서화해야 합니다.

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

프로젝트를 제공하기 위해 수행해야 하는 작업과 수행해야 하는 작업을 다룹니다

정의된 대상 내 프로젝트 상태 보고서

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

개념 증명(POC)

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

이는 솔루션의 타당성을 입증하고, 필요한 목적을 달성할 수 있는지, 사용 가능성이 있는지 검증하는 데 목적이 있어야 합니다.

규칙 제거

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

품질 보고서 형식 및 대상

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

조정 해제

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

릴리스 노트

릴리스 노트는 릴리스에 대한 설명서의 일부입니다. 릴리스 노트에는 다음이 포함되어야 합니다.

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

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

노트

예를 보려면 AEM 릴리스 노트를 참조하십시오.

프로덕션 환경에서 실행 중인 릴리스

프로덕션 단계에서 실행 및 활성 상태의 최종 릴리스를 참조하십시오.

관련 계약 조건

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

보고 대상

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

저장소 최적화

데이터를 tar 파일에서 덮어쓰지 않으면 기존 데이터만 업데이트하더라도 디스크 사용이 증가합니다.

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

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

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

요구 사항 설명서

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

지원 가능한 리소스 라이브 실행

라이브하는 데 필요한 모든 역할을 담당하고 사용할 수 있도록 합니다.

위험 평가

위험 지원은 고객의 IT 및/또는 보안 부서에서 수행합니다.

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

위험 완화 계획

위험 완화 계획은 위험 평가를 포함합니다. 모두 다음을 포함합니다.

  • 위험
  • 이러한 위험에 대한 가능한 해결 방법은 구현 시 발생할 수 있습니다.

ROI 기대치

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

그들은 예상 투자와 관련하여 예상되는 이점과 수익을 규정함으로써 경제적인 측면에서 솔루션의 효율성을 나타내기 위해 목적이 있다.

역할 및 권한 개념

높은 수준의 개요를 포함하여 새 응용 프로그램에 필요한 역할 및 액세스 권한과 관련된 개념에 대한 세부 사양

  • 역할
  • 그룹
  • 사용자
  • 권한
  • 사용자 관리 및 프로비저닝뿐만 아니라

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

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

역할 및 권한 사양

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

보안 아키텍처 Recommendations

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

보안 기반 코딩 지침

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

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

Security 검사 목록

솔루션 준수에 필요한 추가 정책과 함께 보안 개념을 기준으로 한 프로젝트 특정 항목 확인 목록입니다.

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

보안 개념

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

보안 개념 초안

다음 항목의 보안 설정을 포함하는 높은 수준의 개요:

  • application
  • 아키텍처
  • 인프라

보안 문제 목록 및 평가

목록에 기재되어 평가된 솔루션의 모든 보안 문제노력 예상치를 포함하여.

비즈니스 이해 관계자로부터 보안 서명

보안 구현이 정책 및 기대를 준수하도록 이해 당사자로부터 로그오프합니다.

지원 프로세스 설정

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

타사 시스템 SLA

구축 및 지원 중에 사용할 수 있도록 SLA(서비스 수준 계약)를 사용할 수 있도록 하고 개발 팀과 운영 팀 모두에게 알려야 합니다.

연기 테스트 개념

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

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

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

모든 시스템에서 연기 테스트를 실행하여 설치 또는 모든 환경에 배포할 솔루션의 기본 기능을 정확하게 수행해야 합니다.

소프트웨어 아키텍처 전략

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

솔루션 검토 위원회가 설치되고 회의 대상 집합

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

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

솔루션 Runbook

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

솔루션 로그오프 및 수락 프로세스

승인 과정은 솔루션을 생산적인 환경으로 출시하기 전에 충족해야 하는 기준을 간략하게 설명합니다.

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

특수 기능 개념

AEM 플랫폼에서 일반적인 개발 범위를 벗어난 특별한 기능에 대한 초기 개념입니다.

특수 기능 사양

AEM 플랫폼에서 일반적인 개발 범위를 벗어난 특별한 기능에 대한 세부 사항입니다.

사양 지침

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

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

고객의 세부 규격에 대한 명확한 승인 절차가 필요하다. 이 프로세스는 요구 사항에 대해 범위가 명확하고 견고함을 보장합니다.

AEM 관리자 교육에 대해 선택한 직원

솔루션을 관리하는 데 필요한 내부 직원입니다.

작성자 및 최종 사용자 트레이닝용으로 선택한 직원

솔루션 작성을 위한 교육이 필요한 내부 직원

이해 관계자

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

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

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

실제 구현 팀 외부의 모든 이해 관계자가 다음을 인식하는지 확인:

  • 성공의 정의
  • 성공 기준

이해 관계자는 프로젝트 및 기대치를 파악합니다.

실제 구현 팀 외부의 모든 이해 관계자가 프로젝트 팀 내부와 고객에 대한 전체 프로젝트 및 기대치에 부합하는지 확인

상태 보고서 형식 정의

상태 보고서는 커뮤니케이션의 주요 도구입니다. 이 형식은 고객의 보고 요구 사항에 맞게 조정되어야 합니다.

성공 기준 및 정의

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

  • 프로젝트의 성공적인 결과를 정의하는 내용입니다.
  • 성공에 대한 정의를 충족하는 데 필요한 특정 기준.

성공 기준을 충족시키는 데 사용됩니다.

  • KPI 기준
  • 구현 전체에서 결정을 내릴 때.

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

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

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

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

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

시스템 아키텍처 정의

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

시스템 아키텍처 설명서

시스템 아키텍처를 설명하는 문서인터페이스, 네트워크 위치, 모든 환경을 위한 통합 등 다양한 정보를 제공합니다.

시스템 아키텍처 보안 개념

시스템 아키텍처가 보안 정책을 준수하도록 하는 방법에 대한 높은 수준의 개요입니다. 다음과 같은 이점이 있습니다.

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

시스템 위험 요소가 식별되고 확인됨

위험 평가(또는 기타 검토)에서 발견된 위험 요소는 식별하고 평가됩니다.

  • 각 측면에서 암시된 위험 수준
  • 이러한 문제를 해결하는 데 필요한 구현 변경에 대한 예상 노력과 함께.

팀이 성공 정의 및 기준에 대해 알고 있습니다.

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

팀이 통신 계획에 대해 알고 있습니다.

모든 팀원이 고객과 소통해야 하는 사람과 구체적인 방법 및 시기를 알고 있는지 확인합니다.

팀은 프로젝트와 기대를 이해함

프로젝트 팀 내부 및 고객에게 제공되는 전체 프로젝트 및 기대치에 맞게 조정됩니다.

기술 요구 사항

이러한 요구 사항은 솔루션을 지원하는 서비스의 기술 구현에만 해당됩니다.

기술 위험 요소 확인됨

잠재적인 기술적 위험 파악 및 확인 기술적 위험에는 다음이 포함됩니다.

  • 교차 사이트 스크립팅
  • 최종 사용자 확인 입력 필드
  • 인프라
  • 기술 시대
  • 통합 수
  • 및 종속성

기술 사양

기술 사양이 다루는 내용(기타 정보 포함):

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

템플릿 사양

필요한 템플릿에 대한 사양입니다. parsys, 블루프린트 및 상속 매핑을 비롯한 세부 사항을 포함해야 합니다.

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

테스트 케이스

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

테스트 내용

테스트 컨텐츠는 가능한 프로덕션 컨텐츠와 비슷해야 합니다. 모든 시나리오를 테스트할 수 있도록 충분히 선택해야 합니다.

테스트 환경 준비

자동화된 배포를 통해 모든 릴리스 후보 코드가 최신 테스트 준비가 되었는지 확인하십시오.

테스트 보고서

테스트 결과를 자세히 설명하는 보고서;포함:

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

다음 사항에 유의해야 합니다.

  • 모든 테스트 팀은 중립을 지키고 테스트 결과를 전달하도록 허용해야 합니다.
  • 프로젝트 관리자는 결과에 미치는 영향을 평가하고 적절한 조치를 결정하는 것이 책임이다.

테스트 세트

자동화 세트 및 도구 선택 이러한 구성 요소는 사용 사례를 포함한 테스트를 자동화하는 데 사용됩니다.

테스트 도구 세트가 선택된

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

테스트 개념

Testing Concept는 해당 프로젝트에 대한 테스트를 매우 세부적으로 표시하는 개요입니다.QA, UAT, 성능, 보안 및 통합 테스트를 포함합니다.

테스트 플랜

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

테스트 범위

이러한 요구 사항은 솔루션을 지원하는 서비스의 기술 구현에만 해당됩니다.

전략 테스트

테스트 전략에서는 품질 보증 및 사용자 수락 테스트를 위한 고급 전략을 대략적으로 설명합니다. 여기에는 타임라인, 보고 커덴스 및 실행이 포함됩니다.

제3자 통합 개념

제3자 시스템과의 통합을 위한 건축 및 시스템 수준 개념.

제3자 통합 사양

제3자 시스템의 지원 기능 및 통합에 대한 요구 사항(기능 및 비기능 모두)에 대한 세부 사항입니다.

제3자 보안 개념

제3자 통합의 보안을 보장하는 개념. 적절한 보안 정책을 준수해야 합니다.

통합을 위한 제3자 시스템

통합 구현을 위해 적절한 설명서와 함께 모든 제3자 시스템을 사용할 수 있는지 확인합니다.

타사 시스템 액세스 활성화

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

제3자 테스트 개념

정의:

  • 통합을 테스트하는 데 사용 사례
  • 제3자 응용 프로그램과 관련된 기능

임계값 정의

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

예:

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

타임라인 및 마일스톤

이렇게 하면 다음과 같이 사용할 프로젝트 타임라인과 계약 마일스톤을 정의해야 합니다.

  • 송장 발급.
  • 성공 정의, 성공 기준 및 KPI에 맞게 조정합니다.

총 프로젝트 노력

프로젝트의 각 리드에서 모든 노력이 합쳐져야 한다.비용, 개발, 시스템 엔지니어링, 건축 및 테스트 등을 비롯한 다양한 분야 지원

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

교육 자료

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

프로젝트의 범위와 기대 이해

적절한 페르소나는 그들이 완전히 이해했음을 확인해야 한다:

  • 프로젝트의 범위
  • 모든 고객의 기대치
  • 이는 프로젝트의 단계별로 개인별 모든 의사 결정의 기본이 됩니다.

URL 처리 개념

URL 처리 개념이 다음과 같은 AEM 특정 URL 기능에 포함되어야 합니다.

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

이 개념 또한 고려해야 합니다.

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

사용 사례

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

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

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

사용자 안내서

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

  • 작성자
  • 파워 유저
  • 관리자

유효성이 확인된 예산 계획

예산 계획은 모든 이해 관계자에 의해 검토 및 검증되어야 한다. 인보이스 발행, 금액 및 방법/예산 보고 타이밍 등의 세부 사항을 확인해야 합니다.

흰색 상자 테스트 결과

화이트 박스 테스트는 해당 기능이 아닌 애플리케이션의 내부 구조나 작동 방식을 테스트하는 방법입니다. 화이트 박스 테스트는 소프트웨어 테스트 프로세스의 유닛, 통합 및 시스템 수준에서 적용할 수 있습니다.

워크플로 사양

워크플로우 개념에 따라 이러한 사양은 전체 워크플로우를 생성하는 단계를 자세히 정의해야 합니다.

각 워크플로우의 사양은 다음과 같아야 합니다(최소).

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

워크플로우 개념

워크플로우를 통해 AEM 활동을 자동화할 수 있습니다. 워크플로우 컨셉 요약은 다음과 같습니다.

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

이 페이지에서는

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now