Show Menu
화제×

검사 목록 - 추가 참조

이 페이지에서는 프로젝트 관리 - 우수 사례 검사 목록에서 다루는 문서 및 원칙을 세부적으로 추가하거나 보완할 수 있습니다 .

AEM - 무엇을 사용할 예정입니까?

이 하위 섹션의 목록은 완전하지는 않지만, 소개용으로 작성된 것입니다.

AEM 내의 기능

AEM을 구현할 때(특히 처음) AEM의 기능 및 워크플로우를 검토하여 원하는 영역을 확인해야 합니다.
사용할 AEM의 기능과 디자인에 미치는 영향을 고려해 보십시오.예를 들면 다음과 같습니다.
또한 릴리스 노트에서 다양한 버전의 AEM에 대한 새로운 기능이 추가된 시기를 확인하십시오.

통합

AEM은 다른 Adobe 제품 및/또는 타사 서비스와 통합할 수 있습니다. 이러한 기능을 사용하면 언제든지 성능과 기능을 향상시킬 수 있습니다.
자세한 내용은 솔루션 통합을 참조하십시오.

마이그레이션 또는 업그레이드?

주요 고려 사항은 다음 중 어느 것을 원하는지 여부입니다.
  • 기존 설치를 업그레이드합니다.
  • 현재 시스템에서 새 설치로 컨텐츠를 마이그레이션합니다.
이전 버전에서 현재 버전으로 이동하는 경우 다음 두 가지 옵션이 있습니다.
  • 패키지 관리자를 사용하여 이전 시스템에서 새 시스템으로 모든 컨텐츠 및 애플리케이션 코드를 내보냅니다.
  • 기존 시스템을 적절하게 업그레이드하십시오. 대부분의 경우 권장되는 옵션입니다.

기본 기준 규칙

모든 프로젝트와 마찬가지로 가능한 한 빨리 준거법 제정이 중요하다. 이러한 쿠키에는 다음이 포함됩니다.
이러한 포인트는 일반적이며, 우수 사례 체크리스트는 AEM과 관련된 세부 사항을 다룹니다.
  • 역할
    이러한 사항은 명확히 정의되고 프로젝트에 관련된 모든 사람에게 알려져야 합니다. 또한 다음을 강조 표시하는 것이 좋습니다.
    • 의사 결정권자
    • 연락처
  • 책임
    • 각 역할에 대해 프로젝트와 관련된 책임을 명확히 정의하면 혼동을 방지할 수 있습니다.
  • 참여
    가능한 한 빨리 이해관계자를 참여시켜 이해 관계자가 이 프로젝트에 참여하도록 장려할 수 있으므로 참여자들의 성공을 위한 노력을 늘릴 수 있습니다.
    • 고객 측면에서는 매일 시스템을 사용하여 작업해야 하는 작성자가 포함됩니다.
    • 프로젝트 팀 내에서 품질 보증을 담당하는 담당자도 포함됩니다. 고객의 요구 사항을 더 잘 이해할수록 테스트를 계획할 수 있습니다.
  • 커뮤니케이션 경로
    • 이러한 내용이 지나치게 형식화되어서는 안 되지만, 특정 정의는 주요 사용자에게 항상 정보를 제공하고 최신 정보를 유지할 수 있도록 해야 합니다. 외부 당사자와의 의사소통에 구체적인 주의가 필요하다.
  • 프로세스
    정의할 프로세스는 개별 프로젝트에 따라 다릅니다. 다음 사항을 고려하여 이러한 간단한 작업을 다시 시도하십시오.
    • 제3자와의 상호 작용을 위한 프로세스(및 커뮤니케이션 경로) 정의예를 들어 디자인 업체 및 서드파티 소프트웨어 공급업체와 같이
    • 종종 고객은 자신의 프로젝트 관리 및 보고 절차와 도구를 갖게 됩니다.
  • 추적 도구
    프로젝트의 버그, 작업 및 기타 측면을 추적하는 데 사용할 수 있는 다양한 도구가 있습니다. 자세한 내용은 잠재적 도구 개요를 참조하십시오.
    • 여기에서 주목해야 할 중요한 점은 정보의 사본을 한 개만 보관하고 정보를 공유하는 것입니다(따라서 사용 중인 도구에 대한 액세스). 따라서 유지 관리가 용이하고 불일치가 발생하지 않도록 할 수 있습니다.
  • 범위
    프로젝트의 적용 대상을 다양한 수준에서 명확히 정의합니다.
    • 개별 릴리스(반복적인 릴리스 프로세스가 사용되는 경우 고객 또는 내부 테스트 팀에 제공되는지 여부에 관계 없음)를 참조하십시오.
    • aem 프로젝트.
    • 전체 프로젝트;타사 소프트웨어를 비롯하여 테스트, 조직 문제 및 기타 여러 가지 문제에 대한 영향을 받을 수 있습니다.
    • 특정 측면에서는 프로젝트 범위 내에 없는 내용을 설명하는 데에도 유용합니다. 이는 필수 문제로 제한되어야 하지만, 혼란과 잘못된 가정을 방지할 수 있습니다.
  • 보고
    보고할 정보, 어떤 양식, 얼마나 자주, 누구에게 어떤 정보를 보고할지 명확하게 정의할 수 있습니다.
  • 용어
    • 사용할 약어 및/또는 고객별 용어를 정의합니다.
  • 가정
    • 모든 가정을 정의합니다.
이 정보는 프로젝트 핸드북 내에 정의할 수 있습니다.또한 Wiki를 사용하면 진행 중인 변경 사항을 효율적으로 처리할 수 있습니다. 이러한 항목이 정의된 모든 곳에서 주요 요소는 다음과 같습니다.
  • 정보 정의 및 유지 관리
  • 정보는 관련된 모든 사람에게 명확하게 전달된다. 표준 프로젝트 관리 방식이지만 명확한 역할 정의와 올바른 커뮤니케이션이 프로젝트를 만들거나 방해할 수 있을 만큼 자주 반복할 수는 없습니다.
  • 추적 중인 정보는 하나의 버전만 보관됩니다.예: 버그 추적, 문제 추적 등

주요 성능 지표 및 타겟 지표

조직은 주요 성과 지표(KPI)를 사용하여 목표 도달 시 성과를 평가합니다. 이러한 지표는 특정 목표가 얼마나 효과적으로 충족되는지를 보여주는 데 사용할 수 있는 측정 가능한 값입니다.
다음 지표를 사용할 수 있습니다.
  • 비즈니스:
    • 주요 비즈니스 목표를 측정하는 데 사용됩니다.
    • 비즈니스/시나리오에 적합한 KPI를 선택하여 해당 KPI의 유형, 측정 방법, 사용 방법, 작성자 등을 명확히 파악해야 합니다.
  • 공연:
    • 시스템의 성능을 측정하는 방법을 정의합니다.
    • 일부 예에는 페이지 로드 시간, 서버 응답 시간 및 데이터베이스 쿼리 성능이 포함됩니다.
일부(전부는 아님)는 사용자가 식별하고 정의하는 대상 지표를 기반으로 할 수 있습니다.

타겟 지표

지표는 웹 사이트의 품질에 대한 양적 측정을 정의하는 데 사용됩니다. 측정 지표는 기본적으로 달성하고자 하는 성과 목표의 정의이며 KPI(주요 성과 지표) 를 정의하는 데 사용할 수 있습니다 .
많은 지표를 정의할 수 있지만, 일반적으로 사용자가 정의하는 지표에는 성과 및 동시 시청 목표가 포함됩니다. 특히, 정량화가 어려울 수 있고 종종 감정적 평가를 하는 요인이 있습니다.
  • "오늘 웹 사이트가 너무 느려 " - 언제 속도가 느립니까?
  • "모든 것이 직원들이 로그인하면 멈춥니다 " - 시스템 지원 동시 사용자 수
  • "검색하면 시스템이 멈춤 " 으로 전환됩니다. 어떤 유형의 검색 요청이 시스템에 영향을 줍니까?
  • "파일을 다운로드하는 데 시간이 걸립니다." - 다운로드 시간이 허용됩니까(일반적인 네트워크 조건에서)?
Target 지표는 프로젝트의 시작 시 다음과 같은 용도로 정의됩니다.
  • 제공할 웹 사이트의 예상 차원을 나타냅니다.
  • 달성하고자 하는 최소 품질을 나타냅니다.
  • 이러한 요소가 실제로 측정되는 방식을 정의합니다.
  • 주요 성과 지표의 기초로 사용됨
타겟 지표를 정의할 때는 항상 주의해야 합니다.
  • 너무 높게 설정하면 달성할 수 없을 수 있습니다.
  • 낮은 변동을 설정하면 강조 표시되지 않을 수 있습니다.
  • 반복적으로 그리고 일관성 있게 측정할 수 있도록
  • 측정되는 다른 요인들에 대해 균형을 맞추다
  • 특정 지표는 테스트 환경과 관련이 있지만, 일부는 실제 시나리오를 반영해야 하며 측정 및 재생산해야 하므로 프로덕션 웹 사이트에 반영해야 합니다
  • 웹 사이트에 대한 중요도에 따라 지표의 우선 순위를 매깁니다.
  • 지표를 현실적으로 모니터링할 수 있는 세트로 제한
프로젝트를 개발하는 동안 적절하게 업데이트하고 조정할 수 있습니다. 프로젝트가 성공적으로 구현된 후에는 설치를 제어하고 지속적인 작업을 위해 필요한 서비스 수준을 모니터링/유지 관리하는 데 사용할 수 있습니다.
이러한 지표를 적절히 사용하면 유용한 도구를 제공할 수 있습니다.무책임하게 사용될 때 그들은 시간을 낭비할 수 있다. 언제나 그렇듯이, 여러분은 어떤 것을 측정하고 있는지, 어떻게 측정하고 있는지, 그리고 그 이유를 이해해야 합니다.
본 조항은 고려될 기본 원칙과 문제들을 다룰 것입니다. 각 설치는 서로 다르므로 측정할 실제 값은 달라집니다.

모든 것이 프로젝트 디자인에 우선함

측정할 모든 지표는 어떤 면에서 프로젝트의 디자인에 영향을 받습니다. 반대로, 많은 문제들이 디자인 변화로 가장 잘 해결될 것이다.
따라서 디자인을 결정하기 전에 타겟 지표를 정의해야 합니다. 이를 통해 이러한 요소를 기반으로 디자인을 최적화할 수 있습니다. 프로젝트가 개발되면 기본 디자인 원칙을 변경하는 것은 어렵습니다.
웹 사이트의 구조를 만들 때 AEM 웹 사이트에 대해 권장되는 구조를 따릅니다. 다음 문제 및/또는 원칙을 이해해야 합니다.
  • 웹 사이트 컨텐츠를 구성하는 방법
  • 템플릿 및 구성 요소의 작동 방식
  • 캐싱 방식
  • 개인화된 컨텐츠의 영향
  • 검색 기능 작동 방식
  • CSS 및 관련 기술을 사용하여 크기가 작고 중복되지 않는 HTML 코드를 만드는 방법
디자인이 지침을 따르지 않는다고 생각되거나, 몇 가지 의미를 잘 모르는 경우 프로그래밍 단계를 시작하거나 컨텐츠를 작성하기 전에 이러한 문제를 명확히 하십시오.

인프라

인프라를 정의하거나 평가하려면 다음과 같은 타겟 값을 정의하는 데 도움이 됩니다.
  • 방문자/일평균과 최고점
  • 히트/일;평균과 최고점
  • 사용 가능한 웹 페이지 수
  • 웹 컨텐츠 볼륨
사용자의 상황과 웹 사이트의 전략적 중요도에 따라 인프라를 평가하고 선택할 수 있습니다.
  • 서버 수
  • aem 인스턴스 수(작성자 및 게시)

공연

평가할 수 있는 몇 가지 성능 요소가 있습니다.
  • 개별 페이지를 기준으로 응답 시간:
    • 작성 환경의 응답 시간
    • 게시 환경의 응답 시간
  • 검색 요청에 대한 응답 시간
이 섹션은 실제 성능 측정의 기술 세부 사항을 확장하는 성능 최적화와 함께 읽을 수 있습니다.

개별 페이지에 대한 응답 시간

주요 문제는 웹 사이트에서 방문자 요청에 응답하는 시간입니다.
이 값은 각 요청에 따라 다르지만 평균 대상 값을 정의할 수 있습니다. 이 값이 달성 가능하고 유지 관리 가능한 것으로 확인되면 웹 사이트의 성능을 모니터링하고 잠재적인 문제의 개발을 나타내는 데 사용할 수 있습니다
작성자 및 게시 환경의 타겟 차이
타깃팅할 응답 시간은 타겟 고객을 반영하여 작성 및 게시 환경에서 다릅니다.
  • 작성 환경
    이 환경은 작성자가 컨텐츠를 입력하고 업데이트할 때 사용되므로 다음과 같은 작업을 수행해야 합니다.
    • 컨텐트 페이지를 업데이트할 때 높은 수의 요청을 생성하는 소수의 사용자 및 해당 페이지의 개별 요소를 위한 것입니다.
    • 웹 사이트에 컨텐츠를 게시하기 위한 생산성을 극대화할 수 있도록 최대한 빠른 시간 안에
  • 게시 환경
    이 환경에는 사용자가 사용할 수 있도록 만든 컨텐츠가 포함되어 있습니다.
    • 속도는 여전히 중요하지만 작성 환경보다 느립니다
    • 추가 성능 향상 메커니즘은 종종 적용됩니다.
      • 컨텐츠가 캐시됩니다.
      • 로드 밸런싱이 적용됨

타겟 응답 시간 설정

따라서 여러분은 성취 가능한(평균) 응답 시간을 어떻게 결정할 수 있을까요? 이것은 종종 경험의 문제입니다.
  • 웹 사이트의 과거 경험
  • aem을 사용한 경험
  • 평균 응답 시간을 초과하는 복잡한 페이지 인식(가능한 경우 개별적으로 최적화해야 함)
그러나(제어된 상황에서) 다음 지침을 적용할 수 있습니다.
  • 페이지 요청의 70%는 100ms 이내에 응답해야 합니다.
  • 페이지 요청의 25%는 100ms-300ms 이내에 응답해야 합니다.
  • 페이지 요청의 4%는 300ms-500ms 이내에 응답해야 합니다.
  • 페이지 요청의 1%는 500ms-1000ms 이내에 응답해야 합니다.
  • 어떤 페이지도 1초보다 느리게 응답할 수 없습니다.
위의 숫자는 다음 조건을 가정합니다.
  • 게시 시 측정(제작 환경 및/또는 CFC 오버헤드 없음)
  • 서버에서 측정됨(네트워크 오버헤드 없음)
  • 캐시되지 않음(AEM 출력 캐시 없음, 발송자 캐시 없음)
  • 종속성이 많은 복잡한 항목만(HTML, JS, PDF, ...)에만 해당
  • 시스템에 다른 로드 없음
응답 시간을 모니터링하는 데 사용할 수 있는 메커니즘은 다음과 같습니다.
  • AEM request.log를 사용하여 응답 시간 모니터링
    성능 분석의 좋은 시작점은 요청 로그입니다. 다른 정보 중에서 이 정보를 사용하여 개별 요청의 응답 시간을 볼 수 있습니다. 자세한 내용은 성능 최적화를 참조하십시오.
  • HTML 주석을 사용하여 응답 시간 모니터링
    *HTML comments* can be used to include response time information within the source of each page:
    </body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests

검색 요청

검색 요청은 두 가지 측면에서 웹 사이트에 상당한 영향을 줄 수 있습니다.
  • 실제 검색의 응답 시간
    • 신속한 검색 기능은 웹 사이트의 품질 목표입니다
  • 일반 성능에 미치는 영향
    • 검색 기능은 컨텐츠의 섹션(잠재적으로 큰 부분) 또는 특별히 추출된 인덱스를 스캔해야 하므로 최적화되지 않은 경우 전체 시스템의 성능에 영향을 줄 수 있습니다
검색 요청에 대한 타겟을 설정하는 것은 다음에 따라 경험의 문제입니다.
  • aem의 경험
  • 다른 목표와 비교하여 검색의 사용 빈도에 대한 평가
  • 지속성 관리자
  • 검색 색인
  • 검색 기능의 복잡성1개의 검색어만 입력할 수 있는 기본 검색 기능은 사용자가 AND/OR/NOT을 사용하여 복잡한 검색문을 작성할 수 있는 고급 검색보다 빠릅니다.
이러한 작업은 프로젝트 처음부터 계획하고 통합되어야 합니다. 모니터링에 사용할 수 있는 메커니즘은 다음과 같습니다.
  • AEM request.log를 사용하여 검색 응답 시간 모니터링
    다시 request.log를 사용하여 검색 요청에 대한 응답 시간을 모니터링할 수 있습니다.자세한 내용은 성능 최적화를 참조하십시오.
  • 검색 응답 시간 측정을 위한 프로그래밍 방식
    검색 요청 및 해당 성능에 대해 수집한 정보를 사용자 정의하려면 프로젝트 소스 코드에 정보 수집을 포함하는 것이 좋습니다.자세한 내용은 성능 최적화를 참조하십시오.

동시 사용

웹 사이트는 작성자 및 게시 환경 모두에서 많은 사용자/방문자가 사용할 수 있게 됩니다. 테스트 시 사용한 것보다 자주 숫자가 증가하지만 예측하기가 어렵습니다. 부정적인 성능에 영향을 주지 않고 평균 동시 사용자/방문자 수에 맞게 웹 사이트를 설계해야 합니다. 다시 한 번 동시성 테스트를 하는 데 사용할 request.log 수 있습니다.자세한 내용은 성능 최적화를 참조하십시오.
동시 사용자 수에 대한 대상은 환경 유형에 따라 달라집니다.
  • 작성 환경
    • 일반적으로 동시 사용자 수를 정확하게 예측할 수 있습니다. 전체 작성자 수는 알 수 있지만(아마도) 모두 동시에 활성화되지는 않습니다.
  • 게시 환경
    • 예측하기가 더 어려우므로 대상 값을 선택해야 합니다. 다시 한 번 말씀드리자면 현재 웹 사이트의 경험과 새로운 웹 사이트의 실제 기대치를 기반으로 해야 합니다.
    • 특별 이벤트(예: 매우 인기 있는 새로운 컨텐츠를 게시할 때)는 기대치를 초과할 수 있으며 기능(특정 이벤트 티켓을 판매할 수 있는 경우 인쇄소에서 종종 보고됨)을 초과할 수 있습니다.

용량 및 볼륨

관련 지표를 논의하기 전에 용어의 빠른 정의를 참조하십시오.
  • 볼륨
    • 시스템에서 처리 및 배달되는 출력 양입니다.
  • 용량
    • 시스템의 볼륨 전달 능력
    • 각 단계에서 용량 및 볼륨은 아래 표와 같이 다르게 측정됩니다. 최상의 성능을 위해서는 각 단계에서 용량이 볼륨과 일치하는지, 모든 단계에서 용량과 볼륨이 공유되는지 확인하십시오. 예를 들어 모든 요청에 대해 서버에서 탐색하는 대신 클라이언트 컴퓨터에서 탐색을 계산하거나 캐시에 저장할 수 있습니다.
  • 용량 및 볼륨
    What / Where
    용량
    볼륨
    클라이언트
    사용자 컴퓨터의 계산 성능
    페이지 레이아웃의 복잡성.
    네트워크
    네트워크 대역폭.
    페이지 크기(코드, 이미지 등).
    발송자 캐시
    웹 서버의 서버 메모리(기본 메모리 및 하드 드라이브)
    웹 서버(기본 메모리 및 하드 드라이브). 캐시된 페이지의 수 및 크기입니다.
    출력 캐시
    AEM 서버의 서버 메모리(기본 메모리 및 하드 드라이브).
    출력 캐시의 페이지 수 및 크기, 페이지당 종속성 수입니다. 디스패처 캐시가 이 볼륨을 낮춥니다.
    웹 서버
    웹 서버의 계산 성능
    요청 금액. 캐싱을 통해 이 볼륨이 줄어듭니다.
    템플릿
    웹 서버의 계산 성능
    템플릿의 복잡성.
    보관소
    저장소의 성능입니다.
    저장소에서 로드된 페이지 수입니다.

기타 지표

앞의 섹션에서는 정의할 기본 지표를 자세히 설명합니다.
특정 요구 사항에 따라 별도의 지표를 정의하거나 위의 분류를 고려하면 유용할 수 있습니다.
그러나 웹 사이트의 모든 측면을 측정하고 정의하려고 하지 않고 쉽고 안정적으로 작동하는 정확하고 핵심 지표 세트를 갖는 것이 좋습니다. 웹 사이트는 본질적으로 사용자에게 전달되는 즉시 변화하고 진화하게 됩니다.

보안

보안은 중요하며 점점 더 치열해지는 도전입니다. 프로젝트의 초기 단계에서 검토 및 계획되어야 합니다 .
보안 검사 목록 세부 사항은 배포 시 AEM 설치가 안전한지 확인하는 데 수행해야 하는 단계입니다. 기타 보안 측면에는 보안(개발 시) 및 사용자 관리 및 보안이 포함됩니다 .

병렬 및 반복 작업

다음을 수행합니다.
  • AEM 프로젝트의 첫 번째 구현과 관련된 개요를 제공합니다.
  • 개요특정 단계/마일스톤 /작업에 대한 프로젝트 검사 목록을 참조하십시오.
  • 모든 시간의 저울은 이론적이다.
표준 AEM 프로젝트를 새로 구현하려면 다음과 같은 작업을 고려해야 합니다.
  • 판매 프로세스에서 전환
  • 고객 애플리케이션 구현( 개발 ).
  • 고객 사이트(인프라)에서 인프라(및 관련 프로세스)의 설치 및​ 구성 .
  • 컨텐츠(컨텐츠)의 생성(또는​ 마이그레이션 )
  • 운영(유지​ 관리/지원 )으로 인계
  • 후속 릴리스.
모든 측면에서는 반복 방법을 사용하는 것이 좋습니다.
프로젝트 시작을 Soft Launch( 가용성, 여러 번 반복) Hard Launch(Full Availability - Live)로 분할하여 프로덕션 환경에서 현실적인 조건에서 조정, 최적화 및 사용자 트레이닝을 수행할 수 있습니다.
프로젝트의 수명 주기 동안 수행(또는 평가)해야 하는 작업의 예는 프로젝트 검사 목록을 참조하십시오.
각 카테고리에 대한 몇 가지 사항은 다음과 같습니다.
  • 개발
    • 먼저 기본 아키텍처를 정의합니다.
    • 개발을 위해 여러 번 반복(스프린트)을 사용합니다.
      • 첫 번째 스프린트는 첫 번째 전체 개발 주기와 같습니다.
      • 첫 번째 스프린트는 테스트 환경에 첫 번째 배포를 가져옵니다.
      • 모든 스프린트는 실행 가능한 결과를 가지고 있다.
      • 각 스프린트는 고객 사인오프(정형 테스트 최소 및 피드백 포함)를 받습니다.
    • 프로젝트 동안 사용 가능한 AEM 버전의 업데이트에 대한 이벤트를 계획합니다.
    • 인쇄 기간 동안 테스트 및 최적화를 계획할 수 있습니다.
    • 안정화 및 최적화 단계 계획
    • 추가 릴리스에 대해 계획할 항목 로그를 만듭니다.
    • 파트너 참여 및 인계 계획
  • 인프라
    • 기본 아키텍처를 먼저 정의합니다.
      • 성능 요구 사항을 정의합니다.
      • 성과 목표 정의(예: 기대치 정의)
      • 하드웨어 및 인프라 아키텍처 정의크기 조정을 포함합니다.
      • 배포 정의
    • 여러 반복 사용;for first sprint and initial configuration prepare:
      • 개발 환경.
      • 개발 프로세스.
      • 테스트 환경.
      • 배포 프로세스(구성 관리 포함).
    • 여러 로드 테스트에 대한 플랜
    • 인쇄 기간 동안 테스트 및 최적화를 계획할 수 있습니다.
    • 안정화 및 최적화 단계 계획
    • 가능한 한 빨리 프로덕션 환경에 배포할 수 있습니다(운영 팀이 경험을 얻기 위해 시스템을 설정할 수 있도록 허용).
    • 지정된 사용자와 정의된 역할을 가능한 한 빨리 사용할 수 있습니다.
    • 교육 계획(예: 관리자 교육).
    • 작전에 대한 인계 계획
  • 컨텐트
    • 기본 아키텍처:
      • 콘텐츠 계층 구조 개선
      • 컨텐츠 개념을 정의하는 데 도움이 됩니다.
      • MSM 사용 및 레이아웃을 정의합니다.
      • 역할, 그룹, 워크플로우 및 권한을 정의합니다.
    • 오프라인 페이지 만들기가 유용한지 고려하십시오.
    • 테스트 및 피드백에 사용하기 위해 첫 번째 페이지와 컨텐츠를 조기에 만들 수 있도록 계획하십시오.
    • 기존 컨텐츠 마이그레이션 계획
    • 리팩토링 후 "인스프린트 마이그레이션"을 계획합니다.
    • "컨텐츠 번다운" 계획(go-live 컨텐츠의 사이트 맵)

시간 및 노력 계산

결과 작업 목록에 따라 (수준 높은) 작업 정의에 대한 시간과 노력을 초기 추적으로 만들 수 있습니다. 여기에는 누가 언제 무엇을 할 것인지(고객 또는 파트너)에 대한 표시가 포함되어야 합니다.
다음 목록은 관련된 작업의 표준 근사치와 상호 관계를 보여주므로 비용을 보여줍니다.
이러한 수치는 초기 추정치에만 사용할 수 있습니다. 숙련된 AEM 개발자는 세부 분석을 수행해야 합니다.
위상
노력
개발
각 구성 요소 노드에 대해 대략적인 2-4시간 추정은 모든 개발 요구 사항을 다룹니다.
개발자 테스트
개발의 15%
후속 작업
개발 10%
설명서
개발의 15%
JavaDoc 설명서
개발 10%
버그 수정
개발의 15%
프로젝트 관리
지속적인 프로젝트 관리 및 거버넌스를 위한 프로젝트 비용의 20%
그런 다음 사용 가능하거나 필요한 리소스를 마감 시간 및 비용에 연결할 수 있습니다.

참조 아키텍처

참조 아키텍처는 AEM 아키텍처에 대한 템플릿 솔루션을 제공하기 위해 제공됩니다. 참조 아키텍처는 크기 조절, 안정성 및 보안 등 기업 시스템에서 흔히 발생하는 문제를 해결합니다.
다음 사이트 지표를 정의해야 합니다.
분류
정의
인터넷 사이트 수
인트라넷 사이트 수
코드 베이스의 수(예: 인터넷과 인트라넷이 다른 경우)
개별 페이지 수
사이트 방문 횟수/일 수
페이지 보기 횟수/일 수
데이터 전송 볼륨(GB)/일
동시 사용자 수(폐쇄된 사용자 그룹)
동시 방문자 수(게시)
동시 작성자 수
등록된 작성자 수
페이지 활성화/근무일 수
배포 중 페이지 활성화 수

잠재적 도구 개요

사용할 수 있는 도구를 알리기 위해 다음 목록이 제공됩니다. 이것은 광범위한 추천 목록이 아니라 소개 자료로 작성되었으며, 선호하는 다른 도구를 사용하는 것을 막지 말아야 합니다.
제품 설명
AEM
AEM 자체에서는 애플리케이션을 모니터링, 테스트, 조사 및 디버깅하는 데 도움이 되는 다양한 메커니즘을 제공합니다.포함:
셀레늄 Selenium 은 오픈 소스 테스트 툴입니다. 테스트는 사용자의 작업 방식을 에뮬레이션하여 브라우저에서 직접 실행됩니다.
Microsoft Project 일반적으로 사용되는 프로젝트 관리 툴
지라 Jira 는 소프트웨어 버그의 세부 사항을 추적하고 관리하기 위한 오픈 소스 툴입니다. 워크플로우는 필요에 따라 버그 세부 사항에 적용될 수 있습니다.
Git Git 은 수정 버전 제어 소프트웨어입니다.
Eclipse
Eclipse는 다양한 프로젝트로 구성된 오픈 소스 IDE입니다. 이러한 플랫폼은 전체 수명주기에 걸쳐 소프트웨어를 구축, 배포 및 관리하기 위한 확장 가능한 프레임워크, 툴 및 런타임으로 구성된 개방형 개발 플랫폼을 구축하는 데 중점을 두고 있습니다.
자세한 내용은 Eclipse를 사용하여 AEM 프로젝트를 개발하는 방법을 참조하십시오.
IntelliJ
포괄적인 기능을 제공하는 전문(따라서 라이선스 비용 부담) IDE
자세한 내용은 IntelliJ IDEA를 사용하여 AEM 프로젝트를 개발하는 방법을 참조하십시오.
Maven Maven은 프로젝트의 빌드 프로세스(소프트웨어 및 설명서)를 관리할 수 있는 소프트웨어 프로젝트 관리 및 이해 도구입니다.

추가 읽기

또한 다음 섹션은 특히 관심 있는 부분입니다.

우수 사례

Adobe는 모든 단계 및 대상에 대한 추가적인 우수 사례를 제공합니다.